Status update.

I really haven't spent much time on anything new since the last post.
There is a bug that seems to be part of the original conversion of the disassembly back to assembly code that did not appear in initial tests, but now it has become a show stopper.  This has forced me to go back to my original goal of creating a version of the source code that generates an identical binary to the original ROM.  Then I can test individual changes against that code instead of everything all at once.  Most of that work is complete but I probably have another 25-50 changes to go before it's ready.   It's a couple hours work at the most.

One of the easiest optimizations that came out of this effort was simply using an assembler that properly generates code for direct page references.  I'm actually had to force the assembler to generate the original opcodes using FCB and FDB.  This alone probably saved enough space vs the Easter eggs to implement the ELSE statement.  That's the first change I'll make to the code.
Then I'll insert the ELSE code, followed by a few small optimizations that use D where it's definitely safe.

Two of the optimizations that I want to use involve the CHARGET and storing the pointer to the next line.  They will certainly offer a speedup.  But to fully support the CHARGET changes requires looking at dozens of subroutines to find out what the X register contains for each one.  This is going to take a notebook or whiteboard and several days work.  Given the time constraints of the contest, it will have to be in a later release.  Storing the pointer to the next line is almost complete, but there is still one condition where it is failing and I need to see what is still messing up the FOR NEXT stack.  This optimization may also have to wait.

Everything previously mentioned will certainly offer a small performance increase..  I've also written faster versions of the code that moves strings and made a lot of other modifications that can save clock cycles.  When all those are rolled out, Microcolor BASIC will certainly be more responsive.   Running two copies of the VMC10 emulator side by side running the same program show a small but noticeable difference.

I have not worked on code to speedup the search for line numbers.  I looked at a simple design on paper and I probably need another 50 to 75 bytes for that.  It's just not going to fit in the limited ROM space.  Maybe some future ah-ha moments will free up enough space, but I have my doubts.

This brings us to the real bottleneck which is the math library.  I've made several optimizations but they all have to be retested from scratch thanks to the bug I mentioned.  So that's another thing that may not make the release.  Sadly, the fastest approach on paper to many of these routines is probably going to exceed available space.  It's an 8K ROM, not a Tardis.

Ultimately, I should have a release that supports ELSE and is faster soon.  It won't be as fast as I'd like, but there will certainly be follow up releases as I test the other optimizations.  Hopefully some of the better ones will be ready before the end of the contest.  The fixes to the bad Microsoft math constants can already be used as an option, so that should be in the release as well.