Thanks Pokemon!
What I'm doing is porting fruitcake's disassembly of MAZOGS into FASM-ZX. Since you did a great job in mixing BASIC and Assembly I thought this would help with dealing with all the PEEKS, POKES and RAND USR lines if I make modification to the assembly code. It has definitely tested FASM-ZX.
Here are some things I found:
I redid the ZX81VARS.INC with colons at the labels as listed below to handle any reference to the system variables.
Code: Select all
;
; ZX81VARS.INC
; include file with variables used by Sinclair ZX81
; for FASMZ80 (flatassembler with Z80 instruction set)
;
; V1.2
;
virtual at MEMST
ERR_NR: db ? ; error number $ff is no error
FLAGS: db ? ; flags of system
ERR_SP: dw ? ; first item of machine stack
RAMTOP: dw ? ; top address of ram, first non-existing memory location
MODE: db ? ; cursor mode (K/L,F,G)
PPC: dw ? ; line number currently executed
SAVE_BEGIN: ; start address of prgrams loaded into memory
end virtual
ORG SAVE_BEGIN
VERSN: db 0 ; version, 0=ZX81 BASIC
E_PPC: dw 0 ; number of current line with cursor (in listing)
D_FILE: dw DFILE_ADDR ; begin of D_FILE (display file) in memory
DF_CC: dw DFILE_ADDR+1 ; current cursor position in D_FILE (used for print routine)
VARS: dw VARS_ADDR ; begin of variable section in memory
DEST: dw 0 ; address of variable in assignment
E_LINE: dw WORKSPACE ; address of workspace
if defined AUTORUN
CH_ADD: dw AUTORUN ; address of next character to be interpreted
else
CH_ADD: dw 0 ; address of next character to be interpreted
end if
X_PTR: dw 0 ; address of character preceeding "S" marker
STKBOT: dw WORKSPACE ; stack botton (top-down)
STKEND: dw WORKSPACE ; end of stack (top)
BERG: db 0 ; calculators b register, possibly write error, should be BREG :-)
MEM: dw MEMBOT ; address for calculator's memory
UNUSED1: db 0 ; unused variable / space
DF_SZ: db 2 ; no. of lines in lower part of screen including 1 blank line
S_TOP: dw 0 ; no. of top program line in automatic listings
LAST_K: dw 0 ; last key pressed
DEBOUNCE: db 0 ; debounce status of keyboard
MARGIN: db PAL ; margin value, could be used PAL or NTSC
if defined AUTORUN
NXTLIN: dw AUTORUN ; next line to be executed
else
NXTLIN: dw 0 ; next line to be executed
end if
OLDPPC: dw 0 ; line to jump when executing CONT (continue)
FLAGX: db 0 ; internal flags
STRLEN: dw 0 ; length of string, interally used
T_ADDR: dw 0 ; next item in syntax (token) table
SEED: dw 0 ; seed variable set by RAND
FRAMES: dw 0 ; counter of frames sent to TV, used by PAUSE command
COORDS: db 0 ; x coordinate of last point plotted
db 0 ; y coordinate of last point plotted
PR_CC: db $BC ; LPRINT position used with real printer
S_POSN: db 33 ; column no. for print position
db 24 ; line no. for print position
match =FAST_MODE,STARTMODE {
CDFLAG: db FAST_MODE
}
match =SLOW_MODE,STARTMODE {
CDFLAG: db SLOW_MODE
}
match =STARTMODE,STARTMODE {
CDFLAG: db SLOW_MODE
}
assert CDFLAG > -1
PRBUFF: db 32 dup(0) ; printer buffer, initialized with 0
db NEWLINE ; printer buffer ends with a newline character
MEMBOT: db 30 dup(0) ; calculator additional memory ???
UNUSED2: dw 0 ; unused variable / space
BASIC_AREA:
I found that version 1.701.s produces an error when LD E,(HL) or LD D,(HL) is processed version 1.701.q does not have that error.
The most interesting bug I found is when L408C or L4B0C is in a line I get an Invalid Operand error. I changed the label L408C: to PLOC: and still got the error but when I changed L408C: to L408X: and L4B0C: to L4B0X: it compiled fine. It look like any label ending in the letter C cannot be identified.
Once I made those corrections I could compile MAZOGS with 1.701.q and run it without an issue.
One interesting thing I found that fruitcake caught, by using a macro, is that the code uses the 4 byte ED prefixed version of LD HL,(ADDR) rather than the 3 byte version. When I originally compiled it I used the 3 byte version and MAZOGS hung at making the maze. Until I figure out how to do macros I just used the 3 byte version with a NOP after to keep all code lining up with the Basic references. This was probably Don Priestley's way of securing the code from reverse engineering since re-assembling a disassembly of the code would replace the 4 bytes with 3 bytes causing the program to fail.
I hope what I found helps out in future versions of FASM-ZX.