Zork I on an Apple I

Corey,

The interpreter itself is only around 7.5k. Once you add the needed zero page, 6502 stack, z-machine stack, keyboard/display buffer, data file block pointer buffer, etc. it requires 9k.

The individual Z-machine data files can reach up to 128k in size and do seem to be quite large. For example, Zork I is over 92k.

The interpreter loads the data file pages as necessary, however a large chunk of them are required to be in memory at all time. This will depend on which game is being played, but for Zork I the initial read-in loads around 20k before the virtual machine is started. Hitchhiker's Guide to the Galaxy takes slightly more. Once the game is started, it loads another roughly 4k to get to the mailbox in Zork I.

While I have the interpreter assembled with the end of memory just under what the CFFA1 uses for buffers/data starting at $8700, I have run it with the end of memory set at $7FFF. It loads the few games I tried. Running with the top of memory set much lower fails.

However, based on the above numbers, I think it is safe to say that it will have to have 32k to just load the game itself. In theory the z-machine could use up to 64k of non-paged memory, which means that some games may not be playable without swapping pages, or additional memory.

In short, a CFFA1 is absolutely required, but it also means that games can be saved/restored (a feature which I also have working.)

Corey,

Not quite, I have the taken Apple II version of the version 3 (rev A.) interpreter and used it as the "core" of the Apple I one. This required rewriting the DISK I/O as well as tweaking the keyboard and display sections. It wasn't difficult, but did result in my learning quite a bit about the CFFA1, ProDOS file structure, and most importantly the Z-machine system itself.

This Digital Antiquarian article has an excellent description of the z-machine, how it works, and the system requirements for running it. The numbers seem to match up quite a bit to what I referenced above in regards to memory/storage requirements.

Dave,

Yes, although individuals will need the Rev. A interpreter (generally found on the original Zork III disks for the Apple II) and the appropriate version 3 (.z3) data files for the games that they wish to play. I will look more into how to release it after VCFMW later this month.

I have uploaded a zip file containing the small "preload" code that patches and then executes the Apple II version "A" z-machine interpreter. The patches allow the interpreter to use the CFFA1 as storage as well as to properly access the display and keyboard of the Apple 1.

In order to use this, you will need three things, besides the Apple 1 (replica or emulator) and CFFA1.

1. The preload utility
2. The Apple II Infocom interpreter version "A"
3. The datafile for the Infocom game (version 3/z3 games only)

All three of these items should be placed on the compact flash card (or image) as:

PRELOAD.BIN
ZIP.BIN
INFOCOM.DAT

Using the CFFA1, load PRELOAD.BIN at $0500 and ZIP.BIN at $0800. Then quit the CFFA1 menu and execute 0500R from the Woz monitor. The preloader will patch the interpreter, and start executing it with the current game stored as INFOCOM.DAT.

preload.zip (679 bytes)

Version "A" of the interpreter can be spotted on games that when run on an Apple //e do not prompt for 40/80 columns. I found it on a version of Zork III. Using the technique found in the Infosnarf package, this can be obtained by loading the game, and at the prompt hitting reset. Move the game temporarily out of the way by issuing *4000<0800.08FFM, boot a DOS 3.3 disk without a hello program, restore the original version by using *0800<4000.40FFM, and save with BSAVE ZIP.BIN,A$800,L$1A00

The original instructions from Infosnarf can be found here: http://apple2.org.za/gswv/a2zine/Utils/InfocomProInfo.txt I found that I had to adjust the first two bytes to read D8 A9, as indicated.

Alternatively, some emulators allow the saving of memory directly, which may be easier for some individuals. Appending the ZIP.BIN to the PRELOAD.BIN can save an extra step as well.

Typically, I load the compact flash card with the following tree (using preload+zip combined as ZIP.BIN)

ZIP.BIN
GAME1/INFOCOM.DAT
GAME2/INFOCOM.DAT
GAME3/INFOCOM.DAT

This allows me to load the two bin files into memory, and then select the game with the prefix command. The interpreter will save/restore games into the current prefix as well, which allows a user to not interfere with other saved games. If saving a game fails, verify that there is sufficient space left on the Compact Flash card (or image.) Saved games should always be done to the default disk 2, although positions 0-7 can be used.

This has been run on an original Apple 1 with a CFFA1, OpenEmulator, and a modified version of the MESS emulator (to add the CFFA1.)

Thanks go to Eric Smith for his disassembly of the Apple II version "A" interpreter.

March 2018 Update: Quite a bit of work has been done lately on locating various versions of the interpreter and Infocom games. As a bit of clarification, what I have called "A" above is actually the first release of the interpreter, with no letter. Eric Smith has updated his disassembly and made it available on his github page here: https://github.com/brouhaha/a2zip

That is neat and all but I just am wondering how you emulate an apple 1 machine like that.

Max,

OpenEmulator for the Mac will allow you to emulate the Apple 1 with the CFFA1 using a fairly simple interface. I used that to develop this until I added CFFA1 support to my copy of MESS.

That is neat and all but I just am wondering how you emulate an apple 1 machine like that.

Max,

I know that this is a bit old, but with recent versions of MESS, it is possible to now emulate an apple 1 with a CFFA1. This will allow running not only the Infocom games as above but also the Ultimate Apple 1 Software Collection as well. This provides an additional option for individuals who may not have a MacOS system available.

Here's my exact response:

Hi,

I don't feel comfortable uploading those images as they contain copyright material. I posted the instructions, which others have successfully used, in order to avoid getting involved in a copyright
discussion.

I reviewed the instructions that I posted, and don't feel that I really have anything else to add
to them. They are worded in such a way that they give proper credit to the individuals who were key
to the development of the software.

I apologize for not being able to post responses to questions promptly.

It may have gotten lost in the above instructions, but you can probably load a copy of an Infocom game running the correct interpreter, halt the emulator, and then use the emulators debugger to change the two bytes at 0800 to D8 A9.

Then save the entire block of memory from 0800 through 21FF (1A00 bytes.) How this is done will likely depend heavily on which emulator you are using.

This will give you the ZIP.BIN file.

This is probably going to be much simpler than the infosnarf method.

While I've not done this with mess/mame, I think that the save command executed after changing the two bytes within the debugger would be:

save ZIP.BIN,0800,1A00

Remember that ZIP.BIN needs to be loaded using the CFFA menu at $0800, and the PRELOAD.BIN file needs to be loaded at $0500.

The INFOCOM.DAT game file needs to be in the current directory. Game files can be obtained in a number of different ways. You'll need to do some research as I just used one that I already had from another project.