Posts by FeralChild

    mega65 Yes, Open ROMs has moved to KickAssembler completely (but from the logs I can see that some old version is being compiled) and does not need any submodules anymore (but requires Java now to run the KickAssembler).

    The build system has changed since then - to build the newc65.rom file type 'make build/newc65.rom' (or 'make all' if you want all the builds). On my development branch you will find pre-built file (with release date and number embedded in ROM) in 'bin' subdirectory (this change is not merged yet).

    Be warned, however - this ROM has a problem under XEMU, once we try to print a character in the top-right corner of the screen it damages screen memory and crashes. Reason unknown yet, the bug does not reproduce under VICE (I'm curious if this happens on a real Mega65 too...). Unfortunately, the startup banner from Retrofan (default for Mega65 build) does exactly this - I think I'll change it temporarily until the problem is resolved, so the ROM is at least usable under XEMU. Hypothesis: we might accidentally trigger one of the Mega65 extended opcodes.

    spasskl Ophis needs Python 2.x only (not JRE), no Open ROMs version from the past required both Ophis and KickAssembler.

    Unfortunately, I will be rather busy for the upcoming few days and I can't look into this right now.

    Interested in one piece :) To be honest, this design looks much more ergonomic than the C65, with drive facing the user.

    Any price info? Will the black/matt version be available too?

    I'll definitely still focus on Kernal in the near future. My personal TODO list for the Kernal (items marked as '(distant future)' will probably be done only after BASIC reaches certain maturity level):

    1. IEC/IEEE-488

    - test/finish the JiffyDOS - we really need the optimized LOAD loop (I'm considering blanking the screen during loading, SJLOAD does this and is faster than original JiffyDOS ROM), and working SD2IEC is a must for me (I haven't tested it yet) - once these are done, I'm going to merge my changes upstream

    - reverse engineer and implement DolphinDOS protocol (both serial and parallel); blocking point: I can't get it to work under VICE, not yet sure why

    - support CIA 1/2 burst mod - burst is the 'Commodore way', so I would like to have it supported

    - (distant future) Mega65 should be fast enough to implement the burst protocol in software

    - (distant future) native support for IEEE-488 cartridges

    2. RS-232

    - integrate UP9600 driver - already started working on this, but it's a little bit more complicated than I initially thought

    - integrate UP2400 driver

    - support the ACIA mod - Mega65 is going to implement ACIA, I see Gideon is working on ACIA for Ultimate64, so it's probably THE way to provide device #2

    3. Tape

    - add LOAD support for normal (non-turbo) tapes

    - (distant future) implement tape speed calibration in our turbo tape implementation

    - (distant future) try to autodetect file format (normal/turbo) while looking for synchronization sequence

    4. Screen editor

    - there are quite a lot of well-known SYS addresses (already provided stubs), we should support them

    - fancy Mega65 logo display crashes under XEMU - investigate why

    - (distant future) possibly implement some implement C128/C65 features (style TAB-handling, ESC sequences, etc.) using mega65 extra RAM

    5. Compatibility

    - pseudo-IEC device #3 should be supported

    - GEOS (including MP3) should boot; it's autostart code is nasty, it overrides the CPU stack

    - more file browsers should work, not just FB64; FIBR is most likely the next candidate

    - test more games

    6. Misc

    - Mega65 has extra ROM, we should move some parts of Kernal (where it won't hurt the performance too much) to it and utilize the 'far JSR' Mega65 feature

    - we need to provide user-friendly Kernal patcher, so that people can use our Kernal features with original CBM BASIC

    - (distant future) rethink the RAM-under-ROM support concept - IMHO for Mega65 the best option would be to leave the '38911 BASIC bytes' for BASIC text, but store all the variables in Mega65 extra RAM

    Today is a big day - the current unofficial snapshot ( is finally able to load files using JiffyDOS protocol - at least from the VICE-emulated 1541 dive :) It's, unfortunately, not too fast, for now only about twice as fast as the original Commodore IEC - that's because JiffyDOS contains specially optimized LOAD loop, which my implementation currently lacks. But the protocol itself seems to be working and that's important.

    There were other improvements done recently too:
    - official Kernal API is quite complete now; besides RS-232 and limited tape support, the only (I think) missing functionality is a pseudo-IEC device #3 (text screen)
    - RUN/STOP key, HELP keys, and function keys are programmable (at compile time); for now I've programmed F1/F3/F5/F7 with functions similar to Final series cartridges
    - the HELP key... the C128 keyboard support seems to be working under VICE; Mega65 keyboard might work, but the code is completely untested (and F9-F14 keys are programmable too!)
    - RUN/STOP terminates quote mode - I always liked this functionality of my BlackBox cartridges :)
    - there is a simple Turbo Tape 64 compatible loader, can be accessed either by loading from device #7 (like on Final cartridges), or using <left_arrow>L (Black Box v3 and v8 cartridges I was using as a child had it implemented this way); supports LOAD only - no SAVE, no VERIFY, no sequential files; I'm not going to implement them, I consider tape as a legacy medium; loading files saved in normal Commodore format is not implemented yet


    Now... anyone knows how to use 32kb 1541 drive ROMs on VICE? Neither S-JiffyDOS ROM, nor the DolphinDOS works for me, I only get a blinking let after trying to access the disk (yes, would like to have DolphinDOS supported too).

    Maybe you could attract few more donators using the YouTube? Some week ago two new videos appeared, but none of them mentions the fundraising - I think you could tell a few words about it at the end of each clips. Also, there are probably more interesting things to show besides the freezer capabilities - more GEOS apps (show how quickly they launch and run comparing to the GEOS running on C64), maybe some update regarding the CP/M emulation (if the project didn't die), maybe there are some 3D games that can benefit from Mega65 turbo speed?

    1. How about filling the whole back with trapdoors (to reduce cost - maybe use the same size for all of them)? In case someone wants to provide user port + tape port + who_knows_what port exension, so that we won't need to cut the case (like with user port for Ultimate 64).

    2. Are you going to use off-the shelf key caps for the final case, or create own moulds? Taking off-the-shelf ones could probably save quite some cash.

    Nelson - There is not even THE single Amiga mouse. I suppose Commodore would have done what it always did - supply the mouse they happened to have in the nearest warehouse :)

    Honestly, I never really liked the shape of the 1351 mouse. Now I've got a dirt cheap PS/2 mouse connected to Micromys V5 (interface itself is well hidden, connected via cable extender) and I'm a happy man :D

    Note that there is no user-port on either version yet, as this will require an optional expansion board that has yet to be designed, or a special cartridge. Did you want to do interesting serial communications things?

    I just think about device #2 redirected to ACIA... but definitely not in the near future.

    Overall, the devkit looks good :)

    I might be interested in one, depending on the price and features. I have some questions:

    1. Does the devkit have a full C65 keyboard (Scroll Lock, F9-F14, Alt, Tab, etc.), or only C64 keys?
    2. Is the ACIA already functioning (or at least - expected to function after the FPGA gets updated)?
    3. Does it contain a physical floppy drive? (to be honest, I would prefer smaller case without the physical floppy, or Amiga-style floppy location, I'm a little bit short of space)
    4. What switches are you planning to use? Cherry MX? Kailh? Gateron? Is it possible to choose colour of the switches?
    5. Is it reasonably easy to exchange the Kernal/BASIC ROM?

    One more thing... it might be profitable, if ROM could access additional Mega65 registers, whether the software enabled them or not. Especially $D607 and $D608 (but possibly others) - as without them my new shiny SCNKEY won't be able to scan additional C65 keys. And we want them to be scanned - in my development branch keys RUN, HELP (on C128 should work, on C65 completely untested yet), F1-F8, F9-F14 (C65, untested) can have commands assigned (selectable during compilation).

    The Commodore 65 has some additional keys in comparison to 64. In the documentation I can see a keyboard matrix of 8 rows and 9 columns (as opposed to 8 columns on the C64). I've got two questions:

    1. How to read the extra column (the one with ALT, ESC, additional function keys, etc.)? Is it possible to do this from it's C64 mode?

    2. I would like to ask someone with Mega 65 board for a small favour: could you check (on the C65 ROMs in C65 mode) what are the PETSCII keys (if they are any) of the following keys:


    I know there are some C65 emulators, but I really don't trust they correctly map the keys (and - yes, I would like to support this keyboard in Open ROMs as a compile time option).

    I have been thinking about having the CPU in NMOS mode in C64 mode only when running instructions from RAM, instead of from ROM, as this should solve that problem completely.

    IMHO this is the best solution. In the Open ROMs you can currently select the target CPU - there isn't that much optimization yet, but you can already save about 45 bytes if you build for 65C02 instruction set (where you can use PHX, PHY, PLX, and PLY) - it's now realized by Kick Assembler pseudocommands, which fall back to using accumulator on a pure 6502/6510. The 4502 has another nice feature for easy optimizations: branch instructions with offsets in two bytes (BEQ + word instead of BNE + $03 + JMP + word, etc.), I suppose we can also save quite a few bytes.