Posts by merlintwa

Quote from Kosmas

What one could think about is to include something like the sd2iec. That would be less complex than a 1541 emulation, but even probably too complex for the kff.

So with the Kung-Fu-Flash cartridge as-is the main limitation is that the ARM's available pins are fully used. There is not a single pin available.

TL;DR: I think the KFF is a good balance as-is. sd2iec with somewhat different hardware might work, not sure if it is worth it. Maybe its better to try to convert any missing SD2IEC-supported titles (How many are there these days?) not yet available for KFF, on C64 side to "plain" loading.

I did try to implement connecting to IEC on hardware connection side. I made a prototype version of Kim's KFF, using a version of the ARM chip with more pins available (a 100 pin version instead of the 64-pin version Kim uses). This is the exact same ARM silicon IC, just connected differently to the outside world. Then I connected those additional pins up to the IEC bus, the DMA pin and I also connected a separate SPI color LCD screen using a few pins on top of the KFF module. There are still some pins left over for other fun hobby projects. The size and cost is roughly the same as the 64-pin ARM chip. (Of course adding a few Euro for the IEC connector and LCD screen and anything else)

I had to move around some of the pin connections of the original pinout of the KFF to get it working, so this prototype is not a version that is directly software compatible with the original Kung-Fu Flash. It requires changing the GPIO port addresses with some 8-bit shifts here and there in Kim's ARM source code. Other than that, it is compatible with Kim's software.

I think something like sd2iec might be possible with that prototype pinout, though I never found the time to go ahead and code that. There are also fun things possible with the DMA pin, which I never found the time to code.

When running a C64 game/app, while the ARM is emulating the C64 ROMs, the ARM gets a software interrupt on every C64 1MHz cycle. The ARM then has a small number of cycles to react to that interrupt and process it, toggling GPIOs at 196 MHz. The main challenge I've found is that the ARM interrupt has quite a large latency variation (so number of cycles from the 1MHz interrupt hardware signal to the point the ARM starts running the interrupt code) depending on what the ARM was doing just before that interrupt happened. If you want to draw a parallel, the C64 has an interrupt uncertainty of 1-3 cycles typically, where the ARM can have anything from 12 to 50+? cycles of uncertainty. So all background ARM code written for this 1MHz mode (like the D64 handling) really needs to take into account not a single ARM instruction may cause high interrupt latency (like accessing some slow ARM peripherals). Kim's code is managing that latency very well. In practice with KFF code, the ARM interrupt latency is between 12 and 17 or so 196MHz cycles.

So any ARM sd2iec code would need to be written in a similar fashion.

In the version of Kim's software I worked on, when the C64 is only presenting the KFF menu, so directly after startup, it does not actually run that 1MHz interrupt. In that mode, the ARM does have cycles to spare and if the ARM happens to block for a lot of cycles the KFF menu works just fine. I was able to implement showing the box art of the game in the menu on the SPI LCD screen while the KFF menu is shown.

@Kim thanks again for the fantastic Kung-Fu Flash, it really is a very fun project.

Thats too bad, I would have hoped at least a little bit better score than zero C64's out of 4 working.

If you get a normal start screen but no changed kernal, it likely means its *almost* working, as that only happens when the hiram A14 test fails when the kernal does its first write to $01, and turns the soft-kernal off.

A lot has to go right to get to that screen.

It will take a while before I have time to create some variants with a few strategically placed nops to see if that might help. Making the A14 test longer also shortens the time the data is on the bus near the end of the cycle.

Hello all,

So it took quite a while, but I have been able to get a working soft-kernal mod for Kim's excellent Kung Fu Flash project, for the PCB rev2.

You can find it here: it is a BETA release, with limited testing done.

https://github.com/medzes/Kung…K/KungFuFlash_v1.41SK.upd

This is a PAL-only feature for now.

I have tested this on a plain C64 assy 250407 and a shortboard C64C with SuperPLA. Both work quite stable for me, tested many hours.

But as the timing to get this working is very close, I do expect some refinements may be necessary for other boards (or may never work).

Please treat this as a BETA-release of the soft-kernal mod.

The code size does not quite fit all 1.41 features, I had to remove the Diagnostic feature to have enough room. This may be improved in later releases (maybe using -flto) or with overlay.

If you experience any problems, you should be able to switch back to the regular 1.41 UPD file release from Kim.

I have not modified the launcher menu or cartridge timing, so you should be able to change to another UPD file the same as before.

To use the kernal mode: Simply put a kernal file with .bin extension on the SD card, click on that to activate it. (it will be copied to kernal.bin on the SD card)

The soft kernal is active in KFF Disk Mode (when you long-press Mount a D64/D81), and in EasyFlash3 mode (when you "Load" a PRG with long-press)

You can also press F7 to go to Basic with EF3 soft kernal on.

To no longer use a soft-kernal, you can long-press the kernal.bin file in the root of the SD card and delete it.

Kim has made sure the KFF code supports the JiffyDos kernal well, other kernals may or may not work with the KFF Disk mode.

Note that C128 CRT's are still supported with .bin extension. The code checks if the bin file has a CBM marker for C128.

I want to thank Kim again for this fantastic project!

For some background, I have been working on this on a different prototype board, and I was never sure the special ARM pins in the KFF rev 2 PCB used for EXROM and GAME could make the same timing as the prototype board I used to develop this.

But after merging that with the latest 1.41 release of Kim and finally checking in all the ARM assembly code, and getting my hands on a rev2 KFF cartridge, I have found the special ARM PC14 and PC15 pins have the same timing measured on the oscilloscope as I found on the prototype board.

So, I did open up the ARM/STM32 trickbox quite far to get this working.. Had a lot of fun figuring out the crazy details of Arm Cortex-M4 instruction cycle accurate timing, and how to improve the EXROM/GAME low-to-high signal transitions switching to normal 3V3 outputs very briefly before changing EXROM/GAME back to open-drain.

Also lots of fun trying to work around GCC optimization issues. I've even used a bunch of floating-point registers as globals to meet the timing.

I expect to later release a measurement / logic analyzer tool in KFF that I built to be able to measure the timing for the soft-kernal. It could also be extended with other features, but it first needs a overlay system as the measurement tool won't fit in the 48kB space together with the other code.

LeeBan you may also try converting SID files from the HVSC collection with PSID64 to separate PRG files. Disclaimer I have not tried it extensively. https://sourceforge.net/projects/psid64/

Many SID files are just standard C64 PRG's with a 126 byte header. But some SID files need to be used with a standard playback routine, which isn't part of the SID file. PSID64 seems to handle both cases.

Maybe the logic inside PSID64 could be used to make a special C64 KFF-specifc program that loads the SID file clicked in the KFF menu, does the conversion, and starts the tune.

Quote from kim_jorgensen

A new firmware has been released which improves the disk emulation. This will allow some of the 116 games mentioned by CommFor to work, but not all.

The firmware now also allows the search text editor to be controlled by a joystick, which is useful for the C64GS

Fantasic news! I was hoping the CBM-DOS U1/U2 track/sector block-read/block-write commands would be added.

*Accelerated* standard Kernal loading of files as well as track/sector, is now offered by:

- C64 hardware with JiffyDOS

- C64 hardware with parallel cable SpeedDos, DolphinDOS, ProfDOS, and so on

- All of the main C64 emulators (that I am aware of)

- Many "modern" Cartridges (Don't exactly know which, but BackBit, UC-II, and now KFF as well)

Anyone know if there are "classic" cartridges that offer fast block load?

It would be great if all remaining disk titles that use "special" loading could be converted or have a fallback to do block read/write - they would then work on all those systems!

Does anybody have an idea how many C64 disk-only titles are left unsupported by KFF which don't have a standard CBM-DOS loading version? And how feasible it is to convert them to standard loading?

It does get hairy with titles that use (raster) interrupts during the fastloading while the kernel is swapped in, or that have sprites enabled. JiffyDOS disables sprites during data transfer, so do some of the parallel loaders. Some do screen blanking as well to get rid of badlines.

I reviewed a few titles myself, and found that the ones I checked they had a set of files, where they needed to be able to "seek" (POSIX-style) into (their own list of) files and read / write at a specific position (byte level or block level) of the file on disk. I'm guessing this is ported from other systems that did offer seek at the time. CBM-DOS doesnt offer file seeking (apart from REL files with their own special issues and limitations) so it seems the titles implemented a fastloader with seek support. To make seek work well, you need to be able to calculate directly from the seek position and start of the file, which track/sector its going to be. So I see they use a fixed track-sector interval and use all 256 bytes of each block as file data.

This would have to be replaced case by case with a file table in C64 memory where the offset on track/sector can be calculated on C64 side and sent as track/sector read/write commands. You'd need to remove the old fastloader to make room for this in C64 memory though. And handle or disable interrupts while the kernal is enabled...

About the STM32F405RGT6 availability: If you're planning just one KFF you could order a prototype board with one on it from ali chinaman and desolder it yourself.

No volume manufacturer will go to such lengths of desoldering so the cost of those proto boards (made years ago, still witting in a warehouse somewhere) is not as ridiculous as the loose parts.

I'd not personally expect much fake products there either, its just old excess stock they're trying to sell

Meine besten kumpel hatte ich fast 20 jahre aus den auge verloren - bis etwa 10 jahre her. Nach ein get-together von den alten schulzeit C64 gruppe, hatten wir uns ofter und ofter wieder aufgesucht - und im letzten 8 jahre arbeiten wir zusammen an freelance software projecten, im proffesionelle raum. Macht also ganz viel spass!

Jetzt suchen wir auch wieder zusammen neue projecten im web-develop mit embedded hardware welt, also die etwas weniger standart projecten.

Mein kumpel viele 8 und 16 bit computer und consoles - ich selbe halts bei den C64.

Quote from Schmitti

Nein, die Verstärkung wird nicht so schlecht, dass am Ende 10 V aus dem Regler kommen. Das liegt daran, dass die Schaltung im Regler durchlegiert ist und die Eingangsspannung direkt auf den Ausgang gegeben wird. Das hat nichts mit einem alternden Transistor und sich verschiebenden analogen Parametern zu tun. Dafür hat der 78xx ja eine Regelschaltung.

Soweit ich weiß, ist keine MTBF für den Regler spezifiziert. Wo kommt denn dann überhaupt Dein 10x her? Das Problem ist die Temperatur in der Regel auch gar nicht. Temperaturwechsel sind eher kritisch, also häufig ein- und auschalten

Tja alle electrische componenten haben ein MTBF, ob es specifieziert ist oder nicht. Im algemeine sinne, gilt fur alle componenten das wenn mann sie am rande des max-ratings gebracht die lebenstaur von componenten extrem stark reduziert wird. Es gibt hersteller die daruber eine aussage geben konnen, aber ob es spezifiziert ist oder nicht macht nichts aus - das effect tredt auf.

Langdauer temperatur hat ein exponentielles effect auf MTBF, darum hatte ich ~10x geschrieben.

Ein und ausschalter auch - aber bei LM7805 equivalente erwarte ich das bei C64 nicht,

Alle Liniear-regler sind dieseble schaltung als modere LDO's, sie haben alle ungefahr dieselbe intrinsike probleme am ende von ihre lebenstauer, wobei einfach *alle* power transistoren slechter werden uber zeit durch material degradation - langdaurerig hohe temperatur mit hohen strohmdichtheit - vielleicht vindest du diese LDO analyze bei high-temperature gebrauch interessant. https://training.ti.com/sites/…easy-detroit_tech_day.pdf

Das den regler nach 10V reglet, was du "durchlegiert" nennt, ist naturlich den end-power-stage transistor innerhalb des 7805, die slechter als transistor functioniert als vorher, durch material degradation. Also wir meinen dasselbe.

Aber, transistoren, ICs usw max-ratings usw sind nicht so das man alles machen kann innerhalb diesen ratings ohne effecte auf lebensdauer, noise, usw. Den C64 netzteil fehler mode ist genau ein gutes beispiel von ein fehler type das nicht nur open/closed ist, sondern langsam -mehr-closed.

Quote from Schmitti

Was ist für Dich ein Wedge-Netzteil? Ich meine die C=-Original-Netzteile. Wenn Du die meinst, was ist an den Dioden unterdimensioniert? Die sind für 1 A Dauerleistung ausgelegt. Mehr fließt da auch nicht im Integral. Wenn die Leiterplatte schwarz wird, wurde das Netzteil nicht gut belüftet und stand vieleicht eng eingepfercht in einer Ecke. Das ist natürlich ungeschickt.

Tja, das problem hier ist nicht das es unterdimensioniert auf einzel teile oder wegen max-rating, aber das die 5V regler (einer der viele 7805-equivalenten) am hoheren-ende von den max-ratings fur langere zeiten gebracht wird, wodurch den MTBF von den 5V regler mit ~10x reduziert wird. Das bemerkt man dan bei C64 ofter als bei andere PSU's nach 30 jahren, lese ich hier auch im forum.

Die 902503 PCB versionen mit nur 2 dioden wirden was ich gesehen habe immer schwarz - es gibt auch 4-dioden pcbs von diese 902503 die sind nicht so schwarz. Ist ja nur das den total strohm dan verteilt wird wodurch einzelcomponenten minder locale hitze producieren. (4 aparte hotspots statt 2)

Kann sein das gute beluftung ein problem ist, aber ich hab auch hier im forum images von diese 902503 psu's gesehen mit schwartzen pcb.

Die beluftung in generelle sinne ist nicht zureichend entworfen - und das wird dan noch erstarkt wenn man cartidges oft gebraucht durch den zustatzlichen strohm gebrauch.

Dan was ist dan wirklich das problem: statt power-supply ausfall (kurzschluss oder keine spannung sind beide gut weil die dein C64 nicht beschadigen) nach 20 jahren, geht den 5V regler sehr oft im fail-closed mode. Das ist gerade das problem, den end-stufe transistor im 5V regler wird schlechter und schlechter hFE wird geringer und geringer, dadurch steigt die ausgangs spannung ober 5.5V - sogar bis 10V am ende.

Ich glaube generell gesprochen haben alle Liniair-voltage-regler dieses problem, aber bei den C64 netzteile kommt es einfach viel ofter vor als andere retro gerate. Das kan nur sein weil das 5V regler teil einfach ein viel kurzere MTBF hat als andere retro gerate, aber die 5V regler vor verschiedene hersteller selbst unterscheiden einander nicht viel aus diese zeitalter.

Die viel kurtzere MTBF mit fail-closed endstufe kann dan nur temperatur relatiert sein.

Also am meisten solte mann dan den 5V regler auswechseln (schwerig weill volliig erklebt mit heatsink und trafo, sehr einfach den trafo to beschadigen) und den elcos auch mal ersatzen (leicht). Dan mal wenn moglich den 240V taps statt des 220-V taps von den trafo benutzen (wenn es die gibt).

Find ich zufiel arbeit.

Quote from Schmitti

So schlecht sind die Netzteile nicht. Bis auf den Überspannungsschutz simpel und robust aufgebaut, leicht zu reparieren.

Auch in der Industrie gibt es noch Schaltungen, die 30 Jahre benutzt werden. Maschinensteuerungen gehören beispielsweise dazu.

Die original "wedge" netzteile haben eine billig-schaltung mit unter-dimensionierten 2 dioden rectifier (immer schwartzen pcbs innerhalb des "wedge" c64 netzteile weil diese dioden viel zu heiss werden und den pcb beschadigen), unstabielen +0.1-0.2 volt aus ein 5V regler hohlen mit ein 300 Ohm widerstand im ground-connection. Diese 5V regler wird dan extrem heiss und dadurch ist die lebensdaur beperkt. Und sie sind nicht einfach zu reparieren, weil die 5V regler komplett verklebt ist mit den heatsink.

Im industriellen bereich sind PCB's soweit ich weiss nicht fur mehr als 15-20 jahr entwurfen. Ganze machinen sind schon fur 50+ jahren entworfen aber die electronica in solche machinen wird schon beim aufbau als "replacement part" aufgenommen.

Bei normale (professionelle) maintenance cycle wird dan alle electronica, sensors, power-supplies, jedes 1-5 jahr durchgemessen, wo es gefehlt oder ausser spec ist ersetzt, und jeden 10-20 jahr vollig erneut um schwer-zu-diagnostisieren problemen vor zu sein.

Interessant wird es jetzt mit auto- electronica. Jeder hort horror-stories uber auto's von weniger als 10 jahre alt mit unendlich viel electronica probleme (meistens in nicht-essential sachen wie sensors/dashboard/multimedia, aber vollig kabel-baum replacement kommt zu viel vor). 100+ cpu's in ein auto kommt schon vor.

Al diese electronica ist dan jetzt am ende entwurf-zeit fur autos rund 2000 (wo es nicht schon ersetzt ist).

Wird es keine old-timer autos diese electronica-zeit geben, weil es nicht ersetzbar / emulierbar ist? Vielleicht.

Quote from csdragon

[External Media: https://www.youtube.com/watch?v=ryXSDVXQ9IE]

Sehr guten video, mit referenzen an wikipedia artikel. Fehlt fur mich nur eine aussprach wie oft welcher fehlermechanismus dan normaleweise vorkommt bei retro computing. Und C64-specifiieke sachen wie die ganz schlecht entworfen original netzteile (uberspannung) kommen naturich noch dabei.

Generell: Alle retro chips sind langst im teil III von den bathtub-curve, und deshalb macht es den hersteller nichts mehr aus welches fehlermechanismus es dan exact ist was fehlt. Nur fur spezial anwendungen wie Raumfahrt und Militar bekummert mann noch nach 30 jahre uber functionieren. Fur die meisten practischen Militar anwendungen heute, hat man dieses process schon aufgegeben und versucht man normalen consumer-IC / consumer PCs mit externe mittel wie metal-enclosure, airconditioning, extra-stable power supply, und majority voting so zuverlassig zu machen als vorher mit speziel entwurfen einzel-ICs.

Quote from Schmitti

Normalerweise macht man ein solides Design mit einem aufgebufferten Clock-Tree. Das hat viele Vorteile, unter anderem dass Elektromigration kein Problem ist.

Das hatte das prototype auch, es war genau diese uberdimensionierte buffers im diistribuierten clock-tree die dann gebracht waren um hohere taktfrequenzen (faster rise/fall times) zu bekommen, die dan mit ein unacceptabel hohen ausfall percentage nach lifetime tests im ofen bekommen hat. Das konnten wir dan verbesseren durch hoheren metal-layer zu preferieren fur die clock-leitungen und wo moglich doppel-vias zu routen. Aber trotzdem gibt es tatzachlich ein nicht zu ignorieren percentage failure im feld von IC's durch electromigration.

Ich kann mich dan vorstellen fur C64 IC's, nach den probleme in 1983 sind alle chips etwas anders geroutet oder vias grosser dimensioniert im exestierende mask-set. In diese jahre war den turn-around time von ein neue mask im mask-set (zb. nur alle vias grosser machen) ja wochen stat monate die es 10 jahr spater gebracht hat.

Silicon production ist ja immer so das es einige von den milionen/milijarden vias in einer IC unter minimal-spec gefertigd werden durch production fehler. Diese tiele haben zum beispiel ein via het hohen wiederstand in einer stelle so dass den maximale taktfrequenz des teil etwas minder hoch ist, das wird dan hoffentlich im test phase im production schon detectiert (was nicht so oft wirklich gelingt) und nach binning als low-freq teil verkauft. Aber solche nicht-vollig-defecte vias, sind dan auch genau fur electromigration sehr gefulig und konnen ja dan im feld ausfallen.

In factory-testen sind halb-functionierende transisor und hohere-widerstand via oft nich zu detectieren. Und den effect von ein halb-functionierende transistor oder schlecht geformte via sind nicht zu unterscheiden.

Noch ein annekdote: electromigration war bei ein prototype chip woran ich gearbeitet hab, unerwartet im distribuierten clock-netz, nicht den power linien. Dieses clock-netz andert sich ja 2x pro takt, und hat ausserhalb des power-linien den grossten strohm. Aber, diese clock linien wurden alle minimal-abstand und minimal-width und nur 1 via geroutet - genau so wie alle andere spuren. Das haben wir dan im 1-woche ofen-test feststellen konnen, und reparieren konnen fur den production-variante.

Quote from Schmitti

Sofern die Leitungen im IC nach gewissen Grundregeln designt wurden, ist das nicht der kritische Punkt. Der Effekt kommt dann zum Tragen, wenn ich an die Grenze gehe, was das Material gerade noch hergibt. Dann macht es in der Praxis einen Unterschied, ob Leitungen im IC abgerundete Ecken haben oder nicht. Wenn im normalen IC Elektromigration ein Ausfallschwerpunkt ist, wurde das Design falsch gemacht.

Stimmt, aber CBM hat ja mit electromigration viel probleme gehat damit https://en.wikipedia.org/wiki/Electromigration

"Electromigration due to poor fabrication processes was a significant cause of IC failures on Commodore's home computers during the 1980s. During 1983, the Commodore 64 computer for a time had a nearly 50% customer return rate."

Ich denke als reaktion sind noch immer functionierende teile stark uberdimensioniert.

Problem mit elecromigration ist das es nie aufhort, die ionen im material bleiben immer bei gebrauch langsahm weiter migriren,m wodurch wiederstand hoher wird, wordurch dan mehr local heitzung platsfindet. Bis es fehlt.

Viel C64 chips sind ja normal schon uber 80C nach eine halbe stunde, also das macht electromigration viel mehr ein problem als bei CMOS. Bei CMOS sind es fast immer nur power-linien mit unerwarteten oder schlecht simulierten power-density oder local heating hotspots

Electronmigration ja, auch schwerig dafur zu dimensionieren mit IC tools.

Bei spateren chips wird bei die power-linien, weniger scharfe ecken (45 grat) gebraucht, oder wurden ecken in power-linien stark uberdimensioniert mit viele metal-layer und vias um es so lange wie moglich functioneren zu lassen.

Ja TTL, NMOS, HCMOS chips sind unglaublich uber-engineerd das sie jetzt noch immer functionieren. Das CBM-ziel war das den C64 nur einige jahren functionieren soll. Erst viel spater wurden die meisten chip fehler ursachen gut studiert und dann danach wurden consumer chips am meisten fur 10 jahre functionieren dimensioniert.

Ich erinnere mich seht gut den IC-pin ESD-diode grosse discussion. ESD ist einer der meist vorkommende fehlerursache, und ESD dioden gebrachen sehr viel IC platz = geld. Also wurde damals in 90'r jahren sehr viel zeit genommen um aus zu finden wie klein man den ESD dioden unter jeden pin erstellen kann das den IC die gangingen ESD specification holt. Daneben, in ein ofen auf 200 C fur eine woche um so zeit-effecte zu emulieren. Alles nur um das beste compromis zwichen kosten (silicon area) und lebensdauer zu finden.

Geht auch anders, altere Militar spec IC's und raumfahrt IC's sind eigentlich oft uberdimensioniert so das sie einzelfehler von transistoren uberleben konnen. Zum beispiel alte analog raumfahrt IC's hatten immer 4 transistors in ein schaltung so das diese 4 wie 1 transitor functioniert. Wenn 1 dieser 4 transistor in diese schaltung felht (entweder "offen" oder "geschlossen" fehler), bleiben die ubrige 3 noch immer functionieren wie 1 transistor. (Pioneer 10)

Ich glaube mit C64 haben wir gluck das alles noch immer nach 40-50 jahren functioniert.

Plastix ja ich kenne den systemloader nicht weiter, aber das tool kan ja nur den kernal-rom ersetzen mit C64 RAM.

Also ich hatte das so eingeschatzt hier oben das die benutzer von systemloader die beschrankungen auch kennen.

Nutzlich kan systemloader sein fur eigene C64 experimente, eigene kernal-mods mal ausprobieren, cross-compiler oder hardware checks aber naturlich wird systemloader nicht mit die meisten prg's compatibel sein. Um mit eigene experimente den KFF und systemloader zu gebrauchen sollen die alle auf ein D64 image stehen.

Fur richtige soft-kernal support wie EasyFlash 3 hat, und wie skoe es in sein document beschrieben hat, braucht den KFF neue firmware. So wie ich hier oben geschrieben habe gibt es davon ein beta version, die wartet auf ein freiwilliger die das ausprobieren, messen kann. Danach kan es mit den gangigen firmware gemerged werden.

Ist doch viel einfacher alle files hieroben in ein D64 image zu setzen mit DirMaster, dan wird das doch schon functionieren, oder?

@DerSchatten Es gibt schon ein betaversion von soft-kernal, die functioniert auf mein eigenes KFF-abgeleite prototype mit andere pinout.

Diese soft-kernal wurde ich gerne zum merge mit den gangigen kff software vorbereiten, aber zuerst soll ein freiwilliger den soft-kernal version von KFF mal ausprobieren.

Ich kann das nicht selbst weil ich kein original KFF besitz.

Problem ist das es moglich ist dass den ST-chip GPIO pin fur EXROM und GAME auf meine version "normale" GPIO's sind und im standard KFF sind das "fast-normale" GPIO. Es kann sein das den timing von dieser pins etwas anders ist, und dadurch die ARM code etwas anders sein soll.

Also wenn jemand dass versuchen will dan geht das schon. Auf eigene risiko naturlich - es gibt naturlich das risico das ich eine kleine fehler beim C programmieren gemacht habe fur den normal KFF version.

Steht in meine github-fork

Yeah 10k cycles is enough in any way I can think of. Its only used by KFF on firmware updates andwhen switching between larger than 64kB crt images.

SDcards have similar cycle wear.

For C64 hobby usage 10k cycles will last decades.