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?
Seems to be plenty of juice left for running code on the STM when using the C64 bus handler.
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.
This is bitmap mode so if using text mode the CPU should be able to copy a whole screen within a raster scan.
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.
This is bitmap mode so if using text mode the CPU should be able to copy a whole screen within a raster scan.
If I am not wrong in Ultimax Mode the VIC should to access data from the catridge.
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.
This is bitmap mode so if using text mode the CPU should be able to copy a whole screen within a raster scan.
If I am not wrong in Ultimax Mode the VIC should to access data from the catridge.
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.
In c64_interface.c:
#define C64_BUS_HANDLER(name) <- The one I use atm
---
// This supports VIC-II reads from the cartridge (i.e. character and sprite data)
// but uses 100% CPU - other interrupts are not served due to the interrupt priority
#define C64_VIC_BUS_HANDLER(name)
Seems to be plenty of juice left for running code on the STM when using the C64 bus handler.
[External Media: https://www.youtube.com/watch?v=ncyAJKaVR8A]
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.
This is bitmap mode so if using text mode the CPU should be able to copy a whole screen within a raster scan.
I see mode 7 coming for the C64.
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.
Display MoreHi!
Inspired by Carsten’s RasPIC64 project and my experience with Tapecard SD I have created a new cartridge called Kung Fu Flash and released it as open source.
Kung Fu Flash can emulate different cartridge types, load PRG and D64 files from the microSD card and support EasyFlash 3 USB. It is what I call a Software Defined Cartridge, where a fast microcontroller emulates cartridge hardware in software.
You can find the project here: https://github.com/KimJorgensen/KungFuFlash
This is still work in progress; there is no write support, only the PAL version of the Commodore 64 is supported and the latest version of the gerber has not been tested yet.
Built your cartridge yesterday Kim. Only had 0402 capacitors and resistors so I had to do quite a lot of fiddling, but I managed. Worked in 1 go. 
I have been flashing STM32's before, but ran into issues never experienced before (Kali Linux / OpenOCD / ST-Link V2.0). Had to unlock first before I could write, never experienced that before.
May I suggest to go more in depth on the SWD procedure on your GitHub page? Maybe a bit more documentation on that subject will help a lot of people I think.
Just 1 small point of attention, it would have been more practical to have a separate jumper on the board for connecting Boot0 to 3v3. Once you hook up the ST-Link it is tricky to connect Boot0 to the 3v3 pin next to it as the lead from the programmer already occupies the 3v3 pin.
But once I got it flashed ..
I can only say: Awesome! This definitely is 'The Final Cartridge' I will ever need.
Truly a great project, a big, big! compliment for your work Kim!
The fact that you had to unlock the STM32 before you could flash it, could mean it has been used before. Did you buy it from China? I flashed a few KFF's but never had to unlock the STM32. But I sometimes buy programmable chips from China, always advertised as "brand new, genuine and unused" and all of it has been proven to be untrue.
This could be well the case indeed. They came from China.
Where in china you have bought the STM32 ?
Where in china you have bought the STM32 ?
Found it on Ali Express.
Display More
And the Price?
I have ordered 4 Pieces on Ebay for 5 Euro plus 7 Euro for Postage.
The Dealer said, that the Chips are comming back to him.
4 Days Later the same Chips cost 50 euro.
I take a look. Very Hot Price.
Cleverer Verkäufer 
The fact that you had to unlock the STM32 before you could flash it, could mean it has been used before. Did you buy it from China? I flashed a few KFF's but never had to unlock the STM32. But I sometimes buy programmable chips from China, always advertised as "brand new, genuine and unused" and all of it has been proven to be untrue.
Same happened to me when I ordered from China and at the time I was working on my dumper tool I use to order from China in hope that they came read protected. (RDP1 or RDP2) Usually they came with RDP1 but I also once got an RDP2 protected chip which required double glitching to get the firmware out. One funny thing is that this RDP2 protected chip could also be downgraded to RDP1 and then RDP0 by erasing the content so the chip worked flawlessly after this. Info from STM states that after setting RDP2 it would be impossible to downgrade again 
And in case some one is wondering how to dump a read protected chip then wallet.fail did a great job on this that was introduced at CCC some time ago. This is of course only the first step but helped me on the right path.
I have been flashing STM32's before, but ran into issues never experienced before (Kali Linux / OpenOCD / ST-Link V2.0). Had to unlock first before I could write, never experienced that before.
The STM32 ST-LINK Utility from ST does actually detect if the STM32 is locked and has an option for unlocking it.
May I suggest to go more in depth on the SWD procedure on your GitHub page? Maybe a bit more documentation on that subject will help a lot of people I think.
Yes, the documentation is a bit short. Feel free to create a pull request if you have any specific ideas to improve it
I can only say: Awesome! This definitely is 'The Final Cartridge' I will ever need.
Truly a great project, a big, big! compliment for your work Kim!
Thank you, I'm glad that you like it.
With last firmware (1.28) Prince of Persia finally works on my C128 with Kung Fu Flash using "Run (VIC-II/C128 mode)" from the file options menu (shift+return). 
With last firmware (1.28) Prince of Persia finally works on my C128 with Kung Fu Flash using "Run (VIC-II/C128 mode)" from the file options menu (shift+return).
Great. I didn't know that anybody had problems with Prince of Persia on the C128
With last firmware (1.28) Prince of Persia finally works on my C128 with Kung Fu Flash using "Run (VIC-II/C128 mode)" from the file options menu (shift+return).
Great. I didn't know that anybody had problems with Prince of Persia on the C128
I discover and i used the feature "Run (VIC-II/C128 mode)" recently, my fault 
Anyway, thanks for your effort
Display More
And the Price?
I have ordered 4 Pieces on Ebay for 5 Euro plus 7 Euro for Postage.
The Dealer said, that the Chips are comming back to him.
4 Days Later the same Chips cost 50 euro.
I take a look. Very Hot Price.
Paid €15,00 per piece including shipping, they don't have them anymore now. It's hard to find any STM32's these days due to the chip shortages. Guess I was lucky.
