Master MOS disassembly

[tom_seddon]

A (work in progress) rebuildable, partially commented disassembly of the MOS parts of Acorn MOS for the Master series: https://github.com/tom-seddon/acorn_mos_disassembly - builds all the released versions for the Master (3.20, 3.50, 4.00. 5.00, 5.10, 5.11), and four variants: the Olivetti PC128S MOS, and 3 interesting additional versions Pernod suggested.

All of this is a work in progress, and the source is more than a little inscrutable in some places (for now, I've erred on the side of unifying significant duplicated code and tying it all together with .includes, rather than keeping things actually readable), but there's enough there to give an idea of what's going on, and the .lst files are fairly readable. (Mark Moxon, TobyLobster and level7 have set a high bar for disassembly projects, in terms of presentation of results and quality of commentary, and I'm sorry this one doesn't match theirs! But I do at least intend to try postprocessing the .lst files to create something a bit prettier.)

More than a few comments and labels have come from TobyLobster's excellent MOS reassembly, as there is some overlap with earlier versions of the OS, and from JGH's original disassembly.

--Tom

[dominicbeesley]

Excellent! This is something I keep meaning to look at but haven't worked up the energy. I'm sure you've done a much more consistent job than I would!

I'll try and get a dive into it soon.

D

[tom_seddon]

Excellent! This is something I keep meaning to look at but haven't worked up the energy. I'm sure you've done a much more consistent job than I would!

I'll try and get a dive into it soon.

Thanks for the note and I hope you find it useful. I think it's worthwhile in its current form, but (as you'll find out) there are still numerous holes! But this as a long-term project for me, so they'll get plugged as time goes on. I'll just be chipping away at this as time/inclination takes me. But PRs/notes/etc. are always welcome if you (or anybody else) find anything interesting of course!

--Tom

P.S. JGH has a disassembly of the Electron MOS too: https://mdfs.net/Info/Comp/Acorn/Source/MOS.htm - doing something starting from this is on my todo list as well. At least there'll only be one version of it this time

[tom_seddon]

I've updated the build process to produce two extremely experimental and (so far) very under-tested new builds of the Master MOS: 3.20(NT) and 3.50(NT).

NT = No Terminal: the terminal code has been removed, replaced with the extra code previously stuffed into some other sideways ROM bank. The MOS code is now confined to the MOS region and bank 15, so, in theory, when putting together a new MegaROM, you can put whatever you like in banks 9-14.

Some restrictions on MegaROM layout remain: MOS 3.20(NT) still has no SRAM utilities, so you'll need to get them from somewhere somehow (or live without); and MOS 3.50(NT) does not change the fact that MOS 3.50 DFS and ADFS are related, so you can't put those two ROMs just anywhere. (For more about this: https://mdfs.net/Info/Comp/BBC/SROMs/MegaROM.htm)

Once a suitable adapter for my IC programmer arrives, I'll be running 3.20(NT) in my own Master, and occasionally trying 3.50(NT), so while there may be some issues with the builds so far, in the long run they'll get fixed.

--Tom

[dominicbeesley]

Good work. Getting to this point is a milestone and something that should be of real use.

[Kevin Edwards]

Awesome work.

I'd love to see someone tackle the Acorn Communicator OS one day. I'm sure there's a dump of the ROMs somewhere?

[dominicbeesley]

I'm on it. Hoping to post something half useful in the next week or so.

D

[Kevin Edwards]

Awesome. Looking forward to seeing it!

[arg]

I'd love to see someone tackle the Acorn Communicator OS one day. I'm sure there's a dump of the ROMs somewhere?

If you get as far as the Econet module, I have a printout of the original source (probably only an early version, but still potentially useful).

[Kevin Edwards]

I wish I'd kept hold of the Acorn Communicator manual I had!

[tricky]

Re *(NT), it would be great to have a version that sent the IRQ to ram, like the NMI, but I guess this would break all the timing in your demos and my games unless...

[Pernod]

I'm on it. Hoping to post something half useful in the next week or so.

Looking forward to this, and hope it helps me understand how the teletext hardware is enabled when MODE7 is selected.

[tom_seddon]

Re *(NT), it would be great to have a version that sent the IRQ to ram, like the NMI, but I guess this would break all the timing in your demos and my games unless...

I suspect this would break a lot of stuff in general, not just because the overhead of the IRQ preamble would change (interfering with the chosen timer values), but also because wherever in RAM you copy the preamble (or part thereof) you can absolutely guarantee it will get overwritten by at least one thing and make a big mess

Regarding this sort of breaking change: the original scope for this project (or at least my efforts on it - it's on GitHub, so anybody can fork it!) did not include creating a bunch of new modified versions of the MOS. I decided to do MOS 3.20(NT) and MOS 3.50(NT) because it seemed like these would represent two useful new versions of the MOS, that would involve only simple changes to the code, and would (in theory) not interfere with general compatibility.

But the long term plan has always been to set up the source code so that it would be more amenable to this sort of modification! Even if I won't necessarily end up doing this kind of thing myself - though never say never - I intend to find (and add conditional errors or warnings for) all the alignment restrictions, and track down all the non-obvious label references that would interfere with rearranging the code, and ideally turn the current mishmash of version number checks into a more structured set of checks for feature flags that can be turned on or off as independently as is feasible.

--Tom

[tom_seddon]

I've added a CI setup, so you can get an up to date set of listing files and (experimantal, untested, at your own risk, etc.) No Terminal ROMs from the GitHub releases page: https://github.com/tom-seddon/acorn_mos ... ses/latest

(I'll continue pushing new copies of the dist files to the repo itself occasionally for now, as it comes in handy for hotlinking to specific lines.)

The experimental NT ROMs also have their own separate README here now: https://github.com/tom-seddon/acorn_mos ... docs/NT.md

--Tom

[Ukwebb]

Hi Tom
Couple of quick questions - now I'm getting time to play with this ....
I've been able to build the Images from your Git page now
1. Do I need to extract the Character Set section of rom and include that into the top of Rom 15 ?
2. is there anything else similar required ? or just burn the first 16k and the last 16k from the build for 3.20nt/3.50nt
3. for the original - non NT versions, what is the very small (2 or 3k) EXT.ROM for? is that the bit thats ontop of view? is there a specific start address if so?

3. Do these builds include the y2K fixes and other bug fixes eg the *MOVE bug and OSBYTE &6B bug etc?
4. if not - I'm guessing where these mods go will have moved ?
5. if not- would it be easy to include them?

[Coeus]

Hi Tom
3. Do these builds include the y2K fixes and other bug fixes eg the *MOVE bug and OSBYTE &6B bug etc?

What is this *MOVE bug? Is this the one where the file permissions on non-DFS filing systems are set to inaccessible to anyone? Where is the fix?

[Ukwebb]

its in JGH's BUILDMOS program
https://mdfs.net/Info/Comp/BBC/SROMs/MegaROM.htm

[tom_seddon]

1. Do I need to extract the Character Set section of rom and include that into the top of Rom 15 ?
2. is there anything else similar required ? or just burn the first 16k and the last 16k from the build for 3.20nt/3.50nt

Not sure which section step 1 refers to - step 2 should be all that's required. Look in build/320nt/ or build/350nt/, and use mos.rom for the MOS area and utils.rom for ROM 15. There shouldn't be anything else that needs doing (but please report back if you find otherwise - these builds have had only the briefest of quick tests in my emulator).

3. for the original - non NT versions, what is the very small (2 or 3k) EXT.ROM for? is that the bit thats ontop of view? is there a specific start address if so?

You can ignore these - the contents of build/320/, build/350/, etc., are just temporary files and not designed for use. When building the standard ROMs, the build result is the assembler .lst file only.

3. Do these builds include the y2K fixes and other bug fixes eg the *MOVE bug and OSBYTE &6B bug etc?

No - at least, not currently! For now, 3.20(NT) and 3.50(NT) are deliberately identical to 3.20 and 3.50, aside from the lack of Terminal. I'll make another post about this.

4. if not - I'm guessing where these mods go will have moved ?
5. if not- would it be easy to include them?

Yes and yes, in that order! For now, you can fix these in place:

For OSBYTE &6B, this line here, I think: https://github.com/tom-seddon/acorn_mos ... .s65#L9984 - the MOS 3.50 code is correct

For the basic Y2K fix, that's just patching one lda, so it's always 20xx. I think it's this one here, which should be lda #$20: https://github.com/tom-seddon/acorn_mos ... c.s65#L467

The *MOVE bug is here: https://github.com/tom-seddon/acorn_mos ... .s65#L1602 - change lda #$f0 to lda #$20 (I think)

These spot bug fixes would be perfect candidates for feature flags, making them easier to add or remove. I've added a GitHub issue about this: https://github.com/tom-seddon/acorn_mos ... /issues/25

--Tom

[james]

{deleted}

[tom_seddon]

Regarding new builds: producing new builds of the MOS was deliberately not a goal of this project, but 3.20(NT) and 3.50(NT) looked just too easy to ignore. And these 3 small fixes look useful too, so, really, it would be nice to have a build with them included.

(Producing new builds remains not a goal of this project! - however it looks like it will be producing them anyway...)

Part of the reason for not wanting to change more than absolutely necessary to produce the NT builds is that the MOS version numbering scheme is weird, and not very good, and I didn't want to contribute to the issue by calling some updated version 3.21, say, and then conflict with somebody else's 3.21. (JGH has one, for example! And I bet it's not the only one.) There's already a bit of this with the modern builds of ADFS, which try to fit in with the Acorn numbering scheme, with (to my taste) mixed results.

So, current plan, and so far it is just a plan (comments sought): I'll create 3 new version lines, so new features and tweaks can go in and there'll never be any version number mixups. (And there'll also be room for a lot more versions before the initial supply of numbers is exhausted.) And this thread contains a perfect set of inaugural fixes:

MOS 6.xx - derived from MOS 3.20, for Master 128 only. 6.00 will be equivalent to 3.20(NT) plus 3 fixes: OSBYTE &6B, Y2K, *MOVE.

MOS 7.xx - derived from MOS 3.50, for Master 128 only. 7.00 will be equivalent to 3.50(NT) plus 2 fixes: Y2K, *MOVE. (OSBYTE &6B is already fixed in MOS 3.50.)

MOS 8.xx - derived from MOS 5.10, for Master Compact/PC128S only. 8.00 will be equivalent to 5.10 plus 2 fixes: OSBYTE &6B, *MOVE. (Y2K doesn't apply as the Compact has no RTC.)

Some random notes:

* The Y2K "fix" will be to treat the date as always 20xx - I think this is enough to make *TIME (etc.) produce valid results. It's still only 2023! We can revisit this decision later
* All 3 lines will also be 32 KB builds: MOS region and ROM 15 only. The Terminal ROM will never be included
* OSBYTE &00 results will not change (however the error text when X=0 will be different)
* OSBYTE &81 results will not change
* MOS 5.11, MOS I5.10C and MOS 4.00 would end up dead ends, but useful fixes (if any are there to be found) can be brought across
* Version numbers will increase in lock step, with all versions being released simultaneously and built from the same source
* I have no current way of testing MOS 8.xx, but MOS 5.10 already had no terminal, so the changes will be pretty minor
* 3.20(NT) and 3.50(NT) will remain as they are
* 3.50 reportedly has some compatibility problems with some software, so it seems worth having a separate version based on 3.20 rather than 3.50
* Compacts usually seem to have MOS 5.10, so probably no point starting from anywhere else

--Tom

[tom_seddon]

A couple more ideas for possible changes:

* remove *X
* go through the MOS bugs and port across any fixes that are easy to do

--Tom

[Ukwebb]

first load up of 3.20NT and 3.50NT on real hardware - and it works a treat
even after the y2k etc patches

I'm a bit torn on the year patch -
On one hand it is 24 years ish now since we needed 19xx
but on the other it is a 1980's machine !

having a little code in there would be great if it can be squeezed in (keeping it to the UNIX Epoch)
if year>70 then Century=19 else Century=20

[tom_seddon]

My own position would be that if you want the 1980s experience, you can install the 1980s ROMs - but it's arguable.

https://beebwiki.mdfs.net/OSWORD_%260E suggests the date range for a 2-digit year would be 1980-2079? - though this could be a 3rd-party invention, as it sounds like the Acorn stuff either ignored the issue, or stored the century separately. (Which the Master MOS could do: note year specified when setting the time, store it in CMOS RAM. Now you're covered for everything! - though somebody does have to write the code.)

Querying the date as BCD values only returns 2 digits, so you'd have to assume in that situation. Maybe upgrade the code to handle one of the data formats where the year is returned. Again, somebody would have to write the code...!

--Tom

[tom_seddon]

https://beebwiki.mdfs.net/OSWORD_%260E suggests the date range for a 2-digit year would be 1980-2079? - though this could be a 3rd-party invention, as it sounds like the Acorn stuff either ignored the issue, or stored the century separately. (Which the Master MOS could do: note year specified when setting the time, store it in CMOS RAM. Now you're covered for everything! - though somebody does have to write the code.)

Oops, idn't notice that NFS uses 1981 as the base date. A 3rd option.

--Tom

[tom_seddon]

What is this *MOVE bug? Is this the one where the file permissions on non-DFS filing systems are set to inaccessible to anyone? Where is the fix?

I thought I'd look at this, as I've mostly only used DFS so I'm not very familiar with the FS attributes system in general. The change alters the $f0 constant in this bit of code in *MOVE, which clears some of the bits in the target file's attributes:

Code: Select all

                lda #$F0                     ; Mask out 'public' access bits
                trb osfileParameterBlock+OSFILEParameterBlock.attributes+0
                lda #$01                     ; Write info on dest file
                jsr OSFILE

So the default code resets bits 4-7; the changed code resets only bit 5.

Bits 4-7 are unused in ADFS and DFS, so hopefully no change in behaviour there.

In NFS, bit 4 means readable by other users and bit 5 means writeable by other users. So previously, a MOVE'd file would have its others-readable and others-writeable flags cleared; with this change, it will retain the others-readable bit.

Hmm... I'm not really sure this counts as a bug, not as such, unless I've misunderstood what's going on? (An ever-present risk!) The default NFS permissions for new files are apparently WR/, so it's somewhat consistent to have MOVE'd files not accessible by others by default. (I'm not going to say the updated behaviour is wrong either though, and it would probably also make sense not to change any of the attribute bits at all...)

--Tom

[Coeus]

The second I have not confirmed (yet)...

Testing this with the Battletank tape, here is a catalogue of the tape:

Rewinding the tape and issuing a *MOVE command to copy this file to ADFS and stopping in the b-em debugger after the OSGBPB to fetch the data from TAPE, the area in page 3 with the details from the last tape block has the info needed:

Code: Select all

03B2 : 42 41 54 54 4C 45 54 41 4E 4B 00 00 00 19 00 00   BATTLETANK......
03C2 : 00 19 00 00 02 00 29 00 80 00 00 00 00 26 76 19   ......)......&v.

but this is not copied to the ADFS file:

So, to make the *MOVE command do what people would reasonably expect across a range of filing system needs a bit more work than changing one mask byte.

In the new NT versions of the MOS, once the code that was once on the end of either View or DFS is in ROM 15, is there much space left to be able to do something like that?

[tom_seddon]

Interestingly, JGH's version of the fix changes this so the mask is &80 and the only bit cleared is the most significant which is "not deletable by others". I am not sure in what way this is an improvement - why that one permission specifically? To me, both the default and not tinkering with the permissions would both make more sense than that.

Welp, looks like I got mixed up - the mask is indeed $80, not $20! But this doesn't make me any less confused.

I was looking at the Econet Advanced User Guide from Chris's Acorns: http://chrisacorns.computinghistory.org ... nuals.html - page 39 says that attribute bit 7 is undefined. But the AUG does say that bit 7 means not deleteable for others.

Either way: I agree

There do seem to be a couple of more serious limitations in *MOVE and the handing of file attributes. The first is behaviour that I have actually seen which that, when copying from DFS to a more recent filing system that supports ADFS/NFS-style permissions, the "readable by you" and "writable by you" permissions are cleared on the new file, because DFS returns them as zero from a OSFILE A=5 call. That overwrites more sensible default permissions assigned to the new file when it was created.

Interestingly, I think it was the Advanced User Guide that documented the permissions other than "Locked" in the least signifcant byte of the file attributes as "not readable by you", "not writable by you" etc. i.e. a 1 means you can't and a 0 means you can. So it looks like someone came up with a scheme to make file permissions transfer nicely from DFS to more modern filing systems and then, in actual implementation, this wasn't done.

The second I have not confirmed (yet) by testing, but looks to be the case reading the code, which is that if copying from RFS/CFS it doesn't bother copying the load and exec addresses across. It seems that decision was based on the fact that CFS does not implement OSFILE A=5 so the *MOVE code can't request the file attributes after it has finished copying the file with OSGBPB. Does CFS put those addresses somewhere when processing the file? It must do, I think, for loading the file via OSFILE but maybe not with OSFIND/OSGBPB.

Good points all round... I hadn't delved into the code to this extent. Add these to the list of possible bugs that could do with fixing. Even if the DFS issue is out of scope (this project does not cover the DFS ROM!), the CFS and RFS are part of the MOS and so fixes for those would be nice to have.

(To be honest, I never really rated *MOVE, as it only works on individual files, and doesn't handle wildcards - not that it's possible to do any better using the generic APIs, of course. Would be good to have it work properly for people that do use it though.)


--Tom

[tom_seddon]

In the new NT versions of the MOS, once the code that was once on the end of either View or DFS is in ROM 15, is there much space left to be able to do something like that?

There probably is. The MOS region is a bit tight, but there's some useful space in the terminal/utils ROM in both cases:

MOS 3.20(NT): MOS = 1 byte, ROM 15 = 1,259 bytes (total: 1260)

MOS 3.50(NT): MOS = 219 bytes, ROM 15 = 483 bytes (total: 702)

(There's a fair bit of extra stuff in 3.50: SRAM utils, Tube language relocation, non-daft CMOS reset. It makes space for it by tightening up the CMOS/*STATUS/*CONFIGURE code and stuffing some of the reset code in the TST area at $fc00...$feff.)

--Tom

P.S. I have a GitHub issue about squeezing the SRAM utils and non-daft CMOS reset into some equivalent of 3.20, which looks like it should be possible, but might require some rearrangement: https://github.com/tom-seddon/acorn_mos ... /issues/19

[tom_seddon]

I've added a separate repo for updated MOS versions: https://github.com/tom-seddon/acorn_mos ... d/releases - they get built from the code in existing disassembly repo, but the release cadence and naming scheme needs to be slightly different, and having a separate repo seems the easiest way to do that.

So far: MOS 6.00 (based on MOS 3.20), MOS 7.00 (based on MOS 3.50) and MOS 8.00 (based on MOS 5.10). Y2K fix + OSBYTE &6B, as appropriate, just to get the ball rolling. (I couldn't convince myself the *MOVE change was unambiguously the right thing, so I left it out for now.)

I don't have any way of testing this stuff on real hardware yet, but I'll be using MOS 6.x or 7.x in my emulator, so if there are any particularly obvious issues then hopefully I'll find them.

--Tom

[Ukwebb]

For simplicity's sake.. (and it's been a long day) are MOS 6,7 & 8, basically mod 3.20, 3.50 and 5.10 respectively but with the stated bug fixes?

I'm more than happy to try them on one of my real masters I'll let you know anything I find.