ST536 STE EDITION

[exxos]

For the 288? Grand. Will give it a crack if I get the "proper" test firmware booting first.

Yes..

CURRENT6 is the current latest build I was testing on Friday. It has the logic for the ROM shadow, but its not "enabled" in the logic yet....

[Badwolf]

@Badwolf Are you 100% sure it is a TTram issue? Original TOS206 is still basically a 68000 system which doesn't understand caches. Might be worth turning cache off in the desktop menu and just ruling that out next...

No I'm not sure at all as I've no way of turning TT-RAM off for a like-for-like comparison. I can't just disable caches on the desktop as these never see the desktop.

Well, unless I build a non-TTRAM detecting version of EmuTOS 1.3 and burn that to to a ROM chip so I can flip the jumper, I suppose.

It looks like you were right & I was jumping to conclusions.

I didn't have time for CPLD surgery today, but I did manage to build and burn a version of EmuTOS1.3 without TT-RAM support.

My primary test game (F1GP) still wouldn't boot. My screen corruption game (FOTI) remained corrupted.

So it's not TT-RAM being declared.

So the bony finger of suspicion points to caches.

I do have a CDIS header on my board so I tried jumpering that.

No difference in behaviour.

IIRC CDIS doesn't allow the cache to be filled or something, which ought to do the job, but doesn't seem to. Perhaps there's another subtly there. Instruction versus Data, perhaps?

Anyway, next up was MAPROM. IIRC MAPROM blocks at least some caches for the whole STRAM range so might do the job for me if I do a soft boot into the games.

No difference in behaviour.

So perhaps it's not caches? Or perhaps neither of these approaches alter the behaviour of the right cache?

But there's something that ExxTOS and EmuTOS does, which TOS2.06 doesn't, which causes these games to fail. Or vice versa.

Anyone any thoughts?

BW

[exxos]

Stack frames / MMU :shrug:

Problem with 206 original, it still thinks it's running on a 68000. It's not properly compatible with the 030.

My build is compiled with a 030 in mind and it won't run on a 68000 at all. It's kinda like a dumbed down TOS306 really.

If you have something I can copy onto floppy or HDD I could try it on mine... But I have no way to get floppy images onto my STE currently..

[exxos]

Relating to the ROM shadow, I did a quick experiment..

My assumption was that the address would settle even with translation before /AS goes low. But I thought I would wait for /AS to go low THEN do the translation, which means slowing down the SDRAM access a bit.

It was sort of successful, because now it gets further than it did before but crashes later anyway :roll:

IMG_3193.JPG

IMG_3194.JPG

I delayed SDRAM access by a second clock just to make sure, but same problem :( always seems to crash with the same message in EMUTOS.

[exxos]

SUCCESS!!! (ALMOST)

I ran A-INT via a clocked delay and that seems to have solved the problem. So either the address takes more than 10ns to transition, or the PLD is glitching internally which shouldn't happen ...

TTram dropped from 847% to 833% which sucks. BUT with MAPROM, it dropped to 807% . So its still an improvement!

EMUTOS:

IMG_3195.JPG

TOS206 (patched)

Locks up at the same point when loading GB6. Locks up before the main window is drawn...

EDIT:

Forgot to run BLTFIX, but oddly, the screen "goes black" AFTER running it :shrug:

IMG_3196.JPG

Oh I know, its because during my code testing I did not allow the blitter to access ROM.. So I need to fix that next...

[Badwolf]

Line F error would be typical if, for example, the processor goes to read an instruction and gets 0xFFs back.

Black boxes are what you get when blitting (soft or hard) 0xFFs to the screen.

We can probably infer that either the SDRAM controller isn't supplying data at the right time, or it's supplying data from the wrong address.

Perhaps, during the ROM copy, fill the rest of SDRAM with a non-0xFF pattern to rule out the latter?

BW

[Badwolf]

Stack frames / MMU :shrug:

Stack frames would be the same irregardless of the OS. MMU initialisation? Perhaps.

If you have something I can copy onto floppy or HDD I could try it on mine... But I have no way to get floppy images onto my STE currently..

I've been intentionally trying to boot original images (or sometimes cracked versions thereof), but let me see if I can find something copyable that exhibits the behaviour.

Perhaps I'll boot from TOS2.06 and see if I can replicate the problem with a soft-loaded EmuTOS. That way I can take stuff out and iterate much more quickly.

I really want to get the chip swtiched out so we're all singing from the same hymn sheet, but I'm only getting about 45 mins per night at best ATM!

BW

[exxos]

Stack frames would be the same irregardless of the OS. MMU initialisation? Perhaps.

I'm not so sure.. Because when Putnik was patching TOS so the STE could run properly with a 68010, IIRC, he said it didn't work because of stack frames. He patched something, then it worked.. but it was like several years ago now.. so maybe I remembering wrong..

EDIT:

Is a mention of something here..
viewtopic.php?p=103713#p103713

Also from an old thread..

Another unfortunate choice has been to pass trap parameters on the stack. Because since 68010, the exception stack frame format has changed. All old code intercepting traps and looking at stack parameters does not work anymore on such processors, unless they are aware of such difference (with the help of the _longframe $59e variable). And the situation degraded again on ColdFire, where the exception stack frame changed completely again.

larger stackframe in 68010-30 and later, what just fails on SW what manipulates with data on stack. And TOS is such SW, so needs special support for larger stackframe. Threre are some other changes, like reading of SR register, then pipeline used by 68030 (maybe bt 68020 too ?) what causes bad work of some self modifying SW.
All SW, what fails because mentioned CPU changes may fail on 68010-30. Reading of SR register is exception - that can be solved in TOS, as it is .

There's also comments about later TOS versions using more RAM which can upset games if they use lower RAM which was "unused" before.. I assume my TOS206 patch may use more RAM than original 206, but no idea.

[Badwolf]

Stack frames would be the same irregardless of the OS. MMU initialisation? Perhaps.

I'm not so sure.. Because when Putnik was patching TOS so the STE could run properly with a 68010, IIRC, he said it didn't work because of stack frames. He patched something, then it worked.. but it was like several years ago now.. so maybe I remembering wrong..

Stack frame length (primarily for bus error, but also illegal instruction IIRC) is a function of the processor. The OS can't* influence if a game's going to fail because it expects a 68000 stack frame and is getting an 030 one. This is one of the big reasons you can't run TOS 1.4 on an 030 and why it would need patching, but patching the OS won't make other software handle long frames.

* I say can't here. Technically it can and it's what Anders has tried with his Hyper68k program (which I've worked on), but no OS that I'm aware of tries to become a hypervisor, so more correctly the OS, doing the normal things we expect of the OS, can't directly change another piece of software's long frame handling logic. It can set the longframe variable to the proper value and it can set the _CPU cookie correctly, but how a third party program acts on that is not in its control.

There's also comments about later TOS versions using more RAM which can upset games if they use lower RAM which was "unused" before.. I assume my TOS206 patch may use more RAM than original 206, but no idea.

Yes, that's possible, but I wouldn't realistically expect that to be a problem with so many games. TOS has changed its memory usage ever since 1.2 came out so you'd expect that to affect mostly the older games.

I've done a little bit of testing with Hatari and things definitely start behaving differently when MMU emulation is turned on under ETOS, so that could indeed be involved somehow. Perhaps connected to the shadowing of registers?

BW

[stephen_usher]

There's also comments about later TOS versions using more RAM which can upset games if they use lower RAM which was "unused" before.. I assume my TOS206 patch may use more RAM than original 206, but no idea.

Yes, that's possible, but I wouldn't realistically expect that to be a problem with so many games. TOS has changed its memory usage ever since 1.2 came out so you'd expect that to affect mostly the older games.

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.

All you can do is set the cookies for the CPU and FPU and hope programs use them. I wish PP's game loaders used them rather than guessing using the TOS version.