maybe you could think over adding a .DOT-command for loading created on original Betadisk 48 / Betadisk 128 Interface with the "MagicButton"? Those Snahsot are loaded from TR-DOS with

GOTO "Snapname" Code

Here a have a .TRD-Disk with a Snapshot of the Game "Bounty Bob strikes back", booting OK on TR-DOS v4 and TR-DOS v5, but not on divIDE with esxDOS this .TRD-Image mounted with esxDOS .vdisk Virtual Disk:

TRD-Fiie: https://spectrumcomputing.co.uk/forums/ … hp?id=2270

Topic discussed here: https://spectrumcomputing.co.uk/forums/ … 55#p179555

Thanks in advance

I need it under NextBASIC, and there´s no BASIC built-in command for doing this query from NextBASIC yet.

Thank you!

After listing a catalog with .ls and press of a key the screen get completely cleared.

If a file with a complicated filename e.g. WC4H2QX.TXT is listed we need to remember complete filename in our brain to type a following command like .ERASE WC4H2QX.TXT

Could the CLS from .ls please removed?

One of features is simplified switching between disk drives with commands *A instead original *"A:". It is not something which can have any influence on software compatibility, because this command is not normally used in any BASIC programs (i mean - in BASIC program will be used original compatible syntax). But it is very convenient for users during work in TRDOS command line.

Can you please modify TRDOS bundled with ESXDOS and add this little but useful feature?

Thank you very much.

Small sample files for testing would be really appreciated!
Why not distribute it with the OS?

Thanks

Complete "rewinding to start" may be reached by detaching and again attaching the .TAP-File. But something like ".rewind" may be helpful? (Even if the desired "Tape-Blocks" can be named "1", "2" and so on, so we just can do an "LOAD "2"" to load the correct one).

Or maybe a way to "Auto-Rewind" to start of .TAP-File if the of .TAP-file end is reached? ... Haven't tried this yet, maybe this feature is already present in esxDOS.

I've been wondering what would be needed to be able to distribute physical copies of homebrew games made for ESXDOS, and I found there are two main problems:

1) ESXDOS version segmentation.
2) License

First problem makes people unable to create a bootable SD card, that you can just insert in your DivMMc and get it working out of the box, as you don't know which version of the files at SYS and BIN folders to add. I honestly don't know the reason behind that, but I wonder if there may be a set of SYS files that can be "wildcard sys files", so ESXDOS accepts them as valid, always. Otherwise, there may be an option to have some AUTOEXEC.BIN file in SYS folder, that if present, is loaded as ESXDOS.BIN temporarily (not flashed), in which case authors will just to make sure the usual ESXDOS.BIN file is bundle with the SYS and BIN foldes in the SD card, and just rename it AUTOEXEC.BIN

Second problem is that as far as I have found, it's unclear if ESXDOS can be bundled with a game.

Of course I understand first problem will persist even if a new version supporting some of the features I suggested is created, casue that would not change the current segmentation, but in the long term it may be a solution.

first let me say that esxDOS is great!

I switched over to it from FatWare because it allows to actually delete files, without me having to use a separate system to do that. And this function is so valuable to let forget about the fact that esxDOS does not support long filenames yet.

However, do delete a file is still a bit of a hassle nonetheless, you have to switch over to basic and type in the erase command.

Wouldn't it be great if you could just delete files straight away from the filebrowser?

You know, I just like to watch the demos, but want to easily get rid of stuff that doesn't work.

Regards

F Invalid file name

exception and catching it. CLOSE # is a bit trickier, as the original 48k ROM is buggy. So you can do what +D and DISCIPLE did with CLOSE #* (I'd suggest CLOSE ## instead not to confuse wiht * being the current drive in esxDOS), but just to be nice with projects like ZX85, you can also catch a

J Invalid I/O device

exception from CLOSE # so that fixed ROMs can use the regular syntax.

If you give me access to esxDOS sources, I can code it up for you. For free. I'd really hate wasting time reverse-engineering esxDOS and binary-patching it.

The purpose of this is for software to be able to get the list of sectors that a file uses by seeking it on 512 byte steps. That list of sectors can therefore be used to perform low level access to the actual device bypassing ESXDOS and allowing real time audio or video playing without the need for the file to be unfragmented and without the need for such program to reimplement a file system just for this.

It also opens the posibility of new hardware devices to be designed so they receive a list of sector addresses obtained this way and the hardware itself is in charge of performing read operations to the device independent of the CPU (so a TZX file player could read TZX/PZX files stored in the same card DivMMC uses instead of using a different SD card, and file selection could be made possible using ESXDOS itself, much like the current implementation of PZX file player on ZX-UNO)

10 LET T$="RockOn.TAP"
20 .TAPEIN T$

However this gets me a "No such FILE or DIR, 20:1" message

Modifying to try semicolon trick from the "Topic: String variable in save*/load* commands" thread leave the BASIC as:
10 LET T$="RockOn.TAP"
20 .TAPEIN ;T$

This gets the error of "Invalid FILENAME, 20:1"

I guess at this point I have a few questions:

1) Is there a proper/generic way to pass variables to dotcommands or is it something that is handled at the dotcommand implimentation / source level?
2) If it's option 2 above, is there some reference docs so I can look at writing my own .TAPEIN inside of my own RAM based app (not a dotcommand, ideally with z88dk)

-Thanks in Advance
Dx