Datei in Assembler speichern und in BASIC laden

40 GET#1,A$:V(I)=ASC(A$+CHR$(0))

WIMRE liest INPUT# bis zu einem Zeilenumbruch, während GET# einfach nur ein Byte einliest.

Neben Zeilenumbruch auch bei

Komma

< und >
semikolon und doppelpunkt

Bei „kleiner“ und „größer“ auch?

Arndt

Zitat von GoDot

Bei „kleiner“ und „größer“ auch?

Laut Wiki schon. Habs aber ned ausprobiert

Zitat von Goodwell

Laut Wiki schon.

In *welchem* Wiki? Im C64-Wiki jedenfalls nicht. Würde mich auch schwer wundern, denn die beiden Zeichen haben sonst keine Interpreter-Bedeutung wie die anderen Zeichen bei dem Befehl.

Arndt

Dada: https://www.c64-wiki.com/wiki/INPUT(hash)

Zitat von Goodwell

Dada: https://www.c64-wiki.com/wiki/INPUT(hash)

Die Zeichen < und > werden in dieser Textpassage als Anführungszeichen benutzt!

Zitat von Goodwell

Dada: [...]

In Punkto Semikolon ist dieser Wiki-Artikel definitiv falsch. Die spitzen Klammern (vulgo, Größer bzw. Kleiner-Zeichen) nutzt der Artikel aber nur, um die Trennzeichen besser herauszustellen, das hast Du dann falsch interpretiert.

Als Trennzeichen gelten Komma, Doppelpunkt und CHR$(13). Mit Anführungszeichen CHR$(34) können zumindest Komma und Doppelpunkt verwendet werden, wenn man das ganze Element umschließt. Das ist auch notwendig, wenn führende oder folgende Leerzeichen übernommen werden sollen.

Wie Anführungszeichen innerhalb eines Datenelements verarbeitet werden, muß ich allerdings auch noch mal nachschauen.

Zitat von goloMAK

Zitat von Goodwell

Dada: https://www.c64-wiki.com/wiki/INPUT(hash)

Die Zeichen < und > werden in dieser Textpassage als Anführungszeichen benutzt!

Wiki ist ent-konfusioniert!

Oh danke. In der Eile beim Überfliegen falsch wiedergegeben. Mea culpa.

Uff, endlich geklärt!

Arndt

Zitat von Mike

Wie Anführungszeichen innerhalb eines Datenelements verarbeitet werden, muß ich allerdings auch noch mal nachschauen.

Ganz einfach mit 1 INPUTA$:PRINTA$:GOTO1 mal ausgetestet:

TEST"TEST liest TEST"TEST ein.

Ein Anführungszeichen mittendrin verhindert im Anschluß nicht die Erkennung von Komma oder Doppelpunkt als Trennzeichen, TEST"TEST:TEST ergibt also ?EXTRA IGNORED und TEST"TEST wird eingelesen.

Steht am Anfang ein Anführungszeichen, um mittendrin Kommas oder Doppelpunkte zuzulassen, führt ein weiteres Anführungszeichen mittendrin zu einem ?REDO FROM START und man muß die Eingabe ("richtig") wiederholen.

Insgesamt ist der INPUT-Parser also recht undurchsichtig und das nur, damit man mehrere Variablen mit einem INPUT-Befehl einlesen kann.

Speziell für das Auslesen aus einer Datei ist man sicher besser damit bedient, alles bis zu einem CHR$(13) in einen String einzulesen und den dann selber zu parsen, so wie ich das hier für den VC-20 gemacht habe - ROM calls and other tricks - Page 2 - Denial (sleepingelephant.com):

Zitat von Mike

; REL file READ RECORD written 2008 by Michael Kircher

; writing a record into a REL file with PRINT# is okay, but reading it

; back with INPUT# is a bit of a nuisance, since INPUT# is restricted to

; 88 (on the 64: 80) chars, and also barfs at anything unexpected, like

; commas, quotes, and colons.

; this pair of routines reads in a complete record up to (but not including)

; the terminating CR, and assigns it to a string, without any those problems.

Alles anzeigen

Zitat von muffi

40 GET#1,A$:V(I)=ASC(A$+CHR$(0))

Nur generell: Wenn man das Snippet in einem größeren Projekt einbindet, dann vielleicht besser in der effizienteren Variante (String-Heap und Laufzeit schonend):