2.6K (F8)
Eben die v3.7 getestet... damit geht es auch. Also mal husch husch die Firmware updaten 
Posts by darkvision
-
-
Scheint dann kein Problem mit dem Befehl GET_TIME zu sein, sondern eher generelle art.
markusC64 Ich verwende den Code zum erkennen der U2+, ist das bei der U2 anders?
-
Für die U2 ohne + gibt es aber auch die V3.6... evtl. Ist das ja das Problem.
-
Ich habe ultimateRTC nicht programmiert, sondern nur via git clone geholt und dann compiliert.
Hat auch keiner behauptet, aber der Code weicht auch an anderen Stellen von dem von mir bzw von tokra importierten Code ab. Dein importierter Code ist deutlich älter als meiner, evtl. hat sich die Firmware seither verändert. Abgesehen davon ist das Compiler-Code, ich hab den Assembler-Code von Tokra importiert. Wer weiß was der Compiler draus macht. Daher verstehe ich durchaus auch Deine geoDebugger-Anfrage und würde mich freuen wenn da jemand helfen könnte.
-
-
In eigener Sache:
Auf Grund von Tests mit der aktuellen Firmware für die U2+ und geoCham64RTC hab ich die BootDisk von MP64V37 von meinem Hauptsystem (MK2+TC64v2 mit SD2IEC+CMD-Laufwerken) auf mein "Testsystem" übertragen (MK2+Ultimate2+ mit SD2IEC). Gleiches Boot-Laufwerk 8:
Startet direkt von Disk
Man kann also die Startdisketten (fast) problemlos zwischen Systemen mit den beiden Erweiterungen austauschen, sofern das Boot-Laufwerk das gleiche ist.
Der GEOS.Editor meckert ggf. beim Start wegen fehlenden (physikalischen) Laufwerken, aber das ist Einstellungssache. Die verwendete RAM-Erweiterung spielt keine Rolle, es sein denn die Größe ist kleiner, dann werden ggf. nicht alle RAM-Laufwerke installiert.
Bei U2+ sollte man aber die Kombination REU+GeoRAM vermeiden, da beide den gleichen Speicher verwenden. Das TC64v2 hat damit kein Problem, kann aber nur 4Mb GeoRAM verwenden.
-
Nicht komplett heute, aber die letzten Tage und zumindest heute den letzten Feinschliff verpasst...
Tool zum automatischen erstellen von Partitionen auf der CMD-HD bzw. angeschlossenen SCSI-Geräten. BASIC V2 mit ein paar Assembler-AddOns für interne Funktionen der CMD-HD.
-
Probier mal meine eigene Programmierung von Ende 2017:
tokra Danke für Deinen Code! Den hab ich (unter Namensnennung) in mein Tool integriert, das die Uhrzeit für U2+ und das TC64v2 unter GEOS setzt, also ein Tool für beide Erweiterungen. Wenn das ein Problem sein sollte dann einfach sagen.
Mit dem Code hab ich das eben für die V3.6 Firmware getestet und funktioniert nach wie vor. frank128 sollte am besten mal den gesamten Code posten, evtl. findet man dann den Fehler.
-
Aber danke für den Feedback, dass es bei Dir noch geht.
Es geht mit der v3.3... was neueres hab ich nicht getestet. Das U2+ wird hier eher selten genutzt. Hab aber eben nochmal GEOS gestartet, die Uhrzeit steht noch auf Winterzeit, aber es geht
P.S. Ich sehe das es eine V3.6 gibt. Eben aktualisiert und getestet. Geht auch mit der v3.6
-
Offenbar versteht die 1541U2 das Kommando DOS_CMD_GET_TIME nicht (mehr)
Es gab da ein RTC-Demo von
Torsten Kracke.Das hab ich in mein Tool integriert. kannst Du hier nachlesen. Funktioniert hier noch.Kann es sein das Du die drei Werte immer in das gleiche Register schreibst? Das Letzte byte ist das ControlRegister $df1c und nicht das DatenRegister $df1d.
-
Ich kann zu dem eigentlichen Problem nichts beitragen... aber es gibt geoCham64RTC. Wurde zwar für das TC64/GEOS64 entwickelt, müsste aber auch unter GEOS128 und UltimateII(+) laufen. Zumindest hab ich keine anderweitigen Bug-Reports erhalten...
-
Ich muss einfach nochmal (immer mal wieder), ein "Großes Dankeschön" aussprechen, mit der Du uns User, an Deiner "Arbeit" teilhaben lässt.
nu is aber gut
Mit welcher "Liebe zum Detail" und mit welchem "Fachwissen", Du, diese Programme aus dem Boden stampfst, stellt für mich als reinen Anwender, eine unglaubliche Leistung da.
Fachwissen... nuja... der SCSI-Kram hab ich ja größtenteils über Reverse-Engineering von anderen Programme, z.B. ScsiConnect oder llformat, gelernt. Und natürlich mit Hilfe des SCSI Reference Manuals von Seagate...
Trotzdem gibt es noch ein paar Punkte wo ich gestern fast verzweifelt bin:
In der ersten Entwickler-Version von hdPartInit ging das erstellen von Partitionen sehr viel schneller als in der ersten Testversion. Nach dem erstellen von 79 Partitionen auf dem ZIP zeigt ein "@$=P" aber nicht alle Partitionen an, seltsamerweise fehlten die letzten 3. Ich konnte aber in die Partitionen mit "@CPn" wechseln. Die waren also da... und formatiert.
Setzt man die CMD-HD zurück und aktiviert das ZIP wieder, dann wurden die Partitionen auch angezeigt.
Jetzt aktualisiere ich die Partitionstabelle nach jeder neu erstellten Partition. Dadurch dauert das deutlich länger, aber es werden zum Schluss alle Partitionen angezeigt.
Warum das so ist
Und "aus dem Boden stampfen" tu ich nichts, hdPartInit ist ja nur ein Abfallprodukt von cbmHDscsi64... selbst die Idee dazu ist ja recycled (von RL-INIT). Sind ja auch nur 1000 Zeilen an BASIC-Code... quasi nichts im Vergleich zu MegaPatch
-
Wenn geoscsicopy/cbmscsicopy jetzt noch mehrere Partitionen in einem Stück kopieren könnte (Ein- oder Mehrfachauswahl, bestenfalls kompletter Inhalt), auf ein Medium mit gleicher Partitionstabelle, wäre das echt "Traumhaft".
Ich denke das lohnt den Aufwand kaum, wie oft kopiert man denn immer *alle* Partitionen?
Ich hab aber eben die von Dir gemeldeten Fehler in geoSCSIcopy64 behoben und eine "SYNC"-Option eingebaut. Damit wird bei der Auswahl einer Quell-Partition auf dem Ziel-Laufwerk eine Partition mit gleicher Nummer gesucht und ggf. gleich aktiviert.
Damit wählt man jetzt nur noch die Quell-Partition und klickt auf "StartCopy".
Damit hab ich eben auch hdPartInit getestet. Davon wird es aber keine GEOS-Version geben, so oft muss man das ja nicht einsetzen und bei Bedarf kann man es ja vom GEOS-DeskTop aus starten.
Ich schick Dir später noch die aktuellen Versionen von beiden Programmen. Ich denke damit kann man schon recht einfach Partitionen von der HD auf externe Laufwerke sichern bzw. Partitionen für die Sicherung automatisch erstellen.
-
Routest Du die Verbindungen zwischen den Komponenten bei jedem Layout wieder neu oder ist das automatisiert? Sind ja doch ein "paar" Leiterbahnen
Gefällt mir jedenfalls
-
Als Ergänzung zu geoSCSIcopy64 hab ich aus den Code-Schnippseln von cbmHDscsi64 ein weiteres BASIC Programm erstellt: hdPartInit.
hdPartInit ist angelehnt an mein Tool RL-Init, ein Programm zum automatischen erstellen von Partitionen auf der CMD-RAMlink, z-B. nach einen Systemausfall.
Bei der CMD-HD geht es weniger um einen Ausfall des Systemlaufwerks, als vielmehr um das automatische erstellen von Partitionen an Hand einer Konfigurationsdatei, z.B. um mit cbmSCSIcopy64/geoSCSIcopy64 Partitionen vom Systemlaufwerk auf ein Backup-Laufwerk an der CMD-HD zu kopieren.
Damit muss man die Backup-Partitionen nicht mehr manuell erstellen, sondern kann an Hand eines vorhandenen Laufwerks auf einem weiteren Laufwerk eine Kopie der Partitionstabelle erstellen. Die Tabelle kann auch in einer Konfigurationsdatei gespeichert werden, falls man mehrere Backup-Medien erstellen will.
Das Programm funktioniert bereits, knapp 80 Partitionen werden auf einem ZIP-Laufwerk in wenigen Minuten automatisch erstellt und formatiert.
HINWEIS: Das Programm kopiert nicht den Inhalt der Partitionen, es hilft nur beim erstellen von mehreren Partitionen auf einem Backup-Laufwerk!
Beim speichern der Partitionen auf dem Ziel-Laufwerk wird immer der gesamte Inhalt gelöscht. Das ist das gleiche wie bei RL-Init. Um einzelne Partitionen zu erstellen sollte man cbmHDscsi64 verwenden!!!
Wie funktionierts?
- Programm starten
- mit F1/F3/F5 das Quell-Laufwerk auswählen
- 'I' für "Partitionen importieren" auswählen
- mit F5 das Ziel-Laufwerk wählen
- Optional: 'V' um die Partitionen zu überprüfen
- 'W' um die Partitionstabelle auf dem Ziel-Laufwerk zu erstellen
- Optional: 'S' um die Partitionstabelle als Datei zu speichern
Auf dem Ziel-Laufwerk hat man jetzt die gleichen Partitionen wie auf dem Quell-Laufwerk. Ausnahme: Es steht nicht genügend Speicher zur Verfügung: In dem Fall werden nicht alle Partitionen erstellt.
Ein bisschen an Fein-tuning fehlt noch... hier ein erster ScreenShot
-
Wie gesagt, wenn es eine PS/2 Maus mit 1000dpi war (hab nach einer kurzen Recherche keine mit höheren DPI Werten gefunden), dann dürfte Dir 800 auch noch zu schnell sein und 400/500 wäre wohl das richtige.
Das eine zu Hohe DPI Zahl den Adapter zerschießt kann ich mir nicht vorstellen... ich denke der Adapter bekommt dann nur mehr Werte geliefert und der C64 interpretiert das dann als eine größere Bewegung. Aber genaueres kann ich nicht dazu sagen.
Ich hab am C64 auch schon mit den 3200dpi experimentiert, bisher ohne Probleme und der erste Adapter funktioniert noch
. -
Meinen USB-Maus-Adapter hatt es mir vor einiger Zeit "Zerschossen", darum bin ich auf PS/2 Umgestiegen...
Was war das denn für eine PS/2-Maus bzw. mit wieviel DPI?
Wenn es 1000dpi waren dürften die 800 nicht viel langsamer sein. Wenn Dir das zu schnell war, dann bräuchtest Du was mit 400.
Die Logitech S96 oder ähnlich alte hatten wohl 400dpi, dürfte es aber nur noch gebraucht geben.
-
Deswegen frage ich ja Wiesel aka "Jens" von IComp.
Schon klar
Aber danke fürs prüfen, jetzt liegt es zumindest nahe, dass meine Hardware nicht außergewöhnlich spinnt.
Ich hab noch weiter getestet... nachdem ich die Bugs im Wiki zu JiffyDOS/IEC gelesen hab. Ich hab deshalb mal mein Mini-IEC-Kabel für das TC64 rausgesucht und die Laufwerke direkt an das TC64 angschlossen... da läuft alles mit JiffyDOS nur im C64.
Es läuft aber auch alles wenn ich die Laufwerke am C64-Bus hängen hab und ein extra SD2IEC an das TC64 über das Mini-IEC-Kabel anhänge. Dann also 8:SD2IECextern, 9:Internal1541, 10:SD2IECamTC64, 11:SD2IECextern, 16:CMDHDextern. BootFromSD ON oder OFF spielt keine Rolle. JiffyDOS im internen Laufwerk macht auch keinen Unterschied.
Der TC64-IEC-Bus scheint sich etwas anders zu verhalten als der externe des C64, scheint aber auch den externen IEC-Bus zu beeinflussen. Da gab es ja einen Bug in Bezug auf C64+Jiffy+Timing und echten Laufwerken. Keine Ahnung ob das ein ähnliches Problem ist.
Evtl. verhält sich das SD2IEC hier etwas anders, denn wenn ich am SD2IEC das Problem mit dem "FILE NOT FOUND" habe kann ich die Datei von der CMD-HD laden. Zumindest hier betrifft das Problem also nur meine SD2IEC-Laufwerke. Und auch nur wenn die am C64-Bus hängen. Und auch nur wenn ich kein JiffyDOS in der internen 1541 installiert hab. Und nur wenn kein zusätzliches Laufwerk am TC64 über das MiniIEC-Kabel angeschlossen ist.
Mehr kann ich zum "Fehler" nicht beisteuern...
-
Ob es hilft, weiss ich nicht
Hilft... bei Verwendung eines JoySticks unter GEOS2/MP3, nicht aber beim 1351/SuperMouse-Treiber. Der verwendet diese Register (minMouseSpeed, maxMouseSpeed, mouseAccel) nicht.
Den Original-Code vom 1351-Treiber hab ich nicht da, in meinem GEOS-Disassembler-Code findet sich aber ein Maustreiber, der ebenfalls (wie der SuperMouse-Treiber) nicht auf die Werte reagiert.
Eben mal GEOS 2.0 in VICE mit 1351-Treiber gestartet... da finde ich keinen Zugriff auf die Maus-Register.
Unter GEOS 2.0 gibt es auch das Programm "Voreinstellung", da kann man die Werte auch ändern. Hilft bei der 1351 oder dem SuperMouse-Treiber aber nichts...
Ich fürchte da bleibt es bei einer Maus mit weniger DPI. Ich hatte ja mal die echte 1351 mit dem Tom+Rev2-Adapter mit PC-Maus verglichen. Der DPI-Wert liegt gefühlt irgendwo zwischen 400 und evtl 600dpi, wenn ich die Geschwindigkeit beider Geräte vergleiche.
Für den MicroMys-Adapter hab ich mir extra noch eine PS/2-Maus mit 800dpi geholt. Gaming-Mäuse mit DPI-Umschalter hab ich für PS/2 nicht gefunden und weniger als 800DPI auch nicht.
-
Verwende ich aber eine interne emulierte 1541 ( No 8 ) und ein externes SD2IEC ( No 9 ), so gehen die Probleme los:
Speedloader gehen nicht mehr, mit Jiffydos gibt es vom SD2IEC laifend "File not Found error", obwohl die Dateien vorhanden sind.
So... jetzt nur ein SD2IEC und ein internes Laufwerk... und ich kann den Fehler ebenfalls reproduzieren. An einem C64 MK2 mit TC64v2.
Beim laden von Dateien erhalte ich einen FILE NOT FOUND und die Laufwerks-LED des SD2IEC leuchtet weiter... ein @I setzt das Laufwerk und die LED dann zurück.
Bei mir tritt das Problem aber immer auf wenn JiffyDOS im C64 im Spiel ist, unabhängig vom BootFromSD an oder aus.
Es macht aber einen Unterschied ob Jiffy im internen 1541 aktiv ist oder nicht:
Ohne Jiffy: File not found
Mit Jiffy: Keine Probleme
Ich kann das jetzt auch mit der gestrigen Konfiguration reproduzieren, also 8:SD2IEC, 11:SD2IEC, 16:CMDHD und intern9:1541.
Nur C64-Jiffy: File not found
Mit C64+1541-Jiffy: Funktioniert.
Keine Ahnung warum das Gestern funktioniert hat... hatte ja extra mit und ohne Laufwerks-ROM getestet.
Ich hab jetzt "Boot from SD" auf "ON" gesetzt und in CHAM64/ ein KERNAL.ROM und DRIVE1.ROM abgelegt. Damit funktioniert es auch.
Lösche ich DRIVE1.ROM aus dem CHAM64/ Verzeichnis dann bekomme ich wieder die FILE NOT FOUND-Error.
Wechsle ich nach einem Fehler in das TC64-Menü und lade das Drive-ROM von Hand und kehre ohne RESET zum C64 zurück und wiederhole den gleichen LOAD-Befehl, dann wird die Datei geladen.
Aber selbst mit JiffyDOS im internen Laufwerk funktioniert ein SD2IEC im internen FileBrowser nicht immer richtig, sobald JiffyDOS im C64 aktiv ist. Mal geht es, mal werden nur ein paar Dateien eingelesen.
markusC64 Hattest Du das in der Kombination auch schon getestet? Also Jiffy im C64+Laufwerk?
Ich hab auch mal eine echte 1541 ohne JiffyDOS angehängt, geht.
