Hello, Guest the thread was viewed5.7k times and contains 27 replies

last post from dddaaannn at the

Mega65 detection in C64 Mode

    Taking a closer look, the CBDOS change in 920379 that I mentioned is highly suspicious. I see that it does in fact relocate some CBDOS variables to zero page $b0 in GO64 mode. This is an unfortunate choice. While that region may be unused by the KERNAL as far as there not being a tape device present, it's common for C64 programs to repurpose that space precisely because it's typically unused. This is the only substantial change we've made to the C64 KERNAL piece of the MEGA65 ROM (other than the banner change, which should be harmless).


    Prior to the change, the DOS routines used $dff2-$dffb for similar purposes. I don't think it's as easy as going back to doing that, but we could look into it. This does share DOS code with MEGA65 mode, and this change was part of a larger refactoring effort.


    To answer your question, you can find MEGA65 documentation at https://mega65.org/docs, though there's very little special information about GO64 mode because it's supposed to be mostly just the C64 ROM—other than this DOS variable change, apparently. If you're using the Xemu emulator, there are limited debugging features. Open the menu, select Debug -> Start umon on :4510, then either use a tool like m65dbg ala m65dbg -l tcp, or just telnet localhost 4510 and access a few commands like m0000 to inspect memory. If you own a MEGA65, you can request access to the mega65-rom source code repository. Unfortunately it is closed source and only licensed to owners.


    — Dan

    Quote from dddaaannn

    I see that it does in fact relocate some CBDOS variables to zero page $b0 in GO64 mode. This is an unfortunate choice. While that region may be unused by the KERNAL as far as there not being a tape device present, it's common for C64 programs to repurpose that space precisely because it's typically unused.

    Oh, that is of course a "heavy" intervention in the kernel64! This was indeed a rather "unfortunate" modification, because now the 64 mode is "unnecessarily" no longer as compatible as it was and, as you mention, quite a few programmes for the C64 use the unused tape part.

    Quote from dddaaannn

    If you own a MEGA65, you can request access to the mega65-rom source code repository.

    Of course, I own a batch 1 Mega65 (I'm one of the first 400). My intention, when I ordered it, was to try to port GoDot to the Mega (which I dropped in the meantime - not enough info, and tbh, GoDot's home is the 64!) :-)


    Arndt

    Quote from GoDot

    not enough info

    Right.

    When you're used to how well documented the VIC-II and even the VDC-Chips are, then that's really a problem.

    Even more so because the Kawari and the Commander X16 have their graphics capabilities also documented very well.


    So, apparently I'm not the only one who just had stopped investigating because the right information is just nowhere to be found...

    Quote from Snoopy
    Quote from dddaaannn

    I see that it does in fact relocate some CBDOS variables to zero page $b0 in GO64 mode. This is an unfortunate choice. While that region may be unused by the KERNAL as far as there not being a tape device present, it's common for C64 programs to repurpose that space precisely because it's typically unused.

    Oh, that is of course a "heavy" intervention in the kernel64! This was indeed a rather "unfortunate" modification, because now the 64 mode is "unnecessarily" no longer as compatible as it was and, as you mention, quite a few programmes for the C64 use the unused tape part.

    I fully agree. We'll keep the bug open and see if we can restore this.


    — Dan

    My recommendation is to read back the current value of the $d02f (53295) register:


    On C65/M65 in native mode it is $96 (150) or $53 (83), depending on whether the VIC-III or VIC-IV mode has been set up lately.


    On C65/M65 in C64 mode it is $40 (64), as the GO64 command sets it so. (Or maybe one of the above two if a user application has already changed it before.)


    On a plain C64 it is always $ff (255), since not in use.


    On a C128 (in either mode) it is between $f8-$ff (248-255), depending on the extended keyboard lines.


    As for making it absolutely sure, just firstly only read and check it for the first three out of the above-mentioned options ($96, $53, $40), if succeeding, then OK. If it fails, then check it against $ff and try to change it for $40, if succeeding, then it's OK, too. (If you can't change it, then you are on a plain C64.)

    The regression involving the GO64 mode zero page addresses has been fixed in ROM beta 920390. This resolves the issue with TSB.


    More good news: the latest "next" version of Xemu now supports the latest ROM betas. So you can now help test ROMs on real hardware with the latest development core, or on Xemu using the latest "next" version. Thanks to LGB for working on this!