PunyInform and Ozmoo

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

Re: PunyInform and Ozmoo

Post by lurkio » Fri Jul 31, 2020 6:18 pm

Thanks for the latest build of Ozmoo with Calypso, Steve!
SteveF wrote:
Wed Jul 29, 2020 9:26 pm
You'd need to clone my repository and have it build a new .ssd from the .z5 file. I can give you some assistance with this if you like. We can probably make this work on Windows but it would be slightly easier if you're on Linux, as that's what I'm using. You'd need to install the acme assembler, beebasm and have a version of python available.
I've installed the acme assembler using Homebrew on the commandline on macOS, and I've got a pre-built Mac binary of beebasm 1.0.8 that someone (danielj?) uploaded to this forum, and I've got versions 2 and 3 of Python (I think), so I might actually be geared up for having a go at this, if you'd be willing to explain, in (very!) simple terms, how to do a clone and build..? [EDIT: This is so I can play around in Acorn Ozmoo with games other than Calypso, which you've already built and uploaded a package for.]

:?:

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

Re: PunyInform and Ozmoo

Post by SteveF » Fri Jul 31, 2020 8:01 pm

lurkio wrote:
Fri Jul 31, 2020 6:18 pm
Thanks for the latest build of Ozmoo with Calypso, Steve!
You're welcome!
lurkio wrote:
Fri Jul 31, 2020 6:18 pm
I've installed the acme assembler using Homebrew on the commandline on macOS, and I've got a pre-built Mac binary of beebasm 1.0.8 that someone (danielj?) uploaded to this forum, and I've got versions 2 and 3 of Python (I think), so I might actually be geared up for having a go at this, if you'd be willing to explain, in (very!) simple terms, how to do a clone and build..? [EDIT: This is so I can play around in Acorn Ozmoo with games other than Calypso, which you've already built and uploaded a package for.]
Perfect timing, because I just created a (relatively) user-friendly build system. :-) I'm using Linux so it shouldn't be too different, let's see how we get on.

Do you have the "git" command line tool installed too? If you do, change to some suitable working directory and do:

Code: Select all

git clone https://github.com/ZornsLemma/ozmoo.git
cd ozmoo
git checkout stardot-ozmoo-preview-2020-07-31b
If you don't, you can download a .zip or .tar.gz of the source code from here: https://github.com/ZornsLemma/ozmoo/rel ... 020-07-31b You'll need to unpack that somewhere and cd into the ozmoo directory.

At this point it should (ahem) be as simple as typing:

Code: Select all

python make-acorn.py whatever-game-you-like.z5
That will create a whatever-game-you-like.ssd file in the directory you ran it from, and you can then load that into an emulator. .z3 games will work too, I just picked .z5 for that example.

Since it's bound not to work first time, here are a few things to try:
  • Add -vv after make-acorn.py in that last command line and copy and paste the output into a message here so I can look at it.
  • If your game is big, you'll need to add -2 after make-acorn.py to make a double-sided .dsd image instead. You'll get an error if you need to do this.
Please let me know how you get on!

Edited to add: you might need beebasm 1.09, I'm not sure. We can work round that if you do and no one has a 1.09 binary you can use.

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

Re: PunyInform and Ozmoo

Post by lurkio » Fri Jul 31, 2020 8:23 pm

SteveF wrote:
Fri Jul 31, 2020 8:01 pm
Perfect timing, because I just created a (relatively) user-friendly build system. :-) I'm using Linux so it shouldn't be too different, let's see how we get on ... Edited to add: you might need beebasm 1.09, I'm not sure. We can work round that if you do and no one has a 1.09 binary you can use.
It worked! Not first time, but that was because I had an older version of beebasm. But I just downloaded the latest version of the source (1.09) from the beebasm Github and built it, and it was surprisingly painless! And then your build instructions for Ozmoo worked perfectly too! Am currently playing Z3 Hitchhiker's in Acorn Ozmoo in MODE7! This is tremendous!

I'll keep mucking about and report back if I find any bugs. But so far, everything looks great!

Btw, I assume you know that RESTART doesn't work in Calypso..?

Oh, and I don't know if this makes any sense, but I had an idea for the status-line: if you find there isn't room to squeeze in the location-name in rooms with long names (especially if you've used up one char to turn the status-line cyan in MODE7), then maybe omit the text "Score: " -- and reintroduce it again when the player moves to a room with a shorter name?!

Anyway, this is fantastic work, Steve!

=D> =D> =D>

EDIT: Btw, I don't fully understand git, so this might be a silly question, but will I ever have to do a "git checkIN" of the code I just did a "git checkout" on?

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

Re: PunyInform and Ozmoo

Post by SteveF » Fri Jul 31, 2020 8:40 pm

That's great news, I'm really chuffed! Thanks for your kind words, of course none of it would be possible without the excellent Commodore version as a starting point. (I'm really enjoying the porting stuff, but I don't think I'd have the patience or skill to build something like this from scratch.)

The RESTART behaviour is inherited from the Commodore version - Ozmoo doesn't support RESTART in games which don't use virtual memory. I could tweak this - it wouldn't be hard, as all RESTART does is "*RUN :0.$.OZMOO" - but I don't know if I should diverge from upstream gratuitously. Non-VM games don't require you to keep the disc in the drive all the time, so strictly speaking I'd have to check for the game disc and then execute that command, but it wouldn't be a huge deal as I already have code to do that after a save or restore for VM games. On a purely practical level, pressing SHIFT+BREAK would restart in virtually the same amount of time, but it does nag at me a little that RESTART isn't supported when it would be so little work. I think part of the reason the C64 version is like this is so a non-VM game could be loaded from tape, but I may be wrong. That consideration doesn't really apply here, I can't see anyone even BITD having a second processor but not a floppy drive.

That's not a bad idea about the status line, although note that the interpreter only draws the status line for Z3 games - games for later versions draw their own. Do you have a specific example where behaviour like this has been needed or are you just thinking generally? I see there is some code in upstream Ozmoo to generate the status line but superficially it doesn't seem to do any truncation; I haven't tested it though, so it might.

Edit: a question for Fredrik here, way back on page 1 you wrote:
If you plan on supporting z4+ games, and you have a different number of characters in the statusline compared to the rest of the screen, you would need to use this width for the top window in general (In z4+, the statusline is just a top window of height 1).
I'm looking at the Z-machine spec and it's not that obvious to me the screen model allows the screen width to be inconsistent between different windows. Am I missing something? I am thinking I will need to offer a build-time option which tells Ozmoo "the top window is the status line, fiddle around to make it colour in mode 7, it will be OK with this game" to work around this. Or just leave the status line black and white in mode 7, of course. :-)

And no, you don't have to do a check in on git. git doesn't lock files when you check them out, so there's nothing to undo. If you want to make any changes to the code you'll need to "commit" them to your own repository, but that's strictly for developers.

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

Re: PunyInform and Ozmoo

Post by lurkio » Fri Jul 31, 2020 9:09 pm

Well, Hitchhiker's in Acorn Ozmoo accepts the quotation-marks in a certain command that you have to type in at one point (which I mentioned previously) -- and that's the acid test for Z-Code interpreters as far as I'm concerned! :wink:

SteveF wrote:
Fri Jul 31, 2020 8:40 pm
The RESTART behaviour is inherited from the Commodore version - Ozmoo doesn't support RESTART in games which don't use virtual memory.
I wouldn't worry about it then. Restarting manually isn't a hassle by any means.

SteveF wrote:
Fri Jul 31, 2020 8:40 pm
I am thinking I will need to offer a build-time option which tells Ozmoo "the top window is the status line, fiddle around to make it colour in mode 7, it will be OK with this game" to work around this. Or just leave the status line black and white in mode 7, of course.
Please offer an option to colourise the status-line in MODE7 if at all possible! Up to you of course, but MODE7 provides the clearest and most readable text on the Beeb, especially for users with eyes of a certain vintage..! So I bet most players would choose to use it in preference to any other MODE. And distinguishing the status line from the rest of the text would look so much nicer -- it would instantly tell you, at a glance, where you are and what your score is. Otherwise, the status-line sort of blends in with the main game text and is a bit confusing... Not that this is the hill I'm gonna die on or anything. (Probably.)

:idea:

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

Re: PunyInform and Ozmoo

Post by SteveF » Fri Jul 31, 2020 10:05 pm

lurkio wrote:
Fri Jul 31, 2020 9:09 pm
Well, Hitchhiker's in Acorn Ozmoo accepts the quotation-marks in a certain command that you have to type in at one point (which I mentioned previously) -- and that's the acid test for Z-Code interpreters as far as I'm concerned! :wink:
Good to know!
lurkio wrote:
Fri Jul 31, 2020 9:09 pm
Please offer an option to colourise the status-line in MODE7 if at all possible!
Don't worry, I will definitely do this unless it's absolutely impossible - and at least for z3 games it is definitely going to be possible. :-)

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

Re: PunyInform and Ozmoo

Post by lurkio » Fri Jul 31, 2020 10:42 pm

SteveF wrote:
Fri Jul 31, 2020 10:05 pm
Don't worry, I will definitely do this unless it's absolutely impossible - and at least for z3 games it is definitely going to be possible. :-)
Phew!

Btw, if it's not too much of a pain, could you briefly explain why the build process involves two different assemblers -- beebasm and acme -- rather than just one or the other?

:?:

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

Re: PunyInform and Ozmoo

Post by SteveF » Fri Jul 31, 2020 11:07 pm

lurkio wrote:
Fri Jul 31, 2020 10:42 pm
Btw, if it's not too much of a pain, could you briefly explain why the build process involves two different assemblers -- beebasm and acme -- rather than just one or the other?
No pain at all. To start with beebasm was a handy tool to assemble a .ssd from the command line when I was trying to get the port started. make-acorn.py is now capable of creating .ssd files itself, so the reason beebasm is still there is that the LOADER program is written in BASIC, and beebasm is used to tokenise it. This means I can edit it freely and it can live in git as a text file rather than a tokenised file. (Edited: LOADER is pretty trivial and doesn't change much at the moment, but as the port becomes more polished I'd expect it to maybe display a pretty mode 7 banner and ask the user what screen mode they want to use, so it will get a bit more involved.)

I could swap beebasm out for some other command-line tokenising utility (although I had a very quick search and couldn't find one) but I think people are more likely to have beebasm installed than that other utility. beebasm also allows the input BASIC program to have no line numbers, which I find more comfortable.

(What would be ideal would be a BASIC tokenising program under a GPL2-compatible licence written in ruby or python, then I could just include it directly in the repository and remove a dependency. I suspect ultimately I will end up rewriting make-acorn.py in ruby to match the Commodore case, in which case that BASIC tokenising program would need to be in ruby rather than Python as well.)

User avatar
Dave Footitt
Posts: 899
Joined: Thu Jun 22, 2006 10:31 am
Location: Abandoned Uranium Workings
Contact:

Re: PunyInform and Ozmoo

Post by Dave Footitt » Sat Aug 01, 2020 12:30 am

SteveF wrote:
Fri Jul 31, 2020 10:05 pm
Don't worry, I will definitely do this unless it's absolutely impossible - and at least for z3 games it is definitely going to be possible. :-)
Thanks to help from Fredrik, Calypso builds as v3 as well as v5 so just in case you need it as z3 for your testing I've attached both here.

Happy to help if you need further!
Attachments
calypso.zip
(62.35 KiB) Downloaded 11 times

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

Re: PunyInform and Ozmoo

Post by SteveF » Sat Aug 01, 2020 2:49 am

Dave Footitt wrote:
Sat Aug 01, 2020 12:30 am
Thanks to help from Fredrik, Calypso builds as v3 as well as v5 so just in case you need it as z3 for your testing I've attached both here.
Thanks, that will come in handy! Just out of interest, are they completely equivalent? Could a user tell the difference between them just by playing under a Z-machine interpreter (not necessarily Ozmoo)?

User avatar
Dave Footitt
Posts: 899
Joined: Thu Jun 22, 2006 10:31 am
Location: Abandoned Uranium Workings
Contact:

Re: PunyInform and Ozmoo

Post by Dave Footitt » Sat Aug 01, 2020 9:59 pm

SteveF wrote:
Sat Aug 01, 2020 2:49 am
Thanks, that will come in handy! Just out of interest, are they completely equivalent? Could a user tell the difference between them just by playing under a Z-machine interpreter (not necessarily Ozmoo)?
From Fredrik in an earlier email to me:
Also, for many of the old 8-bit computers, there are z3 interpreters available, but not z5 interpreters.

The only advantage of the z5 version is that the room names are printed in bold text, on platforms that support it. Old 8-bit platforms typically don't, but modern ones do.

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

Re: PunyInform and Ozmoo

Post by SteveF » Sat Aug 01, 2020 10:09 pm

The only advantage of the z5 version is that the room names are printed in bold text, on platforms that support it. Old 8-bit platforms typically don't, but modern ones do.
Interesting, thanks. In principle I could probably support bold text in non-mode 7, but I guess it's not a super high priority feature. :-)

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

Re: PunyInform and Ozmoo

Post by fredrikr » Mon Aug 03, 2020 10:54 pm

SteveF wrote:
Fri Jul 31, 2020 8:40 pm
The RESTART behaviour is inherited from the Commodore version - Ozmoo doesn't support RESTART in games which don't use virtual memory. I could tweak this - it wouldn't be hard, as all RESTART does is "*RUN :0.$.OZMOO" - but I don't know if I should diverge from upstream gratuitously. Non-VM games don't require you to keep the disc in the drive all the time, so strictly speaking I'd have to check for the game disc and then execute that command, but it wouldn't be a huge deal as I already have code to do that after a save or restore for VM games. On a purely practical level, pressing SHIFT+BREAK would restart in virtually the same amount of time, but it does nag at me a little that RESTART isn't supported when it would be so little work. I think part of the reason the C64 version is like this is so a non-VM game could be loaded from tape, but I may be wrong. That consideration doesn't really apply here, I can't see anyone even BITD having a second processor but not a floppy drive.
For the C64, a lot of people only had tape and no disk back in the eighties, and so this has led to quite a few people owning a C64 with just a tape drive today, or owning both tape and disk drives but preferring to use tape because that reminds them more of the eighties. That's why we'd like to have a mode which allows games to be saved as a single file, so they can then be loaded from any media you like.

Just a note: It's easy enough in the Calypso source to replace RestartSub with a routine that just prints "Sorry, restart is not supported." or something. If you want to distribute a version where restart doesn't work, you may want to do this.
SteveF wrote:
Fri Jul 31, 2020 8:40 pm
Edit: a question for Fredrik here, way back on page 1 you wrote:
If you plan on supporting z4+ games, and you have a different number of characters in the statusline compared to the rest of the screen, you would need to use this width for the top window in general (In z4+, the statusline is just a top window of height 1).
I'm looking at the Z-machine spec and it's not that obvious to me the screen model allows the screen width to be inconsistent between different windows. Am I missing something? I am thinking I will need to offer a build-time option which tells Ozmoo "the top window is the status line, fiddle around to make it colour in mode 7, it will be OK with this game" to work around this. Or just leave the status line black and white in mode 7, of course. :-)
The Z-machine doesn't know or care how wide your lower window is. The game can't place the cursor there, it can't read the cursor position etc. Most modern interpreters use a proportional font in the lower window and so the width of the lower window in characters in not fixed.

But the width of the upper window (which is the same as the statusline in z4+) must be specified in the Z-code header. It says "screen width" in the specification, but it's really upper window width.

Then again, when you expand the upper window, the contents of the lower window which are now covered by the upper window should not be deleted, IIRC. But you'd probably get away with doing so anyway, if needed.

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

Re: PunyInform and Ozmoo

Post by fredrikr » Mon Aug 03, 2020 11:04 pm

SteveF wrote:
Sat Aug 01, 2020 10:09 pm
The only advantage of the z5 version is that the room names are printed in bold text, on platforms that support it. Old 8-bit platforms typically don't, but modern ones do.
Interesting, thanks. In principle I could probably support bold text in non-mode 7, but I guess it's not a super high priority feature. :-)
Also note that there are more things you can do in z5 but which aren't used in Calypso, like:

* You can read the screen width and use this to center text on screen, or choose to display something in different ways depending on the screen width.

* You can design your own statusline. The statusline can be any number of lines you like.

* You can print text using reverse video.

* You can change the colour of text and background at any time.

* You can read single keypresses.

* You can have an interrupt routine run at certain intervals while waiting for player input.

* You can replace the default alphabet table, which is a critical part of the text compression, i.e. to allow some accented characters to be stored efficiently.

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

Re: PunyInform and Ozmoo

Post by SteveF » Tue Aug 04, 2020 11:36 am

fredrikr wrote:
Mon Aug 03, 2020 10:54 pm
The Z-machine doesn't know or care how wide your lower window is. The game can't place the cursor there, it can't read the cursor position etc. Most modern interpreters use a proportional font in the lower window and so the width of the lower window in characters in not fixed.

But the width of the upper window (which is the same as the statusline in z4+) must be specified in the Z-code header. It says "screen width" in the specification, but it's really upper window width.
Thanks Fredrik, that makes sense. I've been experimenting with ways to colourise a status bar-like upper window for Z5 games and I may not need this, but it's good to understand the screen model better.

I might tweak RESTART to always work on Acorn builds, but I haven't decided yet. Certainly back in the day lots of Beeb owners will have only had tape, but the limited RAM means a cassette-only Beeb isn't really much use for Ozmoo. People will just have to get their nostalgia fix listening to the disc drive clunking away instead. :-)

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

Re: PunyInform and Ozmoo

Post by SteveF » Thu Aug 06, 2020 2:31 pm

Lurkio posed some questions over in another thread, but my answer got too long so I thought I'd better post it here where it fits a bit better.
lurkio wrote:
Thu Aug 06, 2020 12:37 pm
But would it be too fiddly to just use SWRAM in a more conventional way? Is there a minimum amount of contiguous memory that Ozmoo needs? Is the size of the contiguous memory block available in a Model B without your hack just not big enough?
Good questions! The short answer to all of them is "maybe". :-) At the risk of going into too much detail, here are the longer answers:

The Z-machine has three regions of memory - dynamic, static and high. Static and high are both read-only and as far as porting Ozmoo goes the distinction between them isn't really important. Access to them might require swapping in a new 512-byte byte block of data from disc using the Ozmoo virtual memory subsystem, so it's funnelled via a very limited number of subroutines in the code.

Dynamic memory can be modified by the running game. In Ozmoo (and virtually every other interpreter, I believe) it has to be kept in RAM so it can be modified. Without starting to get creative about this [1], that means you more-or-less need enough RAM for:
  • The OS, filing system and screen (4.75K at the bottom of RAM and 1K at the top of main RAM on a model B, since I expect to need PAGE at &1300 to allow the use of one file for save/restore [2])
  • The Ozmoo code and Z-machine stack (approximately 12K with my current prototype code on a model B)
  • The game's dynamic memory
  • Virtual memory backing RAM: this is a cache for read-only static/high memory blocks read in from disc so that the interpreter isn't continually grinding at the drive. The technical minimum here is 1K (one 512-byte block for the program counter, one 512-byte block for data access), but you'd need the patience of a saint to use this to play a game. The realistic minimum will vary with the user's patience and the game being played, but based on experiments with my prototype, about 16K is borderline tolerable. [3]
Let's ignore the virtual memory backing RAM, because it's pretty easy to distribute it over the available memory (including multiple sideways RAM banks) thanks to the controlled way it's accessed in the Ozmoo code. Dynamic memory is the critical resource here.

So on a model B with a mode 7 screen at &7C00, there's about 14.25K of contiguous free RAM between the top of the Ozmoo code/stack and the screen RAM. Is that enough? It depends what you want to run:
  • Dave's "Calypso", even in its Z5 incarnation, only needs 6.1K of dynamic memory, so everything's fine there.
  • The Ozmoo "benchmark" game, Infocom's "Hollywood Hijinx" (Z3), needs 11.8K of dynamic memory, so it's closer but fits.
  • A Z5 copy of "THHGTTG" I have here needs 14.8K of dynamic memory, so that's not going to fit.
  • Graham Nelson's "Curses" release 16 needs 25.5K of dynamic memory, so that's too big as well.
(You can see the dynamic memory needed for any game by running the "infodump" utility on it; it's shown in hexadecimal bytes as "Size of dynamic memory".)

Using the screen-at-&3C00 hack, the Ozmoo executable would have a "hole" in it so it fits round the screen and dynamic memory would start at about &4700. If we page in a 16K sideways RAM bank, we'd have &C000-&4700=30.25K of contiguous memory which could be used as dynamic memory. So this opens up a lot more possible games which can be run on a model B under Ozmoo. It might well be that things like "Curses" release 16 are too big/slow for an 8-bit machine anyway, but given a classic Z3 game like "Hollywood Hijinx" is close to the current limit, I don't find it hard to imagine there are games you could realistically run which wouldn't fit without this hack.

The C64 version of Ozmoo can provide about 35K of dynamic memory to a game, so it's nice if the model B can be roughly competitive with this and run roughly the same games. (You'd need at least 2x16K sideways RAM banks to have a chance of running a game needing 30K dynamic RAM, though, as one bank would be entirely taken by the dynamic RAM and you'd need at least another 16K for the virtual memory backing RAM.)

The other alternative is to tweak the Ozmoo code to allow the dynamic memory to be non-contiguous. I think this would be possible and I've identified maybe a dozen places in the code where an adjustment would need to be made, but I'd be a bit worried this would introduce subtle bugs. It's relatively easy to be confident the virtual memory code is working correctly, but changes to dynamic memory access scattered around the code in various different Z-machine opcode implementations aren't quite so simple. Given the relatively self-contained nature of the screen-at-&3C00 hack, I think it's a nicer option barring as-yet-undiscovered flaws in the plan.

Footnotes :-):
  1. It just *might* be possible to play tricks like allowing dynamic memory to be paged in and out from/to disc. What about memory that's been changed?
    • Blocks of dynamic memory could be locked into RAM once they'd been touched by the game, hoping many blocks aren't.
    • We could keep copies of just the changed bytes within those pages in a different data structure in RAM, so we can restore them when we page the data back in.
    • We could write the modified pages out to disc, rather than only ever reading from the disc for virtual memory purposes.
    All of these would be pretty intrusive code changes and they'd probably all perform horribly. Except for sheer hack value, I really don't want to go there. :-)
  2. If the dynamic memory fits entirely in main RAM, it's possible to save/restore using OSFILE instead of OSFIND+OSGBPB, which means PAGE can be at &1100 on a model B. This is how the second processor version does a save/restore at the moment.
  3. I'd be interested to know how much a solid-state storage solution like MMFS helps with low RAM situations, once I actually have some finished code.
Edited to add: There's another option, of just starting dynamic memory at the start of the first sideways RAM bank and either wasting the main RAM free below the screen at &7C00 or jumping through some modest hoops to use it as virtual memory cache. That allows games needing up to 16K dynamic memory to be supported on a model B, but I think the screen-at-&3C00 hack is both better (up to 30K dynamic memory) and simpler to implement.

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

Re: PunyInform and Ozmoo

Post by KenLowe » Thu Aug 06, 2020 8:17 pm

SteveF wrote:
Fri Jul 31, 2020 8:01 pm
Perfect timing, because I just created a (relatively) user-friendly build system. :-) I'm using Linux so it shouldn't be too different, let's see how we get on.

Do you have the "git" command line tool installed too? If you do, change to some suitable working directory and do:

Code: Select all

git clone https://github.com/ZornsLemma/ozmoo.git
cd ozmoo
git checkout stardot-ozmoo-preview-2020-07-31b
If you don't, you can download a .zip or .tar.gz of the source code from here: https://github.com/ZornsLemma/ozmoo/rel ... 020-07-31b You'll need to unpack that somewhere and cd into the ozmoo directory.

At this point it should (ahem) be as simple as typing:

Code: Select all

python make-acorn.py whatever-game-you-like.z5
That will create a whatever-game-you-like.ssd file in the directory you ran it from, and you can then load that into an emulator. .z3 games will work too, I just picked .z5 for that example.

Since it's bound not to work first time, here are a few things to try:
  • Add -vv after make-acorn.py in that last command line and copy and paste the output into a message here so I can look at it.
  • If your game is big, you'll need to add -2 after make-acorn.py to make a double-sided .dsd image instead. You'll get an error if you need to do this.
Please let me know how you get on!

Edited to add: you might need beebasm 1.09, I'm not sure. We can work round that if you do and no one has a 1.09 binary you can use.
I've just stumbled across this thread, and can't believe what I've been missing! Great work!!!

Unfortunately, I'm struggling to get it working. I suspect it might be because I'm trying to run this on a Windows 10 machine. So here's what I've done...

Firstly, on a CentOS machine, I downloaded the latest beebasm source and compiled it following this guide:
Coeus wrote:
Mon Jul 06, 2020 5:19 pm
That's interesting. I just did:

Code: Select all

git clone https://github.com/stardot/beebasm.git
cd beemasm/src
make all
and that seemed to work fine. I then copied the beebasm.exe file over to my Window 10 machine.

Then, I downloaded the ozmoo archive from github, and extracted to my Windows 10 PC. I copied the beebasm.exe file into the ozmoo folder, along with a couple of different infocom data files (zork1 and hitchhik), but I'm getting a file not found error when trying to run the script from an admin command prompt:

Code: Select all

c:\Users\me\Desktop\Ozmoo\ozmoo-stardot-ozmoo-preview-2020-07-31b>python make-acorn.py -vv hitchhik.z5
acme --setpc $600 -DACORN=1 -DSTACK_PAGES=4 -DSMALLBLOCK=1 -DSPLASHWAIT=0 -DZ5=1 --cpu 6502 --format plain -l ../temp/acme_labels_no_vmem.txt -r ../temp/acme_report_no_vmem.txt --outfile ../temp/ozmoo_no_vmem ozmoo.asm
Traceback (most recent call last):
  File "make-acorn.py", line 132, in <module>
    run_and_check(substitute(acme_args1 + acme_args2, "VERSION", "no_vmem"))
  File "make-acorn.py", line 36, in run_and_check
    child = subprocess.Popen(args, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
  File "C:\Users\me\AppData\Local\Programs\Python\Python38-32\lib\subprocess.py", line 854, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "C:\Users\me\AppData\Local\Programs\Python\Python38-32\lib\subprocess.py", line 1307, in _execute_child
    hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
FileNotFoundError: [WinError 2] The system cannot find the file specified
Any idea where I might be going wrong? I wonder if beebasm.exe is in the wrong location?

Edit: Same error when running from Centos, this time with beebasm copied into the ozmoo directory:

Code: Select all

[root@xxxxxxxx ozmoo]# python make-acorn.py -vv hitchhik.z5
acme --setpc $600 -DACORN=1 -DSTACK_PAGES=4 -DSMALLBLOCK=1 -DSPLASHWAIT=0 -DZ5=1 --cpu 6502 --format plain -l ../temp/acme_labels_no_vmem.txt -r ../temp/acme_report_no_vmem.txt --outfile ../temp/ozmoo_no_vmem ozmoo.asm
Traceback (most recent call last):
  File "make-acorn.py", line 132, in <module>
    run_and_check(substitute(acme_args1 + acme_args2, "VERSION", "no_vmem"))
  File "make-acorn.py", line 36, in run_and_check
    child = subprocess.Popen(args, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
  File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__
    errread, errwrite)
  File "/usr/lib64/python2.7/subprocess.py", line 1327, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

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

Re: PunyInform and Ozmoo

Post by SteveF » Thu Aug 06, 2020 11:10 pm

It looks like there's a problem finding the "acme" assembler. Do you have it installed and on your path? If you just type "acme" at the command prompt, do you get a usage message or does it say something like "file not found"?

Edit: I might be reading things wrong, but it sounds like you've compiled beebasm on CentOS and then copied that Linux binary over to Windows 10. Does that work? Traditionally it wouldn't, but I suppose it might do these days. Do you get output if you type "beebasm --help" at the command prompt? In any case, I think the first problem you're hitting is finding the "acme" assembler. - OK, I just did a quick web search as I had some vague memories, are you using WSL? If so I guess this should work fine. In any case, if you're also trying on CentOS none of this is going to be a problem there.

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

Re: PunyInform and Ozmoo

Post by KenLowe » Fri Aug 07, 2020 7:00 am

SteveF wrote:
Thu Aug 06, 2020 11:10 pm
It looks like there's a problem finding the "acme" assembler. Do you have it installed and on your path? If you just type "acme" at the command prompt, do you get a usage message or does it say something like "file not found"?
I almost certainly don't have ACME installed. I'll check that out shortly. Thanks.
SteveF wrote:
Thu Aug 06, 2020 11:10 pm
I might be reading things wrong, but it sounds like you've compiled beebasm on CentOS and then copied that Linux binary over to Windows 10. Does that work? Traditionally it wouldn't, but I suppose it might do these days. Do you get output if you type "beebasm --help" at the command prompt? In any case, I think the first problem you're hitting is finding the "acme" assembler. - OK, I just did a quick web search as I had some vague memories, are you using WSL? If so I guess this should work fine. In any case, if you're also trying on CentOS none of this is going to be a problem there.
Regarding beebasm, two binaries got compiled; beebasm and beebasm.exe. I copied beebasm.exe over to my Windows machine. Both versions run fine on their respective OS. I dont have WSL installed. At least it's not something I've consciously installed.

Edit1: I missed the need for ACME. I've found the source on Sourceforge. Any pointers on how to install and compile this on CentOS?
Edit2: So, I'm sat at my PC now. I've been able to download a pre-compiled Win32 binary of ACME from the Sourceforge site, and I've copied that over to the ozmoo folder on my Windows 10 PC. Both ACME and beebasm run standalone from the ozmoo folder, but I still get the same error when I run the python script. I'll mess around with the PATH variable to see if that makes any difference:

Code: Select all

c:\Users\me\Desktop\Ozmoo>acme -V
This is ACME, release 0.97 ("Zem"), 4 Jul 2020
  DOS/OS2/Win32 version. Compiled by Dirk Hoepf

Code: Select all

c:\Users\me\Desktop\Ozmoo>beebasm --help
beebasm 1.09

Possible options:
 -i <file>      Specify source filename
 -o <file>      Specify output filename (when not specified by SAVE command)
 -di <file>     Specify a disc image file to be added to
 -do <file>     Specify a disc image file to output
 -boot <file>   Specify a filename to be run by !BOOT on a new disc image
 -opt <opt>     Specify the *OPT 4,n for the generated disc image
 -title <title> Specify the title for the generated disc image
 -v             Verbose output
 -d             Dump all global symbols after assembly
 -w             Require whitespace between opcodes and labels
 -vc            Use Visual C++-style error messages
 -D <sym>=<val> Define symbol prior to assembly
 --help         See this help again

Code: Select all

c:\Users\me\Desktop\Ozmoo>python make-acorn.py -vv hitchhik.z5
acme --setpc $600 -DACORN=1 -DSTACK_PAGES=4 -DSMALLBLOCK=1 -DSPLASHWAIT=0 -DZ5=1 --cpu 6502 --format plain -l ../temp/acme_labels_no_vmem.txt -r ../temp/acme_report_no_vmem.txt --outfile ../temp/ozmoo_no_vmem ozmoo.asm
Traceback (most recent call last):
  File "make-acorn.py", line 132, in <module>
    run_and_check(substitute(acme_args1 + acme_args2, "VERSION", "no_vmem"))
  File "make-acorn.py", line 36, in run_and_check
    child = subprocess.Popen(args, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
  File "C:\Users\Ken Lowe\AppData\Local\Programs\Python\Python38-32\lib\subprocess.py", line 854, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "C:\Users\Ken Lowe\AppData\Local\Programs\Python\Python38-32\lib\subprocess.py", line 1307, in _execute_child
    hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
FileNotFoundError: [WinError 2] The system cannot find the file specified
Edit3: Ok, big step forward :D . Adding %USERPROFILE%\Desktop\Ozmoo to the PATH statement has got it working on my Windows 10 setup. Well almost. I now have z3 versions of Zork 1, 2 & 3 and Hitchhiker's Guide to the Galaxy running on my co pro enabled beeb (which must be the coolest things ever to have run on my beeb) 8) 8), but I get an error with z5 version of Hitchhiker's Guide to the Galaxy. I'll investigate that later. And, of course, no Infocom collection would be complete without Leather Goddesses of Phobos:

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 291, in <module>
    assert low & 0xff == low
AssertionError

C:\Users\me\Desktop\Ozmoo>
Is there any reason I can't post up the various .ssd images for others to test?
capture3.png
Zork 1 running on a 6502 2nd Processor
capture24.png
Zork 2 running on a 6502 2nd Processor
capture25.png
Zork 3 running on a 6502 2nd Processor
capture23.png
The Hitchhiker's Guide to the Galaxy running on a 6502 2nd Processor
capture26.png
Leather Goddesses of Phobos running on a 6502 2nd Processor
Oh, and +1 for the Mode 7 screen option. Also, instead of jumping directly to a SWRAM implementation, would you consider an implementation for beebs with Shadow RAM (eg, B+, Beeb with IntegraB Shadow / SW RAM board <- my interest!!!, beeb with Watford Shadow RAM board etc). I'm sure that would be simpler to implement than the SWRAM version!

Great work so far =D> =D> =D> .

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

Re: PunyInform and Ozmoo

Post by SteveF » Fri Aug 07, 2020 12:50 pm

Congratulations on getting it working! I might add an initial check for acme and beebasm early in the build and generate a clearer error if they're not found, although ultimately I suspect I'll be throwing make-acorn.py away and rewriting it in Ruby.

Thanks for reporting the "assert low & 0xff == low" failure. I've seen this for myself in a different context during my work on the SWR version and I think I've now fixed it there. If I don't get the SWR version out for people to test in the next couple of days I will try to port the fix over to the non-SWR version; please feel free to give me a nudge here if neither of those happens automatically.

I don't know what the copyright status is on these games; I don't personally object if you want to do it, but could you please hold off a bit to give Fredrik and the stardot admins a chance to voice an opinion?

I'm not averse to supporting shadow RAM on the B if someone is willing to test and put up with frequent breakages. :-) However, unless I'm missing some feature of these boards (I never had shadow RAM on the B BITD, so it's quite possible), I don't think they help that much. The real challenge with Ozmoo is free RAM for game data and since we can run in mode 7 here, shadow RAM only gives us an extra 1K of RAM back. We need sideways RAM to add sufficient memory to the basic 32K to be able to run games without a second processor. Shadow RAM *does* allow Ozmoo to run in mode 0, 3, 4 or 6, and the current SWR prototype allows this already on a Master. The real benefit of shadow RAM is that it gets the screen memory out of the way so we can have as much contiguous free RAM as possible.

Incidentally, subject to life not getting in the way, the SWR prototype is coming along nicely and I hope to be able to release a preview soon; it's working properly AFAICT and really just needs a bit of tidying up so it can support all the different models and the build system can build them all and put them onto a single .ssd which decides what version to run on the current machine.

I hope this makes sense; I've written this in a bit of a rush but I wanted to reply to you ASAP. I'll check back in on the thread later today so if I've forgotten anything or this doesn't make sense please let me know!

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

Re: PunyInform and Ozmoo

Post by KenLowe » Fri Aug 07, 2020 1:11 pm

SteveF wrote:
Fri Aug 07, 2020 12:50 pm
Thanks for reporting the "assert low & 0xff == low" failure. I've seen this for myself in a different context during my work on the SWR version and I think I've now fixed it there. If I don't get the SWR version out for people to test in the next couple of days I will try to port the fix over to the non-SWR version; please feel free to give me a nudge here if neither of those happens automatically.
No rush.
SteveF wrote:
Fri Aug 07, 2020 12:50 pm
I don't know what the copyright status is on these games; I don't personally object if you want to do it, but could you please hold off a bit to give Fredrik and the stardot admins a chance to voice an opinion?
I think most of the early Infocom games are now considered Abandonware and are freely available for download. I was more concerned about releasing images with a potentially incomplete (or not fully tested) z-machine interpreter.
SteveF wrote:
Fri Aug 07, 2020 12:50 pm
I'm not averse to supporting shadow RAM on the B if someone is willing to test and put up with frequent breakages. :-) However, unless I'm missing some feature of these boards (I never had shadow RAM on the B BITD, so it's quite possible), I don't think they help that much. The real challenge with Ozmoo is free RAM for game data and since we can run in mode 7 here, shadow RAM only gives us an extra 1K of RAM back. We need sideways RAM to add sufficient memory to the basic 32K to be able to run games without a second processor. Shadow RAM *does* allow Ozmoo to run in mode 0, 3, 4 or 6, and the current SWR prototype allows this already on a Master. The real benefit of shadow RAM is that it gets the screen memory out of the way so we can have as much contiguous free RAM as possible.
With Shadow RAM active, you have access to RAM all the way up to &7FFF. However, if running in Mode 7, and with a bit of smart switching, you should also have access to screen memory between &3000 and &7BFF. The Shadow RAM is generally implemented via a 32k RAM module. Since screen memory only takes up 20k, there is a further 12k of available memory to play with. This is sometimes referred to as 'Private RAM'. The IntegraB uses a small portion of this RAM for some of it's own configuration, but again with some smart switching, the majority is available for general use.

I'd be more than happy to help with testing on B+, Model B with IntegraB and Model B with Watford Shadow RAM. I have access to all three.

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

Re: PunyInform and Ozmoo

Post by SteveF » Fri Aug 07, 2020 1:20 pm

KenLowe wrote:
Fri Aug 07, 2020 1:11 pm
SteveF wrote:
Fri Aug 07, 2020 12:50 pm
I don't know what the copyright status is on these games; I don't personally object if you want to do it, but could you please hold off a bit to give Fredrik and the stardot admins a chance to voice an opinion?
I think most of the early Infocom games are now considered Abandonware and are freely available for download. I was more concerned about releasing images with a potentially incomplete (or not fully tested) z-machine interpreter.
From that point of view, it might be best if you hold off for a few days as I hope to push an alpha (feature complete, but potentially buggy) release of the combined tube/sideways RAM version shortly, and then at least those images will be generating bug reports on that code, rather than the current slightly outdated code.
KenLowe wrote:
Fri Aug 07, 2020 1:11 pm
With Shadow RAM active, you have access to RAM all the way up to &7FFF. However, if running in Mode 7, and with a bit of smart switching, you should also have access to screen memory between &3000 and &7BFF. The Shadow RAM is generally implemented via a 32k RAM module. Since screen memory only takes up 20k, there is a further 12k of available memory to play with. This is sometimes referred to as 'Private RAM'. The IntegraB uses a small portion of this RAM for some of it's own configuration, but again with some smart switching, the majority is available for general use.
I hope to be able to support the 12k "private RAM" on the B+; where in the memory map does the IntegraB make its private RAM available? Using the spare 19k of shadow RAM between &3000-&7BFF might be tricky, as at least part of the Ozmoo code itself will live in that region and it could end up switching itself out unless carefully arranged. I'm not going to say it's impossible, but I think that would be something to look at once the sideways RAM and shadow-RAM-for-screen-RAM version is tested and working.

On the plus side, doesn't the Integra B have vast quantities of sideways RAM as well? That should be supported more or less automatically by the new version and may well make the more complex options unnecessary.

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

Re: PunyInform and Ozmoo

Post by KenLowe » Fri Aug 07, 2020 1:44 pm

SteveF wrote:
Fri Aug 07, 2020 1:20 pm
From that point of view, it might be best if you hold off for a few days as I hope to push an alpha (feature complete, but potentially buggy) release of the combined tube/sideways RAM version shortly, and then at least those images will be generating bug reports on that code, rather than the current slightly outdated code.
Yup. No problem.
SteveF wrote:
Fri Aug 07, 2020 1:20 pm
I hope to be able to support the 12k "private RAM" on the B+; where in the memory map does the IntegraB make its private RAM available?
&8000 - &AFFF. I think it's the same as the B+ in that regard. Here's an extract from the IntegraB manual:
IntegraB 8-3.PNG
IntegraB Shadow & Private RAM Implementation
SteveF wrote:
Fri Aug 07, 2020 1:20 pm
On the plus side, doesn't the Integra B have vast quantities of sideways RAM as well? That should be supported more or less automatically by the new version and may well make the more complex options unnecessary.
Indeed it does. By default it has 4 x 16k RAM banks, and this can be easily extended all the way up to 12 by installing an extra four 32k RAM modules. But sometimes nice to have that space reserved for ROMs, and use the Shadow RAM first if it's available. However, I accept that less people will have a Shadow RAM option (I'm working on a new IntegraB board that will hopefully address that!), so priority should be to get it working on SWRAM first.

As an aside, some of the later Level 9 graphical adventure games (eg Lancelot) required both Shadow and SWRAM if you wanted to get the graphics. Without shadow RAM you could only play the games in text mode, and even then you still needed a couple of SWRAM banks.

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

Re: PunyInform and Ozmoo

Post by SteveF » Tue Aug 11, 2020 7:26 pm

I'm both proud and nervous to present "alpha 1" of Acorn Ozmoo 3.4. I'll probably do some rambling technical posts about this later, but from a user perspective, here's what's new:
  • You can now run without a second processor if you have at least 16K of sideways RAM. Up to 144K of sideways RAM will be used automatically. Second processors and sideways RAM are detected automatically.
  • If you have shadow RAM or a second processor, you can run in modes 0, 3, 4, 6 or 7, i.e. text resolutions between 40x25 and 80x32.
  • The status line is shown in colour in mode 7.
  • You can press CTRL-F and CTRL-B at the game prompt to change the foreground and background colours. (In mode 7 CTRL-F changes the colour of the status line and CTRL-B does nothing.)
  • Both hardware scrolling (fast, a bit ugly) and software scrolling (slow, prettier) are now supported - before only software scrolling was used. If you use modes 0-6 it will default to hardware scrolling, mode 7 will default to software scrolling. Except on a model B with no shadow RAM or second processor (where hardware scrolling isn't supported), you can press CTRL-S to toggle between these options - you'll heard a bleep when you do this.
On a model B with no shadow RAM or second processor, a trick is used to move the mode 7 screen RAM to &3C00. Some emulators don't support this, so if you have problems either switch to B+/Master/second processor mode or try a different emulator.

You can download a .zip or .tar.gz file of the source code from github or you can get it directly using the git command line tool:

Code: Select all

git clone https://github.com/ZornsLemma/ozmoo.git
cd ozmoo
git checkout stardot-ozmoo-preview-2020-08-11-alpha-1
If you already cloned the repository earlier, I think this will work:

Code: Select all

cd ozmoo
git fetch
git checkout stardot-ozmoo-preview-2020-08-11-alpha-1

Once you have the code and the necessary prerequisites (python, acme and beebasm 1.09) installed, the process to make a disc image from a Z-code game is the same as before:

Code: Select all

python make-acorn.py your-game-filename-here
If you plan to play on real hardware using a real floppy drive, passing a '-2' option after make-acorn.py to build a double-sided disc image will improve the performance. (This works on an emulator as well, of course, but you're less likely to see any benefit from it.)

Please report any bugs here and I'll take a look; please pass a '-vv' option after make-acorn.py when building and include the output in your bug report. Please also report the exact hardware configuration/emulator you're using as it can make a big difference.

If you do run into problems, the following might help (but please still report the problem, as these are workarounds and shouldn't be necessary):
  • The mode 7 colour status bar is mildly hacky, particularly for Z4+ games. You can pass a '-7' option after make-acorn.py to disable this if it's causing problems for a particular game.
  • If you get errors about the "Acorn screen hole", pass a '--no-hole-check' option after make-acorn.py to disable it. Note that if you build with this option the game will be broken on a BBC B with no shadow RAM or second processor.
  • If the sideways RAM version breaks for you, pass a '--no-dynmem-adjust' option after make-acorn.py to disable an attempt to maximise the use of available sideways RAM.
  • Try toggling between hardware/software scrolling (CTRL-S) and see if that helps.
Requests for advice/assistance:
  • I would expect this to work on an Integra-B, but I can't even get it to load properly in BeebEm 4.15 in Integra-B mode. Ken - if you could try it on real hardware and let me know how you get on I'd appreciate it.
  • I'm not absolutely sure what's going on, but in BeebEm 4.15 using an 8271 disc controller there seems to be a warning about the disc format being misidentified. Using a 1770 disc controller seems to work fine.
  • I've seen problems with the second processor version when using an emulated model B and DFS 0.9 in b-em. I don't know if this is expected to work or not.
  • I'd like to be able to use memory from &1100/&1300 upwards on a B/B+ (depending on whether we need to open a single file handle or not), but issues like this make me think that's just not a safe proposition. (Remember an OS error could occur during a save or restore, and the game needs to carry on.) If anyone knows how to make this work reliably, or to detect machines where it is safe to do this, please let me know.
I plan to make further enhancements (at the very least I would like to try supporting the B+ private 12K RAM, and I suspect the Integra-B equivalent will be possible too) but there's enough new code in this release that I thought it would be good to get some user feedback on its reliability before adding extra complications.

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

Re: PunyInform and Ozmoo

Post by KenLowe » Tue Aug 11, 2020 9:53 pm

Nice one Steve. Excellent update =D> =D> =D>. I really like the Mode 0, 80 column screen. A couple of initial observations:
  • I no longer get the error when trying to build the .z5 file. That now appears to be working fine.
  • With the Tube enabled, everything seems to work fine.
  • With the Tube disabled, banks 6, 7, 8, 9, A & B on my IntegraB board (OSMODE 0) are being identified as SWRAM. I actually have SWRAM in banks 4, 5, 6 & 7. Banks 4 & 5 are write enabled so should be identified as SWRAM. Banks 6 & 7 are write protected, so should be identified as ROM. I have nothing in banks 8, 9, A & B. I'm not sure why banks 4 thru 7 are not being correctly identified, but 8 thru A are probably falling foul of this capacitance issue. I eventually get a FATAL ERROR: 8 error when it finishes loading; presumably because it's been writing to non existent (and write protected) SWRAM banks
Edit 1: Thinking about banks 4 & 5; these contain valid ROM images, so that's perhaps why these banks not being identified as available I'll wipe those banks and try again.
Edit 2: Yes, wiping banks 4 & 5 made those available. That's probably a good feature; not using a bank that has a valid ROM image installed. Still not sure why a write protected bank is being identified as SWRAM, though.
Edit 3: Selecting OSMODE 4 on the IntegraB board, banks 4 & 5 are the only banks being identified as SWRAM, which is correct. Shadow RAM is also being correctly identified. However, it then hangs at this point.
Last edited by KenLowe on Tue Aug 11, 2020 10:11 pm, edited 1 time in total.

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

Re: PunyInform and Ozmoo

Post by SteveF » Tue Aug 11, 2020 10:09 pm

KenLowe wrote:
Tue Aug 11, 2020 9:53 pm
Nice one Steve. Excellent update =D> =D> =D>. I really like the Mode 0, 80 column screen. A couple of initial observations:
Thanks, I'm glad to know it's mostly working! With so many new moving parts I was a bit worried it would fall over as soon as someone else used it.
KenLowe wrote:
Tue Aug 11, 2020 9:53 pm
  • With the Tube disabled, banks 6, 7, 8, 9, A & B on my IntegraB board are being identified as SWRAM. I actually have SWRAM in banks 4, 5, 6 & 7. Banks 4 & 5 are write enabled so should be identified as SWRAM. Banks 6 & 7 are write protected, so should be identified as ROM. I have nothing in banks 8, 9, A & B. I'm not sure why banks 4 thru 7 are not being correctly identified, but 8 thru A are probably falling foul of this capacitance issue. I eventually get a FATAL ERROR: 8 error when it finishes loading; presumably because it's been writing to non existent (and write protected) SWRAM banks
Edit 1: Thinking about banks 4 & 5; these contain valid ROM images, so that's perhaps why these banks not being identified as available I'll wipe those banks and try again.
Edit 2: Yes, wiping banks 4 & 5 made those available. That's probably a good feature; not using a bank that has a valid ROM image installed. Still not sure why a write protected bank is being identified as SWRAM, though.
I think you've hit the answer with banks 4 and 5 - the sideways RAM detection ignores anything with a language or service entry.

As for the other detection errors, I suspect they're a combination of the capacitance issue you've identified and/or "ghosting" (I can't remember the right term; there was a post about it which I can't find any more) where values stay on the data bus and fool sideways RAM detection code into thinking it has stored a value in a RAM bank which doesn't exist. The sideways RAM detection code is assembled via the BASIC assembler so it's easy to examine/tinker with (just load LOADER into BASIC), or the source is in text form on github. If you or anyone else can suggest improvements here I'm more than happy to tweak the code.

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

Re: PunyInform and Ozmoo

Post by KenLowe » Tue Aug 11, 2020 10:19 pm

SteveF wrote:
Tue Aug 11, 2020 10:09 pm
I think you've hit the answer with banks 4 and 5 - the sideways RAM detection ignores anything with a language or service entry.
Ok. That makes sense. Still not sure why banks 6 & 7 are being detected as SWRAM, though.
SteveF wrote:
Tue Aug 11, 2020 10:09 pm
As for the other detection errors, I suspect they're a combination of the capacitance issue you've identified and/or "ghosting" (I can't remember the right term; there was a post about it which I can't find any more) where values stay on the data bus and fool sideways RAM detection code into thinking it has stored a value in a RAM bank which doesn't exist.
I provided a link above to an earlier post I made about this issue. Here it is again, more obvious this time:

viewtopic.php?p=283216
SteveF wrote:
Tue Aug 11, 2020 10:09 pm
The sideways RAM detection code is assembled via the BASIC assembler so it's easy to examine/tinker with (just load LOADER into BASIC), or the source is in text form on github. If you or anyone else can suggest improvements here I'm more than happy to tweak the code.
I had a quick look at the loader, but would need to take a bit more time to see if we could make it more robust to this issue.

BTW, I made an edit to my previous post (Edit 3) at the same time as you posted your reply, adding a little bit more info about the OSMODE differences.

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

Re: PunyInform and Ozmoo

Post by SteveF » Tue Aug 11, 2020 10:20 pm

KenLowe wrote:
Tue Aug 11, 2020 9:53 pm
Edit 3: Selecting OSMODE 4 on the IntegraB board, banks 4 & 5 are the only banks being identified as SWRAM, which is correct. Shadow RAM is also being correctly identified. However, it then hangs at this point.
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.

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

Re: PunyInform and Ozmoo

Post by SteveF » Tue Aug 11, 2020 10:22 pm

KenLowe wrote:
Tue Aug 11, 2020 10:19 pm
I provided a link above to an earlier post I made about this issue. Here it is again, more obvious this time:

viewtopic.php?p=283216
Cheers, it looks like you/Stephen/Mark had some suggestions in there which might work. I'll see if I can tweak the loader.

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

Re: PunyInform and Ozmoo

Post by KenLowe » 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.

Post Reply

Return to “8-bit acorn software: other”