Bellcom disk 397, a (Turbo)BASIC puzzle

Entry posted by Atari_Ace August 7, 2018

409 views

At this point I've fixed a lot of Bellcom disks, and now find the remaining ones are going to have to wait until I find another source of the damaged content, or some manual work on my part.

Disk 397 is a good example of the latter. It is missing sector 228, which is the first sector of AUTORUN.BAS, which turns out to be the Autocrostics program, which is also archived on the Pooldisk as UMICH\CIS\CROSTI.ATR, sector 214. So using the tools developed so far, we copy over the sector and fix the link and all should be well.

006a90: SECTOR: 214: FILE:
     0  00 00 00 01 ac 01 ad 01-25 03 1b 24 30 24 44 49   ........%..$0$DI
    10  4d 45 4e 53 49 4f ce 4d-45 4e d5 4c 4f 41 44 5f   MENSIO.MEN.LOAD_
    20  44 41 54 c1 50 4c 41 d9-c1 52 45 54 55 52 ce 47   DAT.PLA..RETUR.G
    30  4f 41 48 45 41 c4 47 4f-42 41 43 cb 44 49 53 4b   OAHEA.GOBAC.DISK
    40  53 41 56 c5 50 52 49 4e-d4 48 45 4c d0 46 4c 41   SAV.PRIN.HEL.FLA
    50  53 c8 43 4c 45 41 d2 45-44 47 45 d3 d8 4c 49 4e   S.CLEA.EDGE..LIN
    60  4b a8 4c 49 4e cb 44 45-46 49 4e c5 44 d0 54 b3   K.LIN.DEFIN.D.T.
    70  54 b4 42 cb 54 b1 44 45-46 a4 54 b2 54 0c d7 7d   T.B.T.DEF.T.T..}

Well, it doesn't work. Why? The two files are slightly different versions of the same BASIC program. Since slightly different isn't exact, a blind copy of the first 125 bytes isn't necessarily going to work. Some adjustment is going to need to be made, but what?

SAVE'd BASIC programs are all structured alike (this is actually a Turbo BASIC program, which follows the same design). They all start out with 7 words/pointers: lomem, vntp, vntd, vvtp, stmtab, stmcur, starp. This is followed by a variable name table (reflected by the vntp and vntd variables), a dummy byte, the variable value table (vvtp), followed by the list of statements (stmtab).

In the case of Autocrostics, byte 125 of the file is still in the variable name table and if you ignore the missing first 125 bytes, the files are mostly identical up to around offset 0x1b30. Around that point, a line in the program has been changed causing the rest of the file to shift. So we should be able to copy the first sector and edit the introductory words to restore the file.

A little thought suggests the first five words should be the same. The programs seem to have the same variables, so the name and value tables haven't moved, and the first statement (stmtab) should be in the same place. So that suggests we only need to change stmcur and starp to restore the original file.

Let's start with starp. It basically points to the end of the program (or the start of the string table). The UMICH file is actually smaller than this by 35 bytes, so naively you'd expect to have to increase starp by 35 = 0x23 bytes to compensate, and indeed, we need to change starp from 0x2430 to 0x2453.

Now let's tackle stmcur. In normal cases, it will be smaller than starp by the size of the command to save the file, since SAVE "filename" was the last command run, and it will get stored as a hidden line 32768 in the file. In our case, the difference is 0x2430-0x241b = 0x15 bytes, and if we look at the end of the file, the last fifteen bytes are 00 80 15 15 19 0f 0d <D4:PLAYER.TBX> 16, which is indeed the last line of the program (notice that program lines start with the line number and then a length byte, followed by the line data).

In AUTORUN.BAS, the equivalent values are 00 80 15 15 19 0f 0d <D:AUTORUN.BAS> 16. By coincidence, although the names are different they are the same length, so the line is also 0x15 bytes. So we should set stmcur to 0x2453-0x15 = 0x243e.

So by patching in the sector and adjusting those two values we've restored the missing sector with fairly high confidence. And the disk boots again!

397.atr