Re: New three versions of C64 source code

From: Kajtár Zsolt <>
Date: Wed, 03 Dec 2014 17:39:31 +0100
Message-ID: <>
Hash: SHA1

> IIRC 64tass isn't able to handle the combination of text and bytes. It 
> won't accept the above examples at all, it expects .text in the first
> place if text is used. And it cannot handle something like 'D'+$80 as
> well.

I'm sorry, but you're using it wrong. I tried to resist, but this
misinformation comes up several times now, and I can't leave it like that.

Don't take it personally. You're not the first being surprised why .byte is
not just an alias of .text as on some other assemblers. But there's a good
reason for that.

.byte is just like .word, .long and friends. Therefore it requires single
byte constants, just like .word requires single word constants. After all
these directives have range validation for their input.

Text is a constant, like any number. Usually single letter constants are
used, but you can use more than one letter just like more than one digit for
numbers. One letter is usually one byte, but it may be encoding dependent.

If you write something like this:

.byte "en"

then you try to feed .byte with a two byte constant, which will not fit into
a byte, so you get an error. However these variants are fine:

.word "en"
.long "end"

as they accept bigger constants and the text constant is not too long to fit.

For long text constants .text needs to be used. That accepts text of any
length, and stores it's bytes. No matter how many bytes it ends up. In
addition you can intermix single bytes for control codes and such.

So I guess what you wanted to do is:

.text "EN", "D"+$80

That's fine in raw text encoding (let's simply say ASCII), where "D" is $44.

But then (I think) you enabled PETSCII encoding on the command line, and
then "d" is $44 and "D" is $C4. So "D"+$80 ends up as $144, which fails to
convert. (that must be the reason why you claim it does not support 'D'+$80)

I assume you've selected screen code encoding as a workaround for this
misunderstanding, which makes "D" $44 again. ($44 is a shifted D on C64
screen) At least I've found the directive in the source for this, and
there's no logical explanation for that.

One possibility is that you use raw encoding for ASCII letters like most of
the other assemblers (don't give the "-a" parameter). Which is not optimal
as then you can't easily type shifted letters without hacks like "X"+$80.

Or if you use PETSCII translation, then convert all characters properly so
that it ends up like it was planned:

.text "enD"

I may fix up the source sometime later to remove the screen code hack and
unnecessary .byte-s.

- -- 
Version: GnuPG v1


       Message was sent through the cbm-hackers mailing list
Received on 2014-12-03 17:00:03

Archive generated by hypermail 2.2.0.