Debug C-code using CC65 in the CX16?

[svenvandevelde]

Do you know if it is possible to develop using the CC65 compiler in the CX16, and debug the c-code interactively in an IDE?

Does somebody have experience with this?

[Ender]

I don't believe there's a program that currently does this, but it's certainly possible to make your own version of the emulator that's integrated into an IDE environment that uses CC65 as the compiler.  Something like this would be a fairly involved project to do though.

[ZeroByte]

Debugging C on system is pretty hard. One thing I found helpful is to compile the errant module to assembly and make sym files in the process.

cl65 -g -Ln module.sym -t cx16 -a module.c

Then you at least have assembly to compare (module.s) against in the debugger. Box16 can even load the .sym file so labels appear in the debugger.

Edited December 4, 2021 by ZeroByte

[svenvandevelde]

On 12/4/2021 at 7:29 PM, ZeroByte said:

Debugging C on system is pretty hard. One thing I found helpful is to compile the errant module to assembly and make sym files in the process.

cl65 -g -Ln module.sym -t cx16 -a module.c

Then you at least have assembly to compare (module.s) against in the debugger. Box16 can even load the .sym file so labels appear in the debugger.

Where can we find the Box16? Don't even know what it is ...

[SlithyMatt]

On 12/19/2021 at 11:02 AM, svenvandevelde said:

Where can we find the Box16? Don't even know what it is ...

It's an alternative emulator created by @StephenHorn

https://github.com/indigodarkwolf/box16

[svenvandevelde]

On 12/19/2021 at 7:03 PM, SlithyMatt said:

It's an alternative emulator created by @StephenHorn

https://github.com/indigodarkwolf/box16

ohhhh! This is very interesting. How come I missed that :-).

[StephenHorn]

On 12/19/2021 at 2:14 PM, svenvandevelde said:

ohhhh! This is very interesting. How come I missed that :-).

I haven't been promoting it out of respect for the X16 team and in the hopes that work would continue on the official emulator. Also, there are a couple of things I'd like to resolve first, such as how to eliminate the need for Windows users to build their own ROMs. As far as I'm aware, I would not be allowed to distribute a build of the current ROM source code with Windows binaries of Box16.

[svenvandevelde]

On 12/19/2021 at 9:29 PM, StephenHorn said:

I haven't been promoting it out of respect for the X16 team and in the hopes that work would continue on the official emulator. Also, there are a couple of things I'd like to resolve first, such as how to eliminate the need for Windows users to build their own ROMs. As far as I'm aware, I would not be allowed to distribute a build of the current ROM source code with Windows binaries of Box16.

I've installed the box16 on my pc, and downloaded the rom.bin and installed it at the root dir of the box16.

But when i start the emulator, i get a blank white screen. Does somebody know what may be the issue?

[desertfish]

Likely a OpenGL driver problem, make sure the emulator doesn't use Intel gfx but rather a discrete AMD or Nvidia graphics card with updated drivers

[svenvandevelde]

On 12/30/2021 at 12:25 AM, desertfish said:

Likely a OpenGL driver problem, make sure the emulator doesn't use Intel gfx but rather a discrete AMD or Nvidia graphics card with updated drivers

Thanks. Just to make sure, I tried the box16 version 39.2.3. with the Kyoto version 38 rom.bin. But maybe this is not the way as it is not working ... 

When I read that the rom.bin needs to be build, how can I build the rom of the version 39 of the rom is not released yet? I mean, where is the source code of version 39 of the rom? How to obtain this source code? Is this the master branch of the rom on github?

Edited December 30, 2021 by svenvandevelde

[desertfish]

Rom source is on the same repository as the official emulator ;  https://github.com/commanderx16/x16-rom/   master branch is the upcoming r39.

You could also download the prebuilt one with LOAD fixes by ZeroByte, posted elsewhere on this forum recently.

Edited December 30, 2021 by desertfish

[svenvandevelde]

On 12/30/2021 at 1:08 PM, desertfish said:

Rom source is on the same repository as the official emulator ;  https://github.com/commanderx16/x16-rom/   master branch is the upcoming r39.

You could also download the prebuilt one with LOAD fixes by ZeroByte, posted elsewhere on this forum recently.

Thank you. And does the rom 39 use zeropage 00 and 01 to address the ram and rom banks respectively? Or are these still done through the VIA addressing?

[desertfish]

the r39 rom adheres to the r39 state of the X16 , and so does box16.  In r39 $00 and $01 are used for banking.

[svenvandevelde]

On 12/30/2021 at 2:40 PM, desertfish said:

the r39 rom adheres to the r39 state of the X16 , and so does box16.  In r39 $00 and $01 are used for banking.

Thank you. So i need to make 2 version of the heap memory manager.

[desertfish]

Perhaps you can make just one version that selects the appropriate banking addresses to be used based on the version of the rom it is running under?

[svenvandevelde]

On 12/30/2021 at 4:46 PM, desertfish said:

Perhaps you can make just one version that selects the appropriate banking addresses to be used based on the version of the rom it is running under?

How can I identify the ROM version in C? Which adres to peek? I have a feeling I'm going to learn something new ...

[Edmond D]

https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md#kernal-version

 

[JimmyDansbo]

On 12/30/2021 at 7:16 PM, svenvandevelde said:

How can I identify the ROM version in C? Which adres to peek?

You read from Addres $FF80 in ROM bank 0

Quote

*=$0801
!byte $0C,$08,$0A,$00,$9E,' ','2','0','6','4',$00,$00,$00
*=$0810

KERNELVER    = $FF80
main:
    lda    $01
    tay        ; Save current ROM
    lda    #0
    sta    $01    ; Set ROM bank = 0
    lda    KERNELVER    ; Read kernel version
    sty    $01    ; Restore ROM Bank

    rts
 

https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md#kernal-version

[svenvandevelde]

On 12/30/2021 at 8:11 PM, JimmyDansbo said:

You read from Addres $FF80 in ROM bank 0

https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md#kernal-version

Amazing ... for testing I can indeed use the above methods, but for production i think it is better to have it really nicely implemented separately.
Anyway, the future will be the version 39, right? So that means that in the future the $00 and $01 will switch the banks, which I really like by the way!

Note that the heap manager switches banks all the time, as there are no pointers but handles. To refer to a memory block, the function heap_data_ptr is used, which receives the handle. So based on the bank information embedded in the handle, the index block is retrieved, and the data handle is unpacked to set the correct bank and return the 16 bit data pointer, pointing to the previously allocated memory block start position in BRAM
(between 0xA000 and 0xBFFF).

 

    enemy_handle = heap_alloc(HEAP_SEGMENT_BRAM_ENTITIES, sizeof(Enemy)); 

    Enemy* enemy = (Enemy*)heap_data_ptr(enemy_handle);

    memset(enemy, 0, sizeof(Enemy));

 

    enemy->health = 1;

    enemy->x = x;

    enemy->y = y;

    enemy->sprite_type = &SpriteEnemy01;

    enemy->sprite_offset = NextOffset();

Edited December 30, 2021 by svenvandevelde

[ZeroByte]

On 12/30/2021 at 8:48 AM, svenvandevelde said:

Thank you. So i need to make 2 version of the heap memory manager.

My sound library builds for both r38 and r39 and puts both builds into the .lib file, and projects that use it can define REV=38 or REV=39 to link the correct version.

The way I did it is that I submitted a PR to SlithyMatt's x16.inc file (which I have grown accustomed to using in all of my projects now) that adds support for --asm-define REV=x where x can be 38 or 39. It defaults to 38 if you don't specify this. When you do this, it creates a define _X16_VERSION_ = 38 or 39. The symbols in x16.inc use this definition to selectively define the values for ROM_BANK, RAM_BANK, YM_reg, and YM_data to the appropriate values for the two revisions. My code also has conditional sections switching on _X16_VERSION_.

I came up with a system of building all files as example.o38 and example.o39 which export their symbols with appended revision tags - helloworld: is exported as helloworld38 in example.o38 and as helloworld39: in example.o39. Then anything that imports should import whichever one is appropriate and alias it with the un-tagged symbol. ( helloworld := helloworld38 )
I made macros for this:
 

Quote

.macro IMPORT_TAGGED symbol
    .import    .ident(.sprintf("%s%d",symbol,REV))
    .ident(.sprintf("%s",symbol))    :=    .ident(.sprintf("%s%d",symbol,REV))
.endmacro

.macro IMPORTZP_TAGGED symbol
    .importzp .ident(.sprintf("%s%d",symbol,REV))
    .ident(.sprintf("%s",symbol))    :=    .ident(.sprintf("%s%d",symbol,REV))
.endmacro

(I switch on REV and not _X16_VERSION_ in the .inc file so it doesn't require x16.inc to be included in order to work properly)

Edited January 3 by ZeroByte
Added more info

[BruceMcF]

On 12/30/2021 at 3:02 PM, svenvandevelde said:

Amazing ... for testing I can indeed use the above methods, but for production i think it is better to have it really nicely implemented separately.
Anyway, the future will be the version 39, right? So that means that in the future the $00 and $01 will switch the banks, which I really like by the way! ...

Definitely ... I presume that sooner or later we will get more Kernel code and with it one or a few more Revs, but they'll all be $00/$01 memory banking from here on out.