[N8VEM-S100:7433] 16mb SRAM Version 03 Board Success!

[Gary Kaufman]

One board that's been frustrating me for a long time has been the Version
03 16mb SRAM board with the 80386 processor board

I built one of the earlier mezzanine based boards which worked well with
2mbx8 SRAM (Cypress CY62167ELL-45ZXI 45ns 5v), but was never able to get
the V3 board to work properly with 4mbx8 SRAM (Alliance AS6C3216 55ns
3.3v). The errors were unpredictable, but most commonly resulted in 55H
fill errors in the A00000-BFFFFF and E00000-FFFFFF range and almost random
1234H fill errors anywhere in memory. The errors weren't isolated to a
single bank or SRAM and wait states / clock speed didn't seem to change
much, although it was more stable at very low clock speeds.

After several months of intermittently trying things, I substituted 74F240
for U9 and 74F139 for U4. The board has run two full passes of the
protected mode "J4" test without a single error.

Hopefully this might save someone else a bit of time.

- Gary

[David Fry]

Hi Gary,

I use the Version 03 16MB SRAM board with 2 x AS6C3216 for 8MB of RAM.
It has been built 'Stock' without modification and I've never had an issue
even with the 80386 (although I confess that board is hardly in my system)

Just a thought have you double checked the address decoding jumpers ?
K3 should be position 1-2 for the AS6C3216 chips
Jumper P2 should be 1-2, and P3 should be 5-6

If these are wrong you will get address decoding issues

Regards

David

Post by Gary Kaufman
One board that's been frustrating me for a long time has been the Version
03 16mb SRAM board with the 80386 processor board
I built one of the earlier mezzanine based boards which worked well with
2mbx8 SRAM (Cypress CY62167ELL-45ZXI 45ns 5v), but was never able to get
the V3 board to work properly with 4mbx8 SRAM (Alliance AS6C3216 55ns
3.3v). The errors were unpredictable, but most commonly resulted in 55H
fill errors in the A00000-BFFFFF and E00000-FFFFFF range and almost random
1234H fill errors anywhere in memory. The errors weren't isolated to a
single bank or SRAM and wait states / clock speed didn't seem to change
much, although it was more stable at very low clock speeds.
After several months of intermittently trying things, I substituted 74F240
for U9 and 74F139 for U4. The board has run two full passes of the
protected mode "J4" test without a single error.
Hopefully this might save someone else a bit of time.
- Gary

[Gary Kaufman]

David -

Thanks for the confirmation of the jumpers, I do have them correct. At
one point I left off P3 (intentionally) and ran it as a 8mb board - I
seem to recall that it was far more reliable that way, although I have
no idea why that might be.

In any case, this board was frustrating me for a long time - the 4mbx8's
were expensive and the board is very cosmetically attractive so I really
wanted to use it in the system. Glad to have it finally working
nicely. For those in the USA, Unicorn Electronics has both 74F240 and
74F139/74S139 at $0.49 each.

I have the V5 board waiting to construct, but will probably just recycle
the mezzanine board for now until I find a good price on the AS6C3216's.

- Gary

Post by David Fry
Hi Gary,
I use the Version 03 16MB SRAM board with 2 x AS6C3216 for 8MB of RAM.
It has been built 'Stock' without modification and I've never had an
issue even with the 80386 (although I confess that board is hardly in
my system)
Just a thought have you double checked the address decoding jumpers ?
K3 should be position 1-2 for the AS6C3216 chips
Jumper P2 should be 1-2, and P3 should be 5-6
If these are wrong you will get address decoding issues
Regards
David
One board that's been frustrating me for a long time has been the
Version 03 16mb SRAM board with the 80386 processor board
I built one of the earlier mezzanine based boards which worked
well with 2mbx8 SRAM (Cypress CY62167ELL-45ZXI 45ns 5v), but was
never able to get the V3 board to work properly with 4mbx8 SRAM
(Alliance AS6C3216 55ns 3.3v). The errors were unpredictable, but
most commonly resulted in 55H fill errors in the A00000-BFFFFF and
E00000-FFFFFF range and almost random 1234H fill errors anywhere
in memory. The errors weren't isolated to a single bank or SRAM
and wait states / clock speed didn't seem to change much, although
it was more stable at very low clock speeds.
After several months of intermittently trying things, I
substituted 74F240 for U9 and 74F139 for U4. The board has run
two full passes of the protected mode "J4" test without a single
error.
Hopefully this might save someone else a bit of time.
- Gary
--
You received this message because you are subscribed to the Google
Groups "N8VEM-S100" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/d/optout.

[John Monahan]

Great observation Gary, thanks. I have been using the 5V chips these days, but have a board 3.3V board running with a 36MHz Oscillator. Nevertheless I will upgrade all my boards to a 74F240. Don’t have 74F139’s but will use 74S139. The latter should be OK since the inputs are buffered and thus no bus loading.



As you probably know by now I have been working on a V2 version of that 80386 board. It’s been a very long road with a number of prototypes but I’m real close to a final CPLD driven version now. The fundamental problem with putting the 80386 (and 80486) on the S100 bus is the processor read and write signals come out very early in the cycle. The S100 bus pWR* had to be modified and was on the “V1” 80386 board. However the pDBIN signal is also marginal. I could get a reliable system with a CLK2 of 36MHz (S100 Phi 9 MHz) in a 21 slot Godbout motherboard with active termination, but it was clear this was not optimum.



The good news with a CPLD driven board is one can have much more control on the length and timing of these signals. The bad news is – lots of fiddling around with byte, word, even, odd, RAM and I/O read/write logic signals analysis. I’m getting there. Right now I have a solid 40MHz CLK2 board working (S100 Phi 10MHz).

This is with your V3 16MB RAM board and with the newer V5 board (also the old 4MB boards). The V5 (GAL based) board, BTW gets around the delay of the above 74xx circuits.



Anyway again, great info Gary. Will get you a V2 80386 hopefully soon.

John









From: n8vem-***@googlegroups.com [mailto:n8vem-***@googlegroups.com] On Behalf Of Gary Kaufman
Sent: Tuesday, July 21, 2015 6:36 AM
To: n8vem-***@googlegroups.com
Subject: [N8VEM-S100:7433] 16mb SRAM Version 03 Board Success!



One board that's been frustrating me for a long time has been the Version 03 16mb SRAM board with the 80386 processor board

I built one of the earlier mezzanine based boards which worked well with 2mbx8 SRAM (Cypress CY62167ELL-45ZXI 45ns 5v), but was never able to get the V3 board to work properly with 4mbx8 SRAM (Alliance AS6C3216 55ns 3.3v). The errors were unpredictable, but most commonly resulted in 55H fill errors in the A00000-BFFFFF and E00000-FFFFFF range and almost random 1234H fill errors anywhere in memory. The errors weren't isolated to a single bank or SRAM and wait states / clock speed didn't seem to change much, although it was more stable at very low clock speeds.

After several months of intermittently trying things, I substituted 74F240 for U9 and 74F139 for U4. The board has run two full passes of the protected mode "J4" test without a single error.

Hopefully this might save someone else a bit of time.

- Gary