ZEsarUX-7.2 Beta

Discuss ZX Spectrum Next Games, Tools and more.
Post Reply
User avatar
Posts: 228
Joined: Mon May 29, 2017 8:14 pm

ZEsarUX-7.2 Beta

Post by chernandezba » Wed Dec 19, 2018 7:45 pm


I have uploaded a new BETA version of ZEsarUX 7.2
You can download a compiled version for Mac or Windows from:

Linux and other O.S. users, you can compile from source code.

Changes in this beta version:

Version 7.2. 19 December 2018 - Neula edition

Added setting to specify configuration file

Improved menu environment:
* Added new menu window type: ZX Vision. GUI Windows can be moved, resized, scrolled, minimized, closed, and change the focus to the background
* Warning and Error window messages now show an animation

Added key to save text windows contents to a file
Added setting to send a final space after every word in the osd adventure keyboard
Added Dandanator CPC emulation
Added machine Amstrad CPC 4128

Improved ZRCP:
-commands smartload and snapshot-load are more intelligent now
-running in verbose or limit mode, or cpu-step command, can now update the display inmediately (having real video setting on)
Improved vu-meters: high volumes are shown in red
Improved sprite viewer: you can view sprites up to 512x512

Improved disassemble window:
*now you can export the disassemble to text file
*you can now see the full opcode when debugging Sinclair QL
*you can now show/hide hexadecimal dump of every opcode

Fixed visual glitches in some menus when Pentagon machine and real video: audio wave, visualmem, ay piano, wave piano, view sprites
Fixed visual glitches in some menus when interlaced enabled: audio wave, visualmem, ay piano, wave piano, view sprites
Fixed audio bug: sending a sample to the DAC by using Next registers, it wasn’t reseting the silence detection counter, so sound would probably be frozen (and repeated again, and again...)
Fixed autoload on tbblue (on normal and also fast boot mode)



ZX Second-Emulator And Released for UniX

Posts: 109
Joined: Mon Jul 16, 2018 7:11 pm

Re: ZEsarUX-7.2 Beta

Post by Ped7g » Wed Jan 09, 2019 11:34 am

Hi Cesar,

I'm trying to help to update the emulation to current state of HW, as you probably noticed (the pull request on github), but I think I'm at a point when some discussion with you about what kind of help is truly helping you and acceptable for you, is needed.

The (proposed) changes for clip-windows seem to me sort of minimal, and you can probably adjust them to your liking easily, but now I'm looking at fixing palette stuff, and I'm afraid I would love to divert from your current state considerably.

Both internally and in debug views I would prefer "RRRG_GGBB p000_000B" view, like full-violet 9b colour being "E301H" (not sure, how to display "priority" bit in palette viewer, for me as programmer "E381H" is acceptable, or colour coding (background like I used for index of clip windows?) ... I'm also ok, if this would be not default view, and your current "1C7H" would stay as default, but for code debugging this format is a bit useless and I have to recalculate it in head.

But I would really insist on changing the internal storage of palettes in the two-byte way like they are being sent to NextReg$44, i.e. E3H, 01H or E3H, 81H .. But I'm not sure how badly it would hurt your other code (video signal output).

I was also looking a bit into sprite engine rewrite, but so far I didn't fully understand how your emulator ticks, as the HW sprite engine reads sprite attributes and patterns during rendering, so the Z80 must run together with the sprite engine to produce somewhat-accurate results, like code changing pattern for late sprites at beginning of scanline should should produce visible change... I don't believe 100% accuracy is needed for practical usage (and 100% accuracy will be difficult, as we don't know the precise timing of HW implementation, it's reading pixels of sprites at 28MHz which is the bottleneck for total pixel throughput, but I don't know if there are some skips of beat in situations like switching to next sprite/etc) ... but probably producing the next-line-buffer in chunks of 16..32 Z80 cycles (32T) would make sense to me... but then the emulator code can be designed for that way of running (per tiny chunks, having similar architecture as the real HW thing), as bending classic procedure toward this would be quite painful in my experience.

But... all of this depends, if these correlate somehow with your own visions, and you are willing to discuss under which conditions you would accept such work.

So.. feel free to contact me here, or at FB ("Peter Ped H.") if you think we can discuss some of these topics.

Thank you, and cheers,

Post Reply