After I dove into ELSE efficiency, and then dove into it a bit deeper, I realized one of the major things that slows down BASIC is having to scan to the end of the line in order to find the next line.
In part 7 of my Optimizing Color BASIC series, I noticed that a GOTO or GOSUB was much slower if there were things on the line after it:
10 GOTO 100:REM THIS GOES TO THE INPUT ROUTINE
When BASIC is searching for a line number, each line entry has a size which lets it skip ahead to the next line if the line number did not match. But, once BASIC is processing a line, it does not track that. If the parser gets one token in to a line and it has to GOTO somewhere else, it has to scan forward until it finds the end of the line, then it can start scanning line numbers and skipping lines again.
Thus, one should not put comments on the ends of lines. They have to be parsed through. It is much faster to put comments on their own lines, though that takes up a more memory since each new line number takes 5 bytes.
This is one of the reasons this…
30 IF Z=1 THEN 100 ELSE IF Z=2 THEN 200 ELSE IF Z=3 THEN 300 ELSE IF Z=4 THEN 400
…can be slower than…
30 IF Z=1 THEN 100
31 IF Z=2 THEN 200
32 IF Z=3 THEN 300
33 IF Z=4 THEN 400
In the first example, if Z=1, BASIC still has to scan through all the remaining bytes of the line until it finds the end. In the second example, BASIC gets the line number then is already at the end and can immediately start scanning.
Thus, to add to my previous ELSE discussion, we should stop doing this:
30 IF X=1 THEN X=X+1:GOTO 70
If X is NOT 1, BASIC still has to scan through the rest of the line before it can check whatever happens next. Instead, it ican be much faster to do this:
30 IF X=1 THEN 100
...
100 X=X+1:GOTO xxx
There is a caveat to this. Things in BASIC are quite predictable. This change makes it faster to get to line 100 to do the actual work (X=X+1). BUT, from line 100 it could be much slower to get back to the top if there were a bunch of lines before the target line. If it’s a GOTO near the top of the program, it’s fast. If it’s a loop around 500, and you try to GOTO 500, that could be much slower if it had to scan through all the lines from 10 to 499 to get there.
This is when organizing code locations comes in very important, but that is a discussion for another time.
But other than situations like that, this is faster way:
10 REM MAIN LOOP
20 REM GET Z OR WHATEVER
30 IF Z=1 THEN 100
31 IF Z=2 THEN 200
32 IF Z=3 THEN 300
33 IF Z=4 THEN 400
40 REM NO KEY, DO IDLE LOOP STUFF
50 GOTO 10
100 X=X+1:GOTO 10
200 X=X-1:GOTO 10
300 Y=Y+1:GOTO 10
400 Y=Y-1:GOTO 10
If Z=4, the code will get there much faster since there is less for it to scan through after each Z check.
The location of where the work is done (later in the program or back at the top) is the only thing that can make this slower (or faster). Once a program gets large enough, moving things around may help speed up certain things but will slow down other things. I guess, much like real estate, location matters.
I guess we can stop using ELSE, and stop doing work on IF lines. And that goes for things like this:
IF SC=1000 THEN LV=LV+1
At 1000 points, we get a new life! However, every time through that loop when SC is not 1000, BASIC has to skip over “THEN LV=LV+1”, wasting cycles. The savings would be huge over the life of that loop to just do:
IF SC=1000 THEN 1000
…and let 1000 handle LV=LV+1 and returning back with a GOTO. GOSUB might be better, but that might be slower for something like this since:
IF SC=1000 THEN GOSUB 1000
…has an extra token (and potentially spaces, if you use them for readability) versus:
IF SC=1000 THEN 1000
WHEN this code runs (SC=1000), it may be faster to GOSUB and RETURN than it would be to GOTO/GOTO. BUT, most of the time the main loop is running that code will not be called and parsing past the GOSUB will just be wasting time.
if (input(DIGITAL_IN1) == HIGH)
{
...
}
if (input(DIGITAL_IN2) == HIGH)
{
...
}
if (input(DIGITAL_IN3) == HIGH)
{
...
}
This code led me to having to open schematics and figure out what digital input 1, 2 and 3 where.
So I used the free CodeBlocks editor refactor “Rename Symbol” feature to change their names to:
if (input(ROBOT_ON_FIRE_IN1) == HIGH)
{
...
}
if (input(BATTERY_OVERLOAD_IN2) == HIGH)
{
...
}
if (input(DUST_BIN_FULL_IN3) == HIGH)
{
...
}
…but using names that made sense for my application ;-)
Someone must have thought it was important to include the input number (IN1, IN2 and IN3) — possibly so they would not need to look through defines to see what value goes to what input — so I kept those in my names.
But now, when I find this code months down the line, I’ll immediately know which function is most likely detecting that the robot is on fire.
05-20-2020: Fixed a few typos, added a few more sentences.
From wikipedia.com
Every since I first learned about the Max Headroom signal hijacking incident in 1987, I’ve been fascinated about it. There has been much coverage of this over the years, including some interesting “recreations” of behind-the-scenes footage.
There has even been a documentary about the incident. Here are some to check out:
However, one thing remains consistent when I watch videos that theorize on this, or read the REDDIT threads, etc. Most seem to think that this was an inside job (it probably was; would be the easiest explanation). But, most don’t seem to realize how much you could do with good home equipment back in the early 1980s, let alone towards the end of that decade.
1980s home video was better than folks think.
My first encounter with a home video recorder was one my father had — a huge, hulking machine with giant push buttons and a pop up tray to insert the VHS tape. This was around 1980 or 1981.
Over the years, he had all kinds of cool video equipment. We had an early video camera, which could hook to the VCR using an adapter box that would power the camera and turn it’s output into audio/video cables. This camera was an old-style camera that would leave streaks when you moved it past lights due to the way the image sensor worked. Early, ancient stuff!
Later he had a backpack-sized VHS unit that could be ran off a 12V power supply or battery, and we took it, and the external camera, to Walt Disney World in 1982. As a young teen, it took me and another kid to lug it around (one with the recorder strapped to him, and the other operating the camera). This was all consumer equipment.
He also had Betamax (then later a SuperBeta) equipment as well. Folks commenting don’t seem to remember that Beta was widespread for awhile — early video rental stores had both VHS and BETA movies available to rent.
HomeTV!
Before the FCC put and end to it, we had in-home TV stations! You could buy a box that would transmit video to a nearby TV. And by nearby, I mean down the block. My father would broadcast movies in the evenings and let the neighbors know so they could tune in and watch. And that TV transmitter box could be ran on batteries. I remember one Thanksgiving (? or maybe it was a Christmas ?) where I was walking around the festivities with the luggable VHS unit and camera, recording stuff while others watched what I was doing on the TV in the living room. I guess that was really cool, but it was all just normal stuff to me, having grown up around it.
And it kept getting better…
Each time my dad upgraded, the new equipment was even batter. I still have the full size SuperVHS camcorder my father gave me after he upgraded to 8mm video (and it still works!).
Back to Max
Back to the Max Headroom incident… a few things I want to say:
Often you say people say Max was autistic, or drunk, or just nervous. But why? It does not seem to have been a live recording. There is an edit in the middle of the video! At best, the first half could be live then they switch to a tape, or the first part could be a tape and they switch to live, but it would be much easier to just pre-record and hit PLAY on a VCR. Max may have been drunk, but the evidence suggests he wanted it that way or he could have just re-recorded everything.
The edit is often pointed out as being proof that he was a TV station insider because the edit is perfect. Look up “flying erase head.” You could buy VCRs that had this, and they would make seamless cuts from one recording to the next. They cost more, but you could buy a consumer recorder that had one. It was not anything magical or special. BUT, you didn’t even need one. That luggable portable VCR we had could often do really clean edits — even without a flying erase head! My dad edited so many productions using two of those units (including videos that ran at booths at boat shows, that I did computer graphics for, and even a travel video for the island of Belize, which I’d never heard of back then). We had another unit after that one which was not portable, but did edits so well I did STOP MOTION animation with it. Just a nice consumer VCR! You did NOT need professional equipment to get a clean edit.
As to how they hijacked the signal, TV and radio stations commonly had (and still do) their studios at one place, and beamed their broadcast signal to the remote transmitter. Theories say they were up on a tall building. But why? Every radio station remote with a MARTI unit could broadcast from car dealerships. Heck, the run down AM radio station I worked at in 1987 had one, and it was ancient. And TV stations would go “live” from remote events all the time from their news van. I think the folks who talked about a vehicle (why a van?) being used probably make more sense than climbing up a building. It would be far easier to just park somewhere near the receiving dish and beam a low power signal to it, but I only have experience with doing that with radio stations. (There would be a lot of other issues, since I believe the remote news van would be beaming a different type of signal to a special receiver, and would NOT be capable of sending in the broadcast signal.) But, getting a signal in between the studio and the remote transmitter location could be done from the ground. (Or from a building; but it seems far riskier to climb a building and set equipment up.)
In a city the size of Chicago, I have no doubt that cameras and transmitters and all kinds of video things were readily available to those who wanted them. The only magic part here is the equipment that was used to overpower the TV station’s broadcast signal. An insider would have information, but folks could buy a lot of used equipment like this even back then (before eBay). The requirement to have need a license to operate it did not prevent you from buying it. (Anyone could by a HAM radio, but it was illegal to use it without a license, for example, and we had a place where I grew up that sold police radios and such.)
So who knows. Insider (or at least someone from the industry) makes sense. HAM radio/electronics hobbyists? Sure, why not. But I wish folks would drop the claims of the clean edit as proof it was someone with professional equipment. At least the Oddity guy talked about it looking like it was on a VHS unit (though that was just because of the poor picture quality — the fact that it did such a lean edit shows it would have been a higher quality machine).
I sure hope one day we hear the story behind this event.
My recent return to exploring my old Commodore VIC-20 code has reminded me about the main reason I jumped ship to a Radio Shack TRS-80 Color Computer: Extended Color BASIC. The older CBM BASIC V2 used by the VIC was missing keywords like ELSE, and had no functions for graphics or sounds. While I am having a blast re-learning how to program VIC-20 games, I sure do miss things like ELSE.
But should I?
IF/THEN/ELSE versus IF/THEN versus ON/GOTO
Pop quiz time! Suppose you were trying to determine if you needed to move a game character up, down, left or right. Which is the faster way to handle four choices?
30 IF Z=1 THEN 100 ELSE IF Z=2 THEN 200 ELSE IF Z=3 THEN 400 ELSE IF Z=4 THEN 500
…or…
30 IF Z=1 THEN 100
31 IF Z=2 THEN 200
32 IF Z=3 THEN 400
33 IF Z=4 THEN 500
Of course, if the values were only 1, 2, 3 and 4, you wouldn’t do either. Instead, you might just do:
ON Z GOTO 100,200,300,400
…but for the sake of this question, assume the values are not in any kind of order that allows you to do that.
IF/THEN/Work/ELSE versus IF/THEN/WORK
Suppose you were a junior high kid learning to program and you wanted to update some player X/Y positions based on keyboard input. Which one of these would be faster?
30 IF Z=1 THEN X=X+1 ELSE IF Z=2 THEN X=X-1 IF Z=3 THEN Y=Y+1 IF Z=4 THEN Y=Y-1
…versus…
30 IF Z=1 THEN X=X+1
31 IF Z=2 THEN X=X-1
32 IF Z=3 THEN Y=Y+1
33 IF Z=4 THEN Y=Y-1
All is not fair
I should point out that the speed it takes to run these snippets depends on the value of Z. For the sake of this article, let’s assume no key is pressed, so Z is set to something that is not 1, 2, 3 or 4.
Obviously, when there are four IFs in a row (either in a single line with ELSE, or on separate lines), the order of the checks determines how fast you get to each one. If Z is 1, and that is the first IF check, that happens faster than if Z is 4 and the code has to check against 1, 2 and 3 before finally checking against 4.
The same thing applies in languages that use switch/case type logic, so the things that need to be the fastest or happen most often should be at the top of the list and checked before things that happen less often.
Because of this, to be fair, we should also check best case (Z=1) and worst case (Z=4) and see what that does.
Benchmarking going to a line
In my benchmark program, this one counted to 954:
0 REM elsetst1.bas '954
5 DIM TE,TM,B,A,TT
10 FORA=0TO3:TIMER=0:TM=TIMER
20 FORB=0TO1000
30 IF Z=1 THEN 100 ELSE IF Z=2 THEN 200 ELSE IF Z=3 THEN 400 ELSE IF Z=4 THEN 500
70 NEXT
80 TE=TIMER-TM:PRINTA,TE
90 TT=TT+TE:NEXT:PRINTTT/A:END
And this one was a tiny bit faster. It counted to 942:
0 REM elsetst1.bas '942
5 DIM TE,TM,B,A,TT
10 FORA=0TO3:TIMER=0:TM=TIMER
20 FORB=0TO1000
30 IF Z=1 THEN 100
31 IF Z=2 THEN 200
32 IF Z=3 THEN 300
33 IF Z=4 THEN 400
70 NEXT
80 TE=TIMER-TM:PRINTA,TE
90 TT=TT+TE:NEXT:PRINTTT/A:END
Thus, using ELSE was a bit worse if none of the conditions were true.
IF we could have used ON/GOTO, that would be blazing at 253!
0 REM elsetst3.bas '253
5 DIM TE,TM,B,A,TT
10 FORA=0TO3:TIMER=0:TM=TIMER
20 FORB=0TO1000
30 ON Z GOTO 100,200,300,400
70 NEXT
80 TE=TIMER-TM:PRINTA,TE
90 TT=TT+TE:NEXT:PRINTTT/A:END
But I said we couldn’t, because I changed the rules to “do work” rather than “go to a line.”
Benchmarking doing work
Doing work with ELSE clocked in at 601:
0 REM elsetst4.bas '601
5 DIM TE,TM,B,A,TT
10 FORA=0TO3:TIMER=0:TM=TIMER
20 FORB=0TO1000
30 IF Z=1 THEN X=X+1 ELSE IF Z=2 THEN X=X-1 IF Z=3 THEN Y=Y+1 IF Z=4 THEN Y=Y-1
70 NEXT
80 TE=TIMER-TM:PRINTA,TE
90 TT=TT+TE:NEXT:PRINTTT/A:END
Since ELSE was slower to go to a line, I thought maybe it would be here, too, but instead, splitting the statements was slower. This one reports 963:
0 REM elsetst5.bas '963
5 DIM TE,TM,B,A,TT
10 FORA=0TO3:TIMER=0:TM=TIMER
20 FORB=0TO1000
30 IF Z=1 THEN X=X+1
31 IF Z=2 THEN X=X-1
32 IF Z=3 THEN Y=Y+1
33 IF Z=4 THEN Y=Y-1
70 NEXT
80 TE=TIMER-TM:PRINTA,TE
90 TT=TT+TE:NEXT:PRINTTT/A:END
It seems like ELSE has its place, but not for just going to a line.
Best versus Worst: FIGHT!
Let’s try some best and worst cases now. For this test, I’ll resolve the jumps to lines 100, 200, 300 and 400 by adding this:
100 GOTO 70
200 GOTO 70
300 GOTO 70
400 GOTO 70
That will greatly slow things down since we have to search forward to the new line, then it has to start back at the top of the program and search forward to find line 70. BUT, it will be consistent from test to test. I’ll add a “6 Z=1” or “6 Z=4” line.
If you are using IF to go to some code, ON/GOTO is the fastest, following by separate lines. Even in the worst case, separate lines are still a tiny bit faster, which surprised me. I suspect it’s the time it takes to parse the ELSE versus a new line number. Retesting with all the spaces removed might change the results and make them closer.
But it does look like we need to stop doing “IF X=Y THEN ZZZ ELSE IF X=Y THEN ZZZ ELSE” unless we really need the extra bytes ELSE saves over a new line number.
And if you are trying to do work, ELSE seems substantially faster than separate line numbers. But, in both cases, best and worst case are very close. I believe this is a benchmark issue, since the time to scan a few lines is tiny compared to the time it takes to do something like “X=X+1”, and both best and worst case do the same amount of work. A better test would need to be performed.
Bonus
There is a way to speed up the separate line statements when doing work, especially for better case. Consider this:
0 REM elsetst6.bas '1034
5 DIM TE,TM,B,A,TT
10 FORA=0TO3:TIMER=0:TM=TIMER
20 FORB=0TO1000
30 IF Z=1 THEN X=X+1:GOTO 70
31 IF Z=2 THEN X=X-1:GOTO 70
32 IF Z=3 THEN Y=Y+1:GOTO 70
33 IF Z=4 THEN Y=Y-1
70 NEXT
80 TE=TIMER-TM:PRINTA,TE
90 TT=TT+TE:NEXT:PRINTTT/A:END
By adding the GOTO, if line 30 is satisfied (Z=1), the parser can start searching for line 70 without having to do the check against Z three more times. But, when a case is not satisfied, it now has to parse through the GOTO token and a line number to find the end of the line, meaning that for worst case (Z=4) it should be a bit slower.
It looks like there’s a significant improvement for best case, and a slight decrease in performance for worst case (the overhead of skipping more characters to find the end of the line for the false conditions).
The more you know…
I guess I am learning quite a bit by revisiting the VIC-20 and having to do things without ELSE.
I got stuck on my multi-part Sky-Ape-Er dissection tangent, so I thought I’d do something different for today’s VIC-20 Tuesday.
The VIC-20 uses programmable character based graphics, You can change the pixels that make up a letter “A” to be a small 8×8 icon of a spaceship, for instance. But, when you move that letter A to different spots on the screen, it jumps 8 pixels at a time making movement quite jerky (as demonstrated by all my VIC-20 programs):
Since I don’t have time to write a full article at the moment, I’ll share this small VIC-20 program and come back to discuss what it is doing, and why it is doing it, later.
30 print"{clear}{reverse on}frames:"
60 for c=0 to 7:print chr$(65+c);chr$(73+c):print:next
70 gosub 950
100 poke 36869,255
105 rem
108 rem go thru each row of the character
109 rem
110 for ln=0 to 7
115 rem
118 rem read value, multiply by 256 to make 16-bits
119 rem
120 read v:v=v*256
125 rem
128 rem go thru each frame character
129 rem
130 for ch=0 to 7
135 rem
138 rem split 16-bit value into 8-bit values
139 rem
140 b1=int(v/256)
150 b2=v-(b1*256)
155 rem
158 rem poke shifted value in each charater
159 rem
160 poke 7176+ch*8+ln,b1
170 poke 7176+ch*8+ln+64,b2
175 rem
178 rem shift 16-bit value to the right one bit
179 rem
180 v=v/2
190 next
200 next
210 gosub 950
900 poke 36869,240:poke 198,0
910 end
950 get a$:if a$="" then 950
960 return
1000 DATA 60,126,255,255,255,255,126,60
More comments from the first ELSE article… First, MiaM chimes in:
MiaM:
You could also split that to two separate statements. One handling K=17 case, and then do ON K-38 GOTO 50,x,30 where x is just the line following the ON GOTO line.
don’t know about speed but you could also try ON K-16 GOTO 40,x,x,x,x,x,x,x,x,x,x,x,x,x,x,x,x,x,x,x,x,x,50,x,x,30 (also where x is the following line)
MiaM
In my example, I was getting keypress values back that represented left (17), right (39) and jump (41). By filling the ON/GOTO/GOSUB with bogus line values where the gaps are, you can now use ON/GOTO for non-sequential values. But, if the first number expected was a 17, that would be 17 dummy values at the start. Mia’s approach is to subtract that starting value, eliminating the need for 16 dummy values. Clever!
Clever, sure. But can it be benchmarked?
So how bad is this with speed? Let’s find out.
First, for the dummy lines we will just put nothing between the commas. That will be parsed as a zero, which is bad if any of those values are hit since going to 0 would restart the program, but since we are just testing and can control the value, it will give us the fastest way to parse a long ON/GOTO/GOSUB. Using real lines numbers will only be slower.
0 REM ONMIAM.BAS
5 DIM TE,TM,B,A,TT
6 K=17 'BEST CASE
10 FORA=0TO3:TIMER=0:TM=TIMER
20 FORB=0TO1000
30 ON K-16 GOTO 100,,,,,,,,,,,,,,,,,,,,,,200,,300
70 NEXT
80 TE=TIMER-TM:PRINTA,TE
90 TT=TT+TE:NEXT:PRINTTT/A:END
100 REM LEFT
110 GOTO70
200 REM RIGHT
210 GOTO70
300 REM JUMP
310 GOTO70
Best case for the first target gives me 590. Not bad!
Trying again with “K=41” for worst case gives us 664. Still not terrible.
How does this rank against manual IF/THENs like this?
0 REM ONMIAM2.BAS
5 DIM TE,TM,B,A,TT
6 K=17 'BEST CASE
10 FORA=0TO3:TIMER=0:TM=TIMER
20 FORB=0TO1000
30 IF K=17 THEN 100:GOTO 70
40 IF K=39 THEN 200:GOTO 70
50 IF K=41 THEN 300
70 NEXT
80 TE=TIMER-TM:PRINTA,TE
90 TT=TT+TE:NEXT:PRINTTT/A:END
100 REM LEFT
110 GOTO70
200 REM RIGHT
210 GOTO70
300 REM JUMP
310 GOTO70
Best case (17) reports 504 and worst case (41) reports 1128. Can there really be that much more overhead to skip two extra IF/THENs? It seems so. In this example, the long ON/GOTO is faster in worst case. Interesting. If worst case is a button not used that often (“smart bomb”), IF/THEN may be the best option, but if all buttons are used equally, there’s probably a point where a long ON/GOTO makes more sense.
But wait … there’s more!
Rob provided a suggestion about using an array:
Yep, could also do something like Dim C(256) C(17)=1:C(39)=2:C(41)=3 … ON C(K) GOSUB 20,30,40 etc. But that’s probably a bit memory hungry.
Rob
Rob’s idea of using an array to translate the non-sequential values into sequential numbers is a fun one. It uses more memory, and trades the time it takes to do an array lookup for the time it takes to parse a long ON/GOTO/GOSUB line.
Let’s try:
0 REM ONMIAM2.BAS
5 DIM TE,TM,B,A,TT
6 K=17 'BEST CASE
7 DIMK(41):K(17)=1:K(39)=2:K(41)=41
10 FORA=0TO3:TIMER=0:TM=TIMER
20 FORB=0TO1000
30 ON K(K) GOTO 100,200,300
70 NEXT
80 TE=TIMER-TM:PRINTA,TE
90 TT=TT+TE:NEXT:PRINTTT/A:END
100 REM LEFT
110 GOTO70
200 REM RIGHT
210 GOTO70
300 REM JUMP
310 GOTO70
Since the largest value we need to check for is 41, I did a DIM K(41). That will allow for values from 0 to 41.
Best case (17) gives us 432! Faster than the manual IF/THEN check!
Worse case (41) gives us 432 … Really? ON/GOTO is really fast with just a few choices. It would be slower if there were dozens and you wanted the one at the end.
The downside of this approach is the memory it took for an array of 42 (0-41) variables. Doing something like this:
NEW:CLEAR
PRINT MEM
DIM K(41)
PRINT MEM
…shows me 22823 and 22606. That’s 217 bytes being taken by the 42 K array entries. (There is an entry reserved for the array itself, then each array element takes 5 bytes, I believe. It’s been awhile since I wrote my String Theory articles which I think looked into how variables are stored.)
This may be the fastest approach if you have a few hundred bytes available to use for this. On a VIC-20 with 3583 bytes free on startup, if I had memory left when I was done with my normal IF/THEN version, I could retrofit it with this approach and use that extra available RAM to speed up my program a tad.
Very cool.
Thanks to MiaM and Rob for these interesting ideas.
Is it really VIC-20 Tuesday again? Okay, then. Let’s get started…
The theory so far…
When we last left off, I had just described my theory about how my prototype Sky-Ape-Er game loaded as just one file which contained a custom character set — without being contained in DATA statements or anywhere in the BASIC code.
My theory was that I modified BASIC’s “start of variables” pointer (which normally points to just past the end of the BASIC code) so it was after the memory where the custom characters were stored. When saved, the file would contain the entire range of memory including those custom characters. When the program was LOADed and ran, the first thing it had to do was set the “start of variables” pointer back to where it needed to be, just after the BASIC code.
Today I want to test that theory by trying to create a standalone BASIC program that contains custom character set data. I am going to use the excellent CBM prg Studio development environment to make a BASIC project that will have three things:
A custom character set. I will use the editor to export the characters out as DATA statements into a BASIC file.
That new file will be turned in to a program that will READ the DATA statements and POKE the values into RAM memory.
Finally, I will have a simple test program that will do the necessary POKEs to enable RAM characters and animate them.
Since I haven’t owned a VIC-20 since 1983, I am going to do all of this in the VICE VIC-20 emulator. To do it like I did it back in 1982, I am going to use a virtual cassette tape for program storage. I could probably do this easier using an emulated disk drive, but never had a disk drive on my VIC-20 and I want to keep this as virtually real as possible.
Except for the whole part of using a Mac and virtual PC for development, of course.
Step 1: Custom characters and loader program.
Using CBM prg Studio’s character set editor, I created a few custom characters:
VIC-20 custom character set test in CBM prg Studio.
I then used the “Character Set -> Export -> To Listing” option to output the DATA statements containing those characters.
I then added the following code to load the DATA statements into memory, and display them to verify they work.
0 rem custom charset
1 rem protect chars
2 rem from basic.
3 REM set string end
4 POKE51,0:POKE52,28
5 REM set memory end
6 POKE55,0:POKE56,28
7 REM clear vars
8 CLR
10 for l=7168 to 7168+12*8-1
15 read v:poke l,v
20 next
25 rem clear 'space'
30 for l=7424 to 7432
35 poke l,0:next
40 print"{clear}{reverse on}charset:{reverse off}"
45 print" a b c d"
50 print" e g i"
55 print"@f@h@j@k@"
60 poke 36869,255
65 get a$
70 if a$="" then 65
75 poke 36869,240
80 print l and 255;int(l/256)
85 end
1000 DATA 255,2,4,8,16,32,255,255
1010 DATA 0,28,46,71,142,92,56,0
1020 DATA 16,40,68,98,118,62,28,8
1030 DATA 0,28,58,113,226,116,56,0
1040 DATA 16,56,124,110,70,34,20,8
1050 DATA 96,240,96,62,185,89,28,30
1060 DATA 189,68,132,66,33,0,255,255
1070 DATA 24,60,24,126,189,189,189,60
1080 DATA 189,36,36,36,102,0,255,255
1090 DATA 6,15,6,124,157,154,56,120
1100 DATA 189,34,33,66,132,0,255,255
1110 DATA 255,102,129,66,138,150,223,255
Here is what it is doing:
Lines 4 and 6 – These POKEs are used to protect the characters in memory so BASIC will not override them. They set the highest memory location that BASIC and strings can use. I set them to 7168, the address where the custom characters load.
Line 10 to 20 – FOR/NEXT loop of READ and POKE the first 8 bytes where character RAM will be. This is where the “@” symbol is (character 0).
Line 30 to 35 – These POKEs clear out the “space” character in the custom character set. I do this so my DATA statements don’t have to contain all the characters up to space.
Line 40 to 55 – Clear screen then print reverse text (which will still show up even after we switch to RAM character mode) and the custom characters.
Line 60 – Set VIC chip to use RAM starting at 7168 for custom characters. At this point, the screen will show my custom characters, and the reverse video should appear as normal text.
Line 65 and 70 – Wait for key to be pressed.
Line 75 – Set VIC chip to use normal ROM area for characters.
Line 80 – Print the two bytes that represent the last memory location used by the character set. These will be POKEd into 45 and 46 before SAVING the demo program later.
Line 85 – End.
Line 1000 to 1110 – Each line has eight bytes that make up a custom character.
Here is what it looks like when it runs:
VIC-20 custom character set demo.
Then when you press enter, it disables the custom characters and you will see it says “CHAR:” in reverse view with letters a-i and @ where the custom characters were. It then prints two numbers, which I need to write down. Those numbers represent the address of the end of the custom characters my test program uses.
I will build this into a “.prg” file, and then load that into VICE. Next, I will “Create and attach an empty tape image” (I called mine “Custom Char Demo.tap“) and then save this loader program to that virtual tape:
SAVE "CHAR SET LOAD"
Step 2: Program to use the custom characters.
The next part will be a standalone program that will make use of these characters. I am creating a simple demo where spinning bricks fall from the sky and a player character on a sidewalk below has to dodge them. Except nothing happens if a brick hits the player because this is just a demo.
Here is my demo program:
0 rem charset demo
1 REM set vars start
2 POKE45,104:POKE46,19
3 REM set string end
4 POKE51,0:POKE52,28
5 REM set memory end
6 POKE55,0:POKE56,28
7 REM clear vars
8 CLR
9 for l=7424 to 7432
10 poke l,0:next
11 REM charset in RAM
12 POKE 36869,255
13 rem
100 print "{clear}{down*20}";
105 print "@@@@@@@@@@@@@@@@@@@@@@";
110 for l=38400 to 38911:poke l,0:next
115 rem init bricks
120 for b=0 to 3:bl(b)=7680+rnd(1)*22+88*b:bc(b)=1+b:next
125 rem init player
130 p1=8109:p2=8131:pt=7:pb=8
135 rem main loop
140 pokep1,pt:pokep2,pb
145 for b=0 to 3:poke bl(b),32
150 bl(b)=bl(b)+22:if bl(b)>8120 then bl(b)=7680+rnd(1)*22
155 bc(b)=bc(b)+1:if bc(b)>4 then bc(b)=1
160 poke bl(b),bc(b)
165 next
170 get a$
175 if a$="a" then if p2>8119 then pokep1,32:pokep2,0:p1=p1-1:p2=p2-1:pt=5:pb=6:goto 140
180 if a$="s" then if p2<8141 then pokep1,32:pokep2,0:p1=p1+1:p2=p2+1:pt=9:pb=10:goto 140
185 if a$="q" then 510
190 pt=7:pb=8
195 goto 140
500 REM charset in ROM
510 POKE 36869,240
520 END
1000 PRINT PEEK(45);PEEK(46)
Here is what it is doing… Actually, I’ll skip the demo logic and just mention a few important things:
Line 1000 – This prints the programs’ current end (start of variables). Since I need the program to restore this when it loads (after being saved with the custom characters), I can load this program and “RUN 1000” to get those values. I then change the POKEs in line 2 to match those values. Thus, when the real program is loaded, it will fix those pointers which will get messed up by the SAVE process.
Thus, I would load this program into memory (but NOT run it) and do “RUN 1000” and note those numbers. I changed the POKEs on line 2 to match those values. Then I saved this after the “CHAR SET TEST” program as:
SAVE "CHAR SET TEST"
Step 3: Save the all-in-one test and charset file.
Now I reset the virtual VIC and rewind the virtual tape. Here are the steps:
LOAD and RUN the “CHAR SET LOAD” program to get the character set in memory. I make a note of the two numbers printed out at the end.
LOAD (but DO NOT run) the “CHAR SET TEST” program.
With the TEST program in memory, I do the following POKEs to change the end of BASIC pointer: POKE 45,X:POKE 46,Y …where X is the first number the loader program printed and Y is the second number the loader program printed.
I now can SAVE the test program and it should save all of the BASIC and continue saving until it gets to the end of RAM.
SAVE "CHAR SET DEMO"
Step 4: Test!
After a reboot, and rewind of the virtual tape, I try loading the “CHAR SET DEMO” program and running it…
VIC-20 error when loading my character set demo program.
Oh no! My theory is not correct. Something is still wrong. Running this program produces parts of the custom character, but not all. It’s clear I am off somewhere.
What am I doing wrong? I guess I’m gonna need a part 6. . .
Does anyone know a plug-in or method to convert a preformatted block into a code block? Since the Gutenberg editor was introduced, there has been a new type of block specially for code. All my old articles use with preformatted or a plug-in. I want to go in and clean them all up and use the current, modern WordPress features.
That might be a nice approach if the numbers were relatively close to each other, but at some point, adding a bunch of dummy numbers to the ON/GOTO line would take more time to parse than just using separate IF/THEN statements.
Arbitrary GOTO
My example was based on some VIC-20 code I wrote back in 1983. I was reading which key was currently being held down, and would get back three different values for the keys I was reading:
17 – ‘A’ key is pressed (LEFT)
42 – ‘S’ key is pressed (RIGHT)
39 – ‘F1’ key is pressed (JUMP)
I couldn’t use ON/GOTO for values 17, 42 and 39.
But Rob’s code does just that!
20 ON -(K=41)-2*(K=17)-3*(K=39) GOTO 30,40,50
In BASIC, any comparison returns a -1 if it is TRUE, or a 0 if it is FALSE:
PRINTing the result of a comparison in Color BASIC.
…so in Rob’s example, the checks in parenthesis will be turned in to either a -1 or a 0 based on the value of K.
If K is 41, then (K=42) will be (-1) and (K=17) and (K=39) will both be (0).
If K is 17, then (K=17) will be (-1) and (K=41) and (K=3) will both be (0).
If K is 39, then (K-39) will be (-1) and (K=42) and (K=17) will both be (0).
Let’s see what that does:
20 ON -(K=41)-2*(K=17)-3*(K=39) GOTO 30,40,50
K = 41 produces:
ON -(-1) - 2*(0) - 3*(0) GOTO 30,40,50
ON 1 - 0 - 0 GOTO 30,40,50
ON 1 GOTO 30,40,50
K-17 produces:
ON -(0) - 2*(-1) - 3*(0) GOTO 30,40,50
ON 0 - -2 - 0 GOTO 30,40,50
ON 2 GOTO 30,40,50
K-39 produces:
ON -(0) - 2*(0) - 3*(-1) GOTO 30,40,50
ON 0 - 0 - -3 GOTO 30,40,50
ON 3 GOTO 30,40,50
Fantastic! Subtracting a negative makes it a positive, and multiplying by zero makes zero.
Math rules! And it actually works:
0 REM robgoto.bas
10 INPUT "41, 17 OR 39";K
20 ON -(K=41)-2*(K=17)-3*(K=39) GOSUB 30,40,50
25 GOTO 10
30 PRINT "30":RETURN
40 PRINT "40":RETURN
50 PRINT "50":RETURN
Arbitrary ON/GOTO (tip by Rob).
Fantastic! What a great tip. Thanks, Rob!
Arbitrary benchmark
So of course, I now have to see how this compares to separate IF/THEN’s speed-wise. Let’s pull out the trusty benchmark test code and do a version for best case (first choice) and worst case (last choice) for each approach (Rob’s, and IF/THENs).
Arbitrary ON/GOSUB, best case:
0 REM robgoto1.bas
5 DIM TE,TM,B,A,TT
6 K=41
10 FORA=0TO3:TIMER=0:TM=TIMER
20 FORB=0TO1000
30 ON -(K=41)-2*(K=17)-3*(K=39) GOSUB 100,200,300
70 NEXT
80 TE=TIMER-TM:PRINTA,TE
90 TT=TT+TE:NEXT:PRINTTT/A:END
100 RETURN
200 RETURN
300 RETURN
This produces 1368.
Arbitrary ON/GOSUB, worse case:
0 REM robgoto2.bas
5 DIM TE,TM,B,A,TT
6 K=39
10 FORA=0TO3:TIMER=0:TM=TIMER
20 FORB=0TO1000
30 ON -(K=41)-2*(K=17)-3*(K=39) GOSUB 100,200,300
70 NEXT
80 TE=TIMER-TM:PRINTA,TE
90 TT=TT+TE:NEXT:PRINTTT/A:END
100 RETURN
200 RETURN
300 RETURN
This produces 1434
Separate IF/THEN/GOSUB, best case:
0 REM ongoto1.bas
5 DIM TE,TM,B,A,TT
6 K=41
10 FORA=0TO3:TIMER=0:TM=TIMER
20 FORB=0TO1000
30 IF K=41 THEN GOSUB 100:GOTO 70
40 IF K=17 THEN GOSUB 200:GOTO 70
50 IF K=39 THEN GOSUB 300
70 NEXT
80 TE=TIMER-TM:PRINTA,TE
90 TT=TT+TE:NEXT:PRINTTT/A:END
100 RETURN
200 RETURN
300 RETURN
This produces 518 – almost three times faster!
Separate IF/THEN/GOSUB, worse case:
0 REM ongoto2.bas
5 DIM TE,TM,B,A,TT
6 K=39
10 FORA=0TO3:TIMER=0:TM=TIMER
20 FORB=0TO1000
30 IF K=41 THEN GOSUB 100:GOTO 70
40 IF K=17 THEN GOSUB 200:GOTO 70
50 IF K=39 THEN GOSUB 300
70 NEXT
80 TE=TIMER-TM:PRINTA,TE
90 TT=TT+TE:NEXT:PRINTTT/A:END
100 RETURN
200 RETURN
300 RETURN
This produces 1098, meaning even worst case is still faster.
BUT, we are doing a bunch of number parsing and math here. We can’t do anything about the math, but on Color BASIC, we can change those decimal values to HEX and speed up that part. Let’s try that:
0 REM robgoto3.bas
5 DIM TE,TM,B,A,TT
6 K=41
10 FORA=0TO3:TIMER=0:TM=TIMER
20 FORB=0TO1000
30 ON -(K=&H29)-&H2*(K=&H11)-&H3*(K=&H27) GOSUB 100,200,300
70 NEXT
80 TE=TIMER-TM:PRINTA,TE
90 TT=TT+TE:NEXT:PRINTTT/A:END
100 RETURN
200 RETURN
300 RETURN
By switching the five integer values in line 30 one to HEX, the speed of best case goes from 1368 to 1150! That’s faster, but it still doesn’t beat 518 using separate IF/THEN/GOSUB.
We might be able to make this a bit faster by using variables, so lets try that:
0 REM robgoto4.bas
5 DIM TE,TM,B,A,TT
6 K=41
7 L=&H29:M=&H2:N=&H11:O=&H3:P=&H27
10 FORA=0TO3:TIMER=0:TM=TIMER
20 FORB=0TO1000
30 ON -(K=L)-M*(K=N)-O*(K=P) GOSUB 100,200,300
70 NEXT
80 TE=TIMER-TM:PRINTA,TE
90 TT=TT+TE:NEXT:PRINTTT/A:END
100 RETURN
200 RETURN
300 RETURN
This brings the time down slightly to 1092. Still not enough to beat the separate IF/THEN/GOSUB (and that could also be sped up slightly using HEX or variables).
Conclusion
This trick is very cool. From my calculations, it looks like it save code space, which could be very important on a low-memory system like a 4K CoCo or the 5K VIC-20. That alone might make this trick worth doing.
But for speed, such as a BASIC game, it looks like brute force IF/THEN may be a better approach.
It’s really nice to have options. I can’t wait for an opportunity to use this technique in something.
I have completed my code walk-through of one of my earliest computer programs, a Donkey Kong-inspired VIC-20 game called Sky-Ape-Er. But, the version I presented was not the only version of the game I created. I have dozens of saved copies of this game in various stages of completion, but one in particular stood out. It used completely different graphics.
Sky-Ape-Er: The Prototype
VIC-20 Sky-Ape-Er version 1, death screen.
VIC-20 Sky-Ape-Er version 1, screen 1.
VIC-20 Sky-Ape-Er version 1, screen 2.
VIC-20 Sky-Ape-Er version 1, screen 3.
As a reminder, here is what the graphics were later changed to in the release version:
VIC-20 Sky-Ape Er, screen 1.
VIC-20 Sky-Ape Er, screen 2.
VIC-20 Sky-Ape-Er, screen 3.
The ape was completely different, and the platform graphics were meant to resemble the ones used in the arcade game Donkey Kong. But why were there pinwheels? I have so many questions for my junior high self.
When I first uncovered these tapes I was unaware of how many variations of my programs were on them. When I started this article on my Sky-Ape-Er game, I discovered that the earlier version with different graphics was also using some different code — most notably in how it read the keyboard input.
I thought it might be fun to look at the programming choices I originally made, and speculate on why I changed them.
Sky-Ape-Er: The Mystery
The first thing I want to discuss is a mystery I am currently trying to solve. My VIC-20 games that used custom character sets seem to come in three forms:
DATA STATEMENTS
The BASIC program reads the character set from DATA statements and POKEs it into memory. This is what the Sky-Ape-Er INSTRUCTIONS program does. I believe these character sets may have been designed by the Eight by Eight Create program I previously mentioned. If true, I don’t envy my junior high self having to manually copy down the numbers to paper and type them in to my own program later. From the documentation:
“Once you have created, designed and examined enough characters, you can copy their associated numbers on paper to be used in any programs you make.”
Eight by Eight Create instruction from January 1983 Creative Computing magazine (Volume 9, Number 1), page 270.
Yipes.
LOADABLE CHARACTER SET
A standalone binary “program” of the custom character set that can be loaded into memory, presumably at the address of where the character data goes. I have found several programs called things like CHARS and TNTCH that do not have any BASIC code in them. I suspected these were character set data (especially TNTCH which was on the tape after the main program TNT) but I had no idea how to use them. I was finally able to see what was inside by importing them into the CBM prg Studio‘s characters set editor. CBM prg Studio is a Windows integrated development environment (IDE) for making Commodore programs in BASIC or assembly. It has some great features and is worth checking out.
VIC-20 Factory TNT character set in CBM prg Studio.
This let me see that these were indeed character sets, though my first attempt to import them had all the graphics off by a few lines. I needed to use an offset (bytes to skip in the file) of 2 for the characters to load properly. That told me that whatever type of file this was had some 2 byte header at the start (perhaps memory location where to load the data?).
ALL-IN-ONE PROGRAM WITH CHARACTER SET
And this is the mystery! My early prototype version of Sky-Ape-Er was just one program, and it loaded up with the custom character set. There was no font in DATA statements. There was no pre-loader that did it. It just loaded and “just worked.” I have no idea how I created this, nor do I know why, for the release version, I change it to use two programs and DATA statements.
Using a free hex editor, I opened the file and looked for the end of the BASIC program. I could tell it ended around byte 2612 because the last line was a “SYS xxxxx” command that would reboot the VIC-20. The xxxxx numeric value was visible as plain text in the tokenized BASIC file, so it was easy to spot.
VIC-20 .prg file in a HEX editor.
After this was a bunch more data. Somewhere in there must be the character set. But where? I decided to try opening the entire program file in the character set editor and using the 2612 offset where the BASIC program ended.
VIC-20 CBM prg Studio importing a .prg to find the embedded charset data.
Doing this showed garbage between the BASIC program and character data, but scrolling down let me visibly see where the font data began.
VIC-20 CBM prg Studio trying to find where character set data is in a .prg file.
I now knew that approximately 58 characters (each character is 8×8, so 8 bytes per) into the file was the start of the font data. A little math (which was hard) and some trial and error (which was easy) and I came up with 3073 as the offset to use from the stat of the .prg to where my custom characters were. I imported using that value and got this:
VIC-20 character set data imported from a .prg file.
Tada!
If I knew what the font data was to begin wish (from DATA statements), I could have just scanned the HEX file looking for those values. But I didn’t, so I couldn’t.
Now I have a BASIC file for the game, as well as a character set file in the CBM prg Studio editor. But how did I combine them together in the first place?
Where does the data go from here?
The clue is in these POKEs found on the first line of the program:
They reminded me of similar POKEs in Color BASIC that track where the program starts in memory as well as where variables and strings go. I expected CBM BASIC would be similar, so I went searching for a VIC-20 memory map.
I want to do a deep dive into this later, but for now, here are what those POKEs are doing:
*002D-002E 45-46 Pointer: Start of Variables
*0033-0034 51-52 Pointer: String storage (moving down)
*0037-0038 55-56 Pointer: Limit of memory
The “*” notes “Useful memory locations” in the memory map. I agree. I seem to be changing where variables and strings start, as well as where the end of memory is on startup.
Why was I changing the start of variables, the end of string storage, and limiting the end of BASIC? I have a theory, which parallels something I’ve done on the CoCo.
In Color BASIC, we use the CLEAR command to allocate more string space (“CLEAR 500” for 500 bytes for strings). It looks like CBM BASIC doesn’t do that, and allows strings to use as much memory as is available (the memory between the end of the BASIC program + variable arrays, and the limit of memory).
CLEAR can also limit how much memory BASIC can use (“CLEAR 200,&H3F00”). That’s useful when you are wanting to use some of that memory for machine language and don’t want BASIC to overwrite it. I am betting POKE 51/52 is like CLEAR x,XXXX.
VIC-20 Memory Map
To better visualize this, let’s take a quick look at where the 5K of RAM in the VIC-20 is located.
Hey, look at that! The memory range used by BASIC (4096-7679) is the “3583 BYTES FREE” value shown on the startup screen:
VIC-20 startup screen showing 3583 bytes free.
Notice the 3K gap (1024-4095) which is where the 3K RAM expansion cartridge goes if you have one. I never did, though I did have the Super Expander cartridge which gave extra memory as well as enhanced graphics and sound commands.
Side Note: When memory expansion cartridges are plugged in, more memory becomes available and some things shift around. But for this discussion, we will talk only about the stock 5K VIC-20. It was only in recent years that I learned the VIC-20 was a 5K computer. I’d always thought it was 4K. That now makes the weird 3K memory expansion make more sense, since that would boost it to a nice even 8K. But I digress…
Now let’s zoom in on just the memory BASIC is using:
When a new numeric variable is added, it goes into the Variables section, which grows larger downward. When a new array is added, it goes into the Arrays area (and likely the entries there point to the Variable) and it grows larger downward. When a string is added, it gets an entry in the Variable section (“A$”) which has a pointer into the actual string content in the Strings section, which grows upwards.
So why was I changing the start of variables, the end of string storage, and limiting the end of BASIC? I believe I was making BASIC think the program was larger than it really was so it would SAVE out (and thus LOAD back later) the program PLUS some custom character data. When the program would run, it would need to reset the pointers to be at the actual end of the BASIC program, and limit memory so BASIC did not write over the character data.
In order to explain this, we need to look at how the VIC-20 custom characters worked.
How the VIC-20 custom characters worked
The VIC-20 character set was 4K of data stored in ROM starting at 0x8000:
8000-83FF 32768-33791 Upper case and graphics
8400-87FF 33792-33815 Reversed upper case and graphics
8800-8BFF 33816-35839 Upper and lower case
8C00-8FFF 35840-36863 Reversed upper and lower case
Each character was 8 pixels wide (one byte) by 8 pixels tall (8 bytes total). There is room for 512 characters in that 4K. Normal printable ASCII characters are 0-127, so it looks like the Commodore PETASCII was similar, with 128 special Commodore characters per bank (128 characters * 8 bytes per character = 1024 bytes).
On power up, the VIC’s video chip is programmed to use the first of those four 1K blocks of ROM for its character set. There is a register with four bits that can be changed to select which of those four ROM blocks it uses, or point it to four 1K RAM blocks in RAM. By loading a character set in to one of those RAM areas and setting the register, the VIC will now display the custom character set rather than the one built in to the ROM. Here are the important four bits:
9005 36869 bits 0-3 start of character memory (default = 0)
bits 4-7 is rest of video address (default= F)
BITS 3,2,1,0 CM starting address
HEX DEC
0000 ROM 8000 32768
0001 8400 33792
0010 8800 34816
0011 8C00 35840
1000 RAM 0000 0000
1100 1000 4096
1101 1400 5120
1110 1800 6144
1111 1C00 7168
Memory location 36869 can be one of these 8 values:
0xF0 / 240 / 11110000 – Use 8000-83FF (Upper case and graphics)
0xF1 / 241 / 11110001 – Use 8400-87FF (Reversed upper case and graphics)
0xF2 / 242 / 11110010 – Use 8800-8BFF (Upper and lower case)
0xF3 / 243 / 11110011 – Use 8C00-8FFF (Reversed upper and lower case)
0xfc / 252 / 11111100 – Use 1000-13FF RAM area #1
0xfd / 253 / 11111101 – Use 1400-17FF RAM area #2
0xfe / 254 / 11111110 – Use 1800-1BFF RAM area #3
0xff / 255 / 11111111 – Use 1C00-1FFFF RAM area #4
The four RAM locations all are within the 4K that is used by BASIC and screen memory:
0x1000 – 0x1dff – 3583 bytes used by BASIC programs.
0x1e00 – 0x1fff – 512 bytes used by screen memory.
We can’t use RAM area #1 for characters because that is where our BASIC program is. If we kept our BASIC program and all its variables very small (1K, 0x1000-0x13FF), we could use area #2. But, it makes more sense to use area #4 and give as much memory as possible to BASIC.
In my programs I see POKE 36869,255 and POKE 36869,240. The first POKE makes the video chip start using characters in RAM starting at 0x1c00 (bit pattern 1111). This means a BASIC program and all its variables can’t be any larger than 3072 bytes (0x1000-0x1bff). The second poke switches the characters back to using the standard ROM location for uppercase and graphics characters (bit pattern 0000).
My Sky-Ape-Er INSTRUCTIONS program would READ character data and then POKE it into memory starting at 0x1c00 (7168). It then did POKE 36869,255 to start using them. To display a normal text screen, or at the end of the program, it would POKE 36869,240 to get back to the ROM character set. (This is the part I actually mostly remembered.)
I do want to point out that the character RAM area #4 overlaps with the screen memory:
0x1c00 – 0x1fff – Character RAM area #4.
0x1e00 – 0x1fff – 512 bytes used by screen memory.
This tells me that you really only have 0x1c00 to 0x1dff (7168-7679) for custom characters. That’s 512 bytes, and at 8 bytes per letter, there is only room for 64 custom characters. Assembly language programs that did not need BASIC could move things around and use one of the other blocks in its entirety, but this last block shares memory with the screen so not all of it can be used for character data.
Character sets
The PETSCII character set starts at zero with an “@” symbol, followed by the alphabet characters “A-Z” (1-26), then various punctuation and symbols (27-47), then numbers (48-57), then more punctuation and symbols (59-63). This covers the basic characters and uppercase alphabet just like standard ASCII does for characters 32-96. This means being limited to just 64 characters is not bad at all.
And, as I was working through this, I discovered why my Factory TNT game is not displaying the score correctly! I did not realize it also contained updated number characters (48-57) that I was not properly loading during my “restoration” of the game:
VIC-20 Factory TNT character set also remaps the numbers.
I’m so glad I am writing this article and figured that out. It was driving me mad!
But I digress…
Stay on target… Stay on target…
This means that you could have a BASIC program from 0x1000 to 0x1bff followed by custom character data from 0x1c00 to 0x1dff. If you had the characters in memory for your BASIC program to use, and you SAVEd your BASIC program, those custom characters would NOT be saved with it since BASIC doesn’t know anything about them.
But … you could lie to BASIC and tell it your BASIC program actually ENDS at 0x1dff, then when you SAVE it should write out the entire range of memory (0x1c00 to 0x1dff) thinking it’s just one large BASIC program…
Then, when you loaded it back it, BASIC would start loading it into memory at 0x1c00 and keep going until it got to the end of the program. You now have loaded memory that is part BASIC, and part character set!
But, if you tried to RUN it, you wouldn’t get very far because BASIC would think there is no memory left for variables. You would need to un-lie to BASIC and tell it where the program really ends, and do so without using varaibles.
