Commander X16

Hmm... unfortunately, I'm hitting some roadblocks. I got my code with the assembly subroutines to compile, but I'm getting a disk error, but the DOS command resets the emulator. Looking at the generated assembly code, it looks like you're writing to zero page locations 0,1, and locations > $80. This is a problem, since BASIC and the KERNAL rely on $80 and up, and $00 and $01 are the bank switching addresses (or will be when the next version comes out.)

I checked the target files, and I didn't see any way to constrain Zero Page addresses, so I'm going to put this to bed until I can investigate more later. 

 

1 hour ago, TomXP411 said:

Hmm... unfortunately, I'm hitting some roadblocks. I got my code with the assembly subroutines to compile, but I'm getting a disk error, but the DOS command resets the emulator. Looking at the generated assembly code, it looks like you're writing to zero page locations 0,1, and locations > $80. This is a problem, since BASIC and the KERNAL rely on $80 and up, and $00 and $01 are the bank switching addresses (or will be when the next version comes out.)



I checked the target files, and I didn't see any way to constrain Zero Page addresses, so I'm going to put this to bed until I can investigate more later. 



 

You can restrict the zeropages used through #pragma zp_reserve()

However, the compiler avoids 0 and 1 by default - and starts allocating from 2 upwards. So I believe there is something different causing the issue you are seeing.  

If you would share the program with me I can help find the issue.

 

Okay,  it looks like my wounds were self inflicted. I used the load example you suggested without realizing that it explicitly uses the free ZP locations on the Commodore 64, which happen to be in the space you're not supposed to use on the Commander. This was overwriting something that was causing a BRK every time I tried to run any BASIC command.

Along the way, I discovered that the print routines use screen codes, rather than PETSCII codes, which was giving me a FILE NOT FOUND error. The filename "DEMO" was actually being encoded as 4,5,13,15. 

Now that I know that's an issue, I can work around it. If they're not already there, I'll add some PETSCII<>Screen code conversion routines, so that problem can be worked around in the future. 

Although it would be nice to have sigils or prefixes to encode strings as PETSCII/ASCII, instead of screen codes, so we could just write something like 

char* filename = "demo,r,s"p;   // encode the filename as PETSCII text. 

 

 

45 minutes ago, TomXP411 said:

Now that I know that's an issue, I can work around it. If they're not already there, I'll add some PETSCII<>Screen code conversion routines, so that problem can be worked around in the future. 



Although it would be nice to have sigils or prefixes to encode strings as PETSCII/ASCII, instead of screen codes, so we could just write something like 

char* filename = "demo,r,s"p;   // encode the filename as PETSCII text. 

At compile-time you can change the string encoding of your literal strings in two ways. The pragma changes it for all strings following the pragma:

#pragma encoding(petscii_mixed)

If you just want a single string in petscii then you can use the magic suffix "pm" after your string - which is surprisingly close to your own proposal ?

"abcABC1"pm

If you want ASCII instead, then the name is "ascii" and the magic suffix is "as"

There is currently no library code offering run-time conversion. 

Waoo !

That seems very very promising !

I'll give it a try.

Meanwhile, I was a bit curious looking at the source code you showed in the first post so I went to read the doc ?

Quick remarks:

- The high low operator. Pretty obvious when you're in asm. In C, it looks really weird. Not to mention your highlighter didn't recognize it. I would rather go with the same kind of logic you're using for string with a postfix modifier.

addr.H and addr.L

or simply an explicit HIGH(addr)

- The floating point type

Could you have a placeholder type like float and some pre defined functions ?

Therefore the compiler would be able to compile those. The only thing is to add the library for the target system

- function calls

Is there a way to tell how the parms have to be passed (thru registers, thru stack....)? I didn't see anything on that matter.

- inline kickasm code:

Absolutely brilliant !!

Congratulations, Sir.

ps: any chance we have at some point other targets.... like the apple // ?

3 hours ago, Jesper Gravgaard said:

At compile-time you can change the string encoding of your literal strings in two ways. The pragma changes it for all strings following the pragma:

#pragma encoding(petscii_mixed)

If you just want a single string in petscii then you can use the magic suffix "pm" after your string - which is surprisingly close to your own proposal ?

"abcABC1"pm

If you want ASCII instead, then the name is "ascii" and the magic suffix is "as"



There is currently no library code offering run-time conversion. 

Thanks. Yes, the magic suffixes are exactly what I was looking for. 

 

I think half of my trouble is that the PDF included in the release appears to be incomplete. I actually searched all references of “string” and could not find the magic suffixes, nor could I find a list of #pragmas. I did find your Google Doc, but I didn’t find the magic suffixes in there, either. (Although I will look again.)

I have plans to build an Orthodox File Manager (sort of Midnight Commander for the Commander X16), and I will need to build the conversion and output functions in question, so as I complete chunks of that, I’ll send over the more useful parts. 

 

Now that I have a working file reader, I’ve passed the biggest roadblock, so ? 

@kktos Thank you for the kind words and the feedback. If you have more feedback or suggestions please let me know.

Here are my short answers to your points

3 hours ago, kktos said:

Quick remarks:

- The high low operator. Pretty obvious when you're in asm. In C, it looks really weird. Not to mention your highlighter didn't recognize it. I would rather go with the same kind of logic you're using for string with a postfix modifier.

addr.H and addr.L

or simply an explicit HIGH(addr)

I agree with you! In the start the language has more ASM-features mixed in - but over time the compiler has gradually been improved and moved close and closer the standard C.

I believe it is important to have the feature of addressing individual bytes - and the current solution is not very readable when used on 16bit or 32bit data. Also as you point out it confuses IDEs. 

So I want to find a different solution along the line of your proposals.

My  TODO is here: https://gitlab.com/camelot/kickc/-/issues/221

4 hours ago, kktos said:

- The floating point type

Could you have a placeholder type like float and some pre defined functions ?

Therefore the compiler would be able to compile those. The only thing is to add the library for the target system

That would be a fine way to add support for floats. I have added a description here https://gitlab.com/camelot/kickc/-/issues/619

There is a bunch of stuff in the pipeline, so for now it will be put into the pile of ideas.

4 hours ago, kktos said:

- function calls

Is there a way to tell how the parms have to be passed (thru registers, thru stack....)? I didn't see anything on that matter.

There are keywords for changing the calling convention on a single function. Currently there are two supported calling conventions:

- __phicall - passes parameters through shared variables.

- __stackcall - passes parameters on the stack.

__phicall is the default and allows the optimizer to optimize parameter passing quite a lot. __stackcall works for the test programs I have created - but I have not done very extensive testing. 

There is also a pragma for changing it in the entire program #pragma calling(__stackcall)

I am working on adding the more advanced stuff, like calling conventions, to the documentation. 

4 hours ago, kktos said:

- inline kickasm code:

Absolutely brilliant !!

Thank you. It is extremely useful when loading images or generating tables.

4 hours ago, kktos said:

ps: any chance we have at some point other targets.... like the apple // ?

I have been steadily adding platforms. The last additions have been Atari XL/XE, MEGA65 and CX16. The next ones I am considering are C128,  Acorn Electron and PC Engine. 



I prefer to have the actual hardware myself so I can test that the compiler produces programs that run on the hardware. I do not have an Apple II yet. 



However, the Apple II would be an obvious addition at some point. 

 

3 hours ago, TomXP411 said:

I think half of my trouble is that the PDF included in the release appears to be incomplete. I actually searched all references of “string” and could not find the magic suffixes, nor could I find a list of #pragmas. I did find your Google Doc, but I didn’t find the magic suffixes in there, either. (Although I will look again.)

The documentation is a work in progress. I am working on getting it up-to-date with the features that have been added.

3 hours ago, TomXP411 said:

I have plans to build an Orthodox File Manager (sort of Midnight Commander for the Commander X16), and I will need to build the conversion and output functions in question, so as I complete chunks of that, I’ll send over the more useful parts. 

That sounds like a very useful tool! 

It would be great if you create some of the libraries that are missing for KickC. If they can be useful for others I will gladly merge it into my repository and include them in future releases.

13 hours ago, Jesper Gravgaard said:

The documentation is a work in progress. I am working on getting it up-to-date with the features that have been added.



That sounds like a very useful tool! 



It would be great if you create some of the libraries that are missing for KickC. If they can be useful for others I will gladly merge it into my repository and include them in future releases.

I am working on it now... part of the problem is I really don't understand your assembly/c interface very well, and your calling convention is not something I've seen before. 

For example, I wanted to fill a buffer in the data segment, with the pointer stored in RO (address 2 in zero page). I'd expect something like this to work...

in my global section:

  __address($02) word R0;

char* buffer ..... 

...

R0 = (word) buffer;

asm {

  STA (R0),Y

...

}

}

But the compiler just completely removed the assignment to R0, then failed to assemble the STA line because R0 didn't exist. 

I ended up using a really obtuse syntax with a double pointer that I pulled out of your LOAD example, but I don't understand why the code above doesn't work. 

 

Tom, I guess that's related to what Jesper told you already about the compiler no "seeing" the var in the asm.

Therefore, here, as it doesn't see any use of R0, it simply removes it.

You need to use volatile in the declaration so the complier won't optimize it