2.3.4 (SNAPSHOT)
- minimal JDK version lifted up to 21
- updated embedded JDK to 23.0.1+13
- updated JInput library to 2.0.10
2.3.3 (21-oct-2023)
- improved z80 snapshot load to process 0-2 banks among 128 ram banks
- updated embedded JDK to 21.0.1+12
2.3.2 (23-mar-2023)
- added AppImage
- added way to decrease CPU use in non-turbo mode with option "Try use less resources" #35
- updated embedded JDK to 20+37
- minor improvements of Z80 emulation
- added Ula Plus palette support for animation GIF recording
- fixed restore indicator panel view flag after restart #86
full change log
NB! The emulator has been developed as proof of concept of ZX-Poly and by default it starts in ZX-Poly mode, if you need ZX-Spectrum 128 mode then activate it through options!
I am a ZX-Spectrum fan since 1989. ZX-Spectrum platform was very popular in the USSR. In april of 1994 I got some idea how to resolve attribute clash through moving the platform from mono-system to poly-system.
The idea was to start four ZX-Spectrum-128 in parallel with small modifications of graphics data. It didn't need any changes in ROM and SOS but only total synchronization between CPUs and sharing of all control signals.
I can't say that the idea was too original one because I was inspired by the book "COMPUTER IMAGES" ("Understanding computer" Time-Life books). There I found several strings about the Pixar platform (developed by the Lucasfilm team) which processes each color component by dedicated CPU. In ZX-Poly each CPU also processes dedicated color component (R,G,B,Y). Software no so often checks information written into VRAM so that big part of games and utilities could be adapted just through edition of their graphic data.
Both the concept and emulator and all its parts are published under GNU GPL3 license.
| OS | Download link |
|---|---|
 |
for Windows x64 (JRE included) |
 |
for OSX x64 (JRE included) |
 |
for OSX Arm64 (JRE included) |
 |
for Linux x64 (JRE included) |
 |
Linuc AppImage x64 (JRE included) |
 |
cross-platform JAR file |
Because the emulator is written in Java, its JAR file can be started just through command
line java -jar zxpoly-emul-2.3.3.jar
By default it starts embedded ZX-Poly Test ROM image, but it can be replaced by ZX-128 SOS in File->Options->Active
ROM, the ROM will be downloaded from one of remote network resources.
- Snapshots: .Z80, .SNA, .SZX, .ZXP (ZX-Poly snapshot format), ZIP (Spec256 with SNA inside), .ROM (ROM images), .PROM ( ZX-Poly ROM images)
- Tape: .TZX (allows export as WAV), .TAP (allows export as WAV), .WAV
- Disks: .TRD, .SCL
Since 2.0.5 the emulator supports game-pads and joysticks. It uses X,Y position and recognizing all buttons as Fire.
Mapping of game controller can be turned on through Service->Game controllers. I recommend restart emulator after
new controller connect because JInput works not well for such situation. For work with joystick, the emulator uses
library jinput so that it can work not for all host-platforms.
The base of the platform is the theory that stable synchronous systems (without any inside random processes) built on
the same components (because different element base can be also source of random processes) by being started
synchronously in the same time from the same state have the same state in any point of time if all synchronous system
components get the same input signal states in the same time.
ZX-Poly platform adds several ports to manipulate work modes and the main port of the platform is
#3D00. In more details it is desribed in wiki.
It is just regular ZX-Spectrum mode 256x192 with 2 attributed colors for 8x8 pixel block.
It is a family of video-modes and contain three sub-mode. All modes provide way for each pixel to get a color from standard ZX-Spectrum 16 color palette.
It is just regular video mode without any masking. It just integrates pixel info from video-ram of all CPU modules and form 4 bit index in ZX-Spectrum palette.
TRD disk with the example can be downloaded from here, the game has been partly colorized
It works as previous one and provide way to for 4 bit index for pixel, but also it analyses INK and PAPER colors from CPU0 video-ram and if INK = PAPER then whole block is filled by the INK color. It is made to provide way to make compatibility with games hidding some visual elements in areas with same INK and PAPER colors.
It is the most complex from the video-mode family. It analyses FLASH bit of each attribute from CPU0 video-memory and turn on ZX-Poly mode only for blocks where FLASH bit is ON. In the same time it analyses INK and PAPER attribute values and if they the same then whole block is filled by INK else form pixel colors as in standard ZX-Poly mode. All blocks where FLASH is OFF are processed as in standard ZX-Spectrum video-mode. FLASH is not working in the mode (but it is no so often feature in games). The video-mode provides way to colorize games with color dynamic indicators and duotone game-play areas.
The Mode uses attributes but places pixels in chess order.
TRD disk with the example can be downloaded from here
To adapt old games, I have developed special utility called ZX-Poly Sprite corrector, which can be found in releases. It
is a very easy editor which shows images in data blocks and allows to redraw them. It supports import from Z80 and SNA
snapshots and as the result it generates ZXP snapshots.
Its pre-built versions can be found on the latest release page.
Original look of the game
On Christmas 2017 I made some adaptation of the old game "Official Father Christmas" (1989) for ZX-Poly (mode 6). Of course not all was smoothly, some elements of third level could not be colorized because their colorization broke game process and made CPU modules out of sync, it looks like that the level contains some optimization in graphics processing for those elements and presented some check for empty areas to optimize speed.
Adapted game version in ZX-Poly emulator format can be downloaded from here.
I was playing with adaptation of the game for 512x384 (mode 5), program code works well but the game and without
adaptation is so colorful and detailed that big effect is not visible. Also it was impossible to adapt the main hero
sprites because the same sprites are used for both right and left walk through mirroring.
Adapted game version in ZX-Poly emulator format can be
downloaded from here.
In november 2019, I made some adaptation of "Flying Shark" game for ZX-Poly 256x192 (mode 7). It shows possibility of
combination of standard ZX-Spectrum colorization (for game panels) and ZX-Poly colorization (for game field). Snapshot
for ZX-Poly emulator can be downloaded from here.
The colorized version prepared and provided by @jotarp
I'm the programmer of "Comando Quatro" (yes, 35 years ago) and I've recently discovered your emulator (TLDR; I've recently rejoined my old colleagues from Gamesoft and they even invite us to give talks about those years: https://www.youtube.com/watch?v=TKIFtYspv1U , in spanish). I have tried to adapt my game to "mode 4", colouring the graphics. It has been fun to meet again with that game that took me so many hours of sleep when I was only 20 years old. I think the most appropriate place to publish the result is here. I haven't added too many colour details. The main feature of the result is that... there is no more "colour clash".
Snapshot for ZX-Poly emulator can be downloaded from here.
In 2021, during one evening I made adaptation of "Alien 8" game for ZX-Poly 256x192. Snapshot for ZX-Poly emulator can
be downloaded from here.
Since 2.0.1 version, some restricted Spec256 platform
emulation added. Because there is real difference in work of ZX-Poly emulator (which based on parallel CPUs)
and Spec256 (which based on CPU with 64bit virtual
registers), not all games work well, but many of them can be started and playable.
Known issues with emulation of listed games:
- Knight lore wrongly colored picture
- Bubbler losing colorization for some game elements
In ZX-Poly emulator working in Spec256 mode, some CPU registers are syncronized every iteration (by default PC, SP and
bits of F excluding C bit), but it works not for all games. In games which need another register set, there can be
provided special zxpAlignRegs parameter in CFG file situated in snapshot archive. For
instance zxpAlignRegs=XxYyPSsHLb means syncronization of IX,IY,PC,SP,H,L and B' registers.
No, I had some negotiations with ZX-Spectrum clone manufacturers in Russia in the middle of 90th but I agreed with them that it was too late for market.
No, it doesn't. ZX-Poly uses standard ZX-Spectrum 128 OS + TR-DOS. On start ZX-Poly even starts only one Z80 and three others in sleep mode and it is no so easy to detect difference in work with regular ZX-Spectrum 128 (I didn't find).
Both ZX-Poly and Spec256 work as SIMD computers but ZX-Poly is based on 4 Z80 "real" CPUs and Spec256 has some mix of 8 bit + 64 bit virtual Z80 CPU under the hood, I made attempt to convert some games from Spec256 to ZX-Poly but attempt failed because Spec256 is much more tolerant for damage of execution code (it executes non changed program and only changed extra-graphical data is sent through virtual 64 bit registers, changed data blocks don't affect executing flow).
ZX-Poly is a normal multi-CPU system and can work as in SIMD mode (to be compatible with existing software) as in MIMD mode and in the mode all CPUs work independently. It has some primitive synchronization mechanism called STOP-ADDRESS which allows to align common start address for all CPUs, also CPU0 can get some approximate info about current executing addresses of other CPUs and can get even some signals through interruptions what makes possible to emulate some periphery (like sound devices) in slave CPUs. Each CPU has its own memory area in common heap but it is possible to override memory areas and even map them totally each other (in the case it will be just multi CPU ZX 128).
Any software can be adapted but adpatation of games which don't have too complex sprite output and packed sprites, can be adpated just through edit of their graphics elements.