letzter Beitrag von ZeroZero am
Grundsaetzlich beinhaltet ein PRG File ein Programm, welches aber auch sonst irgendwas beinhalten kann.
Normalerweise enthält es die in den ersten 2 Bytes, welche im Low-High Format sind, die Zielspeicherstelle wo es geladen werden soll, also z.B. für BASIC Programme $01 $08.
In Deinem Fall ist das Screen Memory $0400 (dezimal 1024), also müssten Deine 2 ersten Bytes $00 $04 sein.
Wenn Du dann so eine PRG Datei mit LOAD"MYSCREEN.PRG",8,1 lädst, wird sie direkt ins Screen RAM geschrieben.
In Deinem Fall ist das Screen Memory $0400 (dezimal 1024), also müssten Deine 2 ersten Bytes $00 $04 sein.
Das hätte ich auch so angenommen,
Ich habe mir per FCIII den Bereich von 1024 bis 2023 gespeichert
Wenn ich den mit ,8,1 lade wird mir das direkt auf den Bildschirm geladen
-> so weit so gut
Wenn ich nun mit
open 1,8,5,"name,p,r"
und
get #1,a$:print asc(a$)
der reihe nach die Datei einlese
bekomme ich 51,49,44,83,89 ...
irgendwie finde ich da weder eine 1024 noch eine 0400
Ich mutmasse mal, dass mit OPEN diese 2 Bytes ignoriert bzw. übersprungen werden.
Aber wenn Du eh mit OPEN arbeitest und damit selbst bestimmst, wo der Inhalt hin soll, dann kannst Du ja auch eine SEQ Datei erstellen, die nur die reinen Daten enthält.
<EDIT> Scheint so zu sein, wird hier beschrieben: http://www.c64os.com/post?p=27
Here's the thing though, when you open a PRG file for read or write via one of the channels, 2 through 14, it behaves exactly the same as a SEQ file. If you open a new PRG file for write, then the first two bytes you write are the first two bytes put down on the disk. Even though these two bytes will be treated as the load address if that file is subsequently LOADed. When writing a text file from a text editor, there is no reason why the text editor couldn't read and write the data to and from a PRG file. But most of them don't. Novatext, which I use all the time, just writes SEQ files as you would expect. The problem is that a file written from Novatext cannot be immediately thereafter LOADed without getting the Error #64.
Also bei mir klappt das Lesen. "Starter" ist ein Basic-Programm.
Prüf doch mal, ob deine Datei wirklich mit $00,$04 beginnt (mit irgendeinem Disk- oder Datei-Tool).
In deinem ersten Beitrag hattest du open1,8,15,"name,p,w" geschrieben. Ich weiss nicht, was passiert, wenn man den Fehlerkanal 15 zum Schreiben öffnet, aber ich würde erwarten, dass das nicht funktioniert.
ich habe jetzt ganz oben in die erste Zeile ABCDEFG ... geschrieben
Beim zurücklesen aus Basic bekomme ich
51,49,83,89,78,84,65,88,32,69 ...
erwartet hätte ich:
00,04,65,66,67,68,69 ...
Vorsicht, im Screen Memory steht kein PETSCII encoding sondern einfach die jeweilige Position im Zeichensatz ("Screen codes").
Was du hier bekommst ist zwar trotzdem Müll, aber zu erwarten wäre (dezimal):
0,4,1,2,3,4,5,6,7
ch habe jetzt ganz oben in die erste Zeile ABCDEFG ... geschrieben
Beim zurücklesen aus Basic bekomme ich
51,49,83,89,78,84,65,88,32,69 ...
erwartet hätte ich:
00,04,65,66,67,68,69 ...
Das macht leider wenig Sinn, was du da schreibst. Du schreibst also auf den Bildschirm (per Tastatur? per Programm?).
Du liest aus Basic zurück (vom Bildschirm? aus einer Datei? wie wurde die Datei erzeugt? wie wurde sie gelesen?)
Und wenn du "31SYNTAX E..." liest, dann hast du wohl wieder den Fehlerkanal ausgelesen (Kanal 15).
Also wenn du nicht mal genau beschreibst, was du eigentlich tust, dann wird man dir nicht helfen können.Ein Programmlisting wäre hilfreich.
Also bei mir klappt das Lesen. "Starter" ist ein Basic-Programm.
Prüf doch mal, ob deine Datei wirklich mit $00,$04 beginnt (mit irgendeinem Disk- oder Datei-Tool).
In deinem ersten Beitrag hattest du open1,8,15,"name,p,w" geschrieben. Ich weiss nicht, was passiert, wenn man den Fehlerkanal 15 zum Schreiben öffnet, aber ich würde erwarten, dass das nicht funktioniert.
Gut - im Screen shoot ists jetzt Kanal 5.
Aber klar - ein Listing würde zwar helfen, allerdings denke ich, dass das auf dem Screenshoot schon das ganze listing ist.
-------
Edit: Huch! Ich nehm alles zurück und behaupte nun das Gegenteil ... ist ja nur das Listing fürs Lesen.
Also wenn du nicht mal genau beschreibst, was du eigentlich tust,
This.
Ich nehme an: Was Du eigentlich willst, ist, "Kernal-Save" von Basic aus aufzurufen.
Edit: Huch! Ich nehm alles zurück und behaupte nun das Gegenteil ... ist ja nur das Listing fürs Lesen.
Da er ja nicht sagt, was er wie speichern will, kann man auch kein Listing zum Schreiben liefern.
Ich geb's erst mal auf, bis es brauchbare Infos gibt.
Wurzelzwerg sollte einfach mal beschrieben, was er eigentlich vor hat. Ich vermute, dass er schon bei der Herangehensweise auf dem Holzweg ist.
Es gibt normalerweise keinen Grund, Daten als PRG mit Load-Adresse zu speichern.
Das macht leider wenig Sinn, was du da schreibst.
Wie wäre es mal damit, Beitrag 1, 3 und 5 im Zusammenhang zu lesen?
Ich mutmasse mal, dass mit OPEN diese 2 Bytes ignoriert bzw. übersprungen werden.
Ähm- nein? Du 'verlierst' die ersten beiden Bytes, wenn Du so ein 'Pseudo-PRG' mit LOAD einlädst. Weil... Startadresse. Das ist aber eien Sache des LOAD im Computer, nicht des OPEN in der Floppy. An den Daten rumbasteln tut die Floppy nur bei Directories. Und die Startadresse hängt das Binär-SAVE des FC III ja offensichtlich richtig an, weil das LOAD...,8,1 funktioniert.
Wird eventuell mit SD2IEC oder Emulator gearbeitet, und die können kein PRG auf höheren Sekundäradressen? (sollten sie allerdings)
Es gibt normalerweise keinen Grund, Daten als PRG mit Load-Adresse zu speichern.
PRG-Dateien werden (in BASIC) schneller als SEQ-Dateien eingeladen.
Wie wäre es mal damit, Beitrag 1, 3 und 5 im Zusammenhang zu lesen?
Man kann sowas ja auch im Zusammenhang schreiben ... aber wenn du das verstanden hast... 
PRG-Dateien werden (in BASIC) schneller als SEQ-Dateien eingeladen.
Sicher nicht, wenn man sie mit OPEN und GET lädt. Die Floppy und das Basic machen da keinen Unterschied zwischen PRG und SEQ.
So wie ich das verstehe war das OPEN hier nur zum Test. Ich denke das ganze soll auf sowas hinauslaufen:
Danach stellt in der Tat ein load"screen",8,1 den Bildschirminhalt wieder her, vermurkst aber natürlich auch die BASIC Pointer.
Sehr schön.
Vor dem laden noch 0 in die 157 Poken damit das Ready am ende vom Laden nicht gleich wieder den screen verhaut.
Danach stellt in der Tat ein load"screen",8,1 den Bildschirminhalt wieder her, vermurkst aber natürlich auch die BASIC Pointer.
Eben - und funktioniert daher nicht. Also der falsche Ansatz, wie ich oben schon geschrieben hatte.
LOAD ist nicht für Daten sondern für Programme.
Eben - und funktioniert daher nicht. Also der falsche Ansatz, wie ich oben schon geschrieben hatte.LOAD ist nicht für Daten sondern für Programme.
Es gibt schon „Tricks“ wie man das umgehen könnte, aber wir wollen jetzt mal nicht den Namen „Bloody Mary“ hier heraufbeschwören... 
Insofern ist der OPEN Ansatz die richtige Richtung.
LOAD ist nicht für Daten sondern für Programme.
Naja, so pauschal kann man das jetzt auch nicht sagen. Spritedaten, Grafik und Assemblerprogramme lassen sich per Load recht komfortabel aus einem Basicprogramm nachladen!
Spritedaten, Grafik und Assemblerprogramme lassen sich per Load recht komfortabel aus einem Basicprogramm nachladen!
Und was macht man mit den Basic-Pointern? Vorher sichern und hinterher wieder herstellen? Sind die Variablen noch da?
Wird das eigene Programm danach überhaupt weiter ausgeführt oder muss man da auch noch tricksen?
