Adventures in LPT - Part I

An integral part of cross-developing for any platform is obvious: how do we transfer our work to the real hardware?

In the world of the Commodore 64, a few decent solutions have been proposed:

1. Install a 5.25" floppy drive into your PC.

2. Create a C64 cartridge that emulates a C64 disk drive and takes an SD card (or similar) as input.

3. Create a cable to communicate between the C64 and a PC.

And yes, there are others that I didn't mention. But by far, my personal favorite is the third option. But what kind of cable do we use, and how does it work?

A few cables have been designed, my favorite being the XE1541 cable, invented by Nicolas Welte and Wolfgang Moser:

This image from http://amigakit.leamancomputing.com/catalog/images/1541-transfer-cable.jpg , if you didn't catch the watermark ;) .

This cable connects the 6-pin serial DIN port on the C64 to a standard 25-pin LPT (Line Print Terminal) on a PC. In this way, the two can be connected in such a way that the PC will act just like any peripheral device that could be connected to the C64. Specifically, we can write a program for the PC so that it will act exactly like a CBM 1541 floppy disk drive (or any C64-compatible floppy disk drive, really).

Astute and/or experienced readers will notice something. The C64's port is serial, but the LPT is parallel. How can this be, and why wouldn't we just connect the right lines to a serial COM port on the PC?

You have to remember here that the C64 is over twenty years old. The significance of this is that the transfer rate of its serial port is WAAAAAAAAAAAAY slower than that of modern COM ports. In addition, there are lines in the C64 serial port that can't be checked with a modern COM port without direct pinout control. This means that with hardware-controlled serial encoders and decoders on the COM ports, we can't slow the PC's connection down enough to effectively communicate with the C64. However, we can connect certain lines of the C64 to corresponding control and status register lines of the LPT. In this way, we can connect lines that weren't available to us by using a COM port. More importantly, though, we can simply continuously output or poll with correct timing the necessary values to/from the C64.

That's all for now I think :) . In the next parts of this series, I'll get into the specifics of the XE1541 cable, with schematics, some connector pinouts, etc :) . For now, wish me luck, as I finally submitted my MIT application! Also bring on 2010...YUP's got some big things planned; are you ready? ;)

YUP Commodore 64 Demo - Introduction

Yes, it's true. The demoscene's youngest group is making a demo on the demoscene's oldest machine :) . Why, you might be wondering?

1. The C64's CPU is a MOS 6510. It's basically a 6502 but with an extra 6-bit I/O port. The instruction set for this ~1mhz tiny titan contains only 56 instructions (mostly 8-bit with some [limited] 16-bit support; as was the case with many microprocessors of its time) and very few addressing modes...not to mention a wonderful list of illegal opcodes supported by many assemblers out there :) . This is an extremely nice little processor to program.

More info on the MOS 65xx processors can be found here: http://www.masswerk.at/6502/6502_instruction_set.html

2. The color palette is completely different from most of the 8-bit computers at the time. Most of the C64's competitors used a typical "generic" 8-colors-at-two-brightness-settings sort of palette, just like in less-recent versions of MS-Paint...also like the Sinclair ZX Spectrum, whose palette can be seen here:

But strangely, when the C64's video chip (the VIC-II) was designed, they completely threw out convention and went their own unique direction for colors...well, except for black and white :) . This lovely palette can be seen here:

Thanks to the guys at http://www.retro-sanctuary.com/ for those images, by the way.

3. Well, um...I don't really have a third reason. I guess I could admit that I have a soft spot for vintage computers...but that's too cheesy, right? :)

So, yeah. We're doin' it. And no, we're not coding it for PAL machines, because I'm from the US where NTSC is the only way to go. Progress has been painfully slow, as [thus far] I've done all the development myself. This includes music, code, and graphics (if you'd even call crappy hardcoded bitmaps graphics)...though, I'm proud to say I've managed to do some nice technical things that most beginners in the C64 scene are too afraid to even attempt :) . All in all it's been a fun ride, except for music developmet. Mainly, this is because the only cross-development tracker for the C64 currently is a program called GoatTracker. Originally, it was written for DOS, and later it was ported to Windows, taking its confusing and dated user interface along with it. Maybe I'll end up doing my own someday to make this process more bearable. On the code side, I've been using Notepad++, C64Asm, and batch files for assembling. This works pretty well..though I'll most likely switch to an assembler like ACME, which supports scripting so I won't have to unroll speed-critical loops by hand. I suppose a couple screenshots for you wouldn't hurt, either:

...Nothing too impressive, really...mainly because I really didn't show you much at all ;) Not to mention that first screenshot is nowhere near finished...but I like the colors, so why not show it? :)

I suppose that's all for now. Wish us luck in finishing this beast someday :)

New Blog!

Hey guys, Ferris here. After [far too much] nagging by [too many] friends of mine, I finally started a blog. Within a few days here you'll start seeing some progress for many of my current projects, including a new 4k synth system, a Commodore 64 demo, and more. For now, I'll spend several hours (or at least until my lappy dies on me) perfecting the layout; though we all know as a scener I'll never be truly happy with it ;) .