CoCo ROM to RAM (64K test) – part 2

See also: part 1 and part 2.

On a 64K Color Computer, the BASIC ROMs configure it so the first 32K is RAM and the second 32K is ROM. It is easy to change a memory location and cause the upper 32K to be RAM, too, but if you did that from BASIC you would suddenly find yourself without the ROM and would have a nice crash.

Machine language programs that did not rely on any ROM calls could enable the 64K RAM mode and use the full 64K memory as they wished.

At some point, someone was the first to figure out they could copy the ROMs in to RAM, and then switch to RAM mode. This would allow them to be running BASIC from RAM, and thus it would be possible to use POKEs to modify the BASIC code and do patches.

In an effort to see who first figured this out and published details, I did some searching…

March 1982 – Frank Hogg

I found something on page 18 of the March 1982 issue of Color Computer News. The article was called “MORE ON 64K by Frank Hogg of Frank Hogg Labs.

https://colorcomputerarchive.com/repo/Documents/Magazines/Color%20Computer%20News/Color%20Computer%20News%20%2307%20-%20March%201982.pdf

Last month we showed you how to access the other 32K in your Color Computer bringing it up to the full 64K, This month we’re going to discuss some additional uses for that memory, plus a program to copy the ROM Basic into RAM and run it there;

– Frank Hogg, Color Computer News, March 1982

Included was a BASIC program that loaded the machine code, with example POKEs used to modify BASIC (such as changing the PRINT command to be WRITE).

The assembly code was listed in comments:

1820 ' THE MACHINE LANGUAGE
1830 ' PROGRAM TO MOVE BASIC TO
1840 ' RAM IS AS FOLLOWS:
1850 '
1860 '
1870 ' EP   ORCC #$50 DIS. INTS.
1880 '      LDX #$8000 1ST ADDR.
1890 ' LOOP LDA ,X
1900 '      STA $FFDF MAP TYPE 1
1910 '      STA ,X+ IN RAM!
1920 '      STA $FFDE MAP TYPE 0
1930 '      CMPX #$FFOO LAST +1
1940 '      BNE LOOP
1950 '      STA $FFDF MAP TYPE 1
1960 '      ANDCC #$AF ENBL INTS
1970 '      RTS 

Was this the first such program published?

April 1983 – Frank Hogg revisted

Frank had a follow-up in the April 1983 issue, as well, on page 19. It looks like an article, but it was labeled as a paid ad called “64K KORNER“:

https://colorcomputerarchive.com/repo/Documents/Magazines/Color%20Computer%20News/Color%20Computer%20News%20%2319%20-%20April%201983.pdf

The code listed was the same, but with updated comments. He also added a copyright notice as well as a small standalone BASIC loader:

1 ' Copyright 1983 by Frank Hogg Permission to use is
2 ' given for all but commercial use.
10 CLEAR 999
20 DATA 26,80,190,128,0,183,255,222,166,128
30 DATA 183,255,223,167,31,140,224,0,37,241,57
40 FOR I=1 TO 21:READ A:A$=A$+CHR$(A):NEXT I
50 P=VARPTR(A$)+1
60 POKE P,126
70 EXEC P
80 PRINT "NOW IN RAM!"

Frank chose to store the machine language bytes as characters of a string. He then gets the pointer to the 5-byte string descriptor and adds one to it. That makes P point to the unused byte which is directly in front of the two byte address of the string in string space. The string descriptor looks like this:

        Addr of String in Mem
                 |
              +-----+
              |     |
[Siz] [N/A] [MSB] [LSB] [N/A]
        |
        P points here

He then POKEs a 126 at that P location, which I believe is a machine language JMP instructions. Then he EXECutes P, which makes for a very clever way to execute this code!

[Siz] [JMP] [MSB] [LSB] [N/A]

I would have done it the long way like this:

P=VARPTR(A$)
EXEC PEEK(P+2)*256+PEEK(P+3)

Frank did much better.

July 1987 – Rainbow article

Another ROM to RAM program showed up in the July 1987 Rainbow on page 97. Joseph Forgione submitted a small utility to change BASIC’s “OK” prompt to say “READY.” In included a short DRIVER.BAS program which was a ROM to RAM routine:

1 DATA 26,80,142,128,0,127,255,222,166,132,127,255,223,167,132,48,1,140,255,0,38,239,28,159,57
2 FORA=&HE00 TO &HE18:READX:POKEA,X:NEXTA:EXEC3584:POKE65503,0:PRINT"OS IS NOW IN RAM!"

I fed those bytes in to the 6809 Simulator at www.6809.uk to see what it looked like:

4000: 1A 50     ORCC  #$50
4002: 8E 80 00  LDX   #$8000
4005: 7F FF DE  CLR   $FFDE
4008: A6 84     LDA   ,X
400A: 7F FF DF  CLR   $FFDF
400D: A7 84     STA   ,X
400F: 30 01     LEAX  $01,X
4011: 8C FF 00  CMPX  #$FF00
4014: 26 EF     BNE   $4005
4016: 1C 9F     ANDCC #$9F
4018: 39        RTS

This is very similar to Hogg’s original, except instead of incrementing X when the byte is stored (STA ,X+) the author chose to not do that, and have a different instruction add one to X (LEAX $01,X). That makes it a few bytes larger and a few clock cycles slower, not that anyone would really notice.

Where did it come from?

I have yet to locate the one I used back on my CoCo 1, but it was probably from my pre-disk drive days and is on some old cassette tape somewhere. I had never seen Color Computer News, so my version probably came from Rainbow Magazine, or perhaps one of the few issues of Color Computer Magazine or Hot CoCo I picked up from the newstand. I was unable to locate anything obvious in the Rainbow indexes except that 1987 article.

Variations of this code seem to pop up, even to this day. In 2016, Juan Castro provided me a routine which I used in an earlier article about 64K. It was a faster one, that copied 6 bytes at a time instead of just one.

If anyone know who did this first (or at least was the first time it was in print somewhere), please leave a comment.

Until then, we’ll say it was Frank Hogg in March 1982.

Until next time…

5 thoughts on “CoCo ROM to RAM (64K test) – part 2

  1. Johann Klasek

    Not only the LEAX -1,X slows it down, also the CLR $FFDE and CLR $FFDF takes 2 cycles more each (CLR behaves as read-modify-write operations on memory).

    Reply
          1. Johann Klasek

            Yes, CLR is only fast in conjunction with register A or B. On memory locations it has the read-modify-write semantic (which is some kind of overkill because there is no need for the read part). It seems the CPU’s wiring for this opcode reuses the RMW “engine” for simplicity with the exception of overwriting the read cycle’s value by zero …

Leave a Reply to Johann KlasekCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.