Ticks debugger

[suborb]

This is the start of a debugger for ticks. Commands supported:

• cont
• step
• break 0xXXXX
• reg
• dis

They could all do with extending and extra ones added, but it's better than nothing.

The disassembler is hacked from one I found online, but I think it's worth replacing with something a bit more home-brew to allow easier extension.

There's command line history and editing courtesy of linenoise, this compiles on mingw and I think on VS as well. If someone with windows could confirm that would be nice.

Finally, I've added -mz80 and -mz80-zxn options to ticks and added the ZXN opcodes that the opt file rules use.

[aralbrec]

No there's no timing information. I can try to ask but the people doing hw have been very busy and not too accessible.

Mike is doing 4T in his emulator but I'm not sure where he gets that info from. It certainly doesn't make sense from a standard z80 point of view.

[aralbrec]

Some timings passed along by Mike:

LDIX 16T
LDIRX 21T

MUL 4T (16*16 bit)

ADD HL,A 4T
ADD HL,$0000 12T

PIXELDN 4T
PIXELAD 4T
SETAE 4T

INC DEHL 4T
ADD DEHL,BC 4T
ADD DEHL,$0000 12T

TEST $XX 7T

So popx is probably 4T too. Some of the instructions are implemented internally using faster logic.

[suborb]

Brilliant, thank you. I think we can extrapolate that push $xxxx is 12T then.

I've not implemented the LDI instructions yet, but I guess that LDIRX is 21T for each loop and then 16T for the last one?

[aralbrec]

Some more guesswork here:
#312

The ldi* are using the z80 logic so the timing is the same so like you say 21/16. fillde and outinb may be much faster than guessed.

[aralbrec]

I just gave z88dk-dis a try on a compiled program:

z88dk-dis -o32768 -s32768 -mz80-zxn -x sudoku.map sudoku_CODE.bin > out.txt

I gave it a map file for symbols and that's going to mix defined constants with addresses. It looks like the destination addresses for jumps and calls is filled in correctly, though there may be errors if a constant a label share the same value.

The beginning looks like this:

__clib_exit_stack_size:	di      		;f3
__EACCES:           	push    iy		;fd e5
CHAR_CTRL_C:        	exx     		;d9
__CLIB_OPT_TXT2NUM_SELECT_FAST_DEC:	push    hl		;e5
__EFBIG:            	ld      (__sp_or_ret),sp		;ed 73 6e df
STDIO_MSG_CLOS:     	ld      sp,$ff58		;31 58 ff
__LAYER2_COLOR_GREEN_3:	ld      hl,$9f50		;21 50 9f
ITERM_MSG_GETC:     	inc     (hl)		;34
__LAYER2_COLOR_HTML_Green:	inc     (hl)		;34
ITERM_MSG_PUTC:     	call    _main		;cd 32 9a
__IO_RRSLS_LAYER_PRIORITY_ULS:	push    hl		;e5
__ESXDOS_ENAMETOOLONG:	pop     bc		;c1
ITERM_MSG_BS_PWD:   	ld      sp,(__sp_or_ret)		;ed 7b 6e df
__MESSAGE_ITERM_NEXT__:	exx     		;d9
CHAR_ESC:           	pop     hl		;e1
__ESXDOS_EMAPRAMACTIVE:	exx     		;d9
__ESXDOS_EDRIVEBUSY:	pop     iy		;fd e1
__LAYER2_COLOR_HTML_Aqua:	im      1		;ed 56
OTERM_MSG_SCROLL:   	ei      		;fb
OTERM_MSG_CLS:      	ret     		;c9

The labels on the left are defined contants, in fact: 0,1,2,3,etc. So the left side labels are not being offset to 32768 as they should be ("-o32768").

[suborb]

I think it should be:

z88dk-dis -o 32768 -s 32768 -mz80-zxn -x sudoku.map sudoku_CODE.bin > out.txt

i.e. space separated. The command line parsing is the same as ticks itself.

I think the map file probably needs to distinguish between labels and defc to get the symbolic compilation to truly work.

[aralbrec]

If I put the spaces in:

z88dk-dis -o 32768 -s 32768 -mz80-zxn -x sudoku.map sudoku_CODE.bin > out.txt
Cannot load file '32768'
Cannot load file '32768'

but the label thing is fixed.

It's nice to see the symbols in there:

asm_zx_scroll_wc_up_noexx:	exx     		;d9
l_824b:             	push    bc		;c5
l_824c:             	push    de		;d5
l_824d:             	push    hl		;e5
l_824e:             	exx     		;d9
l_824f:             	call    asm_zx_scroll_wc_up		;cd 57 82
l_8252:             	pop     hl		;e1
l_8253:             	pop     de		;d1
l_8254:             	pop     bc		;c1
l_8255:             	exx     		;d9
l_8256:             	ret     		;c9
asm_zx_scroll_wc_up:	inc     d		;14
l_8258:             	dec     d		;15
l_8259:             	jp      nz,asm_zx_cls_wc		;c2 aa 81
asm0_zx_scroll_wc_up:	inc     e		;1c
l_825d:             	dec     e		;1d
l_825e:             	ret     z		;c8
l_825f:             	ld      a,(iy+$03)		;fd 7e 03
l_8262:             	dec     a		;3d
l_8263:             	sub     a,e		;93
l_8264:             	jp      c,asm_zx_cls_wc		;da aa 81
l_8267:             	inc     a		;3c
l_8268:             	ld      c,a		;4f
l_8269:             	push    hl		;e5
l_826a:             	push    de		;d5
l_826b:             	ld      h,(iy+$02)		;fd 66 02
l_826e:             	ld      l,(iy+$00)		;fd 6e 00
l_8271:             	call    asm_zx_cxy2saddr		;cd 19 82
l_8274:             	ex      de,hl		;eb
l_8275:             	ld      a,(iy+$02)		;fd 7e 02
l_8278:             	add     a,l		;85
l_8279:             	ld      h,a		;67
l_827a:             	ld      l,(iy+$00)		;fd 6e 00
l_827d:             	call    asm_zx_cxy2saddr		;cd 19 82
l_8280:             	push    hl		;e5
l_8281:             	push    de		;d5
l_8282:             	exx     		;d9
l_8283:             	pop     hl		;e1
l_8284:             	pop     de		;d1
l_8285:             	call    asm_zx_saddr2aaddr		;cd 40 82
l_8288:             	ex      de,hl		;eb
l_8289:             	call    asm_zx_saddr2aaddr		;cd 40 82
l_828c:             	ld      b,$00		;06 00
l_828e:             	exx     		;d9
copy_up_loop_0:     	exx     		;d9

It would be nice if no end address is specified that is pursues all branches rather than stopping after a fixed line count. yazd does something like that.

I think the map file probably needs to distinguish between labels and defc to get the symbolic compilation to truly work.

I also use defc to define address aliases. I don't know if z80asm would be able to distinguish between a link-time defc (an address) and an assemble time constant in the map file. We also have to look at putting bank information into the map file (and have it sorted by bank) and it would be nice if z88dk-dis could handle multiple banks eventually.

[aralbrec]

Actually I will move this to the main issues.