Remapollo for A4060

[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.

[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.

[PanterHZ]

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.

There seems to be some confusion here

RemAPollo is a tool specifically made to be used with a certain range of the Apollo accelerator cards. Its main purpose is to copy the entire Kickstart ROM into Fast RAM, which in turn leads to a faster Amiga (since reading from RAM is faster than from ROM). Especially Workbench gets a bit snappier and more responsive, but programs that use gadtools also opens quicker as well.

This concept worked fine until the release of BB2 for AmigaOS 3.9. Now there was a conflict between RemAPollo (DRAP) and SetPatch, which lead to the Amiga rebooting all the time (caused by the new exec.library).

The solution then was to either simply use BB1 only, or to load the BB2 ROM update as modules, like described in this thread.

Whether or not it is possible to softkick by using RemAPollo, and then only use "LoadModule AUTO" for loading modules, depends a little upon if LoadModule is kinda "softkick-aware".


PS! What I have written in this thread regarding LoadModule, is not meant by me as bashing it in any way, my point is simply that it may not be the best solution in all cases

[PanterHZ]

Another probably dumb/obvious question, but if the RemApollo tool "breaks" when using anything newer than BB2, why not just get rid of it and use another tool out there to load Kickstart into RAM?

Well, the thing is that all softkickers out there have this problem with OS3.9 and BB2 update, where SetPatch does something that makes the softkicker belive that KS ROM haven't been copied to RAM, so it does this again and reboots. Next up, SetPatch belives that the BB2 update haven't been loaded, so it does this again and reboots.

And this goes on and on in a never ending loop.

I bypass this problem on my KS2.05 Amiga 600. Here I use a tool for checking the KS version, and if it's lower than 40, then ACAtune is used for softkicking a KS3.1 ROM file. Otherwise, no softkicking is attempted.

[PanterHZ]

No, you still do not understand. If a module is in ROM, LoadModule will replace it. Only then. If you leave a module out, LoadModule will not touch it, and "ramlib" will pick it up. Exactly from the same place. This is *intentional* so you can replace the ROM with any other version, and you do not need to move the modules around.

It is really a bad idea to keep the modules in a separate place because them Ramlib will not be able to find them.

Maybe it could be an idea to make some kind of ListModule tool to go with LoadModule? This tool could then be used for scanning through the boot partition, where it displays all modules that LoadModule will find and prefer to use.

This would give the user a better overview of what LoadModule actually does.

[PanterHZ]

Well all I wanted to know was how to rekick with remapollo or if there is a good alternative for rekicking ROM.

You already have the most suitable tool installed. I promise you that it won't get any easier with another one

The main problem is that you have way too much (non standard) stuff going on in your Startup-Sequence, so it's not easy to pinpoint the exact reason for all the issues. I have tried to explain what you can do, but I realize that it may all sound a bit confusing.

So below is hopefully a more simpler explenation of what you can try, which sticks to the most basics of OS3.9 with Boing Bag 2 only (nothing more, nothing less) :


1. Do as I mentioned in another post regarding workbench.library and icon.library. In other words, copy them to the LIBS:OS3.9 dir, and rename or delete the ones in LIBS:


2. Make sure that the C:RemAPollo line looks exactly like this (everything on ONE line):

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


3. Disable the C:LoadResident and C:LoadModule lines for now by inserting a semi-colon at the beginning of the line (you can deal with these later). The lines should then look like this:

;C:LoadResident >NIL: DEVS:trackdisk.device

;C:LoadModule >NIL: DEVS:battmem.resource DEVS:console.device DEVS:FileSystem.resource DEVS:misc.resource DEVSotgo.resource L:FastFileSystem L:Ram-Handler L:Shell-Seg LIBS:dos.library LIBS:layers.library REVERSE NOREBOOT


4. There is no need for SetPatch to have anything to do with the BB2 ROM updates, since this is already taken care of by RemAPollo. So change this line from:

C:SetPatch SKIPROMUPDATES console.device,dos,filesystem,FileSystem.resource, ram-handler,shell QUIET

to:

C:SetPatch NOROMUPDATE QUIET


5. Save the Startup-Sequence and turn off the Amiga. After a couple of seconds, turn it on again, and now the Amiga should hopefully boot into Workbench.



If the above doesn't work, it may be the result of issues with your 68060.library.

[PanterHZ]

What version of remapollo you use?
In my A4000D I have 2 behaviours.
On version 1.7
if I use the
If WARN
RemAPollo ....
EndIf
...
It doesn't work, Computer freezes.
On version 1.8 I have to use If WARN.... Or it won't softkick.
In either  versions I cannot use DRAP.
According to instructions we have to apply a ptch to 68060.library (60.10), wich I did. (I followed the instructions).
If I use skipromupdate ... it works.
If I use NOROMUPDATE quiet, it doesn't softKick.
Everything works, I understand what you say, I tried it, but maybe I'm still missing something.
From what I see now, only a few parts are rekicked, so, the best solution is to :
a) Make a rom and rekick it by software with your favourite requicker. (but that will still bring you trouble with scsi.device in apollo.
b) Burn ROMs the way you want and simplify S-S by removing manythings.

I'm using RemAPollo 1.7 on my Amiga 1200 with Apollo 1240 card, and I use a patched version of the standard 68040.library. I haven't tried RemAPollo 1.8 yet, since I wasn't aware of this version.

If you have the lines like this in your Startup-Sequence:

;C:DRAP
If WARN
RemAPollo ....
EndIf

Then whatever is between the "IF WARN" and "EndIf" lines will be skipped since there's nothing above them that may give a return code of 5 (WARN) or more. This has nothing to do with DRAP or RemAPollo, or anything else really, it's just how the Amiga works :-)
In other words, without any DRAP, no remapping will even be attempted.

But just to rule things out: When you used the RUX tool for extracting modules from the ROM Update, did you remember to use the correct argument? This can either be A600, A1200, A3000, A4000I or A4000S, but in your case it should be one of the last two (A4000I for IDE controller, and A4000S for SCSI controller).

What kind of zorro cards do you have installed in your Amiga (if any)? RemAPollo.doc mentions that there might be issues with certain cards.

[PanterHZ]

I did exactly like it says on remapollo.doc.
rux  AmigaOS ROM Update A4000i
It gave me 9 OS_Module1-9, wich I put on the recommended drawer. DRAP just hangs.
Don't know why.
Anyway I found an easy way, maybe not the best. I just use SKIPROMUPDATE . It's important to skipromupdate scsi.device, that's what causes the problems. Then I use Quickrom. It works fine. KSRemap from GVP also works fine.

But if it's just scsi.device that causes problems, it should be really easy to fix. Just remove OS_Module6 (scsi.device) from the RemAPollo line, so it looks like this:

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

I had to do this myself, since I use IDEfix which requires original scsi.device.