No comment

I'm still waiting on the USB to serial adapter for testing the 68hc11 BASIC.  I should have ordered from Newegg instead of ebay.  But that leaves more time to work on the VZ ROM disassembly.

The goal is to mostly to fully commented VZ ROM disassembly, but up until now I have only thrown in a few comments for things like RST calls. 

Below is a little sample of what the disassembly looks like once commends are added.
All function names and comments were added by sed.  The comments were extracted from the OCR text of a book for the TRS-80.   The formatting could use some work, but it's significant progress.  This will result in a fully commented disassembly but with actual labels for system functions and variables that were never in any books.  VZ specific code will still need comments, but this will take care of a significant portion of the ROM. 

This has involved a lot of data entry, and editing, but the speed at which changes can be made and applied to the entire file is well worth the effort.  I should also be able to generate disassemblies of other Z80 machines using Microsoft BASIC much faster if they share system variables and code.  The TRS-80 itself should be trivial other than fixing the ROM entry points for the disassembler and moving system variables.

07C3: 21 25 79                   L07C3: LD      HL,SIGN        ;--- Reset sign flag so that ************ see note--> *
07C6: 7E                                LD      A,(HL)        ;--- mantissa will have a negative sign
07C7: 2F                                CPL        ;--- Invert the sign flag
07C8: 77                                LD      (HL),A        ;--- Store sign flag
07C9: AF                                XOR     A        ;--- Zero A
07CA: 6F                                LD      L,A        ;--- then save it
07CB: 90                                SUB     B        ;--- Complement B (0 - B)
07CC: 47                                LD      B,A        ;--- Save new value of B
07CD: 7D                                LD      A,L        ;--- Reload zero into A
07CE: 9B                                SBC     A,E        ;--- Complement E (0 - E)
07CF: 5F                                LD      E,A        ;--- Save new value for E
07D0: 7D                                LD      A,L        ;--- Reload A with zero
07D1: 9A                                SBC     A,D        ;--- Complement D (0 - D)
07D2: 57                                LD      D,A        ;--- Save new D value
07D3: 7D                                LD      A,L        ;--- Reload A with zero
07D4: 99                                SBC     A,C        ;--- Complement C (0 - C)
07D5: 4F                                LD      C,A        ;--- Save new C value
07D6: C9                                RET        ;---Rtn to caller *********** Unpack a SP number ******

First Phase of VZ ROM Disassembly Mostly Completed

The VZ ROM disassembly is mostly complete from just a raw code standpoint.
It needs commented, more labels, etc... but it's to the point where you can follow a lot of the code.

Quite a few things are labeled with the sed script now including:
Math constant tables
Key math library functions (add, subtract, multiply, divide)
Commands in the token table
Code & data copied to RAM on startup
RST calls are tagged so you can see what is being called
Interrupt handler
Many system variables
Many text stings for prompts or errors
etc...

There are still a couple holes that haven't been disassembled.  I have to determine if they are used or not and it they are, where the entry points are.  There is some dead space in the ROM that was filled with garbage, and that isn't tagged in the data yet.

A header needs to be created so it can be reassembled.  At that point I can start removing dead code and filler that the VZ doesn't need.  Then the empty space can be used for new commands or to speed up the math library by unrolling some loops.  That's still a ways off though.

VZ Disassembly continued...

I'm waiting on a USB to serial adapter to come from China, so the 68hc11 BASIC is pretty much on hold, and I haven't even looked at the IDE interface since I last mentioned it.  The IDE port doesn't really need to be finished until I can use the 68hc11 board, and that was going to be used by BASIC... so it's not an immediate priority.  I'm working on the VZ ROM disassembly in the time being.

As for the disassembly... there are now enough system variables being labeled by the sed script to where it's possible to identify what many parts of the ROM are doing.

One thing I discovered is that YAZD may not properly handle the RST instruction.  It disassembles it, but it may not treat it like a JP.  This left some commonly called functions as data.  Microsoft used RST to conserve ROM space.  While it certainly works, it also slows down the interpreter.  But regardless of why, it left me having to manually define all the RST calls as entry points.  I have also blindly labeled many other entry points to see what the code looks like.

Anyway... here is another excerpt from the disassembly to give you an idea of how things are shaping up.  There are still system variables left to be defined, some of the entry points I manually created will need to be removed, and comments still need to be added.  But since the process is automated, it only takes seconds to regenerate the disassembly and add or change labels.  Once I create a block of define statements for system variables and label addresses containing string data, I should be able to reassemble the code.  I'm debating on whether to fix the disassembler so it can do a lot of this or to just script it in sed to be done with it.

        ; Referenced from 3747
L3752:  INC     HL
        DEC     BC
        LD      A,C
        OR      B
        JR      NZ,L3743
        LD      HL,7839h
        RES     3,(HL)
        LD      HL,VERIFY_MSG
        CALL    PUTSTRING
        LD      HL,OK_MSG
        CALL    PUTSTRING
        JP      L36CF

VERIFY_MSG:  DB      0Dh
        DB      56h             ; 'V'
        DB      45h             ; 'E'
        DB      52h             ; 'R'
        DB      49h             ; 'I'
        DB      46h             ; 'F'
        DB      59h             ; 'Y'
        DB      20h             ; ' '
        DB      00h

VZ ROM Disassembly

Where the combination of YAZD and sed works, you get code that looks like this.  With a pass through sed adding comments, this could look really good without major code manipulation on my part.

        ; Entry Point
        ; --- START PROC RUN ---
RUN:  JP      Z,L1B5D
        CALL    79C7h
        CALL    L1B61
        LD      BC,1D1Eh
        JR      L1EC1
        ; Entry Point
        ; --- START PROC GOSUB ---
GOSUB:  LD      C,03h
        CALL    L1963
        POP     BC
        PUSH    HL
        PUSH    HL
        LD      HL,(78A2h)
        EX      (SP),HL
        LD      A,91h
        PUSH    AF
        INC     SP
        ; Referenced from 1EAF
        ; --- START PROC L1EC1 ---
L1EC1:  PUSH    BC
        ; Entry Point
        ; --- START PROC GOTO ---
GOTO:  CALL    L1E5A
        ; Referenced from 1FC7
        ; --- START PROC L1EC5 ---
L1EC5:  CALL    REM
        PUSH    HL
        LD      HL,(78A2h)
        RST     0x18

However, YAZD  needs to take configuration input from a file, you should be able to manually identify blocks of data including size/type/length (byte, 16 bit word, string),  entry/data points should have configurable labels instead of manually generated ones, and data labels should automatically be generated as an option.  Using sed works, but it would be nice to complete this in a single step, especially for other people that aren't familiar with Unix/Linux.

One problem with sed is that it can be a bit indiscriminate in how it performs it's search and replace.  Relabeling addresses that are formatted like "L1EC1:" works well, but adding a custom label to actual references to that label (call jp, etc..) can potentially change unrelated values, where YAZD would be able to know the difference.

YAZD is open source, but it's poorly commented.  Figuring out the code takes time (though most of it doesn't look bad), and that's before I make changes.  It just adds more time to an already time consuming process, and I still have to a create a file with comments for the ROM based on existing comments from TRS-80.  At least I don't have to create everything just from the disassembly.

Fedora Plot MC-10

Another comparison of the factory MC-10 ROM vs the modified version.
This is a 3D plot of the "Fedora" hat.
I still have to fix a speed issue with the divide, but it seems stable and all but a handful of programs seem to work.  The ones that don't have some address dependencies that would need to be patched.
Once I fix the divide it should be ready for a final release for 8K.  Many of the changes I have planned for the 68hc11 version will directly work with the 6803.  I plan on saving some of the 68hc11 specific code for last so both versions can be developed in parallel.

I ran across a reverse engineered copy of Extended Color BASIC (mostly just Color BASIC actually) that had been ported to other 6809 systems.  It's been sitting on my hard drive for some time but I had forgotten about it.  At first glance, the math library appears to be very similar to Microcolor BASIC.  I could probably squeeze several changes from my MC-10 code in, but I'll have to locate a more intact version of the original ROMs if they exist.  There are also a couple things I could borrow for the 68hc11 and 6803 versions.  

IDE/ATA interface details

The IDE/ATA interface I posted is a simple 8 bit design that buffers the high byte of the 16 bit word the interface uses.  It's more what you'd use for a Z80 or 6502 machine than a an 8 bit chip with 16 bit support like the 6803, 68hc11, 6809, etc...  Many of the IDE/ATA interfaces I've looked at treat the high byte as a zero and only use half the storage capacity of a device.  It works but it won't be readable on a PC.

The control lines from the CPLD to the transceiver are not connected because I want to work out the logic require for a 16 bit interface first.  The two bi-directional transceivers required for a 16 bit interface each have 6 control lines, so the control logic will require 12 outputs, multiplexed outputs, or several signals being duplicated between both chips.  The CPLD I selected only has 8 configurable I/O lines.  I know a few signals are duplicates, but the device may be a bit too small.  It's cheap though, so if I can get it to work, someone should be able to built an interface for under $30 using perf board, and that's probably a high estimate.