Animating images in Applesoft Basic

3 posts / 0 new
Last post
Offline
Last seen: 8 hours 50 min ago
Joined: Sep 28 2024 - 12:15
Posts: 12
Animating images in Applesoft Basic

Hello, per the title, I have this little project where I'd like to animate five 280x192 HGR images with a utility I found from Beagle Bros, Extra-K. It comes with a program called Extra.Screens that utilizes 128k of memory from the IIE and the Extended 80 column card. Attached is the manual with the needed info (pages 26 to ~35).

https://www.applefritter.com/files/2025/04/13/Extra-K.pdf

 

I understand that I can use &SAVE to move my .BIN HGR files to aux memory, and the use &LOAD to display them with HGR and HGR2. However, I can't get this to work. So far I have:

10 HOME

20 PRINT CHR$(4)"BRUN EXTRA.SCREENS"

30 &"H", AT2, SAVE "X1.BIN"

40 &"H", AT2, SAVE "X2.BIN"

50 &"H", AT2, SAVE "X3.BIN"

60 &"H", AT2, SAVE "X4.BIN"

70 &"H", AT2, SAVE "X5.BIN"

80 HGR

90 &AT2, LOAD "X1.BIN"

100 POKE 49237,0

110 &AT1, LOAD "X2.BIN"

120 POKE 49236,0

130 &AT2, LOAD "X3.BIN"

140 POKE 49237,0

150 &AT1, LOAD "X4.BIN"

160 POKE 49236,0

170 &AT2, LOAD "X5.BIN"

180 POKE 49237,0

190 END

 

What confuses me is that I have to first &SAVE them to either AT1 or AT2 and then it seems I have to do it again with &LOAD? Any help? Thanks.

 

 

Online
Last seen: 1 hour 41 min ago
Joined: Feb 27 2021 - 18:59
Posts: 695
extending BASIC

Applesoft BASIC does not run programs by interpreting them character by character, but compiles them into an internal format that is made up of tokens. In this way it is like every other BASIC that doesn't compile to native machine code. It wouldn't be feasible to run programs in the form that you type in: consider something like a FOR ... NEXT loop. When execution reaches NEXT, it must jump backwards to the corresponding FOR statement, but it would be impossible to do so by searching the whole program text for the letters "FOR". Instead a token is stored along with the memory address of the beginning of the loop, to which execution can return directly.

The user interface hides these details from you to make the system more approachable for novices learning to program a computer for the first time. When you LIST your program, it looks much like when you typed it in, but this actually is done by de-compiling the program in memory from tokens back into BASIC source code. The actual source code that you type vanishes when you press return at the end of each line, replaced by its tokenized interpretation.

The EXTRA.SCREENS program adds new statements to the BASIC language when it is run. Before it is run, those statements are unrecognized by BASIC and it has no idea what tokens to compile.

So you cannot type a program—like you have done—that uses those statements without running the utility first.

The other problem is how images are managed by Extra Screens. From the manual it doesn't look like it loads each image from a disk file, but instead transfers the images from the graphics screen. Using &SAVE with a screen page number takes whatever is currently on screen on that page and saves it into aux memory under the name you give to it. That name is just a convenient label and has nothing to do with any file name.

The way that disk files become involved is with the &STORE and &RECALL commands, which work on every image currently saved in aux memory (not individual images).

Offline
Last seen: 8 hours 50 min ago
Joined: Sep 28 2024 - 12:15
Posts: 12
Ah shoot, guess it isn't as

Ah shoot, guess it isn't as easy as I thought...

so I can't just load the images from disk to memory, I have to BLOAD the images to $A4000 and then save the resulting screen? Extra-K has a screen demo on the disk, written in basic and listable. Viewing the code, the images displayed are coded in basic, not just .bin files. I may have to rethink my approach.

Log in or register to post comments