| |
Krill
Registered: Apr 2002
Posts: 2839 |
Release id #167152 : Krill's Loader, repository version 164
If no problems emerge (i know they will, but anyways)... I can explain a bit about the full on-the-fly GCR block read+decode+checksumming. |
|
... 36 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Groepazthanks for pointing out the emulator code that can be safely removed :) If you mean the 1541U detection code, take a look at this option:.define ONLY_1541_AND_COMPATIBLE 0 ; reduces host-side install code by omitting any native custom drive code for non-1541 compatible
; drives, treats any drive as 1541, using an incompatible drive will cause undefined behaviour
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
but that would remove support for 1581 etc too, i guess? |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Groepazbut that would remove support for 1581 etc too, i guess? Indeed. To keep it simple, there's no option to remove detection of specific models of the 1541 family only, once that family is detected. I'm sure you can figure out what to nix for that. :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
broken emulators are not part of the 1541 family though :) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Yes. But you know the story. After i found out about these incompatibilities the hard way, i grudgingly decided to work around those (because 1541U is quite relevant these days, and some older firmwares for 1541U1 will not be fixed), then add 1541U as a separate drive model, which is now also detected.
The idea is that anybody using the custom drive code API could then decide to use some other code if 1541U is detected and its broken implementation of some illegals or the VIA port would prohibit use of the regular 1541 code. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
i know. terrible ideas there |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Just type "make" they said. Easiest thing in the world. (Haven't tried with this version yet though.) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting CruzerJust type "make" they said. Easiest thing in the world. (Haven't tried with this version yet though.) Not sure what you're getting at, but you don't have to "make", just use the pre-compiled binaries in the archive. If they don't take your fancy for some reason or other, why, just... tell me and your wishes might *just* tip the scale to warrant different defaults. :) |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
Nice, will have to check this out if I ever get the time to do some serious C64 coding again. Thanks for sticking with proper tools. |
| |
Smasher
Registered: Feb 2003
Posts: 512 |
first test: I compiled this amazing loader trying all supported packers.
this is the length of the compiled file "loader-c64.prg" (no raw load):
BITNAX: $29d
BYTEBOOZER: $2a2
DOYNAX: $2bb
EXOMIZER: $370
LEVELCRUSH: $2be
NUCRUNCH: $2d9
PUCRUNCH: $324
SUBSIZER: $384
TINYCRUNCH: $1f2
so you can import the resident at $0100-$03ff (assuming that's a smart place where to put it) with some packers, but not with all of them.
I hope this info could be useful for someone... I'll now dedicate some time on the speed tests. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next |
