KickC Optimizing C-Compiler now supports MEGA65

Hi all,

I am the author of the KickC optimizing C-compiler. The newest release 0.8.3 adds support for MEGA65.

This includes support for the 45GS02 and 65CE02 CPU's utilizing the Z-register, new instructions and new addressing modes when generating and optimizing the code.

KickC does not currently utilize the virtual 32bit register because the Xemu emulator does not support it - and Xemu is currently the only way I have for testing.

The compiler includes some example mega65 program that demonstrate DMA and a memory-mapped SID being played in an IRQ.

It also includes a complete rewrite of the raster65.asm demo in C. See https://gitlab.com/camelot/kic…xamples/mega65/raster65.c

The compiler includes H-files for most of the chipset of the Mega65, including DMAgic and VIC-III/IV in #include <mega65.h>.

KickC currently only has a subset of the C standard library. It does support conio.h and I have added support for both 40 column and 80 column modes on the MEGA65.

To test it out download it here https://gitlab.com/camelot/kickc/-/releases and unzip it.

If you have the HMW-version of Xemu installed and available in your PATH you can compile and execute the raster65.c demo using the following command (screenshot of the running demo below)

./kickc_0.8.3/bin/kickc.sh -e kickc_0.8.3/examples/mega65/raster65.c

I would very much appreciate it if someone could test the example programs on a real MEGA65. I have ordered a DevKit, but currently I can only test using Xemu.

Please let me know if it works for you, and also let me know if you run into any problems or miss any particular features.

/Rex of Camelot

This is great news! Thanks for all the effort

(I'll give it a try right away...)

RASTER65 looks perfect on the R2 board

(I'll try porting my own wator-m65 demo to KickC, but from the looks of it I'll have to rewrite and expand some things...)

Hi again

Like I had threatened I would... I'm trying to get my wa-tor simulation (https://github.com/steph72/m65wator) to compile with KickC. I had to make some adjustments, but now I'm stuck with an error message I can't make heads or tails of, because there's no indication of the location in the source code where the compiler encounters the problem:

I'm attaching my original source to this post; I compiled it via

(kickc.sh is in my $PATH).

Any ideas?

Zitat von ubik

Any ideas?

Hi ubik!

It is really great that you have given KickC a spin!

I have compiled your main.c code - and found the problem with it.

At line 324 you have the following:

memcpy_dma_command4(1, 0xf800, 0, canvas, WSIZE);

memcpy_dma_command is a local variable used by the function memcpy_dma4().

If you replace the line with the following you will fix the problem:

memcpy_dma4(1, 0xf800, 0, canvas, WSIZE);

The current error message given by KickC is horrible. I will fix that in the next release.

Please let me know if you encounter any other issues!

/Jesper

Zitat von LGB-Z

Zitat von JesperGravgaard

KickC does not currently utilize the virtual 32bit register because the Xemu emulator does not support it - and Xemu is currently the only way I have for testing.

Maybe you should drop me an issue on Github for Xemu, to implement those Honestly it was "low priority" for me, even just thinking about it, since not so much thing wants to use it (but even probably future Hyppo will, that's true ...).

I have added an Xemu feature request

https://github.com/lgblgblgb/xemu/issues/202

Zitat von JesperGravgaard

memcpy_dma_command is a local variable used by the function memcpy_dma4().

Thank you! Of course! stupid mistake! but I really didn't spot it; I've been too long without coffee

Anyways, a few changes and adjustments later, and I now have a working version of the simulation compiled with KickC, and it's MUCH faster than its cc65 counterpart... I'd estimate at least 4 times or more... very nice. And, the generated code is much smaller.

Only problem is, the simulation crashes on the real machine (R2 preseries board), and I've yet to figure out why... I'll debug the whole thing tomorrow.

In the meantime, you can use Xemu to look at the result...

Again, thanks for the excellent work n8!

Zitat von deft

Hey wow @JesperGravaard ! You went through my messy code and managed to port it - unbelievable! I will test the compiled demo asap, what I can see from here is that there shouldn't be any asterisks around the greetings but spaces instead - like visible in the data:

Code

1. // Greetings
2. char GREETING[] = " DOUBLEFLASH " " ADTBM "

I guess it's a small fix. Again, unbelievably well done!

best

deft

Thank you very much for the kind words deft. I am very happy you like the C-port of your work

I have to admit that I added the asterisks to the greetings on purpose. It was the only real modification I did to your demo. I felt that the greetings zoom-effect looks more impressive with the asterisks in place - since the leftmost asterisks are visible all the time and demonstrates the zoom really well.

Removing the following lines of C-code gets rid of them again

// Put '*' as default greeting

for( char i=0;i<40;i++)
(SCREEN + GREET_ROW*40)[i] = '*';

Zitat von ubik

Anyways, a few changes and adjustments later, and I now have a working version of the simulation compiled with KickC, and it's MUCH faster than its cc65 counterpart... I'd estimate at least 4 times or more... very nice. And, the generated code is much smaller.

Only problem is, the simulation crashes on the real machine (R2 preseries board), and I've yet to figure out why... I'll debug the whole thing tomorrow.

In the meantime, you can use Xemu to look at the result...

ubik It is great that you got your wator-code to work with KickC.

I am very glad that you are seeing a performance improvement over CC65. A primary purpose of KickC is to produce fast ASM The program looks very interesting on Xemu.

I am eager to hear why it does not run on the real hardware. I do not have access to a real mega65 myself, but of course the compiler should support the real hardware.

So if you can point me in the right direction I will fix any error the compiler might have.

n8!

Zitat von JesperGravgaard

I am eager to hear why it does not run on the real hardware.

So here's the news: It runs perfectly on real hardware when built for the mega65_c64 platform target (oh and boy is it fast ;)).

My first suspicion was the C65's IRQ, but further tests didn't confirm this, as running the whole program with interrupts disabled still crashes the machine.

So I think the problem might somehow be related to the different memory configuration in which C65 mode starts up.

Zitat von ubik

So here's the news: It runs perfectly on real hardware when built for the mega65_c64 platform target (oh and boy is it fast ;)).

My first suspicion was the C65's IRQ, but further tests didn't confirm this, as running the whole program with interrupts disabled still crashes the machine.

So I think the problem might somehow be related to the different memory configuration in which C65 mode starts up.

First it is wonderful that the compiled program basically works on the real platform!

You are probably right that the crash is related to the start-up memory configuration.

Even though I only work in the emulator my own programs written using the "mega65" platform target often fails because of the way memory and IRQs work out of the box in the non-C64 mode.

I have had to add BANK 0 to my basic programs and asm { sei }; memoryRemap(0,0,0); to the start of my C-programs to get memory into a reasonable starting state. This has been enough to keep my programs from crashing - but I do not have a complete picture of what state the machine/memory is actually in when starting up in non-C64 mode.

I guess the good news is that your crash problem can probably also be fixed with the right amount of set-up code to configure memory and other stuff to the right state before running the actual main program - if we succeed in understanding what the state is at start-up and make the code needed to get it into the state needed.

Great news!!!

i will give it a try... thank you for your efforts.

Zitat von Snoopy

The "problem" was, that I typed the RUN in the last line of the screen and after printing the "Hello World!" on the first line, it was scrolled above, so I can't see it. So, some "errors" are just sitting in front of the computer!

I am glad you got it to work.

The conio.h / stdio.h library in KickC currently starts in the cursor in the upper left corner. This is primarily because KickC has it's own character functions and does not rely on the KERNAL/BASIC functions.

A second reason is that the goal is to make a C-compiler with zero runtime code that is not needed by the program. I have recently added the ability to create library start-up code that is only linked if a certain function is called - so if I can find the current cursor X/Y (probably somewhere on zeropage) it would actually be possible to initialize the cursor position on startup to the current position in the screen editor.

Zitat von Snoopy

The current cursor line is stored in $00EB: PEEK(235)

The current cursor column in $00EC: PEEK(236)

Thank you!

$EB looks correct for the cursor line.

When I look at $EC it does not seem to contain the cursor column in my emulator (using a C65 ROM). However - I will set x-position to 0 nomatter what the y-posistion is - so it is not important to find the correct y-pos.

I have now coded the initialization of conio.h based on the current cursor line. It will be included in the next release.

Zitat von Snoopy

Zitat von JesperGravgaard

so if I can find the current cursor X/Y (probably somewhere on zeropage)

The current cursor line is stored in $00EB: PEEK(235)

The current cursor column in $00EC: PEEK(236)

Not sure where to ask but will this kind/level of information be available in the user guide (book) also? I have seen many things documented here in these posts with various memory locations but it would be nice to have a reference somewhere to look it all up