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.
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“:
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…
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).
The value doesn’t have to be set to 0. Would there be a faster way using something like a STA or similar?
Exactly. STA or STB will work just fine. Doesn’t matter what’s in the registers.
And less clock cycles? STA 65497 versus CLR 65497?
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 …