Developers’ Aid

[ops]

Developers’ Aid is a cartridge for VIC-20 developers to help testing and debugging software on real VIC-20 hardware. It combines Programmer’s Aid cartridge, Over5 file transfer program and C’mon Machine Code monitor.

For more information GOTO https://ops.github.io/developersaid/

Please test and report any bugs you find. If you come up with a feature you want to see in the final version please let me know. There is still some memory left.

Thanks to Daniel Kahlin for Over5, Aleksi Eeben for C'mon and Simon Rowe for Programmers' Aid ROM disassembly.

[Mike]

Please test and report any bugs you find. If you come up with a feature you want to see in the final version please let me know. There is still some memory left.

Some time ago, I actively searched for a small (ideally, 2 KB max.) monitor/debugger for the VIC-20. C'mon, especially in its Lite version, was a promising candidate, but ... while the included commands surely work as announced, C'mon missed out on some important details:

• Other monitors format their disassembly, memory and register dump outputs in a way they can be directly fed back as commands after modifications. With C'mon, that only works in a rather non-intuitive way - with the disassembly output by inserting "A" and a blank space in the first line of the disassembly. The memory dump (after inserting "W" and space) additionally requires the removal of the trailing PETSCII dump. There's no provision at all to change the stored register dump!
• The G command (execute code) has no provision to set the initial values of the CPU registers from aforementioned register dump. Rather the user code is called with essentially undefined register contents. That makes it impossible to test small code snippets which are meant to be executed sequentially (with preserved registers in-between).
• What's entirely missing is a command to search for byte sequences, as does the H command in, say, VICMON.
• A native monitor should limit its zero page usage to an absolute minimum. Thrashing $FB..$FE is a no-go as those zero page addresses are the first candidates that come to mind for user code. Doesn't help debugging if one wants to check what he had put into those zero page addresses to see what went wrong with the own code, only to find out C'mon had overwritten those values.
• A useful addition would be a command to compare two memory ranges with a syntax similar to the C command (copy memory). Both commands could share 99+% of their code, when the compare version branches over the STA (dst),Y instruction, but both code paths include a CMP (dst),Y instruction which prints out the source and/or destination address when source and destination bytes don't match,
• another useful addition would be if the F command (fill memory) could not only fill a single byte value, but byte patterns,
• finally, a V command (verify file) would complement the S (save file) and L (load file) command.

To save space, the other disk commands could probably be omitted. They're available in a similar fashion with an optionally loaded DOS wedge. So, there's some leeway for the improvement of C'mon.

When it comes to Over5 and ProgAid, they both are good and proven tools and shouldn't be missing in any tool collection.

Greetings,

Michael