Badwolf wrote: 09 Nov 2026 11:46
Yeah sure. If it's softloaded by the user into GEMDOS memory pool.
If it's built into the hardware with transparent remapping of the memory and no off switch, then I don't agree.
I understand your point, but that is really your own use case as a developer, not how the vast majority will use it. You said yourself you have very little time for anything these days, so I doubt you would be developing for the ST536 at that level, and I seriously doubt anyone else would either. So it is a bit of a moot point really.
As for it being built into the hardware, it is not the hardware doing it by itself. TOS copies itself into TT-RAM at boot and then tells the PLD to switch over, so it is effectively soft loaded by TOS, just at boot rather than from the desktop. I actually wrote a module which turns off TT-RAM and fast ROM from software, but I disabled it because I really did not see the point.
EmuTOS does not have the copy built in, so it never triggers fast ROM at all. As you tend to use EmuTOS, it already acts the way you want anyway. EmuTOS would need a program to switch fast ROM on, which I have not written yet.
Even from a development point of view, I don't see any use case where TOS running fast has any downside at all. During development there are endless reboots, and having TOS running fast is a huge time saver. Having it running slow while developing would absolutely drive me nuts!
Most people just want to plug it in and have it work, with no software to install or configure. That is exactly why I built fast ROM into TOS and got rid of the need for MAPROM altogether, as it kept things a lot simpler for everyone.
MAPROM does a bunch of strange things by itself, and even Anders himself doesn't really know how it works any more. It is not supported, nobody knows how it works, and nobody is going to maintain it, that much is clear. Running MAPROM adds a lot more layers of complication and issues than simply running TOS fast, and people using it may well run into compatibility issues because of the tricks it does to speed up the system. So I bypassed the whole issue by not requiring it at all, and not using it has far more advantages than using it.
As for the warm reset, I would argue a cold boot every time is an enormous advantage. I have seen plenty of times where switching between TOS and EmuTOS does not play nicely unless a cold boot happens. The user flips the ROM jumper with the machine powered on, presses reset, and one or the other screws up because memory has not been reset properly, which then leaves them confused and frustrated because it has all gone nuts.
That is exactly why I made Flashy Clock do a cold boot, as switching operating systems can corrupt the other one otherwise. With the ST536 it also means that after a reset the ROM copy is taken fresh from the ROM chips, so a ROM bank change takes effect straight away instead of the old TOS carrying on from TT-RAM. Of course nobody should change jumpers with the power on, but I find myself doing it repeatedly and no doubt other people will do exactly the same. A cold boot on every reset rules out a flood of weird issues and complaints before they happen, simply because people do not power down for 30 seconds after changing the ROM bank. It only takes a few seconds longer anyway.
The whole point of an accelerator is to go fast, and deliberately having something run slow defeats the object of having an accelerator in the first place. I am not going to make 99% of users put up with GEM moving like it is loading from a C15 tape, or force them to run a bunch of programs just to enable features. That just gets way too confusing for people, and every extra program adds another layer of confusion and its own issues on top.