Diskussion:Relativdatei

RETURN-Zeichen und CHR$(255)

Ich habe das Verhalten von REL-Dateien selbst gerade recht intensiv getestet:
Man braucht zwar nicht zwingend das RETURN-Zeichen zum Abspeichern der Datensätze, es dient aber als Datensatztrenner. Daher erzeugt der Befehl PRINT#1,"ZEILE 1"+CHR$(13)+"ZEILE 2" automatisch 2 Records. Dagegen kann ich problemlos auch mehrere CHR$(255)-Zeichen in einem Datensatz ablegen. --Fedi (Diskussion) 21:43, 15. Feb. 2015 (CET)

Nachtrag: Die Tests habe ich auf einem emulierten C128 (Vice) mit Floppy 1571 durchgeführt. --Fedi (Diskussion) 22:22, 15. Feb. 2015 (CET)

Ich hab sie auch intensiv getestet, nur liegt das schon länger zurück und muss zum Teil die Ergebnisse noch verifizieren. Diese stammen allerdings auf C64+1541 auch unter Vice. --JohannKlasek (Diskussion) 22:47, 15. Feb. 2015 (CET)

Da ist mir wohl beim Testen ein Lapsus unterlaufen. So wie's aussieht, werden die Datensätze nicht durch das RETURN-Zeichen getrennt, sondern durch die einzelnen PRINT#-Vorgänge selbst, sprich mit jedem PRINT# wird ein neuer Datensatz angelegt, auch wenn der Befehl mit einem Semikolon abgeschlossen ist. Einen Problemfall stellen aber noch abschließende NULL-Bytes dar, da diese nicht ignoriert werden. --Fedi (Diskussion) 23:10, 15. Feb. 2015 (CET)

Genau darauf wollte ich hinaus, muss ich jetzt noch mein Testprogramm posten? Aus PRINT#/INPUT#/GET# beschränkt sich die Sicht immer nur auf einen Datensatz. Stimmt, die NULL-Zeichen am Ende werden ignoriert, das mit den 255er-Zeichen ist aber auch nicht zwingend das Ende des Datensatzes, sondern es geht nach dem was der letzte Schreibbefehl insgesamt geschrieben hat, nur NULL-Zeichen am Ende werden ignoriert - soweit meine Erkenntnis. --JohannKlasek (Diskussion) 23:59, 15. Feb. 2015 (CET)

Datensatzpositionsparameter

Die Erwähnung von "Laut einigen Handbüchern droht aber bei Verzicht auf diesen Parameter Datenverlust." ohne Beleg halte ich nicht für sinnvoll oder seriös. Entweder ist es so oder nicht bzw. unter welchen Bedingungen. So ist der Satz bestenfalls ein Schreckgespenst. Zumindest im CBM DOS 2.6 wird das völlig korrekt behandelt (laut ROM-Listing).
Diese Aussage kam vermutlich deswegen auf, weil die Leute das implizite CHR$(13) mitgesendet haben, weil das ";" am Ende des PRINT-Befehls fehlte und haben sich dann über den Datenverlust gewundert, weil mitten im Datensatz geschrieben oder gelesen wurde bzw. über das Ende positioniert wurde was dann "50, OVERFLOW IN RECORD,00,00" ergeben hat. Ursache und Wirkung halte ich für vertauscht. --JohannKlasek (Diskussion) 22:58, 19. Feb. 2015 (CET)

Erwähnen könnte man vielleicht das der Positionsbefehl mit dem Parameter einen Bug hat: Transaktor Vol. 7, Ausgabe 4, S. 73 ff. --BlackJack (Diskussion) 01:31, 20. Feb. 2015 (CET)

Vielleicht einen Abschnitt "Mythen und Fakten" einrichten? Z.B. habe ich "damals" irgendwo gelesen, man sollte auf Disketten mit REL-Dateien kein Validate ausführen, weil dann die Side-Sector-Blöcke freigegeben würden. --Fedi (Diskussion) 13:48, 20. Feb. 2015 (CET)

Das ist ja überhaupt die beste Urban Legend in Bezug auf die 1541er, die ich bislang gehört hab (also bei all den Versuchen der jüngeren Zeit, habe ich dafür keinerlei Beleg gefunden. Bitte, so etwas kann man im Forum64 diskutieren, oder hier, aber nicht auf der Hauptseite. --JohannKlasek (Diskussion) 14:11, 20. Feb. 2015 (CET)

Vielleicht hast Du mich falsch verstanden. Ich meinte nicht, dass an der Geschichte was dran ist, sondern erwähnte sie als Beispiel für einen "Mythos" (der vielleicht auf einer Verwechslung mit Direktzugriffsdateien beruht). --Fedi (Diskussion) 20:14, 20. Feb. 2015 (CET)

Die Sache, die BlackJack erwähnt hat, halte ich für wesentlich ernster und muss unbedingt rein. Wär auch interessant, ob das bei allen anderen CBM-DOS-Versionen auch der Fall war, oder irgendwann mal gefixt wurde (1581, ...). --JohannKlasek (Diskussion) 14:11, 20. Feb. 2015 (CET)

Hab das nun unter Besonderheiten abgehandelt (um dem Aufbau mit "Sequentielle Datei" konform zu bleiben). --JohannKlasek (Diskussion) 16:25, 19. Aug. 2016 (CEST)

Format des Super Side Sectors

Mir ist aufgefallen, dass im Handbuch zur 1581 ein anderer Aufbau des SSS beschrieben ist wie im Handbuch zum Laufwerk 8250. Laut 1581-Handbuch besitzt ein SSS Zeiger auf 126 Side-Sector-Gruppen, im anderen Handbuch wird von 127 Zeigern geschrieben. Weiß jemand, ob sich das Format tatsächlich unterscheidet oder ob es sich um einen Fehler in einem der Handbücher handelt? --Fedi (Diskussion) 22:48, 20. Feb. 2015 (CET)

Also das in 1581 stehende scheint mir plausibel (126):

+---------------------------------------------------------------+
| SUPER SIDE SECTOR BLOCK                                       |
|                                                               |
| 0,1        Track and sector of first side sector in group 0.  |
| 2          $FE                                                |
| 3,4        Track and sector of first side sector in group 0.  |
| 5,6        Track and sector of first side sector in group 1.  |
| 253-254    Track and sector of first side sector in group 125.|
+---------------------------------------------------------------+

  The  super  side  sector  has  pointers  to 126  groups of side
sectors.  Each of these groups contains 6 side sectors. Each side
sector points to 120 data blocks, containing 254 bytes each. 126x
6x120x254=23,042,880 bytes (maximum relative file size).

Auch die max. Größe würde dann passen, im Artikel nicht.

Wenn das obige stimmt und an Position 2 ein $FE steht, dann gehen sich ja nur 126 aus. Position 255 bleibt dann unbenützt. --JohannKlasek (Diskussion) 05:59, 21. Feb. 2015 (CET)

Ich habe das jetzt auf einer virt. CBM8250 getestet und das SSS-Format ist wie oben. Dass ein SSS 127 SS-Gruppen enthalten kann ist also ein Fehler des Commodore-Handbuchs. --Fedi (Diskussion) 19:10, 21. Feb. 2015 (CET)