Diskussion:SAVE
Was soll denn
Durch die Angabe der Sekundäradresse 1 wird ein Programm absolut gespeichert. Dies ist z.B. für Maschinenspracheprogramme erforderlich.
heißen? "Absolut gespeichert" heißt was? Was Maschinenspracheprogramme angeht, würde ich im Artikel darauf gar nicht eingehen, denn SAVE bzw. das ganze BASIC V2 kann mit MSPs ja sowieso eher nicht sinnvoll umgehen, und in der Praxis benutzt man BASIC-SAVE auch im Zusammenhang mit MSPs einfach nicht, oder? -- 1570 11:43, 16. Jul. 2012 (CEST)
- Hab das mal so korrigiert wie es im C64-Bedienungshandbuch steht und auch aus dem ROM-Listing von "C64 für Insider" ersichtlich ist. --H.T.W 14:41, 16. Jul. 2012 (CEST)
- Absolut gespeichert heißt, soviel wie es wird ein definierter Speicherbereich gespeichert z.b. $C000 bis $CFFF
- Ich würde es begrüssen, wenn wir alle Geheimnisse des SAVE-Befehls preisgeben auch wie man Maschinenspracheprogramme mit SAVE "NAME",8,1 abspeichert.
- Ich glaube, wir als erfahrende C64-User sind oft recht verwöhnt, weil wir vieles haben. Entsprechende Steckmodule mit wichtigen ergänzenden BASIC-Erweiterungen oder entsprechende Tools. Aber wir müssen oft bedenken, daß Neueinsteiger (egal ob C64 real oder C64-Emulator) eben nicht alles von Anfang an haben. Es ging in den Anfängen ebenfalls mit einfachen Bordmitteln sprich BASIC.
- Die grundlegenden Inhalte zu SAVE waren aus dem Buch "Alles über den C64" (1.Auflage), das ich als einen der wichtigsten Bücher zum C64 finde.
- Ich würde es weiterhin begrüssen die Hinweise der Sekundäradresse nicht einfach wegfallen zu lassen !
- Ein C64-Wiki sollte über alles neutral aufklären und nicht irgendwelche Mythen zwischen BASIC und Maschinensprache wieder verschärfen. --Jodigi 23:32, 16. Jul. 2012 (CEST)
- Wie soll SAVE denn $C000 bis $CFFF speichern und was hat die Sekundäradresse damit zu tun? Bzw. was sagt das Buch denn dazu genau? -- 1570 23:51, 16. Jul. 2012 (CEST)
- Kann ich zur Zeit leider nicht nachrecherchieren. Muss ich aber irgendwann sicher mal nachtragen. Aber es ist möglich. Ggf. muss da noch vorher etwas gepoket werden.
- Weiterhin habe ich auch schon BASIC-Programme mit rund 200 Blocks abgespeichert.--Jodigi 01:23, 17. Jul. 2012 (CEST)
- @Jodigi (und alle Admins):
- Es gibt mit dem normalen Save-Befehl (Beginn der regulären SAVE-Routine ab $f5ed) des Basic V2 KEINE Möglichkeit einen bestimmbaren Speicherbereich zu speichern. Die Save-Routine holt immer LB/HB der Startadresse ($0801) aus $c1/$c2 und diese Werte werden zu Beginn des zu speichernden Files gespeichert (die erste 2 Bytes).
- Es gibt bei Save mit Geräteadresse >1 KEINE Wirkung der Sekundäradresse, die wird einfach überlesen!
- Bei Geräteadresse 1 (Datasette) gibt es die Sekundäradresse 0 bis 3 (Bit 0 = Basic/Ass, Bit 1 = keinEOT/EOT) UND DA WIRDS KOMPLIZIERT! denn die zeigt nun wirklich der LOAD-Routine NUR für Datasette an ob absolut oder relativ geladen wird!! Es wird NUR die HEADERMARKE (Byte 1 im File, 01=Basic, 03=Ass, 05=EOT) gespeichert es kann aber auch hier KEIN bestimmbarer Speicherbereich gespeichert werden!!
- Sekundäradresse 0 (oder keine) = Zeigt der Load-Routine an dass ein Basic-Pgm (immer $0801 laden) folgt, KEINE Marke für BAND-ENDE (EOT) schreiben. Das ist der Normalfall
- Sekundäradresse 1 = Zeigt der Load-Routine an dass ein Maschinenspr-Pgm (Ladeadresse aus dem Beginn des Files holen) folgt, KEINE Marke für BAND-ENDE (EOT) schreiben
- Sekundäradresse 2 = Zeigt der Load-Routine an dass ein Basic-Pgm (immer $0801 laden) folgt, UND Marke für BAND-ENDE (EOT) schreiben.
- Sekundäradresse 3 = Zeigt der Load-Routine an dass ein Maschinenspr-Pgm (Ladeadresse aus dem Beginn des Files holen) folgt, UND Marke für BAND-ENDE (EOT) schreiben
- Sieh dir mal (und auch alle anderen) das Rom-Listing im von mir genannten Buch (du weist wo du es findest) Seite 238-242, 249 (GetHd EOT), 484, (10 Basic-Tab) an. Momentan stimmt das mit der Sec-Adr im Artikel noch nicht ganz nicht überein... Nachtrag: Jetzt schon zu 99,9% ...
--H.T.W 02:32, 17. Jul. 2012 (CEST)
- Sieh dir mal (und auch alle anderen) das Rom-Listing im von mir genannten Buch (du weist wo du es findest) Seite 238-242, 249 (GetHd EOT), 484, (10 Basic-Tab) an. Momentan stimmt das mit der Sec-Adr im Artikel noch nicht ganz nicht überein... Nachtrag: Jetzt schon zu 99,9% ...
- Nachtrag: Man könnte es auch einfacher sagen (gilt nur für Geräteadresse 1 - Datasette):
- Sekundäradresse 0 (oder keine) = Der Load-Routine anzeigen dass ein Basic-Pgm folgt (immer Start $0801)
- Sekundäradresse 1 = Der Load-Routine anzeigen dass ein Maschinenspr-Pgm folgt (immer Start aus File auslesen)
- Sekundäradresse 2 (3) = EOT schreiben und der Load-Routine damit anzeigen dass das Band zu Ende ist (die sucht immer zuerst nach EOT und das wars dann ;) )
--H.T.W 04:04, 17. Jul. 2012 (CEST)
- Schreibe doch mal bitte den OPEN-PRINT#-Trick als Kurzprogramm hinzu. Mich würde interessieren wie Du da die Start- und Endadresse setzt.--Jodigi 22:36, 23. Jul. 2012 (CEST)
- Siehe PRINT(Raute)-Beispiel. -- 1570 11:30, 24. Jul. 2012 (CEST)
Emulator SAVE Problem?[Quelltext bearbeiten]
Unter den Emulatoren VICE und c64 Forever ist mir folgendes aufgefallen: Ich speichere Basicprogramm mit SAVE"BLABLA",8. Dann erweitere ich Programm und speichere erneut mit SAVE"BLABLA",8. Nun blinkt die Laufwerks-LED. Wenn ich vor dem zweiten SAVE die Datei lösche mit OPEN 1,8,15,"S:BLABLA":CLOSE 1 funktioniert das Überschreiben.
Frage als Nur-Emulator-C64er: Hat echte C64 Hardware das gleiche Verhalten?
AndreAdrian (Diskussion) 22:03, 3. Apr. 2020 (CEST)
- Ja, hat er. Ist eine Datei mit gleichem Dateinamen auf Diskette abgespeichert, so kann man die Datei nicht einfach durch Überschreiben einfach erneuern oder löschen!
- Überschreiben (REPLACE) geht nur mit
SAVE "@:dateiname",8
, was bei einem echten C64 mit Floppy zu Problemen führen kann! - Oder alternativ erst mit dem o.g. SCRATCH-Befehl mit
OPEN 1,8,15,"S:dateiname":CLOSE 1
löschen und dann erneut mit SAVE abspeichern.
- Trotzdem wünsche ich Dir viel Spaß bei Deiner BASIC-Programmierung. --Jodigi (Diskussion) 00:30, 4. Apr. 2020 (CEST)
- Mit der REPLACE-Funktion würde jedenfalls vorsichtig sein. Es gibt da den legendären Replace-Bug, den man vermeiden sollte. Im Zweifelsfalls vorher löschen und dann speichern. Ich bin einst dazu übergegangen, Versionsnummern an Dateinamen anzuhängen und so fortlaufend abzuspeichern. Wenn dann kein Platz mehr war, habe ich dann die "alten" Versionen gelöscht oder auf einer anderen Diskette weiter gemacht.
--JohannKlasek (Diskussion) 00:10, 6. Apr. 2020 (CEST)
Länge des Dateinamen[Quelltext bearbeiten]
Hallo,
da gab es doch ein Limit. Es steht noch nicht drin, wie lang ein Dateiname sein darf. --Lulu-Ann (Diskussion) 00:15, 18. Aug. 2021 (CEST)
- Danke für den Hinweis! Ist ergänzt! --GoDot (Diskussion) 21:58, 18. Aug. 2021 (CEST)
- Das finde ich ziemlich überflüssig, hier explizit gerade bei SAVE spezifische Eigenschaften zum Dateinamen anzuführen. Das ist und sollte in Dateiname beschrieben werden. Sonst muss man anfangen die Beschreibung auch noch in LOAD, VERIFY und OPEN auch mehrfach anzuführen. Das hängt primär vom Gerät ab (ist also dessen Eigenschaft) und nicht von SAVE an sich und das Gerät entscheidet, wie viele Zeichen tatsächlich vom String auf dem Medium landen. Die SAVE-Routine selbst sendet etwa bei IEC-Bus-Geräten bis zu 255 zum Gerät.
Lediglich die von BASIC 4 stammenden Disk-Kommandos wie DSAVE, DLOAD, COPY, BACKUP, APPEND, etc. erlauben als Dateiname nur einen String mit maximaler Länge von 16 (sonst kommt "STRING TOO LONG ERROR"). --JohannKlasek (Diskussion) 18:10, 19. Aug. 2021 (CEST)
- Das finde ich ziemlich überflüssig, hier explizit gerade bei SAVE spezifische Eigenschaften zum Dateinamen anzuführen. Das ist und sollte in Dateiname beschrieben werden. Sonst muss man anfangen die Beschreibung auch noch in LOAD, VERIFY und OPEN auch mehrfach anzuführen. Das hängt primär vom Gerät ab (ist also dessen Eigenschaft) und nicht von SAVE an sich und das Gerät entscheidet, wie viele Zeichen tatsächlich vom String auf dem Medium landen. Die SAVE-Routine selbst sendet etwa bei IEC-Bus-Geräten bis zu 255 zum Gerät.
- Ich bin auch der Meinung, das bei Dateien von Datassetten bespw. länger Dateinamen als 16 Zeichen angezeigt werden und auch schon verwendet wurden. Lediglich im Directory einer Diskette ist es so, das die Anzeige dort bei 16 Zeichen begrenzt ist. Eventuell ist es sogar möglich mit überlangen Dateinamen bei Disketten einen einfachen Kopierschutz zu installieren. Dies müsste man aber Mal durchtesten!
- Und durch Manipulation des Directorys sind auch solche Einträge möglich:
100 "GEISTERJAGD",8: PRG<
--Jodigi (Diskussion) 19:36, 19. Aug. 2021 (CEST)
- --Zitat: Das ist und sollte in Dateiname beschrieben werden. --/Zitat. Das hatte ich nicht gecheckt, sorry. Es hätte also gereicht, bei Erwähnung des Begriffs "Dateiname" einen Link draufzulegen. Bin demnächst sorgfältiger. --GoDot (Diskussion) 22:12, 19. Aug. 2021 (CEST)
- D.h. vieles in den Dateinamen auslagern und hier nur einen kurzen Verweis mit der Begrenzung von Zeichen und max. Länge der Dateinamen. --Jodigi (Diskussion) 02:33, 20. Aug. 2021 (CEST)