PunyInform and Ozmoo

bbc/electron apps, languages, utils, educational progs, demos + more
fredrikr
Posts: 40
Joined: Sat Jul 18, 2020 11:20 pm
Contact:

Re: PunyInform and Ozmoo

Post by fredrikr »

Just a quick note to let you all know that Ozmoo 5 has now been released. The biggest news is that it has support for C128 and Plus/4 platforms.

This is the grand finale of a few months of pretty intense work on Ozmoo.

Ozmoo Online ( http://microheaven.com/ozmooonline/ ) has support for these new targets.
SteveF
Posts: 935
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

Thanks Fredrik, and congratulations! I'll probably start taking a look at porting this after Christmas. I'll probably promote the current Acorn port to beta status at that point, and then the port of Ozmoo 5 will be marked as alpha.
User avatar
KenLowe
Posts: 1755
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: PunyInform and Ozmoo

Post by KenLowe »

SteveF wrote:
Mon Dec 21, 2020 11:28 pm
Thanks Fredrik, and congratulations! I'll probably start taking a look at porting this after Christmas. I'll probably promote the current Acorn port to beta status at that point, and then the port of Ozmoo 5 will be marked as alpha.
I see a sneaky version update has recently appeared on your github page :)
SteveF
Posts: 935
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

It has, but it may not be what it seems. It depends what exactly you're referring to on my github page. :-)

Acorn Ozmoo 4.4 hasn't had any bugs reported in a while and I should probably have promoted it from "alpha" status a while ago. As I'm close to announcing the first alpha release of Acorn Ozmoo 5.8, I thought that would be a good point to make a "proper" release of 4.4, just for neatness. So there is a tagged release of "4.4 (Acorn 2021-02-18)" here: https://github.com/ZornsLemma/ozmoo/rel ... 2021-02-18 However, except for the version number, it's identical to "4.4 (Acorn alpha 3.7e)". Thanks to Fredrik for his encouragement here!

I have been tinkering with Acorn Ozmoo 5.x and you may have seen the 5.x branch in my github repository. I was hoping to announce the first alpha of that last weekend, but I found a performance regression and so I want to do a little more tinkering with it before I ask people to test it. I hope to be announcing this in the next week, probably within the next few days. Anyone who feels particularly keen is free to try the code on that 5.x branch now, but it's fairly likely to be broken as it's still in development.
SteveF
Posts: 935
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

I'm pleased to announce the first alpha release of Acorn Ozmoo 5.8. You can get it from github here: https://github.com/ZornsLemma/ozmoo/rel ... .8-alpha-1

Please expect bugs, and please report them here so I can investigate. If you're making a "professional" release of a Z-machine game, you should almost certainly be using 4.4; see my previous post for details.

So what's new?
  • The version number is higher. Come on, what more could you want? New! Shiny! With added vitamin D!
  • The sideways RAM version is a little bit faster, although it will vary a bit with game, machine and build options. In regression testing I've seen about 1.5-4.5% improvement on the benchmark, auto-playing Hollywood Hijinx to completion. The second processor version should be about the same speed as 4.4. (This isn't a huge improvement, but small changes will accumulate and I'd hate for Acorn Ozmoo to get a few percent slower every time there's a new version, so this is at least moving in the right direction.)
  • The Electron is no longer such a special case; it's treated more like a BBC B which doesn't have mode 7 and has a different mechanism for sideways ROM paging. (This goes both ways, actually; the BBC machines can now use memory in the same way the Electron always did in Ozmoo 4.4.) This means the Electron can handle slightly larger games; it's no longer limited to games needing <=16K of dynamic memory.
  • On a BBC B with no shadow RAM Ozmoo can now automatically use all main RAM, so you'll have extra memory available - which means less disc access - if you have a filing system with PAGE=&E00, but the game will still work with higher values of PAGE. (It was possible to manually tweak the build to take advantage of PAGE=&E00 before, but such a build wouldn't work on a machine with a higher PAGE.) As a beneficial side effect, the "Acorn screen hole has not been added" build error has been banished forever.
I have some plans for further enhancements but I would appreciate it if people could give this build some testing so I can get some confidence in it before I do any further tinkering. :-) Absolutely any kind of testing is useful, but I am slightly more interested in testing on machines with no shadow RAM.

Thanks as always to Johan and Fredrik for their work on upstream Ozmoo!

If you just want to build and play some games and see if you hit any bugs, you can stop reading here.

Additional slightly technical details

Advanced or curious users might like to know that:
  • Hardware scrolling is now disabled on all machines in mode 7. There was a minor glitch with the interaction between hardware scrolling and the coloured status line in mode 7. Software scrolling looks nicer and isn't significantly slower than hardware scrolling in mode 7, so it seemed best just to disable hardware scrolling rather than add code and complexity trying to fix this. (Software scrolling was always the default in mode 7; I doubt anyone ever used hardware scrolling, as you'd need to press CTRL-S to toggle into hardware scrolling mode.)
  • The PREOPT files generated by Ozmoo 4.x aren't compatible with Ozmoo 5.x. Pre-optimisation is still supported and works exactly the same, you just need to regenerate your PREOPT files using the same series of game commands you used to generate them originally. (I doubt anyone will be affected by this. But for the record: if you're using the pre-optimisation feature seriously, you should be re-using the series of commands to generate the PREOPT file, not treating the PREOPT file itself as valuable.)
Upstream Ozmoo is currently at version 5.10; I will pick the latest changes up soon, but having spent some time giving Acorn Ozmoo 5.8 a bit of testing prior to announcing this alpha release I don't want to risk merging them just yet. I was on the verge of releasing this alpha a week ago when I discovered the Electron version of 5.x was slower than 4.4 and had to chase down the problem.

I have a draft writeup of some nerdy technical details for those interested in that sort of thing, but I think I'll polish that up and post it in separate chunks over the next few days. If I'm not too busy fixing bugs, of course...

COMING SOON!
  • When *MORE* is really *LESS*!
  • Your Electron is LYING to you!
  • Make your Z-code games run faster with this one weird old trick!
Don't forget to like, share and subscribe give 5.8 some testing!
User avatar
KenLowe
Posts: 1755
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: PunyInform and Ozmoo

Post by KenLowe »

Thanks for this update Steve. I just tried to build a DFS game using the same command as before, but it's failed as follows:

Code: Select all

c:\Users\xxxxxx\Desktop\Ozmoo>python make-acorn.py -p --title "Alien Research Centre 3" arc3d.z3
Traceback (most recent call last):
  File "make-acorn.py", line 1815, in <module>
    make_disc_image()
  File "make-acorn.py", line 1599, in make_disc_image
    e = make_electron_swr_executable()
  File "make-acorn.py", line 1071, in make_electron_swr_executable
    return make_small_or_big_dynmem_executable(leafname, args, "Electron")
  File "make-acorn.py", line 1017, in make_small_or_big_dynmem_executable
    small_e = make_highest_possible_executable(leafname, args + small_dynmem_args, None)
  File "make-acorn.py", line 951, in make_highest_possible_executable
    e_low = make_optimally_aligned_executable(leafname, 0xe00, args, report_failure_prefix)
  File "make-acorn.py", line 988, in make_optimally_aligned_executable
    base_executable = make_ozmoo_executable(leafname, initial_start_addr, args, report_failure_prefix)
  File "make-acorn.py", line 926, in make_ozmoo_executable
    return OzmooExecutable(leafname, start_addr, args)
  File "make-acorn.py", line 818, in __init__
    Executable.__init__(self, "ozmoo.asm", leafname, version_maker, start_addr, args)
  File "make-acorn.py", line 671, in __init__
    run_and_check(["acme", "--cpu", cpu, "--format", "plain", "--setpc", "$" + ourhex(start_addr)] + self.args + ["-l", up(self._labels_filename), "-r", up(self._report_filename), "--outfile", up(self._asm_output_filename), asm_filename], None, lambda x: x.startswith("Warning"))
  File "make-acorn.py", line 148, in run_and_check
    child_warnings = [line for line in child_output if warning_filter(line)]
  File "make-acorn.py", line 148, in <listcomp>
    child_warnings = [line for line in child_output if warning_filter(line)]
  File "make-acorn.py", line 671, in <lambda>
    run_and_check(["acme", "--cpu", cpu, "--format", "plain", "--setpc", "$" + ourhex(start_addr)] + self.args + ["-l", up(self._labels_filename), "-r", up(self._report_filename), "--outfile", up(self._asm_output_filename), asm_filename], None, lambda x: x.startswith("Warning"))
TypeError: startswith first arg must be bytes or a tuple of bytes, not str

c:\Users\xxxxxx\Desktop\Ozmoo>
Building other DFS games give a similar error. On the other hand, ADFS builds seem to work fine:

Code: Select all

c:\Users\xxxxxx\Desktop\Ozmoo>python make-acorn.py -a -p --title "Alien Research Centre 3" arc3d.z3 _ARC3.adf

c:\Users\xxxxxx\Desktop\Ozmoo>
SteveF
Posts: 935
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

Hi Ken,

Thanks for trying this. I think this is probably a bug which only shows up with Python 3 and Windows - the command you mention works fine for me on Linux with Python 2 or 3.

I've created alpha 2 which I hope will fix this: https://github.com/ZornsLemma/ozmoo/rel ... .8-alpha-2

Edited to add: I'm a bit surprised this only affects DFS games, but let's see if the fix works for you before worrying about it. :-)

Edited to add 2: Actually, I think it might not be a Linux-vs-Windows problem - it might be different versions of the acme assembler generate different warnings, and my version doesn't generate any warnings and bypasses a bug in make-acorn.py in Python 3. Can you please let me know the exact version of acme you're running, and I'll try that one myself? I still hope alpha 2 will fix this for you anyway, but if there is a warning from some acme versions it would be good to fix it in my code.

Let me know how you get on...

Cheers.

Steve
User avatar
KenLowe
Posts: 1755
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: PunyInform and Ozmoo

Post by KenLowe »

SteveF wrote:
Sun Feb 28, 2021 8:43 pm
Hi Ken,

Thanks for trying this. I think this is probably a bug which only shows up with Python 3 and Windows - the command you mention works fine for me on Linux with Python 2 or 3.

I've created alpha 2 which I hope will fix this: https://github.com/ZornsLemma/ozmoo/rel ... .8-alpha-2

Edited to add: I'm a bit surprised this only affects DFS games, but let's see if the fix works for you before worrying about it. :-)

Edited to add 2: Actually, I think it might not be a Linux-vs-Windows problem - it might be different versions of the acme assembler generate different warnings, and my version doesn't generate any warnings and bypasses a bug in make-acorn.py in Python 3. Can you please let me know the exact version of acme you're running, and I'll try that one myself? I still hope alpha 2 will fix this for you anyway, but if there is a warning from some acme versions it would be good to fix it in my code.

Let me know how you get on...

Cheers.

Steve
Yikes! Am I perhaps using an old version of Python?

Edit - Sorry, just seen your second edit. Let me check...

Code: Select all

c:\Users\xxxxxx\Desktop\Ozmoo>python make-acorn.py -p --title "Zork1: The Great Underground Empire" zork1.z3
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_BLOCKS=48 -DACORN_DYNAMIC_SIZE_BYTES=11859 -DACORN_VMEM_BLOCKS=156 -DACORN_CURSOR_EDIT_READ=1 -DZ3=1 -DVMEM=1 -DACORN_SWR=1 -DACORN_RELOCATABLE=1 -DACORN_ELECTRON_SWR=1 -DACORN_SCREEN_HOLE=1 -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
Warning - File acorn.asm, line 829 (Macro acorn_deletable_init_inline): Binary literal with strange number of digits.
Warning - File ozmoo.asm, line 1635 (Subzone deletable_init): ...called from here.

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_BLOCKS=48 -DACORN_DYNAMIC_SIZE_BYTES=11859 -DACORN_VMEM_BLOCKS=156 -DACORN_CURSOR_EDIT_READ=1 -DZ3=1 -DVMEM=1 -DACORN_SWR=1 -DACORN_RELOCATABLE=1 -DACORN_ELECTRON_SWR=1 -DACORN_SCREEN_HOLE=1 -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.asm, line 829 (Macro acorn_deletable_init_inline): Binary literal with strange number of digits.
Warning - File ozmoo.asm, line 1635 (Subzone deletable_init): ...called from here.

acme --cpu 6502 --format plain --setpc $f00 -DACORN=1 -DACORN_CURSOR_PASS_THROUGH=1 -DSTACK_PAGES=4 -DSMALLBLOCK=1 -DSPLASHWAIT=0 -DACORN_HW_SCROLL=1 -DACORN_INITIAL_NONSTORED_BLOCKS=48 -DACORN_DYNAMIC_SIZE_BYTES=11859 -DACORN_VMEM_BLOCKS=156 -DACORN_CURSOR_EDIT_READ=1 -DZ3=1 -DVMEM=1 -DACORN_SWR=1 -DACORN_RELOCATABLE=1 -DACORN_ELECTRON_SWR=1 -DACORN_SCREEN_HOLE=1 -DACORN_SWR_MEDIUM_DYNMEM=1 -l ..\temp\acme_labels_ozmoo_electron_swr_mediumdyn_f00 -r ..\temp\acme_report_ozmoo_electron_swr_mediumdyn_f00 --outfile ..\temp\ozmoo_electron_swr_mediumdyn_f00 ozmoo.asm
Warning - File acorn.asm, line 829 (Macro acorn_deletable_init_inline): Binary literal with strange number of digits.
Warning - File ozmoo.asm, line 1635 (Subzone deletable_init): ...called from here.

acme --cpu 6502 --format plain --setpc $1a00 -DACORN=1 -DACORN_CURSOR_PASS_THROUGH=1 -DSTACK_PAGES=4 -DSMALLBLOCK=1 -DSPLASHWAIT=0 -DACORN_HW_SCROLL=1 -DACORN_INITIAL_NONSTORED_BLOCKS=48 -DACORN_DYNAMIC_SIZE_BYTES=11859 -DACORN_VMEM_BLOCKS=156 -DACORN_CURSOR_EDIT_READ=1 -DZ3=1 -DVMEM=1 -DACORN_SWR=1 -DACORN_RELOCATABLE=1 -DACORN_ELECTRON_SWR=1 -DACORN_SCREEN_HOLE=1 -DACORN_SWR_MEDIUM_DYNMEM=1 -l ..\temp\acme_labels_ozmoo_electron_swr_mediumdyn_1a00 -r ..\temp\acme_report_ozmoo_electron_swr_mediumdyn_1a00 --outfile ..\temp\ozmoo_electron_swr_mediumdyn_1a00 ozmoo.asm
Warning - File acorn.asm, line 829 (Macro acorn_deletable_init_inline): Binary literal with strange number of digits.
Warning - File ozmoo.asm, line 1635 (Subzone deletable_init): ...called from here.

acme --cpu 6502 --format plain --setpc $1900 -DACORN=1 -DACORN_CURSOR_PASS_THROUGH=1 -DSTACK_PAGES=4 -DSMALLBLOCK=1 -DSPLASHWAIT=0 -DACORN_HW_SCROLL=1 -DACORN_INITIAL_NONSTORED_BLOCKS=48 -DACORN_DYNAMIC_SIZE_BYTES=11859 -DACORN_VMEM_BLOCKS=156 -DACORN_CURSOR_EDIT_READ=1 -DZ3=1 -DVMEM=1 -DACORN_SWR=1 -DACORN_RELOCATABLE=1 -DACORN_ELECTRON_SWR=1 -DACORN_SCREEN_HOLE=1 -DACORN_SWR_MEDIUM_DYNMEM=1 -l ..\temp\acme_labels_ozmoo_electron_swr_mediumdyn_1900 -r ..\temp\acme_report_ozmoo_electron_swr_mediumdyn_1900 --outfile ..\temp\ozmoo_electron_swr_mediumdyn_1900 ozmoo.asm
Warning - File acorn.asm, line 829 (Macro acorn_deletable_init_inline): Binary literal with strange number of digits.
Warning - File ozmoo.asm, line 1635 (Subzone deletable_init): ...called from here.

acme --cpu 6502 --format plain --setpc $e00 -DACORN=1 -DACORN_CURSOR_PASS_THROUGH=1 -DSTACK_PAGES=4 -DSMALLBLOCK=1 -DSPLASHWAIT=0 -DACORN_INITIAL_NONSTORED_BLOCKS=48 -DACORN_DYNAMIC_SIZE_BYTES=11859 -DACORN_VMEM_BLOCKS=156 -DACORN_CURSOR_EDIT_READ=1 -DZ3=1 -DVMEM=1 -DACORN_SWR=1 -DACORN_RELOCATABLE=1 -DMODE_7_STATUS=1 -DACORN_SCREEN_HOLE=1 -DACORN_SWR_SMALL_DYNMEM=1 -l ..\temp\acme_labels_ozmoo_bbc_swr_smalldyn_e00 -r ..\temp\acme_report_ozmoo_bbc_swr_smalldyn_e00 --outfile ..\temp\ozmoo_bbc_swr_smalldyn_e00 ozmoo.asm
Warning - File acorn.asm, line 829 (Macro acorn_deletable_init_inline): Binary literal with strange number of digits.
Warning - File ozmoo.asm, line 1635 (Subzone deletable_init): ...called from here.

acme --cpu 6502 --format plain --setpc $f00 -DACORN=1 -DACORN_CURSOR_PASS_THROUGH=1 -DSTACK_PAGES=4 -DSMALLBLOCK=1 -DSPLASHWAIT=0 -DACORN_INITIAL_NONSTORED_BLOCKS=48 -DACORN_DYNAMIC_SIZE_BYTES=11859 -DACORN_VMEM_BLOCKS=156 -DACORN_CURSOR_EDIT_READ=1 -DZ3=1 -DVMEM=1 -DACORN_SWR=1 -DACORN_RELOCATABLE=1 -DMODE_7_STATUS=1 -DACORN_SCREEN_HOLE=1 -DACORN_SWR_SMALL_DYNMEM=1 -l ..\temp\acme_labels_ozmoo_bbc_swr_smalldyn_f00 -r ..\temp\acme_report_ozmoo_bbc_swr_smalldyn_f00 --outfile ..\temp\ozmoo_bbc_swr_smalldyn_f00 ozmoo.asm
Warning - File acorn.asm, line 829 (Macro acorn_deletable_init_inline): Binary literal with strange number of digits.
Warning - File ozmoo.asm, line 1635 (Subzone deletable_init): ...called from here.

acme --cpu 6502 --format plain --setpc $2400 -DACORN=1 -DACORN_CURSOR_PASS_THROUGH=1 -DSTACK_PAGES=4 -DSMALLBLOCK=1 -DSPLASHWAIT=0 -DACORN_INITIAL_NONSTORED_BLOCKS=48 -DACORN_DYNAMIC_SIZE_BYTES=11859 -DACORN_VMEM_BLOCKS=156 -DACORN_CURSOR_EDIT_READ=1 -DZ3=1 -DVMEM=1 -DACORN_SWR=1 -DACORN_RELOCATABLE=1 -DMODE_7_STATUS=1 -DACORN_SCREEN_HOLE=1 -DACORN_SWR_SMALL_DYNMEM=1 -l ..\temp\acme_labels_ozmoo_bbc_swr_smalldyn_2400 -r ..\temp\acme_report_ozmoo_bbc_swr_smalldyn_2400 --outfile ..\temp\ozmoo_bbc_swr_smalldyn_2400 ozmoo.asm
Warning - File acorn.asm, line 829 (Macro acorn_deletable_init_inline): Binary literal with strange number of digits.
Warning - File ozmoo.asm, line 1635 (Subzone deletable_init): ...called from here.

acme --cpu 6502 --format plain --setpc $2300 -DACORN=1 -DACORN_CURSOR_PASS_THROUGH=1 -DSTACK_PAGES=4 -DSMALLBLOCK=1 -DSPLASHWAIT=0 -DACORN_INITIAL_NONSTORED_BLOCKS=48 -DACORN_DYNAMIC_SIZE_BYTES=11859 -DACORN_VMEM_BLOCKS=156 -DACORN_CURSOR_EDIT_READ=1 -DZ3=1 -DVMEM=1 -DACORN_SWR=1 -DACORN_RELOCATABLE=1 -DMODE_7_STATUS=1 -DACORN_SCREEN_HOLE=1 -DACORN_SWR_SMALL_DYNMEM=1 -l ..\temp\acme_labels_ozmoo_bbc_swr_smalldyn_2300 -r ..\temp\acme_report_ozmoo_bbc_swr_smalldyn_2300 --outfile ..\temp\ozmoo_bbc_swr_smalldyn_2300 ozmoo.asm
Warning - File acorn.asm, line 829 (Macro acorn_deletable_init_inline): Binary literal with strange number of digits.
Warning - File ozmoo.asm, line 1635 (Subzone deletable_init): ...called from here.

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_BLOCKS=48 -DACORN_DYNAMIC_SIZE_BYTES=11859 -DACORN_VMEM_BLOCKS=156 -DACORN_CURSOR_EDIT_READ=1 -DZ3=1 -DVMEM=1 -DACORN_SWR=1 -DACORN_RELOCATABLE=1 -DMODE_7_STATUS=1 -DACORN_SWR_SMALL_DYNMEM=1 -l ..\temp\acme_labels_ozmoo_bbc_swr_shr_smalldyn_e00 -r ..\temp\acme_report_ozmoo_bbc_swr_shr_smalldyn_e00 --outfile ..\temp\ozmoo_bbc_swr_shr_smalldyn_e00 ozmoo.asm
Warning - File acorn.asm, line 829 (Macro acorn_deletable_init_inline): Binary literal with strange number of digits.
Warning - File ozmoo.asm, line 1635 (Subzone deletable_init): ...called from here.

acme --cpu 6502 --format plain --setpc $f00 -DACORN=1 -DACORN_CURSOR_PASS_THROUGH=1 -DSTACK_PAGES=4 -DSMALLBLOCK=1 -DSPLASHWAIT=0 -DACORN_HW_SCROLL=1 -DACORN_INITIAL_NONSTORED_BLOCKS=48 -DACORN_DYNAMIC_SIZE_BYTES=11859 -DACORN_VMEM_BLOCKS=156 -DACORN_CURSOR_EDIT_READ=1 -DZ3=1 -DVMEM=1 -DACORN_SWR=1 -DACORN_RELOCATABLE=1 -DMODE_7_STATUS=1 -DACORN_SWR_SMALL_DYNMEM=1 -l ..\temp\acme_labels_ozmoo_bbc_swr_shr_smalldyn_f00 -r ..\temp\acme_report_ozmoo_bbc_swr_shr_smalldyn_f00 --outfile ..\temp\ozmoo_bbc_swr_shr_smalldyn_f00 ozmoo.asm
Warning - File acorn.asm, line 829 (Macro acorn_deletable_init_inline): Binary literal with strange number of digits.
Warning - File ozmoo.asm, line 1635 (Subzone deletable_init): ...called from here.

acme --cpu 6502 --format plain --setpc $2700 -DACORN=1 -DACORN_CURSOR_PASS_THROUGH=1 -DSTACK_PAGES=4 -DSMALLBLOCK=1 -DSPLASHWAIT=0 -DACORN_HW_SCROLL=1 -DACORN_INITIAL_NONSTORED_BLOCKS=48 -DACORN_DYNAMIC_SIZE_BYTES=11859 -DACORN_VMEM_BLOCKS=156 -DACORN_CURSOR_EDIT_READ=1 -DZ3=1 -DVMEM=1 -DACORN_SWR=1 -DACORN_RELOCATABLE=1 -DMODE_7_STATUS=1 -DACORN_SWR_SMALL_DYNMEM=1 -l ..\temp\acme_labels_ozmoo_bbc_swr_shr_smalldyn_2700 -r ..\temp\acme_report_ozmoo_bbc_swr_shr_smalldyn_2700 --outfile ..\temp\ozmoo_bbc_swr_shr_smalldyn_2700 ozmoo.asm
Warning - File acorn.asm, line 829 (Macro acorn_deletable_init_inline): Binary literal with strange number of digits.
Warning - File ozmoo.asm, line 1635 (Subzone deletable_init): ...called from here.

acme --cpu 6502 --format plain --setpc $2600 -DACORN=1 -DACORN_CURSOR_PASS_THROUGH=1 -DSTACK_PAGES=4 -DSMALLBLOCK=1 -DSPLASHWAIT=0 -DACORN_HW_SCROLL=1 -DACORN_INITIAL_NONSTORED_BLOCKS=48 -DACORN_DYNAMIC_SIZE_BYTES=11859 -DACORN_VMEM_BLOCKS=156 -DACORN_CURSOR_EDIT_READ=1 -DZ3=1 -DVMEM=1 -DACORN_SWR=1 -DACORN_RELOCATABLE=1 -DMODE_7_STATUS=1 -DACORN_SWR_SMALL_DYNMEM=1 -l ..\temp\acme_labels_ozmoo_bbc_swr_shr_smalldyn_2600 -r ..\temp\acme_report_ozmoo_bbc_swr_shr_smalldyn_2600 --outfile ..\temp\ozmoo_bbc_swr_shr_smalldyn_2600 ozmoo.asm
Warning - File acorn.asm, line 829 (Macro acorn_deletable_init_inline): Binary literal with strange number of digits.
Warning - File ozmoo.asm, line 1635 (Subzone deletable_init): ...called from here.

acme --cpu 65c02 --format plain --setpc $700 -DACORN=1 -DACORN_CURSOR_PASS_THROUGH=1 -DSTACK_PAGES=4 -DSMALLBLOCK=1 -DSPLASHWAIT=0 -DACORN_HW_SCROLL=1 -DACORN_INITIAL_NONSTORED_BLOCKS=48 -DACORN_DYNAMIC_SIZE_BYTES=11859 -DACORN_VMEM_BLOCKS=156 -DACORN_CURSOR_EDIT_READ=1 -DZ3=1 -DMODE_7_STATUS=1 -DACORN_TURBO_SUPPORTED=1 -DCMOS=1 -l ..\temp\acme_labels_ozmoo_tube_novmem_700 -r ..\temp\acme_report_ozmoo_tube_novmem_700 --outfile ..\temp\ozmoo_tube_novmem_700 ozmoo.asm
Warning - File acorn.asm, line 829 (Macro acorn_deletable_init_inline): Binary literal with strange number of digits.
Warning - File ozmoo.asm, line 1635 (Subzone deletable_init): ...called from here.

acme --cpu 65c02 --format plain --setpc $700 -DACORN=1 -DACORN_CURSOR_PASS_THROUGH=1 -DSTACK_PAGES=4 -DSMALLBLOCK=1 -DSPLASHWAIT=0 -DACORN_HW_SCROLL=1 -DACORN_INITIAL_NONSTORED_BLOCKS=48 -DACORN_DYNAMIC_SIZE_BYTES=11859 -DACORN_VMEM_BLOCKS=156 -DACORN_CURSOR_EDIT_READ=1 -DZ3=1 -DMODE_7_STATUS=1 -DACORN_TURBO_SUPPORTED=1 -DCMOS=1 -DVMEM=1 -DACORN_TUBE_CACHE=1 -DACORN_TUBE_CACHE_MIN_TIMESTAMP=0 -DACORN_TUBE_CACHE_MAX_TIMESTAMP=224 -l ..\temp\acme_labels_ozmoo_tube_700 -r ..\temp\acme_report_ozmoo_tube_700 --outfile ..\temp\ozmoo_tube_700 ozmoo.asm
Warning - File acorn.asm, line 829 (Macro acorn_deletable_init_inline): Binary literal with strange number of digits.
Warning - File ozmoo.asm, line 1635 (Subzone deletable_init): ...called from here.


c:\Users\xxxxxx\Desktop\Ozmoo>
SteveF
Posts: 935
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

Thanks Ken. No, I think your Python is fine. What seems to be happening is your acme is generating warnings - which are probably harmless, but I will investigate - and the build script is showing those so they don't get ignored. I think my acme may be a little bit older and doesn't generate those warnings, otherwise I'd have fixed them already. (4.4 was more prone to hiding warnings during the build, that's one of the small changes in 5.x.)

Edited to add: alpha 3 should fix that warning: https://github.com/ZornsLemma/ozmoo/rel ... .8-alpha-3
User avatar
KenLowe
Posts: 1755
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: PunyInform and Ozmoo

Post by KenLowe »

SteveF wrote:
Sun Feb 28, 2021 8:43 pm
Can you please let me know the exact version of acme you're running, and I'll try that one myself?

Code: Select all

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

c:\Users\xxxxxx\Desktop\Ozmoo>
SteveF wrote:
Sun Feb 28, 2021 8:57 pm
I think your Python is fine.
Just for reference:

Code: Select all

c:\Users\xxxxxx\Desktop\Ozmoo>python
Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:21:23) [MSC v.1916 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
User avatar
KenLowe
Posts: 1755
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: PunyInform and Ozmoo

Post by KenLowe »

SteveF wrote:
Sun Feb 28, 2021 8:57 pm
Edited to add: alpha 3 should fix that warning: https://github.com/ZornsLemma/ozmoo/rel ... .8-alpha-3
That's fixed it. Everything is now building again. Thanks. Not tested on the beeb yet, though.

Edit: Ok, so tested a couple of DFS and ADFS games on the beeb with Shadow RAM and 2 x SWRAM banks, and all seem to be working fine.
SteveF
Posts: 935
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

KenLowe wrote:
Sun Feb 28, 2021 9:04 pm
SteveF wrote:
Sun Feb 28, 2021 8:57 pm
Edited to add: alpha 3 should fix that warning: https://github.com/ZornsLemma/ozmoo/rel ... .8-alpha-3
That's fixed it. Everything is now building again. Thanks. Not tested on the beeb yet, though.

Edit: Ok, so tested a couple of DFS and ADFS games on the beeb with Shadow RAM and 2 x SWRAM banks, and all seem to be working fine.
Brilliant, thanks Ken!

Just for the record, I was using a slightly older version of acme:

Code: Select all

This is ACME, release 0.96.2 ("Fenchurch"), 10 Mar 2017
  Platform independent version.
That's probably why you got a warning and I didn't; there was a six-bit binary constant in some DFS-specific code which triggered a warning. (The code was correct, but it's a fair warning and I've added a couple of leading 0s to keep acme happy.)

I'll probably switch to acme 0.96.4 ("Fenchurch")a newer version shortly.
User avatar
lurkio
Posts: 3387
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: PunyInform and Ozmoo

Post by lurkio »

I haven't changed my Acorn Ozmoo setup since last time I posted in this thread. If I upgrade to the latest version of Acorn Ozmoo, will I be able to revert to an earlier version (if I want to, for some reason)? I'm not sure. (My memory of how to upgrade is also a bit hazy... :oops: )

In the meantime, I decided to stick with the version I'm currently on and have a go at building what I think is the latest release of Mini-Zork 2:

https://github.com/heasm66/mini_zork_2_z3

That seemed to work fine. The built .SSD reports "Powered by Ozmoo 4.4 (Acorn alpha 3.7e)".

EDIT: I just remembered I can do this:

Code: Select all

$ git fetch
remote: Enumerating objects: 1094, done.
remote: Counting objects: 100% (1094/1094), done.
remote: Compressing objects: 100% (130/130), done.
remote: Total 2527 (delta 1016), reused 1038 (delta 962), pack-reused 1433
Receiving objects: 100% (2527/2527), 4.11 MiB | 4.86 MiB/s, done.
Resolving deltas: 100% (1869/1869), completed with 49 local objects.
From https://github.com/ZornsLemma/ozmoo
 * [new branch]      acorn-4.x             -> origin/acorn-4.x
 * [new branch]      acorn-5.3             -> origin/acorn-5.3
 * [new branch]      acorn-5.x             -> origin/acorn-5.x
 * [new branch]      acorn-bigdyn-exp      -> origin/acorn-bigdyn-exp
 * [new branch]      acorn-exe-mode-opt    -> origin/acorn-exe-mode-opt
 * [new branch]      acorn-global-hack     -> origin/acorn-global-hack
   587cb8d..23c2593  acorn-lzsa-executable -> origin/acorn-lzsa-executable
 * [new branch]      acorn-medium-dyn      -> origin/acorn-medium-dyn
 * [new branch]      acorn-mempointer-exp  -> origin/acorn-mempointer-exp
 * [new branch]      acorn-opt-exp         -> origin/acorn-opt-exp
 * [new branch]      acorn-opt-exp-2       -> origin/acorn-opt-exp-2
 * [new branch]      acorn-rnb-opt         -> origin/acorn-rnb-opt
 * [new branch]      acorn-screen-hole-exp -> origin/acorn-screen-hole-exp
 * [new branch]      exe-mode-opt          -> origin/exe-mode-opt
 * [new branch]      find-prop-opt         -> origin/find-prop-opt
 * [new branch]      fix1                  -> origin/fix1
   7b8a67f..b69a422  master                -> origin/master
 * [new branch]      mempointer-opt        -> origin/mempointer-opt
 * [new branch]      sbza-opt              -> origin/sbza-opt
 * [new branch]      status-tweaks         -> origin/status-tweaks
 * [new branch]      vmem-opt              -> origin/vmem-opt
 * [new tag]         acorn-4.4-2021-02-18  -> acorn-4.4-2021-02-18
 * [new tag]         stardot-ozmoo-preview-5.8-alpha-3 -> stardot-ozmoo-preview-5.8-alpha-3
 * [new tag]         stardot-ozmoo-preview-5.8-alpha-1 -> stardot-ozmoo-preview-5.8-alpha-1
 * [new tag]         stardot-ozmoo-preview-5.8-alpha-2 -> stardot-ozmoo-preview-5.8-alpha-2
So presumably I can do a "git checkout" on the 5.8-alpha-3 tag, and then test whatever I want to test, and then revert to 4.4 (if I want to, for some reason) by doing "git checkout acorn-4.4-2021-02-18"?

:?:
User avatar
KenLowe
Posts: 1755
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: PunyInform and Ozmoo

Post by KenLowe »

I just download the latest zip, and copy everything from the zip into my working folder. If I need to go back a revision I just copy everything from the earlier zip into my working folder.
SteveF
Posts: 935
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

TL;DR: both those approaches should be fine in practice, so do whatever's easiest.

I am 99% sure lurkio's "git checkout" method will work, because it's what I do myself. I sometimes flail around a bit getting the "git fetch" command right (because I don't do it very often), so if it doesn't work let me know and I'll try to figure out what's wrong. *If* (which you probably don't) you make any temporary tweaks to Ozmoo yourself you will probably get an error the next time you try to checkout and need to give a git command to say "it's OK, you can throw those changes away".

Ken's approach is also fine, although *if* a file got removed in one version it would probably be left lying around in the working folder and could in theory cause problems, but I don't believe Acorn Ozmoo does anything tricky in this area.
User avatar
lurkio
Posts: 3387
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: PunyInform and Ozmoo

Post by lurkio »

I upgraded to "Ozmoo 5.8 (Acorn alpha 3)" using git, and everything's working great.

I did notice this was still happening in Z3 Hitchhiker, though:
SteveF wrote:
Wed Nov 18, 2020 4:01 pm
lurkio wrote:
Wed Nov 18, 2020 1:29 am
But I did get to the end, and what I found was that when the game terminates it might help if Ozmoo printed a blank line before returning to BASIC -- because currently the word "BASIC" looks like it's part of the text printed by the game itself!

It might be even better if Ozmoo waited for a keypress before returning to BASIC..?
This is absolutely possible, it's not a bad idea and it's not hard to implement. The only thing that gives me the slightest pause is that it will increase the size of the Ozmoo executable a little bit, and these small changes build up and gradually erode the free memory for caching the game
I realise I said at the time that I thought it was a very unimportant and non-urgent issue, and that no extra memory should be wasted on implementing a fix, and I'm still of that opinion, as, I think, are you.

However..! What if when the player has won the game and it prints its final line of text (the victory message), your code jumped to the press-Shift-to-scroll routine, without printing anything else on screen at all? By that time the player will have got used to pressing Shift to scroll, so it'll probably occur to them to do so. And, when they do press Shift, the game can just end as it currently does (without necessarily needing to scroll any text at all)..?

I'm just trying, in my own naive way, to think of how you might implement this still very non-essential feature without taking up significant amounts of extra RAM. If my ideas don't make sense or would still consume too much memory, then please ignore them. There are obviously far more important things to implement first! (E.g. have you thought about foreign-language character sets..? [scarpers] :wink: )
SteveF
Posts: 935
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

lurkio wrote:
Thu Mar 04, 2021 2:48 pm
I upgraded to "Ozmoo 5.8 (Acorn alpha 3)" using git, and everything's working great.
Great, thanks for giving it a try!
lurkio wrote:
Thu Mar 04, 2021 2:48 pm
I did notice this was still happening in Z3 Hitchhiker, though:
SteveF wrote:
Wed Nov 18, 2020 4:01 pm
lurkio wrote:
Wed Nov 18, 2020 1:29 am
But I did get to the end, and what I found was that when the game terminates it might help if Ozmoo printed a blank line before returning to BASIC -- because currently the word "BASIC" looks like it's part of the text printed by the game itself!

It might be even better if Ozmoo waited for a keypress before returning to BASIC..?
This is absolutely possible, it's not a bad idea and it's not hard to implement. The only thing that gives me the slightest pause is that it will increase the size of the Ozmoo executable a little bit, and these small changes build up and gradually erode the free memory for caching the game
I realise I said at the time that I thought it was a very unimportant and non-urgent issue, and that no extra memory should be wasted on implementing a fix, and I'm still of that opinion, as, I think, are you.
I am, but I think it's important to keep a balance between compactness and polish/useful features. For example, the save/restore instructions ("Please enter a filename or * command or just press RETURN to carry on playing. You can safely remove the game disc now.") take 120 bytes just for the text, but I think having this makes the user experience a bit nicer.

And the fact that the current approach could cause part of the game-winning message to be lost as the "BASIC" message and prompt scrolls the screen outside Ozmoo's control means this does really need to be tweaked in some way.
lurkio wrote:
Thu Mar 04, 2021 2:48 pm
However..! What if when you've won the game and it prints its final line of text (the victory message), your code jumped to the press-Shift-to-scroll routine, without printing anything else on screen at all? By that time the player will have got used to pressing Shift to scroll, so it'll probably occur to them to do so. And, when they do press Shift, the game can just end as it currently does (without necessarily needing to scroll any text at all)..?

I'm just trying, in my own naive way, to think of how you might implement this still very non-essential feature without taking up significant amounts of extra RAM. If my ideas don't make sense or would still consume too much memory, then please ignore them.
I'm glad you're taking an interest in a small detail like this; it's nice to know I'm not the only one thinking about these little touches.

This isn't a bad suggestion at all and I might implement it; it wouldn't be hard and then you could give it a try. However, you've made me think about this again and I wonder if we're still over-complicating things:
  • Going back to first principles, there's a Z-machine instruction "quit" which the game executes when it's finished. For what it's worth, here's what the Z-machine standard says about it:
    Exit the game immediately. (Any "Are you sure?" question must be asked by the game, not the interpreter.) It is not legal to return from the main routine (that is, from where execution first begins) and this must be used instead.
    This instruction might be executed because the user quit the game, or it might be because the user has won the game. I don't believe Ozmoo can tell the difference between these two cases, for what it's worth.
  • On the Commodore machines, Ozmoo implements the "quit" instruction by calling kernal_reset, which reboots the machine, losing the contents of the screen completely. I wonder if I'm missing something here; what happens if someone finishes Z3 HHGTTG on Commodore Ozmoo? Will they not get to read the last bit of text?
  • frotz (running in a terminal) appears to print a "*** [Hit any key to exit.]" prompt when quitting, presumably to avoid this lost text problem.
  • The current Acorn implementation of the "quit" instruction re-enters BASIC, as we've discussed.
    • You can see the code (complete with long waffling TODO about this issue :-) ) here: https://github.com/ZornsLemma/ozmoo/blo ... .asm#L1756 The code takes 35 bytes in the worst case, because it has to reset things to reasonable defaults, although only 21 bytes by default (without ACORN_FUNCTION_KEY_PASS_THROUGH).
  • If I remember correctly, I decided to re-enter BASIC at this point because it seemed vaguely analogous to the way a DOS interpreter would return to the command line prompt, or the way frotz (running in a terminal) does the same.
  • But - unless other people use their Acorn machines way differently than I do - it's not as though you're going to have an ongoing terminal session on an Acorn machine which you want to return to after the game. So you might end up back at the BASIC prompt, but is anyone really going to start typing in a BASIC program there and then, or type CHAIN "FOO" to run another program? Maybe they are, but I think I would *always* press BREAK first to get the machine into a clean state, and if I wanted to run something else I'd be pressing SHIFT-BREAK anyway.
  • So how would it be if Acorn Ozmoo's "quit" implementation just printed "[Press BREAK]" and sat in an infinite loop?
    • This would be printed via the Ozmoo text output mechanism, so it would automatically pause for SHIFT if (and only if) there was some text the user hadn't had a chance to read.
    • Because pressing BREAK will automatically reset things, we don't need to waste space on the 21-35 bytes of code to set up various sensible defaults. Printing "[Press BREAK]" and hanging would take about 20 bytes, so we'd still come out ahead and we'd solve the "the user might miss some text" problem.
What do you think? I'm not averse to your SHIFT suggestion if you still think it's better, although it will be slightly more code because we need to print the message *and* reset the options so things work reasonably at the BASIC prompt (e.g. we're not stuck in reverse video).
lurkio wrote:
Thu Mar 04, 2021 2:48 pm
There are obviously far more important things to implement first! (E.g. have you thought about foreign-language character sets..? [scarpers] :wink: )
That's something I have thought about a little bit. :-) Upstream Ozmoo supports a pretty wide range of languages; my attitude with the Acorn port is that it's something I'm happy to look at when a fluent speaker turns up with a foreign language game they're interested in running.

I do plan to allow the BBC B with no shadow RAM to run in mode 6 - Ozmoo 5.x makes this a bit easier, for reasons I'll waffle about in an upcoming post on nerdy technical details - just like the Electron (obviously) always does. This would be helpful for foreign language games, since of course you can't redefine the character set in mode 7. (I'd expect to let the user run foreign language games in mode 7 as well, if they don't mind making do with the standard character set. For larger games, it might be a case of mode 7 or nothing.)
Last edited by SteveF on Thu Mar 04, 2021 7:57 pm, edited 1 time in total.
User avatar
lurkio
Posts: 3387
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: PunyInform and Ozmoo

Post by lurkio »

SteveF wrote:
Thu Mar 04, 2021 4:27 pm
So how would it be if Acorn Ozmoo's "quit" implementation just printed "[Press BREAK]" and sat in an infinite loop?
  • This would be printed via the Ozmoo text output mechanism, so it would automatically pause for SHIFT if (and only if) there was some text the user hadn't had a chance to read.
  • Because pressing BREAK will automatically reset things, we don't need to waste space on the 21-35 bytes of code to set up various sensible defaults. Printing "[Press BREAK]" and hanging would take about 20 bytes, so we'd still come out ahead and we'd solve the "the user might miss some text" problem.
On balance, taking everything you've said into consideration, I have to say that this "[Press BREAK]" fix strikes me as being the best all-round solution to the problem. In fact, I really like it! (But if it starts to look like you're running out of memory for other more important features, then I'd urge you to ditch the fix altogether, obviously! (EDIT: Oh, wait -- this press-Break fix would actually use less memory than the existing return-to-BASIC code, right? Then it's win-win!))

:idea:

(EDIT: Btw, the only reason I keep going on about this apparently minor issue is that it's literally the only complaint I've got about playing Hitchhiker on a Beeb! (Btw, those are surely the two greatest things ever to have come out of the BBC -- together at last!) The whole experience of playing z3 Hitchhiker in Acorn Ozmoo is so smooth and flawless and Teletexty -- and then you get to the end of the game and you suddenly see the word "BASIC" glued onto the bottom of the victory message! It's a little bit jarring -- but only because everything else about Acorn Ozmoo is so incredibly good.)
SteveF
Posts: 935
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

lurkio wrote:
Thu Mar 04, 2021 7:13 pm
On balance, taking everything you've said into consideration, I have to say that this "[Press BREAK]" fix strikes me as being the best all-round solution to the problem. In fact, I really like it! (But if it starts to look like you're running out of memory for other more important features, then I'd urge you to ditch the fix altogether, obviously! (EDIT: Oh, wait -- this press-Break fix would actually use less memory than the existing return-to-BASIC code, right? Then it's win-win!))
Yes, I've now implemented it and unless things have gone horribly wrong the Ozmoo code is now 13 bytes shorter (27 bytes shorter if you're using the --function-keys option to pass function keys through to the game, which most games won't need) and a couple of lingering TODO comments in the code have been done away with. Happy days!

I do wonder if a game might leave the output stream set to something other than the screen or do something else (superficially) weird when it calls "quit", causing the "[Press BREAK]" message to disappear into the ether or worse, but the few I've tried so far all seem to work.

Please give alpha 4 a test, quitting and winning as many games as possible. :-) You can do "git fetch"+"git checkout stardot-ozmoo-preview-5.8-alpha-4" or get the zip here: https://github.com/ZornsLemma/ozmoo/rel ... .8-alpha-4
lurkio wrote:
Thu Mar 04, 2021 7:13 pm
(EDIT: Btw, the only reason I keep going on about this apparently minor issue is that it's literally the only complaint I've got about playing Hitchhiker on a Beeb! (Btw, those are surely the two greatest things ever to have come out of the BBC -- together at last!) The whole experience of playing z3 Hitchhiker in Acorn Ozmoo is so smooth and flawless and Teletexty -- and then you get to the end of the game and you suddenly see the word "BASIC" glued onto the bottom of the victory message! It's a little bit jarring -- but only because everything else about Acorn Ozmoo is so incredibly good.)
Thanks! As a genuine question, from someone who still intends to play the game at some point - why do you prefer the z3 version over (say) the Solid Gold z5? Is it just faster on Acorn Ozmoo? Does it have some special "it's the version I played BITD" quality the others lack? Or something else altogether?
User avatar
lurkio
Posts: 3387
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: PunyInform and Ozmoo

Post by lurkio »

SteveF wrote:
Thu Mar 04, 2021 8:17 pm
Please give alpha 4 a test, quitting and winning as many games as possible.
I'll have a go, although the winning part might be a bit tricky as I don't know any other games half as well as Hitchhiker. But let me see what I can do...

SteveF wrote:
Thu Mar 04, 2021 8:17 pm
Thanks! As a genuine question, from someone who still intends to play the game at some point - why do you prefer the z3 version over (say) the Solid Gold z5? Is it just faster on Acorn Ozmoo? Does it have some special "it's the version I played BITD" quality the others lack? Or something else altogether?
The z3 version is, I think, the first version I ever played, so there's that. But I also had the notion, which may well be wrong, that it was somehow a better version to start testing Ozmoo with because it was smaller in filesize than the SG version and hence less complex, probably -- so I thought that testing Ozmoo with the z3 version, to begin with, might be a good way to make sure that Acorn Ozmoo had covered the essentials of the Z-machine spec. But, as I said, these were just vague notions in my own head that may well be absolute tosh!

In any case, I've now tested the SG version of Hitchhiker (in Ozmoo 5) too, and it seems fine -- very slightly slower than the z3, perhaps, but not by much -- if at all. I might just be imagining it. But it's very impressive to see Acorn Ozmoo handle SG Hitchhiker with its extensive menus and hints, etc.

Btw, I believe it's only the z3 version of Hitchhiker that drops you to the BASIC prompt when you win -- I seem to remember that when I used Ozmoo 5 and played all the way through the SG version of Hitchhiker, it gave me the RESTART/RESTORE/etc. options instead.

:idea:
SteveF
Posts: 935
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

lurkio wrote:
Fri Mar 05, 2021 1:22 am
SteveF wrote:
Thu Mar 04, 2021 8:17 pm
Please give alpha 4 a test, quitting and winning as many games as possible.
I'll have a go, although the winning part might be a bit tricky as I don't know any other games half as well as Hitchhiker. But let me see what I can do...
Thanks! This would be helpful, but I was half joking, so please don't burn off your enthusiasm struggling too much with this.
lurkio wrote:
Fri Mar 05, 2021 1:22 am
SteveF wrote:
Thu Mar 04, 2021 8:17 pm
Thanks! As a genuine question, from someone who still intends to play the game at some point - why do you prefer the z3 version over (say) the Solid Gold z5? Is it just faster on Acorn Ozmoo? Does it have some special "it's the version I played BITD" quality the others lack? Or something else altogether?
The z3 version is, I think, the first version I ever played, so there's that. But I also had the notion, which may well be wrong, that it was somehow a better version to start testing Ozmoo with because it was smaller in filesize than the SG version and hence less complex, probably -- so I thought that testing Ozmoo with the z3 version, to begin with, might be a good way to make sure that Acorn Ozmoo had covered the essentials of the Z-machine spec. But, as I said, these were just vague notions in my own head that may well be absolute tosh!
That's not unreasonable - being smaller and z3 should both contribute to improving the performance, and the mode 7 coloured status line is simpler and more reliable in z3 games. But if/when I finally get round to making a serious attempt to play the game for its own sake, there's no real reason I should prefer the z3 version? (I'd probably play it with frotz; on Acorn Ozmoo I'd be too worried about finding any bugs to enjoy the game. ;-) )
lurkio wrote:
Fri Mar 05, 2021 1:22 am
Btw, I believe it's only the z3 version of Hitchhiker that drops you to the BASIC prompt when you win -- I seem to remember that when I used Ozmoo 5 and played all the way through the SG version of Hitchhiker, it gave me the RESTART/RESTORE/etc. options instead.
I can believe that - I haven't won either, but I've died a few times (just playing around for testing, really - he said, not making excuses at all...) in z5 and I've noticed it giving that prompt, and I also note that Hollywood Hijinx does the same when you win that.
fredrikr
Posts: 40
Joined: Sat Jul 18, 2020 11:20 pm
Contact:

Re: PunyInform and Ozmoo

Post by fredrikr »

SteveF wrote:
Thu Mar 04, 2021 4:27 pm

[*]On the Commodore machines, Ozmoo implements the "quit" instruction by calling kernal_reset, which reboots the machine, losing the contents of the screen completely. I wonder if I'm missing something here; what happens if someone finishes Z3 HHGTTG on Commodore Ozmoo? Will they not get to read the last bit of text?
This is what happens, yes.

Few games do this, but we'll add a safeguard to Ozmoo on Commodore too. We'll probably show a MORE prompt, and when you press a key, the machine resets. This should cost three bytes, which is acceptable.
User avatar
lurkio
Posts: 3387
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: PunyInform and Ozmoo

Post by lurkio »

SteveF wrote:
Fri Mar 05, 2021 3:19 am
But if/when I finally get round to making a serious attempt to play the game for its own sake, there's no real reason I should prefer the z3 version?
I don't think so. The SG version has the advantage of built-in hints and the abbreviation X for EXAMINE (a godsend!), and it might have fewer bugs than the z3, although this list is cause for some doubt about that.

SteveF wrote:
Fri Mar 05, 2021 3:19 am
(I'd probably play it with frotz; on Acorn Ozmoo I'd be too worried about finding any bugs [in Acorn Ozmoo] to enjoy the game. ;-) )
You won't. Have faith!

:)

EDIT: Here's the victory screen for z3 Hitchhiker in the latest version of Acorn Ozmoo:

Screenshot 2021-03-05 at 13.09.07.png

If I were the most loathsome pedant in the universe I would say it'd be nice if there were a blank line between the victory message and "[Press BREAK]" -- but thankfully I'm not. :wink: (But, to be serious, I think this is already a great fix.)
SteveF
Posts: 935
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

fredrikr wrote:
Fri Mar 05, 2021 9:21 am
We'll probably show a MORE prompt, and when you press a key, the machine resets. This should cost three bytes, which is acceptable.
:-)
lurkio wrote:
Fri Mar 05, 2021 12:25 pm
SteveF wrote:
Fri Mar 05, 2021 3:19 am
But if/when I finally get round to making a serious attempt to play the game for its own sake, there's no real reason I should prefer the z3 version?
I don't think so. The SG version has the advantage of built-in hints and the abbreviation X for EXAMINE (a godsend!), and it might have fewer bugs than the z3, although this list is cause for some doubt about that.
Cheers, I'll probably use the SG version then. (I won't look at the list of bugs in case it's spoilery.)
lurkio wrote:
Fri Mar 05, 2021 12:25 pm
If I were the most loathsome pedant in the universe I would say it'd be nice if there were a blank line between the victory message and "[Press BREAK]" -- but thankfully I'm not. :wink: (But, to be serious, I think this is already a great fix.)
Well, if you were, you'd be in luck, because today's special offer is an extra blank line before "[Press BREAK]" COMPLETELY FREE! Yes, pay 0 bytes now and 0 bytes later! How can we do this? Volume! By chance there's an extra carriage return immediately before the "[Press BREAK]" string, so we just need to move a label back one byte to include it: https://github.com/ZornsLemma/ozmoo/com ... f930615c17

Alpha 5 is here: https://github.com/ZornsLemma/ozmoo/rel ... .8-alpha-5

Let me know if you like this or not. It unconditionally adds a blank line before "[Press BREAK]", so some games will end up with a two blank line gap where previously they had one and so on. I suspect it looks better to have a too-big gap in some games than no gap in others (like Z3 HHGTTG). I did it without the extra blank line before because that's what command-line frotz seems to do. (Detecting whether we've already printed a blank line or not would obviously be possible, but I think that would take more code than it would be worth.)
SteveF
Posts: 935
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

lurkio wrote:
Fri Mar 05, 2021 12:25 pm
The SG version has the advantage of built-in hints and the abbreviation X for EXAMINE (a godsend!)
You probably already knew, but for what it's worth, if you do:

Code: Select all

*KEY0 "EXAMINE "
before booting the game, f0 will act as a pseudo-substitute for X. (I know it's not as intuitive as just typing "X".)

Edit: I'm sure you knew about *KEY, my point is just that it works in Ozmoo too. :-)
User avatar
lurkio
Posts: 3387
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: PunyInform and Ozmoo

Post by lurkio »

SteveF wrote:
Fri Mar 05, 2021 5:54 pm
By chance there's an extra carriage return immediately before the "[Press BREAK]" string, so we just need to move a label back one byte to include it: https://github.com/ZornsLemma/ozmoo/com ... f930615c17 Alpha 5 is here: https://github.com/ZornsLemma/ozmoo/rel ... .8-alpha-5
Perfect!:

Screenshot 2021-03-05 at 23.55.32.png

SteveF wrote:
Fri Mar 05, 2021 5:54 pm
It unconditionally adds a blank line before "[Press BREAK]", so some games will end up with a two blank line gap where previously they had one and so on. I suspect it looks better to have a too-big gap in some games than no gap in others (like Z3 HHGTTG).
Yes, I suspect the same thing.

SteveF wrote:
Fri Mar 05, 2021 5:54 pm
Detecting whether we've already printed a blank line or not would obviously be possible, but I think that would take more code than it would be worth.
Agreed.

Incidentally, I'm reminded that I recently wanted to detect a preceding blank line in MODE7 in BASIC and came up with this:

Code: Select all

REM Is the previous line blank?
DEFFNb:LOCAL A%,B%,I%:VDU 11:A%=?&34B*256+?&34A:VDU 10
FOR I%=0 TO 39 STEP 4
B%=A%+I%:B%=B%+&400*(B%>&7FFF)
IF !B%=&20202020 NEXT:=TRUE ELSE I%=39:NEXT:=FALSE
Of course, as I said, I agree that it's really not worth adding code to Acorn Ozmoo for the sake of this feature. An extra blank line or two at the end of a game won't make much difference and probably won't even be noticed.

:idea:
SteveF
Posts: 935
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

Great, thanks for testing that, I'm glad it works!

That blank line detection routine looks quite smart, but apart from the fact we're in agreement almost any amount of code to do this in Ozmoo is too much, I wouldn't be able to use it as it wouldn't work across the tube or (of course) in non-teletext modes, both of which Ozmoo supports.

If I *did* do this I'd probably end up setting some sort of flag in the Ozmoo equivalent of OSWRCH to record if the last character output was a carriage return or not (and if a game insists on printing some spaces then that line wouldn't be counted as blank).
SteveF
Posts: 935
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

So here's alpha 6: https://github.com/ZornsLemma/ozmoo/rel ... .8-alpha-6

This adds a progress bar when loading or restarting the game; unless I accidentally broke things, nothing else should be different. Please let me know how you get on!

Technical details

You can stop reading here if you just want to use Ozmoo to make and play games.

This change only adds three bytes of runtime code. Obviously I couldn't implement this feature in just three bytes, but the rest of the code for the progress bar is only held in memory temporarily when Ozmoo first starts.

Acorn Ozmoo has a multi-stage initialisation process, during which some bits of code which are only used once during startup are discarded after they've been executed. Here's a memory map:
ozmoo-low-ram.png
(For me at least, that's only just about readable inline; you can click on the diagram to expand it. I think the particular shade of red doesn't help either, but I did want to use red/amber/green here.)

The green sections show how memory is used once the game is actually running - that is, when Ozmoo is executing the Z-code instructions that make up the game.

When Ozmoo first loads from disc, the red and amber sections of the diagram are loaded along with the runtime code.

The red section gets overwritten by the game data when we start to load it from disc, but code which can be executed before this can live there. This section can be almost as large as we like and it doesn't cost much, just a little disc space and load time.

The code to actually load the game data can't live in the red section, or it would overwrite itself. So it lives in the amber section, which is where the Z-machine stack will live once the game starts executing. This section has a fixed size - we don't want to waste memory on an over-large Z-machine stack just to create space for the initialisation code - so there's some pressure to keep the code size down. As part of the progress bar implementation, I moved some code from the amber section into the red section, which frees up more space if it's needed in future and more than compensates for the very small additional amount of amber code required to support the progress bar.

Additional initialisation which happens after loading the game data into RAM and before the Z-machine starts executing also lives in the amber area. Changing the screen mode into the one selected in the loader lives here, for example; this means the user is left looking at the loader screen while all the game data is loaded, instead of a blank screen following a screen mode change.

In reality some code lives in the green "Runtime code" section when it could be moved into the red or amber sections. I don't think there's all that much, but at some point I may go over the code and see what can be moved. The smaller the "Runtime code" section is, the lower data_start will be and the more main RAM we have free for game data, improving performance by reducing disc access during play.

The diagram slightly oversimplifies things; the red section actually starts where the amber section finishes, rather than always starting exactly at data_start, so things don't look like the diagram unless the amber section is completely full of code.

Except for the shifting around of code between sections, this structure isn't new; I just thought I'd write about it now. As far as the progress bar goes:
  • We need an extra three bytes in the "runtime code" to position the OS cursor correctly on a RESTART.
  • Calculating how many progress bar steps correspond to each 512-byte block of data we're going to read from disc is done in the red section; we know the size of the game data at this point, and we've also done the necessary RAM size calculations.
  • Counting the number of 512-byte blocks loaded and adding an extra step to the progress bar every few blocks is done inside the loading code in the amber section.
Commodore Ozmoo has the amber section - it's where the idea came from, I didn't think of it - but I don't believe it has an equivalent of the red section. Instead, as much game data as will fit into RAM is appended directly to the Ozmoo executable, so there isn't any space for code after the Z-machine stack. Why doesn't Acorn Ozmoo append game data to the executable like this?
  • On a typical game disc there are actually four Ozmoo executables, so it would be wasteful of disc space to do it.
  • A lot of RAM on Acorn machines isn't directly accessible - we can't *RUN a 40K executable stretching from PAGE=&E00 up to &AE00 and expect it to work, as the filing system will be paged in between &8000 and &C000.
  • PAGE is quite variable, so we'd have to make a worst-case assumption when deciding how much of the game to bundle into the executable, reducing the advantage even further.
  • It is faster to load data sequentially using *RUN (or *LOAD) than to do the equivalent sequential reads 512 bytes at a time using OSWORD &7F/OSGBPB, but not *that* much faster. On the Commodore this (as I understand it) isn't true, because a fastloader will accelerate the equivalent of the former but not the latter. So the Acorn port does give up a small loading advantage by not appending game data to the executable, but not that much of one.
  • Commodore Ozmoo also benefits from the fact that since the executable is compressed, so is game data it contains, saving disc space and loading time. This would be an advantage on Acorn, but not enough to outweigh the above reasons.
User avatar
KenLowe
Posts: 1755
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: PunyInform and Ozmoo

Post by KenLowe »

SteveF wrote:
Sat Mar 06, 2021 12:44 pm
So here's alpha 6: https://github.com/ZornsLemma/ozmoo/rel ... .8-alpha-6

This adds a progress bar when loading or restarting the game; unless I accidentally broke things, nothing else should be different. Please let me know how you get on!
Nice add! Just tried it on a couple of floppy based ADFS games and it seems to work fine.

I'm not so sure about the [Press BREAK] feature that was added in the previous release, though. I preferred it when you were dropped back to the command prompt when you quit a game. When running from a HDD it was then easy to just change directory to another game (*DIR ^.^.nextgame - albeit I was going to request that you jumped up a level from the SAVES folder when you did quit to get back to the original folder). Having said all that, I've never actually got to the end of a game to see what happens, and at the end of the day it's no big deal for me. It's just a personal preference.

Thank you for the continued development.
User avatar
lurkio
Posts: 3387
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: PunyInform and Ozmoo

Post by lurkio »

SteveF wrote:
Sat Mar 06, 2021 12:44 pm
So here's alpha 6: https://github.com/ZornsLemma/ozmoo/rel ... .8-alpha-6 This adds a progress bar when loading or restarting the game
Just had a very quick go of this -- it's great!

I was thinking of suggesting that there ought to be some sort of indication of "activity" while the game loads (especially because in some cases (e.g. on the whole of bbcmicro.co.uk!) disc-drive noises will have been disabled) -- even if it was only to make the "Loading" message flash. But this is a much better idea and works really well!

=D> =D> =D>
Post Reply

Return to “8-bit acorn software: other”