Infocom adventures

[fuzzel]

Did anybody every attempt to port a version of one of the Infocom games to the bbc ?
Zork would have been brilliant, there weren't a huge number of locations so I suppose it would have been possible to squeeze it in.

[sweh]

Does this help?

http://www.retrosoftware.co.uk/wiki/ind ... r_informz3

[fuzzel]

Yeah, it sounds like the standard 32k beeb doesn't have enough memory to accommodate the interpreter / finished program.
The better option would be to reverse-engineer the game and maybe reduce the game text if I run out of memory. I think I'll start work on a BBC basic version and develop my own adventure system in the process.
Would it be worth me uploading a work in progress for feedback at some future date?

[hoglet]

Did anybody every attempt to port a version of one of the Infocom games to the bbc ?
Zork would have been brilliant, there weren't a huge number of locations so I suppose it would have been possible to squeeze it in.

It's possible to run them under CP/M with a Z80 Co Processor.

Here's Zork 2 and 3:
http://www.stardot.org.uk/forums/viewto ... 62#p107162

And here's Hitchhiker's Guide to the Galaxy and Planetfall:
http://www.stardot.org.uk/forums/viewto ... 32#p100432

Dave

[sweh]

The better option would be to reverse-engineer the game and maybe reduce the game text if I run out of memory.

Or perhaps do a "paging" solution where subsets of the data are loaded from disk as needed. SSDs would make it pretty quick, and even real floppies would likely be fast enough.

[poink]

Or perhaps do a "paging" solution where subsets of the data are loaded from disk as needed. SSDs would make it pretty quick, and even real floppies would likely be fast enough.

Yes, should be pretty practical considering that you've already got the z-machine as an abstraction layer. Also, there's just targetting Beebs with sideways RAM: if you can fit it into the Z80 second processor, it should definitely fit it into the Master series machines.

[hexwab]

Yes. https://github.com/hexwab/zeugma .

It's pretty lacking still. No split screen, no word wrap, no saving, no undo, no restart.
(This explains the included game, which doesn't require any of these...)
Somehow I haven't quite got round to implementing all the features that would turn this into a usable environment. Not to mention optimization. Then there's fun things like proportional fonts...

Still, it does work, even on a model B. And the fact that someone is interested might revive my interest.

[EdwardianDuck]

This has surfaced recently (via https://intfiction.org/t/infocom-z-code ... ters/65741) https://github.com/erkyrath/infocom-zco ... ster/acorn.

Given that we have Ozmoo, it's perhaps only of historical interest.

Source code for other platforms has also surfaced https://github.com/erkyrath/infocom-zco ... ree/master.

I haven't looked into any of it closely.

Jeremy

[EdwardianDuck]

More for something to do than there being any real point, I did convert the Acorn ZIP source code to CA65, get it to assemble and fudge together a disk image using a small game from elsewhere (my game didn't work). It starts up, displays the initial blurb and gets as far as the prompt, but crashes when I try something simple like examining an object.

Possibly I've messed something up in the conversion. Hopefully I'll have time to experiment further tomorrow.

Jeremy

[SteveF]

This is fascinating, and thanks very much for having a go at building it. It would be cool to see this working!

[EdwardianDuck]

Success (for some value of "success").

Conversion to CA65 was relatively straightforward. This is old-school 6502 with nothing fancy like macros, so conversion was little more than replace EQU with =, DB with .byte, DW with .word, ORG with .org and INCLUD with .include. There might have been a few other bits, but that was the bulk of it. I also commented out the PAGE, TITLE, SBTTL and END directives, which are just cosmetic.

There is one obvious bug in the source (lines 349 & 350 of zdos.asm) but that's not too important and it's obvious how to fix it. Line 350 starts with an "odd" character, so perhaps the error is line noise / data loss from a serial connection?

The build is atypical for CA65 because of the use of .org ($1100). Normally one sets this during the link process.

The strange aspect is how the game data is stored on the disk. It's written directly to the tracks starting from track 4. OK, that's not all that strange, but it only uses 8 sectors out of 10 per track, the last two on each track are skipped. According to a comment in the code, this was done to make the math easier! I used a very rough C# program (DotNet core) to write the data after building a disk image with the program.

Attached are two disk images.

ZipTest.ssd isn't a game, it's some basic unit tests taken from the GitHub repository linked above.
MiniZork.ssd is what it says. I've played a few moves. Try $VERIFY.

It's been a struggle to find .z3 files which work. My game (Duck! Me?) doesn't work (too big for the disk) and neither does a small game called Locked (search AtariAge for this, it's a basic one location escape room game). Locked prints its banner but fails after you enter any command complaining about invalid opcodes. My guess is that this is a very early interpreter version and Inform6/PunyInform is using some more modern opcodes. Of perhaps it's something else and the error number is spurious. Realistically I don't have the skills to diagnose this.

The interpreter is <6Kb and is started with the *ZIP command. There is code in the repository to make a bootable disk, but I didn't bother with that.

Jeremy

[KenLowe]

Awesome. Just given it a quick test, and it's loading up nicely!

[EdwardianDuck]

I've roughly packaged up the CA65 & C# source. See build.sh and Program.cs for the build process. Also in the archive is zip.txt, which is the CA65 listing file from the build.

Note that build.sh uses my homebrew disk image writer. If you're doing this yourself, you'll need to use your preferred disk imager.

Program.cs should be trivial to port to your modern language of choice.

It's all very quick & dirty I'm afraid.

Jeremy

[EdwardianDuck]

Quick update. The code as found tramples over low memory to some extent, starting from $500 it needs $600 bytes. As an unrealistic test I changed $500 to $1900 which means the code starts at an eye-watering $1F00. However, this does enable a small game like Locked to run, albeit rather slowly. It's a short game, I was able to complete it. Duck! Me? falls over with an out of memory error code, so there's not enough memory left to load the resident portion of the game. While this isn't terribly practical, given that we have Ozmoo, it does at least demonstrate that it can in theory run a game written using Inform6 & PunyInform.

It's been an interesting weekend project. If there's any interest, I can poke around a bit more and figure out how to allocate the memory to avoid issues with newer (most?) games.

Jeremy

[SteveF]

Success (for some value of "success").

Congratulations, this is neat!

The interpreter is <6Kb

That's quite a bit smaller than Ozmoo - unless I'm getting confused, a quick test build shows ~11K for a Z3 Acorn Ozmoo interpreter (edit: this includes 1K for the Z-machine stack, so maybe 10K would be a fairer comparison). Ozmoo deliberately doesn't target the smallest possible systems, and it does offer all sorts of niceties, but for running on a 32K machine with no sideways RAM, this interpreter might (depending how well it's been optimised, of course) offer a better experience as it can presumably cache more game data in memory.

The 8 sectors per track thing is intriguing. Sure, it is a bit annoying to divide by 10 in machine code, but the Z-machine itself requires a division routine anyway so it's not as if this would take that much more code. I guess this comes with the prototype-y nature. Maybe there was also an idea the disc would actually be formatted with only 8 sectors per track on those tracks as a copy protection measure?

[EdwardianDuck]

In terms of memory abuse, the code as found tramples over the sound workspace, then makes a sound by printing the BELL character, which I assume in turn tramples over ZIP's workspace. As ZIP's stack overlaps the sound workspace, chaos ensues depending on stack usage. Changing the memory map to avoid this area seems to resolve the problem (at least sufficiently to allow Cloak Of Darkness from the PunyInform distribution to run with ZIP at $1100 (which is the default in the code).

Getting Duck! Me? to run* requires running ZIP at $E00 on a Master 128. Even then, it only just fits.

* by "run" I mean crawl along at the pace of an arthritic sloth, it's unplayably slow. It must be swapping a lot.

How practical is this? Hard to be sure, it's OK for a small game and would be better if the code ran from a sideways ROM image to free up more main RAM, but there's some self-modification going on, so perhaps not. From my perspective, this is a historical artifact rather something I plan to put much more effort into, due to limits on my time and talent.

At first glance I'm not seeing a lot of optimisation in the code, but again, I'm talent limited and could well be missing all sorts of stuff.

Jeremy

[SteveF]

Getting Duck! Me? to run* requires running ZIP at $E00 on a Master 128. Even then, it only just fits.

* by "run" I mean crawl along at the pace of an arthritic sloth, it's unplayably slow. It must be swapping a lot.

It might be impractical, but it's still cool that you got this to work!

How practical is this? Hard to be sure, it's OK for a small game and would be better if the code ran from a sideways ROM image to free up more main RAM, but there's some self-modification going on, so perhaps not. From my perspective, this is a historical artifact rather something I plan to put much more effort into, due to limits on my time and talent.

I'm sure you're right - this is interesting more for historical reasons than anything else. If someone did want to run Z-code games on "small" (32K, maybe 48K too) machines better than Ozmoo will, the other Z-code interpreters written for the Beeb over the years would probably do a better job, and I wouldn't be surprised if there are some other modern 6502 interpreters for non-Acorn systems that could be ported which have probably had more optimisation done than this interpreter. (Not to mention that I suspect the vast majority of modern hobbyists will have at least 16K of sideways RAM, and it isn't a hard-to-find, expensive or "historically inauthentic" upgrade if someone wants it. So running Z-code games on a 32K machine is probably more for the challenge than for any real reason.)

[EdwardianDuck]

As a quick test I packaged up the original 1980 Zork 1. It runs, but slowly. The resident portion is about 19Kb, which doesn't leave more than 1-2Kb (I haven't figured it out exactly) for the rest, so there's a lot of swapping.

This ties up with this document from the Infocom archives.

https://archive.org/details/InfocomCabi ... up?q=acorn

Which is interesting. It's the only match for "acorn".

Jeremy

[EdwardianDuck]

If Infocom had released the games listed in the document from the Infocom archives for the BBC Model B at the time, what would that have looked like?

Well, probably a bit like the attached.

Some of the games have many variations, so I've guessed based on the dates/serial numbers. The demo/sampler is excluded as it's not really clear what that relates to and the examples I've found tend to crash after the initial infodump.

Jeremy

[EdwardianDuck]

More for my own amusement than anything else, I've started poking around in the code, looking for issues and things which one might optimise. Of course, by the time this was written, Infocom's 6502 interpreter must have been pretty robust and it shares a lot of code with other 6502 platforms (at first glance). So far I've eliminated a couple of bits of self-modifying code with a view to perhaps building a SW ROM image to free up more swap space. I've also replaced [ & ] with ( & ) in the character printing routine because the interpreter only runs in MODE 7 because of memory constraints.

Also, more generally, it's interesting looking at how the interpreter works.

Jeremy

[Lardo Boffin]

I expect this has been posted somewhere already but this showed up in my inbox today:

https://arstechnica.com/gaming/2023/11/ ... een-found/

[derek]

Hi,

There is Acorn Source Code in this Guthub Repository for Infocom X Interrpreters.
https://github.com/erkyrath/infocom-zcode-terps

I also use ZIP on a Sinclair QL, for Z5 games only,many games to play.

[fuzzel]

If Infocom had released the games listed in the document from the Infocom archives for the BBC Model B at the time, what would that have looked like?

Well, probably a bit like the attached.

Some of the games have many variations, so I've guessed based on the dates/serial numbers. The demo/sampler is excluded as it's not really clear what that relates to and the examples I've found tend to crash after the initial infodump.

Jeremy

These look absolutely amazing! On a beeb emulator at speed x 2 they're pretty fast compared to other machines (except perhaps DOS on a modern PC) and well a worth a play - provided of course that they work and are bug-free?

[EdwardianDuck]

I've no idea if/how buggy this might be. By the time this was presumably written, the 6502 interpreter would have been quite mature, so my guess based on no real information, is that any bugs or sub-optimal coding will be in the machine specific parts. I did spot one instance of two ZP variables overlapping.

This evening I've been fiddling about with the machine specific bits, looking for easy optimisations. Changing the way text is printed and the screen cleared has saved about 119 bytes. That's enough to move the code size below a page break, freeing up a whole 1 page for swap space.

I'd need to recover another 170 bytes to get a second extra page for swap space. That seems optimistic.

On the negative side, the way some text is formatted for printing requires changing the strings in place, so that's annoying if one wanted to produce a SW ROM of the interpreter to free up more space for games with a larger preload and/or more swap space.

As ever, this is just me pottering about for my own amusement/understanding. For best results, use OZMOO instead.

Jeremy

[tricky]

Is it likely to run on a second processor where page would be lower and the CPU faster?

Does ozmoo?

I had a brief look at porting DAAD but that is as far as I have got with adventure runtimes.

[EdwardianDuck]

Probably not as it stands because of the amount of low memory it tramples over.

OZMOO will run on a 2nd processor and is the recommended* solution for playing Z3 and Z5 games on the BBC. The Infocom ZIP interpreter for the BBC is Z3 only.

Just to be absolutely clear here, I'm not trying to compete with OZMOO in any way, shape or form.

Jeremy

*by me, that is.

[SteveF]

OZMOO will run on a 2nd processor and is the recommended* solution
[...]
*by me, that is.

Thanks Jeremy!

I'm glad you're taking a look at this code; it's been interesting to read your comments on it so far. If you do (and I appreciate you may not) feel inclined to keep working on it, I could see some potential uses for it (aside from its significant historical interest [1]) which would complement Ozmoo:

• As previously discussed, this may run better on 32K machines than Ozmoo.
• You could consider targetting machines with just 16K of sideways RAM. Because this gives a fairly simple flat address space with no paging (you just need to take care when loading data from disc into sideways RAM), it might not be that complicated - both to implement, and also might be faster at runtime.
• You could target Electrons with just 16K of sideways RAM. Ozmoo runs from main RAM and uses sideways RAM only for data. Running code in main RAM comes with a speed penalty on the Electron. If this interpreter could be built to run in sideways RAM, it could be significantly faster on an Electron than Ozmoo is, even if the two interpreters are otherwise comparable in performance.

Not that competing would be a bad thing if you or anyone else did feel so inclined, IMO. That way the two interpreters can steal ideas off each other and both improve.

[1] Running the games from your "what could have been" version is somehow cooler than I think anything modern ever could be.

[EdwardianDuck]

The attached archive contains a SWROM image (zip.bin). Using B2 and a Model B configuration I have this "installed" in one of the sideways ROM banks. (the file is also on the disk image as INFOCOM, you can *SRLOAD INFOCOM 8000 7 Q, then Control+Break to register it if you're using a Master 128).

Mount the disk image (Zork 1) in drive 0, then use *INFOCOM to start the game.

Zork 1 is now running on a Model B with 8Kb of swap space, which makes things smoother / more practical.

The game is still written to the disk image using the 8/10 sector layout, so the previously uploaded images will still work with the SWROM interpreter.

Just to be clear, it's all very hacky at this point in time.

Memory usage as follows:

ZP = $8A bytes (ZIP stores pretty much all it's variables in ZP)
Stack & Paging = $400 starting at $400
Other workspace = $191 bytes starting at $A00
Code = $1649 bytes starting at $8000
Data = $2DC bytes following on after the code (split out from being scattered throughout the code in the source as found)

Game data is now being loaded at $1100 which is where Infocom had loaded the interpreter.

This won't work on an Electron, the code assumes mode 7 is supported and hard codes dealing with it.

Probably the next step for me is to modernise the code so that it's a bit easier for me to understand.

Jeremy

[vexorg]

How big is zork, there' are varying reports on actual size.

If it's going to be a cut down version for the bbc, is there any real point, as you'll get emulators for PDP-10, or any other platform it did run on.

[EdwardianDuck]

OK, no problem, I'll stop working on it.