Need help with a printed BASIC program "limitation"

[TheRaven81]

So I'm a new owner of a previously owned 800 XL. Along with it came several issues of Antic(unfortunately without their disks). One issue was Volume 3, Number 4 from August 1984. The Game of the Month, Creepy Caverns, was printed in 2 parts for "the benefit of readers who have only 16K of RAM.", according to the instructions under "How to use the program with (minimum 32K) DOS systems". But the 800XL I have has 64K.

 

So how do I type this in if I don't have this limitation? I had first thought to just type them both in one after the other, but as I was looking at both listings I noticed they have some duplicate line numbers. I'm guessing though that if I just typed them both in, then there might be problems since there can be only one of a single line number. Typing one and then typing the other would overwrite the one before it. 

 

This is a huge shot in the dark, asking this question here. I don't exactly expect anyone to have an answer for me, but with me being a new user, any help I can get is appreciated.

Edited December 6, 2019 by TheRaven81

[mimo]

[mimo]

CREEPCAV.BAS

[TheRaven81]

1. As for what you highlighted, I was probably going to end up doing this once I was done typing them both in and saving them. But I was half under the impression that the program was only split for the sake of people with this limitation, and half hoping there would be another way besides creating and merging 2 files.  

2. I can't use that file, i don't have the fancy peripherals to take it from my PC to my 800XL. I could use it on Altirra, but that's no fun, and just ends up neglecting the use of the Atari hardware.

[drpeter]

If you're not going to check your typing using the TYPO system, you can just type in both listings together, omitting the lines 5050 and 5060 from Listing 1 and 5000, 5095, 5096 from Listing 2

[TheRaven81]

Oh. 

*facepalm*

That makes a lot of sense. Those are the lines the article says to omit when combining the 2 files. I don't know how/why my brain didn't put that together. Thank you. That will be a lot easier.

[pmgraphics]

On 12/6/2019 at 6:11 AM, mimo said:

CREEPCAV.BAS 12.23 kB · 16 downloads

this file has something strange on line 4410.

 

[Rybags]

Using logic to determine what color to use is OK (though was it intended in the listing?) - but that PLOT at the end looks to have some corruption in the Y parameter.

[pmgraphics]

I looked up the original listing and fixed the last plot statement--PLOT 14,23. I'm not sure what it did. I played the game through with the corrupt statement and with the corrected statement and it was all the same.

[_The Doctor__]

will the minor corrections be uploaded here for all to download or shall we all make the same fixes as they are written about?

[pmgraphics]

13 minutes ago, _The Doctor__ said:

will the minor corrections be uploaded here for all to download or shall we all make the same fixes as they are written about?

I'm not the source of the original .bas file, thus I just posted the correction. I noticed no difference in game play with the correction. I do not know how to make a .bas file that I originally downloaded from mimo's link in this thread. My corrected version is saved to one of my ATR files that contains several other programs.

[Atari_Ace]

I find such data corruption interesting:  Line 4410 can be found at offset $1eea in the file, which hex dumps as follows:

  1ee0  0e 40 06 00 00 00 00 15-a5 16 3a 11 5d 12 03 2b   .@........:.]..+
  1ef0  28 8b 2c 24 0e 41 01 86-00 00 00 14 1e 2c cb 12   (.,$.A.......,..
  1f00  0e 40 23 00 00 00 00 14-2d 03 2b 28 8a 2c 24 0e   .@#.....-.+(.,$.
  1f10  41 01 87 00 00 00 14 3f-2c 0e 40 11 00 00 00 00   A......?,.@.....
  1f20  12 0e 40 23 00 00 00 00-14 4b 03 9e 24 0e 41 01   ..@#.....K..$.A.
  1f30  89 00 00 00 14 5d 2c 0e-40 14 00 00 00 00 12 0e   .....],.@.......
  1f40  0c b5 7d 00 00 00 16 3c-11 6b 25 36 bf 2d ce 25   ..}....<.k%6.-.%

Constants in Atari BASIC start with 0e, followed by a biased exponent ($40 is zero), followed by the BCD digits, so 14 = "0e 40 14 00 00 00 00". "0e 0c b5 7d 00 00 00" is the whacky number, which isn't even a valid floating point constant (you can't have hex values a-f in the BCD digits).  We can change those 3 bytes to "40 23 00" to repair it.

 

The Antic v3n4 disk is in the Atari 8bit Preservation project and that one has the same corruption.  On that disk, those bytes come from the first three bytes of sector 537.  It almost looks like the end of the last sector is bleeding into the beginning of that sector (well, the $7d at least).  It could just be a random corruption, though.

 

BTW, line 10 is also different from that disk and the bas file attached here.  It has MO(N,5) in the DIM statement (which matches the printed listing), whereas this file has MON(P,5).  Since P>N, this typo has no effect other than allocating more memory.

 

So here's the file from the preservation disk with the patch above applied.

CREEPCAV.BAS