Which Is More Compact on the Tandy Color Computer -- Machine Code or BASIC?

A perennial question on one of the Tandy/Radio Shack Color Computer FaceBook groups:

Is machine code or BASIC more compact?

The answer is not simple, so I'm going to blog it.

The first question is, which BASIC?

BASIC compilers convert the BASIC program source to machine code (or assembly language, which is pretty much functionally equivalent to machine code). So comparing the compactness of BASIC compilers to machine code is basically just analyzing the ability of the compiler to produce efficient code.

Some BASIC interpreters directly interpret from the program text. This tends not to be very compact, since you're the program is just the text stored. But it may well be more compact than the machine code produced by a simplistic compiler or a programmer who isn't very fluent in the processor and its machine/assembly language.

Other BASIC interpreters parse the source text and compile it to high-level byte codes defined by the interpreter, storing the stream of byte codes, usually with the comments. Whether the stored byte-code stream is compact or not depends to a large extent on how well the byte code is designed.

Compared to most CPU machine codes, the byte-code streams can be rather compact.

But the comments that get stored with the byte-code streams can result in a stored program that is not compact. In fact, the better the comments, the fatter the stored program.

But there's more! (heh)

The 6809 in the Tandy/Radio Shack Color Computer has a very advanced machine code which is essentially equivalent in expressiveness to a well-designed byte code.

So 6809 machine code tends to be compact.

Aaaand the BASIC interpreter in the Color Computer is one of Microsoft's. Microsoft developed a method of mechanically projecting their 8080 BASIC on other CPU architectures, which resulted in quickly done implementations that basically ignored many of the special features of other processors and wasted a lot of code and cycles emulating the BASIC run-time that Bill and Paul hacked together for the 8080.

So, even though the BASIC in the Color Computer is a byte-code interpreter, it's not necessarily all that compact. 

So the general conclusion is that you really don't want to ask the question. Just learn both as tools.

But, there's MORE!

The Color Computer does not have a separate BIOS like the IBM PC 5150 does.

It has some routines that can be used more-or-less independently of BASIC, specifically the Input Character and Output Character routines. If you have DOS Extended Basic plugged in (via the floppy controller cartridge), the disk input and output routines can also be used, with some care, somewhat independently from BASIC.

That's code that you don't have to write yourself, and it (usually) exists in ROM in the Color Computers 1 & 2, and doesn't take up space in RAM.

That's not compact code, but it might save space.

If you are willing to let BASIC do a lot of the lifting, you can mix machine language code with BASIC code by reserving space for it via BASIC commands and reading the machine language code in from data statements, or reading the machine language parts in from disk or tape.

If you don't co-exist with BASIC, you have to write your own fundamental (especially, I/O) routines and include them with your programs -- unless you target the OS-9/6809 operating system (or the community rewrite, NitrOS-9), or Flex09, or one of the other operating systems available for the 6809.

And all the code you write yourself takes up space.

Really, targeting OS-9/6809 is probably the better idea, but I don't want to take the time to take that topic up in this post.

Bits of stuff you may want to know relative to this question, BASIC takes up 8K to 24K in the upper half of the 6809's 64K address space in the Color Computers 1 & 2. Your BASIC program and your machine code will have to share the lower 32K, or as much as is physically installed -- except for in the 64K mode, which I will explain a little bit after explaining what I just said.

• Color BASIC lives in 8K of ROM inside the computer, in the upper half of the address space (so it can boot the computer up on power on).
  
  
• Extended Color BASIC (ECB) is obtained by adding an 8K extension ROM internally. (Or, in some later models that come with ECB installed, there is only one 16K ROM.) The 8K of ECB extensions exist just above the boot ROM.
  
  
• Disk Extended Color BASIC (DECB) adds another 8K of ROM in the controller ROMpack, as I mentioned above.

It looks like this:

(Apologies for having incorrect order in the description above and an incorrect table here for the first couple of hours live.)

65504~65535	reserved, and interrupt vectors
65280~65503	I/O, control
57344~65279	(gap)
49152~57343	ECB (if present)
40960~49151	DECB ROM (if present)
32768~40959	Color BASIC/Boot/interrupt code
0~32767	RAM

(For those wondering, the addressing circuitry ghosts the top 32 bytes of the boot ROM from 40928 to 40959 up to 65504 to 65535 so that the vectors in the ROM that starts at 32768 can be read in response to interrupts.) 

The boot process points the video controller somewhere in the RAM, and 512 bytes (one quarter kilobyte) is used for the video buffer (text mode). BASIC reserves some of the RAM for strings and variables and some for storing code, does some other initialization, and shows you the copyright notice and OK prompt.

You can check how much physical RAM is installed by using the BASIC PRINT command, printing the value of the MEM pseudo-variable right after power-on:

PRINT MEM

What it should show you for various sizes of physical RAM installed:

• 4K RAM: PRINT MEM shows less than 4K, around 2K after boot, in Color BASIC only. ECB and DECB will not boot in 4K of RAM.
  
  
• 16K RAM: PRINT MEM shows between 4K and 16K, close to 16K for Color BASIC, a bit more than 8K for ECB, and a bit more than 6K for DECB.
  
  
• 32K RAM: PRINT MEM shows between 16K and 32K, close to 31K for Color BASIC, a bit over 24K for ECB, and a bit over 22K for DECB. 

These reservations of RAM can be adjusted by BASIC commands in your program (or just at the keyboard, when you're testing things).

Use the FILES command to adjust the number of file buffers.

Use the CLEAR command to specify how much string variable/space you want, and what you want BASIC to respect as the top of RAM. For instance, if you want 2000 bytes for variables and strings, and you want to put your machine language routines at 30000 and above, use

CLEAR 2000, 30000

(That's assuming you have 32K RAM or more.)

PRINT MEM after that, and you should get just over 18K, which BASIC will use to store the program in.

(I think that's the way it worked.)

Now, if you want to leave BASIC completely behind, using your own I/O routines and all, you don't really have to care how much memory BASIC thinks is left over. You only have to pay attention to where the video buffer is. But then you have to include your own I/O routines with the code, and they do take space (and time to write).

(But you also need to pay attention to the interrupt time operations of the machine.) 

You can get information on how to determine where the video buffer is and such from EDTASM+ or DISK EDTASM manuals and other sources.

Now, I mentioned the 64K RAM mode. You can install 64K of RAM in a Color Computer 1 or 2 (with some physical modifications on the mainboard, instructions are available in various places if yours doesn't have the expansions already installed). But Microsoft's BASIC will only use 32K of it.

How you get access to the full 64K is to use OS-9/6809. And leave Microsoft BASIC behind. 

:)

Or, you can load a (machine language) routine to hit the Page Switch bit to map the physically high half of RAM low, copy the ROMs to the RAM, flip the page switch back so that the code from the ROMs is in place for the next interrupt, and you're in business, running the ROM code out of RAM.

Unfortunately, Microsoft BASIC still doesn't want to let you set the limit to BASIC above (a hundred bytes or so below) 32K. But you do end up with some RAM in the upper half that can be used for machine code.

There are patches, modified BASICs and 3rd party BASICs that let you get around the 32K limit, finding them is an exercise for the reader.

Then there is the Color Computer 3. The smallest configuration for the Color Computer 3 is 128K. That's bigger than the 6809 can address by itself, of course. The Color Computer 3 has a replacement for the SAM (and VDG) called the GIME, which provides the means of bank switching the RAM around in 8K chunks, and that's how it can access more memory.

The Color Computer 3 boots from the ROMs, copies the ROM to RAM, and still leaves you with only 32K for BASIC. Except that the new version of BASIC provides for wider text screens, higher resolutions, and more colors, managing the video memory for you. All of this uses the expanded memory, and leaves the conventional memory available for your program. So it's definitely worth the upgrade.

On the other hand, OS-9/6809 level 2 or NitrOS-9 will take care of the bank switching for you, if you use that, letting you use more of the expanded RAM space for your own code.

I really should do a more complete version of this, I supposed, with diagrams and coding examples, and an explanation of how to run OS-9, but I really don't feel like I can afford the time this week or next. I have to take care of some government paperwork.

So, the conclusion --

If you are needing to squeeze functionality into a tight space, the question isn't really machine code vs. BASIC. 

It's figuring out what you want to do with which -- and the fun in doing that is why you are doing retro in the first place, isn't it?