| |
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 |
TSM: I tried out your patched Krestage on my handheld, it works like a charm. The only thing I noticed is that it crashes when it starts again with the first part, right after the part started. But the unpatched original already does that. Dunno if this is a Pi1541 issue or my handheld, can anyone confirm this?
Now, where do I get some d81 multi file from for the freeze testing? Or do I need to just "weld" together several .d81s? |
| |
DeeKay
Registered: Nov 2002 Posts: 362 |
okay, I did some d81 testing by welding the ultima IV and Sonic d81s together in a mountlist. I guess it's safe to say that mount lists and d81 don't really work (on Pi1541 v1.24 at least), cause the .lst file will neither mount on FB64 nor via the OLED/buttons. When i select both d81s on the OLED to make a temporary mount list out of them, it *seems* to work at first, but when you change the disk it just doesn't and the directory is still the first disk.
So I would not bother about that. Steve probably never bothered to support anything else but .d64 in mount lists, theoretically you could also put all other supported filetypes in there (g64, t64, prg, nib etc), not just d81, creating all kinds of nightmare problems, from having to switch drivetypes on the fly to creating temporary d64s out of prgs and t64s, all while being in cycle exact mode...
Loading from a single d81 via FB64 works - but slow, as expected!..
I also patched your multi file .t64 with Final Fight and it loads now (fast!) after changing the header and every file entry to $82 (instead of $02). But the extra "toobig" file won't show up, the directory looks identical for both. |
| |
TSM
Registered: Jan 2007 Posts: 42 |
Thanks for the info, DeeKay. Here's "neverfast.prg" a test-only version that simulates a kernal check gone "wrong" (i. e. "kernal is not stock"). It should work like the one that doesn't check the kernal, but it should never fastload anything.
Along with that is the "throwaway" version that checks the kernal (i included it again for your convenience). On your setup, this one should behave EXACTLY like the no-kernal-check version.
https://drive.google.com/file/d/1SrTClAjrgs9mK5j-2iWsFLPScj8O2_.. |
| |
TSM
Registered: Jan 2007 Posts: 42 |
Quoting xahmolUnfortunately for some reason my Pi1541 went broken. Sorry to hear that! Thank you for the testing you've been doing so far. |
| |
DeeKay
Registered: Nov 2002 Posts: 362 |
TSM: So where is the kernel checked in the KC version? on the drive itself, on the c64 side - or both?
cause i can easily load a jiffy rom on the Pi1541.... |
| |
TSM
Registered: Jan 2007 Posts: 42 |
Quoting DeeKayTSM: So where is the kernel checked in the KC version? on the drive itself, on the c64 side - or both?
cause i can easily load a jiffy rom on the Pi1541.... In the C64 only. |
| |
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 ;-) |
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 - Next |