So, in the context of resurrecting and refining our ten year old beeb816 project, @revaldinho and I were looking into an issue: white snow was accumulating on the BBC Micro's bitmapped display. Evidently our in-CPU-socket upgrade was issuing rogue writes to the RAM. But we could find no glitch in the RnW line, and every dummy cycle that we ran was a read cycle, and was in any case directed to ROM.

A bit more observation showed that we saw both 1s and 0s being written over existing data, in a pattern almost (but not quite) repeating every 128 bytes, but the pattern differing between the two 16k banks of DRAM in the machine.

One oddity was that this phenomenon occurred whenever we ran our accelerator with an asynchronous clock, but never when we ran synchronously to the host (at 4MHz or 8MHz, the host being a 2MHz system.)

For a long time, for ten years in fact, we'd vaguely suspected something was wrong with the switching of the clock between accelerated mode and slow accesses to the host.

But no!

Long story short, with help from @hoglet, we found out what it was: even though WE was held inactive, our address lines were buzzing about at accelerated speed, and not at all respecting the setup and hold constraints relative to RAS.

It turns out, if you read dynamic RAM without respecting timing, you might well corrupt your data!

(This does make a certain amount of sense, given the way that rows are accessed, and a whole row of bits is presented to the sense amps, which have to both detect and regenerate the original charge on the active row.)

Interesting. It's a bit unexpected that a read cycle would corrupt memory. I guess that means the address needs to be stable and look like a dram address at all times, meaning the address would need to be muxed (eg forced to zero) to a fixed location if dram is not selected.

_________________
http://www.finitron.ca

Yes, it feels like a simple octal latch can solve this: we need to have the address lines stable in something like a 15ns window, but we can keep them stable for a whole dummy cycle. In other words, if we'd realised the hazard, it's not too hard to avoid - we think. A respin of the board is in order.

In a from-scratch system design, you would normally suppress the /RAS and /CAS strobes during the dummy CPU cycles, and only actually perform the DMA accesses. But the BBC Micro is built around the assumption that there is an access in every clock phase, which is true for the 6502 originally fitted.

(Maybe worth noting that any system with DRAM also needs to be sure that refresh is taken care of. In the Beeb's case, the video subsystem does that implicitly. But an in-socket system might need not only to produce dummy accesses but also a realistic sequence of SYNC pulses - that's true for Acorn's 6502 Second Processor, IIRC. I also recall a situation with @hoglet where something very nearly worked, and it turned out the PSRAM was not being given a chance to self-refresh.)

Well done to @hoglet

People do forget that with DRAM, EVERY read cycle will destroy the currently selected row data that was stored, hence that row has to be rewritten. If RAS or CAS changes during this time, or the address lines are not stable for the minimum required time before RAS or CAS change state, the internal row address or column address may change during the rewrite...

Exactly the same happens during a refresh cycle, except that if CAS never goes active (after RAS), the tristate output buffer is not enabled.

Mark