A tuneup for the Amiga 500

Fully operational and playing Questron II – but it took a lot of work to get there.

When I bid for that copy of Questron II for the Commodore Amiga on eBay a few weeks ago, I knew I was getting myself into trouble. You see, the sad fact is that I haven’t had a fully functional Amiga since before 2006.

My Amiga 500P was my primary computer through my undergrad college years. At first, I used it – along with my trusty SupraModem 2400 – to discover the BBS scene. Towards the end, I rigged up some kind of IP-over-serial hack to access the Net from my dorm room. I added a GVP HD-8+ sidecar with a massive 50 megabyte hard drive (SCSI, of course) and 2 megs of RAM. At considerable expense and with the help of a good friend I finally got an AmigaOS 2.04 update ROM kit for it. It was a trustworthy machine that remained capable long past Commodore’s corporate demise and its own technological obsolescence.

Eventually, though, I had to move on, and by 1998 or so I was a dedicated Linux snob. I never got rid of the A500 but, as the Rush song goes, “Time if nothing else will do its worst.” When I finally hooked it up again, a few years ago, all was not well. It booted up, with a few transient read errors on the disk, but the keyboard didn’t respond.

With a PC, a broken keyboard is a trivial problem – you just replace it. The Amiga 500 is from that style of 80s home computers where the keyboard was integral with the case, and connected directly to the motherboard. And for all I knew, the motherboard itself might have been the problem.

I wasn’t as hardware-savvy then as I am now; or at least I was more chicken about poking around in the guts of a computer. Instead, I decided to try to recover the information from the hard drive and a few important floppy disks – I figured I could use them with the WinUAE Amiga emulator.

That turned into a major project. I used the Amiga Explorer software that came with Cloanto’s AmigaForever to connect the A500 to a PC using a pair of serial cables, a null modem adapter, and a USB-to-serial port adapter. There’s a piece of the Amiga Explorer software that you’re supposed to install on the Amiga; and in theory you can do that by redirecting the serial port to a file by entering a single command in the Amiga shell. The theory would’ve worked really well if it hadn’t been for the broken keyboard.

Eventually, I figured out a workaround: using a text editor and a folder of old email messages, I was able to copy and paste a script file together, one character at a time, using only the mouse. After that we were in business, and I was able to copy the entire hard drive image, the system ROM image, and every Amiga floppy disk I had sitting around that wasn’t copy-protected. Since then, I’ve had the entire system available virtually on my desktop.

Replacement keyboard – I’m glad that I didn’t have to live with that funky UK layout.

Fast forward to 2013, when I decided it was time to try again to fix the hardware. It took me a while to find a replacement keyboard; they only show up on eBay occasionally, and even then they’re usually not American keyboards. Eventually, I settled for a cheap keyboard shipped from the UK; I figured if it worked I could swap individual keys from the broken board to recreate a US keyboard layout.

In the meantime, I did some other preparations. We’re talking about a computer that’s more than two decades old, so caution is good. Before I fired the Amiga up, I tested the power supply with a voltmeter. It’s supposed to have +5V, +12V, and -12V signals. I measured +5.57V, +12.65V, and -11.17V (under no load), which I expected would be close enough.

I did a quick power-on test to see if the system was still working like I remembered. While it came up immediately, I noticed that it was short half a meg of RAM. I had some hunches about that, but first things first.

That RF shielding’s seen better days, but at least it’s not soldered in place…

Getting the computer open was easier than it used to be – only three of the original screws are still in place. I stripped a couple of them back in the days before I had a decent set of Torx screwdrivers, and left them out for good.

Before I swapped out the keyboard, there was something I wanted to try. The A500 uses a pair of 8520 CIAs (Complex Interface Adapters), which are pretty much the same as the 6526 CIAs in the Commodore 64 and serve most of the same functions – they interface with the serial and parallel ports, joystick ports, and the keyboard. The 8520s have a reputation for being failure-prone, so I tried swapping them. If one was good and the other bad, I’d be trading my keyboard failure for some other problem. At least I’d know what was going on.

Swapping the CIAs had no effect, so I resigned myself to using the (fairly grungy and yellowed) UK keyboard. It wasn’t pretty, but it did work! I was still looking at a lot of cleaning and replacement of keycaps, but there was one last thing to try. The A500 keyboard has a small circuit board attached to it that holds the power and disk LEDs, some 7400-series logic, and a Commodore Semiconductor Group 6570-036, which I took to be some kind of bespoke keyboard controller IC.

The keyboard’s controller circuit board turned out to be the real culprit.

I didn’t see anything wrong with the circuit board on the original US keyboard, but I decided to swap the controller from the UK keyboard onto the US keyboard to see what would happen. And it worked! Apparently the US keyboard was mechanically sound, and the problems were in the controller electronics. Personally, I’m just happy to have as much of the original machine in working condition as possible – for sentimental reasons, if nothing else.

By the way, according to this web site, the 6570 is actually a microcontroller with a 6502 CPU core. I guess the Amiga and C64 have more in common than I thought!

With the keyboard working again, I turned my attention to the missing memory. The A500 has a “trapdoor” expansion in the bottom, which usually contains a 512 KB RAM expansion and a battery-backed clock. I’ve heard plenty of horror stories about those old batteries leaking and corroding the traces on the expansion card. I didn’t know how bad it was or if it would be salvageable. Before I could find out, though, I had to deal with the metal RF shielding which completely encased the expansion card and was actually soldered shut!

The A501 RAM expansion and real-time clock. They sure didn’t want anyone poking around inside this thing!

Let me tell you, dealing with that was a pain! I spent more than half an hour with a soldering iron and a spool of desoldering braid, trying to clear enough solder away to get any of the three tabs loose. I was just about to give up and open it up with a pair of aviation snips when I finally got one side loose, and was able to bend the top half of the shielding out of the way.

Ironically, after all that, there was very little sign of any damage. Even more ironically, when I put it back together and tried it again, it worked (and yes, I did try reseating the board before spending all that time opening it up).

Once I got inside, things didn’t look to bad – but note the slight discoloration near the battery.

So now I once again have a fully operational Amiga, though it’s not perfect. There’s a buzzing noise coming from the old Commodore 1084s monitor which might indicate a bad transformer or a loose solder weld or something, and I’m not about to go poking around in the back of a CRT. The SCSI hard drive is also making a noise like a jet engine, which is a little worrying, and I don’t know how much longer it might last. It may be time to look at what kind of replacement technology is available for it.

On the upside, I am happy to report that the Questron II game disk works just fine, and the game even has some graphical upgrades over the C64 version. I may be a little rusty with old-school CRPGs, though, because my character got attacked and killed by wandering monsters when I was less than 20 steps away from the first town!

C64 User Port Input

In my first post on the C64 User Port, I only did output – blinking LEDs according to a program.  You can do input too, which will let the C64 talk to other machines, or sense the world around it.

There’s a catch, of course.  The User Port’s pins are binary – on and off – but the real world is analog.  To bridge that gap, you need an Analog to Digital Converter (ADC).  The ADC I’m using in this post is a microchip from, appropriately enough, Microchip Technologies – the MCP3008.  You can see it straddling the center lane of the breadboard in the picture below.

Breadboard with the MCP3008 ADC. The potentiometer is connected to one of the analog input pins on the right side of the chip. Power, ground, and four data lines connect to the left side of the chip. The yellow wires at the top are unconnected.

Now, to be entirely honest, the MCP3008 was not my first choice for interfacing with a C64.  However, I forgot to order the component I wanted in the rush to get ready for Gen Con, and this is what I actually had on hand.  I got the 3008 from AdaFruit a few weeks ago, along with a few other toys that’ll be showing up in future entries.

For one thing, the 3008 outputs a 10-bit value – so it maps the input voltage to a value between 0 and 1023.  That’s a slightly weird match for an 8-bit micro.  There’s also the interface.  I had wanted to use a chip with an 8-bit parallel interface because using it would be trivial.  Instead, the MCP3008 uses an interface called SPI (Serial Peripheral Interface) bus.

SPI is a serial interface that uses four wires to connect a master (in this case, the C64) to a slave (the MCP3008).  It’s not hugely complicated, but it’s not something I’ve ever used before, either.  Luckily, AdaFruit included some tutorials to get me started.  Of course, the tutorials were for a Raspberry Pi instead of a C64, and the code was in Python, instead of 6502 assembly.  So there was a certain amount of adaptation to be done.

The analog input in my sample circuit is a potentiometer used as a voltage divider.  It’s hooked up to one of the chip’s analog inputs (it actually has 8 separate input channels, which is cool) and provides 0 to 5 volts.

In addition to the +5v and ground connections from the User Port, I use four of the parallel port pins to implement the SPI bus.  One line is the “chip select”, which enables the ADC.  Another is a clock line, which is used to tell the ADC when to read or write data.  Finally, there are individual input and output lines.  The SPI bus is full-duplex – both sides can talk simultaneously – though we don’t need that feature in this example.

On the software side, I’m essentially bit-banging – changing the values of individual bits, rather than using a library or any kind of dedicated interface.  To send a bit, I set the output line to 0 or 1, and then briefly toggle the clock line.  To read, I toggle the clock and then read the input line.

To sample the analog input, the C64 sends a 5-bit message to the 3008: two 1’s, followed by a 3-bit number indicating which of the 8 inputs I want to sample.  Shortly after, it starts reading: a 0 bit, followed by 10 bits of data.  That gets inserted, one bit at a time, into a 16-bit number with a value between 0 and 1022.

Did I say 1022?  Ideally, the max value would be 1023.  I guess my potentiometer is eating a little voltage even when it’s turned all the way over.  That’s another one of those “real world” things you have to watch out for.

Another real world thing still has me puzzled:  according to the datasheet for the 3008, and also the python code at Adafruit, there should be one more clock transition between when I finish writing to the 3008 and start reading.  But if I do that, all my data is one bit off from where it should be, and my values go from 0 to 2045 (not even 2047! sigh…).  Either there’s a subtle timing issue involved, or I don’t understand the SPI bus as well as I think I do.

Probably the latter.

One last trick before we finish.  How do you print a 16-bit number to the screen as its decimal value from assembly?  You cheat.  You copy the high byte of the value to the accumulator, copy the low byte to the X register, and then jsr to $BDCD.  That’s actually the location of a routine in the C64’s BASIC ROM that’ll do all the work for you!  That’s much simpler than doing it yourself!

A C64 graphics hack, part 2

Last week I said I was going to work on a smooth scrolling routine for the C64.  But I’m as prone to creeping featurism as any other hacker, and at the last minute I decided to spruce it up a bit.  Oh, let’s make it scroll at different speeds! I told myself, and Why not have it scroll in two different directions!  Luckily, adding these features was the easy part.  Getting the scroller to work at all was the tricky bit, but the video below shows what I accomplished.

The VIC chip has hardware support for smoothly scrolling the screen.  Now, what that actually means is that there are three bits on one of the registers that you can set to scroll the entire screen as much as 7 pixels to the right.  Hey, at least it’s a start.

So what happens when you want to scroll farther than that?  Last time, I described how the screen is arranged as a 40×25 grid of characters.  If you want to scroll 8 pixels to the right, you set the hardware scroll to 0, and then you go through each row of the grid and rotate each character one spot to the right (In other words, a row like “ABCDE” becomes “EABCD”).  That’s 1000 copy operations, and another 1000 if you want it to work in color.

If you want to scroll continuously, then you just use the hardware scroll register to move from 0 to 7 pixels, and when it rolls over you move the contents of screen memory and start again.  By the way, there’ll be a flickering column on the left side of the screen where the contents has been scrolled out of the way, but the VIC-II has you covered:  Another bit in the scroll register will put you into 38-column mode.  The video chip pushes the borders in by eight pixels on either side so that you can draw there without anyone noticing.

Now, actually implementing this is pretty tricky.  It turns out that moving 1000 or 2000 characters on a C64 is a lot of work.  My first, fairly naive attempt produced a flickering mess – it took me longer to rotate character memory around than it did for the video chip to display a frame.  Aha! you’re thinking if you know something about graphics.  He needs to use double-buffering!  Well, that’s part of the solution, but remember that special memory attached to the VIC-II that’s used to store the color of each character?  That color memory can’t be moved.  You can’t double-buffer it.  You’ve got to update that memory while the VIC-II is reading it and spitting out a video signal.  You are – to borrow a phrase from Atari 2600 hackers – racing the beam.

The VIC-II outputs its video signal row-by-row, from the upper-left to the lower-right.  You’ve got to make sure your changes are in place when the VIC gets to that part of the display.  To get ready for that, I had to do two things.  First, I optimized my code for rotating the characters around by using loop unrolling.  That was surprisingly effective.  The second thing was that I put all my drawing code in an interrupt handler (which is a topic worthy of its own post, some day), and I hooked up my interrupt so that it was triggered in sync with the VIC chip.

Even then, it takes me four frames to get ready for that one magic frame where I have to make all the characters appear one spot over from where they were.  I start when the scroll register is at 5 (when I’m scrolling to the right).  I copy the first 12 rows of character data into a second screen buffer, rotating each row by one character.  During the next frame, I copy the rest of the character memory.

The tricky part happens when I copy the color memory.  My interrupt triggers when the VIC has output the last row of the screen, so I have some free time while the chip draws the bottom border, and then the top border of the next frame.  The scroll register is updated to 7 – as far to the right as it can go.  I wait a little longer – until the VIC has drawn the first couple of rows of characters.  Then I start rotating the characters in the top rows of color memory, while the chip is still drawing the bottom rows.

Then, we finally wrap the hardware scroll counter back to zero.  While the VIC is drawing the borders, we tell it to start reading character data from the other character buffer, where the rotated data has been waiting for it.  As the VIC starts drawing this frame, with the new character data and the freshly-rotated color memory, our code still has work to do – it needs to rotate the bottom rows of color memory before the VIC needs to look at them!

Whew!  That’s a lot of work spread out over four frames.  Of course, it could be compacted farther.  I’m sure I could do all that in three frames; probably in two.  There are techniques like speed code that are considerably faster than the copy/rotate routines I’m using.  But doing it this way, I still have a fair amount of time left each frame that could be used for program logic, or sound effects, or whatever.  This graphics hack is a long way from being part of a game, but it is a step in that direction.

All in all, I adore the intricacy of what’s going on here, and I enjoyed puzzling out how the timing and all the pieces fit together.  I deliberately didn’t look at any existing solutions, so this one is all me – and, yeah, it’s probably terribly suboptimal.  But it was fun, and that’s the goal.  If you do want to see the code in all its gory detail (the labels, at least, are a complete mess), the source code and a .d64 disk image are here.

Update: The source code for this program is now available as part of my c64-projects github repository. There is also a live version of this program using in-browser C64 emulation at archive.org.

A C64 graphics hack, part 1

I have quite a bit of computer graphics experience, but most of it is in 3D using APIs like OpenGL. Programming graphics on the Commodore 64 is a completely different experience. The only API is the specifications of the graphics hardware, and timing is of the utmost importance. There are a few techniques I’d like to try out, but you can’t jump into something like this without doing your homework.

The graphics hardware on the C64 is really one chip – the MOS 6567, known as the VIC-II. Designing color video hardware in the early eighties was a tough job because of the timing and bandwidth constraints, and the VIC-II followed the creation of the VIC (of Commodore Vic 20 fame) and several failed graphics projects.

Those constraints also explain why the VIC-II’s graphics formats are so unusual to a modern eye. These days, we’re almost always using bitmapped displays – the screen is described as an array of pixels, and each pixel is defined by 2-4 bytes of color information. While you can do a bitmapped display on the C64 – albeit with an unusual memory layout – there are usually better options.

The graphics modes that are mostly used in C64 programs and games are character-based. The C64 can display 40 rows and 25 columns of text. Rather than storing a bitmap of the screen itself, the C64 stores an array detailing what character to display at each location. Using this technique, you can describe the entire screen using only 1000 bytes of data. A bitmapped display would take at least 8 times that much.

This may not seem immediately useful – how can you make an action game out of a screen full of text? Well, the VIC-II was kind of designed around answering that question, and it has several features that make it all possible:

• Hardware support for smooth scrolling in any direction.
• User-defined character sets, so that you can replace the alphabet with graphical tiles.
• Multi-color modes that allow each tile to contain up to 4 colors.
• Sprites, which are can appear on top of the character-mode graphics and move independently.

Of course, game developers and demo programmers found ways to make the C64 display even more complex graphics, but that’s another story for another day.

Let me close by mentioning one last feature of the VIC-II. While it only takes 1000 characters to describe the character data on a screen, there’s also the question of color. In the simplest case, the C64 has one background color for the entire screen, and an individual foreground color for each character. Those foreground colors – 1000 numbers, each 4 bits in size – are stored in a separate color memory attached to the VIC-II, which will require some special handling later on.

In part 2, I’m going to start on a smooth scrolling routine for the C64, which will highlight why these character-based graphics modes are necessary – and why programming C64 games can be so challenging.

16-bit math in an 8-bit world

A couple days ago, I said the 6502 can’t multiply. I also said it can’t deal with numbers larger than eight bits wide. So here’s a trivial example where I get it to do both. It even almost fits on one screen.

The code above – the center columns are the actual assembly – is a multiplication algorithm for the 6502.  It takes a 16-bit multiplicand times a 16-bit multiplier, giving me a 32-bit result.

(Actually, the multiplicand is 32 bits wide for implementation reasons, so you could multiply a 32-bit number by a 16-bit number.  But then you’d have to worry about overflowing the 32-bit result.)

I don’t intend to make this a tutorial, but let me comment on what’s going on here.  The two numbers we’re multiplying, and the result, are just going to exist in the computer’s memory.  The multiplier is at $c104 and $c105, the multiplicand is at $c100 through $c103, and the result will go in $c106 through $c109.  That’s all hexadecimal, of course, and the numbers are little-endian, if you know what that means.

Basically, we have a loop that examines each bit of the 16-bit multiplier.  If that bit is 1, we add the multiplicand to the result.  Of course, we have to add each byte of the 32-bit multiplicand and result separately – that’s what the whole middle section of the screen is doing.

Also, each time through the loop, we shift the multiplicand one bit to the left – that’s the ASL and ROL stuff at the bottom of the screen.  A left shift is the same as multiplying by 2, so each time through we’re adding larger numbers to the result.

(The part of the code that got cut off the bottom of my screenshot, by the way, is just where we decrement our loop variable and then branch back up to the top of the algorithm at $c002.)

Really, this works the same way that people multiply large numbers by hand – it’s just using binary math instead of normal base-10 numbers.  You look at each digit of the multiplier separately, generating a bunch of partial results, each with another zero at the end, that all add together for a final result.

Of course, this extends to arbitrarily large numbers.  You could modify it to handle 64-bit, or even 256-bit integers, just by using this same pattern of instructions.

It’s astonishing just how much work is going on here!  The loop executes 16 times.  If the bit of the multiplier we’re looking at is a 1, we have to do the add which takes up 13 instructions – and then we still have to bit-shift the multiplicand.  Think about this if you’re writing a game and have to refresh the screen 60 times a second: It wouldn’t take much more than a dozen of these multiplications to use up all the time you have for doing your graphics, sound, and game logic.

And that’s the other really fun part of a project like this – seeing what you can do with limited resources.  In my day job, a quad-core processor with 6 GB of RAM is limited resources.  This is… a little tighter.  I’m going to be working on some graphic hacks next, and I think then we’ll see just how tight these things can get.

The thing that thrills me, though, isn’t the complexity of the algorithm – it’s pretty straightforward once you’re thinking in binary.  The thing I love about it is the visceral satisfaction that what I’m coding is exactly what the processor ends up doing.  It’s kind of like watching a record on a turntable.  There’s a feeling of the mechanical nature of what’s going on, down where the software is changing things in the real world, that can get lost in the everyday jumble of JIT compilers, high-level languages, and virtualization.  Down at the bottom, it’s all electrons moving across silicon.  Think about that the next time Windows crashes on you.

Oh, and it would be terribly rude of me not to name my sources.  My main reference for 6502 assembly is Jim Butterfield’s classic Machine Language for the Commodore 64, 128, and other Commodore Computers – It’s an easy read but a little elementary, and he actually shies away from describing a general multiplication algorithm.  For that, I went to Derek Bush and Peter Holmes’s Commodore 64 Assembly Language Programming.