PunyInform and Ozmoo

bbc/electron apps, languages, utils, educational progs, demos + more
Post Reply
User avatar
Dave Footitt
Posts: 930
Joined: Thu Jun 22, 2006 10:31 am
Location: Abandoned Uranium Workings
Contact:

Re: PunyInform and Ozmoo

Post by Dave Footitt » Tue Aug 11, 2020 11:06 pm

Fantastic work Steve great achievement =D> =D> =D>

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

Re: PunyInform and Ozmoo

Post by KenLowe » Tue Aug 11, 2020 11:14 pm

KenLowe wrote:
Tue Aug 11, 2020 10:26 pm
SteveF wrote:
Tue Aug 11, 2020 10:20 pm
I hadn't read the Integra-B manual (but I will, if you have a link) but the BeebEm Integra-B is using OSMODE 4 and that hangs too, so I guess at least that's consistent. Do you have any ideas? Except for switching RAM banks using &FE30, the "shadow RAM" version of Ozmoo being used here doesn't do anything deliberately iffy, it uses the OS for just about everything. What seems really odd is it hangs even before it gets to the prompt asking you which mode to use, and this is pure BASIC code in LOADER, no machine code shenanigans going on.
Copy of the manual can be downloaded from here:

viewtopic.php?p=283216

I'll have a look at the loader to see if I can work out why it's hanging.
Edit: Ok. It's failing at line 45. Something to do with relocation. I've not tried to work out what it's trying to do yet.
Right, something weird happening in the function. It's as if there are too many lines in FNrelocate-to. Remove a couple of the lines with REM, and it gets a bit further. It now asks me what mode I want, but then fails with 'Mistake at line 155' error after I select a mode.
Last edited by KenLowe on Tue Aug 11, 2020 11:18 pm, edited 1 time in total.

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

Re: PunyInform and Ozmoo

Post by SteveF » Tue Aug 11, 2020 11:18 pm

Cheers, I'll take a look at the manual later - I'll tinker with the RAM detection first.

All line 45 is doing is calling a function which returns PAGE, divides it by 256 to get the high byte and pokes it into &408. This is information which the OZMOOSH executable will use to relocate itself after it's loaded, but there is no relocation happening at this point. &408 is part of the BASIC resident integer variable storage so I think this should be harmless as far as the running program is concerned.

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

Re: PunyInform and Ozmoo

Post by SteveF » Tue Aug 11, 2020 11:19 pm

We seem to be overlapping each other. :-) This is just off the top of my head and I don't pretend to understand what's going on - but I note that TOP is &310F, i.e. "overlapping" the top 20K of main RAM. Could there be some weird paging going on which is corrupting the program?

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

Re: PunyInform and Ozmoo

Post by SteveF » Tue Aug 11, 2020 11:21 pm

Bearing in mind I haven't read the manual yet, on BeebEm with Integra-B in OSMODE 4 if I simply do:

Code: Select all

LOAD "LOADER"
MODE 128
LIST
I get a "Bad program" error.

Edit: and if I insert "MODE 135" in !BOOT just before 'CHAIN "LOADER"' it works. I don't understand why this is necessary though.
Last edited by SteveF on Tue Aug 11, 2020 11:23 pm, edited 1 time in total.

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

Re: PunyInform and Ozmoo

Post by KenLowe » Tue Aug 11, 2020 11:22 pm

SteveF wrote:
Tue Aug 11, 2020 11:19 pm
We seem to be overlapping each other. :-) This is just off the top of my head and I don't pretend to understand what's going on - but I note that TOP is &310F, i.e. "overlapping" the top 20K of main RAM. Could there be some weird paging going on which is corrupting the program?
Perhaps. When it hangs, if I press Break and then type OLD, I get Bad Program error. However, if I then Ctrl-Break and type OLD, the program re-appears (uncorrupt).

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

Re: PunyInform and Ozmoo

Post by KenLowe » Tue Aug 11, 2020 11:31 pm

SteveF wrote:
Tue Aug 11, 2020 11:21 pm
Bearing in mind I haven't read the manual yet, on BeebEm with Integra-B in OSMODE 4 if I simply do:

Code: Select all

LOAD "LOADER"
MODE 128
LIST
I get a "Bad program" error.

Edit: and if I insert "MODE 135" in !BOOT just before 'CHAIN "LOADER"' it works. I don't understand why this is necessary though.
I get the same 'Bad program' on the real hardware. Similarly, if I switch to MODE128 before running loader it works. If I type:

Code: Select all

LOAD "LOADER"
MODE 0
I get a Bad Mode error, so the code is obviously going into Screen RAM territory. For some reason the switch to shadow mode 0 is being allowed, but is corrupting the RAM.

Edit: I see you've noted the same with TOP.

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

Re: PunyInform and Ozmoo

Post by SteveF » Wed Aug 12, 2020 1:16 am

Right, I've been having a play with the sideways RAM detection. I don't have it cracked yet, but I am getting there. I am seeing some odd behaviour on BeebEm's Integra-B emulation and I am wondering if real hardware does the same.

Ken - can you please try the attached bootable disc image on real hardware, with RAM in bank 4 and bank 0 unpopulated? I'm interested in the character it outputs just before the ">" prompt at the end. I think it should output "B" - and it does on a Master 128 - but on BeebEm Integra-B it outputs "A".

Here's the code for ease of reference:

Code: Select all

   10FOR opt%=0 TO 3 STEP 3
   20P%=&900
   30[OPT opt%
   40LDA &F4
   50PHA
   60LDA #4
   70JSR select
   80LDA #66
   90STA &8008
  101\ JMP skip
  110LDA #0
  120JSR select
  130LDA #65
  140STA &8008
  150.skip
  160LDA #4
  170JSR select
  180LDA &8008
  190JSR &FFEE
  200PLA
  210JMP select
  220.select
  230STA &F4
  240STA &FE30
  250RTS
  260]
  270NEXT
  280CALL &900
This selects bank 4, stores 66 ("B") at &8008, selects bank 0, stores 65 ("A") at &8008, re-selects bank 4 and prints the character at &8008, which I think should be "B".

On BeebEm at least, writing to bank 0 - which is set as empty in the ROM config - seems to write to bank 4, probably (but this is a guess) because it was the last "real" bank selected. I don't *think* this is the behaviour we would see if the bank selection were not fully decoded and banks 0 and 4 were really the same bank, because if I do "*SRSAVE FOO 8000 8010 0" and then *DUMP FOO, I don't see "A" or "B" at &8008.

Edit: Looking at the BeebEm source, this behaviour seems very deliberate - there's a call to RomWriteThrough() in https://github.com/stardot/beebem-windo ... eebmem.cpp which redirects writes to the lowest writable bank. It would still be good to confirm this behaviour on real hardware - I can't see anything about it in the Integra-B manual, though I haven't read it cover-to-cover - before I try thinking of a way to not have this upset the detection code.
Attachments
integra-b-test.zip
(477 Bytes) Downloaded 13 times
Last edited by SteveF on Wed Aug 12, 2020 3:27 am, edited 2 times in total.

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

Re: PunyInform and Ozmoo

Post by SteveF » Wed Aug 12, 2020 1:28 am

I've pushed a new alpha 1.1 tag to github which has a) a "MODE 135" added to !BOOT to fix the Integra-B OSMODE 4 problem (I'd still like to understand why this is necessary, but in practice it does seem to fix things anyway) b) the new sideways RAM detection code. On BeebEm Integra-B the new sideways RAM detection code does not work reliably, but the old code didn't work reliably on real Integra-B hardware anyway so this is no worse, and I cherish a faint hope the strange behaviour I'm seeing is a BeebEm bug. On other hardware the new sideways RAM detection code should be much better, and shouldn't get confused by a partially-decoded bank select on a model B - please let me know if you try this and it works/doesn't work.

The new tag is stardot-ozmoo-preview-2020-08-12-alpha-1.1, you can use the instructions in the earlier post with this tag to get this version of the code.

The new sideways RAM detection works by:
  • First iterating over all 16 banks; any which don't have a service or language entry get 256 bytes of data written to them at &81xx. This data is a copy of some data in main RAM, EORed with the RAM bank number so it's different for each bank.
  • Then iterating over all 16 banks a second time, checking any which don't have a service or language entry to see if the 256 bytes of data at &81xx look like they should for that bank. In a further effort to avoid buffering/ghosting/capacitance/hardware goblin issues, the comparison is done like this:

    Code: Select all

    TYA ; get bank number in A
    EOR main_ram_data,X ; re-calculate the value we stored on the first pass
    CMP &8100,X ; check it against the potential RAM bank
    
    My hope is that because the value we're comparing with was generated internally in the CPU by the EOR operation, it will not be floating around in some hardware attached to the data bus by chance and cause false positives.
If the ROM bank selection is not fully decoded, some of the writes in the first pass will overwrite others, but that's fine because the data is different in each bank and on the second pass only one of those duplicated banks will pass the data check and be identified as a RAM bank. I haven't tested this - do any emulators implement partially-decoded bank selection? - but I think it should work.

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

Re: PunyInform and Ozmoo

Post by KenLowe » Wed Aug 12, 2020 6:28 am

SteveF wrote:
Wed Aug 12, 2020 1:16 am
Ken - can you please try the attached bootable disc image on real hardware, with RAM in bank 4 and bank 0 unpopulated? I'm interested in the character it outputs just before the ">" prompt at the end. I think it should output "B" - and it does on a Master 128 - but on BeebEm Integra-B it outputs "A".
It outputs 'B' on real hardware. On the IntegraB, selecting banks 0 thru 3 selects the 4 ROM slots on the main beeb motherboard, so these will always be ROMs (unless the slots have been modified to accept RAM). There's nothing special about the ROM selection on IntegraB board. It latches the lowest 4 bits of the databus when the address is &FE30, and puts these bits through a 4 to 16 line decoder.
SteveF wrote:
Wed Aug 12, 2020 1:16 am
Looking at the BeebEm source, this behaviour seems very deliberate - there's a call to RomWriteThrough() in https://github.com/stardot/beebem-windo ... eebmem.cpp which redirects writes to the lowest writable bank. It would still be good to confirm this behaviour on real hardware - I can't see anything about it in the Integra-B manual, though I haven't read it cover-to-cover - before I try thinking of a way to not have this upset the detection code.
I've just tested on BeebEm, and I'm seeing the same behaviour. Yuk. It should definitely NOT be doing that! That needs to be fixed in BeebEm. Just tested with B-Em, and once set up correctly it's not exhibiting that behaviour.
SteveF wrote:
Wed Aug 12, 2020 1:28 am
The new sideways RAM detection works by:
  • First iterating over all 16 banks; any which don't have a service or language entry get 256 bytes of data written to them at &81xx. This data is a copy of some data in main RAM, EORed with the RAM bank number so it's different for each bank.
  • Then iterating over all 16 banks a second time, checking any which don't have a service or language entry to see if the 256 bytes of data at &81xx look like they should for that bank. In a further effort to avoid buffering/ghosting/capacitance/hardware goblin issues, the comparison is done like this:

    Code: Select all

    TYA ; get bank number in A
    EOR main_ram_data,X ; re-calculate the value we stored on the first pass
    CMP &8100,X ; check it against the potential RAM bank
    
    My hope is that because the value we're comparing with was generated internally in the CPU by the EOR operation, it will not be floating around in some hardware attached to the data bus by chance and cause false positives.
If the ROM bank selection is not fully decoded, some of the writes in the first pass will overwrite others, but that's fine because the data is different in each bank and on the second pass only one of those duplicated banks will pass the data check and be identified as a RAM bank. I haven't tested this - do any emulators implement partially-decoded bank selection? - but I think it should work.
Yup. That's working much better on my real hardware. Empty slots are no longer being identified as RAM.

This is an excellent bit of software =D> =D> =D>. I now have Zork running 80 column (mode 0) in a beeb with shadow / sideways RAM, and 40 column (mode 7) in a beeb with just sideways RAM. I have been waiting soooo long for this!

Here's a screen capture of Zork1 running on my beeb, using shadow & SW RAM on my IntegraB:
capture29.png
Zork 1 running in Mode 0 on my IntegraB beeb

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

Re: PunyInform and Ozmoo

Post by SteveF » Wed Aug 12, 2020 11:53 am

Thanks Ken, both for trying that out and your kind words! I've raised https://github.com/stardot/beebem-windows/issues/63 for this BeebEm problem if you want to chip in with any advice as you obviously know this hardware pretty well.

I think I am going to have another go at tweaking the sideways RAM detection anyway, because even if the Integra-B doesn't do this, I have now remembered some ROM boards BITD used to have a single 16K RAM bank with all other banks as ROM, and all writes to &8000-&C000 were directed to that single 16K RAM bank. This had the advantage you could load ROM images into sideways RAM with a simple *LOAD THEROM 8000. I believe the alpha 1.1 sideways RAM detection code would fail to find such a board unless the RAM happened to be readable as bank 0, because it would behave very much like the BeebEm Integra-B. I will keep the "check with 256 bytes and use EOR" code which should hopefully avoid reintroducing any false positives. Edit: Then again, on hardware which behaves like that, if the user has loaded a sideways ROM - perhaps MMFS, for example - into the 16K RAM bank, I am going to scribble all over it and crash the machine by writing to &81xx in a "different" bank during the sideways RAM detection. So maybe I need to go back to just modifying &8008 (the binary version number) for an initial detection pass and then do this more comprehensive check afterwards. I'll mull it over for a bit.

(If my memories are faulty and this style of sideways RAM was never a thing, I hope someone will tell me. But I'm reasonably confident I didn't just imagine this.)
Last edited by SteveF on Wed Aug 12, 2020 12:05 pm, edited 1 time in total.

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

Re: PunyInform and Ozmoo

Post by lurkio » Wed Aug 12, 2020 11:58 am

SteveF wrote:
Wed Aug 12, 2020 11:53 am
I think I am going to have amother go at tweaking ...
Great work, Steve! =D> =D> =D>

I was going to try Ozmoo on a real Model B with an IFEL/Picton SWRAM/ROM board, later today. Which version of the software should I use to test with? Or should I wait for another update?

:?:

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

Re: PunyInform and Ozmoo

Post by SteveF » Wed Aug 12, 2020 12:11 pm

lurkio wrote:
Wed Aug 12, 2020 11:58 am
SteveF wrote:
Wed Aug 12, 2020 11:53 am
I think I am going to have amother go at tweaking ...
Great work, Steve! =D> =D> =D>

I was going to try Ozmoo on a real Model B with an IFEL/Picton SWRAM/ROM board, later today. Which version of the software should I use to test with? Or should I wait for another update?
Thanks Lurkio! It's great to have this tested on real hardware, there's a lot more to this sideways RAM detection business than I had realised. I had a quick search on the forum and couldn't find any precise details on that hardware, so I am guessing, but:
  • If you're only going to try this once, please wait until I've come up with my final whizz-bang sideways RAM detection code.
  • If you're keen, alpha 1.1 will *probably* work best.
If the machine has >16K of sideways RAM it probably won't exhibit the "all writes go to the same bank" behaviour which my current code doesn't like anyway.

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

Re: PunyInform and Ozmoo

Post by KenLowe » Wed Aug 12, 2020 1:23 pm

SteveF wrote:
Wed Aug 12, 2020 11:53 am
I think I am going to have another go at tweaking the sideways RAM detection anyway, because even if the Integra-B doesn't do this, I have now remembered some ROM boards BITD used to have a single 16K RAM bank with all other banks as ROM, and all writes to &8000-&C000 were directed to that single 16K RAM bank. This had the advantage you could load ROM images into sideways RAM with a simple *LOAD THEROM 8000. I believe the alpha 1.1 sideways RAM detection code would fail to find such a board unless the RAM happened to be readable as bank 0, because it would behave very much like the BeebEm Integra-B. I will keep the "check with 256 bytes and use EOR" code which should hopefully avoid reintroducing any false positives. Edit: Then again, on hardware which behaves like that, if the user has loaded a sideways ROM - perhaps MMFS, for example - into the 16K RAM bank, I am going to scribble all over it and crash the machine by writing to &81xx in a "different" bank during the sideways RAM detection. So maybe I need to go back to just modifying &8008 (the binary version number) for an initial detection pass and then do this more comprehensive check afterwards. I'll mull it over for a bit.

(If my memories are faulty and this style of sideways RAM was never a thing, I hope someone will tell me. But I'm reasonably confident I didn't just imagine this.)
No. Your memory is spot on:

viewtopic.php?f=3&t=2312&p=16642&#p16642

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

Re: PunyInform and Ozmoo

Post by SteveF » Wed Aug 12, 2020 7:20 pm

Thanks Ken. There was a link in one of the threads you posted to Wouter Scholten's sideways RAM detection code (http://wouter.bbcmicro.net/bbc/software-whs.html), which looks like it already handles all these complexities and more. He's given me the OK to use it (thanks again Wouter!), so I've pushed a new tag stardot-ozmoo-preview-2020-08-12-alpha-1.2 with this code instead of my own sideways RAM detection. This works for me on all the emulators I've tried, including BeebEm's slightly flawed Integra-B emulation.

(Wouter's code can detect more forms of sideways RAM than Ozmoo currently supports; if anyone has Solidisk/Watford sideways RAM and is willing to act as a guinea pig I am happy to try to add support for these.)

Please try this on real hardware if you have it and let me know if it does/doesn't work. :-)

chrisn
Posts: 650
Joined: Sat Apr 19, 2014 12:31 pm
Location: UK
Contact:

Re: PunyInform and Ozmoo

Post by chrisn » Wed Aug 12, 2020 8:38 pm

Thanks Steve for reporting the BeebEm issue. I've just pushed a change in GitHub to fix this, which will go into the next BeebEm beta release.

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

Re: PunyInform and Ozmoo

Post by SteveF » Wed Aug 12, 2020 8:41 pm

Thanks, that's great (and really fast too)!

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

Re: PunyInform and Ozmoo

Post by lurkio » Wed Aug 12, 2020 9:14 pm

SteveF wrote:
Wed Aug 12, 2020 7:20 pm
I've pushed a new tag stardot-ozmoo-preview-2020-08-12-alpha-1.2
Just tried this on a real Master 128 with SWRAM in banks 4-7, with the game running on a DataCentre -- it didn't work at first but then I did a *DTRAP, which makes the DataCentre masquerade as a real disc-drive somehow, and then it all worked perfectly! Shadow RAM was detected too.

The initial stage of the Z3 game (Hitchhiker's, naturally) is very fast because the disc doesn't seem to get accessed -- although, thinking about it, I'm not entirely sure if that's true because the DataCentre is very fast, so I might not have noticed even if it was accessed. Hmm. I might try transferring the disc-image to a real floppy later...

Anyway, this is fantastic. Really well done, Steve! =D> =D> =D>

I'll update this post when I've got it running on a real Model B with SWRAM...

:idea:

Btw, here's the disc-image I'm using -- I'm hoping I correctly checked out alpha1.2:

hhgg.ssd
(157.5 KiB) Downloaded 14 times

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

Re: PunyInform and Ozmoo

Post by SteveF » Wed Aug 12, 2020 9:51 pm

Thanks lurkio! That's definitely a 1.2 build, I can see the new sideways RAM detection code in the loader.

I've had a quick look at the Datacentre manual and yes, given Ozmoo uses OSWORD &7F to read the game data from the disc I am not surprised it needs *DTRAP to work on the Datacentre. I'm glad it works!

I look forward to hearing how it copes on your model B too...

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

Re: PunyInform and Ozmoo

Post by lurkio » Wed Aug 12, 2020 10:17 pm

SteveF wrote:
Wed Aug 12, 2020 9:51 pm
I look forward to hearing how it copes on your model B too...
Just ran it on a real Model B without any Shadow RAM but with an IFEL/Picton SWRAM/ROM board, with various ROM images loaded into the Flash ROM slots and also into two of the SWRAM slots (0 and 1), I think. Your code detected SWRAM in slots 4, 5, 8, 9, 12 and 13:

PHOTO-2018-12-27-18-46-46.jpg

After the SWRAM-detection and the pre-loading from a real floppy drive, the game ran and worked perfectly. The relocated screen looked indistinguishable from a normal MODE7 screen!

=D> =D> =D>

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

Re: PunyInform and Ozmoo

Post by SteveF » Wed Aug 12, 2020 11:13 pm

Thanks again lurkio, that's reassuring - if you had ROM images loaded into SWR banks 0 and 1 they would not be picked up by Ozmoo. It's also good to hear the relocated mode 7 screen is working fine, obviously I know it should work but emulation is one thing and the real hardware is another!

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

Re: PunyInform and Ozmoo

Post by KenLowe » Thu Aug 13, 2020 12:32 am

Just tried Alpha-1.2, but ran into an error with the build function on one of the .z5 files. Looks like I need to create a double sided disk, but when I try that I then get another error:

Code: Select all

C:\Users\me\Desktop\Ozmoo>python make-acorn.py zork1.z3

C:\Users\me\Desktop\Ozmoo>python make-acorn.py zork2.z3

C:\Users\me\Desktop\Ozmoo>python make-acorn.py zork3.z3

C:\Users\me\Desktop\Ozmoo>python make-acorn.py hhgg.z3

C:\Users\me\Desktop\Ozmoo>python make-acorn.py leather.z3

C:\Users\me\Desktop\Ozmoo>python make-acorn.py hitchhik.z5
Traceback (most recent call last):
  File "make-acorn.py", line 464, in <module>
    ssd.add_file("$", "DATA", 0, 0, game_data)
  File "make-acorn.py", line 274, in add_file
    self.add_to_catalogue(directory, name, load_addr, exec_addr, len(data), self.first_free_sector())
  File "make-acorn.py", line 254, in add_to_catalogue
    raise DiscFull()
TypeError: exceptions must derive from BaseException

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "make-acorn.py", line 465, in <module>
    except DiscFull:
TypeError: catching classes that do not inherit from BaseException is not allowed

C:\Users\me\Desktop\Ozmoo>python make-acorn.py -2 hitchhik.z5
Traceback (most recent call last):
  File "make-acorn.py", line 473, in <module>
    data[(i % 20) / 10].extend(game_data[i*256:i*256+10*256])
TypeError: list indices must be integers or slices, not float

C:\Users\me\Desktop\Ozmoo>
The .z3 files complied without any errors. I tried one of these on a Standard beeb with SWRAM in banks 4 & 5 (actually my beeb with IntegraB in OSMODE 0). Both SWRAM banks were detected correctly, and no ghost banks detected. Game loaded in mode 7 and ran without issue. I then tried it on a beeb with IntegraB in OSMODE 4. Shadow RAM and SWRAM banks 4 & 5 were all correctly detected, and again no ghost banks detected. Game loaded in mode 0 and ran without issue. Finally I tested with a second processor. Second processor was detected and game loaded in mode 0 and ran without issue.

Other than the .z5 issue, everything else worked fine.

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

Re: PunyInform and Ozmoo

Post by SteveF » Thu Aug 13, 2020 2:21 am

Thanks for testing all that Ken, much appreciated - and reassuring too!

I suspect the only reason a double-sided disc is needed here is that the LOADER code is currently rather bloated and things would otherwise squeeze onto a single-sided disc. I've made a note to look into that. In the meantime, I've created stardot-ozmoo-preview-2020-08-13-alpha-1.3 which should have a fix for the problems you've reported - you should now be able to build this double-sided disc.

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

Re: PunyInform and Ozmoo

Post by SteveF » Thu Aug 13, 2020 3:16 am

Incidentally, does anyone know of a game which uses the cursor keys? In theory Acorn Ozmoo supports these, but I haven't had any means of testing this...

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

Re: PunyInform and Ozmoo

Post by KenLowe » Thu Aug 13, 2020 7:04 am

SteveF wrote:
Thu Aug 13, 2020 2:21 am
I've created stardot-ozmoo-preview-2020-08-13-alpha-1.3 which should have a fix for the problems you've reported - you should now be able to build this double-sided disc.
That seems to have fixed it, and everything else I've tested is still working. Thank you.
SteveF wrote:
Thu Aug 13, 2020 3:16 am
Incidentally, does anyone know of a game which uses the cursor keys? In theory Acorn Ozmoo supports these, but I haven't had any means of testing this...
Unfortunately I don't know of any.

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

Re: PunyInform and Ozmoo

Post by lurkio » Thu Aug 13, 2020 11:10 am

SteveF wrote:
Thu Aug 13, 2020 3:16 am
Incidentally, does anyone know of a game which uses the cursor keys? In theory Acorn Ozmoo supports these, but I haven't had any means of testing this...
Curses by Graham Nelson uses the Up and Down cursor keys in the HELP menu system. Here it is, hopefully built with alpha1.3:

Acorn Ozmoo seems to handle the cursoring well. (Btw, because Curses is a Z5 game with a multi-line status-bar, it doesn't display very well in MODE7! Not a surprise. Not complaining, btw. Just an observation.)

Btw, is there any way to package a game with Acorn Ozmoo and predetermine the screen mode, so the user doesn't have to manually type in the mode number before the game loads? I'm thinking it would be nice to make such a build available behind the Play button on bbcmicro.co.uk -- with a separate "standard" build of the same hypothetical game (on a different disc-image) behind the Download button -- basically just so that the user experience can be forced into MODE7 for the sake of improving command-response times in JSBeeb on bbcmicro.co.uk (and also because I just like MODE7!).

:?:

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

Re: PunyInform and Ozmoo

Post by SteveF » Thu Aug 13, 2020 12:27 pm

KenLowe wrote:
Thu Aug 13, 2020 7:04 am
That seems to have fixed it, and everything else I've tested is still working. Thank you.
Great, thanks!
lurkio wrote:
Thu Aug 13, 2020 11:10 am
SteveF wrote:
Thu Aug 13, 2020 3:16 am
Incidentally, does anyone know of a game which uses the cursor keys? In theory Acorn Ozmoo supports these, but I haven't had any means of testing this...
Curses by Graham Nelson uses the Up and Down cursor keys in the HELP menu system. Here it is, hopefully built with alpha1.3:
  • curses.dsd

Acorn Ozmoo seems to handle the cursoring well. (Btw, because Curses is a Z5 game with a multi-line status-bar, it doesn't display very well in MODE7! Not a surprise. Not complaining, btw. Just an observation.)
Great, thanks for finding this, it's good to know the cursor keys work!

You're right about it not displaying very well. It doesn't really seem to like 40x25, as it looks almost as bad in mode 6. That's a good thing in a way, as it suggests there's no problem with the mild hacks to colourise the mode 7 status bar.
lurkio wrote:
Thu Aug 13, 2020 11:10 am
Btw, is there any way to package a game with Acorn Ozmoo and predetermine the screen mode, so the user doesn't have to manually type in the mode number before the game loads? I'm thinking it would be nice to make such a build available behind the Play button on bbcmicro.co.uk -- with a separate "standard" build of the same hypothetical game (on a different disc-image) behind the Download button -- basically just so that the user experience can be forced into MODE7 for the sake of improving command-response times in JSBeeb on bbcmicro.co.uk (and also because I just like MODE7!).
The short answer is that right now a) if you configure it to run on a model B with no shadow RAM, it will be forced to use mode 7 :-) b) there's otherwise no way to force this completely automatically, but you can just edit the BASIC LOADER program to remove the choice of mode and save it back to the disc.

However, your question gives me a chance to ramble about some thoughts I've had in this area. At the moment the loader is functional but unfriendly. I could imagine someone playing around on bbcmicro.co.uk without much knowledge of the Beeb launching the game, thinking "What's a screen mode? What do I choose? This looks rubbish!". What I would like to do at some point (and I'd welcome thoughts/suggestions on this) is:
  • Allow the make-acorn.py script to optionally take a filename to a partial mode 7 screen. This would be displayed automatically as a banner at the top of the loader screen, while leaving the bottom half-ish free for the loader to show information and interact with the user. Some sort of sensible and hopefully not too ugly default would be provided by default (e.g. the game title in mode 7 double height in a coloured banner with a box round it), but the idea here is that if (say) we wanted to put together a "professional-looking" release of Dave's "Calypso", someone with the necessary artistic skills would design a custom mode 7 banner for that game, rather than it having a generic one and looking like every other Ozmoo-using game.
  • In the bottom half of the screen the loader would show the second processor/shadow RAM/sideways RAM situation (for support purposes) in as friendly/compact a way as possible.
  • The loader would show a little menu of available screen modes (if the hardware doesn't only support mode 7) showing the text resolution and maybe some brief hint as to the difference between mode 7 and other modes. Rather than making the user choose explicitly, this might default to mode 7 but allow the user to change it by pressing (say) "0" for mode 0 if they wish.
  • The loader would also mention the ability to press CTRL-F/CTRL-B/CTRL-S at the game prompt.
  • At the bottom it would say something like "Press SPACE to start."
This is just a sketch to get the basic idea across; I'm not dead set on any specific aspect of this screen design or UI.

If we had something like this, would you still want to force the game into mode 7 regardless of the hardware capabilities for jsbeeb? I do find jsbeeb a bit sluggish, but I always put that down to my hardware being old and my web browser always creaking under the weight of open tabs. Is the responsiveness that much better on jsbeeb in mode 7 even on decent hardware? I'm not averse to adding a "force mode 7" option if it's really going to help.

Edited to add: Here's a mockup in edit.tf, showing mode 4 currently selected. Tweaks or complete redesigns welcome!

I am thinking there's maybe no need to waste a line saying "shadow RAM" detected, as the fact you're being offered a choice of mode implies that. That way the hardware detected would always take a single line ("xxK sideways RAM" or "second processor").

fredrikr
Posts: 28
Joined: Sat Jul 18, 2020 11:20 pm
Contact:

Re: PunyInform and Ozmoo

Post by fredrikr » Thu Aug 13, 2020 2:13 pm

SteveF wrote:
Thu Aug 13, 2020 3:16 am
Incidentally, does anyone know of a game which uses the cursor keys? In theory Acorn Ozmoo supports these, but I haven't had any means of testing this...
For any new interpreter, you should definitely try "Freefall" and "Robot Finds Kitten"...

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

Re: PunyInform and Ozmoo

Post by SteveF » Thu Aug 13, 2020 2:41 pm

fredrikr wrote:
Thu Aug 13, 2020 2:13 pm
SteveF wrote:
Thu Aug 13, 2020 3:16 am
Incidentally, does anyone know of a game which uses the cursor keys? In theory Acorn Ozmoo supports these, but I haven't had any means of testing this...
For any new interpreter, you should definitely try "Freefall" and "Robot Finds Kitten"...
Thanks Fredrik, the cursor keys work fine in "Robot Finds Kitten". They don't work in Freefall (at least not the one in the Ozmoo examples directory), but they don't work on frotz either, so I don't think that's a problem. Freefall works well though (assuming you turn Caps Lock off; it's equally case-sensitive under frotz, it's just that frotz will typically be started with Caps Lock off whereas Acorn machines usually default to Caps Lock on).

fredrikr
Posts: 28
Joined: Sat Jul 18, 2020 11:20 pm
Contact:

Re: PunyInform and Ozmoo

Post by fredrikr » Thu Aug 13, 2020 3:40 pm

SteveF wrote:
Thu Aug 13, 2020 2:41 pm
fredrikr wrote:
Thu Aug 13, 2020 2:13 pm
SteveF wrote:
Thu Aug 13, 2020 3:16 am
Incidentally, does anyone know of a game which uses the cursor keys? In theory Acorn Ozmoo supports these, but I haven't had any means of testing this...
For any new interpreter, you should definitely try "Freefall" and "Robot Finds Kitten"...
Thanks Fredrik, the cursor keys work fine in "Robot Finds Kitten". They don't work in Freefall (at least not the one in the Ozmoo examples directory), but they don't work on frotz either, so I don't think that's a problem. Freefall works well though (assuming you turn Caps Lock off; it's equally case-sensitive under frotz, it's just that frotz will typically be started with Caps Lock off whereas Acorn machines usually default to Caps Lock on).
Oh sorry, Freefall doesn't use the cursor keys, that's right!

Does it run at a good speed?

Post Reply

Return to “8-bit acorn software: other”