Hello, Guest the thread was called809 times and contains 72 replays

last post from LGB-Z at the

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

  • And I've got some good news:

    - sending commands to drive seems to work
    - turnaround mechanism seems to work now
    - receiving bytes from the drive seems to work too :)

    Not tested yet:
    - sending normal bytes (not commands)
    - EOI (end of stream)

    Time to add proper disk support for all these OPEN / CLOSE / CHKIN / CHRIN / CHROUT routines now :)

  • Some features of the LOAD command :) Special handling of the second parameter starts at 256 - this was done mainly for testing, I'm not sure if it's going to stay, or if the syntax won't change here.


    Unfortunately, some of my recent fixes broke IEC for some devices - doesn't work with JiffyDOS drive ROMs anymore (what's interesting, still works with SD2IEC) or Ultimate 64 software IEC.


    BTW, currently 3 flavours of the ROMs can be created - generic one (screenshots), Mega65 (fancy banner) or Ultimate 64 (did some experimentation with their Ultimate DOS interface, code is disabled for now).

  • 1. Paul, what is your plan for de-duplication of code (printf, etc.) between BASIC and KERNAL? I thought about a 'private' jumptable within KERNAL, so that BASIC could access the routines there. For the start, it could be placed in some fixed address, eventually we could extract it's location from the map file and pass it in some script-geterated .s file to BASIC (this way KERNAL would be a precondition for building BASIC).

    2. I really don't like this '61436 BYTES FREE' feature...
    - it's using free memory area starting from $2A7 (compatibility problem)
    - it's complicated and slow: for every BASIC program memory read/write we have bank switching, NMI workaround, even disabling IRQs (I'm afraid TI variable won't like it); good that we at least have optimized memory copy
    I've got another idea - 51199 BYTES FREE (MEMSIZ pushed to $CFFF). Less, but still quite a lot, and with the following advantages:
    - no special handling for memory write needed (read: as fast as original, less maintenance burden)
    - for memory read, we would need much smaller peek_under_rom routine, without all the interrupt-related mess, possibly switching RAM/ROM only when needed; with helper code in RAM of 3 bytes only: LDA ($xx), Y + RTS; this should be much more compatible, we could put it in some poorly documented temporary area (maybe even store/restore original content using the CPU stack)
    - since we would probably have I/O available all the time, we could consider using REU to speed-up shift_mem_up and shift_mem_down routines
    - one more advantage: we could switch between 38911 (MEMSIZ at $9FFF - original behavior) / 47103 (MEMSIZ at $BFFF - the 4KB area above BASIC still free) / 51199 (MEMSIZ at $CFFF) models easily at run time; we could simply extend the NEW / CLR commands to accept optional numeric parameter 0 / 1 / 2 and (if parameter given) switch the memory model

  • For 1, this sounds ok to me.


    For 2, I am happy to have different variants, as I think sometimes people care more about having a bigger program versus faster BASIC. Also, when we make a native BASIC for the MEGA65, the speed and other things are not such a problem. How hard is it to have it selectable at compile time?


    Paul.

  • For 2. - I looked again in Ophis manual, I think we could use parametric macros for this purpose. We could have, for example, 3 directories, exactly one would have to be included to the build:


    ,memmodel_38k - for standard C64 behaviour - max speed and compatibility, lowest memory available
    ,memmodel_50k - a compromise, BASIC memory up to I/O space; I think we could try to put helper code where CHRGET resides in RAM - this model won't be compatible with BASIC extensions nevertheless, so we don't need CHRGET :)

    ,memmodel_60k - current solution

    I'm going to try when I have some more time. I need to finally make this IEC code compatible with non-standard drive ROMs.

  • Also, while I think of it, take a look at KickAss, and tell me if you think it would be a better assembler for this?

    (We would still use the crazy program that does the pick-and-place and merges the individual fragment files together).

    The reason being, is that we are looking to move much of the existing MEGA65 assembly stuff over to KickAss, and also

    use KickC for the hypervisor, and having everything in a more common framework would be nice. But I am also okay with

    sticking with Ophis, if you prefer.


    Paul.

  • Interesting. I thought, ca65 will be preferred, once I also managed to make KS (... hyppo) compiled with CA65 which worked on the Nexys4 board with the M65 bitstream without problem. Yes, the label file stuff was a problem that Ophis could generated something CA65 couldn't. I would be quite interested to see the ideas/benefits to choose KickAss, especially since I don't know anything on that, so it would be a great lesson for me, I guess :) Honestly, I hate java in general, but surely that's a minor point (though I hope it's possible to compile it to a regular sane app with a java->native compiler lke gcj).

  • Part of the interest in using KickAss, is that KickC is MUCH nicer than CC65 for what we want to do. It is only a subset of C, but has a bunch of nice things for 6502, and generates much more efficient (and readable!) code. It should also be easy to get the map file out of it, I believe. My goal is that Hyppo can actually be in 99% of KickC, instead of Assembler, which will make it much easier to write, debug and maintain.


    Paul.

  • I see. Though I am not sure, any C compiler generated code can be near as fast and short than a good, hand written asm code, which can be important for the hypervisor because of the limited hypervisor RAM space. But anyway, sounds interesting :) And since I don't know anything too much about KickC or KickAsm, also a good excuse to have a look.