WIC64 Kernel verwenden und dann?
F1 läd das Portal und F3 startet das dann .... Fehler kommt schon nach dem Laden 
WiC64
- detlef
- Thread is marked as Resolved.
-
-
Ich habe das WICRadio mal getestet mit dem aktuellen letzten Release, was mir aufgefallen ist, gegenüber dem Kernal64 sowie einem original C64 ist, dass beim Lied wechsel es extrem kratzt. Ich nehme im Code extra die Lautstärke raus und füttere vorher den SID nicht mehr, was eigentlich super funktioniert. Aber unter Vice anscheint nicht.
Kann das einer bestätigen?
Naja, "kratzen" nicht ... aber der Sound hakt dann halt für ein/zwei Sekunden und fadet nicht aus .... aber ja, ich weiß was du meinst
-
WIC64 Kernel verwenden und dann?
F1 läd das Portal und F3 startet das dann .... Fehler kommt schon nach dem Laden
fixed.
PS: build laueft noch...
-
WIC64 Kernel verwenden und dann?
F1 läd das Portal und F3 startet das dann .... Fehler kommt schon nach dem Laden
fixed.
PS: build laueft noch...
funktioniert
-
Ich habe das WICRadio mal getestet mit dem aktuellen letzten Release, was mir aufgefallen ist, gegenüber dem Kernal64 sowie einem original C64 ist, dass beim Lied wechsel es extrem kratzt. Ich nehme im Code extra die Lautstärke raus und füttere vorher den SID nicht mehr, was eigentlich super funktioniert. Aber unter Vice anscheint nicht.
Kann das einer bestätigen?
Naja, "kratzen" nicht ... aber der Sound hakt dann halt für ein/zwei Sekunden und fadet nicht aus .... aber ja, ich weiß was du meinst
Irgendwie stockt halt die ganze Emulation, sobald was "ausserhalb" passiert. Habe ich auch schon beobachtet, wenn man ein Verzeichnis mit sehr vielen Dateien lädt (als Virtual device).
Sieht man ja auch an der Speedanzeige, die da kurzzeitig gerne mal auf 90% zurück geht.
-
Meine GEOS-Version des Portal-Launchers erkennt zwar das WiC64, das laden des Portals schlägt aber fehl.
Ich kann ein wenig schauen, ob es an der Emulation oder Deinem loader liegt und ev. herausfinden warum das Portal nicht läuft.
Ich hab jetzt etwas getestet... da scheint das Timing unter VICE nicht exakt so zu sein wie auf realer Hardware.
Wenn man ein Byte vom WiC64 abholen will muss man ja warten bis es bereit steht. Dazu prüft man $dd0d:
An realer Hardware funktioniert das so ohne Probleme... unter VICE braucht es aber eine zusätzliche Verzögerung, die so auch im start.prg enthalten ist:
Display MoreCodeNach dem abrufen von $dd0d sind mind. 4x NOP notwendig, dann funktioniert mein GEOS-Launcher auch unter VICE. 3x NOP reicht nicht, da scheint schon der Empfang der Byteanzahl/Ladeadresse nicht zu funktionieren und danach kommt die Empfangsroutine durcheinander. Ich hatte zwar eine Timer-basierte Warteschleife wenn das Byte noch nicht Ready ist, aber wenn das Byte bereits anliegt, dann wird die nicht ausgeführt. Also hab ich das Byte zu schnell abgerufen. Unter realer Hardware OK, unter VICE (mit x64sc ohne WARP) scheint das problematisch zu sein.
Ich werde die NOPs im Code belassen (auch beim senden eines Byte an das WiC64), schaden tut es bei realer Hardware nicht. Damit funktioniert dann hier alles auch unter VICE. Meine Warteschleife hab ich auch angepasst, dann geht es auch im WARP-Modus.
Getestet mit VICE r39632 / Linux.
-
Display More
Meine GEOS-Version des Portal-Launchers erkennt zwar das WiC64, das laden des Portals schlägt aber fehl.
Ich kann ein wenig schauen, ob es an der Emulation oder Deinem loader liegt und ev. herausfinden warum das Portal nicht läuft.
Ich hab jetzt etwas getestet... da scheint das Timing unter VICE nicht exakt so zu sein wie auf realer Hardware.
Wenn man ein Byte vom WiC64 abholen will muss man ja warten bis es bereit steht. Dazu prüft man $dd0d:
An realer Hardware funktioniert das so ohne Probleme... unter VICE braucht es aber eine zusätzliche Verzögerung, die so auch im start.prg enthalten ist:
Display MoreCodeNach dem abrufen von $dd0d sind mind. 4x NOP notwendig, dann funktioniert mein GEOS-Launcher auch unter VICE. 3x NOP reicht nicht, da scheint schon der Empfang der Byteanzahl/Ladeadresse nicht zu funktionieren und danach kommt die Empfangsroutine durcheinander. Ich hatte zwar eine Timer-basierte Warteschleife wenn das Byte noch nicht Ready ist, aber wenn das Byte bereits anliegt, dann wird die nicht ausgeführt. Also hab ich das Byte zu schnell abgerufen. Unter realer Hardware OK, unter VICE (mit x64sc ohne WARP) scheint das problematisch zu sein.
Ich werde die NOPs im Code belassen (auch beim senden eines Byte an das WiC64), schaden tut es bei realer Hardware nicht. Damit funktioniert dann hier alles auch unter VICE. Meine Warteschleife hab ich auch angepasst, dann geht es auch im WARP-Modus.
Getestet mit VICE r39632 / Linux.
Sehr spannend - das waere das erste Mal dass der C64 auf den ESP warten muss...
Aber die NOPs waren schon immer da (i.e. schon in den ersten Versionen WIC64 C64 Driver) - ich nehme an, dass es auch mit der realen HW empirisch festgestellt wurde, dass man die braucht.
Ich hatte ein aehnliches Projekt (https://github.com/pottendo/c64-userport-driver) ziemlich zeitgleich - ich brauche auch keine NOPs, hatte aber auch andere Dinge vor (siehe userport-drv.asm); z.B. interrupt getrieben, zusaetzliche Steuerleitung um den CIA zu schuetzen, etc. Aber das war mein erster Versuch - bin sicher da sind viele Bugs drin.
Die WIC64 Emulation macht an dieser Stelle sowieso was seltsames:
Display MoreCode- /* PA2 interrupt toggles input/output mode */
- static void userport_wic64_store_pa2(uint8_t value)
- {
- /* DBG(("userport_wic64_store_pa2 val:%02x (c64 %s - rl = %d)", value, value ? "sends" : "receives", reply_length)); */
- if ((wic64_inputmode == 1)
- && (value == 0)
- && (reply_length)) {
- DBG(("userport_wic64_store_pa2 val:%02x (c64 %s - rl = %d)", value, value ? "sends" : "receives", reply_length));
- handshake_flag2();
- }
- wic64_inputmode = value;
- }
I.e. unter den Bedingungen (if (...)) wird einmal zusaetzlich ein handshake (FLAG2 toggle) gemacht.
Ich denke, dass das als 'dummy byte' beim WIC64 driver ankommt. Ohne dem jedenfalls geht's nicht.Siehe:
Display MoreCode- wic64_pull_strt
- sei ; init reading
- ldy #$00 ; set port B to input
- sty $dd03
- lda $dd00
- and #$fb ; PA2 LOW: WiC in send-mode
- sta $dd00
- jsr read_byte ; dummy byte for triggering ESP IRQ
- jsr read_byte ; data length high byte
- sta bytes_send+1
- sta tmp ; counter Hhigh byte
- jsr read_byte ; data length low byte
- sta bytes_send+0
- rts
Das FLAG2 dauert in der Emulation 3 Zyklen (siehe Funktion handshake_flag2()). Vielleicht macht's das aus?
Aber egal - die 4 NOPs werden i.A. unsere Lebenszeit nicht entscheidend verschwenden... bei mir sicher ned, wenn ich darueber nachdenk' was ich hier eigentlich mach'!
happy hacking, pottendo
-
Dazu prüft man $dd0d:
Verhalten sich da neue VICE Versionen noch gleich? Es gibt einen Test (https://sourceforge.net/p/vice…t/dd0dtest.prg?format=raw). Diesen besteht VICE jetzt, die letzte "stable" 3.7.1 noch nicht.
Also wurde da was geändert. Oder besteht da gar kein Zusammenhang?
-
Sehr spannend - das waere das erste Mal dass der C64 auf den ESP warten muss...
Bist Du Dir da sicher?
In den Universal-Routinen gibt es die Routine ":wait_handshake". Da ist eine Schleife mit $ab x $ab x $?? ($0100) = 7.5m Durchläufen enthalten. Bei 10 Takten je Durchlauf (grobe Annahme) sind das 75sek. bis zum Timeout. Bei einer SCPU64 noch ca. 4sek.
Das erklärt warum start.prg mit 20MHz funktioniert, die Warteschleife ist einfach lang genug.
Beim GEOS-Launcher (bzw. bei der lib.WiC64 für GEOS) will ich keine 75sek. warten bis der User einen Timeout bekommt, daher warten die Routinen bei mir kürzer was bei V0.3 dazu geführt hat das der GEOS-Launcher bei 20MHz nicht starten wollte. Ich hab die Wartezeiten etwas verlängert und warte nach dem senden eines (Befehls-)Byte und jetzt scheint es zu funktionieren. Auch am TC64 mit 10MHz.
Also muss der C64 schon ab&zu auf den ESP32 warten... abgesehen von der Zeit die ein Server benötigt um um Client-Anfragen zu reagieren (mir hat jemand mal das Stichwort Sky-DSL gegeben, da sind die PING-Zeiten selbst schon etwas länger...).
P.S. Getestet mit VICE r43949 und XSCPU64/20MHz mit/ohne WARP...
-
WinVice 3.7.1 r43918 mit eingestelltem WIC64 Settings Userport.
XSCPU64 20MHZ GDos64, wic64demo 0.4.
https://bitbucket.org/mkgit64/…4-demo/v0.4/wic64demo.d64
(View Raw drücken zum downloaden)
Einloggen funktioniert. Nur kurz Wic Radio ausgewählt und angespielt.
Auch das hat funktioniert. Klasse....
Liebe Grüße,
Jojo
-
OT: Kleiner Tipp: Über "Downloads" (im Navigationsmenü) kann man das direkt herunterladen... ohne ViewRAW
Aber die NOPs waren schon immer da (i.e. schon in den ersten Versionen WIC64 C64 Driver) - ich nehme an, dass es auch mit der realen HW empirisch festgestellt wurde, dass man die braucht.
Was die 4x NOP angeht... ich hab vorhin in die deutsche Anleitung geschaut, da sind ja ein paar Assemblerbeispiele enthalten. Ohne die NOPs... also sollten die nicht zwingend erforderlich sein...
-
Eine Frage noch zum Demo .....
Gibt es eigentlich eine Möglichkeit, vom WIC64 Demo wieder in's Geos zu gelangen. Wäre natürlich Super, wenn der “Rückweg“ auch machbar wäre.
Liebe Grüße,
Jojo
-
Display More
Eine Frage noch zum Demo .....
Gibt es eigentlich eine Möglichkeit, vom WIC64 Demo wieder in's Geos zu gelangen. Wäre natürlich Super, wenn der “Rückweg“ auch machbar wäre.
Liebe Grüße,
Jojo
Nicht das ich wüsste... der Trick mit SYS49152 funktioniert hier nicht, da der Bereich durch Code vom WiC64/Portal Menü überschrieben wird. Programme könnten ja den gesamten Speicher belegen, also müsste man sowas in das Portalmenü integrieren, was sicherlich keinen Sinn macht.
Besitzer von Ultimate oder TC64 können ja bei Bedarf fboot über den Filebrowser starten, dann ist GEOS sehr schnell wieder da...
-
Schade. Danke für die Info.
-
Was die 4x NOP angeht... ich hab vorhin in die deutsche Anleitung geschaut, da sind ja ein paar Assemblerbeispiele enthalten. Ohne die NOPs... also sollten die nicht zwingend erforderlich sein...
Wie gesagt, die Emulation spielt da mit den Zyklen beim Flag herum - habe ein bissl mit dem Experten gechattet und habe festgestellt, dass z.B. die Wert 5,4 oder 2 das Verhalten der Emulation verschlechtert - bei WIC64Radio zeigt sich das recht schnell.
btw, habe die TZ nun so gemacht, dass die korrekten Zeiten angezeigt werden - auch eine sinnvolle TZ bei Deinem ntp Test.
bye, pottendo
