Category Archives: Hardware

Hardware, TIGA

TIGA – The basic stuff

3 Comments

Welcome to the TIGA basics page! The fist post in my little TIGA chapter.
You probably came here because you just got (or plan to buy) a cool, shiny TIGA card and like put it to some use. Or you’ve read about it and found out, that the Web is pretty thin on that matter… Anyway, you came to the right place!

Let’s check some points fist…

Hardware

Well, if you have a card already, great, you’re set.

There were/are different versions around. The early cards used the first implementation of the graphics controller called TMS34010  which was clocked up to 60MHz (amazingly high!). For example TIs very own “TIGA Star”:

Later models used the advanced TMS34020 which started at 33MHz up to a max of 40 but had faster instruction cycle times, a faster memory interface and a twice as big instruction cache (512 bytes. Yes, bytes). Additionally the ‘020 supports the rare TM34082 floating point co-processor (actually even more than one) to speed up 3D calculation. I’m not aware of a Tool using that…

One of the first ‘020 cards was probably the Diamond from TI, which even features a socket for the FPU:

My weapon of choice is the mighty Miro TIGER:

Every TMS340 has its own RAM to run “programs” in. Depending on the model this starts at 1MB and can sometimes expanded up to 17MB. Better cards used SIMM to do this, but there were some models which used  proprietary RAM modules which are nearly impossible to come by these days.
Next the TMS340 needs VRAM, the memory holding the graphics itself. Again, depending on the model, this might vary from 1 to 4MB resulting in different max resolutions. IMHO just 1MB doesn’t do a TIGA card justice. That is just enough for 640×480 in 24bit…
Finally, as TIGA was not a standard CGA/EGA/VGA replacement, you’ll need some way of displaying the DOS text/graphics output. TIGA was always meant as an additional display mostly using a 2nd high-resolution screen, so TIGA cards either run in parallel to an existing VGA card or it also features a (mostly simple) VGA controller for this.
Very sophisticated cards like the above miroTIGER gave many options for this. It features a small VGA part (a Cirrus Logic CL-GD540 and 256K of DRAM) to make a 2nd card unnecessary or could disable that to use a 2nd card of your choice for a two-screen-solution or offered to loop-though the signal of an existing VGA card and automatically switch between them for a single-screen-setup.

Recommendation

So if you consider buying a TIGA card, go for a TMS34020 with SIMM sockets. It should have at least 1MB RAM and 2MB of VRAM. A SPEA Graphiti FGA is a good example for this minimum config.
While DRAM isn’t that important, the more VRAM you have, the better. Having a VGA controller on board might be desirable if you’re tight on slots – but to my knowledge the best VGA controller ever used on-board  was an ET4000. So it’s more or less a matter of taste.

Software

Actually this is the more important point on your list. While yes, TIGA is a standard, it contains certain proprietary parts, called the CD, GM and EXTPRIMS you’ll need to get your card going. The reason for this is the driver which is more a layer model looking like this (listed bottom-up):

Application using TIGA (e.g. AutoCAD)
application specific extensions (also *.ALM/*.RLM file)
extended primitives (EXTPRIMS.RLM/*.ALM)
Graphics Manager (e.g. tigagm.out)
Communication Driver (tigacd.exe)

 

The 3 yellow(ish) levels are card-dependent, so without them, you’re lost and your shiny TIGA card just makes a nice paperweight.
The lowest level is the Communications Driver, or CD for short, is 100% hardware dependent –  It is always supplied by the cards manufacturer and, well, handles the low-level communication and resides in the PC (upper-)memory.
Above that sits the Graphics Manager (GM)- this is the “real thing™”, the core or kernel of TIGA – which is the firsts thing being loaded into the cards own DRAM.
On top of the Graphics Manager sits another layer belonging to the package provided by the card manufacturer and loaded into the cards RAM, the Extended Primitives Library called EXTPRIMS.RLM in 99% of all cases. This contains all the drawing routines for primitives e.g. boxes, circles but also printing text etc. The file extension ‘RLM’ stands for relocatable load modules while ALM means absolute load modules. RLM’s are loaded and linked at run time, ALM’s are linked in advance for a fixed configuration and later at run time just loaded onto the TIGA card.

Here’s another illustration to show the layer model separated by memory regions:

With these 3 layers loaded, your TIGA card is ready to rock and awaiting commands from your application. Let’s take AutoCAD as an example – it’s probably the best example anyway as TIGA was mainly used for CAD.
It will not only load the TIGA driver but probably also some extensions provided by your cards manufacturer. So for example the miroTIGER came with a 3D-Viewer called “MulitVIEW”, ELSA provided a tool called ELSAVIEW with their Gemini cards etc.. All those tools loaded some extra code into the cards RAM (that’s the light blue layer).
All the extension tools I saw up to now didn’t require more than 200KB RAM. The TIGA core itself is at ~100KB, so for most basic stuff 1MB might suffice at first – but of course some of those tools need extra RAM for holding data so my assumption is that 2MB are a good bet to start with.

Caveats

All that said, be aware that were two main versions of the TIGA kernel – V1.x and V2.x which have slight differences in programming. Again, it depends on the model of your card which TIGA version is supported. As far as I know, V2.x (2.2 being the latest) requires a TMS34020.
ALM’s were a unique feature of TIGA V1.1 and should no longer be used with TIGA V2.0. Generally, V1.x programs do not run (properly) on a V2.x CD/GM combo.

Setup

First, most likely there might be something to setup on your card. DIP switches for example or jumpers. At least you need to know/set the base-IO address of your card. Lucky are those who have a manual 😉
Next, as this is DOS-land, there are some things to set-up in your config files. As usual with DOS, you have to set an environment variable in your AUTOEXEC.BAT:

SET TIGA=-mC:\TIGA -lC:\TIGA -i0x60
PATH=%PATH%;C:\TIGA

This defines the path(es) to your TIGA modules and libraries as well as the base-IO address, at which your card is communicating. This has to be adjusted to your hardware setting.
Also the base-path to your TIGA files needs to be in the system path.

Then you load your CD and (optionally) GM:

lh C:\TIGA\TIGACD.EXE
lhC:\TIGA\TIGALNK.EXE -LX

The 1st line is clear – if your config allows, you can load the CD into upper-memory. With the 2nd line you can pre-load the GM into the cards RAM and the -LX parameter makes sure it eXecutes right after that. This step is optional, as well programmed TIGA programs check for the GM and if it’s not loaded, they’ll take care of that.

That’s about it. Yay, your TIGA system is up and running 😀 and you’re ready for some action.

The next post shows how to program your TIGA card and do some graphics…

miroHIGHRISC & miroTIGER

Digging deeper into the highRISC

Leave a comment

After 7 years mainly doing research on Transputers and the i860, I had the feeling it’s time to do some more digging into the highRISC card.
If you have read my initial post about the miroHIGHRISC (and the Tiger) you remember the undocumented 20pin socket on the card (pictured in the upper right corner):

HighRiscLeft

Let’s have another look at the “UART port” again:

The pinout (the connector is rotated 90° counter clock-wise):

GND  oo  /WR0
D0   oo  INT2
D1   oo  /RD
D2   oo  /IOSEL
D3   oo  RESET (most likely)
D4   oo  A2
D5   oo  A3
D6   oo  A4
D7   oo  A5
VCC  oo  A23

Reading a bit of the BIOS’ disassembly, I stumbled across routines to talk to an UART.  A very common (D)UART of those days was the SCN2681. If you take a look at this chips specs, they perfectly fit to the signals provided at the HIGRISCs UART-port!

Here’s its pinout with the corresponding pins marked:

 

A2-A5 are used for A0-A3 on the 2681 and the only pin not directly represented is A23 which might be used to decode. Also, it nicely reveals that CPU INT2 is used for the UART.

The LR33000 datasheet tells me that there’s an 4MB IO-area starting at 0x1E000000 reaching up to 0x1EFFFFFF- most likely the 2681 will live there… and the corresponding signal called /IOSEL is available on the UART-port (and will perfectly help as chip-select decoder). Tadaa!

So after the UART we need to get the RX/TX signals to a higher level, i.e. the +/-15V of RS232 – this is the call for our old friend MAX232.

[current bread-board experiments sadly didn’t yield into ‘instant success(tm)’… I’m missing out something – need more time to investigate]

Bootcode / BIOS

The LR330xx CPU also has an /EPSEL EPROM select signal, indicating it’s accessing an EPROM expected to start at 0x1F000000 and ends at 0x1FFFFFFF (4MB right below the IO-area).
Using this knowledge and knowing that the MIPS standard boot-vector is at 0x1FC00000, it’s easy to feed the ROM-dump I did some years ago into the disassembler with the correct start address to do his job.

We need to get an understanding of this bootcode first, so that we can get an idea of “what is where” (e.g. ISA bus, UART etc) and later upload our own code and use those addresses.
Just to stick my head a bit into the clouds, the aim is to first port a then common MIPS monitor-program called ‘PMON’ and use that to run some sort of μLinux. But that’s probably another handful of years ahead…
PMON was a good source of information, because it’s originally written by LSI, supporting all the LSI eval-boards. Lo and behold, some of them had a 2681 UART, too… located at 0xBE000000, which is extensively used in my BIOS disassembly  😉
I have a certain feeling that miro borrowed some design ideas from the LSI Pocket Rocket evaluation board (don’t Google it, it’s a mythic being – if you have documentation, mail me!).

So this is the 2681 memory-map then:

#define BASE_2681 0xbe000000
#define SRA_2681 ((1*4)+BASE_2681) // 0xbe000004 status register 
#define THRA_2681 ((3*4)+BASE_2681) // 0xbe00000C Rx/Tx holding register 
#define ACR_2681 ((4*4)+BASE_2681) // 0xbe000010 Aux contrl. register 
#define ISR_2681 ((5*4)+BASE_2681) // 0xbe000014 interrupt state register 
#define CTU_2681 ((6*4)+BASE_2681) // 0xbe000018 Counter timer upper 
#define CTL_2681 ((7*4)+BASE_2681) // 0xbe00001C counter timer lower 
#define START_2681 ((14*4)+BASE_2681) // 0xbe000038 start timer 
#define STOP_2681 ((15*4)+BASE_2681) // 0xbe00003C stoptimer

Using those addresses we should easily identify the comms routines.

Something happens at 0xBE800000 which seems not UART related. So that’s probably the reason why A23 is available on the connector. That way we can ignore access to that address by OR’ing it with /IOSEL to create a /CS.

The DOS side of things

The tool to load a MIPS executable into the HIGHRISC is called DL.EXE. Loading the test-program prints this to the console:

miroHIGHRISC download program. V 1.00
(c) miro Computer Products AG , Germany

CONFIG: I/O-register-address: 0x368 
CONFIG: DRAM - base-address : 0xD000 
CONFIG: DRAM - size : 8 MB
CONFIG: TIGER - RAM - size : 8 MB

Resetcount = 87340

Loading test.zor
text : start=0x80030000 size=0x52c0
data : start=0x800352c0 size=0x520
bss : start=0x800357e0 size=0x150
entry : 0x800301a0
TIGER comm.address : 0x3ffd00
max_used_address : 0x35930 
real_DRAM : 0x800000 
Heapsize : 0x7CA6D0

test.zor sucessfully downloaded.

This gives us valuable information. The DOS-side uses the IO port 0x368 and has a memory window of 16K from  0xD000 to D3FF.
MIPS programs are loaded to 0x80030000 and the 16K seems to be mapped to 0x003FFD00, just 128K below the 4MB boundary of the LR33k address space.

As usual – this is heavily work-in-progress. So this post will be edited while making any new progress. TBC…

Helios, Misc

ARM eval boards and Helios

1 Comment

     “Every end implies a beginning.”

This post started out as a special Helios article, but given the rarity and historical importance of the used hardware, it’s now somewhere between the worlds of OS and Hardware – and the combination marks the end of an operating system and the launch of an incredibly successful processor family.

Helios is most likely already one of the loneliest OSes on the planet… I estimate about 10-20 active Helios installations of the Transputer version currently running. But the Helios ARM version supposed to run on my VLSI ARM eval boards is probably the only one on planet Earth.

Quick history digression

Talking about lonely… The  eval boards we’re discussing here, the VY86PID family, was what you could buy from VLSI. VLSI  founded  ARM Ltd. together with Acorn and Apple.
So you’re actually looking at the birthplace of your mobile phones processor right now. This is, where it all started!

When you’ve planned to build a computer based on VLSIs range of ARM CPUs back in the days – most notable the ARM6xx, 7xx and ARM7500 series – you got a VY86PID board . And because not many did – mind the Acorn RiscPC and Apple Newton – those boards are rare as hens teeth today. Googling for it will most likely bring you back here 😉
There’s just one good, original source of information left: The page of Art Sobel himself, Hardware Applications Manager for Embedded products at VLSI Technology, father of the boards discussed here.

Last question: “Why VY86PID? That sounds Intel’ish, like the x86 family.”
Well, VLSIs official name for their ARM IC range always started with VL or VY86… so  for example the fist mass-produced CPU, the ARM2, was officially called VL86C010. It’s memory controller was VL86C110 and they used  VY86C610 for the ARM610.  Only with the introduction of their last ARM CPU, they changed it and called the ARM7500 VY27073B…

Hardware

But now, let’s have a look at the eval boards first…

VY86PID 2

This is the earliest implementation of a PID I ever saw and own. Its components are:

  • ARM600 CPU at 30MHz – soldered onto the board
  • 4 SIMM slots for 1-16MB RAM
  • MEMC3 memory controller on a 12MHz bus
  • ‘INTWT’ INTerrupt (With Timer) controller (Maybe a VL86C410 derivative)
  • VL16C552 Serial/Parallel controller serving an on-board connector each
  • 128KB-1MB ROM (jumpers used for setting the size)
  • one ISA compatible expansion slot
  • 4 status LEDs, Reset- and Panic-buttons
  • an empty PLCC68 socket for the FPA10 FPU from GECPlessey
  • edge-connector to connect a ‘logic analyzer probe board’

It’s worth mentioning that both controllers, the MEMC as well as the INTWT were implemented in QuickLogic ‘pASIC’ QL8X12B 1st generation FPGA. That’s about 1000 gate arrays – tiny in today’s measures. That’s interesting as the MEMC was available as commercial ASIC already – but it that could only support 4MB explaining the appended version number “3”.
Also, take note that the PID2 uses an ARM600, not the later widely used 610 (RiscPC, Newton 1xx series). The 600 features support for a floating point co-processor, ARM Ltd. usually used the term floating point accelerator – this was only supported with the ARM600 & 700 and later integrated in the ARM7500FE.

VY86PID3

This is the PID3, sometimes also written PID III – this time it’s processor-independent for ARM610, 710, and 810 CPUs, featuring a connector for a CPU module which is 100% compatible to the ones used in the Acorn RiscPC.
Most parts are similar to the previous PID – even the FPGAs – so these are the notable differences:

  • No CPU on-board – instead it offers a slot
  • 10BaseT Ethernet port (SMC 91C94) with 4 status LEDs
  • the empty PLCC socket was removed

Luckily I got an extensive manual with it, even containing all the schematics. Boy, those were the days, when manuals were real manuals!

vy86pid3b

The PID3 with (dis)connected CPU board (it’s an ARM710 card from Acorn RiscPC)

vy86pid3a

So far for the hardware. Both run a rudimentary monitor program from ROM – so let’s have a look into that…

Software

Out of the box the PIDs run a monitor program called “DEMON”, short for DEbug MONitor.
As with most single board computers (eg. Motorola VME boards) those monitors are more or less command-line BIOSes with some debugging features (read/write memory & registers) and are mainly used to load binaries and start them.

 

The toolchain which came with the eval boards is available here. It even includes a (cross)C-compiler and libs in source!

Helios (so far…)

This was the reason why I bought the boards – getting Helios run on ARM. The original Helios sources which I’m hosting on github also came with a kernel for ARM, specifically the Acorn Archimedes and, well, the PID2…

Historical side note: Why Helios on ARM?

Well,  at the time this port was done it became obvious that the INMOS Transputer wasn’t developing as fast as other CPU families did and so Perihelion, like other INMOS customers,  turned towards alternative architectures.
Also they looked for more profitable market: “The emphasis by this time was to make an embedded real-time system rather than an interactive Unix clone” [Nick Garnett, designer of Helios]
Set-top boxes come to my mind… and later SGS-Thomson was quite successful in that area with their Transputer based ST20 family.

There are 2 supposed ways on getting Helios onto a PID – both using an RS232 connection:

  1. load the kernel through the Helios server (that’s the DOS/Unix terminal tool) which then talks to the DEMON or
  2. Have Helios burned into EPROMs instead of DEMON.

I wasn’t able to get the EPROMs work (binary image here) – or more precisely, connect to the system. It didn’t accept connections from the server, even the readme says so. The LEDs a showing a heartbeat pattern, so I assume the kernel is running – but without a shell connection I can’t tell more.

The alternative way by uploading through the server looked more promising… I got it stable at 38400 baud and using the debug flag (ctrl-shift-c) I could see the bytes flying upwards…

…but then it looses the connection, misses an ACK and then  fails to send the system config.  The server – while successfully initialized – then sits and waits forever  😥

To be continued…

TIGA

TIGA programming

13 Comments

After we talked about the basics of the TIGA standard in the previous post, we’re now  trying to do some TIGA programming… (mind the absence of the word “useful”  😉 )

I can’t stress this enough: Compared to even the earliest 3D accelerators TIGA wasn’t fast. Actually it’s not meant to be a 3D accelerator at all, it’s a 2D accelerator which tried to cope with the slow ISA bus speed. With the arrival of VL-bus and then PCI, TIGA hadn’t had a chance – even with a TMS34082 FPU it reached a max of  160,000 polygons/sec and 25,000 shaded polygons/sec – and there’s no real support for textures. Fun fact: An original PlayStation (1, that is) did 180,000 textured and lighted polygons/sec…
Ah, and before you ask: No, there was no native Linux X11 support ever. There were two X11 servers: MetroLink offered a “stub” which translated X-call on the host to TIGA which ran on the card. And there was a DOS(!) X11 server from AGE Logic. That one ran solely inside the cards RAM, ignored TIGA completely and its speed was comparable to a Sparc 1 or Personal Iris  😕 The upside was, that was also the case on a slow i386/25 which was still usable running several tasks. So a lot of work was offloaded to the TMS340… OTOH you could invest that money in a i486 and a simple ET4000 to get the same responsiveness and got more CPU-Ooomp on top.

Demos

Anyhow, to have a quick start in TIGA programming, let’s do some demos… but before we start, make sure you can tick every point on this list:

  • You’ll need a running DOS (>= v3.2) system
  • Obviously a TIGA graphics card in an (E)ISA slot – VMs won’t take you far here.
  • A successfully loaded CD and GM (what’s that? Read the 1st TIGA post over here!)
  • A decent C compiler – I use Borland C (Turbo C v2 is fine, too) for that
  • The API documentation PDF from TI (aka “Interface Users Guide”)

…and the libraries. Those came in the so-called DDK (Drive Development Kit, download it here), which was meant to develop drivers on the DOS side of things but can also be used to write some code making use of the insane TMS340 powers 😉
This DDK contains some (thin) documentation of how to set-up your compiler and the important libraries as well as the include files.
Just unzip the archive to some place you can remember – I used C:\TIGA on my box.

Setup

There are some things to be done in the Borland/Turbo C IDE before you can compile code with the DDK.

1. Add the directory path-name of where the TIGA include files are located in the Options/Directory menu. e.g.:

Include directories: C:\TURBOC\INCLUDE; C:\TIGA\INCLUDE

2. Add the directory path-name of where the TIGA Application Interface Library files are located in the Options/Directory menu, e.g.:

Library directories: C:\TURBOC\LIB; C:\TIGA\LIBS

3. Specify the TIGA Application Interface library in the Project-Make
file. Simply add a line “AI.LIB” into your Project-Make file. No
directory needs to be specified since the path name was added to the Options/Directory menu as described above.

If you prefer to use the command-line it’s most convenient to add the paths in the call. E.g. building demo.c would result in this call:

tcc -Ic:\tiga\include -Lc:\tiga\libs -ms demo.c ai.lib

The code

Ok, so your dev-system is all set. The TI documentation is pretty good and, well, the only one you can still find these days. So make sure you gave it at least a quick glance-through. By the way, we’re only doing TIGA v2.x stuff… the DDK is not v1.0 compatible.

Have a look at Chapter 3.4. (PDF page 45), it gives a good intro how a basic TIGA application setup looks like. Basically that’s:

  • First check for a Communication Driver (CD) and then open a connection to it
  • Do your thing
  • Properly close the CD
  • exit(0);

The opening and closing of the CD are wrapped into the init_tiga() and term_tiga() functions, so I’ll use those in my samples, too. So here’s a rudimentary example without the aiding functions and #includes needed. It’s drawing a blue, solid filled rectangle, half the size of the screen, centered in the screen:

init_tiga(1);                       /* initialize TIGA*/

get_config(&config);                /* Get info on current mode */
width = config.mode.disp_hres >> 1; /* Width 1/2 screen width */
height = config.mode.disp_vres >> 1; /* Height 1/2 screen height */
xleft = width >> 1;                  /* Center rect in middle */
ytop = height >> 1;                 /* of screen */
set_fcolor(BLUE);                   /* Set foreground color */
fill_rect(width,height,xleft,ytop); /* Fill the rectangle */

term_tiga();                        /* Properly terminate TIGA */

Pretty straightforward, huh?

So without further ado, just do something more impressive: Animation!
Well, don’t wet your pants, it’s just a spinning wire-frame cube, but hey! That was quite something back in 1990 😉 It also shows the usage of extended primitives, i.e. drawing functions which might needed to be loaded onto your TIGA board first (depending on model)
The code is a bit longer, so here’s the ZIP archive, which includes a TurboC project file for your convenience, too.

As soon as I figured out, how to do decent screenshots from the TIGA frambuffer, I’ll post a piccy here.

BGI Driver

Sounds like a strange thing, but might be handy at times if you want to port your brilliant BGI application fast. And well, that’s what the BGI was meant for, right?
The driver was written in 1990 by ‘TSS Rolf Bartz’ and is most likely abandonware…

So this BGI ‘driver’ or better called a wrapper will translate BGI calls into TIGA… of course there are some limitations in speed.
Also out-of-the-box all functions use the BGI maximum of 256 colors but up to the max. resolution your TIGA card provides (well,16384×16384 is the limit ;-)).

That said, there’s a very good readme included (read it!) which not only explains how to use the driver but also tells you more about the enhancements Rolf ingeniously added:

  • There are calls for circles/ellipsoids to bypass the emulation of some calls and use genuine TIGA calls – that should speed up things quite well.
  • FillPoly uses the native TIGA call if there’s enough RAM for a workspace
  • He patched SetWriteMode so that you can use the full 24-bit TIGA color palette.

Again: This is a work-around and should not used for new projects.
If you successfully coded some demos, please let me know!

An odd end…

Finally, I’d like to share some heavy stuff: The Digital Micronics Vivid 24.

Yes, it’s an AMIGA Zorro III card, but at heart it’s TIGA… to the max! TMS34020 40MHz, two (2!) 34082 FPUs can be added, max. 8MB RAM and 16MB(!) VRAM… that’s some serious TI-o-rama. In 1992 this beast costs nearly 3000US$   😯

Apple 68k, DIY Projects

Fixing the Quadra 950 power-supply

4 Comments

One day the power-supply of my beloved Quadra went “bzzzzzt-poof” (sparks flying, smoke rising).
First I was desperate… try to find a Quadra 950 power-supply these days. And if you find one, it’ll cost you the same you’d pay for a complete system… and then you’re still not sure, if it won’t go poof very soon, too.

Then I thought: Hey, why don’t replace the whole thing by something more modern, much cheaper and smaller?!
It’s already been proven with other Mac systems that using a standard PC power-supply (PSU for short) is feasible, so why should a Quadra 950 power-supply be much different?
As there are some descriptions out there – mainly for those “10-pin connectors” (Mac IIcx, vx or PMac family) I thought it might be helpful to have a step-by-step how-to with lots of photos…

We’re interuppting this transmission for a stern word of warning:

Working on/in power supplies is dangerous. I take no responsibility for any damages, injuries or fatal strokes! If you’re unsure if you can do this hack, just don’t do it!

First (obviously), unplug the unit. Leave it unplugged for 15 minutes or so. In most PSUs there are bleeder resistors that will bleed down the stored voltages inside over time BUT THERE ARE NO GUARANTEES!!

When you open the unit, understand that there are two hazards:

  1. Stored high voltage (200V or so) on the “input” side of the unit.
  2. Stored high currents (tens of amps) on the “output” side of the unit.

Either 1 or 2 can be deadly. If you die, it’s social darwinism. You have been warned. 

Dismantle

So for the initial try I pulled a cheap ATX power-supply out of my junk-pile (wife-speak for “basement”) and put it next to the original, humongous Supplyzilla created by Apple. Ok, that should fit in 😉

Opening Supplyzilla is another thing. About 10 screws, a cut in my finger and 30 mins of cursing later I found the reason why I wasn’t able to get the two case-parts apart: Don’t forget to unplug the fan cable :-/
After this you can fold-open the case and have a good view onto huge capacitors, lots of dirt and 1990s tech…

There are two PCBs each mounted to a side of the case. Unscrew and separate them – because mine was dead anyhow (and I wasn’t planning to repair it) separation was easy. Snip!
I wasn’t able to get the external cable-harness leading out of the case. So this was a 2nd snip-snap… I planned to use the original PC cables anyhow. You can reuse the original plug or use the one from the ATX PSU (if it’s a 24pin one).

Here they are… rest in pieces 😛

Fitting room

Next up: The first fitting… even still in its enclosure it would nearly fit two times.
BTW: I like the sticker saying in German “VORSICHT! GEFAHRENZONE!” (Caution, danger-zone!) That’s soooo 80’s Top-Gun 😀

Because we have to modify the ATX PSU, it had to be stripped down, too. Compared to Supplyzilla it’s pretty deserted in there…
Yes, it’s a cheapo one looking at the passive PFC and could have be designed much better, but for the 1st try it’s OK.

2nd fitting making sure all heatsinks are well placed into the airflow, cables close to outlets (the fan will be replaced by a big one, of course).

You will be assimilated…

Next step was a meditational one. Loosening all 24 pins clamped into the ATX plug. I used the “cut staple method”. One to the left, one to the right, push them in, pull the cable… repeat.
Configuration of the Q950 plug will be described further down. I suggest to do this as one of the last steps. For now just tape all loosened pins together to save them from bending.

Having the preparations done, it was on to the workshop drilling some holes and cutting screw threads (optional but nicer than holes and nuts)…

…to have a proper seating for the stand-offs. We don’t want the PCB touch the case, don’t we?

All fits nicely. The PFC screwed to the case like in its original habitat – ugly, but will do for now.

The noise filter was directly soldered to the power-out plug. Again ugly, unprofessional but OK for a try.

So the filter went into the case and unneeded cables like 3V, were shortended and kept inside the power-supply.

Connecting the dots

Now for the plug-configuration. All documentation I’ve found on the web were wrong – dead-wrong, even leading to drama…
So this is the correct pinout for Quadra 900/950’s:

Having this, the mapping from the “Mac-plug” to your ATX-PSUs cables is pretty straightforward:

  • Red (5 volts) stays red
  • Black (Ground) stays black
  • Yellow (+12V) also stays that way, too
  • Orange (-12) is blue in your ATX-PSU
  • Blue (5V standby) is the violet cable in ATX-PSUs
  • White is mostly unused on ATX-PSUs – we will recycle that cable for PFW…

As for 5V/GND wires don’t worry if your ATX PSU doesn’t offer enough of them (10 each). Mine just had five 5V wires, so I populated every 2nd slot in the plug.

Killing me softly

Finally the ‘circuit’ for using the Quadras soft-power feature had to be implemented – a simple rocker-switch connecting the green (Pwr_on) wire to GND would do, but this is just so below the mighty Quadras grandeur.
I opted for the very simple, more reasonable solution using a NPN-resistor… even a 74LS04 is an overkill in this case. Just my 2ct, though.

This is the schematic, nothing spectacular:

Yeah, the symbols for the resistors are European, that’s because… well, I am European 😉 As for the transistor use any NPN you can get easily. E.g. BC547 or BC549 (again, European numbering scheme, you’ll have to figure out JEDEC names if needed).

And here’s the PSU before its going to be closed and put back into my Q950.
Pink box: The soft-power ‘circuit’ (yeah, I was too lazy to create a PCB for a transistor and two resistors).
Green box: Unneeded cables been cut (3V, extra 12V, pwr_good).

Everything else was routed outside (All 5V/GND, +12V, -12V, 5V_tickle and the white cable was cut and reused for PFW.

Hints: DON’T use the GND from fan-connectors! They might be modulated to control the fan speed and other wired things. Better use one of the e.g. unused 12V cable-pairs.
Check everything before closing the case – Again CAUTION!!! High voltage. You touch, you die!!

Woo-hoo! Lady Quadra works again!

Outlook

That was a cheap fix… about $5 in parts if you have to buy a used ATX PSU. To make things easier and look more professional I plan to design a small PCB which fits right where one of the original PSU PCBs sat, providing the 4 drive connectors (4-pin) so that you can keep using the original drive power-cables. Also I plan to add:

  • the soft-power circuit
  • a temperature fan speed controller
  • (optional) internal 5¼” power-connectors for solder-free connection to the external 4pin connectors.
MIPS, RS2030, workstation

The MIPS RS2030

1 Comment

Intro: The sleeping beauty

Well, the MIPS RS2030 isn’t really a beauty – but it slept quite a while in my basement. Actually, it’s a mediocre UNIX workstation at best… but there are many things about it, making it a special piece of my collection – and as an returning reader of GeekDot you may know I have a soft spot for those whacky things from back then… and as often with my posts, this one will be the most detailed you’ll be able to find. The RS2030 is yet another lonely system.
Well, if you look like this, you’re not the hottest thing in the Workstation-Discotheque 😉

First things first

MIPS… Even if you have just a dim knowledge about processor history, this name will ring a bell… Founded in 1982 MIPS created the first commercially available RISC CPU and until 1992, they were system manufacturers, too.
The RS2030 had many “firsts”: It was one of their first models, featuring their first CPU, the R2000, and somewhat paved their way into the market while immediately hurting MIPS’ reputation… more about that later. And last but not least, the used OS was one of the first 32-bit operating systems (1985) for RISC-based workstation-class computers.

So here are the specs:

  • Insane 12 (VAX)MIPS squeezed out of an 16.6MHz R2000 CPU and R2010 FPU. 32KB external Cache should speed things up a bit…
  • Up to 16MB (yes, that’s the max) RAM
  • 10Mbps ethernet… that’s 10base2 or an AUI transceiver.
  • 4MB/s synchronous SCSI interface (internal space for one 3.5″ HD)
  • Two RS232 ports controlled by an NEC V50.
  • Optional monochrome or color frame-buffer
  • Optional 3.5″ floppy drive

Just for the record: There was a 2nd model called RC2030, which only differed by not having the frame-buffer. It was sold as server… that’s why the put the “C” in the name. Errr, no, it’s… not… logical. So I’ll forget about this and move on.

The official brochure pictured all these parts like this:

Nice, but missing the power-supply and stuff… in reality, my RS2030 looks like this from the top:

Yeah, I’m missing the the hard-drive carrier – but the same goes for the front bezel, so what the heck… OTOH I have the mighty color frame-buffer, which you can see to the right of the huge power-supply in the middle. It is capable of 1280x1024x8bits/pixel at 60Hz. Here it is in more detail:

Here’s my mainboard having the PSU and frame-buffer removed, revealing the glorious R2000 and his math-bro’ R2010 as well as the V50 “I/O processor” and 4 mysterious MIPS custom chips :

Right behind where the frame-buffer sat, above the CPU/FPU you’ll find the L2 caches and RAM slots. These are SIPP modules and the maximum supported are 16x1MB.
Back in 1989 that was many… not much, but enough for a serious workstation:

Looking closely you’ll notice the cut cables for the 2nd fan (wasn’t me!). A small but very loud one meant to cool the RAM and most important the CPU/FPU underneath the frame-buffer.
Because I currently run the RS2030 without lid, it’s OK. But after some hours it gets quite hot in that region.

To the left of the power-supply (which has another very loud fan) are supposed two carriers for the hard-drive and the floppy-drive. Both were absent when I got this little beast.
Underneath the drives are the ethernet and SCSI controllers as well as the 4 EPROMs containing the “BIOS”, aka monitor.
Like all workstations back then, the RS2030 boots into a monitor, a basic software which gives you some means of setup and options to boot from HD, tape or network. More about this in the next chapter about setting things up.

To round things up, here’s the back side – connectors are from left-to-right:
Keyboard (DIN), 10base2 & AUI ethernet, SCSI, one parallel, two serial connectors and on top the frame-buffer. Mind the uncommon “0W3” RGB connector.

The OS with the many names

Finally, the RS2030 -like all MIPS workstations- ran a strange flavour of UNIX called UMIPS or MIPS OS or RISC/os or RISCos (not to be confused with Acorn Ltd.’s RiscOS)… all tree names/notations are used randomly across documents and mails from those times. So Googling stuff is a drag, 99% of the hits are Acorns RiscOS pages.
It seems MIPS’ operating system started out as UMIPS (UnixMIPS) and settled to RISCos around 1990.
As said, in 1992 MIPS gave up making computers… and was sold to Silicon Graphics (SGI). And playing around with early IRIX versions you smell RISCos all over the place – it’s definitely the mother (or father) of IRIX.

Anyhow, like other Unices of those times, RISCos is hard to get used to it as it misses all those comfortable things we got used to in these Linux days. No bash, no editor but vi etc… To make things short, here’s the Wikipedia roundup:
RISC/os was based largely on UNIX System V with additions from 4.3BSD UNIX, ported to the MIPS architecture. It was a “dual-universe” operating system, meaning that it had separate, switchable runtime environments providing compatibility with either System V Release 3 or 4.3BSD.

Rant, rant, rant…

As said in the beginning, the RS2030 wasn’t quite the showpiece for MIPS. During my research I came across many disgruntled posts about this and other MIPS machine(s).
It actually seems that the RS2030 wasn’t even designed by MIPS but taken over from some other company (my assumption is ‘Integrated Solutions Inc.’ given the marking on the frame-buffer) to fill a gap. Here’s the gist featuring replies by someone who obviously worked for MIPS back then:

>>Between the sloppy I/O implementation (the RS2030 was designed by a
>>now-defunct-or-nearly-so workstation company, whose design Mips had to finish
>>to allow the delivery on a large contract; the bozos who did the box used an
>>off-the-shelf NEC V50 chip for I/O and programmed it poorly, causing lame
>>serial and SCSI performance where simply using the R2000 would have worked
>>better), the lack of expandability and the proprietary memory modules…

The options at the time were:
a) Walk away from a deal for a few thousand systems, a large percentage at the time of Mips’ total base
b) Manufacture only the few thousand systems, and make little or no money on each because of economy-of-scale issues
c) Build and announce the 2030, and keep going on the next generation (albeit somewhat delayed)

(a) and (b) would have resulted in no Mips workstation product at all
that year, which would have been dramatically worse for the company.
The strategic direction at the time was to expect most serial i/o to
come in from terminal servers (this was subsequently modified somewhat).
In addition, issues of SCSI performance did not become apparent and reproduceable from quite some time after product launch.

>Surely MIPS could at least provide new ROMs for the V50? Or did the
>bozos solder them in?
There are some reliability fixes available. As for performance, let’s
face it: nobody’s going to spend money to improve the performance of a
system, at no return, years after it has been dropped from the product
line.

Wow, so it was deliver something mediocre and move-on quickly to create something better. IMHO not the best way to build a good reputation.
This probably led to comments like this:

Unfortunately, computers made by MIPS Co. were ill-engineered products. They were error-prone. From my limited experiences, they easily got broken. We had many broken RC2030s (early times RISC desktop with sloooooow R2000, codenamed “Jupiter”) and many broken RC3230s.
We stock them unwillingly and dumped eventually with disappointments.

Does this make me turning away from this poor little, mediocre thing. Not a bit! It’s an important piece of IT history – and because this is GeekDot, I will make it work for its money.

So follow me to the next chapter: RC2030 – The resurrection.

RS2030

MIPS RS2030 – the resurrection

2 Comments

As mentioned in the first MIPS RS2030 post, I’ve got mine off ePay around 2004 and after some testing its life was about slowly moving through my basement waiting for it resurrection…

Hardware

The long way into the light

So, in 2004 the RS2030 wasn’t in the best condition: No front bezel, no hard-drive and a flakey DALLAS clock-chip. There were 8MB of SIPP modules plugged in and luckily it came with the original keyboard, a monitor cable and two QIC tapes from 1989 containing RISCos 4.10.
I fiddled around with it for a bit, still having a 21″ CRT on my desk, happily connecting to the BNC cable and the tapes were still readable but I wasn’t able to get things booting without a tiny bit of documentation. At least I added 8 more 1MB SIPPs for small money to fill it to the brim.

This changed 2012, when I got in contact with Julien Noël, who ran no-l.org (wayback-machine link) which pretty well described how to install RISCos. Well, he had a MIPS Magnum 4000 and used a bootp() server, but it described a lot of things I was desperately needing for my resurrection.
Some mails flew back and forth, a BNC-to-VGA adapter was build and little RS2030 saw some daylight again. Sadly my QIC tape-drive disintegrated over the last years and its pressure rollers turned into sticky goo – and I figured this out, when the goo slowly crawled into my precious tapes. Yikes!  😥
I cleaned the tapes as good as possible and everything went back into the darkness of “Zee Vault™” again. I think it was the next month, when Julian sent me a tarball containing RISCos 4.52 tape images. I saved them in a safe place and moved on…

Now or never!

This year (2018) I had more time at hand than usual and plenty of it went into some of my Macs and a comparably vintage SGI Personal IRIS.
During my fight practicing with installing IRIX 5.3 onto a clean drive I felt like prepared for an even older MIPS box. This time it had to be done! I got myself a new-old-stock QIC drive, 2 still sealed QIC-150 tapes and moved everything in front of my LG TFT display, which is able to handle sync-on-green signals.
Let’s check if it’s still alive at all – flick the switch, a noisy fan starts blowing and ~45sec and some beeps later the RS2030 is back in business:

Yes, the console looks strange. It just uses 2/3 of the screen and has a frame around it. The green tint is due to my way too long video cable.

Ok, there are many “FAILED” messages but it found all RAM and the ROM monitor (aka BIOS) prompt is happily blinking. Woohoo! I left it running/idling like this for a while just to make sure the power-supply stays stable.
After half an hour I moved on. The fails of the NVRAM and Counter/Timer test showed that the DALLAS DS1287 clock-chip finally went flat. The failed SCSI Master Test gave me a bigger shiver…

The clock-chip was quickly removed, the ram content saved, cut-open and enhanced with an external 3V button cell. It’s a common drill for all vintage hardware enthusiasts. I think this is the mother of all clock-chip modding posts.
Luckily the SCSI Master Test went away with the modded DS1287. Phew… while I had my beloved EPROM programmer at hand, I also saved the four 27c512 EPROMs and some Googling actually brought up a  more recent version than mine: v4.30 from Jul. 1989 vs. 4.32 from Jan.1991. You can download the binary images here. The most useful difference I found is the added ‘sprobe‘ command, listing all SCSI devices found.

There’s a nice thing all computers should (still) have. A 7-segment display next to the EPROMs giving you some idea of the systems status while booting. Also pictured the modded clockchip.

I found an older post of somebody desperately looking for a keyboard. While it looks like an XT-keyboard and weights like an IBM model M, it seems to be somewhat special. As said, I’m lucky to gave gotten mine together with the RC2030.

This was the last step: Check the drives. Find a proper SCSI hard-drive and externally connect my new tape-drive.
Having learned from my “tape disaster” in 2012 I carefully checked my tapes before putting them into my precious new tape-drive. And yes, they had a problem: The the slack retention belt was worn out and lost its elasticity…. resulting in, well, slack. To fix this you need a new(er) tape as ‘belt-donor’ and then do some tape-DJ’ing.

As I wasn’t able to find 2 reliable donor tapes, I decided to not dump the RISCos 4.10 tapes and move on…

Software

It’s getting serious: I took my two best blank QIC tapes and copied the RISCos 4.52 tape-images onto them using Linux on my retro-server (which one day deserves a post for itself). That was the easy part…

Let the game begin

Using Juliens recipe the initial boot from the tapes went smooth. Well, at least for 90’s measurement. Times were different, so it’s definitely not slap in some DVD/USB-stick and let the BIOS do the rest – choose some packages to be installed and baaam!, OS installed.
This is the drill (theoretically):

  • Use the minimal boot command of the ROM Monitor to boot a stand-alone shell (‘sash‘) from the 3rd block of the tape.
  • This sash knows filesystems, so you can use it to temporarily copy a mini-root system from tape block #4 into the swap-partition
  • Then load the RISCos kernel from tape telling him where to find the mini-root filesystem.
  • Finally this kernel loads a full-blown shell which then is able to execute the install script (‘inst’).

But if you’re not owning an original hard-drive you have to format/partition yours first. In this case you have to “boot” the MIPS format tool. It’s the grandfather of SGI IRIX’ fx, just even more basic.
Very basic. And confusing. Out of the box, it “knows” 13 hard-drive models, of which 8 aren’t even SCSI. And all of them are very, very, very obsolete. Here’s the printout:

Option #13 gave me some hope… “other” means you can add your own drive – if you have these specs at hand:

Well, I guess you don’t. Neither did I. So I wasted spent 2 days to figure out how to get a partition scheme and whatever else is needed by RISCos onto my disk.
To spare you this experience, bad ideas are:

  • Use the IRIX’ fx tool
  • Use gParted
  • experiment with those wiredo specs

The solution is -as most of the time- simple. Choose some SCSI disk from the menu, answer all questions but deny formatting, so it will write all partitions and the so-called volume header (a partition containing sash and stuff). The tool ‘prtvtoc’ (PRinT Volume Table Of Content) will then show you something like this:

After that you can boot sash, miniroot und finally start ‘inst’. Again a very simple installation tool which creates the EFS filesystem and copies all packages onto the hard-drive. Time for a break… tapes are slow and it’ll take ~2hrs.

So tonight I’m gonna party like it’s nineteen ninety-nine

When that’s done, you have to reboot and your MIPS will boot like a proper workstation… back in the days. It takes some minutes and it greets you with a simple ‘sh’ prompt.

To make your life a bit easier quickly enter ‘chsh’ to switch into ‘csh’ which is a bit more modern.
From there have fun exploring your new, old system. Ah, and don’t forget: RISCos is not year 2000 aware. So set the clock to something before December 1999 😉

Don’t miss the next chapter: Home improvement… making things a bit more convenient.

68000, Apple 68k, Carrera040, Hardware

Carrera 040 in an SE/30

4 Comments

As promised in my blog entry nearly one year ago, here’s the (monster) post about this project.

Background

Boy, what a ride! This is definitely my most complex (and still ongoing finished) software reverse engineering stunt ever!!
When starting this venture I was a blue-eyed Mac user and just-for-fun programmer and never imagined to learn this much about those machines I loved since 1985… by the way of a very nice guy I was finally able to get an SE/30. Immediately I thought of accelerating the cutie.
This first post will give you an insight about the workflow, hardware and software used. Following posts will then guide you deep into the code…

The MicroMac Carrera040

For many years I had a Carrera040 (or C040 for short)  – a Motorola 68040 accelerator for Apple Macintoshes – in my locker which I bought in wise foresight without even owning a Mac to plug it in. The C040 I got was meant for usage in a Macintosh IIci, plugged into its L2 cache-slot. That said, using special adapters, the C040 could also be used in other 68030 Macs like the IIx, IIcx, IIsi, IIvi/vx and the LC/LC II.

Is the Carrera a Speedster?

What’s this question about? Well, you might also have come about notions of an accelerator called the ‘Mobius Speedster‘ which is pretty similar to the C040.
Well, it is and my wild assumption is that at one point MicroMac bought the design from Mobius. There’s even a leftover in the C040’s ReadMe:
“Applications that do not work with Quadra or Centris Macs are not likely to work on ‘040 accelerators, including the Carrera040. Generally, these incompatibilities are limited to the ‘040’s copy-back cache, or FAST mode on the Speedster.“

So when I had my glorious SE/30 sitting on my desk it immediately came to my mind to make this card running in it.
You have to know, that the SE/30 is a somewhat shrinked-down version of a Mac IIx which again is pretty close to the IIci – and there was an adapter in existence to use another popular IIci accelerator in an SE/30 (Daystar Turbo 040). But it’s very rare and there’s next to no chance to find one. Anyhow, it’s doable, so I was hooked.
I stumbled across a cry for help in the 68kmla forum, a user owning such an adapter and a C040 tried to get it running in his SE/30… to no avail. So while still not having the proper adapter (yet) I thought “why not start looking into the driver while waiting for the hardware?”.
So the journey started…

MacNosy – a users nightmare, a hackers heaven.

My natural reflex is to reach deep into my tool-bag, get out my favorite disassembler/hex-viewer and start digging through its output. But for System 7 my bag was empty. Is there any disassembler at all?
While the good thing is, that most software packages which cost plenty of $$$ back then are abandonware today, the bad thing is that many are undocumented and unsupported. After some research it became clear that MacNosy was and still is the best m68k MacOS disassembler around.

Boy, this disassembler is powerful! But it seems to be written by Steve Jasic for, well, Steve Jasic. I know that kind of tools – I’ve written some of those… and never showed it to anybody because it was, erm, special. Prepare yourself for “everything will be different than you’ll expect it”. Steve gave a sh!# about UI or keyboard conventions. Cope with it.

Luckily there’s a very good review and some sort of documentation can be found here.

Same but different – which is where?

Does ‘A5-world’ ring a bell to you? No? Don’t worry, it was the same for me, even I am using Macs for a long time.
Even it’s an 68k system, there are so many things done different than e.g. in Amiga OS or Ataris TOS – so you have to learn a lot.

Because it would absolutely bloat this post, I will link to external pages explaining the used term. So watch for the first mentioning, it’ll be a URL…

The provided Carrera040 “drivers” consist of an INIT/Extension (“Startup Carrera”) and a Control Panel (“Carrera 040 1.8”).
In the provided readme file there’s the line “With version 1.8 we have included an extension which ensures the Carrera040 code to load very early in the boot process.”

And indeed, the INIT code does not do much more than loading a specific resource from the control panels resource-fork.
So I concentrated on the control panel (CP for short). Using ResEdit, you’ll find the main detection and control-code in its resource fork called “SPDR’ (SPeedster DRiver, got it?).
While working through the code, commenting whatever I immediately understood (which wasn’t much in the beginning), I stumbled over several things you should also have an idea about before reading the disassembly in the coming chapters – so here’s a growing reading list:

Macsbug reloaded

During all that code-gazing, head-scratching and learning-new-things-every-day great luck struck and I virtually-met ‘Bolle‘. A guy who created a clone of the mystical PDS-to-IIci-slot-adapter. Woohoo!

Even those 120pin DIN connectors are incredibly hard to find.

So after spending some Euros I was finally able to  jump into the ‘the real thing’ and try my patches in-vivo, or watch the code being executed. Thanks again, Bolle!

My C040 cramped into my beloved SE/30

The drill

The weapon-of-choice for watching code run is definitely Macsbug, the official debugger from Motorola, heavily modified by Apple through all the years until MacOS 9.2.
Back in the days my contact with Macsbug was very brief. When a program ‘bombed’, I’ve entered “g” (for Go) and hoped the system will somewhat heal and keeps running…

Ok, now I had to be somewhat more serious – and my skills had improved over the last 20 years, so my routine turned into single-stepping and tracing through the code, skip certain instructions which might kill the code, watching all the registers and most important and watch how the Carrera “driver” behaves in an SE/30 vs. IIci.
I even created some macros (which have to saved into Macsbug own resource-fork!) and started an endless try-and-crash drill.

The working drill is tedious: You step through the instructions, while following your steps in the disassembled source, to the point where it crashes. Remember/note the point (address) where it crashed and try again.
This means you have to manually trace closer to “the edge” but try not to fall off the cliff. And when you did – and I did many times – rinse & repeat.
Sometimes you can ‘skip’ complete function calls containing hundreds of instructions (called ‘Trace’), sometimes you have to sit-through (i.e. single-step) a very, very, very long loop just to be sure it works 100%.

The next post/chapters will finally dive into the control panels code.
While it’s all about this specific ‘driver’ I’m sure it’ll help everybody who starts the adventure of understanding pretty low-level 68k Macintosh code.

That said, in Dec. 2019, continuously working with Bolle, we came to the conclusion it has to be a hardware problem and Bolle was able to prove this and most importantly found a way to fix it.
There will be a 4th and final post concluding all of our findings.

 

Atari, Hardware, Systems

Atari 2080STF – a prototype?

2 Comments

I bought this Atari 2080STF in 2003 and stored it as-is in my collection. The ST being my first 16bit machine I thought it could be a good point in time to un-dust and resurrect it 16 years later.

Atari 2080STF… 2080??  Yes, that’s true. There are different stories out there about their prototype/fake status.
As far as I see, there are two 2080STF versions out there:

  • The “Yugoslavian Version”
  • My Prototype

The Yugoslavian 2080STF is a pretty simple re-batching of a 1040ST which was upped to 2MB RAM and sold by a company called Mladinska Knjiga.

My 2080STF is different. In contrast to the Yugoslavian it features a proper, 3d embossed label, not some flat DIY thing.
Instead of some serial# printing looking like made with a children-stamping kit it says this:

MarkeTTing Sample… should it have been an omen?

Marketting? Well… somebody’s been in a hurry or not native to English. Anyhow, the label shows the same quality as those used with Ataris produced in greater numbers. That said, there’s no serial number and the model ist just a paper-sticker.

Next unique thing is the floppy cut-out on the right side. It’s the same square one like on a Falcon, but the plastics are in the proper ST grey. Mhhhh….

Looks Falcon’ish, but it isn’t…

Finally the mainboard: Yes, it’s very 1040STFM without the M(odulator) part. But then it features a yet undocumented issue number of C100059, production week 8813. And mind the installed Blitter at the lower right.

Lots of ugly mods to be removed ASAP! But I’ll keep that IDE controller sitting on top of the 68k.

So what do we got here? Not having any matching-numbers system like in the vintage car world, we can only guess…
It might be a real “Marketing Sample” made for a planned pimp-up of the 1040 family. On the other hand it also can be a nicely composed Frankenstein system made of parts e.g. being sold at Ataris sell-out in 1995.
Given the sum of the unique parts being used, I opt for the “real marketing sample”, probably being put together using available parts and meant for checking out, if there’s a demand/market for such model(s)… and history taught us that there wasn’t.

Anyhow, I pulled out the crap which had been “installed” over the previous years…

Boy, look at that IDE “cable adaptor”… a soldering nightmare. And who needs more than 19200 baud anyhow?

So the noisy 2.5″ 80MB harddrive got replaced by a CF-Card which nicely fits where the modulator would be, if this would be a STFM.
Additionally I 3D-printed a mounting thing for it which you can download here.
Finally, the build-in Hard & Software TOS-Card II 2.06 (that’s a long product name!) got fixed so it actually can switch between the on-board TOS and the 2.06 sitting on the card.

When everything’s done, it looks nice and tidy down there:

Yeah, that’s a 4MB card… just for testing. I took a “spliced” IDE cable I made ages ago – does a good job to squeeze underneath the keyboard.

So I think I’m all set for some pure 8MHz 68000 fun… oh boy, did I love those days.

Atari, DIY Projects, DIY Transputer interfacing

ATW800 Farmcard

4 Comments

Sometimes a man has to do what a man has to do 😉 And this time it got to be an ATW800 Farmcard.
A what? ATW800 stands for ATARI Transputer Workstation – basically an Atari ST and a Transputer subsystem in a tower case (just about 250 were build and sold) and looks like this:

Atw front.jpg

Background

Even I still do not own an ATARI Transputer Workstation (yet), I “know” it from the very first presentation when working at the 1988 CeBIT Atari booth back then. The initial demo version used a standard Atari Mega-ST connected to a blunt Atari-PC3 case which housed the Transputer stuff… and the whole thing ran the Helios Operation System about which you can read quite a lot in this GeekDot chapter. Well, actually that was no wonder given that Perihelion Ltd. was not only the creator of Helios but also the birthplace of the ATW800 (Called ABAQ in the early stages).

The final version (the one in the tower case) used so-called Farmcards to expand the number of Transputers available to the system. A Farmcard featured 4 fixed Transputers (T425 or T800) with 1MB of RAM each. Here’s a piccy (click to zoom):

That might be plenty back then, but even in those days progress was made quickly and INMOS presented their TRAM Modules at nearly the same time… and these give you so much more flexibility and also save space. Actually, if you closely read the marketing material from Perihelion you will spot the announcement of a TRAM Farmcard. It just never made it…

I did it my way…

So it was just a question of time until I start to design a TRAM-Farmcard. After many years of unsuccessfully hunting an ATW which is for sale, I at least met shock__ (atari-home.de forum) a lucky ATW800 owner who was happy to help. So using the available documentation and the data provided by shock__ I created this:

Features

So what gives? Well, first of all, there aren’t any original Farmcards available anymore. Even if there were, they’re pretty limited. One Megabyte is enough for a computing slave using pure OCCAM but if you’re using Helios, 300k will already ate up by its core demons. Then there’s space for just 4 Transputers, not many given the size of the card.
That said here’s what this new Farmcard provides:

  • 8 TRAM slots. Can be used for anything. Computing, SCSI, Ethernet or graphics TRAMs. Be it size-1 to 8. There were many, many cool modules available. Today you can at least use my AM-B404 TRAM, a super-fast 2MB size-1 compute TRAM.
    This would mean twice the CPU oomp, and double the RAM.
  • Freely programmable Altera EPM7032/64 CPLD. It will implement Perihelions diagnostic-bus, meant for controlling each Transputer separately. Updates can be done in-field.
  • An external RS422-link. Using differential transceivers (26LS31/32) one can connect external Transputer networks over a distance up to 20-30 meters (vs. 30cm in pure TTL).
  • 4 layer PCB design giving stable power distribution throughout the board. Still, simple layout, easy to patch and only through-hole parts being used to make building as easy as possible.
  • 2 LEDs. Just say’in…

Because of the added Transputer-Slots the network topology looks a bit different than is used to be on the original Farmcard.
This is the “old one”, a simple square, each Transputer has two free links being available at the edge connectors J1-J8:

And this is how the 8 slots are connected:

Now each Transputer has just one link connected to the edge-connectors. Slot 7 uses link-3 to connect to the optional external RS422 connector.

Free as free beer!

Because there are probably only two handful of ATW800 owners out there, I made the schematics freely available here under the GPL license. But to make things clear:
This is untested stuff! The card is huge. It is not cheap to have it manufactured. The best price for 10 PCBs I was able to find was about $250.

The hard part

While the cards design was pretty straightforward the “firmware” of the CPLD will be a different beast. As said, Perihelion used a proprietary bus called “diagnostic bus” (DBus) – a two wire bus used to address all or just a single Transputer in a network to either reset or put him into the so-called analyze-state to do some post-mortem debugging. Pretty advanced stuff given that standard Transputer networks simply used a global reset.

Luckily the DBus is documented in the (short) Farmcard Manual (p.8-10). So we have a rough idea what’s going to be expected:

The DBus is daisy-chained through all Farmcards on the slots as well as on the edge-connectors J9 & J10 (in/out). Because I hadn’t had an original Farmcard at hand I wasn’t sure which of these signals are needed to be controlled by the CPLD. So I connected them all using all available I/O ports.  This is the pinout:

pin function
04 5_ANA
05 1_RES
06 1_ANA
08 LED1 (Error)
09 L_IN
11 L_OUT
12 FAST_IN
14 FAST_OUT
16 SLOW_IN
17 SLOW_OUT
18 GLOBAL_RESET_IN
19 GLOBAL_RESET_OUT
20 T_ERR_IN
21 T_ERR_OUT
24 LED2 (Opt)
25 4_ANA
26 4_RES
27 2_ANA
28 2_RES
29 3_ANA
31 3_RES
33 7_ANA
34 7_RES
36 6_ANA
37 6_RES
39 0_ANA
40 0_RES
41 5_RES

So, this is it for now… it’s an ongoing project and it depends on you how fast progress will be made.

  • Do you own an ATW800? We’re looking for brave testers!
  • Are you a VHDL hero? Grab the manual and do your thing!
  • Transputer nut? Feel free to check the schematic… I’m not swearing it’s 100% bug-free.

To be continued…