- 2021-12-15: Added screen shot of BASIC ROM assembly.
On the Radio Shack Color Computer, Extended Color BASIC added new commands to access high resolution graphics modes. The following modes of the CoCo’s Motoroal 6847 VDG chip (video display generator) were implemented:
- PMODE 0 – 128×96 2-color (1536 bytes)
- PMODE 1 – 128×96 4-color (3072 bytes)
- PMODE 2 – 128×192 2-color (3072 bytes)
- PMODE 3 – 128×192 4-color (6144 bytes)
- PMODE 4 – 256×192 2-color (6144 bytes)
Extended Color BASIC allows a program to allocate up to eight 1536 byte pages of memory for graphics. If you wanted to use a single 128×96 PMODE 0 screen, you would want to reserve on page of memory for it (PCLEAR 1). If you wanted to use a 256×192 PMODE 4 screen, you would want to reserve four pages of memory (PCLEAR 4).
In BASIC, you could reserve eight pages (PCLEAR 8), and then draw on eight different PMODE 0 screens and flip between them, creating simple page-flipping animation. It was amazingly fun back then.
But this isn’t an article about graphics (though now that I think about it, I really want to write one).
By default, BASIC reserves four pages of graphics memory (6144 bytes) which, I guess, saves a BASIC program from having to do “PCLEAR 4” in it before using PMODE 4. Proper BASIC programs always did the PCLEAR anyway just to make sure the memory was available (for instance, if you typed PCLEAR 1 before you ran, the program would error out if it was assuming PCLEAR 4 was available). There have always been bad programmers.
The point of this article is to point out that, by default, BASIC has 6K less memory available to it. On startup, a 32K or 64K disk-based CoCo shows 22823 bytes free to BASIC:
64K NOTE: The reason BASIC memory is the same for 32K and 64K is due to legacy designs. The 6809 processor can only address 16-bits of memory space (64K). The BASIC ROMs started in memory at $8000 (32768, the 32K halfway mark). This allowed the first 32K to be RAM for programs, and the upper 32K was for BASIC ROM, Extended BASIC ROM, Disk BASIC ROM and Program Pak ROMs. Early CoCo hackers figured out how to piggy-pack 32K RAM chips to get 64K RAM in a CoCo, but by default that RAM was “hidden” under the ROM address space. In assembly language, you could map out the ROMs and access the full 64K of RAM. But, since a BASIC program needed the BASIC ROMs, only the first 32K was available.
To get the most memory possible for BASIC we would want to not reserve any graphics pages. However, the PCLEAR command does not allow typing PCLEAR 0. The best we can do is PCLEAR 1, which still reserves 1536 bytes. Doing” PCLEAR 1″ and then “PRINT MEM” will show 27431 bytes free. I am not really sure why PCLEAR 0 was not implemented, but without it, there is always 1.5 K of memory wasted for BASIC programs that do not use high-resolution graphics.
However, it is very simple to achieve a PCLEAR 0 by using a few bytes of assembly language. The short program I use to do it is this:
This program reads the 9-byte assembly code and POKEs it in to memory, then EXECutes the routine. I chose to store it at memory location 1024, which is the start of the 32 column text screen. As a result, when it runs, it will put garbage on the first 9 characters of the screen. I just chose that memory since I knew no other program would use it (unless it was a temporary thing like this). If you understand the CoCo memory map, you can change that 1024 to any other safe location in memory and avoid having the text screen temporarily corrupted.
After running this, now a “PRINT MEM” will show 28967. Now we have 6144 bytes extra for our program! Big win.
However … 28K still isn’t quite the 32K we may have hoped for. This is because there is also memory reserved for the text screen (512 bytes, 1/2 K), cassette load buffers, BASIC input buffers, etc. There is additional memory reserved for Disk BASIC, so you actually have a bit more BASIC memory on a cassette-only system.
As you see above, 24871 bytes are available on a cassette-based CoCo on startup, which means there is about 2K of overhead to support Disk Extended Color BASIC. (Note to self: check these numbers.)
If we do the PCLEAR 0 on a cassette-based CoCo, we end up with 31015 bytes available to BASIC, and that is the most we can get (easily). If you do this:
…you will see what memory location your BASIC program starts at. After a PLCEAR 0 on a cassette-based CoCo, the value returned is 1537. The 32-column text screen is in memory from 1024 to 1536, meaning this is the very earliest in memory that a BASIC program can start. The only way to get more memory would be to extend the end, and we can’t because at the 32K mark, the BASIC ROMs begin. (Thus, 1537 to 32676 in memory is 31230, which is 215 bytes still missing. 200 bytes is reserved for strings, but a CLEAR 0 removes that, meaning there are only 15 bytes of BASIC overhead we can’t actually use.)
BONUS: Here is the nine bytes of assembly that my program POKEs in:
ldb #1 lda <$bc tfr d,y jmp >$96a3
Thanks to William Astle (Lost Wizard Enterprises, creator of LWTools) for translating my POKE bytes back in to the assembly code for me. It’ s been so long, I couldn’t remember what it was doing. In this case, it’s setting up the Y register and jumping in to a ROM routine that handles the PCLEAR, which I assume is being done to bypass the “?FC ERROR” check if the value of 0 is used from BASIC.
Here is the routine from Extended Color BASIC Unravelled:
Pingback: 64K TRS-80 CoCo memory test | Sub-Etha Software
Pingback: Color BASIC String Theory, part 2 | Sub-Etha Software
Pingback: Maximum Memory in Color BASIC – Vintage is the New Old
Interesting approach to achieve the PCLEAR 0 condition on the CoCo. I’ve always had used:
POKE 25,6:NEW [ENTER] on Extended Color BASIC and
POKE 25,14:POKE 3584,0:NEW [ENTER] for Disk Extended BASIC
I ran across POKE 25,6:NEW in my old 1980s notebook. That could not be done in a program since it would erase it. Also, I wonder if that would still let you do a PMODE with BASIC thinking it had four pages reserved. Now that makes me wonder if the assembly PCLEAR 0 disables those commands from working like a PCLEAR 1 would. More stuff to try!
What is 3584???
Now that is something I need to investigate… could be a memory map setting POKE. A SAM tweak location maybe?
3584 happens to be hex E00 which happens to be where the graphics pages start on Disk Basic with the default FILES settings in effect. It is the lowest multiple of 512 bytes that is above the end of the space used by Disk Basic for buffers and the like. (If you use a non-default FILES setting, that number can be quite a lot higher.)
If the BASIC text area is starting at $e01 (3585) the byte before must contain 0, since command RUN starts with the previous location (GETCCH, pointer $A5). The value 0, AKA end-of-line mark, is expected otherwise RUN will fail with ?SN ERROR. Especially in cases where some other data populated this area before one has to ensure that the first byte of the area contains the 0-value.
A basic compiler I’ve been using reserves an additional 512 bytes by changing the FILES configuration. Then it calls itself to run from the disk, where the 2nd time it detects it already did the PCLEAR 0.
IF PEEK(25)>12 THEN FILES 0,94:POKE 25,12:POKE 3072,0:RUN "COMPILER/BAS"
This is for Disk Extended Color Basic.
I expect if you know it’s a disk-only system, doing the POKE would be as good as a PCLEAR 0, before running something new. The actual PCLEAR 0 (if it was allowed in BASIC) would move/relocate variables and such safely, for running programs.
The FILES thing I need to look in to. I barely recall that command.
Pingback: Porting 10 PRINT RACER by 8-Bit Show And Tell to the CoCo | Sub-Etha Software
Pingback: Color BASIC String Theory, part 2 | Sub-Etha Software
Pingback: Online 6809 emulator with semi-MC6847 support | Sub-Etha Software
Pingback: Color BASIC info memory locations. | Sub-Etha Software
Pingback: CoCo ROM to RAM (64K test) – part 1 | Sub-Etha Software
Pingback: FILES command and memory in CoCo Disk BASIC | Sub-Etha Software