Debugging ROM code and custom hardware interactions?

[+jedimatt42]

I'm working on a DSR, that interacts with memory mapped IO to some custom hardware. But the world is upside down, and I need to develop strategies to debug this.

 

My current dev process is : assemble the ROM, rebuild the FPGA image, push it over usb to the custom hardware simulated on an FPGA dev board, reboot the TI, manually test.

 

This isn't bad, as long as the problems are in the hardware. But I need to work the problems out of the software, and am hitting a few mysteries. So I want to step through the code I wrote, and debug it. The current best strategy for stepping through this is going to look like this:

 

Use Classic99 - load the dsr through the cartridge definitions mechanism

customize the code with .ifdef to add debugging features:

if emulation: move IO read and write ports to RAM, so the result can be observed, and the inputs can be manipulated.

if emulation: skip anything in the way of debugging.

 

This seems like it should be pretty effective. But my question to the group is:

 

What techniques have you used, better or worse, for debugging your assembly and custom hardware interactions?

 

-M@

[+jedimatt42]

I believe classic99 will allow me to record the write operations to IO addresses for analysis. So I will probably add that into what I'm doing.

 

I would really like to also be able to provide a transcript of the values to be read from the IO ports, so I can simulate data fetched from the device. That appears to be a non-trivial project on its own, unless there are features I'm overlooking.

 

-M@

[+jedimatt42]

I suspect nobody else has this problem, or they write their own TI-99/4A emulator.

 

Well, just to follow up, in case I ever need to remember this, the technique outlined in post #1 worked pretty well.

 

--

 

Something else I just thought of: For a transcript of data to read, I could use the Classic99 cartridge definition to include a memory image in expansion ram space, and then .ifdef the read operations to also increment the read address.

        .ifdef emulation
RDIN    EQU  >C000
RDINLOC EQU  >BFFE
        .else 
RDIN    EQU  >5FFB
        .endif

...

; setup code
        .ifdef emulation
        LI    R1,RDIN
        MOV   R1,@RDINLOC
        .endif

...

; Read a byte
        .ifdef emulation
        MOV   @RDINLOC,R1
        MOVB  *R1,R0
        INCT  *R1
        .else
        MOVB  @RDIN,R0
        .endif
        
; It eats a register though... 

-M@

[Tursi]

That's pretty much what I do... Although I also build the hardware into the emulator (to whatever level I need). There's no helpful logging features yet, though.

[+Vorticon]

 

 

What techniques have you used, better or worse, for debugging your assembly and custom hardware interactions?

 

-M@

 

Since all of the hardware I create for the TI has no emulation counterpart, I usually rely on the classic SUPERBUG program on the TI when working out issues with assembly programs interfacing. Works well once one gets familiar with it, but still painful. It was my bedrock while testing the TI Vision interface...

[+jedimatt42]

I'll have to try that for the full retro experience, I found SUPERBUG II manual on whtech. It looks promising for some use cases... I have just been using Forth to interactively explore the actual hardware, or little gcc apps, where I don't doubt the code as much as I doubt my assembly code.

 

I exercised the classic99 hardware simulation and my limited DSR rom code all worked as intended. So that is pointing me at a hardware reliability issue. It looks like with SUPERBUG, it would be best to refactor the bit of ROM code I want into a testcase I can run from expansion ram... so that breakpoints can be used.

I might have to relocate to a PEB setup to really use SUPERBUG features.

 

-M@

[+Vorticon]

Yes, the breakpoints feature is essential. Stop program somewhere, probe hardware state, continue, repeat