I’ve completely recut M4ZVM to retain as many benefits as possible, but sitting inside the 48K envelope through a 64x16 display. This meant analysing games to see where the best compromise laid for playing games. PunyInform games are of course excellent to run, and a lot of infocom z5 games work. The z4 games are either too large or need tweaking to fit inside the screen real estate.
z1, z2, z3, z4 and z5 games can execute
Supports full 64x16 display (no trimmed last column unlike the original)
Named game save and load
Fast execution of games (z3 games now execute faster than the original)
z3 status line supports am/pm time including Cut Throats easter egg
Supports Z-code ‘Dynmem’ dynamic memory size up to 18k
I had to remove the debug feature, adapt to the new screen, remove z6 support, and reduce the available dynamic z-memory to allow for optimal performance. Requires 48K and Disk support. At this point they both require LDOS 5.3 to run.
I’ve had some great feedback over the past two weeks and have been able to turn around a second release. Many thanks to Jonathan Hoof for thoroughly testing the Model 3 version which not only helped prove the stability, it also helped me find edge cases that could improve performance. Also thanks to Ira Goldklang who tested the software across a number of different DOS releases on the model 1 (NewDos80, DOSPlus).
Release 2 improvements include:
Save/load was rewritten and works faster now on real hardware
Compatibility across multiple DOS versions allows games to load more broadly
Refining of code and memory map to allow floating amount of cache (upper and lower boundary) to improve performance
New Cache method allows the software to run now on real and emulated hard disks - playing games on FreHD is highly recommended
Highlighting simulation visually improved to look more right-sized for single row status bars, and switches to deeper graphics for multiple rows
Extra memory recovered allowed v6 back in, so now you can play Arthur (without any images) on a TRS-80 model 1 or 3. Hard disk or virtual floppy (HxC2001 or Gotek) highly recommended due to high memory usage causing high cache turnover (i.e. high amount of disk usage)
; [+] Fixed up arrow key mapping (fixes zsnake.z5)
; [+] Rewrote scrolling routines to fix cosmetics
; [+] Use native DOS error messages to improve error message meaning
; [+] Multiple speed improvements across core and routines
; [+] Improved memory usage to increase cache by 2 more sectors
; [+] Bugfixes
A new release is out, with a focus primarily on speed. The core has been thoroughly rewritten (and properly aligned across the Model 1, 3 and 4 versions for my own efficiency). It’s also been thoroughly tested (thanks again to Jonathan Hoof for support, feedback and testing). Speed and code size have been improved each release. To give an idea of the improvement between this and the previous versions, I’ve timed an interaction in Zork: The Undiscovered Underground, which is much more computationally intensive than any previous infocom releases.
The timing is taken from starting in the first room of the game, using the command “look” from after you press enter, until you are prompted again. I run it twice so that it fully caches the required data, and randomness from disk I/O is excluded, and the emulator can count CPU cycles which I can divide by 2MHz. The results look like to me:
ZTUU using M3ZVM Release 3 takes 3.06s
ZTUU using M3ZVM Release 4 takes 2.71s
As a comparison:
Zork 1 R119 - using M3ZVM Release 4 takes 1.97s (down from 2.24s in Rel 3).
As the core processing code is common across the versions, the Model 4 version will have the same proportion of results operating at 4MHz, so you can halve the times.
The links are the same as above, with a summary of updates in the changelog:
; [+] Rewritten ZPC tracking for speed improvement
; Courtesy of Garry Lancaster (zxzvm for Spectrum Next)
; [+] Bugfix: now processes requests for "Stream 0"
; [+] Core code speed rewrites for text encode, call, return, branch,
; timed input, instruction decode
; [+] Rewrote memory management to improve speed
; [+] Multiple fixes to increase available cache
; [+] Synchronised core code 1/3/4
Thanks also go out to Garry Lancaster for further encouragement and ideas on optimising. If you’re a Spectrum Next user, I highly recommend checking the updates Garry Lancaster has made to ZXZVM at Garry Lancaster / zxzvm · GitLab
After posting this I had the sudden urge to go back and check a few things.
That Zork 1 timing seemed slow, so I tried an earlier release. This time, Release 75. Sure enough…
Zork 1 Rel 75 Using M3ZVM R4 takes 1.03s
Almost exactly the same for Zork 1 Release 88. What happened after the Masterpieces version?
One of the ZIL programmers here could probably explain what happens mechanically, but R119 of Zork I is a “Final Internal Release” (source: Infocom Fact Sheet). That designation can be a little misleading, as many FIRs have serious and often game-breaking problems. For instance, the diver’s hose tears for no reason in Cutthroats, Planetfall can stop listing dropped items in room descriptions, etc. Sadly, I know this from playing several FIRs unknowingly!
While I can’t say what’s different in Zork I R119, I can say that FIRs aren’t usually customized or tested for consumer audiences.
Thanks for making this resource available to the community!