PunyInform and Ozmoo

[AndyGarton]

Yes, I'm an idiot ... that's exactly it. I don't see that behaviour with the Gotec route because I'm shift-breaking to start the launcher, which initializes the co-pro. Doh!

Change of subject - I thought I'd try the RamFS to see how fast that might be, but no game will launch, error being "sorry, this game will only work on DFS". Is that just a fact of life? I'm sure I'd seen you mention RamFS earlier in the thread?

[SteveF]

Thanks, I'm glad we got that figured out!

I think RamFS may work if you use the *DTRAP command to tell it to pretend to be DFS, but I don't know for sure. ISTR discussing this (with lurkio?) a long time ago.

[AndyGarton]

Not having much luck here.

I've tried implementing the *DIN code for ADFS but it's not working. Direct access mode on the Gotek works by writing to a special track 254 on the Gotek drive. When I try doing this on ADFS using OSWORD &72 (instead of DFS OSWORD &75) the drive just loops back around once it reaches track 80. I'm not sure if this is a limitation of the Gotek or the beeb. I'll need to ask KierF about this, but given up on this route for now.

It turns out that I can actually run Trickys DFS version of *DIN from ADFS. By default, it was loading to &1100 which was not suitable for ADFS. The code is relocatable, so I loaded it to &3000 instead (just to test it). However, to get it working reliably, I do still need to switch in and out of DFS. Unfortunately, every time I do this, *EXEC halts, and just drops me back to the > prompt. I thought I'd be smart and try moving the *DISK / *ADFS commands from the *EXEC file into the *DIN code, but that didn't make any difference.

So, back to writing some specific code to copy files from floppy to HDD. I've spent way too much time on this already. Probably much more than I would ever spend actually manually copying files. But it's more fun!

Did you get anywhere with this please Ken? I’m currently doing it manually (although using ADFS Explorer to help), so some automation would be great!

[AndyGarton]

Thanks, I'm glad we got that figured out!

I think RamFS may work if you use the *DTRAP command to tell it to pretend to be DFS, but I don't know for sure. ISTR discussing this (with lurkio?) a long time ago.

Excellent, that was it - works fine now, and is super fast as you'd expect. Only small issue with it is that I'll probably forget to *EXPORT my save files back to USB one day, so will probably stick with CF/HD usage in the main. Impressive nevertheless!

[SteveF]

Thanks, I'm glad we got that figured out!

I think RamFS may work if you use the *DTRAP command to tell it to pretend to be DFS, but I don't know for sure. ISTR discussing this (with lurkio?) a long time ago.

Excellent, that was it - works fine now, and is super fast as you'd expect. Only small issue with it is that I'll probably forget to *EXPORT my save files back to USB one day, so will probably stick with CF/HD usage in the main. Impressive nevertheless!

Good to know, thanks!

If you're on a Master rather than a B/B+, you can probably save to the hard drive when running from RAMFS by giving a filename like "-ADFS-:0.$.SAVES.FOO" at the save/restore prompt, if I have the syntax right. But you'd still have to remember to do that, so it may well be safer not to risk it, even if it works.

[AndyGarton]

Cheers, good point and I’ll give that a try.

[AndyGarton]

One small note I forgot to mention before - I'm building my disk images on a Windows 11 machine, and found that the Python 3 install from the "official" website linked in Ken's post didn't work properly, I think because it doesn't get added to the Windows path for some reason, so you get "unknown command" or similar (even after a reboot). However, there is some sort of automated link to the Windows store version, because a system dialog pops up prompting you to install that instead. So I uninstalled the website version, got the store version (which is the exact same version number) and it worked fine from that point. Probably not worth complicating the instructions with that considering the number of people it will likely affect (just me!), but if by chance somebody does hit it, then this post might help.

[AndyGarton]

Is it an impossible dream to think that one day Ozmoo, or something similar, could handle Magnetic Scrolls and/or Level 9 games too? Text only would be fine!

[AndyGarton]

Not having much luck here.

I've tried implementing the *DIN code for ADFS but it's not working. Direct access mode on the Gotek works by writing to a special track 254 on the Gotek drive. When I try doing this on ADFS using OSWORD &72 (instead of DFS OSWORD &75) the drive just loops back around once it reaches track 80. I'm not sure if this is a limitation of the Gotek or the beeb. I'll need to ask KierF about this, but given up on this route for now.

It turns out that I can actually run Trickys DFS version of *DIN from ADFS. By default, it was loading to &1100 which was not suitable for ADFS. The code is relocatable, so I loaded it to &3000 instead (just to test it). However, to get it working reliably, I do still need to switch in and out of DFS. Unfortunately, every time I do this, *EXEC halts, and just drops me back to the > prompt. I thought I'd be smart and try moving the *DISK / *ADFS commands from the *EXEC file into the *DIN code, but that didn't make any difference.

So, back to writing some specific code to copy files from floppy to HDD. I've spent way too much time on this already. Probably much more than I would ever spend actually manually copying files. But it's more fun!

Did you get anywhere with this please Ken? I’m currently doing it manually (although using ADFS Explorer to help), so some automation would be great!

I’ve finally caught up with the whole thread (phew!), so have found your solution, and scripts, thanks very much for that. I think something similar should work for me too (in my case resulting in a single ADFS disk image with all games, which I can then copy in one go over to my CF card using ADFSExplorer). One question I have - you don’t mention editing the !BOOT file to get the games to launch from a nested folder location. Do you not have to do that? Or do you perhaps use some other custom launch method? I’m hoping your UNIMG/MKIMG method can help me here also, in that I can batch copy my edited !BOOT file into all game folders, before the MKIMG step.

[SteveF]

Is it an impossible dream to think that one day Ozmoo, or something similar, could handle Magnetic Scrolls and/or Level 9 games too? Text only would be fine!

I'm sure "something similar" isn't impossible, but I doubt Ozmoo itself will ever do it as I don't think the underlying VMs are that similar. I don't really know though. Ultimately, I'm just porting what Johan and Fredrik are implementing upstream and if they somehow pull this off, I will certainly look at porting it over to Acorn.

[KenLowe]

Not having much luck here.

I've tried implementing the *DIN code for ADFS but it's not working. Direct access mode on the Gotek works by writing to a special track 254 on the Gotek drive. When I try doing this on ADFS using OSWORD &72 (instead of DFS OSWORD &75) the drive just loops back around once it reaches track 80. I'm not sure if this is a limitation of the Gotek or the beeb. I'll need to ask KierF about this, but given up on this route for now.

It turns out that I can actually run Trickys DFS version of *DIN from ADFS. By default, it was loading to &1100 which was not suitable for ADFS. The code is relocatable, so I loaded it to &3000 instead (just to test it). However, to get it working reliably, I do still need to switch in and out of DFS. Unfortunately, every time I do this, *EXEC halts, and just drops me back to the > prompt. I thought I'd be smart and try moving the *DISK / *ADFS commands from the *EXEC file into the *DIN code, but that didn't make any difference.

So, back to writing some specific code to copy files from floppy to HDD. I've spent way too much time on this already. Probably much more than I would ever spend actually manually copying files. But it's more fun!

Did you get anywhere with this please Ken? I’m currently doing it manually (although using ADFS Explorer to help), so some automation would be great!

I was never able to get Direct access mode to work with ADFS. I gave up in the end, and eventually went down another route...

I’ve finally caught up with the whole thread (phew!), so have found your solution, and scripts, thanks very much for that. I think something similar should work for me too (in my case resulting in a single ADFS disk image with all games, which I can then copy in one go over to my CF card using ADFSExplorer). One question I have - you don’t mention editing the !BOOT file to get the games to launch from a nested folder location. Do you not have to do that? Or do you perhaps use some other custom launch method? I’m hoping your UNIMG/MKIMG method can help me here also, in that I can batch copy my edited !BOOT file into all game folders, before the MKIMG step.

Well done in reading through the whole thread. That must have taken some effort. I now challenge you to read through the entire 'Econet to AUN bridge on Raspberry Pi - released' thread in the hardware section. It's even longer!

I generally don't use the !BOOT file when loading from Econet or ADFS HDD. I usually just CHAIN"LOADER" from the relevant directory.

[8bitAG]

Is it an impossible dream to think that one day Ozmoo, or something similar, could handle Magnetic Scrolls and/or Level 9 games too? Text only would be fine!

Both the Magnetic Scrolls games and the Level 9 games run on completely different systems... so would really need separate Ozmoo-style interpreter programs, or could be run on the existing game's interpreters.

Mike Austin, of Level 9, is apparently going to eventually release the A-Code system and tools on GitHub for people to access and, potentially, make their own new games.

[AndyGarton]

I'm encountering an error building "Endless, Nameless" (Z file attached):

Code: Select all

Building Endless, Nameless
acme --cpu 6502 --format plain --setpc $e00 -DACORN=1 -DACORN_CURSOR_PASS_THROUGH=1 -DSTACK_PAGES=4 -DSMALLBLOCK=1 -DSPLASHWAIT=0 -DACORN_HW_SCROLL=1 -DACORN_INITIAL_NONSTORED_PAGES=218 -DACORN_DYNAMIC_SIZE_BYTES=55452 -DACORN_GAME_PAGES=1844 -DACORN_ADFS=1 -DACORN_CURSOR_EDIT_READ=1 -DUSE_HISTORY=48 -DACORN_SHOW_RUNTIME_INFO=1 -DZ8=1 -DVMEM=1 -DACORN_VMEM_BLOCKS=813 -DACORN_SWR=1 -DACORN_RELOCATABLE=1 -DACORN_ELECTRON_SWR=1 -DACORN_SCREEN_HOLE=1 -DACORN_SHADOW_VMEM=1 -DACORN_RECOMMENDED_SHADOW_CACHE_PAGES=4 -DACORN_SWR_SMALL_DYNMEM=1 -l ..\temp\acme_labels_ozmoo_electron_swr_smalldyn_e00 -r ..\temp\acme_report_ozmoo_electron_swr_smalldyn_e00 --outfile ..\temp\ozmoo_electron_swr_smalldyn_e00 ozmoo.asm
Error - File acorn-disk.asm, line 947 (Subzone save_restore): Number out of range.
Error - File acorn-disk.asm, line 949 (Subzone save_restore): Symbol already defined.
Error - File acorn-disk.asm, line 951 (Subzone save_restore): Symbol already defined.
Error - File acorn-disk.asm, line 1121 (Subzone save_restore): Symbol already defined.
Error - File acorn-disk.asm, line 1127 (Subzone save_restore): Symbol already defined.
Error - File acorn-disk.asm, line 1128 (Subzone save_restore): Symbol already defined.
Error - File acorn-disk.asm, line 1133 (Subzone save_restore): Symbol already defined.
Error - File acorn-disk.asm, line 1134 (Subzone save_restore): Symbol already defined.
Error - File acorn-disk.asm, line 1136 (Subzone save_restore): Symbol already defined.
Error - File acorn-disk.asm, line 1139 (Subzone save_restore): Symbol already defined.

acme failed

Build line:

Code: Select all

python make-acorn.py -a -p --auto-start --default-fg-colour 2 --default-bg-colour 0 --default-mode 0 --title "Endless, Nameless" games\Independent\Nameless.z8 IMAGES\Nameless.adf

[AndyGarton]

An issue which could be in the Ozmoo image generation, or possibly JGHarston's UNIMG utility, in that two of my built ADL files cause the UNIMG utility to hang (although it does appear to extract the files ok). I've attached the two ADLs in question (both of which are "too large for a single side" cases btw). The UNIMG line I'm using is (for example):

Code: Select all

unimg IMAGES\Vespers.adl -d HDDImageInd/Games/Independent/Vespers -fs adfs -X --quiet

[AndyGarton]

... just discovered that the resulting extracted disk images both have very large (15mb and 65mb!) garbage single files (named '#' and '"i'4") in the SAVES directory. I suspect the UNIMG process was in a tight loop, so these files would have expanded forever had I not killed the process.

[AndyGarton]

I'm having an issue running large games (really large games, Z8 games) from my CF HD. These games do work when run from a floppy (Gotek) image.

They actual fail during the launch process, when CHAIN "LOADER" errors with "Bad Program". A source game file which is 279kb (LostPig.z8) works ok, a file which is 293kb (SoFar.z8) fails. All my other games which are larger than this fail in the same way.

My machine is a Master 128, with PiTubeDirect (set to standard 6502) and DataCentre. When the launcher works (i.e. with smaller games), it shows as detecting my CoPro, shadow RAM and 64k sideways RAM (banks 4-7). Page shows as 800 when I print it after the Bad Program error.

Any ideas anyone please? Am I just pushing the limits memory wise?!? It's not a huge deal of course as I can just run the games in question direct from floppy as a workaround.

[SteveF]

I'm encountering an error building "Endless, Nameless" (Z file attached):

Thanks for reporting that. Unfortunately this game is just too big for Acorn Ozmoo:

Code: Select all

$ infodump games/endless-nameless.z8 
[...]
Size of dynamic memory:   d89c
[...]

That's >54K, so pretty much the only way this would ever work is on a (currently non-existent) version of Ozmoo for the 256K co-pro which uses an entire 64K bank for dynamic memory. (Edit: I'd hate to put anyone off trying this - Ozmoo *does* support the 256K "turbo" co-pro, but the dynamic memory doesn't get an entire 64K bank to itself yet. You do get 128K of virtual memory cache in addition to that provided by any sideways RAM though.)

The build process should diagnose this properly though, so I've pushed a fix to the acorn-9.x branch to do that. I haven't tagged this up yet, I will probably look at doing that once I've investigated the other problems you've reported (hopefully later today).

For the technically inclined: The reason the build failed so messily is that the address of "end of dynamic memory" would be larger than the 16 bit address space and so acme generates an error which the build system isn't expecting; normally the assembly would succeed and we'd then examine the resulting code and see that it needs more RAM than we have and fail at that point.

[SteveF]

An issue which could be in the Ozmoo image generation, or possibly JGHarston's UNIMG utility, in that two of my built ADL files cause the UNIMG utility to hang (although it does appear to extract the files ok). I've attached the two ADLs in question (both of which are "too large for a single side" cases btw). The UNIMG line I'm using is (for example):

Code: Select all

unimg IMAGES\Vespers.adl -d HDDImageInd/Games/Independent/Vespers -fs adfs -X --quiet

I think the problem is that you need to specify the "-dsd" option to UnImg because the .adl file is interleaved. That seems to fix it for me, please let me know how you get on.

I assume (it was a long time ago and I don't really remember) I am generating interleaved .adl files because I experimented when I added ADFS support and that was what emulators seemed to want. I am open to suggestions to change to generate non-interleaved files for ADFS double-sided discs if that's actually useful. I haven't gone and played around with this to see what works in emulators right now though.

(The interleaving is a little unfortunate in terms of wasting space with an over-large disc image, as it means if the game disc uses more than 320K, all 80 tracks on side 0 are used so we have to write a full 640K of data even if no padding is requested. Not a huge deal but it did confuse me a bit just now so I thought I'd make a note here.)

[SteveF]

I'm having an issue running large games (really large games, Z8 games) from my CF HD. These games do work when run from a floppy (Gotek) image.

They actual fail during the launch process, when CHAIN "LOADER" errors with "Bad Program". A source game file which is 279kb (LostPig.z8) works ok, a file which is 293kb (SoFar.z8) fails. All my other games which are larger than this fail in the same way.

I am guessing this is caused by the file contents getting scrambled when UnImg is used without the "-dsd" option. This will only be needed for games which have to go on an ADFS L disc (where the generated disc image is >320K, which is correlated with the Z-code game size). If this doesn't fix it please let me know and I'll take a look.

[AndyGarton]

Genius, one solution for two problems! The -dsd option did indeed fix both issues, thanks.

[SteveF]

Great, thanks for confirming that!

[EdwardianDuck]

Having recently treated myself to a new Mac Studio so that I've got something that's still getting OS updates, I've been setting up the tools required to rebuild my game ("Duck! Me?"). Where possible I've also been building the tools from source, just to be on the safe side. All seemed go be going well until I decided to switch from release v4.4 to the latest preview, on the grounds that v4.4 didn't like my .z3 build (but was fine with the .z5 build) and that there have been a lot of builds since the last formal release. I had also upgraded Inform6 and PunyInform to the latest releases, just to make tracking down any issues extra hard for myself.

In latest available preview-9.21-alpha-43, I was getting errors like this from ACME.

Code: Select all

Error - File acorn-init-preload.asm, line 508 (Subzone <untitled>): There's more than one character.
Error - File acorn-init-preload.asm, line 508 (Subzone <untitled>): No value given.

Release v4.4 doesn't have this file.

So it turns out that the process needs ACME v0.97 ("Zem") but I had v0.96 ("Fenchurch") because there are two repositories for ACME online, one in SourceForge and another in GitHub and of course I chose the one in GitHub because that's where everything seems to be these days. SourceForge appears to be up to date (0.97) and GitHub isn't (v0.96). The link to ACME here https://zornslemma.github.io/ozmoo.html is, of course, the correct one!

Rebuilding from 0.97 has fixed the impenetrable ACME error message.

Other than that, setting up a suitable development/test toolchain on macOS Monterey is pretty painless.

• Inform6
• PunyInform
• ACME
• BeebAsm
• LZSA
• Acorn Ozmoo
• VS Code
• Inform6 VSCode Extension
• IF Player VSCode Extension
• Frotz (interpreter) (slightly more complicated than just a MAKE command, but not much more)
• SpatterLight (interpreter, free from the AppStore)

Jeremy

[SteveF]

Hi Jeremy, thanks for giving the latest Ozmoo a try!

All seemed go be going well until I decided to switch from release v4.4 to the latest preview, on the grounds that v4.4 didn't like my .z3 build (but was fine with the .z5 build)

I see you posted a .z5 build over in the your game's thread; I hope this was your choice and not because the latest Ozmoo decided it didn't like your .z3 build. If Ozmoo is still getting upset with your .z3 please let me have a copy and I'll investigate.

So it turns out that the process needs ACME v0.97 ("Zem") but I had v0.96 ("Fenchurch") because there are two repositories for ACME online, one in SourceForge and another in GitHub and of course I chose the one in GitHub because that's where everything seems to be these days. SourceForge appears to be up to date (0.97) and GitHub isn't (v0.96).

I have been bitten by this myself when moving between two different machines I use for development. I really should have added a check for this at build time as the message is extremely cryptic. (If memory serves - as you probably already figured out - the problem is that I started using strings as macro arguments, which seems to be 0.97 only.) I will have a look at adding an explicit version check at build time...

The link to ACME here https://zornslemma.github.io/ozmoo.html is, of course, the correct one!

This is entirely deliberate, and not at all a lucky accident. *cough*

[EdwardianDuck]

(I'm at work, so this will be brief).

I used .z5 because .z3 imposes some coding annoyances. When I migrated over to my new Mac, I didn't bother trying .z3. I'll try .z3 when I get time, possibly this evening, and report back. I'm kind of torn between .z3 because my Atari 8 bit build requires it and .z5 because of programming.

Jeremy

[EdwardianDuck]

I've just tried .z3 with the latest Acorn Ozmoo. It built without issue and I was able to play part the way through the game before something went wrong. I'll have to investigate what's happening in the .z3 build, but I think it's logic in my code. It's not crashing, just the game logic is off, I think.

Jeremy

[EdwardianDuck]

My .z3 build was also failing at the same point in both Frotz and Spatterlight, so it was definitely my code causing the issue. I had made a change to one of my extensions late yesterday after posting release 1 to try something out. While this appeared at first glance to be working, it wasn't. Backing this change out makes both the .z3 and .z5 builds work.

In feeble defence of my actions, I haven't looked at Inform for ~9 months and have clearly forgotten many, many things.

Jeremy

[SteveF]

Thanks Jeremy, I'm glad Acorn Ozmoo worked with the .z3 and I appreciate your efforts to test this!

[lurkio]

- - - -

You are in a liminal space known as Stardot.
SteveF is here, working on multiple projects.

> TALK TO STEVEF

SteveF is very busy.

> TALK TO STEVEF REGARDLESS

You start to speak. SteveF looks annoyed.

> HASTILY COME TO THE POINT

How?

> ASK STEVEF IF HE WOULD CONSIDER IMPLEMENTING A BEEB VERSION OF THE 6502 Å-MACHINE INTERPRETER

SteveF looks puzzled.

> EXPLAIN WHAT THE Å-MACHINE IS

You launch into a disjointed and inadequate explanation of the nature of the Å-machine which, essentially, is a newish virtual machine for interactive fiction (IF), designed by Linus Åkesson, who also created Dialog, a new IF language in which text adventure games can be written and compiled for the Å-machine (or, optionally, for the venerable Z-machine too). Åkesson claims that "stories compiled for the Å-machine ... are smaller and faster on vintage hardware." Åkesson has written a 6502 interpreter for compiled Å-machine story files (which take the .aastory filename extension). The 6502 interpreter needs a matching frontend which "handles input, output, and other platform-specific details" — a pretty neat design. Currently, the only known 6502 frontend is for the Commodore 64.

> IT WOULD BE NICE IF THERE WERE A 6502 FRONTEND FOR THE BEEB TOO

Oh, you think it would be "nice", do you? (This is the parser speaking, by the way. Not SteveF.)

> YES, I THINK IT WOULD BE NICE

And you think SteveF will just jump jump up and start coding, do you? Despite the fact that he's got multiple projects on the go already — including the groundbreaking and brilliant Acorn Ozmoo — which must take up a significant amount of his spare time?

> WELL, NO...

No. I mean, you've got a nerve, haven't you? What possessed you to make such a staggeringly pushy request?

> ER, I JUST THOUGHT IT WOULD BE COOL TO BE ABLE TO RUN Å-MACHINE GAMES NATIVELY ON THE BEEB

Why? What's so cool about this blessed Å-Machine?

> THE NAME FOR A START. IT'S PRONOUNCED "AWE MACHINE"!

...

> ...

Seriously? A "cool-sounding" name? That's all you've got? Are you a complete cretin? That's supposed to motivate a very busy genius to drop everything and start a new and involved 6502 coding project, is it?

> WELL, THERE ARE ALSO THE GAMES WRITTEN IN DIALOG THAT RUN ON THE Å-MACHINE...

How many?

> LOOK, IT'S NOT ABOUT QUANTITY, IT'S—

How. Many. Dialog. Games. Are there?

> EIGHT

Eight. Great. (And some of those eight aren't even available as .aastory exports!) And this is the vast library of games that you think the world is desperately hoping that someone will bring to the Beeb, is it? Heaven help us. Do you possibly imagine that anyone other than you is interested in any of this?

> WELL, I IMAGINE LINUS MIGHT BE! AND THEN THERE'S PTOLOM.

I dread to ask...

> PTOLOM. A MEMBER OF INTFICTION.ORG, WHOM I'VE BEEN IN TOUCH WITH, AND WHO'S A BEEB ENTHUSIAST. THEY'VE WRITTEN A GAME IN DIALOG BASED ON THE POEM "THE LADY OF SHALOTT", WHICH IS A COOL IDEA IN ITSELF, AND THEY'VE EXPORTED IT FOR THE Z-MACHINE, BUT IT RAN SLOWER (IN ACORN OZMOO) THAN IT WOULD HAVE IF IT HAD BEEN COMPILED FOR AND RUN BY A NOTIONAL NATIVE 6502 BEEB .AASTORY INTERPRETER. PTOLOM SAID THEY'D HAVE A GO AT IMPLEMENTING A BEEB 6502 FRONTEND THEMSELVES IN MID-NOVEMBER, BUT WORK SEEMS TO HAVE STALLED.

Oh, so not only do you want SteveF to put a huge amount of effort into writing a Beeb Å-Machine terp, but you're also pitting him against a possible rival implementor who may still be working on their own terp as we speak..?!

> WELL, I HAVEN'T HEARD ANYTHING FROM PTOLOM SINCE MID-NOVEMBER, AT WHICH POINT THEY'D BARELY STARTED...

Look. I've had about enough of this. You've got more cheek than the back-end of a baboon. Where the hell do you get off asking people to do your dirty work for you just to satisfy a passing whim?!

> I—

No. Enough. You are insufferable, arrogant, and presumptuous. There's a door to the north. Close it on your way out.

> BUT—

You suddenly find you're unable to speak. You feel compelled to leave.

> ...

I'm waiting.

> GO NORTH

Glancing forlornly behind you at SteveF (who looks relieved, as if he's just dodged a bullet), you walk through the doorway to the north, shutting the door behind you.

You have left the game.

You failed to persuade this parser — let alone SteveF — that an Å-Machine terp for the Beeb would be a good idea.

You have scored zero out of a possible 100. I'd say "Better luck next time" but there won't be a next time.

Goodbye. And good riddance.

*** THE END ***

[marcusjambler]

Thats Hilarious Lurkio

[SteveF]

I enjoyed that, nice one Lurkio! The A-machine looks interesting but (assuming there's ~5% seriousness behind this ) I definitely don't have the time to take a port of this on right now. Never say never though, if/when Ozmoo is "done" (upstream stop adding new features, there are no known bugs and I've done everything I wanted to with the Acorn port) I could potentially be interested in taking a look at it. That's probably not happening any time soon though. Is Ptolom a member here on stardot? It would be interesting if there was a dev diary type thread for the port.

Your post actually gives me the push I've been needing to announce the latest Acorn version - 11.39 alpha 44, which you can get here. It's been a long time so my memory may be faulty, but I don't believe there are any terribly interesting new features for us Acorn users - most of the upstream changes are for the Mega 65. There is a nifty looking optimisation in Z-machine instruction dispatch which I haven't found time to study properly yet, so performance might be a little better.

Upstream has added a "scrollback" option for the Commodore machines which lets you scroll back to see text that has scrolled off the top of the screen. This sounds cool and I'm definitely interested in looking at this for the Acorn port, but it *isn't* present in 11.39 alpha 44.

As I believe I've said on here several times and said to Fredrik I would back in June (sorry Fredrik!), I would like to move towards promoting this version to "stable" status. That just means we feel fairly confident it works as well as any earlier versions and it would then be mentioned on https://zornslemma.github.io/ozmoo as the stable version.

I keep getting myself into a bit of a bind here, as I merge the latest upstream changes into the Acorn port, don't find the time/energy to give it the thorough test I'd like, so I don't post about it here, then a few weeks or months later I see there are new upstream changes and the cycle repeats. I am therefore trying to break the cycle by posting here about 11.39 alpha 44 without having given it any extensive testing myself. So please a) do test this and let me know how you get on b) although it aspires to be a stable release eventually, if you have reasons (e.g. a commercial release of a Z-code game) for needing stable right now, please don't assume this is what you want.

It would also be good to get a new stable version out as I'd then feel free to start making some more extensive changes to the Acorn port - at the moment I daren't do that as it would move us further away from having a recent stable version. (The scrollback feature would be an example of something to look at once a stable version is produced - it's potentially quite intrusive and I doubt I can reuse the Commodore implementation as the Acorn screen isn't (in general) a text mode where the characters live as ASCII or near ASCII in screen RAM.)