PunyInform and Ozmoo

bbc/electron apps, languages, utils, educational progs, demos + more
User avatar
lurkio
Posts: 3527
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: PunyInform and Ozmoo

Post by lurkio »

hoglet wrote:
Tue Mar 23, 2021 5:48 pm
As an aside, I've just tried my Matchbox Co Pro (64MHz, latest firmware) and not hit any issues.
My red Matchbox copro was reprogrammed just once, years ago, when Lee kindly took it to an Abug (or something) for me, and someone whose name I'm ashamed to say I forget worked his magic on it.

But that was ages ago, and I'm sure the firmware's well out of date by now.

Do you think it's outdated firmware that's causing the copro to play havoc with my Master?

How would I find out what version of the firmware is on my copro?

:?:
User avatar
hoglet
Posts: 10169
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: PunyInform and Ozmoo

Post by hoglet »

lurkio wrote:
Tue Mar 23, 2021 6:28 pm
Do you think it's outdated firmware that's causing the copro to play havoc with my Master?
I can't recall any issue with symptoms like this with any of the releases.

Does removing the internal Co Pro have any effect?

Are there any other hardware addons?
lurkio wrote:
Tue Mar 23, 2021 6:28 pm
How would I find out what version of the firmware is on my copro?
There isn't an easy way without a programmer.

You might be able to inferr it from the presence of particular Co Pro, and the numbering.

If you select each Co Pro in turn (using *FX 151,230,N then Ctrl-BREAK) and note which Co Pro you get, I should be able to work it out.

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

Re: PunyInform and Ozmoo

Post by lurkio »

hoglet wrote:
Tue Mar 23, 2021 7:14 pm
I can't recall any issue...
Replied on the copro thread:

viewtopic.php?p=314225#p314225

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

Re: PunyInform and Ozmoo

Post by lurkio »

Removed the internal copro from my Master. Results:

Code: Select all

19.
Machine: as for test 01 but updated to MMFS 1.49 and removed the internal ReCo6502Mini, leaving only the external Matchbox copro in 32MHz mode
stardot-ozmoo-preview-6.0-alpha-15
.SSD
MODE7
start $13e
end $14a2
duration: 1.654666... mins
:)
SteveF
Posts: 959
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

Thanks lurkio, I'm glad you got it working!

Here's an updated set of timings, if I missed anyone's non-buggy times off please let me know.

Code: Select all

Host                            Copro               Time  Notes
  
real M128 96K SWR MMFS          none                328
b-em M128 96K SWR               none                336
real Integra-B 43K SWR SCSI     none                366
real Integra-B 43K SWR Gotek    none                430

b-em B+ 32K SWR                 Acorn 3MHz          208   Some disc access with 32K SWR
b-em M128 96K SWR               Acorn 3MHz          211
real M128 96K SWR MMFS          Acorn 3MHz          212
real Integra-B 32K SWR SCSI     PiTubeDirect 3MHz   222
real Integra-B 32K SWR Gotek    PiTubeDirect 3MHz   256
real Integra-B 32K SWR Gotek    Acorn 3MHz          267   Tube ROM 0.05, R6502AP CPU
real Integra-B 32K SWR Gotek    Acorn 3MHz NMOS     270   Tube ROM 0.05, NMOS 6502

b-em M128 96K SWR               Acorn 4MHz          174
real M128 96K SWR MMFS          ReCo6502Mini 4MHz   180

real M128 96K SWR MMFS          ReCo6502Mini 16MHz  108

real B 80K SWR MMFS             Matchbox 32MHz      92
real M128 96K SWR MMFS          Matchbox 32MHz      99

real Integra-B 32K SWR SCSI     PiTubeDirect fast   110
real Integra-B 32K SWR Gotek    PiTubeDirect fast   138
These are grouped by copro speed and ordered within groups by time. The specs of the host can have a big influence, although with about 64K or more sideways RAM (edit: *and* a copro) the host's filing system performance probably doesn't matter any more as the game fits entirely in RAM.

It's interesting the B is faster than the M128 with the Matchbox 32MHz copro, although the difference isn't huge. I do notice some mild variation from run to run even in as controlled an environment as b-em, so this may even just be random noise. It's also slightly odd b-em's B+ with 32K SWR outperforms a b-em M128 with 96K SWR when both have a 3MHz copro. I don't think this is particularly worth worrying about, but I do wonder if the more complex memory arrangement on the M128 slows things (edit: thinking mainly of OSWRCH here) down very slightly compared to the earlier models - this is just speculation though. (The B+ with 32K SWR would have some disc access during the run whereas the M128 wouldn't, but on b-em running at 500% speed I think disc access is cheap or even free.)

Edit: I should say I'm really pleased with how this has all turned out. We got a bug fixed which was accidentally killing the performance on the ReCo6502Mini and confirmed that running on a copro really does help just as it seemed to for me under b-em. It's also interesting to see Dave's data on the VDU FIFO use, although I guess in real use instead of in the benchmark this isn't such a significant bottleneck because after outputting a paragraph or so the game is going to pause while a human reads the text. Thanks again for all the help!
Last edited by SteveF on Wed Mar 24, 2021 9:17 pm, edited 2 times in total.
User avatar
KenLowe
Posts: 1782
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: PunyInform and Ozmoo

Post by KenLowe »

Power on reset corruption with IntegraB Private RAM has now gone :). Retest with latest Ozmoo gives similar speed results to previous test:

Code: Select all

BBC Model B with IntegraB (OSMODE4)
Shadow RAM
43K sideways RAM (banks &CD+)
1770 DFS 2.26 with Gotek SSD
PAGE &1F00
stardot-ozmoo-preview-6.0-alpha-15 - Mode 7
Start: $00065c
End: $005a69
SteveF
Posts: 959
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

Good news Ken, thanks for testing that! I've updated the time in the post above, although it's only a couple of seconds different.
fredrikr
Posts: 43
Joined: Sat Jul 18, 2020 11:20 pm
Contact:

Re: PunyInform and Ozmoo

Post by fredrikr »

SteveF wrote:
Tue Mar 23, 2021 3:40 pm
a PAL C64 uses 50Hz jiffies
Nope. 60 Hz jiffies.

On a PAL C64 you can get a nice border flicker effekt by briefly changing the border colour and then changing it back again on every Kernal interrupt. Since the interrupt is not in sync with the update frequency of the screen, the flickers will appear "here and there". On an NTSC C64 it's roughly in the same spot all the time, but it slowly moves upwards because it's not perfectly in sync with screen updates.
SteveF
Posts: 959
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

Thanks Fredrik, looks like I got the wrong end of the stick. Fortunately the code was doing the right thing, even if for the wrong reasons - I was multiplying by 5 not 6 in the timed input code. :-)

I've now changed the Acorn port to use 100Hz jiffies internally. This saves nine bytes of runtime code (every little helps!) since I'm no longer doing the divide by 2, and I feel more comfortable with the Ozmoo code now and am pretty sure this won't break anything - when I first wrote this code I didn't want to risk subtle incompatibilities. I've done a sanity check running Freefall against the C64 version in an emulator and it takes roughly five seconds for the first block to hit the bottom on both versions, so the Acorn port isn't running at double speed by accident now.

Using 100Hz jiffies means the timer will wrap around a bit sooner but still far longer than anyone is ever likely to leave Ozmoo running for (1.94 days), and it looks to me as though the timed input code will cope just fine with the timer wrapping round anyway (although I do sometimes get confused with this kind of thing, and I haven't actually gone and tested it).

The only user visible effect of this change is that the numbers reported by the benchmark from the next alpha onwards need to be divided by 100 to give seconds instead of 50.

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

Re: PunyInform and Ozmoo

Post by KenLowe »

BBC Model B with IntegraB (OSMODE4) + Cheese Wedge CoPro with (CMOS?) R6502AP Processor - It looks like I 'upgraded' the processor, when I was trying to understand why the CoPro wouldn't work with most versions of Tube Host Code (it would only work with the host code in NFS 3.34). In the end I upgraded the Tube ROM from v0.01 to v0.05 (see here: viewtopic.php?f=3&t=18602), and that got it working:

Code: Select all

Second Processor (64K)
Shadow RAM
32K sideways RAM (banks &CD)
1770 DFS 2.26 with Gotek SSD
PAGE &800
stardot-ozmoo-preview-6.0-alpha-15 - Mode 7
Start: $000896
End: $003cbd
SteveF wrote:
Mon Mar 22, 2021 7:29 pm
Don't forget the --force-6502 option if you pull out your Acorn copro with the NMOS CPU. :-) (No *need* to do that, a data point for any copro would be interesting, but I didn't want you to get crashes as a result of this, it's a while since we discussed it.)
Good point. I would have completely forgotten about that. Same test as above, but with the CPU swapped out for the original NMOS version, and the --force-6502 option applied (I did try first without this option, and unsurprisingly it didn't work):

Code: Select all

Second Processor (64K)
Shadow RAM
32K sideways RAM (banks &CD)
1770 DFS 2.26 with Gotek SSD
PAGE &800
stardot-ozmoo-preview-6.0-alpha-15 - Mode 7
Start: $000897
End: $3d45
Worth pointing out that all my previous CoPro tests were with HIBASIC (HIMEM=&B800), but I couldn't get the HIBASIC ROM to play with my NMOS 6502, so I had to disable it, and stick with plain BASIC (HIMEM=&8000). Once upon a time I did have a disk version of HIBASIC that worked with this processor, but I'm not sure where that is now. I've not seen it in a long time! Anyway, I'm not sure the location of BASIC makes much difference? Do you respect HIMEM, or do you overwrite BASIC?
Last edited by KenLowe on Wed Mar 24, 2021 9:20 pm, edited 2 times in total.
User avatar
KenLowe
Posts: 1782
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: PunyInform and Ozmoo

Post by KenLowe »

SteveF wrote:
Mon Mar 22, 2021 2:49 pm
That's not what I was proposing, but I do like your idea (although maybe the default should be unshifted for command history; I could see arguments either way). However, from an implementation perspective, I am not sure the OS command editing can be made to work with shifted cursor keys. Do you have any idea how this could be done? (My original suggestion has the same problem; I did say I wasn't sure about implementation, but was trying to stimulate discussion by giving some ideas.)

Edit: *Maybe* installing a handler on INSV and munging the cursor keycodes based on the CTRL-H toggle before the OS decides whether to invoke cursor editing would work. I haven't tried this yet and I'm open to better suggestions on how to implement this even if it would work.
I did wonder how you might implement shifted cursor keys, and assumed you had a cunning plan. Unfortunately I wouldn't be much help here :?.
SteveF wrote:
Sun Mar 21, 2021 5:17 pm
If you want to experiment with the command history for yourself, I've created alpha 13: https://github.com/ZornsLemma/ozmoo/rel ... 0-alpha-13 Please regard this as a "technology preview"; it's not that well tested and the command history is permanently enabled rather than a proper build option. Make sure you specify --no-cursor-editing when running make-acorn.py, otherwise you won't be able to use the command history.
I've just given that a quick test on the latest build and it works nicely. Now that I've had a chance to test it, I definitely think command history should be the default option, and would actually question the need for the standard copy function.
SteveF
Posts: 959
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

Thanks for the timings Ken, I've updated the post above. It's good to see the small CMOS tweaks I put in are saving a couple of seconds. :-)
KenLowe wrote:
Wed Mar 24, 2021 8:49 pm
Worth pointing out that all previous tests were with HIBASIC (HIMEM=&B800), but I couldn't get the HIBASIC ROM to play with my NMOS 6502, so I had to disable it, and stick with plain BASIC (HIMEM=&8000). Once upon a time I did have a disk version of HIBASIC that worked with this processor, but I'm not sure where that is now. I've not seen it in a long time! Anyway, I'm not sure that makes any difference? Do you respect HIMEM?
I hadn't thought to test this, but yes - the loader is a relatively simple BASIC program and doesn't mess around too much, so I'm glad it works fine with HIBASIC as I'd have (nervously) predicted if asked.

That's an interesting thread about your pre-production copro too, thanks for the pointer!
KenLowe wrote:
Wed Mar 24, 2021 9:13 pm
SteveF wrote:
Mon Mar 22, 2021 2:49 pm
Edit: *Maybe* installing a handler on INSV and munging the cursor keycodes based on the CTRL-H toggle before the OS decides whether to invoke cursor editing would work. I haven't tried this yet and I'm open to better suggestions on how to implement this even if it would work.
I did wonder how you might implement shifted cursor keys, and assumed you had a cunning plan. Unfortunately I wouldn't be much help here :?.
I've had a bit of a play around with this and unfortunately I don't think that's going to work. I wrote some experimental code to swap the unshifted cursor key codes and shifted cursor key codes in INSV, which "worked", but the code in OS 1.2 which controls activation of split cursor mode is here:

Code: Select all

    TAY                                                 Y=original character to add to buffer
    BPL .exitWithCarryClear2                            if (code is less than $80) then
                                                        branch (it's simple, so exit)
    AND #%00001111                            GAH! -->  clear high nybble  <-- GAH!
    CMP #11                                             compare with 11
    BCC .handleFunctionKeyPress                         if (less than 11, i.e. function key)
So the OS deliberately ignores SHIFT/CTRL when deciding whether to recognise a cursor key or not. This isn't entirely unreasonable, and it means you can start cursor editing with SHIFT or CTRL held down, but still, it thwarts my plans here.
KenLowe wrote:
Wed Mar 24, 2021 8:49 pm
SteveF wrote:
Sun Mar 21, 2021 5:17 pm
If you want to experiment with the command history for yourself...
I've just given that a quick test on the latest build and it works nicely. Now that I've had a chance to test it, I definitely think command history should be the default option, and would actually question the need for the standard copy function.
Thanks for giving it a test! I think that means we're all in agreement (please speak up if I've got confused!) that command history should be the default, it's just how or if to allow access to the OS cursor editing that's the problem.

I could probably implement a toggle (CTRL-H?) which switches between the two modes, defaulting to command history. The implementation would just switch *FX4 settings when CTRL-H was pressed so I think it would be easy. I could see an argument for just not allowing access to OS cursor editing, but it wouldn't take much code to allow it to be there for those occasions when you want to copy the world "analgesic" instead of retyping it. :-)
User avatar
KenLowe
Posts: 1782
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: PunyInform and Ozmoo

Post by KenLowe »

SteveF wrote:
Wed Mar 24, 2021 9:34 pm
I hadn't thought to test this, but yes - the loader is a relatively simple BASIC program and doesn't mess around too much, so I'm glad it works fine with HIBASIC as I'd have (nervously) predicted if asked.
So, will OZMOO take advantage of the extra memory between &8000 and &B800 if HIBASIC is being used? I'm not sure I really saw much difference in the benchmark times.
SteveF
Posts: 959
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

KenLowe wrote:
Wed Mar 24, 2021 9:42 pm
SteveF wrote:
Wed Mar 24, 2021 9:34 pm
I hadn't thought to test this, but yes - the loader is a relatively simple BASIC program and doesn't mess around too much, so I'm glad it works fine with HIBASIC as I'd have (nervously) predicted if asked.
So, will OZMOO take advantage of the extra memory between &8000 and &B800 if HIBASIC is being used? I'm not sure I really saw much difference in the benchmark times.
It doesn't (shouldn't, anyway :-)) really make any difference; the main Ozmoo executable takes over as the current language and replaces BASIC or HIBASIC, so I would expect the performance to be identical. Only the loader (and preloader, if you have a splash screen) will be running under HIBASIC. Edit: The Ozmoo executable for the second processor (OZMOO2P) uses memory in the second processor from &400-&f7ff inclusive, whichever version of BASIC the loader runs under.
User avatar
KenLowe
Posts: 1782
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: PunyInform and Ozmoo

Post by KenLowe »

SteveF wrote:
Wed Mar 24, 2021 9:45 pm
KenLowe wrote:
Wed Mar 24, 2021 9:42 pm
SteveF wrote:
Wed Mar 24, 2021 9:34 pm
I hadn't thought to test this, but yes - the loader is a relatively simple BASIC program and doesn't mess around too much, so I'm glad it works fine with HIBASIC as I'd have (nervously) predicted if asked.
So, will OZMOO take advantage of the extra memory between &8000 and &B800 if HIBASIC is being used? I'm not sure I really saw much difference in the benchmark times.
It doesn't (shouldn't, anyway :-)) really make any difference; the main Ozmoo executable takes over as the current language and replaces BASIC or HIBASIC, so I would expect the performance to be identical. Only the loader (and preloader, if you have a splash screen) will be running under HIBASIC. Edit: The Ozmoo executable for the second processor (OZMOO2P) uses memory in the second processor from &400-&f7ff inclusive, whichever version of BASIC the loader runs under.
Ah, ok. And once the game is finished (or you quit), how does it drop back to the BASIC > prompt if the language has been overwritten (assuming it's configured to do that and not to <-Press BREAK->)? Do you just issue a *BASIC command, and that re-initialises it? <- showing my ignorance here!
SteveF
Posts: 959
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

Yes, it just does *BASIC. Earlier versions saved the current language on startup and re-entered that (using *FX142) on exit, but I realised that was a bit pointless because the loader is in BASIC so the current language on startup of the Ozmoo executable couldn't be anything else. :-)
fredrikr
Posts: 43
Joined: Sat Jul 18, 2020 11:20 pm
Contact:

Re: PunyInform and Ozmoo

Post by fredrikr »

Join us for a PunyInform game jam! https://itch.io/jam/punyjam1

Learn PunyInform, have fun, write a game which you can then package up for play on Beebs, Commodores, Apples, Spectrums and what have you.
EdwardianDuck
Posts: 160
Joined: Thu Aug 10, 2017 9:07 pm
Contact:

Re: PunyInform and Ozmoo

Post by EdwardianDuck »

Just a brief note for anyone stuck on an older version of Python (I had to install 2.7 because I'm on Windows 7), I had to tweak this routine in make-acorn.py from this

Code: Select all

    def ourhex(i):
    assert i >= 0
    return hex(i)[2:]
to this

Code: Select all

    def ourhex(i):
    assert i >= 0
    return hex(i)[2:].rstrip("L")
to get the command line for ACME to work. I don't use Python myself, but apparently the behaviour of the hex() function changed slightly between 2.x and 3.x. Doubtless there are better ways of doing this.

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

Re: PunyInform and Ozmoo

Post by SteveF »

Thanks Jeremy, I've pushed that fix to the acorn-6.x branch (but haven't tagged this as a new alpha; if anyone needs this doing please let me know). This seems a little odd as my default Python on Ubuntu 20.04 is 2.7 (2.7.18 to be precise) and I haven't had any trouble, but the fix looks harmless where it's not needed so might as well play it safe.
User avatar
Dave Footitt
Posts: 963
Joined: Thu Jun 22, 2006 10:31 am
Location: Abandoned Uranium Workings
Contact:

Re: PunyInform and Ozmoo

Post by Dave Footitt »

fredrikr wrote:
Wed Mar 31, 2021 8:31 pm
Join us for a PunyInform game jam! https://itch.io/jam/punyjam1

Learn PunyInform, have fun, write a game which you can then package up for play on Beebs, Commodores, Apples, Spectrums and what have you.
Good idea Fredrik, I'll be submitting my small adventure later today :D
EdwardianDuck
Posts: 160
Joined: Thu Aug 10, 2017 9:07 pm
Contact:

Re: PunyInform and Ozmoo

Post by EdwardianDuck »

I'm currently porting my own work in progress game Duck! Me? viewtopic.php?f=65&t=21535 to PunyInform, mainly to compare and contrast against my experience of writing it from scratch in 6502 assembly.

More of an intellectual/learning exercise than anything else at this stage.

Jeremy
User avatar
BigEd
Posts: 4046
Joined: Sun Jan 24, 2010 10:24 am
Location: West Country
Contact:

Re: PunyInform and Ozmoo

Post by BigEd »

I'll be interested to hear the results!
SteveF
Posts: 959
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

EdwardianDuck wrote:
Sun May 02, 2021 1:20 pm
I'm currently porting my own work in progress game Duck! Me?
BigEd wrote:
Sun May 02, 2021 1:32 pm
I'll be interested to hear the results!
Me too! If you run into any more problems with Acorn Ozmoo on the way please do let me know.

Opportunistic and unrelated technical details

The rest of this post is just some technical wafflings I drafted ages ago (back when Ozmoo 5.x was the latest and greatest version) which I never got round to posting, so I thought I'd post them now. They're still valid - Ozmoo 6.x is like Ozmoo 5.x in this regard - and might be of geeky interest. As always, you don't need to read or understand any of this if you want to make and play games with Acorn Ozmoo.

A while back I posted about the Ozmoo virtual memory code. Johan and Fredrik have made a small but nifty tweak to how this works in Ozmoo 5.x which I thought it would be nice to write about. I'll talk about version 3 games here, but the same idea applies to all versions.

A version 3 game can be up to 128K, so the Z-machine addresses are 17-bit values. The virtual memory code always works with 512-byte blocks which are aligned to a 512-byte boundary, so we know the low 9 bits of a virtual memory block address will always be 0:
ozmoo-vmap-format-1.png
(Click on the image to enlarge if necessary.)

As described in the earlier post, for every 512-byte block of virtual memory cache Ozmoo has a 16-bit word in the vmap array containing two pieces of information about that block:
  • The Z-machine address of the data; we need this so when we want to access a particular address, we can find the corresponding cache block.
  • A timestamp indicating when that block was last accessed; we use this to decide which block to discard when we need to read a new block in from disc.
There's been a small tweak to the format of each 16-bit vmap entry in Ozmoo 5.x:
ozmoo-vmap-format-2.png
In Ozmoo 4.x, the least significant bit of each vmap entry was always 0. It's natural to do this, because it's the result of shifting the Z-machine address 8 bits to the right, which is a simple byte-oriented operation.

In Ozmoo 5.x, the block address is shifted right an extra bit, giving us an extra bit of timestamp resolution (i.e. doubling the number of available timestamps).

(This, incidentally, is why PREOPT files - which are more-or-less raw dumps of the vmap array - aren't compatible between Ozmoo 4.x and Ozmoo 5.x.)

The above applies to all Z-machine versions, but there's an additional advantage for version 3 games. When we're trying to access address a, we need to do something like:

Code: Select all

high_bits_of_a = a >> 8 # or >> 9 in 5.x
for i = 0 to vmap_size-1
    if (vmap[i] & address_mask) == high_bits_of_a:
    	return i # we found a block containing address a
next
That comparison in the 'if' line is a 16-bit comparison in general, but in Ozmoo 5.x with a version 3 game, the address part of each vmap entry exactly fills the low byte, with the high byte being completely filled by the timestamp. (See the dotted red line on the above diagram.) This means we don't need to perform any explicit masking in the above loop - we just look at the low byte and ignore the high byte, slightly speeding things up and saving a little bit of code.

(The diagrams used here are in my repo. vm-address.dot creates the basic diagram and then - lacking the graphviz skills to do things the way I wanted - I manually hacked the output about in gimp to create the two diagrams themselves.)
User avatar
Dave Footitt
Posts: 963
Joined: Thu Jun 22, 2006 10:31 am
Location: Abandoned Uranium Workings
Contact:

Re: PunyInform and Ozmoo

Post by Dave Footitt »

EdwardianDuck wrote:
Sun May 02, 2021 1:20 pm
I'm currently porting my own work in progress game Duck! Me? viewtopic.php?f=65&t=21535 to PunyInform, mainly to compare and contrast against my experience of writing it from scratch in 6502 assembly.
IMHO Inform is a work of art, and very well designed. The only reason not to use it for me, was a lack of ability to get the game onto an 8 bit platform, which PunyInform and Ozmoo address (and make a splendid job of doing so).

I'd be interested to hear someone elses' thoughts on it though.
fredrikr
Posts: 43
Joined: Sat Jul 18, 2020 11:20 pm
Contact:

Re: PunyInform and Ozmoo

Post by fredrikr »

Voting is now open for PunyJam #1

Anyone can help out as a judge. Details at https://intfiction.org/t/voting-for-punyjam-1/50749
fredrikr
Posts: 43
Joined: Sat Jul 18, 2020 11:20 pm
Contact:

Re: PunyInform and Ozmoo

Post by fredrikr »

Ozmoo 7 is now out. The big news is that it has support for a new target: the MEGA65

Announcement and picture: https://twitter.com/FRamsberg/status/13 ... 6146378757
User avatar
Dave Footitt
Posts: 963
Joined: Thu Jun 22, 2006 10:31 am
Location: Abandoned Uranium Workings
Contact:

Re: PunyInform and Ozmoo

Post by Dave Footitt »

Wow that looks proper lovely, nice one =D>

Being a BBC sort I'd not heard of the Mega65 until I listened to the latest Retro Hour podcast. It sounds a great bit of kit!
SteveF
Posts: 959
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

fredrikr wrote:
Tue May 04, 2021 8:08 pm
Ozmoo 7 is now out.
Congratulations!

Here's Acorn alpha 16, now updated to version 7.0. I've given this a modest amount of testing and I think it's good but please report any problems here so I can take a look.

https://github.com/ZornsLemma/ozmoo/rel ... 0-alpha-16

(Just for the record: the Acorn port's command history support is still in exactly the same state as before, i.e. functional but experimental. I haven't come to any decisions or done any work to tidy up the handling of command history vs native OS cursor editing.)
fredrikr
Posts: 43
Joined: Sat Jul 18, 2020 11:20 pm
Contact:

Re: PunyInform and Ozmoo

Post by fredrikr »

I have just played a beta of Stefan Vogt's new PunyInform game Hibernated 1 Director's Cut, on Ozmoo 7, on an emulated C64 with realistic disk drive speed, and the speed of the game is fantastic! It's a fully-featured z3 game, ~90 KB in size, with a rich game world, lots of puzzles, items and characters. It was developed with Inform 6 / PunyInform, but the speed is on par with early Infocom titles like Zork 1. There will be a physical release for the Commodore 64, Acorn and many other platforms. I believe Ozmoo will be used for the platforms where Ozmoo is available.
SteveF
Posts: 959
Joined: Fri Aug 28, 2015 9:34 pm
Contact:

Re: PunyInform and Ozmoo

Post by SteveF »

fredrikr wrote:
Tue May 11, 2021 10:01 am
I have just played a beta of Stefan Vogt's new PunyInform game Hibernated 1 Director's Cut, on Ozmoo 7, on an emulated C64 with realistic disk drive speed, and the speed of the game is fantastic! It's a fully-featured z3 game, ~90 KB in size, with a rich game world, lots of puzzles, items and characters. It was developed with Inform 6 / PunyInform, but the speed is on par with early Infocom titles like Zork 1. There will be a physical release for the Commodore 64, Acorn and many other platforms. I believe Ozmoo will be used for the platforms where Ozmoo is available.
That sounds great - it's really exciting to see what the combination of Ozmoo and PunyInform makes possible!

On a slightly less cheerful note, here's Acorn alpha 17: https://github.com/ZornsLemma/ozmoo/rel ... 0-alpha-17

This fixes a rather egregious bug I introduced right back in 5.8 alpha 12 (commit 7b54bcfd3c58cb2ceb950e1ff3860acfaf140c18 if you're playing along at home...) which caused sideways RAM to be almost completely ignored by the main Ozmoo executable on a BBC B with no shadow RAM. (I think a single 16K bank would be used on medium dynamic memory builds, helpfully hiding the problem by making the benchmark work, albeit with poor performance which I didn't notice.) This rather shakes my confidence in Acorn Ozmoo, but I'm sure I'll get over it. :-)
Post Reply

Return to “8-bit acorn software: other”