Geos Wheels Masterdisketten

Es gibt 102 Antworten in diesem Thema, welches 11.689 mal aufgerufen wurde. Der letzte Beitrag (29. Mai 2023 um 20:49) ist von markusC64.

  • PS: Thema Uhren: funktionieren die überhaupt noch bei echter Hardware? Oder sind die Batterien längst leer und die Uhren Tod. (Achtung Gefahr: bei HD ist wohl eine seperate Batterie drin, wenn die ausläuft .......

    Ist zwar Off-Topic.

    Wenn die Batterien noch funktionieren, gehen die Uhren noch.

    Die HD hat einen Akku drin, dürfte bei mir nach mehreren Jahre ohne Strom tot sein.

    De SmartMouse bzw. SmartTrack haben eine eingelötete Batterie, funktionieren bei mir noch.

    RamLink und die FD's gab es mit oder ohne RTC.

    Gruss C=Mac.

  • Wenn die Batterien noch funktionieren, gehen die Uhren noch.

    ich habe meine HD40 letztes Jahr wieder aus dem Dornröschenschlaf erweckt, ein FW update aufgespielt und die RTC gecheckt.

    Nach 25 Jahren im Regal hatte die Batterie noch 50% Leistung. Habe die dann ausgetauscht und die RTC neu eingestellt.

    Für die Einrichtung einer HD unter VICE gibt es einen eigenen Thread hier.

    ok, dann gehe ich mal auf die Suche ...wenn man das nicht mit 3 Klicks erklären kann ...

  • Bei der Original-HD kann man die Batterie noch tauschen, ist übrigens kein Akku.

    Bei den FDs wirds schwieriger, es gibt zwar noch Uhrenchips mit vergossener Batterie NOS, aber die werden wohl auch bald alle leer sein.

    Ich hatte damals was gebastelt:

    Bitte melde dich an, um diesen Link zu sehen.

    Aber da ich mir hier keine Werbung o.ä. nachsagen lassen möchte, sage ich gleich: Das ist nur Proof-of-concept und wird auch so bleiben.

    Kann man also machen. Auf den anderen Repliken sind nur die reinen Uhrenchips drauf, alle gespeist durch CR2032-Knopfzellen.

    ?SYNTAX ERROR
    READY.
    Bitte melde dich an, um dieses Bild zu sehen.

    Letzte Projekte:

    Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen. / Bitte melde dich an, um diesen Link zu sehen.

  • P64 ist ein fluxbasiertes Format - wie man aus der Darstellung nebenan des Kopierschutzes erahnen(!) kann, kann g64 den Kopeirschutz nicht vollständig darstellen (Speedabweichung auf Teilen von Track 35 klappt nicht).

    Schwierig, das auf eine echte Floppy zu bekommen.

    Noch ein neues Disk Image Format - P64 - man lernt nie aus.

    Speedabweichung - das dürfte man konventionell mit Nibwrite/KryoFlux/Supercard Pro/FluxTeen und Option Board nicht direkt kopieren können? Oder doch - da "MakeSysDisk" den Kopierschutz mit einem normalen Commodore Laufwerk erzeugen kann?

  • Jaja, das mit der echten Floppy soll so lala gehen, ist aber nicht besonders kompatibel. Aus dem Grund habe ich das erst gar nicht erst versucht.


    Warum ist das so? Der VICE muss doch nur das Handling des seriellen Busses hinbekommen. Alles andere läuft doch mit originaler Hard- und Firmware (CBM DOS) und muss nicht emuliert werden. Ich verstehe nicht die stiefmütterliche Behandlung dieser Option in VICE. Am Mangel an echten Floppy Drives für die Entwickler kann es ja nun wirklich nicht liegen.

  • Jaja, das mit der echten Floppy soll so lala gehen, ist aber nicht besonders kompatibel. Aus dem Grund habe ich das erst gar nicht erst versucht.


    Warum ist das so? Der VICE muss doch nur das Handling des seriellen Busses hinbekommen. Alles andere läuft doch mit originaler Hard- und Firmware (CBM DOS) und muss nicht emuliert werden. Ich verstehe nicht die stiefmütterliche Behandlung dieser Option in VICE. Am Mangel an echten Floppy Drives für die Entwickler kann es ja nun wirklich nicht liegen.

    Dies war mein ein PoC als ein wirklich alltagstaugliches Instrument. Es ist einfach viel zu langsam und muss über virtuelle Device-Traps überhaupt erst ermöglicht werden. Alles andere als Original-IEC-Routinen des ROMs werden auch nicht funktionieren, weil man PC-seitig da nötige Timing für Fastloader o.ä. eh nicht hinbekommen wird.

  • Speedabweichung - das dürfte man konventionell mit Nibwrite/KryoFlux/Supercard Pro/FluxTeen und Option Board nicht direkt kopieren können? Oder doch - da "MakeSysDisk" den Kopierschutz mit einem normalen Commodore Laufwerk erzeugen kann?

    Jein, mit Nibwrite wird das nichts, aber SuperCard Pro sollte das hinbekommen. GreaseWeazle auch. Kryoflux weiß nicht genau - es hat eindeutug seine Stärken beim Einlesen, nicht beim wieder speichern auf Diskette.


    Nachtrag: Supercard Pro ist ja schön für Diskette kopieren auf Diskette. Aber Image auf Diskette, ja dann braucht es ein scp Image, welches genau für die Rotationsgeschwindigkeit der Zielfloppy gemacht worden ist... Bei GreaseWeazle habe ich durchaus schon ähnliche Ergebnisse beobachtet...

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

    Einmal editiert, zuletzt von markusC64 (23. Mai 2023 um 08:32)

  • Warum ist das so? Der VICE muss doch nur das Handling des seriellen Busses hinbekommen. Alles andere läuft doch mit originaler Hard- und Firmware (CBM DOS) und muss nicht emuliert werden.

    Weil VICE dafür eben deutlich mehr hinbekommen muss als nur das Handling des seriellen Bus, denn sobald ein Fastloader im Spiel ist läuft nicht mehr die originale Firmware. Ein emuliertes Floppylaufwerk läuft immer synchron mit dem emulierten C64, egal ob das PC-Betriebssystem dem Emulator gerade CPU-Zeit zuteilt oder nicht - der Emulator muss nur genug CPU-Zeit bekommen, um in 1/50 Sekunde Realzeit 1/50 Sekunde emulierte Systemzeit auszuführen. Um mit einem echten Laufwerk zu reden reicht das aber nicht, da das permanent weiterläuft auch wenn die emulierte CPU gerade nicht weiterläuft - um Laufwerk und emulierten C64 synchron zu halten müssten dürften die beiden nicht mehr als 1/1000000 Sekunde (eine Mikrosekunde) auseinanderlaufen. Das ist mit normalen Betriebssystemen wie Windows oder Linux auf normaler PC-Hardware nicht machbar.

    Ausserdem erfolgt die Anbindung des Laufwerks heutzutage üblicherweise über ein USB-Interface, aber USB basiert (vereinfacht dargestellt) auf Datenpaketen in einem 1000Hz-Raster, also um den Faktor 1000 zu langsam um präzise genug mit dem Laufwerk reden zu können. Zum Vergleich: Ein typischer C64-Fastloader schiebt ein komplettes Byte in unter 50 Mikrosekunden über den Bus.

    VICE verwendet daher einen anderen Ansatz: Es wird ein minimales IEC-Bus-Gerät am emulierten seriellen Bus des Computers emuliert und dessen Transaktionen werden zum echten Laufwerk durchgereicht. Das funktioniert aber natürlich nur mit dem Commodore-Protokoll und nicht mit Fastloadern, deswegen ist ist das deutlich weniger kompatibel als ein emuliertes Laufwerk.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Um mit einem echten Laufwerk zu reden reicht das aber nicht, da das permanent weiterläuft auch wenn die emulierte CPU gerade nicht weiterläuft - um Laufwerk und emulierten C64 synchron zu halten müssten dürften die beiden nicht mehr als 1/1000000 Sekunde (eine Mikrosekunde) auseinanderlaufen. Das ist mit normalen Betriebssystemen wie Windows oder Linux auf normaler PC-Hardware nicht machbar.

    Verstehe ich nicht ganz. Ein PC FDC muss tatsächlich das FDD auf der Low-Level (Flux) Ebene direkt ansprechen und den Track/Sektor Anfang finden. Eine 1541 ist doch aber ein "intelligentes" Subsystem mit eigener CPU und Command Queue, das Lese- und Schreibvorgänge autark durchführt und über eine API (CBM DOS) mit dem Computer kommuniziert. Da sollte doch etwas Asynchronität (wegen USB Tunneling) erlaubt sein? Sicher, die Schnellader machen die Situation schwieriger, aber "eine Mikrosekunde"?

  • Eine 1541 ist doch aber ein "intelligentes" Subsystem mit eigener CPU und Command Queue, das Lese- und Schreibvorgänge autark durchführt und über eine API (CBM DOS) mit dem Computer kommuniziert.

    Ja, aber genau die Kommunikation mit dem Computer ist das Problem: Die ist rein in Software definiert und kann dadurch mit einer Mikrosekunde Auflösung gestaltet werden. Es gibt Konstellationen mit echter Hardware, wo ein einzelner Taktzyklus Abweichung den Unterschied zwischen fehlerfreier und fehlerhafter Kommunikation macht, z.B. muss man für die Kombination von C64DTV und 1541 mit JiffyDOS den Kernal patchen, damit sich das Timing auf dem Bus um einen Taktzyklus verschiebt weil die CIA-Nachbildung im C64DTV ein minimal anderes Timing hat.

    Da sollte doch etwas Asynchronität (wegen USB Tunneling) erlaubt sein?

    Eine Simpel-Synchronisationsschleife in Fastloadern hat eine Ungenauigkeit von 7 Taktzyklen und danach werden Bitpaare typischerweise alle 10 Mikrosekunden auf den Bus gelegt. Es gibt auch Routinen mit besserer Synchronisation, die danach die Bits noch etwas schneller rausschieben können. Das lässt sich nicht einfach so über USB tunneln weil das um den Faktor 100 zu langsam reagiert.

    Sicher, die Schnellader machen die Situation schwieriger, aber "eine Mikrosekunde"?

    Wie willst du beliebige Fastloader behandeln, ohne das Bustiming mikrosekundengenau zu erfassen? Du kannst den Prozessor des extern angeschlossenen Laufwerks nicht beeinflussen, der führt stur das hochgeladene Programm aus, das aus Kopierschutzgründen mit beliebigen Sauereien gespickt sein könnte.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Hallo,

    ich hatte es ja angekündigt :wink: :

    Anbei ein D64, das die erste Beta-Version des Programms zum Ändern der Wheels128-(Geos)Seriennummer enthält. Es läuft nur unter Wheels 128 und ändert nichts auf der Boot-Disk. Die Seriennummer wird während des Bootens im Speicher des Rechners geändert.

    Bitte die beiliegende Anleitung beachten. Sie stammt zwar noch von einem anderen Programm, sollte aber das wichtigste erklären.

    Wenn mit dem Programm alles funktioniert, dann mache ich noch eine Version für Wheels 64 und natürlich eine "vernünftige" Anleitung :wink: .

    Gruß

    Werner

  • In der Zip oder im *.D64 habe ich sie nicht gefunden

    Augen auf im .... ! :bgdev

    Im D64 (auf der Disk) befinden sich 2 Dateien. Eins ist das Programm das andere ein GeoWrite-Dokument, das die Anleitung darstellt.

    Habe es extra nochmal probiert und das nochmal heruntergeladen. Ist alles da ......

    Gruß

    Werner

  • Im OP habe ich Wheels 128 4.2 Uninstalliert hinzugefügt.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

  • Das ROM ist jetzt im OP auch beigefügt. Es wird nur für die Erstinstallation von G64 und für MakeSysDisk von G64 benötigt und sollte anosnsten auch nicht verwendet werden.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

  • Man könnte natürlich die Seriennummer auch direkt im Kernel-File ändern, das birgt aber auch wieder Gefahren :wink: ....

    Da wir jetzt ein nicht installiertes Wheels 128 4.2 haben, habe ich das zwei Mal auf verschiedene Seriennummern installiert (Vor- und Nachname gleich) , nach D64 gewandelt und verglichen: Es sind genau 2 Bytes unterschiedlich, nämlich die Seriennummer im Kernalfile. Demzufolge muss das sicher sein., weil der Installer das auch so macht.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

  • Im D64 (auf der Disk) befinden sich 2 Dateien. Eins ist das Programm das andere ein GeoWrite-Dokument

    alles klar, hatte da nicht mit einem GEO-Write Doc gerechnet, sondern vielleicht mit einer Readme.txt oder PDF ....

    wäre off-topic, aber kann ich im VICE auch was ausdrucken? Dann könnte man am PC ja als Drucker "in PDF speichern" auswählen.

    oder anders herum:

    könnte jemand, der sich mit VICE sehr gut auskennt, seine VICE-Settings Datei hier hochladen und ich könnte sie dann bei mir einladen?

    In dem Falle wäre ich an einem VICE v 3.7.1 inkl. NL10 Drucker, SD2IEC und HD40 (mit JiffyDOS) auf Bitte melde dich an, um diesen Link zu sehen. und RAMLink sehr interessiert.

    Dann hätte ich meine Hardware fast zu 85% virtuell nachgebildet.

    wenn Du mich fragst:
    Run/Stop+Restore
    POKE781,96:SYS58251

    3 Mal editiert, zuletzt von Cpt.Hardy (26. Mai 2023 um 10:02)

  • vielleicht mit einer Readme.txt oder PDF ....

    Ich lach mich tot .....

    Es geht hier um Geos bzw. Wheels. Und da rechnet man mit Readme.txt oder gar PDF ????

    Eine Anleitung sollte in dem Format gespeichert sein, worin es darin geht. Und das ist Geos. Und das Programm dafür unter Geos: Geowrite.

    Kopfschüttel ....

    Werner

  • in GEO-Write kann ich erst ein Dokument öffnen, wenn das System läuft,

    Handbücher, die man damanls zu GEOS bekam konnte man auch lesen, ohne das das System schon installiert war.

    Ausserdem war es ja nur ein Vorschlag ...

  • nämlich die Seriennummer im Kernalfile. Demzufolge muss das sicher sein

    Das mag ja sein, ich bleibe trotzdem bei dem Weg, den ich eingeschlagen habe :wink: .

    "Wildes rumpfuschen" im Kernal mag ich nicht so und: Was ich da mache ist sozusagen "offiziell".

    In den Unterlagen zu Concept bzw. Concept+ (Nachfolger für GeoProgrammer v. M. Randall, ersterer läuft glaube ich sogar noch unter Geos) gibt es Definitionsdateien. In denen findet man auch die Adresse, wo die Seriennummer in Wheels steht. Sieht für mich danach aus, daß das für alle Wheels-Versionen gilt. Ist also wesentlich einfacher zu realisieren als die Stelle im Kernel-File zu finden und zu ändern.

    Wer das nicht mag, kann ja gerne ein Programm dafür erstellen. Ich zwinge ja niemanden auf meinen Weg ...

    Achso, die Adresse in Wheels-Speicher ist $9ff4/$9ff5.

    Gruß

    Werner