Miscellaneous OS Software Functional Specification 

    Distribution: COMPANY CONFIDENTIAL

    Project:      NC Model 1
    Issue:        0.10
    Author(s):    Steve Cormie, Jonathan Harris
    Date:         31-Oct-96
    Last Issue:   0.09

Contents.

History 

	0.01 SMC 19-Mar-96 First created.
	0.02 SMC 20-Mar-96 Added section on Interlace module.
	0.03 SMC 24-May-96 Added mouse detection.
	0.04 JRH 06-Jun-96 Decided on combo chip & RTC.
	0.05 JRH 04-Jul-96 Added new buffer key codes.
	0.06 SMC 08-Jul-96 Added section on ModeFiles module.
	0.07 SMC 06-Aug-96 Removed section on Joystick module.
	                   Added section on machine address.
	0.08 JRH 27-Aug-96 SMC669 combo chip not supported.
	                   Added more new buffer key codes.
	0.09 JRH 20-Sep-96 Added `Home' new buffer key code.
	0.10 JRH 31-Oct-96 Yet another new buffer key code: Print.

Outstanding issues

None.

Overview

This document specifies miscellaneous software development required for the NC Model 1 ROM. This covers all software development which does not merit a full software functional specification eg. small changes to the RISC OS Kernel and other modules.

Italicised text is used where issues are still to be decided or where contents are liable to change.

Technical background

The version of RISC OS in the Network Computer ROM has a number of minor changes mostly to cater for small hardware differences between the NC and the A7000 (which the ROM is based on).

Programmer interface

The following items are covered by this specification:

Auto-detect TV-monitor

The NC Kernel is modified to auto-detect whether a television or monitor is connected to the machine (monitor takes precedence if both are connected). The following SWI has been modified to allow programmers to determine what display type is connected.

OS_ReadModeVariable (SWI &35)

Read information about the given mode.

On entry
        R0 = screen mode (-1 for current)
        R1 = 0 (ModeFlags)
On exit
        R2 = value of variable
        
        Where bits in ModeFlags are:
                Bit     Meaning when set
                0       Non-graphics mode
                1       Teletext mode
                2       Gap mode
                3       BBC gap mode
                4       Hi-res mono mode
                5       Double-height characters
                6       No hardware scroll
                7       Full 8bpp palette
                8       Interlace mode (TV)

Auto-detect NTSC/PAL

A new module, ModeFiles, is introduced to serve several purposes. When the module initialises it calls SWI OS_ReadSysInfo (1) to determine the monitor type. The module then uses *LoadModeFile to load a mode file depending on the monitor type returned, 0 (PAL), 3 (VGA) or 8 (NTSC). After the mode file has been loaded the monitor type returned by SWI OS_ReadSysInfo will be 7 (file) so other modules and applications will not be able to determine the display type. To remedy this the ModeFiles module provides two mechanisms to determine the display type. After loading the mode file it sets the system variable TV$Type to "PAL", "VGA" or "NTSC". It also provides the following SWI to read the display type:

ModeFiles_MonitorType (SWI &4D480)

Read the current monitor type. 

On entry
	R0 = 0 (flags)
On exit
	R0 = monitor type
		0 = PAL
		3 = VGA
		8 = NTSC

The ModeFiles module also provides the following SWI for reading the safe area of the current mode based on the display type:

ModeFiles_SafeArea (SWI &4D481)

Read the safe area of the current mode based on the display type. 

On entry
	R0 = 0 (flags)
On exit
	R0 = x min (in OS units)
	R1 = y min (in OS units)
	R2 = x max (in OS units)
	R3 = y max (in OS units)

The ModeFiles module also claims Service_MonitorLeadTranslation so that it can provide default modes using mode descriptors rather than numbered modes (interlaced modes are no longer provided as numbered modes).

IRQC register set

In order to provide interrupt support for devices linked to the IOLINES register in the ARM7500 ie. the 8-bit I/O port (pins IOP[7:0]), the NC Kernel is modified to provide 8 new device numbers which can be claimed using SWI OS_ClaimDeviceVector. These device numbers are in the range 30 to 37 and correspond to bits 0 to 7 of the IRQC register set respectively. This allows the standby button to generate an interrupt which is claimed by the Standby module.

Because the contents of the IOLINES (and hence IRQC registers) varies so widely between machines the new devices have the following generic names.

	IOMD_C_Bit0_DevNo
	IOMD_C_Bit1_DevNo
	IOMD_C_Bit2_DevNo
	IOMD_C_Bit3_DevNo
	IOMD_C_Bit4_DevNo
	IOMD_C_Bit5_DevNo
	IOMD_C_Bit6_DevNo
	IOMD_C_Bit7_DevNo

Increased video bandwidth

It has been determined that the ARM7500 is capable of higher video bandwidth limits than were allowed for the A7000 while still allowing the appropriate safety margin which was applied to the Risc PC. The bandwidth limit provided by the Kernel has been increased to the theoretical maximum of 64000000. This may need to be restricted using a VIDCBandwidthLimit command during machine boot.

New combo chip

The RISC OS kernel will support the following combo chips:

It is anticipated that the UMC'8669 will be used. The RISC OS kernel will be modified to support the new chip configuration protocol used by the UMC'8669.

The UMC'8669 cannot support a floppy drive at the PC I/O address currently assumed by ADFS without additional hardware. This hardware will not be fitted on NC Model 1. Both ADFS and the kernel programming of the combo chip will need to be altered in the future if floppy drives are to be supported using this combo chip.

Interlace module

Because of the added support for the IRQC register set in the Kernel, a new version of the Interlace module is required because it has "knowledge" of the location of the interrupt handler in Kernel private workspace.

Mouse detection

SWI OS_Pointer is extended as follows so that the presence of a mouse can be detected.

OS_Pointer (SWI &64)

Return presence of mouse.

On entry
	R0 = 2 (reason code)
On exit
	R0 = presence: 0 => not present, 1 => present

Note that presence is detected by mouse movement, it is not possible to detect the physical presence of a mouse in any other way as the device could be IR based.

New non-volatile RAM chip

Recent RISC OS computers have used a Philips PCF8583 chip which provides a Real-Time Clock and 250 bytes of CMOS non-volatile storage. This chip is accessed at address &A0 on the i2c bus. For cost and reliability reasons the NC Model 1 will be fitted with an E2 device which provides non-volatile storage only. This device will be accessed at &A8 on the i2c bus and will provide 1K of non-volatile storage.

The kernel read and write routines (used by OS_Bytes &A1 and &A2) will be amended to access NVRAM at &A0 or &A8 and will cope with the slower write-cycle time of the E2 devices. The existing OS_Byte interface will not be extended, so the additional capacity of the E2 device will not be accesible.

The kernel will set the system time to an (incorrect) default value on initialisation instead of attempting to read the time from the RTC chip. The kernel SetTime routine will set the system time without attempting to write to the RTC chip.

The POST code will be amended to recognise NVRAM at &A0 or &A8 and to not check for a RTC.

Machine address

The NC machine address is defined as being an IEEE allocated MAC address (usually used as an ethernet address). This is a world-wide unique 6-byte number which can be used to identify an individual NC. The current NC design uses a Dallas ID chip and an Acorn specific mapping (applied by the Kernel) to determine the machine ID. Clearly, other manufacturers cannot use numbers allocated from the Acorn range (both for Dallas IDs and for IEEE MAC addresses). This requires a method whereby they can use a similar strategy to Acorn but with Dallas IDs from their own range and their own mapping algorithm or by using another method altogether.

The mechanism whereby a module or application reads the unique machine address is by calling SWI OS_ReadSysInfo 4. Ethernet card drivers should continue to call SWI Podule_ReadInfo which checks that the card is in the correct slot (0 for an NC) and calls OS_ReadSysInfo 4 to get the ethernet address if appropriate. This means that only one network card is permitted to use the machine ID as an ethernet address.

SWI OS_ReadSysInfo 4 is extended in two ways. Firstly, if the Dallas ID chip is not an Acorn part or is not present at all then the following service is issued.

Service_MachineAddress (Service call &BD)

Return machine address.

On entry
	R1 = &BD (reason code)
On exit
	If R1 = 0 (claimed)
		R0 = lower 4 bytes
		R2 = upper 2 bytes

This service call can be claimed by a module either in main ROM or on a network card as appropriate. If the module is on a network card then it should only claim the call if it is in slot 0. The module can determine the machine address to return in whatever way is determined by the manufacturer, examples include:

If the service call returns unclaimed then as a last resort SWI OS_ReadSysInfo 4 checks space allocated in NVRAM for the ethernet address. See NC Model 1 NVRAM Contents for details of this allocation. The Kernel is modified such that the locations reserved for the machine address are write protected unless they have become corrupt (checksum is invalid). Care must therefore be taken when programming these locations to ensure that the 6 bytes + inverted checksum do not become valid part way through programming as the Kernel will then refuse to allow the remaining bytes to be set.

Data interchange

Keyboard buffer codes

The following new keyboard buffer codes are hereby defined: 

	Key		Code	+Shift	+Ctrl

	Help		&C0	&D0	&E0
	Menu		&C1	&D1	&E1
	Open		&C2	&D2	&E2
	Stop		&C3	&D3	&E3
	Back		&C4	&D4	&E4
	Forward		&C5	&D5	&E5
	Toolbar		&C6	&D6	&E6
	Home		&C7	&D7	&E7
	Print		&C8	&D8	&E8

External dependencies

There are no external dependencies.

Acceptance test

To be decided.

Development test strategy

To be decided.

Product organisation

All changes are made to the RISC OS source tree which is used to build the NC Model 1 ROM.

Future enhancements

None planned at present.