Long Filename Browser for ZX-UNO / esxDOS

[tom-cat]

Ok, I found a VERY OLD 32MB SD card... formatted this one to FAT16 and IT WORKS !!!
I have tried two 16Gb SD cards and it doesnt work with either fat or fat32... so it is solved.
Didnt know there is a size limit Well it doesnt work with 2Gb Sandisk Extreme either...

[Luzie]

If anyone can help.
I have a divMMC FUTURE which was working perfectly fine with everything. I just cannot get this Browser to work on it at all. I have tried everything.
Different esxdos versions up to 0.8.8 latest version. Different ZX Spectrums (+, normal rubber, 128k), different formats FAT16 and FAT32, different versions of browser you have posted. Everything works fine with the old divIDE interface and CF card there.
If I start it with dot command .browse I get the yellow line on top, status line with browser version on the bottom for a fraction of a second and then immediately just 0 OK 0:1 message and thats it.
If I srtart if with NMI I get a crash, black border, the file in TMP is created and then reset.
If anyone can help, please. No idea what to try anymore.

Send me a PM and I may send ypu a ZIP-File containing "esxDOS and New File Browser for ZX-Uno" for you to test.

Have you already tried reformatting SD-Card and copying all files to a freshly formatted Card?

[Luzie]

Ok, I found a VERY OLD 32MB SD card... formatted this one to FAT16 and IT WORKS !!!
I have tried two 16Gb SD cards and it doesnt work with either fat or fat32... so it is solved.
Didnt know there is a size limit Well it doesnt work with 2Gb Sandisk Extreme either...

1 GB to 64 GB Cards shouldn´t cause a problem. But always re-format them completely using this: https://www.sdcard.org/downloads/formatter/

[tom-cat]

I just tried formatting them with the mentioned formatter and the result is the same. Goes back to basic as soon as you start the browser.
I wonder if it has something to do with the speed of the cards? I have found an older 1GB SD card in the back of the closet (literally) and this one is also working fine as FAT16 and FAT32 formatted card. I can use this one, it is big enough, so no problems, and it is pretty fast too, even the NMI version that writes to TMP starts in less than 1s. But it still puzzles me why the 16gb ones and the 2gb one don't work at all.

[Luzie]

I just tried formatting them with the mentioned formatter and the result is the same. Goes back to basic as soon as you start the browser.
I wonder if it has something to do with the speed of the cards? I have found an older 1GB SD card in the back of the closet (literally) and this one is also working fine as FAT16 and FAT32 formatted card. I can use this one, it is big enough, so no problems, and it is pretty fast too, even the NMI version that writes to TMP starts in less than 1s. But it still puzzles me why the 16gb ones and the 2gb one don't work at all.

I´m pretty sure it the write-speed of those cards or simply a hardware-incompatibility. I too have 16GB cards (No-name) which don´t work with my divMMC-devices while others work.

[tom-cat]

I just tried formatting them with the mentioned formatter and the result is the same. Goes back to basic as soon as you start the browser.
I wonder if it has something to do with the speed of the cards? I have found an older 1GB SD card in the back of the closet (literally) and this one is also working fine as FAT16 and FAT32 formatted card. I can use this one, it is big enough, so no problems, and it is pretty fast too, even the NMI version that writes to TMP starts in less than 1s. But it still puzzles me why the 16gb ones and the 2gb one don't work at all.

I´m pretty sure it the write-speed of those cards or simply a hardware-incompatibility. I too have 16GB cards (No-name) which don´t work with my divMMC-devices while others work.

The problem is that everything else with divMMC works fine.. the original NMI browser, everything else works with them...

[Luzie]

The problem is that everything else with divMMC works fine.. the original NMI browser, everything else works with them...

If the problem persists, you maybe could create an image from the SD-Card and give it to us for cross-testing.

[bob_fossil]

The problem is that everything else with divMMC works fine.. the original NMI browser, everything else works with them...

The original NMI browser isn't doing sector level reading of the SD card to try and work out the long filenames from the FAT filesystem. I have 5 SD cards to test with here: a no brand 256mb, 512mb Sandisk, 1gb Samsung, 2gb Sandisk and a 4gb no brand. As far as I'm aware, they all work with FAT16 and FAT32. If you can upload a zipped .hdf image of the SD card somewhere, I can try and investigate.

[tom-cat]

Thank you bob_fossil ! As you found out it was the device number problem. It was set to #001 when it should of been #000 for these SD Cards. Working perfectly fine with all my SD cards now.

[bob_fossil]

Thank you bob_fossil ! As you found out it was the device number problem. It was set to #001 when it should of been #000 for these SD Cards. Working perfectly fine with all my SD cards now.

No problem! Thanks for supplying a .hdf file to let me debug the issue. In the upcoming release for v0.12, I've added this scenario to the 'Questions' section of the manual in case anyone else encounters it.

[bob_fossil]

v0.12

• NMI.SYS now uses DivMMC memory pages. This removes the need to save the contents of the memory to the TMP folder whih should remove the speed bottleneck / delay on certain brands of SD-Card when entering the NMI. Thanks to [mention]velesoft[/mention] for providing information and advice on utilising the additional memory in the DivMMC. 'No NMI write (Slow SD Cards)' option in BRWSCFG is now deprecated.
• .browse dot command now uses DivMMC memory pages to save / restore the memory.
• Fullscreen browser now supports screen preview for v2/3 .z80 files (NMI only).
• Fullscreen browser now shows 'DIR' text for directories.
• If you saved a snapshot with the same name as an existing one, the operation would generate an error but the existing file was deleted.
• Fixed redrawing issue when deleting some characters in the text input field.

Download here.

[tom-cat]

v0.12

• NMI.SYS now uses DivMMC memory pages. This removes the need to save the contents of the memory to the TMP folder whih should remove the speed bottleneck / delay on certain brands of SD-Card when entering the NMI. Thanks to [mention]velesoft[/mention] for providing information and advice on utilising the additional memory in the DivMMC. 'No NMI write (Slow SD Cards)' option in BRWSCFG is now deprecated.

Unfortunetly this breaks compatibility with the original DivIDE interface. The Browser does not run there anymore. Version 0.11 works flawlessly though. Would be good if it would be possible to check for 128k of memory and use it only when available? If not, please make version 0.11 available somewhere for DivIDE users who don't have 128k of ram.

[arakar]

Hello,
the link still points to version 0.11

[Luzie]

Hello,
the link still points to version 0.11

When I download, I get 0.12

So I put here 0.11 for download: https://forum.tlienhard.com/phpBB3/down ... p?id=10879

[arakar]

Interesting, it seems there is a cache problem. When using Edge for download, I get the old file, when using Firefox, I get the new file.

[bob_fossil]

As previously mentioned, whenever I do a new release the previous BROWSE_latest.zip is renamed to it's version number. So you can download v11 from here.

[velesoft]

What about .SCR files ? Is possible show picture from browser ? One idea: add possibility show .LCE files with length 13824 bytes (2*6912) in interlace mode

[velesoft]

What about size of used Divmmc memory ? Any free 8kB ram pages ?

[bob_fossil]

What about .SCR files ? Is possible show picture from browser ? One idea: add possibility show .LCE files with length 13824 bytes (2*6912) in interlace mode

You should be able to view .SCR files with the current version.

I am thinking of adding a plugin system which executes a binary file based on the file extension. So for FOOBAR.SCR or FOOBAR.LCE you'd have a SCR file or a LCE file which would get loaded by the browser to handle the file type. This would do whatever is needed for the file and then return back to the browser.

[bob_fossil]

What about size of used Divmmc memory ? Any free 8kB ram pages ?

As I understand it, esxdos uses pages 0-4. so the browser NMI uses pages 5-10 to store the 48k of RAM. The .browse dot command uses pages 5-8 to store the memory from 32768 onwards which gets overwritten by the browser.

[velesoft]

Browser use also zx ram 49152-65535 ? Here may be on zx 128 any zx ram page and locked paging. For example if you in basic write CLEAR 49151: OUT 32765, 50 (OR VALUE 53) then at 49152 is mirrored zx ram page 2 or 5 with disabled paging.

[bob_fossil]

Browser use also zx ram 49152-65535 ? Here may be on zx 128 any zx ram page and locked paging. For example if you in basic write CLEAR 49151: OUT 32765, 50 (OR VALUE 53) then at 49152 is mirrored zx ram page 2 or 5 with disabled paging.

Yes, the browser uses 49152-65535 to store the 8.3 filenames and any associated long filenames.

[velesoft]

Yes, the browser uses 49152-65535 to store the 8.3 filenames and any associated long filenames.

Then you may need small memory test before start browser - if is in area 49152-65535 set ram page 2 or 5 and memory paging is locked then memory is unusable = disable NMI or show message "computer need reset..." etc...

[bob_fossil]

Yes, the browser uses 49152-65535 to store the 8.3 filenames and any associated long filenames.

Then you may need small memory test before start browser - if is in area 49152-65535 set ram page 2 or 5 and memory paging is locked then memory is unusable = disable NMI or show message "computer need reset..." etc...

Not sure I understand the issue. The NMI copies 16384 - 65535 to the divMMC banks and restores this back on exit. Why wouldn't 49152 - 65535 get restored by this operation? If the 128 paging is locked, can't I still copy 49152-65535 to somewhere else (divMMC memory) and then restore it?

[velesoft]

Then you may need small memory test before start browser - if is in area 49152-65535 set ram page 2 or 5 and memory paging is locked then memory is unusable = disable NMI or show message "computer need reset..." etc...

Not sure I understand the issue. The NMI copies 16384 - 65535 to the divMMC banks and restores this back on exit. Why wouldn't 49152 - 65535 get restored by this operation? If the 128 paging is locked, can't I still copy 49152-65535 to somewhere else (divMMC memory) and then restore it?

If you set on zx128 ram page 2 from 49152 then area 32768-49151 is mirrored with area 49152-65535. Then if you write byte 255 to address 32768 then will be visible also on 49152.
And zx ram page 5 is mirrored with zx videoram area 16384-32767