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

[Paul Birkel <pbi...@gmail.com>]

Regarding the dormant-state issue on a multiprocessor bus, couldn't
the self-refresh mode of something like
http://download.micron.com/pdf/datasheets/dram/sdram/128MbSDRAMx32.pdf
be employed?

-----
The SELF REFRESH command can be used to retain data in the SDRAM, even
if the rest of the system is powered down. When in the self refresh
mode, the SDRAM retains data without external clocking. The SELF
REFRESH command is initiated like an AUTO REFRESH command except CKE
is disabled (LOW). Once the SELF REFRESH command is registered, all
the inputs to the SDRAM become “Don’t Care” with the exception of CKE,
which must remain LOW.

Once self refresh mode is engaged, the SDRAM provides its own internal
clocking, causing it to perform its own auto refresh cycles. The SDRAM
must remain in self refresh mode for a minimum period equal to tRAS
and may remain in self refresh mode for an indefinite period beyond
that.

The procedure for exiting self refresh requires a sequence of
commands. First, CLK must be stable (stable clock is defined as a
signal cycling within timing constraints specified for the clock pin)
prior to CKE going back HIGH. Once CKE is HIGH, the SDRAM must have
NOP commands issued (a minimum of two clocks) for tXSR because time is
required for the completion of any internal refresh in progress.

Upon exiting SELF REFRESH mode, AUTO REFRESH commands must be issued
every 15.625μs or less as both SELF REFRESH and AUTO REFRESH utilize
the row refresh counter.
-----

On Thu, Jul 12, 2012 at 2:06 PM, John Monahan <mon...@vitasoft.org> 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 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:    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_Manual.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%20Board.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
>
>