PunyInform and Ozmoo

[hoglet]

Thank you for the effort you have put into getting this working. It's very much appreciated. Do you think some of these games will now make their way into the ASA?

Yes, I would like to include a small selection

I'm happy to continue working on this in the background, and I think these things would be useful
- improved build scripts, to remove the manual steps
- a way to auto-boot a game from the MENU
- include an extended version of the Econet file system with the Tube Host
- add OSGBPB support to the Tube Host
- investigate running these games natively using YARRB Profile 3 (Atom2K15)
- add hardware scrolling to the VGA80 driver (the GODIL hardware supports it)

Dave

[KenLowe]

Getting those additional features would be awesome; particularly getting the Econet support!

I had a quick look at ways of automating the build. I was thinking about using JGHs UNIMG utility to extract the OZMOO2P file from the disk image, and then using the SirMorris bin2atm utility to append the AtoMMC header. But I failed on both fronts. Firstly, I couldn't find a way to extract a single file from disk image using UNIMG, and then I couldn't get the bin2atm to work correctly.

If I can get some time, I might have a look the Ozmoo build scripts, and see if I can amend those to create both the OZMOO2P with header, and the Atom Loader file, again with header.

[hoglet]

I had a quick look at ways of automating the build.

I have a Java program as part of the ASA build that will unpack a disk or tape images into individual files, and then add AtoMMC headers.
https://github.com/hoglet67/AtomSoftwar ... mDisk.java

It's a but clunky, but it works.

Let me know if you want to use this and I'll jot down some notes.

Dave

[KenLowe]

I have a Java program as part of the ASA build that will unpack a disk or tape images into individual files, and then add AtoMMC headers.
https://github.com/hoglet67/AtomSoftwar ... mDisk.java

It's a but clunky, but it works.

Let me know if you want to use this and I'll jot down some notes.

That would be helpful. I've had a quick look through make-acorn python script to see if there was an easy way to strip out the OSMOO2P executable and add the AtoMMC header, but I'm getting a bit bogged down in the code. I've not done much python coding in the past, so it's all a bit of a learning curve for me! Probably done even less in Java, though!

[hoglet]

That would be helpful.

OK, I've tidied it up slightly.

Here's an executable jar file (you'll need to unzip this first):

atomtape.zip

(18.17 KiB) Downloaded 42 times

The program will take either Atom tape archives (.tap files) or Atom/BBC DFS disk files (.40t/.80t/.dsk/.ssd files)

It won't currently handle double sided (.dsd) Disk files; these will need to be split first (e.g. using Stephen's MMB_Utils)

Here's an example session:

Code: Select all

dmb@quadhog:~/ozmoo/disks$ mkdir test
dmb@quadhog:~/ozmoo/disks$ java -jar atomtape.jar
usage: java -jar atomtape.jar [-a] [-b] [-w] [-c] <Src Dir or File> <Dst Dir>

output options:
    -a : Output a .ATM AtoMMC emulator file
    -b : Output a .BAS BASIC text file
    -w : Output a .WAV audio file
    -c : Output a .CSW compressed square wave emulator file

Too few arguments
dmb@quadhog:~/ozmoo/disks$ java -jar atomtape.jar -a Calypso.dsk test
####################################################
# Calypso.dsk -> test/Calypso
####################################################
_BUILD 0000 0000 0082 46c98f86234156646cebdf900fc6aa9b Calypso
    ->test/Calypso/BUILD (BUILD)
_DATA 0000 0000 bc00 e839314dbc5bf044f3d34cd70394c7c7 Calypso
    ->test/Calypso/DATA (DATA)
_OZMOO2P 1120 3390 238d 77ea92a8b6c195e2b7add3e3b13a81f1 Calypso
    ->test/Calypso/OZMOO2P (OZMOO2P)
_OZMOOB 3d4b 687b 2c42 252871bdaad70468899d8c0e944303bb Calypso
    ->test/Calypso/OZMOOB (OZMOOB)
_OZMOOSH 3e8c 6b78 2dfe afb481a47fb09bda18795c45e92d0122 Calypso
    ->test/Calypso/OZMOOSH (OZMOOSH)
_OZMOOE 2824 55ad 2e9b c6bdf13718d2804e7ad6190a4f9459c5 Calypso
    ->test/Calypso/OZMOOE (OZMOOE)
_FINDSWR 0900 0900 01f2 a344b677382ae8aaea3011958d80ebe9 Calypso
    ->test/Calypso/FINDSWR (FINDSWR)
_LOADER 1900 8023 23a5 eef810416007d4296263a9076d8ab644 Calypso
    ->test/Calypso/LOADER (LOADER)
_TURBO 00d0 00d0 001e 149cbe6ecb16c2d59a5b309514a1a5c5 Calypso
    ->test/Calypso/TURBO (TURBO)
_!BOOT 0000 0000 005a 89bd1224a597d26058890c6a58c2a855 Calypso
    ->test/Calypso/!BOOT (!BOOT)
dmb@quadhog:~/ozmoo/disks$ ls -l test/Calypso/
total 124
-rw-rw-r-- 1 dmb dmb   112 Jan 18 12:32 '!BOOT'
-rw-rw-r-- 1 dmb dmb   152 Jan 18 12:32  BUILD
-rw-rw-r-- 1 dmb dmb 48150 Jan 18 12:32  DATA
-rw-rw-r-- 1 dmb dmb   520 Jan 18 12:32  FINDSWR
-rw-rw-r-- 1 dmb dmb  9147 Jan 18 12:32  LOADER
-rw-rw-r-- 1 dmb dmb  9123 Jan 18 12:32  OZMOO2P
-rw-rw-r-- 1 dmb dmb 11352 Jan 18 12:32  OZMOOB
-rw-rw-r-- 1 dmb dmb 11953 Jan 18 12:32  OZMOOE
-rw-rw-r-- 1 dmb dmb 11796 Jan 18 12:32  OZMOOSH
-rw-rw-r-- 1 dmb dmb    52 Jan 18 12:32  TURBO

Dave

[hoglet]

Anyway, I've now got another reason to upgrade my Atom to VGA80:

Here's a little teaser of what's possible without the VGA80 upgrade:

This is using the VDU2440 VDU driver program, which gives a 40x24 display in CLEAR 4 graphics using a 6x8 character font.

Unfortunately, this doesn't support the VDU 31,x,y command, so I've added that into the Tube Host for now.

I've also added a build script for several of the OZMOO games to the archive:
https://github.com/hoglet67/AtomSoftwar ... ster/ozmoo

This builds the following selection and packages each for the Atom:
- Adventure...
- Alien Research Centre 3...
- Behind Closed Doors 9...
- Beyond Zork...
- Calypso...
- Hibernated 1 - Directors Cut...
- The Hitchhikers Guide to the Galaxy...
- Hollywood Hijinx...
- The Job R5...
- Leather Goddesses of Phobos...
- Planetfall...
- Wishbringer...
- Zork1: The Great Underground Empire...
- Zork2: The Wizard of Frobozz...
- Zork3: The Dungeon Master...

Once I've tidied this all up, and make another snapshot build of the archive.

Dave

[KenLowe]

Here's a little teaser of what's possible without the VGA80 upgrade:

This is using the VDU2440 VDU driver program, which gives a 40x24 display in CLEAR 4 graphics using a 6x8 character font.

Wow. That looks brilliant. I can't wait to give it a try!

I'm pretty sure some of those games use DSD images too (BeyondZork, for example), so I'm guessing that all works too. Beyond Zork is actually a good test game because it does more than just scroll text. If I recall, it builds a small map in the top right hand edge of the screen.

[hoglet]

Wow. That looks brilliant. I can't wait to give it a try!

Here you go:
https://github.com/hoglet67/AtomSoftwar ... tag/V12_02

They are all in Chapter B and are currently tagged with OZMOO as both the collection and publisher:

I will correct the publisher field to the actual published (e.g. Infocom) when I get time.

I've only uploaded the AtoMMC release ZIP file, as this isn't going to work over Econet until we can add Tube support.

There are very likely to be bugs and I have done very little testing, so let me know how you get on.

Dave

[KenLowe]

Wow. That looks brilliant. I can't wait to give it a try!

Here you go:
https://github.com/hoglet67/AtomSoftwar ... tag/V12_02

They are all in Chapter B and are currently tagged with OZMOO as both the collection and publisher:
Screenshot from 2023-01-19 14-20-44.png
I will correct the publisher field to the actual published (e.g. Infocom) when I get time.

I've only uploaded the AtoMMC release ZIP file, as this isn't going to work over Econet until we can add Tube support.

There are very likely to be bugs and I have done very little testing, so let me know how you get on.

Dave

Thank you. Looking good with the VDU2440 VDU driver! There's something amiss when using the menu to load the Zork games, though. They all load Zork3. However, if you manually navigate to the Zork directory, *BOOT will load the correct version.

[hoglet]

Thank you. Looking good with the VDU2440 VDU driver! There's something amiss when using the menu to load the Zork games, though. They all load Zork3. However, if you manually navigate to the Zork directory, *BOOT will load the correct version.

I spotted and fixed that earlier - it was a typo in the catalog spreadsheet.

It will be fixed in the next build.

Dave

[fredrikr]

When I look up the Acorn Atom, I read that it has 2 KB of RAM, expandable to 12 KB. What kind of black magic does it take to make it run something like Hollywood Hijinx?

BTW, some happiness over all your work: https://twitter.com/g0blin70/status/1616133354373382159

[hoglet]

When I look up the Acorn Atom, I read that it has 2 KB of RAM, expandable to 12 KB. What kind of black magic does it take to make it run something like Hollywood Hijinx?

Atoms can be upgraded well beyond this...

OZMOO is running on 6502 second processor connected to the Atom which has 64K of RAM.

Ken, I've just uploaded another snapshot build (12.03):
https://github.com/hoglet67/AtomSoftwar ... tag/V12_03

This fixes the catalog issues with the Zork games.

It also add's a fourth VDU option: Alan Knowles's SCREEN ROM, which gives a 42x24 screen that support VDU 28 text windows. This means the software scrolling option (Ctrl-S) is now useable, so the status line no longer flickers.

One thing I noticed is that once the screen start scrolling, OZMOO is sending an awful lot of VDU 28 commands, It looks like it's sending one per line, even in soft scrolling mode.

To debug this, I'm using the ICE Debugger that's included in Atom2K18 to watch the Tube VDU FIFO (#BEE1). Here's two lines from Calypso:

Code: Select all

11.962477 : Mem Rd Watch hit at 3237 reading BEE1:1C  .
11.963109 : Mem Rd Watch hit at 3237 reading BEE1:00  .
11.963215 : Mem Rd Watch hit at 3237 reading BEE1:17  .
11.963336 : Mem Rd Watch hit at 3237 reading BEE1:29  )
11.963470 : Mem Rd Watch hit at 3237 reading BEE1:01  .

11.963730 : Mem Rd Watch hit at 3237 reading BEE1:1F  .
11.964330 : Mem Rd Watch hit at 3237 reading BEE1:29  )
11.971434 : Mem Rd Watch hit at 3237 reading BEE1:16  .

11.974942 : Mem Rd Watch hit at 3237 reading BEE1:0A  .

12.146328 : Mem Rd Watch hit at 3237 reading BEE1:1A  .

12.146887 : Mem Rd Watch hit at 3237 reading BEE1:1F  .
12.147487 : Mem Rd Watch hit at 3237 reading BEE1:00  .
12.147731 : Mem Rd Watch hit at 3237 reading BEE1:17  .

12.150407 : Mem Rd Watch hit at 3237 reading BEE1:6E  n
12.151177 : Mem Rd Watch hit at 3237 reading BEE1:69  i
12.152230 : Mem Rd Watch hit at 3237 reading BEE1:67  g
12.153551 : Mem Rd Watch hit at 3237 reading BEE1:68  h
12.154284 : Mem Rd Watch hit at 3237 reading BEE1:74  t
12.155054 : Mem Rd Watch hit at 3237 reading BEE1:20
12.156107 : Mem Rd Watch hit at 3237 reading BEE1:73  s
12.157365 : Mem Rd Watch hit at 3237 reading BEE1:6B  k
12.158098 : Mem Rd Watch hit at 3237 reading BEE1:79  y
12.158868 : Mem Rd Watch hit at 3237 reading BEE1:20
12.159921 : Mem Rd Watch hit at 3237 reading BEE1:67  g
12.161179 : Mem Rd Watch hit at 3237 reading BEE1:69  i
12.161912 : Mem Rd Watch hit at 3237 reading BEE1:76  v
12.162682 : Mem Rd Watch hit at 3237 reading BEE1:69  i
12.163798 : Mem Rd Watch hit at 3237 reading BEE1:6E  n
12.165056 : Mem Rd Watch hit at 3237 reading BEE1:67  g
12.165789 : Mem Rd Watch hit at 3237 reading BEE1:20
12.166559 : Mem Rd Watch hit at 3237 reading BEE1:79  y
12.167612 : Mem Rd Watch hit at 3237 reading BEE1:6F  o
12.168870 : Mem Rd Watch hit at 3237 reading BEE1:75  u
12.169603 : Mem Rd Watch hit at 3237 reading BEE1:20
12.170373 : Mem Rd Watch hit at 3237 reading BEE1:61  a
12.171426 : Mem Rd Watch hit at 3237 reading BEE1:20
12.172684 : Mem Rd Watch hit at 3237 reading BEE1:62  b
12.173480 : Mem Rd Watch hit at 3237 reading BEE1:72  r
12.174250 : Mem Rd Watch hit at 3237 reading BEE1:69  i
12.175303 : Mem Rd Watch hit at 3237 reading BEE1:65  e
12.176561 : Mem Rd Watch hit at 3237 reading BEE1:66  f
12.177294 : Mem Rd Watch hit at 3237 reading BEE1:20
12.178064 : Mem Rd Watch hit at 3237 reading BEE1:67  g
12.179117 : Mem Rd Watch hit at 3237 reading BEE1:6C  l
12.180375 : Mem Rd Watch hit at 3237 reading BEE1:69  i
12.181108 : Mem Rd Watch hit at 3237 reading BEE1:6D  m
12.181878 : Mem Rd Watch hit at 3237 reading BEE1:70  p
12.182994 : Mem Rd Watch hit at 3237 reading BEE1:73  s
12.184252 : Mem Rd Watch hit at 3237 reading BEE1:65  e
12.184985 : Mem Rd Watch hit at 3237 reading BEE1:20
12.185755 : Mem Rd Watch hit at 3237 reading BEE1:6F  o
12.186808 : Mem Rd Watch hit at 3237 reading BEE1:66  f
12.188066 : Mem Rd Watch hit at 3237 reading BEE1:20
12.188799 : Mem Rd Watch hit at 3237 reading BEE1:61  a

12.189569 : Mem Rd Watch hit at 3237 reading BEE1:1C  .
12.190138 : Mem Rd Watch hit at 3237 reading BEE1:00  .
12.190244 : Mem Rd Watch hit at 3237 reading BEE1:17  .
12.190365 : Mem Rd Watch hit at 3237 reading BEE1:29  )
12.190499 : Mem Rd Watch hit at 3237 reading BEE1:01  .

12.190759 : Mem Rd Watch hit at 3237 reading BEE1:1F  .
12.191359 : Mem Rd Watch hit at 3237 reading BEE1:29  )
12.198526 : Mem Rd Watch hit at 3237 reading BEE1:16  .

12.201971 : Mem Rd Watch hit at 3237 reading BEE1:0A  .

12.373420 : Mem Rd Watch hit at 3237 reading BEE1:1A  .

12.373979 : Mem Rd Watch hit at 3237 reading BEE1:1F  .
12.374579 : Mem Rd Watch hit at 3237 reading BEE1:00  .
12.374823 : Mem Rd Watch hit at 3237 reading BEE1:17  .

12.377499 : Mem Rd Watch hit at 3237 reading BEE1:6C  l
12.378269 : Mem Rd Watch hit at 3237 reading BEE1:69  i
12.379322 : Mem Rd Watch hit at 3237 reading BEE1:66  f
12.380580 : Mem Rd Watch hit at 3237 reading BEE1:65  e
12.381313 : Mem Rd Watch hit at 3237 reading BEE1:6C  l
12.382083 : Mem Rd Watch hit at 3237 reading BEE1:65  e
12.383199 : Mem Rd Watch hit at 3237 reading BEE1:73  s
12.384457 : Mem Rd Watch hit at 3237 reading BEE1:73  s
12.385190 : Mem Rd Watch hit at 3237 reading BEE1:20
12.385960 : Mem Rd Watch hit at 3237 reading BEE1:68  h
12.387013 : Mem Rd Watch hit at 3237 reading BEE1:6F  o
12.388271 : Mem Rd Watch hit at 3237 reading BEE1:72  r
12.389004 : Mem Rd Watch hit at 3237 reading BEE1:69  i
12.389774 : Mem Rd Watch hit at 3237 reading BEE1:7A  z
12.390827 : Mem Rd Watch hit at 3237 reading BEE1:6F  o
12.392085 : Mem Rd Watch hit at 3237 reading BEE1:6E  n
12.392881 : Mem Rd Watch hit at 3237 reading BEE1:20
12.393651 : Mem Rd Watch hit at 3237 reading BEE1:61  a
12.394704 : Mem Rd Watch hit at 3237 reading BEE1:6E  n
12.395962 : Mem Rd Watch hit at 3237 reading BEE1:64  d
12.396695 : Mem Rd Watch hit at 3237 reading BEE1:20
12.397465 : Mem Rd Watch hit at 3237 reading BEE1:61  a
12.398518 : Mem Rd Watch hit at 3237 reading BEE1:20
12.399776 : Mem Rd Watch hit at 3237 reading BEE1:64  d
12.400509 : Mem Rd Watch hit at 3237 reading BEE1:61  a
12.401279 : Mem Rd Watch hit at 3237 reading BEE1:72  r
12.402332 : Mem Rd Watch hit at 3237 reading BEE1:6B  k
12.403653 : Mem Rd Watch hit at 3237 reading BEE1:2C  ,
12.404386 : Mem Rd Watch hit at 3237 reading BEE1:20
12.405156 : Mem Rd Watch hit at 3237 reading BEE1:65  e
12.406209 : Mem Rd Watch hit at 3237 reading BEE1:6D  m
12.407467 : Mem Rd Watch hit at 3237 reading BEE1:70  p
12.408200 : Mem Rd Watch hit at 3237 reading BEE1:74  t
12.408970 : Mem Rd Watch hit at 3237 reading BEE1:79  y
12.410023 : Mem Rd Watch hit at 3237 reading BEE1:20
12.411281 : Mem Rd Watch hit at 3237 reading BEE1:73  s
12.412014 : Mem Rd Watch hit at 3237 reading BEE1:65  e
12.412784 : Mem Rd Watch hit at 3237 reading BEE1:61  a
12.413900 : Mem Rd Watch hit at 3237 reading BEE1:2E  .

Is this expected?

That's quite a bit of overhead.

Dave

[KenLowe]

Ken, I've just uploaded another snapshot build (12.03):
https://github.com/hoglet67/AtomSoftwar ... tag/V12_03

This fixes the catalog issues with the Zork games.

It also adds a fourth VDU option: Alan Knowles's SCREEN ROM, which gives a 42x24 screen that support VDU 28 text windows. This means the software scrolling option (Ctrl-S) is now useable, so the status line no longer flickers.

Excellent. I'm away from home just now, but I'll certainly give this a test tomorrow, once I'm back home!

Edit: In the interim, I thought I've give this a try on Atomulator, but it doesn't seem to have support for Co-Pros, so I'll need to wait until tomorrow!

[hoglet]

Edit: In the interim, I thought I've give this a try on Atomulator, but it doesn't seem to have support for Co-Pros, so I'll need to wait until tomorrow!

The only emulator that has support for the Atom Tube is MAME.
viewtopic.php?f=4&t=14828&p=355418#p355418

I must try this out tomorrow.....

Dave

[KenLowe]

The only emulator that has support for the Atom Tube is MAME.
viewtopic.php?f=4&t=14828&p=355418#p355418

I must try this out tomorrow.....

I thought I'd give this a try, but I got lost in a sea of options. I can't figure out how to add in all the required hardware, so I'll ask for some help in the MAME Atom thread.

Edit: Turns out the Atom changes haven't made it into the release version of MAME yet:

viewtopic.php?p=382125#p382125

[hoglet]

Edit: Turns out the Atom changes haven't made it into the release version of MAME yet:

viewtopic.php?p=382125#p382125

Oh that's a shame, this would have been really useful.

Maybe Nigel could share a development snapshot?

[KenLowe]

Ken, I've just uploaded another snapshot build (12.03):
https://github.com/hoglet67/AtomSoftwar ... tag/V12_03

This fixes the catalog issues with the Zork games.

It also adds a fourth VDU option: Alan Knowles's SCREEN ROM, which gives a 42x24 screen that support VDU 28 text windows. This means the software scrolling option (Ctrl-S) is now useable, so the status line no longer flickers.

Excellent. I'm away from home just now, but I'll certainly give this a test tomorrow, once I'm back home!

I've given this a quick test, and it looks really nice. The software scrolling also works nicely with the SCREEN ROM. I notice that the LOADING progress bar looks a bit strange. I take it that's down to some missing or differently configured VDU codes?

Edit: And one other observation, the SAVE and RESTORE commands are overwriting part of the screen, which makes it a bit more difficult to see what's going on. However, the SAVE routine also seems to think a file already exists when you enter a new filename. I'm not sure why it's doing that.

[hoglet]

I notice that the LOADING progress bar looks a bit strange. I take it that's down to some missing or differently configured VDU codes?

Yes, the loading bar is sending the following characters:
- half_block_graphic = 181
- full_block_graphic = 255

These are hard-coded to specific MODE 7 block graphic characters, as the LOADING progress bar is always shown in MODE 7 on the BBC. I wonder what happens on the Electron???

The 32x16 Atom VDU has suitable equivalents, but the Soft VDU drivers do not.

But that would require changes to Ozmoo, something we have not had to do yet...

Dave

[SteveF]

One thing I noticed is that once the screen start scrolling, OZMOO is sending an awful lot of VDU 28 commands, It looks like it's sending one per line, even in soft scrolling mode.

Is this expected?

It's been a while, but that sounds about right - if maybe suboptimal. Take this with a pinch of salt, but I think the reason it works like this is that on the C64, the newline is a single operation which causes the appropriate part of the screen to scroll in software. I emulated this using VDU 28 for software scrolling, and I didn't want to leave the text window in effect in case something in the Z-machine text output model could scroll a different part of the screen or the whole screen later on and that wouldn't behave correctly because of the existing text window. So I left the text window in effect just long enough to do each scroll. This code dates back to a fairly early point in the Acorn port and I probably wanted to keep things as simple as possible.

It might be possible to improve this - eg remember we have defined a text window and check it's still correct before any subsequent scroll operation and remove/redefine it if it isn't. This might take a bit more code (and thus leave a little less free memory for the game) but probably not loads.

Yes, the loading bar is sending the following characters:
- half_block_graphic = 181
- full_block_graphic = 255

These are hard-coded to specific MODE 7 block graphic characters, as the LOADING progress bar is always shown in MODE 7 on the BBC. I wonder what happens on the Electron???

I think the loader executes a couple of VDU 23 commands to define these to the right shapes, so this "just works" in mode 6 afterwards.

[fredrikr]

I just realized this might be useful to the people using Ozmoo for Acorn too:

If you have a Z-code file embedded in a Blorb file (typically ending with .blb or .blorb or .zlb or .zblorb) you can upload the Blorb file to Ozmoo Online (https://microheaven.com/ozmooonline/ ) and it will extract the Z-code file for you. You can then download the Z-code file (and delete it from the server if you want).

[fredrikr]

A new full-sized game (126 KB z3) using PunyInform has been uploaded to bbcmicro.co.uk, and it's about a visitor at a retro computing gathering, so I guess many of us can relate. https://bbcmicro.co.uk/game.php?id=4287

[AndyGarton]

Apologies if this has already been answered in the thread, but my search skills have let me down - I have an Electron with an ElkSD128 (so plenty of sideways RAM). I've built some games with Ozmoo and they run fine, but are apparently stuck in (I think) mode 6, with an ugly (to me eyes) blue and black stripey background. Is it possible to change to a different mode, ideally an 80 column mode, please?

[SteveF]

Apologies if this has already been answered in the thread, but my search skills have let me down - I have an Electron with an ElkSD128 (so plenty of sideways RAM). I've built some games with Ozmoo and they run fine, but are apparently stuck in (I think) mode 6, with an ugly (to me eyes) blue and black stripey background. Is it possible to change to a different mode, ideally an 80 column mode, please?

Excellent timing for this question Andy.

I've been working on Ozmoo to add support for running in other modes on machines with no shadow RAM. With PAGE=&E00 (which you probably have on the ElkSD128), you can usually run in mode 3 (80 columns), mode 4, mode 6 or (on a BBC, of course) mode 7.

Here's 11.39 alpha 45: https://github.com/ZornsLemma/ozmoo/rel ... 9-alpha-45. I'd like to point out that this really *is* alpha code, because the logic to check whether a game will fit on a particular machine in a particular screen mode is something I find a bit brain-bending (which maybe just means I don't understand it as well as I should, and/or that I'm not looking at it in the cleanest way possible) and I had to twiddle it quite a lot. But since Andy's question came along at just the right time, I figure I'll announce this now and maybe get some other people to do the testing for me.

The most likely bugs as a result of this change are:

• The game offering to run in a certain mode, then crashing when it actually tries to run.
• The game not offering to run in a certain mode when it should actually be able to do so.
• The game complaining about not having enough RAM to run at all when it does.
• The game complaining correctly about not having enough RAM to run at all, but not correctly reporting what the RAM shortfall is.
• The game crashing because there's a syntax error on a line of code to check some aspect of the memory configuration that doesn't get executed very often so I haven't noticed it yet.

The only downside (once I fix any bugs I've introduced ) to this change is that the game you build will (almost) never work on a 32K machine. This was probably more of a party trick than anything useful (if anyone has enjoyed playing an Ozmoo game seriously on a 32K machine I'd be interested to hear about it...), but if it's important to you you can specify --try-support-32k to get the old behaviour. Note the word "try" - there's no guarantee a particular game *can* be run on a 32K machine.

At the risk of stating the obvious, there's no free lunch here - if you run in mode 3 compared to mode 6, there's an extra 8K of RAM used for the screen, so there will be 8K less RAM available for caching the game data and it may run noticeably slower. But if you choose the mode you'd have had forced on you by the older versions of Ozmoo, you're no worse off - you don't pay for something you aren't using.

When using larger screen modes with no shadow RAM you'll probably see temporary screen corruption during a RESTART because the game re-loads itself from disc and will overrun into screen memory; this is transient and the game will clear the screen after it has finished loading.

Mode 3 and mode 6 always have black bars between the lines of text, but obviously you can't see them won't notice them if the background is black on the lines of text themselves. You can avoid seeing them (even in older versions of Ozmoo) by using CTRL-B to change the background to black, or by specifying --default-bg-colour=0 when running make-acorn.py so the background defaults to black instead of blue. Edit: I forgot that on a BBC, you can tweak the CRTC settings to close up the black bars between the lines even when using non-black backgrounds. I can think about adding support for that in Ozmoo if anyone's interested. I don't believe it's possible to do this on an Electron though.

I've changed the default mode highlight colour on the mode 7 loader screen from red to blue. I don't know if this will be massively controversial or not. I did like the red, but it felt a bit in your face for something that's important but isn't the central focus of the screen. Feedback on this welcome, and note that (although it might not work in this alpha, for purely hacky reasons) you can always override the default using a custom title page, and I could and probably will add a simple command line switch to control this more easily.

I've also had to create new mode menu layouts for all the different combinations of available modes that might now be experienced at runtime. Suggested tweaks to these layouts are welcome.

Alpha 45 may also be *slightly* faster than the previous release as I've tried to optimise the use of zero page.

Please don't hesitate to report any problems or suggestions. I am particularly interested in reports of brokenness as a result of unusual machine configurations, PAGE values and uses of the --min-mode and --max-mode build options to restrict the modes the game is allowed to run in.

Technical details

For those interested in this kind of thing...

There's also a new --cache-test option to make-acorn.py which adds a CACHTST BASIC program to the generated SSD. This can be run on a second processor (only) to test the host cache.

The reason the "allow mode choice on machine with no shadow RAM" change means games won't run on an unexpanded 32K machine is that in order to keep as much main RAM free as possible (since that's where the screen memory has to live), we don't consider building using the small dynamic memory model for non-shadow machines, and we prefer to use the medium model over the big model. The medium model puts dynamic memory in the first sideways RAM bank, so we must have at least one such bank. (The big model would potentially allow a 32K machine to run a small game with no sideways RAM, but the big model is slower and more complex and it doesn't feel like a good trade off to force its use just to maybe allow a game to run on a 32K machine while also allowing mode choice on a non-shadow machine. The Ozmoo code itself also gets bigger as a result of the complexity, which will reduce the free RAM for the game even further and make it less likely to work on a 32K machine.) --try-support-32k tells the build system to consider using the small model, as it used to, before trying the medium model.

Although it didn't necessarily give the big wins I'd hoped for, I used two tricks to optimise the zero page use:

• I wrote a hacky Python script which would analyse the "acme" report output and calculate how many bytes would be saved by changing each absolute address to a zero page address (taking into account only instructions which actually have a zero page form), so I could see which would shrink the game code most by moving them into zero page.
• I hacked b-em to count how many times an instruction was executed which a) accessed an absolute address and b) had an equivalent zero page form, and ran the benchmark. This allowed me to see which variables might give the biggest performance increase from being moved into zero page.

[AndyGarton]

Works a treat, thanks Steve!

[SteveF]

Thanks Andy, always lovely to see photos of Ozmoo in action!

[SteveF]

I had a quick go at knocking up a possible splash screen for Zork I. It's probably not finished - some text in a nice font would probably be good, and there's probably scope for manually twiddling some pixels on the logo - but I thought I'd post it here in case anyone wants to play with it.

(Did any of the official Zork releases have title screens we could adapt?)

It's here as a PNG, which I think should work in mode 1.

FWIW I started with the image on zork.fandom.com and twiddled it a bit in gimp:

• I selected the "colourful" areas (the door, the glowing thing behind it and the bolts/latches on the letters) to allow me to treat the two parts of the image differently.
• I applied a threshold to the black and white areas to get a cleaner appearance.
• I posterised the colourful areas to reduce the number of colours there.
• I then did minor bits of twiddling to e.g. remove some stray green pixels and tidy up the fuzzy halo around some of the letters.
• I cropped and scaled it to fit in 320x256.

[KenLowe]

Brilliant .

You do realise you're going to have to do the same with all the other Infocom games now!

[AndyGarton]

Great stuff, is there a way to make it show as the game launches by any chance?

Regarding “official” title screens, it’s funny you should mention it as I’ve been messing about getting Zork going on my Nabu today, and it does have a title screen. I wouldn’t know how to get at the actual file, but it’s similar to yours anyway, and can be seen in the video below around 8 minutes 45 seconds (and in the YouTube thumbnail actually):

https://youtu.be/B-cNE_ZLMH4

[SteveF]

Great stuff, is there a way to make it show as the game launches by any chance?

Thanks Andy! You need to convert it to BBC screen format first. I think the last time I asked the recommended tool for this was the "BBC Image Converter", but as it's a Windows app I've never used it myself - I hope someone else will be able to offer advice on this.

I've hacked something together in Python to do the conversion as a one-off and the Zork I image in BBC screen format along with the hacky Python script to do the conversion (just for reference; I'm not suggesting you or anyone else would like to use it...) are in the attached zip file.

If you unzip that, you just need to add:

Code: Select all

--splash-image=zork-1-wip-4.scr --splash-mode=1

to your make-acorn.py command line to use this as the splash screen for the generated game disc.

Regarding “official” title screens, it’s funny you should mention it as I’ve been messing about getting Zork going on my Nabu today, and it does have a title screen. I wouldn’t know how to get at the actual file, but it’s similar to yours anyway, and can be seen in the video below around 8 minutes 45 seconds (and in the YouTube thumbnail actually):

It's super cool that you have a Nabu! - I saw Adrian Black's video on this a while back. If anyone feels like tweaking (or of course starting from scratch) my Zork I image to look more like this, please feel free. The nice thing about not having any official releases of Infocom Ozmoo games is that everyone can use whichever (or no) title screen they like, so the more variants the better.

I did wonder about using something like Dithertron to generate a mode 2 version with less "in your face" colours for the door, but I quite liked the extra sharpness from mode 1's higher resolution.

Brilliant .

You do realise you're going to have to do the same with all the other Infocom games now!

Thanks Ken! I could see myself at least doing Zork 1-3 to start with. But I'll definitely wait and see if anyone comes up with any interesting remixes or completely alternate versions first. It might be nice to mimic the screen on Andy's Nabu version, for example.

[KenLowe]

Just downloaded the latest Alpha, and added the Zork1 splash screen into both my DFS and ADFS builds. All looking good so far!