F8 Open File function is awfully dang picky!

Phil Pilgrim (PhiPi)

I'm trying some simple experiments that require uploading an EEPROM image that contains additional data in high EEPROM after the program. I've successfully created a ".eeprom" image with the correct checksum, but the IDE's file loader gives me the message, "[noparse][[/noparse]File] contains data after the code space that was not generated by the Propeller tool. [noparse][[/noparse]Well, yeah.] The data will not be displayed or downloaded." Why such nitpickiness? Anything after the program area is benign, except possibly for presetting some VARs, right? Besides, if a file can pass all the other tests except this one, it's probably a legitimate attempt, like mine, to try something interesting and not just random bytes.

BTW, this is not my ultimate objective, but rather a temporary shortcut to writing the data in upper EEPROM.

-Phil

kuroneko

I know it's not part of the IDE etc but why don't you use HAM for the time being http://forums.parallax.com/showthread.php?p=628778?

Ariba

I get the same Error Message, when I try to download my self created Binaries with Propellent (into the RAM).
This binaries have a Spin part with an LMM Interpreter and an added LMM part. I calculate the checksum correct, but no way to download it.

If I download this binaries with my own Loader (in PropTerminal) the Propeller has no problems to execute it.

So, IMHO there is a test to much in the Propellent/PropTool Loader.

Andy

Phil Pilgrim (PhiPi)

At least I'm not alone. This is probably just one of those things that seemed reasonable when the IDE was first written, without being able to foresee any plausible exceptions. Perhaps a simple dialog box instead of the message box would be appropriate here:

File contains data after the code space that was not generated by the Propeller tool.
                            Do you want the extra data zeroed?

                                  [noparse][[/noparse]YES]  [noparse][[/noparse]NO]  [noparse][[/noparse]CANCEL]

Meanwhile, I think I've found a workaround that will get me past my initial requirements.

-Phil

Post Edited (Phil Pilgrim (PhiPi)) : 6/19/2008 3:07:17 AM GMT

hippy

I haven't tried it but I expect it's looking at where the pointers go to from the program header ($0004-$000F ) to verify the file is legit.

It should be possible to tweak the header so it thinks the variables and/or stack starts later in the file which will hopefully allow everything before that to be anything. It should then be possible to alter the program header in RAM to what it should be, issue a CogInit(0,$F002,$0004) and have the program re-start as it should have in the first instance.

That will require some space at the end of the file / RAM to be used for vars / stack at initial start-up so data cannot be put there, but that data could be put elsewhere then byte-moved up as part of the 'second attempt' fix-up.

Updated : That seems to work. Haven't done an actual download and it needs some extra work to do the fixup but I can stop all 'bad image' error messages. Three word entries need to be adjusted at RAM Address / File offset ...

$0008 Ptr to Variable Base
$000A Ptr to Stack Base
$000E Ptr to Stack Init

The long pointed to at Stack Base is $0000_0000, the two longs before Stack Base are both $FFFF_F9FF, Stack Init is Stack Base+4.

Post Edited (hippy) : 6/19/2008 3:04:53 AM GMT

Ariba

Thank you Hippy for youre possible workaround.

I also think it depends on the pointers in the header, but I don't wont to change the Spin stack to the end of the LMM part.
To alter the pointers and restart Spin can be a solution - I will try it.

The better solution would be when Propellent don't test for data behind Spincode, or when we can switch off this Test with a commandline option.
For the PropTool also the message box that Phil suggests is OK.

Andy

hippy

I think PropTool should just download whatever there is in the file, no message box.

I presume it just downloads as little as it can ( to start of vars or start of stack ) but there doesn't seem to be any reason that Propellent / PropTool cannot check the image to find which is the last used long and send that much.

If Propellent is changed, great, but if not this is a work round. Providing the last 8 longs of RAM aren't used it's easy to do. Copy $0004-$000F to $7FE4-$7FEF, alter $0004-$000F to point to $7FFx. It's easy enough to check the last 8 longs aren't used from the pointers there are in $0000-$000F. A simple utility will allow a .eeprom / .binary to be converted to a format Propellent will accept.

A program to be altered this way will need a couple of lines of Spin at the start of PUB Main but once running RAM will look like the originally PropTool generated .eeprom, var and stack pointers pointing to where they should have been.

hippy

Another success, or so it seems from my limiting testing.

Run "MkEeprom yourfile.eeprom" and this will convert any .eeprom file into a format which the
PropTool and Propellent can use and automatically sort itself when it first runs. There is nothing
which needs to be done with the original Spin/PASM source code, it's totally transparent in its
operation.

Very thrown together, VB6 so needs VB6 runtime, doesn't support .binary files, doesn't check
it's an actual Spin .eeprom file before trampling on it. It does check the file hasn't already been
modified and that it can be. Source code included if anyone wants to turn it into a proper and
robust command line application or alter anything. License : Public domain.

It works by moving the original program header to the end of RAM then inserts a faked PUB Main,
updates the program header and updates the file checksum. Once loaded into RAM, the faked
PUB Main is executed, restores the header and restarts the Spin Interpreter. From then on its as
if the original .eeprom had been loaded initially, except there will be some crud lying around in
the last few bytes of RAM.