The 'Full' revision below adds understanding of the rest of the interrupt vectors so that the code can be diverted when the test switch on the CPU board is pressed.  Future work will be to develop a diagnostic test program like Leon's (RIP), but with some enhancements.  It will be available for download in the section below.

Disassembler - Going the other way
One other aspect of assembly development is to be able to possible change or add enhancements to existing code.  The first step in this is to decode or reverse the process above and obtain some kind of human readable form from the original binary image.  In essense, to dis-assemble the ROM file.  After some looking it appears that DASMx is a good choice to check out as it features "code threading".  Similar to A86, it runs as a simple, small command line .exe file.

Since I was familiar with it and there were no copyright issues, I ran my 'full' version of the assembly code through it.  The first step of that is to obtain a ROM image.  The output of the A68 assembler is hex (and can directly be sent into the S4), but DASMx takes a complete binary image.  The easiest way for me to obtain that is to read back out the S4 memory.  I had previously 'erased' the S4 buffer by filling it with 0xFF, just like an erased ROM would appear.  I then created a symbol file so that the Dissassembler could annotate the results accordingly and help me interpret its output.  I then ran the program and could see that DASMx correctly interpreted all the bytes as being either instruction or operand.  An example is the "Main" loop that loops continuously.  A portion of the output is analyzed below.

This is the output from the A68 cross-compiler (assembly to opcode):


and this is the listing from the DASMx disassembler (opcode back to assembly):


Note the similarity in the opcodes and the assembly code in both listings.  The full listing files are included below.

CPU Board Test ROM - XFlash
Each of the PIAs on the Williams CPU boards have an 8-bit Port A, an 8-bit Port B, and a 4-bit Port C.  Unfortunately, Leon's PROM does not test the Port C pins, and I have always wanted to change that.  I decided to write my own test PROM as a result.  Outputs CA2 and CB2 are not difficult to test, and the new code does that by toggling them.  However CA1 and CB1 are input only.  They are tested on the board by applying a toggle to these inputs.  Once this is done, the code halts toggling of that PIA's outputs to indicate successful reading of the pulse.

On a System 11 board, there are three PIAs that have their CA1 and CB1 pins connected as inputs.  The first is U51, the second is U41, and the third is U42.  The first one inputs the coin door switches on its CA1 and CB1 pins, so toggling either of those switches will cause the LED2 on the board to stop flashing (that is demonstrated in the video below).  The other PIAs have their CA1 and CB1 ports connected to 1J21, so you can test those functions by jumpering to the appropriate pins.


The above mentioned functions of the test ROM work without using any of the RAM (since this may be faulty in the target CPU board).  As a result, I cannot make the use of subroutines as any call would require pushing return information onto the stack.  So I had to figure out how to use the CPU's own meager registers to perform tasks such as loops for delays.  One such register is the X (index) register.  This can be loaded, incremented and tested for a particular value so it makes for a good delay counter.  Another register to use possibly is the Stack Pointer register.  As for flags, it may be possible to use the Interrupt Enable flag (I) in the Status Register, although if you set it, the IRQ will fire every ~928 instructions (CPU pin 4).

Finally, just like Leon's ROM, pushing the 'test' button on the CPU board will run a RAM test.  If that fails, the program will halt and light the LED2 on the CPU board.  XFlash is available for download both in assembly and compiled hex code.  You just need to burn the code into a 27256 PROM.

Afterwards, I developed the ROM for the System 9 board and got better at assembly.  I was able to remove all the absolute jumps and made the code easier to read and more portable.  I was then able to combine the System 9 and 11 versions into one file and have a simple IF switch control the assembly process.  The source assembly file is available below.  To use the hex files, simply download the appropriate one and burn a 27128 ROM for System 9 or a 27256 ROM for System 11.

After further study, I realized that the ROM image for the System 9 would also work for a System 11 if I burned the image in both (top and bottom) halves of the 27256.  A test showed this is correct.  A single 27256 (with the 2x System 9 image) works in both System 9 and 11 boards.  Subsequently I made adjustments to allow the same ROM to run both the main as well as the sound section on both types of boards.  So this single ROM can do the work (with improvements) of the four previous versions of Leon's ROMs.