I showed off BMOW to an old college friend the other day. He and I did all the digitial electronics labs together at MIT, where I learned what little I know about how to build a computer. Sadly, he seemed to think I was a little insane for all the energy I’ve put into this project, but I have to admit my demo was a little underwhelming. It didn’t help that MSBASIC crashed when I tried to show it off.

Yes, the random crash bug with string manipulation came back. Again. I’d earlier thought it was 100% present with one version of the code, and 100% absent with another, but it started happening intermittently with the “good” version of the MSBASIC code. Six months ago I would have set up the logic analyzer again, and gone digging for the source of the bug, but I couldn’t bring myself to do it this time. My previous investigations had suggested that memory at $149F was getting overwritten or misread somehow, so I made a very quick and ugly “fix” to the MSBASIC code to avoid that location altogether. In fact, I relocated the whole program image to begin at $1500, wasting about 5K of RAM. That seems to have resolved the problem, but it’s a pretty ugly fix. This bug will almost certainly come back to bite me again later, under other circumstances and at a different memory location.

It’s been a month since my last update, but BMOW and I are back from the dead, and better than ever. I even have some progress to report with MSBASIC! That’s pretty crazy when you consider that BMOW and I both underwent surgery in the past month. No photos of mine, but here’s BMOW on the operating table:

My month started with a health scare: out of nowhere one morning, I was hit with extremely intense abdominal pain, and was totally incapacitated. Called 911, took an ambulance to the hospital, and had surgery to remove a 6mm kidney stone. Afterwords I had a stent put in for a week, which was nearly as miserable as the stone. I’m happy to say I’m back to normal now. Overall I rate the whole experience zero stars, would not recommend.

Right on the heels of that, I had a big project milestone at work, which I won’t bore you with. Suffice it to say it occupied a lot of time. And right in the midst of that, I somehow decided it would be a good idea to replace my PC. Being the hacker sort, I of course built a custom PC from assorted new and used parts, which created all kinds of interesting problems. I had the guts of three different PCs scattered across the floor for a week. In the end I got the new PC up and running, with all the important BMOW data moved over (I hope).

Fast forward to today, when I finally decided to put BMOW back together, and take another look at this mysterious bug with MSBASIC. I described the issue in my previous entry– BASIC seemed to work fine with control flow and numeric computation, but it would lock up any time a string literal or variable was used. I couldn’t even print “HELLO WORLD”. I traced the problem to a mystery overwrite (or failed read) of a specific address in the MSBASIC code dealing with strings, which I was 99% certain was due to a hardware problem of some kind.

There were several issues getting the new PC talking to BMOW again today. I had hastily copied over all the MSBASIC source files from the old PC, which included some experimental modifications I had made to try to track the string bug. It took some digging around to determine how it had all been originally, and restore the code to its earlier state. Then some compiler settings appeared to have gotten lost in the translation, and it took more fiddling just to rebuild a new MSBASIC program image successfully. Then there was more COM port weirdness with the FTDI USB serial driver I’m using to connect to BMOW. Fun.

Finally I got it all going again, launched MSBASIC, and did some string-related operations to begin narrowing down the problem further. But I’ll be damned if it didn’t just work! I was really skeptical at first, so I exercised it for quite a while, rebooted, and cold started, but nothing I could do would shake it. I don’t know why, but maybe some of the steps I went through to get the software working on my new PC affected things somehow. That’s a pretty flimsy theory, but I can’t chase a bug that’s not there anymore.

So there you have it: a working MSBASIC running on BMOW. Is the bug going to come back again as soon as I breathe on it wrong? Quite possibly, but like I said, there’s nothing more I can do about it if I can’t even see the bug.

Onward to better things, then. There are still a couple of minor issues with my port of MSBASIC that I’d like to resolve. The biggest is that my keyboard driver doesn’t support the caps lock key, so I have to hold down the shift key while typing all keywords. FOR is not the same as for, according to MSBASIC. There are also some display formatting issues. You can see in the photo above that the visitor number has two spaces before and after it, for reasons unknown.

Beyond that, I think it’s time to start wrapping up BMOW. It’s come a long way in a year plus, and it’s been pretty amazing, but I’m feeling the pull of other projects and passtimes that I’d like to work on too. Before I send BMOW off for a well-deserved retirement, though, I want to build a decent case to hold everything, and protect it from accidental smashing. It’s been sitting bare on my desk for a year, and it’s a miracle that some kid, cat, or flying object hasn’t demolished it already. Just look at this thing:

I’ve got a case, I’ve got the tools, all I need is a little time and motivation to put it all together.

For bonus points, I’d still like to add some simple audio output, and maybe persistent storage using battery backed RAM, but I won’t cry if those never come to pass. As I tell my kids, we’ll see. I can’t say exactly how the next few months will turn out for BMOW, but I’m sure they’ll be interesting ones.

A picture tells the story here:

It’s BASIC! And not just any BASIC– it’s the venerable Microsoft BASIC that I remember fondly from the Apple II, Commodore 64, and other machines of that era. The version shown here is a plain-vanilla build that makes no assumptions about memory size or terminal capabilities. I think it was originally used on the KIM-1 computer.

BASIC took longer than I’d expected to get working, and in fact it still doesn’t work correctly. Any reference to a string variable or a PRINT statement with a string literal will lock up the computer. It works in the simulator, though, and I had it print “HELLO STEVE” infinitely on the real hardware earlier, but then I tweaked a few things and broke it somehow. Hopefully it won’t be too difficult to fix.

The main obstacle to getting MS BASIC running correctly on BMOW was the imperfect emulation of the 6502 instruction set. As I’d mentioned earlier, I never implemented some 6502 instructions, and others I implemented slightly differently than the 6502. I had to write microcode to implement several dozen 6502 instructions that BMOW was missing, which were mostly the ones that used page zero addressing. I also had to harmonize which condition codes are modified by each instruction. That was a slow and tedious process that would have been impossible without the BMOW simulator.

Another source of problems was BMOW’s stack. The 6502 has a 256 byte stack at $0100 in memory. Since it’s only 256 bytes, the stack pointer register is just 8 bits. BMOW has a 24-bit stack pointer that can point anywhere in the 16MB address range. Most of the explicit references to stack memory in the MS BASIC code used a STACK symbolic name, which was easy to change. But there were also some hidden assumptions about the stack location in the address arithmetic of parts of the code. Again, finding those would have been impossible without the simulator.

Of course I had to implement BMOW-specific I/O routines for text. I still don’t have CTRL-C working. And LOAD and SAVE don’t do anything, since there’s no storage medium from which to load or save.

The final challenge was working with two different assemblers. Up until now, all of the assembly code I’ve written has been assembled with an assembler called ACME. I’ve made lots of changes to ACME so that it supports all the instructions and addressing modes that are unique to BMOW. The MS BASIC code I used was written for the ca65 assembler, however. That meant I couldn’t use any BMOW-specific instructions or addressing without resorting to hand-assembled bytes included into the source code. It also meant that I couldn’t easily incorporate my existing keyboard, video, and console libraries into MS BASIC. My eventual solution was assemble the BMOW libraries with ACME, and include them as binary data in the ca65 source files. That worked, but it meant none of the labels or constants defined in the ACME source can be referenced from the ca65 source, which is a pain in the butt.

If I get the problems with strings sorted out, and generic BASIC programs running OK, then I’ll probably look at adding some BMOW-specific keyboard to BASIC for drawing graphics and things.

Yesterday was the 1 year anniversary of the first BMOW journal entry, which described the CPU architecture design that I’d worked out on paper. The planning phase grew from there, and lasted several months. The first wires in what would become BMOW weren’t connected until March 9, but it was only a month more past then until the first successful run of a fibonacci program on the hardware. I guess planning pays off!

I’ve started looking at getting BASIC working on the machine. At first I thought I might need to reverse engineer an existing 8-bit BASIC from the ROM image, or write my own, but then I found something much better. These guys have reverse-engineered 7 different versions of Microsoft BASIC, creating a set of well-documented 6502 assembly source files. It’s probably nearly as good as the original source was, and you can conditionally compile Applesoft, Commodore, and other BASIC variants.

I’ve been working on this for 4 days now, and it’s going fairly well. Early on, I found that quite of few of BMOW’s instructions that are supposed to act like 6502’s aren’t quite accurate in the way they update the condition codes. Some 6502 instructions update only the negative and zero flags, others updates those plus the carry and overflow flags, and still others update additional combinations of flags. In contrast, most BMOW instructions either updated all the flags, or none. Fixing the behavior to match the 6502 required a lot of new microcode and a couple of wiring changes.

There are also quite a few 6502 instructions that I just never bothered to implement in BMOW, because I didn’t find them useful. Microsoft BASIC uses practically every possible instruction, though, so I’ve been madly implementing new instructions in microcode, updating the assembler and simulator to match.

I think it’s actually getting close to working. Running in the simulator, BASIC detects how much RAM I have, prints a copyright message, and dumps me to the BASIC prompt. But if I type something like “10 PRINT ‘Steve’ “, it spews an error that’s every possible BASIC error message concatenated together. The line that reports the number of bytes free also shows it as something like “19019.1901 bytes free”. Strangely, it actually converts the byte count to a floating point number, then calls the floating point print routine, and something’s clearly going wrong inside there. I haven’t actually tried running on the real hardware yet, but if I can get the major issues sorted out in the simulator, it should go pretty smoothly.

Microchess for BMOW is now a full-fledged graphical program, instead of a text-mode program using ASCII art for the board. It was pretty easy to do, fortunately. I wrote a stand-alone routine to draw the board graphics using the existing Microchess board state in memory, and replaced the ASCII art code with a call to my new routine. It uses BMOW’s mixed-video mode capabilities, with a 208×208 board using 16 colors, a 4-line scrolling text area for move entry, and an empty 48×208 area to the right of the board. Maybe this area could be used to show a running list of moves?