| |
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 |
ofcourse, PRG loading should also be sped up by adding:
!if turbo25 = 1 {
lda extension_type ; get type of last image that was mounted
cmp #$0C ; D64?
beq goturbo
cmp #$1C ; D41?
beq goturbo
cmp #$2C ; LST?
beq goturbo
cmp #$30 ; T64?
beq goturbo
cmp #$00 ; PRG?
beq goturbo
jmp + ; We're in a different image type (D81 etc.)
goturbo:
; Backup the LOAD vector
lda $330
sta old_loadl
lda $331
sta old_loadh
jsr $140 ; activate turbo (this alters the LOAD vector)
+
}} |
| |
TSM
Registered: Jan 2007
Posts: 42 |
Quoting DeeKayTSM:
What happens when you add PRG to this list?
I think it should treat any PRG as an image (provided you are not inside some kind of image already, when you select them) and try to mount it. The outcome depends on Pi1541's firmware and the way it works.
This:
cmp #$00 ; PRG?
beq goturbo
Should be:
cmp #$34 ; PRG? (0 means no known extension)
beq goturbo
Let's try. Here's the "bad prg kludge" version:
https://drive.google.com/file/d/1vatoJJXi5yVRmgEF-CCkj4zs8XZjqj.. |
| |
TSM
Registered: Jan 2007
Posts: 42 |
Quote: TSM: I just found out that Pi1541 also supports Nibbler/GCR image files like .nbz, .g64 and .nib. I do wonder if it would be a good idea to add those to the "turbo" filetypes. Probably not, since those formats are used only for autobooting copy protected disks, so a speedloader will most likely not be needed and might even mess things up, huh?
I agree, let's not mess with those! |
| |
xahmol
Registered: Mar 2022
Posts: 2 |
With the badprgkludge.prg version, I can confirm that mounting .PRG files and fastloading them now works at my end. Thx! |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Dito here, this totally works as expected and isn't a "kludge" or "bad" at all, this is great, thanks once more! ;-) The only thing that COULD still be improved now is that it also automatically loads the first file when a PRG is selected, right now it goes into the temporary .d64 like with a .t64 and one needs to select the PRG again to load, but we know there's always only one file in a PRG temp d64, so that step is unnecessary... Do you see a way to do this?
I can also confirm that .lst and .t64 loading is sped up again now with the latest version! And that multi-file .t64s also work and load fast on all files in there (i used Xander's arkanoi1.t64 from Gamebase64, your multi-file t64s don't work out of the box on Pi1541 because of header intolerances, see bug report above, I will modify them accordingly so they do!) |
| |
TSM
Registered: Jan 2007
Posts: 42 |
If this works, it should automatically load the program when a dummy D64 is created from a PRG.
https://drive.google.com/file/d/16oe2mCkbt8AQYJM8fcuUA-fveCTEcR..
Fingers crossed! |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: If this works, it should automatically load the program when a dummy D64 is created from a PRG.
https://drive.google.com/file/d/16oe2mCkbt8AQYJM8fcuUA-fveCTEcR..
Fingers crossed!
Success! This works like a charm! Awesome!
However, by sheer chance, when trying out if t64 and d64 also still work, I found an incompatibility of FB64 that has apparently always been there, because at least Steve's original FB64 already has it: Try running our Krestage Demo from FB64, and see if the halfpixel scroller after the intro and the first load shows garbage!
Works fine with direct load, both ROM loading and with 25x Turbo installed, garbled text when started from any FB64 - what gives? Can anyone confirm this? This should even be reproduceable without Pi1541 in emulation! |
| |
TSM
Registered: Jan 2007
Posts: 42 |
Try this patched version of the demo:
https://drive.google.com/file/d/1Zm4d-XrextEvluKAA_cJEpLdpu3Zct..
The browser writes to the tape buffer but the demo expects it to be all 0's (or at least part of it). |
| |
TSM
Registered: Jan 2007
Posts: 42 |
New experimental throw-away version that doesn't try to fastload with (most) 3rd party kernals:
https://drive.google.com/file/d/1IIV4Ee-6ZNb5BxOC5uv6ctm1RtgYhZ..
"KC" stands for kernal check. Extensive modifications were done without testing, thus this is highly unlikely to work properly. Problems related to the presence of drives other than #8 remain. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
I for one cannot test with alternate kernels, since I was never into this sort of thing (Xander's the Jiffy man!). Just might be possible on U64 though...
I'll do the freezing thing with the zeropage values and the .lst files though! |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
