| |
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. |
| |
TSM
Registered: Jan 2007
Posts: 42 |
I tried method #3, which I'm happy with, but the unpacker's code overwrites some data that I need in the area $02A7 - $03FB (a tape loader).
I guess there's no way to move the unpacker somewhere else without compiling it myself, right? |
| |
spider-j
Registered: Oct 2004
Posts: 498 |
If you're not sure how to use exomizer source I made a really easy readme/howto with example files for acme a couple of years ago (the file link in the first post):
http://www.forum64.de/wbb3/board25-coder-unter-sich/board308-pr..
(while it's a german forum the actual howto is in english) |
| |
ruk
Registered: Jan 2012
Posts: 43 |
As long as you don't load your data in I/O-space you should be fine. E.g if having load-address set to $d804 the crunched data's upper nibbles will be garbled. Decrunching to $d800 from somewhere else should be OK though methinks but it will be glitchy as Algorithm said, if not using hires bitmap mode or disabled display.
Use -Di_table_addr=<address> to specify where exomizer can store its decrunch table. Defaults to tape buffer area. Size is 156bytes. |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
Of course the screen has to be disabled when running the exomizer decrunch. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
why? just setup $01 correctly? |
| |
TSM
Registered: Jan 2007
Posts: 42 |
Even though the lowest address used by my data is $C000, the decruncher zero-fills the memory all the way up to $0801 (or so)! This prevents me from moving the decrunch table to $1000 or whatever. It's also annoying because it takes time. Can the zero-filling be disabled?
Thank you.
PS:
Here's my data
programma.prg ($C000 - $C080)
immagine.scr ($D000 - $D3E7)
immagine.bmp ($E000 - $FF3F)
immagine.col ($D800 - $DBE7)
Edit: immagine.col is actually $1800 - $1BE7, then my program moves it to $D800. Perhaps I was wrong and the zero-fill doesn't occur. I'm looking into it. |
| |
TSM
Registered: Jan 2007
Posts: 42 |
Solved!
I put the .col file at $9800 and the decrunch table at $1000. The speed has increased as well.
Thank you all! |
