Releasing for Next

Discuss game and other programming topics not specifically covered in another forum

Moderator: Programming Moderators

User avatar
Uto
Posts: 83
Joined: Tue May 30, 2017 9:33 am

Releasing for Next

Postby Uto » Mon Feb 03, 2020 9:17 am

Hi all,

A few months ago I was working in an addon (EXTERN) for DAAD Adventure Writer to allow it using Layer2 graphics in adventure games. At that moment, as I was just the developer of the addon I didn't care too much about the .NEX package, cause that would have to be the game author's duty. But it happens that I'm now involved in developing an adventure game, or in fact a port, and it's my duty to package it for release, so I've come back and read a bit about .NEX format, but I've been unable to find enough info.

First I would need to know if .NEX supports games using the ESXDOS compatibility layer, as DAAD addon is using ESXDOS read/write calls. Please notice I need to be able to write files (to save game progress).

At the moment I'm using ZESARUX fast boot to load the game, so I create a .tap file, but of course that is not the best way to do it. I could create a pure ESXDOS basic loader that loads everything (interpreter, game) wtihout problem, and then the addon loads the graphics, but I'm not sure if that is the better approach.

Also, despite I read about NEXCREATOR I seem unable to find a binary release. Is there a Windows build ready to use? MacOS? Linux?

Thanks in advance for your help!

User avatar
Uto
Posts: 83
Joined: Tue May 30, 2017 9:33 am

Re: Releasing for Next

Postby Uto » Mon Feb 03, 2020 9:46 am

I found Nexcreator in syustemnext1.1.zip file, but there is no documentacion and command line help doesn't help too much:

Code: Select all

Nex File Creator
Usage :-
NexCreator source.txt dest.big
UPDATE: Ok, I just found some info here:

https://github.com/varmfskii/zxnext_too ... aster/docs

I'll see what I can get from that, but now I believe I should include only thet files required to start in the .NEX file, and then the rest of the files which are loaded on demand, will be outside the .NEX file.

Do any of you have some sample input file for NEXCREATOR? The fact is my game is a standard 48K game, I only need to load some specific files in the 48K RAM and then jump to a specific addres. From that very moment the code will use ESXDOS calls to load image files, and to load/save games.

Stefan123
Posts: 119
Joined: Mon Jun 05, 2017 9:38 pm

Re: Releasing for Next

Postby Stefan123 » Mon Feb 03, 2020 10:01 am

You can find information about the NEX file format on the official Spectrum Next Wiki site:

https://wiki.specnext.dev/NEX_file_format

The z88dk C compiler also supports the NEX file format.

Ped7g
Posts: 252
Joined: Mon Jul 16, 2018 7:11 pm

Re: Releasing for Next

Postby Ped7g » Mon Feb 03, 2020 10:07 am

The "NEXLOAD" dot command itself does use esxdos-like API calls `rst 8` for F_OPEN/F_READ/...

After the NEXLOAD gives control to the code inside NEX file, the `rst 8` should still work (as long as you don't overwrite/disable/reconfigure divMMC, which requires deliberate specific effort (no worries you will do that by accident, the divMMC memory is not even accessible through Next MMU registers, you have to use specific divMMC I/O ports to cause any kind of damage).

The TAP files can be loaded also under full NextZXOS, so TAP package is not unreasonable, it will just have currently extra step while loading from NextZXOS browser, asking if it should be launched in standard/zx48 (usr0)/zx128 mode, while NEX is loaded without any prompt. Using esxdos-like API `rst 8` from TAP file will cause the savegames to appear on disk outside of TAP file (the NextZXOS does also trap regular ROM LOAD/SAVE routines to work within the TAP, but I believe for the savegames it is actually wanted behaviour, to land outside). But I'm not sure if the DAAD addons will be capable to read files inside TAP through esxdos API, I don't see that as something "obvious", so you probably have to try that with full OS image, to be sure.

Also if NEX file will be used, the addons will still address separate files? Or you can configure them to read from certain offset from NEX file itself? If you have no control over addons code and it's using esxdos API to read files, I'm afraid you will have to put on disk separate files - but I may be wrong, I know very little about esxdos and NextZXOS.

(the NEX file has mechanics to include binary data extra appended to the core file and the NEXLOAD can pass you file handle pointing to the first byte of the appended file, but that's easy to use by esxdos API calls only if can adjust addons code to not open files, but seeks through the already opened file handle to particular positions)

The NEX format is described here https://wiki.specnext.dev/NEX_file_format - also with links to various tools (the official Next distro has NEXLOAD command supporting only V1.2 files, not V1.3, but the nexcreator does create V1.2 at this moment any way).

The nexcreator binary is also part of official distro:
https://gitlab.com/thesmog358/tbblue/tr ... NexCreator

Or you can use the SevenFFF's fork:
https://github.com/Threetwosevensixseven/NexCreator
(there's link to debug windows executable right in the project README)

I'm not sure how difficult it is to build it for mac/linux, I would expect it to be quite easy, but didn't try myself (as I'm producing NEX files directly from asm source with sjasmplus, but that's probably not convenient for your use-case)

to run ZEsarUX with the full NextZXOS I use on linux this bash script:

Code: Select all

#!/bin/bash
zesarux --noconfigfile --vo sdl --ao sdl --machine tbblue --realvideo --zoom 1 --enabletimexvideo --sna-no-change-machine --nosplash --disablefooter --nowelcomemessage --quickexit --disabletooltips --forcevisiblehotkeys --disablemultitaskmenu --mmc-file tbblue.mmc --enable-mmc --enable-divmmc-ports "$@"
the important part is probably " --mmc-file tbblue.mmc --enable-mmc --enable-divmmc-ports" pointing to the 64MB mmc image from the ZEsarUX repository (must be in the current dir, the way how I use it), and I'm using "hdfmonkey" tool to put new files into the mmc image (before launching the emulator).

(I didn't try to force you single path or answer, but I added some info about everything, so sorry if this seems too much or confusing, I'm actually not sure what precisely you want to achieve, so I rather added all info I could recall, at least somewhat related to your question)

User avatar
Uto
Posts: 83
Joined: Tue May 30, 2017 9:33 am

Re: Releasing for Next

Postby Uto » Mon Feb 03, 2020 10:38 am

Thank you all for the detailed information. I'm trying to discard tap files as I think it just doesn't look good to have a TAP file as executable, and then plenty of picture files outside. Reading pictures from .tap file can be done but it's not the best way either.

The DAAD games used originally just 48K, but I just remembered I'm using the MMU to have a place where to load the files before moving to Layer2, so in fact I'm using more RAM. Thus, it'll have to be a 128K .NEX file.

With the information you provided, I think I'll go first for a .NEX file with just the code and data that stay in RAM all time and let the picture files be outside the .NEX file to be loaded by the current loading code.

Once I have done that, I may reconsider including the pictures inside the .NEX file too, using the seek/read approach you mentioned. I have control over the loading code, so I can modify it to load from .NEX file, or at least from a single resource file, whether is the .NEX file or some other big file in the same folder.

Regarding distribution into a SD file, is there any way to make the game boot automatically on start? (maybe just include the required files apart of the game and use some kind of "autoexec"?. I know ESXDOS has AUTOEXEC.BAS but not sure if NextZXOS supports that one.

Ped7g
Posts: 252
Joined: Mon Jul 16, 2018 7:11 pm

Re: Releasing for Next

Postby Ped7g » Mon Feb 03, 2020 10:58 am

autoexec.bas should work

User avatar
Uto
Posts: 83
Joined: Tue May 30, 2017 9:33 am

Re: Releasing for Next

Postby Uto » Mon Feb 03, 2020 11:27 am

Ped7g wrote:
Mon Feb 03, 2020 10:58 am
autoexec.bas should work
Great, thanks!

User avatar
SevenFFF
Posts: 565
Joined: Mon Jun 05, 2017 5:30 pm
Location: USA

Re: Releasing for Next

Postby SevenFFF » Mon Feb 03, 2020 2:18 pm

NextZXOS uses c:/NextZXOS/autoexec.bas, whereas esxDOS uses (I think) c:/sys/autoboot.bas.

Because NextZXOS uses different directories, it can coexist with esxDOS in your SD card, and you can use either depending on which personality you select on the bios menu.

NextZXOS fully supports the esxDOS 0.8.6 API, but internally the code is a thin wrapper around the NextZXOS code, which originates from +3DOS via Garry’s +3e work.

+3DOS file-level APIs are fully supported, but not the sector-level or low-level FDC APIs (because the Next doesn’t have a virtual FDC chip in the FGA). So while +3DOS floppy .dsk images and +3e .p3d hard disk images can be mounted and used, any protected images or images containing FDC code can’t.

It’s very nice to be able to use both APIs in a mix and match fashion without worrying too much.
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel NXTP ESP Update ESP Reset CSpect Plugins

User avatar
SevenFFF
Posts: 565
Joined: Mon Jun 05, 2017 5:30 pm
Location: USA

Re: Releasing for Next

Postby SevenFFF » Mon Feb 03, 2020 3:25 pm

Uto wrote:
Mon Feb 03, 2020 10:38 am
Once I have done that, I may reconsider including the pictures inside the .NEX file too, using the seek/read approach you mentioned. I have control over the loading code, so I can modify it to load from .NEX file, or at least from a single resource file, whether is the .NEX file or some other big file in the same folder.
.NEX files have an option to leave the file handle open after they are loaded, in which case the loader positions the file pointer at the end of the data that got loaded. This means the user can rename the file before launching it, and you don't have to worry about finding it by name and reopening it.

So you can append any data you like to the end of the .NEX, and load that privately with your own code. Or you can seek anywhere within the file if you want to reload data that already got loaded. It's a nice solution for a large single WAD file, instead of needing a whole directory with individual resource files.

You have at least 15 handles available, so you can leave the .NEX handle open throughout your program, even if you need to open other files as well. You can even open multiple handles into the same file, so you can alternately stream data from different pointers - one for DAC audio every frame, one for level data, etc.
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel NXTP ESP Update ESP Reset CSpect Plugins

User avatar
Uto
Posts: 83
Joined: Tue May 30, 2017 9:33 am

Re: Releasing for Next

Postby Uto » Mon Feb 03, 2020 7:40 pm

Thank you SevenFFF, when I started my DAAD extension I started with ESXDOS support for ZX Spectrum, I eventually did it for CPC, C64, MSX, PCW and Spectrum +3, but when I ported it to Next I had not yet done the +3 version, so I re-used the ESXDOS one, which was very convenient.

At the moment the code opens a file and uses a different handle wherever a picture has to be loaded, or a savegame loaded/saved, but yes, it would look very professional to have just one large NEX file, so I'll have a look at it once I manage to make the simple approach work (one NEX file, several picture files).


Who is online

Users browsing this forum: No registered users and 3 guests