[CSDb] - User Forums - Cruncher Plugins + Exomizer + Krill's Loader

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Cruncher Plugins + Exomizer + Krill's Loader

2025-03-20 13:57

Sabbi

Registered: Jan 2002
Posts: 13

Cruncher Plugins + Exomizer + Krill's Loader

Hi Guys,

Currently pulling my hair with Kick Assembler Cruncher Plugins & Exomizer....

My goal is easy(?) - crunching "a.prg" ($9d00-$cfff) with Exomizer & loadcmp it with Krill's Loader.

If I compress with Exomizer manually (exomizer.exe mem -f -o compressed.prg a.prg), everything works fine, loads and decompresses without any issues.

Now I just try to do the same inside Kick Assembler with the Cruncher Plugins:
---------------------------------------
.plugin "se.booze.kickass.CruncherPlugins"

.disk [filename="lazy.d64", name="A", id="1"]
{
[name="TEST", type="prg", segments="Main", modify="B2exe", _jmpAdress=start],
[name="CP", type="prg", segments="CompressTest"],
}

.var a = LoadBinary("a.prg", BF_C64FILE)

.segment CompressTest [start = $9d00] // ???
.modify MemExomizer(true,false)
{
.pc = $9d00 // ??
.fill a.getSize(), a.get(i)
// .import c64 "a.prg"
}
---------------------------------------

A compressed file gets generated and stored to the d64, but it's not loadable/decompressable.

I've tried all possible combinations (MemExomizer, BackwardMemExomizer, ForwardMemExomizer, true/false, direct in .disk ([name="CP", type="prg", prgFiles= "a.prg", modify="ForwardMemExomizer"]).

Can't seem to find the right settings for start or PC, the generated file has a loading address of $9d00, instead of somewhere around $c600 which has the file created with Exomizer directly.

What am I missing? If it's even possible, there has to be a simple fix for this :) Any help is much appreciated!

Thanks!

... 10 posts hidden. Click here to view all posts....

2025-03-23 13:20

Slammer

Registered: Feb 2004
Posts: 425

Are you sure that there should be a load address? If Krill loader decrunches on the fly I just see a need for an address for the unpacked code. (Nb you haven't included a decruncher, so you can't see where the code ends up)

2025-03-23 13:33

Sabbi

Registered: Jan 2002
Posts: 13

Correct me if I'm wrong - but files are always loaded to the loadaddress (no matter compressed or not). So $0002 just can't work.

Also, exomizing the file manually puts it to $C6B5:

 
> exomizer.exe mem -f -o compressed.prg test.prg

Reading ".\test.prg", loading from $9D00 to $D000.
Crunched data reduced 10677 bytes (81.78%)
Writing ".\compressed.prg" as prg, saving from $C6B5 to $D002.

2025-03-23 14:05

Krill

Registered: Apr 2002
Posts: 3046

Quoting Slammer

When I read Ruk's documentation Exomizer3 is not the default setting (Krill, Do you expect V3 these days?)

Yes, i tend to update the crunchers and their respective decrunch routines as soon as i notice updates. (And yes, next version will come with current Dali/ZX0.)

Quoting Sabbi

Correct me if I'm wrong - but files are always loaded to the loadaddress (no matter compressed or not). So $0002 just can't work.

Correct. The crunched file's load address is somewhere in the memory range of its uncompressed counterpart, such that their tail ends are at (approximately*) the same address in order to facilitate in-place decrunching without any extra buffers during loading.

So yes, a load address of $0002 is wrong.

Quoting Sabbi

> exomizer.exe mem -f -o compressed.prg test.prg Reading ".\test.prg", loading from $9D00 to $D000. Crunched data reduced 10677 bytes (81.78%) Writing ".\compressed.prg" as prg, saving from $C6B5 to $D002.

The compressed file ending beyond $D000 will be a problem, however, as it would load to IO registers (crunched files go to C-64 RAM in their crunched state first, and decrunching happens with lower priority between new blocks of crunched data rolling in with higher priority).

* Some crunchers like Dali/ZX0, tinycrunch or TSCrunch have full in-place decrunch capability, such that this file would end at $D000 also in crunched state.

2025-03-23 15:36

Slammer

Registered: Feb 2004
Posts: 425

Ok. I don't know how the exo segment modifier sets the startbytes, but you can throw away the address of the returned memoryblock and set your own by going through another segment:

	.disk [filename="lazy.d64", name="A", id="1"]
	{
		[name="EXOMIZER", type="prg", segments="ExoFile"]
	}

	.segment ExoFile [start = $5000]
	    .segmentout [prgFiles="a.prg", modify="MemExomizer", _forwardCrunching]

Since the sid-example worked the only thing wrong can be the load bytes. You can try if that works if Ruk doesn't show up and show us how its done.

2025-03-26 08:13

Sabbi

Registered: Jan 2002
Posts: 13

Quote:

Since the sid-example worked the only thing wrong can be the load bytes.

Think so too, the problem is that this file would have like a "dynamic" load address depending on crunched size (f.ex uncrunched $2000 - $8000 = crunched $6543 - $8000)

I created a separate script to create the packed files now, also does its job.

2025-03-26 09:40

Slammer

Registered: Feb 2004
Posts: 425

Yaeh i understand you, Whatver get the job solved is a good solution. I peaked in Ruks repo and think he has some code that takes care of it, but perhaps it isn't switched on for the exo-segment modifier.

However, just to show how crunching+diskcreation while assembling works, here is an example from the plugin I made when doing the disk stuff. Its a disk-plugin, that creates disks for the booze loader. I removed some trivial non-loader lines but this is all it takes to use the loader. The macros (LoaderLoadCode and LoaderInstallCode) is in the plugin, so you don't have to worry about that.

It creates a little musicloader that in turn loads an plays two pieces of music which are byteboozed and put on the disk.

    .plugin "kickass.bdloader.BdLoader"

    //------------------------------------------------------------------------
    .disk BoozeDisk [filename="myDisk.d64", name="TESTDISK", id ="2021!", diskno=3] {
        [name=">>MUSICLOADER!<<", type="prg", segments="DRIVER"],
        [name="----------------", type="rel"],
        [name="MUSIC 1         ", type="b2l", prgFiles="data/Angular.prg"],
        [name="MUSIC 2         ", type="b2l", prgFiles="data/OddFellow.prg"]
    }
    //------------------------------------------------------------------------
    .segment DRIVER []
    BasicUpstart2(start)

            // Install loader in the drive
    start:  jsr install
			
            .. some init..
			
            // Init disk
            lda #$83  // Disk 3
            jsr load
						
            // Load music		
    loop1:  lda #0
            sta $d418			

    mNo:    lda #0 		// File index	
            and #$01
            inc mNo+1		
            jsr load

            // Init and play music

            ... some play code
            jmp loop1

            *=$0a00
    load:   LoaderLoadCode()		// Macro for importing the loader code
	    *=$2000
    install: LoaderInstallCode()     // Macro for importing the installer code

2025-03-26 11:51

Krill

Registered: Apr 2002
Posts: 3046

Quoting Slammer

[name="MUSIC 1 ", type="b2l", prgFiles="data/Angular.prg"], [name="MUSIC 2 ", type="b2l", prgFiles="data/OddFellow.prg"]

There should be a similar type as "b2l" to create exo-crunched "level" files with arbitrary load addresses, like maybe "exl", no?

Otherwise, this roundabout way of creating a memory segment (with a fixed address) to dump a file into only to dump that segment to a file again (and only there)
Quoting Slammer

.segment ExoFile [start = $5000] .segmentout [prgFiles="a.prg", modify="MemExomizer", _forwardCrunching]

appears rather problematic indeed. =)

2025-03-26 16:31

Slammer

Registered: Feb 2004
Posts: 425

Yes, Using oneliners is recommended. The intermediate segment is a away to: 1. Test if we where right about a correct startaddress would fix things, 2. make a quick and dirty solution now until we know the thoughts of Ruk, or if he is unavailable then I would consider making a general 'reallocate' parameter on segments to make it work. That would be something like:

    .disk [filename="lazy.d64", name="A", id="1"]
    {
        [name="EXOMIZER", type="prg", prgFiles="a.prg", modify="ForwardExomizer", realloc=$3000]
    }

Having a dedicated file type, as you suggest, is a good idea, since it saves even more writing:

    .disk ExoDisk [filename="lazy.d64", name="A", id="1"]
    {
       [name="EXOMIZER", type="exl", prgFiles="a.prg"]
    }

Sabby/others?: Did you try contacting Ruk? (There might be a simple solution.)

2025-03-26 17:08

Krill

Registered: Apr 2002
Posts: 3046

Yes, but the point is to avoid assigning some static start address altogether.
It entirely depends on the nature of the compressed file, and may change any time.

2025-03-26 17:20

Slammer

Registered: Feb 2004
Posts: 425

Quote: Yes, but the point is to avoid assigning some static start address altogether.
It entirely depends on the nature of the compressed file, and may change any time.

Ok, Then realloc is not good..

Previous - 1 | 2 - Next

Refresh

Subscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search for in
All times are CET.

Search CSDb

Advanced

Users Online

mutetus/Ald ^ Ons
t0m3000/hf^boom!^ibe..
Alakran_64
megasoftargentina
4gentE/ΤRIΛD
Durandal
Mr. Sex/Byterapers
Freeze/Blazon
DeeKay/Crest
REBEL 1/HF
Sokrates
rambo/Therapy/ Resou..
Guests online: 111

Top Demos

1 Next Level  (9.7)
2 Signal Carnival  (9.7)
3 13:37  (9.7)
4 Codeboys & Endians  (9.7)
5 Coma Light 13  (9.6)
6 Mojo  (9.6)
7 Edge of Disgrace  (9.6)
8 In Surgery  (9.6)
9 Uncensored  (9.6)
10 Comaland 100%  (9.6)

Top onefile Demos

1 Nine  (9.7)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.5)
6 Rainbow Connection  (9.5)
7 Dawnfall V1.1  (9.5)
8 Onscreen 5k  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 TRSAC, Gabber & Pebe..  (9.5)

Top Groups

1 Oxyron  (9.3)
2 Booze Design  (9.3)
3 Performers  (9.3)
4 Censor Design  (9.2)
5 Triad  (9.2)

Top Musicians

1 Conrad  (9.7)
2 Reyn Ouwehand  (9.7)
3 LMan  (9.7)
4 Stinsen  (9.7)
5 Rob Hubbard  (9.7)

Page generated in: 0.061 sec.