The images look very different, but the only difference is the scale and center of the image. They are performing the same number of calculations and setting the same number of pixels. Once I add hi-res graphics support this will be more obvious.
Wednesday, December 12, 2018
Apple II vs MC-10
The images look very different, but the only difference is the scale and center of the image. They are performing the same number of calculations and setting the same number of pixels. Once I add hi-res graphics support this will be more obvious.
New CoCo 3 ROM
For those of you that want a new CoCo 3 ROM, I've turned my current code over to William Astle.
Pretty sure he'll be able to crank out the 6809 changes faster than I would since I haven't been working with the 6809 much. This will also leave me to work on a few other optimizations I had in mind.
Pretty sure he'll be able to crank out the 6809 changes faster than I would since I haven't been working with the 6809 much. This will also leave me to work on a few other optimizations I had in mind.
Monday, December 10, 2018
Thursday, December 6, 2018
CoCo 3 vs MC-10 with new ROM
Up to this point I've shown comparisons of the new vs old MC-10 ROM. This video demonstrates the difference in speed between the CoCo 3 running at double speed vs the MC-10 with the new ROM. This is the difference the hardware multiply makes, along with a better implementation of the interpreter. The CoCo 3 will show a greater difference on non-math oriented programs, but this provides a rather interesting comparison. If I were to replace the MC-10's Motorola 6803 with a Hitachi 6303, and if it provided even a 10% speed increase, the MC-10 would win in this comparison. The 6309 provides at least a 20% speedup over the 6809 so that is a very real possibility.
Wednesday, December 5, 2018
Some last minute notes on the new MC-10 ROM
Just some notes on last minute changes to the new MC-10 ROM.
The 16 bit string compare may be a few clock cycles slower when comparing strings of 1-3 bytes in length(?), but anything longer will be faster. The slower performance on short strings will be more than made up for by the faster interpreter, but the difference on longer strings is significant enough to make this change well worthwhile. The new interpreter will always be faster, but should be noticeably so when comparing a lot of long strings like with my test sort code (which I'll release shortly).
The manner in how the the main loop calls the functions associated with tokens has been changed.
The size of the "Command Dispatch Table" has been enlarged to account for all potential tokens. This allowed the removal of the range check before calling the address in the Command Dispatch Table, saving a few clock cycles. Tokens that would result in a syntax error, now jump directly to the error, and undefined tokens jump to the RAM hook "RVEC10" which is set to jump to syntax error by default. This lets the main loop skip the jump to the RAM hook for every ROM based token routine, saving multiple instructions for every token executed, but you can still intercept unused tokens to extend the ROM.
While existing programs that override tokens will not work on the new ROM (I can only think of one), it is still possible to extend BASIC, and alternative versions of existing commands could replace the current ones. I'm working on a way to embed new tokens and parameters directly into the code.
*edit*
Please note that tokens $F0-$FF cannot be used at this time. The token number is multiplied by 2 to calculate the offset in the dispatch table. This is done with a bit shift, but the result is only one byte and the carry is lost. It's a trade off for speed. It still leaves room for 38 new tokens, and I'd like to reserve $EF for future expansion. (Two byte tokens could be a possibility in the future)
The 16 bit string compare may be a few clock cycles slower when comparing strings of 1-3 bytes in length(?), but anything longer will be faster. The slower performance on short strings will be more than made up for by the faster interpreter, but the difference on longer strings is significant enough to make this change well worthwhile. The new interpreter will always be faster, but should be noticeably so when comparing a lot of long strings like with my test sort code (which I'll release shortly).
The manner in how the the main loop calls the functions associated with tokens has been changed.
The size of the "Command Dispatch Table" has been enlarged to account for all potential tokens. This allowed the removal of the range check before calling the address in the Command Dispatch Table, saving a few clock cycles. Tokens that would result in a syntax error, now jump directly to the error, and undefined tokens jump to the RAM hook "RVEC10" which is set to jump to syntax error by default. This lets the main loop skip the jump to the RAM hook for every ROM based token routine, saving multiple instructions for every token executed, but you can still intercept unused tokens to extend the ROM.
While existing programs that override tokens will not work on the new ROM (I can only think of one), it is still possible to extend BASIC, and alternative versions of existing commands could replace the current ones. I'm working on a way to embed new tokens and parameters directly into the code.
*edit*
Please note that tokens $F0-$FF cannot be used at this time. The token number is multiplied by 2 to calculate the offset in the dispatch table. This is done with a bit shift, but the result is only one byte and the carry is lost. It's a trade off for speed. It still leaves room for 38 new tokens, and I'd like to reserve $EF for future expansion. (Two byte tokens could be a possibility in the future)
Subscribe to:
Posts (Atom)