+jedimatt42 Posted February 27, 2017 Share Posted February 27, 2017 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@ 2 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted February 27, 2017 Author Share Posted February 27, 2017 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@ 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted March 1, 2017 Author Share Posted March 1, 2017 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@ Quote Link to comment Share on other sites More sharing options...
Tursi Posted March 1, 2017 Share Posted March 1, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 1, 2017 Share Posted March 1, 2017 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... 1 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted March 1, 2017 Author Share Posted March 1, 2017 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@ Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 2, 2017 Share Posted March 2, 2017 Yes, the breakpoints feature is essential. Stop program somewhere, probe hardware state, continue, repeat Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.