Perl Bindings for VirtualT

VirtualT has turned out, unsurprisingly I guess to be a great development tool. I don't think I could have gotten as far on my Forth OptROM as I have without it.

It could be better though. Although it can single step through code it is lacking in breakpoint support or source level debugging. Ken graciously added a breakpoint feature to the CPU Registers window for me, but I need more. Debugging an OptROM containing a Forth VM running on top of a Model T VM is not the walk in the park that it ought to be ;-) .

In addition to debugging I would like to be able to use VirtualT for testing purposes. Once I get a subroutine or module working the way I want I typically create a battery of regression tests for excercising its functionality. This permits me to do serious load testing. It permits me to make significant code changes while knowing I have a safety net in my battery of unit tests. Essentially, the battery of automated unit tests is an executable version of the requirements for the software which I can and do execute on a whim. Typically that whim comes right before I check my code into the main source tree and label it.

I could do that with VirtualT as it is today... if I wanted to write my unit tests in C++, that is. Unfortunately I find languages like C++ completely unsuitable for writing test code in. Some people can do that... not me. Languages like C, Java, C# or even C++ are fantastic for writing your final, fully specified, highly efficient and effective end product. Tests on the other hand I write in whatever language I feel I can be most efficient and effective in writing as a programmer. Well, and the language I have the most fun writing. These days, that language is Perl.

So what would be a good Perl interface to Virtual T?

I would need to be able to create instances of the vm with specific properties, like whether to use Remem or not, BASIC ROM images, Option ROM images, file system images. Anything that is configurable today through the UI needs to be configurable through the API. I need to on a function call be able to load a BASIC, DO, or CO file to/from the virtual machine's memory.

I need access to the machine: reset, run, break, single-step. I need to be able to place breakpoints. I need to be able to read all hardware state, like the E0 register. I need to be able to jump to a specific location. I need to have access to all registers.

I need to be able to dump the display to a png file. I need to be able to feed characters into the keyboard buffer, and hook the character output routines. This permits interacting with the running vm in a way a user would interact with it.

I need to be able to connect to the serial port as a file steam. I need to be able to take direct control of serial hardware flow control input lines to the vm.

It might make sense for this API to be slightly abstract. For example, I may want to implement an instance of the API that talks over a serial link to a monitor program running on a real laptop. Then I could reuse some of my tests on a real computer. The fact is that there may still be some bugs in VirtualT so it makes sense to test on the real thing too.

Such a programming interface would really supercharge my Model T development efforts. As it is now, I am spending hours resolving problems that could be done in 10s of minutes since I am constantly having to do repetitive actions during compile-edit-debug. When your target is a machine with a user community in the 100's any wasted development time is really expensive.