Nachtrag: Fehler mit FD81 gefunden... wird im nächsten Update behoben (liegt an der Partition die beim Update aktuell nicht erkannt wird).

Hello, Guest the thread was viewed41k times and contains 348 replies
last post from Juergen Johannes at the
GDOS64
- darkvision
- Thread is marked as Resolved.
-
-
Repliken sind ja keine Neuentwicklungen, ggf. wurden da Verbesserungen hinzugefügt.
Sofern in den größer angelegten Tests keine Abweichungen mehr auftreten, sollten diese sich exakt wie Originale verhalten.
Klar, Kinderkrankheiten gibt es manchmal, aber da sollte dann sowieso nicht auf Softwareseite reagiert werden.
-
ggf. wurden da Verbesserungen hinzugefügt.
Und genau darum geht es... Kein Original mehr.
-
Zum Glück - ist einfach besser.
-
Zum Glück - ist einfach besser.
Ist das jetzt Werbung für Deine Produkte? -> OffTopic.
Hier geht es darum das ich in meinen Produkten keine Fehler beheben kann wenn ich die nicht selbst reproduzieren kann. Und wenn beim Einsatz von nicht originaler Hardware Fehler auftreten ist das mindeste was ich erwarte das man das mit originaler Hardware verifiziert bevor man einen Fehler meldet. Wenn ich die (veränderte) Hardware nicht selbst besitze ist das eben "nicht unterstütze Hardware"... Egal wie "Geil" die sein mag...
wweicht hat hier einen Fehler gemeldet, den konnte ich unter VICE nachstellen... eine SCPU128 z.B. gibt es unter VICE nicht... daher könnte ich Probleme nicht mal im Ansatz nachstellen -> Nicht unterstützt, wie Ultimate+TurboFirmware. Ende der Diskussion.
-
Nein, überhaupt nicht - oder kannst du sie irgendwo kaufen?
Mir geht es darum Behauptungen stehen zu lassen, dass bei Repliken mit anderem Verhalten gerechnet werden muss. Das ist nicht richtig, schon gar nicht bei identischer Bestückung.
Dann wäre was kaputt oder ausser Toleranz.
Und darum hatte ich den Fall bei Verbesserungen angesprochen, da KANN (aber muss nicht) was passieren - sollte sich dann aber mit ANSCHLIESSENDEN Test hardwareseitig beheben lassen.
-
Mir geht es darum Behauptungen stehen zu lassen, dass bei Repliken mit anderem Verhalten gerechnet werden muss. Das ist nicht richtig,
Hab ich auch nicht behauptet... im Gegenteil:
Gleiches gilt für Replikas: Dürften funktionieren, aber bei Problemen muss das Fehlverhalten an unterstützter Hardware nachgestellt werden bevor ich da tätig werde.
-
Ich verstehe nunmal deine Erwähnung mit vielleicht auftretenden Problemen mit irgendwelchen Repliken gesamt nicht. Insbesondere nicht, da JJ wohl zufälligerweise einen Test deiner Software auf meinen Repliken erfolgreich gemeldet hat. Dabei hat er mich getaggt und deshalb bin ich auch nur in diesem Thread in Erscheinung getreten, ich verwende GDOS64 überhaupt nicht.
Ist dann wohl für alle Beteiligten besser man testet die Software nur auf Originalhardware und alle anderen melden Abweichungen dann nur an den entsprechenen "Repliken-Ersteller".
Wenn das Prozedere ein Problem darstellt, dann können wir das gern ggf. noch per PN klären. Ich werde jetzt ruhig sein.
-
Ich verstehe nunmal deine Erwähnung mit vielleicht auftretenden Problemen mit irgendwelchen Repliken gesamt nicht.
Es ging nicht explizit um Repliken, sondern generell um nicht vorhandene Hardware. Ich kann nicht alle möglichen Hardware-Versionen vorhalten (wenn man die denn kaufen könnte).
QuoteIn MegaPatch und GDOS64 wird bis auf wenige Ausnahmen nur Hardware unterstützt die ich selbst besitze und für Tests heranziehen kann.
Die HD-Replika hab ich selbst getestet... da würde ich ein "OK" dahintersetzen... Beim Ultimate (als Gegenbeispiel) kommt regelmäßig eine neue Firmware raus. Wie beim WiC64 ändert das die Eigenschaften der Hardware. Sorry, das kann ich bei einem Hobby nicht leisten.
In zwei Jahren baut jemand Deine SCPU128 nach, nimmt andere Chips oder ändert das Layout... und dann soll ich den Fehler suchen wenn meine Software nicht läuft? Nein, kein Original... kein Support. Ganz einfach. Alles andere wird zu kompliziert.
Es geht hier nur darum das ich bei meinen Produkten nur Fehler beheben kann wenn die eindeutig sind oder wenn ich den Fehler mit eigener Hardware oder im Emulator nachstellen kann. Beim FD81-Problem hab ich die FD2/4 hier... hätte ich auch am C64 testen können.
-
Ist es gewollt, daß Installation auf FD1581 nicht mehr möglich ist?
um mal wieder OnTopic zu werden:
Den Fehler konnte ich hier nachstellen, Fehler erkannt (auch wenn Ursache noch weitere Tests erfordert) und auch behoben. Hab GDOS eben neu assembliert und die Installation auf FD81 hat funktioniert, ist im nächsten Update behoben.
Hatte zwischendurch zwar die Installation auf CMD-RL gestestet (was wohl ein Teil des eigentlichen Problems sein könnte) aber die FD (auch mit einer 1581-Disk) stand auf der ToDo-Liste...
-
Den Fehler konnte ich hier nachstellen, Fehler erkannt (auch wenn Ursache noch weitere Tests erfordert) und auch behoben.
Tests abgeschlossen... nur bei der RAMLink ist es erforderlich während des Updates die aktive Partition zu ermitteln. Bei der FD ist das nicht notwendig da die aktive Partition beim Update ja nicht gewechselt wird. Bei der RAMLink kann man ja mehrere Laufwerke mit verschiedenen Partitionen einrichten, bei einer HD/FD geht das nicht.
Daher fehlte der Test auf Partition=0 (nicht initialisiert) was bei der FD zu einem Fehler 49 = $31 = Syntax Error führt. Das scheint grundsätzlich ein Problem in MegaPatch/GDOS zu sein. Muss ich weiter untersuchen... ist aber für das nächste Update kein Problem... ist eher ein "Will-wissen-warum"-Problem...
P.S. Und ist auch jetzt behoben... Die Laufwerkstreiber testen zwar auf Partition >Max, aber nicht auf Partition=0. Ist ein Kandidat für einen BackPort auf MegaPatch 3.3r10... mal sehn.
-
Nur ganz nebenbei, ich habe das selbe Problem.
Auch ich Installiere GDos auf CMD FD...........(Native Modus)
Aber trotz Fehlermeldung kann man GDos Hinterher Booten...................
-
Nur ganz nebenbei, ich habe das selbe Problem.
Auch ich Installiere GDos auf CMD FD...........(Native Modus)
Aber trotz Fehlermeldung kann man GDos Hinterher Booten...................
Ist evtl. etwas untergegangen, aber Problem ist lokal bereits behoben. Weil das aber auch die CMDHD betreffen dürfte will ich das heute erst nochmal ausgiebig testen. Das Problem ist auch nur das Update. Installiert man auf RAM81 und kopiert die Dateien hinterher nur auf die FD und speichert die Konfiguration über GD.CONFIG (ohne Update) dann sollte das auch funktionieren.
-
Hab das nur erwähnt um zu zeigen, das Werner nicht der einzige ist, bei dem das so ist..............
Die Idee im Ram zu Installieren Ist im Übrigen garnichtso schlecht, geht Superschnell !!!
Vieeeeeeel schneller als auf FD zu installieren...........
-
Fehler mit FD81 gefunden... wird im nächsten Update behoben
Danke.
Im neuen Snapshot (02.08.22) ist das Problem behoben.
Gruß
Werner
-
GD Update 02.08.2022:
Obwohl ich nichs an der Konfiguration geändert habe,
Bekomme ich diese Fehlermeldung (Hier unter Vice)
Installiation läuft durch. dann kommt die Fehlermeldung
A,C 1581
B-Ram
C1541
GD weigert sich zu Booten
-
Installiation läuft durch. dann kommt die Fehlermeldung
Da hast Du aber schon etwas konfiguriert, denn da steht Init... **RAM**.
D.h. das System lädt beim Start die Laufwerkstreiber ins RAM. Kann es sein das Du von einem System startest, aber vergessen hast den Treiber für das Startlaufwerk beim laden ins RAM mit aufzunehmen?
Wenn Du z.B. von FD bootest, dann ist das Laufwerk in der Standardeinstellung nicht ausgewählt... nur C=-Laufwerk und RAM-Laufwerke.
Von der Boot-Diskette einfach mal die GD.INI löschen... und neu starten.
-
Installiation läuft durch. dann kommt die Fehlermeldung
Während ich jetzt für den Fall das der Starttreiber bei "Disktreiber-in-RAM" nicht geladen wurde einen Workaround eingebaut habe (wird dann versucht von Disk zu laden), gibt es noch einen zweiten Fall wo obiger Fehler auftreten kann:
GDOS sucht beim Start die Laufwerkstreiber die für eine Installation verwendet werden können. Um bei NativeMode-Verzeichnissen oder bei reduzierten Systemdisketten mit weniger Laufwerkstreibern aber die Suche nicht unendlich in die Länge zu ziehen, prüft GDOS nur die ersten 128 Dateien auf Laufwerkstreiber.
D.h. bei einer Bootdiskette sollten die Systemdateien (oder zumindest die Laufwerkstreiber) innerhalb der ersten 128 Dateien auf Diskette sein. Ist das der Fall und obiger Fehler tritt auf dürfte es an der Einstellung "Disktreiber-in-RAM" liegen.
Die Einstellung ob das aktiv ist oder nicht wird auch in der GD.INI gespeichert. Die wird auch bei einem Update ausgelesen und ggf. übernommen. Daher kann der Fehler auch bei einem Update auftreten.
Wer die Option verwendet sollte vor dem Update sicherstellen, das der Treiber auch mit ins RAM geladen wird (siehe GD.CONFIG, Registermenü "Treiber". Mit dem nächsten Update startet GDOS dann trotzdem, ich werde mir aber eine Fehlermeldung überlegen da hier das System falsch konfiguriert ist.
-
Hallo Darkvision,
Danke für deine Mühe, hab die GD.INI gelöscht nun Bootet GD Normal..............
-Sind Übrigens insgesamt nur 92 Dateien auf der Bootdisk.
-An der Konfiguration hatte ich nichts geändert,
die ist schon lange so unter Vice.
-Ist aber durchaus mgl, das ich mal die Systemdateien von einer anderen Disk auf die Vice-Bootdiskette kopiert hatte............
-Am O-C64 selbst, hatte ich keinerlei Probleme, mit dem Update, da lief das Update ohne Probleme durch und GD hat auch Hinterher gebootet.
Aber nun funktioniert wieder alles, wie es soll, Danke
-
Einen schönen Sonntag allerseits.
PC WinVice........
Habe bis eben ein Problem nicht in den Griff bekommen und es per WinVice aufgezeichnet.
Heute nachmittag habe ich GDos (02.08.22) von LW10, mit WIN Vice (xscpu64 r41576), jeweils eine Partition auf eine CMD RL1581 (LW09) und auf eine CMD HD1581 (LW08) installiert.
LW08 CMD HD 1581er Part (Startpartitin 2)
LW09 CMD RL 1581er Part (Startpartition1)
LW10 1581
LW11 1541
Probleme macht GeoDos (letzte Version) in der Partitionsauswahl auf der CMD RL(bei der CMD HD scheint es zu funktionieren) bei Start mit GDos.
Ich benutze Geodos unter anderem, um meine CMD Hauptverzeichnisse umzubenennen.
Dieses Problem tritt bei Start mit MP3 64 (letzte Version) nicht auf. Gerade eben nochmal probiert (Topdesk+Geodesk).
(Habe gerade gesehen GDos kann auch bald CMD Hauptverzeichnisse umbenennen
)
Liebe Grüße,
Jojo