Oh come on Hyperion...

[Olaf Barthel]

Originally Posted by redblade

I always thought that SetPatch would be freeware for all Amigas as it patches the OS.

Freely available, possibly, but not actually free. You still had to pay for the operating system it was intended for

But that's not really the point here, I suppose. These files have been around for a very long time, and as with so many things Amiga, it was easy to take their presence for granted.

Looking at the contents of the archives, there are some aspects worth pondering.

The "datatypes.library" archive contains no author information and no copyright text. It also bears version number 45 which in 1997/1998 was far from seeing use. This is not the same library which shipped with AmigaOS 3.5 or 3.9. Why is this archive part of this collection?

The remaining three "Version 43" archives (SetPatch, SCSI drivers, FFS) are clearly marked as being beta test software. All archives contain documentation and notes to the effect that it would be unwise to use this beta software for more than three months after their publication. As far as I know these archives were among the first official products of Amiga Technologies GmbH when Amiga software development had finally gotten off the ground again (it would not last, though, until Haage & Partner stepped in and made AmigaOS 3.5 possible). As such it was most useful at the time of publication.

However, the contents of all three "Version 43" archives (SetPatch, SCSI drivers, FFS) were eventually obsoleted by the newer versions included in AmigaOS 3.5 and 3.9, respectively.

I doubt that these old archives fill a present need. They do make sense in the context of archiving historic software, which has a valid place and use.

Personally, I would prefer it if the files, if they are offered, were given more context than just the name and a short description of their contents. You should be aware of the limitations of the software offered before you attempt to install them on your system and discover that something is not quite right.

There is another sticky point to offering these files for download: because the archive contents contain separate binary files which lend themselves to patching/hacking more easily than the binary blobs that shipped with later versions of SetPatch, etc., some people might be tempted to tinker with them rather than going with the more recent versions.

Nothing wrong with tinkering, but if this is done, you'll be stuck with old software which still suffers from bugs/restrictions which newer versions don't have. Tinkering with old software because it's easier that way is not a good place to start.

Requesting that these files not be offered for download any more does address this sticky point. But who's interested in knowing why these files are troublesome? It takes a lot of work to put this into context, learn about other opinions on the matter and (hopefully) come to a conclusion that makes sense (are we there yet?).

The simple stuff still works (a request that these files be removed), but the reactions tend to be simple, too: people feel threatened and react according to how they perceive the threat. I doubt that this whole affair could have played out any other way than it did this week, and this sadly has consequences for everybody. How can you realistically judge the effects of your actions if the smallest bit of stumbling has about the same results as the biggest conceivable mistake?

The best way to limit the risk, is not to take any risks any more. This doesn't bode well for the future of the 68k Amiga operating system.

[E-Penguin]

The 3.x branch of 68k AmigaOS is very fragmented, at least in appearance to those who are not expert in it. Rival versions of 3.1 Kickstarts, a 3.X which may or may not be an improvement on one (or both?) of the 3.1s, various patched versions of modules and programs from 3.5, 3.9 and private attempts.

I'm sure all was made with the best of intentions (I don't subscribe to Hyperion or H&P or anyone else being deliberately evil) but the net result is a mess. Even if some entity were to formally pick up development of 68K AmigaOS - where would they even start?

I rely on people who know better putting things that work together in a package for me to install. It does rely on the handful of people who make such packages not disappearing.

[Olaf Barthel]

Originally Posted by Akira

Is there anywhere we can follow your progress with this? I recently was experimenting with new workbench.library files, and just wonder how many changes you have implemented in the official builds, and on all other stuff you have worked on.

No, this is pretty much all in-house work for now.

The updates which shipped last year were very modest in scope, and decidedly so. With the exception of the hard disk partitioning software ("HDToolBox" and the "prodprep" command which a separate set of installer scripts use to initialize and partition hard disks), the changes are restricted to what Commodore could have done in 1994/1995 had the company continued to exist.

The ROM needed a copyright text change, which due to how compact the fundamental system initialization code is, had the wacky side-effect of making exec.library larger by just enough bytes not to permit it to fit into the Amiga 1200 ROM. To free up space, rebuilding workbench.library with a more modern 'C' compiler was the least risky change at the time. There were bugs in the IDE scsi.device drivers of the Amiga 600 and Amiga 1200 ROMs which were not fixed and found until about 1996. Because of ROM space constraints, the V44-V45 versions of these drivers would not have fit, so the older fixes went in instead. Finally, because the copyright text was longer than before, the operating system component which shows it (it's called "strap", because it "bootstraps" the system from media such as floppy disks, compact flash cards or even hard disk drives) had to be replaced, too.

The disk-based part of the operating system, with the exception of "HDToolBox" and "prodprep", mostly worked as it was without too much trouble (unless you tried to use storage media larger than 2 Gigabytes). The changes mostly affected the system installation script found on the "Install3.1:" volume, in the "install" drawer. The original version only permitted installation from a set of floppy disks, whereas the 2016 reworked version also allowed assignments to be used in place of volumes. Because these changes required more space, the "Installer" tool itself had to be rebuilt again. The "Installer" tool also needed a small fix in the code which estimates if the destination disk has sufficient room for the software to be installed (previously, volumes with more than 2 Gigabytes of space left were a big problem).

And those are the only changes in the 2016 version of the AmigaOS 3.1 ROM and disk set. Not that they were easily made

[Olaf Barthel]

Originally Posted by honx

does amigaos 3.1 included on aca500plus already benefit from this update?

The specific changes in the 2016 update are very modest in scope. If there is a possible benefit (short of making installation of the AmigaOS 3.1 system from CF card or CD-ROM much easier), it is in the use of the bug-fixed scsi.device versions.

However, I expect that the ACA500+ will need to support storage media in excess of 4 Gigabytes, and therefore either require a more modern set of drivers, or completely different drivers.

So, in a nutshell, there is likely too little benefit to be had in the first place...

[Olaf Barthel]

Originally Posted by wawa

if i may quote out of context an explanation delivered elsewhere and with somone else in mind, he may have occured "impossible to negotiate" apparently similar as gunnar.

Hang on, this is "normal" for now. Both Gunnar von Boehn and his associates, as well as Jens Schoenfeld's company are now involved in enterprises which go beyond their original "comfort zone", so to speak.

As far as I can tell Gunnar von Boehn and his associates have very quickly turned what might have started as a side-project into a commercially viable business, and it is still growing, maturing. When this kind of thing happens, you'll invariably have to deal with questions such as how your tax bill is going to look like, if/how/where you might want to set this up as a regular business, how you will manage your supply, your production and your distribution. As an electronics manufacturer you'll also have to learn how local and EU regulations apply to your business. Taxes and regulations you cannot shrug off. That's a very steep path, and it's no comfort at all how quickly you need to learn how to travel it.

Jens Schoenfeld's company "Individual computers" has been around for a long time, it's probably the last of the 1990'ies Amiga companies which is still around and making Amiga hardware. The scope of and the requirements to make the ACA500+ are substantially larger and more complex than the hardware that was produced before. This both means more effort in design and production and likely also a higher requirement to finance the production itself.

In short, both companies took a leap of faith, and are now finding themselves face to face with unfamiliar challenges.

Have some sympathy if these guys are grumpy or reserved.

[Locutus]

Originally Posted by Olaf Barthel

Requesting that these files not be offered for download any more does address this sticky point. But who's interested in knowing why these files are troublesome? It takes a lot of work to put this into context, learn about other opinions on the matter and (hopefully) come to a conclusion that makes sense (are we there yet?).

As always your comments are a great read and valuable, and here is the interesting thing.

The post you just wrote lays out perfectly why the binaries are legacy and not fit for continued use, and that is exactly the right 'putting in context' straight to the point, having that prefaced over a download section would have sorted this out completely.

I truly believe in historical software archiving, and calling for files to be pulled on old legacy software with no real commercial value any more is in the end just a bad gesture, a request to add a disclaimer would not have hurt anyone.

The practical effect isn't big, but its puzzling why such actions are taken sometimes.

[idrougge]

Originally Posted by Olaf Barthel

I doubt that these old archives fill a present need. They do make sense in the context of archiving historic software, which has a valid place and use.

Personally, I would prefer it if the files, if they are offered, were given more context than just the name and a short description of their contents. You should be aware of the limitations of the software offered before you attempt to install them on your system and discover that something is not quite right.

I value your opinion on AmigaOS system integrity, but it's not really for you to decide, although you can advice about it on forums or even send in a readme file to the site in question.

Originally Posted by Olaf Barthel

There is another sticky point to offering these files for download: because the archive contents contain separate binary files which lend themselves to patching/hacking more easily than the binary blobs that shipped with later versions of SetPatch, etc., some people might be tempted to tinker with them rather than going with the more recent versions.

And in what way does this cause sleepless nights at Hyperion headquarters? Did Ben Hermans or the Frieden brothers wake up one night, after having realised in a dream that some people could have been applying patches to Workbench 3.1 the wrong way?

Originally Posted by Olaf Barthel

Nothing wrong with tinkering, but if this is done, you'll be stuck with old software which still suffers from bugs/restrictions which newer versions don't have. Tinkering with old software because it's easier that way is not a good place to start.

Requesting that these files not be offered for download any more does address this sticky point. But who's interested in knowing why these files are troublesome? It takes a lot of work to put this into context, learn about other opinions on the matter and (hopefully) come to a conclusion that makes sense (are we there yet?).

None of that is the business of Hyperion.

Originally Posted by Olaf Barthel

The best way to limit the risk, is not to take any risks any more. This doesn't bode well for the future of the 68k Amiga operating system.

Hyperion's involvement in in the 68k Amiga operating system this far has been limited to removing actually useful pieces of the operating system. Their behaviour, if anything, does not bode well for the future of AmigaOS 3.x.

[IridiumFX]

@Olaf Barthel

thanks for the exciting insights on the boot process. I know I am going wildly off-topic here, but since you know more than anyone else, could you shed some light on the full boot process? I remember that the 68K CPU family starts executing from address 4, which on the Amiga happens to be the pointer to ExecBase. I never understood the magic behind (remapping? but that's a ROM address). Since you described the "strap" module, I was wondering if you had time to describe the full boot process, or at least as much as you know it. Not that this has practical uses, but you know, knowledge not shared now, risks do go dark easily

Originally Posted by Olaf Barthel

No, this is pretty much all in-house work for now.

The updates which shipped last year were very modest in scope, and decidedly so. With the exception of the hard disk partitioning software ("HDToolBox" and the "prodprep" command which a separate set of installer scripts use to initialize and partition hard disks), the changes are restricted to what Commodore could have done in 1994/1995 had the company continued to exist.

The ROM needed a copyright text change, which due to how compact the fundamental system initialization code is, had the wacky side-effect of making exec.library larger by just enough bytes not to permit it to fit into the Amiga 1200 ROM. To free up space, rebuilding workbench.library with a more modern 'C' compiler was the least risky change at the time. There were bugs in the IDE scsi.device drivers of the Amiga 600 and Amiga 1200 ROMs which were not fixed and found until about 1996. Because of ROM space constraints, the V44-V45 versions of these drivers would not have fit, so the older fixes went in instead. Finally, because the copyright text was longer than before, the operating system component which shows it (it's called "strap", because it "bootstraps" the system from media such as floppy disks, compact flash cards or even hard disk drives) had to be replaced, too.

The disk-based part of the operating system, with the exception of "HDToolBox" and "prodprep", mostly worked as it was without too much trouble (unless you tried to use storage media larger than 2 Gigabytes). The changes mostly affected the system installation script found on the "Install3.1:" volume, in the "install" drawer. The original version only permitted installation from a set of floppy disks, whereas the 2016 reworked version also allowed assignments to be used in place of volumes. Because these changes required more space, the "Installer" tool itself had to be rebuilt again. The "Installer" tool also needed a small fix in the code which estimates if the destination disk has sufficient room for the software to be installed (previously, volumes with more than 2 Gigabytes of space left were a big problem).

And those are the only changes in the 2016 version of the AmigaOS 3.1 ROM and disk set. Not that they were easily made

[wawa]

i must admit i have myself some doubts, if the reason to remove the archives in question, was worry about amiga fans and stability of their systems.

[Cylon]

DJBase didn't overreact. He was on vacation and couldn't properly access the server. So the fastest and easiest way was to shut the whole website, because there was a response time involved, he said.

[matthey]

Originally Posted by Olaf Barthel

Requesting that these files not be offered for download any more does address this sticky point. But who's interested in knowing why these files are troublesome? It takes a lot of work to put this into context, learn about other opinions on the matter and (hopefully) come to a conclusion that makes sense (are we there yet?).

Requesting removal of patched 68k AmigaOS modules is going to meet resistance until better and proper alternatives are available. This includes bug fixed modules, 68000 compiled modules (for MiniMig and some simple FPGA based hardware) and properly optimized modules (I have some ideas if you need help here). A new 68k AmigaOS is probably not going to sell well until surpassing AmigaOS 3.9 in many ways. The AmigaOS version numbering system of modules is really only adequate for one developer source and the lack of one source has created the current mess. Fixing the mess is not as simple as removing unofficial modules but requires surpassing them and becoming the single source of quality AmigaOS modules again.

[Olaf Barthel]

Originally Posted by idrougge

I value your opinion on AmigaOS system integrity, but it's not really for you to decide, although you can advice about it on forums or even send in a readme file to the site in question.

My point of view is certainly my own, although I do not insist on keeping it entirely to myself

AmigaOS development for 68k has been left dead in the water for almost two decades now, and the consequences of picking your own choice of components to use on your Amiga have been largely limited to that machine.

In 1993/1994 you could expect to install AmigaOS 3.1 from the six disk set and have a working system, ready to do the job at the conclusion of the installation process. This would not last, and the beta patches which were offered by Amiga Technologies GmbH addressed some of the problems which had already surfaced while Commodore was still in business (affordable hard disk drives with capacities in excess of 4 Gigabytes were on the horizon even in 1994).

These beta patches would be superseded by AmigaOS 3.5, and that by AmigaOS 3.9. Today you don't have an easy path ahead of you when collecting the components which you want to use in a stable, new system.

This is where things take a strange turn, because it is likely easier to find the beta patches (they are freely available for download) than the AmigaOS 3.5 or 3.9 CDs (the latter can still be ordered from Vesalia, or so I am told). As the beta patches come with not enough context to nudge the user into making up his mind whether the AmigaOS 3.5 or 3.9 versions might be a more appropriate choice, or even if there is another choice (patched versions of the scsi.device variants which support CF interfaces), he might just settle with the beta version.

No harm done? That depends.

Last year I worked on the modest AmigaOS 3.1 update, which omitted changes to the hard disk partitioning software. I ran out of time, and it turned out that by not addressing the shortcomings of partitioning software, the usefulness of the update was greatly reduced. HDToolBox fails in unexpected ways when encountering media larger than 4 Gigabytes, and the separate low level partitioning software commands which the scripts in the HDSetup drawer of the Install3.1 volume would use even crash.

HDToolBox is unaware of SCSI device types which so it happens are used by CF interfaces, and likewise the scsi.device variants are unaware of these devices either. Updated versions of each are in the works. Making HDToolBox "behave" requires that it knows what to expect of the scsi.device, and that is very difficult to achieve. You cannot safely ask a device driver to reveal its capabilities to software such as HDToolBox. While the attempt was made with the NSD API enhancements, Amiga device drivers more often than not show unpredictable behaviour when called upon to perform commands which the authors did not expect at the time of implementation.

This is where the mismatch between old scsi.device drivers and the partitioning software causes slip-ups. How can you tell if the scsi.device driver (or the functional equivalent, e.g. gvpscsi.device or omniscsi.device) can handle media larger than 4 Gigabytes, or for that mattern, how can you tell if the FastFileSystem will deal with partitions larger than 2 Gigabytes, or those placed beyond the 4 Gigabyte mark?

I am viewing this from the implementor's point of view, and these legacy drivers are making the job really, really hard. This is where HDToolBox, etc. all too easily get into trouble. You might have written off HDToolBox as unfit for purpose a long time ago, and with good reason. It cannot be entirely redeemed (too many design decisions which transformed into liabilities by 1994), but it can be made robust and useful. How far that can go is checked by what the drivers and the file system permit.

And in what way does this cause sleepless nights at Hyperion headquarters? Did Ben Hermans or the Frieden brothers wake up one night, after having realised in a dream that some people could have been applying patches to Workbench 3.1 the wrong way?

You make this sound funnier than it probably is Not that I would know what causes sleepless nights in certain places, and if there actually is a Hyperion headquarter to begin with.

Seriously, the purpose of commercial Amiga software development is not to deliver entertainment the like which has not been seen since Mack Sennett stopped making silent comedy shorts.

Some of the guys who still see value and purpose in the continued maintenance and development of the platform are still trying hard to get stuff done, only to see their efforts likened to pratfalls and fart jokes. I invite criticism, as it is badly needed in this business to hold the players to account. What I have witnessed up to now I feel is not going far enough, and suffers from making light of the missteps. This is serious, and it should IMHO be treated seriously.

None of that is the business of Hyperion.

Actually, I believe it might just be: assuming responsibility. If not, who right now has the best shot of delivering a sound, consistent 68k AmigaOS package which provides for full backwards binary compatibility through some 30 years of Amiga software development?

Somebody would need to ponder how to make that happen, create it, ship it, sell it, and receive payment for it. Not much happens in a vacuum.

Hyperion's involvement in in the 68k Amiga operating system this far has been limited to removing actually useful pieces of the operating system. Their behaviour, if anything, does not bode well for the future of AmigaOS 3.x.

But then, what actually is sufficient to bode well in this area? The small steps are laughed off, even if they are steps that go into a certain direction directly opposed to the abyss. Irony is employed, sometimes even in conjunction with litotes and the double negative, I kid you not.

[Overflow]

@Olaf

I always enjoy reading your posts, but Im having a hard time finding something concrete to focus on in you last post. Im just a socalled enduser, and I do see increased activity (in Amiga terms) on the AOS3.x platform, partly/mostly cause of the Vampire project.
There is some clear misgivings amongst some developers with regards to lack of support for debugging/mmu issues.

I guess my question is; where do you see things progressing? Some are up in arms over ApolloOS, but given the dormant state of AOS3, it was ineviable.

If official developers give us a good reason to purchase updates, by showing a concrete plan, I expect many ApolloOs users will be happy to spend the money.

Atm it feels dead in the water. Correct me if Im wrong It certainly wont be the first time!

[Lord Aga]

Originally Posted by Olaf Barthel

If not, who right now has the best shot of delivering a sound, consistent 68k AmigaOS package which provides for full backwards binary compatibility through some 30 years of Amiga software development?

Actually, the chances are that I will do it before Hyperion.
And my coding skills max out at making crap in Amos.

[Olaf Barthel]

Originally Posted by IridiumFX

@Olaf Barthel

thanks for the exciting insights on the boot process.

The word "exciting" is not really the first word that pops into my mind when I think of the Amiga boot process

I know I am going wildly off-topic here, but since you know more than anyone else,

Yikes, I hope that might not be the honest truth

could you shed some light on the full boot process? I remember that the 68K CPU family starts executing from address 4, which on the Amiga happens to be the pointer to ExecBase. I never understood the magic behind (remapping? but that's a ROM address). Since you described the "strap" module, I was wondering if you had time to describe the full boot process, or at least as much as you know it. Not that this has practical uses, but you know, knowledge not shared now, risks do go dark easily

I never cared that much for the down and dirty low level hardware setup business. That is an art to be appreciated all by itself. What I know about the entire boot process I learned from the Amiga ROM Kernel Reference manuals and later from the "A3000T service manual". The late Klaus Burkert (Picasso II, etc.) also recommended the 1987 "Commodore Amiga A500/A2000 technical reference manual" because it complements the 1990/1991 A3000 documentation (it covers Zorro II thoroughly, whereas the later documentation focuses on Zorro III only).

This is from memory and simplified, so it's probably so inaccurate that you should go to the primary sources (e.g. the manuals mentioned above, and maybe the official documentation for the MC68000) if you need dependable information:

- When the system is reset (warm reboot) or powered up (cold reboot), the 68000 picks up the initial program counter from whatever is stored in address 4. At the same time the reset signal is asserted, Amiga hardware kicks in which maps the ROM contents to the beginning of the address space, replacing the RAM that's there. If you look at the beginning of the ROM, you'll find that four bytes into the ROM there's an interesting address: it's the address of the exec cold start code. Coupled with the reset instruction this has the effect of making the CPU execute it. I don't know how the ROM mapping reverts to making the RAM appear again, but I suppose this might be something vaguely magical, i.e. the ROM mapping might only be valid for the brief time in which the reset signal is asserted and the CPU fetches the exec cold start code before the reset signal flips back. I'm not enough of a hardware guy to know about these things

- The exec cold start code puts the CPU into a well-defined state, setting up the caches, the interrupt handling, etc. On-board hardware such as memory, I/O devices (CIA chips, Gary, Gayle) are probed and set up. This involves figuring out which on-board memory is installed, how much, and if there's anything interesting there such as the exec library base left over from a warm reboot. The initial exec library base is knit together (or reused from the warm reboot) with the memory known up until now getting added, so that AllocMem() will work. Both the ROM and certain other interesting address spaces are scanned for components (they are referred to in the documentation as "resident modules" or just "modules") which need to be initialized at this early stage. This includes in particular expansion.library, which is going to be the first component to be initialized.

- expansion.library is initialized, and it begins collecting expansion hardware (Zorro II and Zorro III) and sets it up. RAM is added for memory expansions found. And that concludes the first time expansion.library gets the call.

- exec.library is set up properly now, and if possible, ExecBase is moved into fast memory that was picked up by expansion.library. By this point exec.library is fully usable.

- expansion.library is called again, and this time it has to figure out which expansion hardware contains ROM with executable code, such as hard disk device drivers which support autoboot. This is where these ROM contents may get downloaded into RAM and the code is executed. That doesn't happen for a special type of autobooting called "boot point booting", though, which is delayed until the "strap" module comes around.

- The exec cold start code keeps rattling down the list of components which need to be initialized at this stage, now that the early work is done. Nothing fancy here, the components are initialized by priority, which means that depencies are satisfied. For example, intuition.library needs graphics.library, gameport.device and keyboard.device to be operational, so graphics.library, gameport.device and keyboard.device are initialized first and then much later intuition.library. The operating system does not know about these dependencies, it's the developers who have to make sure that these modules are initialized in a very specific order.

- Eventually, the exec cold start code reaches the end of the list of components which it needs to initialize. The last component there is happens to be the "strap" module.

- The "strap" module's purpose is to eventually transfer control to whatever wants to boot the system. That could be code in a floppy disk boot block, for example. "strap" will cycle through checking the attached floppy disks, the PCMCIA interface and expansion devices for bootable devices. Insert a bootable floppy disk and the boot block will be checked, loaded into memory and getting executed. Same thing happens for PCMCIA hardware which looks bootable and for autoboot controllers which might now be ready to get going. Whatever code is executed now has a choice to either take over the system or, what is recommended, start the "normal" boot process properly. This normal boot process is triggered by initializing/opening "dos.library".

- When "dos.library" is initialized, one of the first things that happen is that the list of partitions registered early on in expansion.library are added to the system default mount list. From that point on, the partition with the highest boot priority wins and the system boots from that.

[Gorf]

@Olaf and all others:

No need for sleepless nights, no need for providing grown up fans with "the best solution"

If not, who right now has the best shot of delivering a sound, consistent 68k AmigaOS package which provides for full backwards binary compatibility through some 30 years of Amiga software development?

The community has! Just do the right thing once:

OPEN THE SOURCE!

Yes there will be a lot of different distributions - well there are already (Forever, Amikit, AfA, ApolloOS....) and the best will stay.
AROS68K and AOS could finally blend into something wonderful...

Just let it free! It's time.

[wawa]

Originally Posted by Olaf Barthel

If not, who right now has the best shot of delivering a sound, consistent 68k AmigaOS package which provides for full backwards binary compatibility through some 30 years of Amiga software development?

none, to my knowledge. certainly not hyperion. not only amiga (68k) was not supported by them. they have actively disencouraged contributions in this area.

while last few years the only in its complexity wholely maintained backward compatible system for amiga (68k) along with a number of contibutions (apps, games, tools) is aros (68k).

[Lord Aga]

Originally Posted by wawa

none, to my knowledge.

I'm offended! Didn't you see post #54 !?!

[meynaf]

Originally Posted by Olaf Barthel

I don't know how the ROM mapping reverts to making the RAM appear again, but I suppose this might be something vaguely magical, i.e. the ROM mapping might only be valid for the brief time in which the reset signal is asserted and the CPU fetches the exec cold start code before the reset signal flips back. I'm not enough of a hardware guy to know about these things

Nothing magic here, this is done by a bit in CIA-A. Note that this bit won't allow mapping the ROM again, a reset is needed for this.

[Toni Wilen]

Originally Posted by meynaf

Nothing magic here, this is done by a bit in CIA-A. Note that this bit won't allow mapping the ROM again, a reset is needed for this.

It is not correct. You are mixing two different hardware.

a) CIA IO pin used for ROM overlay. Activates at reset (because reset sets IO ports to inactive state). It can be switched on and off manually.

b) Gayle based system, Gayle handles ROM overlay internally. Activated at reset and automatically switches off when CPU does first CIA-A access. Can't be re-enabled without reset. CIA-A overlay pin is not connected except on CD32 where it is CD audio mute on/off.