Sideways Ram 101

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
msknight
Posts: 550
Joined: Fri Apr 15, 2011 11:07 am
Location: IT support geek
Contact:

Sideways Ram 101

Post by msknight » Fri Jun 24, 2011 7:41 am

Hi Folks,

Even when I had my beeb as a teenager, I never had Sideways RAM.

Now I've got Mark's solution, I'm finding that I'm missing those keys in understanding.

I found Sollidisk's manual from 1986, but it is for their system with their tools, and while it does a grand job of explaining a landlord with only one property at &8000 at any one time, it isn't really doing the job for me.

If anyone has links to Sideways Ram for beginners, I'd greatly appreciate it.

Ta,

Michelle.

User avatar
pstnotpd
Posts: 394
Joined: Wed Jan 20, 2010 11:05 am
Contact:

Re: Sideways Ram 101

Post by pstnotpd » Fri Jun 24, 2011 8:02 am

The clearest reference I found is the "Advanced Sideways Ram User Guide" by Bruce Smith. I don't think anyone has scanned it yet but it sometimes pops up on ebay or amazon.

User avatar
msknight
Posts: 550
Joined: Fri Apr 15, 2011 11:07 am
Location: IT support geek
Contact:

Re: Sideways Ram 101

Post by msknight » Fri Jun 24, 2011 9:42 am

Thanks for that. I'll keep an eye.

There's a copy on Amazon for nearly £50, but that's a bit steep!

User avatar
jms2
Posts: 2357
Joined: Mon Jan 08, 2007 6:38 am
Location: Derby, UK
Contact:

Re: Sideways Ram 101

Post by jms2 » Fri Jun 24, 2011 12:02 pm

I'm sure if you have some specific questions then people on here would be happy to answer them! Although having said that I know the feeling of just "not quite getting it".

My explanation, FWIW, is this. In simple terms you can use it in three ways:

1) As extra RAM. This is only possible from a machine code program because when you page in the RAM, you have to page out BASIC (they occupy the same parts of the memory map). Typical examples of this usage are games, eg Exile and Strykers Run.

2) As a pseudo ROM, by loading a ROM image into the Sideways RAM. You communicate with it typically by issuing * commands and the operating system then manages the paging in and out of the ROM as necessary.

3) As a read-only Filing System using RFS (*ROM). As with (2) above, the operating system does the work of paging in the sideways ram and fetching the files in response to *Load etc, but in this case you have to load the data into sideways ram from disc in the first instance.

Usage no.2 is probably the most common. No.1 really only applies to games and to applications that you might write yourself which require a large amount of memory. Usage no.3 is very rare and rather pointless if you have a disc drive, the only real example of it being the ROM cartridges with games on which were supplied for the Electron.

How to make them work:

Use 1: You have to page in the sideways ram using the following bit of code (hopefully I've got it right..!). Then you can use it as normal ram, addresses being &8000-&BFFF, but only from machine code.

LDA#n \select which bank no the ram is in , n=0 to 16
SEI \turn off interrupts briefly
STA &FE30:STA &F4 \store in ROMSEL latch and ram copy of it
CLI \interrupts back on again

Use 2: The tricky part is loading the ROM image from BASIC. If you just type *Load Image 8000 it won't work because BASIC is paged in. What you need is either the operating system command "*SRLOAD Image 8000 n" (n= sideways ram bank number). *SRLOAD is only present on the Master (and B+?) so for a Beeb you need a disc-based version of the same thing.

Thereafter its the same as having a physical ROM present, so *HELP will show what new commands are available (hopefully).

Use 3: (really for experimentation only - not practical)
A suitable header format is described in the Advanced user guide. Then you'd need to build up a rom image on disc using this header and whatever data you want to go in it. Then see above for how to load it into sideways ram. To use, just type *ROM and then load data as per the cassette filing system.

Does this help?

User avatar
msknight
Posts: 550
Joined: Fri Apr 15, 2011 11:07 am
Location: IT support geek
Contact:

Re: Sideways Ram 101

Post by msknight » Fri Jun 24, 2011 12:26 pm

That's stunning! Many thanks.

I need to go back to a more basic level, though.

I take it, on the beeb, that of the five sockets, the right most is 15, the left most is either 11, or nothing (because it contains the OS, so I'm guessing that this might not be an actual ROM)

Have I got that right?

More questions to follow tonight when I get home from work.

User avatar
pstnotpd
Posts: 394
Joined: Wed Jan 20, 2010 11:05 am
Contact:

Re: Sideways Ram 101

Post by pstnotpd » Fri Jun 24, 2011 12:40 pm

In that case you might want to skip the Bruce Smith guide for now.

That one dives into use 2 at the deep end. It shows how to properly create "roms" yourself which will be recognized by the OS.

User avatar
flynnjs
Posts: 830
Joined: Tue Jul 06, 2010 9:33 pm
Contact:

Re: Sideways Ram 101

Post by flynnjs » Fri Jun 24, 2011 2:14 pm

pstnotpd wrote:The clearest reference I found is the "Advanced Sideways Ram User Guide" by Bruce Smith. I don't think anyone has scanned it yet but it sometimes pops up on ebay or amazon.
Hmm, I have that. I didn't know it wasn't scanned so I'll try to do so in due course.

User avatar
1024MAK
Posts: 9608
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Sideways Ram 101

Post by 1024MAK » Fri Jun 24, 2011 2:37 pm

jms2 wrote:2) As a pseudo ROM, by loading a ROM image into the Sideways RAM. You communicate with it typically by issuing * commands and the operating system then manages the paging in and out of the ROM as necessary.
One way to think about this (the paging in and out), is like changing heads - like Worzel Gummidge. He had a collection of interchangeable heads; each suiting a particular occasion or allowing him to perform a certain task. But could only use (access) one at a time...!
In the case of sideways ROM and sideways RAM, the Beeb does not really care what type of memory is used. The changing of the "head" is done by the firmware (the Operating System software in the OS ROM) by writing a value to a hardware register (also known as a latch) which selects the required sideways ROM (or sideways RAM).

Mark K.

User avatar
msknight
Posts: 550
Joined: Fri Apr 15, 2011 11:07 am
Location: IT support geek
Contact:

Re: Sideways Ram 101

Post by msknight » Fri Jun 24, 2011 2:41 pm

Worzel Gummidge. The theme tune comes back so readily, but the words are a bit fuzzy. "There's a wurr in the ...." Ok, Ok, I'll stop.

I'm trying to figure how a ram chip in a physical socket, can then contain logical rom positions. I can't match the physical latch to a logical latch in a single piece of ram.

What does the magic?

User avatar
1024MAK
Posts: 9608
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Sideways Ram 101

Post by 1024MAK » Fri Jun 24, 2011 3:17 pm

As far as the processor is concerned, it only sees data being returned from logical addressed locations - it does not care what type of memory, or how big or small, nor the actual layout or physical arrangement the memory takes.

[In the following text, I will use the term ROM, but it applies equally to PROM, EPROM, EEPROM, flash ROM, FRAM and sideways RAM (where the sideways RAM is SRAM - Static RAM)].
So you could make up a 16k byte "ROM" (128k bit arranged as 16k by 8 bits) by using a single 16k byte ROM chip, or put two 8k byte ROM chips together on in a circuit, the CPU would then see these as a single 16k byte ROM. Or you can go the other way and use a bigger device (bigger as in a higher capacity) such as a 64k byte ROM, but some electronics external to the ROM chip will only select one quarter of the device at a time (64k divided by 4 gives 16k). The electronics that does the section is effectively a circuit that generates extra address selection lines, which then select the area of the memory on the ROM chip that is required.
Confused? Don't be - the concept is actually simple. Think of it like this - if you have poor eyesight and use a magnifying glass to read the pages of a book, you can only see a section of the page at a time. In order to read the book, you have to select the correct page (the "address") and then select the area of the text that you wish to read with the magnifying glass by moving your glass "window".
Hope this helps :D
Mark K.

User avatar
1024MAK
Posts: 9608
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Sideways Ram 101

Post by 1024MAK » Fri Jun 24, 2011 3:20 pm

The latch/register that provides the extra address lines for sideways ROM/RAM is memory mapped, but not in the sideways ROM/RAM area. It's address is in the input/output (I/O) area.
I'll knock a little diagram up...
Image
Bank switching #1.png
Bank switching #1.png (28.36 KiB) Viewed 4545 times
Image
Bank switching #2.png
Bank switching #2.png (33.74 KiB) Viewed 4545 times

User avatar
msknight
Posts: 550
Joined: Fri Apr 15, 2011 11:07 am
Location: IT support geek
Contact:

Re: Sideways Ram 101

Post by msknight » Fri Jun 24, 2011 4:01 pm

That makes sense.

So, say having a 32K RAM chip in the rightmost socket ... how is the selection done? How does the machine know how to select it as, say, two different banks of 16k?

Does it see one as bank 15 and another as bank 1? Where is the programming done?

User avatar
msknight
Posts: 550
Joined: Fri Apr 15, 2011 11:07 am
Location: IT support geek
Contact:

Re: Sideways Ram 101

Post by msknight » Fri Jun 24, 2011 4:03 pm

... or rather ... how do you get the machine to tell you what it thinks is in what logical bank?

I know the *HELP command will tell me what ROMS it sees, but how would I see how it thinks it is configured?

Am I making sense?

User avatar
MartinB
Posts: 5255
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity
Contact:

Re: Sideways Ram 101

Post by MartinB » Fri Jun 24, 2011 7:28 pm

The Beeb architecture can only generically support a maximum of 16k in the rom area of the address map ($8000-$BFFF) and can only support the decoding of a maximum of 16 discrete devices. Therefore, the precise way in which a 32k device is partitioned is entirely up to the individual configuration. You could indeed use the genuine Romsels 15 and 1 to partition a 32k device in that way and this requires the device /CS, /CE and high order address lines to be connected in such a way as to allow this mapping. There is no rigid protocol dictating how it should be done, it's in the hands of the designer of a given implementation.

If you were to download my *UPXROM utility and use the '?' switch, you would get a good idea of how the Beeb perceives the configuration of its rom banks and this utility will also indicate where a bank is writable ram. Note however that if the Romsel latch at $FE30 is not fully decoded to 16 discrete lines, there is an issue of 'ghosting' where rom/ram can be apparently duplicated in a second (or more) logical slot(s).

User avatar
retroclinic
Posts: 3032
Joined: Thu Jul 03, 2008 1:22 pm
Location: East Riding of Yorkshire
Contact:

Re: Sideways Ram 101

Post by retroclinic » Fri Jun 24, 2011 9:16 pm

Hi Michelle.

Using my machine to learn about sideways RAM is probalby slightly nmore confusing that it should be, simply because the main board is modified to take more ROMs than the beeb should have. The mod I do is documented here:

http://www.retroclinic.com/acorn/swr/swr.htm

With the addition of an enable switch for your 48Z35 RAM, incase it crashes. You've got a lot of info in the books you got with the machine, especially in the concise user guide which does explain about sidewars ROMs and how they work. The RAM is not really any different from the computers hardware point of view, apart from you can write to it.

If you need any more specific info on the way I've modded your machine, then let me know.

Thx, Mark.
Image

User avatar
1024MAK
Posts: 9608
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Sideways Ram 101

Post by 1024MAK » Fri Jun 24, 2011 10:28 pm

A 32k byte RAM chip has 15 address lines. A 16k byte ROM has 14 address lines. As each address line can only be in one of two logic states, 15 address lines gives 32768 different addresses (32k), 14 address lines gives 16384 addresses. So what happens if you want to plug a 32k device into a socket designed for a 16k device?

Well, we need to consider the functions of the pins on the chips.
Here is the pin-out of a 62256 32k byte SRAM chip:
Image
62256 32k byte SRAM.png
62256 32k byte SRAM.png (19.35 KiB) Viewed 4474 times
On a 16k byte 27128 EPROM most pins have the same functions as on a 62256 32k byte SRAM chip except for:
Pin 1 on the EPROM is VPP (used for programming)
Pin 27 on the EPROM is /PGM (also used for programming, but held at +5V for normal use).
Note that a bar/line over a signal name means that it is in its active state when at a logic low level. As this is hard to show in text, one convention is to put a / symbol in front of the signal name – it means the same thing.

On the 62256 32k byte SRAM chip, pin 1 is A14, this is the top most address line. When logic low addresses in the range 0 to 16383 in the chip are available (note this is the address as the memory chip sees it, not as the CPU sees it). When A14 is logic high, addresses in the range 16384 to 32767 are available. So A14 (pin 1) needs to be bent up (unless you modify the circuit board) and a wire connected from it to one of the extra address lines from the ROM select Latch, IC76 (e.g. pin 12 which is Bit 2).

Pin 27 is /WE the write enable signal. This needs to be connected to a suitable signal. Again bend the pin up (again, unless you modify the circuit board) and use a wire to connect it to pin 8 of IC77. Make sure that no part of the pin or the wire enter the socket pin or you may get magic smoke!

Note also that pin 20 chip select /CS and pin 22 output enable /OE combined select each individual memory chip (both need to be logic low before the chip will output data to the data bus). With the sideways ROM system in the Beeb being a partly decoded system, leaving these pins connected in the socket the same as the ROM is okay.

Each half of the 62256 32k byte SRAM will now appear as a separate 16k byte memory in the sideways “ROM” part of the memory map. The ID numbers depend on which socket you plug it in and which output pin on IC76 you used, but will be in the range 0 to 15.

Mark K.

User avatar
retroclinic
Posts: 3032
Joined: Thu Jul 03, 2008 1:22 pm
Location: East Riding of Yorkshire
Contact:

Re: Sideways Ram 101

Post by retroclinic » Fri Jun 24, 2011 10:34 pm

Very nice description!

Just one point to note:
1024MAK wrote:....So A14 (pin 1) needs to be bent up (unless you modify the circuit board)....
On a Model B motherboard, all Pin 1s for the 4 ROMs are left open circuit, so you don't need to bend the pin out. Pin 27 is tied to pin 28, so you as you say for that one, you do need to bend it out, or isolate pin 27 by cutting the track under the board.

Mark.
Image

User avatar
1024MAK
Posts: 9608
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Sideways Ram 101

Post by 1024MAK » Fri Jun 24, 2011 10:36 pm

retroclinic wrote:... does explain about sidewars ROMs and how they work...
:arrow: Is this what you get with a memory or bus contention error :lol: :lol: :lol:

User avatar
retroclinic
Posts: 3032
Joined: Thu Jul 03, 2008 1:22 pm
Location: East Riding of Yorkshire
Contact:

Re: Sideways Ram 101

Post by retroclinic » Fri Jun 24, 2011 10:42 pm

1024MAK wrote:
retroclinic wrote:... does explain about sidewars ROMs and how they work...
:arrow: Is this what you get with a memory or bus contention error :lol: :lol: :lol:
LOL, no it's what you get when you haven't BOUGHT( :lol: (c)2011-TopBannana) a spelchekor, and/or you don't bother to read your post back to yourself 6 times to make sure what you've written is the Queen's English.

Mark.
Image

TopBanana
Posts: 1064
Joined: Wed Jun 09, 2010 2:16 pm
Contact:

Re: Sideways Ram 101

Post by TopBanana » Fri Jun 24, 2011 11:04 pm

retroclinic wrote:
BOUGHT( :lol: (c)2011-TopBannana)

Mark.
Or even TopBanana :lol:

Mate, your spill cheka neads fixxing :shock:

User avatar
msknight
Posts: 550
Joined: Fri Apr 15, 2011 11:07 am
Location: IT support geek
Contact:

Re: Sideways Ram 101

Post by msknight » Sat Jun 25, 2011 7:33 am

Now those are some superb explanations. Many, many thanks.

So, the standard machine puts out requests on the line, but only 12-15 are there to have ROMS in that could respond. So they are wired in to the top two bits of the 4 bit line selector.

When adding a sideways ROM board, then presumably it takes control of receiving all four rom selector bits.

What a sideways RAM does, then, is similar ... fudging the ROM selector cables by running them to pins on sockets that it otherwise wouldn't have used; but adding an extra line to enable writing to the chip.

So a 64K chip would take control of two of those bits, fudging the high bits of its own address lines in order to fudge splitting itself in to four different partitions.

Do I have that right?

User avatar
BeebMaster
Posts: 2976
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Sideways Ram 101

Post by BeebMaster » Sun Jun 26, 2011 12:09 am

I'm not sure about bits of fudge, I don't think that would do any good. This is the way I think of it, not sure if it will help.

There are 4 available ROM sockets inside a BBC B (the fifth one being reserved for the OS ROM).

The Beeb has the capacity to support 16 ROMs, so each of the sockets can in theory hold up to 4 ROMs, or contain enough RAM to hold 4 ROM images.

By attaching flying leads going from the ROM or RAM chips in the sideways ROM slots to certain of the ROM select lines on the Beeb you can use chips larger than 16K to hold multiple images.

In the case of RAM chips, you also need a flying lead to a write enable line so that you can load data into it.

A 32K chip (27256 for ROM or 62256 for RAM) can hold 2 images, and a 64K chip (27512 for ROM or 62512 for RAM) can hold 4 images.

The ROM slot numbers in the BBC's ROM table are not consecutive within a chip holding multiple images, because the socket numbers on the motherboard are numbered 12 to 15. So you have to deduct 4 for each of the additional ROMs inside a 32K or 64K chip.

Therefore, for example, ROM socket 15 will appear as sockets 15 and 11 or 15 and 7 (depending on how you connect up the flying leads) for a 32K chip, and 15, 11, 7 and 4 for a 64K chip.

My BBC B (Station 128) has the OS plus two 16K ROMs (BASIC and DNFS), a 32K sideways RAM (which shows up as slots 12 and 8) and a 32K ROM containing ANFS and ADT, which show up as 14 and 10). Effectively I am getting 6 slots' worth of ROM images in only 4 sockets. If I put the two 16K ROMs on a 32K chip and and use the ROM socket this frees up for another 32K sideways RAM then I could have 8 ROM slots in only 4 sockets.

If could work out a way of putting 4 images in a 64K chip with my EPROM programmer (which I don't think is possible) then I could potentially have all 16 slots available without the use of a ROM board!
Image

User avatar
msknight
Posts: 550
Joined: Fri Apr 15, 2011 11:07 am
Location: IT support geek
Contact:

Re: Sideways Ram 101

Post by msknight » Sun Jun 26, 2011 6:36 am

Thanks everyone. Those are some great explanations.

I think I've got the gist of how it hangs together and how the fly leads are used to coerce the ROM selection into happening on bigger chips.

So how do I ask the BBC to list what it thinks are the ROMS in each socket please?

TopBanana
Posts: 1064
Joined: Wed Jun 09, 2010 2:16 pm
Contact:

Re: Sideways Ram 101

Post by TopBanana » Sun Jun 26, 2011 8:11 am

*HELP is always a good place to start :shock: although it doesn't tell you which socket :lol:

Or, as above
MartinB wrote:If you were to download my *UPXROM utility ..........
Alternatively ADT has a *ROMS command that lists the slots and ROMs, as do many other utility ROMs.

Or you could write you own snippet of code - page in each ROM socket in turn and read the title or copyright string. If you load up EXMON and page a ROM in you quickly see which byes it uses to identify itself.

User avatar
jgharston
Posts: 3801
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Sideways Ram 101

Post by jgharston » Tue Jun 28, 2011 1:19 am

msknight wrote:If anyone has links to Sideways Ram for beginners, I'd greatly appreciate it.
Mastering Sideways ROMs and RAMs. A bit dodgy in places (I'm really tempted to re-edit it), but as good as any.
msknight wrote:So, say having a 32K RAM chip in the rightmost socket ... how is the selection done? How does the machine know how to select it as, say, two different banks of 16k?
By adding a flying lead to pick up the extra address line, as described here.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
1024MAK
Posts: 9608
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Sideways Ram 101

Post by 1024MAK » Wed Jun 29, 2011 2:18 am

I've extracted the area of the circuit diagram showing the sideways (paged) ROMs.
The links shown in red are shown as they should normally be for a standard issue 4 or issue 7 machine.
Also please note that D4 and D5 are also not fitted (as is always the case, you forget something before posting! :mrgreen: )
Image
Beeb Sideways ROM cct #3.png
sideways (paged) ROMs circuit diagram
Beeb Sideways ROM cct #3.png (141.6 KiB) Viewed 4265 times

station240
Posts: 864
Joined: Tue Feb 09, 2010 6:11 pm
Location: South Australia
Contact:

Re: Sideways Ram 101

Post by station240 » Wed Jun 29, 2011 5:36 am

The ROMSEL chip IC 76, is the important part here. See with 4 signal lines you can have 16 possible combinations, and there are 16 possible rom slots. ABCD are the imputs, and QA QB QC QD are the outputs. The bottom two lines, QA and QB, are wired to IC 20 (74LS139) to decode it into the 4 possible combinations.

By connecting additional 74LS139's (and other chips) the the outputs of IC 76 and the gate input for the first 74LS139, you can connect all 16 roms. Of course another way is to despense with decoding all 16 roms and drive some extra address lines in a larger chip.

If you were to connect IC 76 directly to a single large ROM/RAM chip (or two different ones) then you get 16 roms without having to have 16 physical ROM/RAM chips and the decoding logic.

User avatar
msknight
Posts: 550
Joined: Fri Apr 15, 2011 11:07 am
Location: IT support geek
Contact:

Re: Sideways Ram 101

Post by msknight » Wed Jun 29, 2011 9:44 pm

Many thanks for all this effort.

It makes perfect sense now. Previously I was having problems working out how Mark had pulled off having two ROMs which held multiple ROMS, but now I can see how the logical interleaving is working.

I've still got a few things to get 100% straight in my head, but I'm not far off now.

Thanks for all the help on this.

User avatar
msknight
Posts: 550
Joined: Fri Apr 15, 2011 11:07 am
Location: IT support geek
Contact:

Re: Sideways Ram 101

Post by msknight » Sun Jul 03, 2011 6:49 am

OK - I've compressed what I've learned here, in to a smaller page that might help newbies like me, start to understand what is happening.

If someone could check that I had things right, I'd be grateful - http://www.msknight.com/bbc/sideways.html

User avatar
george.h
Posts: 1030
Joined: Wed Apr 13, 2011 5:32 pm
Location: Chelmsford Essex
Contact:

Re: Sideways Ram 101

Post by george.h » Sun Jul 03, 2011 3:39 pm

It's pretty good Michelle!

There are a few small bits need clarifying.

The OS normally handles all the business of paging ROMs in and out. This is done by a whole set of well defined software interfaces for everything from unkown commands to new *FX commands and filing system functions.

The basic way it works is this:

Everything not strictly part of the current language (e.g. BASIC), is treated as an operating system function. This is everything from *commands to input (e.g. keyboard) and output (e.g. the screen) streams and file handling. Anything of this nature is first checked by the OS to see if it directly handles the request. If it doesn't, such as a *command it doesn't recognise or an *FX (OSBYTE) call it doesn't have defined it passes to the sideways ROMs to see if they handle it.

The kind of service required determines which interface is used to pass the request to the ROMs. Once that is determined it uses that interface to "pass" the request to each of the ROMs in turn starting with ROM 15 and ending with ROM 0. This is done by switching each ROM into the address space and calling it through a set of defined entry points. The ROM can then look at the request to see if it is a service it provides. If it isn't, it returns control to the OS which then passes the request onto the next ROM down in number until one of them does or all of the ROMs have been "polled". If none of the ROMs "claim" the request then the OS usually invokes the error handler which usually outputs some error message then drops control back to the current language (if there is no language, at least on the Masters, it takes control itself otherwise you get the "Language?" error).

When a ROM does recognise the service as one it provides then generally it sets about providing the service. When finished it informs the OS by "claiming" the request. This lets the OS know the service has been provided and it can return the system back to the code which requested the service. This could be your own code, the current language (which is itself one of the ROMS) or as can also happen, one of the other sideways ROMs. Obviously this often means switching the ROM which provided the service out and one of the others back in.

So, looking at my whizzy new command of *BANG, the OS looks at this, doesn't regnoise it so passes it to the ROMs. When it gets to my ROM, it does whatever *BANG is then claims it. If no ROM claims it the OS issues a "Bad command" error. Some filing systems though, like DFS, not only check their own commands, but will also see if they can find a file of the same name. If they do they can load it, execute it and then claim the request. This gives the appearance of the disk system handling unknown commands, which it does in a way, but strictly speaking that is still handled by the OS. What it does do, is to provide a mechanism by which filing systems can provide commands not actually in the ROM.

Even "languages", such as VIEW, follow this mechanism as *WORD is nothing more than a command the OS doesn't recognise. Though there is more complex mechanism by which languages claim requests to set themselves as the current default language. (BASIC is an exception to this rule, the OS having a special way of recognising which ROM contains BASIC - just typical of course that I used *BASIC as my original example #-o )

One exception to this is *HELP which is an OS command. If there is nothing after the*HELP then the OS passes a request to each and every ROM which is expected to announce itself and NOT claim the call. This allows ALL ROMS the chance to do this. If there is more stuff on the line after the *HELP command, the OS first sees if it recognises it. If it doesn't then again it gets passed to the ROMs. The ROM which recognises the text is then expected to output more detailed infor (related to the text) and then claim the call.

This request issue/claim mechanism is why if you have two ROMS with the same command, the one in the highest socket grabs it.

The exception to the above is the Tape Filing System which is actually part of the OS.

Depening upon the complexity of the services a particular ROM provides, it may need some RAM space to use. Where this needs to be used to store things the ROM needs to keep track off when it's not actually "paged in", it can claim some private RAM for it's own exclusive use. The OS allocates this, reducing the amount of RAM available to any language by increasing OSHWM (OS High Water Mark) which BASIC then uses to set PAGE.

George
:wink:

EDIT : Corrected my mistake of using BASIC and *BASIC for the language ROM example and PAGE instead of OSHWM (from which PAGE is derived)
Last edited by george.h on Mon Jul 04, 2011 9:36 am, edited 2 times in total.
Pic Caption: "One day son, this will all be yours..."

Post Reply