Strange output from 32k RAM in ROM BANK

[CommanderCoder]

I bought a 62256 chip to act as 2 RAM banks in my old issue 7 BBC B. It is plugged into the middle slot of the 5 ROM banks. I've connected pin 27 to IC 77 pin 8 and pin 1 to IC 76 pin 11.

I've got BEEB.MMB plugged into my SmartSPI and disc 5 has some ROM images on it. I am able to load up 2 rom images to the RAM by using

Code: Select all

*CIN 5
*RLOAD TKIT205 5
*RLOAD WWP14F D

Because the Toolkit has *ROMS I can check the roms installed. However when I continue this to test my RAM and use:

Code: Select all

*RLOAD WWP14F 9
*ROMS

I see 3 ROMS installed.

Is this because &FE30 or &F4 is still set to 9 after the RLOAD, or something else?

[1024MAK]

Although there are four ROM sockets (not including the OS socket which is NOT a sideways ROM), the OS in the Beeb can actually handle sixteen ROMs. However the hardware does not fully decode the number stored in the ROM selection register. So for example, the rightmost ROM socket (IC101) is seen be the hardware at ROM section numbers 3, 7, 11 (0x0B) and 15 (0x0F). The OS normally hides this, by checking to see if there are any duplicate ROMs (with an unmodified machine it will find four copies of each ‘normal’ 8k byte or 16k byte ROM) and will only report the ROM in the highest slot. So in this case, the ROM in IC101 will be reported as ROM 15 (0x0F).

The SRAM you fitted will also be subject to this. But because it is 32k byte device wired as two 16k byte devices, each 16k byte ‘half’ will have only two ROM slot numbers.

Normally you have to restart the OS to get it to recognise a ‘new’ ROM. But some utility software updates the table used itself when you use it to load ROM images into RAM. So it is possible that the poor machine is just confused.

Mark

[jgharston]

In the above image, the *ROMS command you have used has taken no account of the contents of the MOS's ROM table, but is purely paging in each bank and displaying what it sees there, so will see what are called reflections of banks where there isn't full decoding. So, paging in bank 5 sees the same as paging in bank 8+5=13.

However, the MOS checks each bank on RESET and clears the ROM table where there is a duplicate, so anything done through the MOS is not passed to the lower-numbered duplicates. If you use a *ROMS command that goes through the MOS's ROM table you will see the duplicates removed. Often this will be in brackets, or with the ROM type byte listed as zero, eg:

>*ROMS
15 BASIC
14 DFS
13
12
11 (BASIC)
10 (DFS)
etc

or
>*ROMS
15 -L BASIC
14 S- DFS
13 SL WORDWISE
12
11 -- BASIC
10 -- DFS
9 -- WORDWISE
etc.

Some *ROMS commands will count the ROM table and only display what is not duplicated, eg:
>*ROMS
15 BASIC
14 DFS
13 WORDWISE
12
>

And some *ROMS commands will take a parameter to force it to enumerate every bank regardless of duplicates, eg:
>*ROMS
15 BASIC
14 DFS
13 WORDWISE
12
>*ROMS *
15 BASIC
14 DFS
13 WORDWISE
12
11 (BASIC)
10 (DFS)
9 (WORDWISE)
8
7 (BASIC)
6 (DFS)
5 (WORDWISE)
4
3 (BASIC)
2 (DFS)
1 (WORDWISE)
0
>

[CommanderCoder]

Ah thanks. I think I get it. It's some artefact of RLOAD and MOS not keeping in sync; and then *ROMS (part of the TOOLKIT) displaying what it can from MOS or just scanning by itself.

[jgharston]

No no no no no. It's not an artifact of *RLOAD or the MOS. It's an artifact of the hardware and the specific *ROMS command that you have used.

In an unexpanded BBC when you page in bank 4 you will see the same physical hardware as paging in bank 0 and paging in bank 8 and paging in bank 12. This NOTHING TO DO WITH THE MOS and is NOTHING TO DO WITH *RLOAD/*SRLOAD/whatever. It is solely and completely the hardware.

*RLOAD/*SRLOAD will load the specified file, page in the specified bank, and copy the file into that bank. But there is absolutely nothing it can do to stop the hardware being able to see that image by paging in any of the other the three other banks.

Some versions or *SRLOAD will also set the MOS's ROM table byte so that the newly-loaded image it will respond to ROM calls. But all that does is enable it to be visible *to* *the* *MOS* in the bank that you loaded it to. The MOS will still not "see" anything in the three reflections because the ROM table byte for the reflections hasn't been set. *AND* it will still not prevent the hardware being able to see that bank in three other banks, because it is the *hardware* that sees those reflections, *NOT* the MOS, and *NOT* *RLOAD/*SRLOAD.

The reason you are seeing a list showing reflections is *SOLELY* down to *that* *specific* *ROMS command, *NOT* the MOS and *NOT* *RLOAD/*SRLOAD.

The only difference to the above explanation is that your machine has eight physical slots due to using 32K devices, so you have two refelections or each bank.

[CommanderCoder]

Thanks for the comprehensive explanation. So it has nothing to do with *RLOAD or MOS. Just the hardware and that *ROM command.

[sweh]

No no no no no. It's not an artifact of *RLOAD or the MOS. It's an artifact of the hardware and the specific *ROMS command that you have used.

It _could_ be the *RLOAD command if that does &2A1?slot=?&8006 or similar after loading the image, and before pressing BREAK. I don't know what RLOAD command is being used; it's clearly something on the disk (from the screenshot) and not from a ROM.

Now as a test, I just *SRLOAD'd a ROM into RAM banks 4, 5, 6 on my Beeb. Then pressed BREAK. The TOOLKIT PLUS "*ROMS" command (which I think is the one being used here, since that's what shows in the original screenshot) only showed the ROM in slot 6. But if I mangle the table at &2A1 then the command showed all 3 ROMs.

So I think *RLOAD is doing a nasty, here!

[KenLowe]

Now as a test, I just *SRLOAD'd a ROM into RAM banks 4, 5, 6 on my Beeb. Then pressed BREAK. The TOOLKIT PLUS "*ROMS" command (which I think is the one being used here, since that's what shows in the original screenshot) only showed the ROM in slot 6. But if I mangle the table at &2A1 then the command showed all 3 ROMs.

So I think *RLOAD is doing a nasty, here!

Wouldn't you get the ghost copies if you just *RLOAD roms into RAM banks and then use *ROMS to list them, without pressing BREAK first, which is what the OP seems to be doing?

[sweh]

Now as a test, I just *SRLOAD'd a ROM into RAM banks 4, 5, 6 on my Beeb. Then pressed BREAK. The TOOLKIT PLUS "*ROMS" command (which I think is the one being used here, since that's what shows in the original screenshot) only showed the ROM in slot 6. But if I mangle the table at &2A1 then the command showed all 3 ROMs.

So I think *RLOAD is doing a nasty, here!

Wouldn't you get the ghost copies if you just *RLOAD roms into RAM banks and then use *ROMS to list them, without pressing BREAK first, which is what the OP seems to be doing?

Not with my *SRLOAD command 'cos that doesn't mangle the table at &2A1.

The TOOLKIT PLUS *ROMS command looks at this table and only reports on entries with a non-zero.

Which we can demonstrate by mangling the table

Code: Select all

>*ROMS
     0 S   65C02 ASSEMBLER 1.60 (C)1987
     1
     2 S   TOOLKIT PLUS (C)1985 Beebugs
     3 LR  BASIC (C)1982 Acorn
     4
     5
     6
     7
     8 S   DFS,NET (C)ROFF   '1119E  `
     9 S   VIEW (C) 1982 Acornsoft
     A S   EXMON 1.0a (C)1983 Beebug
     B S   RAM Manager (C) 1988 S.Harri
     C
     D
     E
     F
Escape
>?&2A1=0
>*ROMS
     0
     1
     2 S   TOOLKIT PLUS (C)1985 Beebugs
     3 LR  BASIC (C)1982 Acorn
     4
     5
     6
     7
     8 S   DFS,NET (C)ROFF   '1119E  `
     9 S   VIEW (C) 1982 Acornsoft
     A S   EXMON 1.0a (C)1983 Beebug
     B S   RAM Manager (C) 1988 S.Harri
     C
     D
     E
     F
Escape

Note that slot 0 disappeared.
If you're very observant, you'll notice that other language ROMS (eg VIEW) have lost the "L" flag as well. That's 'cos my Manager ROM removes L from everything except BASIC, by mangling the 2A1 table. So BASIC is always the default language, regardless of the slot its in. So it's clear that the Toolkit Plus ROM is reporting based on the 2A1 table here as well

So for the OP to see what he got, it looks like the *RLOAD command updated the 2A1 table so that it looked like both slots were active.

[CommanderCoder]

I took a look at the ROM Table after using *RLOAD (from disk 5 on BEEB.MMB) and it looks like follows:
The table is altered and I guess *ROMS reads from slot 9 but actually reads from D to show the same ROM name.

Starting empty: (note that I'm reading from &2a0 so slot 9 is show at position 10 in this list)

Loading into D:

Loading into 9:

[sweh]

Yeah, that demonstrates your *RLOAD command is mangling the 2A1 table as you load, and that explains why the "*ROMS" command showed the multiple ROMs. It reads from the specified bank, but because of how the Beeb address decoding is done, it sees the same information in multiple banks, and so the same ROM name appears multiple times.

Enabling ROMs like this isn't 100% safe, especially if the ROM needs to allocate private workspace, so when I wrote my stuff back in the day I had a separate *YESROM command to do the mangling (and an associated *NOROM).