[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [N8VEM-S100:954] An 80386 S-100 Board.



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

SOrry...correction, I was looking at two controllers at the same time
and interminged them in my last post,

Here's the V96BMC up on ebay:

http://www.ebay.com/itm/Lot-of-2-V3-Corp-V96BMC-33LP-REV-AB-High-Perfomance-Burst-DRAM-Controller-/230744189846?pt=LH_DefaultDomain_0&hash=item35b96ceb96#ht_790wt_819

- --Mike


On 07/15/2012 06:36 PM, mike wrote:
> There are also a few FW82443BX which support 512MB of DRAM so if
> I'm not mistaken, two of these gets you to 1GB.
> 
> It's designed for the i960 processor but I don't see right up
> front, why it should be adaptable to the 386.
> 
> http://www.ebay.com/itm/FW82443BX-SL2VH-Manu-INTEL-Encapsulation-BGA-Controller-Miscellaneous-/110887357440?pt=LH_DefaultDomain_0&hash=item19d166cc00#ht_2311wt_819
>
>  
> http://www.ebay.com/itm/INTEL-FW82443BX-440BX-AGPset-Host-Bridge-Controller-BGA-/160629103858?pt=LH_DefaultDomain_0&hash=item25663d9cf2#ht_520wt_819
>
>  Datasheet attached.
> 
> Mike
> 
> 
> On 07/15/2012 06:17 PM, mike wrote:
> 
>> I see there's at least a couple DP8421AV-20 up on ebay:
> 
>> http://www.ebay.com/itm/DP8421AV-20-Manu-NS-Encapsulation-PLCC-68-microCMOS-Programmable-256k-1M-4M-/120921409478?pt=LH_DefaultDomain_0&hash=item1c277a47c6#ht_2311wt_819
>
>> 
> 
>> http://www.ebay.com/itm/DP8421AV-Integrated-Circuit-x-1-pieces-/400308222341?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item5d343ab985#ht_4722wt_1202
>
>> 
> 
>> http://www.ebay.com/itm/DP8421AV-20-Integrated-Circuit-x-1-pieces-/160838807571?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item2572bd7013#ht_4722wt_1202
>
>>  Looks like you would need one of those for each 16MB of DRAM if 
>> I'm not mistaken.
> 
>> It's a PLCC backage, so that's kind of nice.
> 
>> Even though they are obsolete, they seem to be still available 
>> here and there.
> 
>> There is also the DP8422A that can drive 64MB apparently, but it 
>> seems to be a little more hard to find.
> 
>> Datasheet attached.
> 
>> --Mike
> 
>> On 07/15/2012 05:00 PM, John Monahan wrote:
>>> That's a bummer Terry!  The problem with static RAM chips like 
>>> the 2MX16 is that they take up a lot of board space. With say
>>> 8 on an S-100 board we are still only at 16MG.  What I liked
>>> about the Cypress SIMMs is you could fit a lot on a board.  I
>>> wonder if there are other Static SIMMs out there still
>>> available.
> 
> 
> 
>>> As to the S-100 access, here is my thinking currently..
> 
>>> Of the two board 80386 set (CPU & RAM), the CPU board would be 
>>> made first and would be self-contained  and be able to boot
>>> from a ROM/RAM combination on the S-100 bus. Using cascade
>>> counters there would be a lot of wait states put on the 80386
>>> for both I/O and RAM access to the S-100 bus.   This should not
>>> bother the CPU. The 80386 BS16* line would always be low
>>> telling the CPU to expect 16 bit data, something we already
>>> have well working with our 8086 & 80286 CPU's.
> 
>>> Up to 16MG of RAM could be used in this way (4 of our 4MG
>>> static RAM boards).
> 
> 
> 
>>> When the above is working the second board would be done.
>>> Using a single 74LS682 we can select what part of the 80386
>>> address range goes "over the top" via a ribbon cable to a
>>> second high density RAM board. The lower cut off could be 0 to
>>> 16MG.  Such a board would run the RAM at a maximum data rate
>>> and 32 bits wide. Only data, address, ALE and R/W lines would
>>> be involved.   The challenge is to get as high a density as
>>> possible on that board. If I could find a DRAM controller that
>>> would refresh GB's of RAM independently of the 80386 (putting
>>> down wait states when busy), that would be best. No luck so
>>> far. That's why I resorted to the SRAM SIMMs.
> 
> 
> 
>>> As to voltage levels there are a few ways to handle the 3.3V/5V
>>>  differences. There are specialized chips for this or you could
>>>  perhaps use a resistor/Zener diode as we did on the Lava-10
>>> VGA board.
> 
> 
> 
>>> Thanks for the suggestion, please keep the discussions going
> 
> 
> 
>>> John
> 
> 
> 
> 
> 
> 
> 
>>> John Monahan Ph.D
> 
>>> e-mail:  <mailto:mon...@vitasoft.org> mon...@vitasoft.org
> 
>>> Text:     <mailto:mon...@txt.att.net> mon...@txt.att.net
> 
> 
> 
> 
> 
>>> From: n8vem...@googlegroups.com 
>>> [mailto:n8vem...@googlegroups.com] On Behalf Of Terry Sare 
>>> Sent: Sunday, July 15, 2012 10:35 AM To: 
>>> n8vem...@googlegroups.com Subject: Re: [N8VEM-S100:951] An 
>>> 80386 S-100 Board.
> 
> 
> 
>>> Looks like Cypress doesn't make those anymore.
> 
>>> Searching some distributors best I found in stock was 1M x16 
>>> (10ns) in TSOP1 (12mm x 20mm) package. Rest were BGA (shudder
>>> -- not at home). http://www.issi.com/pdf/61WV102416ALL.pdf Nu 
>>> Horizons -- IS61WV102416BLL-10TLI -- INTEGRATED SILICON
>>> SOLUTION -- Memory RoHs  $17.1429 Available in Stock     Region
>>> Order Qty 4031 North America
> 
>>> So I am curious -- why do you want to share the memory on the 
>>> S100 bus? A 386DX would be seriously throttled running memory 
>>> through back plane and the SRAM is ~3.3V (or VDD + 0.2) so you 
>>> would have to make sure 5V never gets to any pin. Same thing
>>> for 386DX, most are 5V. Maybe it would be better to consider
>>> I/O only version -- only thing you would not be able to do is
>>> DMA from drive controller. That way the board can run DMA/RAS
>>> only refresh and use standard 100 Pin SODIMM and maybe fit all
>>> on one board. This board is going to be SMT anyway just to get
>>> everything to fit and at least 4 layers IMHO. Fortunately SMT
>>> rework stations have come down in price and you can use a
>>> toaster oven to do the reflow work. There are profiles floating
>>> around on the web for that -- I was doing it on much simpler
>>> boards at home a few years back. They just look kinda toasty if
>>> you mess up but they still work:-).
> 
>>> If you want some way of transferring large blocks of 
>>> information, you can implement a dual port memory (or FIFO)
>>> that the s100 bus can see and create a driver on 386 side that
>>> treats it like a communication controller. BTW, You are putting
>>> a NIC on this thing, right? Ah, armchair design is so much
>>> easier than doing the real work:-)
> 
>>> You can still run MDOS as you get to write the BIOS and Linux 
>>> may require some driver modifications.
> 
>>> ts
> 
>>> PS: you go to work and see terabyte memory configs, 24+ cores 
>>> using 2 procs, 24 plus HDD in single chassis all day and your 
>>> kinda forget how far we have come in such a short time till
>>> you revisit the past.
> 
> 
>>> On 7/14/2012 8:21 PM, John Monahan wrote:
> 
>>> Guys I've been looking at the newer Static RAM chips.  Some now
>>>  come in standard 72 pin SIMMs.
> 
>>> The 1MX32 and 2MX32 chips from Cypress look like they would go 
>>> good with a 80386. See the attached data sheets.  There are 
>>> separate lines for each 8 bit word so ideal for lines BHE0 - 
>>> BHE3. Decent access times too, 12ns.
> 
> 
> 
>>> Next problem finding where I can get them in low numbers!
> 
> 
> 
>>> I have had no look finding a simple DRAM controller that we 
>>> could easily use in the Megabyte range.
> 
> 
> 
>>> John
> 
> 
> 
>>> John Monahan Ph.D
> 
>>> e-mail: mon...@vitasoft.org
> 
>>> Text:     <mailto:mon...@txt.att.net> mon...@txt.att.net
> 
> 
> 
> 
> 
>>> From: John Monahan [mailto:mon...@vitasoft.org] Sent:
>>> Thursday, July 12, 2012 7:30 PM To:
>>> 'n8vem...@googlegroups.com' Subject: RE: [N8VEM-S100:939] An
>>> 80386 S-100 Board.
> 
> 
> 
>>> So if we used a 16 bit PIC, how would it be setup. Shared RAM 
>>> between the 80386 and PIC, sounds even more complicated.  Am I
>>>  missing something here.
> 
>>> John
> 
> 
> 
> 
> 
>>> From:  John Monahan Ph.D
> 
>>> Chief Scientific Officer
> 
>>> Synthetic Biologics, Inc.
> 
>>> Office: (301) 658-6854
> 
>>> jmon...@syntheticbiologics.com
> 
>>> www.syntheticbiologics.com
> 
>>> NYSE Amex: SYN
> 
> 
> 
>>> From: n8vem...@googlegroups.com 
>>> [mailto:n8vem...@googlegroups.com] On Behalf Of Tom Lafleur 
>>> Sent: Thursday, July 12, 2012 6:24 PM To: 
>>> n8vem...@googlegroups.com; John Monahan Subject: Re: 
>>> [N8VEM-S100:939] An 80386 S-100 Board.
> 
> 
> 
>>> John...
> 
>>> here is a tech note on dram controllers... also, today one can 
>>> get 70mips, 16bit PIC processor, that might be able to do the
>>> job with very little coding??? cost is $6
> 
> 
> 
>>> tom...
> 
>>> On Thu, Jul 12, 2012 at 5:50 PM, John Monahan 
>>> <mon...@vitasoft.org> wrote:
> 
>>> Actually thought of something like that a while back Douglas. I
>>>  don't think one could get it to work with the few address
>>> lines of the Z80, besides if we go DRAM may as well go the full
>>> hog and get massive amounts of RAM on the board and high
>>> speed.
> 
> 
> 
>>> Was even thinking of some kind of primitive cascade counter,
>>> but I suspect that it would not be that simple, else why are
>>> there DRAM controllers!
> 
> 
> 
>>> John
> 
> 
> 
> 
> 
> 
> 
>>> From:  John Monahan Ph.D
> 
>>> Chief Scientific Officer
> 
>>> Synthetic Biologics, Inc.
> 
>>> Office: (301) 658-6854 <tel:%28301%29%20658-6854>
> 
>>> jmon...@syntheticbiologics.com
> 
>>> www.syntheticbiologics.com
> 
>>> NYSE Amex: SYN
> 
> 
> 
>>> From: n8vem...@googlegroups.com 
>>> [mailto:n8vem...@googlegroups.com] On Behalf Of Douglas
>>> Goodall Sent: Thursday, July 12, 2012 5:14 PM To: 
>>> n8vem...@googlegroups.com Subject: Re: [N8VEM-S100:936] An 
>>> 80386 S-100 Board.
> 
> 
> 
>>> John,
> 
> 
> 
>>> I know it's a silly idea, but the Z-80 has a built in dynamic 
>>> ram refresh.
> 
> 
> 
>>> But you would probably want to run the 80386 faster than
>>> 20MHz.
> 
> 
> 
>>> Just an idea.....
> 
> 
> 
> 
> 
>>> Douglas
> 
> 
> 
> 
> 
> 
> 
>>> On Jul 12, 2012, at 11:06 AM, John Monahan wrote:
> 
> 
> 
>>> Thanks for excellent suggestions Andrew.  I have been reading 
>>> the Intel manuals a few times now. I do a lot of plane travel
>>> and often bring it along!  Their manuals are excellent. There
>>> is a corresponding software and operating system writers manual
>>> as well. BTW, as well, I found the "The Intel Microprocessors"
>>> book by Barry B. Brey to be outstanding.  There are numerous
>>> editions. The best I have is the 7th edition.  Easily obtained
>>> from Amazon. Recommend it for anybody using hardware with these
>>> chips. Goes all the way up to Pentium BTW.  My only criticism
>>> was the 80286 was lightly done. 80386/80486 <tel:80386%2F80486>
>>> much better.
> 
> 
> 
>>> OK back to S-100 board.  This is a major undertaking (at least 
>>> for me).  I have been oscillating between the 80386 or jumping 
>>> over right to the 80486. The latter has one big advantage in
>>> the it can accommodate an 8,16 or 32 bit bus dynamically.  This
>>> for example means you need only one boot PROM and even old
>>> S-100 boards (in theory) could be used, not that you would
>>> normally use the latter much!  However the step from 80286 to
>>> 80386 is a bit bigger in terms of hammering signals into S-100
>>> shape.
> 
> 
> 
>>> There is now doubt we will need two boards. In fact with two 
>>> boards there is no reason why the CPU cannot run at its normal 
>>> max clock speed with its local memory . Only when we go to the 
>>> tiny amount or RAM (relatively speaking) on the S-100 bus
>>> would we insert 20-30, whatever, wait states or slow the CPU
>>> clock down dramatically.  The S-100 bus could even be
>>> configured possibly as a kind of reverse/slow RAM cash!
> 
> 
> 
>>> However I'm still stuck with how to dynamically refresh the
>>> DRAM Simms. The problem is that unlike the typical Intel single
>>> CPU examples in our case we have potentially a multiprocessor
>>> bus setup.  At times the CPU would be in a dormant/reset state.
>>> The good news is the only shared RAM would other CPU's (a 68K
>>> for example),  would be the S-100 Static RAM.
> 
> 
> 
>>> What I would like to find is a circuit that has self-contained 
>>> DRAM refresh for 1GB or DRAM (or pseudo-static RAM) circuit.
> 
> 
> 
>>> While on RAM, what is the most dense (commonly available) SMT 
>>> static RAM chips people have seen.  The best I have seen so
>>> far is 2MX8 IS61WV20488ALL (Jameco #1862446), a long way from
>>> 1GB!
> 
> 
> 
>>> Suggestions welcome
> 
>>> John
> 
> 
> 
> 
> 
> 
> 
> 
> 
>>> From:  John Monahan Ph.D
> 
>>> e-mail: mon...@vitasoft.org
> 
>>> Text:     <mailto:mon...@txt.att.net> mon...@txt.att.net
> 
> 
> 
>>> From: n8vem...@googlegroups.com 
>>> [mailto:n8vem...@googlegroups.com] On Behalf Of Andrew Lynch
>>>  Sent: Thursday, July 12, 2012 7:16 AM To: 
>>> n8vem...@googlegroups.com Subject: RE: [N8VEM-S100:927] An 
>>> 80386 S-100 Board.
> 
> 
> 
>>> Hi!  Please take a look at this documentation for an S-100 
>>> 80386DX board that's capable of running a "sophisticated" 
>>> operating system like Linux or NetBSD:
> 
> 
> 
>>> http://bitsavers.org/pdf/intel/_dataBooks/1987_80386_Hardware_Reference_Manu
>
>>> 
>>> 
> 
>> al.pdf
> 
> 
> 
>>> I agree the "over the top" daughter board may be necessary for 
>>> all the components.  I suggest we place all the CPU and bus 
>>> control logic on the main CPU board and use a pair of the
>>> newer 40 pin (80 wire) IDE connectors to export all the memory
>>> and its interface logic to another board.
> 
> 
> 
>>> In the Intel 80386 Hardware Reference Manual there are circuits
>>>  for interfacing EPROM and DRAM chips.  I recommend using the
>>> 72 pin DRAM SIMMs since they are "regular" DRAM chips packed on
>>> to mini circuit boards and use the same interface as a regular
>>> DRAM chip. The key for exporting a memory board will be to have
>>> many solid ground connections between the processor and the
>>> memory board so we'll need to keep them close or just make a
>>> double thick S-100 board using a mezzanine connector like we
>>> did on the S-100 System Monitor Board.  If we maximize the full
>>> space available it would give us approximately 100 square
>>> inches of PCB space minus the usual ~10 square inches of S-100
>>> overhead for voltage regulators, filter capacitors, mezzanine
>>> connectors, brackets, mounting holes, clearance margins, etc.
> 
> 
> 
>>> The main benefit of using the 80386DX is that it meets the 
>>> minimum criteria for a "sophisticated" operating system like 
>>> NetBSD or Linux which are both essentially SysV/BSD Un*x 
>>> derivatives/mutants. AFAIK the minimum requirement is a 32 bit 
>>> ISA and an MMU with enough address space to hold a rather
>>> large kernel and associated components.
> 
> 
> 
>>> The memory 16MB addressing limit of the S-100 bus would be 
>>> possible in theory to hold Linux or NetBSD but would be
>>> extremely limiting in my opinion unless we were seeking a mini
>>> Linux like Freesco.  We should strive for as large a memory
>>> space as possible and I believe 256MB (28 address lines) is a
>>> realistic goal using a pair of 128MB DRAM SIMMs.  However, this
>>> would require at least 24 true address lines being multiplexed
>>> to DRAM A0-A11 and 8 individual separate CASx/RASx pairs.  To
>>> get the density we will need, I think DRAM is the only
>>> realistic option without resorting to hobbyist unfriendly large
>>> SMT devices.  Also we can add a pair of 27C1024 16-bit EPROMs
>>> for a full 32 bit data path to the boot ROMs.
> 
> 
> 
>>> This is an enormous project and I recommend starting with a 
>>> relatively low CPU speed like 4 MHz as a starting point.  Once 
>>> the basic hardware is working identify the bottlenecks one at
>>> a time and gradually increase the clock speed.  John is well 
>>> familiar with this technique since all the CPU boards to date 
>>> have gone down that path.
> 
> 
> 
>>> Thanks and have a nice day!
> 
>>> Andrew Lynch
> 
> 
> 
>>> From: n8vem...@googlegroups.com 
>>> [mailto:n8vem...@googlegroups.com] On Behalf Of John Monahan
>>>  Sent: Wednesday, July 11, 2012 1:12 AM To: 
>>> n8vem...@googlegroups.com Subject: [N8VEM-S100:914] An 80386
>>>  S-100 Board.
> 
> 
> 
>>> Hi guys. Having just finished our 80286 S-100 master/slave
>>> S-100 board, see here:-
> 
> 
> 
>>> http://s100computers.com/My%20System%20Pages/80286%20Board/80286%20CPU%20Boa
>
>>> 
>>> 
> 
>> rd.htm
> 
> 
> 
>>> I am thinking how to do the 80386 S-100 board.    In a sense 
>>> it's easier from a hardware perspective  since the jump from
>>> 8086 to 80286 in more than 80286 to 80386.    As we know the
>>> 80286 is really just a fast 8086 (and was used as such).
> 
> 
> 
>>> The 80386 really was a new breed and could run some decent 
>>> software.  That is why I would like to make a new S-100 board.
>>>  Since the 80386 has a 16 bit access pin it's easy to have it 
>>> address the low RAM on the S-100 bus. It would behave like the
>>>  80286.  However to take advantage of the 32 bit data bus and 
>>> address lines I'm thinking of having a daughter board with an 
>>> over the top connecting cable for all that extra RAM capacity.
> 
> 
> 
>>> The question is; should I use static RAM or DRAM.   Static RAM 
>>> is easy to interface, but even with SMT chips lower capacity. 
>>> With DRAM SIMMS we could have a decent Linux going.
> 
>>> My question to this group is does anybody have a suggestion
>>> for a good refresh controller chip/circuit.  It's particularly 
>>> tricky because sometimes the CPU will not have access to the
>>> bus and will be held in its reset state,  (Another CPU is
>>> running the S-100 Bus).   Alternatively anybody know about
>>> "Pseudo Static RAM" chips. Apparently these are self-contained
>>> with their own internal refresh. Don't know how they are
>>> accessed.
> 
> 
> 
>>> Any suggestions/directions...
> 
>>> John
> 
> 
> 
>>> ---
> 
>>> Douglas Goodall
> 
>>> Santa Maria, CA
> 
>>> www.goodall.com
> 
> 
> 
>>> "Even a blind pig finds a truffle now and then" oink oink!!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQA0asAAoJEA7EcEr0emgf37YIAIDjYqketw/f9PeW/CONq3yY
Xi1bxSh4v0aJzOxtXYh+QVPOsftDo8l87I42eo1fZcvRAGLAq/Gph5HeytlYQ/iV
cc4J2uyoa6a8Ryoifo/S1L1TPQSqw4vHpQ2pc/lrffe9I7513nGlySChg+8MA6vK
1c3CIeO907TdhMSG1gff3jWNmWjv+b79UD9BUAZQClBP8KoLXpvr49C7bx3qCqAN
jcqUzMkiP0XDqjc5oraadFZ3uyHvxDD/NzFX1vM9kpdHJRb0yFZriMjYdvhjDKJZ
lKJgu3IiS/j7STOE0PPsbLz3882nwJBq6TC4/NpSSAPel8MzHGpDr5Nj4f0/Eww=
=B3ZK
-----END PGP SIGNATURE-----