| |
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: 1289 |
Bongo Linking Engine this? :)
Bitfire 0.3 or this? :) |
| |
Endurion
Registered: Mar 2007
Posts: 72 |
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: 419 |
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: 2821 |
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: 222 |
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: 2821 |
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: 1031 |
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: 1031 |
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: 2821 |
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: 2821 |
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. :) |
| |
Bitbreaker
Registered: Oct 2002
Posts: 498 |
Quoting KrillQuoting 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? :)
I'd love to have compareable figures from spindle, but it was too much hassle for me to build a testcase with it. I guess it is slightly faster but compresses worse and thus loads again longer. Also memory footprint on c64 side is bigger.
And now deliver your new version, go! go! go! :-) |
| |
Bitbreaker
Registered: Oct 2002
Posts: 498 |
Quote: 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. :)
No. :-) |
| |
HCL
Registered: Feb 2003
Posts: 716 |
Oh, you forget the toolchain that is used in most top-10 productions already: ByteBoozer and the BoozeLoader :). Well tested in real life situations by top demos for 10-15 years by now!! Now with ByteBoozer2.0 you don't need to be afraid to be slower or larger than any of the other oh so popular systems, just chill and let the slim code do the job for you :).
Bb2.0 is not yet out for grabs though, but will be soon. You can of course have a pre-release if you ask me kindly ;). |
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
Ideally I would like to have something that allows me to work kind of like this from a .BAT-file (yeah, I still use those!)
<compile a bunch of files using Kickass>
<pack each file using PACKERTOOL_XXX>
<make a D64 of all files using D64TOOL_YYY>
Then in my main program I want to be able to do something like:
jsr initloader
..
lda/ldx/ldy #SOME_REFERENCE_TO_PART1
jsr load_and_decrunch_at_the_same_time
jsr part1
lda/ldx/ldy #SOME_REFERENCE_TO_PART2
jsr load_and_decrunch_at_the_same_time
jsr part2
I have taken a look at all the suggestions that have been posted so far (with the exception of HCLs stuff, as it seems only the packer and not the loader is released from what I can find on CSDb) and both Bitfire and Krills loader seem to do pretty much what I want to.
I started with Krill as it got the most recommendations. Unfortunately I am lazy and the list of prereqs to compile the thing was a bit too much, as I would need to get cygwin and perl etc. etc. setup first.
I then moved on to Bitfire. I managed to compile win32 versions of both the d64write and bitnax utility, but now I need to download ACME and try to get the files assembled without access to all the sed-magic that the Makefile uses. Another day maybe.
I know I am a bit of a grumpy old man, but I have never really seen the charm with the Linux way of doing things, with distributing sources and makefiles and always having to build everything from scratch when you want to use it. |
| |
HCL
Registered: Feb 2003
Posts: 716 |
Well, you really seem to need my stuff.. :). But I'll talk you later, have to go sleep now.. |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Quoting BitbreakerAnd now deliver your new version, go! go! go! :-) I'm working on a patch release to fix a few bugs and make it compatible with recent versions of cc65/ca65/ld65 again and drop the dreadful Java and Dosbox (for Levelcrush) dependencies. New features and speed improvements will only be contained in the release after that, and who knows when i'll come around to finally do all that. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 498 |
Quote: Oh, you forget the toolchain that is used in most top-10 productions already: ByteBoozer and the BoozeLoader :). Well tested in real life situations by top demos for 10-15 years by now!! Now with ByteBoozer2.0 you don't need to be afraid to be slower or larger than any of the other oh so popular systems, just chill and let the slim code do the job for you :).
Bb2.0 is not yet out for grabs though, but will be soon. You can of course have a pre-release if you ask me kindly ;).
Bla bla bla, share and compare your penis or gtfo :-P |
| |
Bitbreaker
Registered: Oct 2002
Posts: 498 |
Quoting Shadow
I then moved on to Bitfire. I managed to compile win32 versions of both the d64write and bitnax utility, but now I need to download ACME and try to get the files assembled without access to all the sed-magic that the Makefile uses. Another day maybe.
I know I am a bit of a grumpy old man, but I have never really seen the charm with the Linux way of doing things, with distributing sources and makefiles and always having to build everything from scratch when you want to use it.
Well, try to pretty print the labels for other assemblers without any tools but just with a .bat :-) That is what the sed wizardry is for, you can of course just pick the needed labels by hand and adapt them, no need to use the Makefile.
I'm aware that KickAss is offering the possibilities to do all this within an assembler, but well, that would fill again another thread about why that might be a good or bad idea :-)
Distributed sources allow to understand mechanisms and allows one to add own changes easily. I could of course just release a installer and resident part with a fixed address and let it up to you to relocate :-D Also it gives people to continue the work or fix bugs if a project is abandoned or if there's no feedback form the developer in time.
When you compiled acme finally, stick to it, it's worth it :-D |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Quoting HCLOh, you forget the toolchain that is used in most top-10 productions already: ByteBoozer and the BoozeLoader :) ... and this is a very dubious claim as well. Unless you mean the top-10 Booze productions, which would make this a bit of a tautology. :) |
| |
Flavioweb
Registered: Nov 2011
Posts: 442 |
I think that Cadaver loader could be a good choice.
Is fully customizable, support exomizer ad pucrunch in any version and with all possible configuration.
Usually i use Cadaver loader, with 2bit protocol, and exomize my files simply with the "level" parameter, setting the loader configs accordingly.
To create the disk image, cc1541 could be a good choice too. Need some little bugfix to manage BAM correctly but you notice it only if you need to save on disks, but it's a nice tool since you can change files interleave quickly.
Create a chain with these tools and with your fave compiler, it's quite an easy task, both if you choose batch or make files to do it.
If you want to go a little deeper, using *nix power in a windows world, you should think to install cygwin.
With cygwin you can compile sources for windows and use makefiles as on native *nix system, but using your files in/for windows.
Just my 2 cents... |
| |
HCL
Registered: Feb 2003
Posts: 716 |
hey guys, just take a deep breath and drop all that anger and envy.. :) |
| |
Bitbreaker
Registered: Oct 2002
Posts: 498 |
Quote: hey guys, just take a deep breath and drop all that anger and envy.. :)
what? 8-D |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Quoting Flaviowebcc1541 could be a good choice too. Need some little bugfix to manage BAM correctly Which version are you talking about? That bug has been fixed like, what, 10 years ago? (By Jackasser himself, who started this tool, then it got forked somewhat inadvertently and never merged again. I guess his version ties his shoes and makes toast every morning by now.) |
| |
HCL
Registered: Feb 2003
Posts: 716 |
Omg, this is truly embarresing.. If this is so important to you Bitbreaker, i will leave this discussion to avoid further harm.. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
if it wasnt so important there wouldnt be so much work invested, right? lets not pretend its not :) |
| |
Flavioweb
Registered: Nov 2011
Posts: 442 |
Quoting KrillWhich version are you talking about? That bug has been fixed like, what, 10 years ago?
I don't know if there are other sources for download, but quoting JackAsser himself:
Quote:
Submitted by JackAsser [PM] on 2 July 2013
I thought the version here was fixed TBH. The bits in each byte in the BAM was reversed. Just add a (7-i) somewhere in that code. Should be easy to spot! :)
I have not checked if the exe working properly, but compiling it from sources, bug still alive and kickin'.
cc1541 |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
Quoting HCLhey guys, just take a deep breath and drop all that anger and envy.. :) I dont see any anger in this thread at all, just a pissing contest. Isnt that what the scene is about? :P
also, my loader > your loader :)
neither krillloader, byteboozer, bitfire, cadaver, or whatever supports the things my proprietary loader supports, so you all suck anyway :P
PS: the cc1541 on csdb is still borked, the fix is easy though. |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Quoting FlaviowebI don't know if there are other sources for download My loader came with an incarnation of cc1541 since day one. A quick check using the validate command suggested it generates the BAM just fine, at least with the last officially released version (v146). |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Quoting Burglarneither krillloader, byteboozer, bitfire, cadaver, or whatever supports the things my proprietary loader supports Yes, as with all engineering, there is no Silver Bullet (TM) :) Just occupying different spots in the design space to suit different objectives, trading off this for that on the designer's whim. (Amen.) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
i wonder how many more years it'll take until those tools are available in a proper repository :) i'd even submit the changes/fixes i made locally :)
and just for the records: all loaders suck. and their coders are fucking weirdos. FACT |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
somehow it's very odd that groepaz never made a loader :) |
| |
Trap
Registered: Jul 2010
Posts: 222 |
I just want to say that I love that you guys share all your hard work with us less fortunate (dumb?) souls, so we can reap all the benefits. True Bonzai style guys ;)
Sharing is caring :D |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
burglar: actually i did - and it sucked even betterer than the existing alternatives (taboos) ... i doubt anyone would want to see it =) |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Quoting Groepazi wonder how many more years it'll take until those tools are available in a proper repository :) i'd even submit the changes/fixes i made locally :) I think you've just answered your implicit question yourself :D |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
perhaps i should just push my local repo to github and hijack this... =P |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: Quoting FlaviowebI don't know if there are other sources for download My loader came with an incarnation of cc1541 since day one. A quick check using the validate command suggested it generates the BAM just fine, at least with the last officially released version (v146).
/nitpick
on day one your loaders came in native c64 turbo ass src without cc1541 O:-)
/nitpick |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Quoting Oswaldon day one your loaders came in native c64 turbo ass src without cc1541 Yes, the other loaders before the current one. They're somewhat related but different projects. I meant day one of the current loader. |
| |
Pantaloon
Registered: Aug 2003
Posts: 124 |
Krill+Doynax is uber! and very easy to use, i wouldn't change my setup unless some other setup did add alot of benefits, which they don't. For the actual linking i use a simple framework and a custom "make" script written in ..... VBS :) |
| |
raven
Account closed
Registered: Jan 2002
Posts: |
HCL, is your loader still failing on 1571 drives?
EOD is not working on my 128D due to loader issues, cant remember if I tried any of your later demos on 1571. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: Krill+Doynax is uber! and very easy to use, i wouldn't change my setup unless some other setup did add alot of benefits, which they don't. For the actual linking i use a simple framework and a custom "make" script written in ..... VBS :)
yeah, 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. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 498 |
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 ... |
| |
HCL
Registered: Feb 2003
Posts: 716 |
@Raven: Yes my loader worx fine on 1571, EoD still has problems, as i don't care to re-link old demos as soon as i update my loader.. :P.. Perhaps i should (?)..
128dcr still needs extra care, by adding that extra cycle in the transfer loop.. i guess noone but Krill actually did his homework properly there.. |
| |
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: 498 |
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: 11089 |
your buildsystem doesnt rebuild exomizer and VICE if needed? lame =) |
| |
Flavioweb
Registered: Nov 2011
Posts: 442 |
Mine recompile also the kernel using "make oldconfig && configure && make && make modules && make mrproper".
...
Doh! |
| |
Trap
Registered: Jul 2010
Posts: 222 |
I would love to see an example on how you do things in a bat/vbs file? |
| |
Bacchus
Registered: Jan 2002
Posts: 154 |
I have started a more objective summary of the existing solutions out there.
Feel fee to contribute (you can comment - not edit) to prove how far you can piss. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
wasnt there a long thread that compares loaders (and had hard numbers) a year ago or so? :=) |
| |
Shine
Registered: Jul 2012
Posts: 327 |
This:
Nucrunch 0.1
?
EDIT: Ah you talked about loaders, so i missunderstood ... |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Bacchus: Hold your horses when testing my loader, please. New release soon, with massive performance improvements :) |
| |
soci
Registered: Sep 2003
Posts: 473 |
If you have time please check which version of your loader was used in this release:
Dreamtime 2K17
I hope it's something ancient.
It was pure luck that I could show this without a crash at the compo. Spent more than a hour to try to master a version with a box of disks and several drives (in top condition) before I run out of time and gave up.
It was not possible, it always hang after a while or loaded garbage. Basically this version reached the point that it's only usable with an emulator.
Please add more tolerance for real hardware in the coming version if not already done so.
Thanks! |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Ah, now we finally know who "Profi 1" really is. :)
Anyhow, i've peeked a bit at the linked prod and found following pieces of code offending the loader's API:
.C:0a2b AD 00 DD LDA $DD00
.C:0a2e 29 FC AND #$FC
.C:0a30 09 03 ORA #$03
.C:0a32 8D 00 DD STA $DD00
.C:2863 AD 00 DD LDA $DD00
.C:2866 49 02 EOR #$02
.C:2868 8D 00 DD STA $DD00 I know that documentation has not been the strong suit of that tool so far, but include/loader.inc has this revealing convenience macro:
.macro SET_VIC_BANK bank
lda #bank & 3
sta CIA2_PRA
.endmacroThat is, the upper 6 bits of the value written to $dd00 MUST always be 0.
The code above should look like this:
lda #$03
sta $dd00
lda $dd00
eor #$02
and #$03
sta $dd00 The rationale is that the user shall be allowed to write to $dd00 while loading at any time, and without visual glitches, calling a magic loader subroutine or resorting to semaphore-like locking. This is implemented by the loader reading from $dd00 to read bits from the serial bus, but writing to $dd02 ($dd00's corresponding data direction register) to write bits to the serial bus - which only works if the corresponding bits in $dd00 are 0.
Now, with code setting those non-VIC-bank bits to 1, i'd expect it to crash the loader sooner or later, not only on real hardware, but any emulator on VICE level as well.
So maybe you've managed to find a lucky timing co-incidence which is stable and reliable only in the emulator, or this is not the (only) cause of the problem.
That being said:
Quoting sociI hope it's something ancient. The version string in the install routine says "Krill's Loader, version 146" (Krill's Loader, repository version 146), which is (still) the latest official release. Although i've been giving out newer versions upon request, none of those has made it to official release status yet (but they're still the latest and greatest, until the version counter goes up).
Quoting sociPlease add more tolerance for real hardware in the coming version if not already done so. You're the first person to report significant compatibility issues, and rest assured i _do_ test my shit on my sizeable stack o'drives. :)
So please check if above suggestions fix the problem, and if not, let's investigate further.
And always feel free to ask right away, should problems occur. I wonder if you'd have asked me if it wasn't for my teaser up there.
Oh, and i'm always grateful for more beta testers. :D |
| |
soci
Registered: Sep 2003
Posts: 473 |
Thanks!
It must crash with 1541U the same way then. The author insisted it worked for him 100% the time blaming the equipment and more (gently). I'll try it again soon.
I think I'd trip on this RMW trap just as well. It needs to be documented for sure that doing so is a bad idea as the loader manipulates the direction register and such code may cause control bits to be set inadvertently.
It's somewhat similar to a bug one of the entries had (but was fixed early):
lda #xx ; raster line in range of 56-255
sta $d012
lda $d011
and #$7f ; clear high bit as it's less than 256
sta $d011
... do some stuff without syncing to screen
lda $d011
ora #$20 ; switch to bitmap
sta $d011
... and now "crash" 18% of the time with an IRQ set to line 312+
Registers which return something else then they were set to can be great fun ;) |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Quoting sociIt must crash with 1541U the same way then. Ah, so by "emulator", you meant 1541U? Still, other productions using this loader, and in that version, worked fine on 1541U AND the classic drives.
But then it can be argued if an emulator not failing on a bug that trips up on the real hardware (but not vice versa) can be called a bug. It's non-perfect emulation for sure, but from a user perspective... :)
Quoting sociIt needs to be documented for sure that doing so is a bad idea as the loader manipulates the direction register and such code may cause control bits to be set inadvertently. Yes, indeed. I've just valued working on the code more than writing up docs, and responded to people's questions personally and helped them (including changing or adding things based on their experience/reports).
But yeah, quite a while ago already, i've drafted up a small concise text with the most important bits to know and observe about usage and caveats. It'll finally make it into the next release.
Quoting sociRegisters which return something else then they were set to can be great fun ;) Indeed, and quite a few are like that in C-64 world. |
| |
soci
Registered: Sep 2003
Posts: 473 |
On emulator I've meant VICE.
It seems it doesn't even start with the 1541U-II I have with me which means it need to wait at least a week or so... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
VICE isnt perfectly right with this kind of things either, beware :) |
| |
soci
Registered: Sep 2003
Posts: 473 |
Should have checked earlier but the loading and $dd00 manipulation does not happen at the same time so it could be something else. |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Quote: Should have checked earlier but the loading and $dd00 manipulation does not happen at the same time so it could be something else.
Just speculating here. The loader might poll anything while not loading putting it into an illegal stale when manipulating $dd00, even outside loading? or? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
somehow i have a dejavu right now =) |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Quoting JackAsserJust speculating here. The loader might poll anything while not loading putting it into an illegal stale when manipulating $dd00, even outside loading? or? It doesn't poll anything when idle because it's simply not being executed. :) However... writing anything in $00..$ff to $dd00 when not loading requires the config option IDLE_BUS_LOCK to be enabled, otherwise you're still limited to the usual 0..3 range to set the VIC bank. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 498 |
Question is, why would we want to write anything else than $00..$03 to $dd00 in a demo? Stop that expensive and unnecessary masking already :-) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11089 |
lda fpptable,x
sta $d018
sta $dd00
? |
| |
Bitbreaker
Registered: Oct 2002
Posts: 498 |
ldx #$03
lda fpptable,y
sta $d018
sax $dd00
;-) |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Right, because you can always afford to waste the X register just for some $dd00 masking :) |
