It is said...
The complete source code for Turbulence will be released when somebody has reverse engineered the binary enough to provide a detailed description of the techniques used in the greetings part (rotating face with text overlays).
That's where we want to end up. Let's get there step by step. It was suggested to brush the following topics:
bootstrap/unpacker
demo sequence (who does what)
workings of the rotozoomer
workings of the overlay/transparency
Well, starting with the infamous JMP #7 from an unusual location we end up straight in the decoder (I prefer that word, call it what you want) which picks up data from 0x0C24 and writes its first payload to 0x00D4. Note that all addresses are hub addresses (unless stated otherwise). Once finished, the cog will restart with coginit outb. How does the decoder work? The payload is stored reversed in a bit stream which interleaves data and control information.
units = read(11);
while (units--) {
if (read(1)) {
tmp = dst - read(8);
len = read(6) + 2;
for (i = 0; i < len; i++)
hub[noparse][[/noparse]++dst] = hub[noparse][[/noparse]tmp++];
continue;
}
len = read(4) + 1;
for (i = 0; i < len; i++)
hub[noparse][[/noparse]++dst] = read(8);
}
The read() function returns the requested number of bits in the correct order. Note that the destination address is specified one below the actual location (0x00D3 for the first block). The single bit consumed at the beginning of the loop decides whether we do a plain copy from the stream (0) or refer to data we already unpacked (1).
Let's have a look at the first 4 units:
c 00D4: 6E EC BF 68 38 5C FC 50 70 00 7C 5C F1 6F BC A0
c 00E4: 28 6E FC 80 36 48 3C 86 59 00 68 5C 5E DA FC 5C
c 00F4: 50 6E FC F8 6E E8 BF 68 18
r 00FD: 6E FC F8
The first three simply copy bytes from the stream to the destination. Unit 4 refers back to location 0x00F5 from where it copies 3 bytes.
Once decoding of the first block is complete the hub memory looks like this turbulence.pass_1.eeprom. Disassembling this file with your favourite tool will show that the coginit outb disappeared (only to come back later [noparse]:)[/noparse] We now have access code for the EEPROM, some initial setup (video: cog 6/7, audio: cog 5), the hidden part check is done (IIRC 40+ negative edges on P31) as well as whether the demo is resident in EEPROM. After that, we get a final code update for cog 0 (written to 0x01C0) and one more coginit outb which drops us - eventually - into the demo sequence loop.
Which I will explain tomorrow as I have some real work to do as well [noparse]:)[/noparse] For those who can't wait, here are some entry points which can be fed into the decoder.
Disclaimer: Descriptions (especially for commands) may not exactly match their intended purpose. However, it tells me what I need to know [noparse]:)[/noparse]
bootstrap/unpacker
demo sequence (who does what)
workings of the rotozoomer
workings of the overlay/transparency
Depending on whether you found the hidden part or not (the hidden part enabled by default was posted in this thread) you end up with two sequence descriptors located at 0x7D28 and 0x7D68. These are WORD tables with a header and bit stream locations (fit for the decoder). The fourth entry in the header describes the location of the command bit stream (0x7B96 and 0x7D11). Let's have a look at the hidden part as it's the shorter one.
This should be rather easy to follow. A bit stream is selected, then decoded to a given address and one out of 4 cogs (1-4) has to do the work. The last stream doesn't represent code but the scroller message (posted in this thread) which is picked up by cog 3 (started last). I could go into more detail as to what is done in the other 3 cogs but our main focus should stay on the greeting part. Besides, at this point it should be a piece of cake to figure out what's going on.
The normal part is rather long (5min, I'll attach the whole sequence as a file) so I show only the required fragment.
A blob of data is decoded from 0x61CD to 0x0000. This contains the face image (16K, 128x128) and the greeting messages. Then cog 4 is started (payload at 0x2F6F) which does the whole rotozoomer business. The latter is running on its own for about 10s, after that a new palette is loaded and the text overlay code (payload at 0x4319) extracted and distributed among cogs 1-3. The code splits up internally based on cogid which results in:
cog 3 driving colour index bit 3 for all 6 text rows
cog 1 driving colour index bit 2 for rows 1, 3 and 5
cog 2 driving colour index bit 2 for rows 2, 4 and 6
FYI, cog 4 drives colour index bits 1 and 0 giving a total of 16 colours for this part.
More details to follow. If anyone has a particular question, maybe I know the answer. Don't hesitate to ask.
It is said...
the hidden part check is done (IIRC 40+ negative edges on P31) as well as whether the demo is resident in EEPROM.
Okay!, set pin 31 low, start the Demo and the Hidden part shows up
Edit:
I turned the connector wrong (pin 31 was floating) so with right connections it didn't work so I have to set the pin high/low(?) a moment after start up of the Propeller.
Hi Linus
Watch my movie and see if you find what differentiates it from your
And why?
Ps. can't atach my video Sorry It is to big (279 MB)
If You have one e-mail address I can send it to You
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
Screen shoits give no clues.
Only if You watch entire video You can see al problems
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
Having mentioned colour bit indexes and palettes in the last part, I'll explain quickly how the (transparent) text overlay is done. Having dropped so many clues already it borders on stating the obvious but anyway ...
Effectively we are dealing with 3 sources (rotozoomer, primary (top) and secondary (middle) text layer). The palette is arranged like this:
The primary text layer controls bit 3, meaning any colour looking like %1--- resolves to white. The secondary (bit 2) comes into effect for %01-- which gives us a slightly darker appearance of %00-- which is covered by the rotozoomer. That's about it really. If the text bits are not driven high then you get the background image, otherwise either transparent (shadow) or opaque (main) text. I'll attach the background image with two rectangles applied on top (instead of text) to demonstrate the effect.
Let's have a quick look at the rotozoomer next. While it might look complicated it isn't really that difficult. It obviously helps if your picture is using a power of two for width and height to deal with wraps (c mod 2^n is equivalent to c & (2^n - 1)). What happens?
start with the top left corner (x, y)
calculate the address inside your image data (e.g. y mul width + x)
plot this pixel
find the next location, x = (x + dx) mod width, y = (y + dy) mod height
repeat for each column (and subsequently row)
Now try that in PASM, in say 7 instructions! Here is what the inner loop looks like:
loop MOV $096, $098 ' (x, y): VUTS.RQPO.NMLK.JIHG.FEDC.BA98.7654.3210
MOVI $096, $096 ' 8765.4321.0MLK.JIHG.FEDC.BA98.7654.3210
SHL $096, #2 ' 6543.210M.LKJI.HGFE.DCBA.9876.5432.10--
SHR $096, #18 ' ----.----.----.----.--65.4321.0MLK.JIHG 16K address
RDBYTE OUTA, $096 ' feed pixel value to the video driver
ADDX $098, $09a wc ' apply dx and dy
DJNZ $094, #loop ' repeat for all columns
Which is quite impressive. If you follow the bit pattern on the right you'll see that the start coordinates come along as x << 16 + y. The increments are arranged in a slightly different way as they are applied in what I believe is 3.8 fixed point format (but IIRC only 2.8 is effectively used). Note also how an overflow from the dyfraction is applied (one sample late though) to the integer part (ADDX).
dx/dy: yyyy.yyyy.----.-XXX.xxxx.xxxx.----.-YYY
Incidentally, Linus, what is the lonely TEST linecount, #3 wz doing just after the loop?
Excellent work! Not much left now before I'll publish the source code.
kuroneko said...
Incidentally, Linus, what is the lonely TEST linecount, #3 wz doing just after the loop?
That's a good question. I've traced this instruction back through the version control system, but it doesn't make sense back when it was written either. Except that it was checked in late at night. My best guess is that it was used for 4:3 aspect ratio correction, but that I later figured out that I'd perform the correction via dy instead.
We are nearly done. To be honest, it's slightly worse than taking the rotozoomer apart [noparse];)[/noparse] Not so much about its general structure - which is obvious enough - but getting every detail right. What does each cog do:
generate a vsync pulse
generate the back porch, while doing so read in the palette from 0x7C00 and store it in the first 256 longs
spend 2 horizontal lines to sample video data from INA (240 pixels) into a line buffer
output the line buffer twice
repeat last two steps 120 times (2 lines collect, 2 lines emit)
front porch
The difference between cog 6 and 7 being that the latter outputs 2 back porch lines less (and 2 front porch lines more) which nicely interleaves both video signals. Let's have a look at how the data is collected and assembled:
MOV VSCL, $16d
WAITVID $172, #%1010 ' HSYNC pulse
WAITVID $172, $174 ' $00010203:$FFFFFFFF -> HSYNC = VSYNC = 0
MOV VSCL, $171
WAITVID $172, $174
MOVD :line, #$183 ' line buffer - 1
MOV $17e, #60 ' 60 * 4 bytes -> 240 pixels
:loop MOVS :b0, INA ' read colour index from INA and use this as palette source register
:line MOV $0-0, colour
:b0 MOV colour, $0-0
ADD :line, $175 ' $200, next long in line buffer
MOVS :b1, INA
SHL colour, #8
:b1 OR colour, $0-0
NOP
MOVS :b2, INA
SHL colour, #8
:b2 OR colour, $0-0
NOP
MOVS :b3, INA
SHL colour, #8
:b3 OR colour, $0-0
DJNZ $17e, #:loop
MOV $1bf, colour ' store last 4 pixels
... emit line buffer 2x
I mentioned before that fetching 240 pixels takes the time of two scan lines. So why do we only have a single HSYNC pulse and why is HSYNC/VSYNC = 0 for the entire time? It's not as bad as it looks but it had me puzzled for a while until I realised that the other cog emits two normal scan lines during that time. As the I/O pins are ORed together we get our second HSYNC pulse and don't have to worry about VSYNC being low. Colour byte assembly is fairly normal stuff here. Nothing much to see really. I think it's quite a nice design, especially the per frame palette update [noparse]:)[/noparse]
That's it from my side. If anything needs more detail, let me know.
Thanks for providing that challenge, Linus!
Post Edited (kuroneko) : 5/11/2009 12:19:32 PM GMT
Thanks YOU Linus ! I had some great fun too, I tried to help Kuroneko as much as I can but basically he did most of the job and wasted his time to explain me a lot of stuff [noparse]:)[/noparse]
At least it gave me the motivation to write some tools and yep I really discovered interesting things.... And thanks to Jazzed, MagIO2, Ale, Potatohead and friends who really helped at the beginning !
Now time to make good use of this wonderful demo sourcecode and why not coding a new demo A Forum Community demo for next BP would be great And I'm curious to see what Kuroneko would be able to achieve.... a good challenger for Linus ! [noparse]:D[/noparse]
Linus, 2 questions :
- what is the format of your raw images ? (yes raw.. but... [noparse]:)[/noparse])
- did you write a PC based tracker as you did for Craft ? Would be nice to have one plus a song player for the propeller, no ? [noparse]:)[/noparse]
And if I forgot to say it, congrats again... amazing work in less than one year.... plasma looks very cool [noparse]:)[/noparse] Especially the automated constant pool management !
Sorry Linus, i couldn't find the time to join these guys in their reverse engineering quest [noparse]:([/noparse]
But Interestingly enough, almost all my assumption were right... as you might have seen in some early posts.
Are you going to make another demo using the propeller or are you going to use yet another micro controller for your next release ?
Anyway, it's nice to have another guy from Sweden at the same age as me here in the forum [noparse];)[/noparse]
I just tried it out on my demo board, and I was quite impressed!
I had a problem though. I have a microSD interface on pins 1through 4. If I left the card in it didn't look right. Are you passing data through those pins from cog to cog?
It was noticed within minutes of its release that the i/o pins were being used. One person noted that it wouldnt run at all on his bd that had broken ports. On my early bd, which has the poor Prop that I reverse voltsed, the "Turbulance" banner glitches but the demo runs on ok. Something had to happen to the poor little beasy, I suppose
I run Yours Demo with 15MHz PLLx8 and it run fine on most parts but not on TUNNEL.
In this part it is glitches in motion.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
I have just re read my post about the I/O pins, I am sorry if it sounded a bit sharp. I only noticed so quickly because one of my backburnner projects is a Z80 nailed to a prop. I had built that board with lots of jumpers and status LEDs. I was using turbulance to test the Arduino type piggy back board out and noticed the light show. It is at about that level my understanding ends.
120Mhz exceeds the known safe clock speed. Proper function of all elements is guaranteed @ 80Mhz, and is commonly accepted to be reliable at 96Mhz, but with no guarantee.
Intel would tend to overproduce "good" chips but the market would only support those cutting edge seakers so a lot of full wack chips got underatted to fill the bulkof sales. This helped Intel to not have too many proc lying around and yet keep that top price for those that demanded it. Great for reliability, or overclockers. Amd tested and sold much nearer to the very best, that individual chip could handle.
Pros may well be sold under their true limit in the interests of guarenteed results or it may be that now the fabrication is matured the good yield is better than original spec. Plenty of people have tested them since. 80MHz to 96MHz is a respectable hype at 20% with nobody reporting problems. To take the internal to 15MHz with pll8 shows that there is a vast margin available to those wishing to try, within much tighter enviromentals than spec of course.
I once had an AVR chucking out 4 small pictures on a TV, then I realized that at 32MHz it was taking a 100% overclock
For them that will test Linus Akesson's code with frequensies with PLLx8 that is 10-15MHz crystal.
I post my reedited code to support that. It is same code but only edit in it is position that give Propeller PLLx and recalculated checksum.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
Comments
- bootstrap/unpacker
- demo sequence (who does what)
- workings of the rotozoomer
- workings of the overlay/transparency
Well, starting with the infamous JMP #7 from an unusual location we end up straight in the decoder (I prefer that word, call it what you want) which picks up data from 0x0C24 and writes its first payload to 0x00D4. Note that all addresses are hub addresses (unless stated otherwise). Once finished, the cog will restart with coginit outb. How does the decoder work? The payload is stored reversed in a bit stream which interleaves data and control information.units = read(11); while (units--) { if (read(1)) { tmp = dst - read(8); len = read(6) + 2; for (i = 0; i < len; i++) hub[noparse][[/noparse]++dst] = hub[noparse][[/noparse]tmp++]; continue; } len = read(4) + 1; for (i = 0; i < len; i++) hub[noparse][[/noparse]++dst] = read(8); }The read() function returns the requested number of bits in the correct order. Note that the destination address is specified one below the actual location (0x00D3 for the first block). The single bit consumed at the beginning of the loop decides whether we do a plain copy from the stream (0) or refer to data we already unpacked (1).
Let's have a look at the first 4 units:
The first three simply copy bytes from the stream to the destination. Unit 4 refers back to location 0x00F5 from where it copies 3 bytes.
Once decoding of the first block is complete the hub memory looks like this turbulence.pass_1.eeprom. Disassembling this file with your favourite tool will show that the coginit outb disappeared (only to come back later [noparse]:)[/noparse] We now have access code for the EEPROM, some initial setup (video: cog 6/7, audio: cog 5), the hidden part check is done (IIRC 40+ negative edges on P31) as well as whether the demo is resident in EEPROM. After that, we get a final code update for cog 0 (written to 0x01C0) and one more coginit outb which drops us - eventually - into the demo sequence loop.
Which I will explain tomorrow as I have some real work to do as well [noparse]:)[/noparse] For those who can't wait, here are some entry points which can be fed into the decoder.
Post Edited (kuroneko) : 5/8/2009 12:14:01 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
- bootstrap/unpacker
- demo sequence (who does what)
- workings of the rotozoomer
- workings of the overlay/transparency
Depending on whether you found the hidden part or not (the hidden part enabled by default was posted in this thread) you end up with two sequence descriptors located at 0x7D28 and 0x7D68. These are WORD tables with a header and bit stream locations (fit for the decoder). The fourth entry in the header describes the location of the command bit stream (0x7B96 and 0x7D11). Let's have a look at the hidden part as it's the shorter one.This should be rather easy to follow. A bit stream is selected, then decoded to a given address and one out of 4 cogs (1-4) has to do the work. The last stream doesn't represent code but the scroller message (posted in this thread) which is picked up by cog 3 (started last). I could go into more detail as to what is done in the other 3 cogs but our main focus should stay on the greeting part. Besides, at this point it should be a piece of cake to figure out what's going on.
The normal part is rather long (5min, I'll attach the whole sequence as a file) so I show only the required fragment.
A blob of data is decoded from 0x61CD to 0x0000. This contains the face image (16K, 128x128) and the greeting messages. Then cog 4 is started (payload at 0x2F6F) which does the whole rotozoomer business. The latter is running on its own for about 10s, after that a new palette is loaded and the text overlay code (payload at 0x4319) extracted and distributed among cogs 1-3. The code splits up internally based on cogid which results in:
- cog 3 driving colour index bit 3 for all 6 text rows
- cog 1 driving colour index bit 2 for rows 1, 3 and 5
- cog 2 driving colour index bit 2 for rows 2, 4 and 6
FYI, cog 4 drives colour index bits 1 and 0 giving a total of 16 colours for this part.More details to follow. If anyone has a particular question, maybe I know the answer. Don't hesitate to ask.
Post Edited (kuroneko) : 5/8/2009 2:00:14 AM GMT
tmpstore.free.fr/propeller/LoaderDecrypter_v0.2.zip
usage:
For us dummies. If you do a serial communication to the Propeller in the beginning of the Demo, it will trigger the hidden part.
I have disassembly a little bit of the eeprom file
CON
_clkmode = xtal1 + pll16x
_clkfreq = $5C7C0007
Edit:
I turned the connector wrong (pin 31 was floating) so with right connections it didn't work so I have to set the pin high/low(?) a moment after start up of the Propeller.
Post Edited (BEEP) : 5/8/2009 5:33:48 PM GMT
Watch my movie and see if you find what differentiates it from your
And why?
Ps. can't atach my video Sorry It is to big (279 MB)
If You have one e-mail address I can send it to You
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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) : 5/8/2009 8:17:37 PM GMT
Screen shoits give no clues.
Only if You watch entire video You can see al problems
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
- bootstrap/unpacker
- demo sequence (who does what)
- workings of the overlay/transparency
- workings of the rotozoomer
- VGA driver
Having mentioned colour bit indexes and palettes in the last part, I'll explain quickly how the (transparent) text overlay is done. Having dropped so many clues already it borders on stating the obvious but anyway ...Effectively we are dealing with 3 sources (rotozoomer, primary (top) and secondary (middle) text layer). The palette is arranged like this:
The primary text layer controls bit 3, meaning any colour looking like %1--- resolves to white. The secondary (bit 2) comes into effect for %01-- which gives us a slightly darker appearance of %00-- which is covered by the rotozoomer. That's about it really. If the text bits are not driven high then you get the background image, otherwise either transparent (shadow) or opaque (main) text. I'll attach the background image with two rectangles applied on top (instead of text) to demonstrate the effect.
Let's have a quick look at the rotozoomer next. While it might look complicated it isn't really that difficult. It obviously helps if your picture is using a power of two for width and height to deal with wraps (c mod 2^n is equivalent to c & (2^n - 1)). What happens?
- start with the top left corner (x, y)
- calculate the address inside your image data (e.g. y mul width + x)
- plot this pixel
- find the next location, x = (x + dx) mod width, y = (y + dy) mod height
- repeat for each column (and subsequently row)
Now try that in PASM, in say 7 instructions! Here is what the inner loop looks like:loop MOV $096, $098 ' (x, y): VUTS.RQPO.NMLK.JIHG.FEDC.BA98.7654.3210 MOVI $096, $096 ' 8765.4321.0MLK.JIHG.FEDC.BA98.7654.3210 SHL $096, #2 ' 6543.210M.LKJI.HGFE.DCBA.9876.5432.10-- SHR $096, #18 ' ----.----.----.----.--65.4321.0MLK.JIHG 16K address RDBYTE OUTA, $096 ' feed pixel value to the video driver ADDX $098, $09a wc ' apply dx and dy DJNZ $094, #loop ' repeat for all columnsWhich is quite impressive. If you follow the bit pattern on the right you'll see that the start coordinates come along as x << 16 + y. The increments are arranged in a slightly different way as they are applied in what I believe is 3.8 fixed point format (but IIRC only 2.8 is effectively used). Note also how an overflow from the dy fraction is applied (one sample late though) to the integer part (ADDX).
Incidentally, Linus, what is the lonely TEST linecount, #3 wz doing just after the loop?
Post Edited (kuroneko) : 5/9/2009 8:06:35 AM GMT
MOV CTRA, :ctra MOV FRQA, #1 ADD CNT, :delay WAITCNT CNT, #0 CMP :target, PHSA WZ,WC IF_C RDWORD $006, #$096 ' sequence table IF_C ADD $006, #$040 ' switch to hidden sequence IF_C WRWORD $006, #$096 ' update :ctra long $3800001f :delay long $10000000 :target long $00000028That's a good question. I've traced this instruction back through the version control system, but it doesn't make sense back when it was written either. Except that it was checked in late at night. My best guess is that it was used for 4:3 aspect ratio correction, but that I later figured out that I'd perform the correction via dy instead.
- bootstrap/unpacker
- demo sequence (who does what)
- workings of the overlay/transparency
- workings of the rotozoomer
- VGA driver
We are nearly done. To be honest, it's slightly worse than taking the rotozoomer apart [noparse];)[/noparse] Not so much about its general structure - which is obvious enough - but getting every detail right. What does each cog do:- generate a vsync pulse
- generate the back porch, while doing so read in the palette from 0x7C00 and store it in the first 256 longs
- spend 2 horizontal lines to sample video data from INA (240 pixels) into a line buffer
- output the line buffer twice
- repeat last two steps 120 times (2 lines collect, 2 lines emit)
- front porch
The difference between cog 6 and 7 being that the latter outputs 2 back porch lines less (and 2 front porch lines more) which nicely interleaves both video signals. Let's have a look at how the data is collected and assembled:MOV VSCL, $16d WAITVID $172, #%1010 ' HSYNC pulse WAITVID $172, $174 ' $00010203:$FFFFFFFF -> HSYNC = VSYNC = 0 MOV VSCL, $171 WAITVID $172, $174 MOVD :line, #$183 ' line buffer - 1 MOV $17e, #60 ' 60 * 4 bytes -> 240 pixels :loop MOVS :b0, INA ' read colour index from INA and use this as palette source register :line MOV $0-0, colour :b0 MOV colour, $0-0 ADD :line, $175 ' $200, next long in line buffer MOVS :b1, INA SHL colour, #8 :b1 OR colour, $0-0 NOP MOVS :b2, INA SHL colour, #8 :b2 OR colour, $0-0 NOP MOVS :b3, INA SHL colour, #8 :b3 OR colour, $0-0 DJNZ $17e, #:loop MOV $1bf, colour ' store last 4 pixels ... emit line buffer 2xI mentioned before that fetching 240 pixels takes the time of two scan lines. So why do we only have a single HSYNC pulse and why is HSYNC/VSYNC = 0 for the entire time? It's not as bad as it looks but it had me puzzled for a while until I realised that the other cog emits two normal scan lines during that time. As the I/O pins are ORed together we get our second HSYNC pulse and don't have to worry about VSYNC being low. Colour byte assembly is fairly normal stuff here. Nothing much to see really. I think it's quite a nice design, especially the per frame palette update [noparse]:)[/noparse]
That's it from my side. If anything needs more detail, let me know.
Thanks for providing that challenge, Linus!
Post Edited (kuroneko) : 5/11/2009 12:19:32 PM GMT
Great work, kuroneko! Thanks for putting up with my little game.
Here is the source code as promised: www.linusakesson.net/scene/turbulence/source.php. You will find some documentation there as well.
Wow.. I know what I'll be doing for the next few days...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New ICON coming, gotta wait for the INK to heal, now we have colour!
Thanks YOU Linus ! I had some great fun too, I tried to help Kuroneko as much as I can but basically he did most of the job and wasted his time to explain me a lot of stuff [noparse]:)[/noparse]
At least it gave me the motivation to write some tools and yep I really discovered interesting things.... And thanks to Jazzed, MagIO2, Ale, Potatohead and friends who really helped at the beginning !
Now time to make good use of this wonderful demo sourcecode and why not coding a new demo
Linus, 2 questions :
- what is the format of your raw images ? (yes raw.. but... [noparse]:)[/noparse])
- did you write a PC based tracker as you did for Craft ? Would be nice to have one plus a song player for the propeller, no ? [noparse]:)[/noparse]
And if I forgot to say it, congrats again... amazing work in less than one year.... plasma looks very cool [noparse]:)[/noparse] Especially the automated constant pool management !
Post Edited (Shazz) : 5/12/2009 7:20:16 AM GMT
But Interestingly enough, almost all my assumption were right... as you might have seen in some early posts.
Are you going to make another demo using the propeller or are you going to use yet another micro controller for your next release ?
Anyway, it's nice to have another guy from Sweden at the same age as me here in the forum [noparse];)[/noparse]
Yeah, I remember.
I'm not planning another propeller demo for the time being. I've got some ideas for other propeller projects, though.
I just tried it out on my demo board, and I was quite impressed!
I had a problem though. I have a microSD interface on pins 1through 4. If I left the card in it didn't look right. Are you passing data through those pins from cog to cog?
Thanks,
Doug
It was noticed within minutes of its release that the i/o pins were being used. One person noted that it wouldnt run at all on his bd that had broken ports. On my early bd, which has the poor Prop that I reverse voltsed, the "Turbulance" banner glitches but the demo runs on ok. Something had to happen to the poor little beasy, I suppose
I run Yours Demo with 15MHz PLLx8 and it run fine on most parts but not on TUNNEL.
In this part it is glitches in motion.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I have just re read my post about the I/O pins, I am sorry if it sounded a bit sharp. I only noticed so quickly because one of my backburnner projects is a Z80 nailed to a prop. I had built that board with lots of jumpers and status LEDs. I was using turbulance to test the Arduino type piggy back board out and noticed the light show. It is at about that level my understanding ends.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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!
Pros may well be sold under their true limit in the interests of guarenteed results or it may be that now the fabrication is matured the good yield is better than original spec. Plenty of people have tested them since. 80MHz to 96MHz is a respectable hype at 20% with nobody reporting problems. To take the internal to 15MHz with pll8 shows that there is a vast margin available to those wishing to try, within much tighter enviromentals than spec of course.
I once had an AVR chucking out 4 small pictures on a TV, then I realized that at 32MHz it was taking a 100% overclock
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Basic Stamp,···· Propeller,·· · SX,·· FUN!
START:·
>Proccessing Data. . . .··
>Task Complete. . .·.
>Saving Data. . . .
>Entering SLEEP Mode. . . .
>Signing OFF
·
I just downloaded the .eeprom file and ran it for the first time on a Propeller Demo Board.
Pretty amazing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Didn't you help Linus on that demo? Your name was in the credits. I thought you saw the demo before we did.
Jim
Sorry if I have misused Yours code.
Hi All
For them that will test Linus Akesson's code with frequensies with PLLx8 that is 10-15MHz crystal.
I post my reedited code to support that. It is same code but only edit in it is position that give Propeller PLLx and recalculated checksum.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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