GDOS64

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

Zitat von toms01

ggf. wurden da Verbesserungen hinzugefügt.

Und genau darum geht es... Kein Original mehr.

Zitat von toms01

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.

Zitat von toms01

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:

Zitat von darkvision

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.

Zitat von toms01

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).

Zitat

In 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.

Zitat von wweicht

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...

Zitat von darkvision

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.

Zitat von uwe1972

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.

Zitat von uwe1972

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.

Zitat von uwe1972

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.