Option ROM Programming Theory

In a comment from a prior post, twospruces (Steve, I guess?) asks whether there are two kinds of rom routines... those compatible with an option rom and those not.

I guess it depends on the trampoline code that you use, and the routine being called. The general idea is that there is code copied from main ROM to high RAM at boot. When code in option rom wants to call the main rom it runs some code like this (from romhd.asm):

StdCall:
    di
    shld    HoldH             ;Caller's hl
    xchg
    shld    HoldD             ;Caller's de
    pop     h                 ;(hl)=Routine to Call
    mov     e,m
    inx     h
    mov     d,m               ;de=Routine to Call
    inx     h                 ;hl=Return Address
    push    h
    lxi     h,EnableOptROM    ;return through EnableOptROM
    push    h
    push    d                 ;Return Address
    lhld    HoldD             ;Caller's de
    xchg
    lhld    HoldH             ;Caller's hl
    ei
    jmp     StdOn

This code saves HL and DE and sets up the stack with some return addresses to get to and from the main ROM code. It doesn't look like it damages any registers in the process. The EnableOptROM code preserves a by saving and restoring the psw.

EnableOptROMImg:
    push    psw
    mvi    a,1
    out    0xe0
    pop    psw
    ret

And this code, org'd at 0x85:

StdOn:
    push    psw
    push    h
    lxi    h,0x26c8
    xthl
    xra    a
OpExit:
    out    0xe0
    ret

This is in the Option ROM, but I guess it must slide into the main ROM right after the out instruction, like is done on a Remem inter-bank jump. Maybe it doesn't have to transition through high RAM?

I assume that the code at 0x26c8 in the main rom restores the a register before making the jump.

So I think you should be able to call any function in main ROM.

That said, all this stuff adds some overhead to every call. I can imagine if you decided to preserve less of the registers and take advantage of instructions like pchl, you could make a lot more lightweight far calls.

Anyway, I suggest using romhd.asm from club100 as a starting point. There is also code to call interrupt handlers in the main ROM.

Making Option ROMs

Repackaging Fig Forth as an Option ROM is an ongoing task...

I have ported the code to as8085 assembler/linker. Unfortunately I am having a problem with the .s19 file generated by the linker. Other than that, I seem to have a proper Option ROM. I based the Option ROM code of of ROMHD.ASM from http://club100.org

What I still need to do is make sure that it is using RAM memory as its user dictionary and for all state variables.

The biggest task left is making sure that all calls to the main ROM go through the far call code. This switches from OptROM to Main ROM, makes call, and gets back to OptROM. This has to be really slow... to keep things snappy I'd like to use Steve Adolph's fast text scroll routines and embed it along with enough of the text generator to get along, so I don't jump to main ROM for every character printed. Plus screen scroll should actually be faster than a regular Model 100/102!

I would like to keep one Fig Forth source code file. That means I need some macro that I can control that decides to either do a far call to the main rom or a regular call, and assembles the right thing automatically. EP3, "the Extensible Perl Preprocessor" looks promising since Perl is my string processing hammer of choice.

Ultimate VirtualT Trace and Command Line

Sorry Ken, I missed your post sometime back about what trace information I would like from VirtualT.

Trace information...

XML or YAML would be good so it's easy to parse.

If I could just get a running trace of:

• address of instruction
• length
• instruction bytes
• register deltas of value changes
• memory address and new/old value if a memory store operation is performed
• state of option rom (selected or not)

that would be perfect. I could use this as input to my disassembler.

For a command line version, it would be nice to be able to supply a .CO file, a main ROM, an option ROM, and maybe some .DO files that get loaded to memory. The .CO file would run. The Stdout would be the characters as written to the screen, or if an option were given, the contents of a .DO file dumped from RAM file system, or the serial I/O.

Oh, and it would be good to be able to limit tracing to a fixed range of code. So, if PC is in the range, then generate instruction trace. So, this would imply a command line option for this.