[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [N8VEM-S100:956] An 80386 S-100 Board.
Thanks Mike would not have a hope of getting that 82443BX working! Way too
complex for me.
I think the BGA socket ones would be too hard for most people to use. Have
not done the toaster oven approach yet!
The DP8421 however does look interesting. Also it?s a PLCC chip. One chip
per 16M is not great. There is a later DP8430 as well. Not clear what the
difference is.
I think we are on the right track however. Know of other simple DRAM
controllers that could service even more RAM. The later Intel Bridge
things are just too complicated/overkill.
John
John Monahan Ph.D
e-mail: mon...@vitasoft.org
Text: mon...@txt.att.net
-----Original Message-----
From: n8vem...@googlegroups.com [mailto:n8vem...@googlegroups.com] On
Behalf Of mike
Sent: Sunday, July 15, 2012 3:59 PM
To: n8vem...@googlegroups.com
Subject: Re: [N8VEM-S100:956] An 80386 S-100 Board.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Okay, now I have it all sorted out.
Here is the datasgheet for the 82443BX that contains among other things, a
DRAM controller that supports up to 512MB or 1GB with registered DIMMs).
These seem to still have an okay availability for an obsolete part.
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-C
> ontroller-Miscellaneous-/110887357440?pt=LH_DefaultDomain_0&hash=item1
> 9d166cc00#ht_2311wt_819
>
>
> http://www.ebay.com/itm/INTEL-FW82443BX-440BX-AGPset-Host-Bridge-Contr
> oller-BGA-/160629103858?pt=LH_DefaultDomain_0&hash=item25663d9cf2#ht_5
> 20wt_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-mic
>> roCMOS-Programmable-256k-1M-4M-/120921409478?pt=LH_DefaultDomain_0&ha
>> sh=item1c277a47c6#ht_2311wt_819
>
>>
>
>> http://www.ebay.com/itm/DP8421AV-Integrated-Circuit-x-1-pieces-/40030
>> 8222341?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item5d343ab9
>> 85#ht_4722wt_1202
>
>>
>
>> http://www.ebay.com/itm/DP8421AV-20-Integrated-Circuit-x-1-pieces-/16
>> 0838807571?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item2572b
>> d7013#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/
iQEcBAEBAgAGBQJQA0stAAoJEA7EcEr0emgf228IALBjG+RJy3ShgYwkjo6OYDB2
wgAQykIGSRm+DAWIWfnnlYuwL5eoCg6poApBhTz2/7Ygu4INOI9k35FoSV0Wtr/X
1Eh843z2QXyoFoc/09j3RiT0XI6Ir0LNTtHDvmirmee45Lvf1CTRhMCKPTnZWyfh
v3qd9uejmg48lvjgk4C1TVGLX3GpKQmbv9Y+63wuZ+SSTdy5PZ0LUbuSsE/R9+tN
a2E6ELCqCNGFYTWgO25DvMDNQfCQvLH6v0KW87013YQsCv0EeM1s1CMxui5qoXBE
1A0ZiJl15j2BrZh1HpXCUxg82CWLt6LXJCV1mogUQWfNBSvO8eZ4O8FoRRbarwU=
=z/zk
-----END PGP SIGNATURE-----