| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
IRQ-loader toolchain for KickAss/Windows?
So, the one and only time I tried making an IRQ-loading demo I swore I would never, ever try that again.
Now I guess the memory has faded enough that I'm perhaps starting to reconsider! :)
Back then I used Dreamload and Exomizer, however putting it together was a complete pain in the ass.
I don't recall exactly what the trouble was, but I think it was the fact that the de-exomizer needed to point to the end of the packed data, which meant I had to compile the parts I wanted to load, exomize them, manually note the lengths, and then enter that length in another source where I had the general part-loader as indata to the deexomizer. Every little change meant redoing that procedure since the packed length always differed a bit.
Has anyone some more plug-and-play-ready solutions? I know there is lft's Spindle system, but that seems a bit too specific in the way you have to do things, and also kind of Linux-centric.
I would prefer working from Windows and using KickAssembler. |
|
| |
Jammer
Registered: Nov 2002
Posts: 1335 |
Bongo Linking Engine this? :)
Bitfire 0.3 or this? :) |
| |
Endurion
Registered: Mar 2007
Posts: 73 |
Usual plug: C64Studio lets you do pre and post build events (batch scripts) and has a function to get the size of a file (io.filesize)
Since KickAssembler just loves convoluted scripts there's surely a way to count bytes of a file? |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
Forward exomized files are possible these days, e.g. Krill's loader is doing that. Maybe check that one out?
It needs cc65/ca65 to build, but you only really need to do that once, then you can include the binary into your project. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Yes, in fact, i added forward compression/decompression to exomizer and its 6502 decompressors to make it fit the loading scheme and simplify the handling.
Unpacking an exomized file while loading is no more difficult than loading a plain unpacked file - the only difference is to call "loadcompd" instead of "loadraw" with my loader.
As Mr. SID said, you need to bother with other assemblers and their environments only once to compile loaders in general. You will get binaries (usually something like install.prg and loader.prg) and a symbols file which you can include with whatever assembler you please. |
| |
Trap
Registered: Jul 2010
Posts: 223 |
Shadow, when you figure out how to use Krill's loader with Windows/KickAss ... please share :) I failed miserably in every attempt. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Trap: Once you have install.prg, loader.prg and loadersymbols.inc, the rest should be a piece of cake. Include and incbin are your friends.
Getting those files built according to your specs might be a bit difficult at first (especially when you are on Windows only and have little experience with how *NIX-style open-source projects are typically built), but actually using the loader with whatever development environment should be quite straightforward.
You can reach me easily on IRCnet/#c-64, with CSDb PM and especially mail i might be slow to respond or forget to. |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
exactly what Krill said, his loader is gonna be your best bet, in speed only surpassed by bitfire which for a windows user is probably harder to master.
and #c-64 is your source of wisdom. on ircnet. |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
Quoting ShadowI don't recall exactly what the trouble was, but I think it was the fact that the de-exomizer needed to point to the end of the packed data, which meant I had to compile the parts I wanted to load, exomize them, manually note the lengths, and then enter that length in another source... This I really do not understand, because it's simply not true, you just exodecrunch combined with an (irq)loader and feed it a byte at request. Yes this will decrunch backwards by default. But first ask yourself if you really need the data while its loading... If you do, use forward decrunch.
these days tho, I would recommend doynamite/bitnax, size results are worse, but depacking time rules. especially in combination with a fast loader like krill's, this should deliver best results in load+decrunch time. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Burglarin speed only surpassed by bitfire I should really finish that new release, oh my... :)
But i believe that lft's Spindle system is faster as well, and i wouldn't be surprised if it'd best Bitfire in speed. Any stats? :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
That said, having the fastest loading speed is a bit overrated. The top average speeds are fairly close, and most productions don't really need the fastest one. Plus achieving them requires a fair bit of inside knowledge, and more often than not people pick the purportedly fastest loader and then do something wrong, ending up on some speed many other loaders can achieve as well. End of rant. :) |
... 62 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
