Wednesday, May 29, 2013

CHED - Update

Project CHED (Combined Hardware Emulated Drives)

I have finally got CHED to work. I did a working presentation at OzKFest ( which was held on 27-28 July 2013. A summary of my presentation is as follows :-

There are many solutions providing mass storage for the Apple II. Many of them have come about since I began construction on my own solution. I have tried to list and classify the ones that I am aware of. You can see where CHED fits into the picture.

Disk II Port - Disk II protocol
Semi-Virtual Diskette (SVD) -
bootZero -
SDISK II - DISK II emulator for APPLE II -

Disk II Port - Smartport protocol
Apple //c Smartport Compact Flash Adapter -
Smartport Virtual Hard Drive (SPVHD) -

Apple II Slot - Floppy Drive (Replaces the floppy drive controller as well as the drive unit)
Double Action Pseudo Disk / PseudoDisk2 -
iDisk -
SD DISKII Emulator -

Apple II Slot - Hard Disk Drive (Replaces the floppy drive controller as well as the drive unit)
Apple II IDE/ATA interface -
CFFA / CFFA3000 (inludes floppy emulation) -
Microdrive IDE controller -
Focus IDE HD Controller -

Serial port
Apple Disk Transfer ProDOS (ADTPro) -
ADTPro Virtual Drive - VSDRIVE -
Pocket Serial Host (Uses VSDRIVE) -
Apple Game Server -

AppleTalk Network

ADTPro Virtual Drive - VEDRIVE -

Speaker port
Online Apple II Game Server -
Online Apple II Disk Server -
Cassette tapes using a music payer (PC/iPad etc). Source data from Brutal Deluxe Software

Joystick Port
Apple //t -

CHED is a replacement of the floppy drive unit and still requires the controller card to function.

I'm aiming for CHED to replace all three generations of the Apple II floppy disk unit.

Generations :-
1. 5.25 inch floppy disk.
2. Smartport.
3. 3.5 inch floppy disk.

Here is a list of the Apple II models and the generation of floppy disk that they can operate :-

  • II - 1
  • II+ - 1
  • IIe - 1
  • IIc - 1
  • IIe with Liron or Superdrive card - 1, 2
  • IIc with ROM 0 or later - 1, 2
  • IIGS - 1, 2, 3
  • IIc+ - 1, 2, 3

The hardware construction for CHED looks like this :-

  • Atmega128 handles the user interface, hard drive access, protocol conversion and the Apple II interface.
  • IDT72125 Parallel to Serial FIFO chip handles the read signal data because there is not enough CPU time left to bit bang this out of the Atmega128.
  • LCD and keypad allows selection of which disk files to use.
  • ATA hard drive stores the dsk and nib images under FAT32.
  • USB to IDE converter allows easy access to files on the hard disk. 

Currently only the reading of disk files has been implemented ie writing to disk files is yet to come. The USB to IDE interface has yet to be implemented. Using SD media would simplify the design but I'm still committed to creating a more durable solution.

With this design I have found that the amount of memory has been limiting. More memory would allow a better implementation of FAT32 (specifically having directories) and implementing caching so that the hard drive can reduce the amount of reading it needs to do. Also adding a buffer between the LCD/Keypad and the Atmega32 would improve the feel of the user operation.

With these issues in mind I have embarked on trying a different platform to make things easier for myself.

I'm currently playing around with a Cypress Development board to see if I can improve on my previous design.

Friday, February 1, 2013

IIGS Monitor - A2M6014X - Replacement

It wasn't until my last working IIGS Monitor died that I went looking for alternate solutions. In the meantime a composite monitor would suffice but for the long term an RGB solution was certainly needed. It's times like these that you consider the thought that you can never have too many spares.

I have included here a summary of links to several solutions. Each solution works in varying degrees compared to the original. To obtain an alternate solution the cost in time and money will greatly depend on what other resource you already have or can get a hold of easily.

RGB to RGB (Universal Replacement Chassis for arcade monitors)

RGB to YPbPr (Component).


RGB to all of the above.

After checking out the available options I decided that the best solution for me was to get a replacement monitor. Some solutions came close but nothing gives a picture that is as good as the original. I'm also used to having a monitor that looks like it goes with the other parts of the system, especially when it's on display. Being in Australia and needing the 240 volt version (A2M6014X), it was going to be very difficult to track down. These monitors don't come up for sale very often so while I keep my eyes out for a replacement I was going to try and repair the ones I already had.

The first thing to do was to get hold of some schematics. The closest I could come up with where the ones for the 110 volt model (A2M6014). The schematics are available from here :-

I removed the monitor casing and the only circuit board that I had a clear view of both sides was the power supply. This was the section I was mostly concerned about so it was a good starting point. I compared the schematics and to my surprise I was able to follow along quite nicely. I was able to see where the 110 volt parts where meant to go because the circuit board had been designed for both 110 and 240 volt systems. The relevant parts were populated and the alternate power parts were missing but there was room for them on the board and the vias were there too. I quickly realised that the diagnostics and repair was beyond my current skill level. However I now had greater confidence in the possibility of getting it repaired. I wasn't going to pull the monitor apart any further so I don't know if the rest of the schematics matched my setup but I figured it would be pretty close.

I set about finding someone who was able to repair the units. My first thought was to find a TV repairer. All the ones that I contacted were not interested in repairing my devices. I did however manage to track down a repairer who specialised in arcade machines and he was located only a few suburbs away. His website is :-
He was keen on giving it a go. I supplied him with two faulty monitors, the A2M6014 schematics, a IIGS and instructions on how to perform a diagnostic self test (this displays a test pattern). I was hoping that, from the two faulty ones, he could get at least one monitor up and going. He blew my expectations out of the water when he informed me he had fixed both. He also had the pleasure in telling me that these monitors were designed to be worked on, the circuitry was straight forward and all the parts were still readily available or easily replaced with compatible components.

This was fantastic news. Now I'm back to where I wanted to be. However, I'm not ruling out the possibility that I'll find and use a great alternate solution some day.

Power supply board showing the space for alternate power components and a IIGS Monitor showing the self-test.

Thursday, July 26, 2012

Bluetooth Card - Proof of Concept

Bluetooth Card using the MP3 board and source code.

At KansasFest 2009 when Vince Briel (of Briel Computers unveiled his MP3 card I was instantly captivated and eager to find out how this cool little card functioned. After learning its little secrets, like many of the other Apple II developers, I saw great potential for enhancing this card into other USB and serial communication uses. During the construction of WALTR, my wireless turtle robot, I had toyed with the idea of running the Bluetooth from a card inside the Apple II instead of the current external setup. There were many distractions to keep me from having a crack at it. That was until this week.

Since I was attending this year's KansasFest event I was asked by a fellow Aussie Apple II enthusiast to bring back one of Vince's MP3 cards. Since Vince did not have any pre-made cards remaining I signed myself in to the kit building session and put the card together. Vince had a few spare MP3 boards which I quickly snapped up. I put forward the idea of a Bluetooth card and after a quick discussion we realised we had the resources to pull this off.

The spare board came in handy (easier than starting from a Veroboard). The Bluetooth module part was sourced from my WALTR project and the rest of the parts were pulled from a few super serial cards. We had finished construction by the end of the kit building session. All that was left was the software and testing.

Unlike the MP3 card which shows a flashing LED when working, the Bluetooth module's working state can not be determined by just looking at it. It does have a LED but that's used to show the pairing status with the other Bluetooth devices. We needed to show that data could be sent over the medium. In WALTR's latest program changes I had one of the LEDs change colour depending on which mode is selected i.e. green equals LOGO and red equals direct control. This was going to be the test case. If the LED turned from green to red after sending the character "2" and a carriage return then we would have our proof of concept.

The following day, between sessions, we worked out what was needed to initialise the 6551 chip and the software was written on the Apple II to perform the test case. The theory was there but the card just would not work. We kept at it and it was way past midnight before we had any indication that we were close. We were delighted when the logic analyser showed pulses coming out of the 6551 chip even though they didn't look quite right. Also using the MP3 software to talk to the card, made WALTR's wheels go nuts. We struggled through the night. Finally at 4am, Eureka, we got the light to go red. So after running on empty, having floppy disk corruption issues, wiring issues, two faulty 6551 chips and programming hiccups it was finally done. It should have been difficult to fall asleep after being on such a high but I passed out faster than I could say "Good night".

Thank-you to my team members Vince, Wayne, Alex, George and Sean in getting this project completed in such a short time. It was truly a group effort. It seemed like the right people came together at the right time. It was great to see. I had a ball. Also a big thank-you goes out to all the KansasFest attendees who encouraged us throughout all hours of the day and night.

In conclusion, the card in its current state needs to be initialised manually (dedicated software). It would be nice just to be able to type "PR#2" and then be able to type in the transmission string. For this to occur, an EPROM would need to be programmed and added to the board. Also in this instance of the project we have demonstrated the use of Bluetooth however it would be just as feasible to use XBee or Wi-Fi. Even though KansasFest is over for this year I know that the brainstorming and discussions will continue and we will attempt to develop this hack into a functional product.

Sunday, June 3, 2012

CHED - Update

Project CHED (Combined Hardware Emulated Drives)

It has been a while since I have worked on the hardware part of this project. A few months back I hit a stumbling block. The load on the microcontroller was too great when bit-banging the serial output and at the same time handling all the other tasks. To free up the controller I added a parallel to serial FIFO chip. Even though the bitsteam generated by CHED looked correct I was still unable to the get the virtual master disk to boot. With the tools I had at my disposal I was unable to pinpoint the cause of the problem. The logic analyser I was using was capable of high speed captures and was great for viewing the 16 bit data bus but it had a shortcoming. The buffer was too small for analysing data that had high frequency bitstreams on one channel but low frequency ones on another. The analyser software was also limiting when analysing non popular protocols. By changing a few settings on the standard serial protocol analyser I was able to get it to produce some promising results. Unfortunately only a few dozen bytes get converted before it looses the plot and produces invalid results. Some better tools were required if I were to continue.

I sourced a new analyser. It's not as fast as the other but high speed is not required when dealing with Apple II signals. The great thing is that it is not limited by its own memory. It uses a connected computer to store the captured data. The downside is only having eight channels but that should be enough for this project. The reason I selected this package was because of its great software development kit (SDK) that allows you to create custom protocol analysers. Using the examples provided it was not too difficult to create the AppleIIDiskII protocol analyser. Being able to the record the entire boot process was a fantastic sight to see. Seeing the results is one thing but interpreting the data is another. The data frame processing of the SDK is yet to be fully developed so my best option was to export the byte stream and process it myself.

I generated a simple Microsoft Access application to process the data and produce a sequential view of the information that is read by the Apple II. These two tools have given me a better understanding of what is going on. So far I have only captured the data from a real DOS3.3 master disk booting. I have yet to use these tools to diagnose my own device.

For those of you who wanted screen captures of the DiskII protocol I can go one better. You can download my tools and have a look at the data yourself. You will need :-

1. Saleae Logic 1.1.15 software from here (no licence required to view data). 

2. from here File contains :-
    a. Instructions.txt - Instructions on getting started.
    b. AppleIIDiskIIAnalyzer.dll - DiskII Protocol for the Saleae Logic analyser.
    c. MasterBoot.logicdata - Captured data from a real Apple II master boot disk. View using Saleae Logic 1.1.15 software.
    d. DiskIIDataStreamProcessor.mdb - Microsoft Access 2003 application for processing and viewing the DiskII data stream. You will need MS Access 2003 or above to run this application.

There is still plenty of work to be done. However, I am currently looking into another platform which, if it works out, could fast track CHED's development.

Wednesday, April 25, 2012

WALTR - Update

Project WALTR (Wireless, Apple II, Logo, Turtle, Robot)

WALTR is a Parallax Scribbler 2 (S2) robot that takes in direct action or interpreted Logo movement commands via a serial connection and executes them. Although I designed WALTR to be run from an Apple II computer any computer with a serial port and a Logo software package that supports serial communications can be used. WALTR can still be used as a Logo robot even without its pen lifter and Bluetooth enhancements.

Overview of how it works (once the S2 robot is programmed up):-

WALTR in Logo mode.

- Start up your favourite Logo software package. (Only a few Logo software packages are supported at the moment. Each package will most likely need a different WALTR.LOGO file)
- Load in the file WALTR.LOGO. (This file opens the serial port and overrides the turtle graphics commands. Each turtle graphics command will perform its original function as well as outputting the correct serial protocol information to the serial port.)
- Type in the Logo commands or load in and execute your favourite turtle graphics file.
- WALTR listens to the serial port and waits for a command. When a command is received eg "$70 $00 $C8 $13" WALTR will execute it. ($70 or "F" = forward command, $00 and $C8 make up the distance of 200 units and $13 = command termination.)

WALTR in Direct mode.

- Open a terminal program like HyperTerminal or Parallax-Serial-Terminal.exe. (Currently all devices are set to communicate using 9600 baud, no parity, 8 data bits and 1 stop bit)
- Type "2" to turn WALTR into Direct mode. (Typing "1" will revert it back into Logo mode.)
- Type the required command ie "a" (forward), "z" (back), "," (left turn), "." (right turn), [space] (stop) etc.
- WALTR listens to the serial port and waits for a command. When a command is received WALTR will start and continue that command until a new one is received.

Logo control.

Each version of Logo contains different commands for interfacing with the serial port. Each version also has its own quirks and Logo commands that it does not support. Therefore the example files for each Logo version are different. These are the versions I have covered so far:-

  FMSLogo (free Windows package)

  Apple Logo II by LCSI [1984]
  Apple Logo by LCSI [1983]
  Terrapin Logo V1.0 [1981]

WALTR is not an interpreter so it does not accept Logo commands directly eg "FORWARD 200" instead it accepts interpreted commands in a specific format which you can find in the protocol specification document. Currently the communications are in one direction, that is, to the robot. The problem with this is that Logo does not check to see if WALTR has enough buffer space to hold the sent command. The current buffer of 8192 bytes should be good for about 2000 commands. At some stage I plan to modify the communications protocol so that Logo can be informed as to when the robot is ready to receive information. This will allow WALTR to process an unlimited amount of commands.

In regards to the Apple II Logo versions, these needed a bit of work to get them going. I prefer using Apple Logo II because it is ProDOS based which means I can run it from the hard drive. Apple Logo and Terrapin Logo need to be run from floppy disks. These last two packages are screen based hence they only send out 7bits instead of 8bits per character. The robot code ie WALTR_r01.spin needs to be modified. I have provided a constant in the declaration section called FORCE_7BIT_DATA. This needs to be set to to TRUE if using WALTR with Terrapin Logo V1.0 or LCSI's 1983 Apple Logo. Terrapin logo V1.0 is the oldest of the Logo packages and the most difficult to work with. It does not support command overrides so new commands were created ie TPD instead of PD for Pen Down, TFD instead of FD for forward etc. It also does not support sending out the ASCII character $0 so a work around was required for this. When working with Terrapin Logo V1.0 the parameter TERRAPIN_V1 needs to be set to TRUE.

I have included instruction files and Apple II "dsk" files with the examples.

Direct control.

Direct control allows real time control of the robot. Direct control starts a robot movement then just waits for the next command. The robot keeps performing the command until a new command is issued. This allows WALTR to be controlled from a keyboard, mobile phone etc. The easiest way to control WALTR is to open a terminal program and just send the keyboard keystrokes. Alternatively I have provided a simple program showing how the robot can be controlled on an Apple II using a joystick. Again this program is screen based so the declaration FORCE_7BIT_DATA needs to be set to TRUE in WALTR_r01.spin.

Bluetooth issues.

The cheap Bluetooth modules that I purchased are specified to operate at 5V however the signal lines are still only 3.3V. There is a voltage divider on the back board however from my calculations it only reduces the signal by about 0.1 of a volt, nowhere near close enough to the 3.3V needed. Technically I should place some resistors on the module's RX line to protect it, but looking at other people's projects, this mostly goes unimplemented. These cheap modules seem quite tolerant of the higher voltage.

These modules have not stacked up as well as I had expected. The firmware on the modules has been programmed to use power saving mode. This feature places the module into sleep mode if no data has been received after a given amount of time (this is somewhere in the vicinity of 15 to 30 seconds). I found that I was missing characters during the time the module was coming out of sleep mode. I tried to disable this feature as per the manual but it did not work. I contacted the module manufacturer and they informed me that disabling of the power saving mode has not been implemented. To get around this issue I programmed a heartbeat into the communications driver ie a dummy character sent every few seconds to keep the modules from going to sleep.

For now the module is working, be it in a not so desirable way. I could try reflashing the firmware or desoldering it from the back board and replacing it with an alternate unit however if I had my time again I would probably try purchasing a more refined product like the ones from Sparkfun.

Wiring to the Bluetooth module was cleaned up and the Bluetooth module plug was hot glued to the robot's top casing. It's a nice clean fit and since the module is only attached by the plug I can easily replace it if required.

Serial to Bluetooth (for the Apple II).

I built a transparent container for the serial to Bluetooth module and constructed a plug that allows me to source 5V externally from the Apple II. The plug is just a straight through male to female DE-9 with the ground and 5V signals brought out. The plug gets attached to the Apple II's game port. The construction of the custom moulded plug allowed me to try a new product that I have had my eye on. The product is called Sugru. It's like Play-Doh but it sets hard after a day or so. Initially I thought that the product would set like concrete but I discovered that in fact it turns hard and has a rubbery feel to it like an eraser. That's not a bad thing. It makes it easy to trim with a hobby knife.

Custom moulded plug. Before and after adding Sugru.

Serial to Bluetooth converter attached to the Apple IIe and to the Apple IIgs.

Pen lifter.

I was lucky enough that several people have already constructed pen lifters for the S2 robot. It gave me plenty to think about. My inspiration came from these three implementations.

After doing some testing I found that just one paper clip bent in just the right way could be used to hold up the pen. I was able to get away with not having to modify the S2 casing. However since there is only a small gap of about 3mm to 4mm between the top and bottom sections it took me many attempts to get it just right. The current ring will support itself in the pen hole once the robot is put together but it takes some effort when joining the top and bottom sections.

The up and down movement is handled by a "NARO" sized servo motor. I wanted to build a container for the servo so that I could replace it if needed. I wasn't going to bother unless I could find a light weight and easy to construct solution. Sugru came to the rescue yet again. I was able to mould a casing and trim it after it hardened to get the end result, a perfect fitting glove. Adding to the servo holder a bent paper clip, some Velcro and an elastic strap makes it all hold together quite nicely. I am extremely happy with the result. Tuning the up and down positions is very easy. You can hear when the paper clip makes contact with the case. Small servo adjustments are required until this noise is reduced or eliminated.

The pen holder ring in this picture is one of the initial unsuccessful ones.

Since I can't attach WALTR's source code and example files to this blog I have added them to OBEX at the Parallax website. You can find the link to it below. Enjoy.

Friday, January 13, 2012

WALTR - Introduction

Project WALTR (Wireless, Apple II, Logo, Turtle, Robot)

From my early computing days I remember wanting a computer controlled robot (either a turtle robot or a robotic arm). Robot control using home computers started becoming popular in the 1980s however not popular enough in my part of the world as the only ones I ever got to see were the ones in magazines. They were very expensive and since we were unable to afford an original Apple II the chances of getting a robot was even more remote. Over the past few years I have been getting back into the Apple II world and my desire to obtain or build a turtle robot has grown.

I considered purchasing an original turtle robot but they are still very expensive due to their collective appeal. If you can find one they are most likely incomplete and/or require restoration. Rebuilding one from scratch using the plans from magazines also sounded like a huge job. With today's cheap robotic toys I wondered if anything existed that could easily be retrofitted and made to work like an old robot. When I came across the Parallax Scribbler 2 (S2) I knew it would be a great fit.

I had other Apple II projects on the go but Peter's Logo presentations at the last KansasFest resparked my interest and I was pleasantly surprised that I was not the only one looking in this direction and wanting to find a solution.

When looking at the S2 robot it looked like lots of fun even without having it hooked up to the Apple II but I think I have learnt more in a shorter amount of time by having a defined goal. The bonus has been having other fun gadgets to play with along the way. To make the S2 into a Logo controlled turtle robot it was going to need a few modifications. The main one being a pen lifter. The horn, lights and touch sensors could be emulated by using the existing S2 objects. Finally, since I am not trying to build an authentic replica, in today's world a turtle robot would not be complete without having a wireless interface.

Serial wireless (Bluetooth) connection for the Parallax Scribbler 2 Robot.

When I first looked into making the S2 wireless I concentrated on finding something that would plug into the S2's RS232 port (like the IPRE Fluke). Basically I wanted to swap the programming cable with a seamless wireless alternative. The Bluetooth RS232 modules looked rather expensive so I looked around and found the less expensive XBee modules and Bluetooth TTL modules. My preference was to get Bluetooth over XBee so that one day I could control the robot using my mobile phone. Bluetooth TTL modules use the RS232 protocol but at the hardware layer they use TTL signals. They cannot be plugged straight into an RS232 port. TTL and RS232 use different voltage levels (TTL: Off = 0V, On = +5V. RS232: Off is between -3V and -25V, On is between +3V and +25V). However they can be plugged into the S2 hacker port. The disadvantage was that the S2 could not be programmed wirelessly but it had several advantages. It was by far the cheaper option, it was hidden away inside the S2 case and it bypassed the RS232 hardware layer so potentially could be run at higher speeds.

I didn't know much about Bluetooth communication before I started this project and the funny thing is that I still don't. That is the beauty of these modules. The setup is miles easier than trying to pair a Bluetooth device with a computer. The default settings are adequate for a serial connection and the only setting that I needed to make was to the working mode. By default the modules come preprogrammed as slaves so I needed to change one of them into a master. This was achieved by connecting the module up to the "USB to TTL converter", setting it into AT Command mode and sending it "AT+ROLE=1" using a terminal program (I used HyperTerminal). That was the PC side done.

The type of Bluetooth TTL modules that I purchased needed to work with five volt signals and the settings needed to be easily changed in case I did wish to learn more about Bluetooth and reprogram them so that they could talk with other Bluetooth devices. The connection of the slave module to the S2's hacker port was straight forward. To test the S2, via the serial cable and wirelessly, I used the demo code titled S2_test.spin. It's a great utility that allows you to test all the objects of the S2 including the motors. Only one line needs to be changed in S2_test.spin to make it work wirelessly ie "sio.start(s2#RX, s2#TX, 0, 19200)" to "sio.Start(s2#P0, s2#P1, 0, 9600)".

I was very impressed with how quickly I had the S2 moving about. The support for the S2 is amazing. A lot of low level functions have already been written for the S2 objects (speaker, motors, sensors, LEDs) so all one has to do is to include these and call the higher level functions. The serial protocol has also been written and there are plenty of good examples detailing how to interface with other objects like servos. I managed to get the S2 up and running in no time and my simple serial control test only takes around twenty lines of code (not counting the included libraries).

2 x 5V Bluetooth module ("Mini Classical Serial Bluetooth Module" from eBay) - WARNING, sleep mode, see next blog entry.
1 x USB to TTL converter ("PC USB to RS232 RS485 UART TTL Signal Converter New" from eBay)

Apple II Control

Once I had the control of the S2 down pat using the PC I moved over to getting it working with the IIGS. I had an adapter (IIGS Serial Mini-DIN 8-pin to RS232 DE-9) already made up from when I was using ADTPro to transfer disk images over to the IIGS. I made the adapter so that I could connect up the IIGS to serial devices that have the DE-9 connection.

The Bluetooth TTL module could not be plugged straight into the RS232 port. An RS232 to TTL converter was sourced to do the job. This converter and the Bluetooth module require an external five volt supply but an RS232 port can not supply power (not without software and hardware modifications) so currently I have it externally connected but I have plans to source the power from the IIGS. Once the hardware was setup all I had to do was use a terminal program (I used ZLink because it was the first one that I found lying around) to send the commands through.

There are a number of remaining sections to get working including the pen lifter and the interface with the Logo language. There are a few implementations of the pen lifter already constructed for the S2 so I have some examples to work with. The first lot of turtle robots for the Apple II used parallel cards for communication however I will be trying to get my robot talking via a serial connection. Finding a serial protocol that has already been implemented in an Apple II Logo program is proving to be a challenge.

1 x RS232 to TTL converter ("RS232 MAX232 COM Serial to TTL Converter Module Board" from eBay)

Wednesday, June 8, 2011

Power Supply - Conversion

Being without a power supply got me searching for alternate power solutions. The original 230V power supplies are quite hard to come by and fixing the existing aging ones is only going to get me so far. Even when I get around to fixing them how much longer are they really going to last? What I was after was a long term solution. I have seen several good examples of converting PC supplies or triple voltage supplies but these require a modification to make them output the -5V voltage. That is not a huge issue but it is more work than I had hoped for. Quad voltage power supplies are also available but they are wider than the IIGS power supply (which is long and thin) making them difficult to fit inside the IIGS. That was until now. While searching around I came across the SDS60. It's a quad voltage power supply but has a form factor that will allow it to fit inside a IIGS power supply case.

When I ordered the SDS60 I was informed that full production of these was not yet under way so I had to wait a few months for the next run. It was a long wait but well worth it. Once I had the unit it took less than an hour to do the conversion and have my IIGS up and running again. It was the easiest soldering job I have done in years. What more could I ask for? Quad voltage power supply that is small enough to fit into a IIGS power supply case, a breeze to install and uses off the shelf parts. Perfect. It even has a wide input voltage range so you could easily transport it between countries.

Other power supply conversions :-

Made by XP Power
1. SDS60UQ02 Quad Voltage Power Supply
2. SDS60Q CONKIT Quad Voltage Power Supply Connection Kit

Australian distributors :-
1. (about AUD$150 delivered)

In my junk box I had a 120V IIGS power supply which I was going to convert into a 230V supply one day. This will work very well as a base. I desoldered the PCB then just added the cable connectors. It was then only a matter of adding the standoffs and plugging in the SDS60.

Next step is to do some load tests and swap the standoffs from adhesive to screw type. This should lower the PCB and move the heat sink from sitting right up against the cable plug.

Update: 1st November 2012.

I was able to convert another Apple IIGS power supply very cheaply thanks to Mike who found a great source of these handy replacement modules.
It only cost me AUS$45 for two modules including postage to Australia.

Jameco Part no. 2081721
Manufacturer EOS POWER USA INC.
Manufacturer no. LFMVLT80-4000

Mike's power supply conversion :-

Other interesting power supply write ups :-

The procedure was pretty much the same as my other power supply conversion.