exxos's Atari, Amiga & retro forum

@terriblefire Is this normal for STERM ? I mean its hardly low for 20ns...

I played around with various signals and code bits last night..it odd as those ram lockups don't get any worse even when the CPU gets hot,. And yet without a fan it won't run anything 32bit.

Something is tripping up but so far I can't work out what. It only happens with TOS in RAM as well. Testing the RAM otherwise passes just fine. Its really odd...

Its not the cpld getting too hot is it?

PhilC wrote: 03 Apr 2021 10:40 Its not the cpld getting too hot is it?

That's what I thought a few posts back... I can freezer spray the cpu or pld and it works... Its why I wanted to move to the 144xl as they do 5ns ... But its odd as the 144xl says a slower max clock speed than the 288xl.. I don't get it. Something is borderline but so far can't really work out what. The rise and fall times on the PLD look a bit slow, so in theory a 5ns PLD should have better rise and fall times...

Oh I also hacked the 3.3v regulator and even ran up to 3.9v and it made no odds.. So its more why I'm leaning towards the CPU. but to only act up with TOS in RAM... Doesn't make any sense.

Did a ram test and it was passing fine. Then rebooted and it locked up on the second ram test. I might build another board to rule out connections issues. I might add a timeout in the code to issue dtack after say 10 cycles just to make sure something is tripping up somehow, have to wait until Monday now.

exxos wrote: 02 Apr 2021 21:09 Even when I was doing my 16MHz stuff, between CPU pins I could have a 1 V drop just across like 1 cm of track!

Check out march 10th 2015..

https://www.exxosforum.co.uk/atari/last/16mhz/index.htm

Thanks. Solid measurements always persuasive!

Mine's almost a full fill on the bottom layer, but bisected by a bloody 3V3 line I couldn't find room for & stitched to a half-flood on the top.

Definitely 4 layer next time!

BW

exxos wrote: 02 Apr 2021 22:50 @terriblefire Is this normal for STERM ? I mean its hardly low for 20ns...

It only has to be low during a single CPU negative clock edge. 20ns sounds bang on providing there's not too much clock skew.

Here's how mine looks:

BW

exxos wrote: 03 Apr 2021 10:53 Oh I also hacked the 3.3v regulator and even ran up to 3.9v and it made no odds.. So its more why I'm leaning towards the CPU. but to only act up with TOS in RAM... Doesn't make any sense.

TOS in RAM means more time spent at 50MHz. Have you got a proper 50MHz ceramic CPU on there?

My plastics will run happily at 40MHz forever, but whereas one will run for a few minutes at 50 before keeling over the other will simply not do a thing even at 48.

BW

Badwolf wrote: 03 Apr 2021 14:41 TOS in RAM means more time spent at 50MHz. Have you got a proper 50MHz ceramic CPU on there?

My plastics will run happily at 40MHz forever, but whereas one will run for a few minutes at 50 before keeling over the other will simply not do a thing even at 48.

I've tried plastic and ceramic. Both act the same. But it runs at 50mhz all the time not just on TTRAM access. But it doesn't ever trip up on STRAM and even when the CPU gets red hot, nothing gets worse.

The only reason I can think it would hang is if the CPU never sees STERM but TFs code looks like its kept low until AS30 goes high.

The other odd thing is when I do get it to boot, TTRAM shows as some odd number on the upper address ... So the address bus must be corrupted I assume... The data bus is isolated from the ST during ram access ..

I guess even assuming a bad RAM solder somewhere, it wouldn't cause it to freeze up.. More just output ram errors...

I tried slowing down TTRAM access by all sorts of delays but made no odds either. So I can't see it being some bus conflict.

Other than building up a new board, not sure what else I can try. Can only assume the CPU fails on 32bit access at 50mhz but not 16bit stuff...

exxos wrote: 03 Apr 2021 14:56

Badwolf wrote: 03 Apr 2021 14:41 TOS in RAM means more time spent at 50MHz. Have you got a proper 50MHz ceramic CPU on there?

My plastics will run happily at 40MHz forever, but whereas one will run for a few minutes at 50 before keeling over the other will simply not do a thing even at 48.

I've tried plastic and ceramic. Both act the same. But it runs at 50mhz all the time not just on TTRAM access. But it doesn't ever trip up on STRAM and even when the CPU gets red hot, nothing gets worse.

Ah, of course, your delayed DTACK trick. Do you still need that now? I know it might be technically more elegant, but you don't want to throw off the AltRAM timings -- they have to be clock cycle exact.

The only reason I can think it would hang is if the CPU never sees STERM but TFs code looks like its kept low until AS30 goes high.

Are the AS, DSACK[1:0], STERM lines all static after a hang, or still pulsing?

The other odd thing is when I do get it to boot, TTRAM shows as some odd number on the upper address ... So the address bus must be corrupted I assume... The data bus is isolated from the ST during ram access ..

I guess even assuming a bad RAM solder somewhere, it wouldn't cause it to freeze up.. More just output ram errors...

I tried slowing down TTRAM access by all sorts of delays but made no odds either. So I can't see it being some bus conflict.

Other than building up a new board, not sure what else I can try. Can only assume the CPU fails on 32bit access at 50mhz but not 16bit stuff...

All this sounds like the timing is slightly out of whack and stressing AltRAM is causing a failure here and there. It's perfectly possible that because of code changes, something's being routed via a different function block, runs 10ns slower, works most of the time, but every now and again...

That's what stopped me fitting mine into a 144 even though it technically does.

YAARTTT can't show up all errors. Especially cache-related ones.

How does EmuTOS.PRG go? That's a fully in-RAM version of the OS. No need for MapROM or similar. Equally, how do they all fare with data cache off?

https://downloads.sourceforge.net/proje ... -1.0.1.zip

BW