Hallo Besucher, der Thread wurde 474k mal aufgerufen und enthält 2215 Antworten

letzter Beitrag von Stefan Both am

Kung Fu Flash Cartridge

  • This firmware is larger than the available flash so the .upd file must be kept in the root directory of the SD card

    I must say, this actually does sound like somewhat of a drawback. So far, it was quite easy to swap SD cards between cartridges, even with different firmware versions. Or just pull the card from an SD2IEC device and use it in the KFF without any other steps required. Has the firmware grown to large just because of the merge between PAL and NTSC? Might it still be possible to build a "classic" type of firmware for just one of the video standards?


    Just to be clear, I surely mean no offense whatsoever. The KFF is an awesome piece of hardware and a great boon to our community!

  • I must say, this actually does sound like somewhat of a drawback. So far, it was quite easy to swap SD cards between cartridges, even with different firmware versions. Or just pull the card from an SD2IEC device and use it in the KFF without any other steps required. Has the firmware grown to large just because of the merge between PAL and NTSC? Might it still be possible to build a "classic" type of firmware for just one of the video standards?

    Yes, I understand what you are saying but it is not possible to keep adding features to KFF due to the limited flash size. It is not just because that the PAL and NTSC firmware has been merged but also T64 support required more space.

    I could stop adding features or start deleting features I think is less useful but it would be really hard to keep everybody happy.

  • I must say, this actually does sound like somewhat of a drawback. So far, it was quite easy to swap SD cards between cartridges, even with different firmware versions. Or just pull the card from an SD2IEC device and use it in the KFF without any other steps required. Has the firmware grown to large just because of the merge between PAL and NTSC? Might it still be possible to build a "classic" type of firmware for just one of the video standards?

    Yes, I understand what you are saying but it is not possible to keep adding features to KFF due to the limited flash size. It is not just because that the PAL and NTSC firmware has been merged but also T64 support required more space.

    I could stop adding features or start deleting features I think is less useful but it would be really hard to keep everybody happy.

    Uhm, I do not want to be rude: but why bother with supporting T64-format anyways?


    Imho T64 is just nice to have, hence I won't mind just dropping it in favour of new features and bug-fixes in the future. I know there are some people out there with a different opinion, but hey, let's be honest: do we really need T64-Support? ;)


    Imho supporting T64 as a feature is just taking up precious space which could be used for different things, i.e. not stopping adding additional features :)


    Maybe there could be two branches: "master" feature rich, bugfixes, etc. and one with T64-supports but lacking some other/minor features?

    This would be of course some overhead in maintaining and supporting, but at least might result in a flashable flashfile (size wise).


    Just my two Złoty.

  • Just to give an impression, how others did handle this, if you like the idea...

    http://singularcrew.hu/idedos/compile.php

    Thank you for the idea. I would rather not build and maintain such system but it is a valid input on how to try to keep everybody happy, at the expense of simplicity

    Imho T64 is just nice to have, hence I won't mind just dropping it in favour of new features and bug-fixes in the future

    I should have been clearer; Almost all of the available flash was used. Pick almost any feature you would like to add to KFF and you would have this problem

    But I get your point; only require a firmware file on the SD card for less popular features. The difficult question is which features are less popular and how easy is it to load them on demand

  • kim_jorgensen Does this mean it is impossible to brick KFF during update from Firware 3.0 or later? If yes, then I like that idea!

  • But I get your point; only require a firmware file on the SD card for less popular features. The difficult question is which features are less popular and how easy is it to load them on demand

    I'm not sure that this was precisely rayden 's point, but I think it would be a great idea! If it was possible at all to load "extended features" on demand, that is. It would allow for the proverbial best of both worlds: a set of core-features that "just work" no matter which SD card is inserted as well as almost unlimited room for additional features.

  • Yes, maybe like the latest Firmware before V1.30 which just looks for the "bigger" Firmware on sd card when starting. If its there, reboot and use this file, if not, stay with the "core" features.

  • Does this mean it is impossible to brick KFF during update from Firware 3.0 or later? If yes, then I like that idea!

    Prepare to hate the idea :)
    There is no additional protection against bricking your KFF with this firmware

    is a downgrade of the Firmware to Ver. 1.29 e.g. possible, after upgrading to the Ver. 1.30 or later?

    In other words, can I undo the update to version 1.30 and fall back to an older version?

    Yes, you can downgrade to an older version after upgrading to v1.30

  • Imho T64 is just nice to have, hence I won't mind just dropping it in favour of new features and bug-fixes in the future

    I should have been clearer; Almost all of the available flash was used. Pick almost any feature you would like to add to KFF and you would have this problem

    I got that ;) maybe I should clarify (My point is only valid if my assumption that TC64 support as a feature takes up too much space in comparison to other (f.e. crt, prg, etc) features):


    Branch master: pal/ntsc compatible firmware with most features but _no_ TC64 support, some space left for future bugfixes, small (space wise) features => firmware flashable


    Branch $fullFeatureYouNameIt: based on master but with additional TC64 support, firmware exceeds flash-limit => stored on sd-card


    I don't know your codebase, but it _might_ be possible for future branch maintenance to just rebase $fullFeatureYouNameIt on master to get bugfixes, etc. from master into $fullFeatureYouNameIt. But that's just a guess.

  • Hi,


    I don't know if this is the best / right place to ask, but I'm struggling with getting my KungFu Flash to work. I have managed to solder on all the components (except from the push buttons) and I am pretty sure the card is OK. Since I do not have the ST-Link programmer I have used the USB port and dfu-util to install the firmware. So far no problems, and I have verified that when the USB is connected (and the J1 header shorted) I have 4,9V, 3,3V and GND on the 3 pins to the AMS1117 voltage regulator. Same goes for the header pins marked "+5V", "+3.3V" and "GND".


    But even though all seems OK, when I turn on my old Commodore 64 with the card inserted I only get a black screen. Without the card inserted the Commodore 64 starts normally. I did try to flash 3 different versions of the firmware, but that made no difference. Any ideas at where to start to debug the card? Any voltages on the card I should verify or pins to scope for certain signals? I do notice that the reset LED is flashing very fast when the USB is connected, but I guess that is normal?

  • This firmware is larger than the available flash so the .upd file must be kept in the root directory of the SD card

    I must say, this actually does sound like somewhat of a drawback. So far, it was quite easy to swap SD cards between cartridges, even with different firmware versions. Or just pull the card from an SD2IEC device and use it in the KFF without any other steps required. Has the firmware grown to large just because of the merge between PAL and NTSC? Might it still be possible to build a "classic" type of firmware for just one of the video standards?


    Just to be clear, I surely mean no offense whatsoever. The KFF is an awesome piece of hardware and a great boon to our community!

    It doesn't seem that could be a drawback... we could just organize our sdcards with the firmware revision... isn't it? I am missed something?

  • And now to something completely different.


    Sorry for interrupting, but is there any Software for playing .SID files with the KFF Cartridge?

    Normally i use Sidplay 64 with an SD2IEC connected to my C 64 for playing back .SID files.

    But it can't access the SD-Card in the KFF directly, also with other .SID Players it doesn't work.

    Is there any .SID Player for the C 64 which has direct access to the Filesystem of the SD-Card in the KFF?

    Or is there any Option in the KFF to enable direct Filesystem access to the SD-Card?

  • skjelten:


    I just connected my KFF to the PC and it also started blinking and was recognized als Kung Fu Flash by Windows,

    so the Blinking should be normal.

    I didn't do any further testing.

    Did jou also short Boot 0 with 3,3V like described on the KFF Github page?

  • I do notice that the reset LED is flashing very fast when the USB is connected, but I guess that is normal?

    Yes, this is normal when the KFF is started and cannot detect a valid C64 clock signal. This suggest that the firmware was correctly written to the flash and the problem is likely elsewhere.
    I would double check the solder joints, especially on the resistor networks (RN1 and RN2) and the MCU (U3).

    If you have build more KFF boards you could also try to see if you get the same result with them, or if you have a different C64 you could test with that.

  • Did jou also short Boot 0 with 3,3V like described on the KFF Github page?

    When flashing the firmware? Yes, I did - and dfu-utils reported the flashing to be successful. After flashing both jumpers where removed before attempting to use the cartridge.


    Thanks for checking the reset LED for me 👍