Growing up when I did, where I did, it all started with BASIC.
There was Applesoft BASIC, and the Timex-Sinclair 1000’s built-in basic, and the C64’s BASIC V2. It’s not a good language for software development, but it was well-suited to its purpose. Once I got my Project:65 computer working, I knew it needed a BASIC interpreter.
I had some options. A few months back, I was playing with a BASIC interpreter written in C for the Arduino. And of course, there’s the original Microsoft (excuse me, “Micro-Soft”) 6502 BASIC that was adapted for the Apple II and Commodore 64. There’s an interesting article at PageTable that describes the history and versions of that interpreter.
I decided to use Lee Davison’s Enhanced 6502 Basic (EhBASIC) for my project, since that way I’d be starting with complete and commented source code, instead of an annotated disassembly of the Microsoft version.
EhBASIC is designed to be portable between 6502 systems, so its hardware requirements are minimal. It’s also well-suited for a serial port connection like I’m using, instead of a full-blown screen editor. For the time being, I’m ignoring the complexities of LOADing and SAVEing programs, so all I really had to do was fill in my routines to read and write characters. Conveniently, those were the same routines I’d used last week to get XMODEM working – I just had to plug them in.
The biggest adjustments I had to make were because EhBASIC expects to live in ROM – really, it kind of expects to be the ROM, and to serve as the computer’s entire user interface and operating system, just like the built-in BASICs of the early microcomputers. That arrangement wasn’t quite going to work for me, since I’ve been using an 8 KB EEPROM, and EhBASIC is about 11 KB. I’m going to be switching over to a 16 KB EEPROM eventually, but for now I decided I wanted to load my BASIC interpreter into memory and run it like any other program.
This required a few adjustments. Obviously, I needed to change the start address EhBASIC uses so that it would load into the top 11 KB of my 32 KB RAM, which was easy enough. I also had to tell it what memory space it could use for storing programs and variables. My minimal ROM-based “OS” uses parts of page two (starting at $0200) for its own variables, so I set EhBASIC’s RAM_Base variable to $0300. EhBASIC also has a RAM_Top, which I set to $5700 – just below where EhBASIC’s own code begins.
My OS and EhBASIC both use some locations in page zero, but conveniently there weren’t any overlaps to worry about.
I made a few more changes to EhBASIC’s initialization code, but it was mostly a matter of removing things that the OS takes care of, such as setting up the IO system and interrupt vectors. That last part is easy because Project:65 still doesn’t have any interrupt sources hooked up – something I’ll eventually have to address.
After adjusting EhBASIC’s source, I still had to figure out how to build it. Here’s where I decided to challenge myself a little. I’d been using CBM Prg Studio as my assembler for a while, but after running into a few problems I figured it was time to try something else.
I decided to give cc65 a try. Cc65 is actually a complete C cross-compiler for a variety of 6502 systems, which I figured would be interesting to experiment with, but to start I just wanted to try out its assembler, ca65.
There’s not a lot of standardization in 6502 assemblers, so I had to make a few more changes to my EhBASIC source code. For example, labels in ca65 end with colons, and the directives for declaring inline data are a little different from what I’d been using – “.byte” instead of “byte”, for example. A little search and replace – and a little manual cleanup – and I was just about ready.
Since ca65 is part of an entire compiler chain, its ideas about how to handle code and linking are a little more complex than CBM Prg Studio’s. It actually has a separate linker, and much more sophisticated control over how programs are laid out in memory. For now, I’m bypassing a lot of that and just forcing EhBASIC to be assembled with a fixed memory layout, but I think that’ll become really interesting down the road.
Getting ca65 to build the EhBASIC source code was pretty simple, with one really noticeable glitch. It seems that ca65 uses Commodore machines as its default architecture, and that specifically means that it treats all character data as Commodore “PETSCII” instead of regular ASCII. The first time I tried to run the interpreter I got some interesting garbage on the screen – but I’ve got enough familiarity with PETSCII to immediately guess what was going on. Adding “-t none” to the command line fixed that, and before long I was staring at the familiar “Ready” prompt.
Finally, I needed some BASIC programs to run. A classic source is the book “BASIC Computer Games”, edited by David Ahl. I picked a few old favorites like “Hamurabi” and “Life”, and typed them in. (Yes, I know I didn’t have to type them in myself, but it adds authenticity to the experience). To get the programs into the Project:65 computer, I simply copied and pasted them into Tera Term’s buffer.
Well… almost. I’ve been running at 9600 baud, and at that speed the terminal can send data much faster than the BASIC interpreter can process it. One of Tera Term’s useful features is that you can add delays between characters and lines, just for this kind of purpose. 1 ms per character and 20 ms at the end of every line was enough (probably much more than enough) to do the trick.
There were a few minor incompatabilities between these programs and EhBASIC. For example, I had to change all occurrences of “RND(1)” to “RND(0)”, and I had some issues with tab positioning in Life that I had to tweek. Before long, though, I had the games running and I was happily running my Sumerian kingdom into the ground.