Silent Q

Azog's little slice of the world. Whee.

Atari Punk Console

Posted By on February 11, 2013

I haven’t done any “real” project stuff lately, just messing around with vintage systems. So I got the urge, and decided to do something simple.

Been wanting to build an Atari Punk Console for a while, so I sat down and breadboarded one up, using a pair of 555’s rather than a 556 (because I had 555’s and did not have a 556). I wanted to make it a bit more permanent but didn’t have any really good perfboard. I could have ordered some, but by the time you add shipping, as well as associated parts, it was more cost effective to just order one of Jameco’s kits.


They’re fun and simple to build. If you’re not familiar with an APC, it’s just basically a noise maker using one of the oldest commercially available ICs, the 555. They’re hackable: you can add things like CV in, line out, etc, which is/was my plan.

But one day, I saw this thing…


It’s a “Myosone 401 EMG Monitor” by Edmund Scientific. I have no idea what it is, but the retroness of it just screamed at me. Look at it: dials, buttons, analog meter. For $10, why the heck not?

I took it apart, and it looked like a perfect fit for the Jameco APC. This is what the original thing looks like inside. The PCB is single-sided with those very 70s hand-drawn traces (which I didn’t get a picture of, but you know what I mean, right?). I dunno what the ICs are, timers or op-amps, but who cares…


It was short work to fit the Jameco APC inside.


The meter is currently not attached to anything. Not sure where to attach it. I do want it to do something, even just move up and down as you twiddle a dial. I’ll mess with that eventually.


Since it’s the thing to do, I do want to build a Baby-8 or Baby-10 sequencer. I should be able to build it inside this enclosure. But even if not, it still looks cool. At least I think so.

Add a fan to a 1541C

Posted By on February 10, 2013

Nothing stupendous. Just common sense. Since I added a fan to my C64, I figured why not add one to my 1541? Not much room inside the thing, so I had to mount it externally, but you work with what you have…


It’s just a repurposed fan, probably from an old CPU cooler. 12vdc, dunno what the amp rating is. I tapped off C7, the large filter cap that goes in the same orientation as the ICs. It measured 10vdc across. I looked at C8, the other large filter cap perpendicular to it, but that measured close to 20vdc.

The case of the 1541 is a good candidate for Retr0-Brite, think?

Historical games

Posted By on December 31, 2012


So what you’re looking at here are two Atari 2600 games, Pac-Man and E.T. By themselves, probably rather nondescript games, but if you’re familiar with video game history, these two games are often cited as the most vivid reasons for the great video game crash in the early 80s.

While the statement may have a small bit of truth to it, I figure calling these two games the primary reasons for the collapse is a gross over-simplification. Like many issues that can crash an entire industry, there were many factors at hand, these two games being only part of it. If you’re interested in the reasons behind the collapse, and the role that the E.T. game played, see the Wikipedia article. Disclaimer, I generally dislike Wikipedia, but for this purpose, it meets the needs.

But the lore behind the E.T. game is much more entertaining than citing sales figures, market over-saturation, etc.

Some people may not be familiar with this era of video game history. Those of us who lived thru it may have experienced the fallout without really knowing the reason (how many teenagers can concisely summarize an industrial crash?), but I say “lore”, because I personally haven’t been able to verify the story behind the E.T. game.

So just what is the story of these carts? In brief, when the video game industry crashed in 1983, Atari had millions of these E.T. carts to dispose of, and they dumped them into a landfill in New Mexico. I’ve not read any accounts of any excavating such landfills, but that might be due to the landfills being private property, or just being in an undisclosed location, or I’m just too lazy to find such excavation accounts.

The Pac-Man game might have suffered a similar fate, but it’s always the E.T. game cited. The Pac-Man game lent weight to the collapse due to the extremely poor quality of the game.

Which brings up the point, why even bother buying these games, if they’re just a footnote in history? Apparently The Angry Video Game Nerd is coming out with a movie in 2013 which focuses around the story of this game.

I didn’t buy the games like those people who took advantage of Steve Jobs death to post common-as-dirt Apple IIe’s on eBay for $10,000 (yes, they were), but rather to _avoid_ such a rush, if there is a rush. They’re currently common games, you can pick them up on eBay for a few dollars.

Since I don’t have an Atari 2600 (or emulator), for your enjoyment, here is a gameplay session of the Atari 2600 version of Pac-Man:

Compare it to the original:

Hideous, isn’t it? Both of those are probably emulators, but the comparison is nontheless still valid.

It would take ~5 years before the industry was able to recover, and Atari was no longer a player, but the industry now belonged to Nintendo.

Repairing an SX-64

Posted By on December 16, 2012

I would not consider an SX-64 to be exactly “rare”, but it would be more of the “uncommon” type of system. And apparently “desirable”. When listed on eBay, they usually start at $100 or more. I don’t really know how many sell at that price. So when I had opportunity to acquire an SX-6 in “parts condition” for less than the price of a couple of pizzas, it was one of those things I couldn’t pass up. It was in cosmetically nice condition and more importantly, had the keyboard.

Visual inspection revealed no major flaws, so I took the plunge and powered it on. I was expecting the PLA to be blown, at the very least. But to my surprise, it booted right into BASIC. It had some bad memory, reporting 30929 bytes instead of the standard 38911.


So my first goal was to take out the board with the memory and see what the deal is. Unfortunately, unlike the SX-64’s less-portable brother, the SX-64 is not very “user accessible”. Things are jammed at tight as possible, with various daughterboards connecting to one another thru a mess of assorted wiring harnesses.


The board at the far rear is the main CPU board. In front of it, a bit to the left, you can see the expansion cart slot, with a homemade diagnostics ROM. To the left of that is the “expansion” board, which carries the 6526’s, and plugs into the main board via a 40-pin header. Behind THAT, is the 1541 drive control.

When I remove cables, even if their orientation is obvious, I always mark them which you can see on the two white cables at the top of the main board. Then it was a matter of extracting this thing.

I didn’t really get a shot of the whole main board while it was out, but this is where the RAM chips are.


I tried to remove the original RAM in a non-destructive manner, with the idea to test them via the swap-and-replace method on another 64, but that plan didn’t work out. I was more concerned about damaging the PCB, so in the end, I eventually snipped the RAM chips out, which destroyed them. That’s a shame, because some of them were good.

I did find replacement RAM (4164s), and decided to socket them as well. I figure once something needs replacing, there’s a possibility that it may need replacing in the future, and why not? So I picked up a stack of really cheap “machined” sockets.


Well, it goes without saying, but I’ll still say it. When you buy cheap Chinese parts, expect nothing but cheap Chinese parts. It’s hard to tell from the photo, but the pins are flimsy to the point that practically breathing on them will bend them. And the insertion holes are dumb.

Normally I use “real” machined sockets:


They’re usually much more expensive, but for small projects like this, for a do-it-yourself, etc, the cost is so much worth it. I should have just backed out and ordered some good sockets, but I was not in the mood to order $10 worth of sockets with a $10 shipping fee.

Once that was said and done, when I powered it on, I received the expected 38911 bytes free, but the 1541 was not working; the LED and motor stayed on. I did not remember if it was doing this prior to my fiddling with it, as once I saw the memory incorrect, I just jumped in. So I don’t know if I blew the 1541 controller, or if it wasn’t working in the first place.

Ah well, this symptom is apparently one of the most common failures in the 1541, and the first thing you do is replace the 6522s, which fixed the problem.

As far as I can tell, everything else is working, but I’ll have to find some way to put it to more tests. I made a Commodore 64 dead-test diagnostic cart (which you can see above, inserted into the cart slot), but the SX-64 is apparently different enough that it fails quite a lot of tests.

But all in all, I’m quite happy. The keyboard needs a standard cleaning cycle, but that’s nothing to write home (or blog!) about.

Custom keyboard for PET 4032

Posted By on October 9, 2012

I was exploring the possibility of making the graphics keyboard of a PET 4032 a bit more usable, by replacing the special characters in the upper row with numbers, as in a “typical” keyboard.

My ROM edits worked in VICE, so MikeS on the VC forums offered to burn me a ROM with my image. I just got the ROM today, and I am excited: it works! I even made a video with a “live smoke test”:

Commodore PET web browser?

Posted By on October 1, 2012

In a previous post, I talked a bit about the Commodore Flyer.

There are a number of Ethernet devices available for Commodores, such as the 64NIC or the RR-Net, but these are all memory I/O based. The Flyer instead uses Commodore device channels to communicate with the network.

For me, this seems to open up a whole lot of possibilities that may not be practical with the 64NIC/RR-Net stuff, because each and every individual program needs to be “net aware”, while with the Flyer, you use standard Commodore device commands (OPEN, GET, etc).

The network device appears as #7, and you can open, read and write to this just like any other Commodore device. There is even a command channel, sub-address 15, where you can issue net specific commands.

On the Retroswitch web page are a couple of demos of network-aware programs: irc and telnet. But since web traffic is just another protocol, would it be possible to have a Commodore PET web browser?

Of course, I am using the Hack-a-Day retro challenge as my example…

Fundamentally this is pretty easy: open a channel to a URL, read the incoming text, and process it. I wrote a short BASIC program which is probably the crudest HTML processor you’ve ever come across…

You’ll excuse the spaghetti code. It’s unavoidable in a language whose only conditional is a simple IF, and whose basic control flow consists of GOTOs and GOSUBs. Niceties like “do while” didn’t exist yet…

Some comments on the actual code:

Line #1 sets the lower case. This is in conjunction with line 61, which converts from ASCII ATOZ to PETSCII ATOZ. I needed to do this to ake sure the “if” statements in 600+ would process correctly.

Line 35 sends the string to the open network socket; line 40 is for the network processor (secondary device 15).

From there, it simply grabs characters between < and > (HTML delimiters) and does some very simple processing in lines 600 and up.

Given the limitation of the hardware, I did not go all-out. There is only 1k of video memory, and 32k of RAM, so you probably would not be able to implement buffering to allow scrolling. There’s not many text formatting, so things like bold and italic, well, use your imagination.

It’s also VERY SLOW. You probably could re-write it in machine language for speed, and add a few more parsers.

Check out the Flyer documentation for some more interesting possibilities.

Edit: I made the Hack-a-day front page!, and just for that occassion, I made a short video of this:

Commodore Flyer Internet Modem

Posted By on October 1, 2012

The Flyer Internet Modem is a very cool new device that is still in active development. If you are familiar with the Comet64, the concept is very similar, altho the implementation is quite different.

This is an Ethernet interface for your 8-bit Commodore using either the PET’s IEEE buss or the IEC serial buss on the VIC-20 and above. It has connectors for both, so it will work with any generation 8-bit Commodore.

The Flyer is NOT an SD storage device. It has limited internal memory (4mb), so you won’t be loading the entire HVSC project on it. The idea behind this is that you connect it to a cloud server to access disk images. The cloud server can either be a local service by running the CloudServer program, or via the CommodoreONLINE cloud service.

Connect it to your Commodore, and there will be two new devices available: device #7 is for all network traffic, commands, and so on. Device #10 (default, configurable) is an emulated disk drive.

If you want to run the local CloudServer service, download the appropriate version (Windows, or whatever) and configure it to your specifics:

Here, I’ve defined a directory, C:\Pet, where I store PRG files, and a subdirectory under that for disk images. Configure it how you will. If you have a local firewall, make sure you allow incoming TCP port 80.

You can also sign up for a CommodoreONLINE cloud server account; the Flyer is configured by default to access this, so if you want to run a cloud locally, you’ll have to do some additional (easy) steps.

In my examples below, I’ve changed the emulated drive from device #10 to device #8. This is done via the Flyer hardware switch, but you DID read the documentation on, didn’t you?

Once you connect it, you need to do some basic configuration. First, look at drive 1: of the emulated drive, via the normal Commodore DOS commands, load”1:$”,8

Take note that, like the PET dual drives, the config is on the secondary drive, drive 1. If you’re familiar with the 4040, you’ll know what I mean…

Load and run the config program, load”1:config”,8

Press 1 to configure your network to your local environment

It’s configure to auto-update the firmware, so don’t touch #6 unless you really know what you’re doing.

Once the network is configured, go back to the main screen and press 3 to access the clouds. You can have 4 clouds configured, the first one defaults to CommodoreONLINE, but if you set up an account, you’ll need to edit this config for the username and password.

Cloud 2 was undefined, so I defined a cloud called “home” in this slot. This coincides with the local CloudServer program from above:

Once your network and clouds are configured, exit out of the program. You’ll probably want to use the hardware switch on the Flyer to select which cloud server you wish to access.

Now that is all done (which is pretty easy, altho my long-winded explanation makes it sound longer than it really is), you can start to access clouds.

The command syntax is a bit funky, so make sure you do read the documentation. Basically, if you do a directory on device #7, the network device, it will show you the disk images available on your cloud server.

This again coincides with the CloudServer above, and the directory I’ve configured for disk images. Here are a number of PET games disks. If I want to mount one of the disks to appear on the locally emulated drive, I use the load “disk:” command, so to mount PETGMS01:

load “disk:PETGMS01”,7

Remember, at this point I am loading an image from the network, so I need to use the network device, #7. Case matters, too.

You can check which images are mounted with a double-dollar command: load”$$”,7

And you can see that PETGMS01 is locally cached. You can have more disk images loaded. See the documentation how to mount and access multiple images.

Now if you operate on the locally emulated disk device, #8, it’s just like a “real” drive!

There’s a lot more that can be done, considering the design of the Flyer, such as the irc and telnet programs you can download from the retroswitch website, but in another post, I’m going to show you something that stretches things a bit…

Hybrid keyboard for PET 4032

Posted By on September 25, 2012

In a previous post, I pondered making the (graphics) keyboard of a PET 4032 a bit more useful.

After a bit of banging, this should be the working result: edit-4-40-hybrid-60Hz.bin. I’ve named it somewhat in compliance with the other ROMs, but there is no such thing as a “hybrid” keyboard, so I will try to describe what I’ve done.

This is in necessary conjunction with the keyboard edits I did in the previous post, where all I did is modify the keyboard scan table to substitute numbers in place of the native symbols:

After that, I found a portion of the SHIFT handler, and was able to patch some extra stuff in there. Here is a comparison of the original unedited ROM on the left, next to this hybrid ROM on the right:

The SHIFT twiddler occurs at $E578, where an ORA sets the high bit to allow graphics symbols. But there are 24 free bytes filled with NOPs. Perhaps something was patched out a long time ago, but this gives just enough room to squeeze in a few extra bytes of code.

On the left, I’ve shown the listing starting at $E558, which has a CMP and a BEQ, followed by a string of NOPs, then an LSR and BCC, also followed by another string of NOPs. On the right, I moved the LSR and BCC opcodes up to make room for sequential free bytes, so effectively, the patch begins at $E560.

Remember, all this is processed only when the SHIFT key is depressed.

$E560 thru $E566 deal with the shift zero. This is because one of the special characters is a backslash, $5C, whcih is not in sequence with the rest of the special characters. On the original PET keyboard layout, it occurs in a position where SHIFT-8 would be, but that throws off the sequence, so it now appears as SHIFT-0: if the keyboard scancode is $30 (the zero key), load the accumulator with $5C, and go to the instruction just after the original SHIFT twiddle.

CMP #$31 and CMP #$3A compare the characters to test for the SHIFTed versions of the (newly assigned) number keys:

  • If the character is NOT a number, jump to the original SHIFT twiddler to set the high bit (graphics characters).
  • If the character IS a number, subtract $0F to acquire the associated symbol, and the jump AFTER the SHIFT twiddler.

This has the effect of allowing the original graphics characters to appear on all the keys EXCEPT for the (newly assigned) number keys. Basically, you lose the graphics characters on the upper row, in favor of numbers and symbols. This is why I called it a “hybrid” keyboard, it’s sort of a mix between the numbers of a business style keyboard while retaining most of the graphic symbols from a graphics keyboard.

The numeric keypad should function as previous. A further exploration could be made to move these now-missing graphics characters to the keypad. I’ve used 22 of the free 24 bytes, so there are only two free bytes, NOPs left… There may be a more efficient way of doing this, and I would love to hear if someone came up with a better way.

This works in VICE. I am going to try to find a way to get this onto a real ROM so I can try it in a real 4032.

Additional thoughts on remapping PET keyboard

Posted By on September 24, 2012

I mentioned in my previous post that I noticed a number of NOPs just before the SHIFT twiddle. Makes me wonder if there was something here at one point, and then binary patched out (in a similar fashion to how I am trying to binary patch in a new SHIFT routine).

I did not know if the SHIFT twiddle was the target of a jump/branch, or if the code was sequential. Easy to test. I moved the SHIFT twiddle to the top of this block of NOPs.

The left is with the SHIFT twiddle at the original location, the right is with it moved to the top of the NOPs.

This works.

By itself, it tells me nothing. But taken with the empty bytes (NOPs), it tells me that the code is sequential, and that these NOPs are available to patch in some additional instructions.

Looking at the table I laid out on the previous post, the original codes are $21 thru $29 and $5C (the backslash). I think I can do somthing like this:

cmp #$5c ; backslash
beq $E580 ; the address after the below instruction
sbc $#10 ; subtract $10 for symbols

I might be able to take it a step further, but need to pause again. I will patch these additional bytes in and test first.

A more useful PET 4032 keyboard?

Posted By on September 24, 2012

The ultimate goal for this post is to have a more usable keyboard on a PET 4032, which currently has a graphics keyboard. This is a long, and hopefully not-too-rambling post, where I try to detail what I’ve explored. And also perhaps if someone stumbles on this, might help with a more reasonable solution than what I have to date.

This is how the graphics keyboard is laid out. Pay particular attention to the upper row of keys (and ignore the dirty keys, which have since been cleaned):

These keys have symbols rather than numbers. The numbers were accessed via the numeric keypad. This makes “normal” typing difficult. For the last mumblety years, I’ve been trained that the numbers are on the top row, and symbols are SHIFTed numbers. While the symbols themselves may change, that particular difference is easier to overcome than the absence of numbers.

There were a surprisingly large number of versions available, and even models with the same model number may be significantly different. For example, you could have a PET 4032 with TTL graphics or the CRTC. For this purpose, I will only focus on a specific set of parameters, which are still widely variant: a PET 4032 with CRTC and BASIC 4.0.

The one I have is equipped with the FAT-40 “universal” board. With a few changes, one could “upgrade” a PET 4032 to a PET 8032 by basically adding additional memory for the larger screen layout and glue logic and some new ROMs.

The bonus of a PET 8032 is that they were equipped with business keyboards; a more familiar layout. But the more “popular” version of the PET was the 4032, the 40 column version, for which there seems to be much more software available. What’s the trade-off? A better keyboard or higher software compatibility? Isn’t it possible to have the best of both worlds: a more natural keyboard layout on a more popular version of the PET?

Why not just plug an 8032 business style keyboard into the 4032?

For starters, the case cutouts are different. While I suspect the screw-holes would line up, the keypad on a graphics keyboard is larger than that of the business keyboard, and it would not look nice.

More significantly, the scan table between the two appears to be completely different. Looking at this document, one can see that the scan table does not match 1:1. Some do, some don’t. I’ll show my tests with substituting the 8032 scan table a little later…

What other options are there? The 80 column PET has twice as much video memory and the necessary glue logic to decode it. The dot clock is also doubled. Perhaps it is possible to take an 8032 ROM and patch its dot clock to the same speed as a 4032, but I have not explored this possibility yet, as it seems to be more complex.

Being a “universal” board, the other differences must be in ROM, in this case, what is known as the “edit ROM”, which is where keyboard decoding occurs. There are a variety of ROMs available, to fit the variety of systems, but sadly, this particular ROM does not seem to exist. Using the same naming scheme, it would probably be called edit-4-40-b-60Hz.

So let’s explore some PET ROM internals. Even if I don’t solve this problem, it’s still an interesting journey.

Using a hex editor on the edit-4-40-n-60Hz ROM I downloaded from above, and using the scan table from the same source, it was relatively quick to locate the scan table in ROM. In this case, it begins at offset 1855 for 80 characters ($73F for $50 characters). Just look for the beginning two bytes ($3D $2E) and the ending two bytes ($23 $21) and you’ll find it. It matches exactly.

Starting at the end is the codes for the symbols. If you edit these for the numeric codes instead, you’ll produce numbers on those keys. So change the last byte from $21 to $31, you will produce the number “1” rather than the symbol “!”.

I’ve edited the ROM as follows:

From: symbol / code | To: symbol / code
        !       21          1       31
        "       22          2       32
        #       23          3       33
        $       24          4       34
        %       25          5       35
        /       27          6       36
        &       26          7       37
        \       5c          8       38
        (       28          9       39
        )       29          0       30

Here is a screenshot of a HEX editor highlighting the original scan table.

Here is the modified ROM, after editing the changes from above.

Hard to tell, with all those hex numbers floating around, but look at the last highlighted numbers to see the differences.

I use VICE to load this ROM image into the “editor” section:

Word of caution: when you edit a ROM and want to load it into VICE, make sure you close the hex editor (or close the file) before you open it in VICE. And vice versa, when you want to edit the ROM image, make sure VICE is not running. I had a session of head-desking trying to figure out why my saves were actually not saving…

And indeed, this works. The upper row of the keyboard now outputs numbers instead of symbols.

But this reveals a further issue. There are no longer any symbols. These number keys, SHIFted, still outputs the graphics characters as they did before editing.

It was at this point I took the 80 column ROM, edit-4-80-b-60Hz, and found _its_ scan table (which begins at offset $D61, for $50, or 80 characters), and copied it into this 40 column ROM. I found that many of the keys no longer mapped to where they should, so that particular avenue was a dead-end.

Looking at the two scan tables on zimmers, it appears that SHIFT is handled differently on the business keyboard than it is on the graphics keyboard, as revealed by the statement “The shift key always set the high bit, producing a graphic character”.

This is easy to verify. Just PRINT ASC(“A”) and then do for SHIFTed-A (a heart symbol). Since your dealing with bits, it’s easier to look at them in binary. “A” = 65, or binary 0100 0001, SHIFT-A = 193, or binary 1100 0001. And so on thru the whole character set. Indeed, when you press the SHIFT key, it just sets the high bit.

I guessed that the easiest way to do this is to simply ORA #$80, which is the logical “or” operation, to set individual bits, in this case $80 being the high bit. In 6502 opcodes, this would be 09 80. Indeed, there were several spots where this sequence occurs, so I tried each one until I either hit the last one, or changed the behavior in expected ways. I actually found my guess was correct at location $E578. Changing the operand of the ORA from $80 to 00 has the effect of disabling the SHIFT key (since it does not set anything). Changing the opcode to various numbers changes the shift behavior.

How to take advantage of this, so that rather than setting the high bit for graphics characters, allow SHIFT to produce the more usual characters? What is the difference between a number “1”, and its SHIFTed counterpart, “!”?

$10 is the difference. The number “1” is $31, and the SHIFTed “!” is $21. What if I change that ORA #$80 to subtract $10? SBC is opcode $E9 with the operand $10. Patch that into location $E578:

It is the last code listed on this disassembly.

This works, with yet other issues become apparent. Of minor note, it affects non-numeric SHIFT keys, like regular letters.

But the numbers, which are my focus, are not 1:1. Look at my original table above, and you see that the symbols are not in sequential order. The “/” and the “&” are in opposite order than I would expect, and the backslash, “\”, is completely out of order. So subtracting $10 does not give the desired outcome.

Since a simple subtraction does not suffice, I suspect there will need to be some comparisons to take this range into consideration, which might mean patching in additional code.

In the short snip of disassembly above, there are about 16 bytes of NOPs just before the SHIFT twiddle. I figure I can use these bytes for additional patched code, as long as the SHIFT twiddle address ($E578) is not the target of a JMP or branch, and as long as those NOPs are not timing critical delays.

But at the moment, I’m out of ideas, and staring at all these hex numbers is making me wonky.

Here is an image of the edits that I’ve made. If you load this into a HEX editor and compare this with the original, you’ll see the changes (and only those changes) that I’ve listed above. The upper row outputs numbers, and the SHIFTed keys of this row puts of some, but not all, of the correct symbols (and you’re losing the SHIFTed graphics symbols in the meanwhile).