Previous page: Service Events Next page:
ROM Structure   Memory Allocation

From time to time, the OS will send a service event to all ROMS. Each ROM can then decide whether to ignore the event, or to respond. If a ROM responds, it can "claim" the event preventing other ROMs from subsequently responding, or it can exit without claiming to allow other ROMs to respond.

As an example, when the user types the "*HELP" command, then all ROMs (in turn) are sent signal &09. Usually, ROMs all respond to this by displaying their name and possibly version number. If a ROM responds to extended help commands, then this will be indicated, too. ROMs do not claim this event so that all other ROMs can also respond. Alternatively, when the user types the "*WORD" command, the View ROM (if fitted) will respond (if a previous ROM has not claimed it!). Since the ROM will start up its "language", it will claim the event to stop other ROMs responding. It will then signal the OS to start up the language routine in its ROM.

Signals are sent, therefore, in response to various events that occur while the OS is running. When such an event occurs, the OS will place the event number in the accumulator and any relevent data in the Y register. For each ROM, the ROM number will be placed in the X register and the service routine for that ROM will be called. The OS does not reset the values in the accumulator and Y register between ROMs, so it is vital that a ROM preserves these two if it is not claiming the event. This process is started by the OS by calling OSBYTE &8F with the service call number placed in X and the extra data placed in Y. The OS copies the service number to the accumulator and loads the ROM number into X for each ROM in turn. User programs can also use this method to send signals and certain types of ROM (especially file system ROMs) must use this mechanism to claim certain resources, etc.

We can see that a service routine will basically start with code to determine what event has been sent and either ignore it or act on it as necessary. An event is claimed by exiting with the accumulator set to &00, so it is clear that every service routine must ignore an event with this number.

As well as the data in the registers, there is also various information available in certain zero page locations. Of note are:
LocationContents
&F2,&F3 The start address of a buffer used by "star" commands.
&F4 The ROM number.

The simplest ROM is clearly one with a service routine which does nothing but return. Here it is:

EQUB &00
EQUW &0000
JMP service
EQUB &82
EQUB copy-&8000
EQUB &01
.title
EQUS "Simplest ROM"
EQUB &00
.version
EQUS "1.00"
.copy
EQUB &00
EQUS "(C) 2001 Mark Bush"
EQUB &00
.service
RTS

To do more, we first need to know all the service numbers that the OS may send. The calls regarding memory allocation are explained later.
Numbermeaning
&00 Do nothing. This signal means another ROM has claimed the call.
&01 Claim filing system static workspace memory. Call must not be claimed.
&02 Claim dynamic workspace memory. Call must not be claimed.
&03 Filing system bootstrap. This gives a filing system the opportunity to start as the current filing system. If the Y register is zero, then the ROM should auto-boot (say, by running a !BOOT file). If a ROM becomes the current filing system then it should claim this call.
&04 Sent when the user runs a "star" command (other than "*HELP" and "*BASIC" which are handled differently). &F2;&F3 points to the first character of the command ("*") and Y will contain the offset of the first character of the first command word (after any initial stars and spaces). A filing system should not run any files or execute specific commands at this point.
&05 An interrupt unknown to the MOS has occurred. If the ROM recognises the interrupt, it should clear the cause and claim this call.
&06 A BRK has occurred. ROMs may perform any necessary tasks.
&07 An OSBYTE call unknown to the MOS has occurred. A ROM which responds should claim this call.
&08 An OSWORD call unknown to the MOS has occurred. A ROM which responds should claim this call.
&09 Sent when the user runs a "*HELP" command. &F2;&F3 points to the first character of the command ("*") and Y will contain the offset of the first character after the command word (so the routine can see if the command had arguments). This call should not be claimed.
&0A A filing system should cause this to be sent when starting up. It allows the previous filing system to finish use of the static filing system workspace cleanly.
&0B Release ownership of the NMI resource to the previous owner (held in the Y register).
&0C Force the owner of the NMI resource to give it up to a new owner. The current owner should set the Y register to point to itself so that it can be returned after use.
&0D Reserved for Speach Filing System.
&0E Reserved for Speach Filing System.
&0F Warning to filing systems that the filing system indirections have changed because a new filing system is starting up.
&10 Sent in response to OSBYTE 119 informing all filing systems to shut *EXEC, *SPOOL and *SPOOLON files.
&11 Unused.
&12 Start filing system. The Y register contains the filing system number to start (not the same as the ROM number).
&15 A polling interrupt has occurred (as requested by OSBYTE 22). The Y register contains the number of outstanding requests and should be decremented by the number of requests made. If Y becomes zero then the call can be claimed.
&18 Reserved.
&21 Claim static workspace memory in the filing system private RAM. This call should not be claimed.
&22 Claim dynamic workspace memory in the filing system private RAM. This call should not be claimed.
&23 Informs all ROMs of the size of the filing system static workspace in the filing system static workspace memory. This call should not be claimed.
&24 Count dynamic workspace in filing system RAM.
&25 Provide filing system information. All ROMs containing filing systems should, for each filing system contained, write an 11 byte block to the location stored in &F2;&F3 offset by the Y register, incrementing Y to point to the next block. The first 8 bytes are the filing system name (space padded), then the low filehandle limit, the high filehandle limit and the filing system number. This call should not be claimed.
&26 Close all open files (used by *SHUT). This call should not be claimed.
&27 A reset has occurred. ROMs should perform any necessary initialisation. This will follow any memory allocation events if this is a hard reset. This call should not be claimed.
&28 A configuration command unknown to the MOS has occurred. If the ROM recognises the command and owns part of the CMOS RAM it can update the value stored.
&29 A status command unknown to the MOS has occurred. If the ROM recognises the command and owns part of the CMOS RAM it can display the stored value.
&2A A language change is about to occur. The current language should free up any utilisation of language resources.
&2B Reserved.
&FE Tube post-initialisation.
&FF Initialise tube software.


Previous page: Service Events Next page:
ROM Structure   Memory Allocation