If, like me, you like to play with Z80 assembler and hacking around on the wonderfully simple CP/M hardware, these machines are perfect. The size of a notepad and much lighter (and much more robust) than modern laptops, these machines give you go-everywhere CP/M fun.

The Hardware: Amstrad's NC100 and NC200

Outside of the UK, these machines are little known. They were introduced in the early 90s by Amstrad as no-frills pocket word processors, long after the era of the Z80 had come to an end. It seems they were popular with the same people that Amstrad catered for with their PCW range, and were frequently used in education it seems.
The NC100 is essentially a Z80 with 64K RAM and a PCMCIA slot for an additional 1MB of SRAM and an 8 line * 80 columns LCD screen.
The NC200 was introduced a bit later, and boasts a 16*80 screen, 128K RAM and a 3.5" disk drive.
In their normal state, these computers hold little interest for CP/M fans, as their firmware holds just a word processor, terminal software and BBC Basic. But with the introduction of ZCN by Russell Marks, that changed radically.


(*) Note that under ZCN, the NC200's disk drive isn't used, although you can store ZCN files on it using the internal software if you want. ZCN itself only uses the 1MB ramdisk.

 

The Software: Russell Marks' ZCN

ZCN is a CP/M compatible operating system for the NC's, written under the GPL license - freeware. Rather than creating a CP/M BIOS for the NC, Marks decided to start from scratch. That makes ZCN closely tuned to the NC hardware it runs on, allowing full use of features like instant off-on (switch off the machine at any time, and next time you switch on again, you can continue where you left things). Also, compared to standard CP/M, it has some neat features for hacking and Z80 development.
It's sometimes hard to say why a machine 'feels right', but this is definitely my favourite CP/M (-like) environment. Almost all CP/M software runs on the little machines. And because ZCN uses the 1MB PCMCIA card like a hard disk, it's very fast. It also runs for hours on a single set of 4 AA batteries (D cells in the case of the NC200). And it comes with a whole host of support programs - from a custom-installed Z8E debugger to transfer software for communicating with PCs and the original NC firmware.

GPL! That means source code...

Perhaps the best thing of ZCN is that it comes complete with all source code. Neatly written, it gives as much hacking fun on the Z80 as Linux gives on modern hardware. ZCN even comes with an good library of Z80 and NC100 specific assembler routines. Although I am not really a great Z80 coder, this is enough to allow complete control over the machines. The documentation is good, and because of the simple hardware, it's not difficult to fully understand the entire machine in a matter of days. Cliff Lawson's site contributes by documenting the hardware design of the machine.

Practicalities

The NC100 has a small screen - 480*64 pixels. ZCN doesn't use this for a 8 lines*80 columns layout, but instead uses 10 lines * 120 columns. I've read a lot of comments about that choice. But, in fact - get used to it. After 15 minutes you'll be used to the small fonts. And the additional 2 lines matter. A 10-line screen is much more OK than an 8 line screen. On the NC200, you'll have 21 backlit lines - which is excellent.

Some tips...

Finding suitable PCMCIA cards
Finding an NC is not too difficult - go to the UK eBay site and an NC100 will cost you about £20, or an NC200 about £50. See below for a cheaper option - buying a dead NC100 and fixing it.
Anyway, the real challenge is obtaining the right PCMCIA card. You need one for ZCN. The NCs require an SRAM PCMCIA card, max 1MB in size, which seem quite hard to find. One solution is to look for Apple Newton 1MB SRAM cards. Careful - only the 1MB Newton card uses SRAM, all the larger ones are Flash RAM that is useless on the NC.
The other route - the one I tried in November 2003 - is to order a memory card for the Atari Portfolio from Best Electronics in the US - they ship worldwide. One card costs approx $15. Good people, good service. The one I got turned out to be a Newton card, by the way.

Update 2013: on the above link, search for the "Special Buy! Type 1, S-Ram 1 Meg PCMCIA Card (Red and Black card) for the Above Portfolio PCMCIA adapter.  These Recycled 1 Meg S-Ram Cards are an excellent buy for the money. Think of it 1 Meg of Portfolio Total Drive Storage capacity for under $100 including the Portfolio PCMCIA adapter card!  After that, 1 Meg of Portfolio drive Storage for only $15!! CB103058 $15". Disclaimer: I've got nothing to do with Best Electronics, they just seem to sell this at the best price. 
 
Dead NC100s:
It seems that many NC100 owners plug in a third-party power supply instead of running the machine on batteries. Unfortunately, the standard-looking power connector has its polarity reversed from what is usual: The outer side of the connector is +, the inside is -. Alas, a fuse in the NC100 blows up when you get the polarity wrong. This results in a dead machine... see the cool graphics to the right!
Dead NC100s are regularly sold on eBay, and it seems a reasonable bet to buy one assuming it's just the fuse. Fixing it is very, very simple - see John King's fix page. Even I managed, so I got a bargain NC100 for a total cost of £1.24 off eBay...
I am not sure whether the above also works for NC200s. Please let me know if you do...

 Null modem cable trouble:
The normal way to communicate with the NC100, lacking a disk drive, is to use a null modem cable. You'll need one to install ZCN, anyway. I used a bog standard one, but it didn't work. The NC could receive whatever the PC was sending, but the other direction didn't work. I could not find any help on the Net - so if anyone else has this problem, here is the fix: solder a wire between RTS and CTS on the NC connector - short pins 7 and 8.

Links

Russell Marks' ZCN homepage
Tim's Amstrad NC Users' Site
Cliff Lawson's NC Pages

Solving read errors on 5.25" and 8" floppy disks

Over the years, I have had my share of problems with floppy disks like everyone else. Many read errors prove not to be as fatal as most people assume. If the data is really important, it is well worth the trouble to try the following remedies:

Keep on trying

Many machines will come up with an "Abort, Ignore, Retry" message. Go on, Retry! Sometimes the 30th retry works out.

Try another day

Floppy disk drives are the crudest mechanical component in any modern PC. When they warm up after an hour or so of computer use, they have a different tolerance to marginal read errors. When they are rattled by a series of read errors, the miniscule bit of dirt on the read head just might come off.

Try another disk drive

This actually has a FAR larger chance of success. Try reading the floppy disk on as many machines as possible before giving up. The disk drive that wrote the disk might have its read/write head slightly misaligned. A brand new floopy disk might be too well-aligned to pick up the signal correctly, but an older drive might be misaligned in the same direction as your original disk drive. You can give up if 5 different disk drives all refuse, though.
Note that many CP/M disk formats can be read or copied on an MS-DOS machine. Using 22DSKor Xenocopy on a PC, you can have another go at recreating a boot disk for that unique CP/M computer... Also, DIM is a useful PC program. It copies all sectors off a disk and stores them as a file that you can use to clone that diskette. It works for many formats, not just MS-DOS ones.

Try another TYPE of disk drive

It is obvious that you cannot read a 1.2MB HD diskette in a 360k disk drive. But the other way around usually does work, and many people have forgotten that there are actually three different main types of 5.25" disk:
360K, 720K and 1.2MB (or, 40 track/48tpi, 80 track/96tpi and HD)
If you are trying to recover old CP/M disks, they are probably of the 48tpi type, and with the right software, a much more modern MS-DOS PC should be able to read the disk. But still, that PC is likely to have a 1.2MB HD drive, and reading the old disk is at the margin of its mechanical tolerance. If reading your ancient disks matters, the best thing is to buy a 360K disk drive off eBay. They only cost a few dollars, and can simply be plugged in to the slot and connector of your HD drive. Also, note that many PC clones of the 90s had a 5.25" disk drive connector internally, even though the format was already extinct and the PC didn't come with such a drive!
Whatever you do, never use a HD drive to write on a disk that came from an old machine, even though you can with 22DSK or other software. Not until you've made a full backup. The problem is that HD drives have a physically different read/write head, that leaves a more narrow trak on the disk. If the disk was formatted with a 360K drive, that's asking for trouble now or later on.

The Magic Rub

Somebody told me this trick, and it REALLY works wonders. If a floppy disk gives read errors, it might just be that it sits too tightly in its plastic sleeve. The friction that causes might be the last drop, the reason the drive returns with an error.
Take the disk, look for a hard table edge, and rub the four edges of the floppy against the edge of a table or whatever. This makes the disk sleeve a bit 'fatter'. Take care: floppy disk sleeves can damage your table - it is surprising to see how abrasive they are! Ayway, stop rubbing the disk up when you feel it getting fatter, and the disk inside the sleeve is noticeably loosened up.

Soap

I've never really tried it, but there are convincing messages on Usenet from people who opened up the sleeve of a diskette (just one side, it's not as destructive as you may think), take out the actual magnetic disk, and wash it. Apparently, if you wash the disk in tepid water with a bit of Fairy (or whatever the brand of washing-up liquid is), the oxydised film of grime and worn disk surface comes off.
Dry the disk with a soft cloth a bit, let it dry up, use the cloth again, and re-insert the disk into its sleeve. Many errors can be solved this way - especially when you then also try a number of different disk drives.

Clean your disk drive

It's obvious, but it doesn't very often help. Still, cleaning the disk drive's read/write head with a otton swab dipped in alcohol makes sense.

... And as the very last resort:

You can sacrifice your disk drive in a last-ditch attempt. This only makes sense if the data on your disk is more important than your hardware, as your disk drive will need professioal realignment afterwards. Nevertheless, a very successful method is to open your PC, get to the disk drive, and get access to the stepper arm that holds the read/write head at its end. This arm is fixed to the drive on the other side by (normally) two screws that are fixed with glue.
First, try to push the stepper arm to the left or right a bit. I assume you've left your computer powered on, so try and read the disk again. If there's a read error, push the stepper arm left or right again, and try to read. Pushing, at this stage, doesn't yet imply you do anything visible in the sense of shifting the stepper arm. It just means pushing, for now. Keep on trying, if this does not help at all, then:
Seondly, loosen the screws that fix the stepper arm into position. Loosen them only a TINY bit. Then, try the same procedure as above, prodding, pushing, and eventually slightly shifting the stepper arm until you can read your disk. This process can take an hour or two. It's crude, unsophisticated, unscientific, potentially destructive and often HIGHLY successful. Good luck!
Note that the stepper arm you're seeing when you open up the disk drive holds only one of the read/write heads, the other side of the disk is served by the read/write head underneath. It's mostly the top head that causes problems, though, as it sits on the mechanism that lifts up every time you insert a diskette. So focusing on the top head and stepper arm makes sense.

This is a repost of a project from September 2005, describing my experiences with getting a CP/M machine out of the Zilog eZ80 MDS development board. It's nothing more than my practical supplement to what's on www.vegeneering.com. These are just some practical notes - and beware of mistakes. Still, someone may have the same urge to play with this board...


Enabling simultaneous use of Serial and SPI
The MDS uses pin PB6 as the chip enable signal for the MAX232 serial chip. But PB6 is also part of the SPI. The solution suggested on the eZ80 Yahoo group is to cut the chip select and tie it down to ground, so the MAX232 is always active.
For this, a wire leads from U6, pin1 to GND to permanently enable the serial port. The gray wire runs from the bottom left of the board to the upper right, where pin 1 of U6 is linked to it, and disconnected from the board. Unsoldering the pin is a bit difficult – see the Yahoo newsgroup conversation on this in September 2005.







The MMC card reader
I removed an MMC connector from a 9-in-1 USB card reader – cheaper than buying the connector separately, I thought. The connector fits to perf board nicely, I used part of a Eurocard with a DB9 solder pad that connects the connector pins neatly with solder terminals:




Linking the MMC with the eZ80 MDS board
I used a normal 60-pin flat cable connector. All pins required for the MMC adapter are on JP2 of the MDS, between pins 9 and 18.



There is one thing that caught me off guard.

JP2 arranges the pins in the format of:
2 1
4 3
6 5
8 7
...etc
That's the mirror image of what you expect from a flat cable connector, you'd expect
1 2
3 4
5 6
7 8
...etc

So, check which pin is which number before soldering them on to the MMC connector.

The point is, the flat cable runs the wires as
10
9
12
11
14
13
Instead of
9
10
11
12
13
14
Very annoying, count carefully.

Schematic
Below is the connection between JP 2 on the MDS board and the MMC connector. Note the two 10K resistors. Apologies for the draft format, I never got around to cleaning up the documentation for this project...




The source for all of this, obviously, is the original schematic on www.vegeneering.com. That one bases itself on the eZ80 module connectors rather than the JP2 connector on the MDS board, hence my additional schematic.

Hmm... Home alone for the weekend... what to do? Spend the weekend to convert a $25 toy into a home-built Commodore 64.
Obviously.

For those who don't know, the DTV is a simple 25-dollar TV videogame that appeared in 2004. Built into a battery-powered joystick is actually a very complete Commodore 64 clone with some 30 videogames. It has an interesting pedigree, designed by Jeri Ellsworth  after she came up with the Commodore One.

The designers have clearly aimed to make the toy hackable. In fact, it contains something like a '2005 motherboard' for a stand-alone C-64 clone. Hook up a PC keyboard, a 1541 disk drive, add external joystick connectors and, and, er, well, you have a new C-64. How useful is that?!

The initial version was a NTSC design. A European PAL version finally appeared in November 2005. It adds some improvements for those hacking around: it supports both joystick ports; and it has a flash rom containing the 2MB 'virtual hard disk', creating the hope that this flash is rewritable. Writing this in November 2005 though, I haven't heard anyone actually having done that.

One thing seems to bother lots of people: the PAL version apparently shows colours that deviate from the original C-64. Maybe, but nothing that I notice particularly. Using a TV as a monitor never was a great idea, and my DTV does exactly as badly as my original C64 when it comes to the TV picture...

My DTV Hack

Here is my version of a full C-64 replica built from the PAL version of the DTV, and a description of how I built it. How good is this little blue box as a C-64 clone? Not perfect. But still, it's a fun project and it does run most  software - how much I don't know, because I haven't tested it fully yet. The problems I know of so far:

• at present (november 2005), the F7 function key doesn't work.
• by trial and error you have to find out what the keyboard layout is of the PS/2 keyboard.
• there seem to be some minor compatibility issues as well, quite a few games didn't fully run.
• ...and of course you probably forgot how slow a C64 is without a Final Cartridge slotted into the back!

Who cares? It's still a near-perfect replica of the C-64, and it is a simple/cheap/fun hack.

Requirements

To make the DTV into a fully connected C64, you only have to hook up connectors to some solder points on the board. People either put the connectors into the original DTV case, or they take out the board and put it into a new case with more space.
I chose the second option, a proper new case. They sell a perfect one at www.conrad.ch (or .de, presumably), just large enough to fit the board and still leave a bit of room to wire up the connectors. The front and back are plastic, making it easy to cut out space for the connectors. Also, you can easily mount the board inside, the screws fit. Order number 52 31 17-99 for 6.75 euros...

LEFT: The back panel holds the keyboard/disk drive/joystick connectors. I used the original unit's video cable without modification. Its pull-protection thingy ( Thingy ) locks neatly into a cut-out slot in the back panel.

As you can see, I still have to add the second joystick port and also a decent power connector...

RIGHT: The front panel is equally simple: just a reset button and the power switch taken from the original DTV. It neatly drops out of the DTV case, and gives you a built-in power LED and on-off switch that you can easily mount in the front panel with two screws.

Parts list:

• a push button for resetting the DTV;
• a 6-pin DIN connector (female) for the disk drive connector;
• a PS/2 mini-DIN connector (female) for the keyboard;
• two DB-9 connectors (male, ususally for RS-232) for the joystick ports;
• a simple plastic case that turned out to be the perfect fit.  
• I forgot to buy a power supply connector. Hmm. Next time.

The mechanical work

The pictures below show the construction process. All in all, it took only four hours!

Opening the DTV shows the 'motherboard' (A), the board that I removed holding the fire buttons (B), and the power switch unit (C), that I kept. The second picture shows the board itself, before I removed the fire button board which is still visible on the right.



Here's how the board fits into the case, and how the back panel was planned with the connectors. Not visible here is how I cut a small vertical slot into that back panel, that holds the video cable neatly in place. Good way to save on adding one more connector, whilst keepings things solid.



The finished thing, ready to be closed up. All I did was to add the connectors to the board. I soldered everything on the back side of the board, but that's a matter of preference I guess. Only things that remain to be done now is to add the second joystick connector and a proper power connector. For the moment, I still use the original case of the DTV as a battery holder.

Soldering work:

The PAL version of the DTV is different from the NTSC edition. Below are the links I used to get all the correct information for the PAL version.

1 - Finding the soldering points for the keyboard and disk drive ports:
Best shown in this Petscii forum thread. I made a copy of the most important picture, in case the link ever disappears. Zoom the picture to get the full details:

Keyboard/Disk drive solder points
Source: http://jledger.proboards19.com/index.cgi?board=dtvhacking&action=display&thread=1128627064

Next to the three lines shown in the picture, the IEC disk drive connector also needs a GND wire. And the keyboard connector needs an additional GND and +5V. These additional wires that can best be soldered on to where the power leads come on the the board. I wrongly assumed that GND could also be found on the back of the board, just anywhere on the matrix. Not so - it's not GND but +3.3V! If you don't get things to work, check whether your GND wires really go to GND on the front side of the board. And whether your +5V is really +5V, not 3.3V.

2 - Soldering points for the two joysticks:
Best shown in this Petscii forum thread. I made a copy of the most important picture, in case the link ever disappears. Zoom the picture to get the full details:

Joystick solder points
Source: http://jledger.proboards19.com/index.cgi?board=dtvhacking&action=display&thread=1131108146

Joystick #2 is actually the one that is used by all the games that came with the DTV. There are six wires to hook up to the DB-9 connector:

• The four directions, takes from solder points right next to the contact pads on the board shown in yellow;
• The fire button and GND line are both taken from the solder pads on the top left of the picture. It's the left fire button on the DTV you want.

Joystick #1 is less used on the C64. Still, it is useful to have the connector available:

• The four buttons on the DTV actually are the contacts for Joystick 2. A is fire, B is UP, C is DOWN, D is LEFT. Make sure you solder to the solder point for the lines, NOT the solder points that are GND.
• The fifth line goes to the right-hand fire button of the DTV, which is, strangely, Joystick 2's RIGHT. You can get the 6th line, GND, right next to it.

3 - Connector pinouts:
To know how to hook up the connectors to the wires, look at this site or this one. It's quite simple, as summarised below. Note that all connectors are shown from the front side, looking from the outside in. Meaning you should make a mirror-image if you want to look at the solder side!



Thanks to the people who did all the figuring out!

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

Disk drives - the annoying part of retrocomputing

If you want to enjoy your vintage computers, the single most useful investment is adding some form of modern storage to replace old disk drives. That is especially true for the Commodore 64, given that its disk drives are very slow and limited in capacity.

Over the past years, I've added Compact Flash or SD card storage to many of my machines. For the Apple, I have the CFFA 3000, for MSX there is the SD/MMC reader, for the BBC, there's cards from Ctorwy31 and Retroclinic. And of  course, S-100 computers have IDE boards these days. All of this vintage upgrading goodness actually started in the mid 90s with the GIDE from Tilmann Reh - an IDE board that slotted underneath a Z80 to expand pretty much any CP/M machine with mass storage.

Over the years I bought and installed all of the above but - anyway. Here are my experiences in upgrading the C64...

An early device: MMC 64

There used to be the MMC 64 from Individual Computers in Germany. I bought one around 2005. Plugged in to the cartridge port, it presents itself with a menu of files you can load at boot time. It's good for quickly loading single-file games into the C64, but it is not a floppy replacement. Also, by using up the cartridge port, it prevents you from having other desirable goodies there. (Of course, these days, the Retro Replay MMC has taken over from the original MMC 64, and packs a lot more power).

SD2IEC

Then, I got a SD2IEC device in 2008. Mine came from NKC, but the uIEC from Jim Brain is the other option of course. The SD2IEC is excellent - it truly replaces the 1541 in my daily C64 life. You just stick the SD card in your PC, save any D64 image you want, and reinsert the card into your C64. And even better, it is just as happy to act as a 1581 drive, or serve you the files straight on the SD card acting as a hard disk. There are minor compatibility issues now and then, but if you want to play games or do serious work with the C64 you won't really encounter them.
The SD2IEC can easily be mounted inside the C64 (solder it straight on the inside of the Serial port connector, glue it somewhere in the C64 case) but you'll probably want to cut a small slot into your C64 to access the SD card slot from the outside. I chose to make the SD2IEC into a separate device. For that, NKC offers a connector board with In & Out Serial ports, power supply connector and some disk select buttons. I duly put it all into a small cigar box so it can serve all my Commodores...

Commodore Flyer

In 2012, I had the burning desire to go online with my C64. Although I played with a serial-to-Ethernet converter (an old MSS-100 from Lantronix), the problem was of course what to do with Internet access...

This was when I discovered the fantastic Commodore Flyer. Not only does it bring a very clean solution to networking (the network is a Serial port device just like a disk drive or printer), but the firmware also provides 3.5MB of on-board Flash storage, acting pretty much like a SD2IEC. 3.5MB is not that much, but the cool thing of course is that any disk image on the internet, on your local PC, on Commodore Server, or on the 'Cloud' that Brandon provides can be used as well. So: good storage option and smooth network interface in one. I really love it. The networking capabilities deserve some further explanation: it can download and mount D64 images from an URL. But it can also use HTTP, translating back and forth between the simple C64 text capabilities and whatever site it is you want to access. Easily. From Basic! There's also IRC and Telnet programs. Telnet, I can safely say, does a good job. You can even log into old-style Commodore BBSes online. I should mention the competitor to Flyer: the Comet64. I mainly chose the Flyer because it is an IEC device, not a user port device.

Jiffy-DOS

Of course, Commodore left us with a nasty little legacy problem: the horrible Serial  Port driver in the Kernal. Whatever goodness you connect the port, will be dragged down by its ultra-slow communications protocol. Although I used a Final Cartridge, and it works with the Flyer and the SD2IEC, I finally made the upgrade to Jiffy-DOS. It does not bring better performance than the Final Cartridge in simple file loading, but also speeds up any disk interaction done by programs after they have been loaded themselves. That matters. For instance, if you insist on running a C compiler on the C64...
Jiffy-DOS is really an upgrade even more urgent than the Flyer or SD2IEC, especially because they work so well together in combination. Finally, finally, the Commodore 64 is not bogged down anymore by its disk drives. It truly transforms the C64 into an altogether different animal!

Cheat Sheets

Although I referred to improving Daily Life with my C64, Daily is not quite the frequency with which you fire up the C64. So, you tend to forget the exact commands for using Jiffy/Flyer/SD2IEC. Below are the cheat sheets I always keep at hand:
       

Jiffy/SD2IEC Cheat Sheet

Flyer Cheat Sheet

Useful software

Looking back at the C64 with modern eyes, it's striking how proper file management utilities were really missing. Something like the Norton commander, for instance. Once you deal with huge file volumes through an SD2IEC, this becomes even more of a problem. Recently, some very useful tools have been developed to help out:

CBM-Command
Very much in the style of Norton Commander - excellent!

NAV
More colourful & nice to use. From the cool people at Commodore Server.







SJLoad
If you do not have JiffyDOS, SJLoad is an essential tool. It quickly loads itself as a fastloader, then the program you specified when loading SJLoad.

A.     The board and its jumpers

The Willem 4.1 uses an external power supply. According to the manual, the power supply should be an unregulated12V supply, 0.5A, that actually should output something like 16V. Anything between 15 and 20V should be fine. What the manual does not say is that the supply voltage should be much higher if you want to burn old 2716 eproms. For them to be burned successfully, I needed to raise the power supply to 32V. That should be fine, the LM 357 regulators can deal with anything up to 40V.

B.     Settings that I used successfully

Appendix: Preparing the parallel port

I was late in upgrading to a BBC Model B, 31 years late in fact. But last month, it became my favourite 6502 machine overnight. Thanks to its OS and BBC Basic (which seamlessly blends assembler code with Basic), it's the nicest Vintage 6502 programming environment I know of.

Enter the Modern Era. The Beeb's usefulness can be transformed by two upgrades:

1: Upgrade Sideways ROM to 16 slots.
    And make it use NVRAM and Flash ROM as well as old EPROMs.

2: Use a modern MMC card as mass storage.

There are a few suppliers of these hardware upgrades. This blog entry describes my experience with the ones from Ctorwy31, selling regularly through his eBay shop.


1. Ctorwy31 BBC Micro Flash ROM RAM expansion board + battery backup

I was deeply impressed with the package I got in the mail. Not only did it contain the actual board, but a lot of tidbits that help installing it. Even a cut-to-size piece of foam to secure the optional battery into place. A lot of care went into this!

Installing the board is trivial, and the manual says it all. Three wires go to the Beeb motherboard, the expansion board is pressed into the Sideways ROM area and optionally, you place the battery backup (to make RAM into Non-Volatile RAM) in the empty spot next to the Beeb's keyboard.

I chose to solder the three wires to the back of the motherboard, rather than use the provided clips. Ctorwy31 even describes how to unsolder the clips...

The one observation from this little exercise: pressing the expansion board with its multitude of pins into the Sideways ROM sockets should be done with some care. Make sure all the pins are precisely above their sockets before pushing. Because if you bend the pins, it will get very complicated to push all the pins in correctly! I first checked if all pins indeed hovered above their sockets. Then pushed.


2. The Ctorwy31 MMC Drive

Regularly offered on eBay as the "Acorn BBC Micro B Master MMC solid state disk drive", it costs around 36 pounds and shipping abroad adds surprisingly little to that price!

I was planning to make this a how-to describing its installation in detail. But it's too simple for that. Connect the cable to the User port, connect the MMC drive to the other end of the cable, and stick the supplied EPROM into a socket. The MMC is already preloaded with software...

So instead, let me describe how nicely supported the MMC drive is with bits and bobs to mount it.
There are three mount options:

• First, the MMC can be an external device, like a disk drive. You'd need to find a handy little box to put the PCB board in. Slot in the back for the cable, slit in the front to insert an MMC card.
• But the card is so small, that it easily fits inside the top cover of the Beeb. Ctorwy31 provides self-adhesive stands that make this trivial.
• Lastly, if you do not mind cutting a slot into the side of the Beeb's case, you can insert and remove the MMC card like you'd do with a floppy disk. That's very attractive if you need to exchange data with a PC. But cutting a perfectly shaped slit into the case is not easy. So Ctorwy31 even added a little metal strip in the package that you can used to cover up your botched case surgery. And he added a sliding mount to make positioning the MMC board easier. Talk about caring for your customer.

To summarise: 

Both kits are excellent upgrades, they work exactly as promised. And the care with which the package is put together makes them an unreserved recommendation for any Beeb owner. In fact, a must-have.

It had been a while since I last fired up my Atari ST. But recently I did, and managed to wipe out the partitioning of its hard disk within the hour. The ST always had a real vulnerability in that respect - very easy to lose all your data if you have multiple devices on the hard disk port.

• 
  

So, rebuilding the hard disk contents from hundreds of floppies? My love for Vintage Hardware strictly excludes floppy disks, so I looked for a modern storage alternative - something like the CFFA 3000 for the Apple II or the SD2IEC for the C64.

Ultrasatan?

Lo and behold, there's the Ultrasatan. A dual SD card drive that plugs into the ASCI hard disk port and acts like a dual SCSI hard disk. Its somewhat unfortunate name is a continuation from something called the IDE Devil, which was succeeded by a Satandisk. I guess you go one step further down this path of evil with Ultrasatan.

Anyway, the Ultrasatan is now produced and sold by Lotharek. I bought the external version, plus its non-standard ACSI cable. It arrived within a week, and like most of this type of retrocomputing gear, it turned out to be a very fine piece of equipment. Carefully (actually, lovingly) packaged for mail delivery, the drive itself is housed in a beautifully crafted metal case, which looks excellent next to your ST.

One minor thing: it looks excellent on topof a 1040 ST, but the cable is too short/inflexible to sit next to my Mega ST (I placed behind the Mega instead). The cable is solidly constructed though. And there's an internal version intended for Mega ST's actually.

The cool thing about the Ultrasatan is that you can format the (hot-swappable!) SD cards to be both readable by the ST, and by Windows machines. You can thus fill up your drive on the PC (I already had a full ST software setup on the Hatari emulator) and use it on the ST. Or vice versa.

But: for this, you need one of two modern ST hard disk drivers: HDDRIVER from Uwe Seiwert or the Petari driver, just released by ST hardware hero Peter Putnik. With other drivers, like the ICD one, the Ultrasatan works fine - but partitions are only readable for the ST like in the olden days.

I tried both. HDDRIVER worked fine, but setting up was a bit of a hassle. The Petari driver was next, and I stuck with this one. It takes a simpler (quite innovative) mean & lean approach, but at the same time has some very nice advantages. First, you use the partitioner to set up partitions of its proprietary C16 type. They are TOS & DOS compatible - no reason to choose any other option. Secondly, after hitting the Init button in the partitioning program, you run the driver install program and that's it. Done.

Spectre: Macintosh emulation

Although the ST is a nice platform itself, my noSTalgia actually has a lot to do with Spectre, the Macintosh emulator. I partly earned my way through university as a Mac developer - on Spectre. Yes, it was that good in emulating a Mac Plus!

Would Spectre run on Ultrasatan partitions? I have less than ten real Macs, so this is obviously important to me. It turns out that, yes, it will run. But Spectre does not recognise more than 4 partitions on a harddisk, and should reside on the last partition of a drive. So as not to interfere with anything, I keep my Spectre partition on a small dedicated SDcard in the Ultrasatan's second slot.

Getting software from the Mac to the ST had always been an issue. The Spectre GCR cartridge contained a hardware hack to make the ST read Mac GCR disks. Try and find one in 2013... I only have the software version of Spectre. And then, you're condemned to use an intermediary disk type: an MFM-encoded special 800K disk format that can be used on Macs with a FDHD disk drive. Lots of floppy juggling to be avoided, in other words.

I wanted to find out if you can use SD cards to swap data between the Spectre/ST and a Mac. Or actually, a Mac emulator on my PC. I keep a virtual hard disk image with all my 68KMac goodies running under Basilisk. Could I swap that over to Spectre? Yes. Easy once you know how!

• On the ST side, one very cool feature of Spectre is that it recognises Mac-formatted SCSI disks. You could plug in a Mac SCSI drive and Spectre would just work with it.

• On the PC side, the Basilisk and Mini vMac emulators only emulate Mac hard disks through virtual volume images, not full hard disk images. You can't put a volume file on an SD card though, you need a proper hard disk image including boot sector and partition data. Luckily, the third Mac emulator on the PC - Softmac - can work with full hard disk images. See the screen shot.

The following approach gave me a smooth exchange mechanism between Spectre, running from the SD card, and Softmac, running from a disk image file of the SD card:

1. Move the contents of my Basilisk .hfv partition image (which Softmac will not read) over to a big fat .dsk floppy disk image (these .dsk images can be way larger than a floppy disk and still be mounted as virtual floppies!).
2. In Softmac, create a 100mb SCSI disk image. Annoyingly, these files also have a .dsk file extension. Lets call them .dsk/SCSI to separate them from the .dsk "Big Floppy" type of file...
3. Initialise the SCSI image not with the Mac System 6 HD Init program, but with "Apple HD SC Setup 7.3.5" found here (use binhex to unpack). With the System 6 init tool, Softmac appears to have a problem - it seems to work but adding to the disk image afterwards will cause garbled data.
4. Under Softmac, copy everything you want from the .dsk image on this .dsk/SCSI drive image. Spectre will boot from any System 6, 6.0.8 is the most recent one (but also the most bloated one BTW).
5. Use dd, or more comfortably, win32diskimager, to transfer the image to your SD card, and insert it into Ultrasatan. Spectre will recognise it as a Mac HFS drive, and boot straight off it.

After setting this up,there is a very a comfortable file exchange mechanism:
Spectre -> SD Card -> Copy to disk image -> Softmac... and the other way around.

  
The whole process can be simulated through Hatari (an ST emulator) as well. Hatari will mount the .dsk/SCSI image as a hard disk. Note how the SCSI drive(image) is picked up in Spectre. Slight incompatibility with Hatari: it does not want to boot 6.0.8, just System 5. Whilst the real ST will happily boot System 6.

(On the real ST, you need to tell Spectre to look at SCSI device 1 if you use the second slot in the Ultrasatan).

 

Local downloads:

•  here is a ready-made 100mb SCSI disk image file with some data. Transfer to an SD card (any size, doesn't matter but more than 100mb obviously) using win32diskimager, and Spectre will boot off it.
• The Spectre emulator itself, and an ancient System 5 Spectre boot disk image.(Note: use File->Download on the top menu of these Google Drive links to download the entire archive rather than look at the individual files. Bit confusing.)

I guess there are less than 10 people on the planet with a similar interest. But if you are one of them - please let me know if this procedure can be improved?

Demoing N8VEM at the VCFe-CH

Well that was nice! This weekend, the very first Swiss Vintage Computer Festival was held. Despite not being very broadly announced, well over a hundred people turned up. Some seriously knowledgeable people were around too, making it a small-scale but thoroughly enjoyable event. A bit like Switzerland itself, then.

The old Sulzer factory hall is likely to be the biggest VCF venue on record, with some 2100 square metres plus a second floor. It's huge. See how the VCFe banner is a puny white speck on the wall? Hopefully they will decide to make this a repeat event, and then do bring your own Colossus replica along, or possibly that spare IBM Blue Gene. You'd not be in anyone's way with larger machines...

Showing the N8VEM

Anyway. I took the opportunity to showcase some of my favourite N8VEM Homebrewing bits. To record the exhibit for posterity, from left to right: a Zeta with its own VGA screen and PS/2 keyboard; a misplaced bottle of Coke, and a N8VEM SBC.
.

Ladder Excitement!

For some added Live Experience, I had put Ladder and Catchum on the demo too. Text-only Pacman & Donkey Kong clones are moderately interesting... but to my amazement, someone got really, really excited.
Turns out he had recently ported the venerable Ladder to the PC, running under PC-GEOS no less. We spent quite some time going through his ultraclean C code and discussed how actually, it's not such a simple program to code. Then he showed how he managed to shrink a 40K Z-80 CP/M program into a 17K x86 version using custom compression techniques for the level encoding. Phwoar. In a time where looking at a simple HTML web page occupies 50 megabytes of working memory, that's proper coding. Shrinking a piece of Z80 code when moving it to x86 in C?

ECB computing then & now

The inevitable happened after the VCFe in Winterthur two months ago.Three of us Vintage Computer types got together and presto... you have a Vintage Computer club, of sorts, or something.
We found a very friendly reception at the Hackspace Luzern and so we decided to have three monthly meetings there, to see if we can get something going.

Here is the link to what we now call Vintagebytes.ch, and the three trial meetings will be:

• Wednesday Jan 15th, 20:00 - Homebrewing & the N8VEM Project
• Wednesday Feb 12th, 20:00 - The Apple-1 and Kim-1 shown through modern replica's
• Wednesday Mar 12th, 20:00 - Hacking the Dragon 6809 computer 

We meet in the Hackspace Lucerne, Güterstrasse 6 (link), which is located close to the Luzern train station in a SBB railway warehouse. Please have a look at www.vintagebytes.ch for details!

 

I grew up with the Commodore 64. It was simply the default computer to get during the Festive Season of '83. The Atari 400/800 had been around for years, but was too expensive here in Europe. And when the updated 600XL and 800XL arrived in 1984, it was already too late for them to gain significant market share. At least where I lived, the C64 became so omnipresent that anything else was destined to live in its shadow.

So. I never knew much about the 8-bit Ataris. Time to embark on an Atari Exploration Journey!

For Commodore fans, a warning. This particular journey ends in infidelity - even heresy. Better stop reading. Because I must admit, the 800XL gives the C64 a very good run for its money. More solidly engineered, with a 6502 that runs at almost twice the speed, they are very nice home computers indeed... Maybe the Commodore has better sound - but XL demos sounds equally groovy to my untrained ears. Its graphics are said to be inferior to the 64's VIC-II, but you would not say it from the excellent stuff that appeared on the XL. In exchange for an 80% increase in CPU throughput (because that's what 1.79 instead of 1 Mhz means, no?) these things are small fry. The XLs are cool! Besides, it seems, the XL hacker community delivered some things that somehow never quite happened in the C64 world. Like a very proper operating system in the shape of SpartaDOS X.

The journey starts, on the cheap

I picked up an Atari 600XL, condition unknown, for 6 euros. As I am more and more getting fun out of fixing old hardware, I hoped for a nice bug hunt that hopefully would find at least the custom chips in working order. Alas. There was nothing much wrong with the computer, at least not before I started my improvements. The only things wrong were some cracks in the keyboard PCB and a HUGE amount of rust everywhere. This was the first computer I ever saw that had a rust problem. I even had to drill out one of the screws holding the metal shielding together. The shielding was corroded beyond repair, but you don't need it anyway. So, clean the main PCB, solder some jumper wires across the cracked keyboard PCB and that was it in terms of repairs.

Next was to find...

• a power supply. Luckily, the XL series just needs 5V, nothing else. I did not find the 7-pin DIN power connector in my spares box, but a 5-pin DIN connector works fine too. That's because half the pins are GND and the others all are 5V. But memo to self: do not make the mistake to plug it into the 5-pin monitor socket later on. Second memo to self: if you do it again, know that it's not lethal.
• a video cable. European 600XLs have video out, not just RF. Even nicer: a C-64 video cable (simply video, with one cinch for video and one for sound, but not a 3rd one for Luma) works for the XLs as well!It leads to the one criticism I have on the Atari XL hardware: the video signal it produces is nowhere near as good as the C64's. Apparently, you can add S-video output. Or buy the VBXE RGB video card. But that's one step too far for me at the moment.

Stripped from all the rust flakes, the 600XL came to life immediately when both connectors were put in place. What a disappointment. No interesting repair job, then. Oh well, better luck next time.

64K upgrade

The 600XL is a nice package. Much smaller than the C64 in every dimension, and a bit shorter than the 800XL, it is in fact downright cute. Its cuteness comes at a horrible price, though: it only carries 16K of RAM. You cannot do serious home computing in 16K.

Fortunately, upgrading to 64K is as simple as replacing the two 4164 RAMs with 4464s, and adding 3 jumper wires. Upgrade kits are sold on eBay, but I found the 4464s elsewhere for a grand total of 3 EUR. How difficult can it be? Not difficult at all - see this picture I found on the AtariAge forum (click to enlarge). Stupidly simple... Unless you solder the jumper wires to the wrong-but-similar-looking cluster of vias on the motherboard of course. It took me 3 weeks to realise my bludner. In exchange for that stupidity, I learned a lot about the XL's hardware design, trying to figure out what could be the problem. So I got my bug hunt after all... at the expense of some serious ego damage.

21st Century hardware

As is the case with most 8-bit home machines, modern-day upgrades transform the XL into much more interesting machines. In the case of the Ataris, most of that goodness seems to come from a dedicated hacker community in Poland and the Czech Republic. Ataris were popular behind the Iron Curtain, back in the day.
Here are the add-ons and enhancements I found, looking for things that could pimp my 600XL:

• SIO2PC/USB: connects the serial port of the XL to a PC, so the PC can act as disk drive, hard disk and printer.
• SIO2SD: like the uIEC on the C64, this acts as a disk drive replacement using SD cards
• A range of IDE adapters, from basic DIY to ready-made interfaces

But the Top Stuff (IMHO) comes from Lotharek in Poland. I already knew him from his Atari ST products, and his XL developments are just as good as it turns out. The man's a true retrocomputing hero. I bought:

• The SIDE 2 cartridge, which basically adds a Flash ROM with SpartaDOS, plus a CF card that is used as an IDE hard disk, plus a games loader to bypass SpartaDOS. There's even a real-time clock in there.
• The Ultimate1MB board. It adds 1024K of RAM to the XL, and also has Flash ROM on board to add 4 operating system ROMs, and a full SpartaDOS. The latter doubles up what you have in the SIDE 2, but the combo of Ultimate and SIDE 2 truly converts your XL into a growling, prowling supercomputer. 

Add RAM: Installing the Ultimate1MB

You learn from others' mistakes they say. So, er, pay attention to mine if you plan to install an Ultimate1MB. 

The point is, the hardware is truly excellent, as it always is with Lotharek. But the manual is kind of limited. The installation PDF describes the electrical steps to take, but not how to physically fit the board into the cramped innards of the 600XL. Electronically, it's simple. Especially with the 600XL, which has all ICs socketed. You pop out the OS ROM and the MMU, and replace them with ribbon cable connectors that go into the Ultimate board. Then, 4 wires need to be soldered to pins on the 6502.

So far so good. Well up to that point.

1. The placement of the original U1MB

But hovering the U1MB board above the 600XL, I wondered where to place the board. On the internet I found the picture to the right (source here), of the U1MB in a very logical spot right above the OS ROM. But the problem was, Lotharek's cheaper ribbon-cable-to-chip-socket converter adds too much height to the board. If you mount the U1MB above that, the box will not close anymore.

OK, the solution comes upfront. The original version of the U1MB was made by Candle O'Sin, and he used flat connectors. And yes, then it fits as described. See the picture archive here (link). The second version from Lotharek uses more bulky connectors, but Lotharek solves that by recommending you remove the RF box. That creates a beautiful open space on the motherboard, where the U1MB softly lands.

2. The placement of Lotharek's U1MB version

As the second picture illustrates, this alternative placement location is the one to go for with Lotharek's version...

Aargh. But you gotta know about that new placement. Actually not knowing that, but equipped with my nice new desoldering gun, I did what every Man With A Tool does: use it! Without hesitation! So I sucked out the chip socket for the OS ROM, cut the ribbon cable in the right way and soldered it straight onto the motherboard. Rather impressed with my own handiwork, I was wondering about the "almost no soldering involved" claim from Lotharek... until I stumbled upon an AtariAge thread with pictures of the new recommended location for the U1MB in 600XLs.

Oh well. See my own pictures below. Mine looks nice as well, no? Why take the easy road if there is a hard way to success as well...

<pictures forthcoming>

Harumph. By now, my Journey into the XL starts to show me more about my sloppy hardware skills than about the actual darn computer. But then, I flick on the 600XL and I'm greeted with the U1MD's startup screen! Aaaaaah. I knew it.

One thing I should still add. There are these 4 wires to solder to CPU pins. The picture below shows where you can find vias on the board that correspond to the CPU pins. Nicer not to solder on the 6502 Sally CPU directly! Source of the picture below is here (link). Zoom into it and the solder points are labeled in yellow.

Add storage: the SIDE 2

The SIDE 2 is the latest in a range of devices that lets you add IDE drives or CF cards (electronically, they are close to the same thing). But it's probably also the nicest. Flip the on-board switch to the upper position, it is a simple games loader. It loads & runs .XEX program files. And in combination with the U1MB it also mounts & boots .ATR disk images. Software exchange with your PC thus becomes trivial: you save the files from the comfort of your PC, then pop the card into the SIDE 2.
As I never was much of a gamer, flipping the cartridge switch to the lower position makes things more interesting. The XL now boots into the SpartaDOS X rom, which comes provided with a batch of utility programs on the CAR: romdisk device. The equivalent of Fdisk, conveniently called Fdisk as well, can be used to set up partitions. These are not compatible with your PC, so if you want to use all features of the
SIDE 2, you first create 1 FAT32 partition for file exchange with your PC (for use by the SIDE 2 loader, not SpartaDOS) and then any number of partitions for SpartaDOS use. If you are handy, adding a FAT-16 partition seems to be a good idea too because that can be read through special drivers in SpartaDOS.

One thing that got me was the settings on the U1MB config screen to accommodate the SIDE 2. Main thing: the PBI device address was defaulted to 7, but should be set to 1. All other settings are like they are on the picture to the right. Yes. That is a Commodore monitor. Forgive me.

Using an emulator to access SpartaDOS partitions on your PC

Because SpartaDOS partitions cannot be read/written by your PC, file exchange with the SpartaDOS world is not immediately possible. But what you can do, is use the excellent Altirra emulator to read and write to disk image files, that you move to/from the physical CF card with either win32diskimager or dd. Because the emulator does allow you to mount .ATR disk images at the same time as the disk image partition, it becomes the file exchange mechanism. I follow the same approach for my Atari ST, with Ultrasatan and Spectre Macintosh hard disk images.
Altirra is a pretty up to date emulator for the 8-bits Ataris. It emulates both the U1MB and the SIDE 2, if you feed it with the right settings and the right ROM images.

And thus the journey begins...

I've now set up my Atari 600XL the way I like it: vintage computer, but no hassle with floppy disks. Time to explore both the very impressive SpartaDOS X and the dozens of good development tools and application programs. To be continued!

Sooo... we had the first meeting of our brand new local Vintage Computing group in Lucerne, Switzerland on January 15th, and it was really nice. At least, I think it was really nice because it was about the N8VEM and Homebrew Computing. That makes it very nice by default. But there was a great atmosphere and some surprisingly interesting Vintage Computing people to meet!

The next two meetings will be:

February 12th, on replica's like the microKIM, the Apple-I replicates and it looks like, a PDP-8 replica.
We'll also be reviving somewhere between 0 and 2 sickly KIM-I's depending on technical skill, time and spare parts availability.



March 12th, on hacking the Dragon 32 and 6809 microprocessor goodness in general. It seems an earth-shaking innovation in the Dragon world will be announced that night, and I do not use the term lightly. But there's also going to be plenty of interesting things for people who do not necessarily inhabit Planet Dragon.





More information is on www.vintagebytes.ch . If you are in Switzerland, be there or be extremely square!

A $35 FPGA board that can mimic capable Z80, 6809 or 6502 homebrew computers with serial ports, SD mass storage and even VGA & PS/2 keyboard connectors. Mix and match parts to create the computer you like - all in a simple VHDL file a beginner can understand. Brilliant! A bit like a Lego approach to retrocomputing. It is a great way to learn about programmable hardware, where you can start straight off with something interesting and then can climb the learning curve to extend it. The mind wanders... shall I add a MMU to the 6809? Or add a replica of Cromemco's disk controller so I can maybe, someday, run Z80 Cromix on this thing?


I had been wondering how it would be to create a Lego-like box of vintage parts in VHDL and make it into a sort of virtual electronics kit. But in retrocomputing, you have boys, men, Great Men, and then you have Grant Searle. He actually did it, and I stumbled upon his project site a few weeks ago.

There is little to add to his site, so this post is nothing more than how I replicated his project. His site is here: http://searle.hostei.com/grant/Multicomp/index.html

This 1-day project turned out to be a introduction in VHDL, sure, but also a lesson in the economics of deflation. It is amazing how cheap stuff is these days. Here is my Bill of Materials:

• $23.59 Cyclone II dev board: example at DX (link)
• $15 Altera USB blaster, that's including shipping cost: example at Hobby Components (link)
• $1.63 (x 2) for two TTL to RS-232 mini converters: example at DX (link)
• $2.51 for Breadboard wires: example at DX (link)
• $2.56 for a SD card connector board: example at DX (link) although I used one from my old parts box.

Grand total of less than $47... Add a 128K SRAM, two DB-9 serial connectors and a 5V wall wart from the spare parts box, and that's it! You do not even pay shipping costs at DX.com. So ordered, waited two weeks and once the parts came in, picked up a cardboard box from the bin to put it together temporarily. This is the glorious end result of an evening with the soldering iron:


What's to see here? To the right of the FPGA, there is a 128K SRAM chip ($3 or so) that is connected to the dev board. Below is a TTL-to-RS-232 board containing only two readymade converter board with MAX232s on them. To the left, a SD card connector.

The funny thing is that it takes so little effort. I used the single Female-to-Female breadboard wires by cutting them in half. The wire end then gets soldered to the little SRAM or Serial perfboard, the other end has a neat connector to plug into the dev board.

So:

• What does it do? Well, at the moment, it runs CP/M with a 10MHz Z80 and 128MB of mass storage. For a further $3 or so, I can add the VGA and PS/2 connectors so it does not need a serial terminal to operate. 
• What can it do later on? Teach me VHDL whilst working from a starting point that I find interesting. Develop things like MMUs, so I can port OS/9 perhaps. Understand the inner logic in a UART.

Whatever. It is extremely Cool, so many thanks to Grant for this project! I hope it will become the launch platform for many interesting homebrewing hacks.


UPDATE:

I made a disk image with all major CP/M software for the FPGA Multicomp. You can find it on my main site, here: http://obsolescence.wix.com/obsolescence#!multicomp-fpga-cpm-demo-disk/c1fom


UPDATE 2:

It was time to put the Multicomp in a proper box. Here's how it looks now - and with the DIY done, it is time to dive into VHDL...


Inside, a lovely Homebrew mess of wires. The Homebrew look is not intentional - it just reflects my skill set. To my defense, I only wanted to use parts that were already in the junk box. For instance, I chopped off a VGA cable rather than order a VGA connector.

About a year ago I bought a fully loaded IIe for almost nothing. Despite some prejudice dating back to childhood, I found the Apple II actually very, very enjoyable! Something to do with solidity, decent expansion slots, interesting add-on hardware and very nice software. So I liked the machine... only for the power supply to develop trouble within a few days. It could only drive one expansion card. Any more load, and the power supply started clicking - no boot.

I simply bought another IIe, because strangely, that's much cheaper than buying just a spare IIe power supply off eBay. But it is not really a solution, just the addition of another machine to the collection. The first IIe looked very sad in its box (aw, puppy eyes), so I finally gave in and attempted a repair.



There is plenty of information on how to repair Apple II power supplies, and I turned out to be lucky. Mine was an Astec 240V version, and these do not need any drilling out of rivets to get to the insides. They can simply be opened by removing screws on the side.

Spotting the problem

A quick look inside delivered an immediate suspect: capacitor C13 has a bulging top. In 3D it's more obvious, but even on this picture the problem is recognisable.





But wait, there's more - RIFA filter caps on the other side of the PSU. I know these things. They spilled their guts all over my beloved Superbrain last year, my Apple Quadra still stinks of their goo, and they are now at the point of cracking up in my Mac Plus. I hate these things. They have to go, whatever principles are discussed below.

 

 

Vintage Computing repairs: the Battle Of Beliefs

Strongly held conviction, which I picked up from a couple of Grumpy Old Men with decades of real EE knowledge:


But then, these days the Vintage community is full of young hipsters, who feel they have to 'totally recap' any old board they put their hands on. Off go all the electrolytes, because they are all supposedly sure to be completely off-spec and waiting to explode... I think that's a hype. But try it: post a question about a stuck key on the Vintage Computer Forum, and before you know it some Recap Kid will,er, like totally recommend you to recap the board, dude. If you ask about a possible RAM error, same thing, man. Recap.

Humbug. So let's see who's right here... to the left, Grumpy Old EE with the conservative approach. To the right, Beavis and Butthead - totally recap, dude. Time for an experiment.


The scietifically robust experiment: I decided to recap the whole PSU and check the state of the removed 15 or so caps. Would they be so degraded as the Recap Kids claim they all will be after 30 years? Let's see...

An order to Farnell was quickly made - shockingly, the price for 16 medium quality caps plus shipping came out well above the price of the entire IIe. Sheesh. But it did arrive within 36 hours, which was impressive.

Fixing the board

Unsolder, remove, stick in replacement, solder. I found a most useful table with the right capacitor dimensions (here, link) so no fidgeting to put in slightly different new caps.

Removing the burst cap showed it had started to leak underneath. So even though it only bulged slightly on top, it definitely looked like the (or a) culprit.


Getting the PCB out of the case's bottom, by the way, is a bit fidgety. The DC power cable cannot (I think!) be removed from its fixing in the metal case. Instead, you have to pull loose the 240V lugs from the on/off switch, and pry the card out of the case on that end. You can then flip the board over, still with the motherboard power cable stuck on the metal casing, and do the (de)soldering.

Lucky! I put everything back together, checked the voltages and booted the Apple with added cards and floppy disks. Everything fine - finally I can enjoy Apple CP/M on the SoftCard!

Proving the Recap Kids wrong?

Yes. So what about the terrible deterioration of old electrolytes? Was their collective mass replacement justified in any way after 30 years of deterioration? Dude?

Not at all. According to my humble-but-trustworthy multimeter, they were all within 15% of original specs. Actually, even the RIFA filter caps did not show their usual slight cracks in the transparent plastic case.

So I call that 1-0 for the Grumpy Old Men versus the Recap Kids. I just wasted 15+ dollars on replacing perfectly good caps with perfectly good other caps. Listen to the experience of the classical EE types, not the Recap Kids. I like that outcome.

But, errr... look more closely at the second-last picture above. Hmmm. Maybe the score is undecided, for now. Darn. I hate it when a story develops a nuance mid-way.

The main problem with collecting computers is finding a place to actually keep them. Here is my solution to this common problem: IVAR racks from IKEA.

My previous storage solution dates back from ten years ago. It amounted to an initial claim on half our guest bedroom. As the collection grew, the other half of the guestroom slowly filled up with CP/Ms, NeXTs, and Apple IIs too, making it increasingly hard for guests to get to their bed or accept our sincere hospitality.

Poorly constructed shelving put an end to this embarrassing situation. Or maybe it was the excessive load put on the wall-mounted shelves, who knows. Point being, the top shelf gave in, and a cascade of collapsing shelves brought everything to ground level. Bad.

So, time for a New Vision and a new computer room.

I convinced all family members that it'd be much better for them if I got a dedicated room. Even if it means they have to find somewhere else to do whatever they consider to be their insignificant little hobbies. Having thus alienated my loved ones, I emptied the study room, drove to IKEA and bought a serious amount of IVAR racks.

Being a scrooge means there are only two decision criteria regarding hobby furniture. Maximise the number of accessible computers at the lowest possible cost. Having learned from my Catastrophic Computer Collapse (in which, it seems, no actual computers were hurt but still), there was one new restriction added: reasonable strength of construction.

IKEA's IVAR storage system just about meets the 3 criteria. It's not that cheap. Once you add up all the bits and pieces it was twice as expensive as what I ever paid for any computer (remember the scrooge comment). It's not that sturdy, IVAR shelves come out of the shop with varying deformations (ugh) and I do expect some of them will need reinforcing underneath so as to avoid sagging over the years.

But: maximising desk space was at least achieved. By extending the shelves at desk height (that'll be 80cm up from the ground), there is now 4.8 metres of desk space available. Add a normal desk because I was not allowed to put storage racks in front of the window (jeez) and I stretch out to 6.6 metres of desk/work space and a multiple of that in storage above and below it.

Aaaah. That means I have achieved half of my long-term target by making one trip to IKEA... Here is my new den in almost-finished, almost-full glory:



So, what do we have here? Well:

The Mostly Jack Racks

Jack as in Tramiel. I.e., The Tramiel Era. Starting from the left is a Home Computer rack. The C64 always ready to use, but below the desk level, an Amiga 1000 and C128 are hooked up ready to use too, thanks to a $10 video monitor switch. Upstairs, I can grab the 600XL, BBC Model B, Vic 20, ZX 81 or DK'Tronics Spectrum and plug them in ready to go. Most of them come with modern CF or SD storage so it takes almost no time to get ready to play.

Then, there's the Atari ST corner to continue with the main Tramiel theme. A wee bit awkward but the separate keyboard of the Mega ST means it's comfortable enough for a couple of hours of hacking. Below live CP/M luggables (Bondwell 14, Formula-1) and above, well, that's where some bits and bobs live that you need or cannot throw away. Like a BigBoard (future project), a Mac Quadra 700 and a Signetics 2650 development system from very long ago.

The Multi-Steve Racks

Next to that is rack #3, Apple-related space. An Apple II with all sorts of options lives next to a souped-up Mac Plus with CF-SCSI storage and above are the spares. Apples break down much more often than any other Vintage Computers (an opinion-based fact). Also up there is a NeXT, which I once bought but never loved. There's also a PowerMac 9600 and a G4 somewhere below.

The Steve (as in Wozniak, Jobs) theme continues on the next rack with a TRS-80 Model I in full glory. That'll be Steve as in Leininger. See how I consistently people-theme my collection? Above it live the laptop and handheld collection to avoid too much Steve-related consistency. Things like Poqet PCs, HP200LX, HX-20, PX-4, NEC Starlet, NC-100, NC-200, Psion Series 5, Psion XP, you know. At the top floor there's an Epson QX-10, fast asleep for now.

The Kildall & Sun Rack

Moving one click to the right, we enter CP/M territory. My cherished ADM-3A terminal lives abroad, so there's a VGA-based PockeTerm and my trusty 386DX40 to act as terminals. But above it are the IMSAI, a P112, a N8VEM and N8VEM Zeta, a Multicomp FPGA replica, a MC-CP/M machine, all mostly ready to run. Also here, as they need VGA screens, are a cuddly Sun IPX, a proper Ultra 10 and three useless SunFire V120s. About as cutting-edge as my collection goes.

The Guest Rack

If I ever bring my Cromemco's home, two of them will live here. Until then, it's taken by the Epson PX-8 which once started off this collection. Lovely machine! Also, a Philips NMS-8255 with CF storage, a nice Z80 machine I have not spent enough time with. And parts storage. Amazing how all these tiny little bits add up to a significant volume.

The Desk

Equipped with what you need to keep going: scope, soldering iron, logic probe, lab power supply and all the gazillion tools underneath. Finally they all have a fixed place and I can tinker straight away without any time lost to setting up. A flip-up side desk can double the available surface space for bulky projects. It's only 30cm in width, but can grow to 80cm or 130cm in a flash. IKEA are smart people.


So there you have it. My physical Vintage Computing workplace solution. Finally.

Peter Jennings published Microchess in December 1976. It became the Killer Application for the KIM-I (the first 6502 computer)... a full chess program in 924 bytes of 6502 code! Microchess was a defining moment in early microcomputer development - and also is a work of art, a coding masterpiece. Jennings' own site (link) gives a fascinating account of how it came to be. 

Here is how you can run the original Microchess, using a 6502 emulator, on an Arduino. Either a bare-bones Arduino Uno, or add a LED matrix and dec keyboard to create a portable chess machine...

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

Update October 2014:

See my web site (link) for the end product of this project.
This blog page will remain to provide further background. It provides a stand-alone version of Microchess on the Arduino, instead of a full-blown KIM-1 emulator with built-in Microchess...

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




Imagine it's 1976. Microprocessors have emerged over just the past 24 months. Some guys have apparently written a Basic interpreter and an operating system for the 8080 microprocessor, but their setups cost ten times as much as the new $245 KIM-I, a minimal demonstration computer board sold by MOS to showcase their brand-new 6502. 
Imagine having no assembler, no software tools and no access to information other than the manual and data books... entering hand-assembled hex codes into the KIM-I and creating a chess-playing program in just 924 bytes.

That begins to tell how awesome Microchess really is. Yes, the 924 hex values in the picture are all you need to play chess. Less than 7 tweets could contain all that complex logic...

The original Microchess running on 
an Arduino using 6502 emulation 

I got introduced to the Arduino last month. At our local Swiss vintage computer club, Christoph Haberer introduced his CH2 board, which turns the Arduino into a 4-bit computer (see here and here for details). I joked about his Arduino board being close to the minimal spec of running a KIM-I emulator.

Then I came across a post from miker00lz (link) on the Arduino forum. A 6502 emulator running ehBasic on the Arduino?! I changed about 10 lines in the Microchess source code on Peter Jennings' site to handle the serial port, dropped the resulting hex code in Mike's 6502 emulator and... I got myself a real Microchess-playing Arduino.


Two hardware options

Option 1: The code below will run on a standard Arduino Uno board without any extra hardware.  

You play through the Arduino's serial-to-USB port. But please use a terminal emulator like puTTY instead of the Arduino IDE's built-in debugging window: you need the Return key to work normally.



Option 2: Arduino Microchess uses the CH2 shield if it is inserted to recreate a right proper pioneering KIM-I kind of feel... Meaning you get to see the moves on the LEDs, but for an overview of the board you still need the serial port hooked up. Unless you have an actual chess board on which you keep track.

That's how it was on the KIM-I. However, the KIM-I could show 3 hex digits, the CH2 only has space for one of them on the 5x7 matrix... So the joystick is used to flip up for Hex digit 1, and to flip down for hex digit 3.

If you feel like DIY: why not hook up a LED matrix, joystick and keyboard yourself? See this link for pinouts (forthcoming... for now, see source code for the pins used).

Playing Microchess - Command Summary

---------------------------------------------------------------
|CH2 (Serial)                 | CH2 (Serial)                  |
|-------------------------------------------------------------|
|*7  (C) Clear Board         | 1-7 (1-7)   Keys to enter move|
|*8  (E) Exchange sides       |#   (Return) Register move    |
|*9  (P) Play                 |                               |
|-------------------------------------------------------------|
|Joystick up: see hex digit 1 | Joystick down: see hex digit 3|
|-------------------------------------------------------------|
|*4  (L) Load Board           | *5  (S) Save Board            |
|*6  (W) Blitz play (fast & dumb)                             |
---------------------------------------------------------------

Gameplay is intuitive if you think of it this way:

• Start with C-E-P, or *7 for reset, then *8 to swap sides and *9 to ask Microchess for a move.
  On the CH2 these are all on the bottom line of numbers in their logical order...
  
• If you are lazy, you keep doing *8, *9 to let Microchess play itself.
• Or, you enter your own moves by entering (for example - see further below) 1333#,
  followed by *9 to let Microchess make its next move in response.
• The board is printed on the serial port. On the stand-alone CH2, use the joystick to see:
  (up) the piece moved/to move,
  (down) its destination TO square or
  (middle position) its FROM square.

Some extra functions have been added, based on suggestions in the Microchess manual. These are implemented as interventions on top of the 6502 emulator. Rest assured, no vintage bytes from within Microchess have been hurt in the process. You're running 100% original 6502 Microchess :)

Blitz mode: W, or *6, toggles between normal speed (approx. 100 sec per move) and Blitz mode (approx. 10 sec. per move). Note that the CH2 LED flashes for every step taken during Microchess' next move calculation. So the frequency of flashes reminds you which mode you're in.

Save Board: You can save your game using the EEPROM in the Arduino. This simply saves the current chess board so you can continue playing at a later time. Press S (serial) or *5 (CH2) and then enter the slot number you want to save to - a number from 0 to 9. Confirm by hitting return (serial) or # (CH2) and the board is saved.
Load board: done by L (serial) or *4 (CH2). This retrieves a saved game and allows you to continue to play it.


It took me some time to grasp how to operate MicroChess. But the short introduction below will make it intuitive.

1. Initialise
=============
Enter C for Clear. Actually, at any time, hit C to reset the game.
--> The board is reprinted & bottom shows CC CC CC to confirm.

2. Let the computer play against itself
=======================================
Enter E to make the computer take the opposite side of the board.
--> The bottom line shows EE EE EE to confirm you swapped chairs.
Enter P to make the computer Play its move.
--> Deep thought happens. Every few seconds, a dot appears to indicate
    one more possible move has been thought through.
--> Typically, you'll see 30 or so dots before the computer is done.
    It takes about 100 seconds on a real KIM-I, more or less the same
    on the Arduino.

When the best move has been decided, MicroChess prints out the board again.
--> The bottom line shows its move in 3 hex numbers.
        Hex number 1, left digit: 0 if a Black piece was moved, 1 for White
        Hex number 1, right digit: Tells you what piece this was:
             ----------------------------------------------------------------
            | 0 - KING      | 4 - King Bishop  | B - K R Pawn | C - K B Pawn |
            | 1 - Queen     | 5 - Queen Bishop | 9 - Q R Pawn | D - Q B Pawn |
            | 2 - King Rook | 6 - King Knight  | A - K N Pawn | E - Q Pawn   |
            | 3 - Queen Rook| 7 - Queen Knight | B - Q N Pawn | F - K Pawn   |
             ----------------------------------------------------------------
        Hex number 2 is the FROM square (row, column).
        Hex number 3 is the TO square (row, column).

So you can let the computer play both sides by hitting E, then P, E again, P...

3. Entering your own move
=========================
Instead of hitting P, you can enter the 2-digit FROM square and then the 2-digit TO square. After every digit, you'll see the board reprinted. But focus on the bottom line: the digit you press "rolls in" to the bottom line's Numbers 2 and 3 from right to left. This is a remnant of how the KIM-I uses its onboard LEDs.

After four digits, the move is defined. MicroChess shows the piece involved in Hex Number 1: first digit is 0 for white, 1 for black. Second digit is as per the table above.

Once your move is complete, hit Return to register your move.
--> FF appears in Hex Number 1: you have now moved the piece,
    so FF is there to show that the From square is now empty.

After you've registered the move you can still undo it. Just correct the wrong move by entering four more digits in a correcting move, so that the board looks like you intended it to.

Indeed - this is the fundamental point to grasp: MicroChess does not check what you're doing when you move pieces around. You can move its pieces as well as your own. All you are doing here is rearranging the board for the next round of Microchess Deep Thought. You can make a normal move, or shift stuff around on the board as you wish to create a new situation that MicroChess should play against next. It's a feature, not a limitation!

--> Hit P to make MicroChess Play its next move.

4. Special moves:
=================
Castling: just move the two pieces and hit Return after each one to register them both. En passant: break the move up in two moves. The mid-point being on the piece you'll strike out. Queening pawns: yes. Well. Remember which of your pawns has been Queened and give it the according moves afterwards. MicroChess will not Queen on its side. (It can be done on a Kim-I by leaving the program and manipulating its memory through the KIM Monitor. But no such option in the Arduino version. Slight imperfection).

Further reading on MicroChess

The original manual is here (link). To translate between the Kim-I keys and the keys on the serial terminal: 
      Kim-I key    Arduino Serial port   CH2 Board 
         C       |       C            |     *7     
         E       |       E            |     *8     
         PC      |       P            |     *9     
         F       |       Return       |     #      

Original source code of Microchess for serial terminal: do NOT use http://6502.org/source/games/uchess/uchess.htm . It's an older version with some bugs. Instead, use http://benlo.com/files/Microchess6502.txt .

Changes I made to this source code:
- relocate code to $C000
- hack 6551 UART out,
   replace by $F001 - output character, $F003 - 1=key pressed, $F004 - ASCII code of key pressed.
- the print-to-serial routine added to Microchess uses the PHY instruction which is only present in newfangled 65C02s. I removed it, wasting 1 byte for temp storage in the process.

Original source of 6502 emulator for Arduino: Published by miker00lz on the Arduino forum (link).
Original source code to drive the CH2 board: From Christoph Haberer at github (link).

Just to make sure proper credit is given

A thank-you to the genius of mikeR00lz and obviously Peter Jennings. The code is theirs, the bugs are mine. All I did was recompile Microchess with marginal UART changes, and paste it into the 6502 emulator code.
This is the first thing I've ever done on the Arduino, and I did not bother to clean up after my small-but-ugly hack. It's sufficient for me as it is, because (let's face it) this is somewhat unlikely to go into mass production.

Download the source code 

Get the sources here (link).

Arduino_6502.ino contains the main loop. The 6502 is emulated for 100 instructions, then the Arduino checks for input/provides any required output. Cpu.c is the 6502 emulator from Mike, marginally modified to contain the 1,393 hex bytes of 6502 Microchess (not 924 bytes, this is the deluxe version for a serial terminal!). All the other files provide support functions for the LED matrix and keyboard - sourced from Christoph Haberer's CH2 project.

The source of Microchess with my UART changes is uchess6c.asm. You can compile it with the TASS assembler. I used the HxD Hex Editor to remove the two-byte header from the compiled output and then exported it in "c" format. That's what is pasted in to cpu.c.

KIM Uno. Turning the Arduino into a KIM-1 6502 single-board computer. Why not? Following up on my 6502 Microchess project, here is a reasonably faithful replica of the 6502 KIM-1. It can run either on a bare Arduino Uno using its serial-to-USB port, or use an expansion shield (such as the CH2 board) to add LEDs and onboard keys.

This project is on a blog page for a purpose: it's work in progress. But the sources at the bottom of this page already deliver a walking, talking KIM-1 on your Arduino. Check back for updates if you care.

Operating mode: 3 choices

There were two different ways to use the KIM-1 and the Uno adds a third one, in a way.

The KIM-1 itself had a dual, errr, User Interface:

1. you could use the on-board hex keyboard and 7-segment LEDs,
2. or alternatively, you were possibly rich enough to afford a teletype or - ooh - even a serial terminal. Comfortable ASCII keystrokes were then used instead of the on-board dedicated keys. And of course the KIM-1 could then print text to the terminal, instead of just flashing the contents of 3 bytes on its LEDs.

The Kim Uno offers a third user interface option. On the serial port, it can provide a simple replication of the on-board LEDs and keys without the KIM-1 knowing that it is doing this over the serial port.

Confusing? Option 3 just means that the serial screen only shows the status of the hex digits and a status indicator for single-step mode. Like if you were too poor to own a terminal. We're emulating a 1976 lifestyle, not just a piece of hardware here... This option was useful during debugging and I felt it was Cool to leave it in. To use the serial port in the Teletype/Serial Terminal style as described under (2), just press the [TAB] key and KIM Uno switches to that operating mode.

3 hardware options:

1. Bare Arduino Uno: use a serial terminal (puTTY or some other terminal program) to connect to the Arduino's serial port. By default, the terminal shows what a bare KIM-1 shows: 3 bytes. See picture of Option 3 above. But press [TAB] to reset the serial port to its original purpose in the KIM-1: to act as a terminal (Option 2). Note how you can now print a text string, which is no small technological advance in 6502 computing!
2. CH2 board - add keys and LEDs to the Arduino. The source code for download below supports Christoph Haberer's CH2 board. Plug it in as a shield or alternatively, stick the programmed atMega in the socket onboard the CH2.
   The CH2 offers a decimal keyboard and LED matrix, but both are a bit smallish for the mighty KIM. The CH2 only has 12 keys versus the KIM's 23. So the * key is used as a shift key, and double-pressing it (**) reaches some more KIM key functions. Also, the 5x7 LED matrix can only show one byte at a time. So the joystick is used to flip up and down between the 3 hex digits on the KIM-1. It works well, actually
3. DIY: It is really trivial to build a little board that supports your own KIM-1 key/LED hardware. The software is also easy to adapt to such new hardware, all you need to do is pick up some key presses and send bytes to your LEDs. Something with 22 or 23 keys and a slide switch plus 6 7-segment LEDs is ideal. Once I'm done with the software side, I'm going this way too.

How to operate the KIM

The KIM's monitor program is pretty user-friendly. That is, once you understand it. To the right is the KIM's original keyboard to start off the quick introduction below.

To start, enter [AD] 0 2 0 0 on a real KIM-1 (Ctrl A0200 on the KIM Uno)

• Hitting [AD] (Ctrl A) puts you in Address Mode. In other words, you type 4 digits to select any address in the KIM's memory.
• You now see that address 0x0200, which is where you normally start your user programs, holds the value A5. Search for $A5 on this page, which is a great way to learn 6502 coding. A5 is the code for LDA...

 Now enter [+]  (+)on KIM Uno)

• The Plus key just increases the memory address by one, so you can view the next byte. This way you can step through memory to look at it.

Now enter [DA]A5 (Ctrl DA5)

• [DA] puts you in Data Mode. Instead of your digits ending up to form an address, they now form an 8-bit value that can be stored in the memory address shown in the leftmost 4 hex digits. As you typed in A5, that'll overwrite the old value.
• Hit [+] to go to the next memory address, enter two digits, save them with [+], two digits, [+]... this way you can quickly enter a program that you may have assembled on your PC or whatever. By the way, a good interactive, online assembler to quickly cook up code is here (link). Just write the assembler code, hit Assemble button on the middle of the page, and start entering the byte codes at the bottom of the browser page into your KIM. This is more user-friendly than emacs!

Hit the Arduino's Reset button. Or if you have an Arduino without Reset button, power down & up.

• This is just for restoring the demo program that KIM Uno boots up with in 0x0200-0x0209, it might have been damaged by your tinkering just now. The stunning little demo program included at no extra cost in your KIM Uno is the very first program from the First Book of KIM. It swaps the value in 0x0010, which happens to be 0x10, with the value in 0x0011, which happens to be 0x11.

Enter [AD] 0010 (Ctrl A0010)

• Observe address 0010 holds the value 10. Hit +. Notice 0011 holds the value 11. Hit 0200 to go back to 0200 again. You'll see 'A5' again.

Press [GO] (Ctrl G)

• The program runs and the address shown afterwards is 002A, which is the first byte after the program's end.

Press [AD]0010 (Ctrl A0010)

• 0010 now holds 11 instead of 10, and if you hit +, you'll see 0011 holds 10 instead of 11. Indeed: the values have been swapped by running the program.

Slide the SST switch to ON (on the KIM Uno, hit the ]  key).

• type 0200 to go back there, you're still in Address mode. Press [GO] (Ctrl G) and notice that only the first instruction is executed. The display now shows 0202 A6, which is the address and code of the following, second instruction (LDX). But to further inspect the CPU state after the initial LDA instruction that you just executed, you can also explore the following memory locations. They hold a copy of the CPU registers after running that first instruction just now.
  So press [AD] (or CtrlA) 00F3 and see that the accumulator holds 0x10, etc. You can also edit these stored register values using the [DA] (CtrlD) key.

                    00EF = Program counter Low byte
                    00F0 = Program counter High byte
                    00F1 = Status Register (P)
                    00F2 = Stack Pointer (SP)
                    00F3 = Accumulator (A)
                    00F4 = Y Index Register
                    00F5 = X Index Register

Press [PC] (Ctrl P) . This will show you the program counter is still at 0202, ready to execute the second instruction. Hit [GO] (Ctrl G) to execute it. Keep hitting [GO] until you are at program end (0208).

Get out of SST mode by setting the slide switch to OFF (key  [  on the KIM Uno).

Above, you've gone through the entire programming interface of the KIM. Congratulations, all you need to do now is memorise the 6502 instruction set in byte code, using this page to search for mnemonics and byte codes. Or if you are limited in free brain memory, use this page as an assembler and type in the byte codes it generates for you.

Oh, you might wonder about a few things:

• you can stop your program using the [ST] key, where ST stands for STop your program and in the ROM source code, it stands for STart the monitor. On the Kim Uno, [ST] is Ctrl T. It could have been Ctrl S, but that might be interpreted by a terminal program to stop updating the screen. T comes after S, so Ctrl T is sTop.
• the [RS] key (Ctrl R) is a normal Reset button. Note that it will not erase memory, and in fact leave many other settings like they were before. But you enter the KIM Monitor this way if the [ST] key is not strong enough. By the way - [ST] triggers a NMI, and [RS] a RST signal to the 6502.

• how to set break points like a debugger provides? Simple: enter value 00 (for the 6502's BRK instruction) in the address you want to generate a break point at. Do not forget to note down the original value in that byte, and put it back afterwards. Value 00 is the BRK instruction, and it drops you in the KIM Monitor just like Single-Step mode does. So inspect the CPU registers, change them as you like, and hit [GO] (Ctrl G) to continue. But remember you nuked an instruction by overwriting it with BRK. Real KIM Progammers used to enter a NOP instruction at points where they thought they might like a break point at some future point.
• The above description assumes you are using the onboard LEDs and keyboard (or their emulation thereof on the KIM Uno on the serial port, Option 3 mode). If you use a serial terminal on the real KIM-1, or hit [TAB] on the KIM Uno to use the serial port in Option 2 mode, the keystrokes are a bit different. Read the KIM-1 user manual below - and remember to have Caps Lock on.

That's it. It used to be simple with computers, once upon a time. For further reference, read/use:

• the KIM-1 User Manual
• the First Book of KIM
• Andrew Jacobs' 6502 Reference web page holds all 6502 mnemonics, their functions and byte codes in the best possible way. Use your browsers Search function to get around the page. 
• Mass:werk's online assembler gets you from assembler to byte code very fast. In case you do not know 6502 byte codes by heart and do not care to change that.

 

Loading and saving programs to Eeprom - or use 2K of RAM

The 1K EEPROM in the Arduino is mapped as the second K of RAM. Any access to addresses 0x400-0x800 goes through to the EEPROM. You can either use it as extra RAM memory (it will be a bit slower, but not noticeably so for most things), or use it as a space to save your work. I.e, copy your program at 0200 to 0400. For writing to work, press the '>' key to toggle between R/O (default) and R/W Eeprom access. Write protection seemed useful because although there's at least a hundred thousand write cycles in the Eeprom, you can wear it out eventually.

Loading and saving programs to your PC

In serial mode (ie, Option 2, press [TAB] to go there), saving goes as follows: store the end address in 0x17F7 (upper byte, i.e. 02) and 0x17F8 (lower byte, i.e. FF). Now go to the address that is the starting address (0200 most likely). Press Q and a data file will be sent to the terminal. You can copy it, or capture it to a text file. For all the KIM knows, it has just created a paper tape...
The command L allows you to upload a file into the KIM-1. Just press L, the KIM will wait for paper tape data so let your terminal program send the file. In Windows' HyperTerminal: Transfer->Send Text File.

Keyboard templates

The chart below shows the original KIM-1 keyboard, and the corresponding keypresses on the CH2 (top) and on the Serial port (using Option 3! For Option 2, please refer to the original KIM-1 User Manual). It may be handy to keep at hand:



Similarly, if you are using the CH2 shield, the chart below shows how the keys of the KIM-1 are mapped to the CH2's decimal keyboard. You want to keep this close to hand when learning to use KIM Uno on a CH2!

How KIM Uno works

The KIM-1 basically consists of a 6502, two 6530 RIOTs and 1K RAM. Each 6530 contains 1K of ROM, 64 bytes of RAM and I/O & Timer ports.

Just like I did with the Microchess project, I'm using Miker00lz 6502 emulator. I added the KIM-1 ROM code into its memory map, added two 64-byte RAM spaces and of course 1K of Arduino RAM is used as main memory.

Having done that, I needed to replicate the functionality of the I/O and timer ports on each of the two 6530s. The current version of Kim Uno is very lazy. The timers respond with TimeOut at any time. And the only IO port that works is SAD, which just responds with 0x01 to indicate the KIM's ROM should use the onboard keys/LEDs, or (after pressing [TAB]) with 0x00 to indicate the user wants to use his serial terminal. (* note: even if 0x00 is given to tell the KIM to use onboard LEDs, the emulator can still reroute this over the serial port. That's the Option 3 thing.)

Although the above approach to I/O (non)emulation disqualifies me as a proper emulator programmer, the lazyness has almost no impact on functionality. The emulator intercepts calls to the screen and keyboard routines in the KIM ROM, and does its own screen/keyboard I/O in a way invisible to the ROM.

Almost 40 years after the original KIM-I, there must be something improved in the KIM Uno? At boot time, a demo program is loaded into 0x200 for immediate gratification purposes. Also, the NMI and RST vectors at 0x17XX are set during startup. You used to have to do that manually every time to make BRK and SST work.

Proper credit where it is due

Like with the 6502 Microchess project, the bulk of the source code consists of Miker00lz's 6502 emulator, and Christoph Haberer's code to drive the CH2 board.

Download latest source code

Get the source code here (link). (It's Google Drive, so use File->Download to get the whole ZIP file). I spent three days (nights rather) to combine them into KIM Uno. So do not expect beautiful code, it's working code... Please note that the KimUno directory contains the code for the Arduino. The KIMPC directory is just the core code wrapped in a C project for test running on a PC. Cpu.c is the main file, identical for Arduino and PC. The only difference is the #define AVRX put in to compile for the Arduino, or left undefined for standard PC compilation.

• Use puTTY, not the Arduino IDE's serial monitor.
• Use Caps Lock on the Serial terminal
• Planned next: load option for some demo programs downloaded from Arduino Flash

Note! When uploading the code to the Arduino, the IDE will moan about a verification error. Ignore it, it is not your Arduino's fault, nor is it mine. It's a bug in the Arduino uploader that gets confused by too many 0xFF codes in a row, see here for an explanation. Anyway, ignore, all is fine.

Future plans

1. It would be nice to properly emulate the 6530 timers. It may not be of much use, unless you want to use a tape drive, but still. Note that the serial port might just as well keep at 9600 bps hardcoded as it presently is. But see point 3, there it gets useful.
2. There should be a simple menu function where code can be copied from and to one of 10 memory slots in Flash - there's plenty of memory to burn some KIM programs into ROM.
3. Lastly, it's easy to solder up a board that contains a replica of the KIM keyboard (23 keys, a slide switch) and 6 segment LEDs. Plus a 74LS145. It could be hooked up to the Arduino in such a way that the original LED and keyboard routines work without intervention by the emulator core. The schematic can be taken straight from the KIM's manual (click to enlarge).

This blog post is a work in progress. Upfront summary:

Goal: produce a KIM-1 replica for less than $10 all-in.
 
After getting a KIM-1 emulator running on either a bare Arduino Uno or the CH2 board (see previous post) it really was time to learn about producing PCBs and become a KIM Clone Manufacturer.


This blog page will be kept in place because there are some links to it, and it gives some additional technical information.

Design idea

Although the KIM Uno software runs fine on a basic Arduino Uno, having to use the screen and keyboard of a modern PC is not terribly Retro. Because the Arduino's atMega328 has I/O features that are close to those of the original KIM-1, why not produce a PCB to make a proper modern-day KIM-1 mk II? Instead of the KIM's second 6530 I/O functionality, implement an SPI and I2C interface to play with modern gadgets. That results in a calculator-sized KIM-1 which can play with lots of hardware (and can double up as a 6502-based calculator, but that's an idea for later).

Update, August 14 2014:
And it works! I got the boards back from the factory and here is the walking, talking KIM Uno. I want to polish up the software (add a calculator next to the KIM-1 emulation, include Microchess and some utility software, there's enough space in the atMega Flash) and then I'll make a proper update:


Update, June 30 2014:
Returning from holidays I made some changes to the schematic discussed below. The board will have a KIM emulation mode with a 6-digit screen, but flip to 6502 Calculator mode where it uses all 8 digits and the decimal point. You really need that for calculator mode... This uses up all I/O pins of the Arduino Mini Pro; but when the keyboard is not scanned both an SPI and I2C "expansion port" can be used. Board size is now 6x9cm.

Update, August 1:
Board sent off to Seeedstudio for a test run of 5 pieces...      
.

Schematic - considerations

The KIM-1 has an ingenious schematic to scan a keyboard with 24 keys, and drive a 6-digit LED display with mostly the same I/O pins, flipping them from input to output mode. In short:

• The keyboard is wired as a matrix of 4 rows (4 output pins that are switched on sequentially) driving 7 'column lines' each connected with a switch. So 7 input pins are used to sense one of 7 keys, sequentially scanned in 4 rows to create a maximum of 28 keys on the keyboard). 
• The LED display uses common anode segment LEDs. The 7 input pins used in the keyboard now flip to output mode, and then act as cathodes for the 7 segment LED to shape a legible digit on one of the segment LEDs. Because there are 6 segment LEDs, 6 pins are used to multiplex - light up each LED briefly in sequence. 
• Cycle fast enough between lighting up each of the 6 LEDs, do the keyboard scan quickly in-between, and the human eye will see a continually lit-up LED display and a responsive keyboard.

The original schematic is shown here in the KIM-1 User Manual. It is very attractive to replicate this schematic in a KIM-1 remake. The original schematic is beautiful in its simplicity, and with the atMega's extra driving power can be simplified to exactly fit the Arduino's I/O space. The following Arduino pins are used:

• D2..D8: Column pins used to sense keyboard and to select the LED segments
• D9..11: keyboard rows 0,1 and 2
• D12, D13, A0..3: LED digit select lines
• A5: keyboard row 3

Adding I2C to the KIM Uno as an option

On a basic Arduino Uno, the above leaves A4 completely free. And actually, A5 is only used for output to a sense line consisting of a column of keys. Nothing gets hurt if another output purpose is fulfilled by A5 when not scanning that row of keys. This is nice, because A4 is the I2C Data line (input/output) and A5 is the I2C clock line (output only). So the KIM Uno can have an I2C expansion interface adding more fun in the future.

Schematic

The above leads to the following setup, drawn up in Kicad (click to enlarge, click here to download Kicad project). (**note: download link is to Google Drive, meaning you have to select File->Download to get the whole ZIP file)

 Fitting in with the minimalist approach of Arduino, and with minimising cost to a bare minimum, only 11 resistors and 2 four-digit segment LED blocks are needed:


When compared to the original KIM schematic:

8 led digits of which only 6 are used

Of course, the second Segment LED could be a 2-digit one instead of a 4-digit one. The KIM-1 only has 6 digits for its display. But although using a second 4 digit block is wasteful (only 2 of its 4 digits are used) it turns out to be cheaper in my parts-scouring so far.. how bizarre.
Even though only 6 digits are used by the KIM-1, it might be useful to have 8 digits. There could be a flip mode where you can switch over to this thing being a calculator, for which you do need the 8 digits. There's some very historically significant 6502 calculator code it could run (see here and here). And that would make this gadget more useful in daily life!

No need for the 74LS145  in the original KIM-1

1000 ohm resistors strongly limit the current flowing from Arduino pins through the LEDs. The current driving the common anodes (the led0..5 pins) is 30mA, well within the maximum of 40mA allowed on Arduino pins. As luck would have it, this leaves the small segment LEDs bright enough to be clear, but eliminates the need for driving transistors as seen in the original KIM-1. Calculation to verify it (and verify no Arduinos are hurt in the process):

I = (Vcc - Vf)/R  = (5.0 - 1.2)/1000 = 3.8mA per LED segment.
7 led sedments * 3.2mA = 26.6mA load on common anode pins (led0..5)

I hope my calculation is correct - any calculation I make is bound to be incorrect in practice (being trained as an economist, this is both a joke and the truth) and what do I know of EE? But checking the current in multiplexed practice with an ammeter indicated 14mA. Assuming a very conservative 50% duty cycle in my LED-driving code that's 28mA. It sounds safe to me, but I'd like to hear comments!

No need for inverter ICs in column lines

Lastly, the KIM-1 uses inverters between the keypad (pins D2..8 in input mode) and the LED segment cathodes (the same pins switched into output mode). This, too, can be economised away as the atMega328 has enough strength to sink the current of the LED cathodes. The consequence is that the schematic inverts the signals on the input pins (LOW means key pressed, rather than HIGH as in the original KIM-1). That is very handy: the atMega 328 has internal pull-ups to High - so no additional pull-ups are needed to create a defined state for the input pins in case no keys are actually being pressed. It does of course mean that the emulation code needs to invert all signals before presenting them to the KIM's ROM code when it queries the emulated 6530 RIOT registers. But that is trivial.

Finding the cheapest Arduino or atMega328 

Arduino Mini Pro: Size of a 24 pin DIP

Part of the fun in this project is to arrive at minimal building costs.

To my astonishment, a complete Arduino Mini Pro costs just $2.59 on eBay... less than a single, separate atMega328P-PU chip. Using the el cheapo Mini Pro also eliminates the need for the crystal and capacitors you'd need to bring on board when using a separate atMega328 DIP IC. Nice!

By putting the Arduino Mini Pro at the bottom of the PCB, underneath the segment LEDs, a lot of PCB board space can be saved, bringing the size to just millimeters below the 5cm * 10cm size for which you can buy 5 boards for $19.90 at Seedstudio. Nicer!


One other benefit is that the Mino Pro's programming header can double up as serial interface and power supply connector, elegantly (IMHO) at the top right corner of the PBC. All dealt with for $2.59... Nicest!


Some struggling with Kicad resulted in this draft PCB layout.

Note that this is only v0.1.

• I should make use of the additional two I/O pins that the Mini Pro offers (A6, A7). which might open up the possibility of adding a 4-pin SPI rather than a 2-pin I2C interface, which means more available devices. 
• Note also, A5 is not yet wired up. Draft.

   

A prototype to try it all out

I spent the last two nights soldering a prototype together to check the schematic and - especially - the real-life load on the Arduino pins. Rather than using the Arduino Mini Pro, I hooked up an Arduino Uno for the moment. Although wiring up a 24 keyboard matrix was tedious at best, it worked!

The source code (downloadable here) at present is a derivative of the code used for the bare Arduino Uno board. It does not yet emulate the 6530 RIOT registers, but intercepts the ROM display routines instead.  
(**note: download link is to Google Drive, meaning you have to select File->Download to get the whole ZIP file)

Cost

The game for me was to see if I could build this, in a volume of 10 pieces (which according to me is global demand for this less than innovative low-tech computer), for less than $10.

So far, the Bill of Materials looks as follows:

1. PCB at Seedstudio: $19.95 for 5 pieces, or per board:     $3.99
2. 2 4-digit 7-Segment LED blocks of $7.99 per ten:            $1.58
3. 11 resistors                                                                       $0.50 approx
4. 23 PCB switches                                                              $1.00 approx
5. Arduino Mini Pro                                                              $2.59

That's $9.66 in total! Maybe some extra shipping cost from Seedstudio, but that's it. Amazing, the combined power of Arduino and Chinese manufacturing...

Next steps

• Gather some critical inspection from more experienced people, 
• finalise the schematic by using the Mini Pro's A6 and A7 pins,
• order the boards,
• write new emulation code that replicates the 6530 at IO register level rather than at ROM code level. It does not matter in real life, but is more authentic underneath.
• add a Calculator Mode that uses ether the vintage Huey 6502 math code or CR Bond's more advanced code.

Vintage Computer Festival - 

18 & 19 October 2014 - Winterthur, Switzerland

The very cool people of VCFe have decided there will be a repeat of last year's Vintage Computer Festival in Winterthur.

Thanks guys! Looking forward to it. Maybe I can have the World Premiere of my new KIM Uno there :)

Be there, or be terminally square.

Here is the flyer I just got. I guess more news to follow.

Of all the PDP-8s, the 8/I is my favourite. Alas, getting a real one is impractical: they are pretty much impossible to obtain, and just as hard to maintain once you've found one. But asI learned from my $15 KIM-1 clone, making a replica is a good way to get involved with the inner guts of a vintage machine too. The idea of the PiDP-8 is to make it an open-source hardware project again. So here I go... work in progress, comments welcomed.

First completed prototype as of March 30, 2015

Note: below is the development blog in all its gory detail. 
The permanent web site for the PiDP is slowly but surely emerging here (link).

Introduction

The picture to the left shows the state of affairs in early January. Shown on top is the front panel artwork, made translucent in this picture to reveal:
(a) the PCB behind it - mostly visible in the dimmed LEDs, and
(b) a real PDP-8/I front panel behind that - mostly visible in the lit LEDs.

The front panel is pretty much a pixel-perfect clone of the original, with one notable exception: I chopped off the leftmost part of the original, which contains no operating components.

13 Januari 2015

As I looked around for the bits and pieces that I'll need for the PiDP, the last few weeks have crystallised what I want, and what is feasible. The hardest part is always to settle on the compromises you can accept, given the budget you want to work on. To me, a low-cost kit is far more interesting than a no-compromise $1000 replica.

From the cosmetic side, these are the points I've settled upon:

• switches: for a PDP, switches are everything. The original ones for the 8/I are not available. I've settled upon the kind of 120V/240V toggle switch you normally use in wall-mounted light switches. They don't cost all that much, have the right proportions and have a nice tactile feel to them.

Switches... Original 8/I switches on the left (although different in colour). On the right, the budget alternative. Not authentic, but nice and cost-effective. Design Choice #1 is made...

Lining up some of these switches to see how they'd look on a front panel.

• scale: a real 8/I is the width of a 19" rack. In the end, the size of the switches I selected determined the scale of the replica overall. A real 8/I has switches of 1.5cm in width. The switches I selected are 1.0cm in width. To make everything in proportion, the replica is downsized 2:3 versus the original, and is still comfy to toggle on.

• front panel: getting a front panel machined from a specialist shop is very very expensive. The alternative: photos printed on acrylic. An acrylic panel where everything that's supposed to be white is left transparant. I'll have to glue a white paper mask behind it (to let the white lettering come out) but cut-outs from the mask will show the LEDs on the (black) PCB behind it. I'll probably add some 35% black pattern as shading on the front panel above the LEDs.

On the electronics side, this is a very straightforward project. A microcontroller runs one of the existing PDP-8 emulators, and a front panel PCB is attached to the microcontroller to contain the LEDs and switches.

• schematic: I took the schematic idea from my KIM Uno project. In one sense, a KIM-1 does not differ too much from a PDP-8/I front panel. The 8/I has 26 switches, the KIM-1 has 24 keys. The 8/I has 92 LEDs, the KIM-1 has 49 segment LEDs. The multiplexing logic of the KIM Uno just needs some added rows and colums for extra LEDs.
   
• PCB design: A row of 26 switches requires at least 26cm in board space. Round that up to the nearest standard PCB size, and you end up with a 30cm board width. And, as it turns out, reproducing all the LEDs in the right place demands a 10cm height. The PCB is an unsophisticated thing: 92 LEDs, 26 switches, and a bunch of resistors to control LED brightness. As the microcontroller I chose has fairly weak outputs, I put a UDN2981A in-between to take the load off the MCU. And to avoid 'ghosting' of switches, which is a problem with matrix keyboards, every switch needs a diode in line with it. Lots of parts, but the cost is only a few cents for most of them.

  PCB front (LEDs and switches) and PCB back (with the RPi GPIO connector top right).

  .
• Microcontroller choice: the original idea was to use a Teensy 3.1 with Bill Haygood's emulator.
  ARM core, 96K RAM, it would have sufficed. Except that it proved a very tight fit. Because 32K of the PDP's 12-bit words end up taking 64K of 8-bit RAM; packing 3 PDP words in 4 bytes is too cumbersome.
  
  So I looked around for the cheapest alternative. An Arduino Due would do it, but the Raspberry Pi B+ was more attractive. Not much more expensive at $35, and it has all the connectors on-board already. SD drive, HDMI for the terminal, USB ports (USB sticks will act as floppy disks and as the paper tapes): as an all-in-one package it makes sense. Plug it in to the front panel PCB through its 40-pin GPIO connector and that's it. Even though it's more a microcomputer than a microcontroller. Accepting a Raspberry Pi also meant I could use the brilliant simh as the emulator core - which I believe is the most competent PDP-8 emulator around.

The software part has not fully matured yet:

• simh compiles and runs fine on  the Raspberry Pi. But I need to insert the code to update the LEDs and scan the switches. So far, I've experimented with adding a parallel thread to simh which just sticks the PDP-8 registers into the GPIO pins every 5ms or so. That works fine as a test (see 16 January entry below), but:

1. Linux is a bad choice for real-time programs. Multiplexing 8 rows of 12 LEDs each is simple enough on an Arduino - microcontroller software has no problem with flashing each LED row fast enough so that the human eye does not notice any flickering of the LEDs. But Linux is not made for real-time programs. Still, it seems I can update each of the 8 LED rows 30 times per second without too much interruption of the Linux task scheduler.
2. I can't say I've mastered the whole source code of simh, just enough to test my ideas a bit.

Development file repository:

I'll post updates more or less regularly here. Just mail me for the access code.

16 January 2015

The software part is slowly taking shape. It breaks down in two parts:

• Driving the front panel: means getting RPi code that displays the register settings on the 92 LEDs and scans the 26 keys. It is going to be much simpler than I thought.

  Driving 8 rows * 12 LEDs flicker-free under Linux is not a problem!

   I had expected a lot of flickering from the thread being interrupted by other processes. Not so - as long as you use pthread_setschedparam() to set the multiplexing thread to a high priority. I guess I did not realise quite how fast modern computers are :).
  Anyway, a small breadboard setup proves I can get the LEDs to be multiplexed without noticeable flickering. A stand-alone test program (outside of simh) now runs a high-priority thread, which drives 1 led row reliably for 4ms, 30 times per second, whilst the other thread just does whatever it wants to do (ie, it should run simh).
• Hooking up simh with the above multiplex driver. Getting register values out of simh, to display them on the front panel, seems to work fine. But getting front panel key presses communicated in to simh, and letting simh do the appropriate action based on it, is a challenge I have not looked in to yet.

20 January 2015

PCBs ordered at Elecrow... always a stressful moment. What stupid mistakes did I make?
Also, I found the right supplier for the acrylic front panel, but have not ordered it yet.

24 January 2015

Elecrow finished the boards... just a few more days before they arrive. I just realised I have nowhere near enough LEDs in the spares box. Oh well. I'll have to test with only half the LEDs for a while.


Here is the schematic (click to expand):


Quick summary: there are 3 groups of GPIO pins:

1. 8 'xLED' pins, each of which provides power to the anode (+ side) of a row of 12 LEDs. The 3.3v xLED signal comes from a GPIO pin, is led into a UDN 2981A chip which switches a 5V power supply into the anode of the LEDs. I am not sure yet how much power the LEDs will need - mabe the UDN2981 is not even necessary: if 1mA of current makes a LED burn bright enough. We'll see.
2. 12 'column' pins which are the cathodes (- side) of the 12 individual LEDs. So a LED is lit when a column pin is at 0V, and the LED remains unlit when a column pin is at 3.3V. The column pins then quickly flip over to being input pins for the following:
3. 3 'row' pins, which provide power (actually, a power sink, active means 0V for these pins) to a row of 12 switches. The column pins above quickly get switched to input mode, and can then sense which of the switches is 'on' (causes a short to the column pin).

Note:

• The UDN 2981A actually causes a voltage drop of about 1V. 
• A resistor limits the current flowing through each LED.
• A diode in the keyboard matrix (the front panel switches) avoids the problem of 'ghosting' in key matrices.

January 26, 2015

Darn, these PCB people are fast, I got the boards 3 days after they were made. The first thing I tried was a bit of a letdown: I made the holes for the switches slightly too small. So, I spent the afternoon grinding down the pins of 26 switches. The fit is not quite perfect this way, so the switches are mounted slightly irregularly, but that's OK for the prototype. Here's where progress has stopped for the day:

PCB arrived - quickly put in a few components for a few tests. Switches will need slightly bigger drill holes in next run.

January 28, 2015

Before plugging in a Raspberry Pi, I first tested the board with an external 3.3V power supply. Not only to check whether lights turn on and switches give a response on the I/O lines, but also to check power usage.

I discovered a problems with my PCB design:

Green circle good, red circle bad: without adding a junction, a label doesn't create a connection

some traces were missing! After some false accusations against Freerouting I discovered what I had done wrong: in Kicad, if you attach a net label to a line, you also need to hook it up by adding a junction. Without it, the label is meaningless.

Oh well, all problems that could be fixed manually and will be solved on the second version of the PCB.

I'm still waiting for the 2981A driver chip to arrive. It's intended to take the load off the GPIO pins - but even without that component it seems I can drive the whole board from the bare Pi itself (by shorting a few pins to let GPIO pins drive the LEDs directly). To my surprise, LEDs burn brightly enough on just 1mA of current each, using 1.8K resistors as current limiters. As only 12 of them are lit up at any one time, I stay well below the 16mA pin limit on the Pi.

So last night I finally plugged in the Pi and wrote a simple test program using the example C code from Gert van Loo (found here). Seems to work!

Cosmetics interlude: front panel artwork

About that front panel... I had done most of its design during the Christmas holidays, which was a very anti-social thing to do really. I started off from a picture of the 8/I being restored at the RICM. The photo had one disadvantage: this particular 8/I has a non-standard OEM's label at its top, so I had to use some other photo's to reconstruct that bit. But importantly, the RICM picture was taken from more or less straight in front of the machine, so it had almost no perspective distortion.
I put that picture, 50% transparant, as a locked layer in Inkscape. I rescaled it so that each switch was exactly 10.0mm in size on the grid. My real switches are 9.5mm in width, with 0.5mm as a bit of safety between them that makes 10mm. From there on, it was a matter of measuring the spacing between the rows and columns of lights, between switches and lights, etc. I sampled each 'parameter' from multiple measurements on the photo, with a bias to the center of it (where distortion of perspective is minimal). With those same measurements, the PCB was made in Kicad.

Continuing in Inkscape, I started drawing the artwork. Lines, lettering, and the crucial Digital label. There was some real search work in store, and maybe the factoids below are of use to others trying to recreate DEC front panels:

• Font for the 'PDP-8/i' label: MicrogrammaDMedExt. This font is an exact match. Just the slash sign had to be redrawn.
• Font for al the other lettering on the panel: Akzidenz Grotesk Light. Not an exact match, but very very close. I had to adjust kerning and letter spacing and got a near-pixel-perfect match.
• Digital company logo: Ned Batchelder's site has the design history of the Digital logo. I vectorised his PNG, to use in Inkscape. This is a 'true' Digital logo, but not perfectly authentic. Because in 1968, Digital used a marginally different, hand-drawn logo on the 8/I. Not that any normal human being will spot the difference...

With the above, I was able to redraw all the components on the front panel. Working with a transparent photo of a real 8/I in the background, I could place and verify things with pixel precision. I forgot why I felt that was so important, but it seemed a Historically Responsible Duty at the time. The mind narrows when focused on tedious tasks.

I had one problem left. It's impossible to establish the right colours from web pictures of the 8/I. They're all different, because of lighting conditions etc. Fortunately, Al Kossow gave me a lead to this DEC document, which defines the colours. DEC used colour codes that are obsolete by now, so I had to Google around to figure out how to translate them to RGB colour codes. But, for the 8/I:

• The dark brown is "Dark Luggage Tan", Munsell code 5 YR8/4, which is RGB 934f1f if this link can be believed.
• The orange is CHM4 in the Color Harmony Model, which is close to RGB b66702 if this picture is reliable.

In the above lines, I'm sure of the bold bits, but the RGB translation is done on a best-effort basis. I'll have to see my front panel next to a real 8/I before I can be sure...


I'll have to see if I made any catastrophic mistakes when I get the panel sent back from the printers. The core concern: making sure they really deliver the picture as stated, without any resizing or edge-clipping.

February 1, 2015

Life gets in the way regularly, but I finally got some time to work on the PiDP... and discovered a hardware problem: the Raspberry Pi has 1.8K pull-ups on GPIO pins 2 and 3. I did not know about them but they really spoil my party.
The final board will have two options: (1) use pins 14&15 instead of the intended 2&3. This avoids the pullup problem but sacrifices the serial port option that needs pin 14&15. (2) If anyone wants the serial port  - to hook up old terminals directly - the pull-ups need to removed from the Raspberry Pi board and pins 14&15 can be freed up.

How the LEDs and switches work
To explain, first, here is a simplified schematic showing how the 3 I/O pin types work together in a multiplexing cycle. The schematic is simplified in that there are not 1 but 12 'col' pins connected to both the 'ledrow' and 'row' pins. Explanation before picture:

• During switch scanning: 
• One of 3 'row' GPIO pins is set to Output Low (0V) to activate a row of switches. At any other time, the row pins are set to input (high Z).
• The 12 'col' pins (which have internal pull-ups, BTW) are set to input and will sample a Low on any pin where a switch has been closed. As long as a current sink is provided by a row pin set to Low (0V) of course.
• The 8 'ledrow' pins are out of action (either high Z inputs or Output Low) during switch scanning.
• During LED driving:
• One of 8 'ledrow' pins is set to Output High (3.3V), all the others to either input (high Z) or Output Low, both are OK. The single active ledrow pin now powers a row of 12 leds (i.e., the ledrow pin is the anode to those leds).
• The 12 'col' pins are all set to Output. Output High to leave a led unlit, Output to light that one particular led - the col pin acts as its cathode.
• The 3 'row' pins are out of action (high Z inputs) during LED driving.

R23 and 24 pull up two GPIO pins which is nice for I2C but not for me. Remove them?

Anyway. The few LEDs I have at the moment are nicely blinking along... still waiting for the big bag of LEDs I bought 3 weeks ago to fully populate the front panel.

20 February 2015: Blinkenlights are go!

Life got in the way again. But today I had some time to work on the PiDP. The new LEDs arrived and are all soldered in, annoying pins 2&3 are now moved to be pins 14&15, and I finished the test program to drive the front panel. Here is the result, in the shape of a 4 second Blinkenlights movie:


The demo program shown above consists of a normal program modifying a few global variables (think PDP 12-bit registers) in the course of its process, and a wholly separate - real-time - process that multiplexes these registers onto the front panel (think simh). The simulator program can check a variable for the current switch positions at any time and will adjust the register values of the top three led rows to reflect their settings.

In other words: I'm ready for inserting the multiplexing process into simh. Yay!

On the hardware side, there's one thing still to do: insert the newly arrived UDN2981 chip which will take the load off the ledrow pins of the Raspberry. The load of lighting 12 leds at a time, with the current resistor values, is actually not a problem for the Pi and so I let the Pi drive them directly from its own pin power. But if you want the LEDs to burn brighter, the 2981 is needed to provide the juice.

To be continued. May the Blinkenlights be with me.

Souree: Vince Slyngstad's DEC site

February 21, 2015: Flights of fancy

As it turns out, there is a freely available 3D model of the PDP-8/I switches. It looks like I can change its bottom half to become a push-on cap to fit my switches. Hmm.

Source: http://rodaw.me/1EZT38a

Also, I figured out that I can add a paper tape reader on the PCB with a relatively modest extension of the schematic - as done by NeXT on his blog on vintage-computer.com. Add 9 IR receivers (and 9 IR leds), hook them up as an extra 'switch row 4' with the one spare GPIO pin I still have, and you can sense 9 paper tape holes.Users will need to pull the tape through manually. The one big dilemma is how I get punched paper tape to begin with. Allowing users to print outpaper tape with holes being black dots would be a great solution. Then, the PiDP could print paper tape on A4 pages, the user having to cut it up in strips to read it back again. But no idea whether IR receivers can shine through paper and detect black vs white on the paper... I ordered some to play with anyway.

Back to reality tomorrow: get simh to work with my multiplexing function.

February 22, 2015: simh blinks my leds

With only 30 lines of code inserted into simh's body of code, and adding my gpio.c multiplexing driver to simh, I now have a real (real emulated) PDP blinking the lights of my front panel. That was way easier than I expected. Well, all simh is driving so far is the PC row, but the other lines should be easy. Tomorrow. Or actually, later today. I love late weekend nights.

February 24, 2015: Progress

Meanwhile, I got simh to run and blink pretty much all of the front panel leds, except a few where I need to figure out their exact behaviour in real 8/I's first. A few of the switches are working too.

Next to that, I wasted a few hours completing a second prototype. Given that I had to order a few boards anyway, I populated one of the others I got back from Elecrow. This time I used 5mm leds, instead of 3mm leds. I think that's an improvement. Also, the 2981A provides extra brightness to the leds and works as intended.

Because I stupidly made the solder holes too small to fit the switches I want to use, I had to grind all the switch leads down to size for the first prototype. This time, I just used smaller switches. Which looks a bit uglier, but it was worth a try... Anyway, the pictures below give a good impression of how the raw board will look. Instead of the white-on-black acrylic front panel, I temporarily use a black-on-white paper printout...

Second prototype, back side. Note the Raspberry Pi Model A+ and quite a few fixes to the PCB :)

I guess it will need a proper enclosure...

I used small switches on the second proto - does not look right

... but the larger 5mm leds I used this time do look good I think,

Here's prototype 1. Right-sized switches, mounted a bit irregularly :(

February 26th, 2015: Booting OS8 with a working switch panel

Works! There are some finer details to finish in the switch handling, but all the front panel switches behave as they should except under some 'corner conditions' that need to be ironed out.
After finishing up today, I brought the two prototype PiDP-8s to our local hackspace/vintage computer meet and we booted up OS8. Jos, our very own PDP expert - if I may say so - kindly brought along some paper tapes with the BIN loader and FOCAL. As well as a nice small handheld paper tape reader (can be seen between the pair of glasses and the right-hand PDP) I think I can clone into the PiDP. Some day...

A night at the Hackspace. OS8 on the screen and the panel switches work :)

Priority now shifts to getting the acrylic cover plate. The temporary paper one is getting on my nerves.

February 28th, 2015

Unexpectedly quick, some IR leds and photodiodes arrived. So I put together a crude prototype of a paper tape reader. I started with the design of NeXT at the Vintage Computer Forum - replicating his idea of two rows of photodiodes, and bending their pins to make them stand upside down. But thoughts have progressed a bit on the electronics.


Rather than NeXT's purely electronic approach (converting diode output to TTL signals with 4093s), I'm going to try a software-based solution with an Arduino Pro Mini. That is a bit heavy-handed - a whole MCU instead of 9 NAND gates - but it requires just 1 IC, versus 2-3. The atMega would anyway be needed if the thing is to deliver serial output as well as parallel, and sampling photodiodes using analog pins means the atMega MCU can help to make readings more reliable (self calibrating routine, etc).

One problem stood in the way of the Arduino idea initially: the atMega has only 8 analog inputs, and there's 9 holes to scan on paper tape. What I'll try is scan for an index hole first, then - once one is found - quickly scan the 8 data holes, repurposing the 'index' analog pin to sample one of the 8 data holes. I think that should work. Anyway. The picture shows the test contraption I cobbled up today. No idea if it will work - I guess we'll see tomorrow...

February 29th, 2015

I put the paper tape read into Kicad - still a draft. Note: the board breaks in two, the top half folds behind the bottom half. The paper tape is led past two horizontal pin header rows. Sounds like it could damage the tape, but is fine in practice. So far. Making a board is not the same as having a working device :)

Warning- schematic contains an error - fixed by now...

March 2nd, 2015

I finally,finally, finished the artwork for the acrylic panel and sent it off to a manufacturer in Germany. Size is 30x14cm, a 2:3 scale replica of the 8/I. The reproduction is pretty much pixel perfect, with the exception of the bottom brown/white color bar being moved a few mm down from the original for a better cosmetic fit.

The panel has 65% translucent slots (marked in grey) where the indicator leds sit behind and will be done in 1200 dpi (not that anything beyond 600 dpi is noticeable, but still nice). Now I've got to wait 10 days for the test batch of 5 pieces to come home... Note that the big black void at the bottom is where the switch panel is fitted. Looks weird without them.


Meanwhile, I spent time on the paper tape reader. Alas, the prototype I cobbled together on perfboard performs rather ho-hum so far. I guess I better hold off until I am sure this is the right way to go.

March 5th, 2015

Over the past two days, I spent some time thinking of some practicalities if this is to become a kit.

First, what should it be? A 'bare bones kit' consisting of PCB, acrylic front and electronic parts? Or a nicely packaged gadget that is packaged beautifully enough to grace a geek's living room without objections from the loved ones?

Enclosure... I'm considering to include
this one as an option for the kit. The cool thing is that it is also available in a half-size case that would fit the paper tape reader in a matching box.

Free from cables... I'm starting to work towards the idea of a nicely cased machine, which can be wholly stand-alone - no wires at all. Of course you can still use HDMI, USB keyboard/mouse and USB storage, why not. But it could also just use a Wi-Fi connection for terminal sessions and any other communication to the outside world. Heck, you could stick a $16 LiPo battery in the back of the box and make the PiDP just as portable as a laptop.

Dual-mode... The PiDP should be a straight & pure PDP-8 replica in one mode, but still be useable as just a normal Raspberry Pi in a fancy case in the other mode. Why not? During boot time the position of the STOP decides whether or not to be a PDP-8.

Secondly, I brought a very good idea back from one of the guys at the hackspace meeting last week. It's hard to mount the 26 switches perfectly aligned - unless you remove the turning pin from each switch, and string them along on a long brass rod that holds them together. Like pieces of beef on a barbecue skewer...

It turned out to be brilliantly simply: with a side cutter, snip off the end of the pins, pry out out the pins with a 2mm screwdriver and stick the switches on the brass rod. Which turned out to cost only $2 at the local DIY store.

So, the easy-to-mount Switch Skewer looked like this, before I proceeded to stick the whole thing into my prototype PCB no. 3, and soldered it together. Worked perfectly, looked great. But next time I need to remind myself to solder the #%$# thing on the front side of the PCB, not the back side! Oh well. Prototype #3 will not see the light of day then.
Tomorrow, it's time to pull out prototype board  no. 4 and try again. Because when the acrylic panel comes in next week, I want a near-perfect-looking machine for a Youtube demonstration. Prototype #1 is no good because of the irregularly soldered switchesand its smallish 3mm leds. Proto #2 is no good because although it used better-looking 5mm leds (a matter of taste, 3mm leds are the scale-correct size actually), it used a smaller switch type I had lying around.

Lastly, I also started to do a first cost estimate. If I get some quantum discounts, a $100-120 kit cost is feasible. But I'd need to do a run of at least 100 units, especially the acrylic panel and switches then go down dramatically in cost due to bulk pricing. Not sure if there are enough geeks in this niche to do 100 units though. Have to reality-check that sooner or later. Everything will have to wait till next week anyway, when I get some time to work on the project again.

March 9th, 2015: Going to VCFeX to demonstrate the PiDP

I got a really kind invitation from one of the DEC exhibitors at the VCFeX to come and join the PDP-8 'pavillion' there. The VCFe has a bit of a PDP-8 theme this year, with the 50th anniversary of the Straight Eight. So I signed up for what will the debut of the PiDP, where it will run next to a real PDP-8/I amongst others. That'll be an acid test. Nice.

It also gives a very useful deadline to wrap up the software and mechanical construction of the prototypes. Anxiously awaiting delivery of the sample case and acrylic panel to see how they've turned out... always feels like it takes forever when you're waiting for stuff.

The one major challenge is how to cut the acrylic panel: it needs a slot cut into it to accommodate the switches, and I also need to shave off 8mm to fit it into the case I decided to use. Sounds simple, but cutting *clean and straight* slots in acrylic is something for which I lack the tools. Time for a social visit to a few of the local cabinet-makers...

March 19th, 2015: Polishing up the software

I spent quite a few hours to make the modified simh a bit more invisible. Meaning the Pi automatically boots into PDP-8 mode unless the user has enabled the STOP switch at boot time.

The original 60s tape labels on USB sticks that now think they're punched paper

And also, the way simh normally deals with emulating paper tape readers and disk drives is efficient but, err, unromantic. Meaning you have to step out of emulation, type 'attach ptr binloader.bin' and 'go' to continue emulation.

That is not OK for a replica. So I made it such that you take a USB stick, put a disk image or paper tape image on it, and then you stick it in to the machine. You hit the SING_STEP and SING_INST switches at the same time, and whatever image is on the stick is auto-mounted. The nice thing is that now, USB sticks are just modern replacements for paper tapes or disk cartridges! The form factor is different, but plugging in the BIN Loader stick and hitting the two switches does exactly the same as putting a paper tape into the paper tape reader and powering the device on. It's great fun! (I think).

Here's two USB sticks with the BIN Loader and FOCAL69. You toggle in the RIM Loader, plug in the BIN Loader tape stick, toggle 7756 LOAD_ADD, START to load it. Then plug in the FOCAL69 tape stick, toggle 7777 LOAD_ADD, START, and run from 0200 after the Focal tape stick is loaded. You truly have nothing to do with simh commands, it's pure PDP-8 this way.


I'll polish it up a bit more, but it's charming. It also makes it very attractive to have a small USB hub plugged into the PiDP. Then, one of its USB slots is the paper tape reader, two are disk drives, one is maybe for a hard disk cartridge. It works with all the devices that simh emulates, so it invites experimentation. Think USB DECtapes!

Lastly, I'm toying with a program which enhances the uselessness of the whole machine a bit more. The idea is that the Pi can be booted up in Pi mode as well as PDP mode, in which case it's just a Pi like any other. But the front panel will show - in glorious octal - the time, day, year, as well as the weather (barometric pressure, cloudiness, temperature) for the coming 7 days. The weather data is just taken from the rather nice Weather Underground API service. Not sure if I will finish this particular folly, but it fits with my idea that the PiDP should be pretty enough to be a display item. And reading the time in octal will make it an exquisitely obscure time piece as well as good training for rusty PDP users.

March 20th, 2015: Finally Front Panels

It took 20 days, but the manufacturer finally sent me the 4 acrylic front panels. They turned out beautifully. I built myself a router table last week to be able to fit the acrylic panels into the cases. Taking only the first two panels as guinea pigs, I did only marginal damage to them before they fitted in.

But for cutting the slot for the switches into the acrylic panel, I do need to find a way which does not involve me. Or figure out how to do this efficiently. I'm just not very patient with this kind of handywork.

The other thing that will need experimentation is the white mask behind the acrylic. Remember, the acrylic is actually a translucent image. That's done so the leds can be seen behind it, but the white lettering should obviously not be translucent - it still needs a white mask behind it.

Tonight I experimented with just spray-painting the back of the panels with white paint, masking off the led slots with tape to keep them transparent. It proves to be a rather tedious process because of the 0.5mm tolerances in some places. So tomorrow I'll experiment with plan B: using a heavy paper mask with led cutouts, and glue that onto the acrylic's back in an orderly fashion.

I'm so happy after the long wait, that I took some intermediate pictures which serve little purpose because they're not especially pretty. But, shown above is the acrylic panel with a temporary paper backing (so the led slots are all white), fit into the case. I did not even take off the blue cover film, which makes the edges looks a bit rough. Rest assured, the acrylic is cut very cleanly once you peel off the film.

On Sunday, I hope to wrap up three of the prototypes behind their acrylic panels, in their boxes, all done for a demo movie. Getting there!

22 March 2015

It's there! At least, the first fully cased prototype is. A lot of small things to improve in the next three prototypes in the coming week, but:

Cased in ts 15x30cm box. I finally got around to spray-painting the switches...

It has a nice 60s look to it, I think

Shown with its all-in-one peripheral: a USB hub in which one port is PTR, two are disk drives, one is disk cartridge.

You can see a few DIY mistakes I made in cutting the acrylic. And it needs black screws. But it looks sweet!

30 March 2015

Things progressed nicely over the last week, with three prototypes finished. They vary in their connectivity: Two use a Raspberry Pi Model B+, and thus have a side panel with Ethernet and 4 USB ports brought out. One is WiFi-only, using a Model A+ inside. A fourth and last one will have an old-style serial port brought out so serial terminals (I've got an ADM-3A waiting) can be used. This does require removing two SMD resistors from the Pi though.

Here is a Youtube movie of Prototype #1 running: http://youtu.be/5hyUActgT2E

Some points to note:

• I still have to verify all the LEDs respond exactly as they do in the real 8/I - I believe so but the real test is at the VCF East!
• You'll note that those switches that are momentary toggle switches in the original are still 'flick on/flick off' in this prototype. I'm planning to put some springs in these switches to make them momentary - it's not hard to do. But to be honest, you get used to this so quickly it's not very high priority. The front panel software converts a on/off toggle into a momentary signal anyway.
• Also, the STOP switch is meant to be upside down from all the other switches (off = down). I let it be inversed - off = up - for the moment, it's a setting in the code but I prefer it this way myself.
• This particular PiDP uses a Raspberry Model B+, and I'm running a normal Ethernet cable between a laptop with PuTTY and the PiDP. Works flawlessly! No need for crossover cables.

Next steps: refine the software a bit more, and start collecting a nice library set of PDP-8 software from all of its development stages. Especially, I'd like to try TSS-8. And work on the final web site and manual (I believe in good manuals).

After VCF, I'll probably need to polish up some imperfections that are bound to crop up when I run the PiDP next to real machines. And start planning for the kit. On that front, I got a spot of (somewhat) bad news: the really good German manufacturer I used for the acrylic panel seems to have stopped doing them. So I need to find someone else that wants to do it for a reasonable price... oh well.

April 10, 2015

All dressed up and ready for the VCF.

Well, there they are, the four prototypes:


I played around a bit with connectivity options. So two PiDPs use a Raspberry Pi Model A, the other two a Model B. The machine in front has a slot on top to access the HDMI monitor connector (slot not necessary with the right HDMI cable, BTW), the other machines only run terminals from serial or network terminals which is all you need.

• The Model A's have the serial port enabled (meaning R23&24 were clipped off from the Pi's).
• To connect a modern laptop, use a USB-to-TTL-Serial cable. The PiDP runs happily off its 5V power pin: a neat plug & play solution without need for a power supply! 
• To hook up a vintage serial terminal, you need a TTL Serial-to-RS232 converter, and a 5V power supply (a laptop's USB port can provide the power too).
• All four PiDPs have a micro WiFi adapter plugged in, so you can log in to PDP terminals that way too - or use WiFi with VNC to run the Pi's desktop GUI concurrent with the PDP-8 terminal...
• The Model B's are left unmodified, so their serial port is not enabled. To make up for that, the B's can also be accessed from a laptop using an Ethernet cable. Because Model Bs have four USB ports, a separate USB hub is not necessary - but it's still nice to add.

Adopt-a-PiDP...

My better half has decided that our suitcases will be filled with more important things than PiDPs on the way back home from VCF East. So if you're at the VCF and want to take one of these PiDPs, please let me know :) They are 100% compatible with the future final version of the board, they just have some manual fixes on the PCB.

Preparing for producing a batch of PiDP kits...

The company who made the four test panels does not want to do any more of them... apparently they had to redo the PiDP panels three times before they were OK. I found two other manufacturers, who charge $15-20 more - the bad news - but will deliver them ready-made with the white mask and CNC-cut switch slot. Which is good news. Because in this project, I hated nothing more than using the router to cut a slot for the switches. Except for painting the panel backs whilst staying clear of the transparent windows. Well worth the $15 to outsource those two chores I think.

But with this, the kit price would end up at $135 instead of the earlier $120. Whilst the bet I had going against myself in January was actually to do it for $99. Hmm. Inflation. There's still time to haggle on the panel cost a wee bit more though.

May 7th, 2015

Production of the kits has started. Well, at least I've ordered all the parts except PCB and acrylic panel. I still need to decide where to produce the acrylics, it's proving to be more cumbersome than I thought. But it'll happen any day now.

In the mean time, I got extremely lucky: today, thanks to PDP collector hb9aik, an original PDP-8/I front panel found its way to me. Not only that, it's in near-perfect condition! Never thought this day would happen, so thank you!

Here's a shot of original-vs-replica:
So, the next project coming up is already defined: add the PiDP circuitry behind the 8/I front panel. Strangely, this is the one and only 8/I I've ever seen in real life. Very useful, as now I can see the orange of the PiDP needs to be brightened up a bit. It's very subjective of course, but I was surprised that the toggle switches on the replica actually have a better feel to them than the originals. Just not nearly as pretty. The switches of the 8/I feel very different than the more familiar toggles on an 8/e, for instance.

What a glorious day... a real PDP-8/I. Well, the front bit of it anyway.

May 20th, 2015 - spacewar!

I've been busy getting all the parts together for a run of kits. The acrylic seems to be in production with a good manufacturer in Holland - at least, it will be tomorrow after some last-minute questions I got from them. The other parts started to come in bit by bit.

The first peripheral for the PiDP...

spacewar! As seen on the PiDP :)

In the mean time, I ordered a small 7" HDMI screen from China, and mounted it in the one PiDP case I still had left over. The 8/I is a rackmounted machine, so I might as well have something on top of the PiDP (this vc8e type oscilloscope display being that something) and something below it (papertape reader maybe?). 3 stacked cases makes a rack-mounted system of sorts.

But the real reason for this subproject is Kyle Owen's PDP-8 implementation of spacewar, which I saw at VCFeX. It ran on vc8e-like hardware that he developed for his 8/M, using an oscilloscope screen.

But then Kyle mentioned he'd had an emulation of all this goodness running on SimH and Processing... See his Youtube demo. That's a must-have for the PiDP! I just got the HDMI screen running, and played my first PiDP spacewar match. Alas, not using the HDMI screen, it seems that Processing on the Pi has some nasty problem with OpenJDK. So I used a laptop over WiFi as the screen. Never mind - just now, I played my first spacewar game ever. On the PiDP. Thank you Kyle!

May 29th, 2015

I rewrote Kyle's vc8e screen emulator in C, using openVG to get it fast enough for the Raspberry Pi. It works nicely now, so the PiDP starts to look like a proper miniature rack of instruments! The code needs to be cleaned up, but it's there. Once I get the final PCBs in, I'll hook up handheld controllers to the expansion port.

For the rest, not much to mention. The first sample of the acrylic panel came back from the new manufacturer, it needs redoing because the colours are a bit off. But that'll be done. Almost all other parts are in for the first run of 250 kits, with only the non-standard GPIO headers (they need to be extra tall for the Pi) and the cases still in transit. Also, it's high time to clean up the install scripts for the PiDP. That is the one thing I keep postponing...