| |
Krill
Registered: Apr 2002
Posts: 2965 |
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....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11334 |
no, generated files in the repo are not an option either |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1407 |
Quoting Groepaz(*) another requirement is that i can easily crosscompile windows .exe on my linux system. not sure if that rules out rust too - i havent tried this :)
Ironically that's probably easier for you than for me at this point; I used a Docker container running ubuntu so I could build the windows .exe for nucrunch; directly crosscompiling rust to windows binaries from macOS is currently nontrivial. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1407 |
Quote: python has the same problems, i think (is it a single exe requiring no install?) (the point is: right now "our" dev environment is completely freestanding requiring no msys or cygwin or any of that, and no installing either - breaking that is not an option :))
the problem with ca65 are at least nucrunch and tinycrunch, those will not build.
tinycrunch requires no additional python libraries beyond the python standard library*, and indeed still works with python 2 - so for macOS or ubuntu no further installs should be required. Windows I've no idea.
Thanks for your ca65 bug reports re nucrunch and tinycrunch; I didn't realise newer versions of ca65 had made breaking changes.
(*unless you want to rebuild the test Koala, but I've shipped that) |
| |
Krill
Registered: Apr 2002
Posts: 2965 |
Quoting Groepazno, generated files in the repo are not an option either IMHO, that's needlessly restrictive. While it's generally accepted that adding auto-generated files to a repository is a bad idea for various reasons, i find it perfectly okay to add files that are generated manually once in a while, even if they're generated from other code in the same repository. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11334 |
maybe yes, maybe no :) i like it that way, and i am also exercising certain things there which i like to see elsewhere. |
| |
Digger
Registered: Mar 2005
Posts: 425 |
Yay, can't wait to test it on my really moody drive! |
| |
Lazycow
Registered: Dec 2013
Posts: 2 |
Really fast! But the loadertest-c64.d64 hangs with vice 2.4 on NTSC. Emulation problem or bug? (I don't have an NTSC machine to verify) |
| |
Krill
Registered: Apr 2002
Posts: 2965 |
Quoting LazycowReally fast! But the loadertest-c64.d64 hangs with vice 2.4 on NTSC. Emulation problem or bug? (I don't have an NTSC machine to verify) The option NTSC_COMPATIBILITY is disabled for the pre-built images and binaries (because it would slightly slow down PAL performance, see loader/include/config.inc). Enabling it should make it work with both PAL and NTSC. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Really fast! But the loadertest-c64.d64 hangs with vice 2.4 on NTSC. Emulation problem or bug? (I don't have an NTSC machine to verify)
Not that it matters in this case probably, but generally don’t report bugs / problems using 2yr old emulators. |
| |
Krill
Registered: Apr 2002
Posts: 2965 |
Quoting JackAsser2yr old emulators. FWIW, 1541U (up to and including current versions) detection code as found in loader/src/install.s ;)drvch1541u: .byte "m-e", .lobyte($0205), .hibyte($0205); read forward
sei
ldx #$ff
stx $0300
stx $1803; set all port pins as outputs
lda #$a4; bit 0 may be forced to GND (1541-II) or connected to track 0 sensor (1541-C, normally 0 = not on track 0)
sta $1801
cmp $1801
bne is1541u
anc #$8a; and #imm, but no asl/rol, bit 7 of result goes to carry
beq is1541u
bcc is1541u
txa
arr #$7f; bit 6 of result goes to carry
ror $0300
is1541u: inc $1803; set all port pins as inputs
cli
rts
drvchkued:
If $0300 has a negative value after execution, 1541U detected. |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
