Subscribe via RSS

HP Dual PIII-500 Motherboard

I had a good to-and-fro with the Seller on this item. He initially wanted ~AUD500 for it, so I low-balled just under 200. He didn't accept, but then proceeded to get zero bids. It was then re-listed at an auction price of AUD99 and didn't go for much more. If you look on eBay US, seems they're still fetching quite a few dollars! Anyway, it's a dual P3-500 board with on-board SCSI! Nice. The only thing I didn't know was what server it had been ripped out of.


DSC02155 DSC02158 DSC02159

DSC02165 DSC02173 DSC02188

Looking at the photos now, I see that there's a glaringly-obvious Hewlett Packard logo hidden below the AGP slot... something I totally missed when the board arrived. So instead, after a little googlin', I had determined that it was the motherboard from a HP Compaq Netserver E60. This was thanks to the "exchange" code/part-number of "D7140-63000" labelled on one of the ICs.

Front Panel Connector Pinout

Found that someone else had restored such a unit, but not so recently. A private message to the author saw no response. What did help though, were the pictures in that post. IT shows that there's no reset button? Just Power LED, Power Switch and HDD LED.


So, what to do? Grab a screwdriver and poke the pins! Actually, first I worked out which pin was ground via a multimeter. Turns out it's second-from-the-left, but there's only one ground, so that meant getting the LEDs lit will be tricky. After a bit more poking, the left-most pin was determined to be the power switch and, before I knew it, the motherboard speaker was beeping awfully as it had no Video or RAM.


HDD activity wasn't on the header, so I just used the connection directly on the SCSI drive.

A Suitable Video Card

I've had this crazy ATI Rage 128 All-In-Wonder in as box for ages and have never had a good reason to test it. Thankfully, this motherboard has AGP, so let's do it!


With this card in place, most of the operating systems I tried had issues. Drivers, resolutions, framebuffers... this card seems to be a bit of a Unicorn and really only good for Windows. Fortunately, a little bit of effort paid off and it ended up working on all systems. For future reference, here's a possible pinout for the video out breakout cable.

So, What RAM?

The manual indicates that the motherboard supports up to four SDRAM DIMMS, for a maximum total of 1GB. These are expected to be full server-grade and I had quite a few lying aorund. The actual specifications are: 64MB, 128MB, or 256MB unbuffered, 72 bits wide, ECC single-bit correcting, multi-bit detecting. So, those huge DIMMs in the box, with huge stickers and terms like 'sync':


Finally, I get to use the ECC SDRAM modules that seem to be very popular (i.e. in everyone's junk box gathering dust) and never usable in standard desktop motherboards! And, summing up what worked, I could only get to 384mb RAM. I tried mixing ECC and Non-ECC, but this threw a really ugly error. Interestingly it can obviously tell if the RAM DIMM is Non-ECC. Also mixing ECC 133mhz with 100mhz would throw shitty beeping. Finishing the RAM combination testing, I then just put in normal PC100 SDRAM and the bloody thing just booted straight up! No errors, no warning that this was pleb-RAM and not servah-RAM? This was a better option as I had enough laying around to get up to 512mb.

Microcode Update Block Missing

This error appears on HP NetServers when third-party CPUs are used which didn't come with a microcode block flashed onto them.


Could it be that these CPUs have just lost the block that had been previously flashed? Regardless, someone else has already solved this issue, but the link to HP for the new BIOS to flash is well gone! A quick google turned up this BIOS update, but it wants Windows and the filename ends in FR?... I'll get to that after I've mucked around with other OSsss.

Redhat Linux 7.2

And then for some Redhat! I already had the CDs burnt thanks to installing it on the Sony Vaio Z505. The installation was a breeze, but the installer did try to trick me into selecting the wrong video card.


DSC02091 DSC02095 DSC02097

Instead, choose the All-In-Wonder 20-ish lines above. Don't forget to test the mode!


Interestingly, as above, the mode worked fine during setup! Not so well once it then tried to boot... I'd selected the graphical login during install, so on first reboot, the machine produced a blank screen when it tried to load up XDM. It was still the correct resolution, but the whole machine had actually frozen up! No keyboard, no mouse, nothing... SSH wasn't running, so I couldn't connect underneath either! What to do? I could single-user and work out how to switch to text login, or re-install. I chose the latter to save time and effort.

Second time around, a login! startx still produced a blank screen though... at the correct resolution! I rebooted once more, but this time I logged in via SSH and ran startx remotely and...

Last login: Wed Feb 24 03:38:38 2021
[root@localhost root]# startx

XFree86 Version 4.1.0 (Red Hat Linux release: 4.1.0-3) / X Window System
(protocol Version 11, revision 0, vendor release 6510)
Release Date: 2 June 2001
        If the server is older than 6-12 months, or if your card is
        newer than the above date, look for a newer version before
        reporting problems.  (See http://www.XFree86.Org/FAQ)
Build Operating System: Linux 2.4.9-31smp i686 [ELF]
Build Host:

Module Loader present
(==) Log file: "/var/log/XFree86.0.log", Time: Wed Feb 24 03:43:04 2021
(==) Using config file: "/etc/X11/XF86Config-4"
Markers: (--) probed, (**) from config file, (==) default setting,
         (++) from command line, (!!) notice, (II) informational,
         (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) ServerLayout "Anaconda Configured"
(**) |-->Screen "Screen0" (0)
(**) |   |-->Monitor "Monitor0"
(**) |   |-->Device "ATI All-in-Wonder 128 Pro AGP"
(**) |-->Input Device "Mouse0"
(**) |-->Input Device "Keyboard0"
(**) XKB: rules: "xfree86"
(**) XKB: model: "pc105"
(**) XKB: layout: "us"
(**) FontPath set to "unix/:7100"
(**) RgbPath set to "/usr/X11R6/lib/X11/rgb"
(==) ModulePath set to "/usr/X11R6/lib/modules"
(--) using VT number 7

(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
(II) Module bitmap: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/libpcidata.a
(II) Module pcidata: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 0.1.0
(II) Loading /usr/X11R6/lib/modules/libscanpci.a
(II) Module scanpci: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 0.1.0
(II) Unloading /usr/X11R6/lib/modules/libscanpci.a
(--) PCI:*(1:0:0) ATI Rage 128 RF rev 0, Mem @ 0xf8000000/26, 0xf4200000/14, I/O @ 0x9000/8
(II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a
(II) Module GLcore: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/extensions/libdbe.a
(II) Module dbe: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/extensions/libextmod.a
(II) Module extmod: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/linux/libfbdevhw.a
(II) Module fbdevhw: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 0.0.2
(II) Loading /usr/X11R6/lib/modules/extensions/libpex5.a
(II) Module pex5: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/extensions/libdri.a
(II) Module dri: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/linux/libdrm.a
(II) Module drm: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/extensions/libglx.a
(II) Module glx: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/extensions/librecord.a
(II) Module record: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 1.13.0
(II) Loading /usr/X11R6/lib/modules/extensions/libxie.a
(II) Module xie: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/drivers/r128_drv.o
(II) Module r128: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 4.0.1
(II) Loading /usr/X11R6/lib/modules/drivers/ati_drv.o
(II) Module ati: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 6.3.6
(II) Loading /usr/X11R6/lib/modules/input/mouse_drv.o
(II) Module mouse: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 1.0.0
(II) ATI: ATI driver (version 6.3.6) for chipsets: ati, ativga
(II) R128: Driver for ATI Rage 128 chipsets: ATI Rage 128 RE (PCI),
        ATI Rage 128 RF (AGP), ATI Rage 128 RG (AGP), ATI Rage 128 RK (PCI),
        ATI Rage 128 RL (AGP), ATI Rage 128 SM (AGP),
        ATI Rage 128 Pro PD (PCI), ATI Rage 128 Pro PF (AGP),
        ATI Rage 128 Pro ULTRA TF (AGP), ATI Rage 128 Pro ULTRA TL (AGP),
        ATI Rage 128 Pro ULTRA TR (AGP), ATI Rage 128 Mobility LE (PCI),
        ATI Rage 128 Mobility LF (AGP), ATI Rage 128 Mobility MF (AGP),
        ATI Rage 128 Mobility ML (AGP)
(II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon QD (AGP),
        ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP),
        ATI Radeon VE QY (AGP), ATI Radeon VE QZ (AGP),
        ATI Radeon Mobility LW (AGP), ATI Radeon Mobility LY (AGP),
        ATI Radeon Mobility LZ (AGP)
(--) Assigning device section with no busID to primary device
(--) Chipset ATI Rage 128 RF (AGP) found
(II) Loading /usr/X11R6/lib/modules/libvgahw.a
(II) Module vgahw: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 0.1.0
(II) R128(0): PCI bus 1 card 0 func 0
(**) R128(0): Depth 16, (--) framebuffer bpp 16
(II) R128(0): Pixel depth = 16 bits stored in 2 bytes (16 bpp pixmaps)
(==) R128(0): Default visual is TrueColor
(==) R128(0): RGB weight 565
(II) R128(0): Using 6 bits per RGB (8 bit DAC)
(II) Loading /usr/X11R6/lib/modules/linux/libint10.a
(II) Module int10: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 1.0.0
(II) R128(0): initializing int10
(II) R128(0): Primary V_BIOS segment is: 0xc000
(--) R128(0): Chipset: "ATI Rage 128 RF (AGP)" (ChipID = 0x5246)
(--) R128(0): Linear framebuffer at 0xf8000000
(--) R128(0): MMIO registers at 0xf4200000
(--) R128(0): VideoRAM: 16384 kByte (128-bit SDR SGRAM 1:1)
(II) R128(0): PLL parameters: rf=2864 rd=63 min=12500 max=25000; xclk=9000
(II) Loading /usr/X11R6/lib/modules/libddc.a
(II) Module ddc: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/libvbe.a
(II) Module vbe: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 1.0.0
(II) R128(0): VESA BIOS detected
(II) R128(0): VESA VBE DDC supported
(II) R128(0): Manufacturer: PTS  Model: 30d  Serial#: 214342
(II) R128(0): Year: 2005  Week: 22
(II) R128(0): EDID Version: 1.3
(II) R128(0): Analog Display Input,  Input Voltage Level: 0.700/0.700 V
(II) R128(0): Sync:  Separate
(II) R128(0): Max H-Image Size [cm]: horiz.: 34  vert.: 27
(II) R128(0): Gamma: 2.50
(II) R128(0): DPMS capabilities: Off; RGB/Color Display
(II) R128(0): First detailed timing is preferred mode
(II) R128(0): redX: 0.630 redY: 0.330   greenX: 0.300 greenY: 0.600
(II) R128(0): blueX: 0.148 blueY: 0.098   whiteX: 0.310 whiteY: 0.330
(II) R128(0): Supported VESA Video Modes:
(II) R128(0): 720x400@70Hz
(II) R128(0): 640x480@60Hz
(II) R128(0): 640x480@67Hz
(II) R128(0): 640x480@72Hz
(II) R128(0): 640x480@75Hz
(II) R128(0): 800x600@56Hz
(II) R128(0): 800x600@60Hz
(II) R128(0): 800x600@72Hz
(II) R128(0): 800x600@75Hz
(II) R128(0): 832x624@75Hz
(II) R128(0): 1024x768@60Hz
(II) R128(0): 1024x768@70Hz
(II) R128(0): 1024x768@75Hz
(II) R128(0): 1280x1024@75Hz
(II) R128(0): Manufacturer's mask: 0
(II) R128(0): Supported Future Video Modes:
(II) R128(0): #0: hsize: 1280  vsize 1024  refresh: 60  vid: 32897
(II) R128(0): Supported additional Video Mode:
(II) R128(0): clock: 108.0 MHz   Image Size:  337 x 270 mm
(II) R128(0): h_active: 1280  h_sync: 1328  h_sync_end 1440 h_blank_end 1688 h_border: 0
(II) R128(0): v_active: 1024  v_sync: 1025  v_sync_end 1028 v_blanking: 1066 v_border: 0
(II) R128(0): Ranges: V min: 60  V max: 75 Hz, H min: 30  H max: 80 kHz, PixClock max 140 MHz
(II) R128(0): Monitor name: 17JAGBLK-AV
(II) R128(0): Serial No: P2U052214342
(==) R128(0): Using gamma correction (1.0, 1.0, 1.0)
(II) R128(0): Monitor0: Using hsync range of 30.00-80.00 kHz
(II) R128(0): Monitor0: Using vrefresh range of 60.00-75.00 Hz
(II) R128(0): Clock range:  12.50 to 250.00 MHz
(II) R128(0): Not using mode "1400x1050" (hsync out of range)
(II) R128(0): Not using mode "1400x1050" (hsync out of range)
(II) R128(0): Not using default mode "640x350" (vrefresh out of range)
(II) R128(0): Not using default mode "640x400" (vrefresh out of range)
(II) R128(0): Not using default mode "720x400" (vrefresh out of range)
(II) R128(0): Not using default mode "640x480" (vrefresh out of range)
(II) R128(0): Not using default mode "800x600" (vrefresh out of range)
(II) R128(0): Not using default mode "800x600" (vrefresh out of range)
(II) R128(0): Not using default mode "1024x768" (vrefresh out of range)
(II) R128(0): Not using default mode "1024x768" (vrefresh out of range)
(II) R128(0): Not using default mode "1280x960" (hsync out of range)
(II) R128(0): Not using default mode "1280x1024" (hsync out of range)
(II) R128(0): Not using default mode "1600x1200" (hsync out of range)
(II) R128(0): Not using default mode "1600x1200" (hsync out of range)
(II) R128(0): Not using default mode "1600x1200" (hsync out of range)
(II) R128(0): Not using default mode "1600x1200" (hsync out of range)
(II) R128(0): Not using default mode "1792x1344" (hsync out of range)
(II) R128(0): Not using default mode "1792x1344" (bad mode clock/interlace/doublescan)
(II) R128(0): Not using default mode "1856x1392" (hsync out of range)
(II) R128(0): Not using default mode "1856x1392" (bad mode clock/interlace/doublescan)
(II) R128(0): Not using default mode "1920x1440" (hsync out of range)
(II) R128(0): Not using default mode "1920x1440" (bad mode clock/interlace/doublescan)
(--) R128(0): Virtual size is 1280x1024 (pitch 1280)
(**) R128(0): Default mode "1280x1024": 135.0 MHz, 80.0 kHz, 75.0 Hz
(--) R128(0): Display dimensions: (34, 27) cm
(--) R128(0): DPI set to (95, 96)
(II) Loading /usr/X11R6/lib/modules/libfb.a
(II) Module fb: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 1.0.0
(II) Loading /usr/X11R6/lib/modules/libramdac.a
(II) Module ramdac: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 0.1.0
(II) Loading /usr/X11R6/lib/modules/libxaa.a
(II) Module xaa: vendor="The XFree86 Project"
        compiled for 4.1.0, module version = 1.0.0
(==) R128(0): Write-combining range (0xf8000000,0x1000000)

And then the SSH session timed out. Seems that the card driver has tried to instantiate the DRM driver and frozen. A lot of mucking around then ensued, but the answer is simple: The r128 X11 driver didn't load the r128 DRM kernel module, so when it tries to call it, it just locks up. The answer is to run insmod r128 prior to starting X. Of course, this wont work if you've chosen to go for the graphical login. To get it to start on boot, edit /etc/rc.d/rc.local and slap the insmod line in there.


If you've already installed a distro and can't do anything as it boots to a black screen each time, then you need to edit your bootloader config to get linux to boot into single-user mode. For grub, hit E when the boot menu appears, select the second line and hit E again. Navigate to the end of the line and add the word single.

DSC02141 DSC02144 DSC02147

Hit enter and then press B. Linux will then boot, mounting disks, and provide a shell prompt with you already logged in as root. Just edit rc.local from here, inserting the insmod r128 command, and reboot. From here, all was working perfectly. I hadn't tested the All-In-Wonder features though... Looks like I'd need Gatos. The instructions don't look that hard.

Back to that BIOS update, can I use Wine?

Wine was installed by default, and so I wondered if I could run the BIOS updater from Linux? I wasn't ready to install XP/98SE/ME just yet. I downloaded the file and gave it a go:

[root@localhost root]# wine
wineserver: chdir /root/.wine : No such file or directory
[root@localhost root]# mkdir .wine
[root@localhost root]# wine
Wine release 20010731

Usage: wine [options] [--] program_name [arguments]
The -- has to be used if you specify arguments (of the program)

   --debugmsg name  Turn debugging-messages on or off
   --dll name       Enable or disable built-in DLLs
   --dosver x.xx    DOS version to imitate (e.g. 6.22)
                    Only valid with --winver win31
   --help,-h        Show this help message
   --managed        Allow the window manager to manage created windows
   --version,-v     Display the Wine version
   --winver         Version to imitate (win95,nt40,win31,nt2k,win98,nt351,win30,win20)
[root@localhost root]# wine e60bios_fr.exe
x11drv: Can't open display:

Ok ok, let's start X...


Ok sure, it's just a WinZip Self-Extractor that makes a floppy image... can we extract the image?

[root@localhost root]# unzip e60bios_fr.exe
Archive:  e60bios_fr.exe
  inflating: makeunix.bat
  inflating: disk1.img
  inflating: rawrite2.exe
  inflating: disks.ico
 extracting: about.txt

Yes, yes we can. We don't have to use rawrite as Linux has dd, but we'll just check what's in that batch file:

[root@localhost root]# cat makeunix.bat
@echo off
echo Hewlett Packard Company Self extracting diskette Set
echo You will need 1 formatted diskette(s) to continue
echo Press Enter to Continue or Cntrl-C to end the job
pause ^>nul:
echo Diskette Creation disk1
echo NetServer E60 BIOS Update Diskette
echo Press Enter to Continue or  Cntrl-C to end the job
pause ^>nul:
rawrite2.exe -f disk1.img

Nothing special... just a dump straight to floppy. Let's do that, Linux-style! Before I format this floppy... what's on it?


Oh, just a WAD for DOOM II of our high school. Excuse the crappy image... I was a little excited to find a floppy from a drawer with ~20 year old data on it?! I'll write another post on that. Where as I?

[root@localhost root]# dd if=disk1.img of=/dev/fd0 bs=1024 conv=sync ; sync
1440+0 records in
1440+0 records out
[root@localhost root]# cd /mnt
[root@localhost mnt]# mount floppy/
[root@localhost mnt]# ls floppy/
config.sys  contents.abf  io.sys  language.dat  msdos.sys  phlash.exe  phlshwrp.exe  phlshwrp.hds  phlshwrp.ini  platform.bin
[root@localhost mnt]# ls -l floppy/
total 688
-r-xr-xr-x    1 root     root           29 Aug 18  1998 config.sys
-r-xr-xr-x    1 root     root          305 Oct 27  2000 contents.abf
-r-xr-xr-x    1 root     root       524288 Oct 27  2000
-r-xr-xr-x    1 root     root        40992 May 31  1994 io.sys
-r-xr-xr-x    1 root     root            2 Dec 10  1998 language.dat
-r-xr-xr-x    1 root     root        38166 May 31  1994 msdos.sys
-r-xr-xr-x    1 root     root        65605 Feb  9  1999 phlash.exe
-r-xr-xr-x    1 root     root        21179 Jan 13  1999 phlshwrp.exe
-r-xr-xr-x    1 root     root         6791 Dec 31  1997 phlshwrp.hds
-r-xr-xr-x    1 root     root         1739 Oct 27  2000 phlshwrp.ini
-r-xr-xr-x    1 root     root         1207 Jan 22  1999 platform.bin

Nice, there's our boot disk. Time to shutdown and boot the machine with the floppy inserted.

DSC02109 DSC02116 DSC02120

Make sure your flexible disk is set to a higher priority than your solid disk. And then learn french! Or.... cheat...


Note that it did mistranslate one 0 for an 8, but whatever, just do the next-next-finish:

DSC02141 DSC02130 DSC02131

And then it'll reboot by itself:


Yey! Microcode 0000000E installed!

Dodgy LAN Port

For the life of me, I couldn't work out why I had intermittent LAN connectivity whilst using the machine. It wasn't until I checked the LEDs at the back on the port to see that sometimes none were lit, other times just link and then finally activity also. On my LAN, there's always activity thanks to streaming South Yarra Railcam, so it was very strange to see only link lit up.

A quick jiggle of the cable saw that all change though. If I forced the cable away from the board, the lights would go out. On the contrary, pulling the cable down towards the motherboard saw the LAN port function 100% correctly. It seems that the contacts inside the socket were not making a good enough connection with the end of the cable and needed adjusting. Fortunately, the tweezers from the iFixit kit worked perfectly for grabbing each of the 8 contacts and bending them up. At the very back of the plug is a guide for each contact to slide down when the LAN cable is inserted, so I just made sure not to lift the contact wires past/out-of these.

BeOS R5 Professional

This took a little bit of re-learning. After acquiring the ISO, everything just installed perfectly. Google even, sorta, showed in NetPositive. I then tried to set up World O' Networking and, after it restarted the network server, nothing worked anymore. Even a ping from Terminal just threw: ping socket: name not found. A google for this error brought up an Arstechnica forum post from 1999 where a user had the same error! I re-installed BeOS and the network worked again... I re-installed WON and it died again. Reading the doco, it said that if I wanted to uninstall WON thoroughly, I had to go to /beos/system/boot and edit Netscript. Turns out this file didn't even exist! The WON setup had failed to copy in its substitute and had just renamed the old file. I grabbed it manually from the desktop and then everything booted up! But there were no computers to be found in the WON folder on the desktop.

Windows XP

As you'd pretty much eXPect, it all just worked perfectly. All CPUs online and all hardware flying along.


I installed the ATI drivers and even managed to half-capture my shitty megadrive clone. The picture wasn't healthy, but I don't know if I was expecting it to even work, let along show a picture!

Filed under: Retro No Comments

Repairing Atari 2600 Original Wireless Controllers

So, I've recently been repairing a large selection of Atari paraphenalia and, included in the container-load, was an official Atari-branded CX-42 wireless controller kit! The setup is pretty awesome; the base unit has a power input and then an output to go to the console. This means it doesn't need a separate power adapter as it chains into the power for your Atari. It then has the two controller plugs which you simply insert into the left and right controller ports on your console. Finally, the joysticks are more-or-less standard one-button Atari joysticks with extra 4cm bases to contain a 9v battery and radio circuitry.


DSC00674 DSC00671 DSC00698

Of course, this came to me due to being unhealthy. One of the controllers wouldn't go left! I'd usually associate this to cable failure, but... well... they don't really get much abuse in this scenario! They needed a good clean anyway, so the tear-down and diagnosis begun.

Is it the controller? (Hard way!)

So, just because I'd previously torn 100s of these apart, I went straight to the controller to check the internal switches. The construction of these is relatively simple, until you try to separate the joystick circuit board from the actual joystick... so many screws and springs fly everywhere. Regardless, once the unit was open, all switches were tested and found to be functional. I didn't think of taking a photo at the time, so you'll just have to imagine.

Is it the controller? (Easy way!)

After a little googlin', I stumbled across this hint stating that you could 'hear' the controllers using an FM radio. Hah, of course you can... It seems that they use frequencies down around ~40mhz, but somehow you can hear this at ~100mhz on your FM radio. So, what to do? Find an FM radio first. Fortunately I had some on the shelf thanks to wanting to listen to tapes a few months back.

On Windows 10, you'll find there's no more sndrec32. Instead you need to browse over here and Voice Recorder. Yey for anti-monopolistic effort! Anyway, I managed to record the following:

What you'll hear above is: Static -> radio station -> static -> radio station -> static -> weak carrier signal! -> misc. tuning -> STRONG CARRIER SIGNAL! -> 5 presses of the fire button -> ~7 full rotations of the joystick -> 6 presses of the fire button (the last one is longer) -> static. Totally random! But it's a great way to test.

As you can hear above, I started just above ~102mhz FM and scrolled down until I found the carrier signal. Note that I had difficulty originally finding the signal as it's not that strong. Make sure you hold the joystick against whatever FM receiver you're using.

Once the carrier signal was found, I then fine-tuned it until the signal was the strongest and began mashing buttons. Of course, just because LEFT is transmitting something, doesn't mean it's transmitting the correct signal! But hey, we can now check the base to see if there's any obvious issue.

Is it the base unit?

The circuitry inside this unit is, thankfully, quite easy to trace and diagnose. The unit consists of two individual circuits, decoding each controller independently. This is actually a life-saver, thanks to one of the joysticks being 100% functional! With my multimeter in-hand, I went ahead reviewing the circuit and measuring signals along the way. Doing this for both joysticks and both circuits meant that it was straight-forward to determine where the signal started going funny!


Starting from the output, there are two hex-inverter chips on each side. All 6 inverters (2chips x 3inverters) on each side are used and these flip the signal before sending it out to the controller port. The left button was seeing a twitch in the voltage, but not enough to flip the inverter to full +5v. The input was meant to drag to ground, sending the full signal out, but it wasn't happening.

Tracing the signal back, there is an OKI MSM4015RS IC and, for the life of me, I still can't find a datasheet online. I thought this would be a show-stopper, but after testing the signals on this IC for both joysticks when the fire button was pressed, it turns out they're both reporting the same values.

I therefore traced the value back up towards the output and found that the output after the first inverter wasn't being dragged low enough. It was 0.6v on the working joystick and 0.7v on the failing joystick. The output of the inverter is tied to ground with a green-cap and tied high with a 4.7k resistor.

The resistor checked out, but I had no way to test the capacitor with my multimeter. Instead, I swapped the capacitor from joystick one's side to joystick two's. Surprisingly, this now saw joystick one's LEFT button working and joystick two's was now faulty. Nice!

Replacing all green-caps

You'll find three different-valued sets of green-caps on this board: 10x 183k100v (18nf), 10x 223k100v (or 2A223K) (22nf) and 6x 104k100v (100nf). I went ahead and purchased a full set of them from Jaycar with the goal to replace every one of them.


Who knows how close another is to frying?


The aftermath... (did I say only the green-caps? Ooops.. I didn't discriminate and took out the electros as well.)


Removing and replacing was easy enough. I really recommend Goot-Wick desoldering braid for cleaning up the PCB whilst you're doing things like this.

Now up doesn't work?

Hah, seems that enough plugging-and-un-plugging of the controller output cables from the main board caused one pin to fail. Thanks to standard technology, there were plenty of these plugs in my junk box, although not with the same pin count...


So I borrowed an internal connector from a three-pin plug and soldered it in. Worked perfectly!

A minor note on the usage of these wireless controllers

With the wireless base unit powered-on and fully-connected to your Atari, it'll send spurious/erratic/totally-crazy signals to the console on the joystick cable of any joystick that is turned off! There is therefore a correct sequence for powering everything up... Turn the joysticks on first and then the base unit. Note that the base unit doesn't have a power switch, so I'd recommend always turning it off at the wall. I suppose you could then leave the Atari power switch on, as you'll be using the wall switch as the power cable is chained through the wireless controller receiver. Just make sure that both controllers are powered on BEFORE you turn on the wall switch!

When I was first diagnosing this kit, I thought all was pointless after seeing the random signals coming out of the base unit. I was very happy to see the signals settle once the joysticks were powered up!


This unit worked splendidly with 2600-series consoles and games.


Even 2600 games in a 7800 console. What didn't work was the built-in asteroids for/on the 7800.


For some reason, the down and fire buttons won't work. Of course, a standard 1-button Atari 2600 joystick works fine on 7800-Asteroids, but this unit doesn't. I did a little digging and found that the pins aren't brought straight to ground... instead they hover around 150-250 ohms... I wonder if that's enough to not send through a proper button press? Also, they seem to 'repeat'... the multimeter actually goes pretty damn crazy when a button is pressed, beeping on and off as the resistance floats near-zero. As mentioned above, each output is tied high by a 4.7k resistor and low by a 22nf green-cap capacitor. I assume the cap is there to de-bounce the incoming signal, but maybe it's not big enough to trigger a single press for the 7800? I don't want to modify this unit as it's very original, so I'll just suggest that if anyone else wants to use this on a 7800 then they should tinker with the pull-down capacitors on the output lines.

Again, they worked 100% perfectly with all 2600-series equipment I tested.

Battery Cover

One was missing, so I used my Creality CR6-SE to bring a replacement. It didn't turn out toooooo bad. Works well when there's a battery inside... falls out when there's no battery!

DSC00715 DSC00716 DSC00718


Filed under: Retro No Comments

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

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

Atari 2600 Jr – Recapping + Controllers + Composite

Another one of these little units came across my workbench. This time it was a full set with two joysticks and a lot of games... including a boxed version of Frogger! I'd played with one of these before in my previous-previous apartment, so it must be nearly 4 years ago that I met my first Atari. This one wasn't as clean-and-tidy as the previous version, but it still worked nicely.


DSC00137 DSC00138 DSC00141

The first task was to upgrade the unit to composite output, so I jumped over to my previous post on the topic. I purchased all the components needed from Jaycar and, just before I was about to solder to the pins on the IC, realised that the actual mod instructions showed you where to solder. Not to the pins of the IC, but to the legs of the surrounding resistors.... the diagram is even colour-coded. I therefore also didn't have to scratch back a ground pad either!


In no time, the composite signal was being sent out and my TV Tuner card was picking it up nicely. Whilst I was performing the mod, I noticed that the surrounding electrolytic capacitors weren't looking the cleanest, so I replaced those too. After another trip to Jaycar, purchasing 4x 4.7uf and 1x 2200uf (unfortunately they didn't stock double-ended!) capacitors, I went about removing the old ones and soldering in the new ones. Solder wick really works well here to clean the holes in the PCB prior installing the new capacitors. The positive pins are also nicely marked on the PCB.

DSC00143 DSC00145 DSC00146


DSC00151 DSC00159 DSC00160


With everything replaced, there was no noticeable change in video quality or system stability, but neither were a problem to start with. This was more for longevity! I slapped in the multi-cart and tried Pitfall out. The Quickshot controller worked OK, but felt very sticky and the buttons weren't responding to each keypress... what to do? Pull it apart.

The board was not clean... so I grabbed some isopropyl wipes and gave it a good once-over. I also re-soldered the main A button wire as it had previously been compressed by the case and didn't look like it'd hold out much longer. With the unit back together, I could now jump on-command with the button on the base, but the trigger button up top wasn't overly responsive. The stick itself has three screws that hold it together, so I popped them out to have a look.

DSC00087 DSC00092 DSC00094

Turns out the top button had been mashed to within an inch of its life and the previous players had actually punched a hole in the PCB, removing the trace that the button was meant to make contact with.

A little bit of solder was added, which caused a height increase of the pad. I was slightly concerned that this would mean the button could mis-fire, but the spring prevented that from occurring... instead it just meant the button didn't have to travel as far to make contact. I could now jump through Pitfall reliably! Mario Bros was also now a lot more fun!


I suppose the final step now is to find a new ball for the top of this chewed-on stick!

Filed under: Retro No Comments

Sega Mega Drive – Composite + Region-Free

On a total tagent from recent Amiga stuff, I found this in a box whilst I was moving house. I'd totally forgotten that I'd picked it up from a flea market prior to the Christmas Trip overseas.


DSC00102 DSC00105 DSC00107

I grew up a Nintendo-kiddie with Super Mario Bros and Duck Hunt, so the likes of California Games (oops, that's master-system-vintage) and Sonic were a weird adventure whenever I went to friend's houses. This unit arrived slightly scratched-up, but in perfect working condition. It came with a power pack and RF switch, but I wanted Composite output... so I started googlin' for hacks. Then I looked at the back of the machine and realised it had an 8-pin DIN for A/V output. A quick search found off-the-shelf cables, as I didn't have a properly degree'd DIN plug available that'd fit the socket. Your standard 8-pin DIN has the top two outer pins at a different degree and therefore wont fit.

Instead I had to make one from a 5-pin DIN as it turns out the pinout of the A/V Output port has all the pins I'll need at 3 o'clock, 6 o'clock and 9'oclock!

DSC00114 DSC00112 DSC00120

I purchased a 5-pin DIN port from Jaycar and hacked a standard stereo composite RCA video cable in half. From there, I joined ground together and soldered that to pin 3 on the 5-pin DIN. I then twisted L+R together, as this unit produced MONO sound and soldered that to the left-most pin, when looking at the back of the plug. Finally, the central wire from the yellow video plug was soldered to the right-most pin.

From here, the unit worked perfectly! Of course, to test I only had one game...


To make this fit, I had to actually gently file the cartridge slot.


Turns out the japanese-release games are square, whereas the Australian (and probably elsewhere) release carts have 2 rounded corners. After making it fit, the game just worked... although it might play slightly faster on a 60hz clock!

Filed under: Retro No Comments

PCMCIA Cards on Desktop PCs

The PCMCIA (or PC Card) standard was built for portable machines which involve smaller form-factors than desktop PCs. Similar to ISA and PCI cards in desktop PCs, the cards offered expansion capabilities for portable machines including storage and communications. The most common cards are either ethernet, modem or wireless. Storage became an option with both flash memory cards, IDE interface cards and SCSI cards.

Desktop machines can be fitted out with PCMCIA card interfaces. Below I'll cover ISA to PCMCIA, PCI to PCMCIA and USB to PCMCIA, noting the limitations of each. I've had an IBM External CD-ROM 0991-011 in the collection for a while and I'd always wanted to check out its capabilities noting that it has a sound-card built-in!

The desktop machine that'll be running the tests is a PIII-500 with 512mb RAM. It's got enough storage internally to support multiple versions of Windows, so we can test compatibility across the board. I've actually taken out ethernet and sound cards, and disabled unnecessary onboard peripherals, to prevent hardware conflicts with any installed PCMCIA bridge.


I've tested the following PCMCIA Cards during this article. I wanted to make sure I had a card from each category, since I'd expected that certain adapters wouldn't handle all types of cards.

Device Description Driver
SanDisk 1.2gb Memory Card Flash Storage Uses the standard Mass Storage Driver
Belkin 11g Wireless Card Wireless Network Download
IBM External CD-ROM + Sound Card + Gameport External IDE Interface + Extra Download.EXE

I'm pretty much in-love with the IBM External CD. It's got the beautiful 'Aptiva'-esque styling and a bloody sound-card built-in!


DSC00137 DSC00140 DSC00143

Yup, that's the amazing all-inclusive IBM External CD-ROM, but we'll discuss its capabilities at a later date. Following are the two boring (aka. just-work!) cards...


Super boring. They didn't even try to use a differing palette!

PCMCIA Interfaces

To slap a PCMCIA card into a desktop machine, you'll need some kind of adapter. The following are the units that have been tested throughout this article.

Device Connection
IO-Data CardDock EX/DV ISA
Ricoh PCI
Ricoh PCI
Condor PCI Super Card PCI
AirFree USB

First up, here's the Condor PCI Super Card. It's huge and seems to have been custom built for a specific chassis? It might actually have been for a Kodak photo kiosk or somesuch where there are card slots on the front of the case. Based on it's length, I could see this card providing ports to the front.


Unfortunately, it wasn't detected by any part of the system!

DSC00095 DSC00098 DSC00099

The other Ricoh 485-based and 475II-based cards...

DSC00105 DSC00107 DSC00111

Hagiwara Sys-Com Airfree


DSC00116 DSC00117 DSC01195

And I-O DATA's CardDock2-EX/DV...


DSC00127 DSC00131 DSC00132

The results are as follows. The basic finding have been that the newer PCI/USB interfaces only support specific classes of PCMCIA devices. Those being Mass Storage and Network. As soon as you bring in a card that needs interrupts or other low I/O ranges then you're out of luck. On the flip-side, newer versions of windows don't support the older ISA hardware, meaning that the ISA PCMCIA bridge that I had just wont work on anything newer than Millenium.

Bridge Device Operating System Result
IO-Data CardDock EX/DV All Windows 98 SE Fully operational.
IO-Data CardDock EX/DV Any Windows XP Card cannot be installed. Drivers wont recognise hardware and Add/Remove Hardware doesn't auto-detect it.
Ricoh 485/475II Sandisk Flash Storage Windows 98 SE Works, but cannot be easily re-partitioned. Needed to use BOOTICE. (see information below)
Ricoh 485/475II Belkin 11g Wireless Card Windows 98 SE Worked perfectly. Used Odyssey Client 4.52 for WPA2 access.
Ricoh 485/475II IBM External CDROM Any Failed with resource issues. Hardware could not start.
Condor Super PCI Any Any Entire card couldn't be recognised. Even the BIOS didn't list it. Going in the bin... but it's so cool-looking!
Hagiwara Sys-com Airfree Flash Storage Windows 98 SE Works fine. A bit tricky to install on the US English version of Windows 98 SE as the installer just drops out. Works perfectly on Windows 98 SE JP.
Hagiwara Sys-com Airfree Belkin 11g Wireless Windows XP Works fine, as above with installation.
Hagiwara Sys-com Airfree IBM External CDROM Any As above with the PCI cards, it just doesn't work at all thanks to resource limitations.

Partitioning Removable Media In Windows XP Or Lower

I'd somehow managed to trash the partition table on the SanDisk Flash Memory during the testing above. It hadn't caused the resource errors above (I went back and re-tested the scenarios after I'd realised the disk wasn't actually readable), but it had caused errors when trying to access the drive in My Computer... when it actually chose to show up. Both FDISK, DISKPART and Disk Management in all forms/versions/flavours of old-windows didn't want to touch the partition table. I also tried Partition Magic 7.0, but that didn't care either.

winxp-diskpart-nope winxp-pm70-cant-see winxp-sandisk

Actually, FDisk in Windows 98 SE JP managed to show the card, but then suggested that it was onlt 136mb in size? I actually tried to follow through with it and that's what probably really killed the partition table.

sandisk-fdisk-1 sandisk-fdisk-3 sandisk-fdisk-2

Thanks to this post at, I was directed to an older version of BOOTICE which disregards all forms of safety and allows you to totally wipe and re-partition removable media in older versions of Windows.


Choose the correct disk and click 'Parts Manage'. You'll be presented with the screen below...


I was expecting an option to set up the actual parition table, but nothing was presented. Instead you need to choose 'ReFormat USB Disk' and choose the top option.

WPA2 on Windows 98 SE

As mentioned above, you can install the Odyssey Client 4.52 on Windows 98 to enable connections to WPA2-encrypted wireless networks.


I expected that I'd have to build a guest network with WEP encryption, or worse - no encryption, to test the wireless PCMCIA cards... but I didn't! This software worked perfectly!


The IBM External CD-ROM is super-cool! The fact that it comes with a sound card inbuilt and a gameport/midiport is awesome. I suppose it's really suited to an older laptop that doesn't have a soundcard. I actually tried using the joystick port and it works fine, but don't expect all joysticks to work 100%. I'll post about that soon.

As for the PCMCIA to PCI or USB, you're mileage may vary. If you just want to use flash storage or ethernet cards, then go for it... but why not just get an ISA or PCI card? I remember back in the day I really wanted a PCMCIA to PCI adapter for a wireless card to join the Canberra Wireless network... as actual PCI wireless cards were still a pipe-dream. That never happened... and now I have a surplus of the technology and no real reason to need it. Actually... that's the point behind too many posts on this blog!

Filed under: Retro No Comments