What's All This Brouhaha?

Since I’m basically done with my original project, the rewrite of the Apple 1 monitor for the MC6800, I’m now spending my copious free time working on HP-41 stuff. I’m trying to hack together an expansion ROM that will support access to an SD card. Initially I just want to have the equivalent of the HP-IL module DIR, WRTP, and READP functions. I’ll assign it XROM 28 with the full function list of the HP-IL module, but all of the other functions will give a “NONEXISTENT” error, until eventually I get around to implementing more of them.

I haven’t decided whether to finish my assembler written in Python, or use nutstudio.

So far I’ve studied the VASM listings of the HP-IL module’s cassette and control ROM to learn how the DIR, WRTP, and READP functions work.

I doubt that I’ll have this done by the end of this RetroChallenge, but at least I’m making some progress.

A short (1:45) video demo showing my rewrite of the Apple 1 monitor for the MC6800 microprocessor, running on a modified MESS simulator:

http://www.youtube.com/watch?v=Nh7qqymZeiQ

I hope to have in the near future a video of the rewritten monitor running on an Apple 1 replica, such as Mike Willegal’s Mimeo 1.

I wrote a trivial 6800 program to test my rewritten monitor. It just outputs the character set to the display continuously.

        org  $0300
test:   ldaa #$a0
loop:   jsr  echo
        inca
        cmpa #$e0
        bne  loop
        bra  test

Enter it with this command:

300:86 A0 BD FF B4 4C 81 E0 26 F8 20 F4

Verify it with this command:

300.30B

And run it with this command:

300R

After further debugging, my monitor for the Apple 1 with MC6800 microprocessor now works, at least on the MESS simulator. I’ve used it to examine and modify memory, and to run a small test program in RAM.

The monitor still needs to be tested on real hardware, but now I have high confidence that it will work. The monitor is exactly 256 bytes long, the maximum that will fit in the two 256×4 bipolar PROMs used in the Apple 1.

I tried to record video of the session with MESS’ built in avi capture feature. I get an avi file that is hundreds of megabytes, and I haven’t been successful at transcoding it. The worse problem, though, is that the video is rotated horizontally, so that what should be at the left edge of the video is actually almost at the very right edge, and wraps around.

I guess I’ll have to use a camcorder to capture a session.

The assembly source code is here, and the assembly listing is here.

I fixed some bugs in both my splitroms.py utility and my MAME patch. Now I’ve got my MC6800 monitor for the Apple 1 actually running well enough to enter command lines, though it doesn’t execute them properly. It does automatically cancel the command if you enter 128 characters, just like the 6502 monitor.

The Apple 1 uses four-bit-wide bipolar PROMs, so MESS uses ROM image files containing only the low nibble or only the high nibble of the code, stored one nibble per file byte.  I’ve written a splitroms.py Python script to take normal raw binary object files, eight bits per byte as one would get as output from an assembler, and split them into nibble files suitable for MESS.  The script also outputs the ROM_LOAD_NIB_xxx macros for use in the MESS driver source file.

I’ve got a patch to MESS to add simulation of an Apple 1 with an MC6800 processor:  http://pastebin.com/tN3DXX7u

The system name is “apple1_mc6800″. The ROM is not included in that patch, and the ROM names, CRCs, and SHA1SUMs are not correct.

Once I’ve got my ROM debugged, I’ll push the patch upstream to the MESS developers.

I’ve got the Apple 1 monitor for the MC6800 processor nearly completely written, but haven’t done any testing yet.  I haven’t posted more to the blog because there hasn’t been much interesting to say.

At this point it looks like I have a few bytes to spare, which is good because there will likely be bugs that take a few bytes to fix.

The tricky decisions have almost all been concerned with what pointer to keep in the X (index) register at any given point in the code, vs. what pointers to keep in zero page. Using X has the advantage that increment is a single byte instruction, while incrementing a pointer in zero page takes five bytes if you don’t mind destroying the contents of X, or six bytes if X must be preserved.

An interesting “feature” of the Apple 1 monitor is that it does not initialize the stack pointer. In the MOS Technology MCS6502 microprocessor, the most significant eight bits of the stack pointer are hardwired to $01. That means that the stack is constrained to a maximum of 256 bytes, in the address range $0100 to $01FF (page $01). If the stack pointer has the value $0100, and a byte is pushed onto the stack, the stack pointer will wrap to $01FF.  Similarly, if the stack pointer is $01FF, and a byte is popped from the stack, the stack pointer will wrap to $0100.

It is normal practice to initialize the stack pointer very early in system initialization.  However, if you do not plan to use any of the memory in page $01 for anything other than the stack, in principle it does not matter what the starting value of the stack pointer is, and thus it is not necessary to initialize it. The Apple 1 monitor saves a few bytes of ROM space by omitting the stack pointer initialization. Since there are only 256 bytes of ROM, this is a non-trivial savings.

For my port of the Apple 1 monitor to the Motorola MC6800 microprocessor, I will have to explicitly initialize the stack pointer. Since the MC6800 has a full 16-bit stack pointer, leaving it uninitialized could result in attempting to use ROM or nonexistent memory for the stack, neither of which would actually work. It is also possible that the stack would be in RAM, but pointing to locations that are being used for other purposes.

The most obvious way to initialize the stack pointer of the MC6800 is to use the LDS instruction (“LoaD Stack pointer”) with the immediate addressing mode. This is a three byte instruction, of which the second and third bytes are the value to be loaded.

It would be nice to come up with a way to initialize the stack pointer without using three bytes of code. It is my intention to have the MC6800 version of the monitor use a memory map nearly identical to the original MCS6502 version, where $0100 to $01FF is the stack, and $0200 to $027F is the line input buffer. Intuitively it seems like there should be some way to take advantage of the fact that the stack and line input buffer addresses are immediately adjacent, and initialize both the stack pointer and the line input buffer pointer at the same time, using the one-byte TXS instruction to copy the value into the stack pointer. Unfortunately I have yet to find a practical way to do this that actually reduces the overall byte count.

My Retrochallenge 2011 project is to rewrite the Apple 1 monitor for use on the Motorola MC6800 microprocessor.  Steve Wozniak primarily intended the Apple 1 to use the MOS Technology MCS6502 microprocessor, also used in the later Apple II and Apple III, but he designed the Apple 1 board to alternatively accommodate a Motorola MC6800 microprocessor, or the pin-compatible MCS6501. The MC6800 and MCS6501 have a similar bus structure to the MCS6502, but need external clock drivers. There is no evidence that anyone has ever actually used an MC6800 in either a real Apple 1 or a replica.

Continue reading →