Loading character data at the assembly level?

[Victim_RLSH]

If custom character data will be at the end of my assembly program (and on an unexpanded machine it always is anyways) can I just use the assembler to load a block of character data at the appropriate location, such as this using the CBM PRG Studio assembler?

*=$1CE0

Balls

BYTE $C0,$C0,$00,$00,$00,$00,$00,$00 ; CHARACTER 28
BYTE $30,$30,$00,$00,$00,$00,$00,$00 ; CHARACTER 29
BYTE $0C,$0C,$00,$00,$00,$00,$00,$00 ; CHARACTER 30
.
.
.
.
.
.
.

It seems rather redundant to waste memory with both a copy routine and the data to be copied when I can hopefully just have it load with the program data.

[chysn]

For my unexpanded VIC-20 games, I pad prior to $1c00 (for example, see https://github.com/Chysn/VIC20-SubMed/b ... submed.asm).

However, while the game is in development, I'll use a copy routine. Eventually, the code gets big enough that I can dispense with the copy routine and just use careful padding. I might lengthen or shorten instructional text, create or remove minor interface flourishes. If I can't think of anything to do with the memory, I'll add license information or other nonsense. It all depends.

The end result is that the character data sits nicely at $1c00 with no need for a copy routine.

[Victim_RLSH]

I thought I'd be able to finish Gravity Ball soon, but am running into the memory wall and have to take steps to free up some. I noticed that CBM PRG Studio's assembler has no problem with this:

*=$1001

BYTE $0B, $10, $0A, $00, $9E, $34, $31, $32, $38, $00, $00, $00

; 10 SYS4128 - creates a one line BASIC program to launch asm code at $1020

followed by

*=$1020 ;Execution point for asm program

Main
JSR ClearScreen
JSR Copy64Chars
JSR CopyCustomChars
JSR InitGameScreen
JSR InitGameData
.
.
.


It still creates a single .prg file and pads the bytes prior to $1020 with $00. I will try the same thing with the character data and see if it works. I'll get the maximum loading size, but this game will be close to that anyway. Physics is "expensive" when coding it in assembly...

EDIT: OK, finally got to my computer and tried this, it DID work, BUT you have to copy ALL 64 (or 192) characters' data and include it in your .asm file, or write a ROM copy routine that skips around the custom data you just loaded. Since I'm loading all 3.5K as one file anyway, I just dumped the first 64 characters out of CBM PRG Studio's character editor into a hex file at the end of the assembly listing and set the loading location to *=7168. This saved me 216 bytes for the character data plus the size of the copy routines!

[Mike]

You are aware that you can access the non-inverted upper-case character set - when using UDGs at $1C00 - by printing them in inverse? That makes a (even if only partial) copy of the ROM characters largely redundant. You only need to provide your actual UDGs somewhere in $1C00..$1DFF, possibly including a copy of the space character at $1D00. Then the other room formerly occupied by the character ROM copy is free for other code or data.

If custom character data will be at the end of my assembly program (and on an unexpanded machine it always is anyways)

Noone forces you to put the UDG character set at $1C00 with an unexpanded VIC-20. You can for example also put it at $1800, and with the text screen moved to $1600 have a full 256 UDGs.

Here's another example with the UDGs put at $1000 (making UDGs 0 and 1 non-available as they overlap with the BASIC stub): reply.zip (from the thread '4ty - 40x25 interlaced text mode on unexpanded VIC 20'.

[Victim_RLSH]

Thanks! I wasn't aware I could use any ROM characters at all without copying them. That can save a lot of memory on an unexpanded machine. So just AND the character with #%10000000 to print a non-inverted version from ROM?

[Mike]

just AND the character with #%10000000 to print a non-inverted version from ROM?

Logical OR, not AND, but otherwise correct.

This is caused by the internal VA bus and the VIC chip only having a 16K address space, with the following correspondence:

Code: Select all

 VIC (VA bus) | CPU (CA bus)
              |
 $0000..$1FFF | $8000..$9FFF
 $2000..$3FFF | $0000..$1FFF

Now, putting the character set at (CPU) $1C00 actually puts it at $3C00 as seen by VIC. Top bit set characters lead to a wrap-around from ..$3FFF to $0000..$03FF in the VIC address space, which corresponds to $8000..$83FF as seen by the CPU. There, the non-inverted upper-case characters are stored in the character ROM.

That trick was used in practically each and every type-in listing of the time for unexpanded VIC-20.

[chysn]

I was admiring the ability of CBM Studio to do automatic padding, when I found the XA has a pseudo-op that does the same thing:

Code: Select all

pre_charset:
* = $1c00
.dsb (*-pre_charset)
* = $1c00

My build script's XA invocation generates a symbol table. So the last line of the build script is:

Code: Select all

cat toc | grep pre_charset

and I can monitor how much space the rest of the code takes up. Now I no longer need the temporary copy routine for custom characters, and I don't need to go back and forth padding to 3583 bytes!

[Victim_RLSH]

It looks like CBM PRG Studio doesn't pad it, it just skips populating the unused space and saves the whole program space as a .prg, which accomplished the same thing.

[chysn]

It looks like CBM PRG Studio doesn't pad it, it just skips populating the unused space and saves the whole program space as a .prg, which accomplished the same thing.

"Pad" might be the wrong word. It does need to fill the space, though, between the code and the character set. There's no such thing as "skips populating" within a PRG file.

[Victim_RLSH]

The assembly dump just shows the space being skipped, I assume it is all $00.

[chysn]

The assembly dump just shows the space being skipped, I assume it is all $00.

Oh, gotcha.

I’m looking forward to seeing your game!

[Mike]

The assembly dump just shows the space being skipped, I assume it is all $00.

It is still an uncommon terminology you are using here. The list file might not specify what's in the undefined areas - i.e. those between multiple origin directives ("*=$xxxx", ".ORG $xxxx", or whatever syntax the assembler uses). The assembler still has to check, that the segments belonging to each origin directive do not overlap, and when saving to a PRG file it *has* to fill or pad the undefined area(s) with a pre-defined byte value. There's no way to "skip" those undefined areas with a PRG file; the KERNAL of the VIC-20 does not feature such a "fragmented" load.

[Victim_RLSH]

Looks like it just fills the dead space with $00 when it saves the assembly project with the gap in it.

[bjonte]

If your characters are few and can be scattered in memory a bit you can put some in the $0000-$0400 area. For larger sets I use an align keyword to make sure the character set ends up aligned with the VIC requirements.