SPIN DBase, PBase, and DBase

Kye

I'm writing some code that loads program files to eeprom. For EEPROM spin files my code works file. However, for BINARY spin files I have some problems because the files do not cause my loader program to update all eeprom sections with the new image leaving some sections with old data.

I'm okay with this behavior of my loader, however, I would like to force non-valid sections to be zeros when I read them into memory by looking at the setup pbase, dbase, and vbase variables to zero the variable image and the stack area.

Is this possible and how do I do it?

Phil Pilgrim (PhiPi)

I believe it's as easy as zeroing everything past the end of the .binary load. I'm not aware that you have to examine any pointers to find the stack and specific VAR areas.

-Phil

Dave Hein

Here's a snippet of code that I use in Spinix when loading binary files from SD.

  ' Get VBASE and DBASE
  vbase := word[8]
  dbase := word[10]

  ' Clear VAR area
  bytefill(vbase, 0, dbase - vbase)

  ' Set up the stack
  word[dbase][-4] := 2           ' pbase
  word[dbase][-3] := 0           ' vbase
  word[dbase][-2] := 0           ' dbase
  word[dbase][-1] := $fff9       ' pcurr - cogstop(cogid) method in ROM
  long[dbase]~                   ' Zero result

As Phil said, you could just zero out everything after dbase. You only need to set up the four words before dbase if you want to allow the program to return from the first method in the top object and stop the Prop. These values are normally set to $ffff, $fff9, $ffff, $fff9, but 2, 0, 0, $fff9 is sufficient.

EDIT: Programs should not assume that the stack area has been zeroed, but they can assume that the var area is initialized to zero. However, there may be programs around that assume that the high end of the stack is initialized to zero, since this is the case in EEPROM images. Therefore, it would be safer to zero out everything after vbase, and patch in the 4 words before dbase.

Kye

Zeroing after VBase works. I already do the stack marker stuff, but, the rest of the image has to be okay for the checksum to pass.

Phil Pilgrim (PhiPi)

Here are two versions compiled from the same Spin file:



The remainder of the .eeprom file is filled with zeroes. The only additional consideration required for the checksum is the effect of the FFFF_F9FF_FFFF_F9FF. [Looking at some loader code that I wrote awhile back, it looks like the two additional longs are already figured into the .binary file's checksum, even though they're missing from the file itself.]

-Phil

Kye

Its because the bootloader code patches them in.