PunyInform and Ozmoo

[SteveF]

Thanks Fredrik! I've just given this a test and it as well as the new title/subtitle options work nicely.

[SteveF]

I'm pleased to announce Acorn Ozmoo 14.22 (alpha 52). As always thanks to Johan and Fredrik for their continued work on Ozmoo.

So what's new? This is mostly a bugfix and small tweak/optimisation release. The main thing I want to point out here is that save files from this version of Ozmoo may not be compatible with ones from earlier versions and vice-versa. There are more details on this below. Apart from that, read on for more details of the changes if you're interested, but otherwise please just give this a test and let me know how you get on. It hasn't changed that much internally but there have been enough changes that I think it's safer to call this an alpha, so that's what I've done.

I added an --x-for-examine option to Acorn Ozmoo a while back. This added code to internally twiddle user commands so you can type things like "X STATUE" instead of "EXAMINE STATUE" even if the game doesn't understand "X" as a verb. This has now been merged and improved upstream, and I've ported the upstream version back to Acorn Ozmoo. It now works for all Z-machine versions, not just 1-4.

I've also ported an upstream change which automatically enables --x-for-examine if it recognises an Infocom game which doesn't natively support an "X" verb. You can override this behaviour by specifying --no-special-game-check if it causes you problems. (The main reason to disable it would be if you're interested in running on machines with very limited RAM and don't want to waste memory on the extra code to support this.) --no-special-game-check also disables the long-standing automatic patching of Trinity and Beyond Zork to work better in 40 column modes.

Save files from this version of Ozmoo may not be compatible with ones from earlier versions and vice-versa. You may get away with this, perhaps even most of the time, but I'd really advise against relying on it. On older versions of Ozmoo, it's possible that a game saved on one machine would not restore correctly on another, even using the exact same game disc. The technical background to this is that when I originally ported Ozmoo to the Acorn machines, I had to adjust the behaviour of save/restore to allow for the fact the Z-machine stack doesn't have a fixed memory address on Acorn machines, because PAGE can vary. Because I'm not a Z-machine expert, I missed the need to tweak the behaviour of the throw/catch opcodes to accommodate this as well. Upstream Ozmoo now contains logic to handle a variable stack location and so this has been implemented properly upstream and I've ported the change across to Acorn.

Older versions of Acorn Ozmoo used an incorrect value for the number of lines on the screen for version 1 and 2 games; this has now been fixed. This was probably an Acorn-specific bug I introduced at some point and which I happened to notice during the merge, but I haven't dug through the git history to confirm this.

I have fixed some relatively obscure bugs in the loader's calculation of available memory and which modes, if any, the game can run in. Information given on how much extra memory you need when the game doesn't have enough should also be slightly more accurate. It was possible that with the previous release the game would offer to run in some screen modes but would then hang if you tried to do this. I doubt anyone has actually been affected by this, but it's obviously good to fix it. (I believe triggering this bug would need all of 1) a game with <=16K dynamic memory 2) running on a machine with no shadow RAM 3) where you force the build to use the big dynamic memory model instead of the default medium model used for no shadow RAM builds 4) PAGE just right so the game and stack fit perfectly into main RAM and are immediately followed by screen RAM with no gap at all.)

Text printing has been optimised; I finally picked up a change made by upstream in (I think) release 11, which I had misunderstood and not ported across. This doesn't make a huge difference, but the difference is measurable in the benchmark at least. (In technical terms, when printing an entire line of buffered text all but the last character on the line is sent more-or-less directly to OSWRCH instead of going through the internal printchar routine, which saves a little bit of overhead.)

A new --no-integra-b-private-ram option is available which will cause Ozmoo to avoid using the Integra-B private RAM. This does not disable other Integra-B support, so Integra-B shadow and sideways RAM will still be used even if this option is specified.

Edit: I forgot to mention that (thanks to Fredrik asking) make-acorn.py now removes all the temporary files it created inside "temp" by default. You can specify --save-temps if you want to keep them. Because I'm paranoid about accidentally deleting something that isn't a temporary file, it doesn't wipe everything inside the temp directory - it just wipes things it created at the end of the build. This will probably still happen if the build fails or dies unexpectedly, but it is possible files will accumulate gradually over time, and files left over after using --save-temps will not get removed on the next run without --save-temps.

It is also (again at Fredrik's suggestion) now possible to run make-acorn.py without it being in the current directory.

[shifters74]

Thanks SteveF!

I use integra-B on my machine so thats a nice update!

thanks

Shifters

[SteveF]

Thanks Shifters!

I forgot to mention some changes Fredrik requested in my release post, so I've gone back and added them.

[EdwardianDuck]

I managed to find a small problem with the latest release.

In templates/loader.bas, it's missing a closing double quote at the end of line 269.

Code: Select all

DEF FNshadow_extra
IF shadow_state=${shadow_state_screen_only} THEN ="(screen only)

This causes beebasm to throw an error when using PUTBASIC. Appending a double quote above fixes the issue.

I'll run through my port of "Planet Of Death" through the latest version.

Jeremy

[EdwardianDuck]

I'll run through my port of "Planet Of Death" through the latest version.

Which, being an undemanding game, worked as expected.

[SteveF]

Thanks for testing and fixing that Jeremy, much appreciated. I've tagged up alpha 53 with this fix. I'm glad it works for your game - I also did a test build of it myself and it is even just about playable on a 32K machine (built with --try-support-32k), which is nice.

Edit: It's interesting and useful to know that beebasm's PUTBASIC is doing some extra validation here. I posted over in the development tools forum about this.

Edit: Oops, I broke my neck in the ravine. A proper old-school game!

[SteveF]

I've just tagged up 14.22 alpha 54. This tweaks the !BOOT file to avoid showing CHAIN "LOADER" so prominently - I am 99% confident this change won't break anything but would appreciate any testing, especially with third party shadow RAM on the BBC B/Electron. I have also fixed some glitches with the ReCo6502 (at least as emulated in b-em), which would fail to run games built with turbo support and would report nonsense times for the benchmark because Acorn Ozmoo's code relied on 6502-only behaviour (the ReCo6502 uses a 65816).

I've attempted to keep a more detailed changelog than usual and you can see it here if you're interested.

[hoglet]

I have also fixed some glitches with the ReCo6502 (at least as emulated in b-em), which would fail to run games built with turbo support and would report nonsense times for the benchmark because Acorn Ozmoo's code relied on 6502-only behaviour (the ReCo6502 uses a 65816).

FYI, on a real 65C816 the ABS,X addressing mode does not wrap from 0xFFxx back to page zero. This is one of the few cases where 65C816 emulation mode doesn't match a real 65C02, see Bruce Clark's excellent document here:
http://6502.org/tutorials/65c816opcodes.html#5.3

[SteveF]

Thanks Dave, it's good to know this is how real hardware behaves. I used the zp,X "workaround" mentioned on that page too, which means a 6502 second processor has code one byte shorter than it used to as well.

[fredrikr]

I've tried to make Ozmoo Online more useful - I put the PunyInorm games which currently have the highest ratings, in the Story file dropdown list. Also, I added descriptions for these games. Have a look, at https://ozmoo.online (I don't link directly to the Acorn page, because I prefer the top link to be spread, and get a better rating with Google etc)

[KenLowe]

A new --no-integra-b-private-ram option is available which will cause Ozmoo to avoid using the Integra-B private RAM. This does not disable other Integra-B support, so Integra-B shadow and sideways RAM will still be used even if this option is specified.

Out of interest, what was the driver for adding this switch?

FYI, I'm just getting my PiFS prepared for the TNMoC Econet party this weekend, and I've included a number of Ozmoo games in the line up. I'm currently using Alpha 51 and whilst doing some testing I've noticed that Zork 1 Save / Restore isn't working. The machine just hangs when I enter SAVE or RESTORE. Other Ozmoo games are ok. Was there a known issue? I'll try updating it to the latest Alpha 54 to see if that fixes it.

I *think* this is the version I've got on the server:

Code: Select all

python make-acorn.py --splash-image=..\downloads\zork-1-wip-4.scr --splash-mode=1 -a -p --title "Zork1: The Great Underground Empire" ..\downloads\zork1-invclues-r52-s871125.z5 ..\Disk_Images\ADFS_Images\_Zork1.adf

[SteveF]

Hi Ken,

Out of interest, what was the driver for adding this switch?

Nothing special, it's just there in case something else is using the private RAM. The automatic detection should usually catch this anyway, so it's mainly for debugging.

FYI, I'm just getting my PiFS prepared for the TNMoC Econet party this weekend, and I've included a number of Ozmoo games in the line up. I'm currently using Alpha 51 and whilst doing some testing I've noticed that Zork 1 Save / Restore isn't working. The machine just hangs when I enter SAVE or RESTORE. Other Ozmoo games are ok. Was there a known issue? I'll try updating it to the latest Alpha 54 to see if that fixes it.

Great to see Ozmoo will be available at the Econet party, thanks for doing that!

I'm not aware of any specific issues but this obviously isn't good. I've tested with alpha 54 and it has a couple of embarrassing build errors on this game, which I've now fixed in alpha 55, so please give that a try. (There are a few extra details in the changelog if anyone is interested.)

I grabbed that file myself, is this the version you have?

Code: Select all

$ sha256sum games/zork1-invclues-r52-s871125.z5 
07ba90fc9f214fba9532228a3c0ba1230eeeacf5b8dfad5d9d721762aaa5f9b4  games/zork1-invclues-r52-s871125.z5

I built it with alpha 55 and did a simple save/restore test and it did work, but that's not to say something got fixed - this may be one of those bugs which has a complex interplay with the precise main/shadow/sideways RAM settings and can easily disappear with a different build. The tweak to throw/catch in 14.22 alpha 52 or its omission in alpha 51 shouldn't be the issue here - I think it could cause a restore to fail, but it shouldn't cause the save to fail. It's also odd - and in some ways reassuring, as it takes some fiddly code to actually do the save/load out of the picture - that it hangs when you enter SAVE or RESTORE, rather than giving you a chance to enter the filename first.

I will continue to do a little bit of playing around to see if I can get this to go wrong (I may try alpha 51 too) and see what's up but I don't know if I will be able to reproduce it or not. Edit: I just built this game with alpha 51 and it passed a simple save/restore test, so I suspect the bug you hit only manifests on certain machine configurations. Just for the record - not because it's terribly typical - I tested with a b-em BBC B with 144K sideways RAM in banks 0-9, Acorn DFS 2.26, PAGE at &1C00 (because the GXR is enabled) and running in mode 7.

I'm sure you're busy with the party prep but if you do try this please let me know how you get on, and if it does go wrong please let me have as much detail about the machine and its configuration as you can - the OSMODE if it's Integra-B, the sideways RAM config, the value of PAGE, the screen mode, whether there's a co-pro or not and ideally a screenshot of the technical details you get if you hold down the CTRL key while the game is loading after the initial menu. Edit: If alpha 55 works but you can provide similar details for the failing version of alpha 51 I can try to take a look at that - if I can reproduce it there it may reveal a bug which I can then fix in the latest alpha even if we're not able to persuade it to manifest there.

[KenLowe]

I grabbed that file myself, is this the version you have?

Code: Select all

$ sha256sum games/zork1-invclues-r52-s871125.z5 
07ba90fc9f214fba9532228a3c0ba1230eeeacf5b8dfad5d9d721762aaa5f9b4  games/zork1-invclues-r52-s871125.z5

Yup:

Code: Select all

c:\Ozmoo\downloads>certutil -hashfile zork1-invclues-r52-s871125.z5 sha256
SHA256 hash of zork1-invclues-r52-s871125.z5:
07ba90fc9f214fba9532228a3c0ba1230eeeacf5b8dfad5d9d721762aaa5f9b4
CertUtil: -hashfile command completed successfully.

c:\Ozmoo\downloads>

I'm sure you're busy with the party prep but if you do try this please let me know how you get on, and if it does go wrong please let me have as much detail about the machine and its configuration as you can - the OSMODE if it's Integra-B, the sideways RAM config, the value of PAGE, the screen mode, whether there's a co-pro or not and ideally a screenshot of the technical details you get if you hold down the CTRL key while the game is loading after the initial menu.

Before it gets overwritten, this issue was on a BeebEm machine with IntegraB / OSMODE4. 1770 Disc controller & Econet enabled. 6502 Co-Pro hardware selected, but disabled in IBOS. Active ROMS (not unplugged):

15 - IBOS1.26
14 - Basic
13 - DNFS3.00
12 - Acorn ADFS
11 - DFS 2.26
10 - ARM 1.13

RAM banks available at 4, 5, 6 & 7.
All other banks empty

PAGE= &2100.
Mode 7 - Shadow RAM inactive.
OZMOO 13.1 (alpha 51)

I tried unplugging ROMs 11 & 12, which brought page down to &1200, but it didn't make any difference.

Technical Details

Hang on Save

I'm just about to grab alpha 55, and I'll give that a try...

[SteveF]

Thanks Ken, this is already intriguing! When I do this build myself with 13.1 (alpha 51) with the -v switch I get:

Code: Select all

Electron executable uses medium dynamic memory model and requires PAGE<=&1E00
BBC B sideways RAM executable uses medium dynamic memory model and requires PAGE<=&3000
Shadow+sideways RAM executable can't use small dynamic memory model as it would require PAGE<=&1300
Shadow+sideways RAM executable uses big dynamic memory model and requires PAGE<=&3000

Note that all the builds - in particular the shadow build which is presumably being used here (the screenshot shows "shadow RAM" under "Hardware detected", so I assume your statement "Shadow RAM inactive" is a typo) - are using the medium or big memory model. But your screenshot shows "memory model=small". Something strange is going on here!

When I run my own build and hold down CTRL during the load, it does show "memory model=big", as I'd expect.

I hate to ask, but are you absolutely sure you're running the code you just built?

Edit: Also weird/inconsistent is the nonstored_pages value shown in your screenshot. This is (roughly) the game's dynamic RAM size, and it should be (at least) $3c for this game:

Code: Select all

$ infodump games/zork1-invclues-r52-s871125.z5 

Story file is games/zork1-invclues-r52-s871125.z5

    **** Story file header ****

Z-code version:           5
Interpreter flags:        None
Release number:           52
Size of resident memory:  6059
Start PC:                 6741
Dictionary address:       47fe
Object table address:     03fc
Global variables address: 02b0
Size of dynamic memory:   3b3e <-- this is the dynamic memory size, and we round up
Game flags:               None
Serial number:            871125
Abbreviations address:    01f0
File size:                19b30
Checksum:                 4b37

I'm not saying there isn't an Ozmoo bug here, but again my build with alpha 51 does show nonstored_pages=$3c when I hold down CTRL during loading.

Edit: Perhaps the simplest explanation would be that you did everything right but attached the wrong screenshot of the "technical details", instead picking up an older one lying around in your screenshots folder by mistake?

Edit: It is really good this is going wrong under BeebEm, as it greatly increases my chances of reproducing it. It would be good if you could reproduce it without Econet, but if you're busy or it simply won't go wrong without Econet then don't worry about it - I probably ought to have a play with emulated Econet myself anyway, it's just that I don't currently have this set up. (And I will try reproducing without Econet myself as a first step anyway, it's just good if I know that it fails for you too.)

[KenLowe]

Firstly, when I said that Shadow memory was inactive, what I meant was that the base machine was running in a non shadow mode. So, before I stared loading the game, screen was set to MODE 7 and HIMEM was sitting at &7C00. As you point out, shadow ram was available to be used.

I've just upgraded to alpha-55, but it's doing the same. Memory model is still small.

I guess the only difference between our setup is that I'm running this from NET, whereas, I assume you're running from ADFS?

The attached screenshot is definitely correct. With the new build program-start has dropped to $2500 for some reason, but all other entries are exactly the same.

I'll try running it from ADFS, and see what difference that makes...

Edit: Even with ADFS, it's still coming back as small. I'll attach my build...

[SteveF]

Thanks Ken! Looking at the BUILD file on your zipped .adf image, it says the filename is zork1-rs-sAS000C.z1. Is that right? Is it this .z1 version which is hanging or it is the z5 we confirmed the sha256sum of earlier? Edit: Aha, this does indeed lock up for me on "save" (on a simple emulated Master 128 in b-em, FWIW). I'll take a look... Edit: this is also locking up on alpha 55, FWIW.

[SteveF]

I'm embarrassed to announce 14.22 alpha 56, which fixes a long-standing bug in save/restore for Z1 and Z2 games. (The conditional assembly to handle the different versions simply didn't recognise Z1 and Z2 as possibilities, so some code at the start of the subroutines for save/restore was missing.)

Z3+ games were already fine and should continue to be fine. I have given alpha 56 a quick test with a Z1, Z3 and Z5 game and it seems to work fine.

Thanks for finding this Ken, nice work!

[KenLowe]

Thanks Ken! Looking at the BUILD file on your zipped .adf image, it says the filename is zork1-rs-sAS000C.z1. Is that right? Is it this .z1 version which is hanging or it is the z5 we confirmed the sha256sum of earlier? Edit: Aha, this does indeed lock up for me on "save" (on a simple emulated Master 128 in b-em, FWIW). I'll take a look... Edit: this is also locking up on alpha 55, FWIW.

Sorry, I've got a script that builds a couple of different versions of Zork1, and I've managed to get myself a bit confused over the build versions. Anyway, glad you were able to find and fix the issue. I'll download the latest build shortly and give it a try.

Thanks!

[KenLowe]

I'm embarrassed to announce 14.22 alpha 56, which fixes a long-standing bug in save/restore for Z1 and Z2 games. (The conditional assembly to handle the different versions simply didn't recognise Z1 and Z2 as possibilities, so some code at the start of the subroutines for save/restore was missing.)

Z3+ games were already fine and should continue to be fine. I have given alpha 56 a quick test with a Z1, Z3 and Z5 game and it seems to work fine.

Thanks for finding this Ken, nice work!

That's fixed it for me. Thanks for the super quick response and apologies again for the misleading version info I provided earlier!

[SteveF]

No worries Ken, I've done the same sort of thing myself. Thanks for finding this and testing the fix. Fingers crossed Ozmoo doesn't crash all the time during the party, if it does please see if you can get any kind of details so I can investigate later. But I'm sure it will be rock solid.

[fredrikr]

To make sure catch/throw is working properly, you want to try a Dialog game like Tethered, as Dialog relies heavily on this mechanism. Try inserting a bug on purpose in catch/throw and see how far you get in Tethered.

[SteveF]

Thanks Fredrik! I suspect I'm missing something really obvious, but where can I get a Z-code version of Tethered? All I can find are .zblorb files and pre-built C64 versions.

[SteveF]

I suddenly decided to have a go at creating a Zork II logo/title screen. As with the Zork I version, consider it a work in progress (that may never progress further) - if nothing else I suspect it could do with some text, and possibly some further artistic tweaking if anyone feels so inclined.

Here's the PNG version:

zork-2-logo-wip-3.png (16.37 KiB) Viewed 27 times

and I've attached a mode 1 screen dump as a zip file.

Credit where it's due: this is a mash up of my Zork I screen and a scan of the Apple II front cover from mobygames, inexpertly tinkered with in gimp.

Does anyone have any tips for websites/tools which would allow me to add nice-looking low resolution text to images like this?

[KenLowe]

Excellent. I couldn't resist. It's now on my PiFS, ready for the Econet LAN party.

[SteveF]

Thanks Ken!