Loading somewhat-random patterns into the entire 640KB of DRAM, then reading it back... It takes about 4 seconds for a full write/read/verify.

DEFINITELY consider refresh.... Failures increase dramatically as printing a failure takes a bit of time, and that adds to the delay in the refresh of the later bytes, compounding the problem.

So, I've looked into the schematics as best my brain can absorb, and I get the impression that the DRAMs are addressed as such: A15:8 are used to address columns, while A7:0 are used to address rows. When opening a row, as I understand, the entire row gets refreshed (read or write). The higher address-bits (A19:16) select the DRAM chip (and/or are used to select higher row/column addresses... this is where my brain gets lost).

So, as a quick test, I figured to do the following:

Write *all* data locations with data that can't be mistaken from byte-to-byte... (some XOR combination of the address and some other stuff)...

Byte0: 0x00000

Byte1: 0x00100

Byte2: 0x00200

Byte3: 0x00300

...

Byte 255: 0x0ff00

...

Once you reach the maximum DRAM address (0xA0000), start again:

0x00001, 0x00101, 0x00201, and so-on.

------

So, now, with every (sequential) memory access, a row is refreshed. So, whereas before an entire refresh was taking about 4 seconds, now it takes 4/256 = 1/32nd of a second to perform a full refresh.

.

Can't say I came up with the idea... I read vaguely about it on some demoscene page, I think. (I gotta say, I never had much respect for the demoscene until I started this project). As well as some looking into the BIOS code, which, as I understand, basically sets up the DMA controller to do essentially the same. Looking at the schematics (and not really understanding the DMA controller) I think it's slightly more sophisticated than this. There's a bit of circuitry that allows strobing *all* the /RAS pins on *all* the DRAM chips simultaneously. But that circuitry doesn't appear to be accessible any other way than through the DMA controller.

And, I'm sure my method could be improved with further understanding of the circuit. E.G. the /RAS signals go to all the chips within a bank, /Chip-selects are scattered-about, as well. And there's the higher address-bits which go to higher row/col(?) addresses. And, I haven't looked into it very thoroughly. So, e.g., if there's some combination where multiple chips are selected, but their output-enables are demultiplexed, all those chips would be refreshed simultaneously. (I know that SDRAM DIMMs wire things up in this way, it's a scheme for adding more addressable-space, without using explicit address bits. But it also serves the purpose of running the same instruction on those chips, even if that instruction serves no purpose (e.g. READing from a bank of chips while all but one have their output-enables disabled... the read-access occurs, but it's hidden from the user. But it also refreshes all the chips).

--------

As it stands, I'm now getting only one verify-failure through every write/read/verify loop of all 640KB!

-------

The problem, from before, apparently was due to a misunderstanding of the timing... I'd *intended* on activating the /S2:0 signals during the end of "T4", but it turns out it's activating at the beginning of "T1". So I had a nop where it wasn't necessary. I still need to look into that more thoroughly, but earlier tests (before I implemented refresh) were giving only 3 verify-errors out of 640K (but those were read immediately after written)... and I tried all three clock-delay options with no noticeable change. So maybe the clock-alignment isn't nearly as picky as I'd feared. Or, maybe that explains why I'm still getting a failure...

Here's the output from the tests: ("COUNT" is a bit misleading, it's <<=1)

Boot
0x20000 = 0xf0 expected 0xfe
0x60000 = 0xde expected 0xfe
0x1ef45 = 0x44 expected 0x54

### COUNT = 2 ###
0x1ef45 = 0x47 expected 0x57

### COUNT = 4 ###
0x1ef45 = 0x41 expected 0x51

### COUNT = 8 ###
0x1ef45 = 0x4d expected 0x5d

### COUNT = 16 ###

### COUNT = 32 ###
0x1ef45 = 0x65 expected 0x75

### COUNT = 64 ###
0x1ef45 = 0x5 expected 0x15

### COUNT = 128 ###
0x1ef45 = 0xc5 expected 0xd5

### COUNT = 0 ###
0x1ef45 = 0x45 expected 0x55