• Please review our updated Terms and Rules here

5162 XT/286 SIMMs

So I think to resolve the original question of the thread we can safely say that any standard 9 chip 256kB SIMMs will do
Background: Fictional example at [here].

But what if some of the 9-chip 256KB SIMM's contain chips requiring 512 refresh recycles (rows) !

On a 9-chip 256KB SIMM, each of the 9 chips contains 262,144‬ cells (256Kbit). It is up to the chip maker as to the dimensions of the 262,144‬ cell matrix, e.g.
* 512 rows by 512 columns
* 256 rows by 1024 columns
If the chip's cell matrix is 512 rows by 512 columns, then the chip will require 512 refresh recycles (rows). Maybe such 256KB SIMM's do not exist. I do not know.

And so I think, to be safe, that the SIMM requirement is best put at: industry-standard 30-pin, of 256KB, with parity, of 150ns access time (or faster), of 256cycle/4ms refresh
 
And so I think, to be safe, that the SIMM requirement is best put at: industry-standard 30-pin, of 256KB, with parity, of 150ns access time (or faster), of 256cycle/4ms refresh
Sounds good to me, The 3 chip SIMM's P/N: SJ-2563N i currently have in my 5162 have 2 chips of V53C104FK70 [ Data Sheet ] and 1 smaller chip of V53C256AJ70 [ Data Sheet ] If i have been reading the data sheets correctly the requirements are met, As i said before i can't fault them yet, The XUB is behaving with the original IBM Bios fitted but will keep playing until i get bored.
 
Well, that's good to know!
I checked my 256kb SIMMs. I used to have a lot, but it seems at some point in the past I got rid of most of them. All I have at the moment are eight matching 3-chip 256kb SIMMs. I don't recall the part numbers. I haven't tried them on my 5162 board yet, but I did try some 9 chip 1MB SIMMs, and sadly those did not work. I was hoping they would be detected as 256kb SIMMs, but instead the BIOS just sent some error codes to the PC speaker.
 
The 3 chip SIMM's P/N: SJ-2563N i currently have in my 5162 have 2 chips of V53C104FK70 [ Data Sheet ] and 1 smaller chip of V53C256AJ70 [ Data Sheet ] If i have been reading the data sheets correctly the requirements are met, ...
Reading the 'V53C104 Family' data sheet that you pointed to, I see, "512 Refresh cycles/8 ms", and so the 256 cycle requirement is not met.

... As i said before i can't fault them yet, ...
I have a few things going on today. I will come up with a test procedure for you.

... The XUB is behaving with the original IBM Bios fitted ...
Whilst interesting to me (and others I presume), the compatibility of those two things is out of scope of this thread.
 
Reading the 'V53C104 Family' data sheet that you pointed to, I see, "512 Refresh cycles/8 ms", and so the 256 cycle requirement is not met.

Yes, I did read that but i swear i also read something along the lines of " At least 512 Refresh cycles in an 8ms period ", At the time i was searching for data sheets i read several on the V53C104, maybe it was in another data sheet. The data sheet for the V53C256AJ70 chip states " 256 refresh cycles/4ms "

I have a few things going on today. I will come up with a test procedure for you.
Great Thanks

Whilst interesting to me (and others I presume), the compatibility of those two things is out of scope of this thread.

Slightly i suppose, At the mo i'm throwing everything i can think of i have at it.
 
modem7 said:
I have a few things going on today. I will come up with a test procedure for you.
Great Thanks
If there was no DRAM refreshing at all, at boot time, DOS would get loaded into RAM, then within seconds, get corrupted. A user would detect that quickly. Here, the hypothesis (repeat: hypothesis) is that for 512-cycle SIMM's in a 5162, the second half of the SIMM addresses are not getting refreshed. In the 5162, that motherboard address space corresponds to 256 KB to 512 KB.

If DOS is being loaded somewhere in address space xxx KB to 256 KB, DOS is not going to get corrupted (after 'DRAM leakage' time). If a program is then loaded from disk, and goes into address space xxx KB to 256 KB, it is not going to get corrupted (after 'DRAM leakage' time). So a test involves loading something to somewhere in address space 256 KB to 512 KB, waiting say 10 seconds (i.e. well past expected 'DRAM leakage' time), then seeing if that something is corrupted or uncorrupted.

So, since DOS is booting, try the 'OPTION 4: DEBUG' section of [here], substituting "4000:0" in place of "8000:0".
4000:0 is address 256 KB.
Oviously:
1. When you write a block of FF, then wait 10 seconds, you expect to then read back a block of FF; and
2. When you write a block of 00, then wait 10 seconds, you expect to then read back a block of 00.
 
If there was no DRAM refreshing at all, at boot time, DOS would get loaded into RAM, then within seconds, get corrupted. A user would detect that quickly. Here, the hypothesis (repeat: hypothesis) is that for 512-cycle SIMM's in a 5162, the second half of the SIMM addresses are not getting refreshed. In the 5162, that motherboard address space corresponds to 256 KB to 512 KB.

If DOS is being loaded somewhere in address space xxx KB to 256 KB, DOS is not going to get corrupted (after 'DRAM leakage' time). If a program is then loaded from disk, and goes into address space xxx KB to 256 KB, it is not going to get corrupted (after 'DRAM leakage' time). So a test involves loading something to somewhere in address space 256 KB to 512 KB, waiting say 10 seconds (i.e. well past expected 'DRAM leakage' time), then seeing if that something is corrupted or uncorrupted.

So, since DOS is booting, try the 'OPTION 4: DEBUG' section of [here], substituting "4000:0" in place of "8000:0".
4000:0 is address 256 KB.
Oviously:
1. When you write a block of FF, then wait 10 seconds, you expect to then read back a block of FF; and
2. When you write a block of 00, then wait 10 seconds, you expect to then read back a block of 00.

Many thanks, I think i got it right, I tried several times waiting 10 secs and longer,before reading back and with parity errors disabled and not, I got the same results every time, If you can think of anything else i can try let me know, I have not been able to fault it using those 3 chip sims.
debug.jpg
 
Many thanks, I think i got it right, I tried several times waiting 10 secs and longer,before reading back and with parity errors disabled and not, I got the same results every time, If you can think of anything else i can try let me know, I have not been able to fault it using those 3 chip sims.
I cannot think of another experiment.

The 'V53C104 Family' data sheet includes, "512 Refresh cycles/8 ms". Also there is, "up to 512 (x4) bits within a row", implying 512 rows of 512 bits (columns). The 5162's technical reference indicates that the 5162 motherboard is doing 256 refresh cycles over 3.84 ms. So I am puzzled as to what is refreshing rows 257 to 512 of your V53C104FK70 chips.

Can anyone else offer an explanation ?
 
I cannot think of another experiment
Well i'm stumped, Time to put the lid back on, I will leave the original IBM Bios Roms in and leave the 3 chip sims in as it's running fine with them.
 
Back
Top