This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Famicom Z-machine Interpreter

Famicom Z-machine Interpreter
by on (#111262)
Is there a Z-machine interpreter for Famicom? Anyways, it has a keyboard (unlike GameBoy). What mapper is needed, or can it use FDS? But, since it has keyboard it means you can just type it in rather than how it is done in GameBoy and so on.

However, the Famicom keyboard has only ASCII codes $20 to $5F, not $60 to $7E. I can make a suggestion to allow working: SHIFT key already toggles bit4 of ASCII codes $20 to $3F. Therefore, make SHIFT key also toggles bit5 of ASCII codes $40 to $7F. (Actually, this is a useful idea if you make any program on Famicom that is using all ASCII codes; it is not specific to Z-machine interpreter!)

Alternative way is make a system for text adventure game which is compatible with Famicom and which can compiles into iNES format and into Z-machine format independently. For example, you might do: $00xx = Global variables. $6xyy = RAM properties (x) of objects (y). $8xyy = ROM properties (x) of rooms (y). $9xyy = ROM properties (x) of objects (y). $Axyy = Initial value of RAM properties (x) of objects (y). When compiling into Z-machine format, you can use the addresses of Z-machine instead.
Re: Famicom Z-machine Interpreter
by on (#111267)
I'm pretty certain the only licensed things to ever use the keyboard were the releases of BASIC. Unlicensed stuff includes the Dr. PC Jr BIOS.

All mappers should work—the keyboard just plugs into the FC expansion port.
Re: Famicom Z-machine Interpreter
by on (#111268)
lidnariq wrote:
I'm pretty certain the only licensed things to ever use the keyboard were the releases of BASIC. Unlicensed stuff includes the Dr. PC Jr BIOS.
I do mean an unlicensed program of course; possibly written these days if anyone want to do so.

lidnariq wrote:
All mappers should work—the keyboard just plugs into the FC expansion port.
I know all mappers will work with the keyboard. I meant what mapper is suitable for the memory format of Z-machine.
Re: Famicom Z-machine Interpreter
by on (#111277)
lidnariq wrote:
I'm pretty certain the only licensed things to ever use the keyboard were the releases of BASIC.

Correct in general, but at least a certain licensed game does use it for activating the debug mode. The obscurity of how to do this made this feature unknown for years.
Re: Famicom Z-machine Interpreter
by on (#111304)
zzo38 wrote:
I know all mappers will work with the keyboard. I meant what mapper is suitable for the memory format of Z-machine.

Briefly looking, there's a port to the gameboy, so something like UNROM should be good enough, but the Z-machine requires a linear memory map in a 16-bit space, ascending from 0; you'd have to emulate the memory model entirely. I'd probably personally start off with an NROM build and worry about mapper hardware later. (Alternatively, if you wanted to achieve a resolution higher than ≈30x26 onscreen, you might consider using m96 and soft-rendering text)

There's also existing Z-machine interpreters for the Apple][ and one of dubious legality for the C64; neither of those solve the part where you either need to relocate everything or emulate the memory model.
Re: Famicom Z-machine Interpreter
by on (#111307)
From what I read this morning about how the Z-machine works, there's a divide between "dynamic memory" (RAM) and "static memory" and "high memory" (ROM). Much of the NES's internal RAM would be reserved for the Z-machine's stack and global variables, and "dynamic memory" would need to go in PRG RAM on the cartridge. How much "dynamic memory" do Z-machine games use?
Re: Famicom Z-machine Interpreter
by on (#111309)
tepples wrote:
How much "dynamic memory" do Z-machine games use?
The maximum dynamic+static is 64K (128K in my own version 9 specification, but no version 9 games exist), but most games probably use a lot less than that (the header specifies how much dynamic memory is used and how much static memory is used). Also, the high memory contains only program instructions and text strings; not arbitrary data. Dynamic and static memory can also contain program instructions and text strings, but they can contain other data too.

lidnariq wrote:
There's also existing Z-machine interpreters for the Apple][ and one of dubious legality for the C64; neither of those solve the part where you either need to relocate everything or emulate the memory model.
I am aware of these Z-machine interpreters (although I have never seen them), which is part of what made me to think of this, and I know that to solve the memory model on Famicom you will need the proper mapper to do so.

Of course it can be possible to make limited interpreter that does not support too large Z-machine files, too.

Possibly the program can be used to figure out the Z-machine version, RAM/ROM sizes, etc from the header and then make the iNES ROM image file from that, using the mappers which are suitable (possibly the user could specify the mapper); most Z-machine interpreters treat 0OP:191 as an unconditional branch, but with some mappers it may be possible to use the copy protection features of the mapper to determine whether or not it should branch (no Z-machine games use this instruction anyways, but it might be included for completion) (if a mapper is selected that doesn't have this feature, it can be treated as an unconditional branch).
Re: Famicom Z-machine Interpreter
by on (#111462)
MMC5 seems to have enough features to implement most of the Z-machine stuff; division would still need to be implemented in software, though. Even the scanline counter can be used for window splitting, the hardware multiplication can be used to implement 2OP:22, the extra attribute table in ExRAM could be used to make text bold, italic, reverse video, runes, etc (since not all of the ExRAM is used for this purpose, some can be used for additional stuff, together with the Famicom's internal RAM, to store the stack and so on). Z-machine also requires the initial contents of RAM also needs to be stored in the ROM, and the static memory should probably also be copied to RAM since that would probably simplify the program logic (high memory won't fit and doesn't need to be in the same memory space anyways since it is accessed differently; high memory in the Z-machine can only contain routines and encoded text strings). Because the Famicom is a slow computer similar to Commodore 64, the interpreter number should probably be set to 8 for this purpose. Do you know if Commodore 64 uses Amiga runes or PC runes for Font 3? If Font 3 is implemented, this should be used.