Posts by kim_jorgensen

    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.

    One question. Is there any way to return to the current cartridge once you've pressed the menu button or is the only option to reset?

    You can press RUN/STOP which is similar to pressing the reset button, but I guess that is not what you are asking. There are currently no "freeze" functionality in KFF so it is not possible to resume what you were running before pressing the menu button. That would be a cool and useful addition.

    I registered here because I wanted to say thank you to kim_jorgensen This is such a fantastic project and to think you made it opensource I still cannot believe beacause there are less and less people willing to do this bacuse of so much exploitation of the retro comunity by sellers whishing to quickly make money.

    The cart is fantastic and having tried them nearly all that are being made for the C64 I can say that what you have done kim_jorgensen is so practical and quick to use and I really am so happy about this. I have to admit though that I am not able to contribute to the project because I do not have the necessary knowledge. Is there some way to donate to your project. I'd gladly do so, because I believe in the opennes of the community and the people involved in this beautiful nostalgic hobby.

    Thank you. I didn't make this project for making money so I won't accept donations, but if you would like to contribute then there are other ways than writing code. That could be helping answering questions, filing bug reports or writing documentation

    Would it be possible to make a key press on the keyboard to reveal more than 32 characters of the filename? By this I mean characters from 33-64 for example. I have so much files with revisions at the end and they do not fit the max number of 32 characters per filename. It would be so cool to see the complete file name with a keypress.

    You can sort of do that now by entering the file options menu (shift+enter or long press fire) where you can see the entire filename. It would admittedly be better if you could see the filename directly in the browser, either by a key press as you are suggesting or by automatically scrolling long filenames.
    Please feel free to create feature requests on GitHub, as they otherwise quickly gets "lost" here in this thread.

    I have tried different SID players and up untill now I did not have luck trying to read the contents of the SD card. I guess this is a limitation of how the browser software of the card interfaces with different buses and access storage. I guess the maker of sidplay64 should make a version tailored for KFF unless some way to play files is integrated into the browser. I have seen that Matthias has been trying to make that.

    Yes, floppy emulation is quite limited so sidplay64 does unfortunately not work.

    So I noticed you've been using compiler barriers as well as memory barrier commands - I would expect for a single CPU MCU with no cache, when using the APB peripheral busses, to never need such barriers at all. The ARM as well as ST manuals also describe you don't need them for single-CPU systems when accessing the Device memory areas.

    Did you add the __DMB() for a particular specific reason? Or was this just a way to work around some (probably) compiler/optimizer bugs?

    Both types of barriers are useful in a highly timing critical application as this and not added to address compiler or optimizer bugs.

    The compiler barrier is used to prevent the compiler from reordering or intertwining statements, that it otherwise would be free to do for optimization reasons. This is useful in e.g. the BUS_HANDLER macros where the same code is used together with different cartridge implementations, and without them, some of the handlers would need slightly different timing constants depending on what the optimizer did.

    If you don’t get what I mean with intertwined statements, then try to have a look at the generated assembly with and without these barriers. is great for this.

    The memory barriers, which also acts as a compiler barrier, will ensure the ordering of the data transfers done by the MCU. So the __DMB() was added to ensure that the write operation is complete before stating a new operation, which could happen, as the MCU has a write buffer and the peripheral is slower than the MCU. The idea here was again to ensure a consistent timing.

    I also didn't bother with the reset output driver, just used a regular GPIO in open-drain mode. Works good enough for me on my C64.

    The reason for using a transistor is to ensure that the C64 is reset when the MCU is reset. Without it the C64 will continue to run while pressing the reset button and most likely crash if trying to access the cartridge. But the real problem is that a few pins are defined as output after reset, which potentially could cause damage if the C64 is running.

    I just added the 8 resistors for the datalines, to protect high cross-currents in case of timing problems (That is the reason they are there, right kim_jorgensen )

    Yes, that is something I took from EasyFlash 3 to protect the C64 if the timing is off or the MCU crashes.

    I think, more compatibility is not possible, because the serial port is not used.

    A bit more can be done, such as support for REL files and emulating the command channel. But you are correct, much higher compatibility will require a physical connection to the serial port.

    Would it be also possible to "mount" a D64 from the SD and then copy it to the real drive?

    Based on the discussion early December the answer is probably "no" but maybe there are plans to include something like this in a upcoming firmware?

    Well, there is a feature request for this but no one has implemented it yet :)

    You can mount a D64 and use Basic to copy smaller files over, but that is probably not what you want.