- after setting everything correctly according to guide:

1) ESXDOS screen appears
2) "Detecting devices..." - this lasts quite a moment, like 10 secs or sth
3) "Mounting drives..." - this comes up next, with no info about mounted drives or anything following
4) "Loading ESXDOS.SYS... [ERROR] - this comes up finally, then zx resets (black screen, then white screen)

Dirve not mounted, not working.

My suspicions:
I have lot of files on the sd card (like several folders with games, demos etc) - maybe there is some limit?
Most of those files have long names - maybe there is some broblem?

Any other ideas? Is there any crashlog I could retrieve?

I know i am supposed to remove the sd card to ADJUST FLASH FUSE JP2/E. But i cant do this. As i insert the sd card the machine crashed to the blocky screen.

Is there any other way to flash repair this card ???

Any suggestions very grateful.

Do you have maybe any idea what can be the problem?

Thank you, m

Behavious of command RETURN is not always same, sometimes it will RESET computer, sometimes it will froze, sometimes it jumps in NMI menu and RESET after that etc... i suspect bug can depend on stack.

How replicate:
RESET ZX Spectrum
RANDOMIZE USR 15616
RETURN

Should reliably return back to Sinclair BASIC.

I wanted to try the new Dune 2 game from TRD files using esxDOS with DivMMC (on my Spectrum Next), but booting the first floppy produces only a black screen.

Other TRD games like Elite III run without a problem.

I hope someone would find out what the problem is and find a solution...

Regards,
Kapitány

Just upgraded a esxdos 0.8.7 to 0.8.9 on DIVIDE2K20

on 0.8.7 .128 command just leaved me on a 48k basic

when i did the upgrade the .128 command runs tries to boot
the 128 loader menu but gets stuk trying to detect logic units

I was only able to do this on a DIVIDE2K14 0.8.8 (broken now)

Thanks
EDIT:
> I was only able to do this on a DIVIDE2K14 0.8.8 (broken now)
whats broken is the interface not esxdos

TRDN (startet under the esxDOS ) crashes when changing to another Drive like "B:"

Same with TRDN X 8.1: ( Bigger Picture here: https://ibb.co/rG4dsj5 )

It sets colours in the ATTR format.
Colours stay until some basic command changes it.
It should work also with AUTOBOOT.BAS.

ub880d checked this issue and suggested:
In the ESXDOS.SYS must be changed 2 bytes at offset 0x0726:
0x3d and 0x5d to 0xf3 and 0x23

I used a DivMMC Future with a rubber key 48K Spectrum.

My conclusions are:

1. Upon power-up, the initial snapshot filename is "SNAP0000.SNA"
2. Pressing the "S" key, attempts to write a snapshot filename, if the file exists then "ERROR 18" is shown. The snapshot filename serial number is incremented.

Side-effects of this algorithm:

1. If the current working directory is changed then saving the snapshot file does not track the pre-existing snapshot files in that directory. It is OK, but the time relationship is lost meaning that the snapshot filename with the highest snapshot serial number may not be the newest snapshot file. For example, if a directory has gaps in the serial number sequence, then pressing "S" can create a snapshot file within the gap with a lower serial number than the highest serial number snapshot filename.

2. If the current working directory contains a large number of snapshot filenames with no serial number gaps (contiguous), then "S" has to pressed many times with "ERROR 18" until the internal snapshot filename is 1 higher than the highest pre-existing snapshot filename which then allows successful saving of the snapshot file.

Improvements:

1. Perhaps "ERROR 18" can be more verbose and indicate the failed snapshot filename ?

2. Perhaps the current working directory can be scanned to identify the highest snapshot serial number and add 1 to the number and use that as the snapshot filename ?

3. Allow snapshot files to be deleted using the NMI file browser.

4. Allow snapshot filenames to be renamed using the NMI file browser.

Is the source code available ? eg. is it closed or open source ?

Thanks.

One issue that is still not resolved is the load via commander of Kpacku Deluxe.  If you select the TRD, the commander comes up and run Kpacku, the demo will eventually crash.

However, if I launch from basic (.vdisk, RAND USR, RUN, etc) then Kpacku Deluxe runs properly and to completion.

This bug has always been present since 0.8.5.  0.8.8 avoided it because there was no commander (no TRDBOOT.BIN I guess) so programs were loaded from the trdos prompt.

(tested on zx next in pentagon personality)

When booting up on the +2a the boot screen appears (esxDOS logo, version number etc.) but after the message “Detecting devices…” appears nothing further happens.

This is a recent change so it may be a hardware problem. (I’ve replace the Z80 to hopefully rule out M1 problems but that has not helped) so I’m not sure what else to try. Do you have any suggestions?