REQ: new target based on c64 for the upcoming Commander X16

[tschak909]

David Murray is working with a team of engineers to develop an extended Commodore 64 design, adding all sorts of nice little features.

https://www.facebook.com/groups/CommanderX16/

There is an emulator available, and there is development hardware being released out into the wild.

Hardware manual here:
https://github.com/commanderx16/x16-docs/blob/master/Programmer's%20Reference%20Guide.md?fbclid=IwAR1-gdxWQiScF8akykB_gm8yFT-k_Nc9stj6j2-d4q39XwfX99EKfcdfqEM

It looks like binaries emitted by CC65 almost work, something fails in crt0.s, and it ejects back out to BASIC, though.

[tschak909]

Apparently, this works:

    // bad hack: redefine CC65 stack from $0xa800-0xaff, should be a proper x16 custom target
    *((uint8_t*) 0x02) = 0x00;
    *((uint8_t*) 0x03) = 0xb0;

[msx80]

I second this, being able to compile C for the commanderx16 would be awesome!

[3vi1]

I too intend to try to make some X16 programs (after I wrap up current projects). Maybe we can put our heads together and get the proper configurations set up and submitted. https://cc65.github.io/doc/customizing.html

[greg-king5]

I have written enough of it to make a typical "Hello world!" program work in the emulator.

[hasenbanck]

@greg-king5 Could we maybe open a branch somewhere to sync development efforts (I did a quick POC myself this weekend)? I don't think it would be wise to upstream the changes yet, since the X16 project hasn't even finished yet selecting the components.

I played with the idea to simply activate the CBM library for the X16 target and fix everything broken step by step, but after thinking about this matter further, I think it's best to write it's own set of libraries since it vastly different.

EDIT: Okay, I realized that enabling the CBM library would make much sense. I finished by branch so that you could use cc65 using the "x16" target to build the cc65 demo code in the x16-demo repository. The branch doesn't need the bad hack above, since the custom target does have a proper memory layout for the system.

[msx80]

@hasenbanck well done, i'll give it a try! We could also make a "x16.h" or something to include common x16 code like the VERA struct in demo.c

[hasenbanck]

@msx80 I only copied the bare minimum from the C64 library, until the compilation was successfull. The asminc/x16.inc doesn't contain the proper memory addresses / peripherals yet and there is as of right now no include/x16.h (I guess we should also create a include/_vera.h as it seems that it's the convention in cc65).

I think I will write some test code myself in the next days to test each hardware component from C and test which parts need to be added (Especially if the CBM library is working at all).

[hasenbanck]

It seems that @greg-king5 and I'm currently doings some double work. I would really like to focus efforts to make this new target. Since it seems that you greg have much more experience with the codebase, I would like to rebase my efforts of your branch.

[greg-king5]

OK. For those who haven't noticed it, my current work is at
https://github.com/greg-king5/cc65/tree/commander-x16.

It's targeted at release 30 of the emulator; therefore, the VERA (video chip) stuff currently aims at revision 0.7.

[greg-king5]

I "bumped" the library code to work with x16-emu release 31 (so, VERA 0.8).

stdio programs work very well. conio programs work fairly well. But, I see a problem with testcode/lib/joy-test.s when a key is held down for awhile. Sometimes, parts of the lines are printed too far to the right. I don't know if it's caused by my library or by the emulator.

[tschak909]

i'm going to attempt a platoterm bring-up this weekend.

[greg-king5]

With commit 18afc7c, we have a cx16 target. The computer's firmware was derived from the Commodore 64; therefore, I put that target into the cbm family. You can #include <cbm.h> when you write C programs for the Commander X16.

[oliverschmidt]

Thanks :-)

[tschak909]

@greg-king5 yeah, this is awesome! :) This will be enough to do a platoterm bring-up (once I get the graphics bits worked out)

There is also still some discussion as to just WHAT will be possible to connect to the x16 for connectivity, but at least platoterm will be ready for when there is a viable connectivity solution :)

-Thom

[GithubPrankster]

I've tested a hello world, but the text in the emu converts to lowercase everywhere. How do I convert back in C? (Also, if mixed mode can be done.)

[greg-king5]

I've tested a "hello world", but the text in the emu converts to lowercase everywhere. How do I convert back, in C? (Also, if mixed mode can be done.)

Are you asking about the two fonts

1. UPPER-case/graphics
2. lower-/UPPER-case?

cc65's start-up code switches to the second font (the average C program expects both UPPER-case and lower-case letters). You can change to the other font by printing a 0x8E character to the screen.

The simplest way is to #include <cbm.h>; and, call a Kernal function:

cbm_k_bsout(0x8E);

If you print other text to the screen, then you can combine the above character with your other stuff:

printf("\x8ehello world!\n");

(conio functions won't change the font.)

Normally, you can't mix those two fonts on the same screen. (Fancy tricks are possible with VERA's two layers; but, the Kernal doesn't support them.)

[alytle]

Looks like r33 added 128 sprites, but the cx16 target doesn't seem to work in that version because of the RAM bank changes. Anything we can do to make it work with this newest release? Or is it just too much of a moving target?

[greg-king5]

cc65 has been updated for x16emu R33. You need to update your Git repository or a package.

[3vi1]

DEMO.PRG still appears to crash the emulator, with cc65, x16-roms, x16-emu, and x16-demo all built from current source. commanderx16/x16-demo#51

[L-Bouzid]

With commit 18afc7c, we have a cx16 target. The computer's firmware was derived from the Commodore 64; therefore, I put that target into the cbm family. You can #include <cbm.h> when you write C programs for the Commander X16.

good work Greg ...

[Frank-Buss]

With the latest x16-rom from today, the demo program doesn't work. I guess it is a problem with the recent changes of the RAM locations for the ROM variables. Looks like waitvsync hangs, because the TIME location was changed.

[greg-king5]

I added vpeek() and vpoke() functions to the library. They give to C programs a more straight-forward, and faster, access to VERA's internal RAM and registers.

If you have been using your own version of vpoke() in your programs, then you must rename it; or, you must refactor your programs to use the library version. The new prototype is different from what most people have been using in C and BASIC!

cc65/include/cx16.h

Lines 190 to 193 in 9fa90e2

	void __fastcall__ vpoke (unsigned char data, unsigned long addr);
	/* Put a byte into a location in VERA's internal address space.
	** (addr is second instead of first for the sake of code efficiency.)
	*/

[mobluse]

It might be easier to maintain https://github.com/cc65/cc65/blob/master/asminc/cx16.inc by using rom.sym.

You can get old rom.sys files from the releases page in the compiled releases e.g. x16emu_linux-r34.zip, and then compare with e.g. diff to the newly generated. One could generate a new cx16.inc using the latest rom.sym using a script if one somehow used similar names in cx16.inc as in rom.sym. The RAM addresses that the ROM uses are also in rom.sym.

[greg-king5]

Commit b66f727 updated the library to prerelease 36.

[bobbyjim]

cc65's start-up code switches to the second font (the average C program expects both UPPER-case and lower-case letters). You can change to the other font by printing a 0x8E character to the screen.

The simplest way is to #include <cbm.h>; and, call a Kernal function:

cbm_k_bsout(0x8E);

If you print other text to the screen, then you can combine the above character with your other stuff:

printf("\x8ehello world!\n");

Is this documented? I had to dig into this thread to find this out...

[mrdudz]

If you print other text to the screen, then you can combine the above character with your other stuff:

mmh sure? wouldnt the string be subject to ascii->petscii conversion in that case?

[bobbyjim]

If you print other text to the screen, then you can combine the above character with your other stuff:

mmh sure? wouldnt the string be subject to ascii->petscii conversion in that case?

I tried it both ways, and the embedded hex code works (as does cbm_k_bsout()).

[greg-king5]

If you print other text to the screen, then you can combine the above character with your other stuff:

mmh, sure? Wouldn't the string be subject to ascii->petscii conversion, in that case?

Only some of the control codes are translated. "\r\n\f\b", for example. (The documents don't list the ones that are translated.)

[greg-king5]

I added CH_FONT_LOWER and CH_FONT_UPPER to <cbm.h>.

[bobbyjim]

I added CH_FONT_LOWER and CH_FONT_UPPER to <cbm.h>.

Very friendly! Thank you!

[greg-king5]

I added CH_FONT_LOWER and CH_FONT_UPPER to <cbm.h>.

In ca65 Assembly ("cx16.inc"), the spellings are slightly different: CH::FONT_LOWER and CH::FONT_UPPER.

[greg-king5]

Commit 4296cba added a TGI (graphics) driver, 320 dots across, 200 dots down, and 256 colors.

[mrdudz]

@greg-king5 can we close this? we have cx16 support now, right?

[greg-king5]

@greg-king5, can we close this? we have cx16 support now, right?

Yes.