Lz4 depacking into banks

[Heaven/TQA]

I wanted to adapt lz4 depacker for depacking into banks. Right now I have adapted the store byte part where it checks if more than 16k were written and if so it would switch the bank.

 

So read byte I would switch to XL ram and at store byte I would switch to one of the banks.

 

It does not work but does the LZ4 rely on data which might be stored in another bank?

 

The packed file is less than 6k but depacked several banks.

 

Workaround at the moment split the file into 16k chunks and pack/depack those separately.

[pirx]

it is using already depacked data indeed. split to 16KiB chunks or use a buffer if you got space...

[Heaven/TQA]

pirx... right now I have a 64k source file, split that into 16k chunks and pack them separatly with LZ4.

 

so I run the depack routine 4x and set bank prior.

 

but can lz4 depacker not altered to depack automaticly into separate banks ("INC BANK" when window crossed)?

[Rybags]

You might be better off just considering as if you're addressing a 64K area, ie extended Ram. Then do the appropriate bit manipulations to set the bank and base address for each access.

Though the problem with doing that is you'd be adding a lot of processing time to the depack operation.

[Heaven/TQA]

Rybags... that's exactly what I am doing... (or thought I am doing )

 

But one my questions... does LZ4 rely on prior data depacked in different bank?

 

will post my depack code here later.

[Rybags]

https://en.wikipedia.org/wiki/LZ4_(compression_algorithm)

 

It relies on backwards references, so you'd need to implement bank-select algorithm for those too.

[xxl]

The format of the compressed data does not include the information in which the bank references the source, and you can not change the destination address, so you can not go back to the beginning of $4000 during decompression.

 

The easiest way is to compress the 16KB pieces and merge them into one file

 

http://xxl.atari.pl/lz4-decompressor/

[Heaven/TQA]

Ok... thought something like this...

 

So I stick to my already implemented split/pack/depacking 16k segments separately

[Heaven/TQA]

The second field represents the number of bytes to copy from the already decoded output buffer (with 0 representing the minimum match length of 4 bytes)

 

Should have read the specs

[Heaven/TQA]

XXL.... already using your / fox code

[Heaven/TQA]

You might be better off just considering as if you're addressing a 64K area, ie extended Ram. Then do the appropriate bit manipulations to set the bank and base address for each access.

Though the problem with doing that is you'd be adding a lot of processing time to the depack operation.

Thinking more about it that could work, too?

[pirx]

Do it Woz way - write virtual machine with automatic paging. I'd hit it