Greetings and Question from Newbie!

[Saturn78]

Hi there,


after a while I've found time to study my beloved C64 asm, and I've done a setup with Kick Assembly chained with VSCode.

I've tried to study alone, but after I while i think i can declare myself completely stuck and as a newbie I've found this forum for help!

I've already made some sprite with the help of SpritePad, now i'm facing a new challenge: print a charmap!

So i've made a new charmap with CharpadPro, made by 40x8 chars, 320 in total.

I've put up this snippet to print it on screen:

Code: Select all

BasicUpstart2(main) 
#import "screenConstants.asm"
#import "memoryMap.asm" 
 
*=CHARSET_ADDRESS "Charset" 
.import binary "test/FancyMap_CharMapFull - Chars.bin" // 

*=CHARSET_ATTRIB_ADDRESS "Charset Attrib" 
.import binary "test/FancyMap_CharMapFull - CharAttribs_L1.bin" // 

*=HUD_ADDRESS "MAKA_TITLE" 
.import binary "test/FancyMap_CharMapFull - (8bpc, 40x8) Map.bin" // 
 
*=GAME_CODE_ADDRESS "Game Code" 
main: 
    jsr SCREEN_CLEAR

    lda #%11011000   // enable MULTICOLOR - Bit #4: 1 = Multicolor mode on.
    sta $d016
      
     lda #%00011110       
     sta $d018
  
lda #BLUE
sta $d023 //extra color 2

lda #BLACK
sta $d022 //extra color 1
 
lda #RED
sta $d021 //BG color

ldx #00            // Initialize loop counter to 0
ldy #00 //#$192             // Initialize counter for adding $28  //192

jmp loop_start

exit:
    rts
    
loop_start:
    lda loop_counter 
    tax 
    tay
    lda HUD_ADDRESS, x  // Load the char B
    sta $0400, x  // Screen RAM
    tax // Transfer the numer of B to the x-register 
    lda CHARSET_ATTRIB_ADDRESS,x
    sta $d800, y // Color RAM 
    inc loop_counter
    
    jmp loop_start
 
loop_counter: .word 0 //192       // Define a temporary variable (initialized to 0)
loop_row_limit: .byte 0
 

But I probably hit the 255 limit.
With sprites, I've overcome affecting $D010 location, but now I don't know how to do it.

Any advice?

Thanks in advance!

[JohanFr]

Not entirely sure if this is what you are asking about but:

The screen is 1000 bytes, but the X/Y registers can only hold 256 values, so either one need to do a nested loop, or unroll it:

Code: Select all

  ldx #0
copyscreen:
  lda TILEDATA,x
  sta $0400,x
  lda TILEDATA+$100,x
  sta $0500,x
  lda TILEDATA+$200,x
  sta $0600,x
  lda TILEDATA+$300,x
  sta $0700,x
  inx
  bne copyscreen

As you are using Kickassembler, you can take advantage of its script language, making the code more compact:

Code: Select all

  ldx #0
copyscreen:
  .for (var i = 0; i < 4; i++) {
    lda TILEDATA+i*$100,x
    sta $0400+i*$100,x
  }
  inx
  bne copyscreen
  

This will overwrite the sprite pointers at the end of the screen area, so make sure you update those after. Alternatively, do the above for 3 out of the 4 pages, and have a fourth loop not go all 256 bytes.

Same thing for your color ram code.

[JohanFr]

Sorry, forgive my previous answer, answering something you didn't ask. I didn't read properly.

But I would take advantage of the Kickassembler's script-language to do loop unrolling anyway. Something like:

Code: Select all

  ldx #39
loop_start:
  .for (var i = 0; i < NUMBER_OF_ROWS; i++) {
    lda HUD_ADDRESS+i*40, x  // Load the char B
    sta $0400+i*40, x  // Screen RAM
    tay // Transfer the number of B to the y-register
    lda CHARSET_ATTRIB_ADDRESS,y
    sta $d800+i*40, x // Color RAM
  }
  dex
  bpl loop_start

[BigEd]

(Welcome, Saturn78!)

[JohanFr]

If you want the purist approach without using script language, you can use zero page pointers for the screen ram, color ram and the hud, or self modifying code:

Code: Select all

  .const SCREEN=$0400
  .const COLORRAM=$d800
  .const HUD=$XXXX 

  lda #<SCREEN   // Get the low byte of screen address
  sta load_screen  // Update the low byte address of the self modified lda nnnn,x instruction
  lda #>SCREEN  // Get the high byte of the screen address
  sta load_screen+1  // Update the high byte address of the self modified lda nnnn,x instruction
  lda #<HUD
  sta save_hud
  lda #>HUD
  sta save_hud+1
  lda #<COLORRAM
  sta save_colorram
  lda #>COLORRAM
  sta save_colorram+1

  ldy #NUMBER_OF_ROWS
  ldx #39

nextrow:
  sty save_y
nextchar:
  lda load_screen:$0000,x  // Self modified code. Will overwrite the $0000 in the init code above and in the adc code below
  sta save_hud:$0000,x // Self modified code. Will overwrite the $0000 in the init code above and in the adc code below
  tay
  lda CHARSET_ATTRIB_ADDRESS,y
  sta save_colorram:$0000,x // Self modified code. Will overwrite the $0000 in the init code above and in the adc code below
  dex
  bpl nextchar

  clc
  lda load_screen
  adc #40
  sta load_screen
  bcc !+
  inc load_screen+1
  clc

!:
  lda save_hud
  adc #40
  sta save_hud
  bcc !+
  inc save_hud+1
  clc

!:
  lda save_colorram
  adc #40
  sta save_colorram
  bcc !+
  inc save_colorram+1

!:
  ldy save_y:#00
  dey 
  bpl nextrow  
  

EDIT: I guess I ended up using the scriptlanguage for the selfmodifying code anyway. I'll be quiet now
EDIT2: Disclaimer, this was written without any assembling whatsoever so the code might be full of bugs. Hopefully it is helpful anyway

[Saturn78]

Here we are: first of all big thanks to JohanFr, it gives lots to study!

I've spent pretty much all day testing, and even if the "zero page" approach is theorically something i've read about, it still won't work, i need further investigations, when i'll be more confident I'll try to explain better my attempt if still won't succeed!

For what concerns the "syntactic sugar" of "KickAss" , well after lots of try and error I made it work with following approach:

Code: Select all

BasicUpstart2(main) 
#import "screenConstants.asm"
#import "memoryMap.asm" 
  
*=CHARSET_ADDRESS "Charset" 
.import binary "test_big/testimura_CharMapBig - Chars.bin"  

*=CHARSET_ATTRIB_ADDRESS "Charset Attrib" 
.import binary "test_big/testimura_CharMapBig - CharAttribs_L1.bin"  

*=HUD_ADDRESS "test_TITLE" 
.import binary "test_big/testimura_CharMapBig - (8bpc, 40x12) Map.bin"  
  
main: 
    jsr SCREEN_CLEAR

    lda #%11011000   // enable MULTICOLOR - Bit #4: 1 = Multicolor mode on.
    sta $d016
      
     lda #%00011110       
     sta $d018
  
lda #BLUE
sta $d023 //extra color 2

lda #BLACK
sta $d022 //extra color 1
 
lda #RED
sta $d021 //BG color

ldx #00            // Initialize loop counter to 0
ldy #00 //#$192             // Initialize counter for adding $28  //192

jmp loop_start

exit:
    rts
    
.var NUMBER_OF_CHARS =  480
 
loop_start:
  .for (var i = 0; i < NUMBER_OF_CHARS; i++) {
 
   lda HUD_ADDRESS + i  // Load the "ith" char 
    sta $0400 + i  // Screen RAM
    tay // Transfer the number of B to the y-register
    lda CHARSET_ATTRIB_ADDRESS,y
    sta $d800 + i // Color RAM  
  } 
  jmp exit 

Attention: when I've noticed that I would be able to overcome 255 limitation I've decided to use a much bigger charMap made of 40 columns x 12 rows, this explains 480 as char number

With this i got full control of each char printed on screen, but after going back to suggested approach, I'm start thinking that probably i'm not doing this in most efficient way, maybe considering nested loop Cols\Rows or better way to save iterations\logic...

More important than everything is that I feel now i'm in the right place to learn

[JohanFr]

Saturn78 wrote:

Here we are: first of all big thanks to JohanFr, it gives lots to study!

I've spent pretty much all day testing, and even if the "zero page" approach is theorically something i've read about, it still won't work, i need further investigations, when i'll be more confident I'll try to explain better my attempt if still won't succeed!

For what concerns the "syntactic sugar" of "KickAss" , well after lots of try and error I made it work with following approach:

Code: Select all

BasicUpstart2(main) 
#import "screenConstants.asm"
#import "memoryMap.asm" 
  
*=CHARSET_ADDRESS "Charset" 
.import binary "test_big/testimura_CharMapBig - Chars.bin"  

*=CHARSET_ATTRIB_ADDRESS "Charset Attrib" 
.import binary "test_big/testimura_CharMapBig - CharAttribs_L1.bin"  

*=HUD_ADDRESS "test_TITLE" 
.import binary "test_big/testimura_CharMapBig - (8bpc, 40x12) Map.bin"  
  
main: 
    jsr SCREEN_CLEAR

    lda #%11011000   // enable MULTICOLOR - Bit #4: 1 = Multicolor mode on.
    sta $d016
      
     lda #%00011110       
     sta $d018
  
lda #BLUE
sta $d023 //extra color 2

lda #BLACK
sta $d022 //extra color 1
 
lda #RED
sta $d021 //BG color

ldx #00            // Initialize loop counter to 0
ldy #00 //#$192             // Initialize counter for adding $28  //192

jmp loop_start

exit:
    rts
    
.var NUMBER_OF_CHARS =  480
 
loop_start:
  .for (var i = 0; i < NUMBER_OF_CHARS; i++) {
 
   lda HUD_ADDRESS + i  // Load the "ith" char 
    sta $0400 + i  // Screen RAM
    tay // Transfer the number of B to the y-register
    lda CHARSET_ATTRIB_ADDRESS,y
    sta $d800 + i // Color RAM  
  } 
  jmp exit 

Attention: when I've noticed that I would be able to overcome 255 limitation I've decided to use a much bigger charMap made of 40 columns x 12 rows, this explains 480 as char number

With this i got full control of each char printed on screen, but after going back to suggested approach, I'm start thinking that probably i'm not doing this in most efficient way, maybe considering nested loop Cols\Rows or better way to save iterations\logic...

More important than everything is that I feel now i'm in the right place to learn

Programming 6502/6510 is fun. Do note that your version takes quite a bit of memory (the code in the loop is essentially duplicated 480 times). It may or may not pose a problem, but just something to be aware of. I usually use a hybrid solution for loop-unrolling (i.e. instead of having two nested loops i have one loop unrolled), which saves me an index-register to use for other things. But it is always a tradeoff between speed, code size and readability.

[teamtempest]

Be aware that the VIC-II chip in the C64 can only "see" 16Kb of RAM at one time. Aside from the screen color memory at $D800, everything you want to display has to fit into that 16Kb.

You can re-define the character set and point the VIC-II at your re-defined characters. However, a single character set is limited to 256 8x8 glyphs. If you want to display more than that on a single screen, you may have to re-point the VIC-II "on the fly", ie., using raster interrupts. Once the raster reaches whatever line you want to change character sets at, you'll need to re-point the VIC-II to wherever your additional definitions are. And of course change that back once the raster is off the screen, so the top of the screen uses the first 256 characters again.

[teamtempest]

...although it has belatedly occurred to me that it another way it might be possible to get beyond the 256-glyph limit would be to re-define not what the VIC-II is pointing at, but the glyphs themselves. Whenever the VIC-II is not "looking" at a particular glyph (ie., in the process of copying it to the output stream), that image could be overwritten with another. The source could be anywhere in the C64's memory, just as long as the character set itself was somewhere the VIC-II could "see" it. Any number of glyphs could be accommodated this way. It would probably still require watching the raster beam to be sure it was safe to overwrite any particular glyph.