search

dankreek / zfun

Python Z-Machine interpreter library
0 stars 0 forks source link

Design Question: Are Header Classes Necessary? #6

Closed jeffnyman closed 4 years ago

jeffnyman commented 4 years ago

This is not a bug; just a question on the implementation and design rationale. And note: this is truly a question, not a critique.

I see that the ZCodeHeader serves as an abstract class so that you can have individual classes for the header based on version. However, looking at the Z-Machine specification, it looks like when a version is specified then it means "the earliest version to which the rule is applicable." Which means, for example, if some feature in the header says "2" in the specification, it means "2 and up."

What this seems to suggest is that the header will largely be the same except for a few small things dealing with versions 1 and 2 and maybe a few things in version 6. Which means it seems one header class would simplify the design, assuming that it had checks for the version. This is as opposed to the complication (if such it be) of having multiple classes based on an abstract class.

Yours is one of the few (if only) implementations that I've seen taking this approach and so I'm definitely curious about the design choice.

dankreek commented 4 years ago

Oh wow, thanks for the inquiry! So, honestly this project is just me kind of figuring out how to the z-machine all works in preparation for making an interpreter for the Commodore 128. (Bored in quarantine.)

So my initial thoughts there were to make the code changes between versions very obvious to myself when it came time to start the pains-taking process of writing 6502 assembler, so I took this approach.

But design-wise, yes I agree with you there, the Header classes are a bit of a mess.

jeffnyman commented 4 years ago

Perfect! Thank you; that's great context. I actually started re-working your project without the multiple classes and that was mainly what led me to ask. It's very cool to hear about the C128 project.

In fact, I'm building material for a class on teaching programming and I'm going to use emulator/interpreter design as the focus. Needless to say, I'll be using the Z-Machine for this and, like yourself, I will be using Python as well. Mine will be a very pedagogical example -- as opposed to say a performant or optimized one -- so I'm actively investigating different approaches in Python in this regard.

I'll definitely be watching your future developments here. Kudos to us for putting our quarantine time to good use! I'll close this question just to get it out of your active board.

dankreek commented 4 years ago

It's funny, this message inspired me to take another gander at that source file, and jeeze, yeah, what a mess!!! Honestly if you want to put up a PR for your changes I would love to take a look at it.

The C128 project was inspired by a couple things. First, the C128 interpreter made by Infocom is really awful. The load times are horrendous and every time you die (which is a lot with Infocom) the whole game has to reload again. I'm not sure if you've seen Pitch Dark, the Apple II Z-Machine interpreter, but I was fiddling with it on an emulator and got kind of jealous. It runs GREAT and the emulated hardware has the same specs and processor as a stock C128! As a Commodore nerd, I find this to be a grave injustice!

Infocom also stopped making games for 8-bit Commodores after Trinity, I believe, so it would be cool to have support for all Infocom titles as well as the vast library of community-developed Interactive Fiction available now.