Your First Computer versus Your REAL First Computer

Episode #45 of the “Retrocomputing Round Table” podcast posed an interesting topic:

The first physical computer you used versus your spiritual/emotional first computer… and this can be split into “owned” verus “had access to” to make upto two topics.

First Physical:

The first physical computer I had to use was a Research Machines 380Z at school in 1980. These things seemed to have leeched their way into a huge number of high schools in the UK (I keep running into people that remember them fondly), but had absolutely *zero* presence outside the UK. And as at most schools, there was just the one unit, which had to be timeshared amongst the entire computer studies class. There was quite a black market trading “time at the console” in return for lunch tickets, sweets, do-your-homework-for-you and so on!

The really neat feature of the RM380Z, for it’s time, was the bitmapped/vector graphics capability – once trusted as “senior” class members, we got plenty of console-time playing Lunar Lander in glorious high-res monochrome graphics (oops, I mean plenty of time completing educational programming project work). The school also had a CBM PET of course, but we didn’t pay it much attention. Around that time, I did also muck about with a friends personal ZX80 (yeah, he actually *owned* a computer – WOW).

Spiritual Computing Home:

My emotionally first computer was another I didn’t own – at my first job working for a software house in 1983, we used British-designed and manufacturered Integrated Micro Products’ IMP-68 computers with dumb ASCII terminals.

The IMP-68 was an odd beast: an S100 bus 8-slot backplane with a custom 8MHz 68K CPU board, custom memory boards, a Cromemco (remember them?) C3 floppy controller, a dAVID Konan Junior MFM disk controller, and a 6Mb, 12Mb or trully massive 20Mb hard-disk drive – running a UNIX V6 clone (Idris) that didn’t require memory-translation hardware (unlike AT&T UNIX). Idris could take advantage of an MMU if present, but did not absolutely require one. The IMP-68 could also run a ported version of AT&T UNIX v7, thanks to work done by Uniplus.

More wierdness, the custom MMU boards that slotted into the 4MHz backplane were connected to the CPU board by a dedicated 8MHz ribbon-cable: a “local bus” some 10 years before the PC world went “local bus” crazy.

Mind you, there were risks – the internal unshielded power-supply unit included a *house-brick-size* pair of eletrolytic capacitors. Considering that tiny 0.5″ capacitors can be decidedly harmful to humans, these suckers could have turned you into a humanburger if you weren’t *very* careful with your fingers and screwdriver! They even *looked* threatening.

The Recovery and Repair Adventure:

Eventually, when the company had no further use for the IMP-68s, a colleague and I took ownership of the two (mostly) surviving units, and managed to locate another unused one in London. I flew across the water to London to salvage components from it, and carried them back in my luggage – including a 20Mb 5.25-inch full-height disk drive which airport security took an immediate dislike to – a hermetically sealed large metal box with elecronic components on the base – they thought it was a bomb!

After a considerable amount of time haggling, and eventually borrowing a mains-to-5VDC adaptor from another passenger, and a bit of custom on-the-fly wiring, I managed to demonstrate it flashing it’s LEDs to the security personnel, at which point they lost interest in it – either their bomb-identification procedures weren’t too clever, or I had bored them into submission :-)

But by this time the airport gate for my flight home had closed, ouch!

Fortunately, I managed to persuade one of the airline personnel (who just happened to be wandering past on their way to a different gate) to eyeball my boarding-card and get me onto my flight, but I had to travel out to the plane on the last of the baggage cars, sitting on top of my suitcase full of computer parts with the wind blowing in my hair. The steward had to reopen the passenger door to let me onto the plane!

End of the story – we managed to restore two IMP-68s into fully-working condition using the components I had brought back.

Afterwards:

Around 1990, we were asked by the British Museum if we could donate one to their collection, as the very first British-designed and British-manufactured UNIX system. I don’t know if it is still in their collection…

As you may imagine, after all that shenannigans, I still have a place in my heart for the slightly wacky IMP-68.

Your Turn:

If you want to let others know the distinction (if any) between your first physical-versus-spiritual computers, and the reasons, go add your comment to the “First computer vrs first REAL computers” thread in the “Retro Podcasts” section of the Vintage Computer Forums.

Return of the SneakerNet

It’s funny how occasionally you find a need for technologies that you thought you had seen the last of…

I have been developing a small UNIX webserver on a SPARCstation-10, and wanted to portability-check it on an x86 Solaris 8 system. The only such system I had “pre-installed” was a Toshiba Satellite 4000CDT laptop from with a broken CDROM drive and no built-in Ethernet port. Under Solaris 8, the only Ethernet interfaces that work in that particular machine are the 3Com 3C589 or 3C574 PCMCIA cards, which I have misplaced (doh!).

So how to get the source files from the SS10 onto the laptop? I could have FTP-ed the files from the SS10 over the network to another PC that has a USB port, and then transferred from there via a USB memory stick; except that the other PC around was switched off and packed away prior to some planned home decorating (painting the wall it occupied).

What to do? As the saying goes, “if all else fails, use brute force”, preferably mechanical.

Fortunately for me, both the SS10 and the laptop had a long-forgotten 3.5-inch diskette drive built in, so a quick rummage in my stash of bits to turn up an actual (rather dusty) diskette solved the problem – on the SS10, format the diskette as a DOS volume, copy the files onto the diskette, then physically carry the diskette over to the laptop and copy the files off it onto the laptop hard drive. Success!

Overall, not as fast as 100Mb/sec Ethernet, but quick enough for me this time. This particular method of transferring files used to be the primary way of doing so, before networks, CDROM drives, and so on existed.

Traipsing around with a diskette in hand: SneakerNet, gotta love it!

PS: I have not forgotten the other “veteran” 1970s method involving serial-ports and related file-transfer protocols (XMODEM, ZMODEM, Kermit, UUCP, or even raw ascii “transmit/capture-and-hope-for-the-best”). In this case, that would have been even slower to setup and use. If either of those diskette drives breaks, I might just find myself having to use such methods at some point.

RC 2013 WW – The Final Episode

Project: The Sound of Violence.

Well, it’s been a lot of “fun”. The hardware/software development was tricky but no so bad. However, documenting the project was somewhat more challenging!

The problem was video. The SunVideo SBus video-capture card is quite capable, but the sample software that comes with it is very buggy and completely lacking in documentation. One factor that took a long time discover is that if you start the software and *then* connect the video source, the software will immediately crash 90% of the time. Connect the video source first, and it only crashes 10% of the time!

Secondly, the SunVideo software cannot save as constant-bitrate MPEG-1, but only variable-bitrate, in spite of presenting an option to do the former. If you choose that former option, it locks up hard.

Thirdly, although not the fault of the software, it took me a while to discover that MPEG-1 video (PAL format) *must* be recorded at 25 frames/second if you want to play it back at normal speed – I had dialled the “quality” setting upto maximum (as you do), in the expectation that the resulting 15 fps capture would be fine. It is, but won’t play back properly on any other system, so is useless for publishing to the ‘net. After a bit of googling about MPEG-1, I dialled the “quality” setting down until the capture rate got to 25 fps. It took several days to realise I needed to do so.

Final Hardware
The PedalBox had a couple of late-ish adjustments: addition of sponge blocks to get the “feel” right, a revised hinge-location to enable a “heel-and-toe” method of operation, and a bit of color (Sun purple, of course).

finalhw1
finalhw2
finalhw3
finalhw4

PedalBox – The Motion Picture
Before we get to the video of the PedalBox in action, a few excuses:

The video makes the PedalBox appear to be overly sensitive; in fact, I was recording the video late at night and was worried about waking the chaps upstairs, so I was jumping and pressing the pedals very hard! The lateness also explains why the lighting arrangements are so idiosyncratic.

The video itself is very low quality – I dialled the recording quality very low, lower than it needed to be. But as capturing the video was such a pain, I am not going to do it all over again!

The PedalBox switches sound very loud on the video, due to the cheap microphone used, but they are actually quite discrete in real life.

Also, the video as uploaded plays fine from twitpic on the iPad, but generates a “cannot load resources” error when accessed from both my XP machines. It looks like a recent change on twitpic.com is a bit buggy – putting an invalid URL into the wrapping script presented on their website.

Finally, next time I am going to get a tripod for the video-cam – I had the camera balanced on the end of the ironing-board, and angled slightly downwards by judicious wedging with a library membership card and a debit-card.

So the project itself was a great success, but my attempts to document the project progress were an utter failure. Darned new-fangled technology!

Dear Hollywood, no need to worry, I’m staying on this side of the big blue watery thing.

PedalBox - The Motion Picture

UPDATE: after messing with twitpic.com for a while, I came to the conclusion that there is a problem with their “flowplayer” video wrapper. So I resorted to YouTube: PedalBox – The Motion Picture – YouTube.That’s much better, I can see the video on iPad1, XP and Solaris. I think twitpic.com had decided that my SPARCstation-10 was an iPad!!!!

PostScript
Would I do another RetroChallenge? Yes, but only after getting more used to twitter and twitpic, and perhaps laying my hands on a Windows 7 machine, just for interoperability with these new-fangled websites… I have still got items left in my RetroChallenge-ideas list, but most of them are more tricky than the PedalBox. Time to start thinking about RC 2013 Summer!

RC 2013 WW – Modular Software Complete

Project: The Sound of Violence.

The new “modular” software is finished and fully tested. This will
allow future use of the PedalBox for other computer-control purposes,
should I be able to think of any.

Thus, this project is now complete. All that is missing is a video
of the PedalBox in action…

Online Manual Pages:

  • pdlbox_avc – use an MJS PedalBox device as the system audio-volume controller
  • pdlbox – PedalBox device event monitor
  • mess – Multiple Encoded Switch State protocol
  • mess_avc – command-/event-driven audio-volume control

Packages:
A binary directly-installable package for SunOS 5 (Solaris) on SPARC, and source packages, are available from
http://www.shelldozer.im/PedalBox/download.htm.

To actually build the PedalBox software from source, you will need
an ANSI C (C89, C99 or C11) compiler and the “MJSulib
C function library, from http://www.shelldozer.im/mjsulib/download.htm.

And for those of you that might be crazy enough to want to build your own pedalbox hardware device to use with this software, the following (final)
wiring diagram will be useful:
pbxA_wiring

RC 2013 WW – Finished! but…

Project: The Sound of Violence.

It is not over until it *is* over, but for “projects” it sometimes is not over even then…

The pedalbox volume-control and software is all working beautifully now that the pedals are “sprung” by the packing sponge. I have tested the pedalbox and software on Solaris 2.6 (SPARC), Solaris 2.4 (SPARC) and Solaris 8 (x86).

I will post a video of it in action as soon as I obtain an 2xRCA-to-3.5mm jack adaptor cable so that I can capture sound too – a silent video of the volume-control pedalbox would be pretty pointless!

But…

It struck me that the pedalbox might usefully be employed for other computer-control purposes, not just audio-volume control. Thus the current “monolithic” software probably should be split into two parts: a portable (POSIX.1-1988) pedalbox-monitor program that emits bytes representing pedal events to standard-output, and a separate (system-specific) program that reads events from standard-input and sets the audio-volume accordingly. That latter program could, of course, be replaced by one that does something else.

Of course, it would be nice if such a responder program could be written in most any language – shell-script, ruby, perl, awk, C, FORTRAN, python, and so on. Such a wide range (esp. shell) requires that the encoding of the events/state should result in printable (plain text) ASCII bytes, so that text-only programs can join in.

However, the pedal state-encoding should also be a sequence of binary bit-flags so that C, FORTRAN, Pascal, etc can decode the bytes simply, associatively, and very efficiently.

So we need an encoding that is both plain-text ASCII (no control characters) *and* is a set of independant binary bit-flags, at the same time, and ideally is transparently extendable to (say) 1530 separate switches/pedals, but allowing detection of non-implemented switches, we have:

The Switch-State Reporting Protocol

First things first: if there is to be a protocol, it must have a name! In keeping with the amateur nature of the project, I have chosen “Multiple Encoded Switch State” – the MESS protocol. Just about sums it up :-)

The state of all switches is encoded as a single line of printable ASCII characters (terminated by a single ASCII linefeed character).
Each data byte (7-bit, 8-bit or larger, depending on the host environment) encodes the state of four switches in the least-significant 4 bits, 1 bit per switch, starting from LSB for the first switch. For each switch, a 1 bit indicates “on/activated”, a 0 bit indicates “off/deactivated/not present”.

The 6th bit of each data-byte is always set to zero. The 7th bit of each data-byte is always set to 1. All more-significant bits are always set to zero.

Thus, for a three-switch pedalbox, the set of possible states gives:

Switch 3 Switch 2 Switch 1 Data Byte
Hexadecimal ASCII
off off off 0×40 @
off off on 0×41 A
off on off 0×42 B
off on on 0×43 C
on off off 0×44 D
on off on 0×45 E
on on off 0×46 F
on on on 0×47 G

So, for example, in C, the expression

data & 0x44

is true if switch 3 is on, and false otherwise, whereas

data & 0x45

is true if either switch 1 or 3 is on, and false if neither is on.

And so on.

Of course, the MESS producer will need a selectable option to provide state either

  • only when a switch changes state, or
  • periodically (ie: “autorepeat”)

and also an option to report state

  • only for activations, or
  • for both activations and deactivations

because those behavioural aspects are application-specific and need
to be selectable by the user on a case-by-case basis.

Now, the question is, does anybody have any ideas for other pedal-initiated computer-control purposes…?!

RC 2013 WW – Chassis Assembly – Part Two

Project: The Sound of Violence.

Pedals are now fitted, using hardware-store hinges. Unfortunately, there are a couple of adjustments needed: (1) the pedal activation is way too sensitive, when just resting my feet on the pedals, I keep pressing the switches inadvertently and (2) the switches don’t quite fully engage, due to the “other” side of the switch hitting the pedal when popping up (it’s a symmetrical rocker switch button – see this photo).

withpedals2
withpedals3

After rummaging through my boxes of bits, I think I have found the solution to the “can’t rest your feet on the pedals” problem – packing sponge!
sponge

As far as the second issue goes, I guess I will have to carve out a recess in the underside of each pedal to accomodate the “other” end of each rocker switch…

For the next RetroChallenge, remind me to stick to software projects, dammit!

RC 2013 WW – Chassis Assembly – Part One

Project: The Sound of Violence.

Sorry, but it’s more woodwork today… when I told myself it would be a hardware project, this wasn’t quite what I had imagined!

By a total unexpected coincidence, the cut-off remainder of the pedal timber turned out to be *exactly* the same width as the base panel – which means I can use that cut-off as the back-panel! Here it is with the 25-pin D connector fitted:

backpanel

backback
I guess you can spot the TX/RX loopback wire!

A little pencil-marking, hand-drilling, screwing later, we have:

sideimcomplete1

Electric/signalling tests are all good. It lives!

It’s still a bit flimsy, I will need to add triangular cut-to-fit side-panels to give it enough strength to tread on. After (or will it be before?) that, the pedals and their hinges need to be fitted, it looks like that will take some trial-and-error to get good clean pressing of the underlying switches…