Remapollo for A4060

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

[Oldsmobile_Mike]

Wait, what exactly is your question?

I think he's asking about the large 3.9 ROM update file?

[Oldsmobile_Mike]

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.

This is probably a pie-in-the-sky request, but can you give us a list of the names of *all* the modules LoadModule looks for/replaces, and in what locations?   Thanks!  

[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

[Oldsmobile_Mike]

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.

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?

[utri007]

RemApollo fixes probolems with some Zorro cards with rebfix switch. RemApollo 1.8 is updated 2012. Aminet has a 1.7 wich is much older.

I have a 1mb physical kickstrat and I use Thoma's MMuLib and MuFastRom to load it fast ram. Works nicely. Thanks Thomas.

[guest11527]

This is probably a pie-in-the-sky request, but can you give us a list of the names of *all* the modules LoadModule looks for/replaces, and in what locations?   Thanks!  

Only you can know. It depends on the machine, in particular what is in the kickstart. To find out, use a tool like "Xoper", and tell it to show the ROM modules list. If I recall correctly, thi is the "E" command.

All modules are replaced exactly by the same file names you find on the list, in directories that are canonical to the name, libraries in LIBS:, devices in DEVS:, handlers in L:, resources in LIBS:resources and everything else in LIBS:modules. There is a ReadMe in the distribution that tells you what goes where in more detail. The only exceptions are:

"expansion.library" - cannot be replaced
"shell"  maps to "L:Shell-Seg" for historical reasons and
"filesystem" maps to "L:FastFileSystem" for the same reason.

[Gulliver]

@Thomas Richter

I know it is a little bit off-topic, but please indulge me:

Extractmodule & loadmodule are both excellent tools, but there is one big problem for the casual Amiga user out there: extractmodule stores its modules all over the place in sys: and it is quite a mess to distinguish all modules from traditional disk components, and many of them get easily forgotten when one tries to find them.

I understand the reasoning behind you setting them to be in all those places. But again, it is messy for an average user and it makes it difficult for most out there.

Wouldnt it be a better solution to have extractmodule store them inside a specific drawer for that purpose, like for example sys:devs/kickstart or something like that, and if you want you can put all kinds of subdirectories you think you will need inside there?

I am afraid that if you dont do something to solve this, you will end up flooded with emails and forum posts asking for help just for this matter.

I just hope you reconsider this for the benefit of us all.

[dannyp1]

That is how I do it. I store and load all of my modules from one drawer. I don't have to search multiple drawers and check version numbers to know what I am loading. I know with one quick glance.

[guest11527]

@Thomas Richter

I know it is a little bit off-topic, but please indulge me:

Extractmodule & loadmodule are both excellent tools, but there is one big problem for the casual Amiga user out there: extractmodule stores its modules all over the place in sys: and it is quite a mess to distinguish all modules from traditional disk components, and many of them get easily forgotten when one tries to find them.

But that is exactly the beauty of AmigaOs: There is *no difference* between a ROM component and a library in LIBS: - well, as long as it is compiled correctly. Take, for example, "icon.library". Where should it go? It used to be a ROM component, but from 3.9 on, and also in 3.1.4, it is not. The point is: Which modules are in ROM and which are not is just a convention. It does not make any difference.

I understand the reasoning behind you setting them to be in all those places. But again, it is messy for an average user and it makes it difficult for most out there.

What is the "difficult" part there? You do not need to know which part will go to ROM, which will be loaded by LoadModule and which will not. In case a future ROM will not include some components (and yes, exactly this will happen), the components are in exactly the right place where the system will find them if they are *not* in ROM, and if LoadModule will not pick them up. If you put them into another place, you get an error as soon as a program tries to find them.

There is a *reason* for this design, both of the ROM/ramlib design, and LoadModule. They work hand in hand.

[Gulliver]

@Thomas Richter

You are ignoring the fact that brewing a custom rom for the Amiga user has become a very common sport, and I cannot blame them.

That is why the scattered modules approach sucks.

Every Amiga user out there has different acquired tastes for different choices of components, some enjoy replacing console handlers, others require patched modules for the system to work on their new hardware (remember that traditional Amiga manufacturing ended between 1994/1996). So new hardware most of the time requires doing funky things to the kickstart to adapt it. I know it is not a desirable situation, but it is certainly better than not having new hardware at all.

There is no universally accepted use regarding modules. I understand that from the the developers point of view this creates a support mayhem, but from the user point of view, this is certainly salvation.

Just ask around here, and you will soon notice that nearly everyone, for a reason or another, does something "non standard" to their rom/kickstart modules.

[guest11527]

You are ignoring the fact that brewing a custom rom for the Amiga user has become a very common sport, and I cannot blame them.

That is why the scattered modules approach sucks.

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.

[Marmes]

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

[Oldsmobile_Mike]

or if there is a good alternative for rekicking ROM.

Yes, many. Have you tried some of the other programs listed in this thread, or Aminet, SKick, etc.?

[utri007]

Yes, many. Have you tried some of the other programs listed in this thread, or Aminet, SKick, etc.?

You forgot this  - >

I have a 1mb physical kickstrat and I use Thomas' MMuLib and MuFastRom to load it fast ram. Works nicely. Thanks Thomas.

<- those are still supported

There is a problem when stuff is left out from kickstart. It would require special boot floppy wich is not desired situation! It would be very very annoying if there is a boot problem, like hard drive failure etc.

[Marmes]

Quickrom maybe