Problem: The Directive ".strz" is not supported.

[schristis]

Hi..
I've ran examples in ASMEDIT X16 umm...
I've tried it in retroassembler... and would like to use that

strz.JPG (4.93 KiB) Viewed 1118 times

So if its not supported... is there an alternative or easy way to do that in retroassembler ?

Best Regards
Shaun

[schristis]

So I've been using Retroassembler in Visual Studio Code....
And While I'm guessing these "Directives" are not in the CPU but in the ROM... Then what may be a better Assembler for the X16 for assembly ?
(I think... or is there an easy solution..)
I do Like the visual studio code environment...
But I'll try new things lol....

[JimmyDansbo]

I believe that Mr. 8bitguy still uses the Acme assembler.
https://sourceforge.net/projects/acme-crossass/

A lot of people, and the ROM uses the CC65 package which also has an excellent assembler, CA65
https://cc65.github.io/

I am not sure what kind of integrations exist for Visual Studio Code.

[ahenry3068]

So I've been using Retroassembler in Visual Studio Code....
And While I'm guessing these "Directives" are not in the CPU but in the ROM... Then what may be a better Assembler for the X16 for assembly ?
(I think... or is there an easy solution..)
I do Like the visual studio code environment...
But I'll try new things lol....

These "directives" are in the assembler, not the CPU or the ROM. .strz is just a directive to insert a null terminated string into memory.

So


.strz "A" same as
.byte 65,0

[Daedalus]

Yes, as explained, the directives are in the assembler, not VSCode, the CPU, or any ROM in the X16 itself.

The assembler in the cc65 suite "ca65" is the defacto standard for X16 development. I say "defacto" because there is no "official" standard, but virtually everyone used ca65, and ca65 is what is used in the ROMs for the X16.

The .byte directive allocates and (If possible) presets a series of bytes in memory, and can accept ASCII characters in the "usual way", such as:

.byte "Hello world",0
.byte 1,2,3,4,5,6,7,8,9,0
.byte $55,$AA,0
.byte 'a','A',"etc",0

One thing to understand is that the X16 does not use ASCII by default, it uses PETSCII, so 'a' will not produce a lower case a, it will produce an upper case A.

Edited to add:
I also use VSCode as my editor. But I have it pretty stripped down, I don't like any of the "AI" features or the features that try to guess what you're going to type or pop up annoying dialogs trying to "help" you. But I do like the syntax highlighting (I use Cole Campbell's ca65 extension.) and I like the directory based project management. I use script files in a terminal for builds.

[schristis]

These "directives" are in the assembler, not the CPU or the ROM. .strz is just a directive to insert a null terminated string into memory.

So


.strz "A" same as
.byte 65,0

Thankyou... I did try CA65 and ECME... & run that at the DOS prompt... with a similar result I had with "retroassembler"...
Cool Cool ~ I will use ummm... the .Byte Directive.. now you've given a better understanding...

And yup... I think VS Code is a good editor... Ummm... even if you just save as "ASM" and then use whatever assembler at the DOS prompt (perhaps to try out of indifference)... I think its just make it work the way your comfortable with..

Thank's alot
Best regards Shaun

[ahenry3068]

Yes, as explained, the directives are in the assembler, not VSCode, the CPU, or any ROM in the X16 itself.

The assembler in the cc65 suite "ca65" is the defacto standard for X16 development. I say "defacto" because there is no "official" standard, but virtually everyone used ca65, and ca65 is what is used in the ROMs for the X16.

The .byte directive allocates and (If possible) presets a series of bytes in memory, and can accept ASCII characters in the "usual way", such as:

.byte "Hello world",0
.byte 1,2,3,4,5,6,7,8,9,0
.byte $55,$AA,0
.byte 'a','A',"etc",0

One thing to understand is that the X16 does not use ASCII by default, it uses PETSCII, so 'a' will not produce a lower case a, it will produce an upper case A.

Edited to add:
I also use VSCode as my editor. But I have it pretty stripped down, I don't like any of the "AI" features or the features that try to guess what you're going to type or pop up annoying dialogs trying to "help" you. But I do like the syntax highlighting (I use Cole Campbell's ca65 extension.) and I like the directory based project management. I use script files in a terminal for builds.

The 'a' to 'A' is a translation done by the assembler. ca65 does it I think by default. 64tass Does Not without a directive to do so. I'm also dealing with DASM because that's the assembler used by XC=BASIC and I don't believe it does the translation by default either (I could be wrong there).

[Daedalus]

Tony, Thanks for the correction. It is indeed the ca65 assembler doing the conversion from ASCII to PETSCII, but not "by default" per se, it's a result of using "-t cx16" directive in the cl65 command line.

Unfortunately, this is how assembly programming with the x16 is usually started because it reduces the learning curve. That directive both translates ASCII to PETSCII, but also sets up the program entry sequence in the beginning of the .PRG executable that the x16, again by default, requires because it is a BASIC centric machine.

This is my one complaint with the cc65 suite. It hides a lot behind "-t cx65", It would be better if a BASIC entry stub were added as a .byte sequence at the beginning of the program, and ASCII were the default. I know you can switch to the "iso" char (Essentially, ASCII.) character set from the BASIC command line, but I don't even know of a way to do that from assembly.

[ahenry3068]

Tony, Thanks for the correction. It is indeed the ca65 assembler doing the conversion from ASCII to PETSCII, but not "by default" per se, it's a result of using "-t cx16" directive in the cl65 command line.

Unfortunately, this is how assembly programming with the x16 is usually started because it reduces the learning curve. That directive both translates ASCII to PETSCII, but also sets up the program entry sequence in the beginning of the .PRG executable that the x16, again by default, requires because it is a BASIC centric machine.

This is my one complaint with the cc65 suite. It hides a lot behind "-t cx65", It would be better if a BASIC entry stub were added as a .byte sequence at the beginning of the program, and ASCII were the default. I know you can switch to the "iso" char (Essentially, ASCII.) character set from the BASIC command line, but I don't even know of a way to do that from assembly.

You do it the same way from assembly as you do from BASIC. By CHROUT the appropriate PETSCII Control character to the console.

CHR$(15) - ISO ON
CHR$($8F) - ISO OFF (PETSCII ON)
CHR$($8E) - PETSCII Upper/Graph Charset
CHR$($0E) - PETSCII Mixed Upper/Lower charset

There is also the ROM routine screen_set_charset at $FF62 in addition to the standard charsets this
function can also choose from thin & thick versions of the fonts. And as of r47 has cp437 (.A = 7)
and katakana charset as or r48 available.

lda #font
jsr $FF62

Where font is
0 - Pointer to font in .X, .Y
1 - ISO
2 - PET UPPER/GRAPH
3 - PET UPPER/LOWER
4 - PET UPPER/GRAPH (Thin))
5 - PET UPPER/LOWER (Thin)
6 - ISO Thin
7 - cp437 (r47 & greater)
8 - Cyrillic ISO
9 - Cyrillic ISO (thin)
10 - Eastern Latin ISO
11 - Eastern Latin ISO (thin)
12 - Katakana (thin) (since r48)

Prior to r47 only 0 - 6 was valid. screen_set_charset DOES NOT set mode. Control character 15 must be output prior to choosing an ISO font. or Character $8F is in ISO and switching back to PETSCII. PETSCII fonts can be set after boot if ISO is never chosen.
If loading a PETSCII charset in ISO mode or vis versa the screen will be illegible.

[ahenry3068]

You can also just load a 'charset' from file to the 2k of VERA ram starting at 1:$F000. This method does not set mode at all. So PETSCII or ISO mode as appropriate need to be set BEFORE loading the font. (Otherwise the mode change will obliterate the font you just loaded)