Master, MultiOS and Permanent Co-Pro Banner

[acheton1984]

Master128 with internal Acorn 65C102 co-pro, MultiOS, and "Model B MMFS 1.55" in an EPROM on the motherboard. MultiOS is used to select BBC B OS 1.20.

Summary: Despite turning the tube off, the "Acorn TUBE 65C102 Co-Processor" banner is still present after [Break] when running MMFS.

Using the NOTUBE utilitiy from stardot thread "FX Call to turn off 2nd Processor on Model B", it appears to successfully turn the TUBE off over a ctrl-break - ie PRINT~PAGE gives &2100 (rather than &800) and *TEST65 from the TubeUtil disc reports "Not running on Tube".

HOWEVER, despite apparently not running, the banner remains.

Here is the list of ROMs in the machine.

Using ARM (Advanced ROM Manager) to KILL 8 (MMFS), /NOTUBE and Ctrl-Break, gives a startup banner with DFS as the selected FS, PAGE at &1900 and no mention of TUBE:

But, after a power cycle, if I KILL 14 (DFS), /NOTUBE and Ctrl-Break then the TUBE banner is present even though it appears not to be running (PAGE is &1F00)

[hoglet67]

To save me a bit of time, can you post a ZIP containing your complete MultiOS image?

Dave

[acheton1984]

I have no means of extracting the information but I believe I can contact the creator, so I’ll get back to you.On 22 Feb 2024, at 18:50, David Banks @.***> wrote: To save me a bit of time, can you post a ZIP containing your complete MultiOS image? Dave

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[hoglet67]

I've just tried DFS 2.26 and NOTUBE in B-Em, and the benner is present after a control BREAK:

Granted, this a a BBC B rather than a Master, but I think this is just how OS 1.2 / Tube Host 2.30 and NOTUBE work.

This was using the following NOTUBE program:

10 P%=&4000
15 [LDA #0:STA &27A:RTS
20 LDA #3:STA &190+249
30 LDA #159:STA &190+248
40 LDA #76:STA &190+247
50 RTS:]
60 *SAVE NOTUBE 4000+18 FFFF03A5 FFFF039F

Dave

[acheton1984]

Checking for which MultiOS i have, I’ve just broken a pin off the carrier board so can’t add anything further at the moment.On 22 Feb 2024, at 19:11, David Banks @.**> wrote: I've just tried DFS 2.26 and NOTUBE in B-Em, and the benner is present after a control BREAK: image.png (view on web) image.png (view on web) Granted, this a a BBC B rather than a Master, but I think this is just how OS 1.2 / Tube Host 2.30 and NOTUBE work. This was using the following NOTUBE program: 10 P%=&4000 15 [LDA #0:STA &27A:RTS 20 LDA #3:STA &190+249 30 LDA #159:STA &190+248 40 LDA #76:STA &190+247 50 RTS:] 60 SAVE NOTUBE 4000+18 FFFF03A5 FFFF039F

Dave

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[acheton1984]

The Master is working again. I've removed the MMFS ROM from the motherboard and there's no longer any Tube banner at boot into OS 1.20, which leads me to think that the MultiOS DFS probably has the Tube code disabled/removed.

Therefore, I suspect the answer is to compile a copy of MMFS with TUBEHOST=FALSE in top_MMFS.asm. Though that's easier said than done!

[hoglet67]

The Master is working again. I've removed the MMFS ROM from the motherboard and there's no longer any Tube banner at boot into OS 1.20, which leads me to think that the MultiOS DFS probably has the Tube code disabled/removed.

I've built up my own MultiOS that has the same ROMs as your, and that's it looks like the DFS 2.26 that RetroClinic includes is the one from Michael Walker without the Tube Code: https://stardot.org.uk/forums/viewtopic.php?p=38536#p38536

RetroClinics MultiOS manual says:

Using Co-Processors The code for second processors is disabled in OS 1.20 and OS 2.00 modes. If you have a co-processor internally or externally, it will not function under these OSs. This is because when the system is used as a tube host, there is no need for it to be running a downgraded OS, as the main software runs on the second processor. If you want to use your co-processors, please use OS 3.20 or OS 3.50

Therefore, I suspect the answer is to compile a copy of MMFS with TUBEHOST=FALSE in top_MMFS.asm. Though that's easier said than done!

I don't know if you replaced your damaged MultiOS with the one from IFEL. That contains a very sophisticated manager ROM that saves OS 1.20 config settings in some spare CMOS RAM locations. It's actually very cool.

Let me know if you need a specific custom build of MMFS and I can attach it here.

[acheton1984]

The IFEL ones are, sadly, out of stock and the creator said recently on stardot he's having to step away from retro for a while.

I have 2 ukwebb MultiOS ROMS, the new one has a Tubeless MMFS in it but ADFS under MOS 3.x is configured for IDE and the Pi1MHz no longer works. So, I'm sticking with the old MultiOS chip which doesn't have MMFS in it.

As I do have an IFEL RAM/ROM Cartridge, I can easily stick a new Tubeless MMFS ROM image in there.

However, I've download and extracted the code (on an Intel Mac), and run "build.sh MMFS" and get an error almost immediately:

bash-3.2$ ./build.sh MMFS
Building MMFS version 1.55
Using tools/beebasm/beebasm-darwin
Blank build/U/mmfs.ssd created
build/U/mmfs.ssd updated

Building U/EMMFS...
DEVICE.asm:1: error: Bad expression.

_DEVICE_ = "U"
           ^
build failed to create U/EMMFS

DEVICE.asm contains exacly this:

_DEVICE_ = "U"
MACRO SYSTEM_NAME
    EQUS "MMFS"
ENDMACRO
_MM32_      = FALSE

[hoglet67]

What version of BeebASM are you using? You need version 1.10 that supports String variables. Possibly 1.09 would work, 1.08 won't.

[acheton1984]

Ah. beebasm 1.08 is the version in the MMFS respository - replacing it with 1.10 has worked.

MMFS has assembled (with TUBEHOST=FALSE) and the resulting ROM has no Tube banner and PAGE=&1900.

I'm very grateful for your looking and this and help provided - many thanks!