REV 3 - REV 5 - The beginning (ST536)

[exxos]

Been going over night...

IMG_4367.JPG

[macsonny]

Hi All,

I’m so encouraged to see the ST536 project is still alive. I bought a card from Exxos earlier this year and populated with components but I’m not sure I’ve got it right for the Atari ST.

A few questions:

1. I solders on a 288 CPLD but is that right or should I have used a 144 CPLD?

2. I’m struggling to try and work out which firmware I should be trying to flash. Is there a place I can get the current firmware?

3. What is the file(s) I need to put in the AUTO folder to ensure the card is recognized?

Sorry for the dumb questions. I’m more of an Atari 8-bit restoration guy so this 16/32-bit stuff is new to me but I’m really excited to get this card working.

Thanks

Sonny

[exxos]

I’m so encouraged to see the ST536 project is still alive. I bought a card from Exxos earlier this year and populated with components but I’m not sure I’ve got it right for the Atari ST.

All the latest information and firmware is here..
https://www.exxosforum.co.uk/atari/last/ST536/index.htm

See below 2025 NEWS..

[exxos]

For the sake of completeness.. These are before and after images of a timing problem I found with the help of AI.

NO_DELAY.JPG

DELAY.JPG

I also found another issue that when the PLD is heated the scores started to drop..

It would be helpful if some people with a original TF536 could take a couple of scopes for me to see what the original timings were.. Also if heating the PLD causes a slowdown or even a crash..

[ijor]

I would say, as I always say when dealing with CPLD or FPGA code, a comprehensive timing analysis is extremely important.

I think the problem is that the SDRAM data is not ready when the CPU tries to latch it.

That's perfectly possible, and even likely. I'm certainly not surprised. And that's precisely why timing analysis is so important.

Slowing the cycle by 20ns works, as the CPU doesn't latch too early when the data isn't quite stable yet. But of course that is a significant shift for data hold on the SDRAM as well. It works.. Though it slows down TTram access.. Because the CPU is effectively missed 2 sampling edges. So now I just delay by 10ns. It misses the first edge, latches on the second. The result is it is now stable with not much of a performance hit.

There is nothing intrinsically wrong with this approach, but you must be careful. You are explicitly relying on the data arriving late. But what if the data if not arriving late in some circumstances? Say, somebody might use a slightly faster RAM chip, some CPLDs could be slightly faster (even with the same speed grade). If the data happens to not arrive late, the CPU would be latching too late (or if you want, data would be too early, same thing).

You must make sure that data would always be "late", which is not so easy to confirm. Or otherwise you can issue two identical RAM read commands in a row. This way the CPU would always latch the correct data even if it happens to not be late. If the data is late (the hardware is slow), the CPU would latch the first iteration. If it's early (hardware is faster), it would latch the second one. But note that issuing two read commands would extend the SDRAM state machine one extra cycle, which might be a problem.

That is probably why the AI treats it as meta stability, because its not really wrong about latching on a edge which is changing.

No, that's not what AI is saying at all. According to what you posted earlier, AI is saying that the CPLD state machine could have a synchronization problem. AI is talking about how the CPLD handles the control signals coming from the CPU. No relation with the data going from the SDRAM to the CPU.

But the thing is, that was the conclusion to a very long conversation where I was using the AI as my "rubber duck" in all this to come up with ideas on things to look for.. I probably would have never considered a lot of stuff if it wasn't for AI suggestions. Whether it's talking total BS or not, it is greatly helped with a lot of issues and indeed even talked about SDRAM timings a lot where a lot of things wasn't considered.

Yes, I agree. The AI could give useful hints and ideas. As long as you are aware that it is not authoritative and anything that the AI claims should be doubled checked and confirmed, yes, it could certainly be useful.

But again, the AI probably failed in not giving you the most valuable recommendation. Perform a timing analysis. Or at least it wasn't mentioned in the AI quote you posted.

Been going over night..

Fabulous! :)

[olivier.jan]

I’m so encouraged to see the ST536 project is still alive. I bought a card from Exxos earlier this year and populated with components but I’m not sure I’ve got it right for the Atari ST.

All the latest information and firmware is here..
https://www.exxosforum.co.uk/atari/last/ST536/index.htm

See below 2025 NEWS..

Just a quick confirmation: when you write to solder 4.7uF capacitors across all small caps on the bottom, do you mean I need to add 4.7uF along the existing capacitors or do I need to replace the existing capacitors with 4.7uF ?(sorry, not a native English speaker here 😔)

Anyway I need to order the caps…

[exxos]

do you mean I need to add 4.7uF along the existing capacitors or do I need to replace the existing capacitors with 4.7uF ?(sorry, not a native English speaker here 😔)

4.7nF across the existing ones..

[Badwolf]

Or otherwise you can issue two identical RAM read commands in a row.

AFAIK (unless the SDRAM controller has changed significantly since the published TF330 version) that's what is done anyway to allow for the fact the SDRAM is running at 100MHz and the CPU at 50.

But it's SDRAM. Capable of running at 133MHz or more. There ought not be anything arriving late.

BW

[ijor]

AFAIK (unless the SDRAM controller has changed significantly since the published TF330 version) that's what is done anyway to allow for the fact the SDRAM is running at 100MHz and the CPU at 50.

Ah, yes, that makes sense.

But it's SDRAM. Capable of running at 133MHz or more. There ought not be anything arriving late.

The chip speed grade and max frequency has (almost) nothing to do with this. This is about clock skew and latency. You could use DDR graded for 5 GHz, and it could still arrive "late" if the latency is high enough. As a matter of fact, you could say that DDR is designed to arrive "late". A copper trace is not fast enough at those extreme high frequencies. But it is ok because DDR transmission is designed to be pipelined.

In anycase, I repeat once more again ... timing analysis, timing analysis, timing analysis ...

[exxos]

I think I finally found the root cause. All the hacks I've done don't seem to matter anymore. Fast and slow slew now work. I've uploaded a EXP firmware which has a workaround..

I've had to order a rather expensive scope as I believe my old one has been lying to me the whole time.. New scope won't be here for a couple of weeks.. But even then I have to figure out how to use the thing..