| |
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....
|
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Well, I saw a JiffyDOSed c64 at Homecat's place on Monday, if I take my 3A-Pi1541 with me I should be able to test it with FB64... But that'll only be JiffyDOS! No SpeedDOS, DolphinDOS, ProfessionalDOS, RapidDOS etc... Someone else will need to do that! |
| |
TSM
Registered: Jan 2007
Posts: 42 |
Just try neverfast.prg on a stock kernal. The actual recognition mechanism should be ok, it's the mechanism that enables/disables fastloading and automatic PRG mounting that needs testing.
To summarize, on a stock kernal:
- "kc" should always fastload, just like the previuos version
- "neverfast" should never fastload and never mount PRGs
EDIT: I can easily test the kernal recognition part under emulation |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: Just try neverfast.prg on a stock kernal. The actual recognition mechanism should be ok, it's the mechanism that enables/disables fastloading and automatic PRG mounting that needs testing.
To summarize, on a stock kernal:
- "kc" should always fastload, just like the previuos version
- "neverfast" should never fastload and never mount PRGs
EDIT: I can easily test the kernal recognition part under emulation
Okay, I tested it on my Handheld with stock kernel:
neverfast always loads slow (tested: prg (no mounting), lst with d64s, d64, t64 (also multi-file), d81)
KC loads fast on the files that it should (prg (mounted), lst with d64s, d64, t64 (also multi-file)) and doesn't on d81
If the alternate kernel detection works i guess we can consider this a success! ;-D Great!
Should we release/git-submit it now or do you reckon that you could add the new disk command thing? it's just asking for a max 16 char string and then send a "N:$string,xx" DOS command (the ,xx bit is crucial, it won't work without!) in SD2IEC mode really.. it gets automounted after creation btw by Pi1541!
Scratch (S:) and rename (R:) would also be possible, but I fear that would create all kinds of problems with FB64 not being able to process longer filenames, huh? |
| |
TSM
Registered: Jan 2007
Posts: 42 |
Latest source code + turbo binaries:
https://drive.google.com/file/d/1FRx2b3BFbrXbuaeqcAD4st_hHVP1vs..
I think the "new disk / scratch / rename" stuff doesn't really belong in this piece of software. Users should have "dracopy" (*) or something similar in their SD cards for such operations. On top of that, a number of checks should be implemented to prevent filename conflicts etc., which in turn would bloat the program and make the source code even more convoluted than it is.
This source should still build all the versions the old one does but it's still somewhat "hackish", so I would advice keeping it separate from the Pi1541's official repository. I don't use git or github, so do as you see fit. Maybe upload it to CDSb?
* Be sure to name it "dracopy" with no extension ;-) |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
I'm quite sure I tried dracopy with Pi1541 and it didn't work with its somewhat limited SD2IEC compatibility. I've tried a shitload of filebrowsers, but the only ones that worked are those that were specifically adjusted for and tested with Pi1541, i.e. FB64 aka CBMfilebrowser and Boray.se's Dir Plus!...
From the screenshot I think I've tried it, but I shall try once again... Which version do you recommend, TSM? |
| |
TSM
Registered: Jan 2007
Posts: 42 |
I wasn't aware of all these problems. Apparently, Dir Plus is your only choice and even that will fail from time to time. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
okay, I tried Dracopy with Pi1541. v1.0d won't even start, the progress bar grows gor a minute or so and then i get a blue screen. v1.0e does start, but shows nothing and does not react to any keypresses.. |
| |
TSM
Registered: Jan 2007
Posts: 42 |
Sadly, the only program that will (mostly) work for you is probably Dir Plus. The old CBM Command is worth a shot, though.
Anyway, can I see this famous handheld 64 that you have? :-) |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: Sadly, the only program that will (mostly) work for you is probably Dir Plus. The old CBM Command is worth a shot, though.
Anyway, can I see this famous handheld 64 that you have? :-)
Sure: https://youtu.be/3HPQoBLAABs?t=969
..and in German:
https://www.youtube.com/watch?v=BGeMEu-VzSU
and
https://www.youtube.com/watch?v=aPOQ4V2D_-o
I may have actually missed cbmcommand in my testing, cause I cannot remember its UI. But that may be because it just wouldn't start! ;-) I shall try it out!... |
| |
TSM
Registered: Jan 2007
Posts: 42 |
Unbelievable! And it runs on batteries! |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
