JezC wrote:Would an option be to provide a program that can be run to disable the TOS in TT RAM for those who feel the need for it?
I did write a module for it, but I disabled it. Every extra feature in the PLD adds more work and hassle, and as we have seen many times, even small changes upset the SDRAM timings. That is the main reason it went. Also, people would still have to boot to the desktop and run a program to turn it off, by which point TOS has already booted and they are sitting at the desktop in fast mode anyway. No doubt people would then complain that turning it off at that point is too late, so it seems a whole lot of hassle for basically no valid reason.
If you use EmuTOS, fast ROM is never switched on in the first place, as EmuTOS does not have the copy built in.
Features can always be added later if enough people actually want them. But I am not going to develop and spend time on stuff which I would assume hardly anyone will use, on a product where I would assume hardly any will sell in the first place. If people want me to spend more time on stuff, then things have to be more worth me spending the time on. Unfortunately my spare time does not come with an infinite lives poke.
stephen_usher wrote:If it's RAM that the CPU can't access and you're not using 68030 relocation tables then I would agree.
No MMU tables are involved at all. The PLD simply redirects the ROM reads in hardware to a reserved area at the top of the SDRAM, above the TT-RAM that TOS hands out, so nothing gets allocated there. Software changing the MMU tables cannot break it, because it does not use them. That is one of the reasons I did it this way instead of relying on MAPROM.
Badwolf wrote:Well I still tend to think "most people" exposed to an accelerator that turns on everything with no input from the user will end up just going 'this, that, the other doesn't work with ST536...'
Incompatible with what exactly though? All fast ROM does is make GEM and TOS run a bit faster, and I cannot think of a single reason why that would cause anyone a problem. If it was running at 1GHz then maybe, but a few hundred percent faster is very unlikely to upset anything.
I would argue that running a 030 is the most incompatible layer in the first place. The caches, self-modifying code, different exception stack frames and timing loops written for a 68000 will all break far more software than TOS running a bit faster ever will. That comes with any 030 accelerator, fast ROM or not. If people want it totally compatible, then they should not be running a 030 at all. You cannot have it all ways.
Fast ROM has been standard in my stuff for about two decades now, and in all that time nobody has ever complained about TOS running faster. The same goes for the PAK030, which ran TOS from 32-bit ROMs on the board, easily twice as fast as stock, and I never heard a single complaint about that either.
I honestly do not see how the general user looking for a plug and play accelerator would want the acceleration turned off by default, and then have to depend on software to enable it. By the time that software runs, they have already had to sit through the extra wait to get to the desktop in slow mode. Personally I think that is just messy, when we can accelerate the whole boot process simply by having it on by default. It would be like fitting a turbo to a Sinclair C5 that only kicks in once you have parked.
In fact, Frank Lucas was "informing" us that the PAK booted faster, because the PAK had fast ROM turned on by default. We went from about 4 minutes to about 30 seconds to match the PAK. So there has already been one person "complaining" about it NOT having fast ROM on at boot.
Like I keep saying, you cannot have it all ways by default. People also need to realise that whether I do option A or option B, 50% of people will likely complain either way. So I do things which benefit my own workflow and simply make sense, and my workflow runs a lot better with things running fast by default, fast ROM included.
People looking for a plug and play experience just want to plug it in and have everything work out of the box. I always aim to make things as easy and simple as possible, and in my opinion at least, that is the way that makes sense, as it is how I use everything myself. Having to run stuff from AUTO just makes things more complicated and more hassle. Think about games or anything else which autoboots from floppy. With everything off by default, you would get no acceleration at all from the booster, because the "switch it on" programs never got loaded. It all just becomes a huge nightmare.
Sorry if this upsets some people, but this was all decided over a year ago and nobody said a word at the time. It is a bit late now to start complaining, after I have put tons of work into making it what I think is the best and simplest way for everybody to use it, without needing annoying software to load.
I may consider adding a proper off option at some point, but first I would like to see some mainstream proof of software people actually use, where TOS running faster causes a provable problem by itself. I do not recall anyone ever complaining about the PAK030 or any other booster doing the same thing over the past 30 years either. Maybe those scenarios do exist, but obviously not mainstream enough for anyone to have ever mentioned it, in my recollection anyway.
Badwolf wrote:Mind you, if not having it enabled is just a case of popping out the ROM then I suppose it could be a non-issue. That said when I last ran into debugging problems with the 536 there wasn't an easy way to avoid using the fast-access ROM either.
Yes, like I said, EmuTOS will not enable fast ROM, so a ROM without the copy patch simply never turns it on. It can also be turned off in the firmware if a developer wants that, so that is not a problem either. What I am thinking about is the end user's install, their expectations and their experience. Knowing the hassle with multiple versions of MAPROM, which is still largely unproven in a lot of scenarios, simply not having it running at all saves me a huge support nightmare on its own.
