Data Lines in Basic Listings… ?

[+AtariPhreak]

I remember inputting what seemed like an endless series of data lines when typing in things from the atari magazines back in the day. 

 

I recall going through the basic listing and being able to identity everything the program did with the regular basic lines, but never really knew what the DATA statements were all about.

 

Cursory googling says that it has something to do with validation of the basic lines? Could someone explain how this worked? Is this similar to a hash comparison?

[Panther]

I recall that some typed entries did have checksums to validate the input, but most of the time it was either character or graphics data, and sometimes assembly code.

 

[Houdini]

48 minutes ago, AtariPhreak said:

I remember inputting what seemed like an endless series of data lines when typing in things from the atari magazines back in the day. 

 

I recall going through the basic listing and being able to identity everything the program did with the regular basic lines, but never really knew what the DATA statements were all about.

 

Cursory googling says that it has something to do with validation of the basic lines? Could someone explain how this worked? Is this similar to a hash comparison?

DATA statements are just that, a large string of data. Programs can use them any number of ways. For example, they could be character graphics, machine language subroutines, locations of things (such as in an adventure game) etc... Somewhere in the program will be a READ statement(s) and probably a RESTORE statement as well. These can clue you in as to what the program is going to do with the data. RESTORE tells the computer what line of data to start reading from. And READ is just that, read the data sequentially. 

 

You can see an example of this here:

 

In this example the computer is READing the values of the DATA statement and POKEing them into memory. These are configuration values for the Happy drive. After it is finished doing so, the USR function tells the computer to jump into the OS and send the values to the Happy controller.

Edited July 4 by Houdini

[scitari]

Here is a brief introduction to the checksum programs that were used to validate all the data statements. It was so easy to make typos typing those things in.

[Rybags]

Checksum for program entry was usually independent of the program content itself.

From memory, Compute! had one that generated a 2-character code and displayed it when each line was entered - or maybe you called it and a listing was generated?

 

Some people do programs with checksums embedded inside the data or calculated from it but that's pretty rare.

Checksums have the advantage of being simple to calculate but big disadvantage in that they won't detect simple errors like swapped entries.

[+AtariPhreak]

thanks guys.. makes sense.. 

[Rybags]

I checked a Compute! archive and yes, the program generated a 2 character checksum.

I suspect this is generated against the actual characters the user enters so might be different if you use abbreviations or different spacing.

Might see if I can dig up the actual program, the issue I checked had a listing around 1986 and I seem to remember the checksum program itself was sometime around 1983-5.

[pcrow]

7 hours ago, Rybags said:

I checked a Compute! archive and yes, the program generated a 2 character checksum.

I suspect this is generated against the actual characters the user enters so might be different if you use abbreviations or different spacing.

Might see if I can dig up the actual program, the issue I checked had a listing around 1986 and I seem to remember the checksum program itself was sometime around 1983-5.

Atari BASIC is tokenized, so it doesn't make any difference if you put in random spaces or use abbreviations.  There are exceptions, as "PRINT" and "?" are separate tokens, and DATA lines are stored like strings with any spaces as typed.  Having a checksum is particularly useful if there are lots of DATA statements with binary code for use with USR calls, as any typo could crash the program hard.  I haven't looked at the particular program you're referencing, though.

[Rybags]

OK, theory about input buffer - I think it's right actually.

It looks to ignore spaces but will generate a different checksum if you do certain things such as enter statements abbreviated or have leading zeros before constants (a quick look at the code, I think it's just doing a checksum of the raw input buffer data)

 

e.g. 330 GRAPHICS 17 : GOSUB 20 should generate GL

but you can fairly easily enter the line such that the exact stored line is generated but different checksum.

Also, you can change stuff around and get the same result, e.g. 330 GOSUB 17 : GRAPHICS 20

 

Here is the program:

 

100 GRAPHICS 0
110 FOR I=1536 TO 1700:READ A:POKE I,A:C
K=CK+A:NEXT I
120 IF CK<>19072 THEN ? "ERROR IN DA"
130 A=USR(1536)
140 ? :? "AUTOMATIC PROOFREADER NOW"
150 END
1536 DATA 104, 160, 0, 185, 26, 3
1542 DATA 201, 69, 240, 7, 200, 200
1548 DATA 192, 34, 208, 243, 96, 200
1554 DATA 169, 74, 153, 26, 3, 200
1560 DATA 169, 6, 153, 26, 3, 162
1566 DATA 0, 189, 0, 228, 157, 74
1572 DATA 6, 232, 224, 16, 208, 245
1578 DATA 169, 93, 141, 78, 6, 169
1584 DATA 6, 141, 79, 6, 24, 173
1590 DATA 4, 228, 105, 1, 141, 95
1596 DATA 6, 173, 5, 228, 105, 0
1602 DATA 141, 96, 6, 169, 0, 133
1608 DATA 203, 96, 247, 238, 125, 241
1614 DATA 93, 6, 244, 241, 115, 241
1620 DATA 124, 241, 76, 205, 238, 0
1626 DATA 0, 0, 0, 0, 32, 62
1632 DATA 246, 8, 201, 155, 240, 13
1638 DATA 201, 32, 240, 7, 72, 24
1644 DATA 101, 203, 133, 203, 104, 40
1650 DATA 96, 72, 152, 72, 138, 72
1656 DATA 160, 0, 169, 128, 145, 88
1662 DATA 200, 192, 40, 208, 249, 165
1668 DATA 203, 74, 74, 74, 74, 24
1674 DATA 105, 161, 160, 3, 145, 88
1680 DATA 165, 203, 41, 15, 24, 105
1686 DATA 161, 200, 145, 88, 169, 0
1692 DATA 133, 203, 104, 170, 104, 168
1698 DATA 104, 40, 96

 

Edited July 5 by Rybags

[+yetanothertroll]

6 hours ago, pcrow said:

Atari BASIC is tokenized, so it doesn't make any difference if you put in random spaces or use abbreviations.  There are exceptions, as "PRINT" and "?" are separate tokens, and DATA lines are stored like strings with any spaces as typed.  Having a checksum is particularly useful if there are lots of DATA statements with binary code for use with USR calls, as any typo could crash the program hard.  I haven't looked at the particular program you're referencing, though.

 

Has anyone ever tried using Fletcher? It's supposed to be a relatively quick and low overhead way to detect errors like transpositions that simpler checksums don't. It looks do-able even in smaller BASICs, since it doesn't look like it needs XOR or anything more 'exotic' than modulo. I haven't investigated whether you'd need full X=X-Y*INT(X/Y) or if you could get away with X=X-Y*(Y<=X)

 

https://en.wikipedia.org/wiki/Fletcher's_checksum#The_Fletcher_checksum

 

[thank you]

The COMPUTE! proofreader program IIRC only gave a two-capital-letter code... 26 * 26 = 676 possible checksums... collisions were very common even with dis-similar lines.

 

Still, way better than nothing, especially when it came to DATA statements.  Except when it wasn't

 

 

[Rybags]

More possible than that - it acts on screen codes and entering a program allows 255 possibilities (inverse ESC = Return, which can't be generated by a keystroke)

It's not meant to be foolproof - the leeway it does give makes it more useful since extra or omitted spaces don't affect it.

Generally the most common mistakes entering programs are messed up data or omitted statements which would be picked up - though entirely missed lines aren't.

[+CharlieChaplin]

What I would like to know, how can we speed-up the reading + initializing of Data lines in Atari Basic ?

Reason: I have dozens of Atari Basic programs in my collection, where initializing takes 30, 60, 90, 120 or even 180 seconds.

 

1) I have two programs as fast and slow initializing versions. The slow versions have data lines only (60-120 seconds init. time), whereas the fast versions have a few lines of added machine code (so-called "Hot Poker Sub" with only 2 seconds init. time). Could this code be used universally to speed-up init. of data lines -or- does it have to be patched for every Basic program ?

 

2) There are also versions of Basic listings where one version contains only data lines (slow init.) and another version contains machine code instead of data lines (fast init.). Are there programs available that can turn data lines into pure machine code (or do we have to do this manually)?

 

Attached you will find "Jump Ghost" as slow and fast version and "Mission X" as fast version - both fast versions do contain the Hot Poker Sub. Then there is "Supereversion" with data lines and with machine code.

 

It would be great, if I could have a universal routine (Hot Poker Sub) that inits data lines very fast or a tool that turn data lines into pure machine code (again for fast init of data lines)...

 

Jump_Ghost_fast.BAS Jump_Ghost_slow.BAS MISSION_x_fast.BAS SUPEREV1_data_lines.ATR SUPEREV2_machine_code.ATR

[Rybags]

I did a program I called HEXPOKE a long time ago, others have done similar.

It allows reading data into hex strings with or without spaces, so saves some memory to begin with and you call the asm routine to store the data values into Ram.

Result is a startup that can be reduced down to a few seconds rather than near a minute.

[Rybags]

March 1984 Compute! is where the utility was first published https://www.commodore.ca/gallery/magazines/compute/Compute-046-01.pdf

 

Not the best archive source, some of the issues are cut off well before the last page.