PunyInform and Ozmoo

bbc/electron apps, languages, utils, educational progs, demos + more
SteveF
Posts: 792
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF » Sun Aug 30, 2020 4:23 pm

KenLowe wrote:
Sun Aug 30, 2020 4:18 pm
Yes, *DIR will take you to the home directory, so perhaps we need 2 steps. Firstly, '*DIR' to get to home directory followed by '*DIR SAVES' to get to a suitable sub directory. Let me test that...

I'm guessing this wouldn't also work with ADFS without a bit of further work to determine the different paths to the SAVES directory for both NFS and ADFS.
Thanks Ken. What I'm thinking of doing now is (pseudocode):

Code: Select all

IF filing system is NFS THEN *DIR
ON ERROR GOTO 1000
IF filing system is DFS THEN OSCLI "DIR S" ELSE *DIR SAVES
1000REM continue here
The idea being that on ADFS we will enter the SAVES directory inside the game (as present on the original floppy) but not die if it doesn't exist (in case it wasn't copied to hard drive with the rest of the game, for example), and on NFS we will select the user's home directory and then go into their SAVES directory if they have made one.

Edit: Since LOADER is just a BASIC program an advanced user can obviously choose to tweak it, but I'd like it to have sensible defaults.

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

Re: PunyInform and Ozmoo

Post by KenLowe » Sun Aug 30, 2020 4:55 pm

SteveF wrote:
Sun Aug 30, 2020 4:23 pm
KenLowe wrote:
Sun Aug 30, 2020 4:18 pm
Yes, *DIR will take you to the home directory, so perhaps we need 2 steps. Firstly, '*DIR' to get to home directory followed by '*DIR SAVES' to get to a suitable sub directory. Let me test that...

I'm guessing this wouldn't also work with ADFS without a bit of further work to determine the different paths to the SAVES directory for both NFS and ADFS.
Thanks Ken. What I'm thinking of doing now is (pseudocode):

Code: Select all

IF filing system is NFS THEN *DIR
ON ERROR GOTO 1000
IF filing system is DFS THEN OSCLI "DIR S" ELSE *DIR SAVES
1000REM continue here
The idea being that on ADFS we will enter the SAVES directory inside the game (as present on the original floppy) but not die if it doesn't exist (in case it wasn't copied to hard drive with the rest of the game, for example), and on NFS we will select the user's home directory and then go into their SAVES directory if they have made one.

Edit: Since LOADER is just a BASIC program an advanced user can obviously choose to tweak it, but I'd like it to have sensible defaults.
Yes, I think that should work. As a dirty hack, I modified line 51 of LOADER as follows:

Code: Select all

path$=FNpath:OSCLI("DIR"):OSCLI("DIR SAVES")
If I then log in as KEN, create a SAVES folder on my home directory, then switch to $.GAMES.INFOCOM.ZORK1 and CHAIN"LOADER" it all works as expected. The game loads from the shared area, and saves are being saved to the SAVES folder in my home directory 8).

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

Re: PunyInform and Ozmoo

Post by SteveF » Sun Aug 30, 2020 5:35 pm

Thanks Ken, I've pushed these changes up onto github and they'll be in the next alpha. This all feels very professional, having Ozmoo work on NFS. If only it had existed for all those school computer clubs back in the day. :-)

How's the performance on NFS? Does it feel OK-ish?

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

Re: PunyInform and Ozmoo

Post by KenLowe » Sun Aug 30, 2020 6:27 pm

SteveF wrote:
Sun Aug 30, 2020 5:35 pm
How's the performance on NFS? Does it feel OK-ish?
It takes about 6 seconds to load Zork1, so pretty good.

I'm not an Econet expert, so have been trying to find my way through a couple of issues:

Firstly, when I tried to copy a second game onto the server, I hit a file space limit. It turns out each user has been limited to about 256kb of space! There's a couple of utilities to read and change the space, so (after extracting from the adf file again, and then working out that they didn't run on the co-pro), I increased the user SYST to about 20MB. That allowed me to copy Zork2 across to the server.

Secondly, I tried to copy HHGTTG over to the server. This time I managed to crash the server when trying to copy the DATA file (FS Internal error #FA at address 550E). I notice that the data file is bigger than the equivalent data file for Zork 1 / 2 (160k vs 92k), so I'm guessing there's a limit to the size of file that can be saved to the server, but I've only been able to find limited info about this online - possibly something to do with 'Multiple block allocate fails'? Copying the file consistently crashes the server.

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

Re: PunyInform and Ozmoo

Post by SteveF » Sun Aug 30, 2020 7:23 pm

Thanks, 6 seconds sounds pretty good! I guess if there's a hard drive on the file server and limited contention for the network bandwidth it should be pretty good. It's doing 512 byte reads so network overhead shouldn't be too bad.

I know absolutely nothing about Econet but I'd have thought it would cope with files of 160K-ish. This is Level 3, if you have a hard drive, right? If you're feeling keen it might be worth posting in another forum where the Econet experts will see it, unless they play adventure games they're probably not reading this thread. If simply copying the file on is enough to crash the server that takes Ozmoo itself out of the equation so it's just a general Econet question.

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

Re: PunyInform and Ozmoo

Post by KenLowe » Sun Aug 30, 2020 7:27 pm

SteveF wrote:
Sun Aug 30, 2020 7:23 pm
If you're feeling keen it might be worth posting in another forum where the Econet experts will see it, unless they play adventure games they're probably not reading this thread. If simply copying the file on is enough to crash the server that takes Ozmoo itself out of the equation so it's just a general Econet question.
Already done:

viewtopic.php?f=3&t=20384

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

Re: PunyInform and Ozmoo

Post by SteveF » Sun Aug 30, 2020 7:32 pm

Great, I'll be watching that thread with interest then!

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

Re: PunyInform and Ozmoo

Post by KenLowe » Sun Aug 30, 2020 8:03 pm

Sorted by using a different utility (CopyFiles) to copy the files over to the server. That's me got a few adventure games copied over and running from the server now 8) 8).

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

Re: PunyInform and Ozmoo

Post by SteveF » Sun Aug 30, 2020 8:10 pm

Excellent news!

Balrog
Posts: 1
Joined: Tue Sep 01, 2020 5:03 pm
Contact:

Re: PunyInform and Ozmoo

Post by Balrog » Thu Sep 03, 2020 9:41 am

This just to say "Thanks" to SteveF for all his recent efforts with the Z-code emulators for the 'Beeb' and the 'Electron'. Back in the day ... way back some might say ... I ran a small company called ZENOBI Software that produced mainly text-adventures for the ZX Spectrum. These days, as I approach my mid 70s I like to dabble with the conversion of those various titles to other formats. They have been converted to C64, CPC, PCW, Amiga, Atari, MSX, Apple, Plus4 and recently I have been toying around with 'PunyInform'. The Z-files produced with this were then converted to the 'Beeb' and 'Electron' formats using Ozmoo and SteveF's excellent utility prog.

All in all I was well impressed with the ease of use of Ozmoo and the ability to produce a working game from a Z3 file. I converted my 'Behind Closed Doors 9' and 'Alien Research Centre 3' to the 'Beeb and 'Electron' format and then ran them through their respective emulators ... BeebEm and Elkulator.
Both worked surprisingly well and were also reasonably fast in their response times to input.

So I would just like to say a huge "Thank You" to all concerned and wish them well in their future efforts.

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

Re: PunyInform and Ozmoo

Post by KenLowe » Thu Sep 03, 2020 11:38 am

Balrog wrote:
Thu Sep 03, 2020 9:41 am
All in all I was well impressed with the ease of use of Ozmoo and the ability to produce a working game from a Z3 file. I converted my 'Behind Closed Doors 9' and 'Alien Research Centre 3' to the 'Beeb and 'Electron' format and then ran them through their respective emulators ... BeebEm and Elkulator.
Both worked surprisingly well and were also reasonably fast in their response times to input.
Just found your website, and downloaded the two .ssd files. Thank you for sharing! I'll test them out later. Would it be possible to share the raw .z3 files, so we can keep the .ssd images up to date as new features / bug fixes are implemented in Ozmoo? In particular, I'd love an ADFS version that I can then copy over to my L3 Econet server! I had a quick look through your site, but I couldn't see them anywhere; unless of course they're embedded in some of the other disk images (like the apple or cpm versions)?

Edit 1: Or alternatively (probably a question for SteveF), is it possible to extract the original raw z code file from the DATA file within the disk image?
Edit 2: Thinking about it further, is the DATA file actually just a straight copy of raw z code file?
Edit 3: Right, answering my own question. the DATA file is indeed the raw z code file. I was able to extract that from the .ssd file and rename the file with a z3 extension. From there I was able to rebuild in adfs format. I've tested that and it seems to work just fine.
Balrog wrote:
Thu Sep 03, 2020 9:41 am
So I would just like to say a huge "Thank You" to all concerned and wish them well in their future efforts.
I second that!
Last edited by KenLowe on Thu Sep 03, 2020 12:54 pm, edited 3 times in total.

User avatar
lurkio
Posts: 3036
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: PunyInform and Ozmoo

Post by lurkio » Thu Sep 03, 2020 11:53 am

Are we deliberately being cautious about linking to the Balrog's website? Or is it okay to post a link here..?

:?:

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

Re: PunyInform and Ozmoo

Post by SteveF » Thu Sep 03, 2020 5:50 pm

Balrog wrote:
Thu Sep 03, 2020 9:41 am
So I would just like to say a huge "Thank You" to all concerned and wish them well in their future efforts.
Thanks! And thanks for giving it a try with your games, it's great to see PunyInform and Ozmoo making new games available on these older machines.
KenLowe wrote:
Thu Sep 03, 2020 11:38 am
Edit 3: Right, answering my own question. the DATA file is indeed the raw z code file. I was able to extract that from the .ssd file and rename the file with a z3 extension. From there I was able to rebuild in adfs format. I've tested that and it seems to work just fine.
You're absolutely right about this Ken. What you've done is fine, but just for the record: although the DATA file is the raw Z-code game data, the Ozmoo binaries themselves contain some additional derived data (related to but not quite the same as the size of the game's dynamic memory), so it's *not* possible to just swap Z-code game data files around between different Ozmoo disc images and expect it to work - you need to run the DATA file through the make-acorn.py script (as you've been doing).

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

Re: PunyInform and Ozmoo

Post by SteveF » Fri Sep 04, 2020 1:30 am

Here's alpha 2.3: https://github.com/ZornsLemma/ozmoo/rel ... -alpha-2.3

What's new?
  • The Electron version is now better integrated; by default make-acorn.py will build a disc which will work on a BBC B, B+, Master or Electron, provided it has at least 16K of sideways RAM or a second processor. (As before, the Electron will really benefit from having at least 32K of sideways RAM.) You can specify "--bbc-only" or "--electron-only" when building the disc to drop support for one or the other, in order to free up space. [The "--electron" argument from alpha 2.1 is no longer supported or necessary, though the new "--electron-only" option is roughly equivalent.]
  • The loader now displays a half-decent screen in mode 6 on an Electron, including a selectable mode menu if you have a second processor. (Note that the --custom-title-page feature won't affect the mode 6 loader screen, only the mode 7 one.) You can use CTRL-F/CTRL-B to change the foreground/background colour for the game on this mode 6 loader screen.
  • Save/restore now work on the Electron.
  • If you specify --adfs to generate an ADFS disc image, it now defaults to generating an ADFS M (320K, 80 track single-sided) image with a .adf extension. You can specify --double-sided as well to generate an ADFS L image with a .adl extension instead. If you explicitly specify an output filename, an extension of .adf or .adl will implicitly request ADFS M or L generation respectively.
  • Ken's suggestion to have the loader re-load itself if shadow RAM is available but we're not currently in shadow mode has been implemented. This usually has no effect as the !BOOT file selects mode 135, but it will mean the loader should work without problems on an Integra-B even if the !BOOT file isn't being used (e.g. on a hard drive or network installation).
  • Double-sided DFS disc images now have the Ozmoo executables spread over both sides, in order to free up more space for game data and waste less on padding. (This isn't perfect, but it's a start.)
  • make-acorn.py has been tidied up slightly internally, though to be honest it's still rather a mess.
  • The code to handle RESTART has been tweaked slightly; unless I made a mistake, you shouldn't notice this. :-) (On DFS, the loader now puts the command to re-execute the binary in page 4 and the Ozmoo binary just executes that - this means the binary doesn't need to know whether it's on drive 0 or 2, which helps enable the previously mentioned change to spread executables over both sides of a double-sided disc.)
I recommend this version for both the BBC series and the Electron, unlike alpha 2.2 (which I think had a small bug in it which would stop it working on the BBC without being tweaked).

There are a lot of different variations now (Electron vs BBC series, ADFS vs DFS, single vs double-sided, small dynamic memory vs large dynamic memory, sideways RAM vs tube) but I've given this a modest amount of testing and it seems to be fine. Please don't be surprised if stuff that used to work has broken, but please do let me know so I can investigate! I think the most likely source of new bugs is in the save/restore code, so I'd appreciate any feedback on that.

What's still to do? (an incomplete list)
  • Support for pre-optimisation. This lets you play a game built with the pre-optimisation flag in order to determine which bits of the data file are used first, then use that information to tell a "release" version of Ozmoo which bits of the data file to load into memory on startup. The idea here is to allow an author of a game to minimise disc access for a player just starting out. I'll probably look at supporting this anyway, but if anyone is interested in helping me test this it would certainly be helpful and I might get round to supporting it earlier than I otherwise would...
  • Virtual memory tweaks to try to avoid wasting memory between the Ozmoo binary/stack and the screen RAM on an Electron.
  • Support for the Advanced Quarter-meg RAM (AQR), maybe. Auto-detecting this in a user-friendly way (e.g. not trampling over other stuff the user has in it) seems like the hardest part, actually using it inside Ozmoo is probably nothing more than a tweak to the paging code. The other mildly awkward part is this potentially adds another two executables (one for the Master, one for the Electron) to each game disc.
  • Support for the 12K private RAM on a B+/Integra-B, maybe. This would be sort of cool and probably not that hard, but I don't know if anyone would ever see any benefit from it. The most annoying thing here is that it's probably not possible to just use this automatically, as the user could be using it in hard-to-detect ways (e.g. using the version of MMFS which uses it for workspace in order to have PAGE at &E00) so we'd have to ask a question/provide a key to toggle it on/off, which just makes it even less likely anyone would ever use it in practice.
  • Support for non-ROMSEL sideways RAM on the model B, maybe.
  • General tidying up; make-acorn.py in particular is a real mess but as it's continually evolving with other changes I don't want to invest too much time in tidying it up yet.
  • Finer-grained control over what the generated disc image does/doesn't support. Rightly now Z5 THHGTTG doesn't fit on a single-sided disc even in --bbc-only mode; it would be nice to allow the user to throw out (e.g.) tube support to make this fit. (I'm sure hardly anyone is actually using a real single-sided drive these days, but I think double-sided images are a bit less convenient and wasteful of slots for people using things like MMFS.)
  • Shrinking the loader code, if possible. This is probably not going to be possible, although I could make it even less readable than it already is and use shorter variable names etc. Maybe I could implement my own slightly crappy BASIC cruncher in Python though.
  • Switch to allowing RETURN as well as/instead of SPACE to start the game in the loader. :-)

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

Re: PunyInform and Ozmoo

Post by KenLowe » Fri Sep 04, 2020 7:15 am

Wow. You've been busy.... again! =D> =D> =D>.

I'll test later on today, but can I just double check that the following two changes to make it work across an Econet server are implemented in this version? Specifically:
  • Modification to the code that determines the full path name of the binary file in order to prevent an error on NFS; specifically when the executable runs from a shared (non user) area of the Econet server.
  • Modification to the code so that save states will be saved to a SAVES directory off a users home directory when running on NFS.
Also, you mentioned that you might implement some of the extra CMOS instruction if running from a 6502 Co-Pro. Did you actually implement this, or is this still in your future plans.

Edit: Hmmm. I'm getting the following error when trying to build:

Code: Select all

C:\Users\Me\Desktop\Ozmoo>python make-acorn.py --adfs -p zork1.z3
Traceback (most recent call last):
  File "make-acorn.py", line 1035, in <module>
    make_loader()
  File "make-acorn.py", line 459, in make_loader
    loader.write("IF host_os%=0 THEN GOTO 500" + linesep)
TypeError: can only concatenate str (not "bytes") to str
Thanks

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

Re: PunyInform and Ozmoo

Post by SteveF » Fri Sep 04, 2020 12:35 pm

Thanks Ken. Yes, those two NFS-related fixes should be in there. Edit: And although they don't currently offer any benefit due to debugging code, the CMOS instructions have been in use on the second processor build for a while - probably since alpha 2.1, though I haven't gone and checked the precise introduction point. Are you just curious or did you want to use this on your NMOS second processor? I can look at offering an option to disable this, it's on my TODO list anyway and it probably isn't hard.

What I didn't test was Python 3 support, so thanks for finding that. I'll take a look and push out a new alpha soon, cheers.

Edit 2: Right, here's alpha 2.4: https://github.com/ZornsLemma/ozmoo/rel ... -alpha-2.4 This should work with Python 3 (lightly tested so far). it also fixes a bug where the non-virtual-memory second processor build didn't use CMOS instructions and adds a --force-6502 option which will prevent the use of CMOS instructions on any build.

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

Re: PunyInform and Ozmoo

Post by KenLowe » Fri Sep 04, 2020 11:00 pm

Hi Steve,

Thanks for the updated release. Should I be running a different version of Python?

I was just curious about the 6502 Co-Pro. I'm not using my hardware Co-pro at the moment. I'm happy using my PiTubeDirect Co-Pro.

I've been doing some testing with this latest v2.4, and it's working fine with ADFS. However, I seem to be having an issue when I try to run it on NFS in that it hangs at the 'Loading, please wait..." stage after having pressed space. To try and see what's happening, I've modified line 2004 as follows:

Code: Select all

OSCLI("FX4,0"):END
and then look at the variables that are used in line 2005:

fn%=5
path$=$.GAMES.INFOCOM.ZORK1
binary$=OZMOO2P

So, the command build up looks fine. At this stage, the current working directory is $.KEN.SAVE, which looks correct. However, when I then run the following command (mirroring what the line 2005 should be doing), it hangs:

Code: Select all

OSCLI("/"+path$+"."+binary$)
I've tried with the SWR version too, and get the same issue. Again, this SWR version works fine with ADFS.

Any thoughts on what might be going wrong?

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

Re: PunyInform and Ozmoo

Post by SteveF » Sat Sep 05, 2020 12:22 am

KenLowe wrote:
Fri Sep 04, 2020 11:00 pm
Hi Steve,

Thanks for the updated release. Should I be running a different version of Python?
Hi Ken, thanks for testing this. Python 3 is fine, it's just that my Linux distribution has "python" referring to Python 2 so I have to explicitly remember to go and test with Python 3. The changes to cope with both are mildly annoying but not a big deal and I did always intend to support both versions.
KenLowe wrote:
Fri Sep 04, 2020 11:00 pm
I've been doing some testing with this latest v2.4, and it's working fine with ADFS. However, I seem to be having an issue when I try to run it on NFS in that it hangs at the 'Loading, please wait..." stage after having pressed space.
This is weird, I haven't (knowingly) changed anything which I'd expect to break this. Your investigation is helpful and seems to suggest everything is working fine.

I am clutching at straws a bit but in the absence of any better ideas:
  • Could you please do *INFO * or *EX on the $.GAMES.INFOCOM.ZORK1 directory? I am wondering if the load/execution addresses on the binaries are somehow corrupt. (That doesn't seem likely; why would they be corrupt now when they weren't before?)
  • Could you "hand-build" the command OSCLI is going to execute and execute it directly without making BASIC do it? i.e. type "*/$.GAMES.INFOCOM.ZORK1.OZMOO2P" after letting your modified loader set things up. (But why would this matter?)
  • You could also try *RUN instead of */. (But the loader always used */ and it's been fine.)
  • Could you please try redoing the build with alpha 2.1 and see if that still works. (Of course it should.)
  • Edit: Maybe it's hanging inside the BASIC ON ERROR handler. Maybe delete all the ON ERROR lines in the loader and see if that helps? (Probably not, since it also fails when you invoke it from the BASIC prompt not via the loader's own code)
  • Edit: The second processor binary doesn't need much setting up, so maybe try invoking it without using the loader and see what happens. Try something like:

    Code: Select all

    <press CTRL-BREAK to put the machine in a clean state and log on and move to the right directory>
    MODE 135
    ?&409=6:REM status bar colour
    ?&40B=7:REM mode
    $&42F="$.GAMES.INFOCOM.ZORK1.DATA"
    *RUN OZMOO2P
    
  • This one is a bit fiddly so I'd understand if you didn't want to try it - you could try building with alpha 2.1 (assuming that still works), installing that on NFS and then copying the alpha 2.4 OZMOO2P binary over the alpha 2.1 one. That is, use alpha 2.1's loader with alpha 2.4's binary. There might be some subtle breakage around RESTART, but they should otherwise be compatible. This might give some sort of clue as to where the problem is.
I hope I'm going to have a brainwave as soon as I hit Submit. :-) If none of the above straw-clutching gives any clues I will maybe produce a version which outputs some trace information during the setup so we can see how far it gets before hanging.

Edit: I previously said alpha 2.2 when I should have said alpha 2.1. Correct me if I'm wrong - alpha 2.1 was the version you had working before, right?

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

Re: PunyInform and Ozmoo

Post by KenLowe » Sat Sep 05, 2020 1:29 am

SteveF wrote:
Sat Sep 05, 2020 12:22 am
Could you please do *INFO * or *EX on the $.GAMES.INFOCOM.ZORK1 directory? I am wondering if the load/execution addresses on the binaries are somehow corrupt.
Talk about checking the obvious! That's exactly what the problem was. The CopyFiles utility appears to use different methods for copying different files. I'm assuming it's based on size, but I've not looked into how it works. However, the main executables all had load and execute addresses of FFFFFFFF. I think (from memory) the FINDSWR executable was ok.
SteveF wrote:
Sat Sep 05, 2020 12:22 am
(That doesn't seem likely; why would they be corrupt now when they weren't before?)
The million dollar question. I deleted everything in the NFS Zork 1 directory, and tried CopyFiles again. I got exactly the same result. This was with the Co-Pro disabled. So I then tried again with the Co-Pro enabled, and everything copied correctly! Go figure! This must have been how I copied all the files over first time around.

With the correct load and execute addresses, everything is working perfectly.

Thanks for the pointers, and sorry for wasting your time with this!

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

Re: PunyInform and Ozmoo

Post by SteveF » Sat Sep 05, 2020 2:23 am

Thanks Ken, don't worry about wasting my time, I really appreciate the effort you're putting into testing this. I'm glad that's all it was, I can sleep easy now. :-)

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

Re: PunyInform and Ozmoo

Post by SteveF » Fri Sep 11, 2020 9:18 pm

Here's alpha 2.5: https://github.com/ZornsLemma/ozmoo/rel ... -alpha-2.5

What's new?
  • A bug in "restore" has been fixed. I was incorrectly relying on the load address in the OSFILE block to remain unaltered after loading a file. The first restore after loading the game was always fine, the second and subsequent restores would load at the load address of the file loaded in the previous successful restore. This worked fine if you were restoring files saved from exactly the same version, otherwise the restore would overwrite an incorrect part of memory with hilarious results.
  • The "preopt" feature of the C64 version is now supported; lots of waffle about this below. As part of this the initial load of the game from disc into RAM has been tweaked, optimised and had interesting new bugs introduced.
  • On the Electron, memory between the Ozmoo stack and the bottom of screen memory is no longer wasted; it's used as virtual memory cache instead. An Electron is now only about 7K worse off (i.e. the difference in screen memory size) than a shadow RAM-less BBC B with the same value of PAGE and the same amount of sideways RAM. Judging from a test run in MAME with the Slogger Pegasus 400, an Electron with 32K of sideways RAM completes the benchmark 10.5% faster as a result of this change.
I've done my best to test this but as I keep saying, there are a lot of different versions in play now so I may well have missed something. Please let me know if it does/doesn't work for you!

How to use the preopt feature
  • Build a "preopt" version of the game by passing the "-o" option to make-acorn.py.
  • Launch that version of the game; I'd suggest using an emulated Master 128 for this.
  • Make sure the disc isn't write protected.
  • You should see a "*** vmem optimization mode ***" message when the game starts.
  • Play the game. It will be slow because it won't have loaded anything in from disc in advance; it will only load as necessary.
  • Eventually the game will run out of memory, at which point it will dump a load of hex out to the screen and (more importantly) save an S.PREOPT file to the disc. [The file just gets saved as PREOPT, but the DFS version defaults to the S directory so it will probably be called S.PREOPT. On ADFS it will go into the SAVES directory by default.]
  • If you wish, you can type "XXX" to trigger the dump instead of waiting until the game runs out of memory.
  • Extract the S.PREOPT file from the disc image using whatever your preferred tool is. Let's say you call it my-game-preopt on the modern computer you're using to run make-acorn.py.
  • You can now build an optimised version of the game by passing a "-c my-game-preopt" option to make-acorn.py instead of "-o".
Why use the preopt feature?

It's a way to improve the user's experience when the game is first loaded, to give a better first impression and maybe make gameplay a bit smoother. It's completely optional and something you'd probably only do if you were going to produce a "polished" release of a game to share with other people. Once the user has been playing for a while, there won't really be any difference between a normal build and a preopt-assisted build.

When Ozmoo first loads a game, it always loads the game's dynamic memory into RAM; I won't mention this again, it's not important for the preopt feature. It also loads as much of the rest of the game as will fit into the leftover memory. By default (previous versions without preopt support always did this) it will load from the start of the game file until it runs out of memory.

This preload is useful because:
  • It happens as part of startup, when the user is going to be relatively happy to wait, rather than in response to a user entering a command.
  • It happens faster than loading the same data during gameplay, because the disc will already be spinning and the data will be read in the same order it's on the disc, whereas access during gameplay will be relatively random.
However, there's no guarantee that the first part of the game file contains the stuff which is most useful at the start of the game. Maybe the user has 64K of available RAM for the game data, but code or data related to the first few locations or the user's starting inventory happens to be scattered around the game file and a lot of it is at the 80K point in the file. In that case, once the initial load finishes, the user will (e.g.) type "inventory" at the prompt and have to wait while Ozmoo seeks to the 80K point in the file to load a few blocks (discarding some of the ones it had previously loaded).

What the preopt step does is start Ozmoo with *nothing* preloaded automatically. It then loads as normal based on the commands you enter, but it will never discard anything it's loaded - instead it stops and dumps out the list of blocks it loaded when it runs out of memory. The version of the game you build using "-c" has that list of blocks built into it, and it will load *those* blocks on startup instead of the blocks at the start of the game file, so the user doesn't have to wait for them to be loaded from disc. The preopt step is essentially your chance to teach Ozmoo which bits of your game it should load first.

What if the user's machine has more or less RAM than the machine you did the preopt run with? If it has more, Ozmoo will pad out the list of preopt blocks with additional blocks from the start of the game file. If it has less, Ozmoo will load as many of the preopt blocks as it can, in the same order they loaded during your preopt run, and then stop. So it works fine, but the more RAM you have when you do the preopt run the more information Ozmoo has available - this is why I suggested using an emulated Master 128 for the preopt run. (If you really want to go wild with your preopt run, you can add additional sideways RAM, up to a maximum of 144K, but it's probably not worth it.)

It's up to you what commands you enter during the preopt run, but I'd suggest it's not a good idea to use an "efficient" walkthrough of the entire game. A real user playing the game for the first time is going to be examining everything in the first few locations and wandering around there, not forging ahead magically knowing what to do. If there are objects or commands the user will be using throughout the game it might be a good idea to exercise them during the preopt run; this will benefit not just users playing from the start, but users who restore a saved position as soon as the game starts as well.

You're probably going to need to repeat the preopt run (e.g. if you fix a bug in your game, the positions of code and data in the game file might change), so I suggest you prepare it in a text editor and use the emulator's "paste" feature to simulate typing it in by hand. There's nothing stopping you from doing the preopt run on a real machine if you really want to though. (You *might* be able to play tricks with the ability to enter "*" commands during save/restore to allow you to *EXEC a text file containing the preopt commands on a real machine; I haven't tried this myself.)

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

Re: PunyInform and Ozmoo

Post by KenLowe » Fri Sep 11, 2020 11:35 pm

Wow, another big update! I've got a couple of observations based on some light testing of the previous Alpha-2.4 version:
  • Would it be possible to increase the ADFS maximum path length? I had an ADFS directory 0.$.GAMES.INFORM.HITCHHIKE and this was too long by the time the filename was also added. The maximum length of directory name is 10 characters. Would it be possible to increase the max path length to allow upto 3 levels of directory?
  • When building advent.z5 I get a 'Not enough free RAM for game's dynamic memory' error. I didn't get this with earlier versions. Any idea why this might be happening?
  • On one specific HDD I get a FATAL ERROR 8 error when the game data is loaded. This happens for all games (on some games the initial game will load, but if I then QUIT, I get the same error). I suspect a drive issue, however, other files seem to save and load without issue, so I'm not too sure I'm only seeing this with Ozmoo. Any thoughts? I might transfer the files back to floppy and then do a compare of the files on the original floppy vs the ones read back from the HDD to see if there are any differences.
Edit: With point 3 there's definitely some corruption happening. For example, with the DATA file for BCD9.z3 I'm seeing a total of 18 differences, where:

&DF becomes &CF
&F7 becomes &E7
&E7 becomes &C7
&3F becomes &1F
&6F becomes &4F
&AE becomes &8E
&6B becomes &4B

Bits 4 & 5 are not always being set. I wonder if this is perhaps a drive termination issue. I'm using a rather long cable (approx 2m) to connect between the beeb and the drive.

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

Re: PunyInform and Ozmoo

Post by SteveF » Sat Sep 12, 2020 12:27 am

KenLowe wrote:
Fri Sep 11, 2020 11:35 pm
Would it be possible to increase the ADFS maximum path length? I had an ADFS directory 0.$.GAMES.INFORM.HITCHHIKE and this was too long by the time the filename was also added. The maximum length of directory name is 10 characters. Would it be possible to increase the max path length to allow upto 3 levels of directory?
Yes, that's not a big problem. I've pushed alpha 2.6 which increases the maximum length from 31 to 48 useful characters, I hope that's enough.
KenLowe wrote:
Fri Sep 11, 2020 11:35 pm
When building advent.z5 I get a 'Not enough free RAM for game's dynamic memory' error. I didn't get this with earlier versions. Any idea why this might be happening?
This is because the game's too big for the Electron - it has 17.4K of dynamic memory and the Electron can't handle more than 16K. If you specify "--bbc-only" on the command line it should build fine. I've added a TODO item to remind me to look into handling this better/automatically.
KenLowe wrote:
Fri Sep 11, 2020 11:35 pm
On one specific HDD I get a FATAL ERROR 8 error when the game data is loaded. This happens for all games (on some games the initial game will load, but if I then QUIT, I get the same error). I suspect a drive issue, however, other files seem to save and load without issue, so I'm not too sure I'm only seeing this with Ozmoo. Any thoughts? I might transfer the files back to floppy and then do a compare of the files on the original floppy vs the ones read back from the HDD to see if there are any differences.
This looks a bit trickier. :-) It feels a bit feeble but all I can really suggest is that because Ozmoo is seeking around in the file and using random access it may expose flakiness a bit more than the more typical "load/save a whole file" operations. Do you have any other programs which use random access you could try? Transferring the files back off the HDD and comparing them sounds like a good idea, but if other files seem to save and load without issue I'm not too optimistic that will show a problem.

You could perhaps try the ADFS OSGBPB benchmark/test I posted further up the thread and see how that gets on. If you enable the internal "check" option it would verify the data read from the drive, and you could also comment out the OSWORD version which does raw sector access and just leave the OSGBPB version in. If you want me to have a go at knocking up a suitable variation let me know.

Just to check I understand the situation correctly: you have other hard drives, and the same games work fine off those drives when they're attached to the same machine?

Edit: Just seen your edit re the third point. That does look like a hardware issue; it's not impossible Ozmoo has corrupted its own file by writing to it, but I don't think it's very likely - it doesn't contain any code which will try to do that and since it's going via ADFS I think it would be hard to do so by accident. I'm happy to help produce that test program as I suggested if you think it will be useful in trying to confirm the fault.

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

Re: PunyInform and Ozmoo

Post by KenLowe » Sat Sep 12, 2020 12:49 am

SteveF wrote:
Sat Sep 12, 2020 12:27 am
KenLowe wrote:
Fri Sep 11, 2020 11:35 pm
Would it be possible to increase the ADFS maximum path length? I had an ADFS directory 0.$.GAMES.INFORM.HITCHHIKE and this was too long by the time the filename was also added. The maximum length of directory name is 10 characters. Would it be possible to increase the max path length to allow upto 3 levels of directory?
Yes, that's not a big problem. I've pushed alpha 2.6 which increases the maximum length from 31 to 48 useful characters, I hope that's enough.
KenLowe wrote:
Fri Sep 11, 2020 11:35 pm
When building advent.z5 I get a 'Not enough free RAM for game's dynamic memory' error. I didn't get this with earlier versions. Any idea why this might be happening?
This is because the game's too big for the Electron - it has 17.4K of dynamic memory and the Electron can't handle more than 16K. If you specify "--bbc-only" on the command line it should build fine. I've added a TODO item to remind me to look into handling this better/automatically.
KenLowe wrote:
Fri Sep 11, 2020 11:35 pm
On one specific HDD I get a FATAL ERROR 8 error when the game data is loaded. This happens for all games (on some games the initial game will load, but if I then QUIT, I get the same error). I suspect a drive issue, however, other files seem to save and load without issue, so I'm not too sure I'm only seeing this with Ozmoo. Any thoughts? I might transfer the files back to floppy and then do a compare of the files on the original floppy vs the ones read back from the HDD to see if there are any differences.
This looks a bit trickier. :-) It feels a bit feeble but all I can really suggest is that because Ozmoo is seeking around in the file and using random access it may expose flakiness a bit more than the more typical "load/save a whole file" operations. Do you have any other programs which use random access you could try? Transferring the files back off the HDD and comparing them sounds like a good idea, but if other files seem to save and load without issue I'm not too optimistic that will show a problem.

You could perhaps try the ADFS OSGBPB benchmark/test I posted further up the thread and see how that gets on. If you enable the internal "check" option it would verify the data read from the drive, and you could also comment out the OSWORD version which does raw sector access and just leave the OSGBPB version in. If you want me to have a go at knocking up a suitable variation let me know.

Just to check I understand the situation correctly: you have other hard drives, and the same games work fine off those drives when they're attached to the same machine?

Edit: Just seen your edit re the third point. That does look like a hardware issue; it's not impossible Ozmoo has corrupted its own file by writing to it, but I don't think it's very likely - it doesn't contain any code which will try to do that and since it's going via ADFS I think it would be hard to do so by accident. I'm happy to help produce that test program as I suggested if you think it will be useful in trying to confirm the fault.
Thank you for the responses. I'll grab 2.6 shortly, and I can confirm that the --bbc-only switch fixed the memory error for me.

Regarding point 3, I removed one length of ribbon cable (about 80cm) between the 1Mhz port and the HDD host adaptor, and it all seems to be working fine now. And, yes, I have multiple HDDs (all the same model), and I was only seeing this behaviour on one drive.

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

Re: PunyInform and Ozmoo

Post by KenLowe » Sat Sep 12, 2020 2:29 am

With v2.6 I seem to be having an issue with a couple of games that worked on v2.4. On v2.6, one games gives me a Fatal Error 8 message. The other game just hangs at the loading screen. I'm building these for ADFS, and running them on a second processor. I get the issue if I run the games from either floppy or HDD, so this time round I don't think it's my drives that are the problem. The specific games are Alien Research Centre 3, and Behind Closed Doors 9, both of which are referenced in this post:
Balrog wrote:
Thu Sep 03, 2020 9:41 am
All in all I was well impressed with the ease of use of Ozmoo and the ability to produce a working game from a Z3 file. I converted my 'Behind Closed Doors 9' and 'Alien Research Centre 3' to the 'Beeb and 'Electron' format and then ran them through their respective emulators ... BeebEm and Elkulator.
Both worked surprisingly well and were also reasonably fast in their response times to input.
I've attached a copy of both for your info.
Attachments
games.zip
Problematic Games
(59.65 KiB) Downloaded 10 times

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

Re: PunyInform and Ozmoo

Post by SteveF » Sat Sep 12, 2020 3:02 am

KenLowe wrote:
Sat Sep 12, 2020 2:29 am
With v2.6 I seem to be having an issue with a couple of games that worked on v2.4. On v2.6, one games gives me a Fatal Error 8 message. The other game just hangs at the loading screen. I'm building these for ADFS, and running them on a second processor. I get the issue if I run the games from either floppy or HDD, so this time round I don't think it's my drives that are the problem.
That's a bit embarrassing... In reworking the initial game load code, I got so focussed on the typical case where virtual memory is being used that I forgot to load the non-dynamic part of the game from disc if virtual memory wasn't being used. This broke small games on the second processor, which I didn't test. Oops. :oops:

It's only been really lightly tested but I think alpha 2.7 should have a fix for this: https://github.com/ZornsLemma/ozmoo/rel ... -alpha-2.7

Thanks for finding this!

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

Re: PunyInform and Ozmoo

Post by KenLowe » Sat Sep 12, 2020 9:21 am

SteveF wrote:
Sat Sep 12, 2020 3:02 am
[It's only been really lightly tested but I think alpha 2.7 should have a fix for this: https://github.com/ZornsLemma/ozmoo/rel ... -alpha-2.7
Yup, that seems to have fixed it, thanks. Unfortunately my disk corruption issue has reappeared, even with the shorter cable. I'm fairly convinced the drive is faulty :(. I've even swapped the drive PCB with a known good one, but that didn't make any difference.

User avatar
lurkio
Posts: 3036
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: PunyInform and Ozmoo

Post by lurkio » Tue Sep 15, 2020 6:15 pm

SteveF wrote:
Sat Sep 12, 2020 3:02 am
It's only been really lightly tested but I think alpha 2.7 ...
Finally got a chance to test alpha2.7. It worked fine, but I only did a basic test, without the preopt. I just packaged up HHGG and Calypso and had did a quick playtest of both of them in BeebEm.

I haven't tested the preopt option yet, but it blows my mind! It's such a great idea, so helpful for 8-bit machines with their usually small amounts of RAM and possibly slow disc-drives.

Are there any particular tests I should run that would be useful for you, Steve?

:?:

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

Re: PunyInform and Ozmoo

Post by SteveF » Wed Sep 16, 2020 8:34 pm

lurkio wrote:
Tue Sep 15, 2020 6:15 pm
Finally got a chance to test alpha2.7. It worked fine, but I only did a basic test, without the preopt. I just packaged up HHGG and Calypso and had did a quick playtest of both of them in BeebEm.
Thanks lurkio, good to know it's still working!
lurkio wrote:
Tue Sep 15, 2020 6:15 pm
Are there any particular tests I should run that would be useful for you, Steve?
Just using it in general is helpful - I tend to fire up games, play a few moves (e.g. look at a few initial hints on THHGTTGv5 and maybe get out of the bedroom) and leave it at that. I wouldn't want you to burn out but if you're feeling particularly keen:
  • The sideways RAM version is more complex internally so using that instead of the second processor version might help to find any lingering bugs.
  • Save/restore is probably under-tested in general, and has had some reworking recently as part of the Electron support. It's probably fine now, but saving on one version and restoring on a different version (e.g. saving on a second processor version and restoring on a sideways RAM version) would be good to test. Edit: particularly if the save was done moderately far into the game and therefore the virtual memory subsystem has evolved a bit from its initial state, as there could be bugs related to correctly paging in the code needed for the restored state (but I don't know of any) which would not get a chance to bite if I'm just doing a save, making a couple of moves and then restoring.
  • If you're into the Electron giving that version some use would be good, as it's definitely the least tested. But I know it is a bit painful to use compared the BBC, unless you have a turbo board (probably; I haven't tried this myself).
  • Edit: Obviously the preopt is new and under-tested if you feel inclined to play with that, but I do have some more changes in the works which will touch that general area of the code so don't go out of your way to try it.
But as I say, just giving it some use to actually play games on for more than a handful of moves is really helpful and appreciated!

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

Re: PunyInform and Ozmoo

Post by SteveF » Sun Sep 20, 2020 2:15 am

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

What's new?

The main change is that when using a second processor, spare RAM in the host is now used as a second level of cache to store game data. Main RAM (between host OSHWM/"PAGE" and the bottom of screen RAM) and sideways RAM can both be used, up to a total of (just under) 128K, in addition to the second processor's own RAM.

Using b-em to emulate a Master 128 with a 3MHz second processor and drive noises on (the best I can do to simulate a real floppy), the benchmark completes 32% faster with the cache than without it.

I'm pretty chuffed with this. Up until now it hasn't always been a clear win to play a game using a second processor - yes, you (almost always) have a faster CPU and that's helpful, but you also only have about 47K of RAM for the game so there might be a lot more disc access. On a Master 128 the CPU isn't as fast, but you get about 79K for game data. With this change, a Master 128 with second processor will have about 125K for game data and still benefit from the faster CPU in the second processor. [The numbers here are approximately correct but estimated, don't take them too seriously.]

The only other change is that I am now using a crude bit of crunching code in make-acorn.py to crunch the BASIC loader code by shortening procedure and variable names. This saves about 1.5K, not huge but it all helps to speed loading and it may reduce the tension I feel when working on the loader code between my natural verbosity and the fact it's an interpreted language and those long names actively take up space. :-) If this causes you problems, you can disable it by specifying the "--no-loader-crunch" option to make-acorn.py. If you need to do this for any reason other than just debugging/tweaking the loader code on your own machine with proper names, that's a bug so please report it.

The fly in the ointment

While it's not doing anything particularly exotic, the tube host cache code is the most "advanced" second processor code I've ever written, since it has to ship 512-byte blocks of data back and forth between the host and the second processor.

I developed it on b-em in Master 128 mode. I've subsequently tested it on various other emulated machines with mixed results:
  • On MAME 0.224 emulating an Electron with an AP5 and ReCo6502 second processor, the tube build doesn't work properly. I *am* (I believe) taking account of the different address of the tube hardware in the host on the Electron as well as the different sideways RAM paging. If anyone can try this on real hardware (any 6502 second processor; I mention ReCo6502 here just because it's the only one that works with the Electron in MAME 0.224) I'd appreciate it. I have vague hopes this is an emulator issue (mentioned in passing here) and when I get my hands on a newer MAME it will work, but I'm not too confident - as I say, this is new territory for me and I've probably done something wrong. Edit: Nigel has sent me a build of the latest MAME (to be officially released at the end of the month) and the new tube cache works perfectly (well, the benchmark completes successfully anyway) now with all the 6502-based second processors, which is great news all round. Tests on real hardware still greatly appreciated!
  • On b-em it seems to work fine on a B/B+/Master *as long as you have a 1770 instead of an 8271*. A model B with DFS 1.2 almost always (not always) locks up at exactly the same point right at the end of the benchmark (in mode 3, at least). But BeebEm 4.15 emulating that same model B with DFS 1.2 successfully completes the benchmark every single time. Again, this *might* be an emulator bug but it's more likely to be something I've done wrong. (Depending on the feedback I get from this alpha, I might get in touch with Coeus about this, but I'm reluctant to do that just yet.)
It's this which causes me to only be "pretty chuffed" instead of outright chuffed. :-)

I'd really appreciate any test reports (successful or otherwise) for the new tube cache code. It's used by default, but if it's causing you problems you can disable it by passing the "--no-tube-cache" option to make-acorn.py.

Testing with any game is valuable - in many ways more valuable than running the benchmark - but if you could also try the benchmark I'd appreciate it. This just involves getting hold of a copy of Infocom's "Hollywood Hijinx" and passing "--benchmark" to make-acorn.py when building the game. This causes a built-in walkthrough to be typed automatically and disables the press-SHIFT-to-scroll stuff.

The benchmark is obviously a bit of a spoiler for the game, so you may want to avoid it.

From a correctness point of view the main thing is that a) the benchmark completes OK b) (much less likely) you don't notice any subtle corruption in the text output during the benchmark.

From a performance point of view, the benchmark outputs a timestamp in the form "$xxxxxx" at the start of the run and again at the end. Those are hexadecimal counts in fiftieths of a second; the first shows the time taken for the initial loading and the second includes that and also the time taken to run the game. Those timestamps are only valid if nothing stops the OS timer for long; on an Electron they tend to be useless, on the BBC series I tend to trust them but it's possible I am fooling myself by doing so.

If anyone feels like giving the code a look over to see if I'm doing anything wrong, the host-side cache code is here. The tube-using code is bracketed by "jsr claim_tube" and "jsr release_tube".

How it works

This section is just me waffling about the technical details of the implementation; if that floats your boat, great, but if you just want to play adventure games you should stop reading now. :-)

There's a new binary CACHE2P which is run by the loader. It loads and executes in the host, loading high but relocating itself down to host OSHWM to get the maximum amount of free RAM for the cache. It installs itself on USERV and claims OSBYTE &88 and OSWORD &E0.

OSBYTE &88 is used by the Ozmoo executable to initialise the cache and query its size. It needs to know the size so it can preload additional blocks of game data in the host cache as well as the second processor's own memory. Doing this preload (I hope!) correctly and efficiently is actually the biggest part of the change needed to support the cache, as I wanted to a) keep the drive head moving smoothly in one direction only during the load b) put preload blocks with younger timestamps in the second processor's own memory and older ones in the host cache.

OSWORD &E0 allows code running on the second processor to say two related things:
  • (optional) I have block n at address a which I'm about to overwrite, you can copy it first if you want.
  • I'd like to have block m at address a; can you do that for me?
Ignoring the preload support (which is nice but not essential), there are only about 30-40 lines of code added to the Ozmoo code to use the cache. Whenever the virtual memory subsystem is about to go to disc, we make an OSWORD &E0 call to hand over the existing game block we're about to overwrite and to ask if it has the block we're trying to load from disc. If it has the block, we're done, otherwise we just fall through to the existing code to load from disc.

The implementation of OSWORD &E0 is relatively simple. It could potentially be improved, but a fair chunk of the CPU time it takes is involved in copying blocks of data to and fro across the tube and I don't think that can be significantly improved, so any performance penalty from the naive caching algorithm is diminished. It's also the case that any cache hit avoids going to the disc for the data, so even if the cache performance is worse than it could be, it's still much better than not having it. (This assumes an actual floppy drive. Solid-state storage may be so fast there's hardly any benefit from having the cache; if anyone feels inclined to play around timing this on real hardware that would be interesting.)

I originally thought the cache OSWORD would go and fetch the blocks from disc itself if they weren't in the cache, but luckily I spent a bit of time mulling it over before charging ahead with the implementation and realised it would be a lot less awkward (less code duplication and/or rearrangement) to just leave the disc access in the main Ozmoo binary and make the cache a purely RAM-based affair.

The host cache contains a completely disjoint set of blocks from those held in the Ozmoo virtual memory cache in the second processor. When Ozmoo hands a block over to the cache it's doing it because it wants that virtual memory slot for a different block. When the cache hands a block over to Ozmoo, it deletes the local copy of it - it knows Ozmoo in the second processor now has it, it has the youngest possible timestamp there and won't be evicted any time soon, and when it *is* evicted it will be handed back to the host cache, at which point it will be reinserted into the host cache with the youngest possible timestamp there. This means that in the host cache, blocks don't get their timestamps updated because they've been accessed - as soon as they're accessed they are evicted from the cache anyway. The timestamps are just used to decide which block to discard if (as is likely) the cache is full when Ozmoo hands a new block over.

Except during the preload, the timestamps in the two caches are not synchronised in any way. The way blocks move back and forth mean there's no need for this; blocks in the Ozmoo cache in the second processor are all implicitly newer than blocks in the host cache.
Last edited by SteveF on Sun Sep 20, 2020 2:05 pm, edited 1 time in total.

Post Reply

Return to “8-bit acorn software: other”