Skip to content

GitLab

Commit 10073caf authored by Neil Turton's avatar Neil Turton
Browse files

Kernel merged

parent d9272e7d
Expand all Hide whitespace changes
Inline Side-by-side
Showing with 0 additions and 3629 deletions
Doc/!ReadMe deleted 100644 → 0
View file @ d9272e7d
> !ReadMe
Instructions on how to make/modify Arthur.
Directory Asm contains the Exec files.
Asm.A500 assembles the A500 kernel and then does *Asm.BuildA500
Asm.BuildA500 glues modules to the kernel to make an image for 27512's.
Asm.BigA500 glues modules to the kernel to make an image for 1Mbit devices.
Asm.Test assembles the Archimedes kernel, for 300 and 400 series machines.
NB. This uses Hdr.Archie, not Hdr.Test !!!
Asm.Test2 glues modules to the kernel to make an image for 1Mbit devices.
Asm.MoveFS takes a new copy of FileSwitch (and headers) from the net.
Asm.TransTim takes a new copy of Tim's stuff from the net.
Directory Hdr has the header files for the various assemblies.
Directory Text has various files, only one of which is important:
Text.Changes should be updated whenever changes are made to Arthur.
Text.Still has my list of things still to do.
Quick guide to the source files:
Kernel is the first, and has the SWI dispatcher, plus the initialized variables
to copy into RAM, plus some Brazil swi handlers.
Middle contains the rest of the Brazil swi stuff, plus supervisor routines.
NewReset is the reset code - if you need to change this, you will need to use
the AddTubeBashers flag, which lives in Kernel. The TubeChar macro should then
function.
Super1 is the supervisor loop, plus more Brazil oddsnsods.
ArthurSWIs is ReadUnsigned, vectors, services, ValidateAddress. Note that
the version of ChangeDynamic in here is NOT the one that's assembled.
Arthur2 is variables, GSTRANs
Arthur3 is command code, including Status/Configure.
Other files are hopefully obvious from their names.
Backing Up.
===========
You need to copy the whole tree from $.Kernel to the backup medium.
You also need to take a copy of all the current header files from $.Hdr.
A copy of all the tools in $.Library and $.Utils would also be handy.
Have fun!
Doc/0197276.02 deleted 100644 → 0
View file @ d9272e7d
This diff is collapsed.
Doc/A540Extend deleted 100644 → 0
View file @ d9272e7d
; A540Extend
Title: A540Extend
Author: Tim Dobson
Version: 1.01
Started: 01-Nov-90
Last updated: 25-Nov-91
Status: Release
History:
01-Nov-90 TMD Created
25-Nov-91 TMD Updated for RISC OS 3.03
Additions to the mode extension system for A540 and similar machines
====================================================================
This document describes extensions to the RISC OS mode extension system for
machines which have programmable VIDC clock speeds and sync polarities, such
as the A540. Familiarity with the RISC OS 2.00 mode extension system is
assumed (this is described in the existing Programmer's Reference Manual).
The A540 has extra hardware to allow the selection of different VIDC clocks
and to determine the polarity of the sync lines. VIDC uses its clock
together with a set of internal dividers to provide a range of pixel rates.
The format of the "VIDC list" returned from Service_ModeExtension (&50) has
been extended to allow the pixel rate and sync polarities to be specified.
On original Archimedes machines, the VIDC clock is fixed at 24MHz, and the
pixel rate is only determined by VIDC's internal dividers, as specified in
bits 0 and 1 of the Control Register (VIDC address &E0). This would be
stored in the VIDC list as a word of the form &E00000xx.
RISC OS now supports two different format VIDC lists.
The original (type 0) VIDC list format is as follows:-
Offset Value
0 0
4 VIDC base mode
8 VIDC parameter
12 VIDC parameter
.. ..
n -1
The new (type 1) VIDC list format is as follows:-
Offset Value
0 1
4 VIDC base mode
8 VIDC parameter
12 VIDC parameter
.. ..
n -1
n+4 Extended parameter
n+8 Extended parameter
.. ..
m -1
where extended parameters are of the form
(0 << 24) + (pixel rate in kHz)
or
(1 << 24) + (sync polarity)
or
(2 << 24) + (true VIDC clock rate in kHz)
** This option available only from RISC OS 3.03 onwards **
The sync polarity is defined as follows:-
bit 0 = 0 => HSync +ve (as on a standard Archimedes)
= 1 => HSync -ve
bit 1 = 0 => VSync +ve (as on a standard Archimedes)
= 1 => Vsync -ve
bits 2..23 must be zero
A pixel rate specifier in a type 1 VIDC list will override the settings of
bits 0 and 1 of a Control Register specifier in the main body of the list.
If no pixel rate is specified, then the VIDC clock is set to 24MHz, and the
settings of the divider in the Control Register are used as normal.
The A540 hardware provides the following pixel rates:-
24000 kHz, 25175 kHz, 36000 kHz with a multiplier of 2/2
16000 kHz, 16783 kHz, 24000 kHz with a multiplier of 2/3
12000 kHz, 12587 kHz, 18000 kHz with a multiplier of 1/2
8000 kHz, 8392 kHz, 12000 kHz with a multiplier of 1/3
If the pixel rate specified is not achievable with the hardware on the
machine, the nearest available pixel rate is used.
Note: when specifying a pixel rate for a hi-res-mono display, the pixel rate
specified should be the actual pixel rate divided by 4, ie 24000 not 96000.
If no sync polarity is specified, a default of 0 is used (ie the same as a
normal Archimedes).
The true VIDC clock rate specifier (only on RISC OS 3.03 or later) is
intended to be used in systems where the clock rate fed to VIDC is under the
control of some external device, rather than being selected by the clock
select latch. (For example, on the portable machine, the LCD ASIC feeds
either 8MHz or 16MHz into VIDC when LCD modes are selected).
The values programmed into the clock select latch and the VIDC divider are
still determined either from the control register specifier or a pixel rate
specifier assuming the same range of clock speeds as on the A540, but the
VIDC clock rate specifier is used to determine the video memory rate,
which in turn determines the VIDC FIFO Request Pointer values (bits 4 and 5
of the VIDC control register). The VIDC clock rate specifier is also stored
in VDU variable VIDCClockSpeed (&AC), which is used by the SoundDMA module
to determine the VIDC Sound Frequency Register value.
Doc/Kernel deleted 100644 → 0
View file @ d9272e7d
> net#arf:$.a500.RiscOS+.doc.Kernel
Description: Documentation of changes to kernel for PRM
Author: Tim Dobson
Status: Preliminary
History:
06-Oct-89 TMD Created
13-Oct-89 TMD Added documentation of OS_RemoveCallBack
27-Oct-89 TMD Added documentation of VDU variable VIDCClockSpeed
01-Dec-89 NRaine Added documentation of OS_FindMemMapEntries
04-Dec-89 TMD Documentation of OS_FindMemMapEntries updated slightly
The description of bug fixes below is in a very rough state at the moment -
it will need to be tidied up before publication. Not all of the information
below is relevant to the average user.
Documentation updates since RISC OS 2.00 release
------------------------------------------------
Changes applying to RISC OS 2.01
--------------------------------
A new SWI, OS_ChangeRedirection, has been added, to allow the reading and
writing of the handles associated with OS_CLI input/output redirection. This
call was provided for future versions of the task window module, so that
these handles can be made local to the task running in a task window.
SWI OS_ChangeRedirection
Read or write OS_CLI input/output redirection handles
in: R0 = new input handle (0 => not redirected, -1 => leave alone)
R1 = new output handle (0 => not redirected, -1 => leave alone)
out: R0 = old input handle (0 => not redirected)
R1 = old output handle (0 => not redirected)
****************************************************************************
In RISC OS 2.00, the SWI OS_AddCallBack allowed interrupt routines to
request a callback, which was granted later when RISC OS was about to
exit to a user mode routine with IRQs enabled. However there was no way to
cancel a callback request before it was granted. This could cause problems,
for example if a module is being killed, and it has outstanding callback
requests, it must refuse to die, otherwise the callback may be granted after
that memory has been reused for something else. For this reason a new SWI,
OS_RemoveCallBack, has been added.
SWI OS_RemoveCallBack
Remove a transient callback from the list
in: R0 = address that was to be called
R1 = value of R12 that the routine was to be called with
out: R0 = preserved
R1 = preserved
****************************************************************************
A new VDU variable, VIDCClockSpeed (variable number 172), has been added.
The value of this variable is the current VIDC clock rate, in kHz. This
value changes when a screen mode is selected which requires a different
clock rate. The value is read in the same way as other VDU variables, by
issuing the SWI OS_ReadVduVariables.
Typical values are 24000 (ie 24MHz) for TV standard modes, 25175 (ie
25.175MHz) for VGA modes, and 36000 (ie 36MHz) for super-VGA modes.
****************************************************************************
A number of routines were changed to improve IRQ latency:-
a) New version of ChangeDynamicArea which reenables interrupts.
b) Heap manager extend block has improved IRQ latency.
c) Made OS_Byte &87 restore caller's IRQ state during call.
d) Made OS_Word &0E,0 enable IRQs during call.
e) Made OS_Word &15,0 enable IRQs during call.
The heap manager has been optimised in a few places.
The routine that converts a date and time value (in hours, minutes, seconds
etc) into a 5-byte centisecond value has been made smaller and much faster.
Bug fixes
---------
Fixed bug in extend heap call (stack imbalance when returning 'No RAM for
extending heap' error)
Fixed "*%" (LDREQB not LDREQ).
Fixed OS_ReadArgs with a /E argument that evaluates to a string (always used
to give 'Buffer full' - also fixed 2 other bugs lurking in the background,
viz. did STRB of buffer addr assuming it was non-zero to indicate a string,
and didn't allow for length and type bytes in amount free value.
Fixed OS_Word &15 reason code 4 (Read unbuffered mouse position) - it used
to generate undefined instruction trap due to stack mismatch.
Fixed OS_SWINumberToString with negative numbers.
Fixed ROMModules never saying 'Running'.
Made OS_SpriteOp reentrant by pushing register dump area on stack.
Fixed sideways scroll by one 'byte' in MODEs 3 and 6.
Fixed incarnation names being terminated by 1st character.
Fixed *Unplug using address as extra terminator for module name.
Fixed podule IRQ despatcher corrupting R0 (prevented it from correctly
disabling the podule IRQ (or podule FIQ-as-IRQ) interrupt if no handler)
RR-2047: Fixed bug in GSRead with quoted termination.
RR-2060: Fixed bug in AddCallBack which freed the wrong heap node.
RR-2066: Fixed bug which occasionally left soft cursors on the screen.
RR-2067: Fixed bug in keyboard driver (pressing Break (as escape) key when
keyboard buffer full did nothing)
RR-2079: Fixed bug in CallAfter/Every which returned duff error pointers.
Changed error message from null string to 'Invalid time interval'.
RR-2080: Fixed rename incarnation bug.
RR-2099: Fixed bug in monadic plus/minus in EvaluateExpression (eg *Eval
50*-3)
RR-2105: Added help on LEN in *Help Eval.
RR-2108: Fixed bug in prefer incarnation which returned duff error pointers.
Changes applying to RISC OS 2.04
--------------------------------
A new SWI OS_FindMemMapEntries has been added to allow fast scanning of the
soft CAM map to find the correct page numbers for a given range of addresses.
For efficiency, the caller supplies the probable page numbers as well as the
addresses, so that the routine can take a quick look to check if the page
number is already correct before scanning the rest of the CAM map.
SWI OS_FindMemMapEntries
In: R0 -> table of 12-byte page entries
+0 4 probable page number (0..npages-1) (use 0 if no idea)
+4 4 logical address to match with
+8 4 undefined
terminated by a single word containing -1
Out: table of 12-byte entries updated:
+0 4 actual page number (-1 => not found)
+4 4 address (preserved)
+8 4 page protection level
terminator preserved
Doc/KernlSplit deleted 100644 → 0
View file @ d9272e7d
; > KernlSplit
Feasibility of splitting the RISC OS kernel
===========================================
Author: Tim Dobson
Name: KernlSplit
Document version: 0.01
Last modified: 19-Apr-90
Cbange record:
Date Name Description of change
---- ---- ---------------------
19-Apr-90 TDobson Started
This document discusses the feasibility of splitting the RISC OS kernel into
separate modules/code segments for each device driver.
Suggested device drivers to be split off:-
VDU
Screen hardware drivers
VIDC
Pointer
Palette
Hardware scroll/multiple display banks
Allocation of screen memory
Bitmap manipulation
Wrch
Sprites
Draw
Fonts
ColourTrans
Keyboard/mouse
IIC
Real time clock
CMOS RAM
Serial
Centronics
Memory control
Doc/MMUControl deleted 100644 → 0
View file @ d9272e7d
; Available from RISC OS 3.30 onwards
SWI OS_MMUControl (&6B)
On entry:
R0 = reason code/flags (must be zero)
R1 = XOR mask
R2 = AND mask
On exit:
R1 = old value of control register
R2 = new value of control register
Interrupts:
Interrupt status is undefined
Fast interrupts are enabled
Processor mode:
Processor is in SVC mode
Re-entrancy:
Not defined
Use:
This call performs a read-modify-write operation on the ARM MMU
control register. The new value of the register is
((old value AND R2) XOR R1)
The old value of the register is returned in R1, and the new value
in R2. If the call results in the C (Cache enable) bit being
changed, the cache is flushed.
This call is intended for internal system use only. Users wishing to
enable or disable the cache should use the *Cache command instead.
Doc/Mode22 deleted 100644 → 0
View file @ d9272e7d
Title: Mode22
Author: Tim Dobson
History:
05-Dec-91 TMD Created
From RISC OS 3.03 onwards a new screen mode (22) is available, on monitor
types 0 and 1 only, which is suitable for use by visually impaired people.
In terms of pixels and colours the mode is equivalent to mode 35 (an
overscan mode), ie 16 colours, 768 pixels by 288 rows.
However, the ratio of OS coordinates to pixels is changed so that instead of
the screen being 1536 by 1152 coordinates like mode 35, it is only 768 by
576 coordinates. This results in most text and graphics in the desktop being
drawn twice as large in both X and Y directions, thus making them easier to
see.
There are currently a number of problems associated with this mode:-
a) The desktop tool sprites (ie the sprites used in window borders and the
like) are inappropriate for this mode, causing some horizontal lines to
become double thickness, and some vertical lines to disappear entirely.
b) Some applications (including those in the ROM) create windows of a
certain size without scroll bars, and assume that the screen will be big
enough in one or both directions to accommodate the whole of the window.
Some parts of these windows may then be inaccessible.
Examples of this are:-
Filer windows with 'Full info' selected
!Alarm 'Setup','Set clock', 'Set alarm' (particularly repeating alarms)
windows
!Chars window
!Draw toolbox (goes partly off bottom)
!Edit 'Find text' window (particularly with 'Magic characters' or
'Wildcarded expressions' turned on
c) Some applications may create windows and then assume that the
window has been created that size, and then create icons in that
window assuming that size. The icons will then appear in the wrong
place, eg overlapping other icons.
Examples of this are:-
!Paint tool window with various tools selected (eg use sprite as brush)
d) Some applications may create windows aligned with the bottom of the
screen, such that the title bar goes completely off the top of the screen.
The window therefore cannot be moved.
Examples of this are:-
Some !Impression windows.
e) Some applications which use sprites to update their windows, always use
a fixed number of pixels for their windows. The inside of the window
therefore does not appear double size.
Examples of this are:-
PC emulator (in a window).
Doc/Modes deleted 100644 → 0
View file @ d9272e7d
Modes we can do:
DRAM-only system: Peak bandwidth used (x 1E6 bytes/sec)
Total bandwidth available
= 46.5E6 bytes/sec
640 x 480 (72Hz) at 8bpp 31.5
800 x 600 (56Hz) at 8bpp 36
800 x 600 (60Hz) at 8bpp 40
800 x 600 (72Hz) at 4bpp 25
1024 x 768 (60Hz) at 4bpp 32.5
1024 x 768 (70Hz) at 4bpp 37.5
1M VRAM system:
Total bandwidth available
= 80E6 bytes/sec
640 x 480 (72Hz) at 16bpp 63
800 x 600 (56Hz) at 16bpp 72
800 x 600 (60Hz) at 16bpp 80
800 x 600 (72Hz) at 8bpp 50
1024 x 768 (60Hz) at 8bpp 65
1024 x 768 (70Hz) at 8bpp 75
2M VRAM system:
Total bandwidth available
= 160E6 bytes/sec
640 x 480 (72Hz) at 32bpp 126
800 x 600 (56Hz) at 32bpp 144
800 x 600 (60Hz) at 32bpp 160
800 x 600 (72Hz) at 16bpp 100
1024 x 768 (60Hz) at 16bpp 130
1024 x 768 (70Hz) at 16bpp 150
Doc/MonLead deleted 100644 → 0
View file @ d9272e7d
; > Doc.MonLead
Title: MonLead
Author: Tim Dobson
Version: 0.04
Started: 19-Mar-91
Last updated: 24-Apr-92
Status: Incomplete
History:
19-Mar-91 TMD Created
19-Mar-91 TMD Updated
10-Apr-91 TMD Added documentation of Service_MonitorLeadTranslation
24-Apr-92 TMD Corrected information to match bodge for LiteOn monitor
Automatic detection of monitor type from monitor lead ID pins
=============================================================
Some RISC OS computers have circuitry which allows the detection of the
state of ID pins on the monitor connector. This allows the computer to
distinguish between most types of monitor, and adjust its video output
accordingly.
To support this, a number of changes have been made to RISC OS:-
a) To simplify the interface, the commands *Configure Mode and
*Configure WimpMode have been merged. Both commands control the same CMOS
location. Therefore the same screen mode will be selected on startup
irrespective of whether the desktop is being used.
b) The commands *Configure Mode/WimpMode, *Configure MonitorType, and
*Configure Sync now take the keyword Auto as an alternative to a numeric
parameter. If this option is configured, then RISC OS will determine a
reasonable default for the particular parameter, based on the type of
monitor plugged in.
As the default is for all three to be set to Auto, the user should only have
to change the settings if he has a type of monitor which is not recognised
properly, or if he wishes to use a different screen mode from the chosen
default.
c) The effect of holding certain keys down on power-on is slightly changed:-
Key held down on power-on Settings of CMOS RAM
R or Delete MonitorType Auto, Mode/WimpMode Auto, Sync Auto, and all the rest it used to
T or Copy MonitorType Auto, Mode/WimpMode Auto, Sync 0 (separate syncs), and all the rest
Keypad 0 to 9 MonitorType 0 to 9
Keypad dot MonitorType Auto, Mode/WimpMode Auto, Sync Auto
d) A new service has been added which allows unknown values of the monitor
ID to be recognised by modules and converted into the appropriate monitor
type number, sync type and default mode, as follows:-
Service_MonitorLeadTranslation (&76)
in: R1 = service code (&76)
R2 = monitor lead ID (see below)
out: If monitor lead ID is recognised, then the module should set
R1 = 0 (claim service)
R3 = default screen mode number to use on this type of monitor
R4 = monitor type number to use (as used in *Configure MonitorType)
R5 = sync type to use on this type of monitor
(0 => separate syncs, 1 => composite sync)
All other registers must be preserved.
If the monitor lead ID is not recognised, the module should preserve
all registers.
The monitor connector provides 4 ID pins, ID0-ID3. Each of these may be
connected to 0v, +5v or to the Hsync pin. The monitor lead ID therefore
represents the state of the 4 ID pins by 8 bits as follows:-
Bit 0 Bit 1 State of ID0
Bit 2 Bit 3 State of ID1
Bit 4 Bit 5 State of ID2
Bit 6 Bit 7 State of ID3
0 0 Tied to 0v
1 0 Tied to +5v
0 1 Tied to Hsync
1 1 Inderminate - either the state is fluctuating
or machine is not capable of reading the ID
The service is issued when SWI OS_ReadSysInfo is called with R0=1 (see
document 'ReadSysInf') if any of the configured Mode/MonitorType/Sync are
set to Auto.
If the service is not claimed, then RISC OS checks the monitor lead ID
against the following list of recognised IDs:-
Monitor ID pins Monitor type Sync type Default mode
0=0v,1=+5v,H=Hsync,
X=don't care
Pin 0 1 2 3
1 1 H X 1 (Multisync) 1 (composite) 27
1 0 1 X 3 (Mono VGA) 0 (separate) 27
0 1 1 X 3 (Colour VGA) 0 (separate) 27
0 1 0 X 1 (Multisync) * 0 (separate) 27
H 1 1 X 0 (TV standard) 1 (composite) 12
For all other ID values RISC OS uses the TV standard monitor settings.
* This entry should really be monitor type 4 (Super VGA). However the LiteOn
monitor returns this monitor ID, even though it can do the TV standard
modes. RISC OS therefore selects monitor type 1 instead, so the TV standard
and VGA standard modes can be selected on this monitor.
Doc/PaletteV deleted 100644 → 0
View file @ d9272e7d
Title: PaletteV
Author: Tim Dobson
History:
11-Nov-91 TMD Adapted from ColourTrans.Doc.PaletteV
25-Nov-91 TMD Changed a bit about setting flashing colours
From RISC OS 3.03 onwards, the kernel has a default entry on PaletteV. Also,
a number of additional reason codes have been added, to facilitate the
implementation of the LCD drivers for Perth.
The new specification for PaletteV is as follows:-
R4 holds a reason code on entry to the vector. Any owner of the vector which
has carried out the operation requested should set R4 to zero and claim the
vector.