Master MOS disassembly

[tom_seddon]

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.

Yes, exactly - in fact 6.x and 7.x are based on 3.20(NT) and 3.50(NT) respectively, so no support ROMs required (and no terminal). Just MOS+ROM 15. This will remain the case for any future versions too.

Apologies for fiddling around with the version numbers, but it means all 3 versions can share a numbering scheme, and there's no conflict with any existing versions. (Not sure how many versions there'll end up being! But I've got a shortlist of things I'd like to do.)

--Tom

[jgharston]

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.)

I'd recommend keeping to the 3.xx 4.xx 5.xx scheme. Using 6.xx, 7.xx, 8.xx breaks the link between the textual version number and the underlying MOS machine type. I'd recommend:
MOS 3.20 -> MOS 3.3x MOS 3.4x (ie MOS 3.00+0.3)
MOS 3.50 -> MOS 3.8x MOS 3.9x (ie MOS 3.50+0.3)
MOS 4.00 -> MOS 4.3x MOS 4.4x (ie MOS 4.00+0.3)
MOS 5.xx -> MOS 5.3x MOS 5.4x (ie MOS 5.00+0.3)

with each "increment" sharing functionality, eg 3.33 descended from 3.20 having the same functionality as 4.33 descended from 4.00, having the same functionality as 5.33 descended from 5.00, etc.

[jgharston]

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.)

In the 1980s the general written-up concensus was to use 1980 at the pivot point for two-digit year strings, as it only needed to one character to check: <'8' vs =>'8'. Even only one *bit* to check, bit 3 of the decade character. My first thought is that it might be in an issue of SJ User in the Recommended Programming Techniques discussions.

There's enough space to squeeze in a full 19vs20 check, but - as pointed out by several people - it's 24 years since we needed OSWORD 14 to return 19xx, so why not hard-wire it to 20xx. Somewhere I've got the code. Rummage... ah:

Code: Select all

Patch MOS 3.20:
987D: JSR &B8DF
9880: NOP:NOP

B8DF: JSR &9890
B8E2: CMP #&38
B8E4: LDA #&19
B8E6: BCS &B8EA
B8E8: LDA #&20
B8EA: RTS

Code: Select all

Patch MOS 3.50:
9660: JSR &FB21
9663: NOP:NOP

FB21: JSR &9673
FB24: CMP #&38
FB26: LDA #&19
FB28: BCS &FB2C
FB2A: LDA #&20
FB2C: RTS

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...!

Again, already done! The recommended API for returning the century is to make an OSWORD 14 call with parameter 8+n, which deals with an 8-byte date&time block instead of a 7-byte time&date block.

Code: Select all

8-byte BCD date block format:
 +0 century &00-&99
 +1 year    &00-&99
 +2 month   &01-&12
 +3 date    &01-&31
 +4 day     &01-&07 Sun-Sat or &00 for unsupported
 +5 hour    &00-&59
 +6 minute  &00-&59
 +7 second  &00-&59

See also the wiki. Again, could be squeezed into the spare space.

[tom_seddon]

I'd recommend keeping to the 3.xx 4.xx 5.xx scheme. Using 6.xx, 7.xx, 8.xx breaks the link between the textual version number and the underlying MOS machine type. I'd recommend:
MOS 3.20 -> MOS 3.3x MOS 3.4x (ie MOS 3.00+0.3)
MOS 3.50 -> MOS 3.8x MOS 3.9x (ie MOS 3.50+0.3)
MOS 4.00 -> MOS 4.3x MOS 4.4x (ie MOS 4.00+0.3)
MOS 5.xx -> MOS 5.3x MOS 5.4x (ie MOS 5.00+0.3)

with each "increment" sharing functionality, eg 3.33 descended from 3.20 having the same functionality as 4.33 descended from 4.00, having the same functionality as 5.33 descended from 5.00, etc.

I don't like the limited amount of numbers available here if the versions start working their way through 3.21, 3.22, etc. - what happens once it hits 3.49? Also, you have to do some mental arithmetic to work out which versions are equivalent (in terms of being built from the same version of the code). These issues were what drove me to changing the version numbering entirely, even though that isn't really ideal.

But, looking at MOS 6.00, there's actually still 4 bytes free in the MOS area, so maybe I should have added a version suffix instead? "MOS 3.20.0"; "MOS 3.20+0" - or something? Then the extra number goes up with each additoinal new version. It's very obvious which official version it's based on, and we're not going to run out of numbers. (There is 4 bytes free in the MOS area in 6.00, so this gives 1,000 versions to free up more space.)

There's only been one GitHub release so far, so I can always change things around a bit.

--Tom

[Ukwebb]

Just as an idea... As these are only.really bug fixes of existing versions, What about

MOS3.20A, MOS3.20B, etc..

Is it likely there there will ever be 26 variations of 3.20 ?

( Same logic for the other versions obviously)

If someone ever takes it on to completely rewrite it and create the follow-on to MOS3.5 etc then they can always use the higher numbers

[tom_seddon]

Just as an idea... As these are only.really bug fixes of existing versions, What about

MOS3.20A, MOS3.20B, etc..

Is it likely there there will ever be 26 variations of 3.20 ?

( Same logic for the other versions obviously)

If someone ever takes it on to completely rewrite it and create the follow-on to MOS3.5 etc then they can always use the higher numbers

That's a good idea, and now it only needs 1 byte free - yes, 26 will probably be enough in practice before it becomes different enough to make a version number upgrade worth thinking about. Or maybe 25. Might be worth skipping C, to avoid any confusion with MOS I5.10C (Olivetti PC128S).

I don't have any plans for significant new features, but I'd like to fix whatever annoying bugs it's practical to fix. I do also plan to backport some of the 3.50 features into 3.20, SRAM utilities and Tube language relocation being the main ones. (The code also makes it look like 3.50 and 5.10 could be much more similar than they are currently, but that's probably not worth bothering with.)

I think this will be enough to generate a handful of releases, though I've got no timetable for this, and after that we'll see how it goes.

--Tom

[Ukwebb]

Hi Tom,
Found a slight bug
With 3.50NT and a 6502 co-pro and BASIC 4r32, when the system starts up, BASIC doesn't load properly.
You just get a ' * ' prompt instead, or sometimes just the cursor flashing and a locked up machine
if you do get the * , you can type BASIC and it seems to work

I've tried this in beeb-em and on a real machine
The same issue doesnt appear on 3.20NT, so it may be related to Basic 4.r32 which does have HIBASIC embedded

[tom_seddon]

Hi Tom,
Found a slight bug
With 3.50NT and a 6502 co-pro and BASIC 4r32, when the system starts up, BASIC doesn't load properly.
You just get a ' * ' prompt instead, or sometimes just the cursor flashing and a locked up machine
if you do get the * , you can type BASIC and it seems to work

I've tried this in beeb-em and on a real machine
The same issue doesnt appear on 3.20NT, so it may be related to Basic 4.r32 which does have HIBASIC embedded

Thanks for the report, and I'll investigate when I can. I think there's some code in the MOS to cater for the case where the specified relocation table doesn't exist, but don't quote me on that. (If you put MOS 3.50 BASIC in bank 12 and MOS 3.50 VIEW in bank 14 then hopefully things should work, as then the BASIC relocation table will be exactly where it's expected to be.)

If you don't mind having a non-relocating BASIC, you could clear the Tube transfer address bit in the ROM header: https://beebwiki.mdfs.net/Paged_ROM#ROM_headers

--Tom

[Ukwebb]

I had Basic in 12 anyway but putting View in 14 does make it work
hopefully that may help locate the niggle too

[tom_seddon]

I had Basic in 12 anyway but putting View in 14 does make it work
hopefully that may help locate the niggle too

Yes, very interesting - thanks for trying this! There's a couple of check bytes in the relocation data that the MOS is supposed to check, but I wonder whether its check is actually working as designed? Perhaps this aspect of this feature never got much testing.

If nothing else (and even though it's a bit of a non-fix), I should at least put a non-relocating copy of BASIC 4r32 in the repo. Solving this issue properly is always going to require a bit of DIY, or an external tool, as the relocation data has to go in some other ROM and the BASIC ROM needs to know which ROM it is; but a non-relocating BASIC 4r32 would be something that you could put in a custom MegaROM without having to worry about it. (It'd run fine in the 2nd processor, but HIMEM would end up at &8000, same as with any other non-HI version of BASIC.)

--Tom

[Coeus]

The relocation does sound like it would be the issue. It is definitely possible for a ROM to say which other ROM contains its relocation table. In the NT versions, would the relocation data fit the space vacated by the terminal code? It would be great if all the ROMs in a custom MegaROM were independent just like on a Model B but most people are going to want BASIC and anyone with a 6502 c-o-pro is likely to prefer the relocating version of BASIC.

While we're on that, isn't there a bug fix to BASIC 4r32 to fix the accuracy of some calculations?

[hoglet]

While we're on that, isn't there a bug fix to BASIC 4r32 to fix the accuracy of some calculations?

Yes, and fixes are detailed here:
https://github.com/hoglet67/BBCBasic4r3 ... /README.md

See also BigEd's thread: Bugs in log and trig functions of Basic 4r32

[tom_seddon]

The relocation does sound like it would be the issue. It is definitely possible for a ROM to say which other ROM contains its relocation table. In the NT versions, would the relocation data fit the space vacated by the terminal code? It would be great if all the ROMs in a custom MegaROM were independent just like on a Model B but most people are going to want BASIC and anyone with a 6502 c-o-pro is likely to prefer the relocating version of BASIC.

JGH's MegaROM page suggests that the BASIC relocation table is 605 bytes: https://mdfs.net/Info/Comp/BBC/SROMs/MegaROM.htm - and there would actually be room for this, just! Though sadly there's no contiguous region currently large enough

Current free space:

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)

The relocation data ends with two telltale bytes, $c0 and $de, and it does look like the relocator checks for this: https://github.com/tom-seddon/acorn_mos ... s65#L13479 - so in theory things should work if there's no relocation data at the address specified by unmodified BASIC 4r32, which is $c000-1 downards in (current bank)+2.

I had Basic in 12 anyway but putting View in 14 does make it work
hopefully that may help locate the niggle too

If you've been pasting data into an existing MegaROM image, check there's no $c0, $de at the end of where the View ROM used to be!

--Tom

[Ukwebb]

If you've been pasting data into an existing MegaROM image, check there's no $c0, $de at the end of where the View ROM used to be!

Just the two files MOS 350 NT and UTILS 350 NT in the #00000 and #1C000 slots
Basic4r32 into Rom 12, and adfs203/dfs245 etc in their usual places all from the old master megarom

Putting ViewB3.3 (again from the old master megarom) in Rom 14 as you suggested does work though

[tom_seddon]

Just the two files MOS 350 NT and UTILS 350 NT in the #00000 and #1C000 slots
Basic4r32 into Rom 12, and adfs203/dfs245 etc in their usual places all from the old master megarom

Putting ViewB3.3 (again from the old master megarom) in Rom 14 as you suggested does work though

I had a chance to try this in the emulator this evening, and discovered this occurs wih ordinary MOS 3.50 as well! If you remove the View ROM, BASIC 4r32 doesn't work in the second processor. Looks like MOS 3.50 checks for the 6502 ROM relocation bitmap, but doesn't reset the ROM's base address to $8000 if it wasn't found. So you'll end up with the unrelocated ROM copied to its relocated address... crash!

I'll sort out including a non-relocatable BASIC 4r32 that'll be useable with 3.50(NT). If View/ViewSheet/EDIT are relocatable too I'll fix those up as well. It's just 1 bit to clear in the header.

I'll be able to fix this bug for the refreshed versions, I think. (First port of call however is to fix up the versioning scheme, which I'll get done in the next few days.)

--Tom

[BigEd]

It does feel like a bug worth fixing, but I think having the single Basic be also a HiBasic is a nice feature, and very handy for a system which might well have a 6502 second processor hanging off the Tube.

[Ukwebb]

I'll sort out including a non-relocatable BASIC 4r32 that'll be useable with 3.50(NT). If View/ViewSheet/EDIT are relocatable too I'll fix those up as well. It's just 1 bit to clear in the header.

just to ask - by "sort out"/ "fix" - do you mean disable? ie so they no longer make use of the copro?
if so that would be a shame

given the choice - having to include View would be better than not having hibasic & hiview

[markusher]

It does feel like a bug worth fixing, but I think having the single Basic be also a HiBasic is a nice feature, and very handy for a system which might well have a 6502 second processor hanging off the Tube.

Especially as the Pi CoPro has made a copro available to a wider user base.

[tom_seddon]

The modified BASIC 4r32 would act as non-HI BASIC, so it would work on the 6502 second processor but with HIMEM at $8000. Using this would be entirely optional, and provided as a convenience for use with MOS 3.50(NT) if you want to use a 2nd processor with BASIC 4r32.

Your current options with MOS 3.50 or MOS 3.50(NT) and BASIC 4r32 and 2nd processor are:

1. BASIC 4r32 in bank N, MOS 3.50 View in bank N+2 - works as HIBASIC in 2nd processor
2. Some other version of BASIC - works as BASIC is 2nd processor
3. BASIC 4r32 in bank N, no MOS 3.50 View - crashes when used in 2nd processor, unless entered via *BASIC, in which case it works as BASIC

This additional ROM would be there to give you a straightforward additional option:

4. BASIC 4r32 (non-relocateable) in any bank you like - works as BASIC in 2nd processor

Since part of the goal of the No Terminal builds is to make it easier to put together a new MOS MegaROM with anything you like in the other banks, and this modified BASIC 4r32 ROM should be pretty easy to create - should be a question of resetting 1 bit in the header! - it would make sense to provide it.

At some point, probably fairly soon, I will get round to trying to fix this bug, and the fix will hopefully be possible to include in MOS 3.50B (or whatever the actual version number ends up being).

--Tom

[tom_seddon]

I've updated the docs on GitHub with some notes about the MOS 3.50 restrictions: https://github.com/tom-seddon/acorn_mos ... #mos-350nt (looking at it again, now it's on GitHub, I think I can reword this to make it clearer. But it'll do for now)

The release zip now includes non-relocatable versions of BASIC 4r32 and EDIT 1.50r. You can put these in any bank, and they'll work fine in the 2nd processor, but they'll be running in their non-HI forms and so you won't be getting all the memory you could. But they will work!

--Tom

P.S. I do plan to do something a bit similar for DFS+ADFS: https://github.com/tom-seddon/acorn_mos ... /issues/31 - and also ideally figure out how the dependencies work, so that I can document which one you can get away without if necessary, if that's possible. (Any hints welcome; I've never spent any time with the DFS or ADFS code)

[tom_seddon]

I've also updated the versioning scheme for the refreshed versions. 6.xx/7.xx/8.xx are no more. instead, you can download version A: https://github.com/tom-seddon/acorn_mos ... efreshed-A

The zip contains 3.20A, 3.50A and 5.10A, as described here: https://github.com/tom-seddon/acorn_mos ... refresh.md

Current plans for version B: remove *X. Fix the Tube relocation bug.

It does feel like a bug worth fixing, but I think having the single Basic be also a HiBasic is a nice feature, and very handy for a system which might well have a 6502 second processor hanging off the Tube.

I agree. I certainly won't be removing the relocation feature, and in fact I have a couple of plans for improvements to it. This is me just trying to make it easier to work around its limitations without needing to go full DIY.

With the code being in one bank, and the relocation data in another, there's always going to be some self-assembly (of some kind) required if you want to arrange the MegaROM banks differently from the default, but no reason for that to be more annoying than necessary. I'm also cobbling together a Python script for managing Tube relocation bitmaps, which might at least make it marginally less tedious if you're going for the full-customization option.

--Tom

[tom_seddon]

just to ask - by "sort out"/ "fix" - do you mean disable? ie so they no longer make use of the copro?
if so that would be a shame

given the choice - having to include View would be better than not having hibasic & hiview

I think View does its own relocation, though I'm not sure of the details, so it'll be unaffected by any of this.

Thinking about this some more: since there's ~2 KB of spare space in the DFS ROM now, the relocation tables can probably be moved to there. So that would permit a setup like the following, with 3 slots that anything can go in.

15: utils
14: anything
13: ADFS 2.03
12: patched BASIC 4r32 (will also act as HIBASIC)
11: anything
10: anything
9: DFS 2.45 + BASIC relocation bitmap + EDIT relocation bitmap

(I've included both ADFS 2.03 and DFS 2.45; ADFS 2.03 definitely depends on DFS 2.45, so if you use ADFS you need both filing systems. I don't know yet whether DFS 2.45 depends on ADFS 2.30 at all, but it's probably safest to include both...)

The patched BASIC 4r32 will be modified only to change its relocation bitmap address, and will be otherwise identical to the standard one.

The presence of the EDIT relocation bitmap means that a patched EDIT 1.50r (patched as above) could occupy one of the unused slots, and then also act as HIEDIT.

There's 2,304 bytes free in the DFS ROM, and the relocation bitmaps for BASIC (609 bytes) and EDIT (444 bytes) come to 1,053 bytes. So 1,251 bytes still left. Probably enough for a couple more relocation bitmaps!

--Tom

[tom_seddon]

I've released version B: https://github.com/tom-seddon/acorn_mos ... efreshed-B

• 3.20B, 3.50B: RTC year is assumed to be 20xx not 19xx
• 3.20B, 3.50B: remove built-in *X command
• 3.50B: fix handling of missing language ROM Tube relocation bitmaps
• 3.50B: improve language ROM Tube transfer speed

The zip also includes some patched ROMs that you can use if you want HIBASIC and HIEDIT but don't want to spend a bank on View, and I've added some notes about this stuff: https://github.com/tom-seddon/acorn_mos ... MOS3.50.md

I think View does its own relocation, though I'm not sure of the details, so it'll be unaffected by any of this.

I had a quick check, and it does. Looks like the scheme might be quite similar to the MOS one (and was possibly the inspiration for it), just done manually. (This means View can relocate itself slightly higher than would normally be possible, since it's actually less than 16 KB, which it takes advantage of. So instead of ~44 KB space on a 6502 2nd processor, View give you more like 46 KB.)

--Tom

[Ukwebb]

great work Tom
think you've got every option covered there

[jgharston]

Just as an idea... As these are only.really bug fixes of existing versions, What about
MOS3.20A, MOS3.20B, etc..

As long as it streamlines:
MOS |3.|???
MOS |3.|???
MOS |4.|???
MOS |5.|???
etc.
But I'd stll recommend starting at currentbase+3, ie MOS 3.30xxxx, MOS 3.80xxxx, MOS 4.30xxxx, MOS 5.30xxxx as there are already plenty of MOS 3.2x, MOS 3.5x, MOS 5.0x, and MOS 5.1x variants around.

[dominicbeesley]

I think sticking with 3.X numbering is better - more numbers is just more confusing, to me at least...

[tom_seddon]

I went with an alphabetic suffix in the end: 3.20A/3.50A/5.10A, then 3.20B/3.50B/5.10B, - and so on. (C will be skipped, as Olivetti already released I5.10C.)

I think this makes it clear which original version each one is based on, and also makes it clear which version is newer, without reproducing any existing version strings. If I get to the stage of needing to update 3.20Z/3.50Z/5.10Z, I'll think of something.

Hopefully this meets with sufficient approval (or lack of the opposite), as now I've done 2 releases I don't fancy changing it again

--Tom

[geraldholdsworth]

If I get to the stage of needing to update 3.20Z/3.50Z/5.10Z, I'll think of something.

3.21A, 3.51A, 5.11A ?

[tom_seddon]

If I get to the stage of needing to update 3.20Z/3.50Z/5.10Z, I'll think of something.

3.21A, 3.51A, 5.11A ?

I think I'll wait and see how it's looking by that point, if I get there. It's possible that it'll diverge enough to justify new numbers before that point anyway.

Slightly reluctant to reuse 5.11, as there's an actual Acorn version 5.11i - see https://chrisacorns.computinghistory.or ... mpact.html - and it's not quite the same as 5.10. Plenty of letters to go before Future Me has to decide what to do, though, so I'm leaving the decisions up to him

--Tom

[tom_seddon]

After poking around a bit more, I've got a couple of updates to the addresses in https://mdfs.net/Info/Comp/BBC/SROMs/MegaROM.htm that I'm fairly confident about.

ROM bank 9 (DFS):

$8000 - $aeff : DFS 2.45 code
$af00 - $b7ff : MOS 3.50 code
$b800 - $bfff : ADFS 2.03 disk code

There's actually a bit of space free at the end of DFS 2.45 - but it'll be obvious when you're looking. It's a run of $ff bytes.

ROM bank 14 (VIEW):

$8000 - $bbbf : VIEW
$bbc4 - $bd80 : EDIT 1.50r Tube relocation bitmap
$bd9f - $bfff : BASIC 4r32 Tube relocation bitmap

I haven't disassembled VIEW, and I don't intend to, so I guessed at its region from staring at the hex dump. MOS 3.20 View ran to $ba00; another 450-odd bytes doesn't sound outlandish given the extra stuff in MOS 3.50.

--Tom

P.S. for investigating the Tube relocation bitmaps, I put together a Python script: https://github.com/tom-seddon/beeb/tree ... relocation - still needs work (needs a mode to create new bitmaps for your own ROMs; the set command needs some budget-/range-type options so you can insert bitmaps with confidence; etc., etc.) but it's proven useful enough as it stands