REV 3 - REV 5 - The beginning (ST536)

[exxos]

The series resistor PCB is now on order...

Capture.PNG

Meanwhile, the only thing I could do was try and solder some wires to improve the grounding which isn't really easy.. The length of the new ground wires is a order of magnitude longer than the path from the headers to ground.. but oh well..

IMG_4708.JPG

But the interesting thing is, while the spikes are only like 0.1V less, the ringing is a LOT less now.

IMG_4707.JPG

[exxos]

Had a thought.. (Yes is was painful) That the bus enable is happening at the worst time really. So I've added a 150ns delay on it as it doesn't matter for 8mhz anyway. So It now shifts that oscilation further away from the main bus transition oscilation. It was pushed to do 5 full GB6 passes before. Now it's just ticked over to pass 34.. Will leave it on overnight.. I don't expect it to keep going but it seems to be a step in the right direction.

I've added series resistors onto the next revision of the PCB. Not sure what value I'll use yet. The resistor PCB I think had 100R on there. So should be a good starting point. All signals have the resistor. So like 60 signals now with 100R in series.. That's gotta be significantly lower gnd bounce... Be interesting to see what the bounce will look like after that lot.. Even a 50% reduction would be great.

[exxos]

Earlier it ran for either 47 or 57 passes, I forget :roll: I've put a heatsink on the CPU this time. It's just about to pass loop 57 now.. So see if it runs for a bit longer this time.. Will edit this post later the result..

Also did a tiny bit of tidying up on the PCB design and managed to get rid of a few more vias. But I've also added a fair few because of adding the series resistors.

Need my JLC boards to come next so I can see about reducing gnd bounce. Ironically, the adapter PCB will make the gnd length several times longer than it is now. So they will aggregate the issue.. But I hope the peek gnd current will be significantly lower and counteract that..

Interesting that those odd resetting loops during ROM CRC test also seem to have gone. I suppose the physical ROM during boot could have tipped it over the edge. I did actually keep it enabled all the time to try and keep current spikes lower already. I guess putting rom on the 536 could have just been the tipping point.

EDIT
74 loops then locked up. Runtime 254 mins.

[exxos]

Looks like my JLC resistor boards should be coming tomorrow's :thumbup:

Hopefully they will solve all the problems once and for all. If not.. I'm out of things to investigate.. :hide:

[exxos]

Decided to have a look at what it actually "hangs on" . I fed information into a I am gutted to summarise everything into a more comprehensible format... But it looks like for some reason ROM was being accessed but as a WRITE.. Nothing would respond with DTACK and likely why the thing hung up. :stars:


MC68000 Bus Lockup Analysis (Atari ST / TOS 2.06)

While debugging a system lockup I probed a number of pins on the MC68000 CPU and found the following signals held LOW while the clocks were still running.

Pins observed LOW

Code: Select all

Pin 9   - R/W
Pin 23  - IPL2
Pin 24  - IPL1
Pin 26  - FC2
Pin 27  - FC1
Pin 37  - A9
Pin 38  - A10
Pin 41  - A13
Pin 44  - A16
Pin 54  - D15

All other address/data lines were assumed HIGH for the purpose of decoding the bus state.

Decoded address bus

Low address bits observed:

Code: Select all

A9  = 0
A10 = 0
A13 = 0
A16 = 0

Assuming the remaining address lines are HIGH, the resulting address is approximately:

Code: Select all

0xFEECFF

This falls inside the Atari ST TOS ROM mirror region:

Code: Select all

FC0000 – FFFFFF

So the CPU is accessing the TOS ROM address space.

Decoded data bus

Only D15 was LOW while the rest were assumed HIGH:

Code: Select all

D15..D0 = 0 111111111111111

Which corresponds to:

Code: Select all

0x7FFF

Bus control state

The following control signals were observed:

Code: Select all

R/W = LOW

Meaning the CPU is attempting a:

Code: Select all

WRITE cycle

Function code (CPU state)

Function code lines were:

Code: Select all

FC2 = 0
FC1 = 0
FC0 = 1

Which decodes to:

Code: Select all

User Data Space

So the cycle type is:

Code: Select all

User data write

Interrupt level

Interrupt priority lines were:

Code: Select all

IPL2 = 0
IPL1 = 0
IPL0 = 1

This corresponds to:

Code: Select all

Interrupt level 6

On the Atari ST this interrupt level is generated by the MFP (Multi-Function Peripheral) which handles timers, serial port, floppy signals and other system interrupts.

Combined interpretation

Putting everything together, the CPU appears to be attempting the following bus cycle:

Code: Select all

WRITE 0x7FFF -> Address 0xFEECFF
Space : User Data
Interrupt pending : Level 6

Since this address lies in the TOS ROM region, nothing should acknowledge a write cycle there. If no device asserts DTACK, the MC68000 will simply wait forever for the bus cycle to complete.

This would explain why the CPU appears to be locked on a single repeating bus state.

Possible causes

Typical causes for this type of lockup include:

• Missing DTACK response
• Address decoding fault
• Fault in glue logic
• Data bus floating or stuck bit
• Incorrect ROM shadow / memory mapping logic

Further investigation would require checking the state of the main bus handshake signals such as AS, UDS, LDS, DTACK and BERR to determine exactly which phase of the bus cycle the CPU is stuck in.

EDIT:

Just realised I should have measured all the address bits as it was a 030 cycle. I only could easily access the 68000 DIP bus anyway :roll:

Most likely the CPU was trying to write to SDRAM (or some other high up address which is invalid) as the ST side /AS was not low.

[Badwolf]

A cycle will wait forever if no DSACKn, STERM or BERR signal is issued.

Check there isn't an address write that will activate neither the TT-RAM state machine (to assert STERM), the bus error handler or the motherboard access.

You want to make sure one of the three will always fire on any bus access.

The easy way to do this (and how the glue does it) is assert bus error after N cycles of AS being down, regardless of the address. I think the ST does it after 64 cycles, so why not do it after 128?

BW

[exxos]

Yeah I need to add a berr count at some point.

This test has run for 25 hours straight. It circles back to the SDRAM again. I have some stuff to try. But long-term soak testing takes ages :lol:

20260311_190023.jpg

Last runs before got to around 17-20 passes.. So the end *might* be in sight..

[exxos]

Another boring screenshot.. Now to see if my code tweaks in the SDRAM controller keep it running overnight again.. :hide:

20260311_211733.jpg

I gave Claude, GPT, Grok my same theory on the code.. Grok and Claude both agreed with my theory. GPT said basically Nah don't t worry about it. :lol:

Both Claude and grok totally broke the SDRAM controller. Not sure why. But I gave claude my proposed solution and Claude gave me the lines to change.. So that's what's running now..

[exxos]

Its ran for 14 hours just fine...

20260312_101402.jpg

I've just put back the previous firmware to confirm it still locks up.. I'm doing this as I've been caught out so many times in thinking a firmware change fixed it when it just decides to work better for no reason at all..

So it failed under 20 passes before.. Hopefully it will fail again around a similar number. But as these faults are intermittent, only long term tests can help now..

[PhilC]

Making some really good progress there @exxos