Create a SEQ file in BASIC

[rje]

In order to do this, you need to boot with an SD image.  For example

 

~/commanderx16/x16emu_mac-r38/x16emu -sdcard ~/git/x16-a1-sd.img

Now you can get things done.  Here's a BASIC program that creates a new SEQ file.

You'll probably want to write several separate pieces of data.  The comma will separate data for you in a way that INPUT# knows how to read back in.  

100 OPEN 2,8,2,"0:MY-NEW-FILE,SEQ,W"
105 CO$ = "," 
110 PRINT#2, "ROB"; CO$; "10"; CO$; "2020"; CO$; "TEXAS"
120 CLOSE 2

The CO$ inserts actual commas into the SEQ file, so we can read them back in individually.  Otherwise INPUT# would treat the thing as one long line.

To read the SEQ file:

100 OPEN 2,8,2,"0:MY-NEW-FILE,SEQ,R"
110 INPUT#2, N$, M, YR, S$
120 CLOSE 2

 

[Greg King]

9 hours ago, rje said:

Here's a BASIC program that creates a new SEQ file.

(You'll probably want to write several separate pieces of data.  The comma will separate data for you in a way that INPUT# knows how to read back in.)

100 OPEN 2,8,2,"N0:MY-NEW-FILE,SEQ,W"
110 PRINT#2, "ROB", 10, 2020, "TEXAS"
120 CLOSE 2

 

That "N" in the "N0:" will be ignored; don't put it in the string.  And, don't bother to spell out the "SEQ".  Just use the initial letter:

100 OPEN 2,8,2,"0:MY-NEW-FILE,S,W"

[rje]

Quote

That "N" in the "N0:" will be ignored; don't put it in the string.

Thanks for the "N" bit... a holdover to the Bad Olde Days!

Quote

And, don't bother to spell out the "SEQ".  Just use the initial letter:

Because it's a clarification ("SEQ" is more obvious than "S") rather than a confusion (the "N" prefix is a confusion), I'd recommend always keeping this bit of syntactic sugar... especially when you've got the extra two bytes to spend.

[Edmond D]

I encountered an issue with line 110 of the reading code. I modified the line and it appears that reading N$ gave all the data in the line.





I'm sure the issue is with me ?

 

[Scott Robison]

I think you just need to print actual commas between each value you want to input later. So:

110 PRINT#2, "ROB";",";10;",";2020;",";"TEXAS"

INPUT expects commas and possible quote delimited strings. If I remember correctly, it's been a long time.

[TomXP411]

Yeah, putting a comma in a PRINT statement inserts a tab into the output. So the first program actually printed

ROB<tab>10<tab>2020<tab>TEXAS

If you're trying to create a list of comma delimited values, for example  to read back in for later use, then Scott's solution is correct: print a literal comma to the file. Or just print one item per line, like so:

PRINT#2, "ROB"

PRINT#2, "10"

and so on.

 

[Edmond D]

Thanks Rob for the correction of your code in the original post. The code works as expected. 

Quote

You'll probably want to write several separate pieces of data.  The comma will separate data for you in a way that INPUT# knows how to read back in.  

100 OPEN 2,8,2,"0:MY-NEW-FILE,SEQ,W"
105 CO$ = "," 
110 PRINT#2, "ROB"; CO$; "10"; CO$; "2020"; CO$; "TEXAS"
120 CLOSE 2

The CO$ inserts actual commas into the SEQ file, so we can read them back in individually.  Otherwise INPUT# would treat the thing as one long line.



 

Yes that worked correctly:



Likewise the read code worked once I gave it the proper SEQ file name. ?

regards,

Edmond

 

[rje]

You're welcome.

And thank you review team!  It's been decades since I did any file ops on Commodore equipment.

 

Note that there's an "input pattern" required if you're expecting to have null values in the data stream -- I can't quite remember it, but I think it involves injecting a chr$(0) into the input to safeguard against it.

 

[TomXP411]

1 hour ago, rje said:

You're welcome.



And thank you review team!  It's been decades since I did any file ops on Commodore equipment.



 



Note that there's an "input pattern" required if you're expecting to have null values in the data stream -- I can't quite remember it, but I think it involves injecting a chr$(0) into the input to safeguard against it.

So the issue with CHR$(0) and NULL is a problematic one. 

Writing a zero out to disk works fine: PRINT#8, CHR$(0);

However, reading a Zero byte from disk with the GET command will actually return a Zero Length String, aka "". So, because we obviously need file I/O in BASIC to be even slower, you have to check every read against "" when reading binary data. So the pattern goes like this:



100 OPEN 8,8,8,"MyFile,S,R"

110 A=0

120 GET#8, A$

130 IF A$<>"" THEN A=ASC(A$)

140 IF ST <> 0 THEN 200

150 do things 

160 GOTO 110

200 check command channel for errors

250 CLOSE 8

The critical part is lines 110-130. This starts A with a value of zero, so when we get to the IF statement, we already have the null value handled. The IF sets A to the value of the character read for non-null values, and then we get to to the core of the program at 150. 

Line 140 is just the standard EOF check, which diverts to 200 to check the disk status and close the file. You really want to read the command channel in line 200 to make sure that you didn't get some sort of error on the last GET before closing the file. 

I feel like this might be a good time to sit down and do some proper tutorials for disk I/O, covering basic I/O, error handling, and the Position (or seek) command. 

 

 

[SlithyMatt]

1 hour ago, TomXP411 said:

I feel like this might be a good time to sit down and do some proper tutorials for disk I/O, covering basic I/O, error handling, and the Position (or seek) command.

I plan on making one for assembly development as soon as that kernal code is stable and fully functioning in the emulator. Unfortunately, progress on that has been stalled for many months.