*** M E M O R U M ***

Attached is a bug fix to my implementation of the Z-Machine for MTX CP/M.

Also included is a version (M576ZVM.COM) for machines with an additional 512K of RAM, which can load the entire story file into memory. Note this RAM is accessed directly, any RAM disk will be trashed.

To obtain a measure of relative speed, I counted the number of Z80 instructions needed to get from JP START: to CALL ZXINP The results are:

Initial port: 104,440,799
CPMZVM.COM: 28,074,923
M576ZVM.COM: 21,529,545

So the extra RAM only provides a 25% improvement over my revised virtual memory implementation.

It should be noted that the above results are using MEMU, for which disk sectors are available immediately on request. Real hardware will be worse, but should improve the advantage of the extra RAM version.

None of these versions are fast enough to be enjoyable to play I don't see any obvious further speed improvements.

I finally had a chance to try this, on the MTX plus, where I had the CPU running at 10.67mhz to ease some of the response issues

Sometime back in the early 90s I brought Lost Treasures of Infocom volume 2, so I ran some tests using the original data files.

Loading AMFV looked promising Aside from the release number, it's an almost perfect rendition compared to the original COM file running on the PC In use however there are issues None of the commands actually seem to do anything,

This was the 191222 version, the MTX plus doesn't configure the full 512k for CPM. On these tests 256k was available to CPM so I didn't test the virtual memory version.

Whether the issues relate to the MTX plus, or just AMFV, I cant tell, I'll try and find time to re-run the same tests on the real MTX later.

These test were in the colour CPM mode. There's "issues" running the mono CPM version, that is probably nothing to do with CPMZVM.

Martin,

The 191230 zip file contains a bug fixed version of CPMZVM as well as the large RAM version, M576ZVM. I suggest you try that.

I have never got very far, but certainly Zork will respond reasonably to a few commands:
This is running on MEMU, in order to be able to debug the code. And is why I wrote the MEMU Visual Debugger.

The large RAM version (M576ZVM) does not necessarily require 576KB of RAM. It actually requires 64KB for CP/M, plus the size of the story file, rounded up to the nearest 16KB. The largest valid story file is 512KB. However the program does not check that there is sufficient RAM available, it just assumes it. So you might be able to get away with that version on the MTX+ as well, depending upon the size of your story file.

The version of Zork I am running can be downloaded from:
https://ifarchive.org/indexes/if-archiv ... zcode.html

The actual file is:
https://ifarchive.org/if-archive/games/ ... dungeon.z5

The 191230 version fixes the issues with AMFV, it's now accepting commands. Since the datafile for AMFV is "only" 256k, I set the MTXplus to it's maximum for CPM of 448k and was able to run the virtual memory version. It seems to have trouble with commas as it's printing 8e instead, as this photo shows. On the MTXplus, it's playable with either version, there is a pause while the command is processed, but it's not dreadful.

now to get the MTX out....

Real MTX tests:
The 62 column display on the CFX causes display issues, which is hardly unexpected, it's scrolling far more than the interpreter expects. It's not unplayable though. The ROTT board I build last year is basically a CFX with a full memory map, so I was able to test the virtual memory version, it's got the same comma issues as noticed on the MTX plus, and as expected, the same alignment issues as CFX The CFX's low resolution means its not really suitable for long term play, so I moved on to the CFX-II
CFX-II has the 80 column output from the propeller and makes for a "proper" display. Performance isn't at all bad, the Propeller handling the display and improved disc throughput from the 8 bit interface means the game's command processing slow, bot not too slow. Though it was a long time ago, I don't recall the version of HHGG I had on the Atari 800 being super speedy.

Martin,

At the moment, I cannot even begin to imagine why one version of the software should print commas correctly and not the other

Need to be careful about which version you are calling the "virtual memory" version:

• cpmzvm.com uses only 64KB of real memory and therefore uses virtual memory, swapping bits of the story file in and out of memory, to either "swap.dat" for read / write memory, or from the story file for read-only memory.
• m567zvm.com uses the extra real memory to store the story file, and therefore does not need to use virtual memory.

OK for clarity CPMZVM.COM gives the "correct" output
M576ZVM.COM is the version that prints 8e instead of a comma.

Some further revisions to both versions of the ZVM emulator for Memotech.

The issue with M576ZVM.COM was interesting. From the Memotech FDX Technical Manual (on Dave's site):
So as I was filling each bank of RAM (48KB) with the contents of the story file, the byte at 0x0045 in each bank was being corrupted. The solution was to read the first record for each bank into common memory (above 0xC000), and then copy it into place after having read all the other records for the bank.

The revision to CPMVZM.COM was to first delete any existing SWAP.DAT file before re-creating it.

The comma issue with AMFV and M576ZVM is fixed.

Good work
But I've found another "issue" with loading and saving
if I enter "save", the game produces a "Filename" prompt, and waits for the name to be input.

When inputting "restore" to reload, the prompt is input in the wrong place, I missed it the first time and hit some random keys thinking the game had crashed. But in the photo, you can actually see the start of the word "filename" on the end of the status text. The input text for the name does appear to be in the expected place. The file itself seems to save with the last character modified or something, as I used "GAME1" for the test file (from M576ZVM). But in the directory I have just "GAME" appearing, with a non printing code, as the : separator is printed 1 space early, and has changed colour. As the rest of the line is red, is seems possibly the character code is 17. The file however does load back as "GAME1" in both versions

Martin,

Those were both "issues" I inherited from the upstream version.

• Not checking which window is selected before outputting the prompt.
• Converting the character to upper case (and 0DFh) without first checking that the character is a letter.

And you are quite right, the "invisible" character is 17: Should be fixed in the attached versions.