Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user hllerena78 ! (Registered 2019-08-20) You are not logged in 
CSDb User Forums


Forums > C64 Coding > modify Exomiser compressor to black list some memory locations
2019-04-28 18:30
oziphantom

Registered: Oct 2014
Posts: 338
modify Exomiser compressor to black list some memory locations

Does anybody know a way to modify the exomizer compression algorithm to black list FF0X memory locations to never be read from, i.e don't allow them to be used as part of a sequence?

I guess a post process would also work, if there is a simple way to convert use a sequence to literal bytes..
 
... 16 posts hidden. Click here to view all posts....
 
2019-05-01 15:39
ChristopherJam

Registered: Aug 2004
Posts: 950
Quoting Krill
The decision should be made per sequence copy, not per source byte.


Sure, but it's still going to be slower than just blacklisting those particular source bytes. That's an extra check for every token - particularly harsh given that exo also uses copies for recently used single bytes.
2019-05-02 12:15
Krill

Registered: Apr 2002
Posts: 1241
Quoting ChristopherJam
Quoting Krill
The decision should be made per sequence copy, not per source byte.
Sure, but it's still going to be slower than just blacklisting those particular source bytes. That's an extra check for every token - particularly harsh given that exo also uses copies for recently used single bytes.
Yes, disallowing certain memory ranges on the compressor side is the preferred option, IF it is available. :)

Quoting ChristopherJam
That's an extra check for every token - particularly harsh given that exo also uses copies for recently used single bytes.
An extra check for every sequence-copy token. However, it should be highly optimisable. The check only needs to be performed once the problematic range has actually been written to, and as its high-byte is $ff, the back-reference check in flat memory space should allow for early exit. There may be more opportunities for optimisation.
2019-05-02 12:45
oziphantom

Registered: Oct 2014
Posts: 338
not write, read

so if when you are writing to $4000 and it wants to copy a 128 bytes sequence and that sequence starts at fE88, then the first 8 reads(as it reads from the top down) need to be the special read under FF0X code. So in order to know if it needs normal, or special, you need to do
(Start + X + Len).hi > ff where start and len are 16bits 'then do special' is probably the best case. It might be faster overall to just do Start.hi + Len.hi > fd and take the hit rather than take the hit of 16bits for the rest.

ChristopherJam is right Exomizer loves to do a sequence of 1 byte.

I have written Magnus Lind, and he sees that it might be useful for other systems as well, and if its not too much work he is happy to make "black list intervals" a feature of exomizer.
2019-05-02 13:54
Krill

Registered: Apr 2002
Posts: 1241
Quoting oziphantom
not write, read
A sequence cannot be read from before it has been written initially (and writing is not a problem, if i have understood you right). The write pointer is strictly ascending or descending depending on depack direction, and thus the range check is superfluous before the problematic range has been written to. This is why i wrote "The check only needs to be performed once the problematic range has actually been written to".
2019-05-02 14:13
oziphantom

Registered: Oct 2014
Posts: 338
ok I see what you are saying, do the forward decompress not the backwards decompress, this then means I only have to do the slow method for 255 bytes tops
2019-05-02 14:38
Krill

Registered: Apr 2002
Posts: 1241
No, what i said should apply to either depack direction.

I'm not quite sure which direction would give more optimisation opportunities for the $ff0X range check at the moment, but both would probably have to do with the difference of write pointer vs back-reference read pointer crossing the 64K bank boundary or not.

But if you intend to depack while loading, forward decompression is the way to go.
2019-05-02 14:54
oziphantom

Registered: Oct 2014
Posts: 338
wait that won't work, to get PHA one must go backwards.
Since its FF0X going backwards(assuming you start above it, and if you don't just use a version that skips the check altogether) gives you 248 bytes max that won't need the check garanteed.

If you go forward then you only have 248 bytes where one must check for FF0X however you can't use PHA to write..
2019-05-02 14:56
oziphantom

Registered: Oct 2014
Posts: 338
But if you intend to depack while loading, forward decompression is the way to go.

Why is forward better from loading? (apart from it saves you flipping the file )
2019-05-02 15:30
Krill

Registered: Apr 2002
Posts: 1241
Okay, then backward decompression is a given, so any potential performance differences to forward decompression are moot.

Forward decompression is usually suited better for decompression while loading mainly because loading itself is usually performed in the forward direction. You can then decompress in-place* in the same direction. That should work for backward compression as well, given that loading is done in the same direction as well.

* Read buffer (loaded compressed file) is a subset of the write buffer (decompressed file), both end at the same address using forward direction. For Exomizer, there are a few (3-ish) compressed bytes beyond the uncompressed data.
2019-05-11 09:25
oziphantom

Registered: Oct 2014
Posts: 338
Its in, and it works :D
Previous - 1 | 2 | 3 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
DuncanTwain
Dipswitch/Up Rough
Dymo/G★P
Thunder.Bird/HF/MYD!..
Alakran_64
Perff/No Name
blendo75
Mythus/Delysid
Guests online: 63
Top Demos
1 Unboxed  (9.7)
2 Uncensored  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 The Shores of Reflec..  (9.6)
7 Lunatico  (9.6)
8 Wonderland XII  (9.5)
9 C=Bit 18  (9.5)
10 Old Men in Used Cars  (9.5)
Top onefile Demos
1 LSR 64 V0.31  (10)
2 Smile to the Sky  (9.5)
3 Dawnfall V1.1  (9.5)
4 Crystal Gazer  (9.5)
5 Daah, Those Acid Pil..  (9.5)
6 Rewind  (9.5)
7 Instinct  (9.5)
8 Pandemoniac Part 5 o..  (9.5)
9 Innervasion  (9.4)
10 Bad Boy  (9.4)
Top Groups
1 Fossil  (9.8)
2 PriorArt  (9.7)
3 Performers  (9.6)
4 Oxyron  (9.4)
5 Censor Design  (9.4)
Top Hardware-Gurus
1 Soci  (9.9)
2 Grue  (9.8)
3 Zer0-X  (9.8)
4 Wiesel  (9.8)
5 Lemming  (9.7)

Home - Disclaimer
Copyright © No Name 2001-2019
Page generated in: 0.049 sec.