| |
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!... |
|
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
why not use handheld 64 with 1541u ? you have this and much more. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Cause it doesn't have an IEC port.. yet... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11116 |
Chameleon then? |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Did you guys totally miss the part where I said I do *not* want a jiffydos or cartridge solution? 8) |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
A good filebrowser should go via the standard LOAD vector (ILOAD at $0330/1), i.e., not bring its own fastloader.
So... what happens if you install a fastloader, then run the filebrowser?
If the files are then fastloaded all right, it's mostly a matter of having a small booter file to load and install fastloader, then run filebrowser, no? :) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: Did you guys totally miss the part where I said I do *not* want a jiffydos or cartridge solution? 8)
why not ? there are simple solutions to your problem, but you really want a complicated one that doesnt even exist.
also pi64 is an 1541emulator I guess, now hacking that how will give you the c64 side loader ? |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: why not ? there are simple solutions to your problem, but you really want a complicated one that doesnt even exist.
also pi64 is an 1541emulator I guess, now hacking that how will give you the c64 side loader ?
hm. that would be the easiest - if it works and neither Pi1541 nor FB64 kill their respective parts of the fastloader.
I doubt it, but I shall try..
Since the Pi1541 FB64 has already been specially modded to work on Pi1541 i don't care all that much what best practice for a filebrowser would be.. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: why not ? there are simple solutions to your problem, but you really want a complicated one that doesnt even exist.
also pi64 is an 1541emulator I guess, now hacking that how will give you the c64 side loader ?
just wondering: What would mr. transwarp recommend as a small fast software fastloader that can load large onefilers? 8) I find it hard to believe that in light of superfast modern loaders a program from 1986 like 25x Turbo is still the best choice!.. |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Mafiosino Trackloader V2.1 is the current reference for that, perhaps. :)
(Small and fast do somewhat contradict, though.) |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: Mafiosino Trackloader V2.1 is the current reference for that, perhaps. :)
(Small and fast do somewhat contradict, though.)
Thanks, will try out that one as well with FB64.. How big is it and how fast? Loadable Mem range? I know it's somewhat of a contradiction, but 25x Turbo is VERY fast and very small, so seems to be possible! ;-) |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Quoting DeeKay25x Turbo is VERY fast and very small Well, if it fits your bill, why search further? :)
Remind me to add that standard-format fallback fastloader to Transwarp some day, as planned, could come out somewhere around 25-30x. =) |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: Quoting DeeKay25x Turbo is VERY fast and very small Well, if it fits your bill, why search further? :)
Remind me to add that standard-format fallback fastloader to Transwarp some day, as planned, could come out somewhere around 25-30x. =)
Well, I thought with the insane advances we've in the past decade regarding loaders, I thought that sth from 1986 would be just as outdated as, say, the sample playback from back in those days! 8)
Yes, please do add the fallback loader to transwarp! And please do make a small standalone version of it, too, without the transwarp parts! ;-D
Getting actual 25-30x would be super sweet, cause while it's pretty fast, the 25x/30x Turbo thing isn't actually THAT fast!.. |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Quoting DeeKayWell, I thought with the insane advances we've in the past decade regarding loaders, I thought that sth from 1986 would be just as outdated as, say, the sample playback from back in those days! 8) Nah, the actual advances aren't that much. :) While the SID thingies were entirely new inventions/discoveries, the drive stuff was more like incremental updates and combining all tricks in the book for once. Some new things, too, of course, but with modest overall impact.
Quoting DeeKayYes, please do add the fallback loader to transwarp! And please do make a small standalone version of it, too, without the transwarp parts! ;-D No such plans for the latter, actually. Why is "smallness" so important? Is it just a proxy for "quick boot-time" or do you really need the space (on disk)? Transwarp currently boots in 1.7-1.9 seconds, and that's for 32 blocks. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
For something that is loaded with ROM routines always on start before anything else, size matters a lot. If I need to wait 15 seconds until an 8kb loader loads, it kinda defeats the purpose of having a fastloader! ;-) |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Quoting DeeKayFor something that is loaded with ROM routines always on start before anything else, size matters a lot. If I need to wait 15 seconds until an 8kb loader loads, it kinda defeats the purpose of having a fastloader! ;-) As i said, those 8 KB load in under 2 seconds. There's a small boot-fastloader in the first 2 of those 32 blocks. =) |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Okay, I tried loading both MM and 25x Turbo before loading and running FB64. MM seems to deactivate itself after loading FB64, so there is no speedloader anymore, and with 25x active FB64 only reads and displays garbage. Seems it will have to be done the way I envisioned it: Installing the fast loader just before loading the chosen file... |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: Quoting DeeKayFor something that is loaded with ROM routines always on start before anything else, size matters a lot. If I need to wait 15 seconds until an 8kb loader loads, it kinda defeats the purpose of having a fastloader! ;-) As i said, those 8 KB load in under 2 seconds. There's a small boot-fastloader in the first 2 of those 32 blocks. =)
okay... but as long as there's no fallback loader for non-transwarp disks I cannot use it. Also, autostart files won't work in SD2IEC mode. I can set a .d64 as automount in the Pi1541 config though, which could help with autostart loader solutions... |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Quoting DeeKayautostart files won't work in SD2IEC mode. I can set a .d64 as automount in the Pi1541 config though, which could help with autostart loader solutions... Kinda confusing what in your setup is running with proper emulation and what with SD2IEC. If it cannot properly run ,8,1 autostart files, then maybe it can inject to RAM? In which case size doesn't matter, ofc. =) |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Pi1541 knows two modes: SD2IEC mode, in which you can change directories, create and mount new .d64s (simply via N:disk.d64!), rename and delete files and mount .d64s , .prgs, .t64s and .lst files - upon which it changes into cycle exact emulation mode, in which the only thing that's still different is the command "CD:<-" (Arrow left) to get out of emulation mode back into SD2IEC mode.. |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Quoting DeeKaywith 25x active FB64 only reads and displays garbage. Seems it will have to be done the way I envisioned it: Installing the fast loader just before loading the chosen file... Could also be there's a bug in FB64, or at least a necessity to make it behave nicely with pre-installed fastloaders.
So, for a test, what happens if you encode FB64 and some random payload .prg as Transwarp files on a .d64, then LOAD"FB64",8,1 then load the payload file from FB64? |
| |
TSM
Registered: Jan 2007
Posts: 42 |
Hello, here's my try at adding 25X fastload to the Pi1541's filebrowser:
https://easyupload.io/0sev8c
EDIT: never mind, it doesn't work. |
| |
TSM
Registered: Jan 2007
Posts: 42 |
Second attempt. If anyone is interested, please test and report back (I can't because I haven't got the hardware).
https://easyupload.io/bccdxh |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: Second attempt. If anyone is interested, please test and report back (I can't because I haven't got the hardware).
https://easyupload.io/bccdxh
OMG, I love you, this totally works just as expected! ;-)
I have tried loading single files, demos with their own loader, entering .d64s and leaving them again..
What is the difference between normal and reset25? Both seem to work identical from what I saw...
This is amazing, thank you so very much! Will spread this to Pi1541 owners and Steve White ASAP!
How hard would it be for you to add an extra key command for new disk, just enter a name and then do a N:$name dos command? |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Give them an inch... =) |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: Give them an inch... =)
Well, that *was* in the original posting already! ;-D
It just seems logical, since you can enter the d64 name via FB64 so easily.. |
| |
TSM
Registered: Jan 2007
Posts: 42 |
Very well! Can you take a look at this new, hopefully much better version?
https://drive.google.com/file/d/1EFW8ZacmACwtrgQf043UlefwoQaSt4..
This version should not activate turbo mode in images other than D64 and D71, and it should restore kernal routines when done loading.
"Reset25" has to do with the algorithm's logic. Location $25 must be 0 when you launch a program, otherwise it's treated as a tape image. It probably is set to 0 in the part that I can't test, that is, when you "enter" a disk image.
Regarding your other request, we'll see but don't hold your breath :-D |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: Very well! Can you take a look at this new, hopefully much better version?
https://drive.google.com/file/d/1EFW8ZacmACwtrgQf043UlefwoQaSt4..
This version should not activate turbo mode in images other than D64 and D71, and it should restore kernal routines when done loading.
"Reset25" has to do with the algorithm's logic. Location $25 must be 0 when you launch a program, otherwise it's treated as a tape image. It probably is set to 0 in the part that I can't test, that is, when you "enter" a disk image.
Regarding your other request, we'll see but don't hold your breath :-D
Do ignore .d71, Pi1541 cannot handle these images. only .d64, .d81, .prg, .t64 and .lst (mount lists)
Testing the old version:
Stuff from both .d64 and .t64 loads fast in both versions, both in normal and reset25 versions.
PRG loads slow in both.
I cannot tell *any* difference between the two! Any suggestion on what to try?
Todo: .lst files
Testing the new version now.. Together with Xander! ;-) What's the difference between turbo and turbox? |
| |
TSM
Registered: Jan 2007
Posts: 42 |
Turbox is compressed with Exomizer, otherwise it's exactly the same. The new version is based on the source files while the old one was an hack.
You may want to take a look at the thread that I started on the Lemon64 forum, someone has found a number of flaws.
If you have a freezer cartridge, you could check location $25 just after entering a D64 image. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Okay.. Did read the thread on Lemon. The issues with extra drives are to be expected, quite sure 25x Turbo cannot handle multiple drives, since back in 1986 there was no STFU yet to shut up the other drives.. implementing a STFU routine could solve these issues. As for alternate DOSes: Maybe there's a simple detection to see if non-stock stuff is running on the drive, in which case you don't install the Turbo? Krill?
May I ask what sources you based the new version on? Cause from what I understand Stephen modded FB64 for Pi1541.. Did he also put those modded sources on Github?
As said, .d71 cannot be mounted on Pi1541. The much more widespread .t64 (Gamebase64!) however does mount - and the turbo worked for this in your original hack, so don't kill that..
As for PRG files Steve's FB64 behaves wrongly. when using the Pi display and buttons PRGs get mounted in a temp .d64 just like .t64s do (which means they should also load fast! I just tried it by mounting a PRG manually and loading it with 25x Turbo, it works!), but FB64 loads PRGs directly in SD2IEC mode, i.e. sloooow.. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
TSM, can you make FB64 treat PRGs just like .d64s, mounting them etc? Quite sure that's what the button/OLED does when you select a PRG...
As for the T64s, it is quite possible that the T64s I've tried this with came from a Gamebase64 collection that was tailored for SD2IEC use (I got them from the guy that built my Handheld). I find that I cannot mount other T64s from CSDb on Pi1541. My hunch is that the GB64 ones are just renamed PRGs, but I will analyze them... |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
I played around with the new turbox version from yesterday. as expected, it does not mount and load fast on the GB64 T64s anymore but stays and loads in SD2IEC mode.
I did analyze the GB64 T64s, and they're not just renamed PRGs, they do have a 32 byte T64 header: "C64 tape image file". But when I transplant that header into a t64 that does not work, it does mount, but it's shown as empty. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
I got the CSDb t64 (Einstein IV ) to mount (and load fast on the old FB64 mod!) on Pi1541 by replacing the first 32 byte header with the one above AND changing the filetype at offset $41 from $c2 to $82...
I'll message Steve that Pi1541 t64 handling needs to be adjusted to scan for the strings "C64" and "tape" in the first 32 bytes and also to mask out the high nybble for the filetype...
one thing that might be an issue, also with .lst files, is fb64's inability to handle filenames longer than 12 characters.
i had to rename the hacked file because both files showed as einstein_iv_.t64 in FB64 and no matter which one I chose it would always only load the first one (which was the original).
Does anyone have multi-file .t64s for me to test? All the ones I've found are single files!.. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
I opened an issue about T64 file handling on Github:
https://github.com/pi1541/Pi1541/issues/239 |
| |
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)! ;-) |
| |
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? |
| |
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. |
| |
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!)... |
| |
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 |
| |
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. |
| |
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? |
| |
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! |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: 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.
Huh, interesting! So Crossbow fucked this up by not doing a proper init? I'll be sure to tell him next time we talk! ;-)
(Edit: Ooops, replied to the wrong post, sorry!) |
| |
xahmol
Registered: Mar 2022
Posts: 2 |
Unfortunately for some reason my Pi1541 went broken. Expect my RPi 3B is the culprit, but nowhere a new one to buy can be found,
So can not test anymore on this for now.
But I indeed was testing with an Ultimate 64 exactly because it is so easy to swap kernels and drive IDs on that machine, |
| |
hedning
Registered: Mar 2009
Posts: 4596 |
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 |
| |
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! |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Thanks, yeah, I'm very proud of it and I love it! ;-D
Just did some stopwatch speed measurements on it btw, I'm seeing exactly a 7.5x speed gain on the Pi1541 (88.5 sec for 202 Blocks of One-Der on stock, 11.8 sec with Turbo), giving us 17.1 blocks or about 4.4kb a second.
The Retro Replay loader takes about 9.5 seconds, yielding a 9.3x speedup... |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Okay, after finding much higher times for 202 blocks on stock online I figured that loading the PRG in SD2IEC mode was probably not the best idea.
So I measured again without FB64 and One-der PRG mounted and got 10.4s for 25x Turbo (slightly faster, cause the loader does not need to be installed first) and 130.8s for stock. This gives us a 12.6x speedup (19.4 blocks/s or 4.9kb/s) for 25x Turbo (or 11x from FB64 with loader installation first.. and 13.8x for Retro Replay!).. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
I did check cbmcommand btw before, and it would not start with Pi1541.. |
| |
TSM
Registered: Jan 2007
Posts: 42 |
https://drive.google.com/file/d/16ZNsnioPYG6AhkL6QoYB7M3apkN6D5..
Added a compile-time (assemble-time?) option to show "**** COMMODORE 64 BASIC V2 ****" etc. after the loading process.
@DeeKay and anyone interested: please test! |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Will test ASAP, thanks so much! ;-) I requested this btw, because all BASIC faders don't really work with a blank screen.. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
I tested it with both Wonderland 11 and our Deus Ex Machina BASIC Fader, and it works like a charm! Also ran the whole palette of fast loading filetypes just to be sure nothing broke along the way, still works! Great! I think we can release it now, will do over the weekend if that's ok with you.. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
I shall be testing the max loadable filesize just to be sure.. it's probably the stock 202 blocks, but someone claimed it loads up to $e000 (which it definately doesn't!) so I shall try out 203 blocks and more! ;-) |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
okay, i tested, 25x Turbo loads the standard mem range only max without the VIC area, i.e. 202 blocks max (from $0801) or up to $cfff.. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
There ya go: https://csdb.dk/release/?id=223021&show=summary#summary |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
I finally managed to clock Mafiosino fastloader 2.1 btw, I'm seeing an 18.2x speedup (28 blocks/s or 7.1 kb/s) on One-Der, really good.. But then again it's almost 3x the size of 25x Turbo..
On a sidenote, for all Pi1541 owners here, I also went back to Pi1541 kernel v1.23 btw (from v1.24) on Matthias' (Uni64 guy) recommendation, The F20 Lethargy demo works perfectly with that (crashes on v1.24) and it's supposed to be the most bugfree version..
Deus Ex Machina diskchange still doesn't work though.. Quite possible that we,did the same there as in Krestology and used the write protect light barrier to start reading and that Pi1541 does not emulate this, will check with Krestology.. |
| |
TSM
Registered: Jan 2007
Posts: 42 |
Quoting DeeKayTSM: 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?
I made some tests in VICE but couldn't reproduce the problem. The demo always restarts correctly. I put the browser on the disk and used it to launch the demo (a couple of memory locations need to be altered since it's not a Pi1541).
Does it crash as well if you use the physical buttons to mount the image? |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: Quoting DeeKayTSM: 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?
I made some tests in VICE but couldn't reproduce the problem. The demo always restarts correctly. I put the browser on the disk and used it to launch the demo (a couple of memory locations need to be altered since it's not a Pi1541).
Does it crash as well if you use the physical buttons to mount the image?
Yes, as said ("sidenote" ;-) these are all Pi1541 issues and have nothing to do with FB64 Turbo, no worries!
I meanwhile checked Krestology, and that works (I know we did the lightswitch thing there cause I came up with the idea, not sure about Deus, on which Graham did all the linking and loader stuff!), so it's probably not that...
P.S.: It doesn't crash, it just doesn't register the diskchange! |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
TSM: Can you post the link in the Lemon64 forum, too? Just so people know that it's been finalized/released!... |
| |
TSM
Registered: Jan 2007
Posts: 42 |
Quote: TSM: Can you post the link in the Lemon64 forum, too? Just so people know that it's been finalized/released!...
Done! |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: Done!
Tjenks! |
| |
Tom-Cat
Registered: Apr 2003
Posts: 20 |
Deus ex machina disk change doesn't work when using JiffyDos ... |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: Deus ex machina disk change doesn't work when using JiffyDos ...
It does not work when using Pi1541, period! ;-) No matter what DOS you use!... |
