| |
Carrion
Registered: Feb 2009
Posts: 317 |
Exomizer problems on mac os?
Hi to all!
Do you guys encounter strange behaviour of exomizer on mac os (intel)?
I use this command:
./exomizer.exe sfx basic main.prg -s"lda #$01 sta $d021" -o test.prg
causes exomizer to stop with this message:
line 864, syntax error, unexpected STA
Parse failure.
this command:
./exomizer.exe sfx basic main.prg -x "lda #$01 sta $d021" -o test.prg
gives:
line 1290, syntax error, unexpected STA
Parse failure.
Both commands work OK on Windows.
Exomizer compiled on mac os without any warnings or errors. What do I do wrong? or is it mac os version issue?
TIA
[edit]
I get these messages with exo 3.0.2
3.1.1 stops as well but with:
line 1434, syntax error
Parse failure
[edit2]
It's the quotes.... XD
Thanks Trap! |
|
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
No problems here, and I use it extensively.
Try with -s '...' instead of -s "...", I get errors with " too. |
| |
Silver Dream !
Registered: Nov 2005
Posts: 108 |
silverdr$ exomizer sfx basic smpte.c64 -s"lda #$01 sta $d021" -o test.prg
Reading "smpte.c64", loading from $0801 to $095E.
Crunching from $0800 to $095E.
Phase 1: Instrumenting file
-----------------------------
Length of indata: 350 bytes.
[building.directed.acyclic.graph.building.directed.acyclic.graph.]
Instrumenting file, done.
Phase 2: Calculating encoding
-----------------------------
pass 1: optimizing ..
[finding.shortest.path.finding.shortest.path.finding.shortest.pat]
size 2325.0 bits ~291 bytes
pass 2: optimizing ..
[finding.shortest.path.finding.shortest.path.finding.shortest.pat]
size 2323.0 bits ~291 bytes
pass 3: optimizing ..
[finding.shortest.path.finding.shortest.path.finding.shortest.pat]
size 2322.0 bits ~291 bytes
pass 4: optimizing ..
Calculating encoding, done.
Phase 3: Generating output file
------------------------------
Enc: 0000000000000000,2133,0000002203040420,0010013440010031
Length of crunched data: 319 bytes.
Crunched data reduced 31 bytes (8.86%)
Literal sequences are not used, length 1 sequences are used,
length 123 mirrors are not used, max length used is 5 and
the safety offset is 3.
Target is self-decrunching C64 executable,
basic start ($0801-$095E).
line 866, syntax error, unexpected IF
Parse failure.
but when used with single quotes:
silverdr$ exomizer sfx basic smpte.c64 -s'lda #$01 sta $d021' -o test.prg
Reading "smpte.c64", loading from $0801 to $095E.
Crunching from $0800 to $095E.
Phase 1: Instrumenting file
-----------------------------
Length of indata: 350 bytes.
[building.directed.acyclic.graph.building.directed.acyclic.graph.]
Instrumenting file, done.
Phase 2: Calculating encoding
-----------------------------
pass 1: optimizing ..
[finding.shortest.path.finding.shortest.path.finding.shortest.pat]
size 2325.0 bits ~291 bytes
pass 2: optimizing ..
[finding.shortest.path.finding.shortest.path.finding.shortest.pat]
size 2323.0 bits ~291 bytes
pass 3: optimizing ..
[finding.shortest.path.finding.shortest.path.finding.shortest.pat]
size 2322.0 bits ~291 bytes
pass 4: optimizing ..
Calculating encoding, done.
Phase 3: Generating output file
------------------------------
Enc: 0000000000000000,2133,0000002203040420,0010013440010031
Length of crunched data: 319 bytes.
Crunched data reduced 31 bytes (8.86%)
Literal sequences are not used, length 1 sequences are used,
length 123 mirrors are not used, max length used is 5 and
the safety offset is 3.
Target is self-decrunching C64 executable,
basic start ($0801-$095E).
Writing "test.prg" as prg, saving from $0801 to $0A53.
Memory layout: |Start |End |
Crunched data | $07E7| $0925|
Decrunched data | $0800| $095E|
Decrunch table | $0334| $03D0|
Decruncher | $00FD| $01A2| and $9F,$A7,$9E,$AE,$AF
Decrunch effect writes to $DBE7.
Decruncher: |Enter |During|Exit |
RAM config | $37| $37| $37|
IRQ enabled | 1| 1| 1|
silverdr$
|
| |
Carrion
Registered: Feb 2009
Posts: 317 |
yeah.
thanks guys for reply.
Trap sugested mi quotes in an email and I edited the first post right away. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Problem solved, now for some off-topicness:
Why Exomizer in the first place? :)
One of my many pet peeves is needlessly slow decrunch, and Exomizer should only be used if you really need the size.
That basically only goes for cracks, where minimum size earns a flower pot.
(For 4K demos and the like, even slower crunchers exist, but for a good reason.)
There are many other crunchers for self-extracting executables with shorter load-to-run times, despite slightly higher block count. |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
What cruncher would be optimal (generally speaking) if total loading+decrunch time is the issue, and if a standard action replay cartridge is used to load the crunched program? |
| |
Silver Dream !
Registered: Nov 2005
Posts: 108 |
Well, size is the one thing you mentioned. In my case it's also stream decrunching that I use it for when needed.. Other than that - since I began to use DolphinDOS in 1986, I found the load 2s + decrunch 10+ seconds also pretty annoying when compared to load uncrunched in some 3-4s ;-) |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
It's standalone, supports all platforms, has all the options you'll ever need, and it just works out of the box.
Yes it's slow, but it's convenient and we're lazy. Feel free to release something that's even more convenient :) |
| |
Carrion
Registered: Feb 2009
Posts: 317 |
Quote: Problem solved, now for some off-topicness:
Why Exomizer in the first place? :)
One of my many pet peeves is needlessly slow decrunch, and Exomizer should only be used if you really need the size.
That basically only goes for cracks, where minimum size earns a flower pot.
(For 4K demos and the like, even slower crunchers exist, but for a good reason.)
There are many other crunchers for self-extracting executables with shorter load-to-run times, despite slightly higher block count.
@Krill
the size is key factor in my game. With my "coding skills" there was not much memory left. all three part (intro, main game, end) after unpacking the intro take 0801-ffff. levels inside the game are BB2 packed though. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting FranticWhat cruncher would be optimal (generally speaking) if total loading+decrunch time is the issue, and if a standard action replay cartridge is used to load the crunched program? Before settling on Exomizer for a given program, i'd recommend trying TinyCrunch V1.2 (extremely fast decrunch, but limited crunchiness) and https://github.com/bboxy/bitfire/tree/master/packer/zx0 (as crunchy as Exomizer on average, but a lot faster decrunch). |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Carrion@Krill
the size is key factor in my game. With my "coding skills" there was not much memory left. all three part (intro, main game, end) after unpacking the intro take 0801-ffff. levels inside the game are BB2 packed though. Ah, interesting! :)
Then you're always scratching the $0801-$d000 border even with Exomizer, i take it? (ZX0 might still be worth a try.)
When the game comes in three files (and 1541/71 compatibility is all you care for), perhaps try Transwarp on it. Gives you encryption of the end part for free, you only need to bury the key well. ;) (And of course this might delay the inevitable cracks by... anything within 5 to 50 hours? =D) |
... 17 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 - Next |
