PunyInform and Ozmoo

[KenLowe]

Cool. I did wonder if an update was due! I'll take a look at that over the next few days.

Thanks!

[SteveF]

Thanks Ken, I'll keep my fingers crossed.

[lurkio]

The A-machine looks interesting but (assuming there's ~5% seriousness behind this ) I definitely don't have the time to take a port of this on right now.

Oh, I was definitely more than a little serious! But of course I understand that you don't have time to indulge my silly whims right now!

Is Ptolom a member here on stardot? It would be interesting if there was a dev diary type thread for the port.

No, I don't think Ptolom is on Stardot. I'm not aware of any dev diary or indeed of any progress since the brief convo I had with Ptolom in mid-November. I suspect that spare time is in short supply at the mo. Understandable. Never mind.

Your post actually gives me the push I've been needing to announce the latest Acorn version - 11.39 alpha 44

Just managed to give it a quick test (in BeebEm in Model B mode) with my usual run-through of Hitchhiker's -- the .Z5 version this time (which requires a bit of extra care if you're using the Z3-based walkthrough I've posted upthread). Everything seems to work fine!

[EdwardianDuck]

There is a ptolom here, <insert appropriate pronoun> was playing my game a while back. Might not be the same ptolom though.

[fredrikr]

(The scrollback feature would be an example of something to look at once a stable version is produced - it's potentially quite intrusive and I doubt I can reuse the Commodore implementation as the Acorn screen isn't (in general) a text mode where the characters live as ASCII or near ASCII in screen RAM.)

PETSCII <-> screen code mapping can be done in a few lines of code on Commodore machines, but the scrollback feature doesn't really care about PETSCII at all. It copies screen RAM contents, line by line, to the scrollback buffer as it is printed, and then back to screen RAM as the user requests to see the contents of the scrollback buffer. Before it starts showing scrollback contents, it backs up screen RAM and colour RAM, so it can just restore the state perfectly when it's done.

The things we're currently working on for Ozmoo:

* Smooth scrolling (pixel by pixel)
* Syncing regular scrolling to the raster beam to make scrolling flicker-free and tear-free
* User-selectable scroll speed (Unsynced, synced with different delays, smooth)

We have all of this working, but not for all platforms/modes.

We may call it Done anyway soon, to get a new release out for Christmas.

[SteveF]

The A-machine looks interesting but (assuming there's ~5% seriousness behind this ) I definitely don't have the time to take a port of this on right now.

Oh, I was definitely more than a little serious! But of course I understand that you don't have time to indulge my silly whims right now!

Thanks for your understanding! I did enjoy your creative writing at least. Fingers crossed there is some progress on this, either from Ptolom or someone else, as it would be cool to see a port. Have you at least considered having a go yourself? I remember you ported that 6502 game from another machine (the Nascom?) so this might be a nice next project. Based on my experiences doing the early port of Ozmoo, if you target the 6502 second processor exclusively you've got &400-&F800=61K of RAM free for machine code without playing any fancy tricks, so porting a C64 program that isn't using the fancy graphics/sound hardware isn't necessarily too involved. It's supporting things like sideways/shadow RAM that starts to pile on the complexity/divergence from the upstream code.

Your post actually gives me the push I've been needing to announce the latest Acorn version - 11.39 alpha 44

Just managed to give it a quick test (in BeebEm in Model B mode) with my usual run-through of Hitchhiker's -- the .Z5 version this time (which requires a bit of extra care if you're using the Z3-based walkthrough I've posted upthread). Everything seems to work fine!

Brilliant, thanks for giving it a try! Is there anything I could do to help minimise the "extra care" required? If it's down to RNG, it would be fairly easy to add a build option to fix the RNG seed (which is already done for the benchmark, in order to make the walkthrough predictable).

PETSCII <-> screen code mapping can be done in a few lines of code on Commodore machines, but the scrollback feature doesn't really care about PETSCII at all. It copies screen RAM contents, line by line, to the scrollback buffer as it is printed, and then back to screen RAM as the user requests to see the contents of the scrollback buffer. Before it starts showing scrollback contents, it backs up screen RAM and colour RAM, so it can just restore the state perfectly when it's done.

Thanks Fredrik - that's interesting. I haven't spent any time looking at the Commodore code yet so I didn't have any idea how it works. I flip-flop on just how hard this would be to implement on Acorn. Ozmoo is doing all screen access via the OS, and in most modes the screen is bitmapped (so you can't "read text back" from it, without going through a slow and not 100% reliable OS routine that compares the screen bitmap against the character set). It's also AFAIK annoyingly tricky to portably print at the bottom right character of the screen via the OS without it scrolling. The other concern is just the memory requirement - just reserving nK of the 32K main RAM is unlikely to work well, so I'd probably have to try to shoehorn this into using n blocks of the RAM used as virtual memory cache in order to take advantage of the various different RAM expansions supported. These are just off-the-cuff thoughts though, as I say I haven't seriously looked at implementing it yet.

The things we're currently working on for Ozmoo:

* Smooth scrolling (pixel by pixel)
* Syncing regular scrolling to the raster beam to make scrolling flicker-free and tear-free
* User-selectable scroll speed (Unsynced, synced with different delays, smooth)

These sound pretty nifty! I did notice the smooth scrolling feature when I did the last merge. It would be really cool to have that on Acorn - I remember having an ANSI serial terminal emulator on my Archimedes which emulated the VT100 smooth scrolling text and I though it looked really swanky. I have no idea if this is even feasible on the Acorn 8-bit machines though, although I suspect using the same techniques the cleverer games do might make it possible.

I don't have any real hardware so I'm not sure how flickery the scrolling is on Acorn Ozmoo, but if it could be improved that would be nice. I don't think (but I could be wrong) most applications which use the OS for text output do anything special to improve the flickering/tearing of text scrolling. This might be because it's not necessary, or it might be because there's not much you can do to improve it, or it might just be that no one felt it was worth doing.

To whatever extent smooth scrolling and/or flicker/tear-free scrolling can be implemented on 8-bit Acorn hardware, in theory someone could write a utility that intercepts output via the OS and does the necessary tricks to implement them. This would then benefit any application which uses the OS output routines, such as wordprocessors from BITD (and you'd be able to LIST a BASIC program and watch it scroll smoothly ), as well as Acorn Ozmoo. Ozmoo games could include such a utility on the game image and launch it automatically, but it wouldn't have to be deeply embedded in the Ozmoo code.

If anyone feels like getting into playing clever tricks with the CRTC but doesn't fancy writing an entire game, having a go at implementing smooth and/or less flickery scrolling via the OS VDU driver hooks would be a nice project. Hint hint! For Ozmoo to really benefit you'd probably want this to work for scrolling via a text window which covers all but the top line of the screen, which would address the typical game with a one line status bar. I suspect you'd need to start playing tricks with vertical rupture to do nice hardware scrolling in that case, but this is way outside my experience so I'm just guessing.

It might also be possible to allow scrollback and/or improved scroll appearance and restrict them to mode 7 only. That is a non-bitmapped mode and would probably remove a lot of complications.

[lurkio]

it would be cool to see a port [of the Å-machine terp]. Have you at least considered having a go yourself? I remember you ported that 6502 game from another machine (the Nascom?) so this might be a nice next project.

My assembler skills really aren't good enough. They never were. (But porting the UK101 version of Galactic Hitchhiker was fairly easy because all I had to do was insert shims to Acorn MOS routines wherever the original code jumped into the UK101 BASIC ROM. I didn’t need to understand most of the code in the game — so I didn’t, and I still don’t!) I'm not even confident enough to convert (parts of) BeebScott to assembler, which really needs doing. I'm not familiar enough with the 6502 instruction set or with binary arithmetic, etc. Don't think I have the time or the will to get up to speed now...

the latest Acorn version - 11.39 alpha 44

Just managed to give it a quick test (in BeebEm in Model B mode) with my usual run-through of Hitchhiker's -- the .Z5 version this time (which requires a bit of extra care if you're using the Z3-based walkthrough I've posted upthread). Everything seems to work fine!

Brilliant, thanks for giving it a try! Is there anything I could do to help minimise the "extra care" required? If it's down to RNG, it would be fairly easy to add a build option to fix the RNG seed (which is already done for the benchmark, in order to make the walkthrough predictable).

Not sure if anything can be done to "fix" the issue. The issue is that in the Z5 version it seems to be harder to trigger the scene in which you encounter the Bugblatter beast. At least, my slightly vague memory is that it's easier (trivial) to trigger the scene in the Z3 version. Not sure why. Anyway, it's not a big deal.

[EdwardianDuck]

For what it's worth, I ran through .Z3 and .Z5 builds of my game (Duck! Me?) again using the latest build without any issue. The game itself still isn't any better though (see the review on IFDB.org for an idea of how rubbish it really is), so I'm still not recommending that anyone actually play it.

[BigEd]

Hmm... that's certainly a critical review, but it does offer ideas for improvement... might you revisit and add the suggested polish?

(It might be that the reviewer is not a great fan of the absurd. Or of Duckman. Or is it Howard? Or Donald??)

[EdwardianDuck]

The latest beta fixed the programming issues and added some subtle hints based on private feedback, but I think the fundamental issue is that the game doesn't fit in with the modern concept of interactive fiction which is much more about telling a story than solving puzzles. On reflection, I don't think intfiction.org is the right place to mention this sort of game.

The sequel was working on isn't even as good as this, just more of the same absurd nonsense.

Not that any of this matters in the slightest.

[8bitAG]

That particular reviewer describes his rating system as "unusually harsh" with "many games" getting a two star rating from him, so I wouldn't take too much of that to heart. Sometimes the mindset of a reviewer going in to an experience can completely colour their experience. I know that I managed to completely ruin what is considered to be an absolute classic of interactive fiction **in the very first move of the game** by going in with an adventure gamer's mindset.

There are a good mix of different people on the intfiction.org boards... I would hope that it *is* still the place to mention that sort of game. Yes, there are plenty that prefer the "modern" style of puzzle-light story-driven parser game or even choice-based narrative, but there are still some very old-school text adventure fans. Not every game will appeal to everyone there. No matter how good (or bad). I'm not really a fan of the sort of games that get 5 stars on IFDB myself... My brain isn't compatible with long dollops of word treacle... If I want a narrative-heavy, puzzle-light experience then I'll read a book or watch a show.

[SteveF]

For what it's worth, I ran through .Z3 and .Z5 builds of my game (Duck! Me?) again using the latest build without any issue. The game itself still isn't any better though (see the review on IFDB.org for an idea of how rubbish it really is), so I'm still not recommending that anyone actually play it.

Thanks for testing, it's much appreciated! I'm glad it worked.

I still haven't played more than a few moves of your game, but the review hasn't put me off my intention to do so at some point when the round tuit shortage improves; the humour and the atmosphere early on just felt "right", somehow. I didn't read the spoilers in the review though, so I can't say if the specific criticism there is fair or not. I thought some bits of the review were pretty positive in their way, and I think BigEd's point about maybe adding the suggested polish would be worth considering (assuming you think the reviewer's comments there are fair, of course).

On a completely tangential note, I'm sure it's pretty painful putting a lot of work into a creative project and having to read criticism of it - or no one taking any interest and therefore not having to read criticism of it, for that matter! I did at one point feel a surge of enthusiasm for writing a novelty-ish game based on the central premise of one of the stories in "The Cyberiad", involving a machine that could create anything, but only if its name started with "n". Perhaps luckily for me, I subsequently found out Counterfeit Monkey had already done vaguely the same kind of thing but way way better than I ever could, so I was spared the pain of creation and criticism.

[EdwardianDuck]

I just uploaded a sequel "Lost in 17% of DuckSpace". Rather than play this through in something modern like SpatterLight or Frotz, I've take the time today to play it in B2 via Ozmoo. Again, I haven't spotted any issues with Ozmoo.

Jeremy

[fredrikr]

We released Ozmoo v12 for Commodore. Two days later I discovered and fixed a serious bug related to z1 and z2 games and the use of an REU, so we released v12.1.

Where can I find this Duck game sequel?

[SteveF]

We released Ozmoo v12 for Commodore. Two days later I discovered and fixed a serious bug related to z1 and z2 games and the use of an REU, so we released v12.1.

Congratulations! For what it's worth, I am not intending to merge this to the Acorn port until after the stable candidate has had some time to bed in, unless this bug is relevant, and given there's no REU on Acorn I *suspect* (but haven't looked at the fix yet) it isn't.

Where can I find this Duck game sequel?

I think you can find it in this thread - I'm sure Jeremy will correct me if I've got that wrong.

[fredrikr]

We released Ozmoo v12 for Commodore. Two days later I discovered and fixed a serious bug related to z1 and z2 games and the use of an REU, so we released v12.1.

Congratulations! For what it's worth, I am not intending to merge this to the Acorn port until after the stable candidate has had some time to bed in, unless this bug is relevant, and given there's no REU on Acorn I *suspect* (but haven't looked at the fix yet) it isn't.

We calculate the number of 64 KB banks to reserve for game data in the REU, based on the file size and dynmem size stated in the header (we only store static memory in the REU). This calculation went wrong for z1 and z2 since they don't store the file size in the header.

The code where the bug occurred is only built if SUPPORT_REU = 1.

If you find yourself calculating the file size from the header information somewhere else, you should be aware of this though.

Where can I find this Duck game sequel?

I think you can find it in this thread - I'm sure Jeremy will correct me if I've got that wrong.

Thanks!

[SteveF]

We calculate the number of 64 KB banks to reserve for game data in the REU, based on the file size and dynmem size stated in the header (we only store static memory in the REU). This calculation went wrong for z1 and z2 since they don't store the file size in the header.

The code where the bug occurred is only built if SUPPORT_REU = 1.

If you find yourself calculating the file size from the header information somewhere else, you should be aware of this though.

Thanks Fredrik, I think I'm probably OK then - the header_static_mem and header_filelen constants aren't used in any of the Acorn specific code. Obviously if anyone hits problems with z1 and z2 games please let me know.

[KenLowe]

Thanks Ken, I'll keep my fingers crossed.

Sorry, it's taken me a bit longer than anticipated to run these tests. I was having a few Econet permissions & ownership issues, but I've resolved those now, and everything seems to be in order. No issues to report!

[SteveF]

Brilliant, thanks Ken! And Merry Christmas to everyone too.

[SteveF]

I've promoted 11.39 alpha 44 to 11.39 beta 1; there's a new tag here but nothing at all has changed except for the version string. If nothing goes wrong I will probably promote this to "stable" status in a week or so. Thanks again to those of you who've given the alpha a try!

[SteveF]

I've promoted 11.39 beta 1 to stable status, and the version is now "11.39 (2023-01-15)". Nothing has changed since the beta other than the version number. You can get it on github as usual.

I've updated the "official" web page for Acorn Ozmoo to reference this new version.

Thanks to everyone for testing, and of course to Johan and Fredrik for their continued efforts developing Ozmoo!

[KenLowe]

I've promoted 11.39 beta 1 to stable status, and the version is now "11.39 (2023-01-15)". Nothing has changed since the beta other than the version number. You can get it on github as usual.

I've updated the "official" web page for Acorn Ozmoo to reference this new version.

Thanks to everyone for testing, and of course to Johan and Fredrik for their continued efforts developing Ozmoo!

. And thank you for the beeb conversion!

You do know that I'm working on my Atom right now, but I can't find any of the Ozmoo games in the Atom Software Archive yet

Joking aside, I've got a CoPro running on my Atom, so I'm not sure how close we would be to getting Ozmoo running on the Atom???

[SteveF]

. And thank you for the beeb conversion!

Thanks Ken!

Joking aside, I've got a CoPro running on my Atom, so I'm not sure how close we would be to getting Ozmoo running on the Atom???

I suspect this is doable. Off the top of my head:

• Build the Ozmoo game with --no-tube-cache so it doesn't try to use free main/sideways RAM on the host to cache game data. This could probably be supported, but it would need Atom-specific code to be written.
• Build the Ozmoo game with --no-history so it doesn't try to play games with INSV on the host.
• Hack the loader so it doesn't try to run FINDSWR and just assumes there are 0 sideways RAM banks, or replace FINDSWR with a stub binary that just indicates 0 SWR banks are present.
• Make sure you choose a screen mode in the loader which the Atom supports.

Provided the Atom host code implements OSWORD &7F (for a DFS build) or OSGBPB (for a non-DFS build), it *might* then "just work". After all, most of the code is running on the copro - the main thing is to avoid or fix up the relatively small bits of Ozmoo which play around with the host even when running on the copro.

I have absolutely no experience with the Atom myself. I definitely won't have time to look at an Atom port in the near future, but I wouldn't absolutely rule out giving it a try at some point. If you or anyone else feels like having a go please do. I suspect an initial port of a specific game could be done by building a BBC version with the options above and just doing a little bit of manual hackery to copy files over to an Atom disc format and tweaking the loader. That experience would then be useful if we subsequently decide to try to incorporate Atom support directly into the build script.

As I say, I think this is interesting but I won't have time to look at it in the near future. I'm happy to be a back-seat driver in this thread and offer advice and encouragements if anyone feels like having a go.

Edited to add: I'd suggest starting off with a game small enough to fit on a single-sided DFS disc, as that avoids the interleaving of data across the two sides which just might trip things up if the Atom's discs are different. This might not be an issue, but better to play it safe to start with.

I was going to say that starting off with a small game (like Calypso?) that doesn't need virtual memory on a copro might avoid the need for OSWORD &7F/OSGBPB support, but I would have been wrong - we still need these OS calls to load the game data into memory on startup, even if there's no virtual memory used during play.

And I assume there's no reason Ozmoo couldn't run natively on the Atom without copro if there's an expansion which gives enough RAM to work with, if any experienced Atom developers feel like giving this a try. But the copro would almost certainly be an easier way to do this!

[KenLowe]

If you or anyone else feels like having a go please do.

A bit of hackery is on the TODO list!

Edited to add: I'd suggest starting off with a game small enough to fit on a single-sided DFS disc, as that avoids the interleaving of data across the two sides which just might trip things up if the Atom's discs are different. This might not be an issue, but better to play it safe to start with.

I was going to say that starting off with a small game (like Calypso?) that doesn't need virtual memory on a copro might avoid the need for OSWORD &7F/OSGBPB support, but I would have been wrong - we still need these OS calls to load the game data into memory on startup, even if there's no virtual memory used during play.

We've got Econet running on the Atom, so I was thinking about running it from Econet.

Edit:

And I assume there's no reason Ozmoo couldn't run natively on the Atom without copro if there's an expansion which gives enough RAM to work with, if any experienced Atom developers feel like giving this a try. But the copro would almost certainly be an easier way to do this!

An expanded Atom does have extra RAM, but I'm not sure there would be enough for the bigger games that also rely on shadow or sideways RAM when run from the beeb.

[SteveF]

If you or anyone else feels like having a go please do.

A bit of hackery is on the TODO list!

Excellent!

We've got Econet running on the Atom, so I was thinking about running it from Econet.

That sounds like a good plan!

[SteveF]

PS If you're going to be hand-editing the loader (which you probably will!), you might like to build the game with --no-loader-crunch to make it more legible - on a co-pro the extra size of the loader shouldn't cause any problems.

[KenLowe]

PS If you're going to be hand-editing the loader (which you probably will!), you might like to build the game with --no-loader-crunch to make it more legible - on a co-pro the extra size of the loader shouldn't cause any problems.

That's definitely helpful. I've noted that you can't just run the OZMOO2P executable without running the LOADER first? I'm guessing LOADER is setting up certain memory locations before starting OZMOO2P. eg:

Code: Select all

fg_colour=&417
bg_colour=&418
?&419=3
screen_mode=&416
?fg_colour=7:?bg_colour=4
?screen_mode=VAL(menu$(x,y))

Code: Select all

 1331DEF PROCdetect_swr
 1332swr_banks=FNpeek(&904):swr$=""
 1333swr_adjust=0
 1334IF NOT tube AND NOT private_ram_in_use THEN PROCadd_private_ram_as_swr
 1335IF FNpeek(&903)>2 THEN swr$="("+STR$(swr_banks*16)+"K unsupported sideways RAM)":PROCupdate_swr_banks(0)
 1336swr_size=&4000*swr_banks-swr_adjust
 1337IF swr_banks=0 THEN ENDPROC
 1338IF swr_size<=12*1024 THEN swr$="12K private RAM":ENDPROC
 1339swr$=STR$(swr_size DIV 1024)+"K sideways RAM (bank":IF swr_banks>1 THEN swr$=swr$+"s"
 1340swr$=swr$+" &":FOR i=0 TO swr_banks-1:bank=FNpeek(&905+i)
 1341IF bank>=64 THEN bank$="P" ELSE bank$=STR$~bank
 1342swr$=swr$+bank$:NEXT:swr$=swr$+")"
 1343ENDPROC
 1344DEF PROCadd_private_ram_as_swr
 1345IF swr_banks<9 AND integra_b THEN swr_banks?&905=64:PROCupdate_swr_banks(swr_banks+1):swr_adjust=16*1024-&2C00
 1346IF swr_banks<9 AND host_os=2 THEN swr_banks?&905=128:PROCupdate_swr_banks(swr_banks+1):?&904=swr_banks:swr_adjust=16*1024-&2E00
 1347ENDPROC
 1348DEF PROCupdate_swr_banks(i):swr_banks=i:PROCpoke(&904,i):ENDPROC

Is there anywhere that documents the very minimum requirements for running OZMOO2P to save me from trying to decipher LOADER?

[SteveF]

Hi Ken,

I'm afraid there's nothing very concrete.

The chances are most uses of the "?" and "$" operators to poke data into memory are potentially relevant. "$" isn't used much, and probably only matters for making RESTART able to find the executable correctly. Using a modern text editor to search for a regexp like "?.*=" (i.e. ? followed by some stuff followed by =) in the loader will probably find most things. It *might* also be helpful to look at asm/acorn-ozmoo-constants.asm just below the comment starting "; These addresses are written to by the loader...", although the code in there is a bit heavy on macro trickery in order to dynamically allocate addresses and it's probably easier just to look at the loader code.

OZMOO2P is probably generally less dependent on this kind of pre-initialised data than other executables, as it doesn't have to deal with variable PAGE and variable sideways RAM. However, it does check zero page location &ED to see if it's running on a 256K turbo co-processor. If you're having problems, I suspect setting &ED to 0 (to indicate a non-turbo co-pro) will fix things for you. (Edit: I un-bolded that as I just tried this and it wasn't enough to make it work for me in b-em. I'll have a further play.) This is normally set by running the "TURBO" executable from !BOOT. You could also try building with --no-turbo to disable the turbo support as well, although it might be nice to keep it on as there's probably no reason the Atom couldn't use one.

If this doesn't help let me know and I'll see if I can think of anything better, or I'll edit this post if I suddenly have a brainwave.

[SteveF]

OK, I think I've got it. What I wrote before wasn't quite right, at least not for non-DFS builds.

Based on playing around in b-em, I think to run OZMOO2P you must:

• ?&ED=0 to indicate non-turbo co-pro
• $&408="$.DATA" (or whatever path will find the DATA file correctly) - OZMOO2P won't change directory itself, so this can probably just be "DATA" if you're running from the right directory. (The loader will do *DIR SAVES before running OZMOO2P, which is why it messes around generating a full path.)
• Optional: set ?&438=7:?&439=0 to specify white text on black background - if you don't do this, you'll probably get black-on-black and it'll look like it's not working, but you can press CTRL-F/CTRL-B to change the colours at that point instead of poking these up front.

[hoglet]

If this doesn't help let me know and I'll see if I can think of anything better, or I'll edit this post if I suddenly have a brainwave.

Steve,

Is it possible to get the build to generate a listing file for the generated OZMOO2P file?

I am currently using a DFS build - is the above still all correct?

Dave