I've been writing an Applesoft BASIC program over the last few months or so (IIgs and IIe, ProDOS 2.4.2 with BASIC.SYSTEM v1.6).

My large BASIC program was sitting at something like 51 ProDOS blocks. As this program evolved and better coded subs were written, big gaps in my line numbers appeared.

I copied my BASIC program over to DOS3.3 so I could use the 'RENUMBER' program from the Apple DOS3.3 Master disk. The program worked perfectly.

When I moved my new BASIC file over to ProDOS, it was 19 blocks! I thought it was odd, 32 blocks taken up by gaps in line numbers?

So I loaded my original basic program and LISTed it into a sequential text file. Then EXECed the text file (complete with the same gaps in line numbers) back into Applesoft. Saved this file... Only 19 blocks, same size the new renumbered program file.

Okay, so my original BASIC program has an extra 32 blocks which is not due to large gaps in line numbers... What’s consuming all the extra space?

  • The Applesoft BASIC format is documented, so look at the file in some kind of hex editor (or in the monitor in memory) and try to see what's taking up the space? It does sound like a kind of bug somewhere, though I've never heard of it before. It will be difficult for us to figure out the reason without being able to see the 51-blocks file...
    – dirkt
    Commented Jun 21, 2021 at 6:18
  • 1
    Could it just be a kind of fragmentation problem with ProDOS? Meaning that it reuses blocks for the same file and does not free them automatically? A bit like on UCSD disks where you have to "crunch" the disks manually. I don't know the details of ProDOS (I never used anything else than DOS3.3 and UCSD on my Apple II+) but I don't remember it being more sophisticated than FAT. Commented Jun 21, 2021 at 8:20
  • It would make some sort of sense to use a data structure within the file where you could find "line N" without iterating through all lines -- a tree or hash map, for example -- and where you didn't have to shuffle data around when inserting or removing a line. Such structures tend to accumulate unused areas, benefiting from occasional compaction.
    – dave
    Commented Jun 21, 2021 at 11:56
  • 5
    I can't think of a ProDOS or Applesoft issue that would cause this. Line numbers are irrelevant, Applesoft code is stored compactly, ProDOS allocation doesn't fragment, and saving a smaller BASIC file over a larger one doesn't leave stray stuff. Do you still have the super-sized file on a disk image? Examining it with a hex editor would be useful.
    – fadden
    Commented Jun 21, 2021 at 14:49

1 Answer 1


The ProDOS AppleSoft SAVE command:

  1. Creates the file if it doesn't exist
  2. Opens the file
  3. Writes all data from BEGPROG (zero page $67/$68) through ENDPROG (zero page $AF/$B0)
  4. Sets the file length to ENDPROG-BEGPROG
  5. Closes the file
  6. Sets the file aux type to BEGPROG (usually $0801).

Based on this, if ENDPROG (zero pages $AF/$B0) were to be corrupted or intentionally altered, extra data would be included at then end. (Perhaps binary subroutines?).

Based on testing, POKEing into 175/176 will increase the disk size. The increased disk size (and ENDPROG) remained after loading, editing, and re-saving. There's no indication the file is larger when LISTing the code since it still terminates as usual (with a null next line pointer) and AppleSoft doesn't know or care about disks and files.

  • Did you check to see if copying it to a DOS disk reduced the size?
    – fadden
    Commented Jun 22, 2021 at 4:29
  • Note that the file was converted to DOS for purposes of using the renumber utility, which I suspect works by moving the program code to the end of memory, and then copying each line back to the start of memory while adjusting line numbers (which might become bigger or smaller). If the renumber utility uses the triple-zero marker to determine that it has copied everything, it would write the triple-zero marker just past the last line it copied and then set the end-of-program flag to point there.
    – supercat
    Commented Jun 22, 2021 at 16:47
  • I didn't check the DOS aspect but DOS 3.3 seems to use the same ZP locations and logic when loading and saving (but name it ASSOP and ASEOP -- AppleSoft Start / End Of Program. Commented Jun 22, 2021 at 21:14
  • 1
    @supercat Ah, so you're saying the act of renumbering rather than the act of copying did the reduction. I tested this theory with the RENUMBER program itself, which has an embedded binary program. Sure enough, if you LOAD then SAVE it's still 13 blocks, but if you renumber it then SAVE it's only 4 blocks. Corrupted $af-b0 seems likely.
    – fadden
    Commented Jun 22, 2021 at 23:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .