Testing 1... 2... 3...

Just testing different software for recording video from emulators.  I was using CamStudio, but it doesn't handle large files, and long recordings end up wrapping around to the start of the file.  An overflow issue apparently.  This is my 2nd attempt using OBS.  It still needs work but I got this far without reading the documentation.

This is the test I wrote to verify the new string compare function, but it gives a lot of the things in the interpreter a workout.   Note that the gaps during the comb sort are now the same, where they aren't in the earlier video due to a bug.  There are still a couple more bugs to track down, but it's to the point where I can start worrying about adding new commands, or replacing some slow math functions with faster modern algorithms.

A lot of effort was made to keep memory variables the same in the past, but you have to break some eggs to make an omelet... meaning that's over with, it's a waste of time.  The direct page use wasn't really thought out with speed in mind, so... good riddance.  The change is minor, but significant to optimize the math for 16 bit opcodes, and storing the last byte read was good for a 1+% speedup for about an hour's work... but it moved the character parsing code.  One thing I know will break is the patch I posted that could be included in a program.  A simple PEEK will tell you if you should install the patch or not.  Details will follow once the code is finalized.

The BASIC variables and interrupt hooks after video RAM will be there for one release version, but after that, those will be moved below video RAM to make hi-res support possible.  This had to happen.  I will also add an interrupt hook for the illegal instruction interrupt in the HD6303.  That requires replacing the pointer to the floating point register at the end of RAM.  A table of pointers to different functions will be added to support future programs.  If you want a compiler to support floating point, the best way is using ROM calls, and those functions are going to move, so this is another thing that must happen.

When will there be a release?  I have to track down a couple bugs first, then I will make one attempt to generate an 8K ROM.  If it fits in 8K again, I'll release that.  If not, I'll add several new functions first.  No point in building an 16K ROM that only uses 110 bytes of the additional 8K.  INSTR is a likely candidate.  I want to add PRINT USING, but that is pretty large.