Didn't check the pic (JS required) but I guess you have 72 chips all together? That's most likely going to be 4x banks of 512KB, where each bank has 16 chips corresponding to data bits on the 16-bit data bus, and 2 additional chips for parity. The address of the memory error will tell you which 512KB bank to look at, and the bit number where the error occurs would tell you which chip.

It's possible that banks are interleaved, but if the board supports running with 1.5MB (ie. an odd number of banks) then probably not.

bakemono wrote on 2022-05-08, 09:38:

Didn't check the pic (JS required) but I guess you have 72 chips all together? That's most likely going to be 4x banks of 512KB, where each bank has 16 chips corresponding to data bits on the 16-bit data bus, and 2 additional chips for parity. The address of the memory error will tell you which 512KB bank to look at, and the bit number where the error occurs would tell you which chip.

It's possible that banks are interleaved, but if the board supports running with 1.5MB (ie. an odd number of banks) then probably not.

Thank you for your response.

Direct link: https://i.imgur.com/uhmFsxJ.jpg

Now that mention you mention it, the memory is arranged in the same way as on the AboveBoard memory expansion card., and I recall it has "rules for adding chips" in the user manual. Let me see if that gives me any clues...

... So it says I must add two columns at a time, 18 chips. So, looks like you are correct and my suggested approach above needs to be slightly tweaked to account for reading/writing two bytes at a time:

The binary address is "11 1100 1000 0000 0000".

Cut that binary number into a high-order 9bits and a low-order 9 bits : 111100100 000000000
The high order 9bits become the column address within the chip, the low-order 9 bits become the row address within the chip (or vice-versa) and the byte of data gets split amongst the 8 chips (and a parity bit calculated by the 74F280) like this:

• Set address pins on all 9 ram chips to the low-order 9 bits
• Ground /RAS to latch the chip's internal row address
• Set address pins on all 9 ram chips to the high-order 9 bits
• Ground /CAS to latch the chip's internal column address
• Set the data pin for each of the 8 data ram chips in physical column 1 to one of the bits (d0-d7 go into A-H respectively) of the low-byte of the 16-bit word to store
• Set the data pin for the parity chip to the parity output of the 74F280 that is tied to physical column 1
• Set the data pin for each of the 8 data ram chips in physical column 2 to one of the bits (d0-d7 go into A-H respectively) of the high-byte of the 16-bit word to store
• Set the data pin for the parity chip to the parity output of the 74F280 that is tied to physical column 2
• Ground all the /WRITE pins save the values

(For values above 256K the next bit would go to 1, and that bit would tell it to store in the second column of chips, and so on.
Address bits 0-8 are row within the chip, 9-17 are column within the chip... Address lines 18,19,20,21,22 would be parsed to identify which 256k column.
0k-256k = 00000 999999999 999999999
267k-512k = 00001 999999999 999999999
513k-768k = 00010 999999999 999999999
769k=1024k = 00011 999999999 999999999

So to address memory above 1Mb you would have to use address line 20? That matches up with my understanding of "A20" being required to address upper memory.

scruit wrote on 2022-05-08, 11:36:

(For values above 256K the next bit would go to 1, and that bit would tell it to store in the second column of chips, and so on.

No, it's the lowest bit that tells which byte it is. With a 16-bit bus you have the ability to access 16 (18) chips at the same time to read/write two consecutive bytes.

Let's take your address and extend it to 21 bits since that is what would be required to address the whole board (2MB).

0 0011 1100 1000 0000 0000

IF there is no remapping (moving the UMBs around) It'll break down like this:

B BRRR RRRR RRCC CCCC CCCx

Where C bits are used for CAS, R bits for RAS, and B bits select the columns of chips 1+2, 3+4, 5+6, or 7+8.

x represents the lowest address bit but it may not even exist on the board. 386SX doesn't have an A0 line. If it only needs a byte instead of 16-bits it just ignores the other byte.

(Address bits used for RAS and CAS could be swapped for eg. static column mode DRAM, but it doesn't really matter here.)

If the board has its own SRAM cache, memory errors could be coming from there too!

bakemono wrote on 2022-05-09, 10:25:

scruit wrote on 2022-05-08, 11:36:

(For values above 256K the next bit would go to 1, and that bit would tell it to store in the second column of chips, and so on.

No, it's the lowest bit that tells which byte it is. With a 16-bit bus you have the ability to access 16 (18) chips at the same time to read/write two consecutive bytes.

..snip..

Thanks for your response. It matches what I had in my head, which I failed to accurately capture in writing.

When I said "For values above 256K the next bit would go to 1, and that bit would tell it to store in the second column of chips, and so on" I was not clear in describing what was in my head... Having a chance to rephrase it, what I shoudl have said was:

"For values above 256K the next highest address bit, a18 would go to 1, and that bit would tell it to store in the second pair of columns of chips (labeled 3+2) that store the 257k-512k range"

The board has an address line 0, but I agree that that bit should be ignored as it stores 2-byte words. It appears to specify the lower byte number in the address that it uses (on error location in ext mem was listed as 0x100000, which is the first byte above 1024k, and cover the byte addresses of 0x100000 and 0x100001, spanning those addresses with a 2-byte word that is specified by data lines d00-d15)

This is awesome feedback. I've done some smaller arduino-based memory addressing projects in the past, but nothing with a board this complex. I have finished mapping out the daughterboard, base DRAM, ext DRAM, cache SRAM, the buffer/or/nand /parity ics that control those chips, and the proprietary connectors to the motherboard. I am building an arduino mega based memory testing harness that will go beyond testing an individual chip and allow to me communicate with the board using the factory address/data/ras/cas/write/s1/s2/oe lines and do much more complex testing. I have to also implement a dram refresh cycle, but that's pretty clear from the data sheet.

My observation is that base memory tests 100% in checkit3 when the ext memory is removed, but the installing the ext memory reliably results in parity errors when testing base memory alone. I have about 4 different suspects (parity chips are shared between upper-lower mem... There is a factory bodge that ties all the /WRITE and /RAS pins for ext & base memory together bye passing through the 74F244 a couple of times... a few things that could accidentally cause the more than one area of memory to be selected at the same time, resulting in confused data signals and parity errors. I intend to test for these different patterns, and i can't do that using the pc.