Posts by darkvision

Quote from C=Mac

Wie gesagt erst unter MP3 128 getestet.

In der Zwischenzeit neuste Version inkl. neustem TopDesk 128.

Im Source-Code mount.c findet sich dieser Hinweis:

Quote

- Tested using real hardware (C128D, C128DCR, Ultimate 64) using GEOS128 2.0, GEOS64 2.0 and Megapatch3 128.

Also scheint da schon MP3-Support enthalten zu sein.

Was ich so aus dem Quelltext herauslesen kann gibt es da keine UCI-Abfrage vorhanden/nicht vorhanden. Das würde erklären warum es ohne UII+/U64 zu verschiedenen Fehlern kommt.

Wenn UCI abgeschaltet ist, dann dürfte in GDOS64 z.B. die Ultimate nicht als RTC-Gerät angezeigt werden. Wenn das fehlt dann dürfte auch das Tool hier Probleme haben. Also UCI einschalten, in GDOS64 testen ob die Ultimate-Uhr auswählbar ist. Wenn ja dann dürfte auch das Tool funktionieren.

Ich müsste zum testen mal mein U64 oder die Ultimate raussuchen. Aber ich sehe da jetzt kein grundsätzliches Problem mit MP3/GDOS64, wenn schon der Entwickler mit MP3-128 testet...

Quote from Stephan Scheuer

Das Update waren ein Altera-CPLD und ein 128K-Eprom. Danach funktionierte die Rev.1B. Ohne das Update stürzte die SCPU ab, wenn Zugriffe auf das erweitrte RAM ab $020000 stattfanden.

Stimmt, da war was. Weil es unter GEOS damals Probleme gab mussten da was geändert werden. Das passt dazu weil das RAM der SuperCPU als GEOS-Speicher verwendet werden kann und ich meine das lief damals nicht. Musste damals die SCPU "zur Reparatur" einschicken.

In meiner 1B ist ein PLD V1.40-CPU1004 auf der SCPU-Platine verbaut. Ich meine der wurde damals ausgetauscht. Damit geht die RAMCard.

Quote from MalleB

Funktioniert bei der Rev.1B die RAM-Card?

Ich hab eine 1B die auf V2 geupdated wurde. Damals mit 1B ging die RAMCard, meine ich zumindest. Für V2 waren andere Probleme die Grundlage für das Update.

Quote from markusC64

Quote from darkvision

wäre schön wenn man den Source-Code dazu hätte...

Gibt es doch: https://github.com/xahmol/GeoUTools/tree/main/src

Leider nicht so, wie Du es vermutlich erhofft hast: Der Entwickler hat das in C geschrieben und cross compiliert.

Danke... das erklärt so einiges... da bin ich raus. Ich hab das Tool eben noch mit GEOS V2-US gestartet, da bleibt das Programm direkt nach dem Start hängen, ohne Menü-Oberfläche (auch wieder VICE ohne Ux).... vermutlich sollte man ohne Ux das Programm wirklich besser nicht anfassen...

Quote from wweicht

Wie gesagt, unter GDOS64 kommt hier genau wie Dein Bild, unter MP3-64 kommt bei mir das hier:

Es ist nicht das gleiche Bild... Bei mir wird Laufwerk B: als "§" abgezeigt... egal ob von B: oder C: gestartet. Und wen ich das Tool unter MP3 starte sieht das hier so aus:

Es wird gar kein Target angezeigt...

Das ist keine GEOS-Adresse gemäß Reference Guide... der Entwickler scheint sich nicht an die Vorgaben zu halten... wäre schön wenn man den Source-Code dazu hätte...

Für mich scheint das wirklich ein Problem mit der Ux-Hardware-Erkennung zu sein. Weil keine Hardware da ist werden verschiedene Werte gemeldet was dann zu unvorhersehbaren Ergebnissen führt.

M.M.n. muss man ohne Ux-Hardware die Software nicht testen...

Quote from wweicht

Ja, genauso sieht es bei mir mit 1541UII+ unter GDOS64 auch aus. Aber ich kann dann nichts mehr machen, kein Icon anklicken, nichts.

Doch.. bis auf "Home" kann ich alle Icons anklicken und bekomme auch ein Feedback (das Icon blinkt kurz auf). Ohne Ux wird auch der Inhalt im Fenster Aktualisiert (NoData).

Der Code scheint sich selbst zu verändern... Nach dem Start:

Nach Klick auf "Home":

Was dann bei $20b1 zu einem JAM führt...

Da wundert einen nichts mehr...

Quote from wweicht

PS: Unter GDOS64 (aktuelle Version) brauchst Du geoUMount nicht probieren. Nach dem Aufbau der Oberfläche funktioniert nichts mehr. Nichtmal das Directory des USB-Sticks ist korrekt zu sehen....

Bitte mal genauer beschreiben... starten tut das unter GDOS64, auch ohne Ux (unter VICE).

GDOS/current und GUM.d64 (nachdem ich es unnötigerweise auf ein D81 umkopiert habe...)

Ich müsste mal das U64 oder die UII+ aus dem "Keller" holen...

Quote from markusC64

..., damit man nicht vor dem riesen Crash steht...

Ultimate? YMMD!

Quote from wweicht

Wenn das UCI Interface nicht aktiviert ist oder wie ich in VICE (ohne UII+ ) probiert habe, stürzt das Programm immer!!! ab. Da scheint eine Erkennung der Ultimate/UII(+) zu fehlen. Das Prg geht einfach davon aus, daß die Hardware vorhanden ist.

Das deutet ja auf eine fehlende Erkennung der UCI-Schnittstelle hin... wie markusC64 geschrieben hat muss man nur 57117 testen. Das macht auch GDOS/geoCham64RTC. Freiwillige BugReporter vor!

Quote from markusC64

Hm, ja. Vielleicht. Nützt aber nichts, darkvision hat ja beschlossen, nur eien relativ alte Firmware zu unterstützen.

Das hat aber seine Gründe... wäre hier aber Off-Topic...

Aber um es klarzustellen: GDOS funktioniert auch auf neueren Firmware releases... wenn nicht, dann ist die Hardware (inkl. Firmware) schuld. Ich will nur keine BugReports zu Problemen mit neuerer Firmware die ich nicht testen kann (oder will).

Eine Ux-Hardware-Erkennung könnte ich daher dennoch integrieren... und bei fehlender UIC-Unterstützung beim booten warnen... Das ist aber eher eine Komfort-Funktion... ich brauch das nicht. 3rd-Party-Software müsste da eher einen "Fehler" melden... dann gäbe es diese Diskussion nicht.

Quote from markusC64

IF PEEK(57117) = 201 THEN PRINT "UCI DETECTED"

Das hilft doch schon mal weiter, Danke!

Quote from markusC64

a) Ein echter C64 ohne Ultimate II(+) hat jene Option ja gar nicht.

b) Hat die I/O Adresse einen I/O Konflikt mit einigen Freezer-Modulen.

Die Ux-Hardware wird ja bereits abgefragt, ist kein Ux verfügbar, dann kann man das überspringen. Das macht die RTC-Abfrage in GDOS bereits so.

Quote from markusC64

c) Müsste das doch GeosUMount abfragen, weiß aber nicht, ob es das wirklich macht. Und wenn es bei einem geht und bei einem anderen nicht, so ist so etwas die naheliegende Sache zum Prüfen.

Natürlich muss das die Software abfragen, das ist ein Bug in der Software. Aber ein Warnhinweis beim booten oder eine Option in Config die zur Sicherheit die Option abfragt und ggf. nicht startet damit der User nicht mit solchen Problemen konfrontiert wird schadet nicht.

Quote from markusC64

Hast Du denn in den Einstllungen der Ultimate das UCI Interface aktiviert?

Edit: Nennt sich "Command Interface" und ist in den "C64 Settings" zu finden.

Lässt sich die Option unter BASIC abfragen? Dann könnte ich den Start von GDOS/MP3 verweigern wenn der User das nicht aktiviert hat.

Es geht ja nicht um Backups, die sind ja vorhanden. Wenn man mit U1/U2 auch den Fehlerkanal ausließt weiß man ja ob beim lesen/schreiben ein Fehler aufgetreten ist -> Aussortieren und neue Disk hernehmen.

Quote from Krill

Es gibt einige Kopierprogramme, die mit einem Laufwerk die Quelldisk in 3 Schritten über das C-64-RAM auf die Zieldisk kopieren.

Das ist trotzdem aufwändiger als ein BASIC-Programm mit U1/U2 und liefert die gleichen Ergebnisse (ausser bei einem Nibbler, der aber nicht immer auch einen Kopierschutz schreiben kann... das würde ich also als Sonderfall ausschließen).

Quote from Krill

Nicht mit den Standard-Routinen in KERNAL und ROM.

??? OPEN/PRINT/CLOSE sind Standard-Routinen. Und U1/U2 sind Befehle von Diskettenlaufwerken...

Quote from goloMAK

Quote from darkvision

Damit ließt man die Daten im C64 ein und schreibt diese anschließend wieder auf Disk. Braucht ein zweites Laufwerk oder RAMDisk.

Nee, höchstens ne zweite Diskette.

Kommt auf das gleiche raus... alles zum C64 von Disk auslesen und vom C64 aus wieder auf Disk schreiben.

Wie gesagt... ich sehe dahinter keinen Sinn... es ist aus meiner Sicht eher kontraproduktiv. Wenn ich Backups habe würde ich bei einem Lesefehler eher die die aussortieren und eine neue erstellen. Das spart Zeit und für die Hardware evtl. schonender als hunderte Disketten 1x im Jahr zu "re-magnetisieren"...

Quote from goloMAK

Ich sehe nicht, wieso man dafür ein besonderes Programm braucht? Nimm doch einfach ein normales Disk-Copy.

Damit ließt man die Daten im C64 ein und schreibt diese anschließend wieder auf Disk. Braucht ein zweites Laufwerk oder RAMDisk.

Einfacher wäre ein kleines BASIC-Programm das über U1/U2 die Sektoren in das RAM der Floppy ließt und vor dort wieder auf Disk schreibt. Sollte deutlich schneller gehen, da nichts zum C64 übertragen werden muss.

Ich finde das aber auch wenig sinnvoll, da damit auch der Kopf und die Mechanik beansprucht wird. Evtl. gibt dann irgendwann das Laufwerk oder der Kopf den Geist auf während die Disketten dann evtl. noch in Ordnung sind

Ich hab mir auch noch die Routine für das LOAD-Token angeschaut. Die Routine springt nach dem laden und der READY-Meldung nach $A52A:

Evtl. ist es die Routine $A659 die nach dem LOAD einige Adressen initialisiert. Der Routine scheint bei ^name unter JiffyDOS nicht aufgerufen zu werden.

Interessant dürfte der Code ab hier sein:

Nach dem Laden wird also das BASIC-Programm neu "gelinkt" und anschließend die Routine für "RUN" aufgerufen. Also eigentlich nichts besonderes. Aber ich kann den Absturz des WiC64Radio-Loaders hier am C64+JiffyDOS ebenfalls nachvollziehen. LOAD-Befehl funktioniert, ^name nicht...

Bei $AAD7 findet sich noch das folgende:

Sollte eigentlich den CURSOR nur in eine neue Zeile setzen.

Wenn man den Loader mit LOAD"NAME",8 lädt und anschließend statt "RUN" ein SYS63442 (=$F7D2) ausführt, dann startet das Radio und funktioniert danach.

Nach dem sehr wichtigen Hinweis auf GD.RESET war mir klar wo ich suchen musste und hab den Fehler gefunden. Ist im neuen Snapshot behoben.

Bei GD.RESET wurde eine fehlende GD.INI nicht erkannt, damit war die Konfiguration ungültig. Das Absturzverhalten hängt aber stark davon ab wie der Inhalt des RAM und ggf. des DACC zum aktuellen Zeitpunkt war. Bei mir wurde z.B. am C64+TC64+GeoRAM die ersten drei Icons nicht angezeigt (alles schwarz, weiß war hier gar nichts), die Dialogbox (Standard in "cyan") "Bitte Disk einlegen..." ist der Hinweis auf fehlenden DeskTop. Ohne Konfiguration wurde dort auch kein DeskTop-Name eingetragen -> Leerzeichen. Unter Vice mit DACC in der RAMLink hat das ganze aber funktioniert, evtl. weil im DACC immer eine gültige Konfiguration vom letzten Bootvorgang vorliegt.

Der neue Snapshot erzeugt jetzt beim Start eine neue GD.INI falls keine gefunden wird. Ohne GD.INI wird aber nach wie vor nur das Boot-Laufwerk erkannt, die anderen Laufwerke muss man dann manuell einrichten. Damit man die aber nicht löschen muss um GDOS64 zurückzusetzen werde ich evtl. noch ein "RESET" in GD.CONFIG integrieren, wenn ich Zeit dazu habe.

Im letzten Snapshot hatte ich im GEOS/Uhrzeit-Modul die eingestellte Uhrzeit des RTC-Gerätes angezeigt wenn man auf "Aktualisieren" klickt. Jetzt wird auch noch das Datum mit angezeigt. Dann weiß man beim aktualisieren ob es auch geklappt hat. Die Zeit wird aber nicht laufend aktualisiert...

Quote from wweicht

Ich habe jetzt die erstellte Bootdsk von gestern (C128, SD2IEC, Lfw. 8, D81) genommen und vor dem Geos-Start die gd.ini in BASIC gelöscht. Wenn ich die starte, erhalte ich unten, wo die einzelnen Modul-Symbole angezeigt werden sollen einen weißen Balken und dann erscheint eine komplett weiße DB (mit weißem Schatten und weißer Schrift). Ich kann also nicht sehen, was da abgeht.

Zumindest unter VICE schon: Monitor aufrufen und

eintippen. Das ersetzt die Bildschirmfarben durch einen besseren Wert, dann sollte man was sehen.

Quote from wweicht

Ach so, ich starte immer mit "GD.RESET", ...

Es wäre schön wenn solche Infos schon vorher mitgeteilt würden bevor ich hier Stundenlang Installationstests mit falschen Voraussetzungen durchführe. Ich werde das mit GD.RESET mal testen...

Quote from wweicht

... weil manchmal andere Laufwerks-Konfigurationen oder RAM-Erweiterungen benutzt werden.

Das erlaubt nur die Auswahl einer neuen RAM-Erweiterung, die Laufwerke ändert das nicht. Ich hab mir GD und GD.RESET eben angeschaut. GD.RESET setzt vor dem Start von GD.BOOT nur den RAM-Typ auf $ff = Neu wählen. Das ist das 4.Byte nach den beiden BASIC-Headerbytes und dem Sprungbefehl in GD.BOOT. Mehr ändert GD.RESET nicht.

Das mit GD.RESET kann aber einen Unterschied machen, evtl. gibt es einen Fehler wenn DACC=$ff ist und keine GD.INI gefunden wurde. Wenn man GD verwendet (nicht GD.RESET) und keine GD.INI hat, dann ist der Wert DACC=$00 (nicht gewählt). Das wäre dann aber schon länger so, nicht erst seit diesem Update.

Were ich mal testen...

Quote from wweicht

Ist so eigentlich doppelt gemoppelt .

Und ist in dem Fall sogar kontraproduktiv, weil ohne geoCham64RTC+ wären die Uhrzeit-Fehler evtl. früher aufgefallen. Hier verlängert es nur unnötig die Startzeit.

Hier noch ein allgemeiner Tipp zur Installation:

Wer zuerst auf eine RAMDisk installiert und anschließend die Dateien auf die Bootdiskette kopiert, der verliert den Vorteil der GD.INI, das nach einem Update alle Einstellungen in GD.CONFIG erhalten bleiben. Wird beim Update keine GD.INI vorgefunden, dann wird eine mit den Standardeinstellungen erzeugt. Kopiert man dann alles auf die Bootdiskette, dann überschreibt man die bisheriger Konfiguration (z.B. RTC-Gerät, Spooler/TaskManager/Hilfe ein oder aus, GeoDesk-Einstellungen...)

Ich hab am C64 eben die GD.INI meiner Bootdisk auf eine leere RAMDisk kopiert und dann das Update auf der RAMDisk installiert. Dabei bleiben dann die GD.CONFIG-Einstellungen erhalten. Anschließend hab ich alle Dateien (inkl.GD.INI) einfach auf die Bootdiskette im SD2IEC verschoben und danach direkt neu gestartet (Vorher über TC64-Menü den gesamten Speicher inkl. REU gelöscht). Ging hier dann auch problemlos, das zuvor auf ein anderes Laufwerk installiert wurde spielt keine Rolle, die Reihenfolge der Laufwerke bleibt ja gleich...

Allerdings spart das dann kaum Zeit, weil das Installieren auf RAMDisk und Kopieren auf Bootdisk mehr Zeit kostet als die direkte Installation auf die Bootdiskette. Direkt auf die Bootdisk installieren spart einem dann auch das kopieren der GD.INI auf das Zwischenlaufwerk/RAMDisk.

Empfehlenswert ist lediglich die SETUP-Datei auf eine RAMDiskette zu kopieren, damit das analysieren der SETUP-Datei und das einlesen der Installationsdateien beim kopieren schneller geht.

Das vorgehen mit der RAMDisk als Zwischenlaufwerk war bei MP3 noch sinnvoller, da hier sowieso immer alle Einstellungen zurückgesetzt wurden.

Wenn ich mit DESKTOP2 fertig bin hab ich wieder mehr Zeit für GDOS64, evtl. überlege ich mir eine Option "Konfiguration von anderem Laufwerk einlesen"... das könnte dann eine GD.INI während der Installation von einem anderen Laufwerk übernehmen. Das manuelle kopieren (s.o.) geht aber auch schon jetzt und man muss nicht alle Einstellungen in GDOS64/GeoDesk neu einrichten.

Eine Option wäre auch beim fehlen einer GD.INI den Autostart von AutoExec-Dateien zu unterbinden, die evtl. auch nicht mehr vorhandene Laufwerke zugreifen wollen. Dann würde ein löschen einer GD.INI den Neustart erlauben bis man GDOS64 wieder komplett eingerichtet hat.