I just read the USB drive containing the .eeprom file into the eeprom2(24cl256) starting at $00 up to $6FFF (At $7000 I am storing preferences). I then copied 64 bytes at a time from eeprom 2 to eeprom 1 starting at $00 up to $6FFF. There is a method to scroll through the lcd and get a visual of the bytes on each eeprom, they appear identical except after $7000. On the .eeprom file, there is nothing up that high except at $7F18 FF FF F9 FF FF F9 FF, which is present on the boot drive as I did not erase that high.
Scanning and looking from $0 to $6FFF looks identical, but the Prop will not boot from it. Any suggestions on what may be missing?
You say the $FFFFF9FFFFF9FF is at $7F18? Wow, you have a lot of data storage up there. That means your preferences will get dumped into either code, or declared variables.
Do make sure you are zeroing your declared variables before you try and use them then as they won't necessarily be zero as they would usually be on a clean boot.
Oh, and you only have 232 longs of stack space. That's a packed program!
Can you start with something smaller to test with perhaps? I can't see any immediate issues excepting those I've mentioned above, but you never know.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
I wrote a routine that compares eeprom 1 and 2, there are no error from $0 - $6F60. I even tried a newer .eeprom file, copied it over and compared it.
This means I now have to test from the USB to the eeprom, since the eeproms are exact copies up to near $7000.
The main program is over 3600 lines, there are maybe 400 lines in other objects, I had some errors (31 longs too big to fit ram), so I had to clean things up to get it to program. I will be sure to go through and zero out the variables as you said.
Hopefully this will resolve it self in the USB transfer. Come to think of it, I bet the answer is in a check for "D:\ $0D", where if these are found it nukes the buffer and starts that 64byte read over again at 0, I didn't consider that there could be a coincidental set of numbers showing up.
I have been viewing the eeprom file in the Prop tool and picking out around 50 points to compare with the boot eeprom that all match all over the range.
The only difference I can find is all above $7000 which I am not writing to. On the eeprom file being copied to the boot eeprom, at $7EA0 there is FF FF FF F9 FF FF FF F9 FF. Since I am not writing above $7000, the boot eeprom shows at $7F18 FF FF FF F9 FF FF FF F9 FF left over from a previous F11.
I really don't understand Brad how if you add up all those numbers you end up with 0?
TChapman said...
I have been viewing the eeprom file in the Prop tool and picking out around 50 points to compare with the boot eeprom that all match all over the range.
The only difference I can find is all above $7000 which I am not writing to. On the eeprom file being copied to the boot eeprom, at $7EA0 there is FF FF FF F9 FF FF FF F9 FF. Since I am not writing above $7000, the boot eeprom shows at $7F18 FF FF FF F9 FF FF FF F9 FF left over from a previous F11.
I really don't understand Brad how if you add up all those numbers you end up with 0?
You are adding all those bytes into a byte and it should end up as 0. The easy way to do it is add them all into a long and just look at the bottom 8 bits.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
I did an F11, put the program on the main eepom, then copied it to the spare from $0 - $7F, then copied it back to boot eeprom and it boots fine, so I know the code is good getting from eeprom to eeprom. The issue is using the eeprom file, or reading from usb, one or the other. I have visually been over the view info and scanned the eeprom back and forth and cannot detect a problem.
Brad, I am not sure how you mean? You are saying start at $00 on the eeprom and start adding it to each new address, until past the program data where it hits 0? I am not following how adding these random numbers gets to a perfect 0. Can you show some example code? Also, what do I do when I get the bottom 8 bits?
C := 0;
For I := 0 to $7FFF do
C := C + EEprom[noparse][[/noparse] I ];
If C and $FF = 0 then
Writeln('EEprom csum ok')
else
Writeln('Aliens have infected your image');
Basically add up all the bytes in the entire eeprom image. All of them upto and including the $FFFFF9FFFFFFF9FF. If the bottom 8 bits (C and $FF) of that number are clear then the checksum passes. If not then it's bogus.
I'd do this.. copy the *entire* eeprom file from the USB stick to eeprom A. Check the checksum on eeprom A and then copy $0-$6FFF of that across to EEprom B. It *should* boot. The $FFFFF9FFFFFFF9FF is there to stall the cog when the main spin object returns. It should not be a problem if those bytes are in the wrong place provided that does not occur.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
OK good call Brad, I did F11, and ran checksum on the boot eeprom and got a hex value for example $23 $22 $ 22 $00, so I assume the $00 at the end is the success. On the usb copy however it did not end in $00.
I think the way to solve this is to F11 to have an identical copy on the main eeprom as the .eeprom file. Then copy the usb to the spare, start comparing and see where the glitch is.
Or even easier, F11 load the spare eeprom and instead of reading the USB and writing it to the eeprom, read the USB and compare it byte for byte as you _would_ write it to the eeprom.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Finally! Now that it works consistently, I see no reason to copy to the spare eeprom and then the main, just go straight to the main boot eeprom. Things really got weird after copying the spare eeprom to the main, not a good idea to mess with the main programs variable space.
The checksum idea really helped me solve it, a dumb mistake chopping off a byte every 64 bytes due to T = 1 - 64 instead of 0 - 64, make the last byte $00 instead of whatever it should have been, fortunately the pattern made it easy find.
I can hit "update" and copy to the main eeprom consistently and boot from it. It takes maybe a minute to read it at 9600.
Comments
You say the $FFFFF9FFFFF9FF is at $7F18? Wow, you have a lot of data storage up there. That means your preferences will get dumped into either code, or declared variables.
Do make sure you are zeroing your declared variables before you try and use them then as they won't necessarily be zero as they would usually be on a clean boot.
Oh, and you only have 232 longs of stack space. That's a packed program!
Can you start with something smaller to test with perhaps? I can't see any immediate issues excepting those I've mentioned above, but you never know.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
This means I now have to test from the USB to the eeprom, since the eeproms are exact copies up to near $7000.
The main program is over 3600 lines, there are maybe 400 lines in other objects, I had some errors (31 longs too big to fit ram), so I had to clean things up to get it to program. I will be sure to go through and zero out the variables as you said.
Hopefully this will resolve it self in the USB transfer. Come to think of it, I bet the answer is in a check for "D:\ $0D", where if these are found it nukes the buffer and starts that 64byte read over again at 0, I didn't consider that there could be a coincidental set of numbers showing up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
The only difference I can find is all above $7000 which I am not writing to. On the eeprom file being copied to the boot eeprom, at $7EA0 there is FF FF FF F9 FF FF FF F9 FF. Since I am not writing above $7000, the boot eeprom shows at $7F18 FF FF FF F9 FF FF FF F9 FF left over from a previous F11.
I really don't understand Brad how if you add up all those numbers you end up with 0?
You are adding all those bytes into a byte and it should end up as 0. The easy way to do it is add them all into a long and just look at the bottom 8 bits.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Brad, I am not sure how you mean? You are saying start at $00 on the eeprom and start adding it to each new address, until past the program data where it hits 0? I am not following how adding these random numbers gets to a perfect 0. Can you show some example code? Also, what do I do when I get the bottom 8 bits?
For I := 0 to $7FFF do
C := C + EEprom[noparse][[/noparse] I ];
If C and $FF = 0 then
Writeln('EEprom csum ok')
else
Writeln('Aliens have infected your image');
Basically add up all the bytes in the entire eeprom image. All of them upto and including the $FFFFF9FFFFFFF9FF. If the bottom 8 bits (C and $FF) of that number are clear then the checksum passes. If not then it's bogus.
I'd do this.. copy the *entire* eeprom file from the USB stick to eeprom A. Check the checksum on eeprom A and then copy $0-$6FFF of that across to EEprom B. It *should* boot. The $FFFFF9FFFFFFF9FF is there to stall the cog when the main spin object returns. It should not be a problem if those bytes are in the wrong place provided that does not occur.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
Things I just tried:
Zero'd the entire boot eeprom.
F11 the program to the boot eeprom
Copy USB>Boot up to $6FFF.
No boot.
I think the way to solve this is to F11 to have an identical copy on the main eeprom as the .eeprom file. Then copy the usb to the spare, start comparing and see where the glitch is.
Thanks for the pointers, very helpful.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
The checksum idea really helped me solve it, a dumb mistake chopping off a byte every 64 bytes due to T = 1 - 64 instead of 0 - 64, make the last byte $00 instead of whatever it should have been, fortunately the pattern made it easy find.
I can hit "update" and copy to the main eeprom consistently and boot from it. It takes maybe a minute to read it at 9600.
Thanks for the help guys. Mission accomplished.
The Vinculum is a very cool chip btw.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.