Improved 6502 Virtual Trainer

Over the last few days I have made a lot of progress on this project. The main hurdle was getting a USB Virtual Com Port example running with the toolchain. The code from the first 6502 Virtual Trainer, which used an MSP430, was pretty easy to port to the STM32. After I got single-stepping to work, as I mentioned in my last post, I worked on the mode that stores the entire address space on the chip. It was a little surprising at first that it only ran at about 23,000hz. This is not much faster than the 14,000hz I was running at with the MSP430 version. My initial suspicion was that the transfers between the chip and PC to keep their respective copies of the address space synced were taking too much time. Timing the transfers showed that the chip usually spent over 90% of its time executing code, however. The biggest speed up came by manipulating the GPIO registers directly, rather than relying on the cumbersome HAL functions. Another thing I tried was changing the baud rate, although I couldn't find where it was initialized in the code. Eventually I found out that the Virtual Com Port doesn't rely on any sort of baud rate setting. A few other small improvements got the speed up to 350,000hz or so. When I found out how to turn on GCC optimizations in the System Workbench IDE, the speed got up to over 770,000hz. That's 0.77MHz! It's not quite the 1MHz I had hoped for but it is over 50 times faster than the first version.

My original plan was to leave the IDE unchanged so that it would be compatible with both the old
MSP430 board and the new STM32 version, but I had to change a few things. For one, I was only transferring two bytes of data to count how many clock cycles had been executed since the last update, so I had to add a third one since the new board runs so much faster. The old version synced with the IDE when at least 64 bytes of data needed to be transferred. This is the most I could store in the MSP430's internal RAM. The new limit is 200, which wastes less time syncing when lots of data is transferred. A few thousand bytes would probably be even better, but the IDE wasn't able to keep up. This could probably be fixed but 200 is fine for now.

Another thing that changed was losing support for breaking on uninitialized reads. This was a very handy feature on the first version because it could catch many different kinds of errors. That version used a 65C816 in 6502 mode and separating read cycles from internal operation cycles (when the processor is not reading despite the RWB pin being high) was easy monitoring the VPA and VDA pins. There is no easy way to do this on the 65C02 I am using now without storing information on the microcontroller about the status of the bus for every cycle of every opcode in every addressing mode. Hopefully I can live without this feature now that I have a little more experience with 6502 assembly. To test the new version I used the same small RPN graphing calculator program I wrote for the first version. It works great but drawing to the screen, even with the GDI library, is still a bit of a bottleneck.

Now that I am finished with this project I can start on programming the calculator I hope to build for the Makevention in August.