PunyInform and Ozmoo

[SteveF]

Thanks Ken, that's good to hear!

FWIW I *think* there's a bug lurking in alpha 45 (I only tested quickly and I haven't gone back to try older releases) where it gives an "Unreachable" error when loading the benchmark game on an Integra-B with no free sideways RAM. I am not sure if that should work, but it should at least give a proper error about not having enough RAM if it can't work. I just thought I'd mention it here in case you or anyone else gets bitten by it - if you do, I'm interested in hearing about it in case it sheds any light on the issue. (I suspect it's just a glitch introduced when I reworked all the "do we have enough memory?" code in alpha 45 and it won't be terribly hard to fix, but I haven't tried to debug it yet.)

[SteveF]

I'm pleased to announce alpha 46. This very much is an alpha version; the chances of me not having broken something in this release are fairly small, as I've been playing around with lots of parts of the code. As I've said before, I probably over-used the term alpha in the past. I will try to be a bit more confident about marking releases as "beta" in the future if I/other people have given them a reasonable amount of testing, but ultimately you shouldn't take these labels that seriously.

So what's new? The headline features:

• Faster, (mostly) flicker-free scrolling in modes 0-6.
• When using a second processor, more types of memory in the host can be used to cache game data, reducing disc access.
• Exciting new bugs have been introduced by all the hacking around I've done and are waiting to be discovered by YOU!

What follows are technical details for advanced users - things like "you benefit from this change if you have machine X with feature Y". You don't have to understand/care about these details - feel free to just give the alpha a try - but I wanted to provide this information for users who are interested. I will probably write some "dev blog" style posts on the implementation details of these new features later on.

Improved hardware scrolling in modes 0-6

The biggest change to the user experience is that there is a new "fast hardware scrolling" implementation. The former hardware scrolling mechanism still exists and has been retrospectively renamed "slow hardware scrolling".

Fast hardware scrolling is used on almost all machines by default and should mean that in modes 0-6 the status line doesn't flicker (much). Apart from reduced flicker, the scrolling performance is much better: with alpha 45 and its hardware scrolling implementation, a Master 128 took 18% longer to run the benchmark in mode 3 compared to mode 7, while with alpha 46 mode 3 is <1% slower than mode 7.

Fast hardware scrolling is available on all machines except:

• The BBC B+ when the 12K private RAM is not free for Ozmoo to use. The hardware detected info on the loader screen will show "Shadow RAM (via OS)" in this case.
• The Electron or BBC B with third-party shadow RAM that we don't know how to control the paging for, or where the shadow RAM cannot be paged in/out. The Electron Master RAM Board in shadow mode is an example of this. The hardware detected info on the loader screen will show "Shadow RAM (Master RAM Board)" or "Shadow RAM (screen only)" in this case.

The B+ limitation is unfortunate but probably can't be lifted, although I expect few people to be affected by it - probably just those using SWMMFS+. The third-party shadow RAM cases can potentially be improved in future. I have an idea how to make fast hardware scrolling work on the Master RAM Board but didn't want to try it just yet. If you have a BBC B with an unsupported shadow RAM board, please post here and we can discuss adding support.

Fast hardware scrolling is used for an upper window/status line of three or fewer lines. It should be pretty much flicker-free on a BBC with an upper window of two or fewer lines in all modes; on an Electron it will probably be flicker-free for a single line upper window in 40 column modes. Even when it flickers it should still be much faster than slow hardware scrolling or software scrolling. Software scrolling is always used if the upper window is too large for hardware scrolling.

You can toggle between hardware and software scrolling using CTRL-S as before. This toggles between the best form of hardware scrolling available on your machine and software scrolling; you can't choose to use the older "slow" hardware scrolling at runtime if your system supports the new fast hardware scrolling. If this omission bothers you, please post about it, because I don't think the new hardware scrolling should ever be worse.

You can disable the fast hardware scrolling at build time by specifying --no-fast-hw-scroll, if you hate it or if it breaks things for you - but please post here and let me know if either of those applies - or just to do comparisons of the two types of hardware scrolling. You can disable the slow hardware scrolling by specifying --no-slow-hw-scroll; this claws back a bit of memory which just may boost performance, if you're willing to take the risk of being forced to use software scrolling if the game is run on a machine which can't support fast hardware scrolling. You can specify both of those options for a build which only supports software scrolling, if you really want to.

Mode 7 always uses software scrolling, just as before.

Keyboard input changes - mildly technical, but please read this if you used to use the --osrdch option

The Acorn OS provides two ways of reading from the keyboard:

• OSRDCH always waits until a key is pressed (this is what BASIC's GET uses)
• OSBYTE &81 returns even if no key is pressed (this is what BASIC's INKEY uses)

This distinction is important in Ozmoo for games which use timed input, rather than always waiting for the user's next command before doing anything else.

Previous versions had a --osrdch option which did two separate things:

• Used OSRDCH to read from the keyboard instead of OSBYTE &81.
• Prevented Ozmoo using 162 bytes at the bottom of the 6502 stack as buffers.

This worked around problems with some emulators (notably BeebEm versions before 4.16) when pasting input into the emulator.

The --osrdch option has been removed and these two separate things are now controlled by the --force-osrdch and --no-data-in-stack options respectively. If you used to use --osrdch, you can use both of these options to get the same effect. You may not need both; it will depend on exactly what you were trying to achieve.

OSRDCH is now used by default for Z1-3 games, as it shrinks the code slightly and has no downside as these games cannot use timed input. You can still specify --force-osrdch if you want, even if it's not strictly necessary.

If you are building a Z4+ game which you know doesn't use timed input, you can specify --force-osrdch to shrink the code slightly with no downside. This can't be done automatically as Ozmoo has no way to know whether a Z4+ game uses timed input or not at build time.

(Why would you want less code? The smaller the Ozmoo code, the more RAM is free for caching game data. Free RAM gets rounded down to a multiple of 512 bytes for these purposes, so a small saving may not make any difference, but it may also happen to tip the free RAM over a 512 byte boundary.)

--no-data-in-stack may be useful on its own if something on your machine makes heavy demands on the stack and Ozmoo's borderline naughty use of the bottom of the stack causes problems. I am not aware of any situation where this has been a problem so far, except the emulator incompatibility noted above.

Use of spare shadow and private RAM as cache when running on a second processor

When running on a machine with a second processor, alpha 45 (and earlier) would use spare main RAM and sideways RAM in the host to cache game data. Alpha 46 is also capable of using additional host memory for caching:

• The private RAM on the B+ and Integra-B (an extra 11.5/11K respectively)
• Spare shadow RAM (an extra 19K in mode 7, but nothing in mode 0)

This should reduce disc access further if your machine has either of these types of memory. The benchmark doesn't seem to show much improvement from this, probably because the game just isn't that large in comparison to the memory available just in the second processor itself.

As always, spare shadow RAM is only usable if Ozmoo knows how to access it; machines with "unsupported" shadow RAM will be able to use shadow RAM for the screen memory but nothing else, and the loader's list of detected hardware will show "Shadow RAM (screen only)". If you experience this, please post and we can look into adding support for your hardware if possible.

Other minor changes

You can now use colour names (black/red/green/yellow/blue/magenta/cyan/white) as well as physical colour numbers 0-7 when specifying colour related options to make-acorn.py.

A couple of bugs in the calculations to decide which (if any) screen modes the game can run in have been fixed. I still haven't done extensive testing on this so there may well be further bugs lurking.

I think that's everything. As always, feedback is appreciated!

[polluks]

So ElkSD128 scrolling should work?

[SteveF]

Yep, it should do.

[KenLowe]

I'm pleased to announce alpha 46. This very much is an alpha version; the chances of me not having broken something in this release are fairly small, as I've been playing around with lots of parts of the code.

Hmmm. Just tried running this version, but got the following warnings when trying to build. The disk image still seems to be getting generated, so can the warnings just be ignored?

Code: Select all

C:\Users\Me\Desktop\Ozmoo\ozmoo-acorn>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
acme --cpu 6502 --format plain --setpc $900 -DACORN_SHADOW_VMEM=1 -l ..\temp\acme_labels_acorn_shadow_driver_900 -r ..\temp\acme_report_acorn_shadow_driver_900 --outfile ..\temp\acorn_shadow_driver_900 acorn-shadow-driver.asm
Warning - File acorn-shadow-driver.asm, line 45 (Zone <untitled>): C-style "==" comparison detected.
Warning - File acorn-shadow-driver.asm, line 54 (Zone <untitled>): C-style "==" comparison detected.

acme --cpu 6502 --format plain --setpc $5c00 -DACORN_HW_SCROLL_FAST=1 -DACORN_SHADOW_VMEM=1 -l ..\temp\acme_labels_acorn_scroll_5c00 -r ..\temp\acme_report_acorn_scroll_5c00 --outfile ..\temp\acorn_scroll_5c00 acorn-scroll.asm
Warning - File acorn-scroll.asm, line 211 (Zone <untitled>): C-style "==" comparison detected.
Warning - File acorn-scroll.asm, line 257 (Zone <untitled>): C-style "==" comparison detected.
Warning - File acorn-scroll.asm, line 514 (Zone <untitled>): C-style "==" comparison detected.
Warning - File acorn-scroll.asm, line 515 (Zone <untitled>): C-style "==" comparison detected.
Warning - File acorn-scroll.asm, line 534 (Subzone <untitled>): C-style "==" comparison detected.
Warning - File acorn-scroll.asm, line 535 (Subzone <untitled>): C-style "==" comparison detected.

acme --cpu 6502 --format plain --setpc $2600 -DACORN_RELOCATABLE=1 -DACORN_TUBE_CACHE=1 -DACORN_SWR=1 -DACORN_SHADOW_VMEM=1 -l ..\temp\acme_labels_acorn_cache_2600 -r ..\temp\acme_report_acorn_cache_2600 --outfile ..\temp\acorn_cache_2600 acorn-cache.asm
Warning - File acorn-cache.asm, line 61 (Zone <untitled>): C-style "==" comparison detected.
Warning - File acorn-cache.asm, line 605 (Zone <untitled>): C-style "==" comparison detected.
Warning - File acorn-cache.asm, line 607 (Zone <untitled>): C-style "==" comparison detected.
Warning - File acorn-cache.asm, line 612 (Zone <untitled>): C-style "==" comparison detected.

acme --cpu 6502 --format plain --setpc $e00 -DACORN_RELOCATABLE=1 -DACORN_TUBE_CACHE=1 -DACORN_SWR=1 -DACORN_SHADOW_VMEM=1 -l ..\temp\acme_labels_acorn_cache_e00 -r ..\temp\acme_report_acorn_cache_e00 --outfile ..\temp\acorn_cache_e00 acorn-cache.asm
Warning - File acorn-cache.asm, line 61 (Zone <untitled>): C-style "==" comparison detected.
Warning - File acorn-cache.asm, line 605 (Zone <untitled>): C-style "==" comparison detected.
Warning - File acorn-cache.asm, line 607 (Zone <untitled>): C-style "==" comparison detected.
Warning - File acorn-cache.asm, line 612 (Zone <untitled>): C-style "==" comparison detected.

acme --cpu 6502 --format plain --setpc $900 -DUSE_HISTORY=1 -l ..\temp\acme_labels_acorn_insv_900 -r ..\temp\acme_report_acorn_insv_900 --outfile ..\temp\acorn_insv_900 acorn-insv.asm
Warning - File acorn-insv.asm, line 26 (Zone <untitled>): C-style "==" comparison detected.


C:\Users\Me\Desktop\Ozmoo\ozmoo-acorn>

[SteveF]

Thanks for giving it a try Ken! Those should be harmless, but I've tagged up alpha 47 with those comparisons changed to use "=" instead of "==". There are no other changes compared to alpha 46.

My version of acme doesn't give these warnings, can you please let me know which version you're using? I should maybe update mine. I have:

Code: Select all

$ acme --version
This is ACME, release 0.97 ("Zem"), 31 Jan 2021
  Platform independent version.

[KenLowe]

Same version, apparently:

Code: Select all

C:\Users\Me\Desktop\Ozmoo\ozmoo-acorn>acme --version
This is ACME, release 0.97 ("Zem"), 4 Jul 2020
  DOS/OS2/Win32 version. Compiled by Dirk Hoepfner

The warnings are gone with the latest release. Thanks .

Edit: Apart from this one, which has generated a couple of errors, and then fails:

Code: Select all

C:\Users\Me\Desktop\Ozmoo\ozmoo-acorn>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-r2-sAS000C.z1 ..\Disk_Images\ADFS_Images\_zork1-r2.adf
acme --cpu 6502 --format plain --setpc $e00 -DACORN=1 -DACORN_CURSOR_PASS_THROUGH=1 -DSTACK_PAGES=4 -DSPLASHWAIT=0 -DACORN_INITIAL_NONSTORED_PAGES=46 -DACORN_DYNAMIC_SIZE_BYTES=11305 -DACORN_GAME_PAGES=324 -DACORN_LOADER_HIGHLIGHT_FG=131 -DACORN_ADFS=1 -DACORN_CURSOR_EDIT_READ=1 -DACORN_OSRDCH=1 -DUSE_HISTORY=48 -DACORN_SHOW_RUNTIME_INFO=1 -DSUPPORT_80COL=1 -DACORN_HW_SCROLL_SLOW=1 -DACORN_HW_SCROLL_FAST=1 -DZ1=1 -DVMEM=1 -DACORN_VMEM_BLOCKS=139 -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_MEDIUM_DYNMEM=1 -l ..\temp\acme_labels_ozmoo_electron_swr_mediumdyn_e00 -r ..\temp\acme_report_ozmoo_electron_swr_mediumdyn_e00 --outfile ..\temp\ozmoo_electron_swr_mediumdyn_e00 ozmoo.asm
Error - File screen.asm, line 935 (Zone <untitled>): Value not defined (.score_str).
Error - File screen.asm, line 955 (Zone <untitled>): Value not defined (.turns_str).
Error - File screen.asm, line 978 (Zone <untitled>): Value not defined (.statusline_done).

acme failed

C:\Users\Me\Desktop\Ozmoo\ozmoo-acorn>

Edit: Fixed typos!

[SteveF]

Thanks Ken, weird that these nominal 0.97 versions behave so differently, but I guess it's not a big deal. I'll try to remember not to use == in future and if you do get these warnings again a) please let me know b) they shouldn't actually matter, they're just mildly annoying at build time.

The other problem you reported is something I broke for Z1/Z2 games while tweaking the status line code. I've tagged up a very lightly tested alpha 48 which should fix this.

[8bit_era]

Just read this and thought I share my opinion on this. I am not sure if it really makes sense porting the Å-machine. The Dialog compiler has two output formats. One is its own Å-machine format but it also generates highly optimized Z-code. So one can easily compile games written in Dialog to a Z5 file, which then can be run in Ozmoo. The dialog language currently also misses a minimal library like PunyInform. The Dialog standard library in its current form comes with many features that need to be optimized to make it performant in constraint environments. I am currently working on such a library with Linus blessing but porting the Å-machine interpreter really is not necessary I believe. If you set the output to Z-code a Dialog game will run just fine in Ozmoo.

[KenLowe]

The other problem you reported is something I broke for Z1/Z2 games while tweaking the status line code. I've tagged up a very lightly tested alpha 48 which should fix this.

Yup, that seems to have fixed it, thanks. Everything's building perfectly now .

[SteveF]

Just read this and thought I share my opinion on this. I am not sure if it really makes sense porting the Å-machine. The Dialog compiler has two output formats. One is its own Å-machine format but it also generates highly optimized Z-code. So one can easily compile games written in Dialog to a Z5 file, which then can be run in Ozmoo. The dialog language currently also misses a minimal library like PunyInform. The Dialog standard library in its current form comes with many features that need to be optimized to make it performant in constraint environments. I am currently working on such a library with Linus blessing but porting the Å-machine interpreter really is not necessary I believe. If you set the output to Z-code a Dialog game will run just fine in Ozmoo.

This sounds like a cool project, do you have a dev blog or anything like that where we could follow along? It would be neat to expand the pool of games usable with Ozmoo in this way. (That said, if someone fancies porting the Å-machine anyway, that would also be interesting from a technical POV.)

[fredrikr]

I just released a collection of six games that all start at an airlock, for 25+ platforms, including Acorn/BBC computers.

https://twitter.com/FRamsberg/status/16 ... 8650248205

[KenLowe]

Hi Steve. Not sure if this is expected behaviour. I'm trying to run Zork1 from a 6502 Co-Pro, but I'm getting a Page too high error. Unplugging some of my ROMs seems to fix it, though. I'm loading from an ADFS HDD, and in this case have ADFS, DFS2.26 & DNFS1.20 enabled. Disabling DFS2.26 is enough to fix the problem (I'm using DFS2.26 with my 1770 disk controller and DNFS is being used for Econet & Tube host code):

[SteveF]

Hi Ken,

This is a quick post so take it with a pinch of salt, but I hope I'm not talking nonsense...

I think this is caused by the host cache; it tries to load at &2600 and relocate itself down to maximise free host memory, so if PAGE>&2600 this will happen. What PAGE do you have in the host? (You can double check this value of &2600 by looking at the load/exec address of the CACHE2P executable.)

You can probably also test if this is the problem by just doing "*RUN CACHE2P" from the BASIC prompt.

Right now I can't remember if this is something I recently changed or not but I can take a look later. Did things used to work with this setup on earlier versions? I suspect I may have tweaked this as part of the big cache tidying I did when adding support for using shadow RAM in the host cache.

It would definitely be nice to handle this more gracefully. We could (probably; I am not quite sure how it's done) at least check the host OSHWM from the loader and give a better error, or possibly disable the host cache at runtime. It might also be possible to accept a higher host OSHWM, although that might get complicated - I think I chose this value because it means that even on a machine with no shadow RAM, there will be at least two pages of host cache in mode 0 and thus the cache doesn't need special handling for low memory situations.

Cheers.

Steve

PS I find myself wondering if the above is true but irrelevant as it feels a bit unlikely your PAGE is quite so high in the first place, but this is the first thing that comes to mind. If this isn't the issue let me know and I'll see if I can take a look later.

[KenLowe]

I don't have access to my real hardware just now, but I've just tested this on BeebEm using pretty much the same hardware setup:

• BBC Model B with IntegraB. OSMODE 0 selected.
• With DFS2.26, ADFS1.30 & DNFS1.20 all enabled (and the Acorn 1770 disk controller selected from the hardware menu), PAGE on the host is sitting at &2100.
• Execute address for the Zork1 CACHE2P file is &2600.
• If I then enable the CoPro and run the Zork1 loader, I get the PAGE too high error.
• *RUN CACHE2P gives the same error.
• I've also tried BeebEm with a standard Model B (no IntegraB), and get the same results, so pretty sure we can eliminate the IntegraB.

I'm pretty sure I never saw this issue before the 'big cache tidy' exercise.

Thanks!

[SteveF]

Thanks Ken, I was able to reproduce this and I believe it should be fixed in alpha 49.

What follows is some technical waffle just for interest...

In alpha 45 (and earlier), CACHE2P loaded at &2C00 and relocated down to any lower OSHWM at runtime.

In alpha 48 (and probably 47), CACHE2P loaded at &2600 and relocated down to any lower OSHWM at runtime.

Your host OSHWM was &2100, but when the tube was enabled the font also got exploded, pushing it up by &600 to &2700 - higher than &2600, preventing CACHE2P running safely and causing the error you reported.

I lowered the address of CACHE2P in alpha 47/48 as part of the host cache tidying up because I realised there was a lurking corner case. Suppose we have a machine with a second processor, OSHWM at &2C00-ish after font explosion and no sideways RAM (edit:) and running in mode 0 with no shadow RAM. CACHE2P would load and run at &2C00-ish, but there would be no main RAM left over for use as cache, and with no sideways RAM either the host cache would have no room for any cache at all. The host cache code assumed this could never happen and would (probably; I don't think I actually tested it) misbehave as a result. So I decided to just ensure CACHE2P loaded low enough there would always be at least enough main RAM for one cache entry. As you've demonstrated, this breaks things on machines with high but not ridiculous values of PAGE.

Alpha 49 changes this so the host cache copes more gracefully with having no memory for cache entries - it patches itself on startup to just always say "no, I don't have that block" whatever it's asked for. I've reviewed (although it's a bit complex and it's just possible I've missed something) the core Ozmoo code where it preloads data into memory during startup and I think it works fine if the host cache has zero useful entries, so no changes were necessary there.

With this improvement to the host cache code, I've been able to bump the CACHE2P load address up to &2B00 (&2C00 wasn't safe, and probably never was), which should be fine in practice - it allows host PAGE pre-explosion to be as high as &2400 without any problems, and &2500 will work but may cause a loss of the ability to use spare shadow RAM as host cache on some machines.

Does anyone know how to read the host OSHWM across the tube? I couldn't find how to do this last time I looked. I suppose in practice we could peek the OS location holding OSHWM. This isn't critical, but it would be good to check this and give a more friendly error than the "PAGE too high" Ken experienced.

[KenLowe]

Thanks for the fix and the writeup. I can confirm that it's working again for me .

[SteveF]

Brilliant, thanks Ken!

I've had a quick play around and consulted AllMem.txt and I guess in practice I can query the host OSHWM with FNpeek(&244) - FNpeek being the loader function to peek host memory using OSWORD 5. This feels a bit unofficial but it's fine in practice, and it will allow me to generate a friendly error in the loader instead of CACHE2P generating one.

(But of course no one is *ever* going to have host PAGE>&2500, are they? )

[SteveF]

I'm pleased to announce Acorn Ozmoo 13.1 (alpha 50). As always, thanks to Johan and Fredrik for their continued work on Ozmoo!

Undo

I've merged the latest upstream changes. The main user-visible change is the addition of undo support, so you can take back the last action you performed.

• Undo is only supported if you're using a second processor.
• Undo must be enabled at build time by specifying the --undo option to make-acorn.py.

If both of those conditions are met:

• For Z1-4 games, which don't natively support undo, you can press CTRL-U at the prompt to undo the last move. A message will be printed if this works, otherwise you will get a low-pitched beep but nothing else will happen.
• For Z5-8 games, use the game's own support for undo - typically by typing "undo" at the prompt. CTRL-U does not do anything for these games; if the game itself doesn't support undo, you are out of luck.

Just to be clear, you only get one move's worth of undo.

Building with --undo does come with some performance penalties; in practice these are not a big deal, but see the technical details below if you're concerned.

Allow "x" as a synonym for "examine"

The other new user-visible feature is something I've added myself: an experimental option --x-for-examine which will add extra code to the game to make "x" entered at the prompt act like "examine". This only works for Z1-4 games and may be buggy, but I think it improves the playability of games like Hollywood Hijinx which don't natively recognise this abbreviation.

Exhortation to test

This is definitely an alpha release; I have only given it some very light testing, and the merge of the latest upstream changes plus these new features could easily have introduced bugs.

Please give it a go and let me know how you get on. Do post to tell me if it all works fine, as well as if you find something broken! Otherwise it's hard to distinguish "no one has tried it" from "it works so well no one is complaining". And yes, I know it's summer so everyone has better things to do than play adventure games on vintage computers...

Mildly technical details for anyone interested

Behind the scenes, undo works by taking a copy of the game state just before each move, and restoring it if you choose to undo. This means that Ozmoo has to set aside enough memory for a copy of the game's dynamic memory and stack (plus a few extra bytes) to hold the saved state, which reduces the memory available for virtual memory cache and therefore incurs a performance penalty from additional disc access during play. The extent to which this is noticeable will depend on how much free memory your system has; running in mode 6 or 7 will help, as will having shadow RAM and/or sideways RAM. Fast filing systems will also reduce the impact of this, of course. Copying the game state before each move also takes time, adding a further performance penalty.

I'm not trying to put anyone off by mentioning these performance penalties. In practice they are not likely to be a big deal, but this is why undo is not enabled automatically. With a 3MHz co-pro and running in mode 3, a 32K BBC B takes 35% longer to complete the benchmark with undo enabled. Giving the machine 144K of sideways RAM brings the penalty down to 26% longer (an otherwise like-for-like comparison, i.e. with 144K of sideways RAM for the runs with and without undo). Of course, when you're actually playing yourself you are unlikely to notice this, as the primary bottleneck is you typing commands at the keyboard!

In order to avoid excessive performance penalties and for consistency with upstream (specifically, a Commodore 128 with no RAM expansion unit), --undo will be ignored (with a warning) if it would consume more than 19.25K of memory.

Building a game with --undo has no effect when running the game on machines without a second processor - they don't support undo, and they suffer no performance penalties either.

[KenLowe]

Nice update. Thanks! I'll give this a test shortly...

Edit: Seems to have built ok, but with a lot of new warnings. I've only included the first warning. All other warnings are the same:

Code: Select all

C:\Ozmoo\ozmoo-acorn>python make-acorn.py --splash-image=..\downloads\zork-1-wip-4.scr --splash-mode=1 -a -p --undo --title "Zork1: The Great Underground Empire" ..\downloads\zork1-r2-sAS000C.z1 ..\Disk_Images\ADFS_Images\_zork1-r2.adf
acme --cpu 6502 --format plain --setpc $e00 -DACORN=1 -DACORN_CURSOR_PASS_THROUGH=1 -DSTACK_PAGES=4 -DSPLASHWAIT=0 -DACORN_INITIAL_NONSTORED_PAGES=46 -DACORN_DYNAMIC_SIZE_BYTES=11305 -DACORN_GAME_PAGES=324 -DACORN_LOADER_HIGHLIGHT_FG=131 -DZP_BYTES_TO_SAVE=13 -DACORN_ADFS=1 -DACORN_CURSOR_EDIT_READ=1 -DACORN_OSRDCH=1 -DUSE_HISTORY=48 -DACORN_SHOW_RUNTIME_INFO=1 -DSUPPORT_80COL=1 -DACORN_HW_SCROLL_SLOW=1 -DACORN_HW_SCROLL_FAST=1 -DZ1=1 -DVMEM=1 -DACORN_VMEM_BLOCKS=139 -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_MEDIUM_DYNMEM=1 -l ..\temp\acme_labels_ozmoo_electron_swr_mediumdyn_e00 -r ..\temp\acme_report_ozmoo_electron_swr_mediumdyn_e00 --outfile ..\temp\ozmoo_electron_swr_mediumdyn_e00 ozmoo.asm
Warning - File acorn-ozmoo-constants.asm, line 473 (Zone <untitled>): C-style "==" comparison detected.

And here's it running from a SCSI HDD image mounted on BeebEm. I'm going to copy the image over to my Econet FS shortly.

Adventure - Z5 Undo

Hollywood - Z3 Undo

[SteveF]

Thanks for giving that a try Ken, much appreciated! Sorry about the warning creeping in, I've pushed a fix in alpha 51.

The only other change in alpha 51 is that it now checks the game header and ignores (with a warning) the --undo option if a Z5+ game doesn't support undo. This avoids a worst of all possible worlds case where memory is set aside for an undo buffer which can never actually be used. I think this should be safe/correct, but if anyone finds a game which does support undo but doesn't have the undo header bit set let me know and I'll add a way to force this.

Edit: Incidentally I went and had a look at the acme source. My version (https://sourceforge.net/projects/acme-crossass/) has code in alu.c to generate this warning, but it's commented out, and there's an also-commented-out version which gives the "opposite" warning, i.e. warns if a single "=" is used in comparisons! For now I have experimentally reintroduced the warning for "==" use on one of my machines (and I'll try to remember to do it on the other one later) so I might notice if I use this again. I'll provisionally assume that there aren't actually any plans to enable the "opposite" warning in future, despite what the source code seems to imply.

[KenLowe]

Thanks. That fixed it. Very lightly tested, but all running nicely from ADFS HDD and Econet so far .

[SteveF]

Excellent, thanks Ken!

[tnash]

Just out of interest and laziness, is anyone keeping a repository of ssd's for games that are known to work with ozmoo, or do we need to roll our own?

[SteveF]

Just out of interest and laziness, is anyone keeping a repository of ssd's for games that are known to work with ozmoo, or do we need to roll our own?

It's not a huge collection, but FWIW I think most/all of the games tagged with Inform/PunyInform on bbcmicro.co.uk are using Ozmoo, and you can download SSDs for them.

[fredrikr]

Ozmoo Online now has rudimentary support for building disk images for Acorn/BBC computers. https://ozmoo.online/

[SteveF]

Fantastic work Fredrik, thanks for doing this! I just built an SSD of Freefall and it worked first time.

[KenLowe]

Fantastic work Fredrik, thanks for doing this! I just built an SSD of Freefall and it worked first time.

Agreed. I just tried a build of Zork, and that also worked nicely! An option to build an .adf image as well as the .ssd image would also be very nice .

@SteveF - I was going to ask if there were any plans to update the Acorn port to v14.x, but I just had a quick look at the repo, and noticed some recent activity!

[SteveF]

@SteveF - I was going to ask if there were any plans to update the Acorn port to v14.x, but I just had a quick look at the repo, and noticed some recent activity!

Yes, I'm tinkering with it intermittently and hope to post an alpha soon. 14.x is a very impressive release in general - there's support for a whole new machine (the Commander X16), just for starters - but from an Acorn perspective it is really an incremental bugfix release compared to the 13.x series, and from the lack of any bug reports here I'm assuming no users actually got bitten by those bugs. Still, it would be good to see the latest version number on the Acorn port and I am definitely working on it. There are also a few neat little optimisations in there which may bump the performance up slightly.

[fredrikr]

An option to build an .adf image as well as the .ssd image would also be very nice .

Added.