Data logger feature?

[gtoal]

This is a suggestion to enhance the Vextreme for use as a program development/debugging aid.

The Vextreme could be used as a substitute for an expensive logic analyzer/data logger, by recording the program execution path and accesses to rom data, by having the Vextreme keep a cyclic buffer of the addresses that were fetched from, during program execution.

I'm assuming the hardware is not fast enough to log directly to flash on the fly, which is why I suggest the use of a cyclic buffer. If it were, that would be a preferable option as the size of the log could be much greater. Saving a rom access record using a cyclic buffer would look something like: Buff[Ptr] = fetch_addr; ptr = (ptr + 1) & buffsizemask; which should be low enough overhead that it can be done on every fetch.

Depending on RAM available it would also be useful to store an accurate timestamp by using the ARM internal cycle counter. If using a timestamp there would be no need for separate put/get pointers.

It would also be necessary to store the bank ID if the rom being emulated were bank-switched, which would need an extra byte per saved fetch record.

The utility of this would depend on how much free internal RAM is in the SOC, but even something as low as 30K 16-bit words ought to be enough to record all behaviour during a single vectrex drawing cycle.

Some mechanism would be necessary to trigger the Vextreme to save the cyclic buffer to permanent storage. Possible trigger mechanisms might include: 1) external signal to gpio pin 2) external signal via edge connector bus (eg nmi) 3) RPC call from 6809 4) trap on any access to a specific address 5) trap on any attempt to write to rom address space.

If the vextreme has sufficient memory available it would also be possible to implement an array which is the same size as the emulated rom memory, containing flags that could be used to trigger actions - eg trigger an action on read from any marked address, or have write protection at a byte address level in a writable cartridge, or trigger a 6809 interrupt on access to specific byte addresses.

The data logging of the execution path history would be extremely valuable to Vectrex developers because there is currently no other mechanism for tracing program execution that does not also interfere with that execution, whereas this would be like an external logic analyzer sniffing the bus and would not be visible from the 6809.

[djmips]

I think this is a good idea. As an aside, when I worked at Electronic Arts in the nineties, they made exactly such a thing for the SNES and I was able to use it to find some tricky timing bugs with the multiplication hardware and Mode 7. It showed what was happening on every clock and was great for post mortem debugging since you could see how your code got off into the weeds.

[technobly]

Thanks for the write up @gtoal ! I do agree this would be an amazing feature, even if it required a totally separate stripped down build of the STM32 code and only worked for 32KB games (so that there would be plenty of RAM for other things).

Another plan I have of getting similar tracing with not much cost, is a pass-through board that connects to two 16-bit logic analyzers. With a little scripting and proper triggering, the saved data could be stitched back together to form a cheap 32-bit logic analyzer for the Vectrex. You could easily stream as much as you wanted back to the computer via USB.

Even without the trace feature built into VEXTREME, I think the various traps on memory read/write or other hooks into /NMI /HALT would be valuable. And the ability to dump the Vectrex's RAM would be good, although, you can currently do a lot of this in Vide as well with single stepping. Where that breaks down is when you are trying to debug VEXTREME's operation with RPC calls and it's emulated ROM. Because of this, I'm leaning more towards the LA approach because it would interfere less with the operation of VEXTREME.