letzter Beitrag von kim_jorgensen am
Kung Fu Flash Cartridge
- kim_jorgensen
- Unerledigt
-
-
Tank you
-
Awesome.....great!!!!
-
-
The Joker, thank you very much for this!
You nailed 60 games out of my wish list of 213 games to be converted to MagicDesk64 format posted in #532 on this thread.
One question - may I include your MagicDesk64 collection in new version of Kung Fu Flash Nirvana collection which already has major update of new disc games thanks to Metallic's update of Disk2Eaasyflash program?
-
One question - may I include your MagicDesk64 collection in new version of Kung Fu Flash Nirvana collection
of course
-
-
da kommt man mit dem spielen ja nicht mehr nach.
Nur weiter so. Ist dann für jeden was dabei.
-
A new firmware update with NTSC support has been released. If you have a NTSC C64 I would appreciate if you would like to help test this release and provide some feedback.
I had to do some small performance optimizations in this release which also affects the PAL version. Please let me know if I have broken anything for PAL C64s
-
What a fantastic idea and solution!
I've been looking at this in forums, and I am really impressed how well everything seems to work. Next to emulating the cartridge I can see al sorts of great usecases, like a bus tracer, hardware failure diagnostics, and many many other things.
I notice the STM32F405 is fully used on the schematic, leaving no free pins. I'm not sure if that is a real issue or not, but as the same IC STM32F405/407 is also available as a LQFP-100, with 32 more GPIOs, is there any reason this wouldn't be a good alternative?
The price of a STM32F407VET6 is only 0.30 euro more than a STM32F405 at this time. The pin-compatible LQFLP-100 405 version is more expensive than the 407 right now (even though its missing the ethernet function).
I think also this particular STM32F407VET6 version is going to stay very popular (its used in countless pcbs) for the next years so stocks of this variant will likely stay high and cheap.
Even better is that the STM32F407VET6 should be pin-compatible with STM32H750, so you could even put a 400MHz part in it!
I tried my hand at updating the rev2 PCB with a 100% compatible LQPF-100 pinout (same pin and port assignements) first as an attempt, where I only added the DMA pin to PD0. This fits quite easily, I'm a novice at PCB development but I think it worked out nicely. I'll try to upload to github. It helps that the position of the same pins on the LQFP-64 and LQFP-100 are on the same sides and same ordering.
But I expect it would be even nicer to move around the port assignments, so that some standard peripherals of the arm are freed up.
It should be no issue to hook up an SPI TFT LCD, C64 serial IEC pins, tape port to the additional gpios.
Another option I looked at for prototyping, is taking one of those dirt-cheap STM32F407VET6 Micropython development boards (7 Euro including shipping from Aliexpress) which breaks out all the 70 or so gpios, then use a cheap adapter PCB to connect that to the C64 expansion port. The dev board is 68x41mm, just a few mm too large to fit horizontally in a cartridge enclosure. It would fit rotated 90deg, but then you need a usb cable hack. Anyway you cant put a screw in the cartridge.
This helps avoiding SMD handsoldering entirely. There are 3 pins though on this micropython dev board that conflict with the Kung-Fu assignments as the dev board connects a SPI flash and a 32 kHz crystal, so PA15,PB14,PB15 are not free. I guess I could just remove those components from the dev board, then again maybe easier to update the flash card code to use PD,PE instead of PB,PC.
Anyway, I am very impressed by all that has already been done, what a great idea!
-
What a fantastic idea and solution!
Thank you very much!
the same IC STM32F405/407 is also available as a LQFP-100, with 32 more GPIOs, is there any reason this wouldn't be a good alternative?
No, I don't see any reason for this not to work.
The current IC was chosen as it was the smallest MCU that does the job. This was to keep the cost at a minimum and have as few pins as possible to solder.
The price of a STM32F407VET6 is only 0.30 euro more than a STM32F405 at this time.
Just note that this IC only has 512kB of flash. 1024kB is need for the full Kung Fu Flash functionality.
Even better is that the STM32F407VET6 should be pin-compatible with STM32H750, so you could even put a 400MHz part in it!
Yes, that would be cool but the STM32H750 only has 128kB of flash it seems. However, I guess you could choose another MCU in the STM32H7 Series with a larger flash.
I tried my hand at updating the rev2 PCB with a 100% compatible LQPF-100 pinout (same pin and port assignements) first as an attempt, where I only added the DMA pin to PD0. This fits quite easily, I'm a novice at PCB development but I think it worked out nicely. I'll try to upload to github. It helps that the position of the same pins on the LQFP-64 and LQFP-100 are on the same sides and same ordering.
But I expect it would be even nicer to move around the port assignments, so that some standard peripherals of the arm are freed up.
It should be no issue to hook up an SPI TFT LCD, C64 serial IEC pins, tape port to the additional gpios.
It would be nice to be able to control the DMA signal or have some spare gpios. Something to consider when doing pin and port assignments is the read/write performance, so you want the firmware to have as few reads or writes as possible and avoid bit shuffling.
-
Hi Kim,
I was able to upload my mod to github here; https://github.com/medzes/KungFuFlash. I updated the schematic pdf too.
On the 1MB flash, yes ok so you need the STM32F407VGT6 or equivalient instead of the VET6. I notice prices go up and down a lot every day of all these components - right now the LQFP-100 devices are cheaper than the LQFP-64. ($3.95 right now on jclpcb). What I'm looking more at is the stock level and device popularity - it seems the 407VET6 is better stocked in general, but I might not read that situation correct. To me it feels like the situation with Atmega where there is an overwhelming popularity of just one or two of the plentyful variants.
Would an external SPI flash or the SDcard help to store code instead of internal? Or is that too slow.
-
Ich will hier sicher nicht die Diskussion auf hohem technischen Niveau unterwandern, aber ich habe ein ganz praktische Frage zur Nutzung des KFF:
Heute angekommen, gleicht getestet - super! Spiele soweit das Auge reicht ...
Jetzt würde ich gerne den DeadTest und Check64 auch per KFF laufen lassen. Vom DeadTest 781220 habe ich eine *.crt-Datei die funktioniert.Dann habe ich mir die letzte Version vom Check64 (CHECK64_v1.4_20190613\3_586220ted_kinzi_4.bin) hier heruntergeladen, die gibt es aber nur als *.bin - läuft leider nicht vom KFF. Dieses sagt:
"File is not supported or invalid"
Gibt es eine Möglichkeit, das zum laufen zu bringen. Brauche ich ein *.crt- statt einem *.bin-File?
Danke schonmal für alle Auskünfte, viele Grüße, Stefan -
Selbst wenn du dieses Bin-File in ein CRT wandeln würdest, würde es wohl nicht funktionieren, da es quasi 4 Programme in einem sind und du keine Dip-Schalter hast, um die Adressen einzustellen. Du müsstest das Dead-Test als einzelnes Bin-File haben, dann könnte man es in ein CRT-File wandeln, welches dann hoffentlich kompatibel zum KFF-Modul ist.
-
-
Probiere mal das CRT von hier (steckt in dem 7z-File):
Danke, läuft! Wobei ich schon einen funktionierenden DeadTest hatte (siehe oben), aber jetzt in der neuesten Version von kinzi!
EIn Check64 wäre mich aber noch viel wichtiger! Gibt es den auch irgendwo als crt?
Selbst wenn du dieses Bin-File in ein CRT wandeln würdest, würde es wohl nicht funktionieren, da es quasi 4 Programme in einem sind und du keine Dip-Schalter hast, um die Adressen einzustellen. Du müsstest das Dead-Test als einzelnes Bin-File haben, dann könnte man es in ein CRT-File wandeln, welches dann hoffentlich kompatibel zum KFF-Modul ist.
Das ist mir klar. Ich habe aber auch nicht das "große" File mit 32kb genommen sondern das Einzelfile mit 8kb.
-
Habe gerade mal einfach "3_586220ted_kinzi_4.bin" in *.crt umbenannt - geht leider nicht! Kann man beispielsweise mit einem HexEditor aus einem *.bin ein *.crt bauen? Oder denke ich da jetzt zu naiv?
-
Habe gerade mal einfach "3_586220ted_kinzi_4.bin" in *.crt umbenannt - geht leider nicht! Kann man beispielsweise mit einem HexEditor aus einem *.bin ein *.crt bauen? Oder denke ich da jetzt zu naiv?
You can use `cartconv` from VICE e.g.
cartconv -t normal -i 3_586220ted_kinzi_4.bin -o 3_586220ted_kinzi_4.crt -
EIn Check64 wäre mich aber noch viel wichtiger! Gibt es den auch irgendwo als crt?
Nein, das geht nicht, denn da fehlt ja noch die ganze Hardware, wie die Cartridge-Platine, Dip-Schalter und Dongels.
Habe gerade mal einfach "3_586220ted_kinzi_4.bin" in *.crt umbenannt - geht leider nicht! Kann man beispielsweise mit einem HexEditor aus einem *.bin ein *.crt bauen? Oder denke ich da jetzt zu naiv?
Oh, Mann! Das geht natürlich nicht! Ein CRT besteht aus einem Header und den Programm-Daten. Wenn, dann geht das überhaupt mit dem Cartconv.exe von Vice, dazu musst Du aber wissen, für welches Cartridge-Format das Bin-File ist und dann damit in ein CRT wandeln.
-
Would an external SPI flash or the SDcard help to store code instead of internal? Or is that too slow.
That would be too slow. If the MCU had enough RAM then you could get away with using that instead of flash but that would break the EasyFlash save functionality.