Subscribe via RSS

I’m not original…

In fact, my new best friend is over 16 years old!


I ... thiiiiink ... he's half deaf... might be time to replace his ears.


EZIO + OS9 + Hypercard (Or Just Windows)

The EZIO Board is a serial-based I/O module that can connect to both Windows and Macintosh machines. Actually, it can connect to anything that speaks RS-232. One of these came up on eBay recently and I couldn't resist. I saw the Macintosh serial port and decided to give it a go. It's really similar to an Arduino, but from a few decades before the Arduino was even a dream. If I'd known about these back in the early 2000s then I would've definitely had a very nice automated model railway. But alas, I only happen to find one now thanks to eBay!


The unit has 10 digital output lines, 10 digital input lines, 8 analog-to-digital lines and two PWM lines. You then get 4 +5v terminals and 4 GND terminals. There's a PIC microcontroller in the middle running the show and a MAX232 for the RS-232 comms. The unit has a DC-rectifier, so you can feed it 5-15v either AC or DC. The 5-15v is literally the operating recommendations of the 7805 voltage regulator on-board.

There's a whole lot of code on the old site (yeah, you have to use web archive to get to it), but it's mainly for Director!? and Macintosh. Hilariously, the Macintosh example uses Hypercard! Before booting up the Power Mac, I instead wrote a quick bit of C# to test out the unit.


The shot above uses dotnet-ncurses, allowing the console to act like a canvas. It's really nice to be able to draw text to specific areas, rather than scrolling the screen. Anyway, the basic idea is that you can control the digital out and then everything else is read in. Interestingly, floating pins show some very random values... so if you're using this device, make sure you tie everything to ground or use pull-up resistors where appropriate.

Of course, the whole reason I bought this was due to the Macintosh serial port. I wasn't overly-energetic, so I tried a virtual Macintosh first...


After installing Hypercard, the app came up, but the performance once it started trying to interact with the serial port was terrible. It also just didn't work, so I gave up and booted up the Power Mac.


Yup, works a charm. Hypercard is pretty clunky, but I'm sure you could do a lot with it. I'll have to dig out the railway track and control a train!


Philips CDI 450 – Laser Replacement

The Philips CD-i (Compact Disc-Interactive) brand/tech was released back in 1990 to add a level of interactivity to CD-ROM based entertainment. Philips, from 1990 through to 1998, produced and released multiple devices for both the home and educational markets based on this technology. One of those models was the CDI 450 and I just happened to stumble across one a long time back at a Belgian flea market. It's been in a box for quite a while and I've only just gotten around to looking at it... The driving factors were: #1 COVID lockdown is driving me crazy and #2 there's a version of The 7th Guest for this unit!


The unit came with the power supply, a controller with it's face missing and, randomly, a game CD in the drive.

DSC00513 DSC00510 DSC00509

The controller was obviously useless, so I went to GAME OVER? in Amsterdam and picked up the cheapest controller I could find.


There's the standard rule of 'sunk cost' where you don't spend large amounts of money on something that could be dead. I then returned to Australia and the unit has been in the box since. Only recently did I turn it on...

DSC00519 DSC00523 DSC00524


Cool! It works! My French is rusty, so I wanted to try and get other games working. No matter what I tried, the unit would not read CDRs. Every google search I tried lead me to believe that the laser was gone, or going, so I scoured eBay for a replacement. It turns out that searching for VAM-1201 will give you shops in China that have the exact 'new old stock' component that I needed! I ordered one, expecting it to take years, instead having it arrive in just under two weeks!


Popping open the CDI was easy enough. There are four screws in the unit. Two are in the CD bay and two are in the 'optional module area' to the left. Open the CD lid and then remove the plastic shell to the left. It has two clips that need to be pushed in. Woah, what's this? My unit has the Digital Video Cartridge!

DSC00538 DSC00540 DSC00542

With the screws out, you'll now find the RF shield in the way... remove this evenly, prying it up from each corner and making sure there are no wires in the way.


Mine had a lovely amount of discolouration... maybe from the rain that was falling in the flea market in Belgium? Fortunately the motherboard looked pristine.


The Laser aparatus consists of the laser unit and drive motor in a plastic housing, attached to a metal plate via rubber suspension joints. This whole component is held in place by the two screws from the main case and two plastic lugs along the top frame. Gently lift the whole lot, evenly pulling it up. The top two lugs are quite tight, to make sure to ease the unit vertically away from them until it's free. Once done, don't lift too high as you'll first need to disconnect the data ribbon cable and power cables underneath.


Once done, you then need to remove the laser unit from the metal plate. It's held there by four rubber spacers. Note that these are old now, so be very gentle when sliding them out laterally from the slots in the laser housing. I managed to break one when doing so, but fortunately this didn't impact the ability of the unit.


Once you've slotted the new laser on the housing, place it back into the main unit. This is as simple as lining up the lugs at the top, holding the unit at 45-degrees whilst doing so. Note that the wired cable might be longer than the original... just place the wires somewhere in the spacing to the bottom-right. Also make sure the wires don't get pinched when you place the RF shielding back in!

From here? We test...

DSC00562 DSC00563 DSC00564


DSC00567 DSC00569 DSC00571

DSC00572 DSC00573 DSC00574

And the icing on the cake:


A perfect game to test out the DVC! It worked very very nicely.

Filed under: Retro No Comments

Atari 2600 Jr – Reset/Select Switch Repairs

I've recently come across an Atari 2600 Jrs with faulty select and reset buttons. Turns out that the mylar strip that conducts the button presses to the motherboard is toast. It doesn't conduct anything at all and I can't work out exactly where the break is.


To test if the button area even works, you can insert wires as above and check for continuity. In this case, they did, so I considered the following options to repair them.

Silver Conductive Pen

This nearly worked, but I couldn't get the paste to set correctly. The pen is from Jaycar and the basic idea is to draw a line where you want the circuit and let it set. I drew some pretty bad lines on the plastic film, but my first attempt seems to have failed as I drew the tracks too thickly. The 'ink' only becomes conductive once it's totally dry and I'm blaming winter and the fact that I don't have an incandescent bulb in the house anymore.

DSC00428 DSC00431 DSC00432

The next attempts were seemingly too thin. It also seems that you can't 'restart' a trace... the joint isn't conductive? Finally, the resistance seen down the track is totally erratic... but that may also be due to wet ink.

Threaded Wire

I punched a few holes in the mylar and threaded copper wire through. It was a little too stiff but, once in-place, seemed to work quite well! The main issue with this method is that, at either end of the plastic strip, adhering the wire to the conductive trace is difficult. Of course, at the motherboard end you can just jam the wires in the socket!


At the button end, you need to slip it in under the top-layer of plastic. I didn't feel confident that I could keep a valid joint and therefore didn't pursue this technique.


Prior to opening and testing the methods above, I was always intending on just replacing whole plastic strip with microswitches. There's a nice plastic base behind the push buttons and one could easily drill in some switches. This would also give a nice tactile experience to what is (from the factory) a really awful and mushy button press.


I went ahead and drilled holes slightly smaller than the switches. From here, I gouged out the rest of the required space as I wanted a tight fit. Of course, I was imagining things thinking that I tight fit would be enough to hold the switches in place... a hard button-press would probably send them into the case.

DSC00449 DSC00451 DSC00458

Therefore I glued a strip of plastic (yeah, it's a cable-tie) along the back of the holes as a backing plate for the switches. This worked perfectly! I probably should've soldered the wiring first, but it was each enough once the switches were in position!


Once it was all back together, it turns out that the buttons were pressed in 100% of the time. To fix this, I had to drill out a section of the plastic where the button meets the switch. This worked nicely. I then decided to remove the rubber as the press was being overly-softened by it. I'd recommend you test it both ways to see which feels the best... you can also try mounting the rubber on the actual case to make sure the alignment is correct.

DSC00481 DSC00478 DSC00486

From here, I just soldered the wiring up to a standard pin-header which fit snugly into the socket on the motherboard.


Testing began and the switches performed perfectly!

Filed under: Retro No Comments

Fluke Multimeter Repair – Elastometric Strips

What what? I'd had this Fluke Multimeter sitting broken in my box'o'junk for literal decades. It used to work great, but failed at some point a long time ago and was never fixed. Recently, I snapped the cable off a shitty AUD$10 multimeter that I'd been using and so, in my infinite wisdom, thought I'd resurrect the Fluke!


It turned on, but the buttons didn't work.. so it wasn't much good except for the default setting of DC voltage. Testing voltages takes up 50% of my time, but I still need resistance and continuity! Let's rip it open...

DSC00397 DSC00403 DSC00405

So, not shown above (since I'd already fixed it and this post is months old) is that the strips of weird rubber weren't both there. The top strip was, but it turns out there's a lower strip needed. I had probably replaced the battery back in the day and somehow managed to discard the strip that conducts the button presses.


That's where it was meant to go. You can sorta see there's 5-ish segments on the PCB down in the channel, but there's a beautiful air-gap between that PCB and the mainboard. What's meant to go in the middle? I popped out the strip at the top and I, telling the truth, had no idea what the material was. A little bit of googlin' allowed me to realise that it was elastometric strip! Andy's Surplus came to the rescue and quickly delivered two cuttable strips of elastometricity!

Cut.. cut again...


And cut once more and ... TADA!


It works. And whilst the beast is open, replace the battery and solder that battery terminal!


Damn this thing is beautiful.


Burning 16-bit EPROMs with a Willem Programmer

This wasn't fun! I wanted to get Kickstart 1.3 on my Amiga 500 and so I purchased some M27C400 EPROMs from eBay with the thought that I could host two ROMs on them and make it switchable. The ROMs arrived and, to my stupidity, didn't fit in a standard Willem EPROM Programmer! Of course, a quick google prior to purchasing anything would've made this very apparent. Fortunately, there's a fix! You can buy a DIP42 16-bit EPROM Adapter for the Willem, and so I did.


Thanks to COVID, it took an extra-specially long time to arrive and, once it did, got thrown into the box'o'Amiga'junk as I'd put the whole lot on the backburner whilst working on the Ataris of late. This weekend I'd finally managed to wrangle some time together and sat down with my trusty XP laptop to program these chips.... It wasn't easy!

Input Voltages

I jumped head-first into the programming and failed a LOT with errors such as 0x00 and 0x11. Any search online will tell you that, when getting lots of 0x00 and 0x11 errors, it mainly indicates that you aren't supplying the correct programming voltage for your target chip. Check out the PDF Datasheet for the chip you want to burn, it'll specify a programming voltage that it requires to successfully understand and store the bits that you're about to throw at it.

For the M27C400, we need to provide 12.5v +/- 0.25v. The Willem has a blue trimmable capacitor (or is that a resistor) on the top-right of the board that you can adjust to get this voltage. I always recommend to use an external power supply with these programmers and so I have a plug-pack which happily provides 12v @ 2amps. To make sure we'll have a chance of programming this chip, switch to the Test H/W tab of the software and tick VPP. This is pin 1 of the E32 socket. If this has worked, then you'll have a red LED illuminated on the board. Now, check the voltage between pin 16 (GND) and pin 1 (VPP) of the socket.


Mine was reporting a value lower than 12v to start with and hence I had a few issues burning. With a multimeter in place, I tuned the trimmer on the top-right and got the value to 12.5v. Actually, it was probably 12.6... but 12.4 would also work as you just need to be in the range of 12.25 - 12.75.

Another test burn saw a new error... no more 0x00 and 0x11, it was now further into the chip, usually around 0x100?

Willem Software vs. Programmer Settings

Next up, we need to make sure that you can correctly control ALL address lines with your Willem Programmer. After fixing the initial errors above, I started getting new errors at random intervals into the burning process. The errors all seemed to indicate that there was an issue writing data after address 0x100. I'd only been using empty chips, so it couldn't be because they already had data on them. You can also check if the chips are empty prior to burning and I totally recommend doing this. Either way, after this new error was received, I chose to then read the chips and view the data:


What you're seeing above is the data read back from the chip. I wrote the rom (loaded from file) to the chip, got the error and then chose to read the data from the chip back into the application. 75% of the data on that screen is correct, but you'll notice that the data repeats itself from 0x100! It turns out that this was all due to the fact that my Willem was only controlling the first 8 address lines and leaving the rest low. I recommend you rig up an LED test harness as per below and control the address pins via the Test H/W tab on the Willem Software.


After swapping chips around, checking continuity between the 4051s and reseating everything else, I came to the conclusion that there's incorrect information in the Standard Willem Programming Guide. If you scroll to page 5, you'll find information on the version of the software to use. It suggests that, based on jumper settings on the board, you can select if the board emulates a PCB3B or PCB3.5. If you've chosen PCB3B, then you'll need to use software version 0.97ja, as per my post from a long time ago, when I was failing with the same issue! Alternatively, if you've chosen PCB3.5, you need to use 0.98d6 or higher.


I looked at my board and checked out the jumpers that set the board emulation. Mine were actually individually set to 1-2 and 2-3 instead of both 1-2 or both 2-3. Hah... how did this thing ever work?! With these jumpers now set to 2-3 (aka PCB3B), I went back to version 0.97ja of the software and tried to get the full suite of address lines to light up via the Test H/W tab. No dice! If you browse to page 6 of the above PDF, you'll find that the jumpers should be set to 1-2 for PCB35 and 2-3 for PCB3B. Just for fun, I switched the jumpers to 1-2 and tested out version 0.98d6 of the burning software... still no dice! No permutation of checkboxes on the Test H/W tab would get a high signal on any of the address lines higher than A7! Up until this point in time, I'd only programmed 8-bit EPROMs, so I'd never noticed this.

I went ahead and played musical-chips. There's a chain of CD4015BE ICs that shift out the address lines, 3 of them with 1 each controlling 8 bits. It seemed plausible that there might have been a faulty connection between the first and second, but no amount of tinkering brought the address pins to life. I took a break as the frustration (or was that sadness) levels were elevating and sat down to a bit of TV. With a fresh mindset, I came back to the device, forgetting which settings were applied. Opening up version 0.97ja and testing address lines now worked!? Wait, the jumpers are set for PCB35... what the hell, it's backwards!? I opened 0.98d6 and it didn't work, so I set the jumpers back to 2-3 (for PCB3B) and it now 0.98d6 worked!? Urgh... so much time lost. So, TLDR; The PCB3B/PCB35 jumper settings are backwards on my Willem Programmer. Set them to 1-2 for PCB3B and 2-3 for PCB35!

Using the adapter

First up, there's two jumpers on the adapter to configure. The right-most controls the VPP/A21 line and needs to be set to 1-2 for M27C400 or M27C800 EPROMs. The other, in the middle of the board, I left at 1-2 as I don't know what it does.


Next up, there's a ribbon cable used to obtain more address pins from the main programming board. For the M27C400, the base E32 socket of the Willem actually produces enough address lines, so this ribbon cable isn't actually needed. Check out the diagram below to work out how the adapter is constructed. I've coloured the lines that are used on the M27C400 and 800, where you can see that the 400 doesn't use any of the wires from the header on the right.


If you're going to program an M27C800 or larger, you'll need to connect this. Simply make sure that pin A23 (bottom-most) lines up with A23 on the Willem board.


Finally, when inserting ANY chip into to the socket, make sure that the pins are all straight and that none will foul. For any of the chips, always make sure that the bottom pins are at the bottom end of the socket. The EPROMs are designed so that the Address lines extend 'north', so the silhouette on the board is actually for an M27C800. An M27C400 will be one pin lower than the silhouette, aligned at the bottom of the socket.


All the errors I made above would've been avoided if I'd known what I was doing from the start. Usually the old RTFM instruction makes sense, but when the jumper settings work in reverse to the manual, it's a little frustrating. On another note, I'd just trusted that this piece of hardware worked, as I've managed to burn other chips in the past. Assuming that cheap hardware just-works(tm) is a flaw in itself. Always make sure you know the hardware you're working with back-to-front, which was totally possible this time around thanks to open-source schematics being available!


Atari Portfolio

This item popped up on eBay recently and I was very happy to have my offer accepted. The unit came even with a serial adapter! I quickly found 3 AA batteries and inserted them...


DSC00206 DSC00208 DSC00209

The Atari Portfolio is an IBM-compatible 'Palm-top' PC from 1989. If you were paying attention whilst watching Terminator 2, then you would've noticed it was used to break into an ATM. You can even still download the software they used to fake the hack. The unit itself is just bigger than a VHS cassette, but the profile changes once you attach the serial port adapter.


DSC00214 DSC00215 DSC00217


The unit is DOS 2.x compatible, with a few apps already built in. There's a text editor, spreadsheet, calendar and phone book. When I read that it had these features, I instinctively just typed edit on the command line when the unit first powered up. The response of Bad command or program not found came as a slight surprise, but then I thought that it must have another name as it's not official MS-DOS. I then tried ed, editor, nano, emacs, vim... all to no avail. It wasn't until I looked a little closer at the keyboard that I saw that 'Editor' was the Atari-text (the function that executes when the Atari button is held down) under the E key! Nice! It's actually multitasking?

Using the text editor

Just because I found this slightly harder-than-expected, here's a quick primer. The text editor is actually really cool and can be opened by pressing Atari+E. Use Fn-1 (aka. F1) to get to the File menu to start a new file, open a file, etc. F2 gives you a help menu and I seriously recommend that you go through the items in the list. There's a ton of shortcut keys that'll come in handy. F3 is the clipboard menu with options for copying and pasting. At any time, Escape will exit menus and even exit the app right back to the command prompt.


Note, when opening files: if you don't know the file name then just type an asterisk and press enter to get a list of 'openable' files from the hard drive. For fun, I created a simple text file with a random sentence and saved it to C:\. This became useful when testing the serial port.

Note that, at any point in time, Fn + O will turn the unit off. Spacebar will wake it back up.

Initiating serial communications

My unit came totally blank, so I had to fumble my way through getting files transferred over to it. For those playing at home, what follows is the most-simple step-by-step process to get it up and running. These steps were borrowed and modified from Paul Rickard's blog post titled Atari Portfolio Serial Interface: How To Get Terminal Software.


Firstly, we'll need a cable to connect your PC to the Atari. I happened to have a USB-Serial adapter that W10 was happy to use, so I plugged that in and grabbed the relevant converters to get from DB-9 to the DB-25 Null-Modem adapter that I had in the junk box.

Download and extract CoolTerm and get it up and running. Set the 10ms delay option and choose a low BAUD rate with no hardware controls.

coolterm-port-settings coolterm-delay-settings coolterm-no-settings

Power up the Atari and open Set Up via Atari+S. Configure the serial port to BAUD 300, leaving the other settings alone. Make sure you select Initialize! at the end. Next , open the Editor and type a sentence, saving the file to C:\. It'll default to unnamed.txt. With CoolTerm open and connected, type the following:

copy unnamed.txt com1

DSC00224 DSC00225 DSC00226


If you're in luck, the file will have been spat out to the CoolTerm console. If not, then go over everything again... specifically making sure that your cabling is correct!

Transferring actual files

For those that have a valid connection, you can now try and transfer files. Using the DOS copy method above, I tried to copy files bigger than 1kb, but it always failed. Even with CoolTerms transmit delays, I couldn't successfully do it. This is probably the reason why Paul has used xload/xterm. So, the next step is to set up a proper terminal app on the Atari. To do this, you'll need to download both xload and xterm and extract them somewhere.

We'll first use the basic DOS copy command to get over. It's a tiny file that does the same as DOS copy, but has the ability to copy larger files. To get this over, type the following in the Atari, but don't hit enter:

copy com1

Now, on CoolTerm, choose Connection -> Send Text/Binary File. Set the filter to all files and find Select it, but don't hit Open just yet. You'll want to hit enter on the Atari, wait around 3 seconds and then hit Open on CoolTerm.

coolterm-send-file coolterm-sending DSC00227

The Atari wont flinch, but you'll hopefully have a transfer window in CoolTerm flash past (it doesn't stay open as the file is so small) and the file will be transferred. A few seconds later, DOS will drop you back to the prompt and you can list your files to see what copied over. If you have an with a size of 178 bytes, then you've succeeded. Type xload and see what happens. If it has failed, or it's the wrong size, then repeat the steps above until it works!

With xload now on your Portfolio, you can use CoolTerm once more to send the larger file. xload will only ever copy serial bytes to a file called, so don't try and use it for anything else. So, in CoolTerm, select to transfer a file and get ready to hit Open on On the Atari, type xload and press enter. Once you see the screen below, hit Open on CoolTerm. Note that at this point you have the option to switch the BAUD on both units to 1200... I left it at 300 for safety-sake.


After a successful copy, you should have in your C:\ at a ginormous size of 1984 bytes. Type xterm and hit enter... crossing your fingers at the same time.


Nice... trashed binary. I re-did everything again and sent exactly the same... maybe I left it a second longer between hitting enter on xload and choosing Open on CoolTerm...


Yessss! We have a terminal application. xterm on the Atari supports XModem file transfers, but I couldn't work out how to do this with CoolTerm. I was on Windows 10 and managed to find two applications that can do XModem: Hyper Terminal and ExtraPuTTY. For fun... we'll use the former:


Hah. It still runs on W10... so ugly. It'll throw crappy errors at the start, telling you that you need a modem installed... just ignore/skip/cancel where appropriate.

hypertrm-modem-1 hypertrm-modem-2 hypertrm-test

Configure your serial port exactly as you'd done in CoolTerm, turning off any flow control. You can then open xterm on the Atari, choose F2 and send the files from Hypertrm via XModem.

hypertrm-send hypertrm-send-file hypertrm-sending

If it's working, then you'll see the dots across the screen... if you don't send via XModem, then the guts of the file will be printed out to the Atari and shit will get weird!

DSC00232 DSC00234 DSC00235

Transferred and executable!

Games and other software

Most Atari Portfolio software is compressed as LZH. 7-Zip had trouble with most of the files I downloaded, so I had to grab an archiver and do the extraction on the unit. As that there's very little spare space on C:\, this became quite a shuffle. For example, there's a file called yankee.lzh which plays the Yankee Doodle Dandy tune. To decompress it, you'll need on the Atari as well. Transfer both files using xterm and then try and extract the files by running lzhe yankee.lzh. It'll fail on the last file as xterm + xload + lzhe + yankee.lzh + half of the extracted files take up the entire internal storage. To fix this, delete xterm as you don't need it anymore. Leave xload as it'll help when you need to bring xterm back. Inside the LZH file is ptune and it's documentation. The .doc file is actually useless to us, so delete it and then use the editor to create a file of the same name with 0 bytes in size. When you then try to extract the contents of Yankee again, it'll ask to overwrite, but just say no. Finally you'll have yankee.bat that, when executed, will play the tune (poorly) and present the lyrics...

All of this shuffling would be circumvented if I had a memory card in the left-hand slot!

Memory cards

Atari chose the Mitsubishi Bee Card as their memory card type. This card allowed sizes ranging from 32Kb to 128Kb. Any memory cards with larger sizes were 'banked' and required powering off, switching banks and rebooting. The Bee Card was also used in MSX and Korg/Roland music equipment, and so you'll find that there are a variety of options when trying to source cards. There are also home-brew multi-cards, such as this one, if you have the cash and if COVID won't stop your shipments.

Filed under: Retro No Comments

Quantum Bigfoot 4320AT

I remember these drives... they became available around the time I had a Cyrix CPU and an S3 graphics card. We were not willing to cough up for a proper Pentium ~200mhz. Anyway, these were the budget drives also, making use of space instead of enhancing technology to fit more bytes in smaller places!


DSC00151 DSC00156 DSC00157


The Quantum Bigfoot pictured above is the 4320AT model, meaning it's listed capacity is 4.3gb. Of course, partitions never manage to give a drive's entire space to the user, so a FAT32 partition via USB-IDE via Windows 10 formatted out to 4.03gb.


This drive usually wouldn't even warrant a mention, but this model has a specifically interesting feature. It also seems quite rare, since googling didn't result in too many versions of this style of Bigfoot. Looking above, you'll see a transparent sticker over a window in the drive. It's actually a window that exposes the read heads! That's a really strong sticker... or so I hope, I haven't tried to remove it. Regardless, it lets you actually see the head has stopped when it's powered off... better yet, you can even watch it move when it's in operation!

Totally random! And amazing to watch!

Filed under: Retro No Comments

Atari Controller Test Rig

Long-story-short, I've got a new night-job, bringing a large quantity of Atari-related paraphernalia back to life. I've done it before with the 2600 Jr, and I'm ready to do it again, and again, and again, with this batch.

First up is a box of gamepads and controllers. My initial plan was to get one of the Atari units in a known-state, and then test the controllers from there... but that could lead to issues if the console wasn't actually 100%. Instead, why not just rig up a DB-9 port to a simple 5v LED circuit to test each button?

Google will produce a crap-load of results for Atari Joystick Pinout, so find one of them and get started. I chose this one. It turns out the controllers are very straight forward... they just act as a conduit to ground. Pin 8 is the common ground wire and all buttons (directional-pad inclusive) just join their respective pin to this wire.


The above rig was therefore constructed. Voltage is supplied from my desktop power supply and a miriad of LEDs were selected from the junk box. A selection of 48ohm resistors tie them all to the 5v rail. Their anodes all go to a respective pin on the controller port... starting with Up, Down, Left, Right, A, B from the left-most green LED. Of course, A and B are contentious, as the 2600 only utilises one fire button. Even better, the DB-9 socket also supports trigger, so that's the clear LED placed awkwardly on the left-hand side.


First controller to be tested was an Atari gamepad and it instantly misbehaved. Upon opening it, I found that both A and B buttons were tied high with resistors.


A little googlin' declares that these gamepads are actually for the Atari 7800, which supported two buttons. They've nicely made them backwards compatible though, allowing either button to be the standard button for the Atari 2600 jr. Regardless, those pull-up resistors meant that my A and B button LEDs were always dimly-lit!


Upon pressing either button, their respective LED fully-lit, and so did the left-most trigger LED. This makes me think that trigger is the actual 'button' for the Atari 2600 Jr and A/B are for newer systems. Regardless, the unit still had an issue. For those keenly-observing the photos up until this point, you'll have guessed that the directional pad's right button was crapola. It worked sometimes... and then it worked all the time when you jiggled the cable at the entry-point to the controller. So, what to do? Truncate!


Take a good length off, away from the game pad. Cable fractures, when entering casing/housing, are a very standard thing. Usually, very much like this unit, there's 'protection' inside the casing where the cable is held in-place to prevent it from being wrenched out and putting pressure on internal components. This 'protection' in this case is a zig-zag of pins to hold the cable in place without putting serious pressure on it.

For this unit, this 'protection' has done its job and kept the internals safe, but the cable has instead formed an issue directly after it exits the controller case. Here, thanks to humans like me, waving the controller around (rather than pressing the correct buttons), causes undue stress internally and ruptures the wires. In this case, it actually severed the wire that conducts a directional-right press.


DSC00090 DSC00094 DSC00099


As above, strip the newly truncated cable and tin all ends. Once done, de-solder the original chunk of cable, re-soldering the newly cut ends in the same order. Make sure to keep the white bridging wire between both PCBs. Finally, run the cable through the zig-zag and hold it there for a bit to make sure it understands its new role. If you just place it and let go then the cable tends to want to return to it's standard straight-line form. It's actually tough for a thick cable to make those curves, but as mentioned above, it's for the sake of the guts of the contorller.


Finally, test, test, test and test again! Ah... that GREEN RIGHT LED is beautiful.

Filed under: Retro No Comments

Farallon EtherMac Mac/PB Adapter

This was another lesson in failure. I'd recently picked up a PowerMac 6400 (more about that later) from an impulsive eBay auction and then this item came across the Vintage feed. I couldn't resist and no one else cared for it. The basic idea is that you can route Ethernet over LocalTalk to get a Macintosh, which doesn't have standard Ethernet capability, connected to an Ethernet network. This unit plugs into the Serial port (either Printer or Modem) and hijacks power from an ADB port. The piggy-back adapter is nice as most users still want to plug their keyboard/mouse in!


DSC00047 DSC00035a DSC00040a


Most forum posts indicate that these units need no drivers installed. I was happy with this and went ahead and connected the unit to my LAN. Most lights came on, but I couldn't get anything to work. If you do have this unit, then you need to use MacTCP (this unit is not compatible with OpenTransport!) and set up your unit to have hard-coded IPs via a static MacIP setup. From there, everything should just work. As that you're using an older System 7.5.3 (or lower), you don't get to search for Servers by IP address in Chooser, so make sure you have a real Mac on the network to test with. A2Server might also help.

Anyway, whatever I tried... nothing worked. I'd plug the unit in to the Mac and the power light would illuminate. I'd open up Chooser and the next light from power (orange) would start to blink... but the final light, the Ethernet Link Light, would just be flashing quickly. I initially thought this was ethernet traffic, but then realised that this light should actually be a solid green and that the 4th light should indicate traffic. You really only had to flip the unit over to work this out, Steven. So, my unit wasn't even getting link! Easily confirmed by no link light on a hub I managed to power up and then doubly-confirmed by the diagnostic software provided in the v2.22 of the Farallon Software.

So, I popped the unit and started replacing capacitors. I then tried replacing the chips that seemed identical to an ethernet card that I had spare... and in the end? Killed two cards and ended up with zero connectivity! Fortunately the PM6400 accepted an RTL3189, although not under System 7.5.5.

Lesson learnt? A Farallon EtherMac Mac/PB Adapter that has a flashing ethernet link light is dead. Don't even bother trying to use it. Make sure you see a link light at the other end of the ethernet cable before trying to troubleshoot any further.

In hindsight: I wonder if the unit just couldn't negotiate the 100mbit hub? Maybe it only works with 10mbit devices. Too late to test now!

Filed under: Apple No Comments