Long Filename Browser for ZX-UNO / esxDOS

[XoRRoX]

Fantastic. Thank you

[Chris23235]

New test version available here.

More size reduction as I've completed the refactoring of the FAT initialisation code to assembly (just one C function left to refactor in the FAT code now).
You can now overwrite an existing filename when you save a snapshot from the browser.

I did a brief test with the Omni and so far it looked good. I will check if it works with the eLeMeNt tomorrow and report back.

[Chris23235]

I did a brief test with the Omni and so far it looked good. I will check if it works with the eLeMeNt tomorrow and report back.

And now I tested it on the eLeMeNt, no problems either. Thanks for the update @bob_fossil . Overwriting a SNA is a nice feature that comes in handy when using SNA as savestates. Just curious, would it be possible to save in Z80 instead of SNA as this format is more compatible.

[bob_fossil]

And now I tested it on the eLeMeNt, no problems either. Thanks for the update @bob_fossil . Overwriting a SNA is a nice feature that comes in handy when using SNA as savestates. Just curious, would it be possible to save in Z80 instead of SNA as this format is more compatible.

It's possible but it's a lot of work just to end up with the same data (the Z80 registers saved when you entered the NMI by esxDOS and memory dump) that you'd get in a .sna file written out as a more complicated file format.

You'd be better off using a specific utility like snapconv to convert your .sna to .z80. Snapshot files for emulators can have lots of complexity like compressed blocks, additional fields for hardware, internal states and information that only an emulator can know like the machine model or if some special ROM or hardware device is attached. .sna files don't have this additional information which is why some emulators generate warnings when saving or loading them.

[Seven.FFF]

"More compatible" is a less than straightforward concept, and when you dig into it, kinda means "less compatible". The model field and the flags for which additional hardware is connected are great for emulators because they let the snapshot loader reconfigure the emulation to match the snapshot. On a real spectrum, the model and attached hardware is what it currently is, depending on what Spectrum user chose to plug the divMMC into, and what other hardware he also chose to plug in. There's no reconfiguration possible, and Bob's browser can't even really tell what to set for those fields, at least not without a lot of openended guesswork.

The one place where it might make sense is 128K snapshots. Most emulators assume 128K .SNAs are Pentagon 128 snapshots, as that's where the format was first used. So if you take a 128K .SNA made by Bob's browser on a real toastrack or grey +2, an emulator will try to load it as Pentagon 128, and it may well not work due to timing differences, etc. A toastrack or grey +2 .Z80 would play back as the correct model. Again, assuming Bob would be able to detect those models and distinguish them from +2A or +3, which has different timings. It's a bit of a minefield.

The Next NMI Menu switched from making .SNA snapshots to making .Z80 snapshots. That works very well because it's unambiguous how to query the model and internal hardware on a Next, and it's similarly able to reconfigure the internal hardware when loading a snapshot. Similar detections might be possible on other FPGA Spectrums like Uno, MB03+, Prism etc, but to expect a general purpose browser like Bob's to keep track of internal hardware knowledge for all those FPGA Spectrums is not feasible or fair, IMO.

[Chris23235]

Thank you @bob_fossil and @Seven.FFF for the explanation. This makes sense. I thought about the Next switching from SNA to Z80 for compability reasons, but didn't think about having the browser on real Spectrums is so much different.

[desUBIKado]

Hi @bob_fossil,

A few days ago, in the ZX-Uno Telegram group, mcleod_ideafix shared the LOADTAP command for esxDOS which is used to load .TAP files at normal speed. The operation is like LOADPZX, although only these keys are useful:

F7: PLAY/PAUSE of the virtual player.
F9: STOP of the player (PLAY start from the beginning).

And you need to use a Specrum core of mcleod_ideafix with .PZX file loading support.

The binary and source file can be found here: http://svn.zxuno.com/svn/zxuno/software/loadpzx/ (user:guest password: zxuno)

It would be interesting if you could incorporate it into your browser as an added functionality if you are using a ZX-Uno.

[Pegaz]

Hi @bob_fossil,

A few days ago, in the ZX-Uno Telegram group, mcleod_ideafix shared the LOADTAP command for esxDOS which is used to load .TAP files at normal speed. The operation is like LOADPZX, although only these keys are useful:

F7: PLAY/PAUSE of the virtual player.
F9: STOP of the player (PLAY start from the beginning).

And you need to use a Specrum core of mcleod_ideafix with .PZX file loading support.

The binary and source file can be found here: http://svn.zxuno.com/svn/zxuno/software/loadpzx/ (user:guest password: zxuno)

It would be interesting if you could incorporate it into your browser as an added functionality if you are using a ZX-Uno.

Just tried it, it works really well.
It would be great, if we could use this command through the LFN browser.

[Alessandro]

I do not understand what is the point of loading a tape image file at normal speed off a memory card-based interface

[bob_fossil]

I do not understand what is the point of loading a tape image file at normal speed off a memory card-based interface

Neither can I. If you want to load a .tap at normal speed you can convert it to a .pzx file and load it that way. The supplied source code for the PZX plugin could be taken as a basis to do this (it looks like it's copying different pulses to the ZX-UNO SRAM) but I'm not seeing how you'd use this from the browser? How would you specify you wanted slow loading for a file? The dot command also has an option to put pauses between blocks - again, how do you specify you want that when starting a file? I could add config options to do this but you'd have to run the plugin configuration everytime you want to change this. This just adds a load of complexity for a feature that most people won't use.

Let's just say, I'm not convinced at the moment.

[Pegaz]

I do not understand what is the point of loading a tape image file at normal speed off a memory card-based interface

Authentic retro filling...
pzx files are good for playing custom loading schemes, but there's no need to convert all the other tap files and duplicating the space with thousands of new files.

[desUBIKado]

Let's see, a utility would be to see the loading screen in those games in which it disappears as soon as the loading is finished. An example would be the game "The Way of the exploging fist". You could see the loading screen and once it has finished pressing F12 to set the core to 28 Mhz and speed up the loading.

If it is something complex to implement it might not be worth it. I just wanted to let you know about this new utility.

[Pegaz]

Additional "TAP loading speed" option in config screen (shift+c), with two parameters fast/normal, could be the solution if possible.
Fast speed would be the default, as it is now, and normal with new loadtap command would be used as needed.
Of course, if this requires too many changes in the essence of the browser, we shouldnt bother with it any further...

[bob_fossil]

New test version available here.

Final bit of size reduction in the FAT handling code as it's now all written in assembly. Seems to work on my FAT32 setup under emulation in Fuse and in FAT16 on my +2 - but there may be issues. Typically this would manifest itself as corrupted or empty directory listings. Consider yourself warned.

[bob_fossil]

I've updated the code in the previous link, so please re-download it. After releasing it yesterday I found two issues with the new FAT code which should now be fixed. I also managed to get the TAP plugin to support the new realtime tape loading mode for ZX-UNOs. For the moment, to enable it you need to do:

Code: Select all

.plugcfg tap

and then enable the options and save the configuration.

[Chris23235]

I've updated the code in the previous link, so please re-download it. After releasing it yesterday I found two issues with the new FAT code which should now be fixed. I also managed to get the TAP plugin to support the new realtime tape loading mode for ZX-UNOs. For the moment, to enable it you need to do:

Code: Select all

.plugcfg tap

and then enable the options and save the configuration.

I tested it on the Omni and the eLeMeNt as usual and this version works fine on both machines. Many thanks for your work @bob_fossil .

This version seems to be slightly faster or more snappy. But maybe this is just in my mind.

[desUBIKado]

I've updated the code in the previous link, so please re-download it. After releasing it yesterday I found two issues with the new FAT code which should now be fixed. I also managed to get the TAP plugin to support the new realtime tape loading mode for ZX-UNOs. For the moment, to enable it you need to do:

Code: Select all

.plugcfg tap

and then enable the options and save the configuration.

Realtime tape loading works fine on my zx-uno. Thanks.

[bob_fossil]

I tested it on the Omni and the eLeMeNt as usual and this version works fine on both machines. Many thanks for your work @bob_fossil .

This version seems to be slightly faster or more snappy. But maybe this is just in my mind.

The last bit of FAT code was the one that was doing the bulk of the work reading the disk to get the data used to populate the filename list and long file name buffer and the one I was least looking forward to refactoring. Now it's done, all the FAT code is in assembly so there's no switching between the compiler generated assembly and my assembly code which incurred a slight overhead. So I was hopeful it might seem a little faster. If you're running this on a ZX-UNO then it runs the FAT code at 28mhz so your overall speed gain may be negligible.

[Chris23235]

The last bit of FAT code was the one that was doing the bulk of the work reading the disk to get the data used to populate the filename list and long file name buffer and the one I was least looking forward to refactoring. Now it's done, all the FAT code is in assembly so there's no switching between the compiler generated assembly and my assembly code which incurred a slight overhead. So I was hopeful it might seem a little faster. If you're running this on a ZX-UNO then it runs the FAT code at 28mhz so your overall speed gain may be negligible.

Oh great, so it wasn't my imagination at last In fact I found the difference more noticable on the Omni than on the eLeMeNt, but I think here the higher clockspeeds are used by default too.

[jamesh]

Apologies, could not find the answer (did I miss it?), so I would like to clarify one thing about devices, partitions and "Auto detect device" control. It looks like "Auto detect device" must be "ON" if esxDOS is not on the first partition on the SD card. Is that expected behaviour? Boot screen shows device as "hd0", but LFN browser does not work without "Auto detect device" from a card with +3e partition(s).

[bob_fossil]

Apologies, could not find the answer (did I miss it?), so I would like to clarify one thing about devices, partitions and "Auto detect device" control. It looks like "Auto detect device" must be "ON" if esxDOS is not on the first partition on the SD card. Is that expected behaviour? Boot screen shows device as "hd0", but LFN browser does not work without "Auto detect device" from a card with +3e partition(s).

From the manual:

Most SD cards work with the browser 'Device number' set to 1. This is the default setting - however, some cards need this set to 0. If you get the black border and nothing happening problem, run the BRWSCFG .dot command, select the 'Advanced' category with cursor left / right and press ENTER to highlight the 'Device Number' option. Cursor up / down will change the value. Press ENTER again to set the new value and then press S to save the changes. If your disk has multiple partitions then you may need to set the device to a higher value.

From v0.16 and onwards, BRWSCFG has an 'Auto detect device' option in the 'Advanced' category. If you turn this option on, the browser will try and work out the device from the file system automatically. When this option is enabled it overrides the value specified in 'Device Number'. You need this option enabled if you want the browser to support disks with multiple drives e.g. 'GOTO hd1'.

So you can either carry on using 'Auto detect device' for your custom partition layout or you can manually set the device number and work out the number by trying the different allowable values.

I'm not sure how the device number relates to the partition names, HD0 could well end up being device 0 or 2, depending on how the disk is laid out.

[jamesh]

From the manual:

[...] If your disk has multiple partitions then you may need to set the device to a higher value.

Right, this is it. Thank you very much for showing the right direction. I got so distracted trying different card makes/brands, and completely overlooked that last sentence.

I'm not sure how the device number relates to the partition names, HD0 could well end up being device 0 or 2, depending on how the disk is laid out.

So, unless I have a very specific esxDOS setup, like, multiple VFAT partitions or two cards, and want to use the very specific one, "auto detect" seems to be the right way to go for a single VFAT partition "somewhere on the card". Did I get it right?

[bob_fossil]

"Auto detect" is the best option as it uses information from the esxDOS file system to get the correct device number. The other system where you manually set the device number is left behind code from the old version for people who have set up multiple partition devices before v0.16.

I should probably change the default settings to use "Auto detect" but here we are.

[Pegaz]

New test version available here.

Final bit of size reduction in the FAT handling code as it's now all written in assembly. Seems to work on my FAT32 setup under emulation in Fuse and in FAT16 on my +2 - but there may be issues. Typically this would manifest itself as corrupted or empty directory listings. Consider yourself warned.

Just to report, that with this latest test version I have issue with blank directory listings as you mentioned.
Tested on my ZX-Uno+ and 16Gb FAT32 microSD card.
Reverted to the previous test version 25-2 and everything went back to normal.

[Pegaz]

Maybe it's the cause of the problem, because I'm not using the whole 16Gb sd card, just a first 5 Gb FAT32 partition on it, for easier backup.
The rest is unallocated space.