Hello, Guest the thread was called7.3k times and contains 137 replays

last post from mega65 at the

Work is underway to make open-source replacement ROMs for the C64

  • What happens exactly ie., what "lose the capability of mounting D81 images" means? Any error message, etc, console/terminal printout meanwhile, and so on? It is hard to tell if there is not enough input on the nature of the problem :)

  • @ubik, @LGB-Z - the Open ROMs simply does not have the DOS yet, it does not support the C65/MEGA65 built-in floppy drive at all. It supports the IEC serial bus (1541, 1581, SD2IEC, etc.), but it wasn't tested on MEGA65 yet.


    Ah, ok!! That kind of explains everything :)

    Well, I'll have to wait (even more feverishly!) for my Devkit, then :)

  • Variables, arrays - yes. And I would like to allow longer variable names, 2 characters is ridiculously little. But that's a distant future (we don't even have working floating point variables as of yet, only strings), and will be limited to MEGA65 native mode (that's why I'm already clearing all the variables when switching between legacy/native modes). To support something like this we need more space for RAM variables (including zeropage) for the 32-bit pointers, etc. - and in MEGA65 native mode I've gained quite a lot of easily accessible space by putting the screen within $1xxxx segment and dropping the 'dual logical line' concept:
    - it would need quite some work to support above 88 characters in the tokeniser
    - such a long lines of code would be hard to read nevertheless; even in "XXI century style" projects we usually stick to about 100-120 characters per line max, but we tend to use 4 characters for each level of indentation, we have quite long variable names, objects, API calls with 4 or 5 arguments, etc.; for CBM-style BASIC 80 characters per line is already a lot

    As for the text (program), I don't have plans to move it anywhere - I want the program to be preserved when doing GO 64 / GO 65, and be able to easily fall back to legacy mode when user executes BASIC program looking like "10 SYS 2065". I would like to have something like procedures/functions in separate PRG files, or "chainloading" with keeping the variables intact - but again, that's a distant future.

  • Well, it's not that complicated, but:
    - it's a lot of work - the whole variable handling code (and this is quite a lot of code) has to be duplicated, one part using the 32-bit pointers
    - expression parser expect 16-bit pointer to each string, same as each and every command - LOAD, PRINT, etc.; everything has to be adapted, and the 32-bit pointer handling has to be optional (configuration dependent)
    - variable handling does a lot of memory copying; if the user adds a new variable, we need to copy all the array descriptors, string garbage collector copies a lot of memory too - it would be nice to use DMAgic for all this, and I'm not yet familiar with it (80-column screen editor does not use DMAgic yet). In particular, I'm not yet sure how it handles copying of partially overlapping memory areas ("which way" does it copy memory), it might be a good idea to actually reverse the order of memory layout BASIC currently uses - start from strings, afterwards a free area, then array descriptors, and variable descriptors at the end only
    - in the future I would like to have a RAM disk with dynamically allocated storage - so we need to be able to effectively arbitrate memory usage between BASIC and Kernal, this has to be foreseen during development

    And I think that after the 80-column mode text mode is stabilized and useable (there are still a couple of important things to finish), I'll take some time to move from KickAssembler to ACME. It doesn't look like we will see official 65CE02 and MEGA65 CPUs support in KickAssembler anytime soon, and with ACME syntax it will be much easier to integrate code like UP2400, UP9600, or the internal DOS from the Commander X16 ROM project (however, it seems their 2-clause BSD license is not compatible with LGPL 3 - so either we find some solution, or we will have to distribute the DOS as a separate binary).

  • Great, so I don't have a problem with DMA lists.

    There is one more thing, for which I might need to introduce a workaround - I'm quite sure 40 MHz will break the current IEC protocol support. AFAIK both Turbo Chameleon and Ultimate 64 have a workaround: once the IEC-related ports are touched, the CPU speed returns to 1 MHz for the next 1000 cycles - this way both the Kernal IEC implementation and just about every disk turbo can still function properly. Is there something like this planned for MEGA65 (I don't know if it would be compatible with C65 ROM), or should I always switch to 1 MHz for the IEC access?

  • Hello,


    The C65 ROM has IEC code that works at 3.5MHz in C65 mode, I believe. The C64 mode code assumes 1MHz. We could implement something like that, as it does make sense for fastloaders etc. File an issue for me on github, and I'll have a think about how I might best do it. Probably will be based on changing any of the IEC lines, rather than arbitrary writes to the CIA.


    LG

    Paul.

  • Ok, 80-column screen editor merged, can be downloaded from https://github.com/MEGA65/open-roms/tree/master/bin . Remarks:

    - you need XEMU with VIC-IV support; I'm using megawat branch from hernandp

    - editor provides roughly a C64 editor feature set + a "virtual console" - you can scroll back (upwards) up to certain point
    - MEGA65 rom now starts in MEGA65 native 80x50 mode (unless a C64 cartridge is inserted - recognized by the standard CBM80 string), you can manually switch between modes using GO 64 / GO 65 commands
    - SYS command switches to legacy C64 compatibility mode; to avoid the switch use GO SYS command (initially I intended to introduce a new keyword, NSYS - but I wanted it to be easy to produce "fat binaries", where BASIC code detects whether it is C64 ROM, C65 ROM, or MEGA65 Open ROMs, and launches machine code part using appropriate start address)
    - to detect MEGA65 + Open ROMs (in both native and legacy modes) from BASIC, do IF MEGA65 GOTO ... or IF MEGA65 THEN ... - this is actually a hack, MEGA65 is not a tokenised keyword (neither it is a variable, only the IF keyword checks for this particular string), it will display correctly even in CBM BASIC 2.0 editor; on BASIC other than Open ROMs on MEGA65 it will be considered as checking ME variable and (unless ME has non-zero value) the condition will evaluate to false
    - switching between modes preserves program in memory, but clears the variables - for MEGA65 native mode I am planning to move the variables from the usual place to MEGA65 extended memory area, clearing the variables is just a preparation
    - loading anything below $0800 (read: autostart software) should switch to legacy C64 compatibility mode (but this is currently totally untested)

    Last, but not least: THIS IS STILL A PROOF-OF-CONCEPT - MEGA65 native mode memory map might change, BASIC extension described above might change, etc.

  • Great work! Just an extension, if someone needs "XEMU with VIC-IV support" (not so great term, as the master repo of Xemu also does emulate VIC-IV, just not as well!) and don't want to compile etc by his own, then the usual binary download side has that branch too (the third group of downloadables at the bottom): https://github.lgb.hu/xemu/ (though I am not sure how fresh that stuff is, Hernan should drop be a pull request if it's too old ...)