Written and Maintained by Gregory Nacu


Subscribe to C64OS.com with your favorite RSS Reader
July 19, 2019Hardware

Burning EPROMs with Promenade C1

Post Archive Icon

Some quick updates to start with. If you haven't noticed, I've recently put a fair bit of work into the "C64 OS" section of this site. Originally intended to be for technical documentation, and so named for a while, I have rebranded the section as, C64 OS: USER'S GUIDE

I've divided the left–side table of contents into two sections. The first half is just a basic user's guide for regular users. Then part way through there is a subheading for Programmer's Guide, followed by the programming documentation. I've put a good chunk of work into both halves of the guide. The Programmer's Guide is divided primarily by C64 OS kernal module, and I've completed 6 of 10 modules, plus an introduction to the C64 OS kernal, macros, registers, flags, symbols and lookup tables.

I've also been working on a paper version of the manual. But, the limited space in the paper manual means the online version can go into a lot more detail. Having the online version will make me more comfortable about trimming down the paper version to probably 14 or 16 pages.

A second quick update, I've introduced a new layout to the weblog section of C64OS.com. If you look to the left you'll see three buttons at the top, View As Newsfeed, View By Category and View Full Archive. The archive view has been around for a while, but getting to it was never as easy as it is now. View By Category is new. It's got a table of contents at the top, reminicsent of the Buyer's Guide, and the posts are laid out in a grid grouped by their main category tag. I think it's quite nice. Though, now I've got to get better at making nicer "icons" for the posts.

Okay, so following up on my recent post, Versa64Cart and C64 ROMs, I wanted to discuss my experience using the Promenade C1. The Promenade is an EPROM burner with a 28–PIN ZIF socket, in a rugged aluminum case. It connects to your C64 or c128 via the user port. I remember seeing this advertised in the back of a buyer's guide catalog that Commodore put out in the late 80s. I loved that buyer's guide, and I used to drool over all the third–party peripherals. As a kid, the Promenade was one of those that looked interesting, but I never quite understood what it was for.

Who knew that, 30 years later, I would eventually own one, figure out how to use it and then blog about it, singing its praises. But that's pretty much what happened. When the Versa64 Cart came to my attention and I got interested in trying to assemble and sell some, I also wanted to find out if there was any way to burn EPROMs right from my C64. I like doing things with the C64 as much as possible. It's fun, and it feels more authentic to me. So I did a little search and discovered the Promenade. "Oh, that's what that thing from my childhood memories is for." Nice.


The Promenade C1 was built and sold by the Jason–Ranheim Company, out of California. I started asking around about how I could acquire one, and found someone on IRC who had 2 of them and was willing to sell one to me. I bought it, and when it arrived it was in excellent physical and working condition. Here's what it looks like, both outside and in.

The outside of my Promenade C1. The inside of my Promenade C1.

It looks like it's in pretty great condition, considering that the silkscreening1 on the PCB says 1983. There is no corrosion or leaky caps. And it's almost perfectly dust free. What a great find.

What does the Promenade do?

It programs EPROMs. Yes, but how does it do that? What does a computer have to do to program an EPROM? For that matter, what is an EPROM?

EPROMs were an early development in programmable logic. Erasable, Programmable, Read Only Memory. The first ones of reasonable capacity (say, 1 to 2 kilobytes) were available in the mid to late 70s. By the 80s larger capacity EPROMs, 8K, 16K, 32K were common. The chip casing has a window on the top that exposes the component to light. When exposed to sufficient quantities of UV, the memory circuits close. Thus, an empty EPROM reads as all 1s. The job of the programmer then is to blow out some of those circuits so they read as 0s. Once the chip is programmed it needs to have a sticker put over the window to protect it from light exposure, that, with enough time, will erase it.

There is a family of common 8-bit EPROM chips, 27xxx. The number following the 27 is how many kilobits the chip can store. So a 2764 holds 64 kilobits, which, divided by 8 is 8 kilobytes. The 27128, 27256 and 27512 are all pin compatible (more or less) with each other, with 28 pins total. The following diagrams were included in the post about the Versa64 Cart, but here they are again:

Pinout of a 27C64 EPROM Pinout of a 27C128 EPROM
Pinout of a 27C256 EPROM Pinout of a 27C512 EPROM

To use an EPROM as memory in the C64, (theoretically, in practice it's more complicated,) the chip's 8 data pins connect to the C64's 8-bit data bus, and the chip's address lines, from A0 to A12 (A13, A14 or A15, depending on the size of the chip), connect to the C64's 16-bit address bus. This can account for up to 24 bus lines. 8 on the data bus and 16 on the address bus.

But, how would you program an EPROM? With the upto-16 address lines, each 8-bit word in the chip can be addressed. The data to be written is supplied on the chip's 8 data lines. Set the address lines to select the address to write to, set the byte on the 8 data lines, then there is some combination of a PGM line, and a higher voltage line. Depending on the chip, the voltage might be 12.5V, 21V or 25V. The high voltage is required to blow out the circuits selected by bits of the data pins. If a bit is high, an erased EPROM already has a 1 stored. Only the low bits actually need to be written.

We need to be able to independently set 24 output lines, and drive a voltage line at either 12.5, 21 or 25 volts. Ideally we'd do this with the user port. But, unfortunately we're sort of out of luck. Let's take a look at what the user port offers.

Section of C64 Schematic, with User Port and CIA 2.
Some detail removed for simplicity

The user port is primarily connected to CIA 2. But, each CIA chip only has two 8-bit ports for a total of 16 programmable lines. And, as it happens two of these (PA0 and PA1) are used for VIC-II bank selection. And five of them (PA3, PA4, PA5, PA6 and PA7) are used for controlling the IEC serial bus. Leaving only one of the lines from Port A (PA2) available on the user port, plus the 8 lines from Port B, for a total of just 9 lines.

The remaining lines on the user port are for GND, +5VDC, 9VAC, as well as a reset line, and the lines for the CIAs serial port and pulse counter. 9 programmable lines is simply not enough to simultaneously configure the EPROM's 16 address lines, plus set its 8 data lines. And even if it we had enough, the C64 cannot drive any line to voltages high enough to program the EPROM.

What we need is a way for the C64 to set 8 lines at a time, and have those lines get latched externally. The software can then go through a few phases of that until the number of lines needed have been met. Then drive the programming lines to high voltage. And repeat for every byte to be written.

Well, take a look at the schematic of the Promenade C1.

The Promenade C1 Schematic. A set of three 74LS374 chips.

Along the right hand side we see three main ICs, U5, U8 and U10. These are 74LS374 chips, according to the datasheet, these are 3-STATE Octal D-Type Transparent Latches and Edge-Triggered Flip-Flops. Edge triggered flip-flops, means we can clock some data into this chip, and it will hold as output the value that we input. Octal means there are 8 of them, each stores (latches) one bit. And 3-state means that with an output enable control line the output lines from the 8 flip-flips can be put into High Z, effectively removing the chip from the circuit. However, in this particular use case the 3-state feature is not used. You can see that each chip has its /OE line hardwired to GND, so all three chips are always enabled.

At the top left of the schematic are two chips, U1 and U2, these are 723 voltage regulators. Along with that cluster of diodes and large electrolytic capacitors to the left of them, these take the 9VAC from the user port pins 10 and 11, and convert to the appropriate voltage to program the EPROM. The bulk of the rest of the logic on the left hand side of the schematic is there to support configuring the output lines for each of the various EPROMs the Promenade supports.

The EPROM requires, in theory, upto 24 lines to program. The Promenade doesn't actually support the 27512 via software alone. There is a hardware jumper to toggle how its A15 address line is connected. But the C64 actually has to provide more than 24 bits of data. In addition to the EPROM's address and data lines, it needs to control the output voltage level, and also select between the different types of chips which have slight variation on how their upper legs are used. But, wait now, if each 74LS374 has 8 latches, for 8 bits, and there are three of them, that's 24 bits, but we need more than 24 bits to handle the control lines. Don't forget, once the 74LS374 lines are all configured, the 8-bits on the user port are free to be used at the same time. So the three 74LS374's plus the user port give us at least 32 programmable lines.

The 8 data lines on the user port, the CIA's Port B lines, are labeled Q0 to Q7. These are connected in parallel to each of the 74LS374's for setting their values. But the the same lines, Q0 to Q7 are connected to the EPROM's data pins on the ZIF socket, pins 11, 12, 13, 15, 16, 17, 18 and 19. So the user port first programs each of the 74LS374's, with the address bits and the control bits, but not with the data byte. Then the user port itself provides the 8-bits of data to be written.

I'm not totally sure, but it looks to me like user port pins 5, 7 and M are used to control which 74LS374 is being addressed. These are special lines, 5 and 7 are the serial line of CIA 1 and 2 respectively. And M is the lone bit from Port A. So the C64 manipulates these lines to copy a byte at a time from Port B to the each of the 74LS374's. Then, it puts the data byte to write on Port B and raises line 9. Line 9 on the user port is the IEC's attention line. But it is also fed out to the user port. This causes a NAND gate to flip over, which then passes through a pair of XOR gates at the bottom of the schematic, which activates the CE line, which is the Chip Enable on the ZIF socket. Thus enabling the EPROM as the final step, while all the other lines are already appropriately set.

It can then hold line 9 for as long as it wants, to continue to apply the programming voltage to the EPROM. That's about it for the hardware.


Next up is the software. The Promenade C1 originally came with software called Promos. The last version is Promos 2.0. I think this is to be read PROM-OS, like Programmable ROM Operating System. The reason for this name, I believe, is because the whole software is designed as a BASIC extension. I really like this idea. Back in late 2017 I wrote a post called BASIC Wedge Programs, and had ideas for an image viewer, SID Player, unzip utility and more done as BASIC extensions.

The BASIC ROM was designed to be extensible through a series of RAM vectors. And, once extended, you can add the new commands into your BASIC programs. This is so great, because, for things like an image viewer BASIC can be used, as a scripting language, to create slideshows, changing images automatically after a time delay or press of a key. And you could read the filenames of the images out of a data file. I love this idea.

Anyway, making PROMOS a BASIC extension is great. After you load and run PROMOS, it spits out a version and copyright notice, changes the color scheme to blue on white, and you are returned to the READY prompt. The only command you really need to know is G, for glossary. The commands can be run either in direct mode or program mode. So you can just type G and press return, and it prints out the glossary, shown below.

Loading PROMOS 2.0. Listing the PROMOS Glossary.

The glossary provides a list of commands, with example syntax. It looks a bit daunting at first, but it's really quite straightforward. The commands are very reminiscent of using a machine language monitor. Comfort and familiarity with hexadecimal is a must. Though, if you're planning on burning EPROMs you're probably the kind of person who already knows hexadecimal and maybe is even comfortable in an ML Monitor.

Here's the general concept behind the software:

Install a ROM with data into the Promenade's ZIF socket. You can then read a range of data from the ROM into the computer's RAM. Swap the ROM for a new blank EPROM, and you can then write a range of RAM into the EPROM. With the contents of RAM still intact, you can swap in another blank EPROM and write out the same range of RAM again. This is the general idea.

Additionally, there are numerous things you can do with the data. Data in a range of RAM can be written out to a file on disk. A saved file on disk can be loaded back into RAM. So you can rip pre-existing ROMs and save copies of them to disk. You can later load back in any of your saved ROMs and write it out as many times as you want.

There are numerous other commands for working with data to make your life easier. Here are some things you can do:

  • Compare one range of RAM to another.
  • Transfer a range of RAM to elsewhere in RAM.
  • Verify that a range of RAM is the same as in ROM.
  • Get a HEX dump of a range of RAM.
  • Get an ASCII dump of a range of RAM.
  • Search through a range of RAM for a sequence of bytes.
  • Get a HEX dump of the ROM.
  • Get an ASCII dump of the ROM.
  • Fill a range of RAM with a byte.

And so on. This is an amazingly flexible set of tools. Once data is loaded into RAM, you can search or browse through the data, and just as in a machine language monitor, you can change any bytes in memory you want.

Aside: Creating your own custom KERNAL ROM, for example, is very easy. In fact, just a couple of weeks ago, someone from Italy wrote me an email asking if I could help him figure out how to modify the KERNAL so his C64 would always start up and soft restart into uppercase/lowercase mode (rather than the uppercase/graphics mode a C64 usually defaults to.) I looked into it, and it turns out to be very easy. There is a table of bytes used to initialize the registers of the VIC-II. The byte at $ECD1 sets the VIC's $D018 register to $14. And, with a bit of sleuthing, I found that holding SHIFT and pressing COMMODORE merely toggles bit 1 of this register in the VIC-II. There is no other variable used to track this state. You could pull the KERNAL ROM from another C64 and plop it into your Promenade C1. Copy the entire 8K ROM to a range of 8K of RAM. Calculate the offset to where that byte is in RAM, and change it from $14 to $16. Swap an 8K EPROM into the Promenade, and write the modified KERNAL out to it. Bingo, bango, pop that EPROM into your C64 in place of its original KERNAL ROM and all of a sudden your machine always defaults to uppercase/lowercase mode. Very Cool.

Arguments used from the previous command are maintained, so you can run subsequent commands with the same arguments without needing to retype them. For example, after you program an EPROM by writing data from a range of RAM to a starting offset in the EPROM, you can afterwards verify that the write was done without error by using the verify command. But, you don't have to reenter all the details, just type "V" and press return.

Otherwise, every command stands on its own. Commands that involve reading data from a ROM require you to supply a control word. The control word is just a single byte whose bits are used to configure the Promenade for the type of EPROM in the socket. There is a very easy table of control words in Appendix C of the manual. If you've got a 27C256 EPROM in the socket, for example, you look up that EPROM in the table, and it tells you to use control word E6.

When writing data to the EPROM, (there is only one command to write to EPROM,) you have to include one extra byte to specify the programming method. Again, the table gives you the recommended programming method value for the type of EPROM you're burning.

You have to get the format of the commands right, but they're not too hard. For example, when you want to read data from the ROM into RAM, the first two arguments are the start and end addresses of RAM to read into. And the third argument is the offset whence to start reading in the ROM. All numbers are in hexadecimal. So, R 2000 2FFF 0 E6 will read data from the EPROM starting from offset 0, and will fill into memory from 2000 to 2FFF. That will cause 4 kilobytes to be read. This too is very powerful. You can read, say, four 1K chunks from the ROM and write them into memory in reverse order, then write out the whole 4K block in memory to EPROM. But the order is now different.

It might not seem like it makes sense to do that with a single program, but when you're writing a 16K EPROM with two 8K programs, for use in a bank switching cartridge like Versa64 Cart, it makes lots of sense. It's a snap to reverse the order of two 8K ROMs on a 16K ROM, for example. Furthermore, you don't have to write a whole EPROM all at once. If you have a 32K EPROM, you can write out different non-overlapping chunks to it, at different times. It's very flexible.

Let's say you don't care for the flexibility, and you'd much rather have something that's just a little bit more intuitive. In 1997, Ben Holmes wrote a program called PROM-SHELL. It looks a lot like the sort of tools that CMD made in that era, like FCOPY and BCOPY, etc.

PROM-SHELL requires PROMOS 2.0 to be loaded in. And then PROM-SHELL is probably written in BASIC. It doesn't have to do much, except be a simple menu-driven front end that calls the PROMOS commands in BASIC.

PROM-SHELL 64 by Ben Holmes.

It's a nice little program. And it's a great example of what you can do because the original PROMOS was written as an extension to BASIC.

And that is pretty much it for the software.


These software packages and manual are floating around elsewhere on the internet, but I offer them here so that this software won't be lost to bitrot and other natural forces.

Programming from the Ultimate 64

My first attempt to use the Promenade C1 was, strangely, on the Ultimate 64. One weekend I decided I wanted to bring my Ultimate 64 over to Jérémie's place, use the HDMI cable to easily hookup to his big monitor, and then we could figure out how to use the Promenade and the Versa64 Carts together.

The problem is that the Ultimate 64 doesn't have a standard user port. Instead, where the user port is usually found, there is an HDMI port, an Ethernet port and 2 USB ports. Fortunately Gideon didn't completely forsake the user port. Instead, the Ultimate 64 mainboard has a terminal block just behind the expansion port.

When I originally purchased my Ultimate 64 the terminal block was the only offering. But now, the store is also selling, as an accessory, the U64 Userport Expansion. A small board with a male user port edge connector, and a matching pin block. It ships with a matching 26 PIN ribbon cable.

Ultimate 64 User Port Adapter.

I've since ordered one, but it hasn't arrived yet. (Correction, as of a few days ago, it just arrived.) I'm also way to impatient to wait around for a few weeks for an order to be fulfilled and then ship across the world. I decided I could put together my own cable without too much trouble.

Custom Ultimate 64 User Port Cable 1. Custom Ultimate 64 User Port Cable 2.

I got the male edge connector by dremelling off one end of a mini prototype board I'd ordered a while back from Shareware Plus. They're in the Buyer's Guide under Prototyping Boards in the Hobbyist section.

I was a bit nervous testing it out for the first time. I didn't want to damage my Ultimate 64 or the Promenade. But to my delight and surprise, it seemed to work. The Promenade C1 powered up. The first thing I tested was an original 1571 ROM (one I'd pulled after upgrading a 1571 to JiffyDOS.) Using the "ASCII dump from ROM" command, I was able to read in a portion of the ROM, and sure enough, up popped (C)1985 COMMODORE ELECTRONICS LTD., ALL RIGHTS RESERVED. Very cool, it seems to work!

Reading a 1571 ROM via custom user port cable on Ultimate 64.

The next day I hauled my gear over to Jérémie's so we could nerd out in his retro computer haven for the afternoon, as our kids played together.

We used the Promenade to rip a few ROMs from some cartridges he had. But then came the bad news. Depending on the programming method you specify, the Promenade goes through a sort of realtime verification process while it's programming. It tries to program a byte by setting the programming voltage for a fixed unit of time, then it reads the byte back in and compares it to RAM. If they're not the same, (and the byte read is all 1s, presumably, meaning that byte is still "erased") then it repeats the programming stage for another, longer, fixed length of time. It repeats this check and retry process a few times, and if it still isn't programmed, it aborts with an error.

No matter what we tried it always failed to program the EPROM. At the time I didn't know what the problem was. It was the first time I was trying to use the Promenade to write an EPROM. It was the first time I'd ever used these particular EPROMs. It was the first time I'd ever used the user port on the Ultimate 64, and I was using my own handmade user port cable. A bad combination of "firsts" when something isn't working and you have to troubleshoot.

We decided to try using Jérémie's regular C64c. And, it worked! So there was no problem with the Promenade C1, and there was no problem with my EPROMs. It came down to just the Ultimate 64 or my homebrew user port cable. Since then, I have discovered the reason why it wasn't working. As we saw earlier in the schematic of the Promenade C1, to get its 12.5V, 21V or 25V programming voltage, it runs the user port pins 10 and 11 (9VAC) through a pair of 723 voltage regulators. The problem is, well, take a look at this:

Comparing the pinouts, the Ultimate 64 outputs 12VDC instead of 9VAC.

The left is the c64-wiki article on the user port. And the right is the technical documentation for the Ultimate 64, and its user port terminal block. The Ultimate 64's user port pins 10 and 11 don't output 9VAC… they output 12VDC. No wonder the Promenade was unable to program an EPROM, even though reading them was just fine.

Now, why the difference? On a regular C64, the 9VAC comes directly out of the power supply. There are two pins, 6 and 7 on the 7–pin DIN connector, that provide 9VAC directly. On older C64s the SID makes use of 9VAC, plus the 9VAC is available on the user port. In new C64s the SID no longer requires 9VAC, so the only thing the 9VAC from the power supply does is goes to the user port, for legacy reasons and compatibility with a few strange peripherals. Like, oh, I don't know, maybe an old EPROM burner! The Ultimate 64, on the other hand, uses a much simpler power supply, that outputs DC voltage only. There is no quick and dirty way to just run a trace from the power supply to the user port. Instead, I guess, Gideon opted to replace the 9VAC on those pins with 12VDC.

Apparently, and according to the Ultimate64.com shop, when you order the U64 Userport Expansion board, you can specifically request support for 9VAC. And according to the documentation, the extra pins, 13 and P on the terminal block, which can be software controlled, are used by the user port expansion board to generate the 9VAC. Unfortunately, I hadn't yet figured out that the Promenade C1 requires 9VAC at the time I ordered the expansion. I probably won't bother to order the 9VAC version. And I'll just have to remember that the Promenade C1 doesn't work without the special adapter. In the meantime, it's no big deal. I can just use it on a regular C64 or c128.

Some Glory Shots

Here is the Promenade C1 in use, burning a ROM on a C64c.

Something to be wary of. The Promenade is quite wide. Unfortunately, when it is plugged into the user port it partially covers the cassette port. Now, you might think, well, who cares about the cassette port while you're busy burning EPROMs. But, many SD2IEC drives get their power from the cassette port. In these photos I'm using the uIEC/SD from Retro Innovations. It has a deluxe daughter card that plugs into the cassette port and adds a pair of IEC ports. Fortunately, the daughter card also has a micro USB port. This port is specifically for supplying external power.

Glory shot 1, using Promenade C1 on C64c. Glory shot 2, using Promenade C1 on C64c.

Another work around could be to use a user port expander, such as a GeoPrintCable-II, in passthrough mode. (If you happen to have one.)

Writing a BIN file from a PC

There is one topic I want to touch on, which involves programming an EPROM with a BIN file that you've transferred over from a PC.

The BIN file, let's say it's for an 8K ROM, will be exactly 8192 bytes. And it will occupy an area of memory that is exactly 8K, from say, $2000 to $3FFF, inclusive. But this is not exactly the same as a file you might save for yourself from PROMOS that you ripped from a real ROM. Why not?

Let's say you tear open a cartridge of GORF, and it has an 8K ROM inside. You pull the ROM and drop it into your Promenade C1. Then you use the command to read the ROM into memory from $2000 to $3FFF. It occupies exactly 8192 bytes in memory. Then you save the file from memory to disk. When the region of memory is saved, the KERNAL's save routine is used, which creates a PRG type file on disk, AND prepends the 8192 bytes of data with the standard 2–byte load header. In this case the load header will be $00 $20, little endian for $2000.

When you use PROMOS to load in this file, it uses the KERNAL to do the load. This reads the first two bytes, interprets them as a load address, and then loads the next 8192 bytes to memory starting at that address. Without needing to specify where in memory to load to, the file you previously saved will be loaded back to $2000–$3FFF, its original location. If you saved a file but you'd rather load it into a different area of memory, this is also supported by PROMOS (because it's also a standard feature of the KERNAL.) You simply provide the address in the load command. In this case, the KERNAL reads in the first two bytes and completely igores them. Then it proceeds to read in the next 8192 bytes to the load address you specified.

You can see now why this is problematic when you've copied a BIN file over from a PC. Those files don't include the C64's standard 2–byte load address. First off all, you must specify where to load it to, because the first two bytes will be more or less random, as they're part of data. The KERNAL would interpret them as a load address and send your file to some unpredictable place in memory, possibly corrupting PROMOS itself or other important data in low memory.

But what's worse is that there is no way to get the KERNAL to treat those first two bytes as data. Either the KERNAL will treat the first two bytes as the load address, OR it will skip them ignoring them completely. But it won't load them in. You could modify the file by prepending a valid load address, like $00 $02, to the file on disk. But, I also came up with a pretty easy workaround.

All you have to know is what the two bytes are. You can write a dead simple BASIC program to read the first two bytes and print them out.

The two values printed out are in decimal, you'll have to convert them to hexadecimal. If you can't do that in your head, then you can use a calculator. The calculator in macOS can do it, or a quick search on DuckDuckGo: 30 in HEX gives you 1E. Either write these down, or remember them.

Next, load in the BIN file, but specify the load address as $2002. The KERNAL will skip the first two bytes, but it will load the remaining 8190 bytes into the correct place, because you started offset by 2. Next, use the M command to do a HEX memory dump starting at $2000. Just like in a machine language monitor, you can cursor up to the HEX output, make a change and press return, and the data at that location in memory will be set. Simply cursor up and insert the two bytes you read in and converted above into $2000 and $2001. If you're going to repeatedly use this file for burning ROMs, you could save again, and the new saved copy will include the proper load header.


Lastly, the Promenade C1 was first released in 1983, over 36 years ago. And Jason-Ranheim hasn't been making them in, well, a long time. So why am I bothering to write a blog post about how to use one in 2019?

Daniel Newbury, with copyright permission from Jason-Ranheim, cloned the Promenade C1, which he called the Megabit C1 Clone. Unfortunately, he's stopped selling them too. He has provided his schematic of the device though, and I've made some inquiries about getting the schematic converted into an open source hardware project.

With a bit of luck, we may be able to get the Promenade C1 back to life, and make it commercially available again. It would feel so great to add this old treasure to the Commodore 8-Bit Buyer's Guide. From childhood memory, and wonder about what it is and what it does, to being able to order parts and assemble myself, and listing it in the Buyer's Guide that I maintain. The new world is a wonderful place for retro computing.

Keep your eyes on the site for updates to this project!

  1. That's not silkscreening. It's actually written by leaving behind the trace metal. I wonder if that was an old practice. []

Do you like what you see?

You've just read one of my high–quality, long–form, weblog posts, for free! First, thank you for your interest, it makes producing this content feel worthwhile. I love to hear your input and feedback in the forums below. And I do my best to answer every question.

I'm creating C64 OS and documenting my progress along the way, to give something to you and contribute to the Commodore community. Please consider purchasing one of the items I am currently offering or making a small donation, to help me continue to bring you updates, in–depth technical discussions and programming reference. Your generous support is greatly appreciated.

Greg Naçu — C64OS.com

Want to support my hard work? Here's how!