Das wäre das Sahnehäubschen von KFF das Betriebssystem nachladen.
Vielleicht kann das jemand realisieren und als FW - Update über kim_jorgensen
als Release in github eingestellt werden.
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von kim_jorgensen am
Das wäre das Sahnehäubschen von KFF das Betriebssystem nachladen.
Vielleicht kann das jemand realisieren und als FW - Update über kim_jorgensen
als Release in github eingestellt werden.
Ist doch viel einfacher alle files hieroben in ein D64 image zu setzen mit DirMaster, dan wird das doch schon functionieren, oder?
War das nicht so, dass der Systemlader von Laufwerk #8 lesen will ?
Das Cartride hat ja keinen Laufwerksbuchstaben
Das mit dem Image .d64 ist nicht so verkehrt, wenn der Systemlader so umgebogen wird, das er daraus laden wo er sich gerade befindet kann. Oder ein .x64 konstruieren mit Laufwerksadresse. Das Programm hat doch nur 5 Blocks. Programmierer an die Front.
Sei unser Held.
Den System Lader könnt ihr vergessen, man kann keine größeren Programme laden und nach jedem Reset muß das Kernal neu geladen werden.
Wird bei deiner Lösung denn das HiRam Signal richtig verwertet oder hast du dir da was anderes einfallen lassen?
Wenn das Kernal nicht vernünftig ein oder ausgeblendet werden kann taugen diese Kernal Umschalter leider nicht viel und man hat
bei größeren Programmen immer mit Problemen zu rechnen.
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.
Habe mein Kung Fu Flash fertig gelötet.
Konnte es flashen, habe aber einen Blck Screen. Led geht an.
Vermute aber, dass vielleicht nicht alle Beinchen des Chips richtig verlötet sind.
Ich traue mich das eigentlich nicht mehr weiter daran rumzulöten.
Kurzschluß zwischen den Beinchen ist auch nicht
Wenn sich jemand erbarmt mir das nach zu löten, wäre ich dankbar
Wenn nicht, beiße ich in den sauren Apfel
Sonst mache ich einen Thread unter Reparaturecke auf.
English:
I finished soldering my Kung Fu Flash.
Could flash it, but has a black screen. Led goes on.
But I suspect that maybe not all of the chip's legs are properly soldered.
I don't really dare to mess around with it anymore.
There is also no short circuit between the legs
If someone has mercy on me to solder that, I would be grateful
If not, I'll bite the bullet
Otherwise I'll open a thread under repair corner.
Du kannst es mir gerne schicken. Ich kümmere mich dann darum.
Frage: Wenn ich als ROM Jiffydos eingestellt habe und eine 1541 oder SD2IEC (ebenfalls ausgerüstet mit Jiffydos) funktioniert das dann?
Frage: Wenn ich als ROM Jiffydos eingestellt habe und eine 1541 oder SD2IEC (ebenfalls ausgerüstet mit Jiffydos) funktioniert das dann?
Ja warum nicht?
Kann denn das Kung fu inzwischen auch den Kernal ersetzen?
Frage: Wenn ich als ROM Jiffydos eingestellt habe und eine 1541 oder SD2IEC (ebenfalls ausgerüstet mit Jiffydos) funktioniert das dann?
Ja warum nicht?
Kann denn das Kung fu inzwischen auch den Kernal ersetzen?
Weil es in der Beschreibung im C64-Wiki nicht auftaucht.
Soweit ich weiß, kann das zumindest die „offizielle“ Firmware des KFF noch nicht.
(Edit: Siehe 6 Posts weiter oben...)
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.
Good guess - At the time where the U64 is powered on the FPGA needs to be loaded and started, therefore some time passes before PHI2 is available.
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.
Da frage ich mich doch sofort, ob das so erweitert werden kann, dass es 16k bzw. 24k Kernal auf dem KFF unterstützt.
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.
Good guess - At the time where the U64 is powered on the FPGA needs to be loaded and started, therefore some time passes before PHI2 is available.
Das Laden und starten von .PRGs und .D64 klappt aber. Also wird doch das KFF ordentlich gestartet? Bzw. wo ist der Unterschied zum Start einer .CRT von der SD-Karte im Gegensatz zu .PRG und .D64?
Weiß nicht, frag Kim.
Dunno, ask Kim.
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.
Good guess - At the time where the U64 is powered on the FPGA needs to be loaded and started, therefore some time passes before PHI2 is available.
Das Laden und starten von .PRGs und .D64 klappt aber. Also wird doch das KFF ordentlich gestartet? Bzw. wo ist der Unterschied zum Start einer .CRT von der SD-Karte im Gegensatz zu .PRG und .D64?
Does it help if you keep the KFF in reset for a couple of seconds or wait a bit and reset the KFF?
The reset button is connected to the reset of the MCU (and some resistors/transistors make sure the C64 is also reset). THis perhaps can resync to the PHI2 clock.
Well, starting of .PRGs, .D64 and .CRT itself works when the Ultimate64 is running. (Not talking about a real C64).
Only flaw there is, that upon bootup, when the Ultimate Unit is switched on, .PRGs and .D64 do the autostart as expected.
Just .CRT-Files won't autorun, instead the Filebrowser of the KFF shows up.
KFF checks the clock frequency before starting emulating a CRT. This is done to prevent the PAL firmware to start on NTSC machine and vica versa.
If the U64 does not supply a clock with a stable frequency during startup, this could explain the issue.
Could this check be removed to make it compatible to the Ultimate devices then?