BASIC disassembly

[@username@]

Here's something from Wizzdom issue 3, page 4, which intrigued me. The description of the self modifying program is a little confusing

Code: Select all

Start of program area is 220,0 followed by 5 characters for line number then a space, then 4 characters for DATA: therefore the 0 is at the tenth position.

The actual code is

Code: Select all

10 DATA0
20 READ A
30 POKE 170,220
40 POKE 171,9
50 DATA1

Here, I think, is where perhaps some confusion came in - as almost 20 years on, we can see what's going on inside the machine.

In RAM it looks like this

Code: Select all

00000020   0A 00 FF FF  FF FF 09 16  B4 00 96 00  00 09 00 00  ................
00000030   00 83 00 00  00 00 F6 FF  FF 00 00 CF  00 00 00 00  ................
00000040   0F 01 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000050   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000060   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000070   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00000080   00 00 00 05  14 14 0A 0A  00 00 00 00  00 00 00 00  ................
00000090   00 00 00 00  00 00 00 00  83 00 00 48  00 00 00 00  ...........H....
000000A0   00 14 05 00  00 02 00 00  00 59 DC 0B  C8 02 00 00  .........Y......
000000B0   00 FC 00 00  00 00 00 00  00 C9 00 00  00 00 00 00

Offset $AA and $AB contain the address in VRAM of the actual code. Offset $26 contains a pointer to the value of the last DATA statement.

At this point, before it's run, VRAM looks like this

Code: Select all

00001400   DC 00 DC 0B  DC 16 DC 27  DC 36 00 00  00 00 00 00  At $1400 - the pointers to the actual text OR 0xC000
00001800   00 0A 00 14  00 1E 00 28  00 32 FF FF  FF FF FF FF  Line pointers
00001C00   31 30 20 20  20 44 41 54  41 30 0D 32  30 20 20 20  10   DATA0.20
00001C10   52 45 41 44  41 0D 33 30  20 20 20 50  4F 4B 45 31  READA.30   POKE1
00001C20   37 30 2C 32  32 30 0D 34  30 20 20 20  50 4F 4B 45  70,220.40   POKE
00001C30   31 37 31 2C  39 0D 35 30  20 20 20 44  41 54 41 31  171,9.50   DATA1

... and of course the actual code at $1C00

From here it's easy to see that BASIC uses a simple list of pointers to know which line and in which order.
DATA Statements, however, appear to be unique, in that they are copied down and written back as the program runs.

After execution, VRAM now looks like this

Code: Select all

00001400   DC 00 DC 0B  DC 16 DC 27  DC 36 00 00  00 00 00 00
00001800   00 0A 00 14  00 1E 00 28  00 32 FF FF  FF FF FF FF
00001C00   31 30 20 20  20 44 41 54  41 31 0D 32  30 20 20 20  10   DATA1.20
00001C10   52 45 41 44  41 0D 33 30  20 20 20 50  4F 4B 45 31  READA.30   POKE1
00001C20   37 30 2C 32  32 30 0D 34  30 20 20 20  50 4F 4B 45  70,220.40   POKE
00001C30   31 37 31 2C  39 0D 35 30  20 20 20 44  41 54 41 31  171,9.50   DATA1

As you can see, only the actual DATA statement has changed. What the code did, was tell BASIC through poking $AA,$DC and $AB,9, to put the current DATA value back, at the wrong address.
I hope this explains how this works!

Up in the emulator thread you'll find a fun little program called BASIC Nibbler, which demonstrates this further, but uses 100 or so modifications to read the first 50 bytes of BIOS as nibbles.