Posts by FeralChild

    The problem starts when you need a matching ROM for the given program, and you constantly have to switch the ROMs. Back in the day I was rarely using my favorite BASIC extension (Warsaw BASIC 3.2 cartridge), because it was changing the memory map in an incompatible way, so I couldn’t run any existing games.


    Anyway, this is you project, you’ll do as you decide.

    I agree with Richard, we can easily run into ROM hell. The well-known C65 ROM, the reconstructed C65 ROM, the reconstructed C65 ROM with MEGA65 patches (which alter memory layout!) - this is already a little bit messy. Now, on the other front - Open ROMs able to run C64 software, Open ROMs with BBC BASIC. These would be 5 incompatible ROM sets, in my opinion already too much. And we are just at the beginning (100 DevKits manufactured, plus some hacked Nexys boards).


    BTW. I do not intend to implement BASIC 10 - the goal was to be C64 compatible only, in a way as transparent to the user as possible. You can already load a C64 game from the Open ROMs native mode 80x50 screen, type RUN, and it will automatically switch to VIC-II 40x25 text mode and C64 memory layout - this is something the C65 ROM cannot do.

    Another crazy idea: Open ROMs containing both v2-compatible BASIC (without any crazy extensions) and your BBC BASIC port :) There is still 32KB of unassigned ROM left, and if needed another 24KB can be freed by moving my Z80 emulator out of the ROM. This is a lot.

    There were some mentions on the Discord yesterday about using Open ROMs for the BBC BASIC. I have answered, but it is hard to discuss there without a separate channel, and I am not sure if everyone interested in the topic is actively using Discord. Although I indeed have different plans for the BASIC (I definitely want it to be CBM BASIC V2 compatible), it shouldn’t be a problem to have an alternative BASIC interpreter (using the same Kernal API) within a separate ROM build.


    If you wish, I can prepare Open ROMs for this - for the start an alternative BASIC will be just a stub, in a separate directory, to be filled-in by... someone else :D. Just tell me if you need the ‘C64’ mode (in case you want to implement some kind of hack to allow running certain C64 software with BBC BASIC build).


    If no one starts the coding work, there won’t be a BBC BASIC for MEGA65, ever :D


    Regarding the licensing - if you wish your BBC BASIC to be a part of the official Open ROMs, you will, of course, have to clean up the licensing issues in a way Paul is happy with; this can’t be a grey area. If there will be a need to relicense my contributions to some other open-source license (or rather make available under dual-license) - I’m open for this. But you will have to talk to Paul too, as the Open ROMs is based on his work.

    Even easier with Open ROMs since the last release, no need to load any tools :D


    In the native mode:


    - COLORSET 0 - sets the color palette to the default one

    - COLORSET 1 / 2 / 3 / 4 / 5 / 6 - select palette: C65 standard one / Frodo (current default) / VICE / Colodore / community / Deekay - respectively

    - add 128 to the parameter to select a greyscale variant

    - ESC-[ switches to greyscale variant, ESC-] switches to normal variant (these shortcuts are mentioned in the C65 manual, but apparently not implemented in C65 ROM)

    Open ROMs will end up with ?NOT IMPLEMENTED ERROR (or ?SYNTAX ERROR if BASIC 10 tokens are used). It does not even have floating point (or integer) variables support at this moment - since my work on string variables and arrays last year, I have focused on other areas, right now I'm working on CP/M support (definitely won't be finished until Hyper RAM is stable) and some minimal internal DOS for loading files from SD card.

    But once Paul finishes the IEC fix, and I enable the JiffyDOS support on MEGA65 build, you will be welcome to benchmark the drive performance :D

    Great! I've checked the hmw branch, works for me too! Just a question - is it possible to put additional custom file into a virtual SD card (is it emulated at all)?


    I want back to my Z80 simulator - I'm trying to get the Z80 Instruction Set Exerciser Working (implemented a small CP/M simulation, with crude support of the only system call it needs), for now I am experiencing problems with loading the binary from the DevKit SD Card.

    These registers can be used to access the whole keyboard matrix, but in a more convenient way:


    - no joystick interference; for C64 mode I have written a dedicated code to suppress joystick events; original implementation does not have such a protection

    - you do not have to set bits in 2 separate registers to access the given matrix row like in original C65/C128 designs; just put the row number (0-8, if I remember correctly) into $D614 and read the bitfield from $D613; additionally, you have a dedicated register for bucky keys (SHIFT, ALT, etc.), $D611 - this made my keyboard scanning routine much smaller and more simple - see https://github.com/MEGA65/open…board_m65/mega65_scnkey.s


    I’m definitely not going back to the C65 way of scanning the keyboard (CIA + $D607 / $D608 to access additional kb matrix row). I never managed to get it working nevertheless - and when I got the DevKit, I already new about $D613 / $D614, so I dropped the old code.

    M. J.


    I’m not interested in BASIC not compatible with CBM BASIC 2.0. For me the priority is to be able to run the old software and to make it easy to adapt it to the new capabilities. There are better machines to learn modern programming. But, of course, everybody is welcome to come with his own BASIC :)


    Richard Hallas


    It would certainly be possible to hide line numbers (with dummy numbers) from the user this way or another, but you would need a specialized editor, it wouldn’t be possible to use the CBM-like command line. Quite some work, though, to make it a sane tool.

    @Mac Bacon, Snoopy - we will almost certainly have a line number cache for GOTOs / GOSUBs, I am also thinking about preprocessed integers/floats (if I remember correctly, at least ZX Spectrum BASIC does this), as this will speed up not only the jumps. Sure, if you preprocess the whole program first, labels will be just as fast (at least until you allow providing label as a string variable).

    Snoopy Many of the features you want are actually planned for Open ROMs MEGA65 native mode BASIC. But I do not intend to drop line numbers - I would like to stay reasonably compatible with BASIC 2.0 even in M65 native mode. Yes, we can have longer variable names, we can drop/change some minor/problematic BASIC 2.0 features (like undeclared array size defaulting to 10), but I would prefer to retain the spirit of the 8-bit BASIC.


    Also keep in mind that GOSUB <linenumber> will always be much faster than GOSUB <label>. Yes, we have a 40 MHz CPU, but this is not fast enough to completely give up optimizations.


    Nevertheless, if you would like to improve the Open ROMs BASIC - I do not plan any significant work on it in the near future, for now I am going to focus on other areas (M65 screen editor, CP/M mode, etc.)

    C65 mode can probably give you only troubles. C65 ROM needs more space for system variables, it’s incompatible, not yet well known/documented, and in addition - buggy. And C65/MEGA65 are not like C128, their “C64 mode” can be easily escaped and accessing extra hardware (VIC III or IV) / memory is nearly equally easy.


    Regarding SD2IEC - indeed, some delay might be needed, but it is probably enough to just simulate the best case.


    If it’s feasible to integrate the patches - then indeed this should be a better way. We’ll see, Google Translate is quite good at translating from German to English.