Someone just reminded me of another optimization I planned for the new MC-10 ROM.
It seems that when I hit the OH CRAP I HAVE TO START OVER panic button in the last few days of the contest, I just kind of... sort of... maybe... might have *cough* forgot *cough* about it since I didn't have a written to-do list and hadn't actually written the code yet. And this is a big one.
You see, Microsoft BASIC scans for the BREAK key during program execution. In fact, it scans for the BREAK key every time is passes through the main interpreter loop. Every... single... time. In fact, it is actually the first thing it does when it passes through the main interpreter loop. You can find the code in the source/disassembly labeled as LE519.
The fix is actually quite easy. Just have a counter stored on the direct page, decrement it every pass and if it's not zero, BNE past the test. If it is equal, reset the counter and call the check for BREAK.
That's only 4 new instructions. or around 8 bytes.
Then it's just a matter of tuning the counter setting so eliminates as many calls as we can get away with while keeping the BREAK key feeling responsive.
1. It's simple enough I thought I could do it at the last minute
2. I was trying to free up ROM space for ELSE first and that also sped up the ROM.
3. I was trying to work out more difficult optimizations to see if I could work them into the contest.
4. I didn't write down the to-do list.
As far as space for more optimizations goes...
If I create a runtime only version of the interpreter, the break key test could be dropped entirely, CSAVE could be dropped, and part of the parser/tokenizer might go as well. That would free up some space. You'd have to write your code on the slower ROM and run it on the faster one after it's debugged. Without the constant check for BREAK you'd have to wait for the program to perform keyboard input, or hit reset if you want to quit.
It seems that when I hit the OH CRAP I HAVE TO START OVER panic button in the last few days of the contest, I just kind of... sort of... maybe... might have *cough* forgot *cough* about it since I didn't have a written to-do list and hadn't actually written the code yet. And this is a big one.
You see, Microsoft BASIC scans for the BREAK key during program execution. In fact, it scans for the BREAK key every time is passes through the main interpreter loop. Every... single... time. In fact, it is actually the first thing it does when it passes through the main interpreter loop. You can find the code in the source/disassembly labeled as LE519.
This is one of the worst time wasters in the ROM and it's in every version of Microsoft BASIC that I've looked at. You don't need to scan for BREAK that often. A hack for the TRS-80 Model 1 that disabled this in Level II BASIC supposedly sped up the interpreter considerably, and a patch for the CoCo 3 ROM that uses the keyboard interrupt sped it up a lot as well.
The fix is actually quite easy. Just have a counter stored on the direct page, decrement it every pass and if it's not zero, BNE past the test. If it is equal, reset the counter and call the check for BREAK.
That's only 4 new instructions. or around 8 bytes.
Then it's just a matter of tuning the counter setting so eliminates as many calls as we can get away with while keeping the BREAK key feeling responsive.
I believe this is commonly referred to as "low hanging fruit" and it should have been written first.
The good new is, there should still be enough free space in the ROM to implement it.
The good new is, there should still be enough free space in the ROM to implement it.
This should also fit in the original ROM just by dropping the programmer's name and/or the Microsoft Easter eggs.
FWIW, this code hasn't been implemented yet because:1. It's simple enough I thought I could do it at the last minute
2. I was trying to free up ROM space for ELSE first and that also sped up the ROM.
3. I was trying to work out more difficult optimizations to see if I could work them into the contest.
4. I didn't write down the to-do list.
As far as space for more optimizations goes...
If I create a runtime only version of the interpreter, the break key test could be dropped entirely, CSAVE could be dropped, and part of the parser/tokenizer might go as well. That would free up some space. You'd have to write your code on the slower ROM and run it on the faster one after it's debugged. Without the constant check for BREAK you'd have to wait for the program to perform keyboard input, or hit reset if you want to quit.
If a sound chip were added, the SOUND() function could be made smaller.
The settings could probably be calculated and by using the hardware timer, the wait to turn off the sound could be simplified. This seems really large for what it does.
At some point, I would prefer to just go to a 16K ROM and only be backwards compatible at the source level, or through machine language calls via the vectors at the end of the ROM. I should just redo the Memory setup so interrupt vectors are below video RAM, programs are stored above the screen, and variables/stack are stored below the hi-res screen.
Other thoughts...
Video really needed to start at a higher or lower memory address to give a larger contiguous block of memory to BASIC.. $1000 would have been a much better and the decoding logic wouldn't have been much different. It's like they intentionally crippled the machine in as many ways as they could think of! :/
One of the things I want to do in the future, is to support the 6303, and that would require moving the Floating point vector that resides at the same address as the illegal instruction interrupt vector for the 6303.
Is anything even using that? I've already broken the memory layout of the floating point registers to make the multiply faster, though that's easy to fix.
There should really be vectors for the entire floating point library. Multiply, divide, SQR, ^, SIN, COS, TAN, conversion between integers and floats, etc... This is one of the major flaws I see with the ROM. Any program that wants to use these functions must assume they are at the original address. If you want to use them for a floating point library for C, Pascal, whatever, your program can only run on the original ROM.
The settings could probably be calculated and by using the hardware timer, the wait to turn off the sound could be simplified. This seems really large for what it does.
At some point, I would prefer to just go to a 16K ROM and only be backwards compatible at the source level, or through machine language calls via the vectors at the end of the ROM. I should just redo the Memory setup so interrupt vectors are below video RAM, programs are stored above the screen, and variables/stack are stored below the hi-res screen.
Other thoughts...
Video really needed to start at a higher or lower memory address to give a larger contiguous block of memory to BASIC.. $1000 would have been a much better and the decoding logic wouldn't have been much different. It's like they intentionally crippled the machine in as many ways as they could think of! :/
One of the things I want to do in the future, is to support the 6303, and that would require moving the Floating point vector that resides at the same address as the illegal instruction interrupt vector for the 6303.
Is anything even using that? I've already broken the memory layout of the floating point registers to make the multiply faster, though that's easy to fix.
There should really be vectors for the entire floating point library. Multiply, divide, SQR, ^, SIN, COS, TAN, conversion between integers and floats, etc... This is one of the major flaws I see with the ROM. Any program that wants to use these functions must assume they are at the original address. If you want to use them for a floating point library for C, Pascal, whatever, your program can only run on the original ROM.
No comments:
Post a Comment