| |
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....
|
| |
hedning
Registered: Mar 2009
Posts: 4599 |
I don’t get it. Whatever fastloader that works with the real deal should work with the emulated stuff, or the emulated stuff needs to be fixed. There should be no need for emulator only fastloders? |
| |
TSM
Registered: Jan 2007
Posts: 42 |
Quote: I don’t get it. Whatever fastloader that works with the real deal should work with the emulated stuff, or the emulated stuff needs to be fixed. There should be no need for emulator only fastloders?
The fastloader itself works in the same way everywere. The problem is that the Pi1541 has different modes of operation. It can switch back and forth between the so-called "sd2iec" mode and 15x1 emulation mode. Such flow of operation can't be emulated in VICE as far as I know. That's why you need the device to test the modifications made to the browser.
I hope I answered your question.
EDIT - To clarify: the "sd2iec" mode makes the Pi1541 behave like a device of its own, that is, not stricly an emulator. |
| |
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 |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 - Next |
