PunyInform and Ozmoo

[SteveF]

Hi Dave,

You can see the assembly listing in either temp/acme_report_ozmoo_tube_novmem_700 (if it's a game which doesn't use vmem - probably the case here) or temp/acme_report_ozmoo_tube_700. (The tube build is nice and simple here as there's no need to do relocation to handle variable PAGE.) Edit: I got those names wrong before, sorry!

For DFS, my instructions above won't work. You need to do:

Code: Select all

$&408="/:0.$.OZMOO2P" # probably only matters for the RESTART command
?&417=0:?&418=7:REM set bg/fg colours - different address in DFS builds as path at &408 has smaller max length

(Edit: I got the addresses for the colours wrong and have now fixed this - thanks Ken!)
You also need to do something else I haven't figured out yet. I will edit this post once I do...

Cheers.

Steve

[KenLowe]

Here's a copy from my build folder:

[hoglet]

So the first thing that's going wrong is the progress bar calculation, because it uses various osbytes that are not yet implemented:
- osbyte_read_cursor_position
- osbyte_read_screen_mode
- osbyte_read_cursor_position
- osbyte_read_vdu_variable

This is causing the progress_indicator_blocks_per_step to be calculated as -1 resulting in a very long progress bar that takes minutes to print.

After that, it uses the keyboard scanning osbytes (A=&81) which are also missing.

I fear this is going to be an uphill battle!

Dave

[KenLowe]

So the first thing that's going wrong is the progress bar calculation, because it uses various osbytes that are not yet implemented:
- osbyte_read_cursor_position
- osbyte_read_screen_mode
- osbyte_read_cursor_position
- osbyte_read_vdu_variable

This is causing the progress_indicator_blocks_per_step to be calculated as -1 resulting in a very long progress bar that takes minutes to print.

After that, it uses the keyboard scanning osbytes (A=&81) which are also missing.

I fear this is going to be an uphill battle!

Dave

Oh dear!

[SteveF]

It looks like you've got further than me! It's not strictly relevant to the Atom, but when I'm running DFS OZMOO2P direct from the BASIC prompt on an emulated Master+copro, I get "Bad command" and debugging seems to imply that it's getting upset when trying to use OSCLI to execute "GO 700" after decompressing the executable. *But* this works fine when it runs from the loader. I must be getting confused somewhere...

It would probably be possible to just hack out the code making most of those problematic calls, or hard-code them to return some vaguely sensible values which will probably work - obviously the progress bar isn't critical.

For OSBYTE &81: if it's easier, you could build the game with --osrdch to tell it to use OSRDCH for text input instead of OSBYTE &81. There will still be one remaining use of OSBYTE &81 to check for SHIFT being pressed during paging (screen.asm, search for "lda #osbyte_read_key") but that could probably be manually hacked to an OSRDCH as well (giving "press any key to scroll" behaviour instead of "press SHIFT to scroll").

(Edit: the reason it uses OSBYTE &81 by default is to allow for games which can generate timed events while waiting for the user's input. I don't think Calypso will use this, so there's nothing practical lost by using OSRDCH instead. We just default to the more general method.)

[KenLowe]

Hi Dave,

You can see the assembly listing in either temp/acme_report_ozmoo_tube_novmem_700 (if it's a game which doesn't use vmem - probably the case here) or temp/acme_report_ozmoo_tube_700. (The tube build is nice and simple here as there's no need to do relocation to handle variable PAGE.) Edit: I got those names wrong before, sorry!

For DFS, my instructions above won't work. You need to do:

Code: Select all

$&408="/:0.$.OZMOO2P" # probably only matters for the RESTART command
?&418=0:?&419=7:REM set bg/fg colours - different address in DFS builds as path at &408 has smaller max length

For OSBYTE &81: if it's easier, you could build the game with --osrdch to tell it to use OSRDCH for text input instead of OSBYTE &81. There will still be one remaining use of OSBYTE &81 to check for SHIFT being pressed during paging (screen.asm, search for "lda #osbyte_read_key") but that could probably be manually hacked to an OSRDCH as well (giving "press any key to scroll" behaviour instead of "press SHIFT to scroll").

With those settings it's very nearly working (using &417 and &418 for the bg & fg colours)! Once the loading has finished, I can see text characters appearing in the top left hand corner of the screen and there is regular beeping from the speaker as the characters change. It's difficult to make out, but the changing characters are definitely making up words. It looks like it's working in a 1 x3 character display (a block either side, with a changing character in the middle), and the beeping is occurring every time a 'page' is full! Eventually the characters stop changing and the beeping stops and the computer appears to hang up. I'm guessing this is the point where the game is looking for data input. I tried setting address &416 (screen-mode) to 6 to see if different modes would make any difference, but it didn't appear to. I'll do some more experimenting tomorrow evening.

[SteveF]

With those settings it's very nearly working (using &417 and &418 for the bg & fg colours)! Once the loading has finished, I can see text characters appearing in the top left hand corner of the screen and there is regular beeping from the speaker as the characters change. It's difficult to make out, but the changing characters are definitely making up words. It looks like it's working in a 1 x3 character display (a block either side, with a changing character in the middle), and the beeping is occurring every time a 'page' is full! Eventually the characters stop changing and the beeping stops and the computer appears to hang up. I'm guessing this is the point where the game is looking for data input. I tried setting address &416 (screen-mode) to 6 to see if different modes would make any difference, but it didn't appear to. I'll do some more experimenting tomorrow evening.

That sounds promising!

I do wonder if this is caused by Ozmoo trying to read the screen size via osbyte_read_vdu_variable and getting bad (small) values which cause it to try to use a tiny 1x3 display. It may also have something to do with the use of VDU codes 28 (vdu_define_text_window) and 26 (vdu_reset_text_window) to control the scrolling; I don't know if these are supported on the Atom in this enviroment. Most of this code is in screenkernal.asm and searching in it for calls to osbyte/oswrch will probably identify possible code for hacking around with.

Edit: Probably not the problem, but just in case: If you converted the "wait for SHIFT" code to "wait for any key", did you remember to remove the loop ("beq -" just above increase_num_rows_done in screen.asm) around it? We need to loop around calls to OSBYTE &81 as it returns even if there's no keypress, but we don't need it for OSRDCH.

Edit: I think you're right about the fg/bg colour addresses, sorry! I've patched up my post above now. I never got round to testing that bit properly as I was getting blocked on the "Bad command" problem. Still don't know what's happening there, although it's presumably not causing you guys any problems and it doesn't happen in normal use when the loader runs OZMOO2P, so I guess it's hardly a pressing issue, although it would be nice to know as it may suddenly start manifesting itself in normal use just to be spiteful at some point.

[KenLowe]

I do wonder if this is caused by Ozmoo trying to read the screen size via osbyte_read_vdu_variable and getting bad (small) values which cause it to try to use a tiny 1x3 display. It may also have something to do with the use of VDU codes 28 (vdu_define_text_window) and 26 (vdu_reset_text_window) to control the scrolling; I don't know if these are supported on the Atom in this environment. Most of this code is in screenkernal.asm and searching in it for calls to osbyte/oswrch will probably identify possible code for hacking around with.

Hoglet has already indicated that reading screen size via osbyte_read_vdu_variable is not implemented, but I've just had a quick look at the relevant code for reading the screen size and it could easily be hacked to match the Atom screen text resolution - whatever that actually is (edit: 32 x 16, it would appear)! I'm less certain about VDU 26 and 28 calls though.

Edit: Probably not the problem, but just in case: If you converted the "wait for SHIFT" code to "wait for any key", did you remember to remove the loop ("beq -" just above increase_num_rows_done in screen.asm) around it? We need to loop around calls to OSBYTE &81 as it returns even if there's no keypress, but we don't need it for OSRDCH.

I've not changed any code yet, but I understand what you're suggesting I to do here. Initially I might just comment out that section of code altogether, and let it continue scrolling without any user input, just to keep things simple. Once we've got a system that 'works', I can add in the OSRDCH code if that is what's required. I do wonder if I should switch from Hollywood to another game to avoid this initial scrolling issue. I'll probably switch to Calypso, so we're all using the same game - assuming there's no page scrolling on startup with that game.

Edit: I think you're right about the fg/bg colour addresses, sorry! I've patched up my post above now. I never got round to testing that bit properly as I was getting blocked on the "Bad command" problem. Still don't know what's happening there, although it's presumably not causing you guys any problems and it doesn't happen in normal use when the loader runs OZMOO2P, so I guess it's hardly a pressing issue, although it would be nice to know as it may suddenly start manifesting itself in normal use just to be spiteful at some point.

For clarity, this is what I typed into the Atom:

Code: Select all

?&416=6
?&417=0
?&418=7
$&408="OZMOO2P"
*RUN OZMOO2P

I'll probably create a small 'ATOMLOAD' basic file with those minimum commands, so I don't have to keep typing them in - particularly since my 6/& key isn't working, and I'm having to short out springs on the keyboard to get those characters!

I did notice a hard coded entry in the LOADER that I wasn't sure about:

Code: Select all

  609?&419=3

Any idea what that's for?

[SteveF]

I've not changed any code yet, but I understand what you're suggesting I to do here. Initially I might just comment out that section of code altogether, and let it continue scrolling without any user input, just to keep things simple. Once we've got a system that 'works', I can add in the OSRDCH code if that is what's required. I do wonder if I should switch from Hollywood to another game to avoid this initial scrolling issue. I'll probably switch to Calypso, so we're all using the same game - assuming there's no page scrolling on startup with that game.

This is entirely sensible, but FWIW another option would be to build Hollywood Hijinx in benchmark mode, which disables pause-on-scrolling to let the benchmark run through the whole game automatically.

For clarity, this is what I typed into the Atom:

Code: Select all

?&416=6
?&417=0
?&418=7
$&408="OZMOO2P"
*RUN OZMOO2P

That looks mostly good to me, although to be paranoid ?&ED=0 would be good (to explicitly set the non-turbo copro flag) and I think you strictly speaking need a "/" (shorthand for *RUN) at the start of the string at &408 - on DFS I think it's a command, on non-DFS it's the path of the DATA file - but that won't come into play until you're able to issue a "RESTART" command, so not a big deal.

I did notice a hard coded entry in the LOADER that I wasn't sure about:

Code: Select all

  609?&419=3

Any idea what that's for?

This will be setting the default mode 7 input colour to 3. Worst case for not having that set correctly is you'll get odd control characters at the input prompt if the game thinks it's running in mode 7.

FWIW I just remembered that you can look at the temp/acme_labels_ozmoo_tube_700 and temp/acme_labels_ozmoo_tube_novmem_700 files to convert addresses like &419 into their symbolic versions - this one is input_colour, for example. Edit: it's a bit more manual, but it might also be helpful to look at templates/loader.bas to see the "source code" for the loader - by comparing that with the actual BASIC loader on the generated disc image, you can usually manage to work out which line corresponds to which, and that also lets you see the original symbolic version before the literal address got substituted. This should be pretty easy when the BASIC loader hasn't been crunched.

[hoglet]

After a fair bit of debugging, some actual progress to report.

I've extended the Tube Host to support some of the missing OSBYTE calls (81/86/87/a0), and some of the Beeb-specific VDU control sequences (11/1A/1C/1F).

I was stuck for quite a while debugging a crash where the OZMOO code hit a BRK:

It turns out I'd made an error in the OSBYTE A0 (Read VDU Variables) implemention, where I had neglected to set Y to the value of next variable. This resulted in a very small screen width (1) and a buffer overflow (of the print_buffer2 buffer) which nobbled the code that follows it.

Changes to the TubeHost are in git:
https://github.com/hoglet67/AtomTubeHost/commits/master

Here's a snapshot:

TUBE.zip

(678.51 KiB) Downloaded 28 times

With that fixed, I can finally run Calypso

I'm building Calypso with the following options:

Code: Select all

python make-acorn.py -p --osrdch --no-tube-cache --no-history --title "Calypso" ../downloads/calypso.z5 ../disks/Calypso.dsk

For reference, here's the contents of my /CALYPSO folder:

Calypso.zip

(151.46 KiB) Downloaded 25 times

This is the program I'm using to start Calypso

And here's it running:

I've tried it with the 80-col mode, and this crashed so further work to do there.

This is excellent fun!

Dave

[KenLowe]

Making a little bit of progress, but I have a very quick question. I modified the code in screenkernal.asm that reads the screen size, so overwrites the OSBYTE values with fixed Atom values.

Code: Select all

    lda #osbyte_read_vdu_variable  ;$A0
    ldx #vdu_variable_text_window_bottom  ;$09
    jsr osbyte
    ldx #15 ;add by KL
    ldy #31 ;add by KL

And I've given this a quick test in BeebEm. If I select Mode 7 from the LOADER menu, the game play window reduces accordingly, and the text all looks good. I've also commented out the code that pauses scrolling, which is allowing the text to scroll without intervention. However, if I select any of the other modes, the game play window reduces, but the text is all displayed on the bottom line. It looks like this tweak has broken scrolling (which works ok in mode 7). If I change the column value (ldx number) to match the true value of the mode the game is running in, then it works ok with a narrower, but full height window.

Does anything jump out at you as to why it would do that? I've still to test this on the Atom, but I'm guessing the Atom will not be defaulting to mode 7, so I expect to see this issue.

Mode 7 - LDX #15

Mode 4 - LDX #15

Mode 4 - LDX #31

Edit: Oooh. Just seen hoglets post. Excellent update!

[SteveF]

This is excellent work, guys - really exciting to see it coming to life!

Ken - I will have a think and post again if I come up with anything, but to reply quickly to your post, I suspect the issue lies around the use of software vs hardware scrolling. Perhaps not the best terms but they're what I went with:

• Software scrolling uses a text window to scroll the main part of the screen while leaving the status line in place. This looks nicer, but it can be slow as the OS has to do a big block move of screen memory to shift the text window. Mode 7 is fast enough that software scrolling isn't significantly slow, so we always use software scrolling in mode 7.
• Hardware scrolling scrolls the screen without using a text window, so the OS can just adjust the screen start address in the CRTC to scroll. This means that whatever was on line 1 of the screen now appears on line 0, so we manually redraw the status line over the top of it after the OS has done the full-screen scroll. This means the status line is a bit flickery, but the scrolling is much faster. This is used by default in modes 0-6.

You can press CTRL-S to toggle hardware/software scrolling in modes 0-6, so one way to test if this is the problem would be to see if pressing CTRL-S ASAP during play fixes the problems shown in your screenshots in modes 0-6.

Edit: FWIW, the type of scrolling to use is controlled by use_hw_scroll, if this helps find any relevant code.

[KenLowe]

...and Hollywood Hijinx is also working! Even the page scrolling is working.

Hollywood Hijinx

Note that the position of SCORE may need to come left a little bit.

[SteveF]

You probably already found it, but I think searching for sl_score_pos in the code will allow you to tweak the score position.

[KenLowe]

You can press CTRL-S to toggle hardware/software scrolling in modes 0-6, so one way to test if this is the problem would be to see if pressing CTRL-S ASAP during play fixes the problems shown in your screenshots in modes 0-6.

Yes, that worked, but it's a bit irrelevant now that hoglets implemented the necessary OSBYTE calls (A0 in this case).

I think searching for sl_score_pos in the code will allow you to tweak the score position.

Ok, I've located that in screen.asm, so that should be an easy tweak! I'll try changing it from 25 to 20.

Code: Select all

!ifdef TARGET_MEGA65 {
sl_score_pos !byte 54
sl_moves_pos !byte 67
sl_time_pos !byte 64
} else {
sl_score_pos !byte 25

[hoglet]

And here's it running with the VGA80 mode:

There were a few bugs in the VGA80 driver than needed fixing, particularly VDU 17 was not interpreting the colour in the same way as the Beeb does.

Dave

[KenLowe]

Ooooh, Very impressive !

Now I really do need to get my Atom VGA adaptor built! I think I'm finished with the design. I'm just waiting for Chinese New Year holidays to finish - the 'cheap' JLC PCB build service is suspended until 29th Jan .

[KenLowe]

FWIW another option would be to build Hollywood Hijinx in benchmark mode, which disables pause-on-scrolling to let the benchmark run through the whole game automatically.

Hmmm...

Code: Select all

C:\Ozmoo\ozmoo-acorn>python make-acorn.py --no-tube-cache --no-history --osrdch -p --force-6502 --title "Hollywood Hijinx" --benchmark ..\downloads\Hollywood_Hijinx.z3 ..\Disk_Images\AtoMMC_Images\HH-Benchmark.ssd
acme --cpu 6502 --format plain --setpc $700 -DACORN=1 -DACORN_CURSOR_PASS_THROUGH=1 -DSTACK_PAGES=4 -DSMALLBLOCK=1 -DSPLASHWAIT=0 -DACORN_HW_SCROLL=1 -DACORN_INITIAL_NONSTORED_PAGES=48 -DACORN_DYNAMIC_SIZE_BYTES=12142 -DACORN_GAME_PAGES=430 -DACORN_LOADER_HIGHLIGHT_FG=131 -DACORN_CURSOR_EDIT_READ=1 -DBENCHMARK=1 -DDEBUG=1 -DACORN_OSRDCH=1 -DACORN_SHOW_RUNTIME_INFO=1 -DZ3=1 -DMODE_7_STATUS=1 -DMODE_7_INPUT=1 -DVMEM=1 -DACORN_VMEM_BLOCKS=191 -l ..\temp\acme_labels_ozmoo_tube_700 -r ..\temp\acme_report_ozmoo_tube_700 --outfile ..\temp\ozmoo_tube_700 ozmoo.asm
Error - File acorn-ozmoo-constants.asm, line 159 (Zone <untitled>): Value not defined (max_vmap_max_size).
Serious error - File acorn-ozmoo-constants.asm, line 159 (Zone <untitled>): Value not defined.

acme failed

C:\Ozmoo\ozmoo-acorn>

[hoglet]

Error - File acorn-ozmoo-constants.asm, line 159 (Zone <untitled>): Value not defined (max_vmap_max_size).
Serious error - File acorn-ozmoo-constants.asm, line 159 (Zone <untitled>): Value not defined.

It's the -force-6502 option that is causing this.

Dave

[hoglet]

I was able to run the Hollywood Benchmark, albeit rather slowly!

Dave

[KenLowe]

It's the -force-6502 option that is causing this.

That was a result of this discussion:

viewtopic.php?p=314061#p314061

I'm pretty sure it previously worked, before we added those extra options for the Atom build, though.

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

Zork1

I'm not sure why it's complaining about screen size.

[SteveF]

I can't believe the rate of progress here! It's looking good.

I've pushed a (very lightly tested) fix to the acorn-11.x branch for the problem Ken found. I don't plan on producing a new stable release just to incorporate this fix; in practice it's not likely to cause anyone problems and in particular it won't result in a bad build of a game - the worst that will happen is the build will fail and tweaks will be needed.

I think --force-6502 is only indirectly the cause; the real problem is that --force-6502 implies --no-turbo, and --no-turbo had a bug where it tried to use story_start "too early".

[SteveF]

I'm not sure why it's complaining about screen size.

I don't know if this is an (Acorn) Ozmoo bug, a glitch in the Atom port or a "real" behaviour on the part of Zork, but would it maybe be worth trying the Z1 version of Zork? It might be less demanding on hardware capabilities.

[KenLowe]

I'm not sure why it's complaining about screen size.

I don't know if this is an (Acorn) Ozmoo bug, a glitch in the Atom port or a "real" behaviour on the part of Zork, but would it maybe be worth trying the Z1 version of Zork? It might be less demanding on hardware capabilities.

Indeed. That was the zork1-invclues-r52-s871125.z5 version that I had built.

Unfortunately, it takes me quite a lot time to get all the files prepared for the Atom. It would be easier if the OZMOO2P executable was portable, because I need to extract that from each disk image, and then add a special AtoMMC header to it, and that all takes a bit of time. I'm then manually creating a special loader for each game. We could do with a script to help us here!

[KenLowe]

Right, Here's a z3 version of Zork, with SCORE shifted left a little bit. I think it still needs to come back a bit further:

Zork 1 - z3 version

Zork 1 - with SCORE text repositioned

Who would have thought we'd have Zork running on an Atom, BITD! Ok, I know we've had the Infocom games running on Atom via CP/M, but this is much better than that!

Next up needs to be getting it running on the Atom directly, but I suspect that's going to be well beyond my capabilities!

[hoglet]

Next up needs to be getting it running on the Atom directly, but I suspect that's going to be well beyond my capabilities!

I'm a bit confused by this comment - the above screen shots look like you have it running directly on the Atom. Or is this some cunning use of emulation?

[KenLowe]

Next up needs to be getting it running on the Atom directly, but I suspect that's going to be well beyond my capabilities!

I'm a bit confused by this comment - the above screen shots look like you have it running directly on the Atom. Or is this some cunning use of Emulation?

Sorry, I meant without the Co-Pro. Just picking up on your comment here...

viewtopic.php?p=381490#p381490

[hoglet]

Sorry, I meant without the Co-Pro. Just picking up on your comment here...

Ah right, understood.

I imagine that will be much more of a challenge.

[KenLowe]

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?

[KenLowe]

One more question about Ozmoo for the Atom...

Some games (eg HHGTTG) are too large to fit onto a single sided disk and the DATA file needs to span both sides of the disk. How does OZMOO deal with this? On the Atom, I assume we'd need to mount the second side as a separate disk image and then, somehow from the OZMOO2P code, be able to switch between the two images.

This isn't an issue with ADFS / Econet, since the DATA file isn't split on those systems.

Edit 1: Actually, I see there's a bit of discussion about .SSD / DSD images here:

viewtopic.php?p=134835#p134835

So, possibly these will just work. I'll give it a try...

Edit 2: Other than Beyond Zork, all the DSD games that I've got are actually z5 'invclues' based games, and they all give me the 'Screen Too Narrow' error, so I can't fully test them. However, the data file does seem to load successfully, before giving me the error, so hopefully these DSD disks are working just fine. It would interesting to see if they work on the VGA80 setup.