Jump to content
IGNORED

Debugging ROM code and custom hardware interactions?


jedimatt42
 Share

Recommended Posts

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@

  • Like 2
Link to comment
Share on other sites

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@

  • Like 1
Link to comment
Share on other sites

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@

Link to comment
Share on other sites

 

 

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...

  • Like 1
Link to comment
Share on other sites

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@

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...