What does the decrunch colours mean?
category: code [glöplog]
Hello,
From my understanding all crunchers would decrunch from the end of memory and at some point override the crunched data.
There were many different crunchers, and some wrote characters on the screen and others flashed the borders with almost straight stripes.
Can anyone explain what these colours and characters were?
From my understanding all crunchers would decrunch from the end of memory and at some point override the crunched data.
There were many different crunchers, and some wrote characters on the screen and others flashed the borders with almost straight stripes.
Can anyone explain what these colours and characters were?
Varies from cruncher to cruncher, but mostly just a random character or color to keep you entertained and not think everything was hung. Compressed data works just fine as a random generator (high entropy by definition), so probably something from the stream :-)
On Amiga, the stripes come from changing the background colour multiple times per frame, or even multiple times per scanline. I think the most common crunchers used the decompressed data for the background colour, because the stripes would often vary in density (particularily obvious for blocks of null data) rather than be uniformly random like the compressed data. Blue-green was a common colour scheme because that's what you get when writing single bytes to the palette register, which has 4 bits per component.
The random char thing happens mostly on C64 and probably other 8bit machines of that era as well as they have very limited memory.
Im not a coder or exactly sure but I always believed thats because the decruncher uses the screen-memory (or parts of it) for some extra bytes.
Im not a coder or exactly sure but I always believed thats because the decruncher uses the screen-memory (or parts of it) for some extra bytes.
On nintendo ds, I used to change the background color in some places of the main loop as a limited profiling tool. The biggest background color I could see would be the slowest code...
I always assumed the decruncher changes the background color every X decoded bytes so that, juste like Sesse- said, we know that something is happening.
I always assumed the decruncher changes the background color every X decoded bytes so that, juste like Sesse- said, we know that something is happening.
Generally, it's the value of the last crunched byte read or decrunched byte written, translated into color. Just to show something's happening. If the coder was intelligent, he didn't waste CPU on outputting color for every byte, but conditionally.
On Amiga, it's typically the last crunched byte read translated into RGB, meaning that the red component is 0, resulting in cyan-to-blue-to-black color values.
On C64, it's different. I made this time- and color-accurate decrunch intro last year for anyone who miss Mr. Z in their life and only own an Amiga :P
On Amiga, it's typically the last crunched byte read translated into RGB, meaning that the red component is 0, resulting in cyan-to-blue-to-black color values.
On C64, it's different. I made this time- and color-accurate decrunch intro last year for anyone who miss Mr. Z in their life and only own an Amiga :P
Ok, that is very interesting about the blue-green and the last byte read!
In the case of the stripes. Why are they not perfectly horizontal similar to raster bars?
As for chars: Some decrunchers fill about half of the screen with chars and then just one of them changes very quickly for perhaps one 1-2 seconds or so.
Could it be that it is actually the decrunch code that is written to the screen, and the one byte that changes is a while-loop counter doing the decrunching?
There are 40x25=1000 chars on a C64 screen, so would ~500 chars be realistic for a decrunch routine?
In the case of the stripes. Why are they not perfectly horizontal similar to raster bars?
As for chars: Some decrunchers fill about half of the screen with chars and then just one of them changes very quickly for perhaps one 1-2 seconds or so.
Could it be that it is actually the decrunch code that is written to the screen, and the one byte that changes is a while-loop counter doing the decrunching?
There are 40x25=1000 chars on a C64 screen, so would ~500 chars be realistic for a decrunch routine?
raster bars are either done by specific hardware (copper lists on Amiga, etc), or carefully timed CPU code so that the color changes always happen in places where you can't see them.
On the other hand, the decruncher color changing will not be particularly synced to anything, they just happen at various places in the decrunching code. And the color change may then happen at random places in the midle of the screen, where you can see them.
On the other hand, the decruncher color changing will not be particularly synced to anything, they just happen at various places in the decrunching code. And the color change may then happen at random places in the midle of the screen, where you can see them.
the crunchy crumble croquets are addictive.
Screen flashing on Amiga, Atari etc. is basically just the intention to show that the CPU is still busy, otherwise staring on the screen for half a minute and nothing happens might rise the question whatever is happening, or if anything is going on at all.
On C64, to use all the memory available, the depacking routine is getting copied into screen ram (like you described it) and there you can really see how it is working... :)
On C64, to use all the memory available, the depacking routine is getting copied into screen ram (like you described it) and there you can really see how it is working... :)
Hehe, some crunchers let YOU decide how to show it´s still depacking (at work) by letting you choose which register to write the random depacked values to...
backgroundcolor would be $d021 on c64 or $d020 for the border
backgroundcolor would be $dff180 on Amiga
...but what if you chose some Audio-Register? ;) That´s the strange noises some depackers especially on c=64 gave you, i love them! :)
backgroundcolor would be $d021 on c64 or $d020 for the border
backgroundcolor would be $dff180 on Amiga
...but what if you chose some Audio-Register? ;) That´s the strange noises some depackers especially on c=64 gave you, i love them! :)
hardy: yes.. back in the 90's there were crunchers on C64 where you can pick decrunching effects from a big variety and even choose different combinations. so, that's almost the question: is it about getting the file as small as possible or rather get it started with insane flickering screen plus wild noise... :)
There are all kinds of ways to indicate that something's happening. It's the same as for loading which also took lots of time. So on Spectrum you have the loading border colors mimicking the last byte read as well, so that they become visualizers for the actual data loaded.
The reason that the stripes are not straight is because the CPU is changing the hardware color registers directly. The video chip runs on a synchronized clock which is much higher than 15 kHz for each pixel line to output. This means that most of the time, the CPU clock will be executing the color change instruction in the middle of a pixel line. You could busy-wait with the CPU until the end of the pixel line to make them straight, but that would waste 50% CPU power. You could have a synced interrupt running, changing the color, but that would also cost CPU time. On Amiga, you could poke a Copper List, and that would take a minimal amount of DMA time.
You can indicate this with colors, chars, anything you want. It's basically a loading bar, and you could have the loader or decruncher message any effect running to visualize it, turning the decrunch into an effect on its own - though that effect would have to be decrunched separately first (or appended uncrunched, wasting media space which is the reason for crunching in the first place).
Since it's possible to do this any way you like, but if you see a growing and shrinking, overwritten "char garbage" area on the screen, it typically reflects patterns, blocks, or segments from the stack, using the screen memory as buffering space. Since the screen memory is never used for storing program code, this is a smart way for tight fits: to decrunch a big program that barely fits in the rest of the memory when decrunched. So in this case, it serves not only as an indicator that something's happening, but also has a programming benefit.
The reason that the stripes are not straight is because the CPU is changing the hardware color registers directly. The video chip runs on a synchronized clock which is much higher than 15 kHz for each pixel line to output. This means that most of the time, the CPU clock will be executing the color change instruction in the middle of a pixel line. You could busy-wait with the CPU until the end of the pixel line to make them straight, but that would waste 50% CPU power. You could have a synced interrupt running, changing the color, but that would also cost CPU time. On Amiga, you could poke a Copper List, and that would take a minimal amount of DMA time.
You can indicate this with colors, chars, anything you want. It's basically a loading bar, and you could have the loader or decruncher message any effect running to visualize it, turning the decrunch into an effect on its own - though that effect would have to be decrunched separately first (or appended uncrunched, wasting media space which is the reason for crunching in the first place).
Since it's possible to do this any way you like, but if you see a growing and shrinking, overwritten "char garbage" area on the screen, it typically reflects patterns, blocks, or segments from the stack, using the screen memory as buffering space. Since the screen memory is never used for storing program code, this is a smart way for tight fits: to decrunch a big program that barely fits in the rest of the memory when decrunched. So in this case, it serves not only as an indicator that something's happening, but also has a programming benefit.
Ok, this raises more questions =)
Screen ram is that the 25x40 chars?
Could the code be executed from screen ram? If, was it slower than main memory?
Wasn't it difficult to read back the chars from the screen?
I had completely missed that the noise during some decrunchers had a meaning. That makes it even more cool!!! =)
Were there many crunchers on the C64? And was it like on the Amiga, where they were intended for others to use?
Screen ram is that the 25x40 chars?
Could the code be executed from screen ram? If, was it slower than main memory?
Wasn't it difficult to read back the chars from the screen?
I had completely missed that the noise during some decrunchers had a meaning. That makes it even more cool!!! =)
Were there many crunchers on the C64? And was it like on the Amiga, where they were intended for others to use?
yes, there are loads (and probably a lot more without the word "cruncher" in them).
Crunchers/Packers scenewise appeared to get cracktros smaller, so they fit the few bytes left on a Disk. Later they got used to shrink Disk-sized Games into small onefilers, so a Disk could hold several games instead of just one.
The Screen Ram on c64 f.e. is about 1kb in size, so 1kb out of 64kb the machine had...of which the System took away about the half already, but well...using those extra 1kb was/is almost mandatory for the amounts of data that get shuffled.
Reading back chars from screen: you don´t really need to do anything difficult here...data is in bytes and chars are declared as bytes...so every data-byte you read is displayed as a char like declared in the PetScii-Table. So if you have some data-byte $21 it would be shown as "!" (an exclamation mark) on the screen...but at the same time it remains pure data, so it can still be used as that from anywhere, as screen-ram is handled as every other ram that´s read-/writeable.
So normally you use the screen-ram for garbage-data, that won´t be needed anymore at runtime...freeing the screen-ram is unneeded aswell, as you´ll paint sth in there anyway!
c64-screen-ram
P.S.: In the same way bytes that are used as chars use the PetScii-Table to know what it is, you can view bytes that represent code and even read that byte-code if you get used to it:
if you spot a $20 in a code-data-block you know its an assembler-instruction known as JSR (Jump to SubRoutine):
illegal opcode table
The Screen Ram on c64 f.e. is about 1kb in size, so 1kb out of 64kb the machine had...of which the System took away about the half already, but well...using those extra 1kb was/is almost mandatory for the amounts of data that get shuffled.
Reading back chars from screen: you don´t really need to do anything difficult here...data is in bytes and chars are declared as bytes...so every data-byte you read is displayed as a char like declared in the PetScii-Table. So if you have some data-byte $21 it would be shown as "!" (an exclamation mark) on the screen...but at the same time it remains pure data, so it can still be used as that from anywhere, as screen-ram is handled as every other ram that´s read-/writeable.
So normally you use the screen-ram for garbage-data, that won´t be needed anymore at runtime...freeing the screen-ram is unneeded aswell, as you´ll paint sth in there anyway!
c64-screen-ram
P.S.: In the same way bytes that are used as chars use the PetScii-Table to know what it is, you can view bytes that represent code and even read that byte-code if you get used to it:
if you spot a $20 in a code-data-block you know its an assembler-instruction known as JSR (Jump to SubRoutine):
illegal opcode table
Funny to think that loaders and crunchers had so much in common.
Interesting that making straight raster bars would come at such a high performance hit!
Cool that it could be used for buffering! Why wasn't the screen ram used for storing program code?
Awesome that so many crunchers can still be downloaded! I wonder if any of them still would be considered state of the art?
Ahh, ok, so screen ram is regular system ram. Now it makes sense. Thanks a lot for clearing that out =)
Interesting that making straight raster bars would come at such a high performance hit!
Cool that it could be used for buffering! Why wasn't the screen ram used for storing program code?
Awesome that so many crunchers can still be downloaded! I wonder if any of them still would be considered state of the art?
Ahh, ok, so screen ram is regular system ram. Now it makes sense. Thanks a lot for clearing that out =)
Actually the colors mean:
Yellow = Buffer overdue
Red = Keyboard overheating, or communist revolution imminent
Blue = Fuckings to lamers
Green = Environmental hazard
Yellow = Buffer overdue
Red = Keyboard overheating, or communist revolution imminent
Blue = Fuckings to lamers
Green = Environmental hazard
Some old Amiga crunchers (PowerPacker for instance, which I think is one of the crunchers that popularized color flashing on Amiga) uses a counter (increasing or decreasing, I am not sure) for the color value, resulting in smooth, rainbow'ish color flashing.
Shrinkler uses the current state of the range decoder, which essentially amounts to random data, so its flashing looks quite different - more scrambled.
Shrinkler uses the current state of the range decoder, which essentially amounts to random data, so its flashing looks quite different - more scrambled.
Quote:
Funny to think that loaders and crunchers had so much in common.
People are copycats. Just look at the dozens of ProTracker clones. ;)
Does Shrinkler beat all the Amiga crunchers like Crunch Mania, Crunch, Stone Cracker, etc?
Crunch (1.4b) were not widely known from my understanding, but it could often beat all the others in 4k intros.
Crunch (1.4b) were not widely known from my understanding, but it could often beat all the others in 4k intros.
Quote:
Could the code be executed from screen ram? If, was it slower than main memory?t
I don't think it was any slower... but screen blanking gave you a 15% increase in performance. I also remember this was necessary for loading from tape drive to keep same speed with VIC20.
Quote:
Ahh, ok, so screen ram is regular system ram. Now it makes sense. Thanks a lot for clearing that out =)
C64 memory went from $0000 to $FFFF. Some of it was attached to certain things however like decimal 53280 53281. You could use these to store values. A side effect would be that the background and foreground colours would change as those values changed. So you couldn't write a block of code here but you could use them to store things. Other parts of memory if they were used for program code or storage would probably lock up your computer.
But you could put machine code in alot of other places... I think I remember some would use the tape buffer for instance.
I swear that sometimes the ram in the 1541 drive was used to execute code to make the c64 do certain things.
Quote:
The Screen Ram on c64 f.e. is about 1kb in size, so 1kb out of 64kb the machine had...of which the System took away about the half already, but well...using those extra 1kb was/is almost mandatory for the amounts of data that get shuffled.
No. not true. In Basic yes, but crunchers would be in assembly, so you'd have the 32k Basic + $A000-$BFFF, $C000-$CFFF, $E000-$FFFF 8+4+8, so you'd have 52k.
Very interesting read!!
What happens in the case, where a game e.g. had 3 intros?
What I mean is, would each group add their intro, and then crunch everything? Or would they first crunch their own intro and then add it?
From a memory point of view, how would that work out? I mean, when you enter the first intro, then everything will be placed at the end of the memory, right? Would the next intro then first move everything to the beginning of memory and then decrunch and place the output to the end of memory?
What happens in the case, where a game e.g. had 3 intros?
What I mean is, would each group add their intro, and then crunch everything? Or would they first crunch their own intro and then add it?
From a memory point of view, how would that work out? I mean, when you enter the first intro, then everything will be placed at the end of the memory, right? Would the next intro then first move everything to the beginning of memory and then decrunch and place the output to the end of memory?