As part of the newly released ESXDOS0.8.6 there's now a new .128 command that should cover your needs

-Dx

As mentioned elsewhere, the original 128 editor will be unstable with esxDOS because of hardware traps. But if you are willing to change your machine's ROM you can have a working 128 editor that won't crash. And this one gives you six channels in the PLAY command instead of three (if you have a TurboSound AY board). https://zx.itch.io/derbyplusplus

-Dx

aowen wrote:

You don't need 128 BASIC. You can use SoftPLAY to use the PLAY command syntax from 48 BASIC. I did look at implementing it as a .PLAY command, but the code requires the ROM's calculator routines and there's no convenient way of accessing those at the moment.

Hi, thanks for your reply, but I ask more for the 128k Editor than for a working PLAY command under 48k Basic. Still fine you wrote a .command .play for this ( https://zx.itch.io/play )

When I responded to this thread in 2015, I hadn't solved the problem of getting SoftPLAY to work as a dot command. Aside from PLAY the only possible reason you could want to use the 128 editor is for tokenized command entry. A better solution is to use a version of the 48K ROM with a tokenizer.

The issue with using the 128 editor with esxDOS is that the area from 15616 to 16383 triggers the TR-DOS traps and therefore it's prone to crashing. Velesoft's solution, if I've understood it correctly, is to effectively run the 128 editor from divMMC RAM, thus preventing the traps from triggering.

An alternative solution is to build a new version of the 128 editor that doesn't contain any program code in the area 15616 to 16383. I'm reasonably confident it would be possible to do this with the Derby+ code base (which is the fastest version of the 128 editor). But you would need to replace the ROMs in your machine.

You don't need 128 BASIC. You can use SoftPLAY to use the PLAY command syntax from 48 BASIC. I did look at implementing it as a .PLAY command, but the code requires the ROM's calculator routines and there's no convenient way of accessing those at the moment.

Hi, thanks for your reply, but I ask more for the 128k Editor than for a working PLAY command under 48k Basic. Still fine you wrote a .command .play for this ( https://zx.itch.io/play )

I´ve created a TAP-File of the 48k/128k Switch program from WOS.

You can download it here:
http://forum.tlienhard.com/phpBB3/downl … hp?id=5528

MCode in TAP-File is save from Adress 50000 (54 Bytes long).
When loaded at adress 50000, you can switch from 128k to 48k Editor with USR 50000
Switching from 48k Editor to 128k Editor works with USR (50000+10)=USR 50010.

Program can be loaded at any adress in RAM, e.g. with LOAD""CODE 32768 from adress 32768 upwards.
Then use USR 32768 for 48k Editor and USR 32778 for 128k Editor.

Don´t tried it yet on a divIDE.

Switch from 128k BASIC to 48k Basic
https://www.worldofspectrum.org/forums/ … ion/11936/
===== SNIP =====
...You can swap back and forth from the 48K and 128K editors to you hearts content....
===== SNAP =====

However I haven´t testet it yet on a divIDE.

Found this on WOS:

http://www.worldofspectrum.org/forums/d … browser/p5
from VELESOFT:

velesoft
June 2012 edited June 2012 Thanks
If any DIVIDE system need work on 128kB models with 128 rom then must exist more versions for more zx 128 roms. Exist english rom for ZX128, english +2, spanish +2 and french +2.

Rom with 128 editor use adress space #3D00-#3DFF for controll syntax of basic, but this adress is on DIVIDE used for tr-dos emulation, If you copy part of 128rom to divide ram and modify this code (in divide ram) then will possible use divide system with 128 editor. And on some other entry points of divide automapper must be add autodetection of connected zx rom type (detect if is set 48 rom or 128 editor).

can we have an external command like .128edit
that can start the divIDE / divMMC in 128k BASIC Editor Mode
so we can write simple 128k BASIC programs like
PLAY "A"
and save them e.g. to a .TRD-Image-File or TAP-File
or easier to a Snaphot which stores with "128k Snaphot Flag",
so it can be later loaded and run automatically in 128k mode.

I know, this could be no complete 128k Mode for the divIDE
(as a divIDE+ is needed with it´s expanded hardware / RAM).

But a "limited 128k" Mode without RAM-paging should be possible
for the divIDE ?

What do you think ?

Regards,

Luzie