Development environment for M65?

  • I love this project and would be interested in potentially making my next game for the M65. A upgraded version of my Aviator Arcade game, but utilizing C65 features. Is there a development environment yet (I couldn't find one, but could have missed something). If not what do you think would be the right timing to begin development? Awesome project!!!

  • Hi and Welcome !

    There are currently two ways to develop for the MEGA65.

    1. The XEMU/M65 emulator. It is still in development but working. sometimes a bit slow. but like i said: W.I.P. Here is a collection of Binaries
    and the link to LGBs (the Developers GitHub page)
    2. you can use a NexysA7 FPGA board from Digilant (previousely known as Nexy4DDR), together with a keyrahv2 and use the latest Bitstream from the M.E.G.A. site. Then you can program on the (close to the) real thing !.

    There is original documentation available for the c65, also on the projects GitHub page you can find a MEGA65 manual W.I.P.

    I hope this helps a bit

    If you need help or if you have questions, please feel free to ask.

    here are some links to some nice MEGA65 Demos (If you haven't seen 'em already...) first, second, third.

  • First, that would be SUPER to have a C65 (or better, MEGA65!) targeted version of your game. We are on the hunt for cool new games for the platform, and maybe that can be bundled for release.

    Okay, so for now, we don't have a nice integrated IDE for the MEGA65.

    What I use is either:

    1. The Ophis assembler, which we have taught how to use the 4510 CPU's new instructions and addressing modes.


    2. CC65 for mixed C + assembly. This is often easier, but has the downside of not (yet) having good support for the 4510 (unless someone has snuck it in), and the C compiler is not that efficient, and so far, has no C65/MEGA65 memory layout, so for now, I just use the C64 memory layout, and load the programs from C64 mode.

    But again, super excited about the prospect of new MEGA65-targeted games, and we are happy to help you in your development experience and answer any questions here, so that you and others who follow have an easier time about it.



  • I find assembler of CC65 is quite great environment for asm-only projects as well, surely I mean about ca65 (the assembler part) of we speak on asm-only project. And that's already comparable with Ophis in the sense that it has full opcode support for 4510 (or whatever we want to name it ...). I am not sure but maybe M65-specific things are missing from both of Ophis and CA65 (ie, "32 bit" linear addressing mode and such, so basically everything over the C65 which is M65-specific). CA65 surely is a bit more complex (even for C64) that is, it's a "modern tool chain" ie separate assembler and linker, but this exactly gives its strength too.

    CC65: With asm-only project, it's perfectly easy to create a C65-mode BASIC stub loader as well, no problem with that. The problem really, with C-only or C/asm mixed stuff, when there is no standard loader (and library btw) for C65. I have some ugly code here:…utils/tree/master/c65izer

    Basically my intent here is to "glue" this front of any c65 compiled stuff meant for C64 (but in theory any "SYS loader" stuff ... not only created with cc65/ca65), and then you can load that directly in C65 mode, without the need to go to C64 mode (GO64) first. Basically it's just an ugly proof-of-the-concept like workaround, what it does: it programs the hardware to meet the criteria of C64 mode, relocates the appended program where it should be in C64 mode, executes part of the C64 KERNAL needed for initialization and "fakes" a RUN command then. Well, it's really not a nice solution, and absolutely sure, it's MUCH MUCH MUCH worse than writing a proper program which can be natively loaded and executed in C65 mode directly, that's true. I haven't even tested it too much, so you've been warned.

    It can be even used as a very crude example how to start a project for C65 mode, btw (asm, basic stub, linker config ...). Again, sorry about the code quality, it's kinda ugly, and also a rather old attempt of mine too.