| |
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? =) |
|
... 20 posts hidden. Click here to view all posts....
|
| |
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? |
| Previous - 1 | 2 | 3 - Next |
