Posts by markusC64

    Stimmt, das ist bekannt. Es gibt Bugreports, dass bestimmte USB Sticks nicht mehr wollen. In 3.10a ist da was korrigiert, dafür wollen andere (wahrscheinlich weniger) USB Sticks nicht mehr...


    Ich habe einen der USB Sticks mir zum Testen geklauft, die mit 3.10 nicht mehr gingen - und mit 3.10a wieder gehen.

    Puh, also zumindest noch ein Lebenszeichen... Dann kann man ja nochmals ein Update versuchen...


    https://github.com/GideonZ/ult…master/ultimate_3.10a.zip


    Den gewümschten Updater daraus als "recover.u2u". Das sollte dann beim Einschalten direkt gestartet werden (der Tipp ist von Gideon allgemein für fehlgeschlagene Updates bei der U2).

    Sollte das gehen: alles machen lassen: Flashen, Konfig löschen, ... egal was, alles machen lassen.


    Muss die 3.10a unbedingt bei mir noch hochladen. Leider gibt es dazu nur eine 99%-ige Stelel der Quelltexte, weil Gideon den U64 FPGA dazu nicht committed hat... Nun, das kommt nicht mehr, ich muss die 99%-Lösung nehmen.

    Und "woanders" laufen beide auf dem U64.

    Da muss man freilich immer fragen, welche Firmware. [Nachtrag: Ich habe Version 3.10a mit zusätzlichen hier sicher nicht relevanten Patches (lediglich U64 Application, der FPGA ist binäridentisch zum Release - aus letzteren folgt, dass es hier nicht relevant ist).

    UII+ und U64 sollten im Prinzip denselben 1541-Emulationskern haben, oder? Hmm...

    Ja. Die Ergebnisse sind auch sehr durchwachsen: Mit einer echten 1570 (sic!) am U64 funktioniert die Version 0.82 (0.84 nicht getestet). Das würde auf die Floppyseite deuten, weil die nun mal ersetzt worden ist. Dass es auf der U2+ mit dem C128 läuft, deutet von der Floppyseite weg.


    So gesehen ist das überraschend. Anderseits kann es eine Kombination von CIA und VIA Ungenauigkeiten in der Emulation sein, die solange nur einer von beiden emuliert ist, passt. Wenn beide emuliert sind mit der Ungenauigkeit, geht es nicht. Das könnte sein. Oder in der emulierten Busverzögerung.



    Ich sollte eigentlich in der Lage sein, die U64 Floppy Emulation mit dem C128 zu nutzen - per seriellen Kabnel einfach verbinden... Dann weiß man, ob in der Floppyemulation ein signifikanter Unterschied ist.


    Wenn es hängt und Du Stop, dann ein- oder zweimal Restore drückst, was passiert dann?

    Ich probiere es aus. Möchte aber darauf hinweisen, dass der U64 die Hardwaremöglichkeit hat, den Inhalt des C64 Busses mit dem Systemtakt zu Debugzwecken zum PC zu schicken. Da kann man dann theoretisch nachvollziehen, was passiert ist - leider muss man dazu den Businhalt irgendwie dekodiert bekommen...

    Hm, an das "AUTOEXEC" hat Gideon zwar nicht ausdrücklich gedacht, jedoch sollte das wenn die Skriptengine erst mal da ist, nicht sonderlich schwierig sein. Man braucht im Zweifel aber Befehle wie "warte bis USB0 gemounted vom ich nenne ihn mal Automounter"...

    Durch eine Anregung von Gideo bin ich jedoch der Meinung, das sollte man allgemeiner fassen:


    Für einen anderen Anwendungsfall dachte Gideon an eine skriptgesteuerte Automatisierung, so dass man ähnlich wie mit einer BAT-Datei unter DOS verschiedene nicht näher genannte Sachen automatisieren kann. Sicher drin enthalten wären solche Sachen wie Image in REU laden und PRG laden. Oder meinetwegen Image mounten.


    Nimmt man dann noch eine solche Skriptdatei namens "AUTOEXEC" hinzu mit der intiuitiven Bedeutung, so wäre man beim automatischen Imagemounten beim Poweron. Kann aber auch gleich viel mehr beim Poweron eröedigen lassen.



    Edit: Bei der Sache, wo Gideon die Skriptsteuerung vogeschlagen hat, ging es darum, GEOS möglichst schnell geladen zu bekommen: REU vorbelegen und dann per DMA "rbbot", "fboot" oder was auch immer laden, um das Booten von REU zu initiieren.

    Nein, wirklich die Kopfumschaltung, so dass man die Rückseite als quasi eigenes Dateisystem nutzen kann mit 664 Blocks frei. "U0>M1" ist was anders, das schaltet in den C128 Modus um (oder wars der C64 Modus, die beiden Werte verwechsel ich immer). Ich rede hier aber von der Kopfumschaltung - mit der man dann die Rückseite eigenständig formatieren kann. So dass man mit "U0>H0" und "U0>H1" zwischen beiden Seiten umschalten kann.


    Dabei sind dann auf der Rückseite in den Tracks tatsächlich GCR mäßig die Nummern 1 bis 35 vergeben. Nicht, wie im C128 Modus die Nummern 36 ff.


    Edit: Ich muss hier zu Testzwecken auch ein eigens dafür angefertigtes G71 haben, wo auf Seite 0 die Geos Startdiskette ist (mit einer Version, die auf Track 36 den Kopierschutz hatte) und die Rückseite eine leere formatierte Diskette ist. Mit U0>Hx umgeschaltet, so dass im Gegensatz zum Diskette wenden die Rückseite die umgekehrte Laufrichtung hat.

    Interessanterweise funktioniert Transwarp 0.82 an meinem C128 mit 1541 Ultimate II+ problemlos mit jener Diskettenemulation. Mit Transwarp 0.84 hängt er aber beim Laden, ansonsten exakt gleiches Setting und direkt hintereinander ausprobiert, so dass nicht unabsichtlich irgendwas anders eingestellt sein könnte.


    PS: Am Ultimate 64 bekomme ich es derzeit nicht zum Laufen, warum auch immer...

    why is there a need for a new .g71 format?

    Is this format really "new"? VICE & Denise already supports it. Ultimate 64 & 1541 Ultimate II+ also (*). Without the format, you cannot format a disk in emulation in 1541 mode and then the backside with "U0>H1" and its format command. Yes, that's the case that does not work with D71.


    So in summary. even standard CBM DOS Commands documented in the manual needs that format to work.



    VICE team decided its bette to have "GCR-1571" header instead of "GCR-1541" header, which males that a new format. Otherwise, it would only have been a valid G64 with other settings.





    (*) with an extension to store also MFM tracks. No need to write that to a floppy...

    G71 ist eigentlich ein G64, mit folgenden Änderungen:


    1) Die Signatur ist GCR-1571 statt GCR-1541, wobei g64conv mir das auch mit Signatur GCR-1541 speichern kann (indem ich als Endung einfach .g64 angebe - für Disketten, die so gemacht sind, dass eine 1541 mit der einen Seite, die jene sieht, komplett klarkommt (lauffähig) und ein C128 mit 1571 eine Rückseite sieht ist das ja evtl. eine sinnvolle Option.)

    2) Im Header gibt es eine Angabe über die maximale Anzahl der (Half-) Tracks, normalerweise 84 (Halftracks). Wegen der Rückseite im doppelseitigen Fall natürlich das doppelte, also 168.

    3) Die Rückseite ist als normale Tracks mit Tracknummer ≥ 43 gespeichert (Track, nicht Halftrack).


    Ich sehe da in Zusammenfassung kein Hindernis.



    Nachtrag: Ist in der VICE-Doku auch dokumentiert.

    Man könnte ggf. ein KF Stream draus machen und mit dtc zurückschreiben. Ok, das wäre jetzt nicht wirklich G71 spezifisch, aber zumindest ein Weg.

    Dabei stellt sich dtc ziemlich schlecht an, nach meiner Erfahrung. Steht IIRC sogar sokumentiert, dass Streams zurückschreiben problematisch ist - kann klappen, muss aber nicht. Einen der kritischen Punkte, die ich ausgemacht habe, ist die fehlende Heuristik für die Write-Splice-Area beim Streams zurückschreiben. Möglicherweise kommt noch eine RPM Anpassungsproblematik hinzu, die prinzipiell ja auftritt, wenn das lesende und schreibende Gerät nicht exakt die selbe RPM haben. Und generierte Dateien haben ja idealisierte RPM.

    Und das Löschen bei Kryoflux ist sowieso so eine Sache...



    Unterstützte Formate wie G64 zurückschreiben, das geht schon eine ganze Nummer besser.


    Userfriedly ist das im Moment also nicht.



    PS: Könntest Recht haben, dass es kein Tool gibt. :-(


    Nachtrag: Mit Fluxhardware und PC Floppy geschrieben bringt außerdem eine Tracklänge, die nicht der RPM der 1571 zum Testen entspricht... Man fängt also umständlich an zu rechnen, wie viel bei der INstallation dann überschrieben wird - mit gerundeten Daten, da man nur Messwerte hat. Nee, mit 1571 schreiben hat aiuch Vorteile. :-)

    Hat irgendwer eine Idee, wie man G71 Dateien übertragen würde?


    Mal angenommen, ich würde meinen experimentellen Wurf auf echter Hardware testen wollen - habe die Geos 128 2.0 Startdisk auf doppelseitige G71 untergebracht - inkl. original Kopierschutz und dessen Abfrage.


    Die "nibtools" unterstützen ja keine im 1571 Sinne doppelseitigen Disketten.

    GeoMakeBoot ist definitiv etwas, was man ausprobiert haben sollte. Es hilft bei 1581, CMD Geräten etc. beim Booten.


    Auf einer 1541 hat der original Geos Loader aber Vorteile, weil er einen integrierten Speeder hat. Zugegeben, wennman sowieso Jiffydos oder ähnliches verbaut hat, schindet der Vorteil gewaltig.