Hi,

ich habe soeben einen Bug im

SECTORCOPY 1.5 (C) 07/88 BIBOSOFT

gefunden.

Dieser äußert sich wie folgt:

Eine hiermit erstellte Kopie enthält in Byte 0 von Sektor 1 eine $80 statt einer $00, wenn das Original dort eine $00 stehen hat.

Die Kopie einer mit MyDOS formatierten Disk scheint korrekt, denn das 'M von MyDOS in Byte 0 von Sektor 1 bleibt erhalten. Ich gehe derzeit davon aus, daß auch das 'S von SpartaDOS erhalten bleibt, habs aber nicht getestet.

Ob das Verhalten nun Absicht ist oder auf einem versehentlichen Fehler beruht weiß ich nicht.

Für die normale Verwendung auf dem Atari mag der Fehler belanglos sein. Für die Archivierung von Datenträgern ist es das aber nicht, da die Kopie nicht dem Original entspricht. Demzufolge passen auch Prüfsummen wie MD5 nicht.

Definitiv sollte ein Sektorkopierer eine 1:1 Kopie erstellen und nicht in den Daten rumfudeln.

CU, Erhard

Moin,

Erhard hat geschrieben:ich habe soeben einen Bug im SECTORCOPY 1.5 (C) 07/88 BIBOSOFT gefunden.

Dieser äußert sich wie folgt: Eine hiermit erstellte Kopie enthält in Byte 0 von Sektor 1 eine $80 statt einer $00, wenn das Original dort eine $00 stehen hat.

Ob das Verhalten nun Absicht ist oder auf einem versehentlichen Fehler beruht weiß ich nicht.

Definitiv sollte ein Sektorkopierer eine 1:1 Kopie erstellen und nicht in den Daten rumfudeln.

Na mal langsam mit den jungen Pferden - das sollte erstmal verifiziert werden

Also... ich habe soeben mal eine stinknormale, Single-Density Diskette mit US Speed Loader und irgendwelchen Games drauf genommen. Das erste Byte im ersten Sektor auf $00 geändert, mit SCOPY 1.5 (von der Speedy Tooldisk) kopiert und die Kopie angeschaut: Byte 0 im Sektor 1 ist $00, wurde also einwandfrei mitkopiert.

Auf welchem Rechner hast Du das gemacht? Wenn es Atari XE war, dann ist das "normal". Es gibt eine... sagen wir, Unschönheit, die sich durch alle Sektorkopierer von E. Reuß / Compy-Shop zieht: Um Platz zu sparen, verwenden diese den Bereich $D500-$D5FF (Steuer-Page für Cartridge Control) als "Speicherbereich", in dem lauter $FF sind - und bauen damit das Sektorfeld für den Formatierbefehl auf - die genaue Funktion habe ich nie ganz verstanden, weiß aber, daß diese 128 Bytes entsprechend vorbereitet sein müssen und überwiegend $FF enthalten, damit die 1050 richtig formatiert.

Auf einem XL funktioniert das gut - weil der Pull-Up Widerstände auf den Datenleitungen hat. Damit liest die CPU immer $FF im Bereich $D500-$D5FF. Ist ein Modul eingesteckt, verweigert der Kopierer ja seinen Dienst.

Auf einem XE wiederum ohne Pull-Up Widerstände werden dort Zufallswerte gelesen - und diese werden für den Buffer zum Formatierbefehl genutzt. Das geht meistens gut, aber manche Firmware-Versionen reagieren "komisch" darauf. Ich habe mich nie so intensiv reingehängt, weil aber, daß es immer mal wieder Probleme mit Kopien gab. Sowie man die Pull-Ups im XE nachrüstet, ist der Spuk vorbei.

Hast Du dies gemacht und/oder einen XL, dann poste doch mal bitte das _exakte_ Szenario, wie und womit Du was getestet hast, bitte. Rechnertyp, OS-Version, Floppy-Typ, Firmware, welcher Speeder usw.

Viele Grüße, Jürgen

PS: Dieses "Gefummel" am Bereich $D500-$D5FF sorgt auch dafür, daß der SectorCopy 1.5 als auch der US-Copy 4 gern mal Probleme beim Vorhandensein einer Ultimate 1 MB macht. Es funktioniert prima, bis man Reset drückt, dann hängt der Rechner in einer Dauer-Reset-Schleife, hier hilft nur ausschalten.

Hi,

ich habe SECTORCOPY 1.5 von der Bibo-DOS Master Disk genommen (und dazu eben diese Disk mit der Option 2 gebootet).

Dann zwei Versuche: Disk to ATR und ATR to ATR.

Verwendete Hardware ist ein 130 XE mit original OS.

Als EMU APE via USB-Interface.

Die 1050 scheidet als Ursache aus, weil bei ATR to ATR auch das Byte geändert wird. (Und es ist das einzige Byte der ganzen Disk, was nicht paßt).

APE und der Atari scheiden auch aus, weil das Problem mit anderen Sektorkopierern nicht auftritt.

Die schwebenden Bits in $D5xx müßten meines Erachtens mehr Fehler verursachen, wenn sie als Ursache für dieses eine geänderte Byte in Frage kommen, was meinst Du?

Vielleicht gibt es mehrere Varianten von dem SECTORCOPY 1.5 ...?

CU, Erhard

Moin,

also ich kann es nicht nachvollziehen. Getestet mit zwei "stock" Maschinen, keine Erweiterungen. Einmal Atari 800XL, der andere ein 130XE, beide mit XL-OS Rev.2 (C061598B ROM).

APE SIO2PC-USB Interface, Windows 10 64 Bit, AtariMax Treiber 1.0.0.7 vom 23.02.2009, APE registrierte Version 3.0.14.

Zum Test habe ich die beiden PD-Disks hier downgeloadet, Nr. 649 (Speedy Tooldisk, da ist auch Sector Copy 1.5 drauf) und Nr. 764 (Bibo-DOS Masterdisk, mit dem Menü "2" (FAST) und dann "Sektor Kopierer" ausgewählt.

In dieser Testumgebung habe ich jeweils die Speedy-/Bibo-Disk vorher mit einem Editor bearbeitet und das erste Byte ($00, danach folgt $03 bei beiden) auf $80 gesetzt und diese Disks dann kopiert. Alle Kopien, egal ob von APE auf APE oder APE auf 1050 (mit/ohne Speedy) oder 1050 auf APE sind identisch, $80 bleibt $80. Natürlich jeweils mit dem SectorCopy 1.5 von der Speedy Tooldisk als auch der Bibo-DOS Masterdisk.

Zum Schluß nochmal 2-3 Tests mit anderen Disketteninhalten, aber... keine Änderung. Ich kann das absolut nicht nachvollziehen. Hmm - seltsam

Grüße, Jürgen

Hi,

ich bin auf das Thema gekommen, weil ein Atarianer namens Stefan die Magazindisks ATR-isiert und mit MD5 Prüfsummen mit der Bitte um Prüfung gemailt hat.

Ich habe darauf hin die Abweichungen festgestellt und die Prozedur von ihm nachgestellt, worauf ich in den gleichen Fehler gelaufen bin.

Ich werde mir das am WE noch einmal genauer anschauen. Unter der Woche nach Feierabend hab ich einfach weder genügend Ruhe noch Zeit dafür.

Ich halte Dich auf dem Laufenden.

CU, Erhard

Hi,

so, ich glaube, daß ich etwas weiter gekommen bin. Ich habe nun eine gute Stunde lang verschiedene Tests durchgeführt.

1) Habe ich den ursprünglichen Test noch einmal wiederholt: ABUC141A.ATR über APE in ein neues ATR kopiert. Ergebnis: Sektor 1 Byte 0 wurde auf $80 geändert.

2) Das Ganze noch einmal mit einem SD Medium. Der Einfachheit halber die BiboDOS Master Disk. Ergebnis: Das Byte wurde nicht geändert.

3) Da das Verhalten bei SD offenbar nicht auftritt habe ich nun geprüft, ob das vom Inhalt der MD Disk abhängt. Ergebnis: bei einem ATR, welches mit Null gefüllt ist, tritt das Verhalten nicht auf. Da Mag141A im letzten Sektor viele $80 stehen hat, habe ich das Test-ATR angepaßt:

- letztes Byte=$80 -> Fehler tritt nicht auf.
- erstes Byte im letzten Sektor = $80 -> Fehler tritt nicht auf
- alle Bytes im letzten Sektor = $80 -> Fehler tritt nicht auf
- alle Bytes des Test-ATR auf $80 bis auf das erste Byte -> Fehler tritt auf
- alle Bytes des Test-ATR sektorweise mit der jeweiligen Tracknummer gefüllt -> Fehler tritt auf ($80)

Der Fehler tritt also scheinbar dann auf, wenn die Disk MD ist, voll ist, hängt aber nicht vom Dateninhalt ab.

4) Anderen Rechner verwendet: Original Atari 130 XE (120 K Speicher werden erkannt)

-> ABUC141A.ATR kopiert -> Fehler tritt nicht auf

5) Trubo Freezer 2011 eingesteckt, RAMDISK angeschaltet (312K werden erkannt)

-> ABUC141A.ATR kopiert -> Fehler tritt auf

Nach dem Stand an dieser Stelle ergibt sich, daß der Fehler abhängig davon auftritt, wie viel der Speichererweiterung über 120K verwendet wird. Ist die Disk leer verwendet SECTORCOPY 1.5 augenscheinlich Datenkompression in der Form, daß es sich leere Sektoren als leere Sektoren merkt.

6) Mein bei 1) verwendeter Rechner war ein Atari 130 XE mit Newell 1MB und eingestecktem Freezer (RAM aus)

-> Freezer ausgesteckt und Test wiederholt -> Fehler tritt auf

7) Den 130 XE von 4) wieder angeschlossen und SysCheck II v2.2 eingesteckt, RAM-Erweiterung aktiv

-> Fehler tritt auf

An dieser Stelle geb ich das Thema erst mal frei damit nachprüfen kann wer möchte.

Anbei noch die von mir verwendete BiboDOS Masterdisk sowie das als Quelle dienende Testmedium .

CU, Erhard

Neugierig wie ich bin, wollte ich das natürlich nachvollziehen.

Allerdings hat Byte 0 in Sektor 1 auf meiner Disk Mag141a eine $03 stehen. Und kopiert mit Sector Copy 1.5 bleibt's auch bei $03 im ATR. Das ATR wurde mit RespeQt 4.0 for Linux erstellt.

Also habe ich als nächsten Schritt von dem ATR eine Testkopie erstellt und dort Byte 0 in Sektor 1 auf $00 gesetzt. Dieses ATR habe ich dann mittels Sectorcopy auf ein weiteres ATR kopiert, und auf der Kopie ist dieses Byte dann wieder zu $03 verändert worden. Dabei spielt es keine Rolle, ob man die Option Formatieren nutzt oder nicht; das Ergebnis bleibt gleich und ist immer $03.

Dann habe ich den Rechner gewechselt. Vom 800XL mit originaler Compy-Shop-Erweiterung 256 KiB auf einen 130XE mit 256 KiB CS-kompatibler Erweiterung. Gleiche Ergebnisse.

Ein weiterer 800XL mit 192 KiB erweitert nach dem Schaltungskonzept von CB, gleiche Ergebnisse.

Dann ein Kopie von Disk auf Disk mittels einer 1050 Speedy und Sectorcopy. $03 in Byte 0 von Sektor 1 bleibt erhalten.

Nun auf der kopierten Disk das Byte auf $00 gesetzt und davon wieder eine Kopie erstellt mittels Sectorcopy. Das Byte bleibt auf $00.

Wenn also Disk-2-Disk funktioniert und Disk-2-ATR nicht - in diesem sehr speziellen Fall - wäre es ggf. wichtig zu wissen, welche Funktion(en) in Sektor 1 der Disk liegen. Vielleicht kommt man dann weiter. Vmtl. hat es etwas mit dem Menüprogramm von Jiri zu tun.

Übrigens, die Kopien auf ATR bzw. Disk, auch wenn verändert, starteten aber einwandfrei.

Nachtrag:

Blöder Fehler meinerseits ...
Der Hex-Editor stand auf 17 statt 16 Bytes pro Zeile ...

Das erste Byte in Sektor 1 ist also auf der Disk $00, das zweite $03.

Ändert aber nix am Ergebnis, denn das auf $00 gesetzte zweite Byte wurde beim Kopieren mit Sectorcopy auf ATR auf $03 gesetzt.

Hi GoodByteXL,

GoodByteXL hat geschrieben:wäre es ggf. wichtig zu wissen, welche Funktion(en) in Sektor 1 der Disk liegen

der Sektor 1 der Disk ist der Bootsektor. Er enthält alle Informationen, die der Computer braucht, um die Disk zu booten.

Bei einer mit Atari DOS 2.x formatierten Disk fängt der Bootsektor wie folgt an:

00 03

Byte 0 (hier: 00) wird meines Wissens durch die Boot-Routinen des OS nicht verwendet
Byte 1 (hier: 03) gibt die Anzahl der zu bootenden Sektoren an, hier eben 3

Hier noch mal eine Zusammenfassung um was es geht:

- bei Verwendung eines Atar 130 XE mit Ramdiskerweiterung auf mindestens 320K
- und unter Verwendung von SECTORCOPY 1.5 (formatiere Zieldisk: nein)
- und bei einer Quell-Disk, bei der alle Sektoren irgendwelche Daten enthalten

ändert augenscheinlich SECTORCOPY 1.5 Byte 0 von $00 auf $80 auf der Ziel-Disk.

Ich habe zwei verschiedene Rechner und drei verschiedene RAM-Erweiterungen ausprobiert, so daß ich davon ausgehe, daß kein Hardwarefehler vorliegt.

CU, Erhard

Sööö, gerade noch einmal getestet. Bei mir wird Byte 1 im Sektor 1 nicht verändert, weder auf der Disk (extra auf 1050 Turbo, also ohne Cache getestet) noch auf dem ATR. Es ist und bleibt null.

Gedanke: Wenn Byte 1 keine Funktion haben sollte, verwendet jemand es ggf. zum Markieren von Kopien?

Ich habe die Kopien mit dem Sectorcopy von der originalen Speedy-System-Disk gemacht, die ich zusammen mit der Mini-Speedy 1050 vor Jahrzehnten gekauft hatte.

Nachtrag: Und Bingo !!!

Der Sektorkopierer von deiner Bibo-Masterdisk verursacht das tatsächlich. Also wohl doch ein Marker ...

Die Systemdisk ist ABBUC PD #0649, die BiboDOS Masterdisk #0764. Ein Vergleich der Versionen zeigt es wohl auf.

Hi GoodByteXL,

GoodByteXL hat geschrieben:Nachtrag: Und Bingo !!! ………. Also wohl doch ein Marker ...

vielen Dank, daß Du das ausprobiert hast und noch besser, daß es nachvollzogen werden konnte.

Das mit dem Marker … tritt ja nur auf, wenn ein Rechner mit mehr RAM als ein 130XE hat verwendet wird. Da würde ich denn Sinn des Markierens nicht verstehen.

Meine BiBo-DOS Masterdisk ist übrigens ein Original vom CompyShop.

Ich werde das mal gelegentlich mit dem von Dir genannten Exemplar vergleichen.

Viele Grüße, Erhard

Erhard hat geschrieben:...
Das mit dem Marker … tritt ja nur auf, wenn ein Rechner mit mehr RAM als ein 130XE hat verwendet wird. Da würde ich denn Sinn des Markierens nicht verstehen.

Tja, das ist die Frage, was da genau passiert. Mit 64 KiB Speicher passiert es definitiv nicht.

Da müsste mal jemand das Programm Sectorcopy von der Masterdisk lösen (ich kann das nicht) und disasassemblieren, um das sagen zu können.

Erhard hat geschrieben:Meine BiBo-DOS Masterdisk ist übrigens ein Original vom CompyShop.

Ich werde das mal gelegentlich mit dem von Dir genannten Exemplar vergleichen.

Die beiden DIsks in der PD-Bibliothek wurden von meinen Originalen gezogen und dort eingestellt. Die MD5 - ermittelt unter SDX 4.49 - ist identisch mit deiner.

Was für mich am Ende noch offen ist:
Wieso startet die ABBUC-Disk Mag141A von der 1050, obwohl (!) ich irrtümlich den Sektor 2 von $03 auf $00 gesetzt hatte?

GoodByteXL hat geschrieben:Was für mich am Ende noch offen ist:
Wieso startet die ABBUC-Disk Mag141A von der 1050, obwohl (!) ich irrtümlich den Sektor 2 von $03 auf $00 gesetzt hatte?

ich vermute, Du meinst nicht Sektor 2, sondern das zweite Byte im ersten Sektor, richtig?

Wenn ja, behaupte ich, Du hast die Änderung nicht vorgenommen oder nicht gespeichert. Wenn doch, wurde nicht mit dem geänderten Datum geladen. Denn wenn 0 (Null) statt 3 dort steht, werden im Boot-Prozess genau Null viele Sektoren geladen und es wird "BOOT ERROR" angezeigt und wiederholt

Stefan hat geschrieben: GoodByteXL hat geschrieben:
Was für mich am Ende noch offen ist:
Wieso startet die ABBUC-Disk Mag141A von der 1050, obwohl (!) ich irrtümlich den Sektor 2 von $03 auf $00 gesetzt hatte?



ich vermute, Du meinst nicht Sektor 2, sondern das zweite Byte im ersten Sektor, richtig?

Wenn ja, behaupte ich, Du hast die Änderung nicht vorgenommen oder nicht gespeichert. Wenn doch, wurde nicht mit dem geänderten Datum geladen. Denn wenn 0 (Null) statt 3 dort steht, werden im Boot-Prozess genau Null viele Sektoren geladen und es wird "BOOT ERROR" angezeigt und wiederholt

..naa gut, das war zu voreilig und ich behaupte jetzt, ich arbeite zu viel mit dem Altirra und zu wenig mit der nativen Hardware Denn nach dem ich meinen 600XL (mit CompyShop-Erweiterung auf 64K aufgerüstet) herangeholt und damit probiert habe, muss ich erstaunt feststellen, es werden 255 Sektoren eingeladen und dann erst unter akustisch aufdringlichem Getöse die permanent wiederholte Zeile mit dem "BOOT ERROR" gebracht. Ein rasch herangeholter 800XL (originalzustand) zeigt das gleiche Verhalten, wie zuvor der 600XL

Hi,

GoodByteXL hat geschrieben:die BiboDOS Masterdisk #0764

GoodByteXL hat geschrieben:Die MD5 - ermittelt unter SDX 4.49 - ist identisch mit deiner.

wenn die MD5 Prüfsummen übereinstimmen dann sind auch die Daten identisch. Ich habe soeben den Test

- Atari 130 XE mit 512K RAM-Erweiterung
- SECTORCOPY 1.5, Formatieren: Nein
- Kopiere volles MD ATR auf ein anderes

noch einmal mit der BiboDOS Masterdisk PD #0764 durchgeführt - wie erwartet tritt der Fehler hier auch auf.

CU, Erhard

Stefan hat geschrieben:

Stefan hat geschrieben:

GoodByteXL hat geschrieben: Was für mich am Ende noch offen ist:
Wieso startet die ABBUC-Disk Mag141A von der 1050, obwohl (!) ich irrtümlich den Sektor 2 von $03 auf $00 gesetzt hatte?

ich vermute, Du meinst nicht Sektor 2, sondern das zweite Byte im ersten Sektor, richtig?

Wenn ja, behaupte ich, Du hast die Änderung nicht vorgenommen oder nicht gespeichert. Wenn doch, wurde nicht mit dem geänderten Datum geladen. Denn wenn 0 (Null) statt 3 dort steht, werden im Boot-Prozess genau Null viele Sektoren geladen und es wird "BOOT ERROR" angezeigt und wiederholt

..naa gut, das war zu voreilig und ich behaupte jetzt, ich arbeite zu viel mit dem Altirra und zu wenig mit der nativen Hardware Denn nach dem ich meinen 600XL (mit CompyShop-Erweiterung auf 64K aufgerüstet) herangeholt und damit probiert habe, muss ich erstaunt feststellen, es werden 255 Sektoren eingeladen und dann erst unter akustisch aufdringlichem Getöse die permanent wiederholte Zeile mit dem "BOOT ERROR" gebracht. Ein rasch herangeholter 800XL (originalzustand) zeigt das gleiche Verhalten, wie zuvor der 600XL

Es ist wirklich so!

Man nehme: SDX und starte den Hex-Editor Eddy. Damit bitte auf einer realen Disk das Byte #2 im Sektor #1 von $03 auf $00 setzen und abspeichern.

Diese Disk, gebootet auf meiner 1050 Mini-Speedy HSD, läuft normal durch und das Intro von Mag #141 startet.

Ich vermute, dass das vorherige Einlesen der Directory in den Cache der Speedy dies bewirkt. Steht dem System kein Cache zur Verfügung wie bei ATR oder Turbo, dann geht's nicht, und es tritt der von dir beschriebene Effekt auf.

Erhard hat geschrieben:... noch einmal mit der BiboDOS Masterdisk PD #0764 durchgeführt - wie erwartet tritt der Fehler hier auch auf.

Das ist halt die Frage, ob es ein Fehler ist oder einen Zweck verfolgt. Leider habe ich keinen 128K-XE oder -XL mehr. Denn dann könnte ich ggf. testen, ob es einen Unterschied gibt zwischen Erweiterung mit bzw. ohne getrennten Zugriff von CPU und ANTIC auf den Erweiterungsspeicher.

Hi,

GoodByteXL hat geschrieben:Es ist wirklich so!

Man nehme: SDX und starte den Hex-Editor Eddy. Damit bitte auf einer realen Disk das Byte #2 im Sektor #1 von $03 auf $00 setzen und abspeichern.

Diese Disk, gebootet auf meiner 1050 Mini-Speedy HSD, läuft normal durch und das Intro von Mag #141 startet.

dem würde ich auch gerne nachgehen. Das würde ja bedeuten, daß hier ein Zwischenspeicher nicht zurückgeschrieben wird. Mach bitte einmal folgenden Test:

- änder wie gehabt und mit de gleichen Umgebung das Byte, lies den Sektor direkt danach neu ein und prüfe das geänderte Byte
- nimm die Disk einmal kurz raus, leg sie wieder ein, lies den Sektor neu ein und prüfe das Byte erneut

Was wird jeweils angezeigt?

CU, Erhard

Erhard hat geschrieben:Hi,

GoodByteXL hat geschrieben:Es ist wirklich so!

Man nehme: SDX und starte den Hex-Editor Eddy. Damit bitte auf einer realen Disk das Byte #2 im Sektor #1 von $03 auf $00 setzen und abspeichern.

Diese Disk, gebootet auf meiner 1050 Mini-Speedy HSD, läuft normal durch und das Intro von Mag #141 startet.

dem würde ich auch gerne nachgehen. Das würde ja bedeuten, daß hier ein Zwischenspeicher nicht zurückgeschrieben wird. [...]

CU, Erhard

Hi Erhard,

wie ich hier http://www.abbuc.de/community/forum/viewtopic.php?f=3&t=10391&p=86702#p86694 zuvor kurz geschrieben hatte, ist die Lösung dieses Rätsels völlig simpel: das Atari-OS des XL versucht mit dem Wert $00 im zweiten Byte (DBSECT), ab Sektor 1 insgesamt 256 Bootsektoren zu der in den Byte 3 und 4 genannten Adresse einzuladen. Allerdings wird am Abschluss versucht, den Sektor 0 (null) zu laden, den es ja nicht gibt, weil der erste Sektor ist Sektor 1.

Bei meinen flugs durchgeführten Tests - Probieren geht über Studieren - mit einem 64K 600XL wie auch einem unmodifizierten 800XL an SIO2PC mit AspeQt (unter Win7) führt der Wert $0 im Byte zwei nach dem Laden von 255 Sektoren zum Anfordern des Sektor 0 und es erscheint "BOOT ERROR". Erscheint mir absolut logisch soweit.

Ich vermute, dass die Mini-Speedy bei GoodByteXL beim Ladeversuch des Sektor null etwas anderes als eine Fehlermeldung zurückgibt, weshalb kein "BOOT ERROR" auftritt, sondern eben die (wenn auch überzählig) gebooteten Daten gestartet werden. Schließlich ist ja sämtlich notwendiger Programmcode (und noch viiiel mehr, aber nicht zu wenig) geladen und deshalb startbar.

Soweit von mir zunächst zum $0 in DBSECT. Weiterhin offen bzw für mich unklar ist, weshalb Sectorcopy 1.5 auf einem Atari mit Speichererweiterung, wie ein 130XE oder kompatibel dazu erweiterte XL-Modelle, bei der Zieldiskette das erste Byte des ersten Sektors von $00 auf den Wert $80 (oder besser gesagt, Bit 7 wird gesetzt, denn aus zB $5f in der Quelle wird $df beim Ziel) modifiziert, während ein 64K-Atari den Wert von der Quelldiskette beibehält. Ich denk, das kann nur ein Bug sein und nicht gewollt. Zurück zum ursprünglichen Thema, an dem ich noch nicht weiter getestet habe

Viele Grüße
Stefan

Erhard hat geschrieben:Hi,

GoodByteXL hat geschrieben:Es ist wirklich so!

Man nehme: SDX und starte den Hex-Editor Eddy. Damit bitte auf einer realen Disk das Byte #2 im Sektor #1 von $03 auf $00 setzen und abspeichern.

Diese Disk, gebootet auf meiner 1050 Mini-Speedy HSD, läuft normal durch und das Intro von Mag #141 startet.

dem würde ich auch gerne nachgehen. Das würde ja bedeuten, daß hier ein Zwischenspeicher nicht zurückgeschrieben wird. Mach bitte einmal folgenden Test:

- änder wie gehabt und mit de gleichen Umgebung das Byte, lies den Sektor direkt danach neu ein und prüfe das geänderte Byte
- nimm die Disk einmal kurz raus, leg sie wieder ein, lies den Sektor neu ein und prüfe das Byte erneut

Was wird jeweils angezeigt?

CU, Erhard

Hatte ich alles gemacht, weil ich ebenso verblüfft war und es mir nicht erklären konnte.
Der Unterschied besteht in der Speedy. Liest man vor dem Booten das Directory ein, bleibt es im Cache erhalten. Dadurch funktioniert der Bootvorgang offenbar dann trotzdem. Löscht man das Directory aus dem Cache, startet die Speedy das Einlese permanent von Neuem.

Was das eigentliche Thema der Modifizierung durch 'Bibosoft Sectorcopy 1.5' angeht, sollte vorbehaltlich einer Klärung respektive Bugfix nur die Version von der Speedy System Disk (PD # 0649) Verwendung finden. Werde die Manager der PD-Bibliothek deswegen mit der Bitte um Aufnahme eines Hinweises 'anfunken'.

Hi,

GoodByteXL hat geschrieben:Hatte ich alles gemacht

Du sagst also, daß wenn Du Sektor 1 von einer Disk auf einer Speedy 1050 einliest, darin etwas änderst und zurückschreibst, die 1050 nicht anläuft und die Daten nicht auf Disk schreibt?

CU, Erhard