2017 RetroChallenge Entry
Introduction
My entry into the 2017 RetroChallenge is to update the Tandy MC-10 BASIC ROM to include the ELSE keyword and to improve compatibility with Color BASIC from Tandy's Color Computer, and to provide some performance optimizations. A ROM image and documentation will be provided at the end of the project.
Backround
Tandy introduced the MC-10 in 1983 as a competitor to a series of very inexpensive entry level 8 bit computers. This includes the Sinclair ZX-80, ZX-81, TS-1000, TS-1500, etc... that had a lot of sales simply because they were the least expensive computers on the market at the time. The MC-10 was marketed a starter computer. Something a person could learn on before moving to a more advanced computer. Advertising usually involved kids. So the kids could learn on this while mom and dad used the more powerful Color Computer or other Tandy computer I presume.
The MC-10 has some similarities to the Tandy Color Computer. It uses a Motorola 6803 microcontroller as the CPU which is partially source compatible with the Color Computer's 6809 CPU, a 6847 Video Display Generator, and a compatible cassette tape storage format. The MC-10's BASIC is also almost identical to Color BASIC on the Color Computer, with the exception of the ELSE keyword which is absent from the MC-10.
One of the key cost saving measures of the MC-10 was limiting the BASIC ROM to 8K. Anything that wouldn't fit in 8K had to be left out. The ELSE keyword was probably omitted because it was also left out of 6502 versions of Microsoft BASIC made prior to 1983. Programs written in Color BASIC could be typed into the MC-10 and run without change as long as they didn't use ELSE, didn't directly access hardware, didn't include embedded machine code, and did not exceed the size of RAM. Of all of those conditions, ELSE is the most likely to be a problem.
The ELSE keyword is also important to conserve memory and improve the speed of programs. It lets you place additional code on a single line that otherwise would require several lines to accomplish. One of the most time consuming tasks carried out by the BASIC interpreter is searching for line numbers. The fewer line numbers you have, the quicker the interpreter can find a line of code. It saves space because you don't need the additional overhead additional lines of code require such as line numbers, line terminators, etc...
The MC-10 has some similarities to the Tandy Color Computer. It uses a Motorola 6803 microcontroller as the CPU which is partially source compatible with the Color Computer's 6809 CPU, a 6847 Video Display Generator, and a compatible cassette tape storage format. The MC-10's BASIC is also almost identical to Color BASIC on the Color Computer, with the exception of the ELSE keyword which is absent from the MC-10.
One of the key cost saving measures of the MC-10 was limiting the BASIC ROM to 8K. Anything that wouldn't fit in 8K had to be left out. The ELSE keyword was probably omitted because it was also left out of 6502 versions of Microsoft BASIC made prior to 1983. Programs written in Color BASIC could be typed into the MC-10 and run without change as long as they didn't use ELSE, didn't directly access hardware, didn't include embedded machine code, and did not exceed the size of RAM. Of all of those conditions, ELSE is the most likely to be a problem.
The ELSE keyword is also important to conserve memory and improve the speed of programs. It lets you place additional code on a single line that otherwise would require several lines to accomplish. One of the most time consuming tasks carried out by the BASIC interpreter is searching for line numbers. The fewer line numbers you have, the quicker the interpreter can find a line of code. It saves space because you don't need the additional overhead additional lines of code require such as line numbers, line terminators, etc...
Goals
The first goal is to add support for ELSE keyword to the MC-10 ROM. There really isn't room to add any other keywords. Examination of the MC-10 ROM disassembly, and the disassembly of the Color BASIC ROM reveals there needs to be 60 or more bytes of code for the IF keywords handler, and several bytes for the new keyword. Some of that space will be gained by removing two "Easter eggs" Microsoft placed in the code, and removal of the programmer's name which is in reverse towards the end of the ROM. The existing IF handler takes up several more bytes. However, the total comes up a few bytes short for the new code. This means some code will need to be optimized for size before the ELSE code can be added.
The second goal is speed optimization of the interpreter and math library. The BASIC in the MC-10 appears to have been derived from the earlier 6800 Microsoft BASIC. One of the enhancements the 6803 offers over the 6800, is the ability to combine the A and B registers to for a 16 bit D register. This can reduce the number of instructions required to perform many operations. While the interpreter seems to take advantage of the D register, the math library appears to be the same as the 6800 version of Microsoft BASIC. Replacing some of the 8 bit instructions with 16 bit instructions will make the code faster, and some of it will be smaller which should help with the first goal. Speed improvements are likely to be small.
A bonus goal will be to fix other known bugs in the standard MC-10 ROM if time and space permits.
Limitations
MC-10 BASIC uses different tokens to represent the keywords in MC-10 BASIC, than are used in Color BASIC. This prevents the MC-10 from loading Color BASIC programs from tape unless they were saved in ASCII. Due to the amount of BASIC software that has been ported to the MC-10 in recent years, it is no longer practical to change the tokens to match Color BASIC.
Adding the ELSE keyword will require placing it to the end of the existing keyword table. Whatever the next available token is will be what we are stuck with. Unless MCX BASIC added ELSE into keyword table in the same spot, the tokenized BASIC code will not be able to run on MCX BASIC unless it doesn't use ELSE. I cannot change this. However, you will be able to save programs in ASCII format, and then load them into the other BASIC just like with Color BASIC.
Some additional RAM will need to be reserved to accommodate nested ELSE keyword handling, and to free up the B register so that the 16 bit D register can be used instead of just A.
The address of where code reside in the ROM is necessarily going to change. Any software that makes direct ROM calls could break. There just isn't enough ROM space to preserve exiting ROM call addresses. The vectors at the end f the ROM will point to the proper locations though. In the future I may be able to produce a ROM image with some optimizations that still preserve entry points to commonly used functions, it just won't be able to support all optimizations or the ELSE keyword.
Some of the largest speed gains in the math library can only be achieved by use of different algorithms. However, they will require larger code and are not an option. Also, one of the biggest gains would be through caching recently called line numbers. Sadly, there isn't enough space to do this either.
While the interpreter will support all the keywords of Color BASIC once this modification is complete, the changes will not let you type in every program for Color BASIC. The editor in the MC-10 uses a smaller input buffer than the one in Color BASIC, so some lines may be too long to type into the machine. The interpreter itself can still execute longer lines, once they are entered though.
Testing will be carried out using emulation for convenience, and to make it easier to make a side by side comparison. And due to the fact that the software for my EPROM burner isn't Windows 10 compatible. Since no I/O code will be changed, emulation should prove to be sufficient.
Note that most MC-10's have the ROM soldered to the motherboard and you either need to perform electronic surgery, or have to add an external expansion board. If you are lucky, your MC-10 may have a socketed ROM like I do.
While the interpreter will support all the keywords of Color BASIC once this modification is complete, the changes will not let you type in every program for Color BASIC. The editor in the MC-10 uses a smaller input buffer than the one in Color BASIC, so some lines may be too long to type into the machine. The interpreter itself can still execute longer lines, once they are entered though.
Testing will be carried out using emulation for convenience, and to make it easier to make a side by side comparison. And due to the fact that the software for my EPROM burner isn't Windows 10 compatible. Since no I/O code will be changed, emulation should prove to be sufficient.
Note that most MC-10's have the ROM soldered to the motherboard and you either need to perform electronic surgery, or have to add an external expansion board. If you are lucky, your MC-10 may have a socketed ROM like I do.
Milestones
A working ROM image built from the existing commented disassembly of the MC-10 ROM. This will serve as the baseline to add changes to.
Removal of the programmer's name, the Easter egg text and code. Add the initial ELSE handling code to see how much additional space will be required.
Identify possible optimizations and implement as many as are required to fit else in the ROM.
Generate a working ROM image with the ELSE keyword. This will only have as many optimizations as are required to fit in the ELSE keyword. Build the first release.
Identify additional optimizations and generate additional working ROM images for testing as optimizations are completed. Fix any bugs found in testing. This will be repeated until the end of the contest or until I can't find any more optimizations and all known bugs are fixed.
A working ROM image built from the existing commented disassembly of the MC-10 ROM. This will serve as the baseline to add changes to.
Removal of the programmer's name, the Easter egg text and code. Add the initial ELSE handling code to see how much additional space will be required.
Identify possible optimizations and implement as many as are required to fit else in the ROM.
Generate a working ROM image with the ELSE keyword. This will only have as many optimizations as are required to fit in the ELSE keyword. Build the first release.
Identify additional optimizations and generate additional working ROM images for testing as optimizations are completed. Fix any bugs found in testing. This will be repeated until the end of the contest or until I can't find any more optimizations and all known bugs are fixed.
No comments:
Post a Comment