What does the decrunch colours mean?
category: code [glöplog]
gary9872: You could unmap the VIC chip if you needed extra RAM, but then you couldn't do anything with the screen, of course.
Quote:
Does Shrinkler beat all the Amiga crunchers like Crunch Mania, Crunch, Stone Cracker, etc?
Yes, it beats the compression ratios of all of these by a good margin. It also has a quite small size overhead, making it suitable for 4k intros.
On the other hand, it decompresses significantly slower that the others (though faster than its earlier incarnation ExeCruncher2), and the compressor is much slower and requires a lot of memory. It it primarily designed for cross-development (running the cruncher on a big, fast machine), though it does run on Amiga as well.
Quote:
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?
First crunch their own intro then add it" would be correct. If you watch after an intro you usually see another decruncher run.
Quote:
When you enter the first intro, then everything will be placed at the end of the memory, right?
Assembly code is non-relocatable so the other code has to be put where it won't be in the way of the current running code. Ideally, all the code should start at the same address.
Therorectically, you could crunch all your crunched intros, but I'm guessing there would be no space savings.
I hope this makes sense. :)
Quote:
gary9872: You could unmap the VIC chip if you needed extra RAM, but then you couldn't do anything with the screen, of course.
Heh heh true, but If we leave it on we can steal 25 to 30 bytes from the sprites.
Quote:
First crunch their own intro then add it" would be correct. If you watch after an intro you usually see another decruncher run.
What puzzles me here is the decrunch time for the second intro. It takes approx the same time as the first intro. So my thought was here that each group would crunch everything.
If however the C64 is really slow at decrunching each intro of perhaps 2kB ((?) I have no idea how large an intro is), then it makes a lot of sense =)
Quote:
Assembly code is non-relocatable so the other code has to be put where it won't be in the way of the current running code. Ideally, all the code should start at the same address.
Ok, so now it is complicated =) Let's say the intro order is: ACC, NEI, DOM.
Let's say DOM crunches the game, crunch their intro and then append it. Is it correct that DOM would place the crunched game (which is large compared to the intro) in the beginning of memory and their own intro right after the crunched game? So when the intro decrunches, it would place the decrunched intro data and code at the end of memory?
And when the intros exits, the game would decrunch to the end of memory overriding the DOM intro?
Quote:
Therorectically, you could crunch all your crunched intros, but I'm guessing there would be no space savings.
There is never anything to gain there space wise. Even if the first cruncher is a simple RLE routine.
Quote:
I hope this makes sense. :)
I'll know when I read your new reply =)
Quote:
There is never anything to gain there space wise. Even if the first cruncher is a simple RLE routine.
Not correct, applying two general-purpose packing algorithms usually does not yield any gains, but if one of them is a specialized packer, its results may still be optimized by a general-purpose packer (example: compressing an IT file with compressed samples with zip or 7z is still smaller than just zipping the uncompressed samples, because zip/7z does not work well with PCM data). Same can apply to whatever crunching routines would be used in your example.
no, frist the intro, lets say from $0801 to $4000, the crunched game from $4000...
after "press space" a transfer routine is written to $0400 (screen mem). jmp $0400, now that routine transfers the crunched game from $4000 to $0801 and does a jmp to its start, probably somehwere around $0801-$0810. dont forget to save the ghostbyte ($3fff) if your intro is messing with $d011 fld/border effects and the crunched game is before $4000. most intros were from $0801 to $2800-$3000 if i remember correcty... code at $0900-$1000, music from $1000-$2000, charset & gfx $2000...
after "press space" a transfer routine is written to $0400 (screen mem). jmp $0400, now that routine transfers the crunched game from $4000 to $0801 and does a jmp to its start, probably somehwere around $0801-$0810. dont forget to save the ghostbyte ($3fff) if your intro is messing with $d011 fld/border effects and the crunched game is before $4000. most intros were from $0801 to $2800-$3000 if i remember correcty... code at $0900-$1000, music from $1000-$2000, charset & gfx $2000...
we were somewhere around barstow when the drugs began to take hold...
Quote:
Not correct, applying two general-purpose packing algorithms usually does not yield any gains, but if one of them is a specialized packer, its results may still be optimized by a general-purpose packer (example: compressing an IT file with compressed samples with zip or 7z is still smaller than just zipping the uncompressed samples, because zip/7z does not work well with PCM data). Same can apply to whatever crunching routines would be used in your example.
Very nice example. I drew my conclusion from level packing First Samurai on the Amiga. It used RLE for each file on the trackloader and if I crunched them again, then the overhead from RLE made the files slightly larger.
Unpacking the RLE stuff and then packing them with a good cruncher made the game fit on one disk.
So I'd say if the first cruncher is weak, it is very likely crunching it again with a good cruncher doesn't give you any space savings.
Quote:
no, frist the intro, lets say from $0801 to $4000, the crunched game from $4000...
after "press space" a transfer routine is written to $0400 (screen mem). jmp $0400, now that routine transfers the crunched game from $4000 to $0801 and does a jmp to its start, probably somehwere around $0801-$0810. dont forget to save the ghostbyte ($3fff) if your intro is messing with $d011 fld/border effects and the crunched game is before $4000. most intros were from $0801 to $2800-$3000 if i remember correcty... code at $0900-$1000, music from $1000-$2000, charset & gfx $2000...
Now I get it. Clever to shift the data to a lower address each time!!
How come there were these standardized places in mem to put code, gfx, and sfx? Could the SID only address e.g. $1000-$2000?
I recall in the later classic FLT intro, they had optimized the music to ~800 bytes. The over all intro were very small, so I wonder if they also used such a big memory space?
i think $1000-$2000 was reserved for the original charset, or not accessible for custom gfx, so it was a good place for music.
I see. Thanks =)
"Screen ram is that the 25x40 chars?"
yes
"Could the code be executed from screen ram? If, was it slower than main memory?"
from the CPU's perspective its like any other memory location. Its just happens to be displayed by the video chip. On c64 all memory runs at same speed unlike on amiga. Thats because memory sharing is generally 50%-50% between Video and CPU. Sometimes the video chip needs more cycles tho, then it asks the cpu to stop. But this happens regardless of where is the cpu executing code. And this is based on WHEN the VICII needs to read sprite data fex. not tied to memory location of cpu's code execution.
"Wasn't it difficult to read back the chars from the screen?"
see above, its like any other memory for the cpu.
"Were there many crunchers on the C64? And was it like on the Amiga, where they were intended for others to use?"
shitloads. in the heydays many group made tools often were only for groupmates to use, be it cruncher music editor or whatever. though sooner or later they leaked, or were given away anyway.
"The Screen Ram on c64 f.e. is about 1kb in size, so 1kb out of 64kb athe machine had...of which the System took away about the half already,"
system doesnt really "takes away" memory on c64. its just ROM that is banked on top of RAM. but you can turn RAM back on with one mem write anytime in machine code, all demos use all 64k if they need it. no problem.
yes
"Could the code be executed from screen ram? If, was it slower than main memory?"
from the CPU's perspective its like any other memory location. Its just happens to be displayed by the video chip. On c64 all memory runs at same speed unlike on amiga. Thats because memory sharing is generally 50%-50% between Video and CPU. Sometimes the video chip needs more cycles tho, then it asks the cpu to stop. But this happens regardless of where is the cpu executing code. And this is based on WHEN the VICII needs to read sprite data fex. not tied to memory location of cpu's code execution.
"Wasn't it difficult to read back the chars from the screen?"
see above, its like any other memory for the cpu.
"Were there many crunchers on the C64? And was it like on the Amiga, where they were intended for others to use?"
shitloads. in the heydays many group made tools often were only for groupmates to use, be it cruncher music editor or whatever. though sooner or later they leaked, or were given away anyway.
"The Screen Ram on c64 f.e. is about 1kb in size, so 1kb out of 64kb athe machine had...of which the System took away about the half already,"
system doesnt really "takes away" memory on c64. its just ROM that is banked on top of RAM. but you can turn RAM back on with one mem write anytime in machine code, all demos use all 64k if they need it. no problem.
