Using Exomizer

[AndyH]

I'm now looking to compress my game as a tape loader with Exomizer as a +35k expanded game.

I have this command line working so far with exomizer:

Code: Select all

exomizer sfx $1c00 maintape.prg 0400.prg -t55 -o tape.prg

maintape.prg starts at $1201 and 0400.prg starts at $0788 in my case, this covers +24K following $2000 and the extra bit in the +3K area at $0400.

I now have the last 8K block at $a000 to deal with. If I add this file to the command line I get an error:

Code: Select all

exomizer sfx $1c00 maintape.prg 0400.prg a000.prg -t55 -o tape.prg

Reading "maintape.prg", loading from $1201 to $8000.
Reading "0400.prg", loading from $0788 to $1000.
Reading "a000.prg", loading from $A000 to $BFFF.
Error:
The memory of the Vic20+3kB+32kB target ends at $8000 and can't hold the
uncrunched data that covers $0788 to $BFFF.

Does anyone know if there a work around for this in Exomizer? Or will I need to load in this last 8K block myself as uncompressed data?

[pixel]

Code: Select all

exomizer sfx $1c00 maintape.prg 0400.prg -t55 -o tape.prg

You need to decrunsh in two parts, e.g. by putting an exomized prg into another.

The first executable starts with BLK5 decompressed which you copy to its place. Then you relocate the other exomizer binary you appended and run that.

[AndyH]

I don't follow, do you mean I have to write some code to load in the compressed data that needs to go to $a000 at say $2000 and decompress to $a000, then load in my main compressed code at $788?

I am at a bit of a loss of how to do that.

[pixel]

*coffee*

You write a loader that's got the uncompressed BLK5 and an exomized binary with the rest in it. That thing you exomize too.
When it starts it copies BLK5 and relocates the exomized binary with the rest and launches that. You probably need to relocate the copy loop to relocate the latter. %p

[groepaz]

I'd rather use some simple RLE packer for the first block though (and perhaps tscrunch for the final step)

[AndyH]

Well the block of data at $a000 is compressed with rle as it happens. I'd not be shocked if exomizer can improve on it though.

I know how to write a bit of code to load in this data via the kernal.

Appologies Pixel, I'm struggling, where's that coffee?

So write some code containing the uncompressed 8k of data at $a000 that copies that to block 5...then exomize this. That part I get.

But that's just the first part... I also need to include the exomized main block of code and somehow unpack this after my a000 block has been reallocted? I'm using the sfx parameter to compress the main block of code, I'd guess I can't use that?

[AndyH]

This is how my memory usage looks uncompressed:

[tokra]

This is the way I did one-file my "Cheese and Onion"-cart back in 2017:

1. Crunch just $2000-$7fff version as sfx-archive
2. attach $a000-$bfff-file at the end of that file
3. change the BASIC-sys to a new routine at the end of the combined file
4. use small assembler-routine at that new address to copy contents back to $a000-$bfff and then JMP to the initial decruncher
5. Crunch again with exomizer as sfx-archive
6. Done

The same should apply to your game basically. Double-crunching might not be the most elegant, but at least a practical way. I should really get into tscrunch as well, this seems to be more practical for most scenarios (best trade-off between decrunch-time and size).

[pixel]

OK, here's the first part with BLK5 piggy-bagging another self-extracting PRG with the rest:

Code: Select all

prg_start   = $11ff                                                                                                                                                                                                                                                                                                                                                     
prg_sysaddr = $120d

    .zeropage

s:
sl: .res 1
sh: .res 1
d:
dl: .res 1
dh: .res 1
c:
cl: .res 1
ch: .res 1

    .code

main:   jmp start

blk5:   .incbin "blk5.bin"
blk5_end:
prg:    .incbin "prg.bin"
prg_end:

prg_size    = prg_end - prg
blk5_size   = blk5_end - blk5

.proc start
    ; Copy PRG to where it should be.
    lda #<prg
    sta sl
    lda #>prg
    sta sh
    lda #<prg_start
    sta dl
    lda #>prg_start
    sta dh
    lda #0
    sta cl
    ldx #1 + <prg_size
    lda #1 + >prg_size
    sta ch
    jsr copy

    ; Copy data to BLK5.
    lda #$00
    sta sl
    sta cl
    lda #$a0
    sta sh
    lda #<blk5
    sta dl
    lda #>blk5
    sta dh
    ldx #1 + <blk5_size
    lda #1 + >blk5_size
    sta ch
    jsr copy

    ; Start the PRG.
    jmp prg_sysaddr

copy:
    ldy #0
    beq n ; (jmp)
l:  lda (s),y
    sta (d),y
    iny
    beq +m
n:  dex
    bne l
    dec ch
    bne l
    rts
m:  inc sh
    inc dh
    bne n ; (jmp)
.endproc

Attached with Makefile in the ZIP:

32k-loader.zip

(1.48 KiB) Downloaded 12 times

[AndyH]

Thanks both, this really helps ... I think I get it now.

[beamrider]

Attached with Makefile in the ZIP: 32k-loader.zip

Assuming that all works since you've attached a make file. In Popeye I had an additional step of copying the bootstrap/relocate code to the cassette buffer as the first step and running everything from there otherwise it overwrote itself when relocating the main program down.

edit: I see you've put the bootstrapper at the end of the payload, so it won't get overwritten until the main compressed prg is expanded. Yes, I should have done that.

[AndyH]

Thanks a million for the help. Much appreciated, Tokra and Pixel you got me over the line. I went with Tokra's suggestion which is working as described.

1. Crunch just $2000-$7fff version as sfx-archive
2. attach $a000-$bfff-file at the end of that file
3. change the BASIC-sys to a new routine at the end of the combined file
4. use small assembler-routine at that new address to copy contents back to $a000-$bfff and then JMP to the initial decruncher
5. Crunch again with exomizer as sfx-archive
6. Done

[pixel]

You're welcome. We all ended up with about the same solution. Any turbo loading planned?

[AndyH]

I've run it through the fast load utility which brings it in to 24 on the vice tape counter. I need to test loading on a real Vic tape drive to be sure it's OK.