Hugo Winner Book Review: Stand on Zanzibar by John Brunner

I really want to like this book, but at 72 pages in I had to set it aside.

It reads more like a series of short scenes, rather than a novel, with little connection between them. While the author makes some rather interesting and accurate predictions about life in the future, I couldn't really find a plot or characters that I cared about.

At a little over 10% of the way through the novel's 650 pages, I called it quits for now, the first time I've done this for any Hugo award-winning novel. I will make another attempt to complete it at a later date.

Setting it aside, I picked up a copy of Heinlein's The Puppet Masters, was hooked within the first few pages, and finished it in a few days. Not a Hugo award winner, it is one of his better novels, avoiding most of the preaching or attempt to shock of some of his books.

Next up, I am reading Small Fry, a memoir by Lisa Brennan-Jobs, daughter of Steve Jobs. It is an easy and enjoyable read and provides insight into Steve Jobs from a slightly different perspective than some other books written about him.

A 6809 Single Board Computer: Instruction Trace/Step Function

In my JMON monitor for the 6502, I implemented a trace or step function where you can execute code one instruction at a time and see the results of execution on the CPU registers. This is very useful for debugging, particularly as this implementation supports stepping through ROM code, something that can't be done with breakpoints.

For my 6809 single board computer I wondered if I could do the same for the 6809 processor. After some thought, it looked feasible, although more challenging as the 6809 has a larger and more complex instruction set than the 6502.

The basic idea is to take the instruction to be executed and store it in a buffer in RAM. The values of all CPU registers from the previous instruction trace are restored and the instruction is executed. A jump instruction is placed right after the traced instruction that goes back to the trace program. After execution, the new register values can be displayed and saved. This allows running code that is in ROM, as it gets copied to RAM when executed.

To implement this requires knowing the length of each instruction, as they can vary on the 6809 from one to five bytes depending on the instruction and addressing mode. From my previously written disassembler I already had code that could determine the instruction length and even disassemble it.

A wrinkle in this approach is handling instructions which cause a change in the flow of execution, such as a JMP (jump) instruction which would not return if simply executed in the buffer. We need to handle this instruction as a special case. We can examine the destination address and update the saved program counter accordingly. We don't need to actually execute it since it changes no other registers than the PC. We do need to check for and handle both direct (8 bit) and extended (16-bit) jump instructions. For direct, the destination address needs to be calculated by combining the instruction operand with the current value of the direct page (DP) register.

Jump to subroutine (JSR) in another special case. Here we need to push the return address on the stack (using the saved value of the stack pointer that we trace with) and then calculate the new PC value.

Similarly, we can handle BRA/LBRA and BSR/LBSR like JMP and JSR but the effective address needs to be calculated by adding the offset to the current PC value. Again we don't need to execute the instruction, just update the new PC value.

The interrupt related instructions SYNC, CWAI, SWI, SWI2, and SWI3 can all be simulated by pushing registers on the stack and setting the PC to the appropriate interrupt vector.

RTS and RTI are simulated by pulling registers (in the case of RTI) or just the PC (for RTS) off the stack. One wrinkle is that in the 6809 we need to check the E (Entire) flag in the condition code register to know of we should restore all registers from the stack.

Conditional branches are a little more tricky. They can transfer control to two different places depending on whether the condition is true or not. These are handled by writing into the execution buffer both the instruction being traced as well as different jumps depending on whether the branch is taken or not. The branch destinations can update the PC accordingly. The code in the buffer looks like below:

XXXX XX 03           Bxx $03 (Taken)         ; Instruction being traced
XXXX 7E XX XX        JMP BranchNotTaken
XXXX 7E XX XX Taken  JMP BranchTaken

We execute the instruction in the buffer and let it perform the test. We need to handle all the possible branch instructions, both short and long versions.

TFR (transfer) and EXG (exchange) instructions are okay to run except the cases where the source or destination is the PC. We need to handle those cases manually since it would otherwise change the flow of control.

Similarly, PSHS/PHSU and PULS/PULU could potentially include the PC in the list of registers pushed or pulled. Currently I just check for this case, remove the PC from the list of registers, and warn the user in this case that it is not fully handled yet.

Indexed addressing poses a challenge: we need to handle an instruction that changes flow of control like JMP 1,X with an arbitrary index addressing mode. It might also produce side effects in the case of instructions like JMP 1,X++. These are handled using a trick: instead of JMP, we run a LEAU instruction with the same indexed operand. Then we examine value of U, which should be the new PC. Currently the code can't handle addressing modes that change the U register like JMP ,U++.

A final challenge is PCR relative index addressing. If we move the instruction to the buffer to execute it, the PC relative address is now wrong. I thought about this, and it should be possible to adjust the offset based on the difference between the original instruction location and the address of the buffer where it will be run. This would get a little complicated, so I didn't implement it (yet). For now I just ignore it and display a message at run time that it is not supported.

After working out most of the logic as pseudocode, I implemented and debugged it. I started with the basic instructions and then added all of the special cases, testing them one at a time. Once done, I tested it with some smaller complete programs.

Finally, I was able to integrate it into the "combined" ROM which also contains the ASSIST09 monitor, disassembler, and Microsoft Basic. I added the trace command as a new ASSIST09 "T" command. It took some shuffling but I was able to just get them all to fit in the 8K ROM.

It hasn't been tested exhaustively, and it can't run BASIC because it uses some PC relative instructions, but it seems to work quite well. Here is some sample output:

>T D000
D000  81 30        CMPA  #$30 
PC=D002 A=FF B=FF X=FFFF Y=FFFF S=FFDF U=FFFF DP=FF CC=11111000 (EFHINZVC)
PRESS TO CONTINUE, TO QUIT  
D002  25 04        BCS   $D008 
PC=D004 A=FF B=FF X=FFFF Y=FFFF S=FFDF U=FFFF DP=FF CC=11111000 (EFHINZVC)
PRESS TO CONTINUE, TO QUIT  
D004  81 3C        CMPA  #$3C 
PC=D006 A=FF B=FF X=FFFF Y=FFFF S=FFDF U=FFFF DP=FF CC=11111000 (EFHINZVC)
PRESS TO CONTINUE, TO QUIT  
D006  25 C0        BCS   $CFC8 
PC=D008 A=FF B=FF X=FFFF Y=FFFF S=FFDF U=FFFF DP=FF CC=11111000 (EFHINZVC)
PRESS TO CONTINUE, TO QUIT  
D008  30 1F        LEAX  $1F ,X
PC=D00A A=FF B=FF X=FFFE Y=FFFF S=FFDF U=FFFF DP=FF CC=11111000 (EFHINZVC)
PRESS TO CONTINUE, TO QUIT  
D00A  34 50        PSHS  U,X
PC=D00C A=FF B=FF X=FFFE Y=FFFF S=FFDB U=FFFF DP=FF CC=11111000 (EFHINZVC)
PRESS TO CONTINUE, TO QUIT  
D00C  0F 41        CLR   $41 
PC=D00E A=FF B=FF X=FFFE Y=FFFF S=FFDB U=FFFF DP=FF CC=11111000 (EFHINZVC)
PRESS TO CONTINUE, TO QUIT  
D00E  CE C0 E7     LDU   #$C0E7 
PC=D011 A=FF B=FF X=FFFE Y=FFFF S=FFDB U=C0E7 DP=FF CC=01111110 (EFHINZVC)
PRESS TO CONTINUE, TO QUIT  
D011  0F 42        CLR   $42 
PC=D013 A=FF B=FF X=FFFE Y=FFFF S=FFDB U=C0E7 DP=FF CC=01111110 (EFHINZVC)
PRESS TO CONTINUE, TO QUIT  
D013  33 4A        LEAU  $0A ,U
PC=D015 A=FF B=FF X=FFFE Y=FFFF S=FFDB U=C0F1 DP=FF CC=01011001 (EFHINZVC)
PRESS TO CONTINUE, TO QUIT 

References

1. https://github.com/jefftranter/6809/tree/master/sbc/trace
2. https://github.com/jefftranter/6809/tree/master/sbc/combined
3. https://github.com/jefftranter/6809/tree/master/sbc/disasm
4. https://github.com/jefftranter/6502/tree/master/asm/jmon

A 6809 Single Board Computer: The MC6839 Floating Point ROM

Implementing floating point math was a challenge with 8-bit microprocessors. The early version of BASIC for the 6502-based Apple 1 and Apple 2 series written by Steve Wozniak only supported 16-bit integer variables in order to keep the size down and achieve acceptable performance. Later, Applesoft BASIC was licensed from Microsoft which supported floating point variables. A significant amount of the code for Microsoft BASIC for 8-bit microprocessors was dedicated to floating point math. Some versions, loaded from tape, gave the user the option to leave out the sin/cos/tan trig functions to save space and free up some memory.

The 6809 supports instructions for 8-bit addition, subtraction, and division and some 16-bit math instructions. While more powerful than earlier processors like the 6502 and 6800, implementing floating point math was still a significant undertaking. Motorola saw an opportunity to offer a floating point math library as a standard product for the 6809. This was made more viable for two reasons:

• An IEEE standard for floating point math formats appeared to be poised to become an industry standard.
• The 6809 allowed writing position independent code, so a floating point library could be offered in binary form that would be independent of the memory map of the system it needed to run on.

Out of this came a product: the MC6839 Floating Point ROM. While essentially a software product, it was sold as hardware: an 8K ROM programmed with the floating point code. As well as the ROM, it included a programming manual almost 100 pages in length, describing how to use it.

The basic features of the library were:

• An 8KB ROM which would run at any contiguous range of addresses.
• All RAM used was relative to the stack pointer.
• A well documented API that allowed operands to be passed in registers or via the stack.
• Fully implemented the IEEE Standard for floating point math (at the time, still in draft form).
• Support for the following operations: add, subtract, multiply, divide, remainder, square root, integer part, absolute value, negate, condition code compares, conversion between integer and floating point, and conversion between binary floating point and BCD.
• Supported three precisions (4, 8, and 10 bytes) defined by the IEEE standard.
• Supported the rounding modes, closure modes, and normalize modes defined by the standard.
• Supported handling of exceptions (e.g. division by zero).

According to the source code it was written around 1980, with revisions up to at least 1982. The author names in the source code were Greg Stevens, Joel Boney, and G. Walker. In 1988 the source code was put in the public domain by Motorola, and can be found on the Internet as well as the binary for the ROM.

I came across the code and decided to try it out on my 6809 single board computer. There is a programming example in the manual that finds the roots to quadratic equations of the form ax^2 + bx +c = 0 using the classic formula -b +/- sqrt(b^2 - 4ac) / 2a

I typed in the example and adapted it to the lwasm assembler. The program uses a standard set of macro instructions to set up the parameters in the correct calling sequences for the ROM. These macros make the code much more readable and were easily ported to the lwasm assembler. I needed to make a few changes in order to make the example a complete runnable program. When run, and with the S record file for the MC6839 ROM also loaded into memory, I was able to get the example to run and produce the correct results. The code is on my github account.

Since I had the source, I took a look at whether I could assemble it. It would take some effort because the original source required a special Motorola "structured assembler" that I have not been able t find any information about. It has a number of structured programming macros for things like looping and conditionals. Given some time this could be reversed engineering by looking at the binary file.

I also found that the source does not quite match the binary (the former has a 1980 copyright date and the latter 1982). Without having a known good binary that corresponds to the source code, porting would be a challenge, so I set any further work on this aside for now.

The MC6839 Floating Point ROM was Motorola's first foray into this type of binary ROM product. The data sheet lists the product as "preliminary" and according to one source it was never actually offered as a product.

Later processors, like the 68000 series, would support floating point math in hardware using either a separate dedicated chip or on-board floating point unit (FPU). These still use (as do modern computers, including your smart phone) the IEEE standard for floating point math.

References

1. https://github.com/jefftranter/6809/tree/master/sbc/mc6839
2. http://github.com/brouhaha/fp09
3. http://www.colorcomputerarchive.com/updates/2017
4. http://www.classiccmp.org/pipermail/cctalk/2017-March/033678.html
5. http://www.classiccmp.org/pipermail/cctech/2016-June/019519.html
6. http://www.colorcomputerarchive.com/coco/Documents/Manuals/Hardware/MC6839%20Floating-point%20ROM%20Manual.pdf