Hello, Guest the thread was called61k times and contains 776 replays

last post from merlintwa at the

Kung Fu Flash Cartridge

  • What are the sizes of the sd cards? I think all kinds are supported but just asking.

    Are all cart formatted fat32 (not exfat as no support compiled in). Also some sd cards have a partition table which can act different under windows or this cart.

    What is the exact error message or are you getting an empty folder?

  • This 30 posts limit is complete rubbish... people posting nonsense just to get to 30... you joined in 2013 this should be more than enough...

    If we (mods, or admins) are aware that someone will post nonsense just to get access to the "Wolke", we'll delete this posts and warn the user to stop doing so.
    If he continues to do so, his account will get deleted! It is as simple as that!

    The reason for this rule is that ppl should take part at the Forum64 family life and not just come here to leech files!
    Now please stop whining about our board rules and please get back to topic!

    Thank you.

    Asking where the wolke is gave me access :whistling::saint:

  • Sjaak74 thanks for answering.

    I have checked the Micro SD Cards:

    4gb Intenso Fat formatted did not work.

    8gb Transcend Fat32 formatted did not work.

    The message then is...

    "File is not supported or invalid


    My 16gb Hama Fat32 formatted card i use with my 1541u2 did work fine though.

    Actually no problem, i can use this card for the next update as well.

    I just wanted to know if there is a known issue with some cards/fat formats/cluster sizes.

    Or better: are there certain recommendations.

    As i also betatest Easyflash releases on the KFF for EXCESS i would like to know if there are problems i might run into with "wrong" cards or formats.

    Anyway thanks for reading, best regards,


  • I can confirm that Transcend 8gb microSD card is not recognized. Transcend 4GB works though.

    Maybe it't time to start new thread KFF compatible cards?

  • Hi all,

    The current generation of large SDcards has more formatting options than older generations have. Off the shelf you can get cards already formatted in the factory as FAT16, FAT32 or exFAT. Then you also have SD, SDHC, and SDXC variants. The official standard tells manufacturors which filesystem to use for what type, but in practice some manufactorors just "do something" which isn't fully according to the standards.

    On top of that, Windows has a long history of not properly writing out all the duplicate recovery bitmap of the FAT/FAT32/exFAT block allocation tables, as well as "file system is clean" marker that the filesystem has, when you remove an sdcard from the PC.

    The "file system is clean" marker and duplicate bitmaps do seem to be written more often by Windows when you do a a"remove hardware safely". But, unfortunately not always.

    To figure out SDcard issues, it would be great to get the details for every non-working SDcard, which exact filesystem it has, and to first try to make sure it has a "file system is clean" marker by doing a "Safely remove hardware" on windows, to determine if that is the source of the issue.

    Many of the smaller open source FAT filesystem libraries don't properly support all the non-clean filesystem cases, and abort. Some libraries support FAT16 and FAT32 but not exFAT.

    Some FAT libraries try to stay clean and easy to understand, by only supporting exactly what the official FAT/exFAT standards say should be done. But windows does require a few things and do a few things that are not in those standards.

  • I have add (experimental) support for the Expert cartridge and Georam Cartridge (only 64K for now). Expert cart can be loaded when the appropriate crt is selected in the directory menu, but it can also be programmed in through the C64 itself. For that the settingsmenu has a new setting 'Expansion on F8'. This setting controls if nothing (none option), expert cartridge (expert option) or Georam (Georam-64K option) is active when the F8 is pressed in the menu. The '---' option will do nothing, but i have allready plans for that.

    In order to program the Expert cart make sure the Expert is selected in the Settings menu. Press F8 somewhere in the menu and you get into regular C64 mode. The cart is now in 'Program' mode. Load the Expert disk and select the appropriate payload you want. when the programming is done reset your commodore as requested. The payload should be executed. For resources about the Expert cart I found this one: Expert Cartridge - ReplayResources (pokefinder.org)

    A few notes:

    - I noticed the expert doesn't play wel along with Jiffydos active, make sure stock kernal is used.

    - Also I couldn't get the freeze button to work properly, so only the restore key and fiddling the CIA works.

    The Georam is for now only 64K big and rolls over omn every 64K which makes it not very usefull at the moment. I think we can push it to about 160K in the end (but requires a bit of rework of the code). Dunno if it is usefull then too, but for simple disk-copying or native compiler like TMP it will suffice. 512K (which is the smallest Georam) is out of reach without a major hardware change.

    I did my development on a PAL SX64 which gives me some minor glitches and I want to rule out if the SX is the problem. I attached the NTSC adn PAL version of my build. Note it is based on the 1.19 release and not the 1.20 release. Also NTSC isn't tested at all.

    Love to hear if it works or not. Please state some specs about your setup (like pal/ntsc, type of motherboard, SX or plain, etc).

    In the end I will produce the code on my github and issue a pull request to the official repo.

  • I don't think so. In order to get it to work, we need to read 256 bytes into the buffer in 84 CPUcycles (which is 42 SPI-cycles @84MHz). With Quad-SPI this will take roughly 2 cycles for the command, 6 or 8 cycles cycles to setup the address and 512 to read those bytes from memory. besides the chip is also 45MHz and we would clock it to fast in the example above.

    I've read somewhere you can stall the CPU. The reu works like this. after the transfer is started no code is executed untill the transfer is completed. Bankswitching (as proposed by Jood) could be possible if we know the application or there is a kind of of ready flag.

    It is much easier to get a seperate Geo/Neoram, Reu or +60K installed in your C64. (like jood proposes :))

  • I've read somewhere you can stall the CPU, but don't know how feasable this will be.

    The 1541 Ultimate does this whenever you press its menu button. So it's known to work great. Here is a technical description: https://github.com/GideonZ/154…0freezing%20the%20C64.pdf

  • Well,

    I'm currently wiring up the prototype board of a 100-pin version of the STM32F407 for KFF.

    - I had to move around a lot of GPIOs to meet with the already used pins on the prototype board

    - There are now some spare pins but it is less than I had hoped. There are around 15 pins left to be wired up- but they are in various places, not contiguous.

    This 15 pins free is not enough pins to do - say - external fast 1MByte of 8-bit SRAM. You would need an even larger package of the STM32F407 for that.

    I've seen someone mention using a different IC in this thread - I think that would be a lot of work.

    There are successors to the STM32F (STM32H7) that offer 1Mbyte of SRAM, but just 128kB flash. It wouldn't be compatible with the KungFuFlash firmware though.

    The whole system would need to be re-architected for that setup - its radically different from the current approach. The ARM program does not need to fit in 128kB - it can be loaded from SDcard on demand. But that is quite a lot of effort to all do. The part does go at 400 MHz giving more headroom for other features.

    But when you consider moving IC, maybe the sidekick solution with a Rasperry Pi makes more sense.

    Yet another possibility, if you want to really spend very serious time reprogramming everything, is using a small linux Cortex-A7 module. There are 8 euro tiny linux modules with around 80 GPIOs. I found one with 64MB DRAM in the IC and runs at ~1GHz - but these are 3.3V only, so will need levelshifters. Probably just a few bus transceivers 74LVC16245 with OEN tied low would work though to make all inputs 5V tolerant.

  • Note that one reason I am using the 100 pin part is to connect the DMA line.

    The current KFF doesn't connect the DMA line as there are not enough pins. I think you could - for prototype kind of reasons - sacrifice the LED on the KFF, connect the reset driving transistor to PC13 (PC13 is limited to 3mA drive strength and frequency), then you have PA15 as an output for DMA. Its on a different port from EXROM/GAME then so will need some more cycles to set/clear.

    In my pin config currently I have GAME on PD0, EXROM on PD1, DMA on PD3.

  • We need a Kung-Fu-Easy-flash Cartridge with D64 support!! :D

    Häh!? Kung Fu Flash can already load from D64 or do you mean real floppy emulation?

    It also support save to disk:

    It took a while but now I finally got the basic save functionality PR from dikdom merged and released.
    I extended it a bit to also include D71/D81 save support, a setting for changing the device number requested by Sjaak74 and a disk image autostart requested by CommFor and The Joker