[CSDb] - User Forums - Small Filebrowser with fastloader for Pi1541

You are not logged in - nap

CSDb User Forums

Forums > CSDb Discussions > Small Filebrowser with fastloader for Pi1541

2022-08-13 16:13

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....

2022-08-21 11:17

DeeKay

Registered: Nov 2002
Posts: 362

I opened an issue about T64 file handling on Github:
https://github.com/pi1541/Pi1541/issues/239

2022-08-21 15:14

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)! ;-)

2022-08-21 16:04

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?

2022-08-22 01:46

TSM

Registered: Jan 2007
Posts: 42

New version:

https://drive.google.com/file/d/1iD1BMPQEj6OaIhBtzcXuzCTcXPO03a..

This time I have included the source files. I'm using the Pi1541 specific version taken from GitHub. The only difference is the list of extensions that will cause the fastload to activate:
- D64
- D41
- LST
- T64

LST files may pose a problem, though. An LST containing D81 images should not cause the fastload to kick in, for instance. So I'd like you to test just that (you should be able to load files correctly, although in slow mode, and to swap disks). If anything goes wrong, here's what I'd like you to do (*if* you feel like it, of course):

- Browse into a swaplist (LST) containing D81 files
- Freeze the C64 and check the values in locations $02, $25 and $28
- Browse into a D81 image
- Freeze the C64 and check the values in locations $02, $25 and $28

I'd also like you to see what happens with LST files containing D64 images. Of course you should be able to load programs in fast mode and swap disks.

And while we're at it... I wonder what happens with T64 files. Is everything that's inside the tape image copied to a temporary D64, or just the first entry? In the former case, what happens when they don't fit?

Thank you for checking the behavior of location $25. The results show that I have no need to fiddle with it.

Regarding loose PRG files to be converted to D64 on the fly, the task is most certainly not possible on my end, but should be handled by the Pi1541's firmware. Besides, I wouldn't want to go there anyway. Sometimes, loose PRG files need to access other files from the same directory. So one should shove all files residing on the same directory into the virtual disk image or, short of doing that, risk the program crashing sooner or later. The SD card that I use with my SD2IEC contains many games that are just a directory with all the game files. Sometimes there is the hi-score file as well and it would never be saved. Just saying; no problem if you still want it :D

About the crashes that happen with 3rd party kernals and multiple devices on the bus, I will perform some tests but I totally lack the experience needed to fix them. I'll try to embed a more robust fastloader; failing that, I'll leave it as it is.

2022-08-22 10:11

DeeKay

Registered: Nov 2002
Posts: 362

I cannot tell you what happens with multi-file T64s, because I need to find one first in order to try it! ;-)

As for PRGs: This "create temporary d64" approach is already built into Pi1541, for both T64 and PRG. But it only happens for PRG when you select one via the OLED, *not* when using FB64! So FB64 would have to be changed first to treat PRG files just like d64s (or t64s), i'm assuming it's just simply sending a mount command for the file and then the Pi1541 FW does its magic...

Without speedloader, it does not matter if FB64 loads PRGs in SD2IEC or in cycle exact mode, because it takes the same time, that's why Stephen probably chose the direct load approach for FB64. But with a Turbo, it very well matters! ;-)

Multi drive support and alternate kernals would be nice, but for my use case I don't need it. If I should ever add an IEC port to my handheld, then that will be used with an Ultimate cartridge anyway in 98% of all useage scenarios, and with that I'll use the cartridge speedloader anyhow (or the new built in FB64 in Retro Replay 3.99, as Count Zero has just informed me!)...

2022-08-22 11:38

DeeKay

Registered: Nov 2002
Posts: 362

TSM:
What happens when you add PRG to this list?

extensions
!tx "dnp",0 ; this extension must be the first for submenu logic of this file image
!if tap_support = 1 {
!tx "tap",0 ; this extension must be the second for submenu logic of this file image
}
!tx "d64",0
!tx "d71",0
!tx "d81",0
!tx "m2i",0
!tx "d41",0
;!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!
; Pi1541 Changes
;!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!
!tx "g64",0
!tx "nib",0
!tx "nbz",0
!tx "lst",0
!tx "t64",0
!tx "prg",0
;!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!
extensions_max = * - extensions

2022-08-22 11:41

TSM

Registered: Jan 2007
Posts: 42

A couple T64s for testing:

https://drive.google.com/file/d/1nYDrm1rDA96bGLOxj4_PUrlLyC92dW..

If you're on Windows, you can easily make them with "Dirmaster".

Have you tried renaming a .PRG to .D64 and then selecting it? I don't expect much, but it's worth a try.

2022-08-22 11:47

DeeKay

Registered: Nov 2002
Posts: 362

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?

2022-08-22 11:55

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)
+
}}

2022-08-22 12:25

TSM

Registered: Jan 2007
Posts: 42

Quoting DeeKay

TSM:
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..

Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 - Next

Refresh

Subscribe to this thread: