exxos's Atari, Amiga & retro forum

stephen_usher wrote: 20 May 2025 11:38 Indeed. A lot of games broke when TOS 1.4 arrived (and when 1.2 arrived as well). I'm not sure if TOS 2.0x would use more than 1.4/1.6x but it may rearrange things a bit. Seeing as 2.0x was only meant for the MegaSTe that was pretty niche so games wouldn't be optimised (fixed) for it.

Thing is, most of the games I'm having problems with work with plain 2.06, but not with ExxTOS or EmuTOS.

Present theory being they (the latter two) initialise the MMU whereas perhaps vanilla 2.06 doesn't.

BW

@Badwolf have you tried the disable MMU jumper on the STE536 ?

exxos wrote: 20 May 2025 12:55 @Badwolf have you tried the disable MMU jumper on the STE536 ?

Not yet (am at work) and I don't have the jumper fitted yet, but it's at the top of the list now!

BW

It's very likely a cache issue. Lots (most?) of games use self modifying code and that will fail dismally on a system with a CPU cache.

Games would not know about the MMU. The only issue might be that if the MMU tables are set so that writing to certain addresses generates a bus error which would not occur on a standard system then the games could crash because of this.

stephen_usher wrote: 20 May 2025 13:22 It's very likely a cache issue. Lots (most?) of games use self modifying code and that will fail dismally on a system with a CPU cache.

Thats what I thought at first as well. my 206 and EMUTOS would clear the caches correctly. Vanilla 206 doesn't. So might be a factor. But he said he tried the CDIS header jumper to disable the cache and no change.

viewtopic.php?p=128595#p128595

FASTROM locked up at this point :roll:


I'm having a new idea on how to go about doing all this... :hide:

exxos wrote: 20 May 2025 13:29

stephen_usher wrote: 20 May 2025 13:22 It's very likely a cache issue. Lots (most?) of games use self modifying code and that will fail dismally on a system with a CPU cache.

Thats what I thought at first as well. my 206 and EMUTOS would clear the caches correctly. Vanilla 206 doesn't. So might be a factor. But he said he tried the CDIS header jumper to disable the cache and no change.

viewtopic.php?p=128595#p128595

So good news: jumpering both greatly increased my compatibility tests.

F1GP being the obvious one that needed MMUDIS jumpered in addition to CDIS, but I haven't tested all with both combinations.

I have a nasty feeling my jumper wasn't making good connection when I did the first tests as the screen corruption I was seeing (and incorrectly attributing to AltRAM somehow interfering based on the EmuTOS/2.06 difference) seems to be cache-based. Which makes sense. I think I must have had a dirty jumper for the couple of screen corruption games and then F1GP failed with MMU and I gave it up as bad test.

So panic over. Thanks for the tips and we do have the option to switch some of this stuff physically on the board. Any scope for a register with your new big CPLD, though?

Cheers,

BW

Badwolf wrote: 20 May 2025 22:52 ....Any scope for a register with your new big CPLD, though?

Possible yes...

So turn off cache, MMU, TTram... and at which point one has to question why have the accelerator at that point :) Might as well fit the V1 STE booster at that point I guess :P

So fast ROM only made it to pass 7 last night :(

I think part of the problem is to RAM address is muxed already and seems 10ns delay there. I've latched the address bus and added a extra clocked delay to the ram access.. it helps a lot but still not stable.

I don't really understand how it could ever work really. The address on the SDRAM likely takes 10ns to settle after /AS goes low.. So no way the SDRAM is going to latch a proper address. Hence the need for adding a delay .

I did try adding a second delay but didn't help. So there must be another problem somewhere..

Problem is as well, The CPU clock switching is done on the raw ram decode for some reason. Technically it could glitch. But also me adding in a ROM decode clause could have upset that also. It if use /AS as a clause in the ram decode line it crashes or doesn't even try to boot. So I think something is still iffy with address decoding somehow.

I tried to find way to speed up the address bus to ram, but it seems it has some initial values sent for setup and then muxed to the address bus,which seems to be where the 10ns delay comes from.

I'll have to experiment with some more delays later. I think it's just inevitable at this point the SDRAM speed is just going to have to take a small speed hit to make sure it's stable on everyone's machines. I think the fast ROM logic is just highlighting existing faults in the SDRAM timings.

Do you really need to speed up the rom access? I use maprom usually. BTW, am sure on the Amiga that the PLD used to copy the rom to fast ram, so may be worth pinching that code?