exxos's Atari, Amiga & retro forum

I spent a couple of hours on this yesterday and didn't get a lot of luck trying to nail down repeatable issues so more work on that is needed.

Currently I'm seeing random lock ups and mono detect reboots on IDE access (again).

Is the green screen a feature of the new ExxTOS? I did get a red one once.

That doesn't look good.

Lock up on HDDriver load.

Running from floppy. Lockup on the blitter benchmark.



BW

You get address error on ROM copy.. So it's failing to copy ROM to SDRAM then falls back to ROM. It used to output bad bits but something broke I think in the error reporting code at some point. Will probably fix or remove that debug output at some point.

I can't find any faults on the boards I have here. So maybe send me your board to me to see if I can replicate what your seeing.

EDIT:

The green screen is really just a debug output at the moment, green means TOS detected a cold boot IIRC.. I got "had" multiple times thinking TTram wasn't working when it was TOS doing a "warm boot" and not looking for it again... So the green screen is a reminder that TOS has "reset" fully as its running its mem config stuff as it does in a cold boot.

exxos wrote: 06 Jul 2025 23:57 You get address error on ROM copy.. So it's failing to copy ROM to SDRAM then falls back to ROM. It used to output bad bits but something broke I think in the error reporting code at some point. Will probably fix or remove that debug output at some point.

I can't find any faults on the boards I have here. So maybe send me your board to me to see if I can replicate what your seeing.

EDIT:

The green screen is really just a debug output at the moment, green means TOS detected a cold boot IIRC.. I got "had" multiple times thinking TTram wasn't working when it was TOS doing a "warm boot" and not looking for it again... So the green screen is a reminder that TOS has "reset" fully as its running its mem config stuff as it does in a cold boot.

Ah, good to know the green isn't an IDE fault (I had similar symptoms when the IDE was plugged in backwards!)

I've spent some more time on it and mass storage and DMA are repeat problems.

EmuTOS will work with my IDE, but only after loading HDDriver. It'll work with ASCI natively, however.

Under ExxTOS HDDriver detects IDE drives but they're not accessible. Sometimes it'll think the disc is only 2GB instead of the 16 it really is. ACSI simply doesn't work at all.

DOTT will run happily with EmuTOS/ACSI.

Same card mounted as IDE will see reboot loops when trying to access large files (like DOTT). I've proven this to be the mono detect interrupt firing via a modified emutos.prg.

Enabling the blitter in ExxTOS (floppy boot) results in a lock up. Disabling cache no effect.

At this point I think I've run out of sensible tests. I think we need to rule out the board being faulty, so I'll send it back to you. My suspicion is the board is fine but my motherboard has subtly different timing requirements to yours.

There is definitely something wrong with DMA, but why it's only an issue under ExxTOS, I don't know. No blitter from the EmuTOS desktop, of course, so that's maybe it. But why ACSI should behave under one OS and not the other is odd. Different drivers, I suppose. Perhaps timing of accesses is sufficiently different.

BW

Badwolf wrote: 07 Jul 2025 23:16 At this point I think I've run out of sensible tests. I think we need to rule out the board being faulty, so I'll send it back to you. My suspicion is the board is fine but my motherboard has subtly different timing requirements to yours.

Yeah there's to many weird problems to attempt to diagnose things as they are currently. You seem to have a lot of unrelated things all acting up like IDE then the blitter. There isn't much in common other than the databus etc

I forget which motherboard you have again...?

All the STE536 and STE motherboards I've tested and everything is fine. I think me testing the STE536 in one of my motherboards is the way to go. If it works you'll have to send me your motherboard to diagnose the problem that way.

The address fault could be a clue. I've seen it where you could assume bad RAM but it's something unrelated like IDE int glitching causing weird errors. Though with your setup I'm just stabbing in the dark now as I can't replicate that weird behaviour. Hopefully it will be something dumb in the end and have a easy fix..

exxos wrote: 08 Jul 2025 00:06 The address fault could be a clue. I've seen it where you could assume bad RAM but it's something unrelated like IDE int glitching causing weird errors. Though with your setup I'm just stabbing in the dark now as I can't replicate that weird behaviour. Hopefully it will be something dumb in the end and have a easy fix..

I think that's only happened a couple of times. Perhaps when it's hung during a ROM copy and I've reset it?

I've got the board packaged up, will get it in the post today.

BW

Badwolf wrote: 08 Jul 2025 11:28 I think that's only happened a couple of times. Perhaps when it's hung during a ROM copy and I've reset it?

I did wonder if it was a bad connection on the ROM, but after it copies to SDRAM it would rule that out anyway (copy is verified)

My only thought is maybe something is still triggering the IDE on yours which causing it to corrupt the bus, that's what I found with the INT line glitching causing all kinds of craziness. But that wouldn't explain issues with DMA stuff if the IDE is unplugged during those tests.

Maybe its something stupid like the CPU has gone bad.. I will test it on my DFB1X test board just to be sure anyway..

I've got the board packaged up, will get it in the post today.

:thumbup:

exxos wrote: 08 Jul 2025 11:44 I did wonder if it was a bad connection on the ROM, but after it copies to SDRAM it would rule that out anyway (copy is verified)

I was about to type that as I was going to mention I'm shipping the original ROM back rather than my current EPROM one as I'm not convinced these old Hitachi chips are making good connection, but like you say: it's checksummed.

My only thought is maybe something is still triggering the IDE on yours which causing it to corrupt the bus, that's what I found with the INT line glitching causing all kinds of craziness. But that wouldn't explain issues with DMA stuff if the IDE is unplugged during those tests.

Mostly I just remove the SD card when testing without IDE, leaving the actual device attached so it could be, but last night I had the entire thing off as I was getting no-where quickly and still saw problems.

The other really weird thing is that I spent a full day remaking an IDE SD card with all my stuff on it that would boot under TOS2.06 with HDDriver and under EmuTOS without it. EmuTOS would not see it at all until HDDriver was run, in which case the partitions appeared and worked well. TOS would simply not open any of the partitions. I don't have a *clue* how that sort of situation could come about.

Anyway: see how you get on. I'm sure I had a working version (perhaps without autoboot) before holiday, but even reverting to current16 didn't show any changes to behaviour, so perhaps I'm dreaming or perhaps the fault really is an intermittent hardware one.

I did clean the main PLCC socket and test with a proper 68k in there, so I doubt it's that, but what else is left? I've been over the CPLD a couple of times.

Very odd.

BW

Badwolf wrote: 08 Jul 2025 11:52 I was about to type that as I was going to mention I'm shipping the original ROM back rather than my current EPROM one as I'm not convinced these old Hitachi chips are making good connection, but like you say: it's checksummed.

Yeah the Hitachi ROMs I have no end of troubles. They legs don't seem very "firm" on them.

EmuTOS would not see it at all until HDDriver was run, in which case the partitions appeared and worked well.

:stars:

TOS would simply not open any of the partitions. I don't have a *clue* how that sort of situation could come about.

Its like EMUTOS "forgot" how to access the harddrive :lol:

Anyway: see how you get on. I'm sure I had a working version (perhaps without autoboot) before holiday, but even reverting to current16 didn't show any changes to behaviour, so perhaps I'm dreaming or perhaps the fault really is an intermittent hardware one.

I've been down that firmware trap many times.. One firmware works, you update it, doesn't work, go back to previous firmware, still doesn't work :lol: :roll: I was fighting with thermal issues for a long time which threw me out for a long time :(

I did clean the main PLCC socket and test with a proper 68k in there, so I doubt it's that, but what else is left? I've been over the CPLD a couple of times.

Operator error :P

Very odd.

I have had a lot of troubles with the STE 8Mhz clock so that could be a factor. Though bad clocks was actually taken into account on the original TF design anyway..

I shalt not rest until I have figured it out :)

I couldn't get my Hitachi's to work at all...atmels just arrived and voila!
Running under modified TOS 2.06. Booted just fine and testing so far is looking fantastic.

Will continue to do some further testing later today.

coonsgm wrote: 10 Jul 2025 17:50 I couldn't get my Hitachi's to work at all...atmels just arrived and voila!

Running under modified TOS 2.06. Booted just fine and testing so far is looking fantastic.

Will continue to do some further testing later today.

:bravo: :2k2: :girldance:


Just need to figure out @Badwolf's list of issues now... Hopefully it will turn up soon.. I will probably start a new thread on that as not to cross the streams with everything else going on...