Redefine the charset with 8K+ RAM

[LoadError]

I've been reading this: http://www.atarimagazines.com/compute/i ... _VIDEO.php

If I got it right, the only way to have a redefined (partial or complete) charset with an 8K (or more) configuration is to move up the start-of-BASIC to make room for the custom charset and the "new" screen, because the VIC chip can only see the first 8K of RAM and the BASIC user space must be contiguous. This in turn requires that the main program is launched by some kind of loader which will take care of shifting the start-of-BASIC and then launch the main program. Is this correct? Is there no way at all to avoid having this external loader?

[Mike]

Those old magazine articles tend to have their own share of errors, but here you actually misinterpreted the diagram on top of the aforementioned article:

the VIC chip can only see the first 8K of RAM

First of all, the VIC chip can only access the internal RAM ($0000..$03FF and $1000..$1FFF) and the character ROM. No external expansion of any kind is "visible" to VIC. This especially applies to the +3K RAM expander. Even though it maps to the $0400..$0FFF range and there are registers settings in VIC that would suggest it is possible to set screen or character base into that range, the RAM in the +3K expander cannot be accessed by the VIC chip due to hardware reasons.

Furthermore, the colour RAM ($9400..$97FF) has another "extra" path over 4 additional data bus lines into VIC. It can only be accessed as colour attribute data by VIC, not as text screen or character data (besides it's only 4 bits wide so that feature, even if it would exist, would be of limited value). Neither can VIC access its own registers, or VIA, or any other I/O in ($9000..$93FF and $9800..$9FFF) for text/character data, so the diagram is right with its caption "Danger I/O Chips! KEEP OUT!"

That being said, for bigger RAM expansions you'll need to make place for character set and text screen before the BASIC program. As you wrote, the most often method is using a boot loader. However, it is also possible to incorporate the character set together with the BASIC program into one binary. A BASIC stub at the original BASIC start will first change the BASIC start pointer and then re-issue a RUN command which starts the payload at the higher address.

Both methods have been discussed here on Denial in various threads. I'll give these two for examples: "Reorganising 8k RAM?", and "New release: 3 New Fonts for Your Vic".

More details are found here: How to reinit 16k expansion?

...

Sigh. That kind of questions should really go into a FAQ.

[LoadError]

Thanks for the explanation.
The confusion had arised mostly because of what is written in part I of that article, here: http://www.atarimagazines.com/compute/i ... _Video.php
"The chip sees only the character ROM, in blocks 0, 1, 2, and 3; and the lowest 8K of RAM (in blocks 8 to 15)".

I will study the links and experiment with the various options.

[Mike]

[...]and the lowest 8K of RAM (in blocks 8 to 15)

Yes, and this is clearly wrong. As I wrote in the preceding post, "blocks" 9 to 11 need to be excluded from that list.

Also, the designation of those 1K address ranges as "blocks" is a mis-nomer. Normally the use of blocks in the context of VIC-20 hardware referres to 8K address ranges numbered BLK0 ($0000..$1FFF) up to BLK7 ($E000..$FFFF). Especially, BLK1..BLK3 and BLK5 are addressed over chip select lines at the expansion port for RAM or ROM expansions.

[LoadError]

Let's assume the following: I will be using the 8K memory expansion (but the game must be able to run with the 16K expansion as well), I will load in RAM a total of 64 characters (26 letters, 10 numbers, the space, 4 reverse letters, 10 reverse numbers and 13 symbols), I will then replace the 13 symbols with my custom chars and I will leave the rest of the charset unchanged. My charset will take 512 bytes of RAM. I will relocate start-of-BASIC from 4608 to 5120, the screen from 4096 to 4608, and finally the custom charset to 4096.
This way I will have: charset; screen; BASIC, all contiguous in this order with no wasted space.
1) the loader will poke 43,1 then 44,20 then 5120,0 to move up start-of-BASIC to 5120
The main program will, in order:
2) poke 648,18 then 36869,204 (12*16+12) then 36866,150 to move the screen to 4608
3) copy the 64 characters from the ROM charset to the free space at 4096-4607
4) overwrite the 13 symbols with my custom chars
If the above is correct, which I hope, my only doubt would be: can I assemble a custom charset by copying chosen, contiguous or non contiguous chars from the ROM charset, or am I required to copy a contiguous set of chars? I don't need all the reverse letters so I was hoping to save some space. I have done a test but the result was unexpected, I can get the normal case letters but all the rest is mixed up. Whereas if I load the whole charset in RAM (2 KB) there is no problem.
Thanks and please bear with me...

[LoadError]

To make matter worse (or more interesting), even if all the above is correct, I've written my program in BASIC but I am compiling it (with AustroCompiler) for speed, but AC will not take the new start-of-BASIC location into account. I've found this topic about this issue. Looks like I will have to ditch my idea of having a custom charset for my game, I need to compile it but I don't know of any other VIC compiler which will allow to choose a different starting address.

[Boray]

To work with austro compiler, you can put some graphics in the tape buffer as described here:
http://www.boray.se/commodore/expandedvic20.html

[LoadError]

Thanks! That is more than enough to accomodate my custom chars. It works a charm in that the loader and the memory relocations are no longer necessary. I can switch to the custom charset for the game screens, and revert to the default charset for the informational screens (title screen etc.).
The only problem is in the game screens I have an header with real time data: score, level, lives left, time remaining. I am using PRINTs to display these.
If I am not mistaken, I should now replace PRINT (which would show garbage chars) with POKE to use the 10 numbers (0-9) in the tape buffer.
Any suggestion for that, other than converting the numeric values to strings and then parsing them to determine the appropriate POKE for each number (which would slow things down dramatically, I guess)?

[Boray]

Depending on your scoring system you could define strings for the numbers. For example:

For t=0to9:for b=0to9
a$(t*10+b)=chr$(t+83)+chr$(b+83)+chr$(83):next b,t

This will give you the score strings 000 to 990 in steps of ten, provided that the graphics for the numbers starts at 83.

[LoadError]

Anyway, it's still a matter of converting a number into a string and then do something to that string; I realize now that I can also use PRINT CHR$ instead of POKE though. Thanks

[Boray]

Yes, but the purpose of my method is that the conversion is just done once on game start and then you just do print a$(score) to print it, which will be just as fast as print score with normal graphics.

[Mike]

You should also keep in mind the score display doesn't need to be updated in every loop, just when the score has changed.

In one game I used the following construct to output a 4-digit score with leading zeroes:

Code: Select all

SC$=STR$(SC+100000):FORT=4TO7:POKE7728+T,VAL(MID$(SC$,T,1))+176:NEXT:RETURN

You see I had no concerns writing the score out to screen with single POKEs.

What kind of game is it you are writing? Sometimes it is possible to identify hot-spots in the game logic that slow everything down, and then it's just a matter of optimizing those - up to the point compiling the program might not anymore be necessary. And then you can pursue the original idea of what kind of user defined characters you wanted to use.

IMO, BASIC compilers are way overrated. The occasional 3- or 4-fold speed increase does not help with non-optimal code.

[LoadError]

Yes, the score will be updated just when needed, but I do have the time remaining display which will be updated every second.
The game is about collecting bombs before they explode, avoid mines, avoid static robots which zap the surroundings, and avoid moving robots. Then there's a bonus stage with no enemies, which I think is the best part. It's the first attempt at an arcade game for me, and the first time I lay my hands on an (emulated) VIC keyboard in more than 30 years, so I'm sure it could be optimized, I'm working on it.

[Mike]

You might take a look at the type-ins I put in my Games collection.

They all run on the unexpanded VIC-20, a good deal of those use UDGs, some of them use a dedicated machine code routine to speed up crucial parts of the game. There you'll surely find a lot of good ideas, which can be transferred to other programs.

Also, Jeff's games give nice examples of tight game main loops.

[LoadError]

I promise I will study these examples because I've got plans to not stop here.
But for this game, and this game only, I want to see what I can come up with without "borrowing" any piece of code, I know myself and the temptation to just copy and paste would be too strong. In the end I'll be happy if the game works and is playable. For the next efforts, I will first study then start to lay out a scheme
Thanks very much guys, for the patience and the knowledge, I'm impressed; also impressed at the fact that there is still a scene for this little micro.
Oh and sorry for bringing up old subjects, but in the end this topic might work as a nice resumé for anyone with the same doubts as I had.
May I post the game here if, after testing it, it looks decent enough?

PS: I've been able to incorporate my chars in the game with the tape buffer hack, now it's starting to look more like it =)