I guess a question I have is why the bytecode interpreter is encrypted in the first place? The only reason I can think of is to prevent cheap gray/black market knock-offs of the prop from appearing. But is that really a concern with such a specialized low volume chip as the Propeller? Maybe it is, I don't know. Someone please enlighten me?
PS: I'm not dissing the prop by any means. Maybe a lot more are sold than I am aware of. I was just comparing it to like the Intel 8051 series. And maybe knock-offs are a bigger issue than I think? Thus my question.
I don't really understand why the ROM is encrypted either, but I guess that there's some cloning history related to the basic stamp. One question I have is if we're only concerned about the spin interpreter in the on-chip ROM, then is it simply possible to make it so that this section of the ROM is not even readable by user programs. Perhaps a particular address space could only be readable if a COG is in a special init state. Maybe there's a reason why this can't be done.
Assuming that there isn't any obvious test path into the ROM (search for some JTAG related hacks on google), then it makes it harder to get to the ROM. I know that there are places that can generate netlists from silicon (I could ask for a reference if anyone doubts this), but you would have to spend some real money to get that. But you might still keep the ROM encrypted just to frustrate somebody who recovered it this way - although they might just clone the whole chip if they are motivated. Parallax probably makes this cheaper by using large process geometries I would think that parts of the instruction set or circuitry (e.g. counter modes) could be patented, and the spin interpreter itself is copyrighted. I never used the basic stamp but assume that it was mostly a software product or at least much more easy to clone using an off the shelf chip, whereas propeller is custom silicon so a much higher barrier to a cloner. My guess is that the propeller ROM has never been decrypted before because there wasn't sufficient interest.
If this potential prop II solution also involves protection of off-chip programs, then I would recommend that they hire an expert who has broken systems in the past. Read up on the DirecTV hacking, Hacking the XBox, DeCSS, HD DVD, Blueray, smart cards, etcetera. Keep in mind that people will glitch your clock and power supply to try to get your design into a desired state, and people will monitor your power consumption to try to determine what you're doing. If you have a true random number generator then people might also heat, cool, or irradiate your system, or otherwise abuse it to bias the generator.
I think that the Schneier's observation is relevant here:
"The only way to become a good algorithm designer is to be a good cryptanalyst:
to break algorithms. Lots of them. Again and again. Only after a student has
demonstrated his ability to cryptanalyze the algorithms of others will his own
designs be taken seriously."
KeithE you bring up a good point. I wonder if what everyone is looking at really IS the ROM code and not some spoof code in a shadow address area (something like the shadow registers in the cogs) that Chip put in just to throw people off, while the REAL interpreter code can only be accessed internally by a cog which is processing spin bytecode? A vehicle ECU supplier of ours does something similar. In order to program the ECU there must first be a seed/key exchange. According to the SAE standard the ECU is supposed to return one code for success and another code for failure. But their ECU always returns success even if the wrong key is sent. It's just that the new program won't flash into the permanent memory.
EDIT: I see Hippy mentioned this earlier. Sorry for the wasted bandwidth. Guess it's time for me to get a little shuteye too.
A partial decoding of the ROM so far. Only 32 fully decoded instructions and another 40 or so where the opcode has been determined. Need to try and identify another instruction to try and get an extra bit mapping out.
For me, time for bed ...
Edit : 348 instructions decoded if the instruction at $1E4 is a RET Now really off to be ...
If there were a 'secret flag' in the Cog/Decoder set when CogInit activated and that enabled decryption for the interpreter load and returned garbage or zeroes when $F004-$FFFF were read otherwise ( by Spin or PASM ), we'd not have anything at all to even start with.
....And Parallax wouldn't be able to·verify the ROM on each chip.
The ROM was encrypted (if you can call it that) to slow down would-be copy cats. When people know enough about something, they can go about replicating it rather casually. If some critical part is unknown, the difficulty can quickly exceed their appetite for work. I would like for everything to be open for customers, but I don't want to enable some thankless rip-off artists. That's why this is the way it is.
In the Propeller II, there will be some form of ROM protection for the booter code, only, since it will be responsible for encrypting data to and from the EEPROM using a unique ID in each chip. If this algorithm (in the booter code) is known, there goes the protection. Real random numbers will also be used to make every download different, so there's never a repeatable 1:1 correspondence between plain and encrypted data. The ultimate point of this is to protect USER code.
Chip said...
In the Propeller II, there will be some form of ROM protection for the booter code, only, since it will be responsible for encrypting data to and from the EEPROM using a unique ID in each chip. If this algorithm (in the booter code) is known, there goes the protection. Real random numbers will also be used to make every download different, so there's never a repeatable 1:1 correspondence between plain and encrypted data. The ultimate point of this is to protect USER code.
I can see that this will work well. But what if you wanted to distribute binary images? And I think I have just thought of the answer, the initial code will just contain some key to de-encrypt the distributed image. Would you provide some kind of tool to do this?
Chip said...
but I don't want to enable some thankless rip-off artists. That's why this is the way it is.
I believe that is covered under 'Nothing is impossible - it's simply a case of whether it's worth doing or not !'
The added difficulty will be a deterrent ..
John
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 'Necessity is the mother of invention'
Chip said...
In the Propeller II, there will be some form of ROM protection for the booter code, only, since it will be responsible for encrypting data to and from the EEPROM using a unique ID in each chip. If this algorithm (in the booter code) is known, there goes the protection. Real random numbers will also be used to make every download different, so there's never a repeatable 1:1 correspondence between plain and encrypted data. The ultimate point of this is to protect USER code.
I can see that this will work well. But what if you wanted to distribute binary images? And I think I have just thought of the answer, the initial code will just contain some key to de-encrypt the distributed image. Would you provide some kind of tool to do this?
Yeah, downloading using encryption is an option. Otherwise, it's just like the current Propeller - EEPROMs will be interchangeable.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 2/22/2008 9:58:00 AM GMT
Also, if someone just loaded a known binary then they would have a known encrypted image to compare and this would probably make it fairly easy to figure out what type of encryption is being used.
stevenmess2004 said...
Also, if someone just loaded a known binary then they would have a known encrypted image to compare and this would probably make it fairly easy to figure out what type of encryption is being used.
That's where real random numbers come in. The PC sends the binary image, then the Prop II uses its·unique·chip ID, along with an internally-generated·real random number, to encrypt the data into the EEPROM. When the EEPROM is read on boot-up, that previously-generated random number is read in some way from the EEPROM image, then in conjunction with the chip's unique ID, the EEPROM data is internally decrypted into RAM. So, downloading the same program over and over will always yield different results in the EEPROM, making it hard to figure out. (This is the idea, anyway - and it will be important not to tell Hippy too much about it). Even if the random number was stored in the same location each time, it might be indistinguishable from the data. It's critical that the algorithm in the booter be hidden from everyone to make this work - that's why there must be some ROM protection.
stevenmess2004 said...
(c) Distribution of what? certain instructions? 1s and 0s? zcr flags?
You generally start an encryption task by assessing how much the code differs from noise. t it doesn't much and you have no bilingue you can stop then
Statistical data are extremely helpful - especially when starting brute force methods - to assess the decoding results automatically.
It this special case a distribution of the 0/1 against the bitposition is a useful systematic approach. You can compare it to other code (Phil did something like that with GRAPHICS); but you need more pieces to get an "feeling" for the range...
Arbitrary "data" through the code is an extremely ugly way to complicate statistical analysis, but we can hope there was not much space left in the interpreter COG Data near the end is not such a problem, as you can incrementally reduce the address range for the investigation to identify the code/data threshhold..
This all will break down when it is no "true" code in that area. In old fashioned simple minded deciphering it
counterfighted nearly all decoding attempts when the "language" of the message was not known... Evans succeeded for Linear-B only after he got the unlikely (!) intuition that the texts were "Greek"
And don't forget there is a second piece of encrypted code in the ROM...
after stepping through and back to line 002 you get
000 long 4
001 address of start of header, probably on stack +2 = pointer to word in hub that stores start of memory
002 ADD $001,#2 WR <-
003 RDWORD ?,$201 WR = RDWORD ?+1,$1
004 ADD $003,#$100 WR
005 ADD $003,#$100 WR
006 DJNZ $000,#$002 WR
All looks good and it will go through and read in the
-Base of program
-Base of variables
-Base of stack
-Initial program counter
-Initial stack counter
That is a nice trick to increment the RD word destination by 1 that I haven't seen before.
All this is obviously stored on the stack when starting a new spin cog and could allow some interesting things (like now knowing how to start spin cogs from assembly ).
Instruction 008 is interesting as it seems to do nothing at startup although it may be used in other places.
Edit: I didn't see hippy's post that already explained all this... Should make sure that I read the entire thread before I go sprouting off...
Post Edited (stevenmess2004) : 2/22/2008 11:40:08 AM GMT
A couple of observations if hippy's code is correct,
-There are 5 longs that get overwritten and therefore whatever is in those locations does nothing (probably near the end of the cog)
-At least two longs are needed for storing variables from main memory
-Since there is an instruction to set the first long to zero, this would seem a likely place to put these variables
-Also the first 7 or 8 longs are probably not needed after startup.
Edit: Also need a long to store the instruction that is going to be decoded in.
Post Edited (stevenmess2004) : 2/22/2008 11:37:37 AM GMT
Instruction 008 is interesting as it seems to do nothing at startup although it may be used in other places.
It's the start of the bytecode fetch-execute loop as best I can tell. There are a lot of "JMP #$008" in the code.
There are 5 longs that get overwritten and therefore whatever is in those locations does nothing (probably
near the end of the cog)
Useful guess. That could explain the longs after what look like constants. Any valus there may be used only
when reading ROM directly, and are effectively RES in the source. There are six longs at the end of the code
which would fit the bill ( don't decode to sensible or useful looking numbers ).
Also the first 7 or 8 longs are probably not needed after startup.
That looks correct. The interpreter uses at least $000-$004 as its working registers.
@ Chip ...
The ROM was encrypted (if you can call it that) to slow down would-be copy cats.
I am confident I am on the right track now. I am sure that what you said when you threw open the challenge
was while you thought you were wearing a cloak of invincibility ( and in hindsight perhaps spoken in haste )
so before posting something which could throw the door wide open where do you / Parallax currently stand
on this ?
The key to the door appears to now be out in the open, even if the rough edges haven't been filed down. It
would still take some effort for people less familiar with the Propeller to finish the task.
There's a big difference though in knowing how to get at the solution and having the solution provided.
Although the challenge was offered up fairly and squarely I don't think either you or I thought it would be
solved ( and certainly not quickly ). For my part, a retraction of that challenge would not be unreasonable in
terms of protecting Parallax IP.
I for one - having enjoyed the Parallax products and generosity of company & staff for several years - and would hope it would stay invisible. I'd hate to see a lot of Propeller "clones" appearing for 1/2 price and 1/10th support and causing Parallax problems.....
An update on progress, but no listing until I've heard from Chip ... All instruction opcodes decoded.
Still stuck on WC and WZ bits and all conditional execution bits. Once an obvious IF_C or IF_Z pops
out from visual inspection that should crack it. Address bits aren't all resolved yet. Although it's
obvious in most places what the addresses should be, my software doesn't fill in the gaps because
it cannot prove it to be the case. Have 15 of 32 bits mapped, 17 to go ( WC, WZ, 4 x cond, 7 x dst,
4 x src ).
Anyone want to try and work out what this code would actually be ... ?
The two CMPS are likely to be "CMPS $000,$001" and "CMP $002,$000". The three XOR's swap $002 with $001, probably used in Case, LookUp, LookDown, and Register Bit Ranges.
>And Parallax wouldn't be able to verify the ROM on each chip
MEMBIST is pretty standard. Maybe parallax relies on functional tests rather than scan/logicbist/membist.
I don't understand why the ROM reads of the interpreter couldn't be locked out by user programs. I assume that when a cog is loaded there's some state that's available that could enable access to the SPIN interpreter. Isn't hardware used to load the 512 longs?
>Maybe someone gets the idea to clone the Prop in an FPGA?
If you cloned the prop in an fpga you would probably have a really expensive prop that wouldn't have all of the features of the real thing, and might run more slowly. Maybe you could fit in more COGs, but you could also buy multiple propeller chips. I would guess that the hub would cause a nightmare for fpga routing.
I've just run a statistical optimization on the first four bits (31 .. 28) of the i-field, correlating them to those of the floating-point ASM code. With a best correlation coefficient of 0.85, I got the following mapping:
····31 <- 3 ····30 <- 7 ····29 <- 21 ····28 <- 12
The first three agree with one of your earlier postings, but you haven't posted the mapping for bit 28 yet. Can you tell me if my result (12) agrees with yours?
Even though I'm behind with these results, I feel a little more confident in the method now (and certainly more so if bit 28 is correct). I say a "little bit", because the second-best permutation yielded a correlation coefficient of 0.83, which is too close for comfort. The next step will be to use those results to ferret out the remaining two bits using the same technique (only 756 remaining permutations). The only point in doing this, of course, is to see how much can be gleaned before having to look at the code and bring experience and intuition into play.
The ROM was encrypted (if you can call it that) to slow down would-be copy cats.
I am confident I am on the right track now. I am sure that what you said when you threw open the challenge
was while you thought you were wearing a cloak of invincibility ( and in hindsight perhaps spoken in haste )
so before posting something which could throw the door wide open where do you / Parallax currently stand
on this ?
The key to the door appears to now be out in the open, even if the rough edges haven't been filed down. It
would still take some effort for people less familiar with the Propeller to finish the task.
There's a big difference though in knowing how to get at the solution and having the solution provided.
Although the challenge was offered up fairly and squarely I don't think either you or I thought it would be
solved ( and certainly not quickly ). For my part, a retraction of that challenge would not be unreasonable in
terms of protecting Parallax IP.
That's right! I didn't think anyone would figure it out, especially so quickly. That's life, though, and while I feel a tinge of dismay and humiliation, I'm·mostly glad for the experience. I appreciate your offer, Hippy, but if you can complete the job, I'll still post the code.
I can see where adding one more level, beyond static bit-swapping, would have really made things difficult (or, so I think).·I didn't want to introduce any more than minimal propogation delay through the hub, though, so I used simple pass gates·to do the bit swapping. Whenever a cog loads from ROM, these muxes rearrange the data bits.
I'm sure that if the source gets posted, it will lead to some improvements. You'll also be able to do a lot more in the way of dynamic objects, as the interpreter can now be malleable in RAM. And, I'll have to point out some things I realize could have been done·better, in hindsight.
As far as copycats go, they've still got other hurdles to overcome, not to mention the expense of making a chip. And, it is true, that the volume of Propeller chips we're selling wouldn't interest any of the big boys, or even the copycats. It's pretty much a labor of love. We hope, of course, that we'll sell·lots of them, but it's not necessary for the continuance of the Propeller.
Comments
PS: I'm not dissing the prop by any means. Maybe a lot more are sold than I am aware of. I was just comparing it to like the Intel 8051 series. And maybe knock-offs are a bigger issue than I think? Thus my question.
Post Edited (Beanie2k) : 2/22/2008 4:47:36 AM GMT
Assuming that there isn't any obvious test path into the ROM (search for some JTAG related hacks on google), then it makes it harder to get to the ROM. I know that there are places that can generate netlists from silicon (I could ask for a reference if anyone doubts this), but you would have to spend some real money to get that. But you might still keep the ROM encrypted just to frustrate somebody who recovered it this way - although they might just clone the whole chip if they are motivated. Parallax probably makes this cheaper by using large process geometries
If this potential prop II solution also involves protection of off-chip programs, then I would recommend that they hire an expert who has broken systems in the past. Read up on the DirecTV hacking, Hacking the XBox, DeCSS, HD DVD, Blueray, smart cards, etcetera. Keep in mind that people will glitch your clock and power supply to try to get your design into a desired state, and people will monitor your power consumption to try to determine what you're doing. If you have a true random number generator then people might also heat, cool, or irradiate your system, or otherwise abuse it to bias the generator.
I think that the Schneier's observation is relevant here:
"The only way to become a good algorithm designer is to be a good cryptanalyst:
to break algorithms. Lots of them. Again and again. Only after a student has
demonstrated his ability to cryptanalyze the algorithms of others will his own
designs be taken seriously."
Anyways I'm no expert.
http://consulting.effectivesoft.com/example_tdb.php?cat_id=11
www.taeus.com does a lot of legal related work, and it's interesting to read about them and their capabilities as well.
I'm not sure who my company has used in the past. For the chips that I've worked on obfuscation has never been a requirement.
EDIT: I see Hippy mentioned this earlier. Sorry for the wasted bandwidth. Guess it's time for me to get a little shuteye too.
Post Edited (Beanie2k) : 2/22/2008 8:31:11 AM GMT
For me, time for bed ...
Edit : 348 instructions decoded if the instruction at $1E4 is a RET
Post Edited (hippy) : 2/22/2008 7:30:13 AM GMT
'Looks really good so far! You're faring much better with your approach than I am with statistics. I think the whole enchilada is within your grasp!
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Maybe someone gets the idea to clone the Prop in an FPGA?
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
How about an internal self test which requires that Parallax inputs the whole correct image for comparison?
(There's not room for a lot more on the current die... )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
In the Propeller II, there will be some form of ROM protection for the booter code, only, since it will be responsible for encrypting data to and from the EEPROM using a unique ID in each chip. If this algorithm (in the booter code) is known, there goes the protection. Real random numbers will also be used to make every download different, so there's never a repeatable 1:1 correspondence between plain and encrypted data. The ultimate point of this is to protect USER code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
I believe that is covered under 'Nothing is impossible - it's simply a case of whether it's worth doing or not !'
The added difficulty will be a deterrent ..
John
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 2/22/2008 9:58:00 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Statistical data are extremely helpful - especially when starting brute force methods - to assess the decoding results automatically.
It this special case a distribution of the 0/1 against the bitposition is a useful systematic approach. You can compare it to other code (Phil did something like that with GRAPHICS); but you need more pieces to get an "feeling" for the range...
Arbitrary "data" through the code is an extremely ugly way to complicate statistical analysis, but we can hope there was not much space left in the interpreter COG
This all will break down when it is no "true" code in that area. In old fashioned simple minded deciphering it
counterfighted nearly all decoding attempts when the "language" of the message was not known... Evans succeeded for Linear-B only after he got the unlikely (!) intuition that the texts were "Greek"
And don't forget there is a second piece of encrypted code in the ROM...
Post Edited (deSilva) : 2/22/2008 10:27:42 AM GMT
after stepping through and back to line 002 you get
All looks good and it will go through and read in the
-Base of program
-Base of variables
-Base of stack
-Initial program counter
-Initial stack counter
That is a nice trick to increment the RD word destination by 1 that I haven't seen before.
All this is obviously stored on the stack when starting a new spin cog and could allow some interesting things (like now knowing how to start spin cogs from assembly
Instruction 008 is interesting as it seems to do nothing at startup although it may be used in other places.
Edit: I didn't see hippy's post that already explained all this... Should make sure that I read the entire thread before I go sprouting off...
Post Edited (stevenmess2004) : 2/22/2008 11:40:08 AM GMT
-There are 5 longs that get overwritten and therefore whatever is in those locations does nothing (probably near the end of the cog)
-At least two longs are needed for storing variables from main memory
-Since there is an instruction to set the first long to zero, this would seem a likely place to put these variables
-Also the first 7 or 8 longs are probably not needed after startup.
Edit: Also need a long to store the instruction that is going to be decoded in.
Post Edited (stevenmess2004) : 2/22/2008 11:37:37 AM GMT
Instruction 008 is interesting as it seems to do nothing at startup although it may be used in other places.
It's the start of the bytecode fetch-execute loop as best I can tell. There are a lot of "JMP #$008" in the code.
There are 5 longs that get overwritten and therefore whatever is in those locations does nothing (probably
near the end of the cog)
Useful guess. That could explain the longs after what look like constants. Any valus there may be used only
when reading ROM directly, and are effectively RES in the source. There are six longs at the end of the code
which would fit the bill ( don't decode to sensible or useful looking numbers ).
Also the first 7 or 8 longs are probably not needed after startup.
That looks correct. The interpreter uses at least $000-$004 as its working registers.
@ Chip ...
The ROM was encrypted (if you can call it that) to slow down would-be copy cats.
I am confident I am on the right track now. I am sure that what you said when you threw open the challenge
was while you thought you were wearing a cloak of invincibility ( and in hindsight perhaps spoken in haste )
so before posting something which could throw the door wide open where do you / Parallax currently stand
on this ?
The key to the door appears to now be out in the open, even if the rough edges haven't been filed down. It
would still take some effort for people less familiar with the Propeller to finish the task.
There's a big difference though in knowing how to get at the solution and having the solution provided.
Although the challenge was offered up fairly and squarely I don't think either you or I thought it would be
solved ( and certainly not quickly ). For my part, a retraction of that challenge would not be unreasonable in
terms of protecting Parallax IP.
Still stuck on WC and WZ bits and all conditional execution bits. Once an obvious IF_C or IF_Z pops
out from visual inspection that should crack it. Address bits aren't all resolved yet. Although it's
obvious in most places what the addresses should be, my software doesn't fill in the gaps because
it cannot prove it to be the case. Have 15 of 32 bits mapped, 17 to go ( WC, WZ, 4 x cond, 7 x dst,
4 x src ).
Anyone want to try and work out what this code would actually be ... ?
Encryptd opcode zcri cccc ddddddddd sssssssss 003C0DC0 011011 0010 ---- 000000010 000000001 IF_? XOR $002,$001 063809C0 011011 0010 ---- 000000001 000000010 IF_? XOR $001,$002 003C0DC0 011011 0010 ---- 000000010 000000001 IF_? XOR $002,$001 00024D89 110000 --00 1111 0000--000 000000001 CMPS $0--,$001 {WC?} {WZ?} 00064089 110000 --00 ---- 0000--010 000000000 IF_? CMPS $0--,$000 {WC?} {WZ?} 0008D9C1 010111 0001 1111 000000000 000000000 RETThe two CMPS are likely to be "CMPS $000,$001" and "CMP $002,$000". The three XOR's swap $002 with $001, probably used in Case, LookUp, LookDown, and Register Bit Ranges.
Post Edited (hippy) : 2/22/2008 4:21:11 PM GMT
I hope in a round about way Chip and the Parallax team will be grateful for your outstanding work. Better now than after Prop II.
Ron
MEMBIST is pretty standard. Maybe parallax relies on functional tests rather than scan/logicbist/membist.
I don't understand why the ROM reads of the interpreter couldn't be locked out by user programs. I assume that when a cog is loaded there's some state that's available that could enable access to the SPIN interpreter. Isn't hardware used to load the 512 longs?
>Maybe someone gets the idea to clone the Prop in an FPGA?
If you cloned the prop in an fpga you would probably have a really expensive prop that wouldn't have all of the features of the real thing, and might run more slowly. Maybe you could fit in more COGs, but you could also buy multiple propeller chips. I would guess that the hub would cause a nightmare for fpga routing.
I've just run a statistical optimization on the first four bits (31 .. 28) of the i-field, correlating them to those of the floating-point ASM code. With a best correlation coefficient of 0.85, I got the following mapping:
····31 <- 3
····30 <- 7
····29 <- 21
····28 <- 12
The first three agree with one of your earlier postings, but you haven't posted the mapping for bit 28 yet. Can you tell me if my result (12) agrees with yours?
Even though I'm behind with these results, I feel a little more confident in the method now (and certainly more so if bit 28 is correct). I say a "little bit", because the second-best permutation yielded a correlation coefficient of 0.83, which is too close for comfort. The next step will be to use those results to ferret out the remaining two bits using the same technique (only 756 remaining permutations). The only point in doing this, of course, is to see how much can be gleaned before having to look at the code and bring experience and intuition into play.
Thanks,
Phil
I can see where adding one more level, beyond static bit-swapping, would have really made things difficult (or, so I think).·I didn't want to introduce any more than minimal propogation delay through the hub, though, so I used simple pass gates·to do the bit swapping. Whenever a cog loads from ROM, these muxes rearrange the data bits.
I'm sure that if the source gets posted, it will lead to some improvements. You'll also be able to do a lot more in the way of dynamic objects, as the interpreter can now be malleable in RAM. And, I'll have to point out some things I realize could have been done·better, in hindsight.
As far as copycats go, they've still got other hurdles to overcome, not to mention the expense of making a chip. And, it is true, that the volume of Propeller chips we're selling wouldn't interest any of the big boys, or even the copycats. It's pretty much a labor of love. We hope, of course, that we'll sell·lots of them, but it's not necessary for the continuance of the Propeller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.