This is an old revision of the document!
ClassicZoo is a fork of ZZT by Adrian “asie” Siekierka, started in late 2020 and initially released in March 2021. Its goal is to improve the ZZT experience while sticking close to the original engine's feel and keeping full compatibility.
If you'd like to learn more about ZZT, the Museum of ZZT is a good place to start.
The minimum requirements are effectively the same as ZZT's own, with the addition of PC-98 support:
Keyboard, Joystick and Mouse input is supported.
IBM PC or NEC PC-9801 compatible computer,
286-class CPU (386/486-class for particularly scripting-heavy games to run at full speed),
640 KB of RAM,
EGA/VGA graphics adapter (CGA will work, but with lower performance due to snow avoidance).
Most ZZT games are designed with Keyboard input in mind - however, a few (two) recommend Mouse input instead.
EMS/XMS extended memory support - effectively lifts the world size limit, as well as improving stability of large worlds on machines with lower amounts of free conventional memory.
Increasing the board size limit from 20000 to 65500 bytes.
Increasing the board count limit from 101 to 256 boards.
Major CPU and memory usage optimizations.
Major editor enhancements: syntax highlighting, OOP import/export, STK color and element support, multiple patterns, block and OOP copy/paste, bugfixes
Fixes for crash/hang engine bugs, while keeping compatibility.
Subdirectory support in the file browser.
NEC PC-9801 port.
The complete list of features is provided in the changelog, which is bundled with ClassicZoo.
NEC PC-98 port
In most cases, you want either the build in bold (for PC-compatibles) or the NEC PC-98 build (for PC-98 machines). See the FAQ for further details.
If you're looking for game worlds, try the Museum of ZZT! Here are some recommendations:
Released on the 9th of August, 2021.
Released on the 11th of July, 2021.
Released on the 27th of May, 2021.
Released on the 13th of April, 2021.
Released on the 11th of April, 2021.
Released on the 6th of April, 2021.
Released on the 28th of March, 2021.
Released on the 27th of March, 2021.
Released on the 23rd of March, 2021.
Released on the 6th of March, 2021.
Q: Which build and executable of ClassicZoo should I use?
A: For all builds, “ZZT.EXE” should be preferred for general usage.
The regular build (in bold) is provided for typical PC-compatible use.
The PC-9801 build is provided for users of NEC PC-9801 machines.
The libre build is provided for projects which do not wish to utilize non-libre code included by Turbo Pascal's compiler. However, it comes with a CPU performance, filesize and memory usage penalty.
The low memory build is meant for especially constrained platforms and removes many features. It is only really useful for platforms with ⇐ 512 KB of memory.
Q: Should I use DOSBox or Zeta with ClassicZoo?
A: Both are likely to work just fine; however, please keep in mind that behaviours which work correctly in DOSBox, but incorrectly in Zeta, are always Zeta bugs and should be reported appropriately.
Q: I'd like to make a ZZT 3.2-compatible game. How can I ensure ClassicZoo's bugfixes don't get in the way?
A: The “?DCOMPAT” command in the editor build serves exactly this purpose. If enabled, it will emit a warning when most bugs fixed by ClassicZoo are encountered - including behaviours which are unreliable in ZZT 3.2, but not always a crash or hang (like double #BIND).
Q: How good is ClassicZoo's compatibility relative to ZZT 3.2?
A: As a rule, all games released for ZZT 3.2 should work correctly in ClassicZoo, and the two should be freely interchangeable for this purpose. I am, however, aware of some behaviours which are not emulated:
Some worlds which rely on arbitrary code execution exploits (like PortalZ
or Hack the Matrix
) which depend specifically on ZZT 3.2 may not work correctly. This may be improved in the future, but - for some of these worlds - may prove impossible.
The fix for the “conveyor destroys player” bug also prevents all usages of the conveyor for stat swapping. To the best of my knowledge, no game uses this behaviour deliberately due to it only being documented very recently - if one is found or created, the bugfix may be adjusted as necessary.