Building Visual 1050 ROMs from Source

Building the Z80 ROM

You can build the Z80 ROM using standard the standard CP/M assembler ASM. You can either do this in MESS with the v1050 emulator, or if you want more speed you can use something like z80pack which also has the nice feature of having virtual hard disks for space to handle generated symbol, list, etc. files.

One important note, the ZBOOT.ASM code I have and the PORTS.LIB from the 1.1 BIOS are not in synch. There is one minor change that needs to be made to compile:

ZBOOT.ASM references the equates VID$VERT$INT (0xA0) and VID$DISP$INT (0xB0). In the 1.1 PORTS.LIB these are defined as vert$clear and clear$6502. Here is an edited version of ZBOOT.ASM that will build with the 1.1 PORTS.LIB.

CP/M ASM will generate an Intel HEX file as output. You cannot use HEXCOM to convert this to binary since it expects a load address of 0x0100 (start of TPA for COM command files) you really need something like HEXBIN to generate a raw binary starting at 0x0000.

I had a difficult time finding a tool that would properly convert to the ASM-generated HEX to binary under Linux. Most tools I tried failed. I ended up using a small utility written by John Elliott called 'LOAD' compiled with gcc for this task. Note that I needed to delete out the extraneous ^Z (standard CP/M End-of-File mark) that pad out the CP/M 128-byte records (these remain when copying files off CP/M images using cpmcp) since I was not actually running LOAD under CP/M

cat zboot.hex | ./load zboot.bin
This should result in an 8K binary image. There is a 1 byte difference from the ROM dump used in MESS: which is at 0x1FFF. This is the checksum value. The ROM dump has this value as 0xEB vs. the generated 0x00.
0x1fff	  DB 00H  ; <<< CHECK SUM VALUE >>>

00001ff0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001ff0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 eb  |................|

Building the 6502 ROM

I am not sure what tools were used to originally build the 6502 ROM source. A possibility was the version of the Microsoft MACRO-80 assembler that had 6502 code generation support, but the version I found could not assemble clean. From some documents I found, the format of DBOOT.ASM sounded close to what was described for Atari Macro Assembler (AMAC) released by Atari Program Exchange (APX). Unfortunately I could not find a copy of this assembler to try.

UPDATE 2012-Oct-06: In a thread on the comp.os.cpm newsgroup entitled 6502 ROM Assembly under CP/M, Emmanuel Roche claims success using XASM65 from Avocet Systems, Inc. to compile this code under CP/M.

I wound up porting the DBOOT.ASM code to the popular dasm assembler and cross-assembling on linux. The ported code is here.

I chose DASM format '3' because generated a blob from which it was easy to extract the 8K of ROM. One issue this caused was a "reverse-index" error caused by padding in the source code to overrun addresses for subsequent ORG specifications. DASM format '2' would allow this but I chose to remain with '3' and to instead comment out some of the pad bytes in the source file.

One other issue I ran into was that at some point the editor I was using did some sort of tab/space conversion so I was surprised at how many difference I hit when I compared my first generated ROM to the MESS ROM. Something to watch for.

As with the Z80 ROM the resulting 8K binary image had a 1 byte difference from the ROM dump used in MESS: which is at 0x16A0. This is again a checksum value (HASHTOT, which does not seem to actually be referenced by the source). The ROM dump has this value as 0x62 vs. the generated 0x00.

f6a0	       00		      DC.B	$00	;THIS IS WHERE THE HASH TOTAL WILL GO

000016a0  00 a2 20 ca a9 00 95 00  8a d0 f8 a2 20 ca b5 00  |.. ......... ...|
000016a0  62 a2 20 ca a9 00 95 00  8a d0 f8 a2 20 ca b5 00  |b. ......... ...|

Note that the discrepancy between 0xF6A0 and 0x16A0 is due to the byte compare dump occuring on the extracted 8K ROM image.

Here is a small script I used to assemble the code and extract the appropriate 8K for the ROM:

# -f3 specified to output as 'raw' format
dasm DBOOTNEW.ASM -f3 -odboot.64k -ldboot.lst -sdboot.sym

# DASM outputs a 64K (minus 32 bytes due to ORG $20) image, 
# we need to cut out the upper 8K for the EPROM.  The rest 
# is throwaway.
dd if=dboot.64k of=dboot.bin ibs=32 skip=1791