Read a text file in Atari Basic

[Champions_2002]

Could anybody point me in the right direction for a way to open a text file with ten names in the file to read by Atari Basic and then printed out, I have look at numerous books and cannot not find how to use OPEN # in atari basic, so any help in finding a book or article on this would br greatfull

[Graham Dearsley]

An example to open a file for output would be.

 

OPEN #2,8,0,"D:MYFILE.TXT"

 

You can replace the 8 for different open modes.

 

4=Input

12=Input/Output

9=Append

 

Do not open the same file for Output again unless you want to erase it !

 

You can send a record to your open file with.

 

PRINT #2;"NAME"

 

If you want tab spaces between your records replace the semicolon with a comma.

 

You use INPUT #2,A$ to read records.

 

[Graham Dearsley]

I think the book your looking for is The Atari BASIC Reference Manual.

 

[Champions_2002]

2 hours ago, Graham Dearsley said:

An example to open a file for output would be.

 

OPEN #2,8,0,"D:MYFILE.TXT"

 

You can replace the 8 for different open modes.

 

4=Input

12=Input/Output

9=Append

 

Do not open the same file for Output again unless you want to erase it !

 

You can send a record to your open file with.

 

PRINT #2;"NAME"

 

If you want tab spaces between your records replace the semicolon with a comma.

 

You use INPUT #2,A$ to read records.

 

Thank you for that 

[Graham Dearsley]

Glad that's what you wanted ?

[zzip]

I'll just add that the #2 is just a channel number,  I usually started with #1, and if I needed additional files open at the same time, then use #2, #3.   Also should add that open isn't just for files, you can open the serial port or screen editor and read/write to that.

[Graham Dearsley]

You can OPEN any device that has an entry in the device handler table, its held in RAM so it can be added to and the device letters and entry address for the built in devices are copied there at system boot or reset.

 

There is no D  device until you boot from a DOS disk, thats why you get non existent device errors if you forgot to boot DOS. 

 

DOS loads its file management system as device handler "D:" and adds it to the table.

 

Just thought i'd mention it ?

 

  

[newTIboyRob]

Can you open and add to a file in Atari Basic sans disk drive and sans DOS but on a 600xl, using the 410 tape recorder?  (I don't know what the device # for tape is?)

Edited September 10, 2023 by newTIboyRob

[Rybags]

Tape doesn't allow append.

Note PRINT #1, doesn't use tab characters, it uses spaces.  Though it does text justification as if tab stops were in place.

You can change the spacing in location 201.  Default value is 10.

 

[thorfdbg]

6 hours ago, newTIboyRob said:

Can you open and add to a file in Atari Basic sans disk drive and sans DOS but on a 600xl, using the 410 tape recorder?  (I don't know what the device # for tape is?)

AtariOS does not have device numbers. It has device characters, and the character for the tape recorder is C:. The number behind # is the channel you want to use, and channels 1 to 5 are available for you.

[TGB1718]

13 hours ago, newTIboyRob said:

I don't know what the device # for tape is?

The command in BASIC is :-

10 OPEN #1,4,0,"C:"

This will open the cassette for input, from this point on, you use #1 as the channel to read data from

i.e.

GET #1,A will read 1 byte from the cassette.

 

I hope you can see that as the cassette is not random access device, you cannot read/write like you can with a disk drive.

You really can't do the sort of things your trying with a cassette.

 

 

[+slx]

58 minutes ago, TGB1718 said:

I hope you can see that as the cassette is not random access device, you cannot read/write like you can with a disk drive.

You really can't do the sort of things your trying with a cassette.

 

 

If you need to write text entries to a cassette you should be able to store the data in a long string and then write the whole string to the cassette at once.

[Rybags]

Not sure PRINT # will work on long strings for output to C :

In the case it doesn't, a quick ML routine could be used - pass the ADR of the string and # of bytes to output and have it call CIO PUT CHARACTERS.

 

(could be wrong there, I know you definitely get problems using INPUT # such as truncated records and in any case I'm fairly sure you're limited to the length you can fetch)

[newTIboyRob]

Before I even attempt what you guys are saying, I will just tell you what I am trying to do.  As I only have the 410 and not a disk drive, and since I have the 600xl with its limited 16k, and since there aren't really any good spreadsheets usuable under 16K, and since I don't have, and at this stage, really don't want to resort to emulators and the like... you get the picture now, Gilligan's Island as primitive as can be....  I actually want to see if I can do the following under these primitive conditions. That will be the challenge and fun of things for me here, that is, if it is even possible:

 

I am writing my own really scaled down spreadsheet program since I can't find one under 16K so far in the past issues of Compute! and other books. When I say scaled down, I mean... really bare bones: I am just trying to store very limited data, we're talking, bits and pieces of 1 or 2 pages worth, in string variables, so the post of member slx above actually was amazingly very, very close to what I was trying for with this program.

 

So it would be like.... write a program in basic, let's call it ATARICALC. Then, instead of using READ and DATA statements, store the info in strings, as in the sums or subtraction totals and/or the concatenations of 2 columns and that's it.  No projections, no fancy formulas and advanced things you get with Speedcalc, Multiplan, etc...just basic 1st grade math here and string combinations say of 2 columns, so I thought this might actually be able to be done.

(I realize it would have TONS of limitations, e.g. with the input statements, e.g. if a mistake is made entering data you have to redo all... but I am aware of this and will try to be careful when inputting data.)

 

***** Then all I would want to do is store/write that stored string variable data to another, new file on tape, let's call that CALCDATA. This file's name would have to be set up within the ATARICALC main tape program file though, since we want to send the ATARICALC data to the CALCDATA file for retrieval, is that correct?

 

So, is all the above still possible?  It's way over my head, but I am learning this new language and trying to piece things together here, little by little. The Rome wasn't built in a day concept. I already at least have started to make the screen display of Visicalc with DRAWTO statements and the like, but I will stop it there if I can't proceed here.  

 

Your thoughts here?

Edited September 11, 2023 by newTIboyRob

[_The Doctor__]

a data matrix with sort is possible, as well as storing to tape, math function are always available you might need to keep track of what section of your string links to what in a another indexing string. It's more than possible, but for speed you would have to be very aware of where anything intensive is living and working. You may even toss some ml strings in there. Over write any setting or initialization data after it's done it's work.

you might get a few pages of data to work with, but not much

Edited September 11, 2023 by _The Doctor__

[newTIboyRob]

Does sound intricate though, Doc. What a mountain. Damn that 16K!  What I am most amazed at though is not one bare bones scaled down spreadsheet, ever, in any books or mags?  Everyone must have been more than satisfied with Visicalc, Speedcalc, Multiplan, etc.. those were all awesome.

Edited September 11, 2023 by newTIboyRob

[newTIboyRob]

Now for some irony... after tons and tons of searching, I actually found an electronic spreadsheet type in program buried in a magazine I wasn't even familiar with BITD. But there are 2 catches here:  1) It was written in Applesoft Basic   2) The version uses a disk drive and I can't tell if it would even work with Atari tape at all, if it would be too limiting with the 16K/ you'd need a disk drive to use this program or would be too hard to translate that over.

 

So let's just look at 1) for now:  With all the simulators and such today, is anyone aware of one where you can type in lines of a program written in one basic that can then be translated over to another machine's basic? I guess you'd call it a basic translator or interpreter  e.g.  HOME in Applesoft when entered becomes/shows as its Atari equivalent of PRINT CHR$(125)?     Does this exist? And would it be too difficult a concept to interweave in this type in program?

 

I can post the 5 page program (actually about 2.5 pages of actual typing) if anyone does care to see it.

 

Edited September 11, 2023 by newTIboyRob

[_The Doctor__]

our string handling methods are tailored towards limited memory however you will have to come up with a suitable array structure when converting from most BASIC dialects, or choose a cartridge based BASIC that is more compatible with some of them like Atari MicroSoft BASIC when using limited memory machines to get a quicker conversion done. It would be nice to go straight to Atari BASIC but sometimes it's helpful to use such methods on your way there.

[+CharlieChaplin]

If you want to add something...

ENTER"C:"

works in some simple way.

 

I also vaguely remember that there is some 128 with the Open command...

OPEN #1,128,0,"C:"

or something like that.

 

Both ENTER and OPEN (and the 128) were used in commercial Basic tape programs (e.g. by Microprose and others).

 

[Rybags]

The AUX2 value 128 is for short IRG.  So for creating a file it would be like OPEN #1,8,128,"C:"

In a lot of cases Basic won't be fast enough to provide data and keep the IRGs at minimum.

For reading, Basic will just about always be too slow to keep up.

But ML routines in these cases can be helpful.

[TGB1718]

14 hours ago, newTIboyRob said:

let's call that CALCDATA. This file's name would have to be set up within the ATARICALC main tape program file though,

The Cassette does not do filenames, there is a utility program that does allow this, but will eat some of your precious 16K.

You would need to keep track of what data is on what tape.

 

[pirx]

i'll repeat here @newTIboyRob - you'll be much better off by treating atari basic as THE spreadsheet. just declare a 2D variable with `DIM A(10,10)`. populate it and perform calculations.

entering formulas as atari basic commands will be similarly laborious as if in a real spreadsheet.

 

The only real (mental) difference is that you do not have the WYSIWYG  editor, it will be more like writing in LaTeX than in Word.

[newTIboyRob]

This is interesting. Pirx, I was actually independently doing what you just said!  Also throwing in some cool things like concatenating strings in the atypical way Atari basic does it, (instead of the other basics which is the much easier way of A$=B$+C$)  The trickiest part of things for me here  is trying to get what ever data's been stored in the string variables in the file saved as text files to tape.  I have 0 experience with that, and only a very small idea of how it actually works, the theory behind it, etc.. and then throwing in these I/O commands, the sending and retrieving info from tape.. I find these hard concepts at this point, but I do have a general idea and I'm trying. 

 

TBG1718, that was essential to know, as I thought you could do that as you can on the VIC-20 tape based system.  Ok, that clears things up a bit, as I was used to doing headers and the like. But, yes, I could just keep good documentation, as you are suggesting, so I can actually know what is on what tape and where.   Just curious.. you mentioned the utility program that does allow this... do you know what it's called, or perhaps a link to that?   Also interested to know if you happen to know about just how much of that 16K would be eaten?

 

Maybe someone knows the answer to this too:

 

Speaking of making tapes, let's say you make a tape on a separate tape recorder, e.g. this great Radio Shack CCR-81 recorder I have. The #'s as we know start at 000... then you take that tape out and put it into the 410 or even another system's recorder.  Are those digits kind of a universal thing, in that 000 on the CCR-81 will correspond directly/exactly with the tape counter on the 410?  (not synchronous, but just I guess a better more accurate word is "corresponding"?)  I've always wondered that.

 

[sanny]

I think the tape counters are specific to each tape drive. You might get into the ball park of your data with similar numbers, but expect some offset. Use a smaller counter on a foreign drive.

[dmsc]

Hi!

2 hours ago, newTIboyRob said:

This is interesting. Pirx, I was actually independently doing what you just said!  Also throwing in some cool things like concatenating strings in the atypical way Atari basic does it, (instead of the other basics which is the much easier way of A$=B$+C$)  The trickiest part of things for me here  is trying to get what ever data's been stored in the string variables in the file saved as text files to tape.  I have 0 experience with that, and only a very small idea of how it actually works, the theory behind it, etc.. and then throwing in these I/O commands, the sending

and retrieving info from tape.. I find these hard concepts at this point, but I do have a general idea and I'm trying. 

 

I think you still don't get what what Pirx is saying: Atari BASIC is your spreadsheet. BASIC is older than spreadsheets, and is more powerful - if somewhat more difficult to use.

 

Suppose you want to add two list of numbers. Simply, write those as DATA:

 

100 DATA 123, 456, 789, 100, 200, 300
200 DATA 654, 321, 987,  10,  20,  30

 

Now, you write your "formula":

 

10 NUM = 6 : DIM A(NUM)
20 RESTORE 100
30 FOR I=1 TO NUM: READ X: A(I) = X : NEXT I
40 RESTORE 200
50 FOR I=1 TO NUM: READ X: A(I) = A(I) + X : NEXT I
60 FOR I=1 TO NUM: PRINT A(I), : NEXT I
70 STOP

 

Now, you save tour program with "CSAVE", and load with "CLOAD". And to change which numbers to add, simply edit the "DATA" lines.

 

BASIC is really meant to be used this way in this early computers.

 

Have Fun!