| |
Krill
Registered: Apr 2002
Posts: 2839 |
Release id #189130 : Krill's Loader, Repository Version 184
I've seen the installer print "WARNING: Buggy 1541U firmware detected. Please update." in a demo compo.
Now, i was planning to remove the workarounds for compatibility with older 1541U firmware versions in future releases of this loader.
I was under the impression that the relevant fixes have been backported to old 1541U1 firmware (they shouldn't really require any more FPGA resources)... But have they, really? =) |
|
| |
Count Zero
Registered: Jan 2003
Posts: 1821 |
So this gets answered:
tried the testloader from the archive with 1541U1 and firmwares 1.72beta (WVL) and 2.6d from https://www.obliterator918.com/1541-ultimate-firmware/ dating 2013.
Both show the failure.
Anybody aware of more recent U1 versions to try? |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Out of curiosity, which incompatibilities do you need to add workarounds for in this case? |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Most importantly, ANC #imm and ARR #imm weren't (aren't) emulated correctly.
Could make do without the former, but for the latter, need to dynamically modify some very timing-critical drive-side code on initialisation.
Additionally, the behaviour of VIA1 port A ($1801) set to output wasn't (isn't) emulated correctly.
This is only used in the ATN responder running on secondary (passive) drives (allowing usage of the 2bit+ATN protocol with more than one drive on the bus), for quicker response and less interference using JMP ($1800).
That code has a separate detection and dynamically chooses between this and a slower code path with traditional polling via BIT $1800 and branches.
From the installer code: sei
;ldy #$00
dey
sty $0300
sty $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
tya
arr #$7f; bit 6 of result goes to carry
ror $0300
is1541u: lda #$66; 1570/71 data directions
sta $1803
; no cli
rts |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Ah, very annoying that the CPU isn't up to par. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Yes, took me a while to figure out what was going wrong on 1541U.
Luckily, 1541U2 inherited the U64 CPU core later (or at least relevant parts of it), and those tricky undocumented opcodes are far more common on C-64 than the drive. =)
But alas, 1541U1 seems to be officially at EOS now. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
but where are the testprograms? :) |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quoting KrillYes, took me a while to figure out what was going wrong on 1541U.
Luckily, 1541U2 inherited the U64 CPU core later (or at least relevant parts of it), and those tricky undocumented opcodes are far more common on C-64 than the drive. =)
But alas, 1541U1 seems to be officially at EOS now.
Would be nice to have a compatibility matrix. I have a 1541U1 and a 1541U2 (not plus). It was a long time since I updated anything though as things have worked ok in practice.
I'm not sure if the full FPGA source for the U1 is available. It didn't use to be. Any takers for a patch? It would be a shame if the 1541U1 would start to become "useless". I've used that as standalone for various devices, eg. the c64dtv and the vic-20. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Groepazbut where are the testprograms? :) This works fine on VICE and is most likely well covered by its test suite.
As for actual testing with 1541U, there is a test program in the archive at Krill's Loader, Repository Version 184 in /loader/build/loadertest-c64.d64.
This would print the message in the OP and report "1541U" as drive type. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
tlr: the 2.x firmware can be build (or at least: could) for U1, the source for that is available. It's a shame gideon doesnt bother to do it anymore, it shouldnt be hard or even complicated to do. |
| |
Peiselulli
Registered: Oct 2006
Posts: 81 |
I remember the 2.x firmware does not support stand alone mode. That is the reason I still use the 1.72beta. |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quote: I remember the 2.x firmware does not support stand alone mode. That is the reason I still use the 1.72beta.
Ah, now that you mention it I remember that's why I do too. :) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Alright, seems like i'll leave the 1541U workarounds in there, then.
Could squeeze in the things i had on the list without touching the 1541U compatibility stuff. =) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
User Comment
Submitted by JackAsser [PM] on 6 May 2021
Once save fully works I will add this loader to EotB instead of just using KERNEL. That would speed up load and saving frrom and to disk alot. Currently I use JiffyDOS just to have it a bit quicker at least.
User Comment
Submitted by Krill [PM] on 6 May 2021
Luke: In fact, yes! As of two days ago, can save to slots (overwrite existing files in their entirety) on 1541. =) Testers are on it. Will add 1571, 1581 and KERNAL fallback in the meantime.
(Before adding the saver, was busy integrating ZX0 and LZSA2 courtesy of Bitbreaker, then refactored, streamlined and optimised a lot of things. It's both smaller and faster now.)
User Comment
Submitted by Luke [PM] on 6 May 2021
Great tool! @Krill any progress on saving? ;) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting JackAsserOnce save fully works I will add this loader to EotB instead of just using KERNEL. That would speed up load and saving frrom and to disk alot. Currently I use JiffyDOS just to have it a bit quicker at least. That would be nice! (And compatible with the BSD-style license :D)
Keep in mind that there is no SD2IEC support except KERNAL fallback, currently. That is, SD2IEC with JiffyDOS would work with okay speed, but not use the loader's native protocol.
I have just changed the protocol again, but now it finally looks good. As in could be set in stone.
Will contact SD2IEC gurus and discuss adding support. =) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Oh, and saving isn't really that fast and will most likely be slower than saving with JiffyDOS.
It's at least about half as quick as could be, as the drive-side code first enumerates all blocks in the saveslot file (pretend-loads the file before saving) before receiving the savefile data to then overwrite the previously enumerated file blocks.
Add on top the fixed overhead to swap drive-side loader and saver code via C-64 RAM. |
| |
Luke
Registered: Nov 2014
Posts: 9 |
Quoting KrillQuoting Luke
Great tool! @Krill any progress on saving? ;)
Luke: In fact, yes! As of two days ago, can save to slots (overwrite existing files in their entirety) on 1541. =) Testers are on it. Will add 1571, 1581 and KERNAL fallback in the meantime.
(Before adding the saver, was busy integrating ZX0 and LZSA2 courtesy of Bitbreaker, then refactored, streamlined and optimised a lot of things. It's both smaller and faster now.)
That's great news! Both, saving AND ZX0 support! So many compression choices. :D
I'm planning to use the loader for a little game I'm working on and being able to save progress/highscores to all the drive types the loader can load from would be awesome. And just in time to give my motivation a big boost, thanks for that, too! ;) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting LukeSo many compression choices. :D =D Supporting 11 crunchers now (all of them working on bytestreams).
One game project i'm aware of might probably mix at least two of them. Some files compress better with one packer, some others with another.
Having different incarnations of the resident portion is perfectly possible while leaving the same loader code running in the drive, and apparently there still is a net gain. =) |
| |
Lynx
Registered: Apr 2004
Posts: 12 |
Quote: So this gets answered:
tried the testloader from the archive with 1541U1 and firmwares 1.72beta (WVL) and 2.6d from https://www.obliterator918.com/1541-ultimate-firmware/ dating 2013.
Both show the failure.
Anybody aware of more recent U1 versions to try?
Im am pretty sure 2.6 is the latest..
Any workaround available? |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
The workaround would be to ignore the warning and carry on. =)
Now that there seems to be some kind of regression even with current U2+ versions... even more so! :)
(I guess i'll leave that piece of compatibility code in for a while.) |
| |
Luke
Registered: Nov 2014
Posts: 9 |
Hi @Krill, I'm building the loader into a Docker image and wanted to build all the included compressors as well. While doing so, I encountered a small error:
In the top Makefile there's this target:
cc1541:
$(MAKE) -C ../$(TOOLSFOLDER)/$(CC1541SRCFOLDER)
However, CC1541SRCFOLDER is actually CC1541FOLDER in the Makefile. :)
Looking forward to the next version ;)
P.S.: With the above change I was able to create an image with all the tools pre-built inside. It's publicly available here and I tried to make sure it's properly marked as unofficial: https://gitlab.com/robotriot/krills-loader/
Are you OK with that? |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Luke: Thanks for the heads-up! It appears i have fixed that mistake as well in the meanwhile. =) cc1541:
- $(MAKE) -C ../$(TOOLSFOLDER)/$(CC1541SRCFOLDER)
+ $(MAKE) -C ../$(TOOLSFOLDER)/$(CC1541FOLDER) Quoting LukeLooking forward to the next version ;) Oh yeah, it's long overdue. Will resume working on it after pushing out a Transwarp patch release soonish. :)
It's basically finished, but need to tidy it up a bit. Has an optional hi-score saver (built on top of a now-clean custom drive code API), new ZX0 and LZSA2 support, bumped Exomizer to v3.1, oh, and an actual file-exists call to ease disk-jockeying. :)
A lot cleaner code now, too, especially for integrating all those stream decrunchers, but that only shows when actually looking at the code. (And maybe because it makes it all a little less prone to bugs.)
Quoting LukeAre you OK with that? Yeah, all good. Thanks! :) |
| |
Luke
Registered: Nov 2014
Posts: 9 |
Yeah! Great stuff. =) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Ah, there's also one relatively important compatibility improvement with 1541-old. :)
Main disk read+decode+checksum loop is now one cycle faster, to make up for the wobble these old belt-driven beasts exhibit (and it doesn't get better with age). |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
New version done, release soon! =)
- improved speed and tolerances
- added decompression support for ZX0-Dali, TSCrunch and LZSA2
- added hi-score saver overwriting existing save-slot files
- added file-exists API for easy multi-disk handling
- added custom drive code API
- added close-file API
 |
| |
Smasher
Registered: Feb 2003
Posts: 512 |
great news!! |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
=) Next on the list is adding native 1551 support (only relevant for the Plus/4 folks, ofc.), but i'll leave that for the next release after this one. |
| |
Joe
Registered: Apr 2002
Posts: 224 |
Awesome work! |
| |
DKT
Registered: Aug 2004
Posts: 96 |
Hooray! \o/
Awesome new features! can't wait |
| |
Perplex
Registered: Feb 2009
Posts: 254 |
Great news! |
| |
El Jefe
Registered: Jul 2005
Posts: 68 |
Really looking forward to this one!
Shocker/Onslaught |
