custom characters in assembly - quick question

[bkumanchik]

I have a quick question about setting up custom characters in assembly, when setting them up do I have to set pointers in order to protect BASIC at all, like when doing this in BASIC, I figure since I'm writing in all assembly and only using a BASIC load I'm safe and don't need to do this.

This question is for: no expansion, 3K expansion and 8K or more expansion

example:

Code: Select all

 ;custom char setup stuff
        lda #255                ; move char set to 7168 ($1C00)
        sta $9005               ; -
        ;lda #52                 ; change pointers to top of available RAM  (ARE THESE LINES NEEDED??)
        ;sta $1c                 ; -
        ;lda #56                 ; -
        ;sta $1c                 ; -     
        

Thanks,

Brian

[Mike]

[...] do I have to set pointers in order to protect BASIC at all, like when doing this in BASIC, [...]

No, it is not necessary to protect the character definitions from the activity of the BASIC interpreter in that case.

See also this post, and to quote from there:

It's not necessary to protect RAM in the BASIC stub with the POKEs to 55/56. Once you leave BASIC with SYS, there's nothing that could be overwritten by the BASIC interpreter. Furthermore, the whole appended machine code already is protected as 45/46 is set behind the loaded data of the file. Actually, setting 55/56 *below* 45/46 (what you do effectively) would confuse the interpreter, if you were to return to BASIC.

This question is for: no expansion, 3K expansion and 8K or more expansion

The above recommendation applies regardless what RAM configuration is present.

Code: Select all

;custom char setup stuff
        lda #255                ; move char set to 7168 ($1C00)
        sta $9005               ; -
        ;lda #52                 ; change pointers to top of available RAM  (ARE THESE LINES NEEDED??)
        ;sta $1c                 ; -
        ;lda #56                 ; -
        ;sta $1c                 ; -

The code portion you commented out wouldn't anyhow work as intended. Its BASIC equivalent is "POKE28,52:POKE28,56" so you were getting value and address the wrong way round.

BTW, when changing the pointer in 55/56, the pointer in 51/52 can be made to follow suit by doing a "CLR" in BASIC. It is more important to set the whole pointer in 55/56 to the correct value than setting 52 by hand in the style of cargo cult programming: 55 need not necessarily be 0 by default (when, for example, the Super Expander is plugged in), and then the characters wouldn't be fully protected.

[bkumanchik]

Thanks for the explanation, I think I'm starting to get this

[MartinC]

Thanks, I had this question too - so this helped me! One further question, I have designed a custom character set and exported it to a BIN file including the load address. Then I have used incbin to include it - does this mean that when assembled the char set will automagically load at 7168 where I specified during the export. Thanks chums.

[chysn]

I have designed a custom character set and exported it to a BIN file including the load address. Then I have used incbin to include it - does this mean that when assembled the char set will automagically load at 7168 where I specified during the export. Thanks chums.

I don't think you specified which cross-assembler you're using, so hard to say.

I use XA, and it does not automatically introduce padding when you change the PC with *. However, the .dsb (fill data) pseudo-op in XA can be used to generate padding:

Code: Select all

end_code:
.dsb ($1c00 - end_code), 0
* = $1c00

The value of the end_code label is defined as the byte after the last byte of my game, and .dsb adds padding bytes equal to the start of custom characters (7168) minus this value. Then the *=$1c00 advances the PC and resumes adding following data (my custom characters) to the binary. If you want padding to be other than 0, set .dsb's second parameter.

So check the manual for your assembler. It might add padding "automagically," but probably not. In my early cross-assembled games, before I discovered .dsb, I'd write my own padding manually as the program changed in size, which was a lot of extra work.