newcoleco

There are lots of Coleco pictures around into PowerPaint format, some made with original software, some converted from JPEG or BMP files by using a picture converter such as BMP2PP by Marcel deKogel or Dither. These pictures .pp files are size 10K or 40K each and aren't in a format convenient for ColecoVision projects but are used by ADAMites for their Holidays special slideshow disks. You can convert PowerPaint files into Dale Wick's .pc files and use them in Atarimax Coleco Ultimate SD Multicart or view them with a simple viewer on your PC. How to add PP files into ColecoVision projects? Extract PATTERN and COLOR tables from PowerPaint files with this command-line tool. This tool has a lot of options (flags) to deal with each situation, even an integrated splitter to extract PATTERN and COLOR tables to be loaded into VRAM. Download (EXE) Version 1.1 : pp2pc.zip Source code available on demand. (on Dale Wick's SVN server)

Dale Wick's .pc format is simply the PATTERN and COLOR tables one after the other, 6K each, into a 12K binary data. A manipulation I like to do is to split into two files to be able to compress each table individually to add pictures into my Coleco projects. There are lots of ways to extract PATTERN and COLOR tables from .pc files and here is my simple solution. Just drag and drop .pc files on this tool to get two 6K files identified with extensions .pattern and .color in an instant. Download compiled EXE : pcspliter.zip Download source : pcspliter_src.zip

Short answer : It takes raw files. Not limited to pictures. This is not a BMP to CV converter. Long answer : No, it's not an image converter, It's a tool to compress raw data into this format I named DAN1. Data in VRAM can be many things such as fullscreen pictures, charsets, game levels, etc. For BMP files, try an image converter such as like BMP2PP or DITHER to transform BMP into a picture file. Extract the PATTERN and COLOR data tables into binary files and apply DAN1 compression. Add the compressed data into your project and use the appropriate code to setup the video chip right and see the result on screen.

Thanks for reminding me to clean up my code for the final release. PP2PC is another tool I made to convert PowerPaint pictures into Dale Wick's ".pc" files. I simply copy-pasted part of its code to implement options (or flags) such as "-v" to verbose all steps, "-h" to show help and "-r" to allow RLE encoding as "there is a string of uncompressed data here better not to try to compress it wastes memory space". I will explain all about DAN1 options (flags) in my speech. The compression tool tries to explore all possibilities and pick up the best solution for this format and that's why it's slow. I guess a quick no so optimized result for development purpose should be an option for this tool, giving more an idea of the space needed and decoding speed while programming and testing projects. If the actual dan1 decompression routine is a bit slow for your taste, I'm sure someone will come up with a faster version the more this tool used. Side note : Try "dan1 -r filename" to allow RLE markers if you consider your data to be difficult to compress such as highly dithered pictures.

And that's part of my challenge right now as I write my speech for this week-end to make this new information somewhat clear, less abstract. Please ask your questions if any.

You probably know I like sharing my tools and games for decades, making them available freely, so what's the good licence terms for what I do believe is right? Is freeware good? or perhaps gpl? or is lgpl applicable? i don't know. But what I do know is I make it available and hope it helps retro gaming enthusiasts like you and me.

DAN1 Compression tool version Beta 20160710 seems stable and perform at a good speed. Decompression routine is a bit slow in its small version and that's expected ( size vs speed dilema ). Overall results surpass or equal the majority of available data compression for 8bit systems. Mission Accomplished. I do a speech during ADAMCon July 15-17, 2016, Guelph, Ontario, Canada. Any questions? remark? comment?

Try compiling the JAVA source code included. Please note : This is a very simple program, no GUI with a file browser. You can drag and drop the .pc file on the executable or make your PC associate the .pc file extension to this program to open the pictures automatically when you double-click them. Enjoy!

Dale Wick's bitmap pictures also known as .pc files are the PATTERN (6KB) and COLOR (6KB) data to be loaded in VRAM on any machine using TMS9918/28 video chip to display a fullscreen bitmap picture. Because of its simplicity, this format was adopted in the AtariMax Ultimate SD ColecoVision Multicart product and used to show a screenshot preview of games or to simply display nice various fullscreen pictures such as pixelart. And here is a very simple program I wrote in Java to open .pc files on your PC computer. Download (Java, Jar, Exe) : ColecoPictureViewer.zip Some pictures in PC format : SomePCPictures.zip

Here's my version of the slide show, in ZX7 , DAN1 and a variant DAN1C. An extra bitmap picture can certainly be added in the project within the limit of 32K. Download the complete folder including compiled and source codes for all these slideshows : SLIDESHOW.zip

I have checked your listing again and I have noticed that you forgot to disable NMI during decompression. This leads to glitches, artefacts in the picture, and do answer your post on another forum about glitches you see.

This thread is about DAN1 data compression. I would love to get feedback before and after the final release. Name : DAN1 Author : Daniel Bienvenu aka NewColeco Start Year : 2014 End Year : 2016 Description : LZSS variant data compression format using Elias gamma length values, four fixed offset sizes, and raw parts (literal as is, see RLE). Objective : Great compression ratio no extra memory needed during decompression. Can be used on vintage 8-bit systems. Details : DAN1 is a format based on LZSS (a variant of LZ77) which attempts compression by finding matches from already seen data. These matches are encoded as a pair of values : size and relative offset. Size is encoded by using Elias gamma, Offset is encoded in 1,4,8 or 12 bits depending on its value. When no match is found for some particular data, it is stored raw, literals. Bits are used as markers in DAN1 format to identify between literals and matches, and between the different sizes of offsets. The first byte is literal by default since no already seen data exists, no need for a marker. An end marker is used to tell the decompressor to stop regardless if there are even more data in the stream or in memory. A special marker is used to tell the decompressor to copy as-is a sequence of bytes all at once. Since the offset sizes are hard coded and no dynamic tables such as adaptive Huffman are used in this format, no extra memory is needed to decompress the data. Data format (short text version) : The first byte is literal The following bytes are bits indicating what is next, reading from the highest bit first. If it's a bit set to 1, the next byte is literal If it's a bit reset to 0, the next bits (and byte) are values for size and relative offset. The size is encoded using Elias gamma format : 1 = 1, 010 = 2, 011 = 3, 00100 = 4, 00101 = 5, 00110 = 6, 00111 = 7, etc. The offset is encoded first with bits marker telling which format size (1, 4, 8 or 12 bits) is the encoded offset then the value itself. RLE marker is a sequence of 17 bits reset to 0 followed by 1 bit set to 1, the number of literals to copy is 27 more than the value of the following byte. END marker is a sequence of 18 bits reset to 0. Offset encoding details : The offset is relative to where to write upcoming data; if the offset value is zero then what we have to write next is what we just wrote as the last byte. Because the size value can be one, meaning a match of a single byte found near, the encoded offset should not be encoded too big in order to save bits, denying relative offset value to be in 8 or 12 bits. For a match of only 2 bytes, a relative offset value in 12 bits doesn't provide any real saving. So here's a table explaining the way offsets are written in DAN1. If the size value is 1, marker bit 0 means the offset is encoded in one bit, marker bit 1 means the offset value (minus 2) is encoded in 4 bits. 0 0 = offset of zero (last byte we just wrote), 0 1 (before the last byte we just wrote), 1 0000 ("before before" the last byte we just wrote), 1 0001, ..., 1 1111. If the size value is 2, marker bit 1 means the offset value (minus 18) is encoded in a byte (8 bits), marker bits 01 means the offset value (minus 2) is encoded in 4 bits, and marker bits 00 means the offset value is encoded in 1 bit. If the size value is greater than 2, marker bit 1 means the offset value (minus 274) is encoded in 4 bits and a byte (12 bits), marker bits 01 means the offset value (minus 18) is encoded in a byte (8 bits), marker bits 001 means the offset value (minus 2) is encoded in 4 bits, marker 000 means the offset value is encoded in 1 bit. Download : DAN1 (EXE, SRC, ASM) Beta version 20160715 : dan1-beta-20160715.zip Older versions : DAN1 (EXE file) Beta version 20160712 : dan1-beta-20160712.zip DAN1 (EXE file) Beta version 20160710 (all-in-one tool) : dan1-beta-20160710.zip DAN1 (EXE file) Beta version 20160704 (compression tool only) : dan1-beta-20160704.zip DAN1 (EXE files) Alpha version 20160618 (limited to file size up to 512K) : dan1-alpha-20160618.zip DAN1 (EXE files) Alpha version 20160604 (limited to file size up to 256K) : dan1.zip Usage : Compression (beta version) command-line :> dan1.exe [options] filename options include : -r to activate rle encoding, -v to verbose, -y to automaticaly say yes to overwrite, -o to specify an output filename Compression (alpha version) command-line :> dan1.exe filename Decompression command-line :> ddan1.exe filename Z80 Assembly Code to decompress in VRAM (ColecoVision version) * 20160715 - fixed RLE bug and optimized for size * ; DAN1 + RLE to VRAM ; 2016 Daniel Bienvenu, Canada ; HL = Source ; DE = Destination (in VRAM) dan1rvram: ; Set Write in VRAM at DE ld c, $BF out (c), e set 6, d out (c), d res 6, d ; Init. Read bits ld a, $80 ; Copy literal byte dan1r_copy_byte: ld b, $01 jr dan1r_literals2main dan1r_special: pop de call getbit ret nc ; EXIT ld b, (hl) ; Load counter value as a byte inc hl inc b call dan1r_literals ld b, $1A dan1r_literals2main: call dan1r_literals ; Main loop dan1r_main_loop: call getbit ; Check next bit jr c,dan1r_copy_byte ; Elias gamma decoding + Special marker push de ld de, $0001 ld b,d dan1r_eliasgamma_0: inc b call getbit ; Check next bit jr c, dan1r_eliasgamma_value bit 4,b jr nz, dan1r_special ; Special marker "0000000000000000" jr dan1r_eliasgamma_0 dan1r_eliasgamma_value_loop: call getbite ; Load next bit into DE rl d dan1r_eliasgamma_value: djnz dan1r_eliasgamma_value_loop push de pop bc ; BC = LENGTH ; Get Offset value ld d, $00 ; Reset Offset to $0000 ; ON LEN GOTO TWO_OFFSETS, THREE_OFFSETS ; GOTO FOUR_OFFSETS ex af,af' ld a,b or a jr z, dan1r_bzero ld a, $03 dan1r_bzero: or c ld e, a ex af, af' dec e jr z, dan1r_offset2 dec e jr z, dan1r_offset3 ld e, d dan1r_offset4: call getbit ; Check next bit jr nc, dan1r_offset3 call getnibblee ; Get next nibble -> E inc e ld d,e ; D = E + 1 jr dan1r_offset3a dan1r_offset3: call getbit ; Check next bit jr nc, dan1r_offset2 dan1r_offset3a: ld e, (hl) ; Load offset as a byte (8 bits) -> E inc hl ex af, af' ld a,e add a, $12 ld e,a jr nc, dan1r_offset3b inc d dan1r_offset3b: ex af,af' jr dan1r_copy_from_offset dan1r_offset2: call getbit ; Check next bit jr nc, dan1r_offset1 call getnibblee ; Get next nibble -> E inc e inc e jr dan1r_copy_from_offset dan1r_offset1: call getbit ; Load next bit -> E rl e ; Copy previously seen bytes dan1r_copy_from_offset: ex (sp), hl ; Store source, Restore destination push hl ; Store destination scf sbc hl, de ; HL = source = destination - offset - 1 pop de ; DE = destination ; BC = count ; COPY BYTES ex af,af' set 6,d dan1r_copybytes_loop: push bc ld c, $BF out (c), l nop out (c), h inc hl nop nop in a, ($BE) nop nop nop out (c), e nop out (c), d inc de nop nop out ($BE), a pop bc dec bc ld a,b or c jr nz, dan1r_copybytes_loop res 6,d ex af,af' pop hl ; Restore source address jp dan1r_main_loop dan1r_literals: ld c, $BE dan1r_literals_loop: outi inc de jr nz, dan1r_literals_loop ret getnibblee: call getbite ; Load next bit -> E call getbite ; Load next bit -> E call getbite ; Load next bit -> E getbite: call getbit ; Load next bit -> E rl e ret getbit: add a, a ret nz ld a, (hl) inc hl rla ret Example : Here is a file encoded in DAN1 format ( in hex values ) : 71 00 00 FF FF 00 00 0F FF F0 00 00 FF FF 02 00 00 00 Input : 71 00 00 FF FF 00 00 0F FF F0 00 00 FF FF 02 00 00 00 Input size : 18 bytes Decode : 71 < size = 65535 , offset in a bit = 0 > < size = 65535 , offset in a bit = 0 > < size = 65535 , offset in a bit = 0 > < size = 2 , offset in a bit = 0> < END marker > Output : 71 71 71 71 71 71 ... 71 Output size : 196608 bytes Details : 196608 times the letter 'q' (see test2.bin file in Exomizer ZIP archive)

Got it! Thanks

I kept my focus on not spending more memory space and I'm quite confident about its efficiency. Expect a first BETA version in a few days.

Please tell me more about how to make things less tedious. And I would love to learn about your music format. Send me a message about it.

Deleted 15 old messages in my AtariAge mailbox. You can send me messages.

Worked on DAN1 compression tool again today [stop] Patched memory leak found after testing DAN1 with test1.bin, test2.bin and test3.bin files from the Exomizer archive [stop] Improved compression speed for special case TEST2.BIN [stop] Quite pleased with the results Table 6 - TEST1.BIN (Sound Sample .WAV) Source : 202762 bytes Exomizer : 202601 bytes DAN1 : 204280* bytes ZX7 : 225280 bytes Tabe 7 - TEST2.BIN (String made of letter 'q') Source : 196608 bytes Exomizer : 39 bytes DAN1 : 18* bytes ZX7 : 19 bytes Table 8 - TEST3.BIN (Documentation text file) Source : 111261 bytes Exomizer : 34219 bytes DAN1 : 48103* bytes ZX7 : 52035 bytes * Still work-in-progress, may change. Checked manually TEST2.BIN result to be correct according to DAN1 format [stop] Need to work on decompression tool.

True. My goal is to reach great compression results for data used in ColecoVision projects and most of it is whatever goes to VRAM. However, DAN1 is all-purpose compression if you know what you are doing with it. My favorite 8-bit console named ColecoVision has 1K of RAM and 16K of VRAM and my objective is to push the limits of what I can fit in the 32K ROM cartridge to exploit this beautiful vintage game system without the need of RAM space for decompression. This is the challenge I've accepted to make ColecoVision homebrew games, to do great with the capacities of the console. Data compression is part of my Coleco tools since the beginning in 1999 and it is a great deal to achieve my goal and I'm happy to sacrifice some years in my life and some CPU time to achieve it. Like in ZX7 and Exomizer, all literals in DAN1 are stored raw to speed things up, but Huffman encoding can be applied in some circumstances (see DEFLATE). I plan to use my fixed Huffman encoding from DAN0 to exploit this potential of extra bytes saving in the future without again using extra RAM space. As to be all-purpose or not, it is true that my main focus is what I need in VRAM for my projects and I based my decisions on this fact because it's important for me. However, the format itself is not specific for one kind of compression since it's a variant of LZSS. Table 5 - Apply DAN1 on a small 24K ZIP file Original ZIP file made of 12K bitmap samples. Size = 24583 bytes DAN1 compression of the ZIP file. Size = 24543* bytes ZX7 compression of the ZIP file. Size = 26815 bytes ZIP file of the ZIP file. Size = 24527 bytes Packed data only from the ZIP of the ZIP file. Size = 24288 bytes DAN1 isn't as strong as DEFLATE (probably due to the lack of Huffman encoding), but it can be used for all-purpose if you know what you do. The difference between DAN1 and ZX7 results here is partly due to the implementation of RLE sequences which is about 10 lines of ASM codes in the decompression routine. I've coded a simple CLI (command-line) to compress in DAN1 format. It handles files up to 64K. I use it for data up to 16K since my focus is what goes in VRAM. I'm sure a clever programmer can make a tool supporting input stream without a size limit. Again, I'm taking this project seriously. DAN1 is a work in progress format and I'm not ready to release it yet.

I've looked at your ROM file very quickly and here is what I saw Inside dzx7.rom 960A: CD 57 96 CALL Something : .. .. .. <- Missing LD HL, SOURCE ADDR IN ROM : .. <- Missing PUSH HL 960D: 21 00 00 LD HL, $0000 = DESTINATION IN VRAM 9610: E5 PUSH HL 9611: 21 2C 80 LD HL, $802C = ? is it the data source ? 9614: CD 53 97 CALL DZX7 DZX7: C1 POP BC : D1 POP DE <- Destination Addr. $0000 = GOOD : E1 POP HL <- Source Addr. $0000 = BAD, Invalid since source address was never pushed? : E5 PUSH HL : D5 PUSH DE : C5 PUSH BC If you want to keep the way you call the dzx7 function by not pushing the source address but instead having it already in the HL register pair, remove the unnecessary POP HL and PUSH HL opcodes from the DZX7 routine and it should work. Give it a try and have fun!

Indeed, ZX7 is a tradeoff between compression ratio and decompression speed and size because it's based on reading bytes most of the time instead of individual bits. It looks like there was a misunderstanding from my part regarding your proof of concept not providing optimal results. When I tried to repeat the experience by rewriting in Java the ZX7 data compression written in C, my results were differents than with the optimal algorithm. Clearly, I made a mistake. One paper compared Elias gamma with Elias gamma on delta and so on and the conclusion is that Elias gamma with lazy LZSS gives best results; this paper confused me at first about the "lazy" LZSS, but I decided to not investigate further... maybe I should. Journey to DAN1 format My goal is to make graphics fit in my ColecoVision projects and the biggest graphics are bitmap screens made of two 6K tables for patterns and colors for a total of 12K, charsets are also quite big and can certainly benefit from good compression. In LZSS compression, offset values are usually the biggest part of the data and just by changing to more suitable sizes for offsets it gets to a better compression at the cost of speed. For example, all Graphic Mode II bitmap screens I've tested, going from a simple logo to pixel art (ZX7, MSX1) to heavily dithered pictures do fit into these two categories : simple and elaborated; 4 bits and 9 bits offsets are best for simple bitmaps (simple logo) and 4 bits and 11 or 12 bits for elaborated bitmaps (vast majority of ColecoVision Bitmap title screens). Since the biggest challenge for my CV projects is to make the graphics fit, I had fun adapting ZX7 to uses these 4,9 and 4,11 offsets to get better compression but still couldn't get close to Exomizer results. I also started to write a paper in PDF about these results, even wrote a presentation last year for the ADAMCon, but I decided to keep going in my R&D before fixing my new format. This year, I've made the discovery of 4 fixed sizes for offset values is the best fit overall (for graphics and text compression), providing compression results closer to Exomizer without the need for extra memory. And since the waiting time before seeing a cool title screen doesn't really matter, I decided to adopt the 4 sizes to encode the offsets. Table 1 - Size of compressed data on a 12K bitmap sample obtained by using one, two, three, four, five or six sizes to encode the offset values. ONE : 11 bits = 2961 ZX7 : 7 and 11 bits = 2901 TWO : 8 and 11 bits = 2841 THREE : 4,8 and 11 bits = 2814 FOUR : 1,4,8 and 11 bits = 2798 FIVE : 1,3,5,8 and 11 bits = 2804 SIX : 1,2,3,5,8 and 11 bits = 2823 Based on these results, no more than 4 different sizes for offset values is best. According to a paper about variants of gamma encoding in LZSS optimization, as mentionned earlier, normal Elias gamma with lazy LZSS is best. But since I don't fully understand what this paper means by "lazy" I just go with what I know. I started to encode my new format DAN1 using LZSS variant with Elias gamma and 4 different sizes to encode offset values. Because I knew some people would want to use this format and not just on simple title bitmap screens, DAN1 also avoid adding constantly bits for each literal byte in a long sequence of bytes (see RLE compression). Table 2 - Size of different routines to decompress to VRAM used in various ColecoVision projects : RLE = 43 DAN0 = 97 ( RLE with literals encoded into a fixed Huffman ) ZX7 = 131 ( LZSS with 7 and 11 bits for Offsets ) DAN1 = 220* ( LZSS with 1, 4, 8 and 12 bits for Offsets and RLE for uncompressed literals ) PLETTER = 222 Table 3 - Size of compressed data of a 12K Bitmap sample RLE = 4528 DAN0 = 4143 ZX7 = 3551 DAN1 = 3419* PLETTER = 3557 Table 4 - Size of both decompression routine and compressed data RLE = 4571 DAN0 = 4240 ZX7 = 3682 DAN1 = 3639* PLETTER = 3779 DAN1 results are marked with * because it's still in development, not yet used in a ColecoVision project. I finish my tests and then present my results during ADAMCon 2016, July 14-18.

I don't know much about the MSX BIOS routines -AND- the ZX7 to RAM routine is pretty much using all register pairs, the accumulator, and flags for various tasks, that's why I can only say "Maybe". I've made my own version ZX7 decompression directly into VRAM (see an earlier post for its source code).

After 2 years studying data compression and testing various ways to achieve it, I've tried to make my own new format named "DAN1". This new format has "no extra memory usage" and "reasonable decompression speed" for 8bit systems. The following table compares data size after various compressions of a 12K sample Graphic Mode II screen. Exomizer v2 : 3337 DAN2 -m 11 : 3416 DAN1 : 3419 MegaLZ : 3524 aPLib : 3543 ZX7 : 3551 Pletter : 3557 BitBuster : 3595 PkK's RLE+Huffman : 3867 PuCrunch : 4000 DAN0 : 4143 Marcel DeKogel's RLE : 4528 In its core, DAN1 is a LZSS variant using 4 different fixed sizes for the offset values in pairs < length , offset >; in comparaison, ZX7 uses only 2 fixed sizes,and Exomizer has variable sizes for the offset depending on its rarety more than its value.

Yes, my zx7 routine here in assembly codes decompress any zx7 data directly to VRAM for a ColecoVision or Coleco ADAM project as long as it fits inside the video memory space without the need of CPU memory buffer space. Try contacting Dale Wick directly (his email on adamcon.org website) about the svn server.

Yes, it is on Dale Wick's SVN server since 2014, where pretty much all my dev are saved since I lost most of my source codes due to PC crashes and HDD failures. Not all my projects are there. My routine is adapted from Metalbrain's small version, modified to decompress into VRAM directly and to be compiled in SDCC as part of the "comp.lib". Used with success already in 2014 in one of my ColecoVision projects. Here's the source codes ; zx7.s ; Decompression in VRAM version by Daniel Bienvenu .module zx7 ; global from this code ;================ .globl _zx7 ; void zx7 (void *data, unsigned vram_offset); .globl zx7 ; HL = ADDR. TO COMPRESSED DATA , DE = DESTINATION IN VRAM .area _CODE _zx7: pop bc pop de pop hl push hl push de push bc zx7: ; Set Write in VRAM at DE ld a,e out (0xbf),a ld a,d or #0x40 out (0xbf),a ld a,#0x80 ; copy literal byte zx7_copy_byte_loop: ld c,#0xbe outi inc de zx7_main_loop: call getbit ; check next bit jr nc,zx7_copy_byte_loop ; determine number of bits used for length (Elias gamma coding) push de ld bc, #1 ld d, b zx7_len_size_loop: inc d call getbit ; check next bit jr nc, zx7_len_size_loop jp zx7_len_value_start zx7_len_value_loop: call getbit ; check next bit rl c rl b jr c, zx7_exit ; check end marker zx7_len_value_start: dec d jr nz, zx7_len_value_loop inc bc ; adjust length ; determine offset ld e, (hl) ; load offset flag (1 bit) + offset value (7 bits) inc hl .db #0xcb, #0x33 ; opcode for undocumented instruction "SLL E" aka "SLS E" jr nc, zx7_offset_end ; if offset flag is set, load 4 extra bits call getbit ; check next bit rl d ; insert first bit into D call getbit ; check next bit rl d ; insert second bit into D call getbit ; check next bit rl d ; insert third bit into D call getbit ; check next bit ccf jr c, zx7_offset_end inc d ; equivalent to adding 128??? to DE ??? NO! zx7_offset_end: rr e ; insert inverted fourth bit into E ; copy previous sequence ex (sp), hl ; store source, restore destination push hl ; store destination sbc hl, de ; HL = source = destination - offset - 1 pop de ; DE = destination ; BC = count ; COPY BYTES ex af,af' set 6,d zx7_copybytes_loop: push bc ld c,#0xbf out (c),l nop out (c),h inc hl in a,(0xbe) nop out (c),e nop out (c),d inc de out (0xbe),a pop bc dec bc ld a,b or c jr nz,zx7_copybytes_loop res 6,d ex af,af' zx7_exit: pop hl ; restore source address (compressed data) jp nc, zx7_main_loop ret getbit: add a,a ret nz ld a,(hl) inc hl rla ret The entry point _zx7 with all the pop push is to allow zx7 to be called from codes written in C program. Here is the simple zx7 header file. // zx7.h void zx7 (unsigned vram_offset, void *data); Side note : The ZX7 compression tool written by the original author do a quick look and compress data based on the ZX7 specifications which I can explain if someone asks for it. However, this tool was written as a proof of concept but NOT as the best compression tool possible for this format to achieve even better compression results than what people are getting now. This situation is easy to understand if we compare with modern ZIP tools which are not optimized for the best compression possible at a cost of taking hours for it but good enough for a nice user experience achievable in seconds or very few minutes. In fact, after studying a lot about compression during my quest of making my own new compression format, reading various scientific papers on the subject and also watching the amusing video series by Google titled Compressor Head, I'm happy to say that after all the headaches, I was able to make my own compression tool based on ZX7 specifications and get the best results out of it. Starting from there, I was able to develop my own format and compare fairly with ZX7 format; the results show better compression results overall at a cost of a slower decompression runtime but still no need for extra RAM space like Exomizer.

In 2014, I added ZX7 format into my Coleco devkit, in the compression library; decompression directly into Video RAM to avoid messing up with the 1KB RAM space of the ColecoVision. I don't know if that answers your question about ZX7 depacker.