Posts by kim_jorgensen

    Problem is that the VIC don't see the ROM using the bus handler so 6502 need to copy data from ROM to RAM and that is why the slow 16 fps.

    Even in that mode you can employ tricks to speed things up; Instead of placing data in ROM, the MCU could autogenerate a C64 program that writes data directly to RAM. This would of course put more load on the MCU.

    As far as I know ultimax mode uses the vic handler and that handler is running in an infinite loop and I don't know if code could be injected to it.

    Kim also wrote a comment on that handler saying it is using 100% CPU so don't know if that could be used.

    I wrote it uses 100% CPU because it spends all the time in the interrupt handler, never allowing anything else to run, but that doesn't mean that you couldn't add more code to the interrupt handler. However, it may be tricky to write game code that meets the strict timing requirements of the interrupt handler.

    If you don't need to handle both CPU and VIC-II reads at the same time, I guess that you could develop a new handler for VIC-II only reads and then switch between the two.

    You think there is room fore some game code to run on the STMF405 combined with the VICII is fetching data from it?

    That really depends on how much work the MCU has to do besides bus handling and how optimized the code is. Why not just make an experiment to get a feel for the limitations?

    I can enter "settings" but I'm also curious about "options".

    Help says something like "+" and hold <shift> but nothing does the trick for me.

    That is the file options. Select a file and press <RETURN> + <SHIFT> on the keyboard or hold the fire button down on the joystick

    Because of the worldwide lack of chips, it’s become practically impossible to make new KFF cartridges. However, there’s an Artery chip which is a drop-in replacement for the STM used in the KFF which has pretty good availability.

    How do you quantify the current availability to conclude that the Artery chip would be easier to source?

    I have been using and searches on as an indicator for the current availability, and it seems that it is still possible to get the STM32F405RGT6 although at a much higher price than just a few months ago. However, searches for e.g. AT32F403RGT6 does not yield any results on the two sites. So from where do you get these Artery chips?

    But it would probably require a rewritten firmware, because of the RAM. Are there any plans for this?

    The project is open source so go nuts, if you think that would be a fun project :)

    kim_jorgensen feel free to use the Sidekick128-PRG-loader-skeleton:…/master/C64Side/cart128.a

    Thank you :). I had considered making a loader based on the example on World of Jani which is similar to what you are doing, but without the use of the datasette buffer.
    For the C64, Kung Fu Flash is using the stack area and allows loading into RAM under the I/O space to support large PRGs, but I'm not sure how creative you need to be on the C128.

    Currently KFF has a size limit of 64kB on PRG files. Does anyone know if this is a reasonable limit for C128 PRGs, or does larger PRG files exist 'in the wild'?

    At poweron, wait for IIRC 5 seconds for PHI to arive. If it does, all is well and waiting is aborted. If not, go on - the U2+ has a standalone mode...

    Perhaps such a waiting for PHI2 can be done in the KFF, too.

    There is already a wait loop for a valid PAL or NTSC clock before the KFF starts. However, if a NTSC clock signal or an unstable clock signal that is detected as NTSC is fed to the KFF during power-up then it fails with the PAL firmware.
    How does the U64 PHI2 signal look like during startup? Do you have a capture of this?

    KFF checks the clock frequency before starting emulating a CRT. This is done to prevent the PAL firmware to start on NTSC machine and vica versa.

    If the U64 does not supply a clock with a stable frequency during startup, this could explain the issue.

    Yes, Kung Fu Flash treats reset and power on the same way so this must be something that is caused by the U64.

    If the U64 board does not supply a stable PHI2 clock on the expansion port during power on that could explain issue but as I don't own a U64 this is purely guesswork.

    kim_jorgensen Is it possible to use cartridge emulation (Retro Replay) and _simultaneously_ "insert" a D64 or D81 image for loading programs and saving?

    Squirrel61 is correct, it's either freezer-emulation OR D64/D81 emulation.

    The disk drive emulation is done by emulating an EasyFlash cartridge where the C64 communicates with the KFF via the EF3 USB registers. It may be possible to implement a custom KFF freezer, but not a general solution that would work with all freezers.

    I have a pretty basic question and I can't quite find an answer for it in this thread: is it possible to save the entire memory state of the C64 and resume it later using the KFF? I like to play some games (loaded from either CRT or D64) that take longer than I have to complete in one session, and such a snapshot functionality would be really helpful to resume later.

    No, there is no snapshot feature built-in so as soon as you enter the menu then it is not possible to resume the interrupted program on the C64. This would be cool but requires developing something close to a freezer in KFF.

    For now your best option is what you are trying and that is to rely on emulated freezer cartridges.

    tcrt-files works great on kff!

    What firmware are you using? :)

    TCRT files is not supported as that would require a physical connection to the tape port to emulate the Tapecart.
    The TapeDevil is a cool collection and luckily they included the d64 files with the programs in the TapeDevil 2/3 release, so you could use these.