Redefine the charset with 8K+ RAM

[Mike]

May I post the game here [...]?

Why certainly! It's always a cool achievement to get a nice game or some other program running on the VIC-20.

And it's also fun, when you team up with a good friend and end up with something like VICtoria.

[LoadError]

I have a small problem with loading chars on the tape buffer.
I've successfully loaded my custom chars, via READ and DATA instructions, in locations 824-911 (characters 103-113). For example if I POKE eg. 4096,103 I get my main character. =)
Now I am trying to copy the reverse case numbers (0-9) from ROM to locations 944-1023.
This is the code to copy each of the eight bytes of each of the ten characters from the ROM charset to the tape buffer (assuming 34176 is the location of the first byte of the first number, i.e. "0"). In essence I am PEEKing locations from 34176 up, one byte at a time, and POKEing the values in locations 944 and up, one byte at a time.

FOR C1=944 TO 1023:POKE C1,PEEK(34176+(C1-944)):NEXT C1

After doing this (and POKEing 36869 to switch to the custom charset), I should POKE for example 4096,118 to get a reverse case "'0". But I get a reverse case "@". The other numbers are equally misrepresented by other symbols. The same happens when I load other characters from ROM into the other area of the tape buffer (characters 83 to 95, i.e. locations 644 and above).

What is happening?

[Mike]

Works for me. Just try out this one (download).

Code: Select all

1 PRINT"{CLR}";
2 FORT=0TO8*10-1
3 POKE8*118+T,PEEK(32768+8*(128+48)+T)
4 NEXT:POKE36869,200
5 FORT=0TO9
6 POKE4096+T,118+T:POKE37888+T,0
7 NEXT
8 GETA$:IFA$=""THEN8
9 SYS58648

Of course you can simplify the numeric expressions in line 3 to 944 and 34176 - I just wrote them this way to make it clearer to myself where these addresses came from.

SYS58648 resets the VIC registers to default values before the program exits to the READY prompt.

[LoadError]

Apparently "POKE C1,PEEK(34176+(C1-944))" and "POKE C1,(PEEK(34176+(C1-944)))" are not the same thing for the VIC. Or are they?

[Mike]

Should be the same. What value did you POKE into 36869?

Except that I tried to avoid the double address shift of 34176+(C1-944) and instead used positive indexes to both base addresses, both constructs:

Code: Select all

FORT=0TO8*10-1
POKE944+T,PEEK(34176+T)
NEXT

and

Code: Select all

FORT=944TO1023
POKET,PEEK(34176+(T-944))
NEXT

should be equivalent.

[LoadError]

Since I am using the "tape buffer hack", I'm doing this:

poke 36869,(peek(36869)and240)+8

I've also found out another thing. Currently the background color is white (poke 36879,29) but occasionally (on explosions...) it briefly becomes red (poke 36879,42). Whenever the background is not white, the blank spaces look garbled. I guess this is because the space character (32) is not mapped to anything in the charset. So I also guess I need to explicitly fill the field with a redefined char residing in the tape buffer, and then use that char code instead of 32 throughout the game.

[Mike]

poke 36869,(peek(36869)and240)+8

There's nothing special about this "tape buffer hack", the character generator just is set to $0000.

The VIC chip has its own address range mapping, compared to the CPU:

Code: Select all

VIC                CPU

$0000 .. $1FFF <-> $8000 .. $9FFF (BLK4)
$2000 .. $3FFF <-> $0000 .. $1FFF (BLK0)

In register 36869, the bottom 4 bit point to the character generator in 1K steps, the CPU address $0000 is equivalent to VIC address $2000, hence %..10 00xx xxxx xxxx => %1000 = 8 as value to put in there.

The top 4 bits point to the text screen address, also in full 1K steps, with the same mapping. Bit 7 (value 128) of register 36866 can add other 512 bytes to this base address which is, for example, used to put the screen to $1E00 on the unexpanded VIC-20. Anyway, when the screen is at $1000 for the CPU (with +8K or more) this means $3000 for the VIC, hence %..11 000x xxxx xxxx. So %1100 = 12 to put in the high nibble => 16*12+8 = 200. Exactly the value I put into 36869.

As the screen base hasn't been altered under these circumstances there's already the correct value in the top bit of 36866, but you can still confirm it with PRINTPEEK(36866)AND128, which should give 0 when +8K RAM are used.

In any case you can change those values for screen base and character generator as you like, they need not reside at their original position. If you need them at another position in RAM you can put as you want within the limits of the available address range (and remember, only the internal RAM is visible to VIC).

[...]the blank spaces look garbled. I guess this is because the space character (32) is not mapped to anything in the charset.

Of course the VIC knows what he ought to address when he encounters a space with the character generator at $0000. It then uses the addresses $0000+8*32..$0000+8*32+7 = 256..263 for this. This is part of the stack area where the interpreter constructs PETSCII text strings for numbers. That data is then visible as glyph for blanks when the foreground at that place is different from the background colour.

[LoadError]

Indeed. I called it a hack because the tape buffer was not originally meant to be used to store custom characters, therefore it's a proper hack = making the machine do something it was not originally meant to do, or in a different way =)

Thanks

[Boray]

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

I just timed boray gammon vs. running the non-compiled basic source, and the compiled version is 6.64 times faster in average (after measuring 7 equal moves). To run the basic source as fast would require a 7.4 MHz Vic-20. The source is however speed optimized, for example using integers which are faster than floating point compiled but slower that floating point not compiled.

The compiled version is also smaller than the source. 14900 bytes vs 18613 bytes (80 % the size)

[LoadError]

I'm happy! All is in working order, the graphics are fully in place (I'm just sad I had to simplify the informational screen before any level, which used to display all the characters encountered in that level, because just a few letters fit in the tape buffer).
And I used a differential timer to just execute most updates once per second (all the timer related stuff, which are calculated in seconds) which meant that the compiled game is even too fast in the first few screens, when there are no other moving creatures than the main character.
Now I "just" have to debug and tweak the difficulty.

I just had to scratch my head for a while, wondering if I had lost my mind, on the routine that turns the numbers to strings and the parses it for display in the header.
Reason of the scratching follows.

pu=1:pu$=str$(pu):print pu$,len (pu$)

VIC answers: (space)1 2

pu$="1":print pu$,len(pu$)

VIC answers: 1 1

The bugger! Why is it adding a leading space when the string variable is derived from STR$?

[Boray]

pu$="1":print pu$,len(pu$)

VIC answers: 1 2

No, it answers
1 1

[Boray]

Why STR$ puts in a leading space... Not sure. Maybe to be consistent with the print command?

[LoadError]

Sorry for the typo, yes it answers 1 1 in the second case, and indeed it adds that space with STR$. Took a bit to figure out. I recall something about this from when I was a kid.

Small teaser:

[Boray]

the compiled version is 6.64 times faster

As a comparison, this would be as the difference between running a CPU at 350 MHz or 2.3 GHz. I've done both with Windows and... strangely I prefer 2.3 GHz.

[LoadError]

Yes, I haven't done any measuring but the speed increase with my game after compiling it is dramatic, to the point that it's now too fast!
I will have to do something to make it more playable because the guy is all over the place like a rocket.
I am thinking a little for...next cycle between the moment the joystick is detected and the moment the actual movement takes place.