exxos's Atari, Amiga & retro forum

The plan currently is to shorten the upper data lines (D16-D31), as they always seem to be the ones causing problems, and they likely have the most capacitance as well. Ironically they are also the longest data traces on the board.

To line things up better for the SDRAM, the shortest traces (D0-D15) actually end up a little longer. That is just how things work out when they are rerouted. The long traces, which are the problem ones, end up roughly half the length they were, so all 32 lines end up much closer in length than before.

I am also moving the 16-bit bus buffer chip, the one that isolates the ST side bus, over towards the CPU. At the moment the CPU has to drive those long data tracks running along the bottom of the board to reach that chip, on top of driving the SDRAM. With the buffer sitting right next to the CPU, the ST side bus gets cut off as close to the CPU as possible, so the CPU no longer sees all that extra track. The long run then sits on the ST side of the buffer instead, where the bus is much slower and it does not matter.

Moving the chip also frees up the space it currently takes in the 68K area, so things there can be tidied up and spread out a bit. I am also planning for a possible future flash chip to go in that space instead.

exxos wrote: 12 Nov 2026 15:48 The plan currently is to shorten the upper data lines (D16-D31), as they always seem to be the ones causing problems, and they likely have the most capacitance as well. Ironically they are also the longest data traces on the board.

How confident are you that they're the problem? The traces might be a bit longer on the board itself but nothign like the ones on DFB1(X) which continue all the way onto and throughout the motherboard entirely unbuffered and seem to be drivable by the same chips.

Seems an awful lot of work for a hunch.

BW

Badwolf wrote: 12 Nov 2026 16:10 How confident are you that they're the problem? The traces might be a bit longer on the board itself but nothign like the ones on DFB1(X) which continue all the way onto and throughout the motherboard entirely unbuffered and seem to be drivable by the same chips.

Seems an awful lot of work for a hunch.

Had a bunch of test programs to find the failing bits. It was always the top 8 data lines, D24 to D31, which are the longest routes. The bus tests never showed an error on D0 to D23.

Thing is, I am running 100MHz SDRAM, so timings are a lot tighter than the DFB1. Getting everything in sync is a PITA.

It's not just a hunch either. With the machine booted and passing, clipping one x10 scope probe on D24 (about 10pF) took it from zero errors to failing 99% of the reads in the test. Take the probe off and it's back to zero. The same probe on RW30 makes no difference. So those lines have less margin than one probe tip's worth of load.

On the current layout the top 8 lines average about 88mm from the CPU, and most of them also carry a 50 to 70mm branch to the 16-bit bus buffer. After the rework they come down to about 41mm on average, the copper load drops from about 28pF to about 17.5pF per line, and moving the buffer takes that branch off the CPU side completely.

Which line in that byte fails first comes down to small differences. D26 and D24 are almost the same length, but D26 always goes first. The whole byte is on the edge though, and halving the copper should give it some margin back.

The thing is that only fails during very specific bit patterns and read and write sequences. YAARTTT would pickup as 0404 test errors, the other programs and I have in my arsenal of been designed to deliberately trigger the failing parts and sequences are now I literally get millions of errors as proof that their problem sequences are failing the way they appear to be.

A.I. Is doing the rework for me anyway. I am just telling it what to do step by step. Normally I wouldn't spend the time on such work personally (sick to death of routing PCBs TBH) . So shorter tracks should in theory match the lower data lines. I already see 1.6ns between D24 and D26. D24 is borderline. So I want to reduce all those higher track lengths and loads as much as possible. Margins should improve and theres some firmware tweaks in the mix as well to help.

exxos wrote: 12 Nov 2026 16:28

Badwolf wrote: 12 Nov 2026 16:10 How confident are you that they're the problem? The traces might be a bit longer on the board itself but nothign like the ones on DFB1(X) which continue all the way onto and throughout the motherboard entirely unbuffered and seem to be drivable by the same chips.
Seems an awful lot of work for a hunch.

Had a bunch of test programs to find the failing bits. It was always the top 8 data lines, D24 to D31, which are the longest routes. The bus tests never showed an error on D0 to D23.

They may be the longest routes, but they also have, like you say, other things on them. Jumping to it being the length seems a stretch at the speed we're talking about.

Thing is, I am running 100MHz SDRAM, so timings are a lot tighter than the DFB1. Getting everything in sync is a PITA.

Timings for the SDRAM commands, sure. But not for the 030. That's only running at 50MHz (20ns), and the data lines themselves are only changing every 40ns at best. Those are same for DFB1.

There could well be lag from the capacitance, reflections from the topography, etc, but 50mm of trace is less than a quarter nanosecond of delay. A factor of 160x smaller than the STERM switching speed.

In other words, I suspect it points to one of the faster clock dependencies being off by one so all your margin is gone. One 50MHz cycle off in your STERM assertion -- or even one 100MHz cycle on the SDRAM commands -- will massively swamp any trace length concerns by around two orders of magnitude.

A topological issue generating reflections might be more easily fixed with some termination and a tweak to the STERM timing.

It's not just a hunch either. With the machine booted and passing, clipping one x10 scope probe on D24 (about 10pF) took it from zero errors to failing 99% of the reads in the test. Take the probe off and it's back to zero. The same probe on RW30 makes no difference. So those lines have less margin than one probe tip's worth of load.

Adding capacitance should reduce reflections & would likely improve things if it were topological, wouldn't it?

So doesn't that sound like something's asserting on the wrong cycle (or half cycle) rather than on a 10cm board you've somehow lost about 4 metres worth of trace delay?

I don't doubt your measurements, I just don't think topography or line length pass the smell test.

BW

Badwolf wrote: 12 Nov 2026 17:12 They may be the longest routes, but they also have, like you say, other things on them. Jumping to it being the length seems a stretch at the speed we're talking about.

The length is what sets the load though. Capacitance to the planes and to the neighbouring tracks goes up with every mm of track. On the current board each of the top 8 lines has about 28pF of copper on it, against under 2pF on D0 to D7.

A topological issue generating reflections might be more easily fixed with some termination and a tweak to the STERM timing.

It's both. The firmware decides when the 030 latches, the board decides how long the lines take to settle. STERM is clocked from the CPU clock, so it can only move in whole 20ns steps. Moving it one clock later on a read straight after a write got the bus tests passing, but that is working around the lack of margin, not removing the cause of it.

Adding capacitance should reduce reflections & would likely improve things if it were topological, wouldn't it?

No, it slows the edges, so the line takes longer to settle while the latch point stays where it is. Whatever it does to reflections, the result was zero errors to 99% failing.

So doesn't that sound like something's asserting on the wrong cycle (or half cycle) rather than on a 10cm board you've somehow lost about 4 metres worth of trace delay?

The 4 metres is right if you only count flight time, but that isn't what's going on. The flight time on these lines is well under a ns, I agree with you there. STERM can only move in whole 20ns steps, so moving it a clock was just the smallest change available, it doesn't mean the data was 20ns late. On the simulation there was only about 2ns between the data settling and the 030 latching it, so a few ns is all it takes.

That few ns comes from how long the line takes to settle, not how long the signal takes to travel. The load slows the edge, and the branches ring, which you can see on the scope. The errors also only happen when the read is the opposite of what was just written, so the line has to swing all the way across. All of that gets worse with longer tracks and more load, which is why the longest and most loaded lines are the ones that fail.

I don't doubt your measurements, I just don't think topography or line length pass the smell test.

The board rework isn't there to fix one fault, it's there to give margin back, which is just good design practice. Right now the four bytes of the data bus average about 18mm, 28mm, 47mm and 88mm from the CPU, with the top byte also carrying the heaviest load. After the rework they are about 25mm, 36mm, 35mm and 41mm, so all 32 lines see a similar load and settle at a similar time, instead of one byte running right on the edge. The firmware then has a bus that behaves the same across all the bits, rather than being tuned around the worst 8 lines.