I just watched the Video demo (no sound) on my Hybrid board. It's even more cool! live.
@Coley
I connected a VGA connector to a resistor board to the expansion board( I kept the wiring on the expansion board to a minimum so I could re-use it later) It's not pretty but it works. I had to remove the SD card as well and change the Xtal to 5MHz(actually a Fox 5.06880 that I found in my old Xtal pile)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob
Post Edited (Bob Lawrence (VE1RLL)) : 4/15/2009 10:24:22 AM GMT
Well it aint spin except for "most" words in the header and starting the first cog [noparse];)[/noparse]
The word at address $18 $2c353535 says coginit(0,0,0) which means the first cog PASM instruction is $5c7c0007 at $0 which means jump to long #$7 which is $1c. Address $1c contains $a0fc060b or mov $3, #$b which is the beginning of some init stuff. That's as far as I get ... will someone with a PASM disassembler please stand up ? Maybe you could simulate this in GEAR.
Oh ! I did not see this post before so I was starting the challenge alone (as published on linus' website) !
I tried to use proplist to disassemble and gear to run but I was first disappointed by the header which is not compliant by what I saw in a Parallax doc (frequencies, checksum). So I was wondering why it was starting by 70007C5C. so thanks jazzed for the explanation... (so the frequencies in the header are used when compiling/assembling) ?
Now I wonder why no strings or bitmap appear in the eeprom, possible to write a short decompressor in such few memory ?
So I will follow this thread actively and try to help [noparse]:)[/noparse]
Shazz said...
... I was first disappointed by the header which is not compliant by what I saw in a Parallax doc (frequencies, checksum).
While the first long is - by convention - used as the clock frequency, its actual value doesn't really matter. Byte 4 ($6F) OTOH looks like a valid clock mode (XTAL1 + PLL16X) which is the important bit.
As the behavior differs from loading the binary in RAM or in EEPROM, it means that it's not equivalent, somebody can explain me the difference ? While reading the Propeller Manual, I did not find any obvious difference, it is said the entire 32Kb are written to the RAM. So I may think that's not the truth...
Interesting what you get by Googling "Quaerendo Invenietis" ... seek and ye shall find ... wonder what other shades of meaning it has. I don't know the difference between loading RAM or EEPROM .... You can look at the rom interpreter source which is on line: http://forums.parallax.com/forums/default.aspx?f=25&m=252691
jazzed, I tried PropLoad.. fails, says names have changes I have to use PropView... I run PropView.. Execution error 13...
I tried PropList, it works but the result is quite different :
PropList Propeller Bytecode Disassembler - Version 1.01 #0245 (C) 2008-2009, AiChip Industries
Disassembly of turbulence.eeprom
================================
Addr Org Instruction Label Opcode Operand
---- --- ----------- ----- ------ -------
0000 00 00 7C 5C I0 LONG 1551630336 ; Clock Freq
0004 6F BYTE XTAL1_PLL16x ; Clock Mode
0005 A6 BYTE $A6 ; Checksum - INCORRECT
0006 10 00 WORD O1 ; PBASE - Base of Program
0008 C4 7F WORD VBASE ; VBASE - Base of Variables
000A CC 7F WORD SBASE ; SBASE - Base of Stack
000C 18 00 WORD S3 ; PINIT - Initial Program Counter
000E D0 7F WORD SINIT ; SINIT - Initial Stack Pointer
PBASE ALIGN OBJECT
0010 B4 7F 02 00 O1 LINK VBASE, 1, 0 ; +0 - Standalone program, no sub-objects
0014 08 00 00 00 X2 LINK S3 ; +1
PINIT ALIGN SPIN
0018 35 S3 PUSH 0
0019 35 PUSH 0
001A 35 PUSH 0
001B 2C COGISUB
001C 0B 06 JPT T4
001E FC EQ
001F A0 30 68 FC PUSH MEM[noparse][[/noparse]].WORD
0023 5C ?? BYTE $5C
0024 04 0A T4 GOTO J5
...
I'll dig into the rom interpreter... I need to understand what's going on (and what I do to run the hidden screen !)
ok.. I took a look at Chip's booter and if the launch step is the same (i.e. chedck pbase, set clock, run interpreter), the way to copy the data into the RAM is not the same. But I did not yet understand what makes a real difference...
I suspect you will find he is overwriting lots of his original EE to RAM download to use for scratch RAM, then reloading from the EE when the overwritten data are actually needed. Notice in the intro he says the Prop has "48 kilobytes of RAM." Demos are about creatively using every last byte, and while none of the stuff on the demo requires a tremendous amount of source bitmap, some of it does require quite a bit of scratchpad.
localroger said...
I suspect you will find he is overwriting lots of his original EE to RAM download to use for scratch RAM, then reloading from the EE when the overwritten data are actually needed. Notice in the intro he says the Prop has "48 kilobytes of RAM." Demos are about creatively using every last byte, and while none of the stuff on the demo requires a tremendous amount of source bitmap, some of it does require quite a bit of scratchpad.
Yeah, I understood that this night (hard to sleep !)
In fact, I took the problem upside down, loading from EEPROM or RAM is the same (easy to check, if the demo is already in the EEPROM, if you load it from the IDE in RAM it works), the difference is after, I guess in fact the EEPROM consists in only a tiny loader/unpacker/VGA Text Driver and a big bunch of packed data, the EEPROM works like a cheap 32Kb mass storage.
1. So in RAM then one cog only the loader/depacker/driver is init'd and this one, as Chip's booter does, is trying to read packed data from the EEPROM, unpack them in Hub RAM, call the good coginit.
2. If it cannot find what it looks for, it displays the message to load the demo in the EEPROM.
So Roger as you said the RAM is probably always updated by this loader each time a new screen has to be shown and the loader does the coginit to transfer those new data to available cogs.
What I don't understand yet, why don't we see the ASCII message ("please load from eeprom blablabla") in cleartext... is it an anagram of Quaerendo Invenietis ? [noparse]:D[/noparse]
Maybe I took another dead end... but I feel more confident this time [noparse]:)[/noparse]
You don't see the string because it's also packed. To have max. room for your demo code you'd pack everything but the packer and the first line of code, which unpacks the first lines of demo code which obviously is the check if the code is available in EEPROM.
I'd bet that the whole demo runs in PASM. It's using one COG to unpack code. Fetching it via I2C and transferring it to COG-RAM via port overlaying the old code - as it is much faster than unpacking it to HUB-RAM and then loading it to COG-RAM. The whole HUB-memory can then be used for data. Running one part of the demo, one or two COGs can already prepare the data for the next part (e.g. a mipmap of the picture).
MagIO2 said...
You don't see the string because it's also packed. To have max. room for your demo code you'd pack everything but the packer and the first line of code, which unpacks the first lines of demo code which obviously is the check if the code is available in EEPROM.
Hummmmm, for sure it's not clear text... but packed I don't know... As the text appears if the EEPROM is not filled, I understand the text is not fetched from the packed data.. So it means in this case this packed data is fetched from RAM by default (sort of exception)... yep makes sense.. So first goal isolate the depacker code ! Any good disassembler available ?
MagIO2 said...
I'd bet that the whole demo runs in PASM. It's using one COG to unpack code. Fetching it via I2C and transferring it to COG-RAM via port overlaying the old code - as it is much faster than unpacking it to HUB-RAM and then loading it to COG-RAM. The whole HUB-memory can then be used for data. Running one part of the demo, one or two COGs can already prepare the data for the next part (e.g. a mipmap of the picture).
Makes sense too, I did not know that you can directly from one cog update RAM of another cog without passing thru the hub. So globally the Hub RAM is the VGA frame buffer (I don't know if it is possible to use the Hub RAM directly as a Frame buffer of the rdlong penalty is too much for filling the waitvid...) ?
Shazz said...
I did not know that you can directly from one cog update RAM of another cog without passing thru the hub. So globally the Hub RAM is the VGA frame buffer (I don't know if it is possible to use the Hub RAM directly as a Frame buffer of the rdlong penalty is too much for filling the waitvid...) ?
You can pass data from one cog to another cog using the I/O pins and bypass the HUB RAM, it sounds like from previous posts that this may be happening.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I. www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT www.tdswieter.com
Makes sense too, I did not know that you can directly from one cog update RAM of another cog without passing thru the hub. So globally the Hub RAM is the VGA frame buffer (I don't know if it is possible to use the Hub RAM directly as a Frame buffer of the rdlong penalty is too much for filling the waitvid...) ?
It is posible at hi comunicate COG to COG with PINs 0..9
With no attention on HUB
Ps. Pins 0..9 give 8 Data bits and 2 signaling lines
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Ah ! very cool !
I tried to use pPropellerSim but I was not able to load what I want so I gave up... Ca you export the full disassembly listing and post it ? I'd like to follow it carefully and try understand what the routine in $030 is doing (coginit OUTB ???)
I can confirm that there is data being sent on the IO pins, as a lot of them "goes crasy" between the different parts in the Demo.
He uses up to 3 different graphics layers, with different resolutions and palettes, by using multiply video generators at the same time.
I'm not quite sure how the transparency works though, as there seems to be some "in between" colors of the mixed sources (like the SNES)
It would be easy to do it using only masking, like some kind of genlock/overlay, the same way as the dual playfield mode works on the Amiga.
One cog is loaded with the music player + music data, and just keeps on playing until the there is no more data.
You can actually hear the "PSG" still making sounds after the demos is finished, because the "envelopes" doesn't mute the "oscilators" entirely.
I'm quite sure that he uses some kind of "raster" technique for the blue zooming/rotating tube effect.
The listing is as I posted it, it does not execute anything outside that small range. After some 7000 cycles executes the coginit OUTB. OUTB has a value of $00_a8_0b_0f.
Address for PAR = 00 00 00 00 10 10 10 = $00_a8
Address of code to load = %00_00_00_10 11 00_00 << 2 = %10 11000000 = $2c0
There is some code @2c0 mostly word writes to HUB RAM but the simulator fails when reading an address from memory. I have to add a mask.
Here is the disassembly of $2c0 till it fails at the djnz :-(
String list file attached(it's a little long to post it all):
Example 1:
seg000:00000018 00000005 C 555,\v
seg000:000000AB 00000005 C h/H<b
seg000:000000D8 00000018 C [noparse][[/noparse] quaerendo invenietis ]
seg000:0000013F 00000006 unicode d
seg000:0000022A 00000006 C \bHB\b A
seg000:0000024B 00000006 C @0rE\"
seg000:000002E2 00000010 unicode \x1B*9GRcmx
seg000:00000302 00000006 unicode 9Yg
Example 2:
seg000:00007A11 00000008 C @&igbjjB
seg000:00007A1D 00000005 C 2[noparse][[/noparse]KgS
seg000:00007A39 00000005 C t\t\r\"{
seg000:00007ACE 00000005 C \r=i\b,
seg000:00007ADB 00000005 C ],ml\b
seg000:00007AFF 00000005 C v3 L`
seg000:00007B55 00000005 C O 46,
seg000:00007B5B 00000008 C rS7S'O{;
seg000:00007B81 00000005 C +4DM\r
seg000:00007C18 00000006 C peU77
seg000:00007D51 00000005 C oW<Ct
seg000:00007FA2 0000000D C turbulence
seg000:00007FB2 0000000D C lft 2009
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob
Post Edited (Bob Lawrence (VE1RLL)) : 4/16/2009 12:33:31 PM GMT
kuroneko said...
It may be packed (I simply don't know) but then why would you waste 0K5 bytes at the end? Just to fill the 32K? It looks more like plain obfuscation.
Oh you're right, that's just a guess but....
1. considering the bunch of stuff in the demo (rotozoom lenna bitmap, turbulence logo, the rose flower, the trees, 2 songs...) it starts to make some kbytes
2. in his Craft demo, Linus used a packer if I'm not wrong to depack on the fly data from the eeprom
3. in case of plain obfuscation, pattern/sequences are still there and looking at the binary, I did not find any pattern (usually very easy to "see" bitmaps & music stuff when watching the hexadecimal stuff), looks very condense like packed data. But ok not a formal proof
4. as Linus says in the hidden screen, he cannot filled the 32 Kb ! no more motivation+idea ! [noparse]:D[/noparse] So yes, room left...
But I agree... you can be right [noparse]:)[/noparse]
@CosmicBob : funny extract [noparse]:)[/noparse] Sometimes I think I recognize words from the hidden part scroll text [noparse]:)[/noparse] but I guess that's an optical illusion [noparse]:)[/noparse] But definitively it looks like packed data as the size is smaller than real text (comparing to obfuscation/encryption)
@Ahle2 : I don't know how you did to understand all of that but really interesting ! And WOW the display technique seems coming from another palnet (in my noob mind)
Community hacking is really fun [noparse]:)[/noparse] I learn a lot !
@Shazz
He he, i don't actually now anything, pure speculation using the exclusion method (there really isn't many options)
It kind of helps to know how those effects were made on the C64/Amiga ( which i do know )
The zooming part of the "roto zoomer", could have been done by altering some video parameters on the fly.
It's seems like everytime there is more than one layer of graphics on screen, some pins goes wild.
Transfering layer data between cogs/Syncing video generators?
I can't wait to see how this goes.. Being a noob, I'll just monitor, it helps if one know the language before one tries to hack.. I'm still going through the networking code trying to figure it out..
But that being said, I look forward in knowing how to pack/unpack code .. I think the time hit to unpack and move code into ram is a small price to pay considering the extra storage one can get in the eeprom..
I am assuming the same could be done for a 64k and a 128k??
Comments
@Coley
I connected a VGA connector to a resistor board to the expansion board( I kept the wiring on the expansion board to a minimum so I could re-use it later) It's not pretty but it works.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob
Post Edited (Bob Lawrence (VE1RLL)) : 4/15/2009 10:24:22 AM GMT
The word at address $18 $2c353535 says coginit(0,0,0) which means the first cog PASM instruction is $5c7c0007 at $0 which means jump to long #$7 which is $1c. Address $1c contains $a0fc060b or mov $3, #$b which is the beginning of some init stuff. That's as far as I get ... will someone with a PASM disassembler please stand up ? Maybe you could simulate this in GEAR.
BTW: Great demo Linus.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
I tried to use proplist to disassemble and gear to run but I was first disappointed by the header which is not compliant by what I saw in a Parallax doc (frequencies, checksum). So I was wondering why it was starting by 70007C5C. so thanks jazzed for the explanation... (so the frequencies in the header are used when compiling/assembling) ?
Now I wonder why no strings or bitmap appear in the eeprom, possible to write a short decompressor in such few memory ?
So I will follow this thread actively and try to help [noparse]:)[/noparse]
Use Hippy's VB6 PropLoad.zip from http://forums.parallax.com/forums/default.aspx?f=25&p=1&m=205628
Enable asm debug with "Help->Debug Asmb" then add some debug info like instruction word column ... need to add conditional mnemonics or interpret manually.
Here's some partial dumps ...
remember that to see something in the data referenced by an instruction, the address needs *= 4.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
I tried PropList, it works but the result is quite different :
PropList Propeller Bytecode Disassembler - Version 1.01 #0245 (C) 2008-2009, AiChip Industries Disassembly of turbulence.eeprom ================================ Addr Org Instruction Label Opcode Operand ---- --- ----------- ----- ------ ------- 0000 00 00 7C 5C I0 LONG 1551630336 ; Clock Freq 0004 6F BYTE XTAL1_PLL16x ; Clock Mode 0005 A6 BYTE $A6 ; Checksum - INCORRECT 0006 10 00 WORD O1 ; PBASE - Base of Program 0008 C4 7F WORD VBASE ; VBASE - Base of Variables 000A CC 7F WORD SBASE ; SBASE - Base of Stack 000C 18 00 WORD S3 ; PINIT - Initial Program Counter 000E D0 7F WORD SINIT ; SINIT - Initial Stack Pointer PBASE ALIGN OBJECT 0010 B4 7F 02 00 O1 LINK VBASE, 1, 0 ; +0 - Standalone program, no sub-objects 0014 08 00 00 00 X2 LINK S3 ; +1 PINIT ALIGN SPIN 0018 35 S3 PUSH 0 0019 35 PUSH 0 001A 35 PUSH 0 001B 2C COGISUB 001C 0B 06 JPT T4 001E FC EQ 001F A0 30 68 FC PUSH MEM[noparse][[/noparse]].WORD 0023 5C ?? BYTE $5C 0024 04 0A T4 GOTO J5 ...I'll dig into the rom interpreter... I need to understand what's going on (and what I do to run the hidden screen !)
ok.. I took a look at Chip's booter and if the launch step is the same (i.e. chedck pbase, set clock, run interpreter), the way to copy the data into the RAM is not the same. But I did not yet understand what makes a real difference...
Post Edited (Shazz) : 4/15/2009 9:17:53 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Basic Stamp,···· Propeller,·· · SX,·· FUN!
START:·
>Proccessing Data. . . .··
>Task Complete. . .·.
>Saving Data. . . .
>Entering SLEEP Mode. . . .
>Signing OFF
·
Yeah, I understood that this night (hard to sleep !)
In fact, I took the problem upside down, loading from EEPROM or RAM is the same (easy to check, if the demo is already in the EEPROM, if you load it from the IDE in RAM it works), the difference is after, I guess in fact the EEPROM consists in only a tiny loader/unpacker/VGA Text Driver and a big bunch of packed data, the EEPROM works like a cheap 32Kb mass storage.
1. So in RAM then one cog only the loader/depacker/driver is init'd and this one, as Chip's booter does, is trying to read packed data from the EEPROM, unpack them in Hub RAM, call the good coginit.
2. If it cannot find what it looks for, it displays the message to load the demo in the EEPROM.
So Roger as you said the RAM is probably always updated by this loader each time a new screen has to be shown and the loader does the coginit to transfer those new data to available cogs.
What I don't understand yet, why don't we see the ASCII message ("please load from eeprom blablabla") in cleartext... is it an anagram of Quaerendo Invenietis ? [noparse]:D[/noparse]
Maybe I took another dead end... but I feel more confident this time [noparse]:)[/noparse]
Post Edited (Shazz) : 4/16/2009 7:17:27 AM GMT
I'd bet that the whole demo runs in PASM. It's using one COG to unpack code. Fetching it via I2C and transferring it to COG-RAM via port overlaying the old code - as it is much faster than unpacking it to HUB-RAM and then loading it to COG-RAM. The whole HUB-memory can then be used for data. Running one part of the demo, one or two COGs can already prepare the data for the next part (e.g. a mipmap of the picture).
Hummmmm, for sure it's not clear text... but packed I don't know... As the text appears if the EEPROM is not filled, I understand the text is not fetched from the packed data.. So it means in this case this packed data is fetched from RAM by default (sort of exception)... yep makes sense.. So first goal isolate the depacker code ! Any good disassembler available ?
Makes sense too, I did not know that you can directly from one cog update RAM of another cog without passing thru the hub. So globally the Hub RAM is the VGA frame buffer (I don't know if it is possible to use the Hub RAM directly as a Frame buffer of the rdlong penalty is too much for filling the waitvid...) ?
You can pass data from one cog to another cog using the I/O pins and bypass the HUB RAM, it sounds like from previous posts that this may be happening.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT
www.tdswieter.com
It is posible at hi comunicate COG to COG with PINs 0..9
With no attention on HUB
Ps. Pins 0..9 give 8 Data bits and 2 signaling lines
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Post Edited (Sapieha) : 4/16/2009 9:06:23 AM GMT
I'm using a not-yet-fully-functional-but-still-useful version of unpublished pPropellerSim everyone forgot about
Edit: Do not pay attention to the label's names, they are the interpreter's.
I tried to use pPropellerSim but I was not able to load what I want so I gave up... Ca you export the full disassembly listing and post it ? I'd like to follow it carefully and try understand what the routine in $030 is doing (coginit OUTB ???)
It may be packed (I simply don't know) but then why would you waste 0K5 bytes at the end? Just to fill the 32K? It looks more like plain obfuscation.
He uses up to 3 different graphics layers, with different resolutions and palettes, by using multiply video generators at the same time.
I'm not quite sure how the transparency works though, as there seems to be some "in between" colors of the mixed sources (like the SNES)
It would be easy to do it using only masking, like some kind of genlock/overlay, the same way as the dual playfield mode works on the Amiga.
One cog is loaded with the music player + music data, and just keeps on playing until the there is no more data.
You can actually hear the "PSG" still making sounds after the demos is finished, because the "envelopes" doesn't mute the "oscilators" entirely.
I'm quite sure that he uses some kind of "raster" technique for the blue zooming/rotating tube effect.
Address for PAR = 00 00 00 00 10 10 10 = $00_a8
Address of code to load = %00_00_00_10 11 00_00 << 2 = %10 11000000 = $2c0
There is some code @2c0 mostly word writes to HUB RAM but the simulator fails when reading an address from memory. I have to add a mask.
Here is the disassembly of $2c0 till it fails at the djnz :-(
Example 1:
seg000:00000018 00000005 C 555,\v seg000:000000AB 00000005 C h/H<b seg000:000000D8 00000018 C [noparse][[/noparse] quaerendo invenietis ] seg000:0000013F 00000006 unicode d seg000:0000022A 00000006 C \bHB\b A seg000:0000024B 00000006 C @0rE\" seg000:000002E2 00000010 unicode \x1B*9GRcmx seg000:00000302 00000006 unicode 9Yg Example 2: seg000:00007A11 00000008 C @&igbjjB seg000:00007A1D 00000005 C 2[noparse][[/noparse]KgS seg000:00007A39 00000005 C t\t\r\"{ seg000:00007ACE 00000005 C \r=i\b, seg000:00007ADB 00000005 C ],ml\b seg000:00007AFF 00000005 C v3 L` seg000:00007B55 00000005 C O 46, seg000:00007B5B 00000008 C rS7S'O{; seg000:00007B81 00000005 C +4DM\r seg000:00007C18 00000006 C peU77 seg000:00007D51 00000005 C oW<Ct seg000:00007FA2 0000000D C turbulence seg000:00007FB2 0000000D C lft 2009▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob
Post Edited (Bob Lawrence (VE1RLL)) : 4/16/2009 12:33:31 PM GMT
Oh you're right, that's just a guess but....
1. considering the bunch of stuff in the demo (rotozoom lenna bitmap, turbulence logo, the rose flower, the trees, 2 songs...) it starts to make some kbytes
2. in his Craft demo, Linus used a packer if I'm not wrong to depack on the fly data from the eeprom
3. in case of plain obfuscation, pattern/sequences are still there and looking at the binary, I did not find any pattern (usually very easy to "see" bitmaps & music stuff when watching the hexadecimal stuff), looks very condense like packed data. But ok not a formal proof
4. as Linus says in the hidden screen, he cannot filled the 32 Kb ! no more motivation+idea ! [noparse]:D[/noparse] So yes, room left...
But I agree... you can be right [noparse]:)[/noparse]
@Ahle2 : I don't know how you did to understand all of that but really interesting ! And WOW the display technique seems coming from another palnet (in my noob mind)
Community hacking is really fun [noparse]:)[/noparse] I learn a lot !
Post Edited (Shazz) : 4/16/2009 2:12:02 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Basic Stamp,···· Propeller,·· · SX,·· FUN!
START:·
>Proccessing Data. . . .··
>Task Complete. . .·.
>Saving Data. . . .
>Entering SLEEP Mode. . . .
>Signing OFF
·
I know the Protoboard does.. Has this been considered?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
I'll check at home but the Parallax DS says : 24LC256-I/ST (32K) and I don't think Linus cheats with that [noparse]:)[/noparse]
He he, i don't actually now anything, pure speculation using the exclusion method (there really isn't many options)
It kind of helps to know how those effects were made on the C64/Amiga ( which i do know )
The zooming part of the "roto zoomer", could have been done by altering some video parameters on the fly.
It's seems like everytime there is more than one layer of graphics on screen, some pins goes wild.
Transfering layer data between cogs/Syncing video generators?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
But that being said, I look forward in knowing how to pack/unpack code .. I think the time hit to unpack and move code into ram is a small price to pay considering the extra storage one can get in the eeprom..
I am assuming the same could be done for a 64k and a 128k??
I wonder how big his code is unpacked??
k.