| |
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. |
|
... 62 posts hidden. Click here to view all posts....
|
| |
hollowman
Registered: Dec 2001
Posts: 474 |
Quoting Oswald/nitpick
on day one your loaders came in native c64 turbo ass src without cc1541 O:-)
/nitpick
Was there a day before plushdos? |
| |
soci
Registered: Sep 2003
Posts: 473 |
Quote: Quoting Oswaldyeah, i often feel that some guys overdo it, a very basic makefile or even a .bat should be enough, on todays pc's it creates a d64 in a few seconds all dependencies recompiled or not.
As well as hot glue and polyurethane foam do suffice when constructing things ...
I don't think so, you may as well need some duct tape and cable ties ;) |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting HCL128dcr still needs extra care, by adding that extra cycle in the transfer loop.. I haven't done extensive testing yet but temporarily switching in the 2 MHz mode during the IRQ transfers also seems to do the trick. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: Quoting Oswald/nitpick
on day one your loaders came in native c64 turbo ass src without cc1541 O:-)
/nitpick
Was there a day before plushdos?
/rambling
well, before that we were using a ripped smash loader. We had fun debugging the turn disk while linking void (each test cycle meant rewatching side 1 on real thing) until we found out I have optimised the side detect code away for gaining some bytes, not knowing what it is :)
and before that I had a megademo with a irqloader ripped from a sex slideshow, but unfortunately that got lost, as I made that before I "joined" the scene, and when I sold my c64 to get an amiga I gave the disk away. maybe a friend has it sitting on a disk somewhere. :)
/ |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
Quoting Oswaldyeah, i often feel that some guys overdo it, a very basic makefile or even a .bat should be enough, on todays pc's it creates a d64 in a few seconds all dependencies recompiled or not.
That's not my experience. Building u4remastered with the equivalent of a bat file takes 12.4 seconds, with an SSD and hot caches. A makefile with 8 parallel jobs brings it down to 5.3 seconds, but just rebuilding the IFFL loader and updating the disk images takes 2.9 seconds, with most time spent in exomizer. Rebuilding the EF version, which doesn't need exomizer, takes 0.7 seconds. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
depends on project and personal pereferences, if VBS works for demos for Pantaloon, then it should be alright I guess. More complex projects it wouldnt work like in your case.
last time I linked I used make, the experience still wasnt much less terrible when I linked on the real thing. seems you just cant escape a dozen of bugs which are a nightmare to find. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
Quoting Oswald
last time I linked I used make, the experience still wasnt much less terrible when I linked on the real thing.
I think linking on the real thing wasn't too bad back then. Everythng was done very well planned and done precicely to not loose too much time in packing. Parts were made in seuqential order and placed on the masterdisk when done. Nowadays everything gets linked first and no matter how flakey it is, and get improved, until things work out finally, as building and packing a whole disk image does not steal too much time in comparision. However many builds when being summed up still steal time, especially the packing and as the amount of builds explodes when going the new approach, and suddenly it is smart again to only recompile and pack that stuff that really changed. Thus: makefiles/build environment that is capable of dependencies. |
| |
Pantaloon
Registered: Aug 2003
Posts: 124 |
my system only relink what has changed. takes about 2 seconds with compile + disk build. parallelizing this wouldnt make it that much faster :) |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
Quoting Pantaloonmy system only relink what has changed. takes about 2 seconds with compile + disk build. parallelizing this wouldnt make it that much faster :) yay, buildsystem pissing contest \o/
I piss this far:
build includes: compiling, png to koala, compiling cc1541 fork, converting json level data to prg, exomizes everything, iffl-links and creates the d64.
build single threaded: 19.25 sec
build parallel: 6 sec
rebuild time depends on what changed of course. and yes, it's just a Makefile |
| |
chatGPZ
Registered: Dec 2001
Posts: 11110 |
your buildsystem doesnt rebuild exomizer and VICE if needed? lame =) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
