BASIC READ DATA question

[Justin Payne]

I've typed in a program, "Flight of the BumbleBee, from SoftSide Magazine #38 (https://archive.org/stream/softside-magazine-38/SoftSide_38_Vol_5-02_1981-11_Music_in_the_Micro#page/n28/mode/1up). I've loaded it in a few emulators but all seem to work relatively well but right now I have a specific question about READ command. Here is the line in the code.

19999 SOUND 0,144,10,8:COLOR 1:PLOT 15,7:RESTORE:FOR Z=1 TO 64:READ X:NEXT Z:TRAP 19999:SOUND 0,0,0,0

 

Nowhere in the program do they use X. They just seem to be reading it from the DATA lines. Can someone explain why they would do this and what might I be missing?

Edited May 30, 2015 by Justin Payne

[Grevle]

Thats a kinda weird line it seems. before the read the is a "restore" command the restore command has no specified line to restore so then i belive it restores to the first data line in the program.Then there is trap 19999. Trap is command to trap a error to the line 19999. Maybe the trap command has something to do with the read x command to do. but im not sure.

 

maybe it some kind of delay routine ?

[+JAC!]

I think the fact that the program is ported over to different platforms is the key to the question above. The code aims at skipping the inital 64 DATA bytes when the game loop restarts. My take is that the person who coded the Atari port was not aware that the ATARI BASIC "RESTORE" supports restoring to a specific line. From what I remember not all BASICs on the different platforms supported that but only supported restoring to the first DATA line in the whole program.

Edited May 30, 2015 by JAC!

[Justin Payne]

OK, I think I know what is happening. This line happens at the end of the song. When this happens, the bee is placed on top of the beehive and a final note is played that happens with...

SOUND 0,144,10,8:COLOR 1:PLOT 15,7

Then he set the data pointer back to the start and skips of the data where he redefines the character set to make character graphics (the first 64 bytes), such as the bee. This places the pointer at the start of the notes. The TRAP is probably just good programming to catch any bad data.

:RESTORE:FOR Z=1 TO 64:READ X:NEXT Z:TRAP 19999

Finally, he turns the sound off and then it all starts over.

:SOUND 0,0,0,0

Cool! Thanks for talking through all of this.

 

I'd like to put this up on AtariMania but I should probably post it here first for you guys to try on real machines because I get strange issues with the character set each time I run it. Sometimes it looks mostly right and other the characters are completely garbage. I'll have to do further debugging.

[Justin Payne]

My take is that the person who coded the Atari port was not aware that the ATARI BASIC "RESTORE" supports restoring to a specific line.

I tried removing that loop and setting RESTORE 1040, which is just after the new character set. Title screen had some title text but also with a bunch of garbage. When I killed the program and tried to rerun it, black screen.

Well, for some reason, that loop is useful. So many things to figure out with this. I kinda like the fact that it's buggy. It gives me the opportunity not only learn what is going on but I actually have a task to complete.

[+JAC!]

The RESTORE 1040 works fine. But you have to be careful to RESET after stopping the program. Otherwise it'll always reserve 5 more pages from RAMTOP with line 30300. And since 5 is not exactly a multiple of 4, this will f..uck anything that has to do with Display List, fonts and PM graphics consequently at the 2nd run.

 

Here's a version without the unnecessary READS.

BEE.atr

 

I also fixed the line 130 to be what it probably should have been.

 

If you enter it as in the listing, the text/graphics is not correct as shown in the screen shot on the paper. Looks like the printer for the mag was not able to correctly print the control characters and turned them and the TAB character into (mutliple) spaces. As a consequence it is impossible to enter the line 130 as shown in the listing. It would be >120 characters.

Edited June 17, 2015 by JAC!

[Justin Payne]

Oooh. Nice find. I will review ASAP.
Thanks for tackling this.

 

Later that day...

 

So, I see what you're talking about by him reserving 5 pages but I have a couple questions about that.

1. Why does it have to be in multiple of 4? Byte boundary?
2. Does it start overwriting areas of memory because of questions 1?
3. Is BASIC, or his code, holding onto that reserved memory and not releasing it so it just grows and grows?
4. If #3 is correct, how would one clean that code up so that this issue wouldn't happen after multiple runs?

BTW: This will be covered in this months Player/Missile podcast and I'll make sure to give you credit for the fix. Sorry, but I can't send you a prize. Rob doesn't pay me.

Edited June 18, 2015 by Justin Payne

[+JAC!]

Preface

The ANTIC chip in the Atari is responsible for bringing all graphics data from the RAM/ROM into the GTIA chip. This includes display list, screen memory, and charset and player missile data. For all three the starting address from which the data is read can be specified. For every new frame, ANTIC starts at that memory address, fetches the data and increments its internal counter to read the next instruction/character/etc. Some registers for specifying are 16 bit wide (DL, SM) an can point to any address in the memory. Others are only or 8 bit wide (charset, PM) and can point to full pages, i.e. memory addresses that are multiples of 256. Consequently data for charset and PM must start at a page boundary. In addition the counters in ANTIC were kept small to same chip space. Hence they cannot count normally but only up to a certain value. Same is true for the logic that adds the counter value to the start address. As a result there are constraints where a charset can be located in memory:

 

- In graphics 0: At a 4 page = 1k boundary

- in graphics 1 and 1: At a 2 page = 512 bytes boundary.

 

What the coder wanted to achieve

As it a good practice on Ataris, the code work should on machines with different amounts of physical memory (400/800 with or without memory upgrades). This is different than on C64 for example where you exactly know how much RAM there is going to be on the consumer's machine. Hence you have to dynamically allocate RAM there where it is. This is done by decrementing RAMTOP (location 106) by the amount of pages you want to reserve and then issuing a GRAPHICS command. The Atari OS will move the display list and screen RAM "down" in memory, so it ends at PEEK(106)*256. The area beyond that is free for you. There you can copy the OS charset and modify it. Then you change the high byte pointer CHBAS at 756 to that page, so ANTIC fetches the charset data from there.

 

What the coder did wrong

Well, many things. I assume the whole program was converted over from another platform via trial and error. If I had done if back then, that would have been the reason.

 

10 TRAP 19999:GOSUB 30330

The trap should only be there right before the READ loop starts. Otherwise error occurring during initialization will cause BASIC to jump right into the main loop - with possibly totally uninitialized variables and memory. So it should be

195 TRAP 19999:REM WHEN DATA RUNS OUT

 

30330 POKE 106,PEEK(106)-5:RETURN

A graphics 0 charset requires 4 pages = 1k, not 5.

 

UC=256*(PEEK(106)+1):

Well, that is one way of fixing the above problem :-)

 

POKE 756,UC/255+2

Should of course be "/256". And this line is what actually causes the garbage at the 2nd start, not as I thought the "-5" since that is compensated by the "+1" above.

 

What the coder did right interestingly

The "+" in this line again indicates that the coder on the other hand did have some Atari detail know how. Or at least he did what I would have done :-) Here he sets the CHBAS point to the 2nd half of the GRAPHICS 0 charset. This has no effect on the GRAPHICS 0 line (ANTIC ignores the bits 0 and 1 there), but causes the graphics 1 lines to display the lowercase characters instead of the upper case characters.

 

Eplilog

Regarding question 3 and 4: There is not proper way of reserving memory other than this in BASIC. That is because there is no guaranteed "initialization" when just typing RUN. Hence you cannot distinguish if the program started with RUN, GOTO or even CONT. But since not too much memory is reserved in one run you have many tries before it will cause a problem. And I personally always pressed RESET all the time in these cases anyway.

 

The attached disk contains "BEENEW.BAS" ´with the fixes.

BEE.atr

Edited June 18, 2015 by JAC!