| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Small Filebrowser with fastloader for Pi1541
Hello all!
Since I'm using my Handheld 64 with Pi1541 and I am neither willing to JiffyDOS it nor have a utility cart plugged in at all times, I am wondering why nobody married the Pi1541 FB64 (the modded one from the Pi1541-homepage) with a fast and small software fastloader such as "25x Turbo" (25 X Turbo) to include that in the FB64 binary and run it just before loading whatever is chosen to load from FB64. There really is no need to use slooooow ROM loading a la SD2IEC when the Pi1541 can handle fast loaders, is there?
Now, while we're at it, adding a simple "N:Newdisk" DOS command feature to create and mount new .d64s right in FB64 (default behaviour when it's in SD2IEC mode!) would seem like a really useful addition, too, and maybe possibly delete and rename, too!...
Any takers here? ;-) I tried to convince a few people like Bitbreaker, GRG and FieserWolf to do it, but that didn't go anywhere because neither of them have a Pi1541....
P.S: "Dir Plus" from boray.se actually does the .d64 creation, rename and delete and even move on Pi1541, but unfortunately not the speedloader bit. Also it's like 100 blocks big, so utterly unuseable as an FB64 alternative!... |
|
... 77 posts hidden. Click here to view all posts....
|
| |
TSM
Registered: Jan 2007
Posts: 42 |
Very well! Can you take a look at this new, hopefully much better version?
https://drive.google.com/file/d/1EFW8ZacmACwtrgQf043UlefwoQaSt4..
This version should not activate turbo mode in images other than D64 and D71, and it should restore kernal routines when done loading.
"Reset25" has to do with the algorithm's logic. Location $25 must be 0 when you launch a program, otherwise it's treated as a tape image. It probably is set to 0 in the part that I can't test, that is, when you "enter" a disk image.
Regarding your other request, we'll see but don't hold your breath :-D |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: Very well! Can you take a look at this new, hopefully much better version?
https://drive.google.com/file/d/1EFW8ZacmACwtrgQf043UlefwoQaSt4..
This version should not activate turbo mode in images other than D64 and D71, and it should restore kernal routines when done loading.
"Reset25" has to do with the algorithm's logic. Location $25 must be 0 when you launch a program, otherwise it's treated as a tape image. It probably is set to 0 in the part that I can't test, that is, when you "enter" a disk image.
Regarding your other request, we'll see but don't hold your breath :-D
Do ignore .d71, Pi1541 cannot handle these images. only .d64, .d81, .prg, .t64 and .lst (mount lists)
Testing the old version:
Stuff from both .d64 and .t64 loads fast in both versions, both in normal and reset25 versions.
PRG loads slow in both.
I cannot tell *any* difference between the two! Any suggestion on what to try?
Todo: .lst files
Testing the new version now.. Together with Xander! ;-) What's the difference between turbo and turbox? |
| |
TSM
Registered: Jan 2007
Posts: 42 |
Turbox is compressed with Exomizer, otherwise it's exactly the same. The new version is based on the source files while the old one was an hack.
You may want to take a look at the thread that I started on the Lemon64 forum, someone has found a number of flaws.
If you have a freezer cartridge, you could check location $25 just after entering a D64 image. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Okay.. Did read the thread on Lemon. The issues with extra drives are to be expected, quite sure 25x Turbo cannot handle multiple drives, since back in 1986 there was no STFU yet to shut up the other drives.. implementing a STFU routine could solve these issues. As for alternate DOSes: Maybe there's a simple detection to see if non-stock stuff is running on the drive, in which case you don't install the Turbo? Krill?
May I ask what sources you based the new version on? Cause from what I understand Stephen modded FB64 for Pi1541.. Did he also put those modded sources on Github?
As said, .d71 cannot be mounted on Pi1541. The much more widespread .t64 (Gamebase64!) however does mount - and the turbo worked for this in your original hack, so don't kill that..
As for PRG files Steve's FB64 behaves wrongly. when using the Pi display and buttons PRGs get mounted in a temp .d64 just like .t64s do (which means they should also load fast! I just tried it by mounting a PRG manually and loading it with 25x Turbo, it works!), but FB64 loads PRGs directly in SD2IEC mode, i.e. sloooow.. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
TSM, can you make FB64 treat PRGs just like .d64s, mounting them etc? Quite sure that's what the button/OLED does when you select a PRG...
As for the T64s, it is quite possible that the T64s I've tried this with came from a Gamebase64 collection that was tailored for SD2IEC use (I got them from the guy that built my Handheld). I find that I cannot mount other T64s from CSDb on Pi1541. My hunch is that the GB64 ones are just renamed PRGs, but I will analyze them... |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
I played around with the new turbox version from yesterday. as expected, it does not mount and load fast on the GB64 T64s anymore but stays and loads in SD2IEC mode.
I did analyze the GB64 T64s, and they're not just renamed PRGs, they do have a 32 byte T64 header: "C64 tape image file". But when I transplant that header into a t64 that does not work, it does mount, but it's shown as empty. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
I got the CSDb t64 (Einstein IV ) to mount (and load fast on the old FB64 mod!) on Pi1541 by replacing the first 32 byte header with the one above AND changing the filetype at offset $41 from $c2 to $82...
I'll message Steve that Pi1541 t64 handling needs to be adjusted to scan for the strings "C64" and "tape" in the first 32 bytes and also to mask out the high nybble for the filetype...
one thing that might be an issue, also with .lst files, is fb64's inability to handle filenames longer than 12 characters.
i had to rename the hacked file because both files showed as einstein_iv_.t64 in FB64 and no matter which one I chose it would always only load the first one (which was the original).
Does anyone have multi-file .t64s for me to test? All the ones I've found are single files!.. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
I opened an issue about T64 file handling on Github:
https://github.com/pi1541/Pi1541/issues/239 |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
I did test .lst mount list files, here are my findings:
1) File name length is not an issue. i tried loading mount lists with 8, 12 and ridiculous (like 24) char d64 names via both the OLED and FB64, and all worked just fine.
2) They do load fast on the old FB64 mod (only tried normal, not reset25, still wondering where that might make a diff!), TSM, but they load slowly on the new turbox one. Probably cause .lst is not part of the "install fastloader for this" filetypes - so please do add, just like .t64 and .prg (which should be treated like a .d64 first in FB64)! ;-) |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
TSM: I froze your old FB64 mod both as normal and reset25 just after mounting and entering the same d64 and an M0025 showed me it was $00 in both versions. Does that help you? |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 - Next |
