| |
ChristopherJam
Registered: Aug 2004
Posts: 1408 |
Packer/decruncher for under IO?
So, what's the current rec for tools that let you load stuff that will crunch down to less than 51199 bytes, but decompresses to the entire area from from (ooh, for example) $0801 to $e1e0? I thought pucrunch took care of that, but either I'm mistaken or I don't know what flags to use.
(why yes, I do have an entry for Show Me Your (Vector) Balls that fits that criteria) |
|
... 15 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2970 |
I've been using $30 for years before realizing $34 has exactly the same results. Still keep using $30. I think $30 and $34 have the same level of usefulness, since they're equivalent. Also, what JackAsser said. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11364 |
i'll just quote it again because it cant be said often enough:
Quote:
Save and set $01 in the irq handler anyway, always unless you really need the cycles. One day 4h before deadline you'll get the brilliant idea to load the next part while you irq is running => boom!
Been there - done that! :)
Oh and for real safety push the values on stack instead of zp if you get the other brilliant idea to allow an irq happen inside the handler.
:) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
@krill: true, although if you are bank switching a lot $34 is helpful because it allows inc/dec to switch I/O on or off without mapping in ROM.
I rarely move out of the $33-$37 range myself. Well, except for tape bits. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1408 |
...so, now I've a one filer that doesn't crunch to less than 51199 bytes.
My disks used to be littered with frozen games this size long before I started cross developing, but my Action Replay was quite happy to load them for me. I can happily send them across to my real c64 even now using codenet.
But what's current best practice for loading them on a bare c64? VICE is understandably barfing. And is it considered bad form to release a single such .prg without placing it on a .d64 with a loader? |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1408 |
..and yes, @JackAsser, I currently have the brilliant idea to allow an irq to happen inside the handler :D |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
if you're picky the solution I see is an autostart loader, otherwise just leave a note it only works with AR, or a provided software speeder... |
| |
Bitbreaker
Registered: Oct 2002
Posts: 504 |
Quoting JackAsserSave and set $01 in the irq handler anyway, always unless you really need the cycles. One day 4h before deadline you'll get the brilliant idea to load the next part while you irq is running => boom!
Apparently there is another big mistake happening before that: A release is finished in time, and thus one never runs into that kind of trouble 8-)
@ChristopherJam:
Adding an autostarting loader would be best practice i'd say. When i was releasing Ächzzeit to be loaded with cart only, there was some decent whining going on :-) |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
At least it was decent. Nothing bugs me more than mediocre whining. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1408 |
Damn that mediocre whining ;)
OK, I'll patch in the Effluvium loader. It's not the fastest in the world, but it's easy to bash into shape, and it's one less tool to learn for now.
I really should play with Krill's at some point.. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1408 |
FWIW I ended up writing my own decruncher with byte aligned records for speed, and a simple decoder that fits easily into zero page. Not quite as high a compression ratio as pucrunch, but a better fit for purpose.
(I wanted the destination to be from $0200 to end of ram, but the data from around the $5000 mark on is pretty incompressible, so that had to be verbatim. All in all, time to roll my own) |
| Previous - 1 | 2 | 3 - Next |
