From "george@wombat (George Scolaro)" Tue Jan  2 01:29:11 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Mon, 1 Jan 90 20:29:07 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Mon, 1 Jan 90 20:29:03 EST
Received: by mips.com (5.61.14/1.11) id AA11407; Mon, 1 Jan 90 17:28:52 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gibjI-00008wC@daver.uu.net>; Mon, 1 Jan 90 15:46 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <wombat!george>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gibjD-0000mHC@daver.uu.net>; Mon, 1 Jan 90 15:46 PST
Received: by wombat.UUCP (smail2.5)
	id AA02275; 1 Jan 90 15:30:32 PST (Mon)
From: george@wombat (George Scolaro)
Date: Mon, 1 Jan 90 15:30:32 PST
In-Reply-To: Bruce Culbertson's message on Dec 27, 13:17.
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Subject: Re:  "Dreaded" 32203 DMAC?
Message-Id: <9001011530.AA02275@wombat.UUCP>
Status: RO

Well hi everyone.

Dave & I are back from our holidays in Canada. A major stumbling block
occured (after we had already left!!!!). The PCB house decided that they
wanted a cheque for 1/2 the value in advance. Unfortunately we couldn't
comply with this requirement since we were already in Canada, so it appears
that the PCB date will slip till the end of January (unless I can convince
them to do it on the agreed date, ie faster). I will talk with them tomorrow
(2nd of Jan) and see what can be done since the mistake is theirs, I did ask
if they wanted any up front money and I was told by the salesman I'm dealing
with that it was not required. Of course the moment we left the story
changed.... we'll see.

[In the message entitled "Re:  "Dreaded" 32203 DMAC?" on Dec 27, 13:17, Bruce Culbertson writes:]
> > Why do Dave and George refer to the 32203 as the "dreaded" 32203? I've
> > been looking at the data sheet and I don't see anything TOO horrible yet.
> 
> I can give you some information since I have used the 32203 in my
> 32016 system.
> 
> I maintain that the 32203 is a pretty good choice for the 32016 and a bad
> choice for the 32532.

Well, the fact of life is that NS does not really want people to use the
32203 DMAC. This may not be the external view, but certainly within NS the
32203 is really treated as 'not for new designs'. Other than only really
being suitable for the 32016 (or 32cg16), it runs to 10Mhz max. Now, the
32cg16 is probably the cheapest of the 32k series CPU's a) 'cos NS is
selling heaps to laser printer companies (eg Canon) b) it doesn't have any
MMU capability and therefore is targeted for non-unix (ie cheaper) systems.
The best part is that the TCU (32201) functionality is on-chip. NS always
had trouble getting the 32201 to talk well with the 32016/32 etc, mainly due
to the tight PHI1 PHI2 non-overlap times etc. This whole problem goes away
with the 32cg16 (it's all on-chip). So, I'd recommend using the 32cg16 as
the generic 32k CPU of choice for add-on cards (that don't require 532
grunt). The only advantage of the 32203 is that it requires next to no glue
logic to connect to the 32cg16, but only at 10mhz max. There is no real way
to connect a 10mhz 32203 to a 15mhz 32cg16. The better solution I feel is to
use the hitachi 71071 DMAC which is a clone (improved clone that is) of the
8237 (PC DMAC) but with 24 bit addressing, and up to 8mhz speed. It can be
run at a different rate than the CPU, ie 15mhz 32cg16 and 7.5mhz DMAC. I
have used the hitachi part and it seems to work well (its also CMOS, unlike
the 32203) and has 4 channels, instead of 2. The program model is pretty
well exactly like the 8237 except for the 24 bit extensions etc. It does
of course require more external glue (a latch, maybe 1 pal etc).

Also, while I'm at it, if you use the 32cg16 (please do), then the
32cg821V-20 or -25 is the better DRAM controller to choose. It bolts onto
the 32cg16 very cleanly (no external pals etc, compared to the dp849x) and
has faster timing (and is CMOS). The 32cg821 is a dp8421 without all the
unnecessary features (ie its cheaper). Of course, the other way is to do
a discrete DRAM controller which really is quite easy, a would have better
timing characteristics that the VLSI DRAM controller. The tradeoff is
complexity and parts count versus better performance (of course 80ns DRAMs
are just about as cheap at 120ns ones these days). The discrete DRAM
controller would probably be easier to interface the 71071 to, than the
32cg821 (just a gut feeling).

Bruce is right on the 532/203 issue, the 32203 would definitely bog a 532
right down besides not supporting the 32 bit data bus etc, ie no byte
gathering capability... real tricky that! (unless the peripheral is 32 bits).
And we haven't even mentioned the memory interface nightmare.

This bit is just some daydreaming....

I have looked a bit at using the 32cg16 as a peripheral CPU, but without
DMA, ie use the 32cg16 to do the data moving. This really only works well
if the DMA rate is fast enough that the cg can sit in a tight loop. Using
a MOVSD instruction with some external hardware to route the byte into a
holding latch (ie byte gather to 16 bits) you could read data at a couple
of megabytes per second.

The other thing to do, is wait a few more months for NS to release a newer
wizzier 32k [really] embedded CPU.... enough said, sssshhh!

best regards,

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From "dlr@daver.uu.net (Dave Rand)" Wed Jan  3 08:40:29 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Wed, 3 Jan 90 03:40:27 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Wed, 3 Jan 90 03:40:24 EST
Received: by mips.com (5.61.14/1.11) id AA16211; Wed, 3 Jan 90 00:40:18 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gj23z-0000mVC@daver.uu.net>; Tue, 2 Jan 90 19:53 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <dlr>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gj23t-0000BYC@daver.uu.net>; Tue, 2 Jan 90 19:53 PST
Message-Id: <m0gj23t-0000BYC@daver.uu.net>
Date: Tue, 2 Jan 90 19:53 PST
From: dlr@daver.uu.net (Dave Rand)
To: pc532@daver.uu.net
Subject: PCB Update
Status: RO

George talked to the PCB house today - they have in fact started the boards,
and do not anticipate any delay, even though we have not given them the
deposit. The fab house (West Coast Circuits) is being quite reasonable,
the want a 50% deposit up front, and the balance on delivery. It is
unfortunate that they did not tell us this in advance, but as it turned
out there will be no problem (so we are told).

I have mailed a number of individual confirmations of receipt of your
cheques - a global thanks to those that have!

Dave Rand / George Scolaro


From "John L. Connin <johnc%manatee%uunet@daver>" Thu Jan  4 06:07:41 1990
Flags: 000000000001
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Thu, 4 Jan 90 01:07:33 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Thu, 4 Jan 90 01:07:26 EST
Received: by mips.com (5.61.14/1.11) id AA17100; Wed, 3 Jan 90 22:04:50 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gjPl5-0000AlC@daver.uu.net>; Wed, 3 Jan 90 21:11 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!tarpit!manatee!johnc>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gjPky-0000BbC@daver.uu.net>; Wed, 3 Jan 90 21:11 PST
Received: from tarpit.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA29646; Wed, 3 Jan 90 17:55:43 -0500
Message-Id: <9001032255.AA29646@uunet.uu.net>
Received: by tarpit.UUCP (smail2.5)
	id AA09116; 3 Jan 90 17:41:24 EST (Wed)
Subject: pc532 Build List
To: pc532%tarpit@daver.uu.NET
Date: Wed, 3 Jan 90 17:34:16 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]
Status: RO


Attached is the start of a "pc532 Build List" which I have passed by
George and Dave.

The idea is to provide a vehicle by which pc532 builders can exchange
construction information in a moderated fashion.   Simply feed me
information related to parts, construction tips, etc.  I will then
incorporate this information and post to the pc532 mailing list a
revised "pc532 Build List" from time to time.

Your on-going contributions are needed for this to work.


Best regards
johnc                           tarpit!manatee!johnc


----------------------------------------------------------------------------------------------------------------

                        pc532 Build List

        Parts List Revision :  1.0
        Date                :  3 jan 90
        BOM reference       :  Version 1D
        Contact             :  J.L. Connin     tarpit!manatee!johnc


        Table of Contents   :
                1.0  Introduction
                1.1  Notes / History
                1.2  Legend
                1.3  Supplier Names and Addresses
                2.0  Bill of Materials
                2.1  BOM pc532
                2.2  BOM - Ancilary Items
                3.0  Construction Notes

----------------------------------------------------------------------------------------------------------------

1.0  Introduction
-----------------

    The intent of the Build List is provide an resource of information
    related to the physical construction of the pc532 (ie. sources of
    supply, construction hints, etc).

    Very simply, from time to time, I will post to the pc532 mailing list
    an updated copy of the Build List based upon input I receive from YOU,
    the pc532 members.


1.1  Notes / Revisions:
-----------------------
    1)  johnc, 22jan89, received version 1D BOM (ie. pcb fab release) from george.
    2)  johnc, 22dec89, started ancilary BOM section


1.2  Legend:
-----------

    *  -  Included in pc532 kit

    All other parts (ie. those not prefixed by '*') are user supplied.

    Source of supply of user supplied parts, were known, is indicated
    immediately after the part description in the BOM.  The source of
    supply fields, from left to right are:  Distributor, catalog page
    number, distributor part number, and part price.  For example,

        JDR,            page85,         NOSLOT-CLK      29.95


1.3  Supplier Names and Addresses:
---------------------------------

        Distributor     Reference               Minimum         Telephone
        -----------     ------------            -------         ----------------
        JDR             1990 Catalog,                           1-800-538-5000
        Jameco          1990 Catalog,           $25.00          1-415-592-8097
        Digi-key        Nov-Dec89                               1-800-344-4539

        Arrow Elec.                             $25.00          1-800-932-7769
        Allied Elec.                            $25.00          1-800-433-5700

Where possible, your local surplus outlets are probably your best
source of supply.



2.0  Bill of Materials
----------------------

---------------------------------------------------------------------------------------------------
2.1  BILL OF MATERIALS     32532 AT MOTHERBOARD        V 1D Thu Dec 21 23:25:07 1989    PAGE   1
---------------------------------------------------------------------------------------------------


     ITEM   QUAN.               DESCRIPTION                                         REF. DES.        

       1      69	CAPACITOR,0.1, 0.3inch spacing, Monolithic Bypass           C1,C10,C11,C12  
                                                                                    C13,C14,C15,C16
                                                                                    C17,C18,C19,C2
                                                                                    C20,C21,C22,C25
                                                                                    C26,C27,C28,C29
                                                                                    C3,C30,C31,C32
                                                                                    C33,C34,C35,C36
                                                                                    C37,C38,C39,C4
                                                                                    C40,C41,C42,C43
                                                                                    C44,C45,C46,C48
                                                                                    C49,C5,C50,C51
                                                                                    C52,C53,C54,C55
                                                                                    C56,C57,C58,C6
                                                                                    C61,C62,C63,C64
                                                                                    C65,C66,C69,C7
                                                                                    C70,C71,C72,C73
                                                                                    C74,C76,C78,C8
                                                                                    C9

       2       1	CAPACITOR,10PF,                                             C75             

       3       4	CAPACITOR,10UF,25V                                          C59,C60,C67,C68 

       4       1	CAPACITOR,33UF,16V                                          C47             

*      5       2	CAPACITOR,50PF,                                             C23,C24         

       6       1	CAPACITOR,5PF,                                              C77             

*      7       1	CRYSTAL, 3.6864MHZ                                          XTAL1           

       8       1	DIODE, IN4148                                               D2              

       9       2	DIODE, IN5817 (SCSI DIODE, Schottky)                        D1,D3           

      10       4	LIGHT EMITTING DIODE, (0.1 inch centers, end stackable)     LED1,LED2,LED3  
                                                                                    LED4

*     11       1	RESISTOR PACK,1K, 6 pin SIP, 5 common resistors             RES1            

      12       1	RESISTOR,100, 1/4W, 5%                                      R2              

      13       3	RESISTOR,10K, 1/4W, 5%                                      R1,R4,R5        

*     14       2	FUSE, 1 Amp Pico Fuse for SCSI                              F1,F2           

      15       1	RESISTOR,1K, 1/4W, 5%                                       R6              

*     16       6	RESISTOR,22, 8 pin Sip, 4 separate resistors                RES2,RES5,RES6


---------------------------------------------------------------------------------------------------
BILL OF MATERIALS       32532 AT MOTHERBOARD        V 1D Thu Dec 21 23:25:07 1989    PAGE   2
---------------------------------------------------------------------------------------------------


     ITEM   QUAN.    	DESCRIPTION                                        	    REF. DES.        

                                                                                    RES7,RES8,RES9

*     17       2	RESISTOR,220, 8 pin Sip, 4 separate resistors               RES15,RES16     

*     18       4	RESISTOR,47, 8 pin Sip, 4 separate resistors                RES10,RES11,RES3
                                                                                    RES4

*     19       1	RESISTOR,4K7, 16 pin Dip, 15 common resistors               RES13           

      20       2	RESISTOR,???, BCLK, /BCLK terminator (TBD)                  R3,R7           

      21       1	74AS00 - AS TTL QUAD TWO INPUT NAND                         U30             

      22       1	74ALS14 - ALS TTL HEX INVERTER WITH SCHMITT TRIGGER         U42             

      23       1	74AS32 - AS TTL QUAD 2 INPUT OR GATE                        U58             

*     24       4	SCSI62 - THE 62 PIN IBM PC/AT BUS CONNECTOR                 CONN12,CONN13   
                                                                                    CONN14,CONN15

      25       2	74AS74 - AS TTL DUAL D FLIP-FLOP                            U31,U32         

      26       1	74F138 - FAST TTL 3/8 DECODER                               U33             

      27       2	74AS174 - AS TTL HEX D FLIP-FLOP                            U26,U50         

      28       3	74AS258 - AS TTL QUAD 2 TO 1 MUX, INVERTED TS OUTPUT        U27,U28,U29     

      29       4	74AS280 - AS TTL 9-BIT PARITY GEN/CHK                       U1,U2,U3,U4     

      30       1	74AS374 - AS TTL OCTAL FLIP-FLOP WITH TS OUTPUT             U16             

      31       1	74AS646 - AS TTL OCTAL REGISTERED/TRANS WITH TS OUT         U43             

      32       4	74AS1004A - AS TTL HEX INVERTING DRIVER                     U17,U21,U22,U5  

      33       1	74ALS1034A - ALS TTL HEX NON-INVERTING DRIVER               U45             

      34       2	74AS1034A - AS TTL HEX NON-INVERTING DRIVER                 U18,U23         

*     35       4	2681/2692 - DUAL CHANNEL DUART                              U48,U52,U55,U60 

*     36       1	74ALS6311 - STATIC COLUMN/PAGE MODE ACCESS DETECTOR         U36             

*     37       4	220/330 OHM 14 PIN DIP TERMINATOR                           RES12,RES14     
                                                                                    RES17,RES18
      ----------------------------------------------------------------------------------------------

      38       1        XTALM - CRYSTAL OSCILLATOR MODULE, 50Mhz                    U25             

        (TTL Crystal Clock Oscillator)
        Digikey,        page61,         x121,           6.19


---------------------------------------------------------------------------------------------------
BILL OF MATERIALS       32532 AT MOTHERBOARD        V 1D Thu Dec 21 23:25:07 1989    PAGE   3
---------------------------------------------------------------------------------------------------


     ITEM   QUAN.               DESCRIPTION                                         REF. DES.        

 *    39       1	27256 - UV ERASABLE PROM 32KX8, 200 ns                      U44             

      40       8	MSC411024 -  1M X 9 BIT DYNAMIC RAM MODULE                  U10,U11,U12,U13 
				  OR 1M X 8 (FOR NO PARITY), FAST PAGE 80 ns        U6,U7,U8,U9
				  Toshiba part # THM81000AS-80 (1M X 8)
			4 SIMMs are the minimum configuration

 *    41       2	PAL16L8 - PROGRAM ARRAY LOGIC, B - SPEED,                   U37,U40         

 *    42       1	PAL16R6 - PROGRAM ARRAY LOGIC, B - SPEED,                   U38             

 *    43       1	PAL16R8 - PROGRAM ARRAY LOGIC, D - SPEED,                   U39             

 *    44       1	PAL20L8 - PROGRAM ARRAY LOGIC, D - SPEED,                   U19             

 *    45       1	20V8A-CMOS-GAL-15ns ELECTRICALLY ERASABLE                   U20             

 *    46       1	32202 - 32000 INTERRUPT CONTROL UNIT, 10Mhz                 U46

 *    47       1	32532 - 32000 SERIES HIGH PERF.  32 BIT BUS CPU, 25Mhz      U35

 *    48       1	32381 - 32000 SERIES 32 BIT BUS FPU, 25Mhz                     U24

      49       1	JUMP1 - SINGLE JUMPER HEADER                                J3              

      50       2	JUMP3 - 3 PIN JUMPER                                        J1,J2           

      51       1	JUMP4 - 4 LOCATION JUMPER BLOCK                             CONN2           

      52       1	CRYSTAL OSCILLATOR MODULE, 20MHZ                            U34             

*     53       2	74AS832 - HEX 2 INPUT OR DRIVERS                            U14,U15         

*     54       1	AIC6250 - HIGH PERFORMANCE SCSI PROTOCOL CHIP               U41             

      55       2	50 WAY TRANSITION CONNECTOR UNSHROUDED (JUST PINS)          CONN1,CONN16    

*     56       1	DP8490 - ENHANCED ASYNCHRONOUS SCSI INTERFACE (EASI)        U57             
				  44 pin PLCC package

*     57       1	IBMPOW - IBM AT POWER CONNECTOR                             CONN11          

      58       8	JUMP10 - 10 WAY JUMPER BLOCK UNSHROUDED (JUST PINS)         CONN10,CONN3    
                                                                                    CONN4,CONN5
                                                                                    CONN6,CONN7
                                                                                    CONN8,CONN9

*     59       8	MC145406 - HEX RS232 CMOS TRANSCEIVER                       U47,U49,U51,U53 
                                                                                    U54,U56,U59,U61

--

----------------------------------------------------------------------------------------------------------------
2.2  BILL OF MATERIALS    32532 AT BOARD
     ANCILLARY ITEMS
----------------------------------------------------------------------------------------------------------------

*      1       5                44 pin PLCC sockets (for scsi and duarts)

*      2       1                68 pin PLCC sockets (for AIC-6250)

*      3       1                175 pin PGA socket (for 32532 CPU)

*      4       1                68 pin PGA socket (for 32381 FPU)

*      5       8                30 pin sockets (for unleaded SIMM memory modules)

       ------------------------------------------------------------------------------------------------------

       6       1                NO-SLOT CLOCK
        JDR,            page85,         NOSLOT-CLK      29.95

       ------------------------------------------------------------------------------------------------------

       7

       ------------------------------------------------------------------------------------------------------

       8

       ------------------------------------------------------------------------------------------------------

       9

       ------------------------------------------------------------------------------------------------------

      10

       ------------------------------------------------------------------------------------------------------



3.0  Construction Notes.
------------------------




From "dlr@daver.uu.net (Dave Rand)" Thu Jan  4 21:17:00 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Thu, 4 Jan 90 16:16:50 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Thu, 4 Jan 90 16:16:33 EST
Received: by mips.com (5.61.14/1.11) id AA06665; Thu, 4 Jan 90 13:14:17 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gjda4-0000CKC@daver.uu.net>; Thu, 4 Jan 90 11:57 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <dlr>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gjdZx-0000EzC@daver.uu.net>; Thu, 4 Jan 90 11:56 PST
Message-Id: <m0gjdZx-0000EzC@daver.uu.net>
Date: Thu, 4 Jan 90 11:57 PST
From: dlr@daver.uu.net (Dave Rand)
To: pc532@daver.uu.net
Status: RO

John.J.Ackley
Message-Id: <9001040929.AA21965@equi.com>


Has the BOM been updated since the parity pal was added?
I've been busy putting my shopping list together from
George's "boms away" posting and Dave's reply to
"finding parts".  There are a few holes in the
ALS and AS listings in the catalogs I have.  (This is
not silly cone valley :-)  I'm going to call some of
the places mentioned on this list for catalogs.  I have
some AS parts where the BOM calls for ALS and visa
versa; is it possible to swap between these two series?

John Ackley <john@equi.com>

From "george@wombat (George Scolaro)" Thu Jan  4 22:13:02 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Thu, 4 Jan 90 17:12:57 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Thu, 4 Jan 90 17:12:52 EST
Received: by mips.com (5.61.14/1.11) id AA08855; Thu, 4 Jan 90 14:12:38 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gjfXM-0000AzC@daver.uu.net>; Thu, 4 Jan 90 14:02 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <wombat!george>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gjfXD-0000AIC@daver.uu.net>; Thu, 4 Jan 90 14:02 PST
Received: by wombat.UUCP (smail2.5)
	id AA08971; 4 Jan 90 13:54:39 PST (Thu)
From: george@wombat (George Scolaro)
Date: Thu, 4 Jan 90 13:54:38 PST
In-Reply-To: Dave Rand's message on Jan  4, 11:57.
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Message-Id: <9001041354.AA08971@wombat.UUCP>
Status: RO

[In the message entitled "" on Jan  4, 11:57, Dave Rand writes:]
> John.J.Ackley
> Message-Id: <9001040929.AA21965@equi.com>
> 
> Has the BOM been updated since the parity pal was added?

The BOM that JohnC has distributed to the net (ie REV 1D) contains
all the devices for the PCB as it is going to be shipped, ie it
includes parity etc.

> "finding parts".  There are a few holes in the
> ALS and AS listings in the catalogs I have.  (This is
> not silly cone valley :-)  I'm going to call some of
> the places mentioned on this list for catalogs.  I have
> some AS parts where the BOM calls for ALS and visa
> versa; is it possible to swap between these two series?

Only to the faster family, ie you could use an AS or F in place of an ALS. AS
is the fastest family around, F is the next and then ALS, ignoring the ACT
etc etc. In theory you could use F series in place of the AS I have called
out for. F is generally 1 or so nanoseconds slower than AS. The design
assumes worst case timing and calls out for AS to achieve this, in reality F
series would work fine since most signals (other than the DRAM lines) are
very lightly loaded and worst case times assume 50pF loads. 
Its just that I like to design worst case, of course you might just end up
with worst case timing on all the chips you plug in.... but that is very
unlikely.

> 
> John Ackley <john@equi.com>

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From ericbr%microsoft@Sun.COM Fri Jan  5 16:13:26 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Fri, 5 Jan 90 11:13:15 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Fri, 5 Jan 90 11:13:05 EST
Received: by mips.com (5.61.14/1.11) id AA00820; Fri, 5 Jan 90 08:12:55 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gjwKG-0000EDC@daver.uu.net>; Fri, 5 Jan 90 07:58 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!Sun.COM!microsoft!ericbr>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gjwKB-00009lC@daver.uu.net>; Fri, 5 Jan 90 07:57 PST
Received: from Sun.COM by uunet.uu.net (5.61/1.14) with SMTP 
	id AA04602; Fri, 5 Jan 90 07:14:08 -0500
Received: from sun.Sun.COM (sun-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
	id AA06184; Thu, 4 Jan 90 22:21:49 PST
Received: from microsoft.UUCP by sun.Sun.COM (4.1/SMI-4.1)
	id AA28285; Thu, 4 Jan 90 22:21:04 PST
From: ericbr%microsoft@Sun.COM
Message-Id: <9001050621.AA28285@sun.Sun.COM>
Subject: 84 pin PLCC chip extractors...
To: pc532@daver.UU.NET
Date: Thu, 4 Jan 90 22:18:23 PST
In-Reply-To: <8912212242.AA15974@uunet.uu.net>; from "John L. Connin" at Dec 21, 89 2:24 pm
X-Mailer: ELM [version 2.2 PL14]
Status: RO

This may not be the best group to ask, but...

Does anyone know where I might be able to buy an 84-pin PLCC chip
extractor?  I've got to swap some VLSI chips, and I don't want to use a
pair of screwdrivers for fear of breaking the socket.  Nobody locally
stocks them, and I don't have a whole bunch of catalogs for various mail
order people.  Help!

Eric
----------------------------------------------------------------
...!{sun, uunet}!microsoft!ericbr               Eric Brown
----------------------------------------------------------------


From "george@wombat (George Scolaro)" Fri Jan  5 17:21:56 1990
Flags: 000000000001
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Fri, 5 Jan 90 12:21:41 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Fri, 5 Jan 90 12:21:33 EST
Received: by mips.com (5.61.14/1.11) id AA02723; Fri, 5 Jan 90 09:21:28 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gjxCZ-0000CuC@daver.uu.net>; Fri, 5 Jan 90 08:54 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <wombat!george>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gjxCN-00008iC@daver.uu.net>; Fri, 5 Jan 90 08:53 PST
Received: by wombat.UUCP (smail2.5)
	id AA11248; 5 Jan 90 08:27:00 PST (Fri)
From: george@wombat (George Scolaro)
Date: Fri, 5 Jan 90 08:27:00 PST
In-Reply-To: daver!uunet!Sun.COM!microsoft!ericbr's message on Jan  4, 22:18.
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Subject: Re: 84 pin PLCC chip extractors...
Message-Id: <9001050827.AA11248@wombat.UUCP>
Status: RO

[In the message entitled "84 pin PLCC chip extractors..." on Jan  4, 22:18, daver!uunet!Sun.COM!microsoft!ericbr writes:]
> This may not be the best group to ask, but...
> 
> Does anyone know where I might be able to buy an 84-pin PLCC chip
> extractor?  I've got to swap some VLSI chips, and I don't want to use a

Before I can tell you who has them, you have to tell us which socket brand
you are using. AMP, 3M, Burndy?? Each socket is different and has its own
special extractor tool...

Fry's has some, but again, which socket Co. ?

> Eric
> ----------------------------------------------------------------
> ...!{sun, uunet}!microsoft!ericbr               Eric Brown
> ----------------------------------------------------------------

regards,


-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From "Jukka Virtanen <jtv@kampi.hut.fi>" Fri Jan  5 19:15:23 1990
Flags: 000000000001
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Fri, 5 Jan 90 14:15:17 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Fri, 5 Jan 90 14:15:10 EST
Received: by mips.com (5.61.14/1.11) id AA06043; Fri, 5 Jan 90 11:11:26 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gjyzf-00009fC@daver.uu.net>; Fri, 5 Jan 90 10:48 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!kampi.hut.fi!jtv>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gjyzU-00005vC@daver.uu.net>; Fri, 5 Jan 90 10:48 PST
Received: from santra.hut.fi by uunet.uu.net (5.61/1.14) with SMTP 
	id AA21221; Fri, 5 Jan 90 13:32:27 -0500
Received: from kampi.hut.fi by santra.hut.fi
	(5.61++/7.0/TeKoLa) id AA27752; Fri, 5 Jan 90 20:32:02 +0200
Received: by kampi.hut.fi id 1890; Fri, 5 Jan 90 20:31:42 EET
From: Jukka Virtanen <jtv@kampi.hut.fi>
To: pc532@daver.uu.NET
Subject: 32GX32 buglist
Message-Id: <90Jan5.203142eet.1890@kampi.hut.fi>
Date: 	Fri, 5 Jan 90 20:31:40 EET
Status: RO


	Happy new year every1!

	In comp.sys.nsc.32k there was some discussion about the bugs in
	the NS32532. Since there might be some interest in this group to
	know what they are, I'll post the buglist here. I got it
	from Jonathan Levy, and since it is *published* I don't
	see anything wrong in posting it.
	
				Juki
				jtv@hut.fi

	The NS32532, according to Jonathan, contains only one know
	bug in addition to the buglist below:

>> As of January 1989 National started shipping the '532 rev. C which 
>> corrected all the above mentioned bugs. The buglist for the NS32GX32
>> was published in the december '89 issue of uP Report. The only addition
>> for the NS32532 buglist is that RDVAL and WRVAL instructions can produce 
>> a wrong result if address bit A31 is high and the protection
>> level is not OK. 
>> 
>> Bottom line: There is absolutely no problems for '532 developers 
>> out there: The S/W tools are available, the HP ISE is available, 
>> support is available, and naturally, CLEAN AND SOLID SILICON IS
>> AVAILABLE !!
>> 
>> Jonathan


                         NS32GX32
                       PRODUCT UPDATE

                     DATE: 25 Aug 1989
                        VERSION: 2.1


PRODUCT INFORMATION:


  1.  An extra trace trap may happen in cases where INT or
      DBG are detected in the RETT from the trace handler
      (or any other instruction which retrieves the PSR with
      T bit high, or sets T bit in the PSR).  (1310)

  2.  Non-restartable bus errors (trap(NBE)) can cause
      unpredictable results. This is a rare occurence in
      which the CPU can either halt, or miss the trap.

      Bypass: Avoid use of ~BERR during write cycles.
      (1313)

  3.  Trap(DBG) can be missed at times. This problem is very
      rare and only a very complex combination of events can
      cause this to happen.  (1321)

  4.  Trap(DBG) on an address compare or on external ~DBG
      during a string instruction will be taken, but the DSR
      will not be updated.  (1324)

  5.  NADS pulse width is not guaranteed to be a minimum of
      10 ns. The guaranteed minimum in this revision is 8.6
      ns.  (1317)

  6.  A read cycle from slave can immediatly follow a memory
      read. This situation causes what looks like a severe
      AC spec conflict, although the actual conflict is
      negligible. This anomaly will be corrected in the next
      NS32GX32 revision.

      Bypass: Not required, as the conflict is minimal in
      real situations,

DATA SHEET CHANGES AND CLARIFICATIONS:

The following changes should be made to the datasheet in the
"Embedded System Processor Data Book", 1989 Edition:


  1.  In certain cases, when an exception has occured during
      the previous instruction, trap(DBG) can be taken prior
      to instruction execution.

  2.  A memory write cycle will never immediatly follow a
      read cycle (from memory or slave). In addition, a
      slave read will never immediatly follow any bus cycle.
      This ensures that no AC spec violations occur on the
      Data Bus.

  3.  tBCh tBCl tNBCh and tNBCl will be defined using tBCp
      as a reference, e.g. tBCh(min) = 0.5*tBCp - 5.  This
      will not change the actual value of these parameters.


NOTE: All comments and clarifications should be forwarded to
Jonathan Levy of the Imaging Applications Group at (408)
721-7437.

From "dlr@daver.UU.NET (Dave Rand)" Fri Jan  5 20:26:09 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Fri, 5 Jan 90 15:25:56 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Fri, 5 Jan 90 15:25:43 EST
Received: by mips.com (5.61.14/1.11) id AA08793; Fri, 5 Jan 90 12:25:33 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gk0S7-0000DhC@daver.uu.net>; Fri, 5 Jan 90 12:22 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <dlr>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gk0S1-0000DaC@daver.uu.net>; Fri, 5 Jan 90 12:22 PST
Message-Id: <m0gk0S1-0000DaC@daver.uu.net>
From: dlr@daver.UU.NET (Dave Rand)
Date: Fri, 5 Jan 90 12:22:09 PST
In-Reply-To: Ken Seefried iii's message on Jan  5, 18:38.
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Subject: Re: Minix/532
Status: RO

[In the message entitled "Minix/532" on Jan  5, 18:38, Ken Seefried iii writes:]
> How goes the Minix port?

I have completed the basic changes (to the MMU code, mostly). At this
point, I am ready to start the debugging of the kernel. I plan to do that
this weekend... Bruce gave me a few more hints after he got back from his
holidays, so I will be able to do much more!


-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr%daver@uunet.uu.net

From "george@wombat (George Scolaro)" Fri Jan  5 21:24:11 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Fri, 5 Jan 90 16:24:03 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Fri, 5 Jan 90 16:23:59 EST
Received: by mips.com (5.61.14/1.11) id AA10544; Fri, 5 Jan 90 13:23:52 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gk1Jp-0000F9C@daver.uu.net>; Fri, 5 Jan 90 13:17 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <wombat!george>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gk1JT-00008nC@daver.uu.net>; Fri, 5 Jan 90 13:17 PST
Received: by wombat.UUCP (smail2.5)
	id AA11445; 5 Jan 90 13:14:12 PST (Fri)
From: george@wombat (George Scolaro)
Date: Fri, 5 Jan 90 13:14:12 PST
In-Reply-To: Jukka Virtanen's message on Jan  5, 20:31.
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Subject: Re: 32GX32 buglist
Message-Id: <9001051314.AA11445@wombat.UUCP>
Status: RO

[In the message entitled "32GX32 buglist" on Jan  5, 20:31, Jukka Virtanen writes:]
> 
> 	Happy new year every1!

ditto

> 	The NS32532, according to Jonathan, contains only one known
> 	bug in addition to the buglist below:
> 
> >> was published in the december '89 issue of uP Report. The only addition
> >> for the NS32532 buglist is that RDVAL and WRVAL instructions can produce 
> >> a wrong result if address bit A31 is high and the protection
> >> level is not OK. 

This is not a problem since we don't have anything (other than the ICU) at
memory with A31 high. Of course this bug is only evident in the 32532 since
in the 32gx32 the mmu is not available which is what you would use rdval and
wrval with.

>                          NS32GX32
>                        PRODUCT UPDATE
> 
>                      DATE: 25 Aug 1989
>                         VERSION: 2.1
> 
> PRODUCT INFORMATION:
> 
>   1.  An extra trace trap may happen in cases where INT or
>       DBG are detected in the RETT from the trace handler
>       (or any other instruction which retrieves the PSR with
>       T bit high, or sets T bit in the PSR).  (1310)

This should not be a problem since trace traps are only used for single
stepping. The PC532 doesn't use the DBG pin, so the chance of this error
occuring is pretty tiny.

>   2.  Non-restartable bus errors (trap(NBE)) can cause
>       unpredictable results. This is a rare occurence in
>       which the CPU can either halt, or miss the trap.

Not a problem since bus errors are not asserted on the PC532.

>   3.  Trap(DBG) can be missed at times. This problem is very
>       rare and only a very complex combination of events can
>       cause this to happen.  (1321)

	i.e. they don't know how to report the bug. Since DBG is not
used on the PC532 this isn't a problem anyhow.

>   4.  Trap(DBG) on an address compare or on external ~DBG
>       during a string instruction will be taken, but the DSR
>       will not be updated.  (1324)

This is only a problem if we use the fancy MMU debug features. Seems to
me that NS should give up on this stuff. They had all sorts of trouble with
the 32082 (and 32382?) with these features.

>   5.  NADS pulse width is not guaranteed to be a minimum of
>       10 ns. The guaranteed minimum in this revision is 8.6
>       ns.  (1317)

Not a problem. The PC532 doesn't use NADS. In fact I can't see a real use
of this signals. Address strobe on a non-multiplexed address bus???

>   6.  A read cycle from slave can immediatly follow a memory
>       read. This situation causes what looks like a severe
>       AC spec conflict, although the actual conflict is
>       negligible. This anomaly will be corrected in the next
>       NS32GX32 revision.

This is the only real problem. This contention will occur for around 20ns or
so during a DRAM access. DRAM turn off time is a max of 20ns for 80ns drams
plus around 10ns+5+4=20ns for CAS de-assertion. ie around 40ns for full
tri-state. The NSPC comes out in a min of 0ns and max of 15ns (ie say 8ns)
then the FPU will start driving data (say 10 or so ns), so we contend for
around 20ns or so.

>       Bypass: Not required, as the conflict is minimal in
>       real situations,

They really mean that a bypass is impossible! 20ns of contention is a bit
revolting, but we can assume that the DRAMs take maybe 10ns to tri-state,
so we get full contention for less than 10ns. Oh well, a bit more noise on
the board during FPU operations.

>   2.  A memory write cycle will never immediatly follow a
>       read cycle (from memory or slave). In addition, a
>       slave read will never immediatly follow any bus cycle.
>       This ensures that no AC spec violations occur on the
>       Data Bus.

This is essential to remove the bus contention issue. Obviously NS hasn't
quite got it right for slave accesses. We will be getting 32532 Rev C
devices from NS.
 
> NOTE: All comments and clarifications should be forwarded to
> Jonathan Levy of the Imaging Applications Group at (408)
> 721-7437.

I'd like to see what the 32381 bug sheet looks like too.

regards,

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From "John L. Connin <johnc%manatee%uunet@daver>" Sat Jan  6 02:40:51 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Fri, 5 Jan 90 21:40:40 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Fri, 5 Jan 90 21:40:32 EST
Received: by mips.com (5.61.14/1.11) id AA19762; Fri, 5 Jan 90 18:40:28 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gk6IC-00008nC@daver.uu.net>; Fri, 5 Jan 90 18:36 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!tarpit!manatee!johnc>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gk6I7-0000CMC@daver.uu.net>; Fri, 5 Jan 90 18:36 PST
Received: from tarpit.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA25208; Fri, 5 Jan 90 21:15:57 -0500
Message-Id: <9001060215.AA25208@uunet.uu.net>
Received: by tarpit.UUCP (smail2.5)
	id AA26731; 5 Jan 90 20:39:01 EST (Fri)
Subject: Inmos G300 color video controller.
To: pc532%tarpit@daver.uu.NET
Date: Fri, 5 Jan 90 20:38:36 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]
Status: RO


In previous postings the Inmos G300 color video controller was mention.
Subsequently, I contacted Inmos to find out more about this animal.

To my untrained eye this looks like a dam good chip for a X-Window
server.   Could someone with more experience in this area comment on 
its strengths / weakness ??

G300 Overview
-------------

Inmos describes the G300 as a dedicated support chip which provides all
necessary functions for controlling real time operation of a raster
scan video system, using dual ported video DRAMs.  Its features are:

  o  Programmable video timing generator.  
  o  256 location by 24 bit color lookup table
  o  a triple 8 bit video DAC
  o  phase lock loop clock generation
  o  memory mapped programming port
  o  to 120 Mhz video rates
  o  external signals and clocks 1/4 video rate

  o  Pricing, 1-24
      G300G-85s,	 85 Mhz,  $94.40
      G300G-10s,	100 Mhz, $132.00
      G300G-11s,	110 Mhz, $185.00
      G300G-12s,	120 Mhz, n/a



Best regards,
johnc				UUCP:  tarpit!manatee!johnc





From "george@wombat (George Scolaro)" Sun Jan  7 01:10:40 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Sat, 6 Jan 90 20:10:35 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Sat, 6 Jan 90 20:10:29 EST
Received: by mips.com (5.61.14/1.11) id AA11066; Sat, 6 Jan 90 17:09:46 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gkRJz-00008wC@daver.uu.net>; Sat, 6 Jan 90 17:03 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <wombat!george>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gkRJu-00003AC@daver.uu.net>; Sat, 6 Jan 90 17:03 PST
Received: by wombat.UUCP (smail2.5)
	id AA14918; 6 Jan 90 16:51:54 PST (Sat)
From: george@wombat (George Scolaro)
Date: Sat, 6 Jan 90 16:51:52 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver
Subject: faster ...
Message-Id: <9001061651.AA14918@wombat.UUCP>
Status: RO

Hi Folks,
	the pc532 is now a tiny bit faster than before. The other day it
struck me that only 2 T-states (80ns) are needed to do a write access using
80ns drams (sort of obvious to me now). I had originally allocated 3, just
as for a read access. So the DRAM controller pal now determines whether a
read or write access is in progress and performs the appropriate RAS. This
only affects out of page accesses (in page have 0 waits on write, 0 waits
on first read and 1 wait during the burst). Out of page accesses now have
4 waits on read and 3 waits on write. The result of all this is around 3-4%
increase in dhrystone numbers (and this benchmark doesn't do that many
writes either!). The pal changes are transparent to the pcb, i.e. all kits
will have the new pals in them.

	On a different tack, Desmond Young (works at NS, is on this mail
list, and is getting a PC532, and designed the DP8490) has got NS to
generously donate 65 DP8490's to the PC532 effort.

regards,

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From "Johan Myreen <jem@cs.hut.fi>" Sun Jan  7 11:58:49 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Sun, 7 Jan 90 06:58:42 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Sun, 7 Jan 90 06:58:29 EST
Received: by mips.com (5.61.14/1.11) id AA20021; Sun, 7 Jan 90 03:57:58 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gkbTD-0000AgC@daver.uu.net>; Sun, 7 Jan 90 03:53 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!cs.hut.fi!jem>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gkbT8-0000CKC@daver.uu.net>; Sun, 7 Jan 90 03:53 PST
Received: from santra.hut.fi by uunet.uu.net (5.61/1.14) with SMTP 
	id AA27080; Sun, 7 Jan 90 06:07:35 -0500
Received: from sauna.hut.fi by santra.hut.fi
	(5.61++/7.0/TeKoLa) id AA10428; Sun, 7 Jan 90 13:07:23 +0200
Received: by cs.hut.fi (4.0/6.8/S-TeKoLa)
	id AA06044; Sun, 7 Jan 90 13:07:22 +0200
Date: Sun, 7 Jan 90 13:07:22 +0200
From: Johan Myreen <jem@cs.hut.fi>
Message-Id: <9001071107.AA06044@cs.hut.fi>
To: pc532@daver
In-Reply-To: John L. Connin's message of Fri, 5 Jan 90 20:38:36 EST
Subject: X server
Status: RO


>From: John L. Connin <johnc%manatee@uunet.UUCP>
>To my untrained eye this looks like a dam good chip for a X-Window
>server.   Could someone with more experience in this area comment on 
>its strengths / weakness ??

Well, it looks nice, but it looks like it is only a support chip: you
will still need a separate processor to run the X server on (?).

To me the Texas Intruments TMS34010 chip looks like a good alternative
to run an X server on. It is a 32 bit *general purpose* processor,
with on-chip peripheral functions supporting its use as a graphics
chip:

   - Programmable CRT control (sync and blanking)
   - DRAM interface (/RAS, /CAS, refresh)
   - Automatic CRT display refresh

The instruction set supports 32 bit integer arithmetic and the usual
addressing modes needed for high level languages. In addition, the chip
has instructions supporting various graphic primitives like pixel
block transfers, filling a pixel array, and drawing lines.

The chip can be used as both an I/O device connected to a host
processor bus. Or, it can be used as a standalone processor, which
would be the case on a PC532 card.

I believe you could design a simple and powerful X server using this
chip. Basically you need the following:

    - The 34010 chip itself
    - Video RAM
    - 2-4 DRAM SIMMs
    - A PROM to boot from
    - A SCSI controller chip
    - Some glue chips
    - What more...?

The price of the chip is no problem: I have seen prices as low as $4.

Well, these are my thougths about a graphics card. I am open to other
suggestions too.

--
Johan Myreen
jem@cs.hut.fi

From "Johan Myreen <jem@cs.hut.fi>" Mon Jan  8 02:47:47 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Sun, 7 Jan 90 21:47:42 EST
Received: from BU.EDU by bu-it.bu.edu (12/20/89); Sun, 7 Jan 90 21:47:39 EST
Received: from MIPS.COM by BU.EDU (1.97) Sun, 7 Jan 90 20:46:00 EST
Received: by mips.com (5.61.14/1.11) id AA00930; Sun, 7 Jan 90 17:45:55 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gkoLw-0000BQC@daver.uu.net>; Sun, 7 Jan 90 17:39 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!cs.hut.fi!jem>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gkoLp-0000DFC@daver.uu.net>; Sun, 7 Jan 90 17:39 PST
Received: from santra.hut.fi by uunet.uu.net (5.61/1.14) with SMTP 
	id AA12559; Sun, 7 Jan 90 19:40:34 -0500
Received: from sauna.hut.fi by santra.hut.fi
	(5.61++/7.0/TeKoLa) id AA24583; Mon, 8 Jan 90 02:40:11 +0200
Received: by cs.hut.fi (4.0/6.8/S-TeKoLa)
	id AA29907; Mon, 8 Jan 90 02:40:08 +0200
Date: Mon, 8 Jan 90 02:40:08 +0200
From: Johan Myreen <jem@cs.hut.fi>
Message-Id: <9001080040.AA29907@cs.hut.fi>
To: pc532@daver
In-Reply-To: ken%mm@gatech.edu's message of 7 Jan 90 20:16:48 GMT (Sun)
Subject: Re: X server (flame wars! :-)
Status: RO


>An `X Server' is *software*.  It is *not* GP's or VDACs or anything else.
>It is a program that controls display and input hardware through a host
>operating system.  Also, there is very little `simple' about it...

Perhaps I should have been more careful with the terminology in my
previous message. I *know* an X server involves a lot of software. But
it still needs something to run on. But what I didn't know was that
you needed a host operating system. What do you need that for? (Well,
it might ease debugging a little, but in principle...)

>[ semi-flame on ]

Let it burn...

>I think it's time for a serious reality check concerning all this
>video stuff.

>Designing the video subsystem is easy compared to getting the X
>Server *software* running, I estimate by an order of magnatude, 
>depending on what the hardware looks like (for X, the less hardware,
>the easier the port).  Unless someone is willing and able to 
>throw an easy man-year of effort into an X Server, we need to look for 
>more realistic solutions.

First of all, I didn't say it was going to be easy. But I am not so
sure about the relative difficulty of porting the software, compared
to designing the hardware. (Personally, I am a little worried about
managing video signals in the 50-100 MHz range...) I would say the
34010 is "less hardware" in that it has a memory mapped frame buffer,
so you can get the server up and running without utilizing any special
instructions in the 34010 instruction set. I am never going to believe
it will take a man-year to port a sample server from the X11
distribution to a 34010 card. Making it fast is another thing...

>[ semi-flame off ]

Gee, it's cold already...

>Now I'm not trying to be a colossal dick-head, or the guy who just sits 
>in the corner and say "nope, can't be done".

Ok, why *are* you such a guy then? :-)

>to be a lot of expectation that getting X running is a trivial matter
>of building some fancy hardware and compiling the MIT release tape
>(oh, and remember, we don't even have a C compiler for the 340x0,
>unless we want to buy one (the TI compiler is pretty bad...at least

Well, we have gcc. Ok, so there is no 34010 version of gcc, but I
don't think making a back end for the 34010 is that impossible. The
34010 is a pretty neat processor, by the way.

What do you others think? Am I underestimating the work involved?

--
Johan Myreen
jem@cs.hut.fi

Ps. This message isn't very constructive. I'm sorry about that.

From "george@wombat (George Scolaro)" Mon Jan  8 02:48:10 1990
Flags: 000000000001
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Sun, 7 Jan 90 21:48:02 EST
Received: from BU.EDU by bu-it.bu.edu (12/20/89); Sun, 7 Jan 90 21:47:57 EST
Received: from MIPS.COM by BU.EDU (1.97) Sun, 7 Jan 90 20:09:55 EST
Received: by mips.com (5.61.14/1.11) id AA00472; Sun, 7 Jan 90 17:09:31 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gknmk-0000AXC@daver.uu.net>; Sun, 7 Jan 90 17:02 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <wombat!george>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gknmd-0000DJC@daver.uu.net>; Sun, 7 Jan 90 17:02 PST
Received: by wombat.UUCP (smail2.5)
	id AA16873; 7 Jan 90 16:52:33 PST (Sun)
From: george@wombat (George Scolaro)
Date: Sun, 7 Jan 90 16:52:33 PST
In-Reply-To: Jon Loeliger's message on Jan  7, 15:40.
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Subject: Re: Build list info
Message-Id: <9001071652.AA16873@wombat.UUCP>
Status: RO

[In the message entitled "Build list info" on Jan  7, 15:40, Jon Loeliger writes:]

> >        Parts List Revision :  1.0
> >        BOM reference       :  Version 1D
> 
> >    1)  johnc, 22jan89, received version 1D BOM (ie. pcb fab release) from george.
 
> First off, Is the date right here?

	probably not eh? But Rev 1D is the right BOM. The date is hardwired,
ie the last date I ever stuck in the schema BOM header.
 
>        1      69	CAPACITOR,0.1, 0.3inch spacing, Monolithic Bypass

0.1 microfarads (decoupling caps), yes they are the IC look-alike-mounts.

> 
>        8       1	DIODE, IN4148                                     D2
> 
>       20       2	RESISTOR,???, BCLK, /BCLK terminator (TBD)        R3,R7
> 
> Has this value been determined yet or is it it some sort of tuning or
> timing resister that must in some way be determined on a per board basis?

Yeah - tuning. The prototypes worked fine without, but when I get the new
pcbs and build one up, I'll stick a 400mhz scope on and determine the best
value.

>       40       8	MSC411024 -  1M X 9 BIT DYNAMIC RAM MODULE                  U10,U11,U12,U13
> 				  OR 1M X 8 (FOR NO PARITY), FAST PAGE 80 ns        U6,U7,U8,U9
> 				  Toshiba part # THM81000AS-80 (1M X 8)
> 			4 SIMMs are the minimum configuration

The part numbers above are for different manufacturers. The DRAM you need is
either x8 of x9 (non or parity) and 1 megabit. They must be 80 ns or faster 
and support fast page mode access. I will check on Monday and post the NEC
part number, then you can just ask for an equivalent.

>       49       1	JUMP1 - SINGLE JUMPER HEADER                  J3
>       50       2	JUMP3 - 3 PIN JUMPER                          J1,J2
>       51       1	JUMP4 - 4 LOCATION JUMPER BLOCK               CONN2
>       55       2	50 WAY TRANSITION CONNECTOR UNSHROUDED (JUST PINS)          CONN1,CONN16    
> 
> Jumpers and connectors.  Without the schemetics or board in hand, I'm really
> not sure what sort of connectors these are...  Are these the standard kind
> with like 1cm leads sticking straight up from the PCB that you can slide a

yeah thats the critter. JUMP1 is 2 pins 0.1 inch centers. JUMP3 is 3 pins 0.1
inch centers. JUMP4 is 4 x 2 pins 0.1 inch centers. The 50 way is 25 x 2 pins
0.1 inch centers (unshrouded, ie just the pins in a plastic carrier).
 
> 3.0  Construction Notes.
> ------------------------
> 
> Question:  How static sensitive are some of these parts?  Are all the
> critical parts socketed so that I don't need to worry about blowing
> them during soldering etc?  Also, any requirements or advice on soldering
> this puppy?  60-40 tin/lead rosin core solder good enough?

The only static sensitive parts are the EPROM, the DRAM, the CPU, FPU, RS232
CMOS driver/receivers, DUARTs, SCSI devices. Just use the normal precautions,
ie don't touch the chips until they are ready to plug in, leave them
in the antistatic package until you're ready. Then when you pick them up,
touch the ground on the PCB before plugging them in. Normal solder is fine.
We are supplying the sockets for the CPU,FPU,DRAM,SCSIs and DUARTs. The rest
of the sockets will be your problem. I recommend could quality machined pin
sockets, they cost a bit more but are well worth it.

regards,

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From "Jon Loeliger <loeliger%convex@uxc.cso.uiuc.edu>" Mon Jan  8 02:50:47 1990
Flags: 000000000001
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Sun, 7 Jan 90 21:50:38 EST
Received: from BU.EDU by bu-it.bu.edu (12/20/89); Sun, 7 Jan 90 21:50:31 EST
Received: from MIPS.COM by BU.EDU (1.97) Sun, 7 Jan 90 17:58:33 EST
Received: by mips.com (5.61.14/1.11) id AA28293; Sun, 7 Jan 90 14:58:29 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gklmh-0000DmC@daver.uu.net>; Sun, 7 Jan 90 14:54 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!uxc.cso.uiuc.edu!convex!loeliger>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gklma-0000DFC@daver.uu.net>; Sun, 7 Jan 90 14:54 PST
Received: from uxc.cso.uiuc.edu by uunet.uu.net (5.61/1.14) with SMTP 
	id AA10702; Sun, 7 Jan 90 17:08:34 -0500
Received: from convex.UUCP by uxc.cso.uiuc.edu with UUCP
	(5.61+/IDA-1.2.8) id AA27751; Sun, 7 Jan 90 15:39:58 -0600
Received: by convex (5.51/4.7)
	id AA20170; Sun, 7 Jan 90 15:40:52 CST
Received: by mozart (5.51/4.7)
	id AA12192; Sun, 7 Jan 90 15:40:50 CST
Message-Id: <9001072140.AA12192@mozart>
To: pc532@daver.uu.NET
Subject: Build list info
Clarity-Index: null
Threat-Level: none
Quote-Of-The-Moment: 's/./&&/g' Tom sed expansively.
Date: Sun, 07 Jan 90 15:40:50 CST
From: Jon Loeliger <loeliger%convex@uxc.cso.uiuc.edu>
Status: RO


Hi,
I wasn't sure if John (Connin) intended us to send this to him
or to pc532@daver.uu.net, so everyone gets it!

I have some more information and questions on some parts.
I just received my Jan-Feb 1990 DigiKey Catalog and pawed
through it for parts.  Here's what I found...


>        Parts List Revision :  1.0
>        BOM reference       :  Version 1D

>    1)  johnc, 22jan89, received version 1D BOM (ie. pcb fab release) from george.

First off, Is the date right here?


       1      69	CAPACITOR,0.1, 0.3inch spacing, Monolithic Bypass

Are these standard disc or IC-look-alike mounts?  Um, units are PF?

       8       1	DIODE, IN4148                                     D2

Digikey p49, 10@.60, 100@5.00

       9       2	DIODE, IN5817 (SCSI DIODE, Schottky)              D1,D3

Digikey p49, 1@.48, 10@4.00


      20       2	RESISTOR,???, BCLK, /BCLK terminator (TBD)        R3,R7

Has this value been determined yet or is it it some sort of tuning or
timing resister that must in some way be determined on a per board basis?


      26       1	74F138 - FAST TTL 3/8 DECODER                     U33

Digikey p33, 74F138PC 1@.79


      52       1	CRYSTAL OSCILLATOR MODULE, 20MHZ              U34

Digikey p51, x119 1@5.78



      40       8	MSC411024 -  1M X 9 BIT DYNAMIC RAM MODULE                  U10,U11,U12,U13
				  OR 1M X 8 (FOR NO PARITY), FAST PAGE 80 ns        U6,U7,U8,U9
				  Toshiba part # THM81000AS-80 (1M X 8)
			4 SIMMs are the minimum configuration

A question here.  Are these grouped as {U10,U11,U12,U13} or {U6,U7,U8,U9}
with different corresponding part numbers MSC411024 and THM81000AS-80
respectively?  Am I correct that in either case they need to be 80ns parts?
I located a local DRAM supplier and want to check out their offerings.  I'd
like to make sure I ask for the right thing...  What sort of price range
should I expect?  Also, if they can quote the Right Price does everyone
still need RAM and might we buy in bulk (50 boards(?) * 4)?   (Actually,
are some of us are doing parity and others not?  Is this decision price
dependent for some?)

      49       1	JUMP1 - SINGLE JUMPER HEADER                  J3
      50       2	JUMP3 - 3 PIN JUMPER                          J1,J2
      51       1	JUMP4 - 4 LOCATION JUMPER BLOCK               CONN2
      55       2	50 WAY TRANSITION CONNECTOR UNSHROUDED (JUST PINS)          CONN1,CONN16    

Jumpers and connectors.  Without the schemetics or board in hand, I'm really
not sure what sort of connectors these are...  Are these the standard kind
with like 1cm leads sticking straight up from the PCB that you can slide a
connector thing down onto?  And, I must confess, I don't know what a
"transition connector" is.  I have this idea we're talking about a thing
with two rows of leads sticking up (down?) parallel to each other.  Can
someone who knows identify or describe these parts for me (us)?


Can someone tell me a supplier for the glue chips in the AS and ALS series?
Digikey appears not to carry them, and my other catalogs are sadly way
out of date...


3.0  Construction Notes.
------------------------

Question:  How static sensitive are some of these parts?  Are all the
critical parts socketed so that I don't need to worry about blowing
them during soldering etc?  Also, any requirements or advice on soldering
this puppy?  60-40 tin/lead rosin core solder good enough?


jdl
------------------------------------------------------------------------------
Jon Loeliger			    loeliger@convex.com
Convex Computer Corporation	    "You should never attack an anarchist.  He
3000 Waterview, Richardson TX 75083  has nothing to lose."   Joe Bob's friend

From "rwa@cs.AthabascaU.CA (Ross Alexander)" Mon Jan  8 07:56:11 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Mon, 8 Jan 90 02:56:07 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Mon, 8 Jan 90 02:56:03 EST
Received: by mips.com (5.61.14/1.11) id AA06278; Sun, 7 Jan 90 23:55:51 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gktWh-0000BgC@daver.uu.net>; Sun, 7 Jan 90 23:10 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!watmath!alberta!atha!root>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gktWc-00009OC@daver.uu.net>; Sun, 7 Jan 90 23:10 PST
Received: from watmath.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA16116; Mon, 8 Jan 90 01:45:25 -0500
Received: from alberta.uucp by watmath.waterloo.edu with uucp
	id <AA02288>; Mon, 8 Jan 90 01:39:25 EST
Received: by pembina.alberta.UUCP (5.52/3.14)
	id AA17441; Sun, 7 Jan 90 23:25:49 MST
Received: by aurora.AthabascaU.CA (/\=-/\ Smail3.1.18.1 #18.26)
	id <m0gksWC-00001vC@aurora.AthabascaU.CA>; Sun, 7 Jan 90 23:06 MST
Received: by aungbad.AthabascaU.CA (/\=-/\ Smail3.1.17.5 #17.20)
	id <m0gksTD-0001yvC@aungbad.AthabascaU.CA>; Sun, 7 Jan 90 23:03 MST
Message-Id: <m0gksTD-0001yvC@aungbad.AthabascaU.CA>
Date: Sun, 7 Jan 90 23:03 MST
From: rwa@cs.AthabascaU.CA (Ross Alexander)
To: pc532@daver.UU.NET
In-Reply-To: Ken Seefried iii's message of 7 Jan 90 22:25:04 GMT (Sun) <9001072225.AA02503@mm.UUCP>
Subject: dirt cheap windowing?
Status: RO

We have some code lying around the shop somewhere which provides
Layers service from a BSD host.  Let me ask it's keeper about whether
it's redistributable, et c., and I'll get back to you.

BTW, I am not real keen on Layers as a working environment, but then
again what do I know?  I live on a microVax running X :-)
--
Ross Alexander    (403) 675 6311    rwa@aungbad.AthabascaU.CA    VE6PDQ

From "Dave Mason <mason%tmsoft%uunet@daver>" Mon Jan  8 07:56:13 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Mon, 8 Jan 90 02:56:10 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Mon, 8 Jan 90 02:56:06 EST
Received: by mips.com (5.61.14/1.11) id AA06285; Sun, 7 Jan 90 23:56:03 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gktWe-0000EmC@daver.uu.net>; Sun, 7 Jan 90 23:10 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!mnetor!tmsoft!mason>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gktWW-0000ASC@daver.uu.net>; Sun, 7 Jan 90 23:10 PST
Received: from mnetor.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA14741; Mon, 8 Jan 90 01:35:23 -0500
Received: by mnetor.UUCP (smail2.3)
	id AA00202; 8 Jan 90 01:22:49 EST (Mon)
Received: by tmsoft.UUCP (smail2.3)
	id AA24257; 7 Jan 90 22:03:08 EST (Sun)
To: pc532@daver.UU.NET
From: Dave Mason <mason%tmsoft%uunet@daver>
Subject: Re: X server (flame wars! :-)
Organization: TM Software Associates Inc.
In-Reply-To: message of Mon, 8 Jan 90 02:40:08 +0200.
             <9001080040.AA29907@cs.hut.fi>
Date: 7 Jan 90 22:03:08 EST (Sun)
Message-Id: <9001072203.AA24257@tmsoft.UUCP>
Status: RO

KS> Ken Seefried <ken%mm.uucp@gatech.edu>
JM> Johan Myreen <jem@cs.hut.fi>

KS>Designing the video subsystem is easy compared to getting the X
KS>Server *software* running, I estimate by an order of magnatude, 
KS>depending on what the hardware looks like (for X, the less hardware,
KS>the easier the port).  Unless someone is willing and able to 
KS>throw an easy man-year of effort into an X Server, we need to look for 
KS>more realistic solutions.

JM> Well, we have gcc. Ok, so there is no 34010 version of gcc, but I
JM> don't think making a back end for the 34010 is that impossible. The
JM> 34010 is a pretty neat processor, by the way.

JM> What do you others think? Am I underestimating the work involved?

A few comments on TI34010 vs Inmos G300:

TI34010:	16 bit memory, maximum speed ~80MHz, includes processor
		nifty chip, should work with a single memory for
		frame/program (though this may slow it unacceptably),
		upgradeable with TI34020, palet chip available

G300+NS32GC16:	32 bit frame memory (I presume, from the posted specs),
		maximum speed ~110MHz, built-in 256 element palet,
		compiler readily available, upgradeable with NS32GX32

Being basically a software hack, getting 100+MHz video signals working
properly worries ME more than porting an X-server.  I'd guess more
like 1 month to get a reasonably functioning X-server, assuming stable
hardware and compiler.

While the G300+NS32GC16 solution is probably a slightly more expensive
solution for the base system, by the time you get a colour palet for
the TI, I think they're going to be pretty close.

For me having a working compiler (and only having to support basically
one programming environment) is a big plus.  While getting GCC to
generate code for the 34010 probably isn't hard, getting it to
generate close to optimal code probably is: while the 34010 is a neat
chip, the instuction set isn't exactly conventional. 

From lyndon@cs.AthabascaU.CA Mon Jan  8 08:19:22 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Mon, 8 Jan 90 03:19:20 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Mon, 8 Jan 90 03:19:16 EST
Received: by mips.com (5.61.14/1.11) id AA06788; Mon, 8 Jan 90 00:19:05 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gkuTF-0000DUC@daver.uu.net>; Mon, 8 Jan 90 00:11 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!watmath!alberta!atha!lyndon>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gkuSm-0000CuC@daver.uu.net>; Mon, 8 Jan 90 00:10 PST
Received: from watmath.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA25904; Mon, 8 Jan 90 02:46:50 -0500
Received: from alberta.uucp by watmath.waterloo.edu with uucp
	id <AA03617>; Mon, 8 Jan 90 02:36:11 EST
Received: by pembina.alberta.UUCP (5.52/3.14)
	id AA17798; Mon, 8 Jan 90 00:11:30 MST
Received: by aurora.AthabascaU.CA (/\=-/\ Smail3.1.18.1 #18.26)
	id <m0gktI2-00001vC@aurora.AthabascaU.CA>; Sun, 7 Jan 90 23:55 MST
Message-Id: <m0gktI2-00001vC@aurora.AthabascaU.CA>
To: rwa@cs.AthabascaU.CA (Ross Alexander)
Cc: pc532@daver.UU.NET
Subject: Re: dirt cheap windowing? 
In-Reply-To: Your message of Sun, 07 Jan 90 23:03:00 -0700.
             <m0gksTD-0001yvC@aungbad.AthabascaU.CA> 
Date: Sun, 07 Jan 90 23:55:34 MST
From: lyndon@cs.AthabascaU.CA
Status: RO

> We have some code lying around the shop somewhere which provides
> Layers service from a BSD host.  Let me ask it's keeper about whether
> it's redistributable, et c., and I'll get back to you.

It's keeper says: "don't bet on it."

The layers command ships as part of the SVR3.1 porting base source
tape. You'll need a SVR3.1 source license to get the code. I
wouldn't want to port it to BSD ...

Once you have layers running, you need all the DMD specific support
code. I don't see any of this on the porting base tape. I do recall
there being some DMD stuff on the AT&T toolchest. It seems to me that
the DMD developers kit was part of it, and might give you the rest
of what you need.

Definative answers on all of the above should be had from Doug Gwyn.

I *do* know that the 630 environment (layers and all) has been ported
to SunOS, and is available from AT&T. I will ping our AT&T tech droid
for further information.

--lyndon

From "mea@mea.utu.fi (Matti Aarnio)" Mon Jan  8 09:53:23 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Mon, 8 Jan 90 04:53:18 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Mon, 8 Jan 90 04:53:14 EST
Received: by mips.com (5.61.14/1.11) id AA08017; Mon, 8 Jan 90 01:53:11 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gkw07-00009CC@daver.uu.net>; Mon, 8 Jan 90 01:49 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!mea.utu.fi!mea>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gkw00-0000EnC@daver.uu.net>; Mon, 8 Jan 90 01:49 PST
Received: from polaris.utu.fi by uunet.uu.net (5.61/1.14) with SMTP 
	id AA13377; Mon, 8 Jan 90 04:35:35 -0500
Received: from mea.utu.fi by polaris.utu.fi; id AA03042; Mon, 8 Jan 90 11:34:13 +0200 
Received: by mea.utu.fi (5.51/10.6.master) id AA03766; Mon, 8 Jan 90 11:35:33 +0200
Message-Id: <9001080935.AA03766@mea.utu.fi>
From: mea@mea.utu.fi (Matti Aarnio)
Subject: Re: X server (flame wars! :-)
To: pc532@daver
Date: Mon, 8 Jan 90 11:35:32 EET
Cc: mea@mea.utu.fi (Matti Aarnio)
In-Reply-To: <9001072203.AA24257@tmsoft.UUCP>; from "Dave Mason" at Jan 7, 90 10:03 pm
X-Mailer: ELM [version 2.2 PL10]
Status: RO

DM> Dave Mason <mason%tmsoft@uunet.UUCP>
KS> Ken Seefried <ken%mm.uucp@gatech.edu>
JM> Johan Myreen <jem@cs.hut.fi>

KS>Designing the video subsystem is easy compared to getting the X
KS>Server *software* running, I estimate by an order of magnatude, 
KS>depending on what the hardware looks like (for X, the less hardware,
KS>the easier the port).  Unless someone is willing and able to 
KS>throw an easy man-year of effort into an X Server, we need to look for 
KS>more realistic solutions.

JM> Well, we have gcc. Ok, so there is no 34010 version of gcc, but I
JM> don't think making a back end for the 34010 is that impossible. The
JM> 34010 is a pretty neat processor, by the way.

JM> What do you others think? Am I underestimating the work involved?

DM> A few comments on TI34010 vs Inmos G300:
DM> 
DM> TI34010:	16 bit memory, maximum speed ~80MHz, includes processor
DM> 		nifty chip, should work with a single memory for
DM> 		frame/program (though this may slow it unacceptably),
DM> 		upgradeable with TI34020, palet chip available
DM> 
DM> G300+NS32GC16:	32 bit frame memory (I presume, from the posted specs),
DM> 		maximum speed ~110MHz, built-in 256 element palet,
DM> 		compiler readily available, upgradeable with NS32GX32
DM> 
DM> Being basically a software hack, getting 100+MHz video signals working
DM> properly worries ME more than porting an X-server.  I'd guess more
DM> like 1 month to get a reasonably functioning X-server, assuming stable
DM> hardware and compiler.

  Getting 100+MHz video isn't that hard, getting it as flexible as possible
is.
  I have created a design for such a board basing on 34010, but it has never
been finished -- I still lack decent CAD programs.  (I have a 386 machine
running UNIX, and no desire to boot it on MSDOS.  I do have a VP/IX however.)

  G300 is basically fast palette + VRAM controller, no graphics DRAWING
features included.  (eg, no processor)

DM> While the G300+NS32GC16 solution is probably a slightly more expensive
DM> solution for the base system, by the time you get a colour palet for
DM> the TI, I think they're going to be pretty close.
DM> 
DM> For me having a working compiler (and only having to support basically
DM> one programming environment) is a big plus.  While getting GCC to
DM> generate code for the 34010 probably isn't hard, getting it to
DM> generate close to optimal code probably is: while the 34010 is a neat
DM> chip, the instuction set isn't exactly conventional. 

  Getting out FAST video isn't that difficult on TI, one just must forget
what TI offers as 'palette', and turn to BrookTree.
On that design I do generate 128 bits WIDE video memory (6.25MHz), which
is multiplexed on LCA/PGA/whatnot (RAM based gate array) multiplexer set
(4 chips) into 32 bit wide dataflow at 25MHz.  Then that is feed to Bt451
Palette and let it do the last multiplexing (by 4) and output.
(Pipelining all the time -- for easing timing considerations)

  That lets quite a lot free time for processor (especially as video memory
must be made with Video-RAMs :-)

  Interesting bit on that design may be, that I did plan to connect it to
host via SCSI adapter...  (back in 1986/7 or so)

	/Matti Aarnio	<mea@mea.utu.fi>


From "Bob Izenberg <xtserv!bei@bu-it.bu.edu>" Mon Jan  8 12:20:31 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Mon, 8 Jan 90 07:20:28 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Mon, 8 Jan 90 07:20:25 EST
Received: by mips.com (5.61.14/1.11) id AA10783; Mon, 8 Jan 90 04:20:11 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gkxja-0000DvC@daver.uu.net>; Mon, 8 Jan 90 03:40 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <attctc!puzzle!xtserv!bei>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gkxjP-0000CpC@daver.uu.net>; Mon, 8 Jan 90 03:40 PST
Received: by attctc.Dallas.TX.US (killer) (/\=-/\ Smail3.1.18.1 #18.1)
	id <m0gkwGh-0002iPC@attctc.Dallas.TX.US>; Mon, 8 Jan 90 04:06 CST
Received: by puzzle.UUCP (/\=-/\ Smail3.1.16.1 #16.11)
	id <m0gkvxJ-0000kUM@puzzle.UUCP>; Mon, 8 Jan 90 03:46 CST
Received: by xtserv.UUCP (UUPC/pcmail 1.0095) with UUCP; Sun, 08 Jan 89 03:40:14 CDT
Date: Sun, 08 Jan 89 03:40:14 CDT
From: Bob Izenberg <xtserv!bei@bu-it.bu.edu>
Message-Id: <23c71e6e@xtserv.UUCP>
X-Mailer: UUPC/mail 1.095
To: pc532%daver%attctc@puzzle
Subject: Re: 5620/630 terminals
Status: RO

In message <9001072225.AA02503@mm.UUCP> Ken Seefried III wrote:
: Anyone on the list know much about the AT&T `layers' windowing
: system for the 5620/BLIT/630 series terminals, specificly, how
: hard is it to port?  I know it needs STREAMS or sockets (prefers
: the former, though it works on BSD 4.2), but what else?
: The reason I ask is that there is a place selling AT&T 5620s
: pretty cheap, and layers is a pretty good environment.  I wouldn't
: mind having it on the pc532.

	The 5620 is a bear to program, from what I hear.  The 630 is easier,
but requires (even on a 3B2/5/15) a new set of libraries for the C compiler,
mostly to shove code at the 68000 in the terminal.  It sure doesn't sound
easy.
-- Bob
 ------------------------------------------------------------------------------
             attctc!puzzle!bei    512 346 7019 (home)    Austin, TX
 ------------------------------------------------------------------------------
-- 
 ------------------------------------------------------------------------------
                     Bob Izenberg [ ] Ralph Kirkley Associates
              attctc!puzzle!bei    512 346 7019 (home)    Austin, TX
 ------------------------------------------------------------------------------

From "ken%mm@gatech.edu (Ken Seefried iii)" Mon Jan  8 12:23:29 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Mon, 8 Jan 90 07:23:26 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Mon, 8 Jan 90 07:23:23 EST
Received: by mips.com (5.61.14/1.11) id AA10847; Mon, 8 Jan 90 04:23:21 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gkyD7-0000DMC@daver.uu.net>; Mon, 8 Jan 90 04:10 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!gatech.edu!mm!ken>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gkyCq-0000E8C@daver.uu.net>; Mon, 8 Jan 90 04:10 PST
Received: from gatech.edu by uunet.uu.net (5.61/1.14) with SMTP 
	id AA02041; Mon, 8 Jan 90 06:51:34 -0500
Received: from mm.UUCP  with UUCP by gatech.edu (5.58/GATECH-8.6)
	id AA23154 for ; Mon, 8 Jan 90 06:49:01 EST
Received: by mm.UUCP (smail2.5)
	id AA03396; 8 Jan 90 04:15:08 GMT (Mon)
In-Reply-To: Johan Myreen <gatech!cs.hut.fi!jem>
       "Re: X server (flame wars! :-)" (Jan  8,  2:40am)
X-Mailer: Mail User's Shell (6.4 2/14/89)
To: pc532@daver.UU.NET
Subject: Re: X server (flame wars! :-)
Message-Id: <9001080415.AA03396@mm.UUCP>
Date: 8 Jan 90 04:15:08 GMT (Mon)
From: ken%mm@gatech.edu (Ken Seefried iii)
Status: RO

On Jan 8,  2:40am, Johan Myreen wrote:
} Subject: Re: X server (flame wars! :-)
                         ^^^^^^^^^^^ just what I *don't* want to start!
				     (no :-))

}
}                                     But what I didn't know was that
} you needed a host operating system. What do you need that for? 
}

In general, the host operating system provides such things as
access to the keyboard and mouse, as well as to the storage device
containing such things as fonts and pixmaps.  Network access (you
need something like sockets or STREAMS for the network, shared
memory for local clients) is done through the host OS, as well as 
dynamic memory management.

Of course, the OS need not be Unix (or VMS, or MS-DOS).  Witness
the multitude of X Windows terminals.  They have a `little OS' in
ROM under the X server that provides access to resources as well
as providing a `telnet'-like program for initial connection to the
host.

In theory, I suppose these things could be folded into the X
Server.  In practice, however, I would imagine any 340x0 based
card for the pc532 would have some sort of control processor (32gc16,
68000, etc.) running a mini-OS that would deal with the SCSI bus and 
fielding I/O requests from the GP and leave the '010 to pushing 
bits around the VRAM.  Regardless of what TI might like you to 
believe, making a 34010 field SCSI I/O, keyboard and mouse traffic 
would *seriously* affect video performance.

}
}                                                                (Well,
} it might ease debugging a little, but in principle...)
} 

And don't underestimate the need for debugging...;') ;')

} 
} First of all, I didn't say it was going to be easy. But I am not so
} sure about the relative difficulty of porting the software, compared
} to designing the hardware. (Personally, I am a little worried about
} managing video signals in the 50-100 MHz range...) 
}

I speced out a 50MHz 34010 subsystem a while back and brought the
prliminary design and all the timing data and data books to some
of the digital design gurus at Georgia Tech.  Paraphrased, they
said `piece of cake'...indeed, the vast majority of the design is
done in various TI application notes.  What is left (in my proto-
design) was attaching a SCSI interface to the control processor.

I worry much less about 50MHz+ signals than programmes with 300K+
executables (SCO 386 Unix XSight R3 server for VGA is ~380K, R4 
server on a monochrome, dumb VAXStation II under Wisconsin BSD 4.3 
is ~700K (unstripped)).

}
}                                                      I would say the
} 34010 is "less hardware" in that it has a memory mapped frame buffer,
} so you can get the server up and running without utilizing any special
} instructions in the 34010 instruction set. 
}

Well...it's not less hardware, at least not in the X sense.

"less harware" means as close to the dumb frame-buffer, main
processor does everything model (ie Sun 3/50) as you can get.

With the 34010-based SCSI video card that has been proposed,
you still have to deal with some rather complicated interactions
between the GP, the control processor and the host.  Remeber,
while the server might be running on the video card, the clients
are running on the main CPU, and need to recieve keyboard input
and send video output.  The X server still needs to request and
recieve fonts and bitmaps from the host machine, as well as
network (ethernet or SLIP) traffic.

These are not easy things to deal with.  The sample servers do not
do this sort of thing (that I am aware of...there may be some new
servers on the R4 tape that do; I haven't finished unpacking it
all).  In other words, you are on your own.

}
}                                       I am never going to believe
} it will take a man-year to port a sample server from the X11
} distribution to a 34010 card. 
} 

That, of course, is your perogative...though I feel very justified
in quoting that figure.

One man-year is a rough estimate I got from someone familiar with 
GSSs' effort to build an X server for the 34010/DGIS interface and
IBM PC/AT I/O.  

The `Godzilla's Guide to Porting X' from MIT throws around the 
figure 6 man-months to port the sample server (R2) to a monochrome, 
dumb frame-buffer based workstation (eg Sun 3/50).  Colour and GPs
add more time.  I don't have the `Guide' here, so I don't know how
much they estimate.

The person at Georgia Tech who ported the R3 server to the
Parallax colour video board on the MicroVAX (Keith Edwards) 
considers a man-year a reasonable estimate.  

There are several other poeple around here actively porting X.  If
you wish, I will continue to get estimates...

Now lets look objectively at what it will take to build an video
card and an X server:

	1) Design, build and test a video card
	2) Write and test a mini-OS for the control processor
	3) Write and test a 34010 back-end for gcc
	4) Write and test an X server (a colour X Server)

Now...even if writing the X server didn't take a man-year, doing
1-4 sure will.  Perhaps Juki can give us an idea of how long it 
takes to do a gcc back-end from scratch (he knows much more about 
gcc than I do, at least the front end of it).

} 
} >Now I'm not trying to be a colossal dick-head, or the guy who just sits 
} >in the corner and say "nope, can't be done".
} 
} Ok, why *are* you such a guy then? :-)
} 

Gee...thanks...

} 
} Well, we have gcc. Ok, so there is no 34010 version of gcc, but I
} don't think making a back end for the 34010 is that impossible. The
} 34010 is a pretty neat processor, by the way.
} 

Hey, I'd *love* to see a 340x0 gcc compiler.  It might be tough
to get the bit-addressing stuff right if gcc doesn't already deal
with it (I wouldn't know), but the 340 series has a reasonable 
enough architecture that a good compiler should do wonders.  Were 
I a compiler jock, I'd have started a year ago.

And I was *not* putting down the 340x0!  I think they are *really
great chips*.  I can't wait to get my hands on the new 34010-based
X Terminals, and I'm lobbying to get one of the new EISA bus 34020
cards from Mylex for our soon-to-be-ordered server.

} 
}-- End of excerpt from Johan Myreen
}

Thats more than enough for now, but let me reiterate:

	I would be overjoyed for someone to convince me that I
	am wrong.  If I am factually wrong on any point, I
	will be more than happy to recant.

	I have a case of beer for the first person or group
	that can port X to a non-frame bufferd, SCSI-based 
	video card with less than a man-year of effort (of
	course, I'll buy a beer for most anyone...:-).

	Do *not* let my rantings dissuade any person from 
	trying if they really, truly feel that they can pull
	it off, even if it does take more than a year.
	Indeed, there are probably people out there who 
	crank out X servers for breakfast and write OSes
	during lunch (god knows, George and Dave brought 
	up the pc532 rather quick considering they have 
	jobs and lives and all).

	I *don't* want a flame war...if anyone feels the 
	need to flame me for what I have said, spare the 
	list the noise a mail me ( uunet!gatech!mm!ken ).

I simply feel that there is a better, simpler way of handling X
for the pc532.


-- 
    ...ken seefried iii          ...!<anywhere>!uunet!gatech!mm!ken
         MetaMedia, Inc.              Atlanta, Georgia, USA
           ken%mm.uucp@gatech.edu       obquote: "I feel...like a god..."
    
    

From Steven.D.Ligett@mac.dartmouth.edu Mon Jan  8 18:14:27 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Mon, 8 Jan 90 13:14:18 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Mon, 8 Jan 90 13:14:08 EST
Received: by mips.com (5.61.14/1.11) id AA18406; Mon, 8 Jan 90 10:13:26 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gl3eu-0000C7C@daver.uu.net>; Mon, 8 Jan 90 09:59 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!mac.dartmouth.edu!Steven.D.Ligett>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gl3eU-0000BeC@daver.uu.net>; Mon, 8 Jan 90 09:59 PST
Received: from dartvax.dartmouth.edu by uunet.uu.net (5.61/1.14) with SMTP 
	id AA20558; Mon, 8 Jan 90 12:40:15 -0500
Received: from d0.dartmouth.edu by dartvax.dartmouth.edu (5.61D1/4.0HUB)
	id AA10579; Mon, 8 Jan 90 12:39:55 -0500
Received: by D0.DARTMOUTH.EDU id <15757>; 8 Jan 90 12:39:54
Message-Id: <927591@mac.Dartmouth.EDU>
Date: 08 Jan 90 12:39:28
From: Steven.D.Ligett@mac.dartmouth.edu
To: pc532@daver.UU.NET (George Scolaro)
Subject: Re: faster ...
Status: RO

--- You wrote:
Hi Folks,
	the pc532 is now a tiny bit faster than before. The other day it
struck me that only 2 T-states (80ns) are needed to do a write access using
80ns drams (sort of obvious to me now).
--- end of quoted material ---
Yes, I think you originally planned for 85 ns rams - which is what was being
produced a couple of years ago.  After a "shrink", I think these all went to
80 ns.  (I just got a quote of $7.35 for 80 ns 1 megx1 drams in DIP package -
can you do better in supermarkets in the valley??)

From lyndon@cs.AthabascaU.CA Mon Jan  8 20:30:26 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Mon, 8 Jan 90 15:30:23 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Mon, 8 Jan 90 15:30:20 EST
Received: by mips.com (5.61.14/1.11) id AA23187; Mon, 8 Jan 90 12:29:44 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gl5v3-0000F8C@daver.uu.net>; Mon, 8 Jan 90 12:24 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!watmath!alberta!atha!lyndon>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gl5uw-0000AyC@daver.uu.net>; Mon, 8 Jan 90 12:24 PST
Received: from watmath.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA14316; Mon, 8 Jan 90 14:50:17 -0500
Received: from alberta.uucp by watmath.waterloo.edu with uucp
	id <AA29166>; Mon, 8 Jan 90 14:22:08 EST
Received: by pembina.alberta.UUCP (5.52/3.14)
	id AA05401; Mon, 8 Jan 90 11:31:29 MST
Received: by aurora.AthabascaU.CA (/\=-/\ Smail3.1.18.1 #18.26)
	id <m0gl3pg-00002uC@aurora.AthabascaU.CA>; Mon, 8 Jan 90 11:11 MST
Message-Id: <m0gl3pg-00002uC@aurora.AthabascaU.CA>
To: pc532@daver.uu.NET
Cc: rwa@cs.AthabascaU.CA (Ross Alexander)
Subject: Re: dirt cheap windowing? 
Date: Mon, 08 Jan 90 11:10:59 MST
From: lyndon@cs.AthabascaU.CA
Status: RO

Just talked to AT&T re BSD support for the 630. Boy was I off base :-)

To get the 630 code running under another system (everything except
layers, although it's probably included) you need to pick up a source
code license for the DMD 630 Software Development System. Once you
have that, AT&T will provide you with a source version of the 630
software that has been ported to SunOS. You're on your own from that
point. There is no support for this version, although the port was done
by someone at UCSD (I think) whose name and email address is included
in the release notes for the SunOS version.

Once upon a time, Dan Wolski was AT&T's product manager for the 630
in the US. You could try calling him at +1 312 810 7676 for further
information. If he's no longer there, track down the current 630
product manager.

I wasn't able to get a PEC or price for the source license.

-lyndon

From "george@wombat (George Scolaro)" Mon Jan  8 20:57:26 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Mon, 8 Jan 90 15:57:13 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Mon, 8 Jan 90 15:56:55 EST
Received: by mips.com (5.61.14/1.11) id AA24064; Mon, 8 Jan 90 12:56:20 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gl6LT-0000DmC@daver.uu.net>; Mon, 8 Jan 90 12:52 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <wombat!george>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gl6LM-0000FnC@daver.uu.net>; Mon, 8 Jan 90 12:51 PST
Received: by wombat.UUCP (smail2.5)
	id AA18455; 8 Jan 90 12:36:07 PST (Mon)
From: george@wombat (George Scolaro)
Date: Mon, 8 Jan 90 12:36:07 PST
In-Reply-To: daver!uunet!mac.dartmouth.edu!Steven.D.Ligett's message on Jan  8, 12:39.
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Subject: Re: faster ...
Message-Id: <9001081236.AA18455@wombat.UUCP>
Status: RO

> Yes, I think you originally planned for 85 ns rams - which is what was being
> produced a couple of years ago.  After a "shrink", I think these all went to
> 80 ns.  (I just got a quote of $7.35 for 80 ns 1 megx1 drams in DIP package -
> can you do better in supermarkets in the valley??)

Sounds like a good price. Of course you need the SIMMs for the PC532. I
haven't looked around too much over here, but around the $10 mark is
pretty average. What is the current x8 and x9 SIMM price. A guess its
less than $100 at this stage.

regards,

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From "Ken Yap <ken@cs.rochester.edu>" Mon Jan  8 21:36:49 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Mon, 8 Jan 90 16:36:46 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Mon, 8 Jan 90 16:36:42 EST
Received: by mips.com (5.61.14/1.11) id AA25472; Mon, 8 Jan 90 13:36:10 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gl6yI-0000G4C@daver.uu.net>; Mon, 8 Jan 90 13:32 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!cs.rochester.edu!ken>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gl6yE-0000G3C@daver.uu.net>; Mon, 8 Jan 90 13:32 PST
Received: from cayuga.cs.rochester.edu by uunet.uu.net (5.61/1.14) with SMTP 
	id AA28406; Mon, 8 Jan 90 16:19:23 -0500
Received: from slate.cs.rochester.edu by cayuga.cs.rochester.edu (5.59/o) id AA19998; Mon, 8 Jan 90 16:18:18 EST
Received: from localhost.ARPA by slate.cs.rochester.edu (4.0/o) id AA25610; Mon, 8 Jan 90 16:18:15 EST
Message-Id: <9001082118.AA25610@slate.cs.rochester.edu>
To: pc532@daver.UU.NET
Subject: X and all that
Reply-To: ken@cs.rochester.edu
In-Reply-To: Your message of Mon, 08 Jan 90 12:36:07 -0800.
             <9001081236.AA18455@wombat.UUCP> 
X-Uucp: ..!rochester!ken Internet: ken@cs.rochester.edu
X-Snail: CS Dept., U of Roch., NY 14627. Voice: Ken!
X-Phone: (716) 275-1448 (office) Fax: (716) 461-2018
Date: Mon, 08 Jan 90 16:18:14 -0500
From: Ken Yap <ken@cs.rochester.edu>
Status: RO

Somebody posted to comp.unix.xenix about how he'd ported MGR to Xenix.
MGR is the Bellcore windowing system and leaner than X and may be
easier to start off with. Sorry, I didn't save the article.

From "sef@kithrup.COM (Sean Eric Fagan)" Mon Jan  8 22:30:13 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Mon, 8 Jan 90 17:30:10 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Mon, 8 Jan 90 17:30:04 EST
Received: by mips.com (5.61.14/1.11) id AA27575; Mon, 8 Jan 90 14:29:58 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gl7WP-0000GmC@daver.uu.net>; Mon, 8 Jan 90 14:07 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <mips!ucscc.UCSC.EDU!kithrup!sef>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gl7WH-0000HHC@daver.uu.net>; Mon, 8 Jan 90 14:07 PST
Received: from ucscc.UCSC.EDU by mips.com (5.61.14/1.10) id AA26649; 
	Mon, 8 Jan 90 14:04:35 -0800 
Received: by ucscc.UCSC.EDU (5.61/1.35)
	id AA22742; Mon, 8 Jan 90 14:05:27 -0800
Message-Id: <9001082205.AA22742@ucscc.UCSC.EDU>
From: sef@kithrup.COM (Sean Eric Fagan)
To: pc532%daver@mips.com
Subject: Re: faster ...
Date: Mon, 8 Jan 90 14:00:26 PST
Status: RO

>Sounds like a good price. Of course you need the SIMMs for the PC532. I
>haven't looked around too much over here, but around the $10 mark is
>pretty average. What is the current x8 and x9 SIMM price. A guess its
>less than $100 at this stage.

There is a company, I think in Silicon Valley, which advertises "the lowest
SIMM prices"; from behaviour posted to UseNET, they seem to mean it
(somebody found a posting showing lower prices, and called these people up;
they verified and then lowered their own prices to beat the competition).  I
do not know the name of the company, but they are advertised in Computer
Currents, or Chronicles; whatever that free trade-rag is.  Any readers of
comp.sys.next?  (I was told of them by someone who read about them
there...)

Mayhap they give large-order discounts?

Sean.
sef@sco.COM

P.S.  Their price was somewhere between $60 and $70 for 1Mbyte SIMMs (for a
NeXT, I think), but I'm not sure of the speed.  It was possibly 80ns, but
I'm not sure, and prices will undoubtedly have changed since then.
SEF


From John.J.Ackley@equi.com Mon Jan  8 22:33:46 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Mon, 8 Jan 90 17:33:43 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Mon, 8 Jan 90 17:33:39 EST
Received: by mips.com (5.61.14/1.11) id AA27703; Mon, 8 Jan 90 14:33:32 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gl7jN-0000HaC@daver.uu.net>; Mon, 8 Jan 90 14:20 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!cis.ohio-state.edu!equicom!John.J.Ackley>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gl7jB-0000GzC@daver.uu.net>; Mon, 8 Jan 90 14:20 PST
Received: from saqqara.cis.ohio-state.edu by uunet.uu.net (5.61/1.14) with SMTP 
	id AA03652; Mon, 8 Jan 90 16:46:10 -0500
Received: by saqqara.cis.ohio-state.edu (5.61/4.891221)
	id AA23243; Mon, 8 Jan 90 16:45:39 -0500
Received: by equi.com (smail2.5)
	id AA08487; 8 Jan 90 16:16:05 EST (Mon)
To: pc532@daver.uu.NET
Subject: scsi equipment
Date: 8 Jan 90 16:16:05 EST (Mon)
From: John.J.Ackley@equi.com
Message-Id: <9001081616.AA08487@equi.com>
Status: RO


Does anybody happen to know of a good outlet for
scsi flop/hard disks?  I do have a few catalogs that
carry hard disks, but no floppies.  We have a TEAC 2.6M
scsi floppy in Motorola's cloths here at work, but our
distributor says I would probably get better prices elsewhere.
Anybody know where that might be?

Refurbished drives might be ok if the source has a good reputation.

On the chip-side, I can't find a few chips anywhere, notably the
7414 (not in any flavor) and the 74AS258.  I'm not worried yet,
I have ordered a few catalogs that may have them. But if anyone
knows of a good supply, I (and probably others) would be grateful.

Also, I'm ready to start pricing one meg SIMM's.  JDR has 1Mx9 sticks,
but I don't know if they are page mode.  (What is that anyway?)

Thanks a poodle,

John Ackley <john@equi.com>

From "John L. Connin <johnc%manatee%uunet@daver>" Mon Jan  8 22:34:02 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Mon, 8 Jan 90 17:33:58 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Mon, 8 Jan 90 17:33:53 EST
Received: by mips.com (5.61.14/1.11) id AA27715; Mon, 8 Jan 90 14:33:43 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gl7jb-0000HCC@daver.uu.net>; Mon, 8 Jan 90 14:21 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!tarpit!manatee!johnc>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gl7jR-0000G8C@daver.uu.net>; Mon, 8 Jan 90 14:20 PST
Received: from tarpit.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA11345; Mon, 8 Jan 90 17:19:37 -0500
Message-Id: <9001082219.AA11345@uunet.uu.net>
Received: by tarpit.UUCP (smail2.5)
	id AA21524; 8 Jan 90 11:34:46 EST (Mon)
Subject: Group DRAM purchase ??
To: pc532%tarpit@daver.uu.NET
Date: Mon, 8 Jan 90 11:34:35 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]
Status: RO


[Jon Loelier writes]

> I located a local DRAM supplier and want to check out their offerings.  I'd
> like to make sure I ask for the right thing...  What sort of price range
> should I expect?  Also, if they can quote the Right Price does everyone
> still need RAM and might we buy in bulk (50 boards(?) * 4)?   (Actually,
> are some of us are doing parity and others not?  Is this decision price
> dependent for some?)

Lets assume that it is possible to negotiate a group DRAM purchase wherein the
supplier agrees to drop ship COD directly to each party.  If this could be
arranged, then each party could simply place his/her order by calling the
designated supplier contact.

Anyone willing volunteer to coordinate / negotiate such a deal ??  

Sorry, I do not currently have the time.

regards,
johnc


From "george@wombat (George Scolaro)" Tue Jan  9 01:31:38 1990
Flags: 000000000001
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Mon, 8 Jan 90 20:31:31 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Mon, 8 Jan 90 20:31:23 EST
Received: by mips.com (5.61.14/1.11) id AA03099; Mon, 8 Jan 90 17:31:18 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0glAR2-0000A4C@daver.uu.net>; Mon, 8 Jan 90 17:14 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <wombat!george>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0glAQq-00008kC@daver.uu.net>; Mon, 8 Jan 90 17:13 PST
Received: by wombat.UUCP (smail2.5)
	id AA19243; 8 Jan 90 17:11:32 PST (Mon)
From: george@wombat (George Scolaro)
Date: Mon, 8 Jan 90 17:11:31 PST
In-Reply-To: daver!uunet!equi.com!John.J.Ackley's message on Jan  8, 16:16.
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Subject: Re: scsi equipment
Message-Id: <9001081711.AA19243@wombat.UUCP>
Status: RO

[In the message entitled "scsi equipment" on Jan  8, 16:16, daver!uunet!equi.com!John.J.Ackley writes:]

> On the chip-side, I can't find a few chips anywhere, notably the
> 7414 (not in any flavor) and the 74AS258.  I'm not worried yet,
> I have ordered a few catalogs that may have them. But if anyone
> knows of a good supply, I (and probably others) would be grateful.

Both Jameco and Digikey advertise the 7414 in different flavours,
the HCT type probably being the best choice. Its only used to generate
the RESET.

> Also, I'm ready to start pricing one meg SIMM's.  JDR has 1Mx9 sticks,
> but I don't know if they are page mode.  (What is that anyway?)
> John Ackley <john@equi.com>

JDR pricing (and Jameco's) are generally high for DRAM devices. Your
better bet are places that specialise in selling DRAM stuff.
The NEC part number that is needed is:

	MC-421000A8-80		for the x8 (no parity) or
	MC-421000A9-80		for the x9 (parity)

The TOSHIBA part number is:

	THM81000AS-80		for the x8
	THM91000AS-80		for the x9

Note that the devices must be unleaded, i.e. for use in sockets.

Page mode is the fast operation mode supported by the devices. Common
modes for drams are: page mode, static column and nibble mode. Most
386 machines use page mode, hence it is easier to get.

regards,

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From blank%clanhlm@ucscc.UCSC.EDU Tue Jan  9 01:37:15 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Mon, 8 Jan 90 20:37:08 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Mon, 8 Jan 90 20:37:00 EST
Received: by mips.com (5.61.14/1.11) id AA03280; Mon, 8 Jan 90 17:36:53 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0glAa0-0000AIC@daver.uu.net>; Mon, 8 Jan 90 17:23 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!ucscc.UCSC.EDU!clanhlm!blank>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0glAZq-0000HZC@daver.uu.net>; Mon, 8 Jan 90 17:23 PST
Received: from ucscc.UCSC.EDU by uunet.uu.net (5.61/1.14) with SMTP 
	id AA23761; Mon, 8 Jan 90 18:16:04 -0500
Received: by ucscc.UCSC.EDU (5.61/1.35)
	id AA25458; Mon, 8 Jan 90 15:16:47 -0800
Received: by clanhlm.UUCP (smail2.5)
	id AA10481; 8 Jan 90 13:00:41 PST (Mon)
To: pc532@daver.UU.NET
Subject: Re: X server (flame wars! :-)
Date: Mon Jan  8 13:00:40 1990
Message-Id: <9001081300.AA10481@clanhlm.UUCP>
From: blank%clanhlm@ucscc.UCSC.EDU
Status: RO

	I have some experience with gcc.  The shortest port I have ever seen
	was a 1 week port (to an ARM).  Usually, if the semantics of the
	CPU map well into the semntics of gcc (think about a VAX...),
	you can get a good port in under 3 months.  If they don't,
	it can take a long time.  In theory, all that has to be done
	is to write a new machine description, an assembly outputter,
	and the peep hole stuff.  In reality, there is a good deal more
	which has to happen.  Exactly what varies with the processor.

					John


From "John L. Connin <johnc%manatee%uunet@daver>" Tue Jan  9 01:46:30 1990
Flags: 000000000001
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Mon, 8 Jan 90 20:46:26 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Mon, 8 Jan 90 20:46:22 EST
Received: by mips.com (5.61.14/1.11) id AA03585; Mon, 8 Jan 90 17:46:15 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0glAp5-00000XC@daver.uu.net>; Mon, 8 Jan 90 17:38 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!tarpit!manatee!johnc>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0glAot-0000BPC@daver.uu.net>; Mon, 8 Jan 90 17:38 PST
Received: from tarpit.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA25272; Mon, 8 Jan 90 20:34:51 -0500
Message-Id: <9001090134.AA25272@uunet.uu.net>
Received: by tarpit.UUCP (smail2.5)
	id AA24567; 8 Jan 90 20:23:34 EST (Mon)
Subject: Build List Revision 1.01
To: pc532%tarpit@daver.uu.NET
Date: Mon, 8 Jan 90 20:23:02 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]
Status: RO


----------------------------------------------------------------------------------------------------------------

                        pc532 Build List

        Parts List Revision :  1.01
        Date last revision  :  7 jan 90
        BOM reference       :  Version 1D
        Contact             :  J.L. Connin     tarpit!manatee!johnc


        Table of Contents   :
                1.0  Introduction
                1.1  Notes / History
                1.2  Legend
                1.3  Supplier Names and Addresses
                2.0  Bill of Materials
                2.1  BOM pc532, kit parts
                2.2  BOM pc532, user supplied parts
                2.3  BOM - Ancilary Items
                3.0  Construction Notes

----------------------------------------------------------------------------------------------------------------

1.0  Introduction
-----------------

    The intent of the Build List is provide an resource of information
    related to the physical construction of the pc532 (ie. sources of
    supply, construction hints, etc).

    Very simply, from time to time, I will post to the pc532 mailing list
    an updated copy of the Build List based upon input I receive from YOU,
    the pc532 members.


1.1  Notes / Revisions:
-----------------------
    1)  johnc, 22dec89, received version 1D BOM (ie. pcb fab release) from george.
    2)  johnc, 22dec89, started ancilary BOM section
    3)  johnc, 07jan90, split BOM into kit and user supplied parts, also grouped
                        like parts together
    4)  johnc, 07jan90, added more ancilary parts
    5)  johnc, 07jan90, added suppliers

1.2  Legend:
-----------

    *  -  Included in pc532 kit

    All other parts (ie. those not prefixed by '*') are user supplied.

    Source of supply of user supplied parts, were known, is indicated
    immediately after the part description in the BOM.  The source of
    supply fields, from left to right are:  Distributor, catalog page
    number, distributor part number, and part price.  For example,

        JDR,            page85,         NOSLOT-CLK      29.95


1.3  Supplier Names and Addresses:
---------------------------------

        Distributor     Reference               Minimum         Telephone
        -----------     ------------            -------         ----------------
        JDR             1990 Catalog,                           1-800-538-5000
        Jameco          1990 Catalog,           $25.00          1-415-592-8097
        Digi-key        Nov-Dec89                               1-800-344-4539

        Arrow Elec.                             $25.00          1-800-932-7769
        Allied Elec.                            $25.00          1-800-433-5700

Where possible, your local surplus outlets are probably your best
source of supply.



2.0  Bill of Materials
----------------------

---------------------------------------------------------------------------------------------------
2.1  BILL OF MATERIALS     32532 AT MOTHERBOARD        V 1D Thu Dec 21 23:25:07 1989    PAGE   1
     pc532 kit parts
---------------------------------------------------------------------------------------------------


     ITEM   QUAN.               DESCRIPTION                                         REF. DES.

*      5       2	CAPACITOR,50PF,                                             C23,C24         
*      7       1	CRYSTAL, 3.6864MHZ                                          XTAL1           
*     11       1	RESISTOR PACK,1K, 6 pin SIP, 5 common resistors             RES1            
*     14       2	FUSE, 1 Amp Pico Fuse for SCSI                              F1,F2           
*     16       6	RESISTOR,22, 8 pin Sip, 4 separate resistors                RES2,RES5,RES6
*     17       2	RESISTOR,220, 8 pin Sip, 4 separate resistors               RES15,RES16     
*     18       4	RESISTOR,47, 8 pin Sip, 4 separate resistors                RES10,RES11,RES3
                                                                                    RES4
*     19       1	RESISTOR,4K7, 16 pin Dip, 15 common resistors               RES13           
*     24       4	SCSI62 - THE 62 PIN IBM PC/AT BUS CONNECTOR                 CONN12,CONN13   
                                                                                    CONN14,CONN15
*     35       4	2681/2692 - DUAL CHANNEL DUART                              U48,U52,U55,U60 
*     36       1	74ALS6311 - STATIC COLUMN/PAGE MODE ACCESS DETECTOR         U36             
*     37       4	220/330 OHM 14 PIN DIP TERMINATOR                           RES12,RES14     
                                                                                    RES17,RES18
*     39       1        27256 - UV ERASABLE PROM 32KX8, 200 ns                      U44
*     41       2        PAL16L8 - PROGRAM ARRAY LOGIC, B - SPEED,                   U37,U40
*     42       1        PAL16R6 - PROGRAM ARRAY LOGIC, B - SPEED,                   U38
*     43       1        PAL16R8 - PROGRAM ARRAY LOGIC, D - SPEED,                   U39
*     44       1        PAL20L8 - PROGRAM ARRAY LOGIC, D - SPEED,                   U19
*     45       1        20V8A-CMOS-GAL-15ns ELECTRICALLY ERASABLE                   U20
*     46       1        32202 - 32000 INTERRUPT CONTROL UNIT, 10Mhz                 U46
*     47       1        32532 - 32000 SERIES HIGH PERF.  32 BIT BUS CPU, 25Mhz      U35
*     48       1        32381 - 32000 SERIES 32 BIT BUS FPU, 25Mhz                     U24
*     53       2	74AS832 - HEX 2 INPUT OR DRIVERS                            U14,U15         
*     54       1	AIC6250 - HIGH PERFORMANCE SCSI PROTOCOL CHIP               U41             
*     56       1	DP8490 - ENHANCED ASYNCHRONOUS SCSI INTERFACE (EASI)        U57             
				  44 pin PLCC package
*     57       1	IBMPOW - IBM AT POWER CONNECTOR                             CONN11          
*     59       8	MC145406 - HEX RS232 CMOS TRANSCEIVER                       U47,U49,U51,U53 
                                                                                    U54,U56,U59,U61

*      1       5                44 pin PLCC sockets (for scsi and duarts)
*      2       1                68 pin PLCC sockets (for AIC-6250)
*      3       1                175 pin PGA socket (for 32532 CPU)
*      4       1                68 pin PGA socket (for 32381 FPU)
*      5       8                30 pin sockets (for unleaded SIMM memory modules)


---------------------------------------------------------------------------------------------------
2.2  BILL OF MATERIALS     32532 AT MOTHERBOARD        V 1D Thu Dec 21 23:25:07 1989    PAGE   1
     pc532 user supplied parts
---------------------------------------------------------------------------------------------------

     ITEM   QUAN.               DESCRIPTION                                         REF. DES.

       1      69        CAPACITOR, 0.1uf, 0.3 inch spacing, Monolithic Bypass           C1,C10,C11,C12
                                C13,C14,C15,C16,C17,C18,C19,C2,C20,C21,C22,C25
                                C26,C27,C28,C29,C3,C30,C31,C32,C33,C34,C35,C36
                                C37,C38,C39,C4,C40,C41,C42,C43,C44,C45,C46,C48,
                                C49,C5,C50,C51,C52,C53,C54,C55,C56,C57,C58,C6
                                C61,C62,C63,C64,C65,C66,C69,C7,C70,C71,C72,C73,
                                C74,C76,C78,C8,C9

       2       1	CAPACITOR,10PF,                                             C75             

       3       4	CAPACITOR,10UF,25V                                          C59,C60,C67,C68 

       4       1	CAPACITOR,33UF,16V                                          C47             

       6       1	CAPACITOR,5PF,                                              C77             
----
       8       1	DIODE, IN4148                                               D2              
                        Digikey         p49,            1N4148          0.60/10

       9       2	DIODE, IN5817 (SCSI DIODE, Schottky)                        D1,D3           
                        Digikey         p49,            1N5817          0.48

      10       4	LIGHT EMITTING DIODE, (0.1 inch centers, end stackable)     LED1,LED2,LED3  
                                                                                    LED4
----
      12       1	RESISTOR,100, 1/4W, 5%                                      R2              

      13       3	RESISTOR,10K, 1/4W, 5%                                      R1,R4,R5        

      15       1	RESISTOR,1K, 1/4W, 5%                                       R6              

      20       2        RESISTOR,???, BCLK, /BCLK terminator (TBD)                  R3,R7
----
      21       1	74AS00 - AS TTL QUAD TWO INPUT NAND                         U30             

      22       1	74ALS14 - ALS TTL HEX INVERTER WITH SCHMITT TRIGGER         U42             

      23       1	74AS32 - AS TTL QUAD 2 INPUT OR GATE                        U58             

      25       2	74AS74 - AS TTL DUAL D FLIP-FLOP                            U31,U32         

      26       1	74F138 - FAST TTL 3/8 DECODER                               U33             
                        Digikey         p33,            74F138PC        0.79

      27       2	74AS174 - AS TTL HEX D FLIP-FLOP                            U26,U50         

      28       3	74AS258 - AS TTL QUAD 2 TO 1 MUX, INVERTED TS OUTPUT        U27,U28,U29     

      29       4	74AS280 - AS TTL 9-BIT PARITY GEN/CHK                       U1,U2,U3,U4     

      30       1	74AS374 - AS TTL OCTAL FLIP-FLOP WITH TS OUTPUT             U16             

      31       1	74AS646 - AS TTL OCTAL REGISTERED/TRANS WITH TS OUT         U43             

      32       4	74AS1004A - AS TTL HEX INVERTING DRIVER                     U17,U21,U22,U5  

      33       1	74ALS1034A - ALS TTL HEX NON-INVERTING DRIVER               U45             

      34       2        74AS1034A - AS TTL HEX NON-INVERTING DRIVER                 U18,U23
----

      40       8        MSC411024 -  1M X 9 BIT DYNAMIC RAM MODULE                  U10,U11,U12,U13 
				  OR 1M X 8 (FOR NO PARITY), FAST PAGE 80 ns        U6,U7,U8,U9
				  Toshiba part # THM81000AS-80 (1M X 8)
			4 SIMMs are the minimum configuration

---
      38       1        XTALM - CRYSTAL OSCILLATOR MODULE, 50Mhz                    U25
                        Digikey,        page61,         x121,           6.19

      52       1        CRYSTAL OSCILLATOR MODULE, 20MHZ                            U34
                        Digikey         p51,            x119            5.78
---

  +-  49       1        JUMP1 - SINGLE JUMPER HEADER                                J3
  +-  50       2        JUMP3 - 3 PIN JUMPER                                        J1,J2
  |                     JDR
  +-->         1        Header Pins, 1 x 40, straight male
                        JDR,                            HDR-40,         $0.99

  +-  51       1        JUMP4 - 4 LOCATION JUMPER BLOCK                             CONN2
  +-  55       2        50 WAY TRANSITION CONNECTOR UNSHROUDED (JUST PINS)          CONN1,CONN16
  +-  58       8        JUMP10 - 10 WAY JUMPER BLOCK UNSHROUDED (JUST PINS)         CONN10,CONN3
  |
  +-->         3        Header Pins, 2 x 40, straight male
                        JDR                             HDR-80,         $2.49


---------------------------------------------------------------------------------------------------
2.3  BILL OF MATERIALS    32532 AT BOARD
     ANCILLARY ITEMS
---------------------------------------------------------------------------------------------------


     100       1        NO-SLOT CLOCK
                        JDR,    page85,         NOSLOT-CLK      29.95

     101      21        IC socket, 14-pin, 0.3 inch width, solder tail, machined
                        JDR,                    AUGAT14,        $0.59

     102      14        IC socket, 16-pin, 0.3 inch width, solder tail, machined
                        Augat 800 series or equivalent

     103       7        IC socket, 20-pin, 0.3 inch width, solder tail, machined
                        Augat 800 series or equivalent

     104       3        IC socket, 24-pin, 0.3 inch width, solder tail, machined
                        JDR,                    AUGAT24SK,      $0.95

     105       1        IC socket, 28-pin, 0.6 inch width, solder tail, machined
                        JDR,                    AUGAT28,        $1.09

     106       1        IC socket, 40-pin, 0.6 inch width, solder tail, machined
                        JDR,                    AUGAT40,        $1.29
-------

     110       8        Connector, IDS, 10-contact, (ie. serial cable assy)
                        JDR, IDS10, $0.55
                        Jameco,                 S10,            $0.59

     111       4        Connector, IDS, 50-contact  (ie. scsi  cable assy)
                        JDR,                    IDS50,          $1.69
                        Jameco,                 S50,            $1.39

     112       8        Connector, IDC, D-Sub, 9-pin, male, (ie. serial cable assy)
                        JDR,                    IDB09P,         $1.39
                        Jameco,                 CDE9P,          $2.39

     113      ---       25 to 9=pin serial adapter
                        JDR,                    GENDER-9-25,    $4.95

     114       1        Connector, 2-pin                 (ie. reset cable assy)

     115       1        Switch, momentary, normally open (ie. reset cable assy)

-------

     120       4        Shorting Blocks
                        JDR,                    JUMPER,         $0.20


3.0  Construction Notes.
------------------------

     (If this section gets to large, will split out as separate document).

1). Re: CAPACITOR,0.1, 0.3inch spacing, Monolithic Bypass
    Q.  Are these standard disc or IC-look-alike mounts?  Um, units are PF?

    A.  0.1 microfarads (decoupling caps), IC look-alike-mounts.

2). Re: RESISTOR,???, BCLK, /BCLK terminator (TBD)        R3,R7
    Q.  Has this value been determined yet or is it it some sort of tuning 
        or timing resister that must in some way be determined on a per 
        board basis?
    A.  George writes: The prototypes worked fine without, but when I get 
        the new pcbs and build one up, I'll stick a 400mhz scope on and 
        determine the best value.

3). Re: 49       1	JUMP1 - SINGLE JUMPER HEADER                  J3
        50       2	JUMP3 - 3 PIN JUMPER                          J1,J2
        51       1	JUMP4 - 4 LOCATION JUMPER BLOCK               CONN2
        55       2	50 WAY TRANSITION CONNECTOR UNSHROUDED (JUST PINS) 
                        CONN1,CONN16    

   George writes: JUMP1 is 2 pins 0.1 inch centers. JUMP3 is 3 pins 0.1
   inch centers. JUMP4 is 4 x 2 pins 0.1 inch centers. The 50 way is 
   25 x 2 pins 0.1 inch centers (unshrouded, ie just the pins in a plastic 
   carrier).

4). Question:  How static sensitive are some of these parts?  Are all the
    critical parts socketed so that I don't need to worry about blowing
    them during soldering etc?  Also, any requirements or advice on soldering
    this puppy?  60-40 tin/lead rosin core solder good enough?

    George writes: The only static sensitive parts are the EPROM, the DRAM, 
    the CPU, FPU, RS232 CMOS driver/receivers, DUARTs, SCSI devices. Just 
    use the normal precautions, ie don't touch the chips until they are 
    ready to plug in, leave them in the antistatic package until you're ready.
    Then when you pick them up, touch the ground on the PCB before plugging 
    them in. Normal solder is fine.  We are supplying the sockets for the CPU,
    FPU,DRAM,SCSIs and DUARTs. The rest of the sockets will be your problem.
    I recommend could quality machined pin sockets, they cost a bit more but
    are well worth it.


From "John L. Connin <johnc%manatee%uunet@daver>" Tue Jan  9 03:41:21 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Mon, 8 Jan 90 22:41:14 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Mon, 8 Jan 90 22:41:07 EST
Received: by mips.com (5.61.14/1.11) id AA06720; Mon, 8 Jan 90 19:41:04 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0glCgL-0000CdC@daver.uu.net>; Mon, 8 Jan 90 19:38 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!tarpit!manatee!johnc>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0glCgF-00008rC@daver.uu.net>; Mon, 8 Jan 90 19:37 PST
Received: from tarpit.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA06389; Mon, 8 Jan 90 21:16:43 -0500
Message-Id: <9001090216.AA06389@uunet.uu.net>
Received: by tarpit.UUCP (smail2.5)
	id AA24801; 8 Jan 90 20:59:54 EST (Mon)
Subject: Objectives (was X discussion)
To: pc532%tarpit@daver.uu.NET
Date: Mon, 8 Jan 90 20:59:02 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]
Status: RO


Earlier I did a dumb thing which wiped out my pc532 messages since
1jan90.  The only reason I mention this is that I can not quote
the recent X discussion.

I can not fault Ken Seefried's argument that purchasing a X terminal,
or other packaged solution is a much simpler solution.  However, in my 
case, this approach is counter to the reason I decided to get involved with 
the pc532 project.  

As hobby activity I want to be associated / involved with the design and 
implementation (hardware and software) of a engineering workstation class 
computer.  Simply, I saw the pc532 project as a vehicle to achieve this
objective.  Quite frankly, if my objective were otherwise, I would have been
better off buying a 386 motherboard than a pc532 kit.

This message should not be construed as a flame of any previous discussion.

regards,
johnc


From "george@wombat (George Scolaro)" Tue Jan  9 04:56:44 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Mon, 8 Jan 90 23:56:40 EST
Received: from BU.EDU by bu-it.bu.edu (12/20/89); Mon, 8 Jan 90 23:56:38 EST
Received: from MIPS.COM by BU.EDU (1.97) Mon, 8 Jan 90 23:56:32 EST
Received: by mips.com (5.61.14/1.11) id AA07975; Mon, 8 Jan 90 20:54:52 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0glDpa-0000DDC@daver.uu.net>; Mon, 8 Jan 90 20:51 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <wombat!george>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0glDpV-0000C1C@daver.uu.net>; Mon, 8 Jan 90 20:51 PST
Received: by wombat.UUCP (smail2.5)
	id AA19389; 8 Jan 90 20:28:41 PST (Mon)
From: george@wombat (George Scolaro)
Date: Mon, 8 Jan 90 20:28:41 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver
Subject: progress
Message-Id: <9001082028.AA19389@wombat.UUCP>
Status: RO

Hi folks,
	this email is just to keep you up with the progress being made
to get the pc532 kits together.

Today we paid 1/2 the PCB costs to the PCB house. They were happy and
have stated any further work with them will have a net 30 day. Nice for
any further boards that get done. The salesman stated that the 24th of
Jan is still the target delivery date.

Tomorrow we put down around $3k on components that can only be ordered
with up front payment. These include the AIC6250, the 74ALS6311 (which
they fortunately have exactly 65), etc. At this stage the only parts
that have a flakey chance of delivery are the 74AS832B's. We'll find
out more over the next few days. These components are all being ordered
through WYLE (a large US distributor).

Today I got a phone call to tell me that the 532 and 381 PGA sockets
are ready for pickup.

all in all, going smoothly,

regards,

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From "Johan Myreen <jem@cs.hut.fi>" Tue Jan  9 12:11:12 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Tue, 9 Jan 90 07:11:03 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Tue, 9 Jan 90 07:10:54 EST
Received: by mips.com (5.61.14/1.11) id AA15831; Tue, 9 Jan 90 04:10:49 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0glKcM-0000E1C@daver.uu.net>; Tue, 9 Jan 90 04:06 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!cs.hut.fi!jem>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0glKcE-00008rC@daver.uu.net>; Tue, 9 Jan 90 04:06 PST
Received: from santra.hut.fi by uunet.uu.net (5.61/1.14) with SMTP 
	id AA14691; Tue, 9 Jan 90 05:28:10 -0500
Received: from sauna.hut.fi by santra.hut.fi
	(5.61++/7.0/TeKoLa) id AA08803; Tue, 9 Jan 90 01:29:09 +0200
Received: by cs.hut.fi (4.0/6.8/S-TeKoLa)
	id AA02716; Tue, 9 Jan 90 01:29:06 +0200
Date: Tue, 9 Jan 90 01:29:06 +0200
From: Johan Myreen <jem@cs.hut.fi>
Message-Id: <9001082329.AA02716@cs.hut.fi>
To: pc532@daver
In-Reply-To: ken%mm@gatech.edu's message of 8 Jan 90 04:15:08 GMT (Mon)
Subject: Re: X server
Status: RO


>Server.  In practice, however, I would imagine any 340x0 based
>board for the pc532 would have some sort of control processor (32gc16,
>68000, etc.) running a mini-OS that would deal with the SCSI bus and 
>fielding I/O requests from the GP and leave the '010 to pushing 
>bits around the VRAM.  Regardless of what TI might like you to 
>believe, making a 34010 field SCSI I/O, keyboard and mouse traffic 
>would *seriously* affect video performance.

Ok, ok. But I see the choice as being between one CPU (the
traditional, Sun 3/50 model) and two CPUs (one host and one X server
processor). I want to keep the design simple and therefore I don't
want to throw in a third processor. This was in fact one of the
reasons I got excited about the 34010: it can function both as a
graphics controller and a host running the server software.  I don't
think a mouse or a keyboard has any significant influence on video
performance. How much the SCSI traffic affects video performance of
course depends on the bandwidth needed by the X protocol. Somebody
mentioned some figures a while ago, but I have lost them.

Adding a control processor on the "host bus" side would free the 34010
>From managing the SCSI connection, but SCSI data (a large bitmap, for
instance) would still be transferred via the local bus, because the
34010's memory is connected to this bus.

>Well...it's not less hardware, at least not in the X sense.
>"less harware" means as close to the dumb frame-buffer, main
>processor does everything model (ie Sun 3/50) as you can get.

That is exactly the meaning I give to those words too. I said in my
previous message that "the 34010 is less hardware in the sense that it
has a memory mapped frame buffer". My idea is that you should try to
get the server up and running quickly, by simply ignoring
34010-specific instructions like "LINE" and so on. You just use it as
a stupid frame buffer video display controller. Later you can speed it
up by rewriting stuff in assembler using instructions like "FILL",
"LINE" and "DRAV" etc.

>With the 34010-based SCSI video card that has been proposed,
>you still have to deal with some rather complicated interactions
>between the GP, the control processor and the host.

Remember, adding a control processor was your proposal :-)

>and send video output.  The X server still needs to request and
>recieve fonts and bitmaps from the host machine, as well as
>network (ethernet or SLIP) traffic.

In this case no network is involved, all the traffic is over the SCSI
bus.

--
Johan Myreen
jem@cs.hut.fi

From owner-pc532%daver@mips.com Tue Jan  9 18:14:24 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: george@wombat (George Scolaro)
Date: Tue, 9 Jan 90 14:28:22 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Subject: Re: DRAMs...
Status: O

[In the message entitled "DRAMs..." on Jan  9, 11:26, Nicolai Kosche writes:]
> Most discussion is centering on 1Mb SIMMs...  What is needed to install
> 4Mb SIMMs?  Are they available?  What is the cost difference?  4x or is
> the cost differential greater?
> 
> Nick Kosche
> nk@sybase.com

The pc532 supports 1m or 4m SIMMs. There are two berg headers that enable
selection of the DRAM size. That's all there is to it. Regarding availability,
I have seen some manufacturers claiming they have them. The last price I saw
was around $700 to $800. Of course this price will drop like a brick as soon
as a couple of sources come on line and the big companies start using them.

regards,


-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From "Bob Izenberg <xtserv!bei@bu-it.bu.edu>" Tue Jan  9 18:21:09 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Tue, 9 Jan 90 13:21:02 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Tue, 9 Jan 90 13:20:59 EST
Received: by mips.com (5.61.14/1.11) id AA23575; Tue, 9 Jan 90 10:20:55 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0glQFu-0000DsC@daver.uu.net>; Tue, 9 Jan 90 10:07 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <attctc!puzzle!xtserv!bei>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0glQFp-0000E4C@daver.uu.net>; Tue, 9 Jan 90 10:07 PST
Received: by attctc.Dallas.TX.US (killer) (/\=-/\ Smail3.1.18.1 #18.1)
	id <m0glLQT-0003QmC@attctc.Dallas.TX.US>; Tue, 9 Jan 90 06:58 CST
Received: by puzzle.UUCP (/\=-/\ Smail3.1.16.1 #16.11)
	id <m0glKgW-0000m0M@puzzle.UUCP>; Tue, 9 Jan 90 06:10 CST
Received: by xtserv.UUCP (UUPC/pcmail 1.0095) with UUCP; Mon, 09 Jan 89 06:09:02 CDT
Date: Mon, 09 Jan 89 06:09:02 CDT
From: Bob Izenberg <xtserv!bei@bu-it.bu.edu>
Message-Id: <23c892ce@xtserv.UUCP>
X-Mailer: UUPC/mail 1.095
To: pc532%daver%attctc@puzzle
Subject: More 5620/630 opines
Status: RO

ken seefried iii wrote:
: I have programmed a 5620 (GaTech used to have hundreds of them), and while
: very funky, I wouldn't consider it a bear, in the sense of, say, writing
: 8086 assembly...:')

Well, yeah... If it's a bear, it's an old, under-supported bear.
: It is also my understanding that the 5620 and the 630 are source code
: compatable (different processors).  I am far from sure on this, though.
Source code incompatible, sad to say.  Anyway, the 5620 gets me kinda misty
eyed... Eyestrain, or nostalgia, from viewing what to me will always be a
very tall Kaypro CRT?  I dunno.  I'll get some better informed diffs between
the two if there's interest.
Side note:  I'll see if I can't find out PEC/comcodes for the 630 Developer's
kit, and who the product mangler is.
-- Bob
-- 
 ------------------------------------------------------------------------------
                     Bob Izenberg [ ] Ralph Kirkley Associates
              attctc!puzzle!bei    512 346 7019 (home)    Austin, TX
 ------------------------------------------------------------------------------

From Steven.D.Ligett@mac.dartmouth.edu Tue Jan  9 18:31:11 1990
Flags: 000000000001
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Tue, 9 Jan 90 13:31:08 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Tue, 9 Jan 90 13:31:03 EST
Received: by mips.com (5.61.14/1.11) id AA22782; Tue, 9 Jan 90 10:01:54 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0glQ76-0000E0C@daver.uu.net>; Tue, 9 Jan 90 09:58 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!mac.dartmouth.edu!Steven.D.Ligett>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0glQ6z-0000HLC@daver.uu.net>; Tue, 9 Jan 90 09:58 PST
Received: from dartvax.dartmouth.edu by uunet.uu.net (5.61/1.14) with SMTP 
	id AA07662; Tue, 9 Jan 90 10:16:49 -0500
Received: from d0.dartmouth.edu by dartvax.dartmouth.edu (5.61D1/4.0HUB)
	id AA24948; Tue, 9 Jan 90 10:16:40 -0500
Received: by D0.DARTMOUTH.EDU id <16376>; 9 Jan 90 10:16:49
Message-Id: <931914@mac.Dartmouth.EDU>
Date: 09 Jan 90 10:13:04
From: Steven.D.Ligett@mac.dartmouth.edu
To: pc532@daver.UU.NET (George Scolaro)
Subject: Re: faster ...
Status: RO

--- You wrote:
What is the current x8 and x9 SIMM price. A guess its
less than $100 at this stage.
--- end of quoted material ---
The most price activity seems to be in the x8 market -- for Macs.  (I was
buying the DIPs to make "DIP SIMMs" for Macs.)  Advertisers in the back of
MacWeek have prices as low as $69 for 1 meg by 8 SIMMs.  Beware, however -
many of these places are selling "homemade" SIMMs; they buy 80 ns drams and
assemble them on PCBs.  However, the assemblys are not speed tested. 
Depending on the design and quality of the board, they may be 5 or 10 ns
slower than the speed of the chip that's on them.

From "John L. Connin <johnc%manatee%uunet@daver>" Tue Jan  9 19:03:55 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Tue, 9 Jan 90 14:03:52 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Tue, 9 Jan 90 14:03:45 EST
Received: by mips.com (5.61.14/1.11) id AA25088; Tue, 9 Jan 90 11:03:42 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0glR4N-00000SC@daver.uu.net>; Tue, 9 Jan 90 10:59 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!tarpit!manatee!johnc>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0glR4G-0000ElC@daver.uu.net>; Tue, 9 Jan 90 10:59 PST
Received: from tarpit.UUCP by uunet.uu.net (5.61/1.14) with UUCP 
	id AA09510; Tue, 9 Jan 90 13:40:51 -0500
Message-Id: <9001091840.AA09510@uunet.uu.net>
Received: by tarpit.UUCP (smail2.5)
	id AA28965; 9 Jan 90 10:11:08 EST (Tue)
Subject: Re: scsi equipment
To: pc532%tarpit@daver.uu.NET
Date: Tue, 9 Jan 90 1:40:35 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]
Status: RO


[ in <9001081616.AA08487@equi.com>, John Ackley writes ]

> Does anybody happen to know of a good outlet for
> scsi flop/hard disks?  I do have a few catalogs that
> carry hard disks, but no floppies.  

John's message caused me to think that a SCSI-Floppy Controller design
might _almost_ be in hand.

On page 4-82 in Nationals "Mass Storage Handbook" is an application
note detailing a SCSI-Printer Controller (SPC).  On page 5-57 of
the same handbook is an application note describing a pc-at floppy
disk controller based upon the National DP8473.  The DP8473 is virtually
a single chip FDC solution.

Concerning software, the SPC application note indicates that all software
described is available from National.  This was recently confirmed by
Dave Rand.  Further, the Minix floppy disk driver (floppy.c)
contains all the code to control a pc style FDC.  The latter expects 
high level read / write requests (Minix messages) -- which in this case 
are much like SCSI commands.

If anyone has the time to investigate this possibility further, I for
one would be appreciative.  

Mechanically, it would appear that such a board could be housed within a 
standard half height 5-1/4 to 3-1/2 inch adapter frame.

regards,
johnc


From "nk@sybase.com (Nicolai Kosche)" Tue Jan  9 20:49:14 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Tue, 9 Jan 90 15:49:08 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Tue, 9 Jan 90 15:49:00 EST
Received: by mips.com (5.61.14/1.11) id AA28791; Tue, 9 Jan 90 12:48:32 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0glSRr-0000AwC@daver.uu.net>; Tue, 9 Jan 90 12:28 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!sybase.com!nk>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0glSRm-0000BuC@daver.uu.net>; Tue, 9 Jan 90 12:28 PST
Received: from tis.llnl.gov by uunet.uu.net (5.61/1.14) with SMTP 
	id AA22456; Tue, 9 Jan 90 14:54:08 -0500
Return-Path: <nk@sybase.com>
Received: by tis.llnl.gov (4.0/1.14.5-TIS)
	id AA07623; Tue, 9 Jan 90 11:52:03 PST
Received: from  home.sybase.com  (home) by sybase.com (3.2/SMI-2.0/SybGW1.9)
	id AA09267; Tue, 9 Jan 90 11:28:33 PST
Received: by  home.sybase.com  (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0/SybNeXT-1.0)
	id AA05594; Tue, 9 Jan 90 11:26:17 PST
Date: Tue, 9 Jan 90 11:26:17 PST
From: nk@sybase.com (Nicolai Kosche)
Message-Id: <9001091926.AA05594@ home.sybase.com >
To: pc532@daver.uu.NET
Subject: DRAMs...
Status: RO

Most discussion is centering on 1Mb SIMMs...  What is needed to install
4Mb SIMMs?  Are they available?  What is the cost difference?  4x or is
the cost differential greater?

Thanks for the info

Nick Kosche
nk@sybase.com

From Steven.D.Ligett@mac.dartmouth.edu Tue Jan  9 21:58:39 1990
Flags: 000000000000
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Tue, 9 Jan 90 16:58:30 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Tue, 9 Jan 90 16:58:17 EST
Received: by mips.com (5.61.14/1.11) id AA01061; Tue, 9 Jan 90 13:57:28 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0glTYR-0000HLC@daver.uu.net>; Tue, 9 Jan 90 13:38 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <uunet!mac.dartmouth.edu!Steven.D.Ligett>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0glTY9-00009AC@daver.uu.net>; Tue, 9 Jan 90 13:38 PST
Received: from dartvax.dartmouth.edu by uunet.uu.net (5.61/1.14) with SMTP 
	id AA05748; Tue, 9 Jan 90 16:13:00 -0500
Received: from d0.dartmouth.edu by dartvax.dartmouth.edu (5.61D1/4.0HUB)
	id AA00505; Tue, 9 Jan 90 16:12:44 -0500
Received: by D0.DARTMOUTH.EDU id <16748>; 9 Jan 90 16:12:51
Message-Id: <934566@mac.Dartmouth.EDU>
Date: 09 Jan 90 16:12:47
From: Steven.D.Ligett@mac.dartmouth.edu
To: pc532@daver.UU.NET (Nicolai Kosche)
Subject: Re: DRAMs...
Status: RO

--- Nick Kosche,nk@sybase.com wrote:
Most discussion is centering on 1Mb SIMMs...  What is needed to install
4Mb SIMMs?  Are they available?  What is the cost difference?  4x or is
the cost differential greater?
--- end of quoted material ---
I got a quote today - in small quantities, Toshiba 4megx8's are $640, and Oki
would match that price with their 4 megx9's.  I believe that both are readily
available, though distributors don't stock them!!  Oh, these are 80 ns parts.

From owner-pc532%daver@mips.com Wed Jan 10 12:32:05 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
To: pc532@daver
Subject: graphics board
Date: Tue Jan  9 12:28:16 1990
From: blank%clanhlm@ucscc.UCSC.EDU
Status: O

	If the plan is to run X, then why don't we think about a graphics
	board which will support a simple port?

	How about a 68020 running at 12 MHz, with a 2M by 1M frame
	buffer (made out of VRAM), some scratch memory (1 Mb of
	265K DRAM or possibly SRAM), a SCSI channel, and enough
	PROM sockets to put the complete X server in.  This would
	take less than a month to design, and there is the whole
	range of compilers for it.  Writting an operating system
	is also relatively trivial -- it is a rather nice chip for
	such things.  Then we would only need to write the libraries
	for what X requires, and the communications code.  I think
	it would be possible to bring such a system up far faster
	than would anyother configuration.

					John


From owner-pc532%daver@mips.com Wed Jan 10 14:23:26 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
To: pc532@daver.UU.NET
Subject: Re: graphics board 
Reply-To: ken@cs.rochester.edu
X-Uucp: ..!rochester!ken Internet: ken@cs.rochester.edu
X-Snail: CS Dept., U of Roch., NY 14627. Voice: Ken!
X-Phone: (716) 275-1448 (office) Fax: (716) 461-2018
Date: Wed, 10 Jan 90 13:24:11 -0500
From: Ken Yap <ken@cs.rochester.edu>
Status: O

Having once done a port of X11 to a different machine and then halfway to
a non-Unix operating system (Amoeba) let me give an idea of what is
involved.

A dumb frame buffer is easiest to do the port to. There is already code
in X to do this. Smart display chips will improve performance but will
make life harder in this department.

Next order of business is to decide what you want to do for IPC and
font storage. You can replace the socket stuff in X with shared memory,
or what have you. Font support is OS specific.  I suppose one could add
a font downloading extension to the server.

Then in the library you have to fix all the modules to do with IPC
and user validation. You'll have to decide what to substitute for
input polling, which uses select() in the BSD implementation.

Porting to a new machine took a month and halfway to a different OS
took two. I think the person who succeded me took another month or
two to get it fully working.

An industrial strength compiler is essential. Most of the first month
was wasted trying to work around a compiler with a small table size.  I
never got the libraries to work on that machine, but ran the
applications over the network.

Finally, the size X is, you'd need a machine with about 50M of free
disk space to work with.

I estimate a good hacker could get a X11 board working in 2 or 3
months. This is for software.  The main thing is to pin down the design
choices.  X allows a spectrum of implementation options.

From owner-pc532%daver@mips.com Wed Jan 10 14:23:37 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
To: pc532@daver.uu.NET
Subject: 1 M x 9 bit SIMM prices
Clarity-Index: null
Threat-Level: none
Quote-Of-The-Moment: 's/./&&/g' Tom sed expansively.
Another-Quote: 1 nanosecond is a short piece of wire.
Who-Said-It: -- George Scolaro
Date: Tue, 09 Jan 90 15:27:23 CST
From: Jon Loeliger <loeliger%convex@uxc.cso.uiuc.edu>
Status: O

[George writes]
> What is the current x8 and x9 SIMM price. A guess its
> less than $100 at this stage.

I called around here to see what I could find for local prices:


Toshiba			(214)-480-0470
777 E Campbell, Richardson TX 75081
    Dallas Sales Representative is Mil-Rep
    Dan Lewis		(214)-644-6731
    1701 N Greenville, Suite 1008, Richardson, TX 75081
    FAX			(214)-644-8161

	THM91000AS-80ns		1 Meg x 9 bit, SIMM, Fast page	$81.35
	THM91000AS-70ns		1 Meg x 9 bit, SIMM, Fast page	$



Motorola		(214)-480-8100
1200 E Campbell, Richardson TX 75081
    Dallas Sales Rep
    Kathy Serrioz	(214)-480-5627

	MCM91000 S80		1 Meg x 9 bit, SIMM, Fast page	$96
	MCM91000 SG80		1 Meg x 9 bit, SIMM, Fast page	$96

	MCM9L1000 S80		1 Meg x 9 bit, SIMM, Fast page	$96
	MCM9L1000 SG80		1 Meg x 9 bit, SIMM, Fast page	$96

	MCM91000  has 512 Cycle refresh of 8 ms
	MCM9L1000 has 512 Cycle refresh of 64 ms



NEC
    Dallas Area Sales rep is TL Marketing
    Cindy		(214)-484-6800

    Parts are actually available from Marshall Electronics,
    Paul Ensley (sp?), (214)-233-5200

	MC-421000A8-80						$
	MC-421000A9-80						$100


Budget Micro		(214)-661-0364
3961 Beltline
	Dave(?)
	MSC411024		1 Meg x 9 bit, fast page	$110




Notes here:
Toshiba claims to have them in good stock.

Motorola claims "this is a brand new part."
Price good through 1Q90, about $86 in 2Q90 in < 100 pieces / order.
The difference between the S and SG versions is "SIMM" and "Gold pad SIMM".

NEC
There is a 4 week lead time for delivery.

Budget Micro wants a 1 hour lead time.  Obviously "Budget" implies
support of *their* budget, not ours...


Technical questions, perhaps for George:
1) Are we looking for 512 refreshes /8ms or /64ms?
2) Also, I looked at the pinouts on some of these chips and it appears
   that the difference between the x8 and x9 chips (besides more bits :-)
   is the separation of the data bit DQ8 into D8 and Q8.  Does the
   PCB/schematic require the separation or allow for them to be wire or-ed
   (jumered?) if needed?  In short, must the x9 chips we use be
   input/output separated or not?
3) There are some toshiba chips (THM91010AS-80ns) that have 1Mx9bit shape,
   but have two pins called PD1 and PD2 (presence detect), whatever that is.
   We're staying away from these, right?
   [I think the answer "yes" just hit my mail box...]


[johnc writes]
> Lets assume that it is possible to negotiate a group DRAM purchase wherein
> the supplier agrees to drop ship COD directly to each party.  If this could
> be arranged, then each party could simply place his/her order by calling the
> designated supplier contact.

One of the places I called claimed that it would be a pain to have me,
some lowly single person with no "credit" (in their eyes), place a
purchase order than it would be to have some acredited company or
previous customer place the order.  Collectively, I read this to mean it
would cost more if I personally placed the order whereas it would be
cheaper if I could talk, say, Convex, into buying for me and doing the
reimbursment number.  Off hand, I doubt that I can talk, say, Convex
into such a deal...

> Anyone willing volunteer to coordinate / negotiate such a deal ??

I am willing.  I think, though, that we might want to have as many
people as possible ping their locals to see what we can get.  Then,
the person who *really* coordinates it might be decided (heh heh
heh :-) just due to locality and initial contact.

jdl
------------------------------------------------------------------------------
Jon Loeliger			    loeliger@convex.com
Convex Computer Corporation	    "You should never attack an anarchist.  He
3000 Waterview, Richardson TX 75083  has nothing to lose."   Joe Bob's friend

From owner-pc532%daver@mips.com Wed Jan 10 14:24:10 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: Jukka Virtanen <jtv@kampi.hut.fi>
To: pc532@daver.uu.NET
Subject: Forwarded article: Re: X server (flame wars! :-)
Date: 	Wed, 10 Jan 90 20:31:18 EET
Status: O


	Petri intended to send this to the mailing list, but
	erroneously sent it only to the newsgroup at santra.hut.fi.

From: petri@digiw.UUCP (Petri Alhola)
Subject: Re: X server (flame wars! :-)
Message-ID: <1141@digiw.UUCP>
Date: 10 Jan 90 17:04:12 GMT
References: <9001072203.AA24257@tmsoft.UUCP>
Reply-To: petri@digiw.UUCP (Petri Alhola)
Organization: Digiware , Helsinki Finland
Lines: 39

In article <9001072203.AA24257@tmsoft.UUCP> pc532%daver@uunet.UU.NET writes:
>
>A few comments on TI34010 vs Inmos G300:
>
>TI34010:	16 bit memory, maximum speed ~80MHz, includes processor
>		nifty chip, should work with a single memory for
>		frame/program (though this may slow it unacceptably),
>		upgradeable with TI34020, palet chip available
>
>G300+NS32GC16:	32 bit frame memory (I presume, from the posted specs),
>		maximum speed ~110MHz, built-in 256 element palet,
>		compiler readily available, upgradeable with NS32GX32
>
 G300+i860:     64 bit memory, 40..50Mhz Risc processor, cache, special
	        graphic instructions supporting 8 and 32 pixels, one
		clock cyckle floats.... . G300 is palette chicp, supporting
		8 bit pixels at 110Mhz , and 24 bit true color mode .

The TI34010 is old, it has narrow bus, it does not have floats, and it
is much more slower than i860, that is fastest processor existing now,
i have looked few designs with TI34010 like matrox PG1280. It is one
and half full sized PC boards, with special gate array making drawing
faster. i860 it is also much faster than NS32GC16 or NS32GX32. There
is existing gcc and gas for i860 and it is easy to use, becouse is
structured as general purpose processor with graphics instructions and
so it can even run Unix. 
At begining it is even possible to run it with
stantard X11 colour server from X11.3 sources, stantard colour server 
expects simply to see video buffer as stantard memory with cols*rows bytes
long, this is everything that G300 does. The default colour server is
slow ( in sun ) even it can be sensible speed with 20 times faster i860.
When we get stantard server running then it is easy to optimize server
for i860 graphics instructions and even make true color server.


 Petri Alhola
 petri@digiw.fi



From owner-pc532%daver@mips.com Wed Jan 10 19:40:58 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
From: george@wombat (George Scolaro)
Date: Wed, 10 Jan 90 16:11:05 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Subject: Re: 1 M x 9 bit SIMM prices
Status: O

[In the message entitled "1 M x 9 bit SIMM prices" on Jan  9, 15:27, Jon Loeliger writes:]
> 
> Technical questions, perhaps for George:
> 1) Are we looking for 512 refreshes /8ms or /64ms?

As long as they support cas before ras refresh I don't care. I have
used the toshiba parts and know they definitely work. Also, toshiba is
currently the industry leader in dram devices. The pc532 performs 2 back
to back refresh cycles (cas before ras) every 30 usec. Its up to the dram to
increment the addresses as it needs.

> 2) Also, I looked at the pinouts on some of these chips and it appears
>    that the difference between the x8 and x9 chips (besides more bits :-)
>    is the separation of the data bit DQ8 into D8 and Q8.  Does the
>    PCB/schematic require the separation or allow for them to be wire or-ed
>    (jumered?) if needed?  In short, must the x9 chips we use be
>    input/output separated or not?

All the dram simms that I have ever seen, even the 256k old ones, had
separate data out and data in for the parity bit. This was to support the
typical parity hardware. The pc532 definitely wants them separate.
The toshiba parts (the thm81000 and thm91000) support the required features.

> 3) There are some toshiba chips (THM91010AS-80ns) that have 1Mx9bit shape,
>    but have two pins called PD1 and PD2 (presence detect), whatever that is.
>    We're staying away from these, right?
Yes, sounds bizarre.

regards,


-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com Wed Jan 10 19:49:10 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Wed, 10 Jan 90 15:55:26 EST
From: Jerry Callen <jcallen@maxzilla.encore.com>
To: pc532@daver.uu.NET
Subject: DRAMS
Status: O

I checked with my local Pioneer Electronics. Since I'm interested in
parity (sorry, George! :-)  I only checked on the 1Meg x 9 SIMMs.

Manufacturer           Part Number         Price/stick         Delivery Time
----------------------------------------------------------------------------
Micron Technology      MT8C9024M-8             $95                5-6 days
Motorola               MCM91000S80             $87                3 weeks

Apparently the price drops pretty DRAMatically if you can live with
100ns parts (which, of course, we can't). Is that possibly why Mac SIMMs
are getting so cheap?

-- Jerry Callen
   jcallen@encore.com

From owner-pc532%daver@mips.com Wed Jan 10 19:49:20 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: Anthony J Stieber <astieber@csd4.csd.uwm.edu>
Subject: Re: X server (big dumb buffer)
To: pc532@daver.uu.NET
Date: Wed, 10 Jan 90 15:25:51 CDT
X-Mailer: ELM [version 2.2 PL10]
Status: O

Why not give X exactly what it wants, a big dumb buffer?  Make a
board with VRAM, video controller, and a SCSI.  The buffer is
writable by any device on the SCSI buss.  For high speed bitmap
transfer a hard drive could write directly to the frame buffer
without an intervening processor.  Perhaps the board could have
two SCSI's one to attach to a SCSIslot another to attach to the
sync SCSI hard drives.  The frame buffer might not even need a
processor, just a random logic controller.  In any case the processor
(if any) on the frame buffer doesn't have to be powerful.  It only
has to keep up with the SCSI and the VRAM.

If you want an intelligent video subsystem just put another SCSI
device with a processor to do the hard work for you.  A generic
board with just a processor, RAM, and a SCSI would be a useful item
that could control anything that you don't want your main processor
(a pc532 or whatever) to fool with directly.
-- 
<-:(= Tony Stieber	astieber@csd4.csd.uwm.edu   att!uwm!uwmcsd4!astieber

From owner-pc532%daver@mips.com Thu Jan 11 13:06:24 1990
Flags: 000000000001
Received: from BU-IT.BU.EDU by BU.EDU (1.97) Thu, 11 Jan 90 13:06:12 EST
Received: from mips.com by bu-it.bu.edu (12/20/89); Thu, 11 Jan 90 13:05:59 EST
Received: by mips.com (5.61.14/1.11) id AA01753; Thu, 11 Jan 90 10:04:06 -0800 
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gm8gl-0000AsC@daver.uu.net>; Thu, 11 Jan 90 09:34 PST
Reply-To: pc532@daver.UU.NET
Return-Path: <@vw26.chips.com:gs@vw25.chips.com>
Received: by daver.uu.net (/\=-/\ Smail3.1.18.1 #18.15)
	id <m0gm8gh-0000BjC@daver.uu.net>; Thu, 11 Jan 90 09:34 PST
Received: by vw26.chips.com (/\=-/\ Smail3.1.18.1 #18.25)
	id <m0gm8ha-0000iMC@vw26.chips.com>; Thu, 11 Jan 90 09:35 PST
Received: by vw25.chips.com (/\=-/\ Smail3.1.18.1 #18.25)
	id <m0gm8g0-0000nAC@vw25.chips.com>; Thu, 11 Jan 90 09:33 PST
Message-Id: <m0gm8g0-0000nAC@vw25.chips.com>
Date: Thu, 11 Jan 90 09:33:30 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: gs@vw25.chips.com (George Scolaro)
To: pc532@daver
Subject: change of part
Status: O

Hi folks,
	well, due to the xtal input difference between the 2681 DUART and
the 2692 DUART, the 74AS32 device must be changed to a 74AC32 device. The
2692 outputs a signal that does not reach below about 1V causing the TTL
level of the 74AS32 to be violated. Using a 74AC32 gives us speed, which is
needed through one of the other gates (in the same package) and 50%
threshold for the oscillator output of the 2692. Signetics recommends the
use of a 74Cxx device to buffer the oscillator, but we need a 74AC (for
speed). We will supply the 74AC32 part with the kit.

regards,

-- 
George Scolaro
(try (pyramid|hoptoad|sun|vsi1)daver!vw25.chips.com!gs)

From owner-pc532%daver@mips.com Thu Jan 11 14:17:32 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Thu, 11 Jan 90 10:02:08 PST
From: mason%unify%sun@daver (Mark Mason)
X-Mailer: Mail User's Shell (6.4 2/14/89)
To: pc532%daver%sun@pyramid
Subject: X windows.
Status: O


About graphics hardware for X windows:

I was relating the X windows discussion going on here to a friend of
mine, who pointed me at another guy I know (Keith Packard), who wrote
me the letter which I have enclosed below. Keith works at the X
Consortium, and is one of the best programmers I have ever met, so I
think he knows what he is talking about. (But I don't know what I'm
talking about here, so that's why I'm posting *his* letter).

{sequent,pyramid}!unify!mason

From: keith@expo.lcs.mit.edu (Keith Packard)

I do have some pretty convincing arguments as to why the 34010 is a poor choice
for X.  But beyond the 34010, graphics co-processors are generally slower than
your CPU for all drawing operations.  The two things which typically kill CPU
based graphics are memory bandwidth and poor code.  The first is already solved
for you by the 32532 -- page mode access is plenty fast.  The second is already
solved in large part by the current X release (R4) which has some reasonable
implementations of frequently used operations for an 8-bit frame buffer.

The Killer Micros argument applies to graphics just as much as any other
project.  Also, if you've got some nightmare at the end of your scsi bus,
you'll spend months getting the server running on it.  With a dumb frame buffer
and two serial ports (for mouse and keyboard), you could get X running in about
a week (given existing kernel support for the mouse and keyboard).

I don't think I can suggest too strongly that you put the 10 chips necessary
for a dumb frame buffer onto the main CPU board.  Brooktree has a new DAC chip
which combines a RAMDAC with a 2-plane cursor.  Very nice part.  The only thing
you need beyond that is 8 VRAM chips and a bit of glue.  Don't forget the
hardware cursor though; software implementations are pretty bad (I should know,
I've done one).  

A possible mechanism for this would be a DIP header which brings the addr/data
paths out for a plug-on video board.  Making the display board plug into the
cpu board solves a few problems, most notably it eliminates most of the
cost of the display for systems which don't need one (file servers).  Don't
make the interface fancy, just address+data lines and minimal signals.  75
pins should be more than enough.

The 32532 has the potential for some pretty amazing CPU-based graphics
operations, don't blow it by putting the graphics memory far from the
computer and attaching some sort of graphics decellerator.

Important design aspects:

	Keep the latency low.
		
	Latency really kills performance for line drawing
	operations, but is less noticable for character drawing,
	rectangle filling and bitblt.

	Keep the bandwidth high.

	Low bandwidth hurts bitblt performance.  If you could use the
	32532 to get at the display memory in page mode, you'd win big.

	Avoid the cache.

	Seems like a contradiction, but going through the cache to the
	display hurts your performance.  Typical screen operations
	touch ~100000 pixels, all of which will not be in the cache.
	This will flush all useful data from the cache and your
	performance will suffer.  Bitblt does not follow the
	working set approximation at all.

If you create dumb frame buffer hardware, I'd be more than willing to
help in the initial port of X to the machine.  Also, I have some
suggestions about the kernel interface to the mouse and keyboard which
help considerably in simplicity and performance.

Here's a short article on why the 34010 is a poor choice, it is a bit
dated (written before I started writing R4 frame buffer code) but
provides some useful arguments.

Keith Packard
MIT X Consortium

------------
The TI 34010 is a nice high-performance graphics processor. X provides a
network-transparent mechanism to access these operations with little
overhead.  While these two seem to be a good match for a medium-performance
standard-based graphics system, there are some aspects of both which lead to
performance problems when implementing the X server using the 34010 graphics
processor.

The 34010 does certain operations very quickly; Bresenham line drawing,
triangle filling and other compute-intensive drawing operations.  In many X
applications, the operations performed are not of this nature.  A typical X
application will spend more time drawing text and copying pixels than filling
polygons.  The 34010 does these operations rather slowly.  The 16-bit wide
bus and slow memory cycle time causes these memory-intensive operations to
suffer; a simple Sun 3/60 will frequently out-perform the 34010 in raw BitBlt
speed.

Of course, the mixture of BitBlt to drawing operations is very application
specific.  As usual, the hardware required for any application is dependent
on the needs of the application.  X is providing a layer for applications to
speak to the hardware through; it is not the application (even though
only the server has access to the hardware).  If you are building a CAD
system, I would expect different graphics hardware than would be used to
design a typesetting layout system.  Different hardware for different needs,
even if both operate using the X protocol.

Another severe limitation of the 34010 is the lack of virtual memory.  X
provides not only the ability to draw on the screen, but to draw in
off-screen memory.  The sizes of these off-screen images can be quite large;
a typical application may want 1 Megabyte (or more) of off-screen storage.
When the 34010 is coupled with a workstation which does provide virtual
memory, the application may reasonably expect the X server to use that
resource for off-screen storage.

To provide for these large images then, the developer must either implement
all graphics operations for both the 34010 and for the main processor, or
shuffle these (potentially large) images between the small dedicated memory
available on the 34010 and the virtual memory of the host system.  In the
first case, applications which spend a large amount of time drawing in
off-screen memory (the Digital PostScript previewer program "dxpsview"
springs to mind here) will be limited by main processor speed, and by the
rate at which bits can be copied from the main processor to the screen.  In
the second case, the 34010 may spend a large amount of time swapping data in
and out of its small memory system for different clients to provide
multi-tasking.

In the successor to the 34010, the 34020, many of these problems are
solved.  The 34020 allows access to it's entire memory space from the host
system, allowing each operation to be performed by the processor which
offers the highest performance.  In addition, the 34020 includes special
architectural features for BitBlt, rectangle fill and text operations which
surpass the performance available from most general purpose microprocessors
(even including RISC solutions like the MIPS R2000).

While X will provide network access to the 34010 operations with little
overhead, the operations desired by the current crop of X applications do
not match the strengths offered by the hardware.  The 34010 is suitable for
traditional on-screen graphics, while X is perceived to demand more
performance for off-screen drawing and text-based applications.  As usual,
these perceptions are biased by the available applications which run under
X, and by the needs of the people buying current systems.

---------------



From owner-pc532%daver@mips.com Thu Jan 11 14:51:05 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: dlr@daver.UU.NET (Dave Rand)
Date: Thu, 11 Jan 90 11:30:39 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Subject: Re: X windows.
Status: O

[In the message entitled "X windows." on Jan 11, 10:02, unify!mason (Mark Mason) writes:]
> 
> About graphics hardware for X windows:
Thanks, for a very informative article!

> From: keith@expo.lcs.mit.edu (Keith Packard)
> 

> I don't think I can suggest too strongly that you put the 10 chips necessary
> for a dumb frame buffer onto the main CPU board.  Brooktree has a new DAC chip

We have two reasons for doing this. The first is that it is not 10 chips.
The second is that the idea of the multi-master SCSI encourages logical
partitioning of tasks. In this case, placing a GX32, or 860 out on the
bus, handling the graphics, mouse and keyboard. This is a Good Thing. 
We want the main CPU running programs. "Attached" cpus may be of different
families, and may be better suited for doing certain tasks (like the attached
DSP board that is being worked on).

> The 32532 has the potential for some pretty amazing CPU-based graphics
> operations, don't blow it by putting the graphics memory far from the
> computer and attaching some sort of graphics decellerator.

This is very true, and why we want a dedicated processor (of some flavor)
close to the graphics memory. It is very hard to design a system with
multiple dual ported memory arrays, and you almost always pay for it
with latency or bandwidth restrictions.

> 	Avoid the cache.
> 
> 	Seems like a contradiction, but going through the cache to the
> 	display hurts your performance.  Typical screen operations

This is very true on the 532/GX32. Simulations showed an improvement of
up to 4x by NOT using the cache - this is due to the fact that the cache
always tries to load a "line" of 16 bytes, and you may not need all of
that data.

The cache does help in most code, however. A good way around this is to
disable the cache in hardware, when accessing the screen bitmap memory.
This keeps all of the benefits of the cache for normal code, while still
providing low latency access to the screen space.


-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr%daver@uunet.uu.net

From owner-pc532%daver@mips.com Fri Jan 12 01:47:00 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.4 2/14/89)
To: pc532@daver.uu.net
Subject: Minix/532 questions
Date: 10 Jan 90 16:56:02 GMT (Wed)
From: ken%mm%gatech@ames.arc.nasa.gov (Ken Seefried iii)
Status: O

I have several questions regarding Minix/532.

1) What is the status of the demand-paged VM implimentation?  How
big an address space?  Any other details?

2) Does it have a TCP/IP `socket' implimentation?  There was talk
at one time of porting the PD TCP/IP package (KA9Q, or some
such?).  

3) How far away is the much discussed Posix compliance?

4) Any hope for memory-mapped files, shared libraries and/or
select()-like facilities (I am willing to work on one or more of
the above, BTW).

5) Since we are using the GNU C compiler, is there any hope of
running the GNU C++ and Objective-C (TBA) compilers?  I will
assume that Jukis' GNU Pascal will run once completed :').

Forgive me if this has been hashed out on the Minix newsgroup, but
I don't read it (far too much pointless IBM-PC traffic to dig
through).

Thanks...

-- 
    ...ken seefried iii          ...!<anywhere>!uunet!gatech!mm!ken
         MetaMedia, Inc.              Atlanta, Georgia, USA
           ken%mm.uucp@gatech.edu       obquote: "I feel...like a god..."
    
    

From owner-pc532%daver@mips.com Fri Jan 12 01:47:04 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.4 2/14/89)
To: pc532@daver.uu.net
Subject: licensing and Tektronix
Date: 10 Jan 90 16:45:13 GMT (Wed)
From: ken%mm%gatech@ames.arc.nasa.gov (Ken Seefried iii)
Status: O

Does anyone know offhand the licensing requirements for Tektronix
UTek?  Does Tek even license it at all?

UTek is a BSD derivative that also includes copy-on-write forks
(the literature indicates that Tek did this first for Unix), lots
of USG stuff, Smalltalk and many other enhancements.  Best of all,
it runs on the 32000 series.

Just curious...certainly the $$$ factor will be out of range, but
it is a helluva nice implimentation...


-- 
    ...ken seefried iii          ...!<anywhere>!uunet!gatech!mm!ken
         MetaMedia, Inc.              Atlanta, Georgia, USA
           ken%mm.uucp@gatech.edu       obquote: "I feel...like a god..."
    
    

From owner-pc532%daver@mips.com Fri Jan 12 07:56:20 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
To: pc532@daver
Subject: graphics servers
Date: Thu Jan 11 19:08:46 1990
From: blank%clanhlm@ucscc.UCSC.EDU
Status: O


	does anyone know exactly what kernel services the X server
	requires?  (A list of functions/system calls would be perfect)

	I tried to look through the 11R3 docs, and I have pulled a
	complete blank on what is needed.

					John



From owner-pc532%daver@mips.com Fri Jan 12 09:35:31 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Date: Thu, 11 Jan 90 23:26:09 EST
From: Jerry Callen <jcallen@maxzilla.encore.com>
To: pc532@daver.uu.NET
Subject: SCSI cables
Status: O

Does anyone know of a source for SCSI cables? I just acquired a Seagate ST277N
for my pc532 and I want to test it with my Macintosh. To do so I need a
cable to adapt the 50 pin header on the drive to standard SCSI female
connector. Also, once I have a working pc532, I'll need a cable to connect
the drive directly to the 50 pin header on the board. My scan of the usual
catalogs (Digikey, Jameco, JDR) was fruitless.

-- Jerry Callen
   jcallen@encore.com

P.S. The ST277N is a 65 meg drive with a 40ms average seek time. There is a
     newer version, the ST277N-1, with a 28ms seek time. The drive I have is
     the older of the two, which I think explains the price; I paid $300. 
     There are more of these drives available from Eli Hefron in Cambridge.
     Their phone number is (617) 492-2345. I have no connection with
     Eli Hefron except as a (hopefully) satisfied customer.

From owner-pc532%daver@mips.com Fri Jan 12 10:36:06 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
From: mea@mea.utu.fi (Matti Aarnio)
Subject: Re: SCSI cables
To: pc532@daver
Date: Fri, 12 Jan 90 16:48:33 EET
X-Mailer: ELM [version 2.2 PL10]
Status: O

> Does anyone know of a source for SCSI cables? I just acquired a Seagate ST277N
> for my pc532 and I want to test it with my Macintosh. To do so I need a
> cable to adapt the 50 pin header on the drive to standard SCSI female
> connector. Also, once I have a working pc532, I'll need a cable to connect
> the drive directly to the 50 pin header on the board. My scan of the usual
> catalogs (Digikey, Jameco, JDR) was fruitless.
> 
> -- Jerry Callen
>    jcallen@encore.com

  I would pick up 50 pin flat cable and suitable connectors for it.
Quite standard issue material.

  If you really insist on making it with shielded twistedpairs cable,
it will be interesting to know what is available...

	/Matti Aarnio	<mea@mea.utu.fi>
		Building up  funic.funet.fi (Sun4)
		for GB worth of source archives.


From owner-pc532%daver@mips.com Fri Jan 12 10:36:09 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
To: pc532@daver.UU.NET
Subject: Re: graphics servers 
Reply-To: ken@cs.rochester.edu
X-Uucp: ..!rochester!ken Internet: ken@cs.rochester.edu
X-Snail: CS Dept., U of Roch., NY 14627. Voice: Ken!
X-Phone: (716) 275-1448 (office) Fax: (716) 461-2018
Date: Fri, 12 Jan 90 10:12:02 -0500
From: Ken Yap <ken@cs.rochester.edu>
Status: O

Here is a probably incomplete list for the BSD implementation, off the
top of my memory:

open	sockets and files
close	sockets and files
read	sockets and files
write	sockets and files
readv	sockets
writev	soekcts
select	sockets
ioctl	sockets, framebuffer
bind	sockets
listen	sockets
accept	sockets

And a whole bunch of library routines for address lookup, etc.

The two major classes of services X requires are IPC and font file storage.

From owner-pc532%daver@mips.com Fri Jan 12 13:55:15 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: Jukka Virtanen <jtv@kampi.hut.fi>
To: pc532@daver
Subject: Minix/532 questions
Date: 	Fri, 12 Jan 90 18:51:33 EET
Status: O


   5) Since we are using the GNU C compiler, is there any hope of
   running the GNU C++ and Objective-C (TBA) compilers?  I will
   assume that Jukis' GNU Pascal will run once completed :').

	I see no problems in running any of the
	abovementioned compilers, once Gnu CC is running
	on pc532.
	
	In addition the Gnu Assembler (gas) supports the whole
	32532 instruction set, I'll check the Gnu loader (gld)
	when I get the board running.

					Juki
					jtv@hut.fi

From owner-pc532%daver@mips.com Fri Jan 12 13:55:26 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Date: Fri, 12 Jan 90 10:23:20 pst
From: Bruce Culbertson <culberts%hplwbc@hplabs.hp.com>
To: pc532@daver.UU.NET
Subject: Re:  Minix/532 questions
Status: O

Hello Ken,

> 1) What is the status of the demand-paged VM implimentation?  How
> big an address space?  Any other details?

No one I know of is working on demand-paged VM.

My own version of Minix uses virtual addressing (e.g. all user process
address spaces start at address 0), but not virtual memory (i.e. all
user pages are in core at all times).  User process spaces can grow,
due to break calls and stack faults, until they consume all remaining
free physical pages.  At boot time, Minix probes the physical address
space to determine how much memory is on the system.  There are no
size limitations similar to PC-Minix's 64K limit.

Dave Rand is trying to adapt my Minix for the pc532.  I currently have
it running on a 32016 system.

> 2) Does it have a TCP/IP `socket' implimentation?  There was talk
> at one time of porting the PD TCP/IP package (KA9Q, or some
> such?).  

A number of people have proposed such a thing.  I have heard no one
say they have done it.

> 3) How far away is the much discussed Posix compliance?

Minix version 2.0 will be POSIX compliant and is at least a year away.
Minix has moved closer to POSIX with its latest release -- 1.5.0.

> 4) Any hope for memory-mapped files, shared libraries and/or
> select()-like facilities (I am willing to work on one or more of
> the above, BTW).

Memory mapped files: since there is currently no VM, this is a long
way off.

Shared libraries: I do not understand why people want this.  A shared
library implies load-time linking, right?  Load-time linking makes
exec prohibitively slow.  MacIntosh has shared libraries and applications
take forever to load.

Select: I don't think select is in POSIX and, hence, is not likely to be
added to official Minix.  Would be easy to implement, though.

> 5) Since we are using the GNU C compiler, is there any hope of
> running the GNU C++ and Objective-C (TBA) compilers?  I will
> assume that Jukis' GNU Pascal will run once completed :').

I don't know much about C++ so this is pure speculation.  It seems
like GNU C++ should be easy to bring up.  I am under the impression
that it does not need new libraries or special linker features.

With luck, a new GNU frontend would not require a new backend and,
hence, GNU Pascal would be easy to bring up.  I know of compiler
horror stories, though, where such theoretical ideals did not come
to pass in reality.



Is this any help?

Regards,
Bruce Culbertson

From owner-pc532%daver@mips.com Fri Jan 12 16:37:00 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: 12 Jan 90 14:31:06
From: Steven.D.Ligett@mac.dartmouth.edu
To: pc532@daver.UU.NET (Jerry Callen)
Subject: Re: DRAMS
Status: O

--- jcallen@encore.com wrote:
Apparently the price drops pretty DRAMatically if you can live with 100ns
parts (which, of course, we can't). Is that possibly why Mac SIMMs are getting
so cheap?
-- Jerry Callen
   --- end of quoted material ---
For 1 meg DIPs, the price differential between 80 and 100 ns parts has been
less than $0.25 (about $2 per SIMM!); the supplier I most frequently buy from
no longer carries 100 ns parts.  I read that over 80% of production is 80 ns
or faster.  Sometimes they send me 70 ns parts instead of 80's, at the price
they quoted to me for 80's.

From owner-pc532%daver@mips.com Fri Jan 12 16:37:03 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.4 2/14/89)
To: pc532@daver.UU.NET
Subject: Re:  Minix/532 questions
Date: 12 Jan 90 19:34:54 GMT (Fri)
From: ken%mm@gatech.edu (Ken Seefried iii)
Status: O

On Jan 12, 10:23am, Bruce Culbertson wrote:
} 
} No one I know of is working on demand-paged VM.
} 

Oops...I thought that was what you were working on...my bad!

} 
} Shared libraries: I do not understand why people want this.  A shared
} library implies load-time linking, right?  Load-time linking makes
} exec prohibitively slow.  MacIntosh has shared libraries and applications
} take forever to load.
} 

I don't (subjectively) find them *that* much slower in SunOS 4.0.3, but
then I have never done a quantitative analysis.

The big win that I get from SLs is space.  In non-SL X11R3 on SunOS,
the `xterm' object is something like 400k (on disk).  In SL R4, `xterm'
is about 40k.  In-core image is equivalently leaner.  You pay the up
front penalty in that all your libs are loaded, but then all of your
objects use the same copy...a big win if you have lots of X clients
running.

} 
} With luck, a new GNU frontend would not require a new backend and,
} hence, GNU Pascal would be easy to bring up.  I know of compiler
} horror stories, though, where such theoretical ideals did not come
} to pass in reality.
} 

Someone else will have to comment authoritatively, but according to
some people that were working on a GNU Modula-2, the backend and
frontend of the GNU compilers were not completely independent yet,
and lacked some hooks for doing non-C-ish things.  This was being
(and buy now may already be) rectified.  This was a year ago.
Again...I'm not a compiler type...this is hersay...

-- 
    ...ken seefried iii          ...!<anywhere>!uunet!gatech!mm!ken
         MetaMedia, Inc.              ken%mm.uucp@gatech.edu 
           Atlanta, Georgia, USA        obquote: "I feel...like a god..."
    
 "Sunny day...good friends...cold beer...life just don't get no better'n that"

From owner-pc532%daver@mips.com Fri Jan 12 16:37:21 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
To: pc532@daver.UU.NET
Subject: Re: Minix/532 questions 
Date: Fri, 12 Jan 90 12:31:28 MST
From: Bdale Garbee <bdale@hpcssa.col.hp.com>
Status: O

> 2) Does it have a TCP/IP `socket' implimentation?  There was talk
> at one time of porting the PD TCP/IP package (KA9Q, or some
> such?).  

Not at this time, far as I know.  I am the "keeper" of the KA9Q Package, and
am confident that porting the latest NOS bits (to be publicly released in the
early March timeframe, I hope...) to Minix32k shouldn't be hard.  We've already
got a good Unix port from Anders Klemets at SICS, he runs a process per I/O
device, and has the networking code run as a process.  With the Berkeley socket
implementation in NOS, you end up with something not far removed from the 4bsd
environment as far as applications programmers are concerned.

I'll probably work on this myself soon as I have a board working.

> 5) Since we are using the GNU C compiler, is there any hope of
> running the GNU C++ and Objective-C (TBA) compilers?  I will
> assume that Jukis' GNU Pascal will run once completed :').

There should not be a problem, as far as I can see.  Bruce has done some work
to gcc to make it behave well with his other tools, perhaps he'll comment on
the details.  I can't imagine that making g++ work would be much harder.

Bdale

From owner-pc532%daver@mips.com Fri Jan 12 16:37:53 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Date: 12 Jan 90 14:26:14
From: Steven.D.Ligett@mac.dartmouth.edu
To: pc532@daver.UU.NET
Subject: Re: DRAMS
Status: O

I called my memory supplier for SIMM prices.  For 100 pieces of Samsung 1
megx8 SIMMs (80 ns), the price would be $72.00 each.  For 200 pieces, the
price may go down to $71.50...  They supply SIMMs made with Samsung chips on
3rd party boards, and also SIMMs made completely by Samsung.  I prefer the
latter.  I didn't ask about drop shipments to many locations.  My guess is
that the total cost with shipping would be $300 for 4 megs.  Is there serious
interest in a group buy?

From owner-pc532%daver@mips.com Fri Jan 12 16:49:03 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Fri, 12 Jan 90 11:45:19 PST
From: mason%unify%sun@daver (Mark Mason)
X-Mailer: Mail User's Shell (6.4 2/14/89)
To: pc532%daver%sun@pyramid
Subject: X windows
Status: O


Couple of comments of my own:

Personally, I would not like to see the pc532 board redesigned for
adding a video interface. I kinda like the scsi bus approach.

Seems like if we go for the 340x0 approach, we should use the 34020
instead of the 34010 for reasons Keith spelled out in his article. I
have no idea about pricing (relative or otherwise) for these chips, so
if the 34010 is $2 and the 34020 is $2000, this is not a good idea ;-).

The statement that X spends most of its time doing BitBlt I have heard
>From several other sources.

I guess if someone really wanted the dumb frame buffer close to the
cpu, you could build a seperate board which plugged in to one or more
of the simm sockets. I think this is what the PMAX does.

Is this possible? Not just for us, I mean, can it be done? Or am I
being silly?

mason

From owner-pc532%daver@mips.com Fri Jan 12 16:49:32 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.4 2/14/89)
To: pc532@daver.uu.net
Subject: X and Motif
Date: 12 Jan 90 19:43:23 GMT (Fri)
From: ken%mm%gatech@ames.arc.nasa.gov (Ken Seefried iii)
Status: O

If we do get X going on the pc532, would anyone be interested in a
Motif port?  I would be willing to do it, with a few caveats:

        1) I could not release the source.  Motif requires a $1K
           source license.

        2) There would be some nominal charge for the binaries, 
           as required by OSF.  I *think* this is about $40.  I
           could try and get them to waive the fee since the
           distribution is so small, but I wouldn't hold my
           breath.  Of course, I would only ask for media and
           shipping cost.

        3) As of now, Motif is not fully compliant with R4 (still
           at R3...not surprising since R4 is a week old).  In
           particular, `mwm' does not seem to work well.  Most
           other clients should run, though.  Motif will be R4
           compliant in the near future.

Comments?

-- 
    ...ken seefried iii          ...!<anywhere>!uunet!gatech!mm!ken
         MetaMedia, Inc.              ken%mm.uucp@gatech.edu 
           Atlanta, Georgia, USA        obquote: "I feel...like a god..."
    
 "Sunny day...good friends...cold beer...life just don't get no better'n that"

From owner-pc532%daver@mips.com Fri Jan 12 16:56:51 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Fri, 12 Jan 90 11:36:20 PST
From: mason%unify%sun@daver (Mark Mason)
X-Mailer: Mail User's Shell (6.4 2/14/89)
To: pc532%daver%sun@pyramid
Subject: GNU compilers/assemblers for the 532.
Status: O



I have noticed some discussion about gnu cc and c++ for the 532 system.

I am in the last stages of porting gcc 1.36 and g++ 1.36.1 to a
Tektronix 32000 workstation.

Sounds like Dave & Bruce have gcc working, which is the biggest first
step.

g++ _requires_ (well...., you _really_ want) ld++, which comes with
g++. I have some patches for ld++ so that it will handle 32000
displacement operands (MSB first). The patches are not very nice yet,
I am going to contact rms and friends about a better way to
incorporate machine-dependent relocations. If somebody needs them
_right now_ I can mail them in a day or two.

Something the manual does not say well is that if you have a
FASCIST_ASSEMBLER (an assembler that checks .stabs) you also have to
define USE_COLLECT while compiling gcc.c and collect.c. This is
because g++ uses .stabs of the form "___CTOR_LIST__",22,0,0,LABEL
to announce a constructor or destructor. FASCIST_ASSEMBLER means the
assembler can't handle these stabs, USE_COLLECT means run the collect
program during final link to handle getting info about static
contructors and destructors.

gas for the 32000 is _very_ buggy last time I looked (about 2 weeks
ago). If someone is interested in working on it, I can send a list of
problems I found.

I understand that Bruce has a assembler for the 32000 that he did
along with the gcc port. I would _love_ to get a copy for my machine
at home (90% of my porting problems are due to my assembler which has
its own ideas about opcode syntax).

I've been wading around in the gnu world for a while now and would be
happy to answer any questions that I can.

{pyramid,sequent}!unify!mason

From owner-pc532%daver@mips.com Fri Jan 12 17:05:38 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Fri, 12 Jan 90 13:53:17 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: gs@vw25.chips.com (George Scolaro)
To: pc532@daver.UU.NET
Subject: Re: DRAMS
Status: O

[In the message entitled "Re: DRAMS" on Jan 12, 14:26, vw26!daver!uunet!mac.dartmouth.edu!Steven.D.Ligett writes:]
> 
> price may go down to $71.50...  They supply SIMMs made with Samsung chips on
> 3rd party boards, and also SIMMs made completely by Samsung.  I prefer the
> latter.  I didn't ask about drop shipments to many locations.  My guess is

Have you direct experience with using lots of Samsung SIMMs? A friend of mine
that works for a company that uses hundreds of SIMMs  dislikes the Samsung
brand, I can't quite remember why.

> that the total cost with shipping would be $300 for 4 megs.  Is there serious
> interest in a group buy?

Are these x9 or x8?

best regards,


-- 
George Scolaro
(try (pyramid|hoptoad|sun|vsi1)daver!vw25.chips.com!gs)

From owner-pc532%daver@mips.com Fri Jan 12 17:09:49 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.4 2/14/89)
To: pc532@daver.uu.net
Subject: dumb frame buffer, anyone?
Date: 12 Jan 90 18:59:10 GMT (Fri)
From: ken%mm%gatech@ames.arc.nasa.gov (Ken Seefried iii)
Status: O

Taking a cue from Keith Packards commentary (thanks Mark!), how
about this:

A small card that plugs into the cpu socket that has a small, dumb
frame buffer and DAC on it, something not unlike the Weitek 1167
cards for i386 machines?  

Pros:

	1) industrial strength compiler availible (GNU C)

	2) can use motherboard serial ports for mouse
	   and keyboard

	3) can use exsisting OS support for resource management

	4) no motherboard modifications...and if you don't want
	   it, don't get it.

	5) easy to design and cheap to build (parts circa $200?
	   I don't have VRAM prices right here)

	6) won't take up an expansion slot (and we are running 
	   out: Ethernet/Serial, DSP, PostScript, i860)

	7) easy to port X to...

Considerations (not Cons):

        1) cooling (perhaps a non-problem)

        2) avoidance of the expansion slots (perhaps a 
	   non-problem)

	3) can the 32532 cache be turned off on the fly?
	   (that is, can it be told that memory accesses
	   into the frame buffer (placed at, say, the 2GB
	   mark in the address space) are non-cacheable?
	   I don't have the 32532 ref right here) 

	3a) there have been a few papers written (the one
	   I have lying around is from AT&T, I think) con-
	   cerning running BitBlt code inside the cache
	   of the 68020 (I believe the Purdure Speedups
	   and the Groupe Bull X Server make heavy use of
	   this).  Now I've never really explored this 
	   technique, but could someone with better know-
	   ledge perhaps comment on its applicability to
	   the '532?  The '532 caches are much bigger
	   (1k D-cache/.5k I-cache v. 256 word unified
	   cache), but I seem to remeber that this par-
	   ticular technique required a unified cache
	   (self-modifying code rings a bell).

        4) OS support for IPC and drivers for kbd/mouse

        5) Disk space requirments (X11 R4 == 150MB for all
           source, more to compile it...although you don't
	   need all 150MB on line at one time)

	6) space...really shouldn't be a problem, but as I 
	   haven't seen the pc532 PCB yet, I can't tell for 
	   sure.

I and several other people around here with server porting experience
would be very willing to work on the port to such a design...perhaps 
a good solid month of work to port and QA the whole distribution, in-
cluding the time it would take to write the keyboard and mouse drivers.
(Keith Packard said a week...he could probably do that, but we probably
couldn't).

Now...if we were *really* serious...what I'd *like* to see would be a 
2-plane dumb frame buffer run into a Princeton LM-301 or similar monitor.
You would be amazed at the improvement those two grey-scales give you
(see the NeXT machine).  A two plane system would use the cfb code in
the distribution and shouldn't be any more difficult to port, though
there is a performance question that I can't really answer.

Discussion?


-- 
    ...ken seefried iii          ...!<anywhere>!uunet!gatech!mm!ken
         MetaMedia, Inc.              ken%mm.uucp@gatech.edu 
           Atlanta, Georgia, USA        obquote: "I feel...like a god..."
    
 "Sunny day...good friends...cold beer...life just don't get no better'n that"

From owner-pc532%daver@mips.com Fri Jan 12 20:27:13 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Fri, 12 Jan 90 16:09:53 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: gs@vw25.chips.com (George Scolaro)
To: pc532@daver.UU.NET
Subject: Re: dumb frame buffer, anyone?
Status: O

[In the message entitled "dumb frame buffer, anyone?" on Jan 12, 18:59, Ken Seefried iii writes:]
> 
> A small card that plugs into the cpu socket that has a small, dumb
> frame buffer and DAC on it, something not unlike the Weitek 1167
> cards for i386 machines?  

The problems with this scheme are:
 
> 	6) won't take up an expansion slot (and we are running 
> 	   out: Ethernet/Serial, DSP, PostScript, i860)
>       2) avoidance of the expansion slots (perhaps a 
> 	   non-problem)

- The 32532 and 32381 sit squarely under the expansion boards. Thus any
adapter board would preclude the use of full length expansion cards.

> 	5) easy to design and cheap to build (parts circa $200?
> 	   I don't have VRAM prices right here)

- Designing the adapter card is a hell of a lot harder than you have
indicated. Any signals that you need to get into (e.g. the /RDY pin to
the 32532) will introduce delays that would be unacceptable. Remember that
we are talking about a 25 Mhz design, not a 4 Mhz Z80 system. Lets do some
quick figures here to illustrate the point:

Clock period = 40ns
Clock to Q output of 15ns PAL = 12ns
Gate delay 74AS00 = 4ns
/RDY setup to clock for 32532 = 18ns

This gives	40ns - 12 - 18 - 4 = 6ns margin.

Now if the /RDY from the adapter board has to be combined with the system
/RDY (and it will unless you have a 0 wait state video sub-system!), you will
introduce a further a further 5.5ns (74AS08). This gives you 0.5 ns of
margin, and we haven't even thought about the extra delay/inductance added
by the adapter board + interboard connector.

> 	3) can the 32532 cache be turned off on the fly?
> 	   (that is, can it be told that memory accesses
> 	   into the frame buffer (placed at, say, the 2GB
> 	   mark in the address space) are non-cacheable?
> 	   I don't have the 32532 ref right here) 

Yes, you can program bits in the MMU registers to control 4k pages or you
can do it externally via a cache inhibit pin at the 16 byte level (cache line
size).

> Now...if we were *really* serious...what I'd *like* to see would be a 
> 2-plane dumb frame buffer run into a Princeton LM-301 or similar monitor.
> You would be amazed at the improvement those two grey-scales give you
> (see the NeXT machine).  A two plane system would use the cfb code in
> the distribution and shouldn't be any more difficult to port, though
> there is a performance question that I can't really answer.
> 
>     ...ken seefried iii          ...!<anywhere>!uunet!gatech!mm!ken
>          MetaMedia, Inc.              ken%mm.uucp@gatech.edu 
>            Atlanta, Georgia, USA        obquote: "I feel...like a god..."

The board that I visualize as being relatively risk free to do involves the
C&T 8514A chip set. The chipset has a very simple interface (either PC/AT or
MCA style), supports 1024x768x256 colours using 8 1mx1 VRAMs, a colour DAC
(either Inmos IMSG176/178 or Brooktree BT471/478), some caps, resistors, a
connector, LM339, a voltage reference and a 74F74. To interface the PC/AT or
MCA bus to any host CPU is relatively simple. The only disadvantages are
that the VRAM is totally hidden from the main CPU via the chipset. Of course
you can twiddle any pixel via commands to the chipset, but the performance
advantages come from using the line_draw/fill/bitblt (and its fast!)
scissoring etc features. And, the chipset comes in a 160 pin and 80 pin quad
flatpack, which requires very very steady hands to solder (its meant for
surface mounting). But I feel, based on the minimum PC532 trace spacing (12
mil), that it is do-able. The best thing is that it will connect directly to
a NEC 3D display, i.e. to industry standard equipment. The chipset is
apparently around the $50 mark in small quantities, which means the main
expense is the VRAM and host CPU. It has a 16 bit data interface and FIFOing
for sending multiple commands to it and also FIFOing for bitblt, it uses the
VRAMs in page mode and 32 bits wide for performance. Now the question is
which CPU?  The 32GX32 is nice if we can get it cheap enough, the 68020 is
the other choice, its pretty cheap, or the 32cg16 if we want instruction set
compatibility and cheapness (but slower).

best regards,

-- 
George Scolaro
(try (pyramid|hoptoad|sun|vsi1)daver!vw25.chips.com!gs)

From owner-pc532%daver@mips.com Fri Jan 12 20:28:01 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.4 2/14/89)
To: pc532@daver.uu.net
Subject: Mach update
Date: 12 Jan 90 22:34:50 GMT (Fri)
From: ken%mm%gatech@ames.arc.nasa.gov (Ken Seefried iii)
Status: O


I figured this would be of interest to the list...

*------------------------------------------------------------------------------*

From: Rick.Rashid@CS.CMU.EDU
Organization: Carnegie Mellon, Pittsburgh, PA

CMU does plan to make the Mach kernel (without Unix compatibility support)
available without external licenses.  This kernel has been running at
CMU for over a year and is now up on Vax, Sun 3 and PMAX platforms.

CMU has two projects ongoing to provide binary Unix compatibility for
the pure Mach kernel.  The first to be completed is based on a
single Mach task with many internal cthreads and a complementary
transparent shared library.  It is fully compatible with the 4.3bsd
binaries which ran on earlier versions of Mach and runs on Vax,
Sun 3 and PMAX platforms on the pure Mach kernel.  A second effort
to build a restructured OS environment which would also support
BSD Unix is also underway.  That system splits all key OS functions
into separate servers whose functions are largely generic (i.e.
independent of Unix functionality) and would be usable for a
variety of OS environments.

Current plans have us distributing the pure kernel with the single
server Unix environment to outside research groups in late spring.
Access to the Unix server would still require Berkeley licensing
but access to the kernel itself, Mach libraries, etc. would not.

-Rick


-- 
    ...ken seefried iii          ...!<anywhere>!uunet!gatech!mm!ken
         MetaMedia, Inc.              ken%mm.uucp@gatech.edu 
           Atlanta, Georgia, USA        obquote: "I feel...like a god..."
    
 "Sunny day...good friends...cold beer...life just don't get no better'n that"

From owner-pc532%daver@mips.com Fri Jan 12 21:01:40 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
To: pc532@daver.UU.NET
Subject: Re:  Minix/532 questions
Date: Fri Jan 12 13:26:59 1990
From: blank%clanhlm@ucscc.UCSC.EDU
Status: O

	Shared libraries do not necessarily imply run-time linking.
	For example, one implementation has a stub of a library
	linked in, which only contains the code for initializing
	the shared library (loading the function vector).  The total
	extra overhead is about one system call.

	A picture:

	% foo

	main()

	open()	-->	dispatch function ()
			--> init library, set init flag (one mmap call)
			--> call open

	read()	->	dispatch function ()
			--> call read

	.
	.
	.

	exit()

	It is a very low overhead (on one set of mesurements, about
	40% of one exec -- lost in the noise of most program's running).
	The drawback is that you have to page in the libraries.  If
	you are running a significant amount of code, the chances are
	that you already have the pages in core.  There is also
	an additional overhead of an indexed jump, but it is minimal.
	In short, the shared library code is typically a preformance
	win.  (Let us NOT speak of OS/2).

	Multics had an even more elegant implementation -- for a complete
	description, Organick (sp?) 1972.

					John


From owner-pc532%daver@mips.com Fri Jan 12 21:04:20 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Date: Fri, 12 Jan 90 16:34:23 pst
From: Bruce Culbertson <culberts%hplwbc@hplabs.hp.com>
To: pc532@daver.UU.NET
Subject: Re:  GNU compilers/assemblers for the 532.
Status: O

Mark Mason writes...

> I have noticed some discussion about gnu cc and c++ for the 532 system.
> 
> I am in the last stages of porting gcc 1.36 and g++ 1.36.1 to a
> Tektronix 32000 workstation.
> 
> Sounds like Dave & Bruce have gcc working, which is the biggest first
> step.

Yes, I have been using gcc with my 32016 system for more than a year.
I wrote my own as, ld, nm, ar, and ranlib because I had not heard of
GNU when I started my project.  Porting Minix to the 32000 was a pretty
good stress test for these tools although I am not dumb enough to claim
that the tools are bug-free!  However, there are no outstanding bugs
and I have not fixed a bug in the last six months.

I am using gcc 1.35.  I assume updating to 1.36 would be simple but I
have not tried it.  My assembler supports all the 32532 instructions and
registers.  The one exception is that the tools have very limited support
for external addressing.  I felt that external addressing was too slow
to be worth the bother.  I have not tested the instructions which do
not run on my 32016 system.

> Something the manual does not say well is that if you have a
> FASCIST_ASSEMBLER (an assembler that checks .stabs) you also have to
> define USE_COLLECT while compiling gcc.c and collect.c. This is
> because g++ uses .stabs of the form "___CTOR_LIST__",22,0,0,LABEL
> to announce a constructor or destructor. FASCIST_ASSEMBLER means the
> assembler can't handle these stabs, USE_COLLECT means run the collect
> program during final link to handle getting info about static
> contructors and destructors.

What is .stabs?  Is it an assembler directive for adding information to
the symbol table?  Perhaps this is only used by the debugger.  I am a
member of the dwindling minority that never uses source code debuggers.
By the way, my tools do not support gdb or any other source code
debugger.  This may be a reason to eventually switch to gas or to revise
my tools.

> I understand that Bruce has a assembler for the 32000 that he did
> along with the gcc port. I would _love_ to get a copy for my machine
> at home (90% of my porting problems are due to my assembler which has
> its own ideas about opcode syntax).

I would be happy to send it to you.

Bruce Culbertson

From owner-pc532%daver@mips.com Fri Jan 12 22:37:35 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Subject: Build List Release 1.02
To: pc532%tarpit@daver.uu.NET
Date: Fri, 12 Jan 90 20:41:35 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]
Status: O


I suspect this will be the final posting of the "Build List".

happy building,
johnc

----------------------------------------------------------------------------------------------------------------

                        pc532 Build List

        Parts List Revision :  1.02
        Date last revision  :  12 jan 90
        BOM reference       :  Version 1D
        Contact             :  J.L. Connin     tarpit!manatee!johnc


        Table of Contents   :
                1.0  Introduction
                1.1  Notes / History
                1.2  Legend
                1.3  Supplier Names and Addresses
                2.0  Bill of Materials
                2.1  BOM pc532, kit parts
                2.2  BOM pc532, user supplied parts
                2.3  BOM - Ancilary Items
                3.0  Construction Notes

----------------------------------------------------------------------------------------------------------------

1.0  Introduction
-----------------

    The intent of the Build List is provide an resource of information
    related to the physical construction of the pc532 (ie. sources of
    supply, construction hints, etc).

    Very simply, from time to time, I will post to the pc532 mailing list
    an updated copy of the Build List based upon input I receive from YOU,
    the pc532 members.


1.1  Notes / Revisions:
-----------------------
    1)  johnc, 22dec89, received version 1D BOM (ie. pcb fab release) from george.
    2)  johnc, 22dec89, started ancilary BOM section
    3)  johnc, 07jan90, split BOM into kit and user supplied parts, also grouped
                        like parts together
    4)  johnc, 07jan90, added more ancilary parts
    5)  johnc, 07jan90, added suppliers
    6)  johnc, 12jan90, added part nos, supplier

1.2  Legend:
-----------

    *  -  Included in pc532 kit

    All other parts (ie. those not prefixed by '*') are user supplied.

    Source of supply of user supplied parts, were known, is indicated
    immediately after the part description in the BOM.  The source of
    supply fields, from left to right are:  Distributor, catalog page
    number, distributor part number, and part price.  For example,

        JDR,            page85,         NOSLOT-CLK      29.95


1.3  Supplier Names and Addresses:
---------------------------------

        Distributor     Reference               Minimum         Telephone
        -----------     ------------            -------         ----------------
        JDR             1990 Catalog,                           1-800-538-5000
        Jameco          1990 Catalog,           $25.00          1-415-592-8097
        Digi-key        Nov-Dec89                               1-800-344-4539

        Arrow Elec.   (catalog sales)           $25.00          1-800-932-7769
        Allied Elec.  (catalog sales)           $25.00          1-800-433-5700

	Sun State Electronics                   $25.00          1-800-780-8777
	( has access to Hamilton/Avnet stock)


Where possible, your local surplus outlets are probably your best
source of supply.



2.0  Bill of Materials
----------------------

---------------------------------------------------------------------------------------------------
2.1  BILL OF MATERIALS     32532 AT MOTHERBOARD        V 1D Thu Dec 21 23:25:07 1989    PAGE   1
     pc532 kit parts
---------------------------------------------------------------------------------------------------


     ITEM   QUAN.               DESCRIPTION                                         REF. DES.

*      5       2	CAPACITOR,50PF,                                             C23,C24         
*      7       1	CRYSTAL, 3.6864MHZ                                          XTAL1           
*     11       1	RESISTOR PACK,1K, 6 pin SIP, 5 common resistors             RES1            
*     14       2	FUSE, 1 Amp Pico Fuse for SCSI                              F1,F2           
*     16       6	RESISTOR,22, 8 pin Sip, 4 separate resistors                RES2,RES5,RES6
*     17       2	RESISTOR,220, 8 pin Sip, 4 separate resistors               RES15,RES16     
*     18       4	RESISTOR,47, 8 pin Sip, 4 separate resistors                RES10,RES11,RES3
                                                                                    RES4
*     19       1	RESISTOR,4K7, 16 pin Dip, 15 common resistors               RES13           
*     24       4	SCSI62 - THE 62 PIN IBM PC/AT BUS CONNECTOR                 CONN12,CONN13   
                                                                                    CONN14,CONN15
*     35       4	2681/2692 - DUAL CHANNEL DUART                              U48,U52,U55,U60 
*     36       1	74ALS6311 - STATIC COLUMN/PAGE MODE ACCESS DETECTOR         U36             
*     37       4	220/330 OHM 14 PIN DIP TERMINATOR                           RES12,RES14     
                                                                                    RES17,RES18
*     39       1        27256 - UV ERASABLE PROM 32KX8, 200 ns                      U44
*     41       2        PAL16L8 - PROGRAM ARRAY LOGIC, B - SPEED,                   U37,U40
*     42       1        PAL16R6 - PROGRAM ARRAY LOGIC, B - SPEED,                   U38
*     43       1        PAL16R8 - PROGRAM ARRAY LOGIC, D - SPEED,                   U39
*     44       1        PAL20L8 - PROGRAM ARRAY LOGIC, D - SPEED,                   U19
*     45       1        20V8A-CMOS-GAL-15ns ELECTRICALLY ERASABLE                   U20
*     46       1        32202 - 32000 INTERRUPT CONTROL UNIT, 10Mhz                 U46
*     47       1        32532 - 32000 SERIES HIGH PERF.  32 BIT BUS CPU, 25Mhz      U35
*     48       1        32381 - 32000 SERIES 32 BIT BUS FPU, 25Mhz                     U24
*     53       2	74AS832 - HEX 2 INPUT OR DRIVERS                            U14,U15         
*     54       1	AIC6250 - HIGH PERFORMANCE SCSI PROTOCOL CHIP               U41             
*     56       1	DP8490 - ENHANCED ASYNCHRONOUS SCSI INTERFACE (EASI)        U57             
				  44 pin PLCC package
*     57       1	IBMPOW - IBM AT POWER CONNECTOR                             CONN11          
*     59       8	MC145406 - HEX RS232 CMOS TRANSCEIVER                       U47,U49,U51,U53 
                                                                                    U54,U56,U59,U61

*     23       1	74AC32 - AS TTL QUAD 2 INPUT OR GATE                        U58             
			Added to pc532 kit, 11jan90, by George


*      1       5                44 pin PLCC sockets (for scsi and duarts)
*      2       1                68 pin PLCC sockets (for AIC-6250)
*      3       1                175 pin PGA socket (for 32532 CPU)
*      4       1                68 pin PGA socket (for 32381 FPU)
*      5       8                30 pin sockets (for unleaded SIMM memory modules)


---------------------------------------------------------------------------------------------------
2.2  BILL OF MATERIALS     32532 AT MOTHERBOARD        V 1D Thu Dec 21 23:25:07 1989    PAGE   1
     pc532 user supplied parts
---------------------------------------------------------------------------------------------------

     ITEM   QUAN.               DESCRIPTION                                         REF. DES.

       1      69        CAPACITOR, 0.1uf, 0.3 inch spacing, Monolithic Bypass
                               C1,C10,C11,C12
                               C13,C14,C15,C16,C17,C18,C19,C2,C20,C21,C22,C25
                               C26,C27,C28,C29,C3,C30,C31,C32,C33,C34,C35,C36
                               C37,C38,C39,C4,C40,C41,C42,C43,C44,C45,C46,C48,
                               C49,C5,C50,C51,C52,C53,C54,C55,C56,C57,C58,C6
                               C61,C62,C63,C64,C65,C66,C69,C7,C70,C71,C72,C73,
                               C74,C76,C78,C8,C9

                	Sprague, Series 920C, DIP Monolythic Ceramic, 
			one-section, 2-pins, 0.1uf, 50v, PN - 923CZ5U104M050B
			Sun State Electronics,  0.29 each


       2       1	CAPACITOR,10PF,                                             C75             

       3       4	CAPACITOR,10UF,25V                                          C59,C60,C67,C68 

       4       1	CAPACITOR,33UF,16V                                          C47             

       6       1	CAPACITOR,5PF,                                              C77             
----
       8       1	DIODE, IN4148                                               D2              
                        Digikey         p49,            1N4148         0.60/10

       9       2	DIODE, IN5817 (SCSI DIODE, Schottky)                        D1,D3           
                        Digikey         p49,            1N5817          0.48

      10       4	LIGHT EMITTING DIODE, (0.1 inch centers, end stackable)     LED1,LED2,LED3  
                                                                                    LED4
----
      12       1	RESISTOR,100, 1/4W, 5%                                      R2              

      13       3	RESISTOR,10K, 1/4W, 5%                                      R1,R4,R5        

      15       1	RESISTOR,1K, 1/4W, 5%                                       R6              

      20       2        RESISTOR,???, BCLK, /BCLK terminator (TBD)                  R3,R7
----
      21       1	74AS00 - AS TTL QUAD TWO INPUT NAND                         U30             
			Arrow, Allied, Sun State

      22       1	74ALS14 - ALS TTL HEX INVERTER WITH SCHMITT TRIGGER         U42             
			Arrow, Allied, Sun State
/*-----------------------------------------------------------------
      23       1	74AS32 - AS TTL QUAD 2 INPUT OR GATE                        U58             
			Arrow, Allied, Sun State

  Part changed to 74AS32 and moved to pc532 kit section, 11jan90
----------------------------------------------------------------*/

      25       2	74AS74 - AS TTL DUAL D FLIP-FLOP                            U31,U32         
			Arrow, Allied, Sun State

      26       1	74F138 - FAST TTL 3/8 DECODER                               U33             
                        Digikey         p33,            74F138PC        0.79
			Sun State

      27       2	74AS174 - AS TTL HEX D FLIP-FLOP                            U26,U50         
			Arrow,  Allied, Sun State

      28       3	74AS258 - AS TTL QUAD 2 TO 1 MUX, INVERTED TS OUTPUT        U27,U28,U29     
			Arrow, Allied, Sun State

      29       4	74AS280 - AS TTL 9-BIT PARITY GEN/CHK                       U1,U2,U3,U4     

      30       1	74AS374 - AS TTL OCTAL FLIP-FLOP WITH TS OUTPUT             U16             
			Arrow, Allied, Sun State

      31       1	74AS646 - AS TTL OCTAL REGISTERED/TRANS WITH TS OUT         U43             
			Arrow, Allied

      32       4	74AS1004A - AS TTL HEX INVERTING DRIVER                     U17,U21,U22,U5  

      33       1	74ALS1034A - ALS TTL HEX NON-INVERTING DRIVER               U45             
			Arrow, Allied

      34       2        74AS1034A - AS TTL HEX NON-INVERTING DRIVER                 U18,U23
			???, 

----

      40       8        MSC411024 -  1M X 9 BIT DYNAMIC RAM MODULE                  U10,U11,U12,U13 
				  OR 1M X 8 (FOR NO PARITY), FAST PAGE 80 ns        U6,U7,U8,U9
				  Toshiba part # THM81000AS-80  (1M X 8)
                                  Toshiba part # THM91000AS-80  (1M X 9)
				  NEC part #     MC-421000A8-80 (1M x 8)
				  NEC part #     MC-421000A9-80 (1M x 9)
				  Motrola        MCM91000 S80	(1M x 9)
						 MCM91000 GS80  (1M x 9)

			4 SIMMs are the minimum configuration. Note that the 
                        devices must be unleaded, i.e. for use in sockets.

---
      38       1        XTALM - CRYSTAL OSCILLATOR MODULE, 50Mhz                    U25
                        Digikey,        page61,         x121,           6.19
			Sun State

      52       1        CRYSTAL OSCILLATOR MODULE, 20MHZ                            U34
                        Digikey         p51,            x119            5.78
			Arrow, Allied, Sun State
---

  +-  49       1        JUMP1 - SINGLE JUMPER HEADER                                J3
  +-  50       2        JUMP3 - 3 PIN JUMPER                                        J1,J2
  |                     JDR
  +-->         1        Header Pins, 1 x 40, straight male
                        JDR,                            HDR-40,         $0.99

  +-  51       1        JUMP4 - 4 LOCATION JUMPER BLOCK                             CONN2
  +-  55       2        50 WAY TRANSITION CONNECTOR UNSHROUDED (JUST PINS)          CONN1,CONN16
  +-  58       8        JUMP10 - 10 WAY JUMPER BLOCK UNSHROUDED (JUST PINS)         CONN10,CONN3
  |
  +-->         3        Header Pins, 2 x 40, straight male
  |                     JDR                             HDR-80,         $2.49
  +-->                  Header Pins, straight male
	       4        Jameco, 2 x 20                  923862R,        $0.59
	       2	Jameco, 2 x 50			923866R,	$1.35

---------------------------------------------------------------------------------------------------
2.3  BILL OF MATERIALS    32532 AT BOARD
     ANCILLARY ITEMS
---------------------------------------------------------------------------------------------------


     100       1        NO-SLOT CLOCK
                        JDR,    page85,         NOSLOT-CLK      29.95

     101      21        IC socket, 14-pin, 0.3 inch width, solder tail, machined
                        JDR,                    AUGAT14,        $0.59
			Jameco,			14MLP,		$0.69

     102      14        IC socket, 16-pin, 0.3 inch width, solder tail, machined
			JDR,			AUGAT16,	$0.69
			Jameco,			16MLP,		$0.79

     103       7        IC socket, 20-pin, 0.3 inch width, solder tail, machined
			JDR,			AUGAT20,	$0.85
			Jameco,			20MLP,		$0.89

     104       3        IC socket, 24-pin, 0.3 inch width, solder tail, machined
                        JDR,                    AUGAT24SK,      $0.95
			Jameco,			24SMLP,		$1.15

     105       1        IC socket, 28-pin, 0.6 inch width, solder tail, machined
                        JDR,                    AUGAT28,        $1.09
			Jameco,			28MLP,		$1.29	

     106       1        IC socket, 40-pin, 0.6 inch width, solder tail, machined
                        JDR,                    AUGAT40,        $1.29
			Jameco,			40MLP,		$1.49

-------

     110       8        Connector, IDS, 10-contact, (ie. serial cable assy)
                        JDR, IDS10, $0.55
                        Jameco,                 S10,            $0.59

     111       4        Connector, IDS, 50-contact  (ie. scsi  cable assy)
                        JDR,                    IDS50,          $1.69
                        Jameco,                 S50,            $1.39

     112       8        Connector, IDC, D-Sub, 9-pin, male, (ie. serial cable assy)
                        JDR,                    IDB09P,         $1.39
                        Jameco,                 CDE9P,          $2.39

     113      ---       25 to 9=pin serial adapter
                        JDR,                    GENDER-9-25,    $4.95

     114       1        Connector, 2-pin                 (ie. reset cable assy)

     115       1        Switch, momentary, normally open (ie. reset cable assy)

-------

     120       4        Shorting Blocks
                        JDR,                    JUMPER,         $0.20
			Jameco, 		JOPEN, 		$0.19

3.0  Construction Notes.
------------------------

     (If this section gets to large, will split out as separate document).

1). Re: CAPACITOR,0.1, 0.3inch spacing, Monolithic Bypass
    Q.  Are these standard disc or IC-look-alike mounts?  Um, units are PF?

    A.  0.1 microfarads (decoupling caps), IC look-alike-mounts.

2). Re: RESISTOR,???, BCLK, /BCLK terminator (TBD)        R3,R7
    Q.  Has this value been determined yet or is it it some sort of tuning 
        or timing resister that must in some way be determined on a per 
        board basis?
    A.  George writes: The prototypes worked fine without, but when I get 
        the new pcbs and build one up, I'll stick a 400mhz scope on and 
        determine the best value.

3). Re: 49       1	JUMP1 - SINGLE JUMPER HEADER                  J3
        50       2	JUMP3 - 3 PIN JUMPER                          J1,J2
        51       1	JUMP4 - 4 LOCATION JUMPER BLOCK               CONN2
        55       2	50 WAY TRANSITION CONNECTOR UNSHROUDED (JUST PINS) 
                        CONN1,CONN16    

   George writes: JUMP1 is 2 pins 0.1 inch centers. JUMP3 is 3 pins 0.1
   inch centers. JUMP4 is 4 x 2 pins 0.1 inch centers. The 50 way is 
   25 x 2 pins 0.1 inch centers (unshrouded, ie just the pins in a plastic 
   carrier).

4). Question:  How static sensitive are some of these parts?  Are all the
    critical parts socketed so that I don't need to worry about blowing
    them during soldering etc?  Also, any requirements or advice on soldering
    this puppy?  60-40 tin/lead rosin core solder good enough?

    George writes: The only static sensitive parts are the EPROM, the DRAM, 
    the CPU, FPU, RS232 CMOS driver/receivers, DUARTs, SCSI devices. Just 
    use the normal precautions, ie don't touch the chips until they are 
    ready to plug in, leave them in the antistatic package until you're ready.
    Then when you pick them up, touch the ground on the PCB before plugging 
    them in. Normal solder is fine.  We are supplying the sockets for the CPU,
    FPU,DRAM,SCSIs and DUARTs. The rest of the sockets will be your problem.
    I recommend could quality machined pin sockets, they cost a bit more but
    are well worth it.

5) George writes, due to the xtal input difference between the 2681 DUART 
   and the 2692 DUART, the 74AS32 device must be changed to a 74AC32 device. 
   The 2692 outputs a signal that does not reach below about 1V causing the 
   TTL level of the 74AS32 to be violated. Using a 74AC32 gives us speed, 
   which is needed through one of the other gates (in the same package) and 
   50% threshold for the oscillator output of the 2692. Signetics recommends 
   the use of a 74Cxx device to buffer the oscillator, but we need a 74AC 
   (for speed). We will supply the 74AC32 part with the kit.


From owner-pc532%daver@mips.com Sat Jan 13 01:13:01 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Subject: X, G300, DSP
To: pc532%tarpit@daver.uu.NET
Date: Fri, 12 Jan 90 23:38:51 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]
Status: O


I was just looking at a brouchure on a VME board which incorporates the
Inmos G300 Color Video Controller.  I thought would be of interest.
Additionally, it has one twist for which I do not understand the implications.
An on-board DSP can be used for graphics processing.

The board, VME-MMI-100a/b is manufactured by Vigra Inc., 4091 Morena
Blvd, Suite  502, San Diego, CA 92117, (619) 483-7531.

The board contains the following sections:

1)  Video Section
    o  Inmos G300 Color Video Controller, 85 Mhz.
       (This is the slowest G300 chip, Inmos also offers 100 and 110 Mhz with
        120 Mhz promised latter this year).
    o  Programmable from 25Hhz to 80Mhz in 5Mhz steps.
    o  On-chip logic allows any number of pixels per screen line
       in multiple of four pixels
    o  To 1024 pixels (ie 1024 kbytes of video ram)
    o  RGB can be programmed for compatible with VGA monitors, multisync
       monitors, as well as high performance interlaced and non-interlaced
       monitors.
   o   etc.

       (all board features mentioned basicly reflect the G300 chip 
        attributes).

2) Audio Section
   o Motorola DSP56001 digital signal processor
   o 14 bit A/D and D/A interface
   o Inputs at microphone and line levels
   o Output 2.5 watt power amplifier
   o Audio bandwidth programmable from telephone to AM broadcast quality.
   o Builtin firmware provides a variety of encoding and data compression
     methods.
   o DSP has assess to video memory and can be used for graphics processing.

     (??  Can anyone expound on the benefits, if any ?? )

3)  IO Section
   o  PC keyboard interface.
   o  Two rs232C serial ports (ie mouse, touch screen, scanner, etc)
   o  16 Bit timer is a by-product of 68681 DUART.


Board size is 9.2 x 6.3 inches.

regards,
johnc


From owner-pc532%daver@mips.com Sat Jan 13 01:13:10 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
To: pc532@daver.UU.NET
Subject: Re: X and Motif 
Date: Fri, 12 Jan 90 18:06:07 MST
From: Bdale Garbee <bdale@hpcssa.col.hp.com>
Status: O

> If we do get X going on the pc532, would anyone be interested in a
> Motif port?  I would be willing to do it, with a few caveats:

My humble employer is very Motif-focussed.  It would indeed make my life more
pleasant to have mwm around, if only for compatiblity with work...  I really
like twm 5.x better, but dunno how long the agony of supporting it across OS
revs will continue to seem worthwhile...

> Comments?

It's all irrelevant until/unless we've got X capability.  I've got a pair of
X terminals at home (a Visual 640XDS and an HP Kaleidoscope card in an AT 
clone), so the clients would be useful for me... but I'm not sure I'm the
average bear.

Anyone considered ethernet/802.3 for the pc532?  Are there any good SCSI to
ether cards for cheap?  I could use one today on my 32016 system...

Bdale

From owner-pc532%daver@mips.com Sat Jan 13 01:27:29 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: george@wombat (George Scolaro)
Date: Fri, 12 Jan 90 22:13:42 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Subject: Re: X and Motif
Status: O

> Anyone considered ethernet/802.3 for the pc532?  Are there any good SCSI to
> ether cards for cheap?  I could use one today on my 32016 system...
> 
> Bdale

The et532 is an ethernet plug in board for the pc532. It has been
discussed previously. Basically:

	32gx32 @ 20mhz
	1 meg fast page dram (8 x 256kx4 drams <= 100ns)
	1 ethernet thin/thick (NS DP8390 chipset)
	16 serial channels (2 x octarts, signetics 2698B)
	1 scsi port (DP8490)

The routing of this board is finished. It is ready to go to photo-
plotting and then to the pcb shop. I am waiting for people to get
their pc532's running, get some pocket money and then to decide
if they want an et532 as well. Actually it is 2 boards, the main
board + the rs232 buffer/connector board (the latter isn't done yet,
but is real simple, 2 layers). The main board is 6 layers and pretty
full!

regards,

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com Sat Jan 13 03:03:10 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Subject: Re: DRAM
To: pc532%tarpit@daver.uu.NET
Date: Sat, 13 Jan 90 1:14:15 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]
Status: O

[in Message-Id: <948794@mac.Dartmouth.EDU>, Steven.D.Ligett writes]

>                                                         Is there serious
> interest in a group buy?

Yes, but not in a manner that burdens someone with managing $$.  

Locally the suppliers are asking too much, and nationally I do not
know of a good supplier.  I favor the Toshiba (1M x 9) SIMM's.
Reason: (a) the Toshiba is supposedly hottest on the market (ie. greater
access margin), and (b) 1 Meg x 9 is more universal (ie. can be reused in 
a system that demands parity).

regards,
johnc


From owner-pc532%daver@mips.com Sat Jan 13 03:03:15 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Subject: Re: dump frame buffer, anyone ?
To: pc532%tarpit@daver.uu.NET
Date: Sat, 13 Jan 90 1:18:37 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]
Status: O


[ in Message-Id: <m0gmbL7-0000n6C@vw25.chips.com, George Scolaro writes]

> The board that I visualize as being relatively risk free to do involves the
> C&T 8514A chip set. The chipset has a very simple interface (either PC/AT or
> MCA style), supports 1024x768x256 colours using 8 1mx1 VRAMs, a colour DAC
> (either Inmos IMSG176/178 or Brooktree BT471/478), some caps, resistors, a
> connector, LM339, a voltage reference and a 74F74. To interface the PC/AT or
> MCA bus to any host CPU is relatively simple. 

[ stuff deleted ]

>
> The best thing is that it will connect directly to
> a NEC 3D display, i.e. to industry standard equipment. 
>

Though more expensive, I kind of favor the Inmos G300 110 Mhz Color video 
controller.  It seems to require little glue logic (Inmos claims 5 or less
chips) and tends to avoid the problem of designing with high frequency
signals by using "multiplexed pixel ports" (ie. on-board digital signal
are 0.25 percent of the video frequency).  Also, it appears that it can
be programmed to handle monitors ranging from VGA to 1280 x 1024 x 256
noninterlaced at 60 Hz refresh.  etc.

While the NEC 3D monitor is attractively priced (about $599) I understand
it is interlaced only, and that under X interlace is noticeable.  
As an alternative, I believe that surplus high resolution color monitors
can be had for around $300-500.  I am not familar with them, but the 
following color monitors were recently quoted at $300:

	Hitatchi  MM-3619A
        Hitatchi  MM-3619N
	Ikekami	  203HLP
        Ikekami   203HLA
	ADAGE CM80, Part 704248-201

> Now the question is
> which CPU?  The 32GX32 is nice if we can get it cheap enough, the 68020 is
> the other choice, its pretty cheap, or the 32cg16 if we want instruction set
> compatibility and cheapness (but slower).

The Inmos transputer has not been mentioned as a possible CPU.  It supports
graphic instructions, has programmable builtin DRAM control, and would
not required a mini-OS (ie. controller OS is build-in hardware).  Also, 
the T400 and T805 are interchangeable permiting choice of cost / performance 
point.  The T400 is approximately $90 1-24 quanity.  The T805 has a builtin
floating point unit and more internal fast ram.  The draw-back is the lack 
of "freely" available binary tools, yet another binary environment, 
and no MMU if desired.

BTW:  I am not necessarly pushing transputers, but I do believe they provide
an interesting alternative that has not been discussed.  Gee, we might even 
find a use for there serial links !

best regards,
johnc


From owner-pc532%daver@mips.com Sat Jan 13 09:02:08 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: mea@mea.utu.fi (Matti Aarnio)
Subject: Re: X, G300, DSP
To: pc532@daver
Date: Sat, 13 Jan 90 15:25:00 EET
X-Mailer: ELM [version 2.2 PL10]
Status: O

> I was just looking at a brouchure on a VME board which incorporates the
> Inmos G300 Color Video Controller.  I thought would be of interest.
> Additionally, it has one twist for which I do not understand the implications.
> An on-board DSP can be used for graphics processing.
...
>    o DSP has assess to video memory and can be used for graphics processing.
> 
>      (??  Can anyone expound on the benefits, if any ?? )

  Yes in deed.  'Old' highend workstations have commonly used slice/signal-
processors to do 3D transformation rendering.
That work essentially contains milling thru an 4x4 matrix.
Basic operation necessary there is Multiply-Accumulate, as one (vertical)
vector is multiplied with that matrix, and result is 2D! transformed coor-
dinates.

  The idea is to feed in description of objects in 3D, and also transformation
rules (or ready matrix) which is used for all those points to get willed
instantation of object.

Well, thats the use.

A good reference for these Matrix things is:
  Principles of Interactive Computer Graphics, 2nd edition.
   William M.Newman, Robert F. Sproull, McGraw-Hill,
	(two possible ISBN's) ISBN 0-07-066455-2, 0-07-046338-7
	(First one is propably correct)
...
> regards,
> johnc

	/Matti Aarnio	<mea@mea.utu.fi>
			<trickle-maint@funic.funet.fi>
			<mea@funet.fi>
	FUNIC:  Finnish Academic and Research Network Project
		Network Information/Software Archival Service


From owner-pc532%daver@mips.com Sat Jan 13 14:05:42 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: george@wombat (George Scolaro)
Date: Sat, 13 Jan 90 10:36:29 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Subject: Re: dump frame buffer, anyone ?
Status: O

[In the message entitled "Re: dump frame buffer, anyone ?" on Jan 13,  1:18, John L. Connin writes:]
> 
> [ in Message-Id: <m0gmbL7-0000n6C@vw25.chips.com, George Scolaro writes]
> 
> > The board that I visualize as being relatively risk free to do involves the
> > C&T 8514A chip set. The chipset has a very simple interface (either PC/AT or
> > MCA style), supports 1024x768x256 colours using 8 1mx1 VRAMs, a colour DAC
> > (either Inmos IMSG176/178 or Brooktree BT471/478), some caps, resistors, a
> > connector, LM339, a voltage reference and a 74F74. To interface the PC/AT or
> > MCA bus to any host CPU is relatively simple.

Maybe I should clear up how simple? The C&T chipset will connect directly to
the PC/AT or MCA (just a jumper option). i.e. the data & address lines will
connect directly to the host CPU. The control lines are very simple, the AT
is a very basic bus (having designed boards to plug in before).

> Though more expensive, I kind of favor the Inmos G300 110 Mhz Color video 
> controller.  It seems to require little glue logic (Inmos claims 5 or less
> chips) and tends to avoid the problem of designing with high frequency
> signals by using "multiplexed pixel ports" (ie. on-board digital signal
> are 0.25 percent of the video frequency).  Also, it appears that it can
> be programmed to handle monitors ranging from VGA to 1280 x 1024 x 256
> noninterlaced at 60 Hz refresh.  etc.

The C&T will also do the following:
	 640 x  480 non interlaced	50.35 mhz
	1024 x  768     interlaced	44.90 mhz
	1024 x  768 non interlaced	65 mhz
	1280 x 1024     interlaced	80 mhz
	1280 x 1024 non interlaced	110 mhz
	1600 x 1200     interlaced	125 mhz
	1600 x 1200 non interlaced	160 mhz
	or user specified (the data sheet claims up to 2560x2048 with    
	external ECL logic = 300mhz)

To do the higher resolutions just requires more VRAMs. It also does pixel
multiplexing, but very cleverly. What it does is input 4 pixels (or 5 for the
higher resolutions) worth of data at a time. Each pixel is actual 8 bits of
VRAM data. i.e. it takes 32 (or 40) bits of data from 8 (or 10) 256x4 VRAMs
in one gulp. The second chip in the chipset takes this 32 (or 40) bits of
video data and then shifts it out (through a special shifter) to produce 8
bits of data (256 colours) that connect to the colour DAC which generates
the R,G and B pins.

> While the NEC 3D monitor is attractively priced (about $599) I understand
> it is interlaced only, and that under X interlace is noticeable.

You understand wrong. I use one to do PCB and schematic entry at home and it
definitely is NOT interlaced. If it is, it certainly is VERY flicker free!

> > Now the question is which CPU?  The 32GX32 is nice if we can get it cheap
> > enough, the 68020 is the other choice, its pretty cheap, or the 32cg16 if
> > we want instruction set compatibility and cheapness (but slower).

> The Inmos transputer has not been mentioned as a possible CPU.  It
> supports graphic instructions, has programmable builtin DRAM control,
> and would not required a mini-OS (ie.  controller OS is build-in
> hardware).

The controller OS that you mention is very primitive. It really only amounts
to a small scheduler. In addition (having designed a board that talked to a
transputer board (designed by a colleague)) I found the transputer boot
environment a major pain in the brain. Unless Inmos has made BIG steps
forward in the bootstrap environment AND in documentation, I wouldn't touch
the transputer for money. The only way we could boot the transputer board
was via a link adapter, with my board providing the boot code. I assume the
T400 etal. can self boot from eprom?


-- A bit of noise follows:

Also has anyone out there personal experience in designing a Transputer
based product? Before I, personally, would commit to doing a pcb run (this
includes: designing, doing the schematic, doing the pcb layout,
photoplotting and finally the PCB run itself) I want to be 100% confident
that the design will work. i.e. I don't want to design a wizzy board in
which any of it has risk associated with it. I would first do a wire wrap
prototype in that case. The PC532 core design was wirewrapped to test the
concept, this paid off in the first pcb prototype. There was one cut and
jump (and this was because I got some mis-information from someone at NS).
The ET532 has a high probability of being 100% correct first time, this is
because the core circuit is straight out of the PC532, the ethernet circuit
is out of NS's ethernet demo board (we have written software for it, and
interfaced one to a 32cg16 in our homebrew ethernet based printer buffer) and
the Octart serial ports are used in a 68000 based printer buffer design we
have just done (that was wirewrap prototyped). So, you can see that in both
cases the confidence level was very high.

Don't get me wrong, I love to do challenging design work (I'm currently
fairly bored as it is waiting to think up something new), BUT when its my
(and likely other people's) money I want to be confident that the design
WILL work. When I design for work, its a different case, that is what (large)
companies expect. They assume a prototype run, then a pilot run, then
production (if all goes well). No commercial design ever works first time,
the marketing people will see to that.

-- Noise kinda' ends.

> Also, the T400 and T805 are interchangeable permiting choice
> of cost / performance point.  The T400 is approximately $90 1-24 quanity.
> The T805 has a builtin floating point unit and more internal fast ram.
> The draw-back is the lack of "freely" available binary tools, yet another
> binary environment, and no MMU if desired.

This is the main drawback. Unless we can get access to source for transputer
tools then its going to be a loser. I (and I'm sure most others) want to use
the PC532 as a basis for developing and debugging and software that will run
in the PC532 system. Having to use a DOS or DEC machine to build the
transputer code is definitely not practical. Have you ever looked at
transputer assembly code? It is definitely revolting - definitely very risc,
to load 32 bit constants you have to split them into 8 bits (or 4 bit, can't
exactly remember) and load them one at a time....

> BTW:  I am not necessarly pushing transputers, but I fdo believe they
> provide an interesting alternative that has not been discussed.  Gee, we
> might even find a use for there serial links !

What serial links? The transputer uses link adapter chips that are definitely
not UART compatible or are you hinting at the spare traces that now link the
expansion slots?

> johnc

whew!

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com Sat Jan 13 21:02:10 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: athos@labtam.oz.au
To: pc532@daver.uu.net
Subject: PostScript and other cards
Date: Sun Jan 14 01:11:27 1990
Status: O

It's been a while since I posted to the group, but life's been busy with
changing net addresses and other hassles.  But I have managed to keep up
with the reading.  Anyway, down to business.

The design for a PostScript board (or the "ps532" as someone called it) seems
to be progressing.  In any case, Marc Boschma (the guy here working on it)
throws ideas and documents at me every now and then.  I'll let him tell you
about it himself when the design settles down a bit.
For the interested, his net address is marcb%eyrie@labtam.oz.au


While waiting for the PCBs, our major PC532 work here is towards an OS for it.
It's a multi-processor system developed from Minix and Amoeba, although if
bits of Mach become available we'll probably grab those also (yes the OS is
intended to be source-code distributable).

One of my earlier questions that I don't think was answered was in relation to
distribution of Minix/532 when it's available.  What physical format will it
be in that we can convert into a bootable PC532 format?  I would have said that
booting from a tape would cut out too many people.

Our OS being capable of using several PC532s connected together with SCSI as
one loosely-couple multiprocessor, one board we're most interested in is a
variant of the pc532.  Basically a stripped down board shoe-horned into an
adaptor card.

Before you jump up and down saying "It won't fit!" I'll elaborate: Leave out
the serial ports, the synch/asynch SCSI port, and possibly one bank of SIMMs.
Does anyone out there think the schematics could be laid out to fit an
AT-length-and-height card?
I recall someone asked a similar question early in the life of the mailing
list but I don't remember the details.

That's not something we want straight away, but if our (or anybody else's)
distributed code works according to plan then it seems the sensible way to
bump up the power of some PC532s.


Also, one of our guys is working on the idea of using Amiga 500s as X display
stations.  It's an extension of the distributed OS, with the X server split
between one of the PC532s and the Amiga(s).
It's certainly not ultra-high resolutions and colours, but for the price it
may be reasonable.  And it also gives you an Amiga (and a Mac :-|
___________________________________________________________________________
David Burren (Athos),			ACSnet: athos%eyrie@labtam.oz.au
img Consultants,
G.P.O. Box 3304GG, Melbourne 3001


From owner-pc532%daver@mips.com Sun Jan 14 01:52:14 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Subject: Re: dump frame buffer, anyone ?
To: pc532%tarpit@daver.uu.NET
Date: Sun, 14 Jan 90 0:10:34 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]
Status: O

[In the message entitled "Re: dump frame buffer, anyone ?" on Jan 13, George
Scolaro writes:]

>
> The C&T will also do the following:
>	 640 x  480 non interlaced	50.35 mhz
>	1024 x  768     interlaced	44.90 mhz
>	1024 x  768 non interlaced	65 mhz
>	1280 x 1024     interlaced	80 mhz
>	1280 x 1024 non interlaced	110 mhz
>	1600 x 1200     interlaced	125 mhz
>	1600 x 1200 non interlaced	160 mhz
>	or user specified (the data sheet claims up to 2560x2048 with    
>	external ECL logic = 300mhz)
>

I am impressed!  I had assumed that the 8514A chip set had a upper limit
of around 1024x768x256, and was feeling somewhat uncomfortable.  Are 
C&T 8514A data sheet available ??

>> While the NEC 3D monitor is attractively priced (about $599) I understand
>> it is interlaced only, and that under X interlace is noticeable.

> You understand wrong. I use one to do PCB and schematic entry at home and it
> definitely is NOT interlaced. If it is, it certainly is VERY flicker free!

Thanks for the first hand clarification.  This should be a definite win for
us in light of the anticipated price wars in the 8514 display market.
It appears that I got the wrong impression from various comp.sys.i386 
discussions concerning X-Windows.  

> > Now the question is which CPU?  The 32GX32 is nice if we can get it cheap
> > enough, the 68020 is the other choice, its pretty cheap, or the 32cg16 if
> > we want instruction set compatibility and cheapness (but slower).

>> The Inmos transputer has not been mentioned as a possible CPU.  It
>> supports graphic instructions, has programmable builtin DRAM control,
>> and would not required a mini-OS (ie.  controller OS is build-in
>> hardware).

> The controller OS that you mention is very primitive. It really only amounts
> to a small scheduler. In addition (having designed a board that talked to a
> transputer board (designed by a colleague)) I found the transputer boot
> environment a major pain in the brain. Unless Inmos has made BIG steps
> forward in the bootstrap environment AND in documentation, I wouldn't touch
> the transputer for money. The only way we could boot the transputer board
> was via a link adapter, with my board providing the boot code. I assume the
> T400 etal. can self boot from eprom?

First, please understand I am not trying to defend the transputer.  But on
the other hand I must confess I find them intriqueing.  In fact I recently
ordered two T400's to satisfy my curiosity.

I am tempted to argue the implication that the transputer's process 
management scheme is too primitive -- but I doubt if any useful purpose 
would be served.  However, I will note that Minix kernel code 'proc.c' 
and the transputers' process management look almost like twins.

Yes, the T400 can be booted from eprom.  Which one is selected is determined 
by sampling the input BootFromRom before the first instruction is executed 
after Reset is taken low.  At least thats what the data sheet says.

> -- A bit of noise follows:

[ discussion of need for low risk design process ]

I could not agree more !!!

> -- Noise kinda' ends.

>> BTW:  I am not necessarly pushing transputers, but I fdo believe they
>> provide an interesting alternative that has not been discussed.  Gee, we
>> might even find a use for there serial links !

> What serial links? The transputer uses link adapter chips that are definitely
> not UART compatible or are you hinting at the spare traces that now link the
> expansion slots?

Very simply, at the moment I wrote the above it struck me as kinda 
amusing that in a SCSI -> T400/T805 -> G300 design the transputer links 
are left flopping in the breeze.

best regards,
johnc

---
John Connin: manatee Orlando, Florida
         UUCP: {peora,uunet,ucf-cs}!tarpit!manatee!johnc


From owner-pc532%daver@mips.com Sun Jan 14 02:52:05 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: george@wombat (George Scolaro)
Date: Sat, 13 Jan 90 22:57:51 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Subject: Re: dump frame buffer, anyone ?
Status: O

[In the message entitled "Re: dump frame buffer, anyone ?" on Jan 14,  0:10, John L. Connin writes:]
> 
> > The C&T will also do the following:
> 
> I am impressed!  I had assumed that the 8514A chip set had a upper limit
> of around 1024x768x256, and was feeling somewhat uncomfortable.  Are 
> C&T 8514A data sheet available ??

I'm not sure. I have them (obviously since I work there), I'll have
to check with the manager of the group (he's downstairs) on Monday
and see if they have been released. I know that C&T was demonstrating
their demo board at Comdex last November.

regards,

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com Sun Jan 14 14:20:06 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Subject: DP8590 buy
To: pc532%tarpit@daver.uu.NET
Date: Sun, 14 Jan 90 13:25:48 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]
Status: O

 
Would someone like to split a DP8490N buy with me ??

The DP8490 is not a distributor stock part, and the minimum buy is 
10 parts for the DP8490N (ie 40-pin DIP package).  I misplaced the exact
price, but if my memory serves me correctly the prices is about
$12.00 per device.

FYI: the minimum buy for the DP8490V (44-pin plcc) is 25.

best regards,
johnc

---
John Connin: Orlando, Florida
         UUCP: {peora,uunet,ucf-cs}!tarpit!manatee!johnc


From owner-pc532%daver@mips.com Mon Jan 15 07:19:46 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
From: Pfister@inf.ethz.ch
Date: 15 Jan 90 10:21:02+0100
To: <pc532@daver.UU.NET>
Subject: Re: Re: Minix/532 questions
Status: O


> Shared libraries: I do not understand why people want this.  A shared
> Slibrary implies load-time linking, right?  Load-time linking makes
> exec prohibitively slow.  MacIntosh has shared libraries and applications
> take forever to load.

If the Macintosh takes a long time to load an application, this has certainly nothing to do
with shared libraries, since those are restricted to the toolbox and operating system modules
which mostly reside in ROM and are called via traps.

Load-time linking can be implemented in an extremely efficient way, such that its overhead
is not measurable.

Linking loaders, and the possibility to explicitly call the loader at run-time, are very powerful
tools for building extensible, object-oriented programs that use a minimal amount of disk
and memory space. Applications for our Oberon operating system are several order of
magnitude smaller than similar UNIX based programs, simply because of shared libraries.

Cuno Pfister

Institut fuer Computersysteme
ETH Zuerich
Switzerland


From owner-pc532%daver@mips.com Mon Jan 15 16:16:34 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Mon, 15 Jan 90 18:20:14 +0100
From: pell@isy.liu.se
To: pc532@daver.uu.NET
Subject: Archive
Status: O

The stuff George and Dave send out (PAL equations and friends) are now available
for FTP from isy.liu.se (130.236.1.3), directory 32k/PC532. The digests of
this mailing list has been moved to the subdirectory mail-list.

George: if you have any updates to those files, please send them to me so I can
keep the archive up-to-date.

Cheers,

    /Pell
--
"Don't think; let the machine do it for you!"
                                   -- E. C. Berkeley
Dept. of Electrical Engineering	                         pell@isy.liu.se
University of Linkoping, Sweden	                    ...!uunet!isy.liu.se!pell

From owner-pc532%daver@mips.com Wed Jan 17 15:21:28 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Date: Wed, 17 Jan 90 12:11 PST
From: dlr@daver.uu.net (Dave Rand)
To: pc532@daver.uu.net
Subject: Parts suppliers
Status: O

One supplier that we just ran across is Arrow. They have a toll-free
telephone number (in the U.S.) for ordering, accept Visa and Mastercard,
and seem to have all of the parts that you would want. The minimum order
is $25. Prices are a trifle high (74AS1004 is $1.22 ea), but not too bad.

We are just putting an order through them now - use at your own risk!

Number is 1-800-93-ARROW (1-800-932-7769).

BTW - uunet.uu.net went down yesterday, and is not up even as I write this.
Your mail may be delayed a day or two...

Dave Rand

From owner-pc532%daver@mips.com Wed Jan 17 20:02:44 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Wed, 17 Jan 90 16:26:07 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: gs@vw25.chips.com (George Scolaro)
To: pc532@daver
Subject: pc532 & parity
Status: O

Hi folks,
	I was just looking through the TI 1989 F-logic data book and
spotted their 74F280B parity checker/generator. Its timing specs are
actually 1ns or so better than the 74AS280. So, if you can get the TI
part, go for it...  Note: it has to be the 74F280B from TI, not other
manufacturers (unless they have the same timing spec). For comparison:

			TI 74F280B	NS 74F280	NS 74AS280
data to parity even/odd	 11ns MAX	17 ns MAX	12 ns MAX

regards,

-- 
George Scolaro
(try (pyramid|hoptoad|sun|vsi1)daver!vw25.chips.com!gs)

From owner-pc532%daver@mips.com Fri Jan 19 03:08:28 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Subject: SIMM report..
To: pc532%tarpit@daver.uu.NET
Date: Thu, 18 Jan 90 18:34:34 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]
Status: O


Locally (ie. National Distributors) I could not find 1Mx9-80ns SIMM's for
less than $130.  So I turned to the "Computer Shopper" and obtained
the following quotes:

   All 1Mx9, 3rd party SIMM board.
   Add state sales tax if in-state purchase


					80ns		70ns
					---------	--------
California Microchip, CA
Toshiba
1-800-776-2447				$99.00		?

Unitex, CA
Samsung
1-800-533-0055				$102.00		?

RMS International, FL, 1 yr guarentee
Samsung / Intel
1-800-869-1515				$89.00		$92.00

Microprocessors Unlimited, OK
Samsung / Intel
1-918-267-4961				$99.00		$110.00

Dram Specialist, CA
Samsung
1-818-718-7200				$95.00		?


Question George:  You mention that you were uncomfortable with Samsung
		  SIMMs'.  Would you feel more comfortable using 70ns
                  Samsung SIMM's ??

Anyone had any bad experiences with the above companies ??

regards,
johnc


From owner-pc532%daver@mips.com Fri Jan 19 11:58:38 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: george@wombat (George Scolaro)
Date: Fri, 19 Jan 90 08:48:02 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Subject: Re: SIMM report..
Status: O

[In the message entitled "SIMM report.." on Jan 18, 18:34, John L. Connin writes:]
> 
> Question George:  You mention that you were uncomfortable with Samsung
> 		  SIMMs'.  Would you feel more comfortable using 70ns
>                   Samsung SIMM's ??
> 
> Anyone had any bad experiences with the above companies ??
> 
> regards,
> johnc

Hi, it wasn't so much 'I' was uncomfortable, but more so one of my friends
who uses a lot of SIMMs. As I mentioned, I can't remember what he said was
wrong. Mind you, I'm also not responsible for the design of their boards,
either. It might just be the case that the board design was flakey, and the
Samsung parts showed up the poor design more readily than other
manufacturers. Also, not all DRAMs are created equal, 80ns devices from
different manufacturers WILL have different specs, not by much, but enough
to cause problems unless you have designed your board for the 'generic' 80ns
DRAM. I know that the specs for: Fujitsu, Hitachi, NEC and Toshiba dram
devices are fine. Mitsubishi has excessive timing specs for a bunch of
important parameters (even though it is an 80ns device). I haven't seen
SAMSUNG specs, so I can't comment.  BUT, Toshiba generally does have the
best design specs with NEC coming in second.

regards,


-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com Fri Jan 19 13:25:43 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
To: pc532@daver.uu.NET
Subject: re: dumb frame buffer, anyone?
Date: 19 Jan 90 18:34:45 MEZ (Fri)
From: jkh@meepmeep.pcs.com (Jordan K. Hubbard)
Status: O


Count me in for an "aye" vote. I think all this talk of i860 or TMS34020
(And I personally am quite fond of the 34020) based display boards is
all well-and-good, but I would welcome a more low cost and (more importantly)
IMMEDIATE approach to the problem. The idea of going back to a CRT
based development environment on *any* machine makes this boy want
to retch. I can certainly stand it on the 532 for a couple of months,
but I'm going to be staring wistfully at my workstation's bitmap the
whole time (that is if I don't end up running several RS232 lines
between the two and running tip under xterm, as I probably will) and
wondering what R4 performance could be like on such a wizzy machine.

A dumb frame buffer will be cheaper, easier to design and a lot faster
to port X to which brings it down out of the "pie-in-the-sky" range
to something we might actually see in the next year or so. I will also
willingly devote time to porting the R4 server and clients (Motif or
otherwise), given the hardware.

The fastest X server I have used to date has been Joel McCormack's
hand-optimized dumb-8-plane-frame-buffer R3 server for the PMAX. This
beat out the Ardent Titan server I had been working with by an impressive
margin, proving that even the spiffiest GP with so-so X support is
going to beat the pants off a DFB with really good X support (given, of
course, that the main CPU is worth its salt). Of course, one comparison
doth not for unassailable statistical proof make, but I think the PMAX's
performance speaks for itself. I'll take one on MY desk any day of the week.

Poking around in the PMAX also revealed something that looked very
much like a large fat SIMM containing the entire frame buffer. I watched
a friend convert a monochrome PMAX into an 8 plane colour one simply
by popping the sucker out and replacing it with a different one. Evidently
the video smarts knew how to deal with the change. Anyone with more
knowledge care to comment on (what I consider to be) this amazing
feat of ungradability? If we could pull something similar off for the
pc532, I would die happy (well, maybe not until MACH was ported at least..)

					Jordan

From owner-pc532%daver@mips.com Fri Jan 19 14:03:34 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
From: dlr@daver.UU.NET (Dave Rand)
Date: Fri, 19 Jan 90 10:48:02 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: jkh@meepmeep.pcs.com (Jordan K. Hubbard)
Subject: re: parts suppliers
Cc: pc532@daver.uu.net
Status: O

[In the message entitled "re: parts suppliers" on Jan 19, 17:59, Jordan K. Hubbard writes:]
> Does Arrow have a non-800 number too? We can't call 800 numbers from
> Germany.

Yes, I knew this, but they don't publish a non-800 number. I'm on the line
with them now... They do have a FAX number, at +1 516 585-0878... the
direct number is +1 516 467-1000.

Arrow carries a wide variety of parts, has a minimum parts order of $25.00,
accepts Visa, Mastercard, and hs various shipping options.



-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr%daver@uunet.uu.net

From owner-pc532%daver@mips.com Fri Jan 19 14:36:12 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Date: Fri, 19 Jan 90 11:21 PST
From: bpan@iscev1.chips.com (Benjamin Pan)
To: pc532%daver@chips
Subject: SIMM price
Status: O



I checked around for the price of 1Mx9-80ns SIMM's. The best quote so far
is $75 a piece. It uses Toshiba chips and is made by a local third party.
The dealer said that he also has SIMM's with Toshiba chips but made by
some third party in Japan. The price tags for those are ranging from $82-$85,
depend on which shipment.

Some backgrounds: this deal is a special favor because the dealer is the
brother-in-law of someone who works in same group here at C&T.
The dealer suggested to go with the $75 SIMM's because those are made
locally therefore carry an one-year warranty. (sales pitch?)
He also said the price of SIMM's fluctuates from shipment to shipment.
As Tuesday, he had a thousand of those $75 ones in stock, but they are
expected to be sold out soon. (high pressure sales technique?) 

Question: is this a good deal?  It seems like a real favor to me because
the dealer is not in the resale business. He usually deals only with
distributors. (I know because we tried to buy monitors for C&T from him before.
It didn't work out.  We were send to his distributor instead)

What do you think? 

Regards

Benjamin Pan (bpan)
PS: this is the first time I send mail to this group, check you mail header
for return path.


From owner-pc532%daver@mips.com Fri Jan 19 14:36:12 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Date: Fri, 19 Jan 90 11:21 PST
From: bpan@iscev1.chips.com (Benjamin Pan)
To: pc532%daver@chips
Subject: SIMM price
Status: O



I checked around for the price of 1Mx9-80ns SIMM's. The best quote so far
is $75 a piece. It uses Toshiba chips and is made by a local third party.
The dealer said that he also has SIMM's with Toshiba chips but made by
some third party in Japan. The price tags for those are ranging from $82-$85,
depend on which shipment.

Some backgrounds: this deal is a special favor because the dealer is the
brother-in-law of someone who works in same group here at C&T.
The dealer suggested to go with the $75 SIMM's because those are made
locally therefore carry an one-year warranty. (sales pitch?)
He also said the price of SIMM's fluctuates from shipment to shipment.
As Tuesday, he had a thousand of those $75 ones in stock, but they are
expected to be sold out soon. (high pressure sales technique?) 

Question: is this a good deal?  It seems like a real favor to me because
the dealer is not in the resale business. He usually deals only with
distributors. (I know because we tried to buy monitors for C&T from him before.
It didn't work out.  We were send to his distributor instead)

What do you think? 

Regards

Benjamin Pan (bpan)
PS: this is the first time I send mail to this group, check you mail header
for return path.


From owner-pc532%daver@mips.com Fri Jan 19 20:14:29 1990
Flags: 000000000011
Reply-To: pc532@daver.UU.NET
Subject: Circuit Cellar BBS, file list
To: pc532%tarpit@daver.uu.NET
Date: Fri, 19 Jan 90 17:29:50 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]
Status: O


The following is a (edited) list of files on the Circuit Cellar BBS
which may be of interest to the pc532 group.  NB: to save bandwidth
I have removed files which were far afield.

Feedback from anyone who has first hand knowledge of the stuff in the
"Electrical engineering programs & files" section which are applicable
to this group would be appreciated.

Best regards,
johnc

        -------------------------------------------------

The following is a list of all the files contained on the Circuit Cellar BBS
as of Friday, December 22, 1989.  The Circuit Cellar BBS may be reached at
(203) 871-1988.  Remember that the Circuit Cellar BBS isn't a file clearing-
house, but is a forum in which to exchange information through the message
base.  Every user is limited to downloading 250K in any 24-hour period.  There
are no exceptions to this limit.  If you want to download more, you must
spread it out over several days.

Finally, note that files in areas 1 and 2 may NOT be posted on other BBSs or
information services.

File area #  1 ... Circuit Cellar INK project files
File area #  2 ... Ciarcia's Circuit Cellar files (BYTE)
File area #  3 ... User-modified Circuit Cellar files
File area #  4 ... Microprocessor development tools
File area #  5 ... Electrical engineering programs & files
File area #  6 ... User-written ImageWise programs
File area #  7 ... User-uploaded ImageWise pictures
File area #  8 ... X-10 files
File area #  9 ... PC Pursuit files
File area # 10 ... CP/M files and programs
File area # 11 ... Utility programs for the IBM PC
File area # 12 ... Miscellaneous IBM PC files
File area # 13 ... Miscellaneous text files
File area # 14 ... Files that don't fit elsewhere

--------------------------------------------------------------------------

File area #  1 ... Circuit Cellar INK project files

This section contains files related to past Circuit Cellar INK
articles.

Files contained in this directory may not be reposted on other BBSs or
information services without express permission from Circuit Cellar Inc.


[stuff deleted]

 November/December 1988, Issue #6

DEBUG31.ARC    54182  DDT-51: 8031 debugger for IBM PC
KERNEL.ARC      8297  DDT-51: 8031 kernel for IBM PC
TEST31.ARC     42907  DDT-51: Test code for circuit debugging
DDT51UPD.TXT    5248  DDT-51 update information
DDT51NOT.TXT   11648  Some DDT-51 notes from Ed Nisley

[stuff deleted]

 September/October 1988, Issue #5

[stuff deleted]
DSCOPE.ARC     13771  Digital oscilloscope DSCOPE program
PLOT.ARC       19852  Digital oscilloscope PLOT program
SWIO.PDS        1702  Digital oscilloscope U7 PAL equations
20X.PDS         3229  Digital oscilloscope U8 PAL equations

[stuff deleted]

This code is posted as a convenience to Circuit Cellar INK
readers.  It is intended for noncommercial use only by micro
enthusiasts and experimenters who build Circuit Cellar INK
projects from scratch.

--------------------------------------------------------------------------

File area #  2 ... Ciarcia's Circuit Cellar files (BYTE)

This section contains files related to past Ciarcia's Circuit
Cellar articles which have appeared in BYTE magazine.

For each article, the first file in the list contains complete
descriptions of what files are available for that article.  Please
read that file before asking questions about what's available.

Files contained in this directory may not be reposted on other BBSs or
information services without express permission from Circuit Cellar Inc.

[stuff deleted]

 August, September 1988: DDT-51 8031/8051 Development System

AUG88.ART       1152  Text file describing what's available
DDT51UPD.TXT    5248  DDT-51 update information (9/6/88)
DDT51NOT.TXT   11648  Some notes from Ed Nisley (9/6/88)
DEBUG31.ARC    54182  8031 debugger for IBM PC (12/4/88)
KERNEL.ARC      8297  8031 kernel for IBM PC (12/12/88)
TEST31.ARC     42907  Test code for circuit debugging (12/12/8
BLINKY.ASM      2560  Sample program for target computer
BLINKY.HEX       128  8031 hex file to match BLINKY.ASM
PS51A14.ARC    82092  8051 cross-assembler for the IBM PC
COPYERRS.ARC    5120  User-written tool for 8051 assembler
PSKERNEL.ARC    8576  User-converted DDT-51 KERNEL for PS51A14

[stuff deleted]

 April, May 1988: SmartSpooler

APR88.ART       1024  Text file describing what's available
SPOOL11.HEX    25728  Version 1.1 of the SmartSpooler EPROM

 January-March 1988: BCC180 Computer/Controller

JAN88.ART       1280  Text file describing what's available
180MON10.HEX   19584  Version 1.0 of the BCC180 ROM Monitor

 November, December 1987: Circuit Cellar IC Tester

NOV87.ART       1024  Text file describing what's available
ICTROM12.HEX   74377  Version 1.2 of the IC Tester's EPROM

[stuff deleted]

 October 1986: Circuit Cellar Serial EPROM Programmer

OCT86.ART       1024  Text file describing what's available
SEPROM16.HEX   46208  Version 1.6 of the SEP EPROM
SEPMAN.TXT     46592  Text of SEP users manual
SEPPARTS.LST    6400  Complete parts list for SEP

[stuff deleted]

--------------------------------------------------------------------------

File area #  3 ... User-modified Circuit Cellar files

This directory contains files related to past Circuit Cellar articles in
both BYTE and Circuit Cellar INK.  The programs and files are either user
written or are derivatives of officially released programs with user
modifications.  They are *not* official Circuit Cellar releases.

Use these programs *at your own risk*.  Circuit Cellar will not be
responsible for the proper operation of any program here and will not fix
bugs.  Contact the person who made the modifications if you have any
problems.

DDT51MOD.ARC   65280  Modified DDT-51 files
DDT51-C.ARC    66115  C Version of DDT-51 programs
DDT51C.ARC     24576  A Different DDT-51 host program

[stuff deleted]

--------------------------------------------------------------------------

File area #  4 ... Microprocessor development tools

This area contains cross-development tools and sample code for several
different microprocessors and microcontrollers.

 Intel 80xx series

BAS051.ARC     40704  BASIC Compiler v1.2 for 8051 family
PS48A14.ARC    58368  PseudoSam 8048 Xassembler ver 1.4
PS51A14.ARC    62464  PseudoSam 8051 Xassembler ver 1.4
PS96A14.ARC    57344  PseudoSam 8096 Xassembler ver 1.4
COPYERRS.ARC    5120  Tool for PS51A14 cross-assembler
TASM27.ARC    128647  Assembler: 8048,8051,6502,6805,Z80,...
UASM.ARC      158720  Universal Assembler: 8051,Z8,6805
DIS8051.ARC    11648  Disassembles 8051 HEX files into .ASM
DIS_8048.ARC    8576  Diassembler for the 8048 family
DIS51.LBR      30336  8051/8031 disassembler for CP/M
SKEL8051.ARC    6528  Skeleton for 8051 program w/serial I/O

 Motorola 68xx and 68xxx series

ASREF.ARC      31104  Full docs for the Motorola AS series asm
AS0.EXE        18432  Cross-assembler for MC6800
AS9.EXE        21504  Cross-assembler for MC6809
AS11.EXE       19456  Cross-assembler for MC68HC11
ASEMBLER.ARC   51518  Source for Motorola AS assemblers
SMALLC11.ARC   62976  SmallC compiler for 68HC11
RTE11.ARC      78848  Real-time kernel for the 68HC11
HC11FP.DOC     17792  Docs for HC11FP.ASM
HC11FP.ASM     76032  Floating-point code for 68HC11
FP11.ASM       11904  Floating-point code for 68HC11
MATH11.ARC     69632  Improved FP library for 68HC11
MATH11A.ARC    71296  Improved FP library for 68HC11
MATH11B.ARC    71936  Improved FP library for 68HC11
MUL16C11.ASM    1792  16-bit multiply routine for 68HC11
X68000.ARC    102912  68000 cross-assembler; Modula-2 source
PD68KCC.ARC   119936  MS-DOS "C" input, output 680x0.Source
6870X.ARC      30080  C source for the 6870x assembler
TBI68K.ARC     47207  Tiny BASIC source code for 680x0

 8080, NSC800, Z80, and HD64180

PSZ80A14.ARC   65536  PseudoSam Z80 Xassembler ver 1.4
ZMAC.ARC       81408  Z80 macro cross-assembler. C source incl
VASM.ARC       52088  8080/8085 xassembler (macros & conds)

 Other processors or host computers

Z8CA.ARC       43904  Z8 cross-assem for Amiga with 'C' source
Z8_IBM.ARC     43008  Z8 xassembler converted for IBM PC

 Utility programs for the IBM PC

BINTEL10.ARC   33792  Binary-to-Intel Hex converter
HEXFILE.COM    18432  Intel Hex File Conversion Utility
BINHEX.ARC      5167  A much better bin-hex-bin converter
SPLIT.EXE       8960  16-bit to 8-bit file splitter
S-RECORD.ARC   23296  Motorola S-Record <--> Binary conversion
CONVERT.DOC     2048  Documentation for CONVERT.EXE
CONVERT.EXE    55296  Convert Motorola S19 files to binary
CONVERT.PAS     3072  Pascal source for CONVERT.EXE

--------------------------------------------------------------------------

File area #  5 ... Electrical engineering programs & files

 The following are programs related to Electrical Engineering.  It is *not*
 possible to download individual files from within an .ARC file.

EEPD1.ARC     133120  Assorted public domain EE software #1
EEPD2.ARC     196352  Assorted public domain EE software #2
EEPD3.ARC     134784  Assorted public domain EE software #3
EEPD4.ARC      58496  Assorted public domain EE software #4
SCHEM.ARC      23424  Schematic CAD
PCB1.ARC      172416  PC board layout (1 of 2)
PCB2.ARC      128640  PC board layout (2 of 2)
LOGSIM.ARC     51691  Logic simulator
ROOTLOC.ARC    85061  Graphics-oriented root locus
RTLOC.ARC      96121  Graphics-oriented root locus
POLYROOT.ARC   54786  Polynomial root finder
PRFEXP.ARC     61486  Partial fraction expansion
TRANS.ARC      39712  Transistor amplifier design
TRANAMP.ARC   167340  Transistor amplifier design
RFTOOL.ARC    168936  Teledyne's RF Toolbox
3DSURFAC.ARC   51584  3D surface plotting program
FLODRAW.ARC    74752  Flowchart/schematic editor
FILTER11.ARC   57216  Active filter design tool
EE-CALC.ARC     7168  Handy circuit formulas program in BASIC
QCKT87.ARC    129024  RF design program, need 80x87
MATHPAK.ARC    84864  Math package of usable formulas
MATHPKII.ARC   45952  Math package with more formulas
NETWORK.ARC    42240  RF design tool
LOCI11.ARC    168320  World's Best Root Locus design program
FFT26.ARC     102656  256-Filter FFT for CGA/EGA (src & bin)
FASTFFT.ARC    19456  Table creation FFT program
SMITTY.ARC     67328  Smith Chart calculator (Pascal)
EE4120.ARC    204800  Antenna design from Virginia Tech
FREQDOM.ARC    89088  Extensive frequency domain analysis--EE
CHEBY.ARC      62336  High-, low-, and bandpass filter design
PSDOCS.ARC     59701  Docs for Pspice v4.0
PSPICE1.ARC   154591  PSpice Classroom version (Part 1)
PSPICE2.ARC   226100  PSpice Classroom version (Part 2)
PSPICE3.ARC    89600  PSpice Classroom version (Part 3)
FREETK.ARC    185771  TK Solver equation processor demo
FERRITE.ARC    16599  Calc mH/1000 for powd. ferrite toroids
IRON.ARC       17408  Calc uH/100 for powdered iron torroids
ROUTE.ARC     130816  PCB autorouter in `C'
PMI.ARC       128000  Search for analog parts..u input req'mts
LATTICE.ARC   141618  Assorted GAL s/w from the Lattice BBS
TI_PLUG.ARC   141312  TI's Programmable Logic User's Guide
ELECTRON.ARC  209287  Programs for electronics
FIBER.ARC      80640  BASIC fiber-optic progs (tokenized)


[stuff deleted]

--------------------------------------------------------------------------

File area # 13 ... Miscellaneous text files

 The following are miscellaneous text files which deal with a whole range of
 topics.  Note that many of the files are in ARC format to take advantage
 of ARC's compression facility.

RS232EX.ARC    11264  A description of RS-232
EISA-ALL.ARC   12288  Text file describing EISA bus
CCSP8149.ARC   39936  Patches for CCSEP Serial EPROM Programme
8251A.ARC       4096  How to program the 8251A USART
PARALLEL.ARC    8192  IBM PC parallel port tutorial
LIM_SPEC.ARC   46336  Lotus/Intel/Microsoft extended mem doc
INTELHEX.ASC    3968  Example of how to make Intel Hex records
CTASK.ARC     131072  Multitasking example with "C" source
XMS.ARC       143360  Microsoft's ExTended Memory Spec. w/src
XEROXPCB.TXT   12288  Use a copier to make circuit boards
E_CAD.LST       3328  A list of ECAD prgms and who writes them

[stuff deleted]

--------------------------------------------------------------------------

File area # 14 ... Files that don't fit elsewhere

 The following files are here because they just don't fit in anywhere else
 on the system.

CENTRONX.ARC    9144  Centronics driver for 8255 on BCC52
XMODEM.C        6784  xmodem example source code in "C"
HAM.ARC         4096  Hamming neural network
XINU.ARC       74752  C source code for UNIX-like O/S
XINU-1.ARC     33792  Missing file, Z80 goodies, news
DAA.ARC        22912  DAA in Orcad and FX80 printer output
DAAOPT.ARC     12544  Optoisolated telephone interface
RCCL-1.ARC    181095  Purdue U  Robotics "C" Library disk 1/3
RCCL-2.ARC    158664  Purdue U  Robotics "C" Library disk 2/3
RCCL-3.ARC    142233  Purdue U  Robotics "C" Library disk 3/3
I3ECONV.EXE    33098  Converts IEEE754 <-> single-prec format

DIGSIM.SIT     33920  Digital Circuit Simulator for Macintosh

[stuff deleted]


From owner-pc532%daver@mips.com Tue Jan 23 20:25:09 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Tue, 23 Jan 90 17:10:02 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: gs@vw25.chips.com (George Scolaro)
To: pc532@daver
Subject: they're here
Status: O

Hi folks,
	well the PCB's turned up today. They look very nice, with a very
fancy soldermask. I'd even trust Dave Rand to solder one....  We are still
waiting for NS to come through with the 32532/32381 & 32202, and a couple of
the vendors to turn up with some connector bits and the 2692 duarts. I will
build one of the units up during the week, just to make sure all is well. I
will try the parity circuit out as well (if I can find some x9 drams), since
this is the only new (unknown) addition to the design.

I'll keep you all posted as news comes to hand.

-- 
George Scolaro
(try (pyramid|hoptoad|sun|vsi1)daver!vw25.chips.com!gs)

From owner-pc532%daver@mips.com Wed Jan 24 00:57:35 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Date: Tue, 23 Jan 90 11:01:04 pst
From: Bruce Culbertson <culberts%hplwbc@hplabs.hp.com>
To: pc532@daver.UU.NET
Subject: Re:  byte ordering
Status: O

> would some kind soul help me I am trying to hand craft a module table
> and exception table for a 32016 (ie non 532 with direct exceptions)
> The data sheets have lovely little digrams showing memory ascending from
> the left to right as a byte stream, but I believe that the displacements
> in  the opcode are bit reversed

I have used the 32016 a fair amount and can understand your frustration.
National decided not to take sides in the little vs. big endian
(byte ordering) crusades -- they made the 32000 both-endian.  I think
they generally are in the lsb-comes-first (LCF) camp.  However, they
were unwilling to give up several features which could not be
implemented with LCF, so some msb-comes-first (MCF) crept into the
architecture.

I have to admit that I am a LCF zealot, myself.  If your CPU's bus
is too small to transfer a whole address, then you want to transfer
the least significant bytes first.  That way, you can start an
address calculation (which may generate a carry) while you fetch
the most significant bytes.  This dictates LCF if you want to
fetch the instruction stream in simple ascending order.  This
actually was not an issue on the 32016, but was one of the original
reasons for the popularity of LCF.  Further, LCF considerably
simplifies the compiler.  If, for example, you decide to read
an integer as a byte (e.g. due to a C cast), the address does
not change if you are using LCF; it does change if you are using MCF.

The 32000 architecture includes displacements which may be 1, 2,
or 4 bytes long.  The length is encoded in the most significant
1 or 2 bits of the displacement.  You need to be able to get
the length from the first byte you fetch since the first byte
might be the only byte.  Hence, displacements are MCF.  As I
recall, all data and addresses in the instruction stream, whether
or not they are displacements, are MCF; everything else is LCF.
Can anyone think of an exception to this rule?  In particular,
the module and interrupt tables are not in the instruction stream
and are LCF.

Below is the code which builds the module and interrupt tables in
my version of Minix.

Bruce Culbertson
--------------------------------------------------------------------

struct mod_entry {			/* 32k module table entry */
  long sb;
  long link;
  long pc_base;
  long dummy;
};

/* Interrupt handlers
 */
int	isr_abt(), isr_ill(), isr_svc(), isr_dvz(), isr_flg(),
	isr_bpt(), isr_trc(), isr_slave(),
	isr_und(), isr_clk(), isr_scsi(), isr_fdc(), isr_tty1(), isr_tty2();

extern char btext, etext, bdata, edata, end;

struct int_vec {
	short	number;
	int	(*isr)();
} isrInitTab[] = {
	{VEC_ABT,	isr_abt},
	{VEC_SLAVE,	isr_slave},
	{VEC_ILL,	isr_ill},
	{VEC_SVC,	isr_svc},
	{VEC_DVZ,	isr_dvz},
	{VEC_FLG,	isr_flg},
	{VEC_UND,	isr_und},
	{VEC_CLK,	isr_clk},
	{VEC_SCSI,	isr_scsi},
	{VEC_FDC,	isr_fdc},
	{VEC_TTY2,	isr_tty2},
	{VEC_TTY1,	isr_tty1},
#ifndef DEBUG
	/* Normally, you want the OS to catch these and send a signal to
	 * the proc which executed them.  For debugging with the ROM
	 * debugger, we need these to get us back into the debugger.
	 */
	{VEC_BPT,	isr_bpt},
	{VEC_TRC,	isr_trc},
#endif
};
#define ISRTABSZ (sizeof (isrInitTab)/sizeof (struct int_vec))

/*===========================================================================*
 *				modtab_init
 *===========================================================================*/
/* Setup mod table.
 */
modtab_init()
{
  struct mod_entry *p;

  p = ((struct mod_entry *)MODTAB_ADR) + MODTAB_MINIX;
  p->sb = 0;
  p->pc_base = (long)(&btext);
}

/*===========================================================================*
 *				inttab_init
 *===========================================================================*/
/* Setup interrupt table.
 */
inttab_init()
{
  struct int_vec *p;
  long *q;

  q = (long *) INTTAB_ADR;
  for (p = isrInitTab; p < isrInitTab + ISRTABSZ; ++p)
    *(q + p->number) = 
	(unsigned)(((struct mod_entry *)MODTAB_ADR) + MODTAB_MINIX) |
	((long)(p->isr) - (long)(&btext)) << 16;
}

From owner-pc532%daver@mips.com Wed Jan 24 20:32:00 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Tue, 23 Jan 90 14:33:15 EST
From: Jerry Callen <jcallen@maxzilla.encore.com>
To: pc532@daver.uu.NET
Subject: SCSI floppy interface
Status: O

I want to know what features people would like in a floppy disk interface
for the pc532. No promises (I've never done anything this big before), but
here's the hardware I'm currently considering:

	DP8490		SCSI interface
	DP8473		floppy disk controller
	HD64180		CPU (includes 2 DMA channels)
	DRAM		256K x 8 
	EPROM		boot

All of these pieces should work together with a minimum of glue logic
(probably all discreet 74LSnnn, since I've never worked with PALs). The
HD64180 is a Z80 superset that can address up to 512K of memory, plus
a separate 64K I/O space. It includes onboard refresh circuitry, 2 DMA
channels (how convenient!) and other miscellaneous stuff that I probably
won't use. 

My main question is how smart to make the software. The easiest thing
to do is to make it really dumb, so that the pc532 just uses the SCSI 
channel to send commands to the floppy disk controller. That keeps the
software on the floppy board really simple (and therefor likely to get done!).

Another approach is to make it smart, so that the floppy board (the 
fl64180?) does caching. 

Finally, I could chose a middle ground, but extensible; implement
a dumb interface, but with the ability to download executable code
over the SCSI interface, so anyone who feels ambitious can make the
dumb interface smarter. I'm leaning towards this last option, so I
can get something working quickly but make it possible for
other non-hardware folks (no EPROM burner needed) to make it better.

BTW, this would give us a backup tape interface, too; there are
cartridge drives that attach to floppy controllers (weird...).

Don't hold your breath on this thing; this is far and away the
most complex thing I have ever tried to build.

-- Jerry Callen
   jcallen@encore.com 

From owner-pc532%daver@mips.com Wed Jan 24 20:53:01 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Wed, 24 Jan 90 17:26 PST
From: dlr@daver.uu.net (Dave Rand)
To: pc532@daver.uu.net
Subject: Bad News
Status: O

For those of you that have ordered kits - bad news. The CPU/FPU/ICU will
be delayed. I just got off the telephone with National (after trying
for several days to get through), and was told that the parts that
were allocated to our effort have been shipped "to a major customer".
The best guess at this point is that we will have the parts at the end
of next week - close to the end of the month.
Sorry about this folks - I didn't see it coming.

If you have more questions, email, or give me a call.

Dave Rand
+1 408 434-0600 X4555 work
+1 408 733-4125 home

From owner-pc532%daver@mips.com Wed Jan 24 20:59:04 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
From: dlr@daver.UU.NET (Dave Rand)
Date: Wed, 24 Jan 90 17:48:22 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Subject: Re: SCSI floppy interface
Status: O

[In the message entitled "SCSI floppy interface" on Jan 23, 14:33, Jerry Callen writes:]
> I want to know what features people would like in a floppy disk interface
> for the pc532. No promises (I've never done anything this big before), but
> here's the hardware I'm currently considering:
> 
> 	DP8490		SCSI interface
> 	DP8473		floppy disk controller
> 	HD64180		CPU (includes 2 DMA channels)
> 	DRAM		256K x 8 
> 	EPROM		boot

This sounds good. If you make the software downloadable, and keep only a
"bootstrap" loader in the ROM, it will make life very easy. George and I
have done this on almost all our designs - this makes fix.. I mean improving
the software very easy!

BTW - Benjamin Pan posted about a good deal on 80nsec DRAM simms ($75).
He is organizing a bulk purchase of them - George and I are going to get
some. If anyone else would like some, you can mail to Benjamin at:
bpan@chips.com (unlikly), or daver!chips!bpan (will probably work).
You can reach him at: +1 408 434-0600 X4296.


-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr%daver@uunet.uu.net

From owner-pc532%daver@mips.com Thu Jan 25 14:23:21 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: 	Thu, 25 Jan 90 13:35:14 EST
From: neil@skatter.USask.CA
Subject: Re:  SCSI floppy interface
To: pc532 <pc532@daver>
Cc: neil@SASK.USask.CA
Status: O

I have a few suggestions which may make the development of the board
easier.
Unless the 64180 has internal support for DRAM (not just refresh generation),
it will be easier to use static RAM. 32 K by 8 devices are available for under
$20. Floppy disks will mainly be used for backups and data/program exchange, so
a large amount of buffering is not necessary. There should be enough RAM to
buffer a cylinder so rotational latency will be minimized. A 360 K (PC)
floppy has 40 cylinder/ 80 tracks, so 9 K/cyl. 1.2 M floppies have
80 cylinders, or 15 K/cylinder. Therefore 32 K of RAM should be lots.

Also, debugging the SCSI driver and other software would be easier if a
serial port was available.

Good luck,
Neil

From owner-pc532%daver@mips.com Thu Jan 25 18:20:57 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Thu, 25 Jan 90 15:46:26 -0600
From: Anthony J Stieber <astieber@csd4.csd.uwm.edu>
To: pc532@daver.uu.NET
Status: O

>From uwm.edu!rutgers!cs.utexas.edu!uunet!hoptoad!well!rab Thu Jan 25 15:46:06 CST 1990
Article 64 of alt.hackers:
Path: uwm.edu!rutgers!cs.utexas.edu!uunet!hoptoad!well!rab
>From: rab@well.UUCP (Bob Bickford)
Newsgroups: alt.hackers
Subject: 34010, graphics, and whatnot
Message-ID: <15695@well.UUCP>
Date: 25 Jan 90 06:09:20 GMT
Lines: 75
Approved: me


In response to a previous article of mine in alt.hackers, a friend wrote:
> 
> I guess you are seeing why Real Companies don't use crud interfaces
> like the 34010.  Put as little stuff between the processor and its
> videoram as possible!  Host CPU's get fast, faster than graphics
> processors get fast.  Besides, host CPU's know how to multitask
> without kludgery.

   We originally chose the '010 (Way Back When) because it could handle
doing all of the control, timing, and refresh of the VRAMs and free us
to worry about what we're good at: dealing with any kind of video signal
and doing a good job of it.  Since that time, we've run into (and overcome)
numerous limits in the '010 design, such as:

    1) Apparently the engineers at TI never bothered to check with anybody
       who knew anything at all about how real video works out in the real
       world: it is impossible to program the '010 video timing registers
       to produce a correctly interlaced video signal.  No combination of
       register values will do it; the VSYNC signal will *always* be either
       one to one-and-a-half lines _late_ in one field, or it will be one
       line too _long_ in one field.  Also, half-line blanking does not
       work, as the '010 is too stupid to correctly pre-load the serial
       shift register(s) at the correct tap point (or to pre-shift out the
       unwanted pixels).

       Since we never had any intention of relying on the '010's timing,
       this was more of a problem in figuring out how to program it so as
       to behave properly with our own signal generation (done with a large
       programmable gate array that we change as needed from NV-RAM config-
       uration data to generate any video rate we like).

    2) The TI engineers also apparently believed that nobody could possibly
       want to have more than 2 Meg of memory in any one image --- while
       the total memory space is nice and large (2^32 bits), there is a
       register that effectively limits the displayable image size by only
       providing enough bits to deal with 2 Meg pixels.

       We hired an '010 expert who designed a way around that one; she's
       also gotten the software to run respectably even with all of the
       kludges we've had to hang off the thing.

    3) As mentioned in my previous article, the "host interface" is just
       plain ridiculous: there's a 32-bit address register, a 16-bit data
       register, and a 16-bit control register.  And that's *it*.  For
       crying out loud, they could have put a few more address bits on
       the bloody thing (and gone to the next size LCC socket) and let the
       host address a "page" at a time or something........

       Also, saving the exact state of the host interface can be very
       tricky because of the idiosyncracies of same; this makes it very
       difficult to interleave VRAM and program control accesses (as I
       described before).


  If I had it all to do over again, I'm *not* sure we wouldn't use the '010.
After all, it *does* blit those pixels around at a fairly respectable speed,
and we can download various code to it as we see fit.  But the host interface
is a nightmare, and we've ended up designing so many ECL PALs to get around
the damn thing's limits that the advantage of having a VRAM controller has
sort of faded into insignificance. 


  Hack story?  Hell, the above is an entire *odyssey*!!!

--
  Robert Bickford        {apple,pacbell,hplabs,ucbvax}!well!rab
  rab@well.sf.ca.us
                      "A Hacker is any person who derives joy from
                       discovering ways to circumvent limitations."
-- 
  Robert Bickford        {apple,pacbell,hplabs,ucbvax}!well!rab
  rab@well.sf.ca.us      /-------------------------------------\
                         | Don't Blame Me: I Voted Libertarian |
                         \-------------------------------------/



From owner-pc532%daver@mips.com Thu Jan 25 20:01:50 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Subject: Re: SCSI floppy interface
To: pc532%tarpit@daver.uu.NET
Date: Thu, 25 Jan 90 18:57:34 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]
Status: O


> I want to know what features people would like in a floppy disk interface
> for the pc532. No promises (I've never done anything this big before), but
> here's the hardware I'm currently considering:
>
>	DP8490		SCSI interface
>	DP8473		floppy disk controller
>	HD64180		CPU (includes 2 DMA channels)
>	DRAM		256K x 8 
>	EPROM		boot
>
> All of these pieces should work together with a minimum of glue logic
> (probably all discreet 74LSnnn, since I've never worked with PALs). The
> HD64180 is a Z80 superset that can address up to 512K of memory, plus
> a separate 64K I/O space. It includes onboard refresh circuitry, 2 DMA
> channels (how convenient!) and other miscellaneous stuff that I probably
>  won't use. 

Two hardware suggestions.  Consider using the Intel 80C186 inlieu of
the HD64180.  The 80C186 / 80C188 has all the features of the 64180 plus
has several programmable chip selects (both address range and number of
wait state).  Though probably more expensive (qty 1-10 about $24) all
the MsDos tools can be used to generate code (eg Turbo-C, MSC, etc) --
a big advantage in my mind.  I can provide the source code for a
program which can convert EXE image to romable code.

The second sugestion is to add a serial port which need not be populated.
With a ROM monitor this would provide a way to nose around and find
out whats happening without going through the SCSI interface.

Best regards,
johnc


From owner-pc532%daver@mips.com Thu Jan 25 20:04:44 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Thu, 25 Jan 90 16:20:20 EST
From: Jerry Callen <jcallen@maxzilla.encore.com>
To: pc532@daver.uu.NET
Subject: Floppy board
Status: O

>From: neil@skatter.USask.CA
>
>Unless the 64180 has internal support for DRAM (not just refresh generation),
>it will be easier to use static RAM.

I don't know what other support DRAMs need. Could you elaborate? The reason
I settled on the HD64180 is precisely because it is easy to interface to
DRAM (no external circuitry needed, at least for 256k DRAMs if I map the
RAM to the top 256K of the 512K address space). The only thing to watch is that
the on-chip DMA can interfere with refresh cycles; you have to alter the
refresh timer when DMA is in progress.

>32 K by 8 devices are available for under
>$20. Floppy disks will mainly be used for backups and data/program exchange, so
>a large amount of buffering is not necessary. There should be enough RAM to
>buffer a cylinder so rotational latency will be minimized. A 360 K (PC)
>floppy has 40 cylinder/ 80 tracks, so 9 K/cyl. 1.2 M floppies have
>80 cylinders, or 15 K/cylinder. Therefore 32 K of RAM should be lots.

I had the same thought at first, but something in me really hated the
notion of putting a measly 32K on the board when just a few more $$$ would
get me 256K. I was also thinking that it might be nice if the 532 could
have the controller suck in a bunch of data off the floppy in one gulp and
blow it back across the SCSI channel in one burst (using smarter software
in the controller). Finally, I hope to reuse the same 64180/8490/DRAM
core in other projects.

Maybe I'm missing something (I've never built anything with DRAMs; the
refresh crap has always scared me away), and if there are some horrible
problems using DRAM I'm willing to reconsider. (Hell, there ain't NOTHIN
nailed down yet!) But I think I want to bite the bullet and start using
DRAM. Any comments, George?

>Also, debugging the SCSI driver and other software would be easier if a
>serial port was available.

The HD64180 has 2 on-chip serial ports that can run at speeds from
150 to 38.4KB (maybe higher). I was planning to use at least one for
debugging and downloading. I would like the board at reset time to
watch the SCSI port and serial channel; if the serial channel talks
first, the board drops into debug mode. If the SCSI talks first, the
board loads off the SCSI. It remains to be seen whether or not I can
make this work.

The 64180 is a pretty neat chip; Steve Ciarcia has presented many projects
in Byte using this chip. I think it is the August/September '86 issues
that have a two-part article on a single-board system that is remarkably
similar to what I'm designing. (Gee, I wonder why? :-)

>Good luck,
>Neil

Thanks, I'll need it! 

-- Jerry Callen
   jcallen@encore.com
   (508) 460-0500

From owner-pc532%daver@mips.com Fri Jan 26 02:34:23 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: george@wombat (George Scolaro)
Date: Thu, 25 Jan 90 23:08:12 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Subject: Re: Floppy board
Status: O

[In the message entitled "Floppy board" on Jan 25, 16:20, Jerry Callen writes:]
> >From: neil@skatter.USask.CA
> >
> >Unless the 64180 has internal support for DRAM (not just refresh generation),
> >it will be easier to use static RAM.
> 
> I don't know what other support DRAMs need. Could you elaborate? The reason

DRAMs need a lot more than just refresh. Refresh on modern DRAMs is quite
easy, since they support cas before ras mode. i.e. all you do is assert cas
before you assert ras and the DRAM does all the address counting etc
internally. BUT, you have to take care of the ras, cas generation plus the
multiplexing of the row/column addresses for the actual accesses. I haven't
looked at the 64180, but I doubt it does any of the ras/cas work for you. If
it supports DRAMs in the same way the Z80 did, this only means that it
generates a signal to tell you that you can do a refresh (i.e. it counts 15
usec periods). You still have to do all the work on the outside.  With a
10Mhz part (or less in the case of the 64180?) DRAM timing is quite easy
since you have lots of them nasty little nanoseconds to play with.

The pros for DRAMs:

- higher capacity. 2 x 256Kx4 is 256k bytes.
- they are very cheap, 120ns 256kx4's are less than $10.
- they occupy little space (but you have to add the multiplexers).
- if you have never used them, it will be satisfying to do a design that
  works.

The cons for DRAMs:

- they are more complicated than srams. You will have to study the data
  book a learn about the different modes.
- keep the signals from the ras/cas/address multiplexers short going to the
  DRAM devices. With only 2 chips, 47ohm (rough) series resistors on the
  control signals & addresses will reduce undershoot (must be less than -1V).

> -- Jerry Callen
>    jcallen@encore.com
>    (508) 460-0500

Sounds like a fun project and one that is in the realm of wirewrapping.
Your ideas about scsi/serial scanning for debugging etc sounds good.
Regarding choice of CPU, pick the chip that you feel most comfortable with
and has good enough performance. The floppy is fairly slow, but with the
SCSI bus you really want to try and run it as fast as possible. It will do
around 4 megabytes/sec, the closer you can get to that the better the
utilization with multiple SCSI masters (of course this is in the extreme
case where you have lots of really wizzy fast boards all talking at the
same time.... not likely for some time yet!).

There are many Z80 PD tools out there (I even have a set hosted under UNIX)
so software development shouldn't be a problem. Also, many 'old timers'
should still remember Z80 code well, in fact when it comes to 80puke86 code I
am completely at a loss. But Z80 code, I can cope with, I even have an
NSC800 (Z80 CMOS semiclone) in my homebrew car computer.

best regards,

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com Fri Jan 26 11:30:18 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: george@wombat (George Scolaro)
Date: Fri, 26 Jan 90 08:20:41 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Subject: Re: et532
Status: O

[In the message entitled "Re: et532" on Jan 26, 15:52, Neil Murray writes:]
> In-Reply-To: <9001161533.9095@munnari.oz.au>; from "ian@sibyl.eleceng.ua.oz" at Jan 16, 90 11:42 pm
> 
> | is being sorted out, but I can use the et532 on my icm3216. (OK I know
> | it will be slow ...). Of course, I will eventually pension off the
> | icm3216 all together and put the et532 on that.
> 
> 	The same applies for me, if the et532 can be used as a Ether <-> SCSI
> setup on standard SCSI cable it would be very useful beyond just my ICM3216.

Hi folks,

In case I haven't been clear, the et532 can be used as a normal scsi device.
In addition to the XT/SCSI edge connector for use in the pc532, the et532
also has a 50 pin (25x2) header which is scsi pin compatible. It also has a
4 pin connector (floppy/hard disk style) for applying external +5/+12/GND.
In fact, when I first did the design, Dave & I thought about using it on our
aging ICM's to get us a) ethernet and b) more serial ports, so I made it
possible to be used externally. I also felt that some people might want a
really high performance ethernet connection with lots of on-board smarts
(hence the 32gx32) for use with machines other than the pc532. Dave did
manage to get the actual ICM ethernet board, but due to lack of time &
software info (he bought it surplus), we never have tried to actually use
it. Of course the et532 is probably an overkill in many respects but the
whole idea of the pc532/et532 etc was to get as much performance as possible
with the least amount of obtainable silicon.

regards,

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com Fri Jan 26 12:34:46 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Date: Fri, 26 Jan 90 11:09:45 EST
From: Jerry Callen <jcallen@maxzilla.encore.com>
To: pc532@daver.uu.NET
Subject: Parts buy
Status: O

I missed out on John's 8490 buy; anyone still interested? I contacted
my local Pioneer, and here are some prices on the parts I need:

	DP8490N (SCSI controller, 40 pin DIP)		$8.95
	DP8473N (floppy controller, 48 pin DIP)		$13.40

The problem is that they have a $60 minimum per line item; this means I
have to order at least 7 8490s and 5 8473s. I personally want
3 8490s and 2 8473s; any takers on the rest?

There is a 2-3 week lead time on the order. I could front the money, but I
would like commitments before I order. I'll just get the parts and ship them
myself to the interested parties.

I'm also shopping around for HD64180s. Any interest? Anyone have a good source?

-- Jerry Callen
   jcallen@encore.com
   (508) 460-0500

From owner-pc532%daver@mips.com Fri Jan 26 12:37:23 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Fri, 26 Jan 90 10:55:07 EST
From: Jerry Callen <jcallen@maxzilla.encore.com>
To: pc532@daver.uu.NET
Subject: Floppy board
Status: O

George writes:

>DRAMs need a lot more than just refresh. Refresh on modern DRAMs is quite
>easy, since they support cas before ras mode. i.e. all you do is assert cas
>before you assert ras and the DRAM does all the address counting etc
>internally. BUT, you have to take care of the ras, cas generation plus the
>multiplexing of the row/column addresses for the actual accesses. I haven't
>looked at the 64180, but I doubt it does any of the ras/cas work for you.
>If it supports DRAMs in the same way the Z80 did, this only means that it
>generates a signal to tell you that you can do a refresh (i.e. it counts 15
>usec periods). You still have to do all the work on the outside.

"The President misspoke."

I was, of course, totally wrong in my assertion that no external logic
was required. However, the external logic is EASY, since the 64180 provides
a signal ("E") which can be used to handle the ras/cas generation with a
few selectors and a flip-flop. Again, I can snarf Ciarcia's design for the
SB180/BCC180. I spent a lot of time looking at those designs last night
and I think I almost understand them. :-)  It looks like a total of about
6 chips, and some of the gates are needed for other functions anyway. BTW,
Ciarcia uses ras-only refresh; the 64180 supplies the address. Not as wizzy
as cas before ras, but it's already designed.

>With a 10Mhz part (or less in the case of the 64180?) DRAM timing is quite
>easy since you have lots of them nasty little nanoseconds to play with.

I would be clocking the 64180 at 9.216 Mhz (18.432 crystal). This somewhat
odd speed makes the on chip baud rate generator happy. Ciarcia uses that
speed, so the crystal must be available.

>The pros for DRAMs:
>
>- higher capacity. 2 x 256Kx4 is 256k bytes.
>- they are very cheap, 120ns 256kx4's are less than $10.

I was going to use 256x1 chips. I have no information on 256x4 chips (but
they sound like a great idea!). How different is the timing? (Guess I need
to order data sheets. Nuts. I already have data on the 256x1 chips.)

>- they occupy little space (but you have to add the multiplexers).
>- if you have never used them, it will be satisfying to do a design that
>  works.

Frankly, this last reason is a major motivator. I WANT to use DRAMs!

>The cons for DRAMs:
>
>- they are more complicated than srams. You will have to study the data
>  book a learn about the different modes.
>- keep the signals from the ras/cas/address multiplexers short going to the
>  DRAM devices. With only 2 chips, 47ohm (rough) series resistors on the
>  control signals & addresses will reduce undershoot (must be less than -1V).

>Sounds like a fun project and one that is in the realm of wirewrapping.
>Your ideas about scsi/serial scanning for debugging etc sounds good.

Thanks. They aren't original, of course.

>Regarding choice of CPU, pick the chip that you feel most comfortable with
>and has good enough performance. The floppy is fairly slow, but with the
>SCSI bus you really want to try and run it as fast as possible. It will do
>around 4 megabytes/sec, the closer you can get to that the better the
>utilization with multiple SCSI masters (of course this is in the extreme
>case where you have lots of really wizzy fast boards all talking at the
>same time.... not likely for some time yet!).

Well, if I have things figured right, the best I can hope for on this board
is a bit over 1 megabyte/second to the SCSI interface. That's actually one
argument for SRAM. Sorry, but I want to start with a relatively slow clock
for my first big project.

>There are many Z80 PD tools out there (I even have a set hosted under UNIX)
>so software development shouldn't be a problem.

Great! I'll want to snarf 'em, if at all possible.

>Also, many 'old timers'
>should still remember Z80 code well, in fact when it comes to 80puke86 code I
>am completely at a loss.

Me too. I don't want to start a flame war, but Intel CPUs make me ill. If
anyone wants one on the floppy controller, they can do their own design. I
don't own a PC (I do have a Mac, though), so the "do the work under Mess-DOS"
argument falls on deaf ears...

>best regards,
>George Scolaro

Thanks for the comments. 

There is one ugly problem with the 64180: it doesn't use .1" pin spacing.
How do I prototype? I have a friend who can do simple (1 layer) PC boards
at home; I figured I would design a small board with the CPU, clock circuitry
and some buffers on it and connect it to my prototyping board with a ribbon
cable. It can't be hard to get THAT much right on the first try, eh?

-- Jerry Callen
   jcallen@encore.com
   (508) 460-0500

From owner-pc532%daver@mips.com Fri Jan 26 13:44:41 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Fri, 26 Jan 90 17:06:22 GMT
From: petri@digiw.fi (Petri Alhola)
To: pc532@daver
Subject: Re: SCSI floppy interface
Newsgroups: santra.pc32532
Organization: Digiware , Helsinki Finland
Bad-Cc: 
Status: O

In article <m0gqyb1-0000DrC@daver.uu.net> you write:
>[In the message entitled "SCSI floppy interface" on Jan 23, 14:33, Jerry Callen writes:]
>> I want to know what features people would like in a floppy disk interface
>> for the pc532. No promises (I've never done anything this big before), but
>> here's the hardware I'm currently considering:
>> 
>> 	DP8490		SCSI interface
>> 	DP8473		floppy disk controller
>> 	HD64180		CPU (includes 2 DMA channels)
>> 	DRAM		256K x 8 
>> 	EPROM		boot
>
There is also nice SCSI controlelr from Motorola called 68hc99 ...
I have seen datasheet about it about two years ago ...
It is 68hc11 CPU core, SCSI interface and Hard disk controller +
some amount buffer memory .... I have not looked any bit more it
but it may be simple and low cost solution for floppy interface
becouse it is nearly single chip solution. Becouse we can not order 
mask version it will need external EPROM . I does not know is it possible
to use hard disc controller to controll floppy, but there is 
Western Digital WD37C65 that is complete AT floppy controller on single
chip. It contains also data separator and line drivers.

 Petri Alhola
 petri@digiw.fi

	


From owner-pc532%daver@mips.com Fri Jan 26 16:05:53 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Fri, 26 Jan 90 11:24:32 PST
From: des@dtg.nsc.com (Desmond Young)
To: pc532@daver.UU.NET
Subject: Re: SCSI floppy interface
Status: O

Concerning the Mot 68hc99....
It was a very big die, therefore a relatively expensive chip.
Certainly not at all competitive in that market place. I doubt
it would do as a cheap solution for us.

  The DP8473 floppy controller basically implements a PC floppy
controller on a chip. It does any density. It has an on-board
ANALOGUE data separator (much better recovery than digital).
The outputs are also capable of driving the floppy direct.
The chip includes the motor select register and data rate select
register from the IBM-PC card.

  National has just announced, in association with ACER, a 
Super-I/O chip. It has two UARTS, DP8473 floppy controller,
game port, connor hard disk interface, parallel port; all
on one chip.

Hope this helps.
Des.

From owner-pc532%daver@mips.com Fri Jan 26 16:13:59 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Subject: Parallel Port?
To: pc532@daver.UU.NET
Date: Fri, 26 Jan 90 12:57:39 PST
X-Mailer: ELM [version 2.2t PL7]
From: ditka!kls (Karl Swartz)
Status: O

Desmond Young writes ...
>   National has just announced, in association with ACER, a 
> Super-I/O chip. It has two UARTS, DP8473 floppy controller,
> game port, connor hard disk interface, parallel port; all
> on one chip.

Which reminds me ... I haven't seen any mention of a parallel
printer port on any of the pc532 pieces.  Did I miss something
(not altogether surprising) or must pc532 printers be serial
devices at present?  (Ok, one could use a serial-to-parallel
converter.)

If there is indeed no parallel port perhaps one could be added
to the floppy interface board -- that and the extra serial port
could be used for printers.  With 256KB of memory it seems a
shame to have the board *just* doing occasional floppy access;
using some of the extra smarts for printer buffering and low-
level management might be a nice fit.

--
Karl Swartz			 |UUCP	uunet!apple!zygot!ditka!kls
1-408/223-1308			 |INet	zygot!ditka!kls@apple.com
"I never let my schooling get in |BIX	kswartz
the way of my education."(Twain) |Snail	1738 Deer Creek Ct., San Jose CA 95148

From owner-pc532%daver@mips.com Fri Jan 26 17:46:50 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Fri, 26 Jan 90 13:38:47 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: gs@vw25.chips.com (George Scolaro)
To: pc532@daver.UU.NET
Subject: Re: Parallel Port?
Status: O

[In the message entitled "Parallel Port?" on Jan 26, 12:57, Karl Swartz writes:]
> 
> Which reminds me ... I haven't seen any mention of a parallel
> printer port on any of the pc532 pieces.  Did I miss something
> (not altogether surprising) or must pc532 printers be serial
> devices at present?  (Ok, one could use a serial-to-parallel
> converter.)

Nope, you didn't miss anything. There is no parallel port on the pc532.  To
tell you the truth, even the et532 (though it could have) doesn't have one
either. I built a printer buffer at home that takes 2 serials + 1 ethernet
+512k of dram and outputs the data (software auto-switching c/o dave) to a
parallel output port which goes to a HP LJII. So, for my use I didn't need
or want a parallel port. Sorry if that sounds a bit self-centered, but the
pc532/et532 did start out as purely homebrew replacements for our icm3216s.
The et532 is done, but the rs232 buffer piggyback board isn't and as I
mentioned enough signals are available to have a centronics port up there.
I have a nice design that does self timed acks etc etc already, so I could
add that. Of course if you don't want the et532 and want the pc532 to handle
centronics there is a local company (in Sunnyvale) called IMC that does two
neat little units (couple inches on a side) that take serial-parallel or
parallel-serial at rates from 19k to 115k. The uarts on the pc532 will run
to 76k baud (internal timer option), giving you an effective 7.6kbytes/second
on the centronics.  The units sell for around the $30 mark (roughly) and work
quite well (we have some), they are called PINs and SINs (parallel->serial &
vv).

best regards,

-- 
George Scolaro
(try (pyramid|hoptoad|sun|vsi1)daver!vw25.chips.com!gs)

From owner-pc532%daver@mips.com Fri Jan 26 23:08:36 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Date: Fri, 26 Jan 90 19:39 PST
From: bpan@iscev1.chips.com ()
To: pc532@daver.uu.net
Subject: SIMM purchase
Status: O


Many of you expressed interest in the RAM purchase and want to get more
information. I joint the pc532 group a bit late so I don't know how you
organized your group purchases in the past. The RAM deal is a special
favor from a friend who can give us the wholesale price. Since he
is local, we (and you too) have to pay the 7% California sales tax.
As for the delivery, I need to talk to Dave and George see if I can
include those SIMMs in whatever they need to send to you. This will
save you $$ as well as my headaches. For those who do not expect to
receive anything from them, I am thinking of just using regular post
office. Any suggestion for packaging?  A person recommanded to use
large box with at least 5 to 6 inches on each side filled with padding
material so that it is punch-save. Is this necessary?


PS: Since I missed the chance of getting the pc532 kit, does anyone have
a good source for the CPU/ICU/FPU? how about SIMM sockets? those sockets
are expensive. The only local store where they have them in stock is
Fry's Electronics and there they are $3.60 each. Among those of you like
to participate the RAM purchases, how many are interested in getting
sockets at the same time? I will use the $3.60 as the reference price.


The following is a worksheet for the purchase:
------------------------------------------------------------------------

SIMM type:        1M x 9
Chip manufacture: Toshiba
Speed:            80ns
SIMM maker:       Century (?) of Japan
Price:            $75/each
Additional cost:  7% California sales tax + shipping


a) How many SIMMs do you need:  __ x $75 + 7% = _____

b) Optional SIMM sockets:        8 x $3.60 + 7% = $30.82

c) Do you expect to receive any thing from Dave soon?  _ Yes  _ No

d) If not, how do you want me to send them to you?

      _ pick up in person
      _ through post office,
        estimated postage ___ + $3 packaging
        Address:



      _ through other means,
        please specify:
        estimated cost ___ + $3 packaging
        Address:




e) Total = _____


   Send check or money order to

        Benjamin Pan
        1025 Olmo Ct.
        San Jose, CA 95129

        408/434-0600 X4296
        408/996-1105 home
------------------------------------------------------------------------



From owner-pc532%daver@mips.com Fri Jan 26 23:23:28 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: 	Fri, 26 Jan 90 22:38:08 EST
From: neil@skatter.USask.CA
Subject: Re:  Floppy board
To: pc532 <pc532@daver>
Cc: neil@SASK.USask.CA
Status: O


>From: neil@skatter.USask.CA
>
>Unless the 64180 has internal support for DRAM (not just refresh generation),
>it will be easier to use static RAM.

>>From: Jerry Callen <jcallen@maxzilla.encore.com>
>>I don't know what other support DRAMs need. Could you elaborate?
I was referring to the address multiplexing circuitry. Since most DRAMs
need half the address bits strobed in with the -RAS signal and the other
half strobed in with -CAS, an extra 5 chips or so are required. You
have Ciarcia's design as a working example so this may not be as much of
a problem.

>32 K by 8 devices are available for under $20.

>>I had the same thought at first, but something in me really hated the
>>notion of putting a measly 32K on the board when just a few more $$$ would
>>get me 256K. I was also thinking that it might be nice if the 532 could
>>have the controller suck in a bunch of data off the floppy in one gulp and
>>blow it back across the SCSI channel in one burst (using smarter software
>>in the controller). Finally, I hope to reuse the same 64180/8490/DRAM
>>core in other projects.
For reads the extra RAM will not make much difference. The floppy is so much
slower than the rest of the system that entire cylinders can be transfered to
the host during the track to track time of the floppy (~3-6 milliseconds -
ignoring any rotational latency, and 5 1/4 inch floppy drives run at 5 or 6
revolutions/sec). For write operations the entire transfer must fit in RAM
to make a _big_ difference. Even then, if more than one floppy is required the
user would have to wait for the controller to write all the buffered data to
disk, so the performance improvement would be negligible.

As far as other projects - more RAM is always nice. I was only pointing
out that static RAM is simpler if it will meet the design requirements.

Regards, and keep us posted,

Neil


From owner-pc532%daver@mips.com Sat Jan 27 12:49:40 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
To: pc532@daver.UU.NET
Subject: Re: SCSI floppy interface 
Date: Sat, 27 Jan 90 11:53:37 EST
From: Bdale Garbee <bdale@col.hp.com>
Status: O

> Two hardware suggestions.  Consider using the Intel 80C186 inlieu of
> the HD64180.

I always thought the 64180 was a little weird, too.  But, if you're going to
go with anything in the "PC processor" world, use an NEC V40.  They are much
nicer to work with than the Intel chips, and are compatible with PC compilers,
and are cheap, and use an 8bit bus, and...

Personally, it'd be a toss between a Z80/64k RAM with 2x32kx8 static, or a 
V40 with 256k as 2x256kx4 DRAM.  I personally believe a Z80 is more than
enough horsepower for this task, and it's super cheap.  A V40 core would live
longer as the basis of other projects, though.

Bdale

From owner-pc532%daver@mips.com Sat Jan 27 17:57:11 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: george@wombat (George Scolaro)
Date: Sat, 27 Jan 90 14:35:59 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver
Subject: life...
Status: O

Hi Folks,
	well I finally got around to putting the last couple of chips on one
of the new pc532 motherboards (had to rip them off the old board) and powering
it up. The good news is that it came straight up, no debugging necessary (I
did stick an extra 74als6311 into a pal socket which meant that it was dead
to start with - very depressing!! but of course once I swapped out the chip
for the correct pal all was well). At this stage interrupts, dram and at
least 2 of the serial ports work fine. We will test the rest of the serial
ports out, check the dp8490 (the other scsi is ok since the leds run). I
haven't checked the parity yet, thats the next step.... I do have 1mx9 simms.

keep you posted,

p.s. there is no bad news yet!

-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com Sun Jan 28 02:19:57 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Sat, 27 Jan 90 23:15 PST
From: dlr@daver.uu.net (Dave Rand)
To: pc532@daver.uu.net
Subject: scsi to floppy controller
Status: O

We were in one of the local stores today purchasing a few parts, and noticed
that for $9.50 you can have a sasi to floppy board. We didn't buy one (a
little rich for us :-), but for those of you that just can't wait to get
a floppy drive on your system, this may be an alternative. I'm sure that
you will have to hack the board a bit, but it just has a z80 on it, so
no major problem. Looked like they have about 10 of them. The store was
Halted Specialties, for the locals.

I'm waiting for Jerry's board!

Dave Rand

From owner-pc532%daver@mips.com Sun Jan 28 13:07:34 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: george@wombat (George Scolaro)
Date: Sun, 28 Jan 90 09:53:34 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Subject: Re: Parallel Port?
Status: O

[In the message entitled "Re: Parallel Port?" on Jan 28,  2:45, Bdale Garbee writes:]
> > I built a printer buffer at home that takes 2 serials + 1 ethernet
> > +512k of dram and outputs the data (software auto-switching c/o dave) to a
> > parallel output port which goes to a HP LJII.
> 
> !!!  Did you do a PCB, or is this a wirewrap?  No matter, I want one.  Any
> chance I can have one?  :-)
> 
> Bdale, tired of manually sharing my LJ2 with my wife's AT clone...
> 

No PCB for this one. In fact its a real kludge, it uses one of NSC's XT
ethernet evaluation boards (with the pal changed to make it non-xt), plugged
into a right angle IBM 62 pin connector that is wirewrapped to a 32cg16
board. The 32cg16 board is all wirewrapped and has 1 centronics (out) + 2
serials (in/out) + dp8421 dram controller. The whole thing is actually in a
metal box with some flashing LEDs (software people demand flashing lights!).

So, you can see that it is a real homebrew project. I don't ever intend to
do a PCB, but there is a real company that is going to come out with a very
similar product.... (real soon now)

regards,


-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com Mon Jan 29 14:26:32 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Mon, 29 Jan 90 09:20:33 EST
From: Jerry Callen <jcallen@maxzilla.encore.com>
To: pc532@daver.uu.NET
Subject: Who are we?
Status: O

Dear PC532ers,

I got several calls at work this weekend (where I wasn't, luckily :-) from
folks on the pc532 mailing list; the easiest way to respond (given the
realities of telephone tag) is via email. Unfortunately, niether caller
left an email address!

Does anyone object to having Dave post the mailing list, so we can all know 
who we are? This would facilitate direct communication in cases where the
entire list need not be involved. Dave, assuming no one else minds, do you
have any objection to posting the list?

(I also have to confess to a burning curiousity as to the number of folks
on the list and where they are...)

-- Jerry Callen
   jcallen@encore.com
   (508) 460-0500 (work)
   (617) 876-5330 (home)

P.S. To the folks who called: try me today at work, or use email, or call
     me at home (but not after 10PM EST, please!).

From owner-pc532%daver@mips.com Mon Jan 29 22:40:21 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Subject: Re: SCSI floppy interface
To: pc532%tarpit@daver.uu.NET
Date: Mon, 29 Jan 90 10:31:02 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]
Status: O


>> From:     Bdale Garbee <attctc!daver!uunet!col.hp.com!bdale>
>> 
>> Personally, it'd be a toss between a Z80/64k RAM with 2x32kx8 static, or a 
>> V40 with 256k as 2x256kx4 DRAM.  I personally believe a Z80 is more than
>> enough horsepower for this task, and it's super cheap.  A V40 core would live
>> longer as the basis of other projects, though.

[ Jon Loelinger write ... ]

> Although I am a Z80 fan, I think that the days of 64K have come and
> a long gone.  I think to make an upscale or even homebrew decision around
> a 64K address space is very limiting and a mistake.  True, the Z80 is
> cheap and probably enough horsepower, but I think a larger address space
> is a necessity.

The 64180 has a builtin Memory Management Unit with 1M or 512K bytes
memory physical address space.  I am not sure this is entirely accurate,
but the 64180 appears to use a paging (bank switch) similar to that 
used in CPM80 Plus systems.

[  stuff deleted ]

I am being to think that perhaps the best way for me to go is to 
utilize a spare computer for floppy, parallel, etc services.
That is wire-wrap a simple SCSI interface card for the spare
computer and connect it to the pc532.  Of course once physically
connected there still is a need for some sort of software to
handle the SCSI IO requests.

Best regards,
johnc

---
John Connin: manatee Orlando, Florida
         UUCP: {peora,uunet,ucf-cs}!tarpit!manatee!johnc



From owner-pc532%daver@mips.com Tue Jan 30 02:59:20 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: george@wombat (George Scolaro)
Date: Mon, 29 Jan 90 23:00:15 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver
Subject: more life...
Status: O

Hi folks,
	well, we just got the parity working. The hardware was easy, it just
worked (after a minor pal fix), but getting the software to come up was
another story, whew!! Anyhow, we now have a solid mechanism to come up from
a cold reset and properly enable and handle parity errors. We certainly know
that we can get them, especially if you forget to initialise all the memory.
Of course, in the process we discovered wonderful bugs in totally unrelated
areas, but it all now works fine. Of course, the most frustrating thing
was getting the system to boot and handle the initial parity errors (even
though the DRAM was perfect) due to uninitialised DRAM. Lots of good stories
to tell about write/reads with burst and data caches....

keep you all posted, regards,


-- 
George Scolaro
george@wombat
(try {pyramid|sun|vsi1|killer} !daver!wombat!george) [37 20 51 N / 122 03 07 W]

From owner-pc532%daver@mips.com Tue Jan 30 13:33:00 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
To: pc532@daver.UU.NET
Subject: Re: SCSI floppy interface 
Date: Tue, 30 Jan 90 07:09:48 MST
From: Bdale Garbee <bdale@col.hp.com>
Status: O

> The 64180 has a builtin Memory Management Unit with 1M or 512K bytes
> memory physical address space.  I am not sure this is entirely accurate,
> but the 64180 appears to use a paging (bank switch) similar to that 
> used in CPM80 Plus systems.

This is precisely why I'm not a big fan of the 64180.  It is, to me, worse than
dealing with Intel's segment registers... I thought bank switching was neat
when I first heard about it for S-100 systems, then I had to write software
for it, and... well... I'd rather not.  Hard to build a good C compiler
runtime library that likes bank switching.

Are there good tools for the 64180 specifically?  Z80 tools aren't good enough
to write code that blindly takes advantage of the extra memory space.  If thereis a good C compiler, etc., I'll shut up and ignore the hardware on this one.

> I am being to think that perhaps the best way for me to go is to 
> utilize a spare computer for floppy, parallel, etc services.

Why?  I surely hope our discussion of processors hasn't scared you off from 
doing a 64180-based board.  It doesn't have to be *perfect*, it just has to
work and make you feel good about having accomplished something!  It *will*
get used, even if it isn't what some of us would have designed ourselves...

Bdale

From owner-pc532%daver@mips.com Tue Jan 30 14:53:56 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Date: Tue, 30 Jan 90 11:36:27 PST
X-Mailer: Mail User's Shell (6.5 4/17/89)
From: gs@vw25.chips.com (George Scolaro)
To: pc532@daver
Subject: esoteric parts
Status: O

[In the message entitled "pc532 part type questions" on Jan 30, 12:11, Jukka Virtanen writes:]
> 	Could you please specify the exact part numbers/types
> 	for the following parts (we are going to make a group
> 	order from the local Arrow distributor, or some such):
> 		- no slot clock

Dave & I just went down to a local computer/electronics place and bought one
for the IBM XT. All we can say is that it is a 28 pin device that sits under
a standard 27256 EPROM. Dallas Semiconductor manufactures the actual device
and it is then sold by other companies. JDR (advertise in BYTE) sells this
one.

> 		- XTALM 50 mhz crystal osc

This is a 14 pin 0.3 inch wide DIP crystal oscillator module with TTL
compatible output. It has 4 pins, pin 1 is no connect, pin 7 is ground, pin
8 is the output and pin 14 is +5V. Digikey sells this one.

> 		- 20 Mhz crystal osc

This is the same as for the 50mhz oscillator. The ARROW part number for this
one is MX055GA-2C-20.0MHz (stock number 9812TQ8). Digikey also sells this
one.

> 	Could you please check also other possible non-accurate
> 	specs. Maybe it would be wise to send the response to
> 	the list. (e.g. I could not figure out where you use the
> 	2*40 header pins :-)
	????

The headers are 2 x 25 pins (for the SCSI, i.e. 2 rows x 25 pins on 0.1 inch
centers). The 2 x 5 pin ones (for the serial) are 2 rows x 5 pins on 0.1 inch
centers etc etc... These headers are for putting ribbon cables on, i.e.
transition connectors. There is also a 2 x 4 header for optional external
LEDs. I normally buy 2 x 25 or larger and then snap off the required lengths
to suit.

regards,


-- 
George Scolaro
(try (pyramid|hoptoad|sun|vsi1)daver!vw25.chips.com!gs)

From owner-pc532%daver@mips.com Tue Jan 30 15:52:18 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Tue, 30 Jan 90 15:31:54 EST
From: Jerry Callen <jcallen@maxzilla.encore.com>
To: pc532@daver.uu.NET
Subject: HD64180 for floppy
Status: O

>From: Bdale Garbee <bdale@col.hp.com>
>
>> The 64180 has a builtin Memory Management Unit with 1M or 512K bytes
>> memory physical address space.  I am not sure this is entirely accurate,
>> but the 64180 appears to use a paging (bank switch) similar to that 
>> used in CPM80 Plus systems.
>
>This is precisely why I'm not a big fan of the 64180.  It is, to me, worse than
>dealing with Intel's segment registers... I thought bank switching was neat
>when I first heard about it for S-100 systems, then I had to write software
>for it, and... well... I'd rather not.  Hard to build a good C compiler
>runtime library that likes bank switching.

This was my first reaction to the 64180, too. But consider our application.
We are using the DRAM primarily as a buffer; I expect the code to be pretty
small. The on-chip DMA can address the ENTIRE address space transparently.
So we program the DMA to get the data off the floppy, then program the
other DMA to send it out on the SCSI bus. We NEVER LOOK AT THE DATA. So
who cares if it's difficult to address? Also, the 64180 makes the "bank
switching" pretty easy. But it really is an MMU; crude, but functional.

Of course, if we want to use this for print buffering (I do plan to put a
parallel port on the board; probably an 8255, since they are cheap and I 
understand them), we will need to look at the data. BUT - not very much.

>Are there good tools for the 64180 specifically?  Z80 tools aren't good enough
>to write code that blindly takes advantage of the extra memory space.  If thereis a good C compiler, etc., I'll shut up and ignore the hardware on this one.

Well, no, not that I know of. Actually, there may be a decent, er, compiled
Basic for it (thanks to Ciarcia). Before you blow your cookies all over the
keyboard, let me add that I DON'T plan to code in Basic!

I realize I'm a bit of a dinosaur, but I was planning to do all the code
in assembler. George pointed me to a public domain assembler that I pulled
off the net, and it seems to work quite nicely. A major goal of this board for
ME is to have fun doing it, and I like assembly coding. (Perverted, I guess...)

>> I am being to think that perhaps the best way for me to go is to 
>> utilize a spare computer for floppy, parallel, etc services.
>
>Why?  I surely hope our discussion of processors hasn't scared you off from 
>doing a 64180-based board.  It doesn't have to be *perfect*, it just has to
>work and make you feel good about having accomplished something!  It *will*
>get used, even if it isn't what some of us would have designed ourselves...

Well put! You know, there's no reason we can't have several people doing
floppy/printer boards. It's such a nice, small, self-contained sort of a
project. I'll post mine once I'm done (and keep people posted about progress),
but no one HAS to use it. Heck, if someone does a "better" design, I might
put THAT in my 532 and keep MY board as toy...

>Bdale

-- Jerry Callen
   jcallen@encore.com
   (508) 460-0500 (work)
   (617) 876-5330 (home)

From owner-pc532%daver@mips.com Tue Jan 30 17:33:04 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Subject: Re: SCSI floppy interface (64180 tools)
To: pc532@daver.UU.NET
Date: Tue, 30 Jan 90 14:24:34 CST
X-Mailer: ELM [version 2.2 PL13]
From: dnewton@carroll1.cc.edu (Dave Newton the Late)
Status: O

> 

   There are 64180-specific tools available...  Just paging through the back of
Byte mag. (used to be so good too...  pity.)

Z-World Engineering (916) 753-3722\
   sells a 64180 SBC and offers Dynamic C, a PC-based 64180 cross-compiler
   with debugger and an interface board.
   The SBC has serial, parallel, iSBX, watchdog, proto area
   $395 board only
   $695 board, C development system, interface board

   Well, actually, that's the only one I could find off the top of my
Byte, but PC Rag probably has some more...  I know they exist...


From owner-pc532%daver@mips.com Tue Jan 30 20:18:21 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
To: pc532@daver.uu.net
Cc: asgard@omni.com
Subject: Systems integration standards, anybody?
Date: Tue, 30 Jan 90 16:04:08 -0800
From: J.R. (Use the Source, Luke) Stoner <asgard@omni.com>
Status: O

Now that people are starting to get their kits and systems together,
certain important decisions need to be made before all mailing list
participants start fracturing the integration issues.  The biggie,
right now is the nitty-gritty of the firmware design as pertains
kernel memory layout, which disk blocks need to be read at boot-time,
whether floppies and tapes should be supported as boot media.  I was
thinking of using either MCD-40 40Mb cartridges (CD2000) or Teac
digital cassettes (Phillips media) as distribution media.  When boot
blocks are read, where do they go, etc.  Ought the firmware contain,
as a standard, something like kadb?  Are unilateral decisions being
made right now as pertain to the MINIX/UNIX/MACH architectures?

If sufficient guidelines are available we can all start the coding
process for things like the EPROM using whatever styles are most
appropriate, as long as data movement is predictable.  Myself, I
was planning on using my existing stand-alone F83 for 32K's as
an extensible monitor but I want there to be simple words in the
dictionary to do things like load from tape and self-test, etc.

What media is the PC532 crowd going to use to share files?

Dave/George/Bruce?

--
J.R. (Use the Source, Luke) Stoner
  "Dying is easy,	| asgard@omni.com
    comedy		| asgard@cpro.uucp
      is hard."		| ...{apple,sgi}!koosh!asgard

From owner-pc532%daver@mips.com Tue Jan 30 22:57:35 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Subject: Re: SCSI floppy interface
To: pc532%tarpit@daver.uu.NET
Date: Tue, 30 Jan 90 20:44:37 EST
From: John L. Connin <johnc%manatee%uunet@daver>
X-Mailer: Elm [version 2.1 PL1]
Status: O

	(15.11/15.5+IOS 3.14) id AA05137; Tue, 30 Jan 90 09:09:50 est
Message-Id: <9001301409.AA05137@hpcsbg.col.hp.com>
To: daver.UU.NET!pc532
Subject: Re: SCSI floppy interface 
In-Reply-To: Your message of "Mon, 29 Jan 90 10:31:02 EST."
             <9001292237.AA01596@uunet.uu.net> 
Date: Tue, 30 Jan 90 07:09:48 MST

[ Bdale Garbee writes ]

[ John Connin writes ]
>> The 64180 has a builtin Memory Management Unit with 1M or 512K bytes
>> memory physical address space.  I am not sure this is entirely accurate,
>> but the 64180 appears to use a paging (bank switch) similar to that 
>> used in CPM80 Plus systems.

> This is precisely why I'm not a big fan of the 64180.  It is, to me, worse than
> dealing with Intel's segment registers... I thought bank switching was neat
> when I first heard about it for S-100 systems, then I had to write software
> for it, and... well... I'd rather not.  Hard to build a good C compiler
> runtime library that likes bank switching.

No flames intended.  It seems to me the implementation (including choice of
chips) should in general be left to the designer to select, particularly 
in the case of a controller.  Of course ultimately the market place will
determine if the designer made prudent decisions.  If you are comfortable
with the previous statement, then let me propose that in the future we
try to limit our discussion of proposed 'products' to functional 
requirements.

>> I am being to think that perhaps the best way for me to go is to 
>> utilize a spare computer for floppy, parallel, etc services.

> Why?  I surely hope our discussion of processors hasn't scared you off from 
> doing a 64180-based board.  
[ stuff deleted ]

Sorry if I was not clear.  For my needs, it just seemed that the feature
set I am interested in sounded more like a computer than a controller.

Subsequently, I have dusted off the boat anchor (ie a Comupro 286), fix
a couple of things, and now have it running (concurrent cpm).  The reason
I mentioned this is one of the first utilities I used was NSWEEP with
the following copyright notice:

	NSWEEP - Version 2.08	04/12/1985
		(c) Dave Rand, 1984, 1985
		    Edmonton, Alberta

Small world !!!

Best regards,
johnc


From owner-pc532%daver@mips.com Tue Jan 30 23:37:18 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: dlr@daver.UU.NET (Dave Rand)
Date: Tue, 30 Jan 90 20:11:56 PST
X-Mailer: Mail User's Shell (7.0.1 12/13/89)
To: pc532@daver.UU.NET
Subject: Re: SCSI floppy interface
Status: O

[In the message entitled "Re: SCSI floppy interface" on Jan 30, 20:44, John L. Connin writes:]
> Subsequently, I have dusted off the boat anchor (ie a Comupro 286), fix
> a couple of things, and now have it running (concurrent cpm).  The reason
> I mentioned this is one of the first utilities I used was NSWEEP with
> the following copyright notice:
> 
> 	NSWEEP - Version 2.08	04/12/1985
> 		(c) Dave Rand, 1984, 1985
> 		    Edmonton, Alberta
> 
> Small world !!!
> 

True. That is me. Looks like you are running the 8086 version, as well!
I used to use CCPM/86 a lot. Big fan of it, in the days that I was doing
lots of software development. In fact, Jim Lopushinsky (of LBRDSK fame)
and I did the original port of CCPM to the IBM AT, while at ISTEC in Edmonton.

I actually wrote NSWP in 82/83 for the 8080, and later ported it in assembler
to the 8086 (under CPM86/MPM86).

Sigh. The good old days, when 100 K assembler source files were BIG, and
debugging 4K executables was real work...


-- 
Dave Rand
{pyramid|hoptoad|sun|vsi1}!daver!dlr	Internet: dlr%daver@uunet.uu.net

From owner-pc532%daver@mips.com Wed Jan 31 14:31:20 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
Date: Tue, 30 Jan 90 15:34:01 PST
From: srg@quick.com (Spencer Garrett)
To: pc532@daver.uu.net
Subject: no-slot clock
Status: O

The no-slot clock is Dallas Semiconductors DS1216E, I believe,
and they call the product SmartWatch.  It's probably cheaper to
order it this way, but probably easier to get it from JDR et al.

From owner-pc532%daver@mips.com Wed Jan 31 14:33:29 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
From: mea@mea.utu.fi (Matti Aarnio)
Subject: Re: SCSI floppy interface
To: pc532@daver
Date: Wed, 31 Jan 90 10:50:30 EET
Cc: mea@mea.utu.fi (Matti Aarnio)
X-Mailer: ELM [version 2.2 PL10]
Status: O

> > The 64180 has a builtin Memory Management Unit with 1M or 512K bytes
> > memory physical address space.  I am not sure this is entirely accurate,
> > but the 64180 appears to use a paging (bank switch) similar to that 
> > used in CPM80 Plus systems.
> 
> This is precisely why I'm not a big fan of the 64180.  It is, to me, worse than
> dealing with Intel's segment registers... I thought bank switching was neat
> when I first heard about it for S-100 systems, then I had to write software
> for it, and... well... I'd rather not.  Hard to build a good C compiler
> runtime library that likes bank switching.
...
> > I am being to think that perhaps the best way for me to go is to 
> > utilize a spare computer for floppy, parallel, etc services.
> 
> Why?  I surely hope our discussion of processors hasn't scared you off from 
> doing a 64180-based board.  It doesn't have to be *perfect*, it just has to
> work and make you feel good about having accomplished something!  It *will*
> get used, even if it isn't what some of us would have designed ourselves...
> 
> Bdale

Well, My friend should be making a board design for  MC68302 Serial IO
processor, and that board will contain also some exotic things, like
Ethernet, SCSI, Parallel port (or two, serials within core of 68302),
memory, floppy controller chip, etc. maybe even VME slave adapter.
(Its part of i860 related project, an IO utility board, and maybe standalone
 controller board.  Its being feed into CAD - I should start making software.)

Best part is software compability :-)  Well, its 68000 plus fancy IO
geared for some mid-range speedy serial IO ports.
And best part:  I can use GCC and GAS to compile...

I made a phone call: design has progressed quite well, still some exotic parts
are missing from Redac CadStar he is using, but its just question of artistic
talent to create them... (Well, to have them look nice.)

	/Matti Aarnio	<mea@mea.utu.fi>


From owner-pc532%daver@mips.com Wed Jan 31 14:34:12 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
X-Mailer: Mail User's Shell (6.4 2/14/89)
To: pc532@daver.UU.NET
Subject: Re: SCSI floppy interface
Date: 31 Jan 90 15:39:59 GMT (Wed)
From: ken%mm@gatech.edu (Ken Seefried iii)
Status: O

On Jan 30,  8:11pm, Dave Rand wrote:
} > 
} > 	NSWEEP - Version 2.08	04/12/1985
} > 		(c) Dave Rand, 1984, 1985
} > 		    Edmonton, Alberta
} > 
} > Small world !!!
} > 
} 
} True. That is me. 
}

Wow...

NSWEEP was the single most useful utility on my old CP/M-80 v.2.2 box
around 83/84 (MASM-80 and Turbo Pascal v.1.0 was how I learned to programme).

How 'bout a '532 version...just kidding...:-)

} 
} Sigh. The good old days, when 100 K assembler source files were BIG, and
} debugging 4K executables was real work...
} 

Yea...as I sit here trying to debug an 8.55 MB (yes kids...MegaBytes)
X11/Motif exec...*sigh*, love those memory leaks...


-- 
       Ken Seefried iii             ...!<anywhere>!uunet!gatech!mm!ken
         MetaMedia, Inc.              ken%mm.uucp@gatech.edu 
           Atlanta, Georgia, USA        obquote: "I feel...like a god..."
    
                         "Release the weasels..."

From owner-pc532%daver@mips.com Wed Jan 31 14:37:14 1990
Flags: 000000000000
Reply-To: pc532@daver.UU.NET
To: pc532@daver.UU.NET
Subject: Re: HD64180 for floppy 
Date: Wed, 31 Jan 90 11:04:24 MST
From: Bdale Garbee <bdale@col.hp.com>
Status: O

> This was my first reaction to the 64180, too. But consider our application.

Ok, I'm sold.

> I realize I'm a bit of a dinosaur, but I was planning to do all the code
> in assembler.

!!  Ok, I still write a lot of assembler too, but less and less by choice...  

> >Why?  I surely hope our discussion of processors hasn't scared you off from 
> >doing a 64180-based board.  It doesn't have to be *perfect*, it just has to
> >work and make you feel good about having accomplished something!  It *will*
> >get used, even if it isn't what some of us would have designed ourselves...

> Well put! You know, there's no reason we can't have several people doing
> floppy/printer boards.

Jerry, I like your attitude.  A good friend of mine once commented that he only
knew of three reasons that ever justified building things from scratch:

	- because you can't get it any other way
	- because it's a learning experience
	- because you can make a substantial price/performance contribution
	
Looks to me like you've satisfied at one of the criteria, so go for it!

> It's such a nice, small, self-contained sort of a project.

Agreed.  If we can get enough folks working on nice, small, self-contained
sorts of projects, this is going to be a fun group to belong to.  :-)

I'm already looking at good ways to do a card with 8530's or equivalents and
DMA for fast packet radio links...

Bdale

From owner-pc532%daver@mips.com Wed Jan 31 14:45:14 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
To: pc532@daver.UU.NET
Subject: Re: Systems integration standards, anybody? 
Date: Wed, 31 Jan 90 11:17:58 MST
From: Bdale Garbee <bdale@col.hp.com>
Status: O

> I was
> thinking of using either MCD-40 40Mb cartridges (CD2000) or Teac
> digital cassettes (Phillips media) as distribution media.

I already have a Teac drive from my S/375, but I'm not married to it.  In fact,
there's a weirdy or two that had to be dealt with in the driver after a SCSI
reset, and I'm not fond of the media.

> Ought the firmware contain, as a standard, something like kadb?

Looked at Bruce Culbertson's monitor?  It's pretty neat, and exists...

> I
> was planning on using my existing stand-alone F83 for 32K's as
> an extensible monitor but I want there to be simple words in the
> dictionary to do things like load from tape and self-test, etc.

Fascinating!  I'm a bit of a Forth hack myself, would find this a really neat
approach...

As long as we can agree on on where to load the bits in memory, and how big a
chunk to load, it's easy.  

> What media is the PC532 crowd going to use to share files?

I'd like to use 1.44meg 3.5" floppies... they mail well, etc...  Sub-optimal 
for a large OS distribution, meaning a tape standard might be better for large
things.  I have no objection to having both tape and floppy on my system.

Bdale

From owner-pc532%daver@mips.com Wed Jan 31 18:11:00 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
To: pc532@daver.uu.net
Subject: Re: Systems integration standards, anybody?
Date: Wed, 31 Jan 90 13:58:47 -0800
From: J.R. (Use the Source, Luke) Stoner <asgard@omni.com>
Status: O

>> I was
>> thinking of using either MCD-40 40Mb cartridges (CD2000) or Teac
>> digital cassettes (Phillips media) as distribution media.

>I already have a Teac drive from my S/375, but I'm not married to it. 
In fact,
>there's a weirdy or two that had to be dealt with in the driver after a SCSI
>reset, and I'm not fond of the media.

I like Phillips media for reliability purposes.  What are the weirdys?
Are they anything like flipping vendor unique bits in select pages?
If so, this is a small matter which is a common problem in nearly
_all_ SCSI tape drives.  I should refer you to a flamage I posted
here a month or two ago.

>> Ought the firmware contain, as a standard, something like kadb?

>Looked at Bruce Culbertson's monitor?  It's pretty neat, and exists...

If it knows about the symbolic executable, like kadb it will work.
The problem is, among other things, we *don't* know what the
executable format of our kernel will be, since we do not know what
the O/S is going to be.  My preference, right now, is MACH with
niceties from Tahoe/BSD and vnode interface like SunOS.  Waiting
for the Stallman weenies to finish is pie-in-the-sky right now and
I have _not_ heard anything about SVRx to make design commitments.
MINIX is not sufficient since it will be a *year* before anything
stable will be available for PC's and Amigas, let alone small
potatoes like our project.

>> I
>> was planning on using my existing stand-alone F83 for 32K's as
>> an extensible monitor but I want there to be simple words in the
>> dictionary to do things like load from tape and self-test, etc.

>Fascinating!  I'm a bit of a Forth hack myself, would find this a really neat
>approach...

I wrote the standalone F83 for CompuPro's ill-fated CPU32016.

>As long as we can agree on on where to load the bits in memory, and how big a
>chunk to load, it's easy.

As long as one does not also lose the symbol table and relocation information
>From ld so that our monitor/kadb/whatever can do symbolic breakpoints.
Believe me, that is important.

>> What media is the PC532 crowd going to use to share files?

>I'd like to use 1.44meg 3.5" floppies... they mail well, etc...  Sub-optimal 
>for a large OS distribution, meaning a tape standard might be better for large
>things.  I have no objection to having both tape and floppy on my system.

I object to the limit being 1.44Mb.  Last year, when I wrote the CompuPro 3.5"
driver a density 3 (1K sector) format used *all* capacity in a HD
floppy (1.6Mb).
The density of floppy media and format *must* be decided before bending
metal for
a floppy controller, since 5.25" LD, 5.25" AT, 3.5" LD, and 3.5" HD all have
*different* clocking rates for the controller chip, which was a pain when
the controller was essentially an 8272.  Capability to format and copy
flops withing
the EPROM monitor is necessary to do safe operations.  Capability to
format and lay
down servo wedges is important for tape drives that require
pre-formatting, like the
MCD-40.  Once accomplished then minimal CCS commands are sufficient to
boot off tape
media since you don't get fancy at that level.  With a MACH kernel with
NFS support
and optional filesystems like CDROM it is quite conceivable to have a
kernel file
larger than 1.6Mb, so I don't like the idea of flops for that purpose
for this reason.
I intend to do _serious_ DSP with this gadget and do not want to spend
energy on
hacking the OS and firmware when *too many* options are to be
supported.  The energy
is really better spent on my DSP goals.

Don't get me wrong.  I am happy right now, and I intend to write a good
firmware support
for a suitable boot/backup media, but I want the decisions made soon,
if not sooner,
so I don't get into the same failure that CompuPro got into, trying to
support SIX
media interchange types, some of which conflicted with the other
architecturally.

>Bdale

--
J.R. (Use the Source, Luke) Stoner
  "Dying is easy,	| asgard@omni.com
    comedy		| asgard@cpro.uucp
      is hard."		| ...{apple,sgi}!koosh!asgard

From owner-pc532%daver@mips.com Wed Jan 31 18:13:04 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
From: athos@labtam.oz.au
To: pc532@daver.uu.net
Subject: Floppys and other boards
Date: Thu Feb  1 01:27:16 1990
Status: O

Message includes: SCSI floppy controllers; Boot procedure;
		  Another board design; Distribution media.

SCSI floppys:
-------------

Jerry Callen's ideas about a floppy controller board seem pretty solid.  I drew
up an outline design for a similar board, and ended up using exactly the same
chips that he's mentioned.  A few thoughts:

If you are using an 8255 for the parallel port, what are you going to use the
other port for?  There's enough on that chip for two parallel ports with
handshaking, but not if you want to controller a few other functions with it.

All a parallel port takes up on the board is an IDC connector, so if there're
enough pins free on the 8255, adding a second parallel port would give the
board more possibilities.  I can't imagine printing and floppy I/O competing
very hard for CPU time on the board.  That is, both are things that happen
sporadically on my machines, and rarely at the same time.  (Feel free to call
me shortsighted, folks!)

With a serial port on the board (which also can be just an IDC connector) for
debugging, it could be used from the host.  I know the pc532 (especially with
an et532) has heaps of serial lines, but if it's there then let it be used if
so desired.  This is all in the domain of the downloaded software for the
board anyway, not the hardware.

Someone please correct me if my SCSI understanding is warped, but the four
floppys (which can hopefully be any mixture of 5.25" and 3.5" drives - anyone
want 8" ?) the parallel port(s) and the serial port could be cleanly
distinguished as separate LUNs on the device.

Also, in my machine I would want to put this board on the same SCSI bus as
the other disks and tape, having the board similar in size to a SCSI/ST-506
controller.  I can see little reason for it to consume an I/O slot.  The best
solution would be to make it to suit both configurations, in the same manner
as the et532.


Boot procedure:
---------------

Someone asked about the mechanism used in booting a pc532 from disk (or tape
or whatever).  Surely it is simplest to get the board to search on its first
SCSI bus for a boot device (start at one end of the ID range) and then load
the first sector from that device (say from LUN 0 ?).  This copes with hard
disks, floppys, tapes, etc.

The question is left about what happens when no boot device is found.  Having
it drop into a ROM monitor seems sensible, but I would like to see a set-up
where it can then be "remote booted".  That is, in a machine made up of
several pc532s (running an appropriate distributed OS) not all of them will
have local disks, and those without should pause until contacted by a
neighbouring board that has already booted.
This is something that will come in the future, and I hope we manage to make
things general and extensible.


Another board:
--------------

A while ago I asked this question, but didn't notice any response.  For a
multi-processor scenario similar to that mentioned above, not every board
needs a synchronous SCSI for disk and tape, nor serial ports.  Given this
outline, and using the pc532 circuit as a starting point, can anyone tell
me if this could be cleanly designed onto an expansion card?

	25 MHz 32532 & 32381
	One bank of SIMMs (ie. 4 or 16 Mb RAM)
	DP8490 for connection to the motherboard, and maybe another for
		possible connection to a SCSI backplane for further I/O
		cards.  Leave that as a 50-pin IDC.

To software running on the board, it would be exactly the same as a pc532,
except that certain devices would not be found: the first SCSI bus and the
serial ports.

The boot ROM could be the same as that used on the pc532, as long as it
gracefully accepted not being able to find all the devices on every board.

Incidentally, locally we've been referring to such a board as a "cp532"
(Child Processor - as distinct from Motherboard).


Distribution media:
-------------------

Personally I would prefer either 5.25" HD (1.2 Mb) floppys or DC600 cartridge
tape.

My pc532 will initially only have hard disks of its own (I've scrounged up a
collection of SCSI controllers and small-ish drives).  My plans for peripherals
include a tape drive and a floppy controller, with (eventually) both 5.25" and
3.5" drives.  In the meantime, eyrie has both a floppy and a tape drive, and
it will be connected to the pc532 with SCSI.

And if I didn't have these locally, I have access to suitable drives on the
machines at work (including 3.5" floppies).  Are these the most common devices
available to you people?

The major initial problem I can see is how to get a bootable OS (initially
Minix in my case) onto one of the pc532's hard disks.  I can plug the disk
into eyrie and initialize it from there, but I can't imagine everyone having
the same equipment as me.


One last question, even if it seems a little "gimmicky".  How easy is it to
provide a LED indication of CPU idle time?  That is, if I decode the ST0-3
pins and use that to drive a single LED, is that too tacky for words?  :-)
Of course, that depends on the OS's idle state using the WAIT instruction.
___________________________________________________________________________
David Burren (Athos),			ACSnet: athos%eyrie@labtam.oz.au
img Consultants,
G.P.O. Box 3304GG, Melbourne 3001, Australia


From owner-pc532%daver@mips.com Wed Jan 31 18:13:48 1990
Flags: 000000000001
Reply-To: pc532@daver.UU.NET
Date: Wed, 31 Jan 90 15:00:53 PST
From: des@dtg.nsc.com (Desmond Young)
To: pc532@daver.UU.NET
Subject: Re: Systems integration standards, anybody?
Status: O

Really OMTI cards.
Halted is a surplus place at the corner of Lawrence and Central Xway.
The OMTI is about $89. The floppy supports 1.2Meg, but do not know
about 1.44 Meg. It handles 250Kb and 500Kbit data rates. I cannot
remember, but does the 1.44Meg use 300Kb?
  Anyway, I know it uses a uPD765 (PC-type) floppy controller, and
the data separation circuitry only allows 250/500Kbits/sec.
  One other option for those with a PC is to use a host-adapter in
the PC, and use your existing floppy controllers. The floppies speed
is not crucial, the PC has enough memory to buffer 1/2 of a 1.2Mb
drive. Hell, for bootstrapping you could use the PC's hard disk
subsystem as well. The cheapest floppy controllers are for the PC,
.Cheers, Des.

