I'm trying to find esxDOS source code, but so far can't find it.

I have ZX Spectrum Harlequin 128k and I really want to make esxDOS work with `basic 128`... I know that the problem is not trivial, but still - would like to dig into it...

I'm kind of assuming the NMI does not do a return to $67 to exit, and uses some BASIC routines. I think switching to the ROM after boot, does allow a "jp $000a" at $0008, for "rst 10" access to raw assembler esxDOS calls.

thank you
Valerio

I have had some AT28B64 chips, so non-B, which do not work properly with the flashing routine.
I think it's because of some enhanced flashing features, present only on the AT28C64B.
So my first question is: can the flashing routine be made compatible with AT28C64?

Many of the AT28C64B batches I've bought throughout the last months, do not work properly.
I suspect these are remarked chips, and in fact AT28C64 (non-B), but I can't be sure.
I tried to flash them as AT28C64 on a USB programmer, which seemed to work ok, hence I think these are AT28C64.

Is there another EEPROM type that will work with the flashing routine?
Of course it would be very nice if there are other types that are pincompatible, so I can use the same pcb.

can anyone please tell us more infos on TRDBOOT.BIN: Where and when is it loaded into memory. And how can we ran other programs/Navigators instead of the included TRDN / TR-DOS Navigator?

This is how the ZXDIR CustomROM was created,
to download from https://mega.nz/folder/O8NwQDjS#yLw7tABrQoY94N3_9Uj2kg

ZXDIR1.ROM - DIR command on COPY key (following BSROM style) and esxDOS tilda character replaced unused pound sign
ZXDIR2.ROM can move the cursor better in the edit line (similar to LECROM)
ZXDIR3.ROM - added an ability to enter hexadecimal numbers (as with Amstrad CPC or in SAM BASIC)

Choose a version that suits you. The last one allows to insert HD numbers with '&' in INPUT, LET, PRINT, OUT, IN ... up to &FFFF,
e.g. PRINT &e0-&f
LET a=&4000: PRINT a
PRINT &FFFF+&3^&2
OUT &Fe,1

Check original color ROM settings in the BlackOnWhite directory.

Modifications are economic, minimal (was added a total of about 100 bytes only) and "should" be highly compatible with any software, because they are short and set in places where they shouldn't interfere with other popular system modifications. The goal was to make a few necessary adjustments only, not to improve or fix basic commands - dot-commands can be now used for purposes of BASIC expansions and mostly no direct ROM patches are needed, I think.

Please have a look at the project here: https://github.com/Utodev/utoboot

Infos:

utoboot

A general purpose boot system so games or utilities can be distributed in SD card format for DivMMC/IDE with ESXDOS (ZX Spectrum)
Purpose

Using DivMMC or DivIDE with ESXDOS is a great experience, but so far there was no way to distribute games in physical format using ESXDOS, mainly because ESXDOS relays in it's own core, which is installed inside the DivMMC/DivIDE flash, and external files such as ESXDOS.SYS, that should be in the SD card. Also, the core and the ESXDOS.SYS file should match in version number, so a developer cannot create a SD card which would work on every DivMMC/IDE, as the developer doesn't know which version of ESXDOS is installed in every target DivMMC.

In latest versions of ESXDOS, the autoboot feature was implemented, and AUTOXEC.BAS can run any game in the SD card, but again, not if you don't know the ESXDOS version of the user.
What we found?

After some testing, based in a first try by @mcleod_ideafix, and with a lot of help from Andrew Owen and Antonio Villena, I managed to find the BETADISK.SYS file is executed when loaded, al least in the very last versionos of ESXDOS (0.8.5 and above). Thus, you can make any code run at that point, for instace to load some other file (the game) and execute it.

But to get to BETADISK.SYS you have go trough loading ESXDOS.SYS first, and that was the main problem as it should match the version of the core installed in the DivMMC.

Well, we found ESXDOS.SYS can be replaced by an empty file, and then no version check is made. That has some side effects, cause some of the functions ESXDOS provides are in the SYS file, not in the core, so some ESXDOS functions doesn't work with this solution. On the other hand, we found the ones most needed for games (load and save files) work flawlessly at least in the latest versions of ESXDOS.

There was still a challenge: in latest versions 0.8.7 and 0.8.8, we found the core itself was calling some of the new functions, which should be in the SYS file. We believe it is the built in autoboot feature. To avoid that, we finally replaced ESXDOS.SYS, with a 4K file plenty of RETs, which, in case of the core calling a function, it just returns. This works for latest versions and we hope it works with future versions too.
So how it works?

At the moment, there you only need to include in a SD card the content of the SYS folder in this project (ESXDOS.SYS and BETADISK.SYS), together with a AUTOEXEC.BIN file that you should place in the root folder of the SD card. That AUTOEXEC.BIN should be a binary loaded at 8000h, and executed at 8000h, cause the loader will loaded it there and then jump to 8000h.

Please notice the ROM will not be initialised, so don't expect the system variables to be there. On the other hand, the loader makes part of the ROM initialization (clears the RAM, sets interrupt mode 1, enables interrupt, sets IY valuye to ERR-NO system variable address), but doesn't make other things like initializae system variables, UDGs, etc.

Also, have in mind that when your game starts, the stack it's at 8000h, so first value stacked will go to $7FFF and $7FFE

If you use the AUTOEXEC.BIN file included in this project, together with the SYS folder, you will have a SD card with an autoexecutable copy of Manic Miner. Thanks to Matthew Smith for creating this great game.
What if my game does not start at 8000h

Ok, that's why the source is available. You have this section in the source code:

define LOAD_ADDRESS 32768 ; Address where to load AUTOEXEC.BIN file define LOAD_SIZE 32768 ; Size of the AUTOEXEC.BIN file (if size if larger than file, file is loaded anyway) define START_ADDRESS 32768 ; Start address to run the game

Just change load address, file size and start address and recompile utoboot.asm using sjasmplus, and you will have a new BETADISk.SYS file ready for your game.
What if my game needs the system variables

We recommend getting a copy of the system variables memory block as a file, and load it from the loader, before calling your code.
I see two [ERROR] messages when starting the game, cause NMI.SYS and RTC.SYS are not there

If that it's too annoying for you, just make copies of ESXDOS.SYS and put them as RTC.SYS and NMI.SYS in the SYS folder.
NMI handler does not work

That's correct, it's a feature.
Notes

    Despite you may think it would be a good idea to have a loading screen shown loaded by the utoboot loader, it is not. As said above, the ROM is not initialized, so you actually don't really have a FRAMES system variables, nor the IM 1 expected interrupts, and also the ESXDOS ROM is paged in, so you don't really have that usual ROM at full.

    Maybe it's not a bad idea to load a screen, then load your game code, and then, when your code starts, set your own interrupt handler, make a pause there so the loading screen is visible, and then continue with your game. If you want to do that, you can use the LoadFile function in the source code, whose parameters are clearly defined there.

    Please notice the loader runs at address 2000h, which is the ESXDOS area for dot commands. If you use ESXDOS functions, consider it is like a dot command, so use HL for the parameters instead of IX.

    Many of the ESXDOS functions work, but some others may not work fine. We have tested loading and saving files, which are important for games (especially loading is great so you can make mulyiple areas with different sprites, loading beatiful background images, etc., but also saving is great to save game progress). Other functions may not work.

AGD Loader

MPAGD (Multi Plataform AGD) IDE can use the Export feature to obtain a binary file for your game, just make sure you create the TAP file, and the go to "Suite ZX\SjasmPlus" folder in the AGD directory and you will find the same file but with BIN extension. Put that file in the root folder of your SD card, rename it to AUTOBOOT.AGD, and put ESXDOS.SYS and AGDBETADISK.SYS en your SYS folder. Finaly, rename AGDBETADISK.SYS as BETADISK.SYS.

If you have a game made with AGD 4.0 or above, MPAGD can also import it and then export it. If it importing TAP file doesn't work, try making a snapshot with an emulator and try to import SNA.

You have a sample game (Hero'es rescue) by Defecto Digital in the repository, so you can check. Thanks Javymetal for letting me use it as sample.
DAAD Ready Loader

DAAD is a text adventure engine made by Infinite Imaginations, AKA Gilsoft, AKA Tim Gilberts, for the Spanish company Aventuras AD. DAAD has a ZX Spectrum interpreter, and DAAD Ready is a package to make adventures with DAAD, which includes ESXDOS targets (for normal Spectrum and also for ZX-Uno, which uses graphics in Timex HiRes mode).

daadloader.asm contains a loader that has been implemented in DAAD Ready 3.0, so games can have autoboot. DAAD Ready contains everything that is needed, but source code is better hosted in this project. DAAD loader will be included by default in DAAD Ready.

https://spectrumcomputing.co.uk/forums/ … COQSzwyulk

This one requires a tool on the PC/Mac to pre-read the directories:

https://youtu.be/8Pg4WtUHuuM

I'm talking about multiloaders when you have one code for several versions of demo/application.

For example, esxDos present - read via it from folder, if not - trying detect TRDOS - read from floppy(in success way) or tape.

sorry, but I´m new into programming Z80 and esxDOS, so this is a Newbie question.

I struggle about exiting a selfprogrammed .DOT-command which started with parameters.
Starting the .DOT-command without any parameters runs it OK with 0 OK, 0:1

But when running passing a parameter, it shows me this on esxDOS 0.8.6: !q, 0:1
or on esxDOS 0.8.7: M, 0:1
or similar strings.

On: http://board.esxdos.org/viewtopic.php?pid=969#p969
I find something about howto right exiting a .DOT-command. But it´s too complicated for me as beginner to understand.
Can someone please give me a source-piece to add to my .dot-command to exit it right with 0 OK, 0:1

I´m on esxDOS 0.8.7 or esxDOS 0.8.6 under DivIDE-Emulation (SpecEmu).

Or should try to use Z88DK as "Assembler only" as I find it hard for me to get into programming C. And Z88DK´s .DOT-command compiling options may fix me problems?

Regards,

Luzie

HDFmaker - A GUI to click together Next and esxDOS-Memorycard-Images and content

First public released Version v001.091 (Package name: "2019-08-18 HDFMaker V001.091.zip" - Filesize: 65 MBytes)
Downloadlink: https://www.magentacloud.de/lnk/9HgGDEX9

Testet under Windows 10 64-Bit

From the ReadMe:

Sorry, no support for this. So please note:

Only runs with Administrative Right "RunAsAdmin" yet.

Only runs from with a directory called HDFMaker which must be at Root of any drive
So HDFMaker.EXE must be at: \HDFMaker\HDFMaker.EXE

AutoHotkey-Sourcecode will be released in future version.

PROGRAMS
|----------- MY_APP_N.AME
             |----------- PRG
                          |----------- MY_APP_N.PRG
                          RSC
                          |----------- RESOURCE.BIN

The RUN command sets the SP to $6000, loads the binary (PRG file) at $6000, changes the path to the resource (RSC) folder and calls $6000. If the binary fails to load it restores the stack and falls back to BASIC. This means the binary can be up to 40K in length. The binary is then responsible for loading its own resources. The method for passing parameters to the app is to define a variable in BASIC.

This approach has a number of advantages over the single executable file method. For example, with multi-lingual software, only the selected language resources need to be loaded. It is also easy to customize the app without the need to recompile it.