How to understand the hex dump of a Spin/PASM binary file
Wossname
Posts: 174
EDIT:
If anyone has some obscure, rare or self-authored Propeller 1 related documentation please consider adding it to this thread as an attachment so that it may be preserved before the ravages of time steal it from us forever.
I will collate any such files into a zip file for easy access at a later date on the main Propeller Resources thread.
I have created a piece of test code ("test.spin" attachment) in order to try to understand the structure of the eeprom/binary file ("test.eeprom" attachment) created by the Propeller Tool.
I hex-dumped this eeprom file thus...
Basically I'm attempting to run some simplified PASM code on all 8 cogs in sequence.
Am I right in thinking that the byte sequence "c0000200 90000000" is an absolute jump to the beginning of the interpreted Spin language section between bytewise addresses 00000a0 and 00000cf inclusive? If it's not a jump but something else, what is it?
The "c0000200 90000000" sequence is followed by my two debugging NOP instructions and then by each of my cogs' allocated PASM code chunks (the 8 repeated identical lines) then by the spin bytecode).
I've scoured the manual and the datasheet for the P8X32A but can find no detailed information about the spin language section of this data. How might I be able to decode this in order to find out the addresses that each of my 8 cogs will take their PASM code from (for instance if my cogs were all running much larger, arbitrary sized sections of PASM)?
I can see some patterns in the spin language section that appear to correspond with the original test.spin file but there are some anomalous bytes here and there which seem to disrupt those patterns a little. I'd appreciate some guidance on this.
If anyone has some obscure, rare or self-authored Propeller 1 related documentation please consider adding it to this thread as an attachment so that it may be preserved before the ravages of time steal it from us forever.
I will collate any such files into a zip file for easy access at a later date on the main Propeller Resources thread.
I have created a piece of test code ("test.spin" attachment) in order to try to understand the structure of the eeprom/binary file ("test.eeprom" attachment) created by the Propeller Tool.
I hex-dumped this eeprom file thus...
0000000: 00b4c404 6f2b1000 d000d800 a000dc00 ....o+.......... 'clock config 0000010: c0000200 90000000 00000000 00000000 ................ 'jump to Spin section??? 0000020: 010afc0c 00000000 00000000 030a7c0c ..............|. 'cog0's PASM 0000030: 010afc0c 00000000 00000000 030a7c0c ..............|. 'cog1's PASM 0000040: 010afc0c 00000000 00000000 030a7c0c ..............|. 'cog2's PASM 0000050: 010afc0c 00000000 00000000 030a7c0c ..............|. 'cog3's PASM 0000060: 010afc0c 00000000 00000000 030a7c0c ..............|. 'cog4's PASM 0000070: 010afc0c 00000000 00000000 030a7c0c ..............|. 'cog5's PASM 0000080: 010afc0c 00000000 00000000 030a7c0c ..............|. 'cog6's PASM 0000090: 010afc0c 00000000 00000000 030a7c0c ..............|. 'cog7's PASM 00000a0: 3722c780 80352c38 06c77035 2c3805c7 7"...5,8..p5,8.. 00000b0: 60352c37 01c75035 2c3721c7 40352c37 `5,7..P5,7!.@5,7 00000c0: 00c73035 2c36c720 352c35c7 10352c32 ..05,6. 5,5..5,2 00000d0: fffff9ff fffff9ff 00000000 00000000 ................ 'marker and end of program... 00000e0: 00000000 00000000 00000000 00000000 ................ 00000f0: 00000000 00000000 00000000 00000000 ................ 'zeroes ad infinitum...
Basically I'm attempting to run some simplified PASM code on all 8 cogs in sequence.
Am I right in thinking that the byte sequence "c0000200 90000000" is an absolute jump to the beginning of the interpreted Spin language section between bytewise addresses 00000a0 and 00000cf inclusive? If it's not a jump but something else, what is it?
The "c0000200 90000000" sequence is followed by my two debugging NOP instructions and then by each of my cogs' allocated PASM code chunks (the 8 repeated identical lines) then by the spin bytecode).
I've scoured the manual and the datasheet for the P8X32A but can find no detailed information about the spin language section of this data. How might I be able to decode this in order to find out the addresses that each of my 8 cogs will take their PASM code from (for instance if my cogs were all running much larger, arbitrary sized sections of PASM)?
I can see some patterns in the spin language section that appear to correspond with the original test.spin file but there are some anomalous bytes here and there which seem to disrupt those patterns a little. I'd appreciate some guidance on this.
Comments
Compile it using BST {view - compiler listing]
The fffff9ff longs at the end are actually a stack frame that is placed at the beginning of the stack. When the first method in the top object returns it actually jumps to location $fff9, which is located at the end of the ROM. The code at $fff9 executes a COGID followed by a COGSTOP.
Does there exist some official documentation regarding this data structure layout?
I did see that the wiki that used to have the "3 bit protocol" information has vanished. I have a copy on my 1st gen Kindle from way back.
Feels like Propeller is an endangered species.
Do you mean this wiki?
—▶ https://github.com/rosco-pc/propeller-wiki
Thank you all for your help
Cheers.
w.
Thanks for the tip about `bstc -ls` for viewing the listing with source. Brad's tools are pretty awesome.
The inner workings of the Spin interpreter were never meant to be documented. Chip went through some effort to scramble the bits so it would be difficult to reverse engineer. He finally released the source for the interpreter when people were getting close to descrambling the binary code located in the ROM.
I encourage people to attach any files containing useful data (particularly if it's been lost over the years and gone '404') and I'll go through this thread in a a few weeks' time and wrap all of them up into a tarball we can all download in one lump.
Here's one from a now '404' wikia site which I cannot remember the name of. It discusses the "3 Bit Protocol" (3PB) used to push program binaries / eeprom files over a serial port (RS-232 signalling) connection...
How about something like github? If we can collect a bunch of all the non-proprietary information that people have gleaned over the years and are willing to submit it, would that be a good way to maintain (I hesitate to use the term "crowd-sourcing") documentation? Any improvements made over time can be integrated using the normal github mechanisms. I don't know how Parallax would feel about such a thing though, we'd be wise to ask their blessing, and we'd need to nominate some people to maintain it. How practical is that? I don't know.
Not sure how else we'd do it except doing a wiki-style site. But that's also something that needs to be maintained by a group - not by an individual. We've already lost wiki's due to unpaid subscriptions.
Hmm, it's a tricky one.
I've zipped them up into one file and I'll post it here for the hell of it. Moar copies is moar betterer.
Keywords for this file so that search engines can find it...
spin, pasm, pnut, booter, interpreter, runner, parallax, propeller, p8x32a, docs, documentation, how to, source, code.
https://github.com/rosco-pc/propeller-wiki/wiki ... this one?
Or let's clone and update it?
GitLab's/GitHub's wikis are very basic... basically I don't like them... but they are easy to clone (a.k.a. to backup)... so data there should be easy to save and to plug in somwhere else even if GitHub evolves in a bad direction...
Maintaining static websites with GitHub/GitLab is not much harder but much more flexible... but may need writing everything in HTML like my notes and ceatsheets and so on...
In a nutshell that's the problem, yeah. The term "platform agnostic" information retrieval springs to mind but I can't put my finger on a system that exists anywhere that isn't owned by some random company that could get bought out overnight.
I'm starting another thread for this generalised problem of knowledge retention... http://forums.parallax.com/discussion/166867/solving-the-documentation-problem-opinions-please
The first two bytes of my Spin block in the compiled EEPROM file I'm looking are 0x37 and 0x22 in that order.
In this context, 0x37 means PUSH a 32-bit value on the stack. The value pushed is given by left-shifting 0x00000001 by the 5 LSB's of 0x22 and if bit 5 of 0x22 is set, subtract one from the value.
0x22 is "0010 0010" in binary. The decrement flag (red) is set and the 5 LSB's contain 2.
So...
((1 << 2) - 1) == 3
But `bstc -ls` decodes this as...
Where did the 7 come from?
The definition for the behaviour was in a random file named "Propeller Spin Bytecodes.txt" posted on this forum, original author unknown.
Is this unofficial "documentation" wrong? It works if you use (2<<2)-1==7 but that goes against the specific examples given in the document.
That's a pretty slick optimisation though.