A500 Fast RAM & IDE

[terriblefire]

At the moment it is about understanding the 68K bus and the system. There is a lot of BS out there on the internet about how the Amiga works... source docs are useful but nothing beats an experiment.

Almost everything i learned about the Amiga was this way. The only two people I trust about Amiga are Thor and Toni Willen.

[cmorley]

I was stuggling with stability @16MHz CPU clock. Finally narrowed it down to me asserting the fast RAM /dtack on reads too early.

I was dong it asynchronously thinking there'd always be enough time for the data to propogate through buffers and the bus to settle before the CPU actually latched the data - but apparently not!

[cmorley]

So finding what fixes the instability is different to the cause and the why.

The MC68000 datasheet says @16MHz you have 50ns setup time max for the data after /DTACK is latched. Measuring at the CPU, with the logic analyser, if I make the data change coincidental with /DTACK then it is stable... 10ns after /DTACK and it will fall over. Where's my setup time budget gone?!

Delaying /DTACK by 10ns does cause a full cycle wait state so maybe the CPU just can't do reliable bus reads at 16MHz? So the internal state machines are tripping up but +1 wait state is enough for it to be happy. The chips are labelled P10s but who knows what they are really.

Does anyone know what clock speed P8 will typically go up to?

[cmorley]

I've come to the conclusion that the clock is just too fast for this 68000. 16MHz derived from a 96MHz clock (3 low, 3 high) is just too fast for this chip.

It seems that delaying dtack past the first S4 edge (so you get a full cycle wait state) is enough to make it happy. So is slowing the clock dynamically to 3 low, 4 high (13.7MHz) when /AS is asserted and 3/3 (16MHz) the rest of the time.

Interestingly the CPU won't ever boot at 16MHz (it always HALTs), it requires a long RESET to start - so I think it is just over the limit. It behaves as expected @ 13.7MHz and below.

I have some 68010 on order - who knows what they will actually be under the remarking! I also have some FN chips which are supposed to be 68HCs... again who knows what they actually are! I drew an adapter to fit an 68000FN in a 68000P which is being posted to me now.

Again, does anyone know what a P8 68000 will clock to typically?

[terriblefire]

I've never seen em past 12Mhz ... BUT! try a non 50% mark to space ratio.. it might help.

[cmorley]

Ooo! What are the chances of that? A P10 and a P12 with identical date and batch IDs?

Photo0950b.jpg

Wait, what?

Photo0949b.jpg

eBay case opened. I don't understand why the Chinese bother to fake this stuff - people will pay real money for genuine parts.

edit: less than 24 hours and I have a full refund.

[cmorley]

The PLCC to DIP adapters arrived today so I can finally try my project with a 68HC000 I have had for months..

Photo0962b.jpg

Obligatory sysinfo shot:

Photo0964b.jpg

This is running at 36MHz. The fast RAM isn't as fast as it could be because I have a noddy refresh in place at the moment - do a refresh when /AS goes high. This is fine at <16MHz but is delaying the next access @ 36MHz.

Not bad for a little dev board which was only designed to be a fast RAM and IDE test bed :)

[cmorley]

No updates for a while on this... next step is to drop the ispMACH LC4xxx CPLD for something else because of Lattice' license cost for the legacy ispLEVER Classic.

I will switch to an Intel/Altera MAX V or an Microchip/ATMEL ATF1508ASV depending on pinouts and cost of level shifting etc.

I might try the Lattice iCE40HX that terriblefire is using on his re-Agnus.