Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!mips!daver!bungi.com!news
Newsgroups: comp.sys.nsc.32k
Subject: Re: Now, where was I?
Message-ID: <9012190216.AA24118@virtech.UUCP>
Date: 19 Dec 90 02:16:15 GMT
References: <<9012072303.AA23483@maxzilla.>>
Sender: news@daver.bungi.com
Lines: 89
Approved: news@daver.bungi.com

My 2 cents:

> Speaking of floppy controllers that I ran out of gas on...
> 
> I've been thoroughly swamped for the past six months, and I've only
> just this week resumed fooling around with my pc532. With any luck I'll
> have Minix up in a week or so, and then catch up on pc532 mail, and then...
> 
> ...maybe get back to work on the floppy controller? I've noticed a few
> messages about folks wanting to attach devices via the DUART sockets;
> this tells me we have a REAL problem. George, I have no intention of
> restarting the "bus wars" discussion of a year ago, but clearly people
> are finding it difficult to hang devices off the pc532. Let's face it:
> a raw uprocessor bus is really easy to attach stuff to, and SCSI isn't.
> What _I_ think we need is a nice generic coprocessor card design that
> DOES have a simple bus; conceivably this card could run a stripped down
> version of Minix.
> 
> My original idea for the floppy controller was:
> 
> - some micoprocessor with at least 2 DMA channels (one for SCSI, one for
>   anything else)
> - DP8490 SCSI interface chip
> - DP8473 floppy disk controller
> - some static ram
> - some EPROM
> - a serial port (optional, but nice to have to talk to ROM monitor)
> - a parallel port (cause everyone wanted one)
> - some DRAM (I'd drop this now, since SRAM has gotten so cheap and is SO easy)
> 
> By dropping the DRAM I'm sure I could design this. The tricky part may well
> be the sofware. Anyway, this could easily be used as a "generic" pc532
> peripheral interface card.
> 
> The piece that I never resolved was the processor. Some possibilities:
> 
> - HD64180 (or Z180): has DMA and serial channels on-chip, but basically
>   a dull, obsolete part (64K address space with simple MMU).

But fast enough if programmed in assembler.

> - 68070 (or some newer Moto part?): has DMA and serial on-chip, but
>   kinda pricy, also a 16 bit bus (8 bit is easier, though I am lately
>   thinking 16 is OK)

Too pricey, and all new tools needed.

> - 80188/80186/V50/whatever: plenty of on-chip peripherals, but that
>   $#@ Intel architecture
> 
> - NS32CG160: 2 DMA channels, on-chip interrupt control unit. Biggest
>   plus, in my mind, is instruction set compatibility with pc532, so we
>   all have the development tools already. Pricy, near as I can tell...

CG160?  I suspect you mean the GX320.  A very neat part.  What price can
we get on it?

> - Other?

TMS-320C25 - and leave out the FDC? :-)

> With any luck I'll restart this project in January. What do you folks out
> there want for the processor? Any other design ideas?
> 
> -- Jerry Callen
>    jcallen@encore.com

I don't think you want this processor to run Minix.  I think what you want is
some pretty mammoth caching.  Now, are we going to use the floppy as a random-
access device, or as a stream device (e.g. for zoo or cpio)?  I prefer the
latter, floppies are for backup.  If this is the case, then buffering two
tracks is nice.  As one track gets laid down with a multisector write, the
second fills in the buffer.  Then the head steps and, without missing a beat,
the next track begins writing.  (You have the trailer gap and the pre-first-
sector gap to set up.)

Actually, I don't think DMA is necessary if you have an 8MHz Z-80.

Let's design this board so it can write as fast as formatting.  Or faster.

Now, with track writes you still have to format.  Neither the WD chips nor
the NEC chips (of which National's is a derivative) have the capability of
writing while formatting.  The DSP chip (you thought I wasn't serious?)
could do everything in one swell foop, but needs fast memory.

Jump to the other approach.  Minix tends to use floppies as mounted file
systems rather than stream devices.  If this is done, then the controller
could cache the superblock and inodes and then use LRU buffers for the
others.  But it won't be fast, alas.