Subscribe via RSS

Burning 16-bit EPROMs with a Willem Programmer

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


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

Input Voltages

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

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


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

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

Willem Software vs. Programmer Settings

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


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


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


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

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

Using the adapter

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


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


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


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


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


Atari Portfolio

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


DSC00206 DSC00208 DSC00209

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


DSC00214 DSC00215 DSC00217


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

Using the text editor

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


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

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

Initiating serial communications

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


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

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

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

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

copy unnamed.txt com1

DSC00224 DSC00225 DSC00226


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

Transferring actual files

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

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

copy com1

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

coolterm-send-file coolterm-sending DSC00227

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

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


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


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


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


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

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

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

hypertrm-send hypertrm-send-file hypertrm-sending

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

DSC00232 DSC00234 DSC00235

Transferred and executable!

Games and other software

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

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

Memory cards

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

Filed under: Retro No Comments

Quantum Bigfoot 4320AT

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


DSC00151 DSC00156 DSC00157


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


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

Totally random! And amazing to watch!

Filed under: Retro No Comments

Atari Controller Test Rig

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

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

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


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


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


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


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


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

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


DSC00090 DSC00094 DSC00099


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


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

Filed under: Retro No Comments

Farallon EtherMac Mac/PB Adapter

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


DSC00047 DSC00035a DSC00040a


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

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

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

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

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

Filed under: Apple No Comments

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

Zorro II Cards On The Amiga 500

The next build for my Amiga 500 was a Zorro II Card Slot Adapter. This unit uses the expansion slot on the left-hand side of the Amiga (just like the external IDE adapter) and provides a vertical slot to plug your Zorro II card into. It also has a standard floppy power plug and circuitry to choose this supply if provided, otherwise use power from the Amiga itself.


The collation of parts was pretty straight-forward, and I only made one mistake! The relays I'd purchased were much too large for the PCB holes.


DSC00021 DSC00024 DSC00028

So I used a relay I had on hand. It didn't work once soldered and tested... it was rated for a 24-volt input! So I went ahead and re-ordered the correct part.


Next up, I used a spare molex power supply plug to make powering the card a little easier...

DSC00036 DSC00037 DSC00041

Final notes when building... after you've soldered nearly 200 joints, go over them all with a magnifying glass...


It's really easy to miss a soldered join when the plates on the PCB are so shiny... also when the lighting above is LED and the reflections of the melted solder look more 3D than they really are! Fully inspect each joint, otherwise you'll get grey screens, white screens and even half-booting!

The shot above shows one of two pins that I failed to correctly solder, and note that it shows it after I found it and slightly bent the pin to test that it wasn't actually making contact! The actual hardware symptom was that, whilst booting, the drives would be found, Workbench would start booting and then it'd pause at the 'wait timeout' in the StartupII boot script. I assume there's some interrupt or IO signal that's meant to come over that pin... amazing how random things are when signals aren't correct.

DSC00011 DSC00013 DSC00015

Finally, the board was assembled and ready to test!

MegaMicro Technologies: SCRAM 2000

SCRAM 2000 is a SCSI for A2000, A3000, A4000. And now also the Amiga 500! This board features a board-mounted 3.5" SCSI hard drive, an external DB-25 SCSI port and the ability to host a total of 8mb RAM.


The card came without a SCSI drive, so I grabbed a 40mb Seagate SCSI (from Apple!) from my box'o'crap, set the ID to 0 and mounted it to the card. Note that the spacing is very tight for the data cable, so make sure the wires are leading away from the card when you plug them in...


After a lot of toying around, the disk was mounted, formatting and even auto-booting on my KS1.3 Amiga! I used a boot disk instead for the KS1.2 Amiga. Note that the install disk can be used as both. Grab it from here and use ScrapPrep to get your drive in order. Then you just need to copy over the Workbench disks and make sure the boot priority is the highest amongst all drives connected! Check out this post for more details on bootable drives (disregard that it's about IDE drives!)

DSC00129 DSC00133 DSC00134

A fun note on this card... it would've actually come in kit-form to the original purchaser back in the late 80s. When that user assembled it, they put the three status LEDs in backwards. I was wondering, whilst debugging things and trying to work out why my machine wouldn't load, why the LEDs just didn't light whatsoever. I assumed it was because I was using a KS1.2 machine and there was no config, etc.... but it turns out that the LEDs were actually in wrong. I fixed this and also rigged up a LED to use on the activity LED headers... a much quicker way to test things like this!


Next trick was to upgrade the RAM on-board. The board uses ZIPs and this was my first time encountering them. Just think of an IC standing on one side, with all pins out the bottom edge. They're interleaved and you must make sure that they line up correctly before inserting them!


DSC00112 DSC00120 DSC00123


As is my usual rush.... I happened to put the last chip in backwards. With the card inserted, the machine wouldn't respond at all... no power light, nothing! I had only ordered 16 chips, so I was very fortunate that everything 'just-worked' when I swapped it around.


Finally, you'll note that the external SCSI port was nicely corroded on the board I recieved. A quick trip to Jaycar saw the purchase of a replacement part and, after a little destruction, the new port was soldered in place.

DSC00107 DSC00108 DSC00110

After this, I had a perfectly bootable SCSI A500 system with 8mb of Fast RAM!

GVP HC+8 Series II, Revision 2 Zorro II SCSI Card

This card happens to be very similar to the SCRAM above. It also hosts 8MB of RAM and a SCSI controller with an external SCSI port. The main difference here is that drive is mounted the opposite way around and SIMM RAM is used.


This first thing I did was get the RAM situation sorted out. The card came with 2 SIMMs installed and the auction quoted that this was 2MB of RAM. I threw the card in the system and the top line of WorkBench 1.3 indicated just under 3MB as the A500 has 512kb internal and the was also a 512kb expansion card in the trapdoor slot. With this, I tried to do things and kept getting the crash below...


I thought I'd bought a faulty card until I pulled the two SIMMs out and realised that they were only 256kb each! The Amiga was trying to get to the other 1.5mb of RAM and there was physically nothing installed... no wonder it crashed. I quickly populated this with 8 1MB RAM SIMMs and the machine soaked them all up, testing them out perfectly.


This one also had a corroded external SCSI port, so I went ahead and replaced it as well.

DSC00166 DSC00246 DSC00248

Finally, a few shots to show what SysInfo has to say about the card.

DSC00386 DSC00387 DSC00388

Installing an setting up the drive was just as simple as the SCRAM setup. the GVP software works beautifully and you can grab the setup disk here, but but here it is as an ADF.


Just make sure that the HDD is not grounding on the ground-plate of the power regulator!

SupraDrive 2000 WordSync

This card is still on its way from the US of A. As mentioned on the Amiga Hardware Database, this card uses two 8-bit transfer buffers instead of DMA. The card is noticably more simple with regards to chip count and board complexity. It's also half-size, not taking the full length of an A2000 case... so I might even try and shoe-horn it into a nice side-car style box.

I'll update more when it has arrived.

Filed under: C64/Amiga No Comments

Capturing the output of an Amiga

You might have more luck than me, but I've had a little bit of trouble both outputting a clean composite signal from an Amiga and then capturing it using a PC. Not knowing if my first capture device was at fault, I upgraded an A520 RF modulator to support S-Video, but this still didn't work. The video capture device in question was a Japanese Area Powers Entry Model V.2, bought in a hurry during the last trip whilst testing Super Famicoms... Haha... the name is hugely appropriate!


It didn't work back in Japan when testing the Famicoms, and it didn't work now with the Amiga 500 + A520. I went googling and found all sorts of posts indicating driver installation caveats for Windows 10, but none of this worked. I then tested it with my PlayStation 2 and got a pretty crisp picture!... It was then obvious that this unit would not work with the output of the Amiga.

AverMedia H339 Mini

This cute/tiny PCI-Express card is very barebones. You can tell it's OEM and came from a machine of one of the big brands. Very hard to find drivers as well! I ended up pulling apart a Dell Driver from here. Here's the actual setup file you'll need for Windows 7,8,10 64-bit.


DSC00004 DSC00006 DSC00008

Anyway, with this physically installed and the device happily showing in Device Manager, I attempted to use the unit under VLC. Make sure that you choose the correct input (via the advanced button via the device properties) when you're setting up the capture...


vlc-2 vlc-3 vlc-4

And that you have PAL chosen instead of NTSC.... and then...


Ahh! Finally, no more switching monitors and no more photos of a computer monitor! Finally just easy PNG screenshots. Note that you might notice a slight delay/lag in the capture video on your PC with VLC. To fix this, hit show more options in the capture dialog and set the caching to 0ms.
You can also set ":live-caching=0" on VLC command line.

Filed under: C64/Amiga No Comments

Formatting an IDE Drive for use in an Amiga 500

You may have previously seen the IDE Adapters that I'd built for my Amiga 500 over here (internal) and here (external). Whilst they worked very well with FAT32 drives attached, I had no end of trouble trying to work out how to partition, format and mount as a native Amiga disk. For everything below, you'll want to use this bootdisk.

The FastFileSystem

Digging through the blog, I'd remembered that I'd done a bit of this back in the day when mucking around with the Amiga 1200. I had used a CF card internally on the A1200 and installed WB3.9 succesfully on a SmartFileSystem Partition. Unfortunately, we can't use that on the A500, so we'll be basing our partitions on FFS, or FastFileSystem. This comes with Workbench 2.0+, but you'll need the file sitting in your L folder for anything lower.

Connecting a drive

Since we're talking IDE, we'll need an adapter. As per my previous mentions, you can find how to build an internal one here and an external one here. Both work great, but follow the posts there for the caveats and tricks when connecting and powering drives.

DSC00238 DSC00244 DSC04120

Note that this can also apply to SCSI drives. Just disregard the steps to add the driver to the disk and/or HDToolBox in the next section.


We'll use HDToolBox for this. It's on the bootdisk I've provided and it's already configured to use the ide.device driver installed in the devs folder. If you're rolling your own, then you'll need to copy the driver over to your floppy and edit the icon for HDToolBox to specify a SCSI_DEVICE_NAME as such...

DSC00303 DSC00305 DSC00307

This is an important step and you'll need a bit of patience... HDToolBox will sit for around 5 minutes interrogating LUNs with no disks, waiting for a response. If you've only connected one drive as master or slave, then the opposite LUN will pause. Below, I've only connected a master, so I saw the message "Checking ide.device address 0 unit 1..." (IDE slave) for a looooong time... but all came good!

DSC00308 DSC00309 DSC00310

From here, you'll need to change the drive type and read the parameters from the drive. Click Change Drive Type and then choose to add a new drive definition. Hit the Read from drive button on the right and cross your fingers.

DSC00311 DSC00312 DSC00313

The shot below shows where HDToolBox has detected by Disk Smith 32mb CF Card. Unfortunately it then failed when trying to write the actual partition table to the disk.

DSC00314 DSC00315 DSC00316

Partition sizing is important, so make sure you pay careful attention to all parameters. The Amiga 500 format application will error out if you try to make a partition too large. Unless you have an upgraded system with more RAM than the standard, don't try and partition a drive that is too big! For example, my 128mb (yes, megabyte!) CF card with one partition formats fine, but if you try a 2gig or 4gig card, you'll have trouble with the auto-detected settings. Here's an idea of the parameters that I've tried...


Size 4096mb 2048mb 128mb 32mb
brand SanDisk WINTEC Dick Smith
ext.power +5v No
cyl 3970 3970 12000 1002 496
heads 16 4 8 8 4
blocks per track 63 256 32 32 32
blocks per cyl 1008 1008 256 256 128
Part.Size (~mb) 1990 950 650 487 196 97 976 487 196 97 749 128 ??
cyl.start 2 2 2 2 2 2 2 2 2 2 2 2 2
cyl.end 3968 1985 1323 992 400 200 1985 992 400 200 6000 1001 495

I read in one of the IDE adapter's instructions that you need to have a low cylinder count, so that's why I started with higher surfaces/heads... but instead it seems that a higher cylinder count works better? There's also talk of making sure that your partition sizes match boundaries of the chips inside your CF cards... but I'm not going to pull one open. All I can recommend is that you detect the settings via HDToolBox and then manipulate them to have a higher cylinder count so that surfaces/heads and blocks are lower.

Anyway, where was I? Creating partitions! After you've adjusted the drive parameters, you can click Partition Drive and set up the partitions. It defaults to two, halving the drive. Note the names and sizes, as you'll need them for the mountlist in the future. I changed the layout by deleting the second partition and stretching the first to the end.

DSC00320 DSC00321 DSC00322

Again, write down those start and end cylinder offsets! You can now hit ok-ok-ok-finish and save all settings. The Amiga will probably reboot.


So, remember how I told you to remember those parameters above? You wrote them all down, didn't you? If you didn't, please open up HDToolBox again and record the numbers from the Drive Type screen and the Advanced area in the Partitioning screen. Once you've noted it all down, you're ready to edit On the bootdisk provided, this is located in the devs folder. If you've booted this disk, then just open Shell and type ed devs/ and press enter.


Once you're in here, you just need to manipulate the fields to match your partition. Starting on the very first line, make sure the name is correct. Change DH0 to whatever you've called yours. Note, there's a bunch of example partition mappings in this file. If you want to use one of the below versions, you can press CTRL-B to delete lines from the text file. For example, you could start at the very top row, hit CTRL-B 17+ times and wipe the top example. Just for fun, here's a reproduction with comments of what you need to change.

FileSystem   = L:FastFileSystem    ; If you want FAT32, then scroll down
Device = ide.device

Unit = 0                   ; 0 = MASTER, 1 = SLAVE

Flags = 0

Surfaces = 4               ; From HDToolBox (HEADS)
BlocksPerTrack = 63        ; From HDToolBox (Blocks Per Track)

Reserved = 2
Interleave = 0

                           ; For the next two values, you'll need
                           ;    to have opened the advanced area when
                           ;    creating partitions in HDToolBox
LowCyl = 2                 ; Start Cyl from Advanced Options
HighCyl = 256              ; End Cyl from Advanced Options
Buffers = 30
GlobVec = -1
BufMemType = 1
DosType = 0x444F5301   ; FFS Dos Type, leave as-is.
Mount = 1

Apologies that the photo above doesn't match the final file that is on the bootdisk! I made the final file match the rest of the examples here as much as possible. Either way, just make sure you get the details in correctly and that there's no other duplicate partition name/definition in

Mounting and Formatting

Before you can do anything with the drive, you'll need to make it available to the system. The low-level tools, as per HDToolBox above, can use the drivers to find and interrogate drives, but they don't make them available to the system directly. To do this, we'll need to use the mount command, pointing it to the mountlist we've created above. Type in the following from a Shell.

mount DH0: from devs/

Make sure that you've replaced DH0 with your partition name and leave the colon at the end. The from operator tells mount not to use the standard mountlist and instead use the file that we specify afterwards. Hit enter and you should be put back to the command prompt without any messages or warnings. The only thing that might happen is that you get a drive visible on the workbench... if this happens, then somehow the partition you've mapped is already formatted and ready-to-go. If this is a surprise, then don't try and open it... anything could happen.

From here we'll want to format the drive. The format command is used here with the DRIVE and NAME parameters. We then specify the disk format at the end.

format DRIVE dh0: NAME CFCARD0 ffs

Above, you can see the partition name is DH0:. As per usual, replace this with your partition name, leaving the colon at the end. After NAME you can type a friendly name for your partition. This is the name that'll show under the icon on your workbench. It's also the name that you can use in Shell.


Do you like the name I gave it? You'll see it's legit as it's in the screenshots below when copying files. I'd gotten pretty desperate after a miriad of partition size permutations, trying to get a format session not to fail. Finally, as per above, one worked... but not before I started typing stupid names for the formatted partition name!

Note that you can add the term quick to the end if you just want to quick format, but I recommend to do a full format the first time!


With the drive totally prepared, it should be visible on the workbench with a single Trashcan inside of it. From here, we'll want to transfer the OS onto it, so go ahead and purchase the Floppy & Hard Disk Image Pack from Amiga Forever. In the kit you'll have two ADF images: one for Workbench 1.3 and another is the Extras 1.3 disk. You'll need to insert these one at a time and copy the entire contents of each onto your new partition.

A quick note on copying disks on the A500: Regardless if you're using real floppies or a Gotek, floppy-switcheroo is the name of the game when trying to get Workbench copied over onto the IDE HDD. Firstly, understand that the copy command is an executable that lives in the c folder of your bootdisk. You can easily copy files around when the bootdisk is inserted. Issues start to arise when you switch disks and try to call copy or any other executables that 'exist' on the bootdisk. Workbench will ask you to insert the bootdisk first to find the executable and then actually run the requested command with its parameters.

This is all fine and well, until you try the following command:

copy DF0: DH0: ALL

It looks simple enough... I've swapped the Workbench 1.3 disk in and asked it to copy. Of course, when it started to execute, it asked me for the disk which contains the actual copy executable:


Yeah, I know, it says A590Setup... a good hint as to what disk I created this IDE Boot Disk off. Anyway, the point is that that was my boot disk and that's where copy lived. Once you switch the disk in, it'll start to execute copy... and copy from DF0 to DH0. Sounds good? It wasn't! As I wanted Workbench 1.3 to copy over, not my boot disk! Because I had DF0: in the copy command, and not workbench1.3:, it's just copying from the drive after swapping the bootdisk in and hasn't checked the name!

To solve this, we have two options. If you're using my bootdisk, then I've already solved it for you with the first option: make the copy program resident. In startup-sequence, I've called the resident command with copy as an argument, making Workbench copy the copy executable to system RAM (not the RAM: disk!) and persist it there during floppy disk changes. This means that it's always available whenever you need to call it.

The second option is shown below. Copy copy to RAM: (the actual RAM disk) and call it from there via RAM:copy.


... copy ... copy ... copy ...


Note that the Workbench 1.3 floppy has a space in its name and that the copy command can't handle this without special formatting. I guessed and tried to reference it as workbench1.3: without the space and somehow this worked fine? I then tried the same method with the Extras 1.3 disk, but that failed entirely. Due to not knowing how to reference it, I used DF0: instead and hence wound up with the situation above where I copied over the wrong disk. After a quick bit of googlin' now, it seems that you simply have to double-quote things:

copy "extras 1.3:" dh0: all

I'll try that at a later date.

Bootable disk

The bootdisk mentioned throughout this article can be converted to an actual bootdisk. I suppose I should've called it a setup disk at first, but it is actually still a standalone bootdisk. Or something. Anyway, it'll now be a bootstrapdisk, mapping the relevant OS drives and folders to the HDD and then kicking WB off from there. The startup-sequence files to do this are all ready to go. Open a shell and switch to the s folder. From there, ed startup-sequence.hd.

; Startup sequence for Hard Disk users...checks for hard disk, then
; transfers control if it is present. (The script assumes DH0:)
; TO USE: copy your normal startup-sequence files (Startup-Sequence,
; and StartupII to the S: directory of your hard disk.
; Then rename your normal Startup-Sequence file
; as Startup-Sequence.f in the S: directory of the floppy, just in case.
; Now replace the Startup-Sequence file on the floppy with this file.
Setpatch >NIL:

;The line below needs to be edited to match your partition name
;You also then need to make sure that has the correct
; parameters for your partition!
mount IDH0: from devs/
assign >NIL: IDH0: exists

; hard disk is present
assign sys: IDH0:
assign c: SYS:c
assign L: SYS:l
assign FONTS: SYS:fonts
assign S: SYS:s
assign DEVS: SYS:devs
assign LIBS: SYS:libs
makedir ram:tr
assign t: ram:tr
execute s:Startup-Sequence
execute df0:s/Startup-Sequence.f

Simply make sure that IDH0 in all three places is changed to whatever your HDD partition name is and then rename the files:

rename startup-sequence startup-sequence.f
rename startup-sequence.hd startup-sequence

From here... reboot!

Filed under: C64/Amiga No Comments