| |
TSM
Registered: Jan 2007
Posts: 42 |
De-Exomize directly to color RAM?
1) Can I achieve this with the 'sfx' command?
2) Can I do it with the 'mem' command and the decruncher sources included in my project?
3) Is it impossible, i.e. am I forced to decrunch the data somewhere else and copy it to color RAM afterwards? |
|
| |
algorithm
Registered: May 2002
Posts: 705 |
Not recommended to depack directly to color ram if there is anything that requires d800 (e.g mcol bitmap etc, mcol char) unless you want to code a "glitch" demo.
The sfx self extractor does not overwrite IO area when depacking but rather, the ram underneath (maybe there are flags where io can be switched in)
Recommended to depack somewhere else, and then to plot to $d800 after |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
if pack ratio is important, better use a custome routine since d800 needs only 4 bits, that is instant 50% gain. |
| |
spider-j
Registered: Oct 2004
Posts: 498 |
No. 2) would be possible, although maybe not with the best pack ratio like Oswald said. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
As said above, possible but what are you trying to achieve? Maybe there is a better solution? |
| |
TSM
Registered: Jan 2007
Posts: 42 |
Quote: As said above, possible but what are you trying to achieve? Maybe there is a better solution?
The idea was to use Exomizer both for compression and to put every block of data where I need it. They are bitmap, screen and color of a multicolor picture, which I want to place at $E000, $D000 and $D800 respectively. |
| |
Mixer
Registered: Apr 2008
Posts: 452 |
Do 2) modify decruncher to write how you like where you like. Writing to IO d800 colorram only keeps low 4 bits of byte. If you need high bits during the process or after, then keep a copy. |
| |
TSM
Registered: Jan 2007
Posts: 42 |
Thank you all for your replies! I'll probably follow Mixer's advice. |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
What you're describing is pretty much exactly what I do in Donkey Kong Junior. |
| |
j0x
Registered: Mar 2004
Posts: 215 |
Isn't this risky? Assume you want to fill $d800-$e100 with $01. Exomizer (I'm assuming it's decompressing forward) will probably write $01 into $d800 and then make a copy of length $8ff. However, the value read from $d800 (and onward) and copied may be $f1, not $01, which will corrupt your bitmap data.
If the decompression happens backwards, the same applies, except your screen data may get corrupted because of the high bits of $d800. |
| |
Mixer
Registered: Apr 2008
Posts: 452 |
Cat loses its skin a few times. Risk is when there are unknowns. |
... 7 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
