SimICE: show floating point calculator command codes

[stefandrissen]

This may be a bit of an oddity.

When the ROM is paged in and rst 0x28 is executed, the following bytes could be shown as floating point calculator command codes.

Here is my current use case to get the address of dvar, it all works now, so as long as I tuck it away in a sub-routine I'm fine:

dvar.version:           equ 7   ; Version number divided by 10 minus 10 (version 1.1 = 1)

fpc:            equ 0x28

fpc.mod:        equ 0x08 ; N1 MOD N2
fpc.onelit:     equ 0x26 ; Stack next byte on FPCS (as a number between 0x00 and 0xff).
fpc.fivelit:    equ 0x27 ; Stack next 5 bytes on FPCS (as any number).
fpc.exit:       equ 0x33 ; Finish using floating point calculator.
fpc.dvar:       equ 0x49

rom.jgetint:    equ 0x0121

    rst fpc
        defb fpc.onelit
        defb dvar.version
        defb fpc.dvar
        defb fpc.fivelit
            defb 0          ; special form
            defb 0          ; positive
            defw 0x4000
            defb 0
        defb fpc.mod
        defb fpc.exit

    call rom.jgetint
    ret

If the rst 0x28 handling were enhanced to understand the floating point calculator, possibly the step over instruction could step over the rst 0x28 including parameters.

rst 0x08 has a similar "issue".

[simonowen]

I've been thinking about extending the symbol format to include both code and data locations to help with that sort of thing. It should include enough information to know how much data follows instructions like rst 8 and rst 0x28, with the potential for extra decoding on the data if the ROM is paged in. It'll be a breaking change to the format so you'll need new versions of both pyz80 and SimCoupe to use it.

The current ROM symbol files are edited versions of the pyz80 output, but it would be good if they could be improved to not need editing. Knowing about data might give enough information to solve that.

Perhaps the ultimate information would be enough to link source code lines to the output code. Though that might be more likely to happen through a debugger plugin to Visual Studio Code instead.