The community forum for all Sinclair users
https://spectrumcomputing.co.uk/forums/
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 wrote: ↑Sat Oct 10, 2020 11:16 amYes, the browser uses 49152-65535 to store the 8.3 filenames and any associated long filenames.
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 wrote: ↑Sat Oct 10, 2020 4:16 pmThen 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 wrote: ↑Sat Oct 10, 2020 11:16 amYes, the browser uses 49152-65535 to store the 8.3 filenames and any associated long filenames.
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.bob_fossil wrote: ↑Sat Oct 10, 2020 5:43 pmNot 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?
Code: Select all
.bas
.lce
.pt2
.pt3
.pzx
.scr
.sna
.sqt
.stc
.tap
.trd
.z80
). This is in the 'No_MMC_Memory' folder. This doesn't support plugins but it will have any additional bug fixes or features that don't require MMC memory.Yes it should, so long as you've copied the BPLUGINS folder into the BIN folder. Plugins are loaded by the file extension so as long as you don't do anything silly like rename a .scr file to a .z80 it should work fine.keithshaw3 wrote: ↑Mon Nov 02, 2020 5:11 pm Hi,
Does the new test version load all the file types listed out of the box or are there some adjustments needed within the plugin config?
Keith.
I think I should dampen your hopes for .TZX-Support:keithshaw3 wrote: ↑Mon Nov 02, 2020 9:06 pm Works great thanks, any chance of adding .TZX support?
Keith.
lordcoxis:
Question: Will esxDOS have .TZX support? Is it a Next exclusive feature?
Answer: Yes, but only for standard data blocks using the ROM loader (just like ResiDOS). It's not a Next exclusive feature.
Oh, Thanks for the info, I didn't realise it wasn't a feature of esxDos, that's a bummer, guess I will just have to keep converting using an emulatorI think I should dampen your hopes for .TZX-Support:
From post (in 2017!) "esxDOS on ZX Next FAQ" on: http://board.esxdos.org/viewtopic.php?pid=279#p279lordcoxis:
Question: Will esxDOS have .TZX support? Is it a Next exclusive feature?
Answer: Yes, but only for standard data blocks using the ROM loader (just like ResiDOS). It's not a Next exclusive feature.
The only change from v0.11 to v0.12 in the NMI.SYS was the usage of divMMC memory bank paging to avoid writing the contents of the RAM to the temp folder. Why this would cause issues with the other NMI browser, I've no idea. You could try using the files from the 'No_MMC_memory' folder and see if they work correctly with it to confirm if this is the cause of the problem. Or just use my browser as your default - the problem should go away then.Luzie wrote: ↑Sun Nov 08, 2020 7:14 pm Dear Bob,
I discovered a bug which maybe introduced from Final Version v0.11 to Final Version v0.12 and later up to latest v0.13-Test2:
I load your "New File Browser for ZX-UNO" from within "Dr. Slumps NMI navigator v.0.0.17" http://board.esxdos.org/viewtopic.php?pid=1584#p1584 via Hotkey J
This works with \SYS\NMI.SYS from your "New File Browser for ZX-UNO" v0.11 Final (Size=444 Bytes) renamed and copied to \SYS\nmi\old088.sys
But it don´t work anymore with \SYS\NMI.SYS from your "New File Browser for ZX-UNO" v0.12 Final (Size=412 Bytes)
neither with \SYS\NMI.SYS from your "New File Browser for ZX-UNO" v0.13-Test2 Final (Size=411 Bytes)
Okay, so I created a new .hdf image with esxdos 0.8.8, the latest version of my NMI browser and v0.0.17 of Dr Slump's NMI browser. When I hit the NMI, I go into Dr Slump's NMI. I press J, the screen flips back to what it was before the NMI (with some extra code running in the screen) before my NMI browser appears. Seems to work fine here.Luzie wrote: ↑Sun Nov 08, 2020 7:14 pm Dear Bob,
I discovered a bug which maybe introduced from Final Version v0.11 to Final Version v0.12 and later up to latest v0.13-Test2:
I load your "New File Browser for ZX-UNO" from within "Dr. Slumps NMI navigator v.0.0.17" http://board.esxdos.org/viewtopic.php?pid=1584#p1584 via Hotkey J
This works with \SYS\NMI.SYS from your "New File Browser for ZX-UNO" v0.11 Final (Size=444 Bytes) renamed and copied to \SYS\nmi\old088.sys
But it don´t work anymore with \SYS\NMI.SYS from your "New File Browser for ZX-UNO" v0.12 Final (Size=412 Bytes)
neither with \SYS\NMI.SYS from your "New File Browser for ZX-UNO" v0.13-Test2 Final (Size=411 Bytes)
Code: Select all
/sys/nmi/old088.sys 441 bytes
Thanks! The SCL plugin will create the .trd filename from the 8.3 filename of the SCL file - I'm not adding long filename writing support.pjrodriguez wrote: ↑Mon Nov 09, 2020 6:15 pm Hi Bob,
Thank you for keeping on updating your file browser.
The .scl plugin is a very good idea and in my real Spectrum+3 it creates the .trd in only a few seconds. But the plugin fails to execute the .trd file after creating it (I get an error) and the .trd file has a 8.3 filename. Maybe the two issues are related. Not a big deal but maybe you can fix it.
The .trd file should be slightly larger than the original .scl file if it worked correctly (you should see some lines in the border while it writes the file). Do you have a link or could you make the .scl file available that you tried to convert so I can investigate further? Thanks.Maybe I´ve done something wrong here. Which Emulator/Interface-Settings do you use for testing?bob_fossil wrote: ↑Mon Nov 09, 2020 6:15 pm Okay, so I created a new .hdf image with esxdos 0.8.8, the latest version of my NMI browser and v0.0.17 of Dr Slump's NMI browser. When I hit the NMI, I go into Dr Slump's NMI. I press J, the screen flips back to what it was before the NMI (with some extra code running in the screen) before my NMI browser appears. Seems to work fine here.Code: Select all
/sys/nmi/old088.sys 441 bytes
I've had to switch over to Fuse. During development of the new browser features in v12 and later I found that SpecEmu didn't seem to emulate the divMMC's 128k of memory correctly (only the 32k needed for esxdos to run) which I'm now using for saving the RAM contents and plugins.Luzie wrote: ↑Mon Nov 09, 2020 6:25 pmMaybe I´ve done something wrong here. Which Emulator/Interface-Settings do you use for testing?bob_fossil wrote: ↑Mon Nov 09, 2020 6:15 pm Okay, so I created a new .hdf image with esxdos 0.8.8, the latest version of my NMI browser and v0.0.17 of Dr Slump's NMI browser. When I hit the NMI, I go into Dr Slump's NMI. I press J, the screen flips back to what it was before the NMI (with some extra code running in the screen) before my NMI browser appears. Seems to work fine here.Code: Select all
/sys/nmi/old088.sys 441 bytes
I´ve tried with SpecEmu (divMMC-Emulation only).
Maybe you could share your .HDF-File for comparison with my "compilation"? (Please send PM). Thank you!
OK. I not tried it with Fuse yet. This maybe the problem I discovered. Not yet tested "No_MMC_Memory"-Version. I´ll keep you informed.bob_fossil wrote: ↑Mon Nov 09, 2020 6:30 pm I've had to switch over to Fuse. During development of the new browser features in v12 and later I found that SpecEmu didn't seem to emulate the divMMC's 128k of memory correctly (only the 32k needed for esxdos to run) which I'm now using for saving the RAM contents and plugins.