Shop OBEX P1 Docs P2 Docs Learn Events
Propeller based demo to be released at Breakpoint. - Page 4 — Parallax Forums

Propeller based demo to be released at Breakpoint.

124678

Comments

  • Bob Lawrence (VE1RLL)Bob Lawrence (VE1RLL) Posts: 1,720
    edited 2009-04-15 04:09
    I just watched the Video demo (no sound) on my Hybrid board. It's even more cool! live. jumpin.gif

    @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. lol.gif 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
  • jazzedjazzed Posts: 11,803
    edited 2009-04-15 05:22
    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.

    BTW: Great demo Linus.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    --Steve


    Propalyzer: Propeller PC Logic Analyzer
    http://forums.parallax.com/showthread.php?p=788230
  • ShazzShazz Posts: 52
    edited 2009-04-15 12:21
    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]
  • kuronekokuroneko Posts: 3,623
    edited 2009-04-15 12:50
    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.
  • jazzedjazzed Posts: 11,803
    edited 2009-04-15 19:50
    Welcome Shazz

    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.


    Init 0018
    
    Spin 0018 PUSH     $00000000 / +0
    Spin 0019 PUSH     $00000000 / +0
    Spin 001A PUSH     $00000000 / +0
    Spin 001B COGISUB  $00000000 / +0
    Asmb 0000 Starts
    Asmb 0000 000 5C7C0007 JMP     000, #007
    Goto 001C 007
    Asmb 001C 007 A0FC060B MOV     003, #00B
    Asmb 0020 008 5CFC6830 JMPRET  034, #030
    Call 00C0 030
    Asmb 00C0 Starts
    Asmb 00C0 030 A0FC0800 MOV     004, #000
    Asmb 00C4 031 5CFC5A2B JMPRET  02D, #02B
    Call 00AC 02B
    Asmb 00AC Starts
    Asmb 00AC 02B 623C482F TEST    024, 02F
    Asmb 00B0 02C 29D44801 SHR     024, #001
    Asmb 00B4 02D 5C540000 JMP     000, #000
    Asmb 00B8 02E 5C7C0026 JMP     000, #026
    Goto 0098 026
    Asmb 0098 026 00BC0424 RDBYTE  002, 024
    Asmb 009C 027 58FC0500 MOVI    002, #100
    Asmb 00A0 028 80FC4801 ADD     024, #001
    Asmb 00A4 029 2CFC4808 SHL     024, #008
    Asmb 00A8 02A 68BC4802 OR      024, 002
    Asmb 00C8 032 34FC0801 RCL     004, #001
    Asmb 00CC 033 E4FC0631 DJNZ    003, #031
    Call 00C4 031
    Asmb 00C4 Starts
    Asmb 00D0 034 5C7C0000 JMP     000, #000
    Exit
    ...
    
    



    000000 5c7c0007 0010a66f 7fcc7fc4 7fd00018  >..|\o...........<
    000010 00027fb4 00000008 2c353535 a0fc060b  >........555,....<
    000020 5cfc6830 a0bc0a04 5cfc5a2b 5c4c0019  >0h.\....+Z.\..L\<
    000030 a0fc0608 5cfc6830 a0bc0c25 84bc0c04  >....0h.\%.......<
    000040 a0fc0606 5cfc6830 80fc0802 00bfe006  >....0h.\........<
    000050 80fc0c01 80fc4a01 003fe025 e4fc0813  >.....J..%.?.....<
    000060 5c7c0022 a0fc0604 5cfc6830 a0bc0c04  >".|\....0h.\....<
    000070 80fc0c01 a0fc0608 5cfc6830 80fc4a01  >........0h.\.J..<
    000080 003c0825 e4fc0c1d e4fc0a0a 5c7c0035  >%.<.........5.|\<
    000090 00000c24 7d2800d3 00bc0424 58fc0500  >$.....(}$......X<
    0000a0 80fc4801 2cfc4808 68bc4802 623c482f  >.H...H.,.H.h/H<b<
    0000b0 29d44801 5c540000 5c7c0026 ff000000  >.H.)..T\&.|\....<
    0000c0 a0fc0800 5cfc5a2b 34fc0801 e4fc0631  >....+Z.\...41...<
    0000d0 5c7c0000 0c7fea02 7571205b 65726561  >..|\....[noparse][[/noparse] quaere<
    0000e0 206f646e 65766e69 7465696e 5d207369  >ndo invenietis ]<
    0000f0 055c8190 02010020 c800b900 1f219003  >..\. .........!.<
    000100 795c8040 00040200 219003c8 0080401f  >@.\y.......!.@..<
    000110 07cae400 90002010 00008001 3c836400  >..... .......d.<<
    000120 010c8990 00000200 60be4000 00000100  >.........@.`....<
    000130 3e41d200 00821608 90000000 6460800e  >..A>..........`d<
    000140 00002000 52006900 05880304 e2001c40  >. ...i.R....@...<
    000150 100803a5 0890142c 10849011 00748240  >....,.......@.t.<
    000160 c4018229 00192002 0401d2f1 880a1608  >).... ..........<
    000170 46881f82 1a462008 608045c8 000c8010  >...F. F..E.`....<
    000180 74800004 00030400 0d200000 106081e4  >...t...... ...`.<
    000190 80065c20 00000130 00220000 483e4000  > \..0....."..@>H<
    0001a0 1000a143 2211542c 0c544135 00094420  >C...,T."5AT. D..<
    0001b0 be84014a a88a4065 5770f81c 7f1a7100  >J...e@....pW.q..<
    0001c0 a3077021 12a88019 002a8840 f02351a1  >!p......@.*..Q#.<
    0001d0 1e06ade1 9dc035fc 20755a89 3d5f3f87  >.....5...Zu .?_=<
    0001e0 3442c1dc 348e1168 86100804 420a0460  >..B4h..4....`..B<
    0001f0 00020006 401d2b90 00a16080 02100110  >.....+.@.`......<
    000200 200e93c8 00003040 01d20000 0a160811  >... @0..........<
    000210 21003f00 00697c80 88030452 001c4005  >.?.!.|i.R....@..<
    
    

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    --Steve


    Propalyzer: Propeller PC Logic Analyzer
    http://forums.parallax.com/showthread.php?p=788230
  • ShazzShazz Posts: 52
    edited 2009-04-15 19:54
    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...
  • ShazzShazz Posts: 52
    edited 2009-04-15 20:03
    Damb ! There is an hidden part ! a long scrolltext and a 3D green rotating cube, and music ! gosh.....
  • jazzedjazzed Posts: 11,803
    edited 2009-04-15 20:15
    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

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    --Steve


    Propalyzer: Propeller PC Logic Analyzer
    http://forums.parallax.com/showthread.php?p=788230
  • ShazzShazz Posts: 52
    edited 2009-04-15 20:30
    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...

    Post Edited (Shazz) : 4/15/2009 9:17:53 PM GMT
  • localrogerlocalroger Posts: 3,451
    edited 2009-04-15 23:53
    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.
  • ProcessingData...ProcessingData... Posts: 208
    edited 2009-04-16 04:16
    Whoa, loaded the program onto my board, even dad was wowed. Can't wait for the code! [noparse];)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Basic Stamp,···· Propeller,·· · SX,·· FUN!


    START:·
    >Proccessing Data. . . .··
    >Task Complete. . .·.
    >Saving Data. . . .
    >Entering SLEEP Mode. . . .
    >Signing OFF


    ·
  • ShazzShazz Posts: 52
    edited 2009-04-16 07:10
    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]

    Post Edited (Shazz) : 4/16/2009 7:17:27 AM GMT
  • MagIO2MagIO2 Posts: 2,243
    edited 2009-04-16 08:37
    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).
  • ShazzShazz Posts: 52
    edited 2009-04-16 08:51
    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...) ?
  • Timothy D. SwieterTimothy D. Swieter Posts: 1,613
    edited 2009-04-16 08:55
    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
  • SapiehaSapieha Posts: 2,964
    edited 2009-04-16 09:01
    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...) ?
    Hi Shazz

    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
  • AleAle Posts: 2,363
    edited 2009-04-16 09:20
    I think the relevant info is contained here smile.gif

    I'm using a not-yet-fully-functional-but-still-useful version of unpublished pPropellerSim everyone forgot about cry.gif

    Edit: Do not pay attention to the label's names, they are the interpreter's.
    938 x 558 - 133K
    936 x 560 - 134K
    937 x 557 - 136K
  • ShazzShazz Posts: 52
    edited 2009-04-16 09:30
    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 ???)
  • kuronekokuroneko Posts: 3,623
    edited 2009-04-16 09:37
    Re: packing

    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.
  • Ahle2Ahle2 Posts: 1,178
    edited 2009-04-16 09:58
    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.
  • AleAle Posts: 2,363
    edited 2009-04-16 11:44
    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 :-(
    937 x 559 - 136K
    937 x 561 - 138K
  • Bob Lawrence (VE1RLL)Bob Lawrence (VE1RLL) Posts: 1,720
    edited 2009-04-16 12:27
    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
  • ShazzShazz Posts: 52
    edited 2009-04-16 13:58
    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]
  • ShazzShazz Posts: 52
    edited 2009-04-16 14:03
    @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 !

    Post Edited (Shazz) : 4/16/2009 2:12:02 PM GMT
  • ProcessingData...ProcessingData... Posts: 208
    edited 2009-04-16 14:29
    I checked and the numbers displayed are not random.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Basic Stamp,···· Propeller,·· · SX,·· FUN!


    START:·
    >Proccessing Data. . . .··
    >Task Complete. . .·.
    >Saving Data. . . .
    >Entering SLEEP Mode. . . .
    >Signing OFF


    ·
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2009-04-16 14:30
    Does anyone remember if the Demoboard ships with a 64K EEPROM?

    I know the Protoboard does.. Has this been considered?

    OBC

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    New to the Propeller?

    Visit the: The Propeller Pages @ Warranty Void.
  • ShazzShazz Posts: 52
    edited 2009-04-16 14:32
    Oldbitcollector said...
    Does anyone remember if the Demoboard ships with a 64K EEPROM?

    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]
  • Ahle2Ahle2 Posts: 1,178
    edited 2009-04-16 15:15
    @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?
  • potatoheadpotatohead Posts: 10,253
    edited 2009-04-16 15:34
    My Demoboard had a 32K EEPROM.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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!
  • KPRKPR Posts: 189
    edited 2009-04-16 17:34
    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??

    I wonder how big his code is unpacked??

    k.
Sign In or Register to comment.