Some things I've been working on

[cosmicr]

I'd love to take advantage of the Kernal routines but unfortunately I'm using 4-bit mode (the original game was actually only 16 colours!).

It would be great also to use banked RAM but I want to stick the 512k RAM limit and most of the RAM is filled with game data (so much that there's no space left for audio).

Maybe I could combine using Banked RAM with using VRAM in 8-bit mode, but memory is definitely at a premium.

[ahenry3068]

I'd love to take advantage of the Kernal routines but unfortunately I'm using 4-bit mode (the original game was actually only 16 colours!).

It would be great also to use banked RAM but I want to stick the 512k RAM limit and most of the RAM is filled with game data (so much that there's no space left for audio).

Maybe I could combine using Banked RAM with using VRAM in 8-bit mode, but memory is definitely at a premium.

Ok cool. It is unfortunate that graph_draw_image won't work for 4 bit color mode. I didn't know what mode you were running in. Your little GIF brought back memory's I never had an Amiga but I did have the DOS version of "Out of this World". One of my favorites.

A couple other routines you might look at since Ram is so tight is memory_decompress. You can have data lzsa compressed in Ram and use memory_decompress to "unzip" it. It's a surprisingly fast routine. I'm actually experimenting on using it to unzip mono chrome bitmap frames (9600 bytes uncompressed). I'm compressing for speed and I'm getting an average of 4 jiffies per frame decompression speed.
.
If you have done an X16 kernel build you'll have the lzsa compression utility on your host system somewhere.

[ahenry3068]

memory_decompress IS NOT "Bank Aware" You can use it to and from Banked Ram but it won't wrap or automatically advance Banks like a "Bank Aware" routine would. But 8k buffers can still be quite useful. One thing it CAN NOT do is decompress across banks. source & target could both be in Banked Ram but they would have to both fit in a single 8k buffer. IT CAN decompress directly to VRAM without advancing the data register or the PCM_FIFO register.

[cosmicr]

Interestingly, the original game data is also compressed using an old Amiga format called "Bytekiller". I re-wrote the decompression routines but they are slow for various reasons (banked RAM being one of them). I'm using the banked ram like a giant "Heap" - which is kind of how the original game used memory. I have routines for reading or writing a byte using banked ram with a 20 bit address (ie the banked ram becomes one long continuous space).

For each game "level" it decompresses the data and loads it all into ram. The decompression is slow. Some is loaded on the fly (especially sounds). I wrote a utility to decompress all the data and save it into the game folder so that it would load faster. I'm not sure how fast the actual CX16 is (I'm using the emulator) but reading directly from disk is only a little slower than using banked ram - I wonder if I could take advantage of that...

[ahenry3068]

Not sure how fast your decompression routine is also my results are possibly skewed because I've mostly been using it with 1bpp bitmaps which are HIGHLY compressible. But I've been getting at least 75% file size reduction and average decompress time for a compressed buffer directly to VERA Ram. (9600 bytes uncompressed, compressed size variable) is about 4 jiffies.

The Emulator is very close to the hardware if your running on an sd-card image. If your running on HOSTFS then disc I/O is way faster than what you'll get in hardware but computation and other code is all still correct.

[ahenry3068]

I would dispense with what every your compression code is and use memory_decompress. It's free in the ROM.
Just have to use lzsa on the HOST system to do all your compression ahead of time. There's no COMPRESS on the X16 natively, just decompress.

Also as to your "Flat memory Pointer thingy" The ROM has routines like that also . FETCH and STASH which will get a byte from any Bank into .A. Act a lot like BASIC Poke & Peek.

[cosmicr]

Thanks for the tips - I've actually scoured the Kernal documentation for useful stuff already, I'm using the file loading routines and a few other methods. I'll consider how I might be able to use the compression but I don't see much benefit because it still needs to be decompressed and that's where memory space runs out. I'd also prefer the game to run stand alone without any pre-requirement - ie you just drop in the game files and play. Plus the bytekiller decompression is required to make the game work.

My Banked RAM methods actually work really well because I can replicate the original game engine's usage of memory. In addition, mine are actually faster than the Kernal methods FETCH and STASH, because you don't need any preparation first, you just pass in an address and it returns a byte - you don't have to think about which bank your data is in, or whether it overlaps onto the next bank. It's fast because I can take advantage of the 2k bank size with some clever bit manipulation (shift right 13 for bank, and mod/and for offset). The whole thing is done in less than 25 bytes of code.