Loading character data at the assembly level?
Moderator: Moderators
-
- Vic 20 Drifter
- Posts: 34
- Joined: Thu Jul 15, 2021 10:50 pm
- Location: Rapid City, SD
- Occupation: Machine Shop Lackey
Loading character data at the assembly level?
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.
*=$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.
Works in Progress: Gravity Ball, a breakout variant in assembly for the unexpanded vic-20
- chysn
- Vic 20 Scientist
- Posts: 1205
- Joined: Tue Oct 22, 2019 12:36 pm
- Website: http://www.beigemaze.com
- Location: Michigan, USA
- Occupation: Software Dev Manager
Re: Loading character data at the assembly level?
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.
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.
VIC-20 Projects: wAx Assembler, TRBo: Turtle RescueBot, Helix Colony, Sub Med, Trolley Problem, Dungeon of Dance, ZEPTOPOLIS, MIDI KERNAL, The Archivist, Ed for Prophet-5
WIP: MIDIcast BASIC extension
he/him/his
WIP: MIDIcast BASIC extension
he/him/his
-
- Vic 20 Drifter
- Posts: 34
- Joined: Thu Jul 15, 2021 10:50 pm
- Location: Rapid City, SD
- Occupation: Machine Shop Lackey
Re: Loading character data at the assembly level?
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!
*=$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!
Works in Progress: Gravity Ball, a breakout variant in assembly for the unexpanded vic-20
- Mike
- Herr VC
- Posts: 4845
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Loading character data at the assembly level?
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.
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'.
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.Victim_RLSH wrote:If custom character data will be at the end of my assembly program (and on an unexpanded machine it always is anyways)
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'.
-
- Vic 20 Drifter
- Posts: 34
- Joined: Thu Jul 15, 2021 10:50 pm
- Location: Rapid City, SD
- Occupation: Machine Shop Lackey
Re: Loading character data at the assembly level?
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?
Works in Progress: Gravity Ball, a breakout variant in assembly for the unexpanded vic-20
- Mike
- Herr VC
- Posts: 4845
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Loading character data at the assembly level?
Logical OR, not AND, but otherwise correct.Victim_RLSH wrote:just AND the character with #%10000000 to print a non-inverted version from ROM?
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
That trick was used in practically each and every type-in listing of the time for unexpanded VIC-20.
- chysn
- Vic 20 Scientist
- Posts: 1205
- Joined: Tue Oct 22, 2019 12:36 pm
- Website: http://www.beigemaze.com
- Location: Michigan, USA
- Occupation: Software Dev Manager
Re: Loading character data at the assembly level?
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:
My build script's XA invocation generates a symbol table. So the last line of the build script is:
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!
Code: Select all
pre_charset:
* = $1c00
.dsb (*-pre_charset)
* = $1c00
Code: Select all
cat toc | grep pre_charset
-
- Vic 20 Drifter
- Posts: 34
- Joined: Thu Jul 15, 2021 10:50 pm
- Location: Rapid City, SD
- Occupation: Machine Shop Lackey
Re: Loading character data at the assembly level?
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.
Works in Progress: Gravity Ball, a breakout variant in assembly for the unexpanded vic-20
- chysn
- Vic 20 Scientist
- Posts: 1205
- Joined: Tue Oct 22, 2019 12:36 pm
- Website: http://www.beigemaze.com
- Location: Michigan, USA
- Occupation: Software Dev Manager
Re: Loading character data at the assembly level?
"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 wrote: ↑Tue Jul 27, 2021 1:07 pm 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.
-
- Vic 20 Drifter
- Posts: 34
- Joined: Thu Jul 15, 2021 10:50 pm
- Location: Rapid City, SD
- Occupation: Machine Shop Lackey
Re: Loading character data at the assembly level?
The assembly dump just shows the space being skipped, I assume it is all $00.
Works in Progress: Gravity Ball, a breakout variant in assembly for the unexpanded vic-20
- chysn
- Vic 20 Scientist
- Posts: 1205
- Joined: Tue Oct 22, 2019 12:36 pm
- Website: http://www.beigemaze.com
- Location: Michigan, USA
- Occupation: Software Dev Manager
Re: Loading character data at the assembly level?
Oh, gotcha.Victim_RLSH wrote: ↑Tue Jul 27, 2021 3:13 pm The assembly dump just shows the space being skipped, I assume it is all $00.
I’m looking forward to seeing your game!
- Mike
- Herr VC
- Posts: 4845
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Loading character data at the assembly level?
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 wrote:The assembly dump just shows the space being skipped, I assume it is all $00.
-
- Vic 20 Drifter
- Posts: 34
- Joined: Thu Jul 15, 2021 10:50 pm
- Location: Rapid City, SD
- Occupation: Machine Shop Lackey
Re: Loading character data at the assembly level?
Looks like it just fills the dead space with $00 when it saves the assembly project with the gap in it.
Works in Progress: Gravity Ball, a breakout variant in assembly for the unexpanded vic-20
Re: Loading character data at the assembly level?
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.