| |
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....
|
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Mine recompile also the kernel using "make oldconfig && configure && make && make modules && make mrproper".
...
Doh! |
| |
Trap
Registered: Jul 2010
Posts: 223 |
I would love to see an example on how you do things in a bat/vbs file? |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
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: 11386 |
wasnt there a long thread that compares loaders (and had hard numbers) a year ago or so? :=) |
| |
Shine
Registered: Jul 2012
Posts: 369 |
This:
Nucrunch 0.1
?
EDIT: Ah you talked about loaders, so i missunderstood ... |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Bacchus: Hold your horses when testing my loader, please. New release soon, with massive performance improvements :) |
| |
soci
Registered: Sep 2003
Posts: 480 |
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: 2980 |
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: 480 |
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: 2980 |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
