ASCII-C64 screen codes in DASM assembler
I am studying assembly for 6502 chip via C64 emulator. Currently trying to print lines to the screen. Here is my code:
processor 6502
org $1000
ldx #$00 ;using x register as column counter
print:
lda message,x;load a with x bit from message
sta $0400,x ;store this bit in row 0 col 0 address
inx ;x++
cpx #$05 ;is x >= 5?
bne print ;if not x >= 5, loop again
rts ;return from program
message dc "HELLO"
hexmsg dc $08,$05,$0c,$0c,$0f
Since my editor (notepad ++ on win 10) uses ascii-like char codes, "HELLO"
in message
is 48 45 4C 4C 4F bit. This gives the following output in the upper left corner of the screen:
This is correct I think by looking at the commodore code table table here .
If I change line 6 to lda hexmsg,x
then I get exactly what I need, the word HELLO
.
I am not very familiar with DASM assembler yet and cannot find complete documentation (if it exists). Most of the tutorials I found just declared message .byte "HELLO"
or something like that and it just works because the assembler they are using automatically converts an ascii text string to a commodore string automatically, but DASM doesn't seem to do it.
Does anyone know how I can get DASM to do this, or recommend another way to just type lines in assembler rather than manually typing the lines as hex data?
source to share
Here is the revised DASM version of aseembler.
http://iancoog.altervista.org/C/dasm2.20.07-iAN_Rev_N.rar
You can use the directives SCRU
and SCRL
to convert ASCII-> Screencode.
label SCRU "string"
label SCRL "string"
SCRU
is designed to enter text in uppercase, even if entered in lowercase. SCRL
preserves the body.
source to share
Aha, ASCII and Commodore codes. We've all been there. You have several options:
-
Don't write directly to screen memory, but use the Kernal CHROUT subroutine instead (perhaps with a line string procedure). Then all you have to worry about is the differences between ASCII and PETSCII, but that's a story for another bed rest. Also, it's good for text, but sucks for games as Kernal slow compares to live recording.
-
Write a small conversion routine that runs when your program starts up, eats your string table, and spits out the converted screen code equivalents. Fast and efficient if your strings are all together and you are not writing a ROM-based application (which cannot do the in-place conversion).
-
Write a DASM pre-processor that runs before DASM in your build script and basically does the same conversion as # 2 above, but to the source code before the assembler sees it. This can be a little rough and you should be sure to back up the original source before poaching it.
-
Get the DASM source code and fix it to invoke user-exit for a new data type (for screen codes) that does the same as # 2, but on the fly at build time. Very rude.
-
Use lowercase letters in strings that will be translated into uppercase screen code equivalents at build time. You may have overlooked the fact that what you are seeing is a shifted representation of the characters in the string, which is a graphical character in default display mode.
Speaking from the experience of all 5 options, I settled on # 2.
Also: switch to the KickAssembler which
- is newer and actively supported
- offers more powerful features.
- integrates very well with VICE for debugging
source to share
It has been a while since I programmed 6510. (Unless you pressed to save every byte of C64 memory ..) Also consider null terminating your string with byte 0, rather than ending at the length reached in X. Does this is slightly more convenient than handling line lengths: D
processor 6502
org $1000
printstring:
ldx #$00
printstrlp:
lda message,x
cmp #0
beq quitstr
cmp #32 ;' ' character
beq noconv
cmp #33 ;! character
beq noconv
cmp #42 ;* character
beq noconv
cmp #48 ;numbers 0-9
bcs numconv
conv:
sec
sbc #$40
noconv:
sta $0400,x
inx
bne printstrlp
quitstr:
rts
numconv:
cmp #58
bcc noconv
jmp conv
message dc "** HELLO C64 WORLD! **",0
source to share