 Previous Messages |
Posted By
MMS
on 2019-12-08
14:13:10
 |  Re: Exomizer & load address
It should be the right sequence then?
-The first picture should be decompressed to $1800-3FFF, return(RTS)
-show it as normal GFX, after Graphic1,1
-Load the next compressed picture (without color) with exomizer to eg. $6000
-when ready switch the bitmap address to $6000 ($FF12), but do not touch color ram address($FF14)
-Load the next compressed picture (without color) with exomizer to $2000
-when ready switch the bitmap address to $2000 ($FF12), but do not touch color ram address($FF14)
repeat...
|
|
Posted By
Lavina
on 2019-12-08
06:56:45
 | Re: Exomizer & load address
That is what we do in trackmos... Kind of buffering. One thing is happening on the screen (and in the used memory) while the rest of the memory (that is not needed currently) is being loaded for the next effects..
|
|
Posted By
MMS
on 2019-12-08
06:32:15
| Re: Exomizer & load address
Kichy: I think your suggestion in the bracket is the fastest, it is a blink of eye to switch the displayed memory segment to the invisible buffer, then vice versa.
|
|
Posted By
KiCHY
on 2019-12-08
02:11:23
| Re: Exomizer & load address
What Mad really wanted to write:
- You would need to flip $FF14 (colorscreenmem).
You told that yours are monochrome images. Perhaps, in that case, you can keep the same colors and you need only one color memory (even you don't need to compress with the images, you can build that up by code).
Changing the decompression address of unpacker can be difficult. If you can't solve that, another solution can be this way:
1. Load image
2. Unpack to invisible buffer, for example $6000-7F40.
3. Copy invisible buffer to visible buffer, for example $2000-$3F40. This is fast, but still visible (the fastest is changing the bitmap address).
4. goto 1.
|
|
Posted By
Mad
on 2019-12-08
04:21:49
| Re: Exomizer & load address
A "TED" Freeze is actual what every (demo)coder would need on these machines. Sadly such stuff didn't exist for our computers. The normal way to handle this is to use a "Doublebuffer". So you display one picture and load the next to another memory position. Then you switch to display the newly loaded picture and load into the other buffer. So you flip the buffer everytime and the loading happens in the background.. You would need to flip $ff1e (colorscreenmem edit after reading Kichys post below: actually it's ff14 :)) and the bitmap pointer at $ff12..
Another edit: With a Ted freeze "almost all" demo effects wouldn"t be possible!! :)
|
|
Posted By
George
on 2019-12-07
21:03:24
 | Re: Exomizer & load address
@Mad
Thank you. That worked. I guess, the packer decompresses direct to screen memory and that why we see this effect.
Is there a way to avoid the screen disabling while still direct decompress in screen memory (without going the way to decompress at another memory location first, then copy to screen memory)? Mybe a kind of TED Freeze.
Maybe there are other decompression modes, which decompress straight forward whitout that effect...
|
|
Posted By
Mad
on 2019-12-07
20:24:21
| Re: Exomizer & load address
George:
I think the disturbance effect may be the actual decrunching of the picture. May that what you see is the packer at work!  .. One solution would to do a
lda #$00
sta $ff06
before loading to disable the screen and afterwards a:
lda #$3b
sta $ff06 ; to enable the screen in bitmap mode again
label: jmp label ; here has to be a waiting for a keypress or something instead
May be that helps already.. But I too think bitfire is fine for picture a disc..
|
|
Posted By
George
on 2019-12-07
15:16:07
| Re: Exomizer & load address
I tried bitfire and the demo-slideshow.
The slide-demo has that demoeffect during the loading (disturbances lines within the picture). Is there somekind of switch for that? i could no figure out how to set this off.
|
|
Posted By
Lavina
on 2019-12-06
13:41:40
| Re: Exomizer & load address
go with Bitfire
|
|
Posted By
George
on 2019-12-06
06:01:48
| Re: Exomizer & load address
@KiChy I tried out exomizer in BASIC (loading raw data) and its like you said:
It comes with an selfextractor and a jmp-adress after selfextracting. I set the value of the jmp adress to byte 60 (rts) and it jumped back to BASIC. Worked fine so far. In my experiment i extracted directy to Graphics memory (1800-FFFF).
The idea behind all this experiments: I want to try a kind of picture streaming for a small animation. Contantly loading compressed pictures from the drive and decompress in (bitmap) memory (one after the other). I would do this in assembly. Just for fun and see the possible speed.
The pictures are monochrome (2 color, Hires Mode), so the compression-rate should be high.
I am sure people have done this before. So any helps and tips are welcome.
|
|
Posted By
KiCHY
on 2019-12-06
05:40:41
| Re: Exomizer & load address
@George: you can load your compressed image with any method, even with kernel functions. The important thing is you need the unpacker code somewhere in memory. It comes either with loaded compressed data (self-extracting program) or you have to supply it separately.
We really need to know more about your environment to give better help Are you still in basic with SYSing machine code or full machine code?
|
|
Posted By
George
on 2019-12-06
03:39:25
| Re: Exomizer & load address
bubis thank you-
I also read about PuCrunch. Are there differences in the performance between the four (decrunch speed) from your experience?
|
|
Posted By
bubis
on 2019-12-05
18:06:51
| Re: Exomizer & load address
There are at least three loaders that can do this for you. SIZ's loader, Krill's loader and Bitfire+4. The last one only supports bitnax compression, the others support Exomizer and other methods too.
|
|
Posted By
George
on 2019-12-05
16:06:29
| Re: Exomizer & load address
Sorry recovering this old thread, but i want to do the same as Kicky.
I want load a compressed picture and unpack it in memory to show it.
If i understand this right:
* you pack the raw data with exomizer
* Then load the file und it unpacks itsself at a dedicated adress? or do id have to call a procedure?
EDIT: I looked it up at the wiki page!
|
|
Posted By
KiCHY
on 2010-05-26
02:59:21
| Re: Exomizer & load address
Thanks for explanation. So we have to live with it.
|
|
Posted By
Csabo
on 2010-05-24
21:57:42
| Re: Exomizer & load address
That should already be pretty clear, but I'll chime in since I was wondering about this myself just last month and asked Magnus directly. My question was:
> [...] Exomizer displays something like this:
>
> Memory layout:
> Data covers $0FFE to $4830.
> Decrunch table is located at $0334 to $03D0.
>
> In the above example, the data should start at $1000 [...]
His reply:
"I should probably document this somewhere too The "data covers" interval is not only for the decrunched data but *also* for the crunched data. If it prints $0ffe for a file that starts at $1000 then it means that two bytes is the minimum overlap that allows for correct decrunching. The decruncher will make sure that the crunched data starts at $0ffe by copying all or parts of it before beginning the actual decrunch.
So together with the target file itself, the stack area and a few zero page locations, the "data covers" and "decrunch table" memory intervals should be the only areas that are overwritten by the decrunch process.
I hope this explains it."
|
|
Posted By
NinjaDRM
on 2010-05-24
20:54:13
| Re: Exomizer & load address
This is a safety buffer and can't be avoided. It is needed because exomizer depacks from the end of the file to the front and could overwrite its own data (endmarker!) otherwise. I usually reserve 8 bytes and that was always enough, though 4 might also do for most cases.
|
|
Posted By
KiCHY
on 2010-05-24
11:58:03
| Exomizer & load address
Hi,
I played with exomizer a bit and found something i don't understand, or, i don't see the point why exomizer works that way.
I wanted to simulate that case when a program has data at $1000-$17FF, has a free space at $1800-$3F40 and wants to load a compressed bitmap from disk and decrunch in memory, then display it.
I saved an empty bitmap (test.prg) from $1800-$3F40. I used exomizer to crunch it with this command:
exomizer.exe mem test.prg -o test.exo
During compression exomizer writes a log into the console window:
...
filename: "test.prg", loading from $1800 to $3F40
...
Length of crunched data: 35 bytes. (remember: empty bitmap 
The load address is $17FE - $1823.
Literal sequences are not used and the safety offset is 2.
So, if I trust in exomizer and simply my program loads the compressed image, it loses 2 bytes of data at $17FE & $17FF.
My question is simply: why exomizer subtracts 2 bytes from load address and how can I instruct exomizer to avoid this?
|
|
