Spectrum Computing

For anyone feeling brave, I've written a test version of the browser NMI.SYS which uses DivMMC memory paging to reduce the amount of data written to the SD-Card when you activate the NMI. It's still writing a file to the card in the /TMP/ folder but only a fraction of what it did before.

On my ZX-Uno with a particularly slow SD card which took around 14 seconds to get to the NMI, the time is down to a more speedy 2-3 seconds. I'd advise backing up the current NMI.SYS on your card and then copying over the newer version in case you encounter issues and need to restore the old browser NMI.

Please note that this assumes your DivMMC device has 128k of pageable memory. I've tested it with Fuse and my ZX-Uno.

Thanks again to [mention]velesoft[/mention] for pointing me in the right direction and helping me get the code straight.

You can download it from here.

And why need write to TMP if DivMMC memory is detected ? Standard NMI on Esxdos also use extra ram instead SD card for speed-up.

Big part of DivMMC ram memory is unused then we can use this 8kB ram pages for extended dot commands for example. None 8kB limits as before. But more easy is before dot command backup ZX ram to Divmmc pages and new long dot commands use as standard ZX program and command code may direct access to zx ram image in Divmmc 8kB pages. This enable new features.

velesoft wrote: ↑Thu Oct 01, 2020 5:27 pm And why need write to TMP if DivMMC memory is detected ? Standard NMI on Esxdos also use extra ram instead SD card for speed-up

If the extra DivMMC memory is paged into the same address space as the NMI (0x2000-0x3ffff) as soon as I try to page in the memory from the NMI, I page out my code in the NMI. To workaround this, I save 512 bytes of memory to disk and then relocate the code to copy the RAM to the DivMMC pages there. I then page the NMI back in and carry on the browser startup from there. When I quit the browser, I need to do the same again to restore the RAM from the DivMMC memory pages. I then restore the memory I overwrote for the relocater with the memory saved to disk.

The current esxDOS NMI writes the screen memory to the /TMP/ folder when you enter the NMI.

bob_fossil wrote: ↑Thu Oct 01, 2020 5:41 pm

velesoft wrote: ↑Thu Oct 01, 2020 5:27 pm And why need write to TMP if DivMMC memory is detected ? Standard NMI on Esxdos also use extra ram instead SD card for speed-up

If the extra DivMMC memory is paged into the same address space as the NMI (0x2000-0x3ffff) as soon as I try to page in the memory from the NMI, I page out my code in the NMI. To workaround this, I save 512 bytes of memory to disk and then relocate the code to copy the RAM to the DivMMC pages there. I then page the NMI back in and carry on the browser startup from there. When I quit the browser, I need to do the same again to restore the RAM from the DivMMC memory pages. I then restore the memory I overwrote for the relocater with the memory saved to disk.

The current esxDOS NMI writes the screen memory to the /TMP/ folder when you enter the NMI.

My idea is:
- after jump to NMI you can copy small part of zx ram direct to divmmc ram nmi page and copy own "CODE 1" from NMI page to zx ram.
- jump to CODE 1 in ZX ram for full backup of zx ram to unused(free) divmmc ram pages (also small ram part from previous copy CODE 1) and load your NMI code (browser) direct to ZX ram. This way don't need any saving to SD card. NMI only save zx ram from 16384 to 49151 (32kB) to DIVMMC memory. Then DIVMMC model with 128kB external ram will use 32kB for esxdos and next 32kB for zx screen with zx memory backup. And second 64kB of DIVMMC ram is free...
Or after first start of NMI preload all NMI code to free DIVMMC ram pages and may work also without SD card.

velesoft wrote: ↑Thu Oct 01, 2020 7:06 pm
My idea is:
- after jump to NMI you can copy small part of zx ram direct to divmmc ram nmi page and copy own "CODE 1" from NMI page to zx ram.
- jump to CODE 1 in ZX ram for full backup of zx ram to unused(free) divmmc ram pages (also small ram part from previous copy CODE 1) and load your NMI code (browser) direct to ZX ram. This way don't need any saving to SD card. NMI only save zx ram from 16384 to 49151 (32kB) to DIVMMC memory. Then DIVMMC model with 128kB external ram will use 32kB for esxdos and next 32kB for zx screen with zx memory backup. And second 64kB of DIVMMC ram is free...
Or after first start of NMI preload all NMI code to free DIVMMC ram pages and may work also without SD card.

Thanks for explaining this. I get a bit confused with the overlapping memory areas and paging. First option was easy to do. Browser NMI.SYS no longer writes any file to the card when you enter the NMI. I've also tidied up the code so the screen is left untouched when you enter the NMI - I was using screen memory for the relocator routine.

Updated version here.

Hello

Thank you so much for creating this. It is the only thing that was missing for us DivIDE/DivMMC users. Everything works great, the browsing is a breeze. There is only one "minor" think I would request, if/when time permits:
When browsing and the list starts to scroll it slows down a lot, because of font redraw. Would it be possible to add an option that instead of scrolling by one entry when you get to the end, it would jump to the beginning of the next page (or end of the previous page if you go up) ? It would speed up browsing a lot.

Hello,
I noticed that with the latest NMI browser version, snapshot saving does not work. It produces error 005 and the .SNA file is 0 bytes long.
Old version which uses tempoprary file works.

Thank you for otherwise excellent file browser.

tom-cat wrote: ↑Sat Oct 03, 2020 7:44 am Hello

Thank you so much for creating this. It is the only thing that was missing for us DivIDE/DivMMC users. Everything works great, the browsing is a breeze. There is only one "minor" think I would request, if/when time permits:
When browsing and the list starts to scroll it slows down a lot, because of font redraw. Would it be possible to add an option that instead of scrolling by one entry when you get to the end, it would jump to the beginning of the next page (or end of the previous page if you go up) ? It would speed up browsing a lot.

Thanks for the kind words. You can use cursor left and right to navigate by page.

bob_fossil wrote: ↑Sat Oct 03, 2020 11:31 am Thanks for the kind words. You can use cursor left and right to navigate by page.

Thats true It is good enough... thanx.

Has anyone tested this on DivMMC FUTURE ? Can't get it to work... just black screen when starting with NMI or with the dot command .browser.
Works fine on DivIDE (first version).

https://www.thefuturewas8bit.com/shop/s ... uture.html

arakar wrote: ↑Sat Oct 03, 2020 9:00 am Hello,
I noticed that with the latest NMI browser version, snapshot saving does not work. It produces error 005 and the .SNA file is 0 bytes long.
Old version which uses tempoprary file works.

Thank you for otherwise excellent file browser.

Yes, in all the excitement of throwing away the code that saves the contents of the RAM to a file when you enter the NMI browser, I'd forgotten that I used that file to build the snapshot later on.

I think I've fixed it now. You might want to give it some further testing. Thanks for the bug report.

Updated version here.

Hello,
everything is working fine now. I can save 48k and 128k snapshots just fine with the latest test version.
Just an observation: If I use an exsisting name for snapshot, it produces error 018, but deletes the existing file. For safety reasons, it might be better not to delete the file.
For reference, I am using ZX Spectrum 128k Toastrack with DivMMC Future with latest esxdos.

arakar wrote: ↑Sat Oct 03, 2020 7:41 pm Hello,
everything is working fine now. I can save 48k and 128k snapshots just fine with the latest test version.
Just an observation: If I use an exsisting name for snapshot, it produces error 018, but deletes the existing file. For safety reasons, it might be better not to delete the file.
For reference, I am using ZX Spectrum 128k Toastrack with DivMMC Future with latest esxdos.

The browser was always deleting the snapshot if an error occurred, e.g. if the file already existed. If you re-download the latest test .zip, it should be fixed.

Everything is perfect now.
Thanks for the effort!

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.

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

tom-cat wrote: ↑Mon Oct 05, 2020 11:06 am 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?

tom-cat wrote: ↑Mon Oct 05, 2020 11:29 am 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/

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.

tom-cat wrote: ↑Mon Oct 05, 2020 4:41 pm 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.

Luzie wrote: ↑Mon Oct 05, 2020 5:30 pm

tom-cat wrote: ↑Mon Oct 05, 2020 4:41 pm 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...

tom-cat wrote: ↑Mon Oct 05, 2020 5:48 pm 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.

tom-cat wrote: ↑Mon Oct 05, 2020 5:48 pm 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.

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.

tom-cat wrote: ↑Wed Oct 07, 2020 8:17 am 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.