Diskussion:OPEN

Dateitypen

@Mac Bacon: Der praktische Nutzen ist freilich bei relativen Dateien beschränkt, aber man kann diese auch "ganz normal" per OPEN öffnen und quasi sequenziell lesen/schreiben. Allerdings liest/schreibt man dann nur den ersten Record (dabei wird auch nicht etwa automatisch weitergeschaltet). D.h. eine realative Datei vereint somit leider nicht die direkte Positionierung innerhalb von Dateien, wie dies faktisch jedes andere Filesystem eines Betriebssystem (CP/M weiß ich nicht, aber zumindest seit PC-DOS/FAT-Tagen) möglich ist.
D.h. rein syntaktisch ist es kein Widerspruch, diese Möglichkeit anzugeben. Ob man hier nur die praktikablen Varianten erwähnt, ist fast Geschmackssache, aber Vollständigkeit halber fände ich besser, es erwähnt zu lassen. Bei den Beispielen kann man dann den "praktischen Gedanken" verwirklichen. --JohannKlasek (Diskussion) 18:38, 7. Mär. 2016 (CET)

Wir sollten jede Möglichkeit hier auf zeigen! --Jodigi (Diskussion) 04:32, 8. Mär. 2016 (CET)

Wo er recht hat, hat er recht. :) In der Tat, ich hab's nochmal im 1541-ROM-Listing überprüft, gibt es für die Typ- und Moduserkennung (siehe $DA09 nur die Buchstaben R, W, A, M für Modus und D, S, P, P, L für Typ. "D" hab ich als "DEL" (deleted) Datei jetzt bislang nicht erwähnt. Also da fällt mir kein wie auch immer gearteter Nutzen ein bzw. es hat meines Erachtens nur eine DOS-interne Bedeutung. Ich glaub jetzt müsste es passen. --JohannKlasek (Diskussion) 22:17, 8. Mär. 2016 (CET)

Der Nutzen von "DEL" war bei der Gestaltung von Directorys über Diskettentools gegegeben, um ein Directory übersichtlicher zu gestalten. Vielleich etwas zweckentfremdet, aber das wurde von den pfiffigen Usern und den o.g. Tools genutzt.

Eine DEL-Datei (Gelöschte Datei) hat für Datenspeicherung sogesehen keinen Nutzen. --Jodigi (Diskussion) 23:22, 8. Mär. 2016 (CET)

Sekundäradresse Floppy

Das 1541 Benutzerhandbuch schreibt über die Sekundäradressen 0 und 1 (Hervorhebung von mir): Die Sekundäradressen 0 und 1 sind für das Laden (LOAD) und Speichern (SAVE) von Programmen bestimmt. Ist das so richtig? --Moiree 01:23, 5. Dez. 2009 (CET)

Die Kausalität ist umgedreht: LOAD und SAVE verwenden die entsprechenden Sekundäradressenwerte. Dadurch, dass der Defaulttyp "PRG" ist, ist somit bei SAVE und LOAD sonst keine explizite Angabe notwendig.
Also der Satz aus dem Handbuch ist nicht falsch, sagt aber auch nicht, dass dies ausschließlich und exklusiv so ist. Kann man ja leicht mit SEQ-Dateien überprüfen ...
--JohannKlasek 03:54, 5. Dez. 2009 (CET)

Gut. Habe nur schon beobachtet, daß das speichern in einer SEQ-Datei mit der Sekundäradresse 0 nicht funktioniert hat, woraus ich unter Bezug auf das obige Zitat schloß, daß es am Dateityp lag. In der Tat ist es wohl aber so, daß "0" vom DOS, ohne Rücksicht auf den Dateityp, zum Lesen reserviert ist, denn das speichern einer SEQ-Datei mit "1" gelang. :-/ --Moiree 04:00, 5. Dez. 2009 (CET)

Fehlermeldungen

Bislang sind Fehlermeldungen stets nur fett ausgezeichnet worden. Hat das einen speziellen Grund hier von Konvention abzuweichen und diese als code-Abschnitt darzustellen? Siehe C64-Wiki_Diskussion:Regelbuch Punkt 5 und 7.
--JohannKlasek 04:28, 5. Dez. 2009 (CET)

Ach, das war mir nicht bekannt. Ich meine, das sieht mehr so wie auf dem Bildschirm aus und ist eher als Rechnerausgabe zu erkennen. Am allerschönsten wäre natuerlich so was ?ODER SO AEHNLICH. Ist aber aufgrund des nicht überall vorhandenen Schriftsatzes nicht vernünftig realisierbar.--Moiree 10:43, 5. Dez. 2009 (CET)

Es war mal gedacht, das komplette C64-Wiki im C64-Zeichensatz-Design darzustellen, daß war aber damals im Test unschön und bisher wurde daran nicht weitergearbeitet.

Und bedenkt, wenn einer meint den Standard zu ändern, darf er nicht vergessen alle anderen Artikel dementsprechend auch anzupassend, da ein einheitliches Design schon wegen dem Wiedererkennungswert sinnvoll ist.

Und ohne einen Kompromiss kommt es dann schon wieder zu ungewollten hin und her-Edits...

Schön wäre es wenn es für Fehlermeldungen oder normalen Systemmeldungen eigne Tags geben könnte, wie z.B. <fmeld> oder <smeld>, damit es eine Abgrenzung zum Programm- bzw. BASIC-Code < code> geben kann--Jodigi 21:03, 5. Dez. 2009 (CET)

Exzellente Idee! {{fehlermeldung|fehlertext}}. Mal ausprobieren!--Moiree 22:43, 5. Dez. 2009 (CET)

Überarbeitung

Ich hab die Beispiele komplett als Code definiert, damit sie leichter lesbar sind. Das sollte bei LOAD und SAVE auch so gehandhabt werden, finde ich. --GoDot (Diskussion) 14:45, 29. Jun. 2021 (CEST)

Funktionierte FileSeek beim C64?

Kann man mit dem normalen Basic eigentlich auf einer Diskette eine Datei bei einer bestimmten Position zum Lesen öffnen, oder geht das immer nur vom Anfang der Datei aus? Bei VisualBasic (VBA) kann man ja auch unter Excel Dateien bei einer vorgegebenen Position zum Lesen öffnen.

Diese Information hatte ich im Artikel vermisst. Wenn das nicht funktionieren sollte, dann sollte man das ebenfalls erwähnen. --77.22.10.5 17:35, 22. Jan. 2024 (CET)

Das geht (bei sequenziellen Dateien) nicht, ich habe bei den Beispielen einen Satz und Link dazu hinzugefügt. -- 1570 (Diskussion) 18:24, 22. Jan. 2024 (CET)

Würde es bei "PRG"-Dateien funktionieren? --77.22.10.5 21:11, 22. Jan. 2024 (CET)

PRGs sind auch nur sequentielle Dateien plus die Konvention, dass die ersten beiden Bytes eine Ladeadresse darstellen. REL-Dateien erlauben Sprünge. Genaueres dazu siehe wie verlinkt CBM-Dateisystem. Das Ganze ist eher eine Einschränkung des CBM-DOS als von OPEN - gut möglich, dass andere Geräte das Anspringen von Offsets in PRGs/SEQs mit irgendeinem Befehl erlauben. -- 1570 (Diskussion) 22:59, 22. Jan. 2024 (CET)

Der "Lesezeiger" beginnt zwar immer am Dateianfang, aber den Schreibzeiger kann man durch den Append-Modus ans Dateiende setzen lassen (implizit überliest somit das DOS den Inhalt, ohne ihn nämlich über die IEC-Schnittstelle übertragen zu müssen). Aber trotzdem im Vergleich zu anderen Dateisystemen oder REL-Dateien ineffizient.
Wie schon erwähnt wurde, hat das mit OPEN an sich nichts zu tun, das ist eine im CBM-DOS liegende Eigenschaft von PRG/SEQ/USR-Dateien. --JohannKlasek (Diskussion) 08:52, 23. Jan. 2024 (CET)