Tag Archives: Know How

Knowledge Base

Vintage Fan replacement

Leave a comment

Making some noise

Working with vintage computers has many aspects and one of them, nearly throughout every component, is noise.
Hard-drives whirr, floppy-disks rattle, the CRT emits a high-pitch whistle and on top of it all at least one fan is blowing like a jet-engine. Time for a fan replacement!

Luckily since these days, much quieter fans have been developed during the last 30 years – so let’s just swap the fan and… ahhh, silence. I did that with my Sun Blade 150 and it worked great!

…well, it’s actually not that simple all the time.

Blown by the wind

System cooling was handled a bit different back in the 80’s and 90’s. Practically there were just 3 levels of cooling:

  • None – convection had to do the job.
  • One for all – one fan cooled the whole system
  • Insane – Either huuuuuge Fans (>8″) or some mad-scientist liquid-cooling was used. I won’t touch these in this post…

The “no fan” class were all so-called home-computers and the lower-end models of the early 16-bit machines like the ATARI ST, Commodore Amiga 500 or the first Apple Macintoshes (Steve Jobs was fanatic about convection cooling).

The most prominent “single fan” family members were office PCs up to the 486-class as well as any desktop/deskside 68k Apple Macintosh. All these had one fan sitting in their power-supply, blowing the warm air out to the back of the case.
Please mind the warm air. We’re not talking hot streams of  death-rays here. While CPUs weren’t a big heat-source issue (until the advent of the i486/50) passive heatsinks were sufficient to cool them by the air-flow/draft through the case created by the PSU.
For such Personal Computer systems it can be perfectly fine to replace some old, noisy fans with recent high-tech whirls. Especially if the PSU was also replaced by something more modern (like I did with my Quadra 950) producing less heat than the original one.

This is a totally different story when it comes down to workstations.
An en-vogue (UNIX) workstation back in the days was mostly designed using a relatively small pizza-box sized case, nicely snuggling underneath a monstrous 21″ CRT. To name just a few there were

  • SUN SparcStation 1 to 20
  • SGI Indy
  • Digital VAX/DECstation
  • Many HP PA-RISC 7xx

These boxes were cramped (hard-drives, expansion cards, lots of RAM) and their high-end processors ran much hotter than those x86 and 68k in personal computers.
Surprisingly none of them had a dedicated CPU fan mounted – instead they all relied on the power of the fan installed in the PSU.

Under pressure

Searching the web, you will find many texts recommending to put a quieter PC into your workstation. Vintage-me says: Don’t!

In case of workstations (pun intended!) a new indicator is needed in the game of fan replacement.
While the ‘PC world’ just looks at the CFM value (cubic feet per minute, i.e. airflow) as a performance indicator, workstation owners need to check the static pressure delivered by a fan. This is measured in mm/H20 (millimeter of water) and means how strong is a fan pulling air over obstacles and/or through venting slits etc. – think vacuum cleaner.
In consequence, two fans having about the same CFM value might be completely different when it comes down to static pressure. This is a nice table I found on the web comparing some high-performance fans with standard PC ones and the Papst 8412N is a good example of what I just wrote: The much liked NF-A8  has just 25% less CFM but only half the mm/H20:

Fan Airflow [CFM] Static pressure [mmH2O] RPM Noise [dB]
Panaflo FBA08A12U1A 46.9 4.8 3450 38.2
EBM Papst 8412N 40.6 4 3100 32.0
Noctua NF-A8 FLX 30 1.96 2000 16.1
Noctua NF-R8 31 1.4 1800 17.1
Arctic F8 31 1 2000 20

That power naturally comes at a price: More revs and much more noise… which is inevitable at the given mm/H20 power.

What’s cooking?

So what happens if I chose the wrong fan?
If a low-pressure fan is placed in an airflow path with lots of obstacles, the fan’s airflow will reduce and it will cool only the nearby components, but won’t have enough juice to suck heat from parts further away.
This means it will only cool (parts of) the power supply and the rest of the workstation will be more-or-less cooled by convection and the internal temperature will accumulate. Running such a machine for a longer duration will lead to ‘effects’. From errors to crashes, even smoke and finally destruction.

“C’mon, that’s folklore, Axel!” – Not a bit my friend.
I just had this experience when I thought that my MIPS RS2030 workstation could do just fine with a somewhat more silent, recent fan. The original one is/was a Delta AFB0812HH – a hellish loud fan. But even a  Noctua NF-A8 with a mm/H2O of nearly 2 made the small MIPS workstation unstable. First the PSU housing got really warm in the middle (switching regulators are screwed onto it there) and after 30 minutes of torture (compiling code) I got more and more SCSI I/O errors until the system completely froze.
Changing the fan back to the noisy one everything ran rock-solid. Quod erat demonstrandum!

So what should I do?

There’s no general advise to follow. If you want to keep your original PSU it might be possible to use a more silent fan for just the PSU and add one or more fans caring for the case ventilation.
Your milage may vary and multiple modern fans -which also need to be mounted somehow- might add up producing the same amount of noise like the single original did.

The cleanest solution is replacing the original PSU innards by more modern & smaller parts which then draw less power and therefore dissipate less heat, requiring less cooling.
This is especially advisable if you have the feeling that the original PSU gives fist signs of ageing (smell, heat, buzzing). Better safe than sorry!

Using Transputers

Basic Transputer Tools

Leave a comment

Ok, so you have your shiny (not so) new Transputer system installed/connected and you really like to know if it works and at least see some results… you’re in need of basic Transputer tools to get started.

First, download the Geekdot “Transputer Tool Kit” from my Transputer software page (New releases are possible, mind the version number).
Each tool introduced here has its own folder in the archive.

ispy/mtest

Even it’s historically not the first application ever developed for Transputers it’s for sure one of the most used.
It started as ‘check‘ and at some point got renamed into ‘ispy‘ – whatever the name is, the technical term would be “network worm”. This means it’s a special piece of code which a) sniffs around in a transputer (what kind, number of links and their speed) and b) replicates itself over all links it previously found.
When done, it outputs a network map like this example:

Using 150 ispy 3.23
 # Part rate Link# [ Link0 Link1 Link2 Link3 ] by Andy!
 0 T800d-25 292k 0 [ HOST   ...   ...   1:0  ]
 1 T425c-20 1.6M 0 [  0:3   2:0   3:0   ...  ]
 2 T400c-20 1.8M 0 [  1:1   ...   ...   ...  ]
 3 T400c-20 1.7M 0 [  1:2   ...   ...   ...  ]

ispy is used on geekdot.com extensively, so any time I write about Transputers you will see some sort of ispy output for sure.
There are several versions of ispy included in this kit. This is because some versions behave more stable than other in certain circumstances. E.g. the most recent version 3.23 does not work very well with the C004 link-switches.

“The other part” of ispy is called mtest. mtest takes ispys output and runs an indepth memory test/report on all Transputers found.

iserver

iserver is part of what INMOS called “itools” – long before Apple discovered the “i” for themselves 😉 – there were many others, mainly development focused (e.g. idebug, icconf etc.).
It is more or less the successor to the godfather of all Transputer booting tools “afserver” (1988). Well, it has to be, being the on INMOS supplied with all their other tools and languages.
The possible options are quite self-explanatory and printed to stdout when omitting any option:

iserver142h

Basically if you see a *.btl, *.b4 or *.b8 file it’s most likely meant to be executed with iserver. Before running successfully iserver need some environment variables set to successfully to be used:

set IBOARDSIZE=#100000
set TRANSPUTER=#150

These two settings tell all itools how much RAM the Transputer has to work with and at which port address it can be found (0x150 is default anyway). The archive contains V1.42h from Nov. 1990 which is the most recent as far as I know.

Mandelbrot

The “CSA Mandelzoom Version” is one of my favorite benchmark tools. I like it so much, that I run it once a while just for fun.. and to extend my benchmark table which I’ve collected over the time using it.

It is nice because it features integer (T4xx) as well as floating point (T8xx) versions of the calculation ‘slave processes’ and scans the network itself. No external tool needed. It’s also possible to let the host (i.e. your PC) calculate the Mandelbrot fractal to get an idea, how much faster/slower your Transputer network is – the archive contains a little benchmark result text file which I accumulated over the years.
Also there are some handy switches available (‘-h’ for help):

  • -v : Use VGA graphics
  • -t : Run on host instead of Transputers
  • -a : Autozoom, loads  a list of coordinates from man.dat and start calculating them without manual interaction.
  • -b : Use a different base address (instead 0x150)
  • -x : Verbose output of the Transputer initialization process (added by me)

After a while I got tired of manually time a calculation run and also ran into problems with large networks which simply became to fast to hand time. So I extended the code of Mandelzoom with a high precision timer (TCHRT, shareware, can’t remove the splashscreen, sorry) which prints out a timer summary when run with the “-a” parameter. I provided my default “MAN.DAT” file, which contains 2 coordinates to calculate (1st & 2nd run) and used for all my benchmarks.

csa_mandel_timerThese are the results of my DOS host system running in VirtualBox.

Caveat: It breaks if there’s a T2xx in the network (e.g. B008/B012) 🙁 And as always: Read the F-ing README.txt!

Since I started to heavily modifying the source, I wrote a post of its own about it as well as put everything on github, so you can join the fun 😉

Other Tools

iskip

iskip can be very handy, when ‘talking’ directly to (externally) connected links, e.g. another network which is connected to your root Transputer. Here’s a good example:
You like to put code directly onto “processor 1” which is connected to link 2 of your root Transputer:

iskip

So you call

iskip 2 /r /e

This sets up the system to direct the program to the target network over the top of the root transputer and starts the route-through process on the root transputer. Options ‘R’ and ‘E’ respectively reset the target network and direct the host file server to monitor the halt-on-errorflag. The program can then be loaded ‘through’ the root Transputer directly onto processor 1 using:

iserver /ss /se /sc test.btl

debug.exe

Yes, I do mean the comes-with-DOS debug.exe. Well, you can use any debugger you like as long it can read/write to port addresses.
Obviously this means [MS|PC|Open|Free]DOS only. You won’t get far with this on Linux, any Windows or OS/2. At least for initial debugging and testing I strongly recommend to use the “bloated interrupt manager” known as DOS.
First of all, you have to know the port addresses the C012 registers are mapped to . There’s a de-facto industry standard which INMOS introduced with the IMSB004. Its been adopted by 90% of all 3rd party products, even with certain ISDN cards using Transputes.

The base address normally is at 0x150 (which can be configured to other addresses in some cases). From this base adress the offset is always the same:

Base Adress Register Comment
+0x00 C012 input data  read
+0x01 C012 Output data write
+0x02 C012 input status register read = returns input status
write = set input interrupt on/off
+0x03 C012 Output status register read = returns output status
write = set output interrupt on/off
+0x10 Reset/Error register write: Reset Transputer & C012 and possibly subsystem (check manual)
read: Get Error status
+0x11 Analyse register  (un)set analyse

So here’s a clean Transputer setup ‘conversation’ using debug (comments are just for clarity, not supported in debug):

c:\>debug
 -o 160 1         # Assert RESET
 -o 161 0         # Deassert ANALYSE
 -o 160 0         # Deassert RESET ... init B004/IMSC
 -o 152 0         # Clear Input  Interrupt enable
 -o 153 0         # Clear Output Interrupt enable
 -i 152           # Read Input Status
 00               # Bit 0 = 0 -> no Data waiting
 -i 153           # Read Output Status
 01               # Bit 0 = 1 -> ready to send 
 -i 160           # Read Error
 00               # Bit 0 = 0 -> ERROR not signaled
-o 151 1          # send POKE
-i 153            # Read Output Status
01                # Ready -> POKE Ack (00 = BAD no Transputer)
After that you’re fine to send and receive bytes through 0x151/0x150. Doing so, you’re completely free which programming language to use. Here are some examples in AppleSoft Basic or even Python.
Using Transputers

The Inmos C004

Leave a comment

Hardware

Before I reinvent the wheel, here’s the quick intro from the manual, what an Inmos C004 actually is:

The IMS C004 is a transparent programmable link switch designed to provide a full crossbar switch between 32 link inputs and 32 link outputs. The IMS C004 will switch links running at either the standard speed of 10 Mbits/sec or at the higher speed of 20 Mbits/sec.
It introduces, on average, only a 1.75 bit time delay on the signal. Link switches can be cascaded to any depth without loss of signal integrity and can be used to construct reconfigurable networks of arbitrary size. The switch is programmed via a separate serial link called the configuration link.

So in simple words: 32 inputs can be freely connected to 32 outputs. Great for large Transputer networks which can be reconfigured only by reprogramming the C004 – on top of that, you can cascade them and create huge, complex networks to make any connection imaginable possible. Like those Parsytec used in their SuperCluster machines looking like this:

MegaFrameXbarDetailYes, that’s 13 C004s and one Transputer to rule them all…

… so much for the theory.

In practice, the C004 is a bitch. Not only does it require a Transputer to configure it (normally a 16bit T2xx) it also adds quite a delay into the link-communication. As mentioned above, it’s “only a 1.75 bit time delay” but this can sum up to quite an amount.
Let me quote some more realistic numbers from the Helios manual (pp.255):

It is of interest to ascertain the effect of the Inmos C004 on the performance of the Helios communication mechanisms. Figure 6.3 illustrates the rates of data communication (Kbytes/second) attained using message passing primitives (PutMsg() and GetMsg()) between two Transputers that were
1. Directly linked and
2. Connected through a C004 link switch.
It is evident from Figure 6.3 that the effect of the C004 link switch on the rate of communication is far from negligible. The overhead imposed by the link switch increases with the size of the message. In the worst case (64 Kbyte message), transmission through the C004 is 23 % slower than sending data over directly connected links.

C004_helios

Oops. 23% is quite essential. So before planning to set up a crazy C004 network you might consider what you want to achieve.
Is it for educational network studies only? Fine.
Are you going for speed and rarely change your Transputer network configuration? Avoid it!

IMHO even the 10 possible Transputers on an IMSB008 do not require a C004 making your day.
Actually, even Parsytec thought that this is useless to use a link switch for the 16 Transputers in their beautiful x’plorer and replaced it by hard-wire dummies:

C004_dummies2

Configuration

Ok, you’re still not scared away and really do like to know how to handle that beast. Fine, here’s what I went through:

To work with a C004 you obviously need either a TRAM carrier like the B008 or some sort of motherboard like the IMSB012 or IMSB014.  Read the boards manual to understand how to connect to the T2xx Network Control Processor (NCP).
For example the IMSB012 has extra pins for “config down” (i.e. IN) and “config up” (i.e. OUT) for its T212 and any other boards being chained to it.
As for the IMSB008 has its T222 connected to Link 1 of TRAM 0.

The hardware wiring is important to know, because this information is needed for the so-called hardwire file used by the INMOS tool “MMS2” (Module Motherboard Software, MSDOS only, the manual is available here).
After reading the manual (do!) you should be able to read this hardwire file for an B008 quite easily. It describes the complete hardware setup and all physical connection between the C004(s), T2xx and Transputer/TRAM links on the board:

-- B008 hardwire description
DEF B008
  SIZES
    T2 1
    C4 1
    SLOT 10
    EDGE 10
   END
   T2CHAIN
     T2 0, LINK 3 C4 0
   END
   HARDWIRE
     SLOT 0,LINK 2 TO SLOT 1,LINK 1
     SLOT 1,LINK 2 TO SLOT 2,LINK 1
     SLOT 2,LINK 2 TO SLOT 3,LINK 1
     SLOT 3,LINK 2 TO SLOT 4,LINK 1
     SLOT 4,LINK 2 TO SLOT 5,LINK 1
     SLOT 5,LINK 2 TO SLOT 6,LINK 1
     SLOT 6,LINK 2 TO SLOT 7,LINK 1
     SLOT 7,LINK 2 TO SLOT 8,LINK 1
     SLOT 8,LINK 2 TO SLOT 9,LINK 1
     C4 0,LINK 10 TO SLOT 0,LINK 3
     C4 0,LINK 1 TO SLOT 1,LINK 0
     C4 0,LINK 11 TO SLOT 1,LINK 3
     C4 0,LINK 2 TO SLOT 2,LINK 0
     C4 0,LINK 12 TO SLOT 2,LINK 3
     C4 0,LINK 3 TO SLOT 3,LINK 0
     C4 0,LINK 13 TO SLOT 3,LINK 3
     C4 0,LINK 4 TO SLOT 4,LINK 0
     C4 0,LINK 14 TO SLOT 4,LINK 3
     C4 0,LINK 5 TO SLOT 5,LINK 0
     C4 0,LINK 15 TO SLOT 5,LINK 3
     C4 0,LINK 6 TO SLOT 6,LINK 0
     C4 0,LINK 16 TO SLOT 6,LINK 3
     C4 0,LINK 7 TO SLOT 7,LINK 0
     C4 0,LINK 17 TO SLOT 7,LINK 3
     C4 0,LINK 8 TO SLOT 8,LINK 0
     C4 0,LINK 18 TO SLOT 8,LINK 3
     C4 0,LINK 9 TO SLOT 9,LINK 0
     C4 0,LINK 19 TO SLOT 9,LINK 3
     C4 0,LINK 20 TO EDGE 0
     C4 0,LINK 21 TO EDGE 1
     C4 0,LINK 22 TO EDGE 2
     C4 0,LINK 23 TO EDGE 3
     C4 0,LINK 24 TO EDGE 4
     C4 0,LINK 25 TO EDGE 5
     C4 0,LINK 26 TO EDGE 6
     C4 0,LINK 27 TO EDGE 7
 -- Uncomment the next two lines if the
 -- patch header wiring is used to
 -- connect C004, link 28 to PatchLink0,
 -- and C004, link 29 to PatchLink1.
 -- C4 0,LINK 28 TO EDGE 8
 -- C4 0,LINK 29 TO EDGE 9
   END
PIPE B008 END

After that’s done, you can prepare a second file. The so called “softwire file” which actually tells the T2xx how to internally connect his in- and out-links. A very simple example would be:

SOFTWIRE 
PIPE 0
 SLOT 0,3 TO SLOT 1,3 
END

This would connect TRAM-0’s 3rd link to TRAM-1’s 3rd link.
Now that you have the necessary config files let’s move on to the MMS itself.

Software

As with nearly every software from INMOS the MMS too is written in OCCAM and therefore has to run on a Transputer. This might be the one in TRAM slot 0 on your B008 or on a local ISA board which itself is connected with 2 links to a B012 (one for config and one to the Transputer network).

To make things easier, I prepared a complete MMS archive to download here (links to my Transputer Software page).
It contains some example soft- and hardwire files, an ISERVER.EXE (the program you need to upload code into your Transputer) as well as a batch file to easily start MMS (RUN_MMS.BAT).
Also you will find a folder with INMOS’ pimped version of ANSI.SYS called BANSI (“Better ANSI”), because all INMOS tools make heavy use of ANSI screen control. So put that into your CONFIG.SYS.

Before we begin, let’s have a look at my IMSB012 with ispy:

ispy 2.33
   # Part rate Mb Bt [  Link0  Link1  Link2  Link3 ]
   0 T800d-25 0.37 0 [   HOST    1:1    2:1    ... ]
   1 T2   -20 1.64 1 [    ...    0:1    ...    ... ]
   2 T800d-25 1.75 1 [    ...    0:2    3:1    ... ]
   3 T800d-25 1.77 1 [    ...    2:2    4:1    ... ]
   4 T800d-25 1.77 1 [    ...    3:2    5:1    ... ]
   5 T800d-25 1.75 1 [    ...    4:2    6:1    ... ]
   6 T800d-25 1.75 1 [    ...    5:2    7:1    ... ]
   7 T800d-25 1.75 1 [    ...    6:2    8:1    ... ]
   8 T800d-25 1.75 1 [    ...    7:2    9:1    ... ]
   9 T800d-25 1.75 1 [    ...    8:2   10:1    ... ]
  10 T800d-25 1.75 1 [    ...    9:2   11:1    ... ]
  11 T800d-25 1.75 1 [    ...   10:2   12:1    ... ]
  12 T800d-25 1.75 1 [    ...   11:2   13:1    ... ]
  13 T800d-25 1.77 1 [    ...   12:2   14:1    ... ]
  14 T800d-25 1.77 1 [    ...   13:2   15:1    ... ]
  15 T800d-25 1.75 1 [    ...   14:2   16:1    ... ]
  16 T800d-25 1.77 1 [    ...   15:2   17:1    ... ]
  17 T800d-25 1.77 1 [    ...   16:2    ...    ... ]

Ok, let’s start MMS2. Use/modify the batch “run_mms.bat” which will do all environment variables expected by iserver.exe and also adds the input and output files – change it as you please.
If everything works fine, iserver loads MMS2.B4 onto your Transputer and executes it. Your screen should look like the screenshot below.
First, I suggest you press “c” for checking the consistency of your hard/softwire files – if everything’s fine, MMS2 will print “Source files checked O.K.” as seen in the lowest line in the screenshot.

MMS1

Just for the fun of it, you can try MMS’ very own network worm – so press “n” to start the network mapper. You will see that it is much slower than e.g. ispy, so just be patient.
After some seconds, you should get something like this:

MMS2

Now it’s time to program you network. So press “s” to set the C004(s). Some infos will rush trough the bottom line of the screen and finally MMS2 states “C004 setting preformed O.K.“:

MMS3

Nothing more to do here so press “q” to quit MMS2.  (Do not run the network mapper again! It seems to reset the T2 and in my case reproducibly crashes the network).
It’s better to use ispy. ispy v2.33 to be precise. I encountered several issues with the C004 and the most recent version 3.23 of ispy.

So running ispy including the /C4  switch to display the settings of the two C004s now shows this – mind all the new connections of each Transputers Link0 and 3:

ispy 2.33
   # Part rate Mb Bt [  Link0  Link1  Link2  Link3 ]
   0 T800d-25 0.37 0 [   HOST    1:1    4:1    ... ]
   1 T2   -20 1.74 1 [    2:C    0:1    ...    3:C ]
   2 C004b   [ 6S3JM54V --U8-1C- -G--F9-I T--7-PQ- ]
   3 C004b   [ -D-2650R BL--E--K H-N3--4- -TU-1OA7 ]
   4 T800d-25 1.65 1 [    ...    0:2    5:1    6:0 ]
   5 T800d-25 1.75 1 [    ...    4:2    7:1    8:0 ]
   6 T800d-25 1.41 0 [    4:3    9:2    8:1   10:0 ]
   7 T800d-25 1.75 1 [    ...    5:2    9:1   11:0 ]
   8 T800d-25 1.41 0 [    5:3    6:2   11:1   12:0 ]
   9 T800d-25 1.75 2 [    ...    7:2    6:1   13:0 ]
  10 T800d-25 1.35 0 [    6:3   13:2   12:1   14:0 ]
  11 T800d-25 1.41 0 [    7:3    8:2   13:1   15:0 ]
  12 T800d-25 1.42 0 [    8:3   10:2   15:1   16:0 ]
  13 T800d-25 1.32 0 [    9:3   11:2   10:1   17:0 ]
  14 T800d-25 1.35 0 [   10:3   17:2   16:1    ... ]
  15 T800d-25 1.41 0 [   11:3   12:2   17:1   18:0 ]
  16 T800d-25 1.33 0 [   12:3   14:2   18:1    ... ]
  17 T800d-25 1.32 0 [   13:3   15:2   14:1   19:0 ]
  18 T800d-25 1.35 0 [   15:3   16:2   19:1    ... ]
  19 T800d-25 1.32 0 [   17:3   18:2    ...    ... ]

Yay! It worked. Positively as well as negatively.
Besides the new connections you might also spot a difference in the link-speed column. In our first run of ispy all Transputers had a link-speed around 1.75MBps.  Now it varies between 1.75 and 1.32, depending on how often the ispy worm crossed a C004.

Two final hints:

If your C004 network has been set-up as planned, you can use ispys output to programm the network later.
Just save the output into an ASCII file (ispy /c4 > my_net.txt) and when needed feed it back into ispy like this:
 ispy /r /cr < my_net.txt
This will reset the network and read in the configuration from stdin.
Obviously you can also manually edit the text file, the c4 lines

   2 C004b   [ 6S3JM54V --U8-1C- -G--F9-I T--7-PQ- ]
   3 C004b   [ -D-2650R BL--E--K H-N3--4- -TU-1OA7 ]

which isn’t as comfortable and comprehensible as editing a hard/softwire file. But your mileage my vary.

Alternatively, MMS2 can create a bootable file with your network settings. This can be used for quickly setting-up your system.
Just hit the “b” key and enter a filename. My MMS2 archive contains the above example as “BOOTB012.BTL”. Run it with “iserver /SB bootb012.btl“.

Caveats

Mind your reset! This means, in many cases a root Transputer might reset all the “worker Transputers” but also your T2xx and in effect all C004. So be careful when resetting your system.

Yes, theoretically you can reconfigure your Inmos C004 on the fly while all connected Transputer run. The most prominent example is having one network topology during data acquisition while changing it for number crunching later on.
This requires a very good knowledge of the notwork and thorough process locking etc.

Handling TRAMs, Knowledge Base, TRAMs

Handling TRAMS

Leave a comment

General caveats

TRAM pins are thinner than normal PCB-Pins e.g. those you may know from Arduino shields and thus they are, well, quite fragile. That’s a problem (by design) with all TRAMs. So be very careful when handling TRAMs, i.e. removing/plugging them from/into your TRAM carrier e.g. a IMS B008.

And you can’t repeat this enough: Ground yourself! Electrostatic discharge will kill your TRAM as well as any other electronic device.

How do I do it? My main and single tool for handling TRAMs is this pair of straight tweezers:

Pliers

This works quite well for carefully removing TRAMs from its socket by putting it between TRAM and socket like this and gently lever the TRAM – not too much! Else you will bent the pins on the other side – repeat on the other side. Done.

The Transputer

If you got you TRAM without a Transputer plugged in, you might figure that it’s quite difficult to plug in the CPU. My suggestion:

Put the back of the TRAM (the socket pins only – refrain from putting any force onto the TRAM pins) on a medium-soft item, e.g. a block of wood or like I usually do it, onto the rim of a sticky-tape roll, and press the CPU using even force into the socket with your thumb.
Double check that all CPU pins are straight and are sliding into the socket holes without force and fiddling. Also, mind the CPU orientation!
Again, never push the Transputer into its socket without support underneath the socket, your TRAM will bend and traces might break rendering it useless. At minimum the TRAM-pins will be damaged.

CPUpress

It’s worse when you’re in need of removing the CPU. Sometimes the ceramic packaging is extremely brittle and the CPU pins do sit very tight in the socket.

Again, use a straight tweezer, gently pushed between the socket and the CPU and carefully lever the CPU for a millimeter max.

CPUlever2

Repeat on all four sides of the CPU…

CPUlever1

EISA Bus, Knowledge Base

Intel EISA Chipset

Leave a comment

This chipset started it all… it was the first EISA chipset produced and the one which riddled me the most. Mainly because I have two EISA boards behaving differently when it comes to expansion cards which were developed later (~1992-94) and so I suspected the Bus Controller to be the reason for all the hassle:

The Hauppauge 4860, an early EISA system and my Intel Professional Workstation (aka LP486, not yet documented on this page).
The first is using a 82350 chipset while the latter has a 82350DT. Where’s the difference? There’s no clear answer to this anywhere, so I had to do some lenghty, in-depth research.
Good that I do not only collect ancient cool hardware but also some documentation, e.g. the 2″ thick Intel “Peripheral Components” handbook from 1991…

Intel_Periph

Here’s my conclusion:

The ‘original’ 82350 Chipset -released May 1990- included just 2-3 chips: 82357, 82358(-33) and (optionally) 82352.
The 82350DT -released April 1991- consisted on 5-7 chips: 82357, 82358DT, 82359, 82351, 82352, 82353 (some of them used multiple times).
The difference between the non-DT and DT version of the 82358 seems to be the synchronous interface to the 82359 DRAM controller, which wasn’t available in the initial chipset.

Chip-by-chip round-up of the chipset:

The 82350DT EISA chip set contains 7 VLSI chips to build a complete EISA
system. It is built upon the 82350 EISA chip set utilizing the 82358DT EBC and
82357 ISP and then adds VLSI components:

  • 82359 DRAM controller.
  • 82353 Advanced Data Path,
  • and 82351 LIOE Local IO Peripheral

The picture below shows a 486 based system with 82350DT chip set.

illu

The host bus connects the CPU and the memory subsystem. Tlte peripheral bus (X-bus) is an 8-bit bus to support the motherboard IO functions: keyboard, floppy and the LIOE which integrates the parallel port; and support: extemal teal time clock und serial ports. The peripheral bus is a buffered version of the 8-bit ISA bus. The memory subsection operates independent of the CPU clock. This independence is accomplished through the use of 82359’s integrated programmable delay line and the  rogrammable state tracker(PST) function. The integrated programmable delay line is used to time precisely the DRAM cycle sequence to DRAM parameters. The PST resides cm the CPU module. Tite 82359/82353 reside on the motherboard. They are indifferent to the CPU/cache used. The PST converts processor cycles to a form acceptable to the 81359. This allows different CPU/ cache combinations to be connected to the same motherboard. Further, it translates CPU’s clock-dependent handshake to clock-less memory interface handshake.

Local I/O EISA Support Peripheral, lntel 82351

The 82351 supports or integrates all of the IO peripheral functions for a typical EISA system board with a minimum of external logic. lt integrates local I/O ddress decoder, EISA system configuration registers, two external serial I/O ontroller interfaces with four assignable interrupts generation, external EISA onfiguration RAM interface, parallel port interface, external floppy disk controller Interface, external keyboard (8×42) controller interface including interrupt generation, and external real time clock interface and EPROM or FLASH EPROM BIOS ROM interface. lt was available in a 132-pin PQFP (Plastic Quad Flat Pack) package.

EISA Bus Buffer (EBB), Intel 82352

The 82352 is a bus buffer IC for EISA bus system. Three 82352 chips are used in a 82350 EISA system. Only one 82352 chip is used in a 82350DT EISA system.
lt operates in three modes. ln Mode 0 it performs data latch and swap functions.
It allows swapping and assembly of  data between the host and EISA/ISA buses on a byte by byte basis. In Mode 1 it provides 1 buffered path between the host data bus and DRAM with parity generation/check. Mode 2 was reserved by Intel for future use (never happened). Mode 3 provides address latching function between the host and EISA/ISA buses. The 82352 was available in 120-pin quad flat pack (QFP).

Advanced Data Path, Intel 82353

The 82353 provides advanced data path in e 82350DT EISA bus system. Two 82353 chips are used in a 82350DT EISA bus system as showed in the graph. Each 82353 is designed as a 16-bit slice. Two 82353 chips can provide parallel interface to 32, 64 or 128- bit wide memory structures to a 32-bit host and system bus.
The 82353 provides optimal 486 burst performance. Each memory cycle enerated by the address controller chip causes 128 bits of memory data to be latched in two 82353 chips. Once data is latched, these 82353 chips mux the four dwords to the destination in one wait state. The 82350DT EISA bus has 128-bit memory bus. A typical burst is 128-bit wide. and a bus with the same width
allows to read the whole burst in one memory cycle. This provides a zero wait state burst at any frequency. The 82353 was available in a 164-pin PQFP package.

Integrated System Peripheral (ISP), Intel 82357

The 82357 contains DMA controllers, interrupt controllers and programmable 16-bit counter/timers. lt provides high-performance arbitration for CPU, EISA/ISA bus masters, DMA channels and refresh. It also provides logic for generation/control non-maskable interrupts. The DMA function is provided by two inbuit 82C37A DMA controllers. These DMA controllers are connected in cascade mode to provide seven independent programmable channels. The timing control for 8-, 16- and 32-bit DMA data transfer is provided. The data transfer rate is 33MB/sec. There are two 82C59A interrupt controllers in the 82357 chip, which provide 14 independent programmable channels for level or edge-triggered interrupts. The 82357 contains five 82C54 compatible programmable 16-bit timers/counters. lt was available in a 132-pin PQFP package.

EISA Bus Controller, Intel 82358DT

The 825358DT provides an interface between 386/486 CPU and EISA bus system.
It provides EISA/ISA bus cycle compatibility with the host(CPU) bus. The 82358DT is a part of intel 82350 and 82350DT chip set. It translates host(CPU) and 82359(DRAM controller) cycles to EISA/ISA bus cycles. lt supports 8-, 16- or 32-bit DMA cycles. lt also supports host and EISA/ISA refresh cycles. lt generates control signals for advanced data path(82353) and EISA bus buffer(82351). lt was available in a 132-pin PQFP package.

DRAM Controller, lntel 82359

The 82359 is a highly integrated advanced memory controller. lt supports 386 and 486 microprocessors. Its operation is independent of speed and type of the CPU. It allows a system designer to implement a variety of CPU/cache combinations. It provides address control, refresh generation and critical DRAM timing generation. In conjunction with two advanced data path devices (82353), it acts as a highly integrated 32-bit dual ported memory controller. Its two ports (or address gateways) to main memory are: one exclusively for the host and one exclusively for EISA. This configuration of ports permits CPU activity to be isolated from EISA bus activity. It controls up to 256MB of motherboard DRAM. It supports 32-, 64- or 128-bit wide memory configurations. lt was available in a 196-pin PQFP package.

Bus Master Interface Controller, Intel 82355

The 82355 is used in an EISA add-in card (expansion board) – thus rarely found on mainboards.
It supports 16- and 32-bit burst transfers at maximum data transfer rate of 33MB/s. It also supports 32-bit non-burst and mismatched data size transfers. It automatically handles misaligned double-word data transfer with no performance penalty. It has two independent data transfer channels with 24-byte FIFOs. Expansion board timing and EISA timing operate asynchronously. The 82355 supports 32-bit EISA addressability (4GB). It integrates three interfaces:
EISA, local CPU and transfer buffer. It supports automatic handling of complete EISA bus master protocol. This includes EISA arbitration/preemption, cycle timing and execution, byte alignment, etc. Further, the 82355 supports local data transfer protocol similar to traditional DMA. It was available in a 132-pin JEDEC PQFP package.

EISA Bus, Knowledge Base

The EISA Bus

Leave a comment

Actually I have no idea why this subject caught my interest so well.
During the hey-days of the EISA bus I wasn’t interested at all, thought that’s something which will never take off and was intended for servers only. I happily stuck to clumsy ISA and sat there until PCI was affordable (ASUS SP3G anyone?).

Now, fiddling with all those exotic cool mainboards, EISA crosses my path all the time. The way EISA is configured, the somewhat cumbersome use of cf.exe (ECU – EISA Configuration Utility) tool drew my interest… maybe because it has the scent of manliness 😉

In my humble opinion, EISA was a crutch, but it layed some basics for the next 10 years:

  • It defined (as a by-product) a standard for the ISA bus, which was all chaotic before
  • It forced Big-Blue (IBM) to think over their Microchannel licensing
  • It was a test-bed for how do things right… later known as PCI

That said, it is the fun twilight-zone between ISA’s direct access “do what you like” and PCI’s “you touch – you die” approach. Where else do you have 32-bit speed and can still change bits manually with DOS’ debug?