Remapollo for A4060

[Marmes]

Hello!

Is there any remaper like remapollo for Apollo 4060, Remapollo 1.8 doesn't seem to work with A4060, or is there a way to put it working?

Cheers!

[utri007]

Of course it works with Apollo 4060.

You tell very little about your problem and setup. Have you read manutal? What 68060.library you are using? What other programs you start early on startup-sequence?

As a alternative you can use MuLibs http://aminet.net/package/util/libs/MMULib

[Marmes]

Here is my startup-sequence for my A4000D with Apollo 4060
Library for 060 is 60.10 as recomended. Patch was made from an old one also as recomended.
Modules were made with RUX AmigaOS ROM Update.

Still hangs, don't know why.

; $VER: Startup-Sequence_HardDrive 45.7 (30.10.2016) for BB4
; Startup-Sequence for hard drive systems

C:DRAP
IF WARN
C:RemAPollo QUIET MAC Modules LIBS:OS3.9/OS_Module1 OS_Module2 OS_Module3 OS_Module4 OS_Module5 OS_Module6 OS_Module7 OS_Module8 OS_Module9
EndIF
FailAt 21
C:LoadResident >NIL: DEVS:trackdisk.device
FailAt 20
C:LoadModule >NIL: DEVS:battmem.resource DEVS:console.device DEVS:FileSystem.resource DEVS:misc.resource DEVS:potgo.resource L:FastFileSystem L:Ram-Handler L:Shell-Seg LIBS:dos.library LIBS:layers.library REVERSE NOREBOOT
C:SetPatch SKIPROMUPDATES console.device,dos,filesystem,FileSystem.resource,ram-handler,shell QUIET

C:Version >NIL:
C:AddBuffers >NIL: DF0: 15
FailAt 21

C:MakeDir RAM:T RAM:Clipboards RAM:ENV RAM:ENV/Sys
C:Copy >NIL: ENVARC: RAM:ENV ALL NOREQ

Resident >NIL: C:Assign PURE
Resident >NIL: C:Execute PURE

Assign >NIL: ENV: RAM:ENV
Assign >NIL: T: RAM:T
Assign >NIL: CLIPS: RAM:Clipboards
Assign >NIL: REXX: S:
Assign >NIL: PRINTERS: DEVS:Printers
Assign >NIL: KEYMAPS: DEVS:Keymaps
Assign >NIL: LOCALE: SYS:Locale
Assign >NIL: LIBS: SYS:Classes ADD
Assign >NIL: HELP: LOCALE:Help DEFER

BindDrivers
C:Mount >NIL: DEVS:DOSDrivers/~(#?.info)

C:LoadMonDrvs

;IF EXISTS DEVS:Monitors
;  IF EXISTS DEVS:Monitors/VGAOnly
;    DEVS:Monitors/VGAOnly
;  EndIF

;  C:List >NIL: DEVS:Monitors/~(#?.info|VGAOnly) TO T:M LFORMAT "DEVS:Monitors/%s"
;  Execute T:M
;  C:Delete >NIL: T:M
;EndIF

SetEnv Language "english"
SetEnv Workbench $Workbench
SetEnv Kickstart $Kickstart
UnSet Workbench
UnSet Kickstart

C:AddDataTypes REFRESH QUIET
C:IPrefs
C:ConClip

Path >NIL: RAM: C: SYS:Utilities SYS:Rexxc SYS:System S: SYS:Prefs SYS:WBStartup SYS:Tools SYS:Tools/Commodities

SYS:System/REXXMast >NIL:

SYS:C/MakeLink RAM:disk.info ENVARC:SYS/def_RAM.info SOFT

IF EXISTS S:User-Startup
  Execute S:User-Startup
EndIF

Resident Execute REMOVE
Resident Assign REMOVE

C:LoadWB
EndCLI >NIL:

[utri007]

You should use only bb 1&2. Those patches will cause problems.

Use setpach to load bb1 ROM update and remove everything else.

[Oldsmobile_Mike]

You should use only bb 1&2. Those patches will cause problems.

Hush, you.  :laughing:

[PanterHZ]

When dealing with modules that gets loaded into memory, there is one rule to have in mind: A module that already has been been loaded, cannot be replaced by another module!

This is what causes the problems you are having. An example is that FileSystem.resource is attempted to be loaded on the C:LoadModule line, when it already has been loaded as OS_Module5 on the C:RemAPollo line.

The file comments of the OS_Modules should give an indication of what type of files they really are, but here is a list over the ones present on my A1200 (version info to the right):

OS_Module1 - ROMUpdate 44.57
OS_Module2 - exec.library 45.20
OS_Module3 - bootmenu 44.7
OS_Module4 - fs 45.13
OS_Module5 - FileSystem.resource 45.10
OS_Module6 - scsi.device 43.43
OS_Module7 - ram-handler 44.23
OS_Module8 - console.device 44.8
OS_Module9 - shell 45.7

In your case, the version of OS_Module6 (scsi.device) should be different than mine. I can also mention that OS_Module4 is FastFileSystem.

I will suggest that you simply disable the C:LoadModule line, and add/replace stuff on the C:RemAPollo line instead. For starters, try this:

C:RemAPollo QUIET MAC Modules LIBS:OS3.9/OS_Module1 OS_Module2 OS_Module3 L:FastFileSystem DEVS:FileSystem.resource OS_Module6 L:Ram-Handler DEVS:console.device OS_Module9

If you can get this to work, try adding the the rest of the modules (one by one):

DEVS:battmem.resource
DEVS:misc.resource
DEVS:potgo.resource
L:Shell-Seg
LIBS:dos.library
LIBS:layers.library

Have in mind that some of these modules cannot be used since other versions of them already is present in one of the OS_Module files (perhaps battmem & potgo?). It can also be a good idea to not use the QUIET option with RemAPollo when you are just testing stuff. This way you will know what's wrong when stuff doesn't work.

[PanterHZ]

Use setpach to load bb1 ROM update and remove everything else.

This is the easiest way, but certainly not the best :-)

When done correctly, it is possible to get RemAPollo to load both Kickstart and BB 2 ROM update into memory without any conflicts (which also leads to just a single reboot upon booting).

Of course, adding BB 3 & 4 to the mix, increases the complexity. That's why I have been reluctant of doing this on my already heavily patched A1200. I want to try this on a fresh and clean OS3.9 install first. But I did help out a guy on Facebook a few years ago, and he got it to work.

[dannyp1]

"A module that already has been been loaded, cannot be replaced by another module!"

Are you sure about this? I was under the impression that LoadModule would replace it if you are loading a newer version. Maybe I'm confused?

[utri007]

RemApollo also supports 1mb kikcstart. So create custom kickstart using Remus/Romus with everything you need and load it with RemApollo.

[Marmes]

OK, everything works except DRAP command that stalls Apollo4060
You need to patch the 060 library v60.10 in order to make it run.
Patcher is included.
From that startup sequence I only removed DRAP. Also replaced OS3.9 Loadmodule for the latest one from aminet. Copied to C:
Now lets see what's going on with DRAP

[PanterHZ]

"A module that already has been been loaded, cannot be replaced by another module!"

Are you sure about this? I was under the impression that LoadModule  would replace it if you are loading a newer version. Maybe I'm  confused?

That might be true, but in this case it's not only LoadModule that loads modules, RemAPollo does it too. There's a possibility that one of them doesn't like what the other do, which is also the reason why I suggested to use RemAPollo only.

RemApollo also supports 1mb kikcstart. So create custom kickstart using Remus/Romus with everything you need and load it with RemApollo.

Sounds really complicated, but it would have been fun to try it out though.

[PanterHZ]

OK, everything works except DRAP command that stalls Apollo4060
You need to patch the 060 library v60.10 in order to make it run.
Patcher is included.
From that startup sequence I only removed DRAP. Also replaced OS3.9 Loadmodule for the latest one from aminet. Copied to C:
Now lets see what's going on with DRAP

If you haven't done so already, you should copy icon.library and workbench.library to the LIBS:OS3.9 dir, and rename the original ones so that the system cannot find them.
In other words, something like this:
  LIBS:-OFF-icon.library
  LIBS:-OFF-workbench.library
  LIBS:OS3.9/icon.library
  LIBS:OS3.9/workbench.library

Then add the libraries to the end of the RemAPollo line. If you still want to try loading modules with LoadModule, the RemAPollo line should now look like this:

C:RemAPollo QUIET MAC Modules LIBS:OS3.9/OS_Module1 OS_Module2 OS_Module3 OS_Module4 OS_Module5 OS_Module6 OS_Module7 OS_Module8 OS_Module9 workbench.library icon.library

I will still suggest that you at least try without using LoadModule though, so that the line looks more like this instead:

C:RemAPollo QUIET MAC Modules LIBS:OS3.9/OS_Module1 OS_Module2 OS_Module3 L:FastFileSystem DEVS:FileSystem.resource OS_Module6 L:Ram-Handler DEVS:console.device OS_Module9 workbench.library icon.library DEVS:battmem.resource DEVS:misc.resource DEVS:potgo.resource L:Shell-Seg LIBS:dos.library LIBS:layers.library

Also, since the entire ROM update gets loaded by RemAPollo, your SetPatch line should then look like this:

  C:SetPatch NOROMUPDATE QUIET


PS! The above mentioned stuff regarding icon.library, workbench.library and SetPatch, is also mentioned in the RemAPollo documentation.

[guest11527]

IF WARN
C:RemAPollo QUIET MAC Modules LIBS:OS3.9/OS_Module1 OS_Module2 OS_Module3 OS_Module4 OS_Module5 OS_Module6 OS_Module7 OS_Module8 OS_Module9
EndIF
FailAt 21
C:LoadResident >NIL: DEVS:trackdisk.device
FailAt 20
C:LoadModule >NIL: DEVS:battmem.resource DEVS:console.device DEVS:FileSystem.resource DEVS:misc.resource DEVS:potgo.resource L:FastFileSystem L:Ram-Handler L:Shell-Seg LIBS:dos.library LIBS:layers.library REVERSE NOREBOOT
C:SetPatch SKIPROMUPDATES console.device,dos,filesystem,FileSystem.resource,ram-handler,shell QUIET

Quite frankly, why are you using four different module loaders? "LoadModule" alone is sufficient. This aside, there is no bug in trackdisk.device that requires fixing, just use the one in ROM. Just the reverse, the latest "improvements" made in it can damage some hardware by decalibrating the read-head of the unit.

Hence:
a) Remapollo does not seem to be updated since 15 years at least. Is it wise to depend on a third party tool this old? Is there a particular need for this tool?

b) LoadResident has been superceeded by LoadModule, so remove it.

c) There is no advantage in a later trackdisk.device. Do not load this anyhow.

d) The SetPatch mechanism ROM Update should be then completely disabled:

"SetPatch NOROMUPDATE"

will do that for you. You get all the modules in the ROM Updates through "ExtractModule", which will also place them in the correct places.

All the above, once you place the Modules in the right places, can be done in a single line:

"LoadModule AUTO"

Yes, it is really that easy.

[Marmes]

So, no more need for Kickstart update? This loads directly to ram like a rekicker?

Quite frankly, why are you using four different module loaders? "LoadModule" alone is sufficient. This aside, there is no bug in trackdisk.device that requires fixing, just use the one in ROM. Just the reverse, the latest "improvements" made in it can damage some hardware by decalibrating the read-head of the unit.

Hence:
a) Remapollo does not seem to be updated since 15 years at least. Is it wise to depend on a third party tool this old? Is there a particular need for this tool?

b) LoadResident has been superceeded by LoadModule, so remove it.

c) There is no advantage in a later trackdisk.device. Do not load this anyhow.

d) The SetPatch mechanism ROM Update should be then completely disabled:

"SetPatch NOROMUPDATE"

will do that for you. You get all the modules in the ROM Updates through "ExtractModule", which will also place them in the correct places.

All the above, once you place the Modules in the right places, can be done in a single line:

"LoadModule AUTO"

Yes, it is really that easy.

[guest11527]

So, no more need for Kickstart update? This loads directly to ram like a rekicker?

Wait, what exactly is your question? A kickstart consists of several modules, and each module (except expansion) can be replaced by LoadModule. So, in principle, if you had all modules in the right format, you could replace pretty much all of it, yes.

LoadModule, LoadResident and SetPatch (and likely RemApollo) can replace modules. Of all the above, only the first three are still supported, and ROM-Module reloading has just been removed from SetPatch, which gives you two alternatives in the future, of which one is more powerful than the other.

Whatever pick you make: Select *one* tool, not four, for the same job.

As said already: "LoadModule AUTO" is all you need, once you setup your system correctly. Replacement libraries go into LIBS:, replacement devices into DEVS:, the Shell as Shell-Seg into L:, and the Ram-Handler similar to all Dos-Handlers into L: as well.