6502 nostalgia

I’ve been trawling through YouTube lately, looking for videos on various tech subjects such as operating systems and embedded programming. Along the way I took a side trip through a series of videos which I’ll label as nostalgia system videos, where the creators talk about various home computer systems of the late 1970s and 1980s. Those videos cover, but aren’t limited to, Atari, Commodore, and Tandy (Radio Shack) home systems. Those in turn are further segregated into the CPUs, such as the 8080/8085, Z80, 6502, and 6800/6809. The computers I used from that period were 6502 based, starting with the old Apple ][ and later theĀ  Commodore 64, for which I paid the princely sum of $599 when it was first introduced in early 1982.

The Commodore 64, or C64 from here on out, was worth every penny. I had enough money left in my budget to purchase one Commodore 1541 floppy disk drive to go along with the C64. It was either that or else use a cassette tape recorder, and I’d come to absolutely loathe using cassettes for external storage due to my exposure to them with the TI 99/4a. If I’d tried to purchase the functional equivalent in Apple hardware it would have set me back between two and three times as much as I spent on Commodore equipment.

I didn’t purchase my C64 for games, I purchased it to act as a development system for other 6502-based DIY computer designs. To support development I wire-wrapped an external expansion board for my C64 that would program EPROMs and implement a real serial RS-232 interface. That board consisted of two MOS 6522 Versatile Interface Adapters (VIA) and an MOS 6551 Asynchronous Communications Interface Adapter (ACIA). I used an ACIA because I was absolutely horrified by the bit-banging the C64 used to do serial communications; the ACIA guaranteed serial communications to at least 19.2 kbits/s. While I started utility programming with the built-in C64 Basic, I quickly transitioned to a 6502 macro assembler for both utility tools native to the C64, and then later to do programming for my other 6502 DIY designs.

I purchased my C64 and 1541 in March of 1982. By the end of that summer I’d finished my C64 expansion board for programming EPROMs and had begun to development on the board you see below.

65c802 single board computer, circa 1980

The design you see now is what’s left of a five year on-and-off evolution, before I stopped to work on other paying designs and began to pull parts off that board to support those paying designs. At the height of its operational glory my 6502 board had two RS-232 serial ports, 48K of static RAM, and space for 11K of EPROM. There’s 1K of the address space set aside for all the peripheral chips on the board. Before I explain how I did that, let’s go through a list of the components on the board.

  • W65C802P-4 — A Western Design Center 65C802 at 4 MHz. This chip replaced the original NMOS chip I started with back in 1982. The manufacture date is 8542, so this chip was made in 1985, which fits with the time I purchased and installed it on the board. It was my intention with the original board to push the CPU clock as much as I could. I never went any faster than 4 MHz.
  • R65C22P2 — A Rockwell 65C22 VIA chip. I swapped this in for the original MOS device to correct a logic bug with the original MOS 6522.
  • WD1770 — A Western Digital single-chip floppy disk controller. The disk interface connector is on the far left edge. I managed to write 6502 assembly routines that could read and write MS-DOS formatted 3.5″ 720K floppy disks. The VIAs above the 1770 provided additional drive selection and control. I pulled the 1770 for another project where I built a stand-alone prototype 3.5″ floppy controller board using a Motorola 68HC11 micro controller for a customer.
  • SCC2692 — A Signetics Dual Asynchronous Receiver/Transmitter, or DUART. It replaced an MOS 6551 ACIA. It came with two serial channels with on-chip ring buffers that could go up to 115 kbit/s. There were also some GPIO pins as well on the chip.
  • HM6264 — An Hitachi Memory 6264 organized as 8k x 8. I had six to start with that ran contiguously from 0x0000 to 0xBFFF.
  • DS1225 — Dallas Semiconductor 1225 non-volatile memory organized as 8k x 8. I used two to replace the Hitachis from 0x8000 to 0xBFFF. The monitor I’d written would take S-record files from the RS-232 port, convert them to binary, and store them at the starting address defined in each S-record. I used those to store my version of Commodore Basic I’d disassembled to source from the C64. Once the source was assembling to matching binary in the C64, I modified the source to call my hardware I/O routines, and was able to program my board in C64 Basic.
  • TBP28L22 — Texas Instruments TBP28L22 programmable read-only memory organized as 256 x 8. I programmed a bit pattern that would produce a single high bit dependent on the address input. It was my I/O device address decoder. The three highest bits of the 6502 was decoded with a 74F139, giving me 8, 8K regions. The 28L22 decoded all the I/O on lowest seven output bits, with the highest bit being the final address decode for the EPROM that started at 0xD000.
  • HN462532 — Hitachi HN462532 EPROM organized as 4K x 8. I originally had four but pulled one for another project. The highest 8K was the full monitor and DOS, while additional applications were in the 7K that started at 0xD000. I’d intended to program my hacked C64 Basic into that 7K area, but never got around to it.

As I wrote earlier, all of this was started back in 1982. According to what notes I still have, I stopped completely around early 1988. My C64 along with my hand-built EPROM programmer was stolen Christmas 1984 while my wife and I were living in a rental in downtown Orlando. I’d gone out of town on business and my wife drove up to see her mother in Ocala. I eventually rebuilt my 6502 programming environment around a DEC Rainbow under MS-DOS. I purchased a commercial EPROM programmer which I used for nearly a decade and now sits on a closet shelf (how I wound up with a DEC Rainbow is a story for another time).

At this point in my life I’m still building embedded systems, but instead of a 4 MHz 8-bit microprocessor I’m working with ARM, Tensilica, and RISC-V 32- and 64-bit embedded MCUs running at hundreds of MHz; instead of EPROMS all of my development boards come with megabytes of reprogrammable FLASH and megabytes of external SRAM. And instead of assembly, I’m programming them in Micro/Circuit Python, C/C++, and Rust. Each MCU comes equipped with I/O, timers, ADCs and DACs, and so much more. I’m glad for my 6502 experiences from the 1980s, but I have absolutely no desire to try and bring any of that back up again. In 1982 I’d have given my right arm to have 1/10 the capabilities I currently have with today’s low-cost boards, which run from $4 for the M0/RP2040-based boards to $10 for RISC-V-based boards, to $20 for the dual core LX7-based boards and M7-based boards.

There is no going back for me, technically nor romantically.

using powerline in bash

Look at my purty Bash prompt

With Powerline installed and working properly with vi, I looked around for how to enable it for Bash. Where-ever I looked, the directions were rather old (they all included how to set it up with Python 2, for example). Based on several entries I noted the information common to both, the use of powerline.sh. By adding the following line of Bash script to .bash_aliases, and opening a new shell, Powerline provided a decorated command prompt similar to vi’s status line.

source $HOME/.local/lib/python3.10/site-packages/powerline/bindings/bash/powerline.sh

If you’ve installed the Python portion of Powerline to your local account, instead of site-wide (and you should do that), then all you have to do to find the script file is find it:

$~ find .local -name powerline.sh

Use that with $HOME to add it to your .bash_aliases file in your home directory.

By the way, current distribution releases now provide a separate file where you can add personal shell customizations instead of mucking around in .bashrc, which has gotten so packed with default setup code for your environment that you run the risk of seriously breaking something by making an inadvertent bad edit. Putting it all in .bash_aliases also makes my customizations portable. I can copy that file and carry it with me where-ever I go within Linux-land.