aplib decompressor for ZX Basic.

[na_th_an]

1. Download the compressor -> <!-- m --><a class="postlink" href="http://www.mojontwins.com/warehouse/apack.zip">http://www.mojontwins.com/warehouse/apack.zip</a><!-- m -->
2. Pack your binaries using it:

Code:

> apack.exe input.bin output.bin

3. Include your packed binaries in your program

Code:

packed: Asm Binary "output.bin" End Asm

4. Include the aplib decompressor (by dwedit/metalbrain/utopian) in your program

Code:

#include once "aplib.bas"

5. Call the depacker to decompress your binary to somewhere else (source, destination):

Code:

aplibUnpack (@packed, 16384)

Here's aplib.bas:

Code:

'' aplib.bas Sub aplibDummyContainer asm ; aPPack decompressor ; original source by dwedit ; very slightly adapted by utopian ; optimized by Metalbrain ; Adapted for ZX Basic by na_th_an ;hl = source ;de = dest depack: ld ixl,128 apbranch1: ldi aploop0: ld ixh,1 ;LWM = 0 aploop: call ap_getbit jr nc,apbranch1 call ap_getbit jr nc,apbranch2 ld b,0 call ap_getbit jr nc,apbranch3 ld c,16 ;get an offset apget4bits: call ap_getbit rl c jr nc,apget4bits jr nz,apbranch4 ld a,b apwritebyte: ld (de),a ;write a 0 inc de jr aploop0 apbranch4: and a ex de,hl ;write a previous byte (1-15 away from dest) sbc hl,bc ld a,(hl) add hl,bc ex de,hl jr apwritebyte apbranch3: ld c,(hl) ;use 7 bit offset, length = 2 or 3 inc hl rr c ret z ;if a zero is encountered here, it is EOF ld a,2 adc a,b push hl ld iyh,b ld iyl,c ld h,d ld l,e sbc hl,bc ld c,a jr ap_finishup2 apbranch2: call ap_getgamma ;use a gamma code * 256 for offset, another gamma code for length dec c ld a,c sub ixh jr z,ap_r0_gamma ;if gamma code is 2, use old r0 offset, dec a ;do I even need this code? ;bc=bc*256+(hl), lazy 16bit way ld b,a ld c,(hl) inc hl ld iyh,b ld iyl,c push bc call ap_getgamma ex (sp),hl ;bc = len, hl=offs push de ex de,hl ld a,4 cp d jr nc,apskip2 inc bc or a apskip2: ld hl,127 sbc hl,de jr c,apskip3 inc bc inc bc apskip3: pop hl ;bc = len, de = offs, hl=junk push hl or a ap_finishup: sbc hl,de pop de ;hl=dest-offs, bc=len, de = dest ap_finishup2: ldir pop hl ld ixh,b jr aploop ap_r0_gamma: call ap_getgamma ;and a new gamma code for length push hl push de ex de,hl ld d,iyh ld e,iyl jr ap_finishup ap_getbit: ld a,ixl add a,a ld ixl,a ret nz ld a,(hl) inc hl rla ld ixl,a ret ap_getgamma: ld bc,1 ap_getgammaloop: call ap_getbit rl c rl b call ap_getbit jr c,ap_getgammaloop ret End Asm apDataPool: Asm ap__source: defw 0 ap__destination: defw 0 End Asm End Sub Sub aplibUnpack (source as uInteger, destination as uInteger) Poke uInteger @apDataPool, source Poke uInteger 2 + @apDataPool, destination Asm ld hl, (ap__source) ld de, (ap__destination) di push ix push iy call depack pop iy pop ix ei End Asm End Sub

Happy coding!

[slenkar]

do you have an example?

What kind of data can be packed? (bytes,ints,strings?)

[boriel]

This will be in the ZX Library. May I bundle it with the compiler? :?:
If so, in the Mojon Twins directory?

[slenkar]

how does someone know where to unpack a bin?
How do I know where there is empty space in RAM?

[na_th_an]

You can pack whatever binary data.

how does someone know where to unpack a bin? - You unpack it where you need it to be.

For example, you can pack a .scr picture (6912 bytes usually compress to under 3 Kb, and even less if the screen is not very complex: I've gotten ~500 bytes for a logo or a frame) and then unpack it to 16384 to display it. You can pack your map data, and have several maps stored in memory, and then unpack the current level to your reserved space.

For example, say that you are using rectangular maps for 4x4 screens of 15x10 tiles each. Your map would be a 4x4x15x10=2400 bytes binary. You have to store somewhere, and have several compressed maps (depending on map complexity, you can save quite a bunch of bytes:

Code:

Sub mapContainer () mapdata: Asm mymap: defs 2400, 0 End Asm level1: Asm binary "level1c.bin" End Asm level2: Asm binary "level2c.bin" End Asm level3: Asm binary "level3c.bin" End Asm End Sub

To unpack level1 and use it, just...

Code:

' unpack level 1: aplibUnpack (@level1, @mapdata)

Then your engine reads the current level map data from @mapdata. When the player finished level 1 and level 2 is needed, you just unpack from @level2 to @mapdata and you have a brand new map.

Stuff like that. I use it all the time for almost everything.


As for examples, I have to clean up the source code of this game, which I hope to be sharing with you all very soon - and you'll have a working example (the logo and the backdrop are compressed images).

@Boriel: do as you wish - but the code is not mine, I just interfaced it. I'm releasing a 128K version soon - an easy way to use the extra RAM pages to store data - like some kind of "virtual storage". We use this for our 128K games in C: several levels, tilesets, and spritesets are stored compressed in the extra RAM. Mapdata, tileset and spriteset for the current level are decompressed from there to low ram buffers when entering a level. Afterwards, the game behaves like a 48K game. It's a good solution which works great and helps you avoid multi-loads

[slenkar]

thanks for the explanation,

how is @mapdata first defined? is it an array,a memory address?

and how do you turn all those bytes into a BIN file?

[britlion]

I've used the compressor in the zx basic library to do the same thing. ( <!-- m --><a class="postlink" href="http://www.boriel.com/wiki/en/index.php/ZX_BASIC:MegaLZ.bas">http://www.boriel.com/wiki/en/index.php ... MegaLZ.bas</a><!-- m --> ) - it works exactly the same way. I'll have to compare and see if this one squishes better, or runs faster

Slenkar:

What you do is compress the data outside an emulator. For example, one game I'm working on (it may even get finished one day) puts up 1/3 of the screen banner graphics by decompressing to the screen memory. 1/3 of the screen is a handy size, because 2K of data fits there neatly, so it's just like doing a full screen in effect.

How do I do that? Well, I design the screen in a graphics package, and when it's together I test it on an emulated spectrum to make sure it looks right. Then, in spin, I export the data from 16384 (the screen memory) for 2K to a file.

I then compress this file with megalz using a command prompt on my PC. Na_th_an's aplib works the same way, but obviously it's different code.

Then you can #include the compressed code inside an asm context, and add in the decompressor code, and voila - zipped up graphics.

[britlion]

1. Download the compressor -> <!-- m --><a class="postlink" href="http://www.mojontwins.com/warehouse/apack.exe">http://www.mojontwins.com/warehouse/apack.exe</a><!-- m -->

I don't think this link is working, Na_th_an?

[slenkar]

I've used the compressor in the zx basic library to do the same thing. ( <!-- m --><a class="postlink" href="http://www.boriel.com/wiki/en/index.php/ZX_BASIC:MegaLZ.bas">http://www.boriel.com/wiki/en/index.php ... MegaLZ.bas</a><!-- m --> ) - it works exactly the same way. I'll have to compare and see if this one squishes better, or runs faster

Slenkar:

What you do is compress the data outside an emulator. For example, one game I'm working on (it may even get finished one day) puts up 1/3 of the screen banner graphics by decompressing to the screen memory. 1/3 of the screen is a handy size, because 2K of data fits there neatly, so it's just like doing a full screen in effect.

How do I do that? Well, I design the screen in a graphics package, and when it's together I test it on an emulated spectrum to make sure it looks right. Then, in spin, I export the data from 16384 (the screen memory) for 2K to a file.

I then compress this file with megalz using a command prompt on my PC. Na_th_an's aplib works the same way, but obviously it's different code.

Then you can #include the compressed code inside an asm context, and add in the decompressor code, and voila - zipped up graphics.

yes graphics packages export to BIN thankfully, but like what about some level data like a bunch of bytes
how do I get the BIN file?

[LCD]

yes graphics packages export to BIN thankfully, but like what about some level data like a bunch of bytes
how do I get the BIN file?

What do you use to create levels? Does it have binary export?

[slenkar]

I would probably input the numbers manually or make a tool myself

[LCD]

I would probably input the numbers manually or make a tool myself

Then you can use:

Code:

label: asm defb 0,0,0,0,0,0,0,0,0,0 ;' your binary data defb 1,2,4,4,5,2,0,0,0,0 ;' your further binary data end asm

As for decompression address you can make a buffer with a label in similar fashion, and re-use it for decompressing all levels one by one. I used similar method in "U-Boot hunt" to decompress all frames of the explosion in real time (I used the MegaLZ compression, because BorIDE can compress selected DEFB's with MegaLZ).

[slenkar]

If I input the number into the .bas file like this

Code:

label: asm defb 0,0,0,0,0,0,0,0,0,0 ;' your binary data defb 1,2,4,4,5,2,0,0,0,0 ;' your further binary data end asm

it wont be compressed, I have to somehow make a BIN file out of these numbers to run through the compressor

[LCD]

If I input the number into the .bas file like this

Code:

label: asm defb 0,0,0,0,0,0,0,0,0,0 ;' your binary data defb 1,2,4,4,5,2,0,0,0,0 ;' your further binary data end asm

it wont be compressed, I have to somehow make a BIN file out of these numbers to run through the compressor

Not if you use the BorIDE's build in MegaLZ compressor...
After you enter these and are happy with level design, select all the DEFB Statements and select "Edit" -> "DEFB Modificaton" -> "MegaLZ Compression". This will replace all DEFB with compressed version.
I will add ApLib compression later too.

[britlion]

Boride gets better and better. Going to add in aplib support too?

Slenkar - you can still do it by hand. Compile the defb statements in, run spin, load the file, export the bin file out from the right address. You can use the debugger to find out where it is if you can't work that out. Done.