I have a utility that will generate Spasm source from a binary file. It also attempts to generate Spin source from the Spasm source, but it generates generic variable and method names. It also has to interpret jumps and guess at the high level command that generated them. I think it generates if and elseif for forward jumps and repeat while for backward jumps. After all the editing you'll need to do on the generated Spin code it's probably better to just wait till to get home to work on it.
If you want me to try to generate a source file just extract a binary file from the EEPROM and post it to this thread or PM me.
You need to load a program into RAM that reads the EEPROM and dumps the hex code to the serial port. You then copy the hex code from PST or whatever terminal emulator you use and store it in a text file. I can convert the hex file to a binary file. I'll see if I can write a hex dump program in a few minutes, or maybe somebody already has one that they can post.
I have a utility that will generate Spasm source from a binary file. It also attempts to generate Spin source from the Spasm source, but it generates generic variable and method names. It also has to interpret jumps and guess at the high level command that generated them. I think it generates if and elseif for forward jumps and repeat while for backward jumps. After all the editing you'll need to do on the generated Spin code it's probably better to just wait till to get home to work on it.
If you want me to try to generate a source file just extract a binary file from the EEPROM and post it to this thread or PM me.
Here's a quickie EEPROM dump program. It compiles, but I haven't tested it. Make should you load it into RAM and not into EEPROM or you will wipe out the program that is in EEPROM. In the Prop Tool F10 will compile and load into RAM. F11 loads into EEPROM. Do not push F11.
Here's a quickie EEPROM dump program. It compiles, but I haven't tested it. Make should you load it into RAM and not into EEPROM or you will wipe out the program that is in EEPROM. In the Prop Tool F10 will compile and load into RAM. F11 loads into EEPROM. Do not push F11.
Well I tried it, but my despin program wasn't quite as far along as I remembered it to be. It generated some Spasm code, and attempted to group it together into Spin statements, but it crashed at some point into the file. Here's the binary file and the partially generate Spin/Spasm file. Sorry I couldn't be of more help.
I left my code on my thumb drive at home and would like to work on my prop before I get back home, is there a utility for this?
There is a way to prevent this happening again, keep the drive on your keychain... Doesn't stop
you locking yourself out because the drive's still in the machine though!
I keep my Prop files in my Dropbox. No more trying to sync files with a USB drive.
I also like to know which program is presently loaded in a Propeller. To do this I add a short DAT section at the top of the program where I keep the name of the program.
DAT programName byte "Hexapod140924c", 0
CON
Near the beginning of the program I send this string to the terminal so I know which version of the code is presently loaded.
There is a way to prevent this happening again, keep the drive on your keychain... Doesn't stop
you locking yourself out because the drive's still in the machine though!
Well I tried it, but my despin program wasn't quite as far along as I remembered it to be. It generated some Spasm code, and attempted to group it together into Spin statements, but it crashed at some point into the file. Here's the binary file and the partially generate Spin/Spasm file. Sorry I couldn't be of more help.
I ran the binary file through an earlier version of despasm that did not try to group Spasm code together into Spin statements and it was able to get through the entire binary file. I attached test2.spasm within test2.zip below. Of course this does not help you much, but in theory a Spin source could be regenerated from this.
There's no official assembly language for Spin bytecodes, so I invented one and called it spasm. I've attached the documentation for the Spasm assembler that describes the opcodes.
The grouping for the Spin statements can be determined by following through the stack usage for the opcodes, and locating when the stack goes down to zero. Exceptions to this rule are instructions like repeat that load parameters on the stack that are used during the entire loop.
Comments
Not really, unless you can read bytecode.
If you want me to try to generate a source file just extract a binary file from the EEPROM and post it to this thread or PM me.
I stand joyfully corrected.
There is a way to prevent this happening again, keep the drive on your keychain... Doesn't stop
you locking yourself out because the drive's still in the machine though!
Backup to cloud and USBdrive?
I keep my Prop files in my Dropbox. No more trying to sync files with a USB drive.
I also like to know which program is presently loaded in a Propeller. To do this I add a short DAT section at the top of the program where I keep the name of the program.
Near the beginning of the program I send this string to the terminal so I know which version of the code is presently loaded.
This has been a huge convenience.
Just me being diligent to double check I have everything would be the best solution, the cloud would also be a good solution.
I like Duane's naming system, I have yet to setup a rx routine in this code, but that is in the plans.
I took a look, just out of curiosity...
I think if it were my Spin code lost and I knew what some of your symbols meant, I could remember what my Spin code was...
The grouping for the Spin statements can be determined by following through the stack usage for the opcodes, and locating when the stack goes down to zero. Exceptions to this rule are instructions like repeat that load parameters on the stack that are used during the entire loop.