storing string data, both kinds, as program line numbers. Possible?

[newTIboyRob]

This one might sound a bit odd, but I was just curious. 

 

So I know the usual/very efficient way to enter data in a program is through READ DATA statement combos, as opposed to INPUT statements, where the data is stored only temporarily in a string "cloud' and then otherwise disappears after a program is RUN. And also the typical way to saving data for future use is the sequential file concept, say writing the info to disk.

 

But what if you have a program that will be saving to tape, and instead of using READ DATA statements, it is calling for data to be entered through INPUT statements, one alphanumeric and the other numeric only. If you do a printout, obviously you would have that data you had previously inputted in the strings to see for the future, but just wondering if the entered string data could be saved as a line number back into the program as a line number for reference? 

 

Thus:

 

5 PRINT CHR$(125)

10 DIM N$ (20), S(5)

20 PRINT "NAME: ";:INPUT N$:PRINT "SCORE: ";:INPUT S

 

(when RUN say you entered JOHN and 10)

 

so instead of:

 

NAME ?   JOHN

SCORE ?  10

 

only screen printing those above, the computer is redirected to actually store that inputted data in, say a REM statement, (so if you didn't print out the file but still wanted to save that inputted data as a line number within the program without the sequential file concept, it would just the line back in the program for you that way you wouldn't have to retype the info as REM statements), and at LIST you'd see

 

30 REM JOHN, 10 

 

as part of the program. I was just thinking if you had a say 20 of those combos, you would just have to be typing all that data in again, (hence I'm aware why READ DATA is the better choice) but, again I wondered if the computer could be told automatically to just put that stored string information back into line numbers, because that would be handy.   Maybe it couldn't be done and that's why the sequential file and READ DATA combos came about? 

Could it be done?  Anyone ever tried something like this?   

 

[danwinslow]

Yes, it's possible I think. The trick relies on printing to the BASIC screen with line numbers and generating returns...I think there's a bit more to it than that, but yes I have seen it in the past.

[jindroush]

Here is how it's done
https://www.atariarchives.org/creativeatari/SelfModifying_Programs.php

[newTIboyRob]

thanks you both, I will see if I can apply it in my program.

[TGB1718]

Have a look at this, I wrote this in 1986, I think it was published in a magazine, essentially it adds data statements to the 

existing program, the program starts at line 32700, so your data statements can be anywhere below that, it can

take input from the keyboard, pressing the space key put the comma between numbers, or you can input from

Disk or Cassette.

 

Have a look, it shows how to automate input.

 

When you were finished, you LISTED the new lines to Cassette or Disk omitting the program lines. 

AUTODA.BAS

[newTIboyRob]

Wow, is that really cool, TGB1718. You've done it ... again!  I clicked on and downloaded that, but it wouldn't run in Adobe, is that because it was a .BAS file?  What can we use to open and view that?

 

P.S.  Those other 2 programs in the jindroush link above are really cool as well. I tried the first one, and indeed, when you LIST, it replaced (essentially erased) the contents of the program's original lines 110-150 and now filled those lines 110-150 with the contents of original lines 30 through 70 with REM statements for lines 110 through 160.  Halloween comes early!   Didn't try program 2, but what a really practical use of this concept, storing up to 100 phone numbers in REM statements.  Ultra cool!!

[Rybags]

I don't get what you're attempting with line numbers.

Line numbers are stored as 16 bit binary with limit 0-32767 in the program.

They are sorted in memory low to high regardless of what order they get entered.

 

So for storing anything they're not all that useful.  I guess you could use reserve line numbers above a certain range, e.g. 2000 onwards and use certain line numbers which could then be chained through to extract some data.

2000-32767 would give a range if 30767 to store integer constants.  But then you'd need code to chain through it to extract the data.

Lines of Basic code have a built in overhead though, so it's not a mega efficient way to store things.

You'd probably do better by just embedding data direct into strings.  But a problem there is you can't easily generate CHR$(155) which is the Return key - you have to generate it with extra statements.

[TGB1718]

10 hours ago, newTIboyRob said:

What can we use to open and view that?

Have you not seen this, a wonderful piece of code

https://rossumur.github.io/esp_8_bit/atr_image_explorer.htm

 

Just drag/drop any Atari known type of file where is says "DRAG FILES HERE", it will display

the file contents, you can the save as .LST if you want, but remember the the listing cannot be 

seen correctly using normal text viewers due to the EOL character Atari uses, also the special characters

cannot be seen.

 

You can also drop .ATR files into it and it will show all the files on the disk image, clicking on any file

and it will be decoded if it's a known file type.

 

However, there's another nice program you may not be aware of "MEMOPAD.EXE", after listing the file,

load it into MEMOPAD and it's ATARI text as you know and love it.

 

EDIT: Should have said, you can also drag/drop .BAS files onto MEMOPAD and it will display them too.

 

 

MemoPad.exe

Edited September 23, 2023 by TGB1718

[newTIboyRob]

So I'm still playing around with this, so this time I will give a scenario. It's one way I can describe what I am wondering, though the situation I mention I'm aware is somewhat far fetched. The idea here is that maybe something similar could be applied in other uses, so just indulge me here:

 

Let's say your friend comes over and you are talking about possible names for who to invite to a big party... but he doesn't have the names written down, he is just throwing names at you. You are sitting at the Atari, ready to input info at his command. So he says  "Mary, John, Jimmy" etc , so you type those in, and then since you need to know how many beers or whatever each person is likely to bring to this event, (looking for just numbers)   he is telling you... Mary will bring like 12, John brings Vodka, so 0, Jimmy 24... and then the list of names and numbers continues on and on for quite a bit, ending with a large bunch of data.

 

Now, again, disregarding the better way of the READ DATA concept, and instead trying to use 2 INPUT statements per line, entered on the same line, one alpha, one numeric only, data for both stored in Strings. So as you go down the list, you have something like this:

 

Mary    12

John      0

Jimmy  24

 

 

Now you get to like 1000 names and # combinations (yes, a huge party!) and don't want to write down what you had brainstormed together,  but you want all the data that was inputted and held in the strings to be actually inserted automatically by the computer into line numbers since you are not printing to paper and so you don't have to write all 2000 pieces of data down yourself. You just want to have and save a record of all the preliminary data you just typed in the computer with the computer, not you, doing the tallying and the computer, not you, essentially writing the info you had just typed in down.  I can see using the REM statements with READ DATA, but I just don't know if STRING data contents can be first tabulated by the computer which then can, itself, be told to put the data you had inputted into new line numbers  so that when you save the program again and return to it, the names and numbers appear within the program lines, say as:

 

990  REM Mary 12

992  REM John 0 

994  REM Jimmy 24

 

and it's not:  990 REM A$, A   992  REM B$, B    994 REM C$, C   etc... it is the data you entered that is saved in the line numbers

                      

 

I realize this may sound a bit odd, but I could think of other uses for this kind of thing, like if you had a lot of names and numbers you wanted to save but not waste ribbon ink printing, say if it was a work in progress that you would come back to from time to time.  I don't know if it is even possible with the string dumps into line numbers, but it would be kind of fun and certainly useful.  If not, I guess it's only READ DATA and REM statements.

Certainly a puzzle!

[TGB1718]

Yes, easy to do, the Atari will allow inserting lines into a running program, I did post an example,

data statements can contain strings and numbers, have look at this little example

 

10 DATA JIM,10,MARY,30,END,0
20 DIM A$(10)
30 READ A$:IF A$="END" THEN END
35 READ A
40 ? A$;"=";A:GOTO 30

 

 

[Rybags]

Another thing to note re memory usage.

Not stacking stuff into lines or having the max amount of data in one line can be very wasteful.

Each program line has overhead, so the idea of using one string per line then associating the line number with it would almost certainly cost more in terms of Ram used.

[TGB1718]

Try this, could do with some formatting and maybe more error checking, not pretty,but it does what you need.

As @Rybags says, would be better if there was more data per line, so maybe put the input(s) into a string

which you could slice up when saving and the number obviously into an array. 

 

If you use Altirra, you can copy/paste this into it, also attached the .BAS and listing.

 

EDIT: have to laugh, I notice the "C:"  is turned into a smiley when listed here

 

 

10 DIM FILE$(40),A$(20),C$(1):LSTART=10000:LEND=30000:C$=CHR$(125)
20 ? C$:? "1. ENTER NEW DATA":? "2. SAVE NEW DATA TO DEVICE"
25 ? "3. PRINT DATA":? "4. LOAD DATA FROM DEVICE":? "5. END"
30 INPUT ANS:IF ANS>5 OR ANS<=0 THEN 20
40 ON ANS GOSUB 4000,5000,6000,7000,1000
50 GOTO 20
1000 END 
4000 REM ENTER DATA
4010 LEND=LSTART
4020 ? C$:? "ENTER NAME ":INPUT A$
4030 ? "ENTER AMOUNT ":INPUT A
4040 ? C$:POSITION 2,4:? LEND;" DATA ";A$;",";A
4050 POSITION 2,7:? "CONT"
4060 POSITION 2,0:POKE 842,13:STOP 
4070 POKE 842,12
4075 IF A$="END" THEN RETURN 
4080 LEND=LEND+10:GOTO 4020
5000 REM SAVE LINES ROUTINE
5010 ? CHR$(125):POSITION 2,4
5020 ? "ENTER FILESPEC TO SAVE":? "  E.G. 😄 OR D1:FNAME.DAT"
5030 INPUT FILE$:IF FILE$="" THEN RETURN 
5040 POSITION 2,14
5050 ? "LIST ";CHR$(34);FILE$;CHR$(34);",";LSTART;",";LEND
5060 POSITION 2,18:? "CONT"
5070 POSITION 2,9:POKE 842,13:STOP 
5080 POKE 842,12
5090 ? "LIST COMPLETE"
5095 GOSUB 6500
5100 RETURN 
6000 REM PRINT DATA
6010 ? C$
6020 RESTORE :COUNT=0:TRAP 6200
6030 READ A$,A
6040 IF A$="END" THEN 6110
6050 ? A$,A
6060 COUNT=COUNT+1:IF COUNT<>20 THEN 6030
6070 COUNT=0:GOSUB 6500
6100 GOTO 6030
6110 GOSUB 6500
6130 RETURN 
6200 IF COUNT=0 THEN ? "ERROR, NO DATA!!!"
6210 GOSUB 6500
6220 RETURN 
6499 REM WAIT FOR KEY PRESS
6500 POKE 764,255
6510 ? "PRESS ANY KEY TO CONTINUE..."
6520 IF PEEK(764)=255 THEN 6520
6530 POKE 764,255:RETURN 
7000 ? C$
7010 ? "ENTER FILESPEC TO LOAD"
7020 ? "E.G. 😄 OR D:FILENAME.LST":? 
7030 INPUT FILE$:IF FILE$="" THEN RETURN 
7035 ? C$:POSITION 2,4:? "ENTER ";FILE$
7040 POSITION 2,7:? "CONT":POSITION 2,0:POKE 842,13:STOP 
7045 POKE 842,12
7050 ? "DATA LOADED"
7060 GOSUB 6500
7070 RETURN 

DATAIN.BAS DATAIN.SRC

Edited September 25, 2023 by TGB1718

[pirx]

a bit different concept but equally silly - for 10 liners competition a few years ago I was fighting to cram sprite data into the basic program and came up with this ingenious idea - 

27367 REM OIiHiiHiug97et77wtgf8x*Fifxwghgigsi___SPRITE_DATA___

keeping data after REM statement is not that innovative, but the line number and REM token were also part of the data itself. 

It did not work out as good as I envisioned, some unwanted artifacts were visible and I optimized the rest so I could save the data in a text variable, but I just wanted to say that using line numbers as meaningful data is somewhat possible ;] 

[newTIboyRob]

Wow, it seems that my crazy idea wasn't so crazy after all then!   It's pretty much doable.   @TGB1718  and @Rybags  , excellent, as always.  TGB, once I solve the SDrive Max or which-should-I-get gadget dilemma I got going on my other thread, I will definitely try what you mentioned as your not so pretty program.  (Looks pretty to me!)    ... but no sense of typing it in and playing if I can't save it due to my 410's ill-timed death.  😆

[newTIboyRob]

@TGB1718  in the the mean time though, your recent little program used READ DATA statements. I've been trying to use the INPUT statement concept to store the alphanumeric and the numeric-only data put back/converted into line numbers. Still possible?

[TGB1718]

48 minutes ago, newTIboyRob said:

I've been trying to use the INPUT statement concept to store the alphanumeric and the numeric-only data put back/converted into line numbers. Still possible?

Not quite sure what you mean, can you elaborate ?

 

Almost anything is do-able

 

 

Edited September 25, 2023 by TGB1718

[_The Doctor__]

Input information can be printed to screen and stored using the self modifying BASIC line method.

?CHR$(A) takes a number and prints the atascii character it represents.

VAL(A$) and such variants switch alpha numbers to actual numeric

most of what you need to know about string manipulations can be found in the short page or two in the following link...

http://ftp.pigwa.net/stuff/collections/atari_forever/www/www.cyberroach.com-atari/analog/an11/strings.htm

[newTIboyRob]

Thanks, Doc. Will try playing with more of the above after I buy a means of data storage and retrieval

[dmsc]

Hi!

13 hours ago, newTIboyRob said:

So I'm still playing around with this, so this time I will give a scenario. It's one way I can describe what I am wondering, though the situation I mention I'm aware is somewhat far fetched. The idea here is that maybe something similar could be applied in other uses, so just indulge me here:

 

Let's say your friend comes over and you are talking about possible names for who to invite to a big party... but he doesn't have the names written down, he is just throwing names at you. You are sitting at the Atari, ready to input info at his command. So he says  "Mary, John, Jimmy" etc , so you type those in, and then since you need to know how many beers or whatever each person is likely to bring to this event, (looking for just numbers)   he is telling you... Mary will bring like 12, John brings Vodka, so 0, Jimmy 24... and then the list of names and numbers continues on and on for quite a bit, ending with a large bunch of data.

 

Now, again, disregarding the better way of the READ DATA concept, and instead trying to use 2 INPUT statements per line, entered on the same line, one alpha, one numeric only, data for both stored in Strings. So as you go down the list, you have something like this:

 

Mary    12

John      0

Jimmy  24

 

 

Now you get to like 1000 names and # combinations (yes, a huge party!) and don't want to write down what you had brainstormed together,  but you want all the data that was inputted and held in the strings to be actually inserted automatically by the computer into line numbers since you are not printing to paper and so you don't have to write all 2000 pieces of data down yourself. You just want to have and save a record of all the preliminary data you just typed in the computer with the computer, not you, doing the tallying and the computer, not you, essentially writing the info you had just typed in down.  I can see using the REM statements with READ DATA, but I just don't know if STRING data contents can be first tabulated by the computer which then can, itself, be told to put the data you had inputted into new line numbers  so that when you save the program again and return to it, the names and numbers appear within the program lines, say as:

 

What I don't understand is... why do you want the data as part of the program??? Normally, it is more efficient to store your data in a different file, that you can load and append, specially if you have a disk drive:

 

10 DIM N$(100) : R=1
15 REM OPEN FILE FOR APPEND
20 TRAP 70 : OPEN #1,9,0,"D:LIST.DAT"
30 ? "Input NUMBER , NAME, press RETURN to end:"
40 TRAP 80 : ? "Record "; R;: INPUT NUM,N$
50 TRAP 70 : PRINT #1, NUM; "," ; N$
60 R=R+1 : GOTO 40
65 REM ERROR ON WRITE
70 ? "ERROR WRITING FILE:"; PEEK(195) : CLOSE #1 : END
75 REM END OF INPUT, CLOSE FILE
80 TRAP 70: CLOSE #1
85 REM READ DATA BACK
90 TRAP 130: R=1 : OPEN #1,4,0,"D:LIST.DAT"
100 TRAP 140: INPUT #1,NUM,N$
110 ? "Record "; R; ": "; N$ , NUM
120 R=R+1 : GOTO 100
125 REM ERROR ON READ
130 ? "ERROR READING FILE:"; PEEK(195) : CLOSE #1 : END
135 REM ALL OK
140 ? "ALL OK" : CLOSE #1 : END

 

The above program will allow you to enter numbers and names, stores them to disk, and then lists all the names again.

 

Using "C:" for the cassette is more difficult, as you can't append to a file, but you can save and load a list in the same way.

 

Have Fun!

[newTIboyRob]

My thought about including the data as part of the program is that way when you save it and return to it, you can see what those values were, so if/when you re-enter things, you have a record of it. (Same as your idea of a sequential file, but stored within the main program's program lines, not in an additional file.)

 

It would basically be what TGB first showed in his little program using READ DATA and REM, whereas I was trying to use the INPUT statement with the info stored in the strings put back into the line numbers to achieve the same result. When I have a way to test it out and save it to a device I will have more, but you've given me some great food for thought in the mean time, thank you.

[newTIboyRob]

Just mentioning here that I don't have a disk drive and it's true that appending to a file is not possible with cassette. But as I say, just for kicks, Im trying here not to store the data in a different file, but rather back in the same file's line numbers. Again, I know that this is easily accomplished using standard READ DATA and REM statements, but I have a program I'm writing that appears in a spreadsheet-like format, so I would like to see if I could use actual INPUT statement and strings for the data which would ultimately be stored back into line numbers without READ DATA.  I realize this appears silly, but it isn't to me.

 

Dmsc, I like that last program you posted above and will try it as well when I get a new storage device next week.