News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_khaz

Is there a Z-Machine interpreter for the CPC?

Started by khaz, 16:09, 09 January 16

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

khaz

The Z-Machine is an engine designed to play text adventure games. It was originally made for the Zork series which were so popular that many new text adventure games were created for this engine. Interpreters for the game engine were ported to almost every computer, and the Z-Machine is the go-to engine when you want to make or play a text adventure game.

I see that Zork were made available to the CPC through CP/M, but I can't find an interpreted that would take external stories. The closest I've got is an interpreter for the ZX-Spectrum +3 and PCW16: Inform - ZMachine - Interpreters but nothing specifically for the CPC range.

Is there a Z-Machine interpreter for the CPC that I wasn't able to find?
or is it possible to use PC/M PCW code somehow?

GeoffB17

Well, it depends what you mean?


I've just been to a site and downloaded the zxzvm system, and yes, the package covers the Spec machines (3 and 3+ ??), the standard PCW range, and the PcW16 (essentially DOS ?).


The same site has an alternative package including the source.


The standard PCW version is pure CP/M, so if your original question was referring to a CPC running CP/M then I would assume this system will work, apart (maybe) from problems with screen size, but maybe the system doesn't make THAT much use of the extra screen size.   If you were wondering about all the extra facilities of the CPC range, colour, sound, graphics, etc, then, er, I think NO.


I see in the notes that there are some things that the PCW version does NOT do, i.e. beep ONLY, no special fonts, etc, so it does sound like plain CP/M.


One warning was issued - the prog, on starting up, will wipe your M: drive for it's own use, so make sure you've got nothing important there!!   No warning given!!   I just did a search for z-machine adventures, and found zxzvm.zip (attached).


Geoff

khaz

Yes I saw that one and I tried to make it work, but I just couldn't? Maybe I'm just doing it wrong though.

I moved the files in a .dsk with winape and started CP/M, but the executable told me I wasn't on a PCW and refused to go further.

AMSDOS

I don't know what programming tools were available to users in 1984, but I've typed in a few adventure games which were published in Multi-platform Magazines like Home Computing Weekly, Steve Lucas wrote "Castle of desolation" in July '84 which got published in HCW Sept '84, but if you go to the Games Computing page, in the October Issue is another Adventure game "Death of a Dictator" from Steve Lucas & also dated July '84, though in the November Issue there's another Adventure game of his "Visitor From Space" and dated August '84.


It makes my mind boggle just how much was written and these programs aren't exactly on the small side, if something was made to produce a working structure for an Adventure Game, I could accept that, though I haven't seen any programs along those lines & all the Adventure Games books seem to be dated 1985 onwards. Yes I suppose when I look at the code there is a similar structure to it, I can only presume these guys were able to produce a working template and build their game from around that, though July '84 is very early, since the 464 came out in June (unless there was some coders privilege going on there).
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

GeoffB17

Re 'Khaz'


I've just tried the package on my PCW, with a game I picked (from a pretty LONG list).


Sort-of worked.   The game started, accessed the game file, and was doing things.   But not properly, and VERY slowly.   Don't know why.   The process does (as per warning in my prev post) attack drive M: for it's own use, so one immed problem could by that your setup does not provide a proper M: drive.


But I had funny things happening with the screen, and when I did start getting game messages, the responses were very odd, so something not working correctly.   Maybe the game I downloaded ('across the universe') was broken?


I note the credit within the PCW version of the system refers to John Elliott (ref Joyce emulator), so could ask him about it??


Could still be worth trying to sort out, as there was a PILE of games available.


Geoff

GeoffB17

Further to the above,


Just tried another game, with a much smaller story file.   The earlier one could well have been too big for drive M:, maybe that was why it went so wrong.


The second game file seemed to work better, but it was still VERY slow.   Really TOO slow to be practical.   Don't know why it's so slow, probably the structure of the story file, and the data therein, is just seriously inefficient?


While checking up on this, I found a comment in some IF (Interactive Fiction) newsgroup discussing the z-Machine, and that also referred to this version of the z-machine, and again commented that it was 'paiiinfully slow', so it's not just me.


Maybe we need a better version of the system?   Maybe need to get the source code, and try to re-write it?


Geoff

||C|-|E||

It would be actually cool to have a proper Z-Machine interpreter for the CPC, there are tons of great games written for it. Apparently, it is very well documented, but I think that nobody tried to write something from scratch...

GeoffB17

Further again to both above.


I've been doing a bit more digging.


Yes, the Inform/z-machine system is very well documented, there are lots of systems for it, there are utilities to do things with the data files, and there are piles of games available.


Problems - there are a number of versions.   They seem NOT to be compatible.   The zxzvm system, for example, copes with versions 3, 4, 5 and 8 (8 may well be the last/latest).  I don't know why not 6 & 7?   The zxzvm system is written in z80 code, so is prob the nearest for CPC use (as opposed to running within CP/M), although you'd have a choice of altering the system for CPC, or far fewer changes for CP/M on the CPC?


I've just downloaded the z80 code (source), I'll have a look at it although I'm FAR from an assembly guru, but I do know a bit about data file manipulation, indexing, searching, etc, and my immediate interest is trying to work out why the present prog is so VERY S...L...O...W.


It need NOT be slow.


My investigation has turned up the fact that published Infocom games (CP/M examples include HH Guide and Phoebos Leather Goddess) already include a CP/M z-machine.   Both those games (which I have for the PCW) comprise a .COM and a .DAT file.   Looking inside the .COM, the two seem to be near identical, apart from the name of the data file to load (i.e. HITCHHIK and LEATHER) and maybe some other numbers near the top.   The datestamp inside the file is the same i.e. 2/5/85.   I've seen a suggestion that if you take one of these files, and change the name of another game file to match what the prog is looking for, then it will run quite happily.   BUT, I understand that these .COM files are fit for v3 of the system ONLY.   I know that the two games I have run perfectly OK on the PCW, so the fault is NOT with the system, but with the zxzvm prog (although to be fair, the games I've tried so far have been later versions - v8 - and the later version may be more complex, and therefore slower (but surely not as MUCH slower as they seem to be).


I'll have a look as the source code, see what I can make of it.   If anything?   I know nothing about the native requirements of the CPC mind you!!


Geoff

GeoffB17

More 'further to the above'...


Looking at the source code, I think my comments regarding M: are incorrect.


It looks like the zxzvm system if fact disables/deletes drive M: entirely, even to the point that the system will no longer recognise M as a valid device.   The program then, I assume, makes use of the RAM now released for it's own purposes.   Then it must re-enable M: as it exits.


The data from the game file must therefore be processed into memory.   In some way.   In the case of the first game I tried, the game (data) file was over 500k, so I assume it was not reading ALL of it?


By the way, for those interested in Z80 assembly, the .zsm files are all VERY well commented, and should be VERY instructive.   I've spotted a few bits well worth further study already!  Some of the files are specific to the Spectrum 3, other bits specific to Amstrad (PCW), there are also mentions of CPC within the code, suggesting that CPC compatibility was not completed, but was at least thought of at some stage??


Geoff

khaz

Everything is now way over my head. I'm glad that you're saying that the source is well documented, hopefully it should allow for porting without too much trouble.

I do have a tangencial question though: wasn't CP/M code hardware agnostic? As in, if you have CP/M for your computer, then CP/M software should run on it? Or do you need to tweak it, even ever so slightly, so that it can run on specific machines? I keep seeing "CP/M software" online without any specification about which hardware it can run on.

||C|-|E||

Some of the soft actually runs in different machines, yes, but some other needs to be tweaked a little bit to make it work... I am not a CP/M expert, but that is what was happening back in the day  :) .

GeoffB17

Yes.


It's always been the case that CP/M software might need the terminal/screen codes changing, for example WordStar and dBase both needed 'installation' for a particular CP/M computer.


Over and above that, there's the fact that the PCW has a larger screen than normal, 90 x 30 char rather than the usual 80 x 24.


Otherwise, yes, a CP/M prog could run on ANY CP/M computer, even if it does mess the screen up!!


Geoff

FloppySoftware

Quote from: khaz on 17:21, 11 January 16
I do have a tangencial question though: wasn't CP/M code hardware agnostic? As in, if you have CP/M for your computer, then CP/M software should run on it? Or do you need to tweak it, even ever so slightly, so that it can run on specific machines? I keep seeing "CP/M software" online without any specification about which hardware it can run on.
Humm...nice question; not so nice reply.  :laugh:

You can write a CP/M program able to run in any machine with CP/M as its OS...  :)  but only if you don't use any specific machine feature.  :o

That includes the screen, the keyboard, the...  >:(

Geoff gave you a good example. The screen control codes for the CPC and the PCW are the same (VT52 like).  :) But their screens differ in color support and dimension terms. You can run the same program in both machines, but the results will not be good.  >:(

The main advantadge of CP/M (simplicity) is sometimes its main drawback.

In order to give your CP/M software good opportunities to run in a variety of machines, you have to include an installation procedure, mainly for screen type, including control codes, color, dimensions, etc.

And, of course, write your program in a way that it can adapt itself to these changes in configuration - not so easy as it sounds.  >:(  But it's posible.  ;)

You could give a look at the source of TE, my small text editor for CP/M. I think it's a good example. The way I follow with TE is to adapt the program to the screen type in compilation time.

In this way, I can develop TE for various kind of screen / machines / OS:

Quote
Current CP/M adaptations are:                   

       
  • Amstrad PCW and CP/M Plus (31x90 VT52 like terminal).
  • Amstrad CPC and CP/M Plus (24x80 VT52 like terminal).
  • Spectrum +3 and CP/M Plus (23x51 VT52 like terminal).
  • K. Murakami's CP/M emulator (25x80 VT100/Ansi).
  • Takeda Toshiya's CP/M emulator (25x80 VT100/Ansi).
  • Generic 25x80 VT100 and WordStar keys.
  • Kaypro II, 4 and 10 (24x80 ADM-3A like terminal), contributed by Stephen S. Mitchell (thanks!).
Adaptations for other OS are:       

       
  • Windows 32 bit (25x80), compiled with Pelles C and its 'conio.h' library.
  • DOS (25x80), compiled with Turbo C, and its 'conio.h' library.
  • GNU/Linux (24x80), compiled with GCC and ncurses.
floppysoftware.es < NEW URL!!!
cpm-connections.blogspot.com.es

AMSDOS

Quote from: FloppySoftware on 23:27, 11 January 16

In order to give your CP/M software good opportunities to run in a variety of machines, you have to include an installation procedure, mainly for screen type, including control codes, color, dimensions, etc.

And, of course, write your program in a way that it can adapt itself to these changes in configuration - not so easy as it sounds.  >:(  But it's posible.  ;)


I tried this with a Generic version of Turbo Pascal 3 a few times, but never had any luck with it.  :o
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

GeoffB17

Windows does it via .ini files, although no need to worry about screen things.   Even so, there are things that may need setting, like drive assignments, preferred paths, some user defaults.


Wordstar (and I think dBase) use another method.   Coded into the start of the .com file are a group of data items, at pre-defined addresses, in which are stored the various terminal codes, etc.   Then there is an installation prog which when run will update all those settings.   The main prog, when running, uses whatever codes are set at those addresses.   The manual indicates what data is at what addresses, so you can use a hex editor to manipulate the same things if you're so inclined.


You could also use a little .ini type file, and read in the required settings, but that would need doing EVERY time you use the prog, and with floppy disks it's always possible the file may become detached, so I'd say the WordStar method is better.   I cannot remember, but I'm sure dbase II did the same. although normal operation of that system involves far fewer screen commands than WS needed.


Geoff

GeoffB17

Yet another 'following....'


I've just tried another 'game' for the zxzvm system.


The ones I'd tried before were v8 files.   They were both pretty large files, one was 500k+, the other was 200k+.
I was saying how slow they were.


The latest one is a v5 file, and it's less than 100k.


When I tried this one, I got a far more normal opening screen, and everything worked much more smoothly.   Still slow-ish, but now just about practical/tolerable.


As far as I can see, the site I was looking at had a lot of v8 games, but there were many v5 as well, and prob some even older variants.   So, the prog does work better, much better, with the older system, and also prob the smaller data file helps too.


Geoff

GeoffB17

#16
Just got a confirmation back from John Elliott.


His z-engine system cannot viably cope with v8 games.   They can contain just too much data, too many options.  Even a small one would be too slow.   v8 is a more recent format, post Infocom, and you'd need a much more powerful machine to copy.


For the zxzvm CP/M system, you should stick to v5, or even better v3 (which is what the official Infocom games available like HHGTTG and Leather Goddess are).   As noted previously, even the v5 game is a little slow, but at least it's playable.  The v3 games are reasonably smooth on the PCW, so they are much better.


One link certainly has a lot of games listed, although I don't know what they're all like.


http://ifarchive.org/indexes/if-archiveXgamesXzcode.html

Cannot get the link to work from here.   Use Google, search 'if archive zcode' and the above should be top item.


600+ games listed in the English section, but various other languages too, incl French, German, Spanish, Dutch.
Usually, the filename indicates version level, i.e. game.z8 or game.z5.


There don't seem to be any x6 or z7 games - John says that these were attempt to include graphics into the format, but they never really caught on.   Prob too machine specific, and too slow.


By the way, the 'if' relates to 'Interactive Fiction', which is the other term to use when searching for such games on the web.


Geoff

pelrun


Unfortunately the biggest problem is the Inform compiler used by nearly all non-Infocom z-machine games doesn't produce well-optimised code (the authors didn't really bother since everyone was on 'fast' PC's by then), so it's not surprising the later games crawl on old machines. Rather than avoid v8 games specifically, avoid any that are "Inform 7" games (even if they are small enough to be v4 or v5), which will be unplayably slow. Inform 6 games will perform better.

||C|-|E||

That is happening more and more with modern interpreters. Almost any PC under the sun is able to run incredibly complex text adventures even if it is slow by today´s standards...  :(

khaz

That's a shame. Would adding RAM help in this specific case?

GeoffB17

Sorry, I believe not.  It's to do with the size and complexity of the data, and the efficiency of the way it's compiled into the 'game' file.  Past a certain point, and it's just too much for the processing power of our humble Z80.


v8 it's way too much, but it tries.   v5 it manages, but you can detect the strain.   v3 and it's quite happy.   As another poster comments, the later versions of the Inform (Z-machine) compiler assumed more powerful computers, and just didn't bother so much with the efficiency of the data.   That's the fairer way to see it.   Less fair, the older programmers who knew they were working within the capabilities of the Z80 and so many k of RAM were just so much BETTER!


Geoff

reidrac

I remember Alan Cox had a "scottfree" interpreter that uses its own internal format (the games need to be converted); and it is pretty standard and portable C code (I tried to port it to my humble 8-bit microcomputer).

I should be possible to enable it to load the games from disk, although I don't know how large are those games; it might need 128K.

I'll put this in my TODO. Sounds like a nice weekend project!
Released The Return of Traxtor, Golden Tail, Magica, The Dawn of Kernel, Kitsune`s Curse, Brick Rick and Hyperdrive for the CPC.

If you like my games and want to show some appreciation, you can always buy me a coffee.

MiguelSky

Even someone made a scottfree version for tiny computers but I couldn't get it working in CPC or Spectrum: scottzx by Stefano Bodrato.

Index: if-archive/scott-adams/interpreters/scottfree

reidrac

Quote from: MiguelSky on 10:52, 15 January 16
Even someone made a scottfree version for tiny computers but I couldn't get it working in CPC or Spectrum: scottzx by Stefano Bodrato.

Index: if-archive/scott-adams/interpreters/scottfree

I'll try to give it a go this weekend.

IIRC I got the original scottfree it to compile in CC65 for the 6502 (before realising that it was a stupid idea because my microcomputer didn't have enough resources to make it run anyway), and being SDCC is more standard compliant, I guess it should be easier but I could be wrong :D
Released The Return of Traxtor, Golden Tail, Magica, The Dawn of Kernel, Kitsune`s Curse, Brick Rick and Hyperdrive for the CPC.

If you like my games and want to show some appreciation, you can always buy me a coffee.

TFM

Don't underestimate the power of the Z80. All it needs is proper memory management. All this math stuff is done quick, what really consumes time is display stuff on screen. And that's always the same for a given system.


In this case one (a person who has TIME) could take the most recent Z system and adapt it for CPC-OS like SymbOS and FutureOS where memory management is given and also a file system for more than 180 KB or so.  :)  Just my three pennies.  :)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Powered by SMFPacks Menu Editor Mod