Skip to content

GitLab

Commit 5f9b5a63 authored by ROOL's avatar ROOL 🤖
Browse files

This commit was manufactured by cvs2git to create branch 'StrongARM'. 

Sprout from Black 1996-11-05 09:41:48 UTC Neil Turton <nturton@gitlab.riscosopen.org> 'Import from cleaned 360 CD'
Cherrypick from master 1996-11-05 09:40:48 UTC Neil Turton <nturton@gitlab.riscosopen.org> 'Clean reimport of hdr.RISCOS (real commit date 2008-03-28 by bavison), without any of the 3rd party allocations.':
    hdr/RISCOS
Delete:
    Doc/!ReadMe
    Doc/0197276.02
    Doc/5thColumn/Manual
    Doc/A540Extend
    Doc/Kernel
    Doc/KernlSplit
    Doc/MMUControl
    Doc/MemMaps/130
    Doc/MemMaps/258
    Doc/Mode22
    Doc/Modes
    Doc/MonLead
    Doc/PaletteV
    Doc/PrivDoc/5thColumn/Concept
    Doc/PrivDoc/MMPM
    Doc/PrivDoc/ScreenMode
    Doc/ReadSysInf
    Doc/TVmodesMed,dde
    OldTestSrc/A600tlb
    OldTestSrc/Arm3
    OldTestSrc/Begin
    OldTestSrc/Cmos
    OldTestSrc/ExtCmd
    OldTestSrc/ExtIO
    OldTestSrc/Ioc
    OldTestSrc/MEMC1
    OldTestSrc/Mem1IOMD
    OldTestSrc/Mem1MEMC1
    OldTestSrc/Mem2
    OldTestSrc/Mem3
    OldTestSrc/Mem4
    OldTestSrc/Mem5
    OldTestSrc/TestMain
    OldTestSrc/Vidc
parent 3da129d2
Hide whitespace changes
Inline Side-by-side
Showing with 0 additions and 4337 deletions
Doc/!ReadMe deleted 100644 → 0
View file @ 3da129d2
> !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 @ 3da129d2
Copyright (C) Acorn Computers Ltd. 1993 0197,276/FS Issue 2 **Live**
Medusa Memory Management Software Functional Specification
==========================================================
-----------------------------------------
| Drawing No : 0197,276/FS |
| Issue : 2 **Live** |
| Date : 15th April 1993 |
| Author : Tim Dobson |
| Sheets : n |
| Last Issue: ? |
-----------------------------------------
Contents
========
1 History
2 Outstanding Issues
3 Overview
4 Technical Background
5 User Interface
5.1 TaskManager and large RAM sizes
6 Programmer Interface
6.1 Logical memory map
6.2 Free pool
6.3 New SWI: OS_DynamicArea
6.3.1 Reason codes
6.3.1.1 Create dynamic area
6.3.1.2 Remove dynamic area
6.3.1.3 Return information on dynamic area
6.3.1.4 Enumerate dynamic areas
6.3.1.5 Renumber dynamic area
6.3.2 Dynamic area handler routine
6.3.2.1 PreGrow
6.3.2.2 PostGrow
6.3.2.3 PreShrink
6.3.2.4 PostShrink
6.3.3 Sequence Of Actions When OS_ChangeDynamicArea Is Called
6.3.3.1 Service_PagesUnsafe
6.3.3.2 Service_PagesSafe
6.3.4 Implementation Notes for OS_ChangeDynamicArea
6.3.5 OS_DynamicArea Service Calls
6.3.5.1 Service_DynamicAreaCreate (&90)
6.3.5.2 Service_DynamicAreaRemove (&91)
6.3.5.2 Service_DynamicAreaRenumber (&92)
6.4 New SWI: OS_Memory
6.4.1 OS_Memory Reasons 0-5: Convert Memory Address
6.4.2 OS_Memory Reasons 6-8: Physical Memory
6.4.2.1 Read Physical Memory Arrangement Table Size
6.4.2.2 Read Physical Memory Arrangement Table
6.4.2.3 Read Amounts Of Various Sorts Of Memory
6.4.3 I/O Space Information
6.4.3.1 Read Controller Presence
6.5 Old SWI OS_SetMemMapEntries (&53)
6.6 Old SWI OS_ReadDynamicArea (&5C)
6.7 New SWI OS_ClaimProcessorVector
7 External Dependancies
8 Development Test Strategy
9 Organisation
10 Future Enhancements
10.1 Abort trappping
10.1.1 Technical background
10.1.2 New SWI: OS_AbortTrap
10.1.2.1 Add abort trap
10.1.2.2 Remove abort trap
1. History
==========
TMD 05-Nov-92 Started initial draft
TMD 08-Mar-93 More detail added
Issue A TMD 21-Apr-93 Released for initial review
JSR 11-May-93 Input from review entered
JSR 24-May-93 Adjustments to area grow and deletion
behaviour.
Add 2 controllers to list: VIDC1 and VIDC20 to
allow ScreenTricks module to operate.
JSR 02-Jun-93 Added section to development test strategy for
Wimp and Switcher testing.
JSR 04-Jun-93 Comments on Issue 1 spec from DLowdell.
2. Outstanding Issues
=====================
What if anything should be done to the task manager's task display to cope
with large memory sizes?
The handling of Wimp_ClaimFreeMemory. This SWI claims the free pool making
it available for data transfers. The Wimp used to implement this by putting
the free memory on the end of the current task. This is no longer
necessarily going to work as there may not be any free space beyond the end
of the current task's memory. Also, it is quite likely that there won't be
enough space for all the free memory.
3. Overview
===========
This specification covers changes to the memory management system in RISC
OS for Medusa platforms.
The main features of Medusa platforms which require changes to RISC OS's
memory management are as follows:-
1) Ability to cope with RAM sizes up to 256+2Mbytes, rather than the
current maximum of 16Mbytes;
2) Ability to control DMA;
3) Requirements for second processor card drivers to claim memory;
4) Physical RAM no longer contiguous;
5) ARM600 MMU requires page table allocation;
6) Logical memory map expansion due to 32-bit address space.
7*) Changes to support emulation of VIDC1;
8*) Changes to support line-doubling;
Note: The implementation of the starred items above (VIDC1 emulation,
line-doubling) are not part of the Medusa project; however it is an aim of
the memory management work that it should be possible to implement these in
a soft-loaded module at a later date.
4. Technical Background
=======================
In RISC OS 2 and 3 (version 3.10) the memory management task was divided
between the kernel and the wimp. The kernel ordered the memory into dynamic
areas and an application space, and the wimp then bludgeoned the kernel into
not getting in the way of the wimp's model of having a free pool and
multiple application spaces, rather than just the one application space
which had all spare memory in it. For Medusa the free pool management will
be moved into the kernel so that there isn't such a wrestling match between
the kernel and the wimp. The wimp will still manage the multiple application
spaces - it being the module responsible for constructing and managing tasks
in the desktop. The main kernel interface for memory management was
OS_ChangeDynamicArea which simply allowed the resizing of dynamic areas.
This has been added to for Medusa with the OS_DynamicArea SWI for the
control, creation and deletion of dynamic areas.
The dynamic area management in RISC OS 2 and 3 (version 3.10) was somewhat
tied together with the dynamic area clients. The change dynamic area SWI
specifically called other modules depending on which dynamic area was being
resized. The result was that there was no flexibility with how dynamic areas
were used.
Other memory related services were not available. For example it was not
possible to find out what memory or hardware was available on the system
without knowing a great deal about the platform.
Memory is referred to in three ways: physcial address, logical address and
physical page number. The first two refer to the address of the memory in
the physical address space (what IOMD presents to ARM) and logical address
space (what the ARM memory manager presents to the ARM core) respectively.
The physical page number is an arbitrary number assigned to RAM pages. It is
necessary to have this last abstraction to save space. If it weren't there
then the storage and management overheads would be prohibitive on a small
memory machine, which, as Medusa is targetted at under 1000 pounds, is
likely to be a majority of users. The way physical page numbers are
allocated is that all the contiguous RAM section in physical address space
are bunched together and the page numbers allocated from 0 upwards.
There are several interfaces described here which use Page blocks. These are
tables of 3-word records:
word use
0 Physical page number
1 logical address
2 physical address
That is, a block of memory 12*N bytes big where N is the number of records
in the block. They are used to pass round lists of addresses or pages.
5. User Interface
=================
5.1 TaskManager and large RAM sizes
-----------------------------------
The TaskManager module's 'Task display' window does not cope well in this
area at present. The combination of a 16-fold increase in maximum RAM size
and an 8-fold decrease in page size means that the existing linear 1
pixel-per-page model will not be practical on large memory machines. A
number of options are possible:-
a) Do nothing. It is rare that anyone will want to manually drag an area's
size to anything particularly big. Most big programs will set their own
Wimp slot size;
b) Allow the user to click in the number fields and enter a number
(presumably still in K);
c) Make the scale exponential (ie at the small sizes it goes in units of
4K, but when the area gets bigger go in larger and larger steps).
d) Make the scale a modified exponential (1+log(x)/c).
5.2 *-Command *Cache On/Off
---------------------------
A module will be provided to give this functionality. It will switch both
caching and write-buffering on and off. The corresponding SWIs will not be
supplied as they are inapplicable to an ARM600/700 based system.
6. Programmer Interface
=======================
6.1 Logical Memory Map
----------------------
Address Size Use Public?
00000000 16k System workspace Private
00004000 16k Scratch space Public(1)
00008000 28M-32k Application space Public
01C00000 8k SVC stack Public(2)
01C02000 2M-8k System heap Private
01E00000 8k Undefined stack Public(2)
01E02000 1M-8k Soft CAM map Private
01F00000 32k Cursor/sound etc Private
01F08000 32k "nowhere" Private
01F10000 1M-64k Reserved for fake screen (480k) Private
02000000 12M RMA Public(3)
02C00000 4M Level 2 page tables Private
03000000 4M I/O space Private(4)
03400000 1M Reserved for VIDC1 emulation Private
03500000 1M VIDC20 Private
03600000 1M Reserved for Vinit &c emulation Private
03700000 1M Reserved for 2nd Proc ctrl regs Private
03800000 8M ROM Private
04000000 2G-64M Dynamic areas Public(5)
80000000 512M Copy of physical space Private
A0000000 1 1/2 G More dynamic areas Public(5)
Notes:
1) This may be used by any module. The rules for its use are:
Not in an IRQ routine
Not if you're going to call something which might use it while you
are
Example clients are: FileCore to hold structures whilst working out how to
allocate some free space; Filer to hold structures for OS_HeapSort.
2) It may be assumed that these end on a 1M boundary and will exception if
accessed beyond that end. However, the exact location of these stacks should
not be assumed.
3) The location of RMA and its maximum size may not be assumed. However, it
is guaranteed that it will be in low 64MBytes (ie can execute 26 bit code).
4) Except where particular device drivers export hardware addresses.
5) Only in so far as a client may make its own dynamic area.
6.2 Free pool
-------------
Large RAM sizes pose a problem for RISC OS, because the existing metaphor
that all spare memory lives in application space breaks down. The current
limit on application space size is 16MB, whereas the maximum RAM size on
Medusa platforms is 258MB. Although this limit can be moved up a little by
moving other areas out of the way, it is not possible to extend it enough
(eg I/O still has to live at &03000000 onwards).
To cope with this a new dynamic area is created, known as the "free pool"
(area number 6). The operation of SWI OS_ChangeDynamicArea is modified as
follows:-
a) When an area (other than the free pool) is grown, memory is taken from
the free pool, if any exists (the current application is not notified
of this).
If having shrunk the free pool to zero size, there is still not enough
memory for the growth, the kernel attempts to remove pages from the
application space as it does under existing versions of RISC OS.
b) When an area (other than the free pool) is shrunk, the pages recovered
are added to the free pool. The current application is not consulted.
c) If the free pool itself is grown, pages are taken from application
space to put in it (and the application consulted beforehand).
d) If the free pool is shrunk, the recovered pages are added to
application space (the application is consulted beforehand).
The WindowManager module also changes, to take this into account. In some
ways its operation is simplified, as it no longer needs to maintain its own
free pool. However the implementation of the following SWIs needs to
change:-
Wimp_TransferBlock at present puts all used task memory into application
space, and then copies the relevant bits over. It cannot do this any more,
as the total used task memory may not fit into application space. Instead
it must do the following:-
Split the transfer into chunks of no more than half of the maximum
application memory size. For each chunk, put the appropriate pages of the
source block in at the start of application space, and the appropriate
pages of the destination block above these, then perform the transfer.
After all chunks have been done, restore the current task's pages in
application space.
Wimp_ClaimFreeMemory needs to be modified, because the Wimp no longer
maintains control of the free pool.
6.3 New SWI: OS_DynamicArea (&66)
---------------------------------
This SWI performs miscellaneous operations on dynamic areas.
On entry, r0 provides a reason code which determines which operation is
performed.
Note that as all operations on dynamic areas work in physical page numbers
it is not possible to map anything other than RAM pages (DRAM and VRAM)
into a dynamic area. In particular EASI space cannot be mapped in.
6.3.1 Reason codes
------------------
6.3.1.1 Create dynamic area
---------------------------
This call creates a new dynamic area.
On entry: r0 = 0 (reason code)
r1 = new area number (-1 => RISC OS should allocate number)
(must not be 128-255 - see section 6.6)
r2 = initial size of area (in bytes)
r3 = base logical address of area (-1 => OS should allocate
base address)
r4 = area flags
bits 0..3 = access privileges to be given to each page
in the area (same format as for
OS_Read/SetMemMapEntries)
bit 4 = 0 => area is singly mapped
= 1 => area is doubly mapped
bits 5..31 must be zero
r5 = maximum size of area, or -1 if the area should be
capable of growing to the total RAM size of the
machine
r6 -> area handler routine, or 0 for no routine
r7 = workspace pointer to be passed in r12 on entry to
area handler (should be 0 if r6=0)
r8 -> area description string (null terminated), eg
"Font cache". This string will be displayed in the
TaskManager window.
On exit: r1 = allocated area number
r3 = specified or allocated base address of area
r5 = specified or allocated maximum size of area
r0,r2,r4,r6-r8 preserved
An error will be returned if:
* the given area number clashes with an existing area, or
* the logical address space occupied by the area at maximum size would
intersect with any other area at maximum size, or
* there is not enough contiguous logical address space to create the
area, or
* there is not enough memory in the free pool to allocate level 2 page
tables to cover the area at maximum size.
If r1 is -1 on entry the RISC OS will allocate an area number itself.
This will be greater than or equal to 256. This means (see section 6.6)
that OS_ReadDynamicArea on these areas will always return with r2
being the maximum area size.
For singly mapped areas the base logical address is the lowest logical
address used by that area. The area grows by adding pages at the high
address end.
For doubly mapped areas the base logical address is the (fixed) boundary
between the two mappings: the first mapping ends at r3-1, and the second
starts at r3. When one of these areas grows the pages in the first copy
move down to accommodate the new pages at the end, and the second copy
simply grows at the end.
On entry, r6 points to the area handler routine which gets called with
various reason codes when an an area is grown or shrunk. If zero is
passed in, then no routine will be called, and any shrink or growth will
be allowed.
Details of the entry and exit conditions for this routine are given
in section 6.3.2 below.
The area is created initially with size zero (ie no pages assigned to
it), and is then grown to the size specified in size r2, which involves
the area handler being called in the same way as if
OS_ChangeDynamicArea was called to grow the area.
The area is created with a maximum size equal to either the amount given
in r5 on entry, or the total RAM size of the machine, if this is
smaller. If r5 is -1 on entry, then the maximum size will be set to the
total RAM size of the machine.
If r3 on entry is -1, then RISC OS allocates a free area of logical
address space which is big enough for the maximum size of the area.
Once the area has been created Service_DynamicAreaCreate will be issued
to inform the rest of the system about this change.
Notes for application writers
-----------------------------
The following facilities:
* the ability to create areas with specific area numbers
* the ability to create areas at specific logical addresses
* the ability to create doubly-mapped areas
are intended for internal system use only.
Applications should in general create only singly-mapped areas, and
request that RISC OS allocate area numbers and logical addresses.
This will prevent clashes of area numbers or addresses.
6.3.1.2 Remove dynamic area
---------------------------
This call removes a previously created dynamic area.
On entry: r0 = 1 (reason code)
r1 = area number
On exit: All registers preserved
An error is returned if the area was not removed for any reason.
Before the area is removed, RISC OS attempts to shrink it to zero size.
This is done using ChangeDynamicArea. If the ChangeDynamicArea returns
an error then the area will be grown back to its original size using
ChangeDynamicArea and the remove dynamic area call will return with an
error. If the ChangeDynamicArea to reduce the area to 0 size worked then
the area will be removed.
Once the area has been removed Service_DynamicAreaRemove will be issued
to inform the rest of the system about this change.
6.3.1.3 Return information on dynamic area
------------------------------------------
This call returns various information on a dynamic area.
On entry: r0 = 2 (reason code)
r1 = area number
On exit: r2 = current size of area (in bytes)
r3 = base logical address of area
r4 = area flags
r5 = maximum size of area
r6 -> area handler routine
r7 = workspace pointer for area handler
r8 -> area description string (null terminated)
Note that for doubly-mapped areas, r3 on exit from this call returns the
address of the boundary between the first and second copies of the area,
whereas OS_ReadDynamicArea returns the start address of the first copy
(for backwards compatibility).
6.3.1.4 Enumerate dynamic areas
-------------------------------
On entry: r0 = 3 (reason code)
r1 = area number or -1
On exit: r1 = next area number or -1
This allows an application to find out what dynamic areas are defined.
-1 is used to start the enumeration and -1 indicates that the
enumeration has finished.
6.3.1.5 Renumber dynamic area
-----------------------------
This call renumbers a dynamic area.
On entry: r0 = 4 (reason code)
r1 = old area number
r2 = new area number
On exit: All registers preserved
An error is returned if the area specified by the old area number does
not exist or if the new number clashes with an existing area.
This call is intended for system use only.
Once the dynamic area has been renumbered Service_DynamicAreaRenumber
will be issued to inform the rest of the system about this change.
6.3.1.6 Read size of application space
--------------------------------------
This call returns the maximum size of application space
On entry: r0 = 5 (reason code)
On exit: r5 = maximum size of application space
This call is intended for system use only.
6.3.2 Dynamic area handler routine
----------------------------------
This section describes the reason codes passed to the dynamic area handler
routine, with their entry and exit conditions.
This routine is called when the size of an area is being changed.
On entry, r0 contains a reason code, which describes what is happening.
It should be noted that when called, OS_ChangeDynamicArea is currently at
work and will reject requests to resize dynamic areas. As a consequence
any SWIs which might resize a dynamic area should be avoided. Such things
as OS_Module to claim some workspace are an example, and hence most file
operations should be avoided (although I/O on an existing file is more
safe than other operations).
The reason codes are as follows:-
6.3.2.1 PreGrow (0)
-------------------
This reason code is issued when a call to OS_ChangeDynamicArea results
in an area growing. It is called before any pages are actually moved. It
allows the handler to specify particular physical pages if it needs them
(eg for the screen area), or to object to the size change.
On entry: r0 = 0 (reason code)
r1 -> Page block
The physical page number entries will be set to -1
r2 = number of entries in Page block (= number of pages
area is growing by)
r3 = number of bytes area is growing by (= r2 * pagesize)
r4 = current size of area (bytes)
r5 = page size
r12 -> workspace
On exit: If the growth is OK, then
r0 is preserved
If particular physical page numbers are required then all
the physical page number entries must be filled in with
the required pages. The other entries must be left alone.
V = 0
else
r0 -> error to return, or zero to return generic error
V = 1
endif
All other registers preseved
This call permits the dynamic area handler to request that specific
pages be used for growing the area. If this is the case then all pages
must be specified. The correspondence between the Page block and memory
is that the first entry in the page block corresponds to the lowest
memory address of the extension, and the last entry in the Page block
the highest memory address.
If an error is returned, then the area will not change size.
6.3.2.2 PostGrow (1)
--------------------
This reason code is issued when a call to OS_ChangeDynamicArea results
in an area growing. It is called after the PreGrow reason code has been
issued successfully and the memory pages have been moved. It provides
the handler with a list of which physical pages have been moved into the
area.
On entry: r0 = 1 (reason code)
r1 -> Page block
Only the physical page number entries are defined
r2 = number of entries in Page block (= number of pages
area grew by)
r3 = number of bytes area grew by
r4 = new size of area (bytes)
r5 = page size
r12 -> workspace
On exit: All registers preserved
6.3.2.3 PreShrink (2)
---------------------
This reason code is issued when a call to OS_ChangeDynamicArea results
in an area shrinking. It is called before any pages are moved. It allows
the handler to limit the amount of memory moved out of the area, or to
object to the size change altogether. The shrink amount alowed as
returned by this reason code is permitted to be a non-page multiple. The
ChangeDynamicArea code will ensure the shrink permitted is rounded down
to a page multiple before it is actioned.
On entry: r0 = 2 (reason code)
r3 = number of bytes area is shrinking by
r4 = current size of area (bytes)
r5 = page size
r12 -> workspace
On exit: If shrink (even by reduced amount) is OK, then
r0 preserved
r3 = number of bytes area can shrink by. This must be less
than or equal to r3 on entry.
V = 0
else
r0 -> error block, or zero to return generic error
r3 = 0
V = 1
endif
All other registers preserved
6.3.2.4 PostShrink (3)
----------------------
This reason code is issued when a call to OS_ChangeDynamicArea results
in an area shrinking. It is always called after the PreShrink reason
code has been issued successfully even if the memory pages can't be
moved.
On entry: r0 = 3 (reason code)
r3 = number of bytes area shrunk by
r4 = new size of area (bytes)
r5 = page size
r12 -> workspace
On exit: All registers preserved
6.3.3 Sequence Of Actions When OS_ChangeDynamicArea Is Called
-------------------------------------------------------------
This section has been provided to give an overview of what happens when a
dynamic area's size is changed. This is presented as pseudo-code for
clarity.
Check IRQSemaphore - reject CDA if set
Growing free pool:
(no check for page availability - do as much as possible!)
Application space being shrunk - confirm it's OK:
If CAO in application space then
UpCall_MovingMemory (asks application if it consents to
memory move)
If UpCall *not* claimed Then reject CDA
Else
Service_Memory (asks modules for objectors to the memory
move)
If Service *is* claimed then reject CDA
EndIf
Move pages from application space end to free pool
Growing other dynamic area:
Check for page availability - if not enough available bounce CDA with
error
Table of pages prepared:
Allocates memory
Fills in -1s for 'any page'
PreGrow is called:
replaces -1s if it wants
objects about resize amount perhaps
Check for unavailable pages:
If there is a non -1 which can't be grabbed then reject CDA
Check for application space resizing:
If free pool < amount needed then
If CAO in application space then
UpCall_MovingMemory (asks application if it consents to
memory move)
If UpCall *not* claimed Then reject CDA
Else
Service_Memory (asks modules for objectors to the memory
move)
If Service *is* claimed then reject CDA
EndIf
EndIf
Page replacements determined:
Work out swap sequences on all non -1s
Replace all -1s with actual pages
Pages get grabbed first from the free pool, then underflowing into
the application space
Issue Service_PagesUnsafe (only if PreGrow specified pages)
Pages get moved around:
Do the page moving/swapping (don't swap if pages requested are in
free pool)
Issue Service_PagesSafe (only if PreGrow specified pages)
PostGrow is called:
Sorts out structures for the new size
Shrinking free pool:
Check if application space OK to grow:
If application space < maximum then
If CAO in application space then
UpCall_MovingMemory (asks application if it consents to
memory move)
If UpCall *not* claimed Then reject CDA
Else
Service_Memory (asks modules for objectors to the memory
move)
If Service *is* claimed then reject CDA
EndIf
EndIf
Move pages from free pool to application space
Shrinking other dynamic area:
PreShrink is called:
objects about resize amount perhaps, or gives larger allowed size
Sorts out structures for the new smaller size as the shrink
will definitely go ahead.
Pages get moved around:
Move pages from dynamic area to free pool
PostShrink is called:
Keep subsystem informed.
It should be noted that the system stack is used for the page structure
passed to the PreGrow routine. As a consequence there is a limit to the
amount that an area can be grown by at one time. To get round this problem
an area grow request of a large amount will be performed in several
steps. If one of these steps fails then the grow will terminate early with
the area grown by however much was achieved, but not by the full amount
requested.
You will notice two new service calls were used here:
Service_PagesUnsafe
Service_PagesSafe
which are issued around page swapping to inform any DMA subsystems (eg
IOMD DMA or second processor) that some pages are being swapped around.
Here is the detailed description of these service calls:
6.3.3.1 Service_PagesUnsafe
---------------------------
On entry: r1 = Service_PagesUnsafe
r2 = Page block filled in by the PreGrow routine with the
two address fields filled in too.
r3 = number of entries in Page block
On exit: All registers preserved
The recipient of this service call is being told that the pages
specified are about to be swapped around. Direct memory access
activities involving the specified pages should be suspended until
Service_PagesSafe has been received indicating the pages are safe.
6.3.3.2 Service_PagesSafe
-------------------------
On entry: r1 = Service_PagesSafe (&8F)
r2 = Number of entries in each Page block
r3 -> Page block before move
r4 -> Page block after move
On exit: All registers preserved
The recipient of this service call is being told that the pages
specified have been swapped for different pages and what those different
pages are. Note that the logical addresses in both Page blocks will
match. The 'before' Page block will contain the physical page numbers
and physical addresses of the pages which were replaced, and the 'after'
block the page numbers and physical addresses of the pages which
replaced them.
6.3.4 Implementation Notes for OS_ChangeDynamicArea
---------------------------------------------------
There is an issue with OS_ChangeDynamicArea when a particular page is
requested by the growing dynamic area which is currently in use by the page
tables. The problem is that moving pages that themselves control where the
pages are is a tricky operation. This is exacerbated on level 1 page tables
even more because these are 16k (4 pages) big and must be 16k aligned. This
means that if a level 1 page table needs moving then another 4 page block
needs to be found - potentially resulting in more page swapping to make such
a gap. Level 2 page tables don't have this problem as they're 4k (1 page)
big.
Having said this, unless some mobility is permitted the minimum
configuration which would permit a '486 second processor to work would be
4MBytes. In a 2MByte machine 1M is left free of page tables to allow the
screen to grow, and the 2nd MByte would, as a consequence, be 'contaminated'
with page tables and so would be unavailable for the 2nd processor. If the
page tables could be moved they could reside in the 'screen' MByte as they
could be moved freely about if the screen needed to grow.
6.3.5 OS_DynamicArea Service Calls
----------------------------------
These service calls are designed to keep the rest of the system informed
about changes to the dynamic areas. Their primary customer is the task
manager, although other modules could make use of them.
6.3.5.1 Service_DynamicAreaCreate (&90)
---------------------------------------
On entry: r1 = Service_DynamicAreaCreate (&90)
r2 = area number of area just created
On exit: All registers preserved
This service must not be claimed
This service is issued just after the successful creation of a dynamic
area.
6.3.5.2 Service_DynamicAreaRemove (&91)
---------------------------------------
On entry: r1 = Service_DynamicAreaRemove (&91)
r2 = area number of area about to be removed
On exit: All registers preserved
This service must not be claimed
This service is issued just before the removal of a dynamic
area. It is issued during a call to OS_DynamicArea(1), after the area has
been successfully reduced to zero size, but before it has been removed
completely.
6.3.5.2 Service_DynamicAreaRenumber (&92)
-----------------------------------------
On entry: r1 = Service_DynamicAreaRenumber (&92)
r2 = old area number
r3 = new area number
On exit: All registers preserved
This service must not be claimed
This service is issued during a call to OS_DynamicArea(2), ie when an area
is being renumbered.
6.4 New SWI: OS_Memory
----------------------
This SWI performs miscellaneous operations for memory management.
On entry: r0 = reason code and flags. Bits o-7 are the reason code, bits
8-31 are the flags which may be specific to the reason code.
The other registers are specific to the reason code.
On exit: The returned values are specific to the reason codes.
Here are the defined reason codes:
0-5: Page block Operations
0 - General Page block Operation
1-5 - reserved
6-8 - physical memory:
6 - read physical memory arrangement table size
7 - read physical memory arrangement table
8 - read amounts of various sorts of memory
9-? - I/O space information:
9 - read controller presence
The details of these are given below.
6.4.1 OS_Memory Reason 0: General Page block Operation
------------------------------------------------------
This reason code is used to convert between representations of memory
addresses. The different memory spaces are logical memory, physical
memory and physical pages.
On entry: r0 = flags:
bit meaning
0-7 reason code (0-5)
8-9 which entry is defined in the Page block:
0 - Physical page number
1 - Logcial address
2 - Physical address
10 Physical page number will be filled in when set
11 Logical address will be filled in when set
12 Physical address will be filled in when set
13-14 Cachability control:
0 - no change
1 - no change
2 - disable caching on these pages
3 - enable caching on these pages
15-31 reserved - set to 0
r1 -> Page block
r2 = number of entries in page block
On exit: Page block updated as necessary
The Page block will be scanned and the specified operations applied to
it. It is possible to do address conversions and control the cachability
on a per-page basis. If any page is found to be unconvertable or
non-existent then an error will be returned and the cachability will be
unaffected. Cachability is accumulated for each page. So, for example, if
there are 5 clients which need caching turned off on a page then each of
them must turn caching back on individually for that page actually to
become cached again.
Where an ambiguity may occur, for example in doubly-mapped areas such as
the screen, one of the possible results will be chosen and filled in.
This will only handle RAM addresses. The address fields may be non-page
aligned.
6.4.2 OS_Memory Reasons 6-8: Physical Memory
--------------------------------------------
These are provided to enable a program to find out what physical
memory there is and its arrangement. The first two calls provide
complete information on the available memory. The information is provided
in the form of a table, with each page of physical memory space having
one entry in the table. Due to the large number of pages the table is
packed down to only 4 bits per page. In each byte of the table the low
order 4 bits correspond to the page before the high order 4 bits, ie it
is little-endian. This is the meaning of a nibble in the table:
bit meaning
0-2 type of memory:
0 not present
1 DRAM
2 VRAM
3 ROM
4 I/O
5-7 Undefined
3 0 - Page available for allocation
1 - Page not available for allocation
The page availability is based on whether it is RAM, and whether it has
already been allocated in such a way that it can't be replaced with a
different RAM page eg the OS's page tables or screen memory.
The third call gives a summary of available memory.
6.4.2.1 Read Physical Memory Arrangement Table Size
---------------------------------------------------
On entry: r0 = 6 (bits 8-31 clear)
On exit: r1 = table size (bytes)
r2 = page size (bytes)
This returns information about the memory arrangement table.
6.4.2.2 Read Physical Memory Arrangement Table
-----------------------------------------------
On entry: r0 = 7 (bits 8-31 clear)
r1 = pointer to table to be filled in
On exit: registers preserved
This returns the physical memory arrangement table in the block of memory
pointed at by r1. Note the information about page availability may well
change between this being called before a OS_ChangeDynamicArea and the
PreGrow routine being called, in particular it may have been necessary
for OS_ChangeDynamicArea to allocate level 2 page tables for the grown
area, and these are not available for allocation. Hence, for
applications which require, say, all pages from physical address 0
onwards their PreGrow handler must make this call, rather than the
information being extracted and held before OS_ChangeDynamicArea being
called.
6.4.2.3 Read Amounts Of Various Sorts Of Memory
-----------------------------------------------
On entry: r0 = bits meaning
0-7 must be 8 - its the reason code
8-11 the type of memory:
1 - DRAM
2 - VRAM
3 - ROM
4 - I/O
12-31 reserved - set to 0
On exit: r1 = number of pages of that sort of memory
r2 = page size (in bytes)
6.4.3 I/O Space Information
---------------------------
These give information about the I/O space. Controllers are identified by
type and sequence number so that a machine could be constructed with,
say, more than one IDE controller in it.
6.4.3.1 Read Controller Presence
--------------------------------
On entry: r0 = 9 (bits 8-31 clear)
r1 = controller ID
bit meaning
0-7 controller sequence number
8-31 controller type:
0 - EASI card access speed control
1 - EASI space
2 - VIDC1
3 - VIDC20
On exit: r1 = controller base address or 0 if not present.
This returns the location of a controller on the given machine. For
example the EASI space gives the base address of podule N where N is
the sequence number given. This reason code is provided for internal
use only and is documented here for completeness' sake. In particular
you must use the Podule manager to get at this information and to
control your podule's EASI space access speed.
6.5 Old SWI OS_SetMemMapEntries (&53)
-------------------------------------
As noted in the RISC OS 3 PRMs -1 should be used to indicate that a page
should become inaccessible, for future compatibility. In the Medusa kernel
the future has arrived - only -1 will work!
6.6 Old SWI OS_ReadDynamicArea (&5C)
------------------------------------
As noted in the RISC OS 3 PRMs if bit 7 of the dynamic area number is set
then r2 will be returned with the maximum area size. This is being changed
slightly to be that if the dynamic area number passed in is greater than or
equal to 128 then r2 will be returned as the dynamic area size. Also, if
the dynamic area number passed in is between 128 and 255 inclusive then the
information will be returned for the area whose number is 128 less than the
passed-in value. The net result is that for old dynamic area numbers (0-5)
the functionality is unchanged, but the number-space impact of the
interface is minimised - it was prety horrible to have to force bit 7 of
all dynamic area numbers to be clear just for this SWI, so we just prohibit
a small patch of low numbers instead.
6.7 New SWI OS_ClaimProcessorVector
-----------------------------------
In
r0=Vector and flags
bit meaning
0-7 Vector number:
0 - 'Branch through 0' vector
1 - Undefined instruction
2 - SWI
3 - Prefetch abort
4 - data abort
5 - address exception (only on ARM 2 & 3)
6 - IRQ
7+ - reserved for future use
8 0=release, 1=claim
9-31 reserved, must be 0
r1=replacement value
r2=value which should currently be on vector (only needed for release)
Out
r1=value which has been replaced (only returned on claim)
This SWI provides a means whereby a module can attach itself to one of the
processor's vectors. This is a direct attachment - you get no environment
except what the processor provides. As such, claiming and releasing the
vectors is somewhat primitive - the claims and releases must occur in the
right order (the release order being the reverse of claim order).
On release if the value in r2 doesn't match what is currently on the vector
then an error will be returned. This ensures correct chaining of claims and
releases.
[ Implementation note:
On break the 1st ROM instruction gets copied to location 0 and branched to
(MOV pc, #0). This used to be a branch direct (B thing) instruction, but
will be changed to a branch indirect (LDR pc, [pc, #thing]). This means the
indirection vector must be filled in with the correct reset address. Hence,
the reset vector must be a different indirection vector to the 'Branch
through 0' one.
]
7. External Dependencies
=========================
The development of the new memory management system relies upon the
availability of ARM600 (or 610) processor boards for A540s.
The Window Manager will need modification to cope with the changed memory
management system. In particular it will need to:
Cope with the free pool being external to the wimp
Change how it does TransferBlock operations
Change how it gets the pages for new tasks
8. Development Test Strategy
=============================
PHTester scripts will be writen to exercise the following SWIs:
OS_Memory
All reasons (0-9)
In range, edge of range, just outside range and wildly out of range values
will be tried. Where buffer contents are returned the buffer will be output.
OS_AbortTrap
Where this implemented then the test strategy would be as follows. Due to the
nature of this SWI unsupported PHTester scripts will not be able to do the
job properly. A piece of support code will be written which can be loaded
into RMA and will monitor calls to the abort trapper. A PHTester script will
be written which will load this trapper, add it, exercise it and monitor the
results. The trapper will then be removed twice to make sure the correct
behaviour results.
OS_ChangeDynamicArea
Again, this is hard to test with straight PHTester scripts. Under normal
circumstance the presence of PHTester running will prohibit dynamic areas
growing, however, this can be got around by growing a dynamic area before
PHTester starts, starting the script then shrink the dynamic area thus
giving the system a free pool (PHTester will refuse to allow the application
space to resize and thus the memory will be pushed into the free pool).
Support code will be writen which will monitor service calls and upcalls and
will exercise the various cases. This act of exercising must be done without
PHTester running.
OS_DynamicArea
Again, support code will be needed for PHTester to be usable. With this
support code PHTester scripts will be writen to add (twice) and remove
(twice) a dynamic area. This area will then be resized testing success and
failure of both grow and shrink, failing because of either not enough memory
or unavilable specific pages being requeested. A straight PHTester script
will be used to exercise enumeration, readinfo and renumber operations.
Testing the Wimp and Switcher
Wimp:
SWI Wimp_SlotSize
The behaviour of this SWI depends on a number of external (To the task and calling parameters) factors:
- Environment, particularly MemoryLimit and ApplicationSpace
- Machine state, eg. remaining amount of memory
- Page size, to compare with ARM 3 systems units of 32K should be used
Shrinking a slot:
Needs to be tested when MemLimit <> AppSpace, when MemLimit=AppSpace < RealSpace
where RealSpace is actual memory mapped in- This feature is used extensively by flex.
When a shrink succeedes, the free pool should grow by the shrinkage and the RMA by a roughly
proportional ammount (for slot being reduced)
Growing a slot:
Again Different environments need testing, but also effects near total memory usage:
Eg. A large increase is requested, but only a smaller amount is available. Also when the
area has been grown, there may not be enough RMA to extend the Memory Map slot and so the
slot shrinks by a page.
In both cases the SWI should return with the environment set to the real size and a message sent
to the switcher.
Application testing.
As mentioned above, flex makes good use of the features of this SWI. Loading a file into !Draw
or !Paint should make the slot grow by a comparable amount to the file size (taking into account the
internal storage methods). When the document is discarded the slot should reduce to the value it was
before (unless flex/malloc usage makes this impossible) and total RMA/system memory should be roughly
what it was, though of course for a first document load the application may claim additional memory.
A small application could be written to do similar things repeatedly and could this give a
measure to memory leaks etc. Medusa is bound to be slower because of smaller page size, more pages (which
need to be scanned when growing a slot) and Log-Phys map (Level 2 table) being in RAM rather than on
chip.
SWI Wimp_TransferBlock
Many possible cases:
Should always be possible even if no free memory.
For tasks a,b,c (c is current task)
a <-> b a <-> c c <-> c
For small and large lengths (eg. 1K or 8Meg)
For when c takes up all/most of app space
For when transfers occur to/from non application space (eg. RMA)
For non word aligned/ size transfers
For transfers involving over-the-page memory, eg. 34k-38k (32-36,36-40 pages)
Application testing.
RAM transfer from !Paint to !Draw (this is c->a,small, prob aligned)
Use of !SqlFiler and !Faults (this c(RMA)->a,small, prob aligned)
Some combinations can only be tested on real Medusa's with 32Meg memory.
SWI Wimp_ClaimFreeMemory
Only claimable once at a time, memory should be accessible and remain intact until free'd
(incidentally can be freed by any task).
System testing
*copy, *compact ?
Mode changing:
SWI Wimp_SetMode, *wimpmode
numbers 0-255 as before (testable by script which then checks screen memory usage and VDU
variables) and new style configuration (again script can work out from config the mem usage and VDU
vars). Wimp should shrink screen memory as much as possible and send mode changed message to all tasks
Switcher:
Dynamic areas used to be scanned (finding addresses for all the system pages) now RDA is used.
Dynamic areas (all, including app-created areas) should update when window is open and a task calls
CDA successfully. Areas which are non-fixed should be draggable, should reflect/update area as seen
by a task. Dragging bars should update memory text as appropriate, on medusa platforms with more than
4Meg this should be logarithmic for large values. Switcher should behave as before on non medusa platforms.
9. Organisation
================
The software described herein resides in the RISC OS ROM.
10. Future Enhancements
=======================
Some sort of system to request memory to be freed in cases of memory
shortage might be nice.
OS_Heap to be extended to allow allocation of anchored moveable blocks. This
would be used to prevent heap fragmentation.
10.1 New SWI: OS_AbortTrap (&67)
--------------------------------
This has been moved to the future enhancements section as this is not
required by the project specification, there is insufficient time to do it
and it can be added later if needed. Also, there are some unresolved issues
regarding handling aborts of writes to &00-&1f and handling of coprocessor
data transfer operations.
10.1.1 Technical background
---------------------------
The extra processor modes in the ARM6 and ARM7 processor cores allow for
complete recovery from data aborts, even if the abort happens while in
privileged modes, such as supervisor mode. This was not possible on
earlier processors, because when the abort was taken, the return address
(and condition codes) was placed in r14_svc, thereby corrupting it.
This allows for (amongst other things) complete software emulation of
hardware devices (apart from devices which cause interrupts, or which are
very time-critical). In particular, it becomes possible to write a module
which emulates VIDC1 on systems which are VIDC20 based (provided that the
address map is set up so that the address where VIDC1 is accessed
(&03400000) causes a data abort when written to).
In order to facilitate this kind of activity, RISC OS allows a module to
provide a trap routine for accesses within specified address ranges. This
is an additional feature over and above the usual abort handlers which are
owned by the current application.
When a data abort happens, the OS works out the range of addresses
accessed by the instruction.
It then looks through its MMU page tables, and splits the range into
sub-ranges which correspond to accesses within one page or section, as
appropriate.
For each sub-range, it then checks the access privileges to see if the
access was valid. If so, it performs the access itself. (For a load, it
transfers the data into a temporary stack frame from which the register(s)
will be subsequently loaded. For a store, the stack frame is already set
up with the register(s) to be stored.)
If the sub-range corresponds to a page or section which would have caused
an abort, the sub-range is then checked against its list of abort traps.
Starting with the lowest address in the sub-range, if the address is
contained within any of the address ranges specified in the list, then
the corresponding routine is called. The registers on entry and on exit
are as follows:-
On entry: r0 = flags
bits 1,0 = 00 undefined
01 store
10 load
11 SWP
bit 2 = 0 => user mode access
1 => privileged mode access
bits 3..31 undefined
r1 -> block of registers to be transferred to/from
r2 = lowest address which faulted in the specifed address range
r3 = number of transferred bytes which fall within the specified address range
r4 -> instruction which aborted
r12 = workspace ptr specified in node
SVC26 (at the moment - I might change this to SVC32 at some stage)
On exit: VC => instruction processed, please complete writeback
VS => instruction shouldn't be allowed - generate exception
All registers preserved (apart from PSR)
If the routine wishes to accept the transfer as valid, it must perform the
transfer itself by transferring the data (of length r3 bytes) in or out of
the block pointed to by r1. (In the case of the SWP instruction it must
transfer data out of, then into the block). It should then exit with V=0.
The OS will then advance its address pointer by the number of bytes
processed by this routine, and continue with the next sub-range (if there
are any more to do).
If the routine wishes to fault the transfer after all, it should exit with
V=1. This will cause the OS to call the normal data abort handler. (This
also happens if an address in a sub-range which faulted does not lie in
any address range on the list).
Note: this behaviour currently precludes having two or more abort traps on
the list which have overlapping address ranges, where each trap actually
is interested in a subset of accesses within that range. At the moment,
the OS faults if any trap routine exits VS, whereas it could carry on down
the list looking for further trap ranges containing the address. But then
you would have to have some way of returning saying you had done part of
the transfer.
In addition to trapping page and section faults, the OS has special code
to deal with writes to addresses in the range &00 to &1F inclusive, which
cause aborts on ARM6/7 when the processor is executing in a 26-bit PC mode
(assuming we are in the 32-bit PC configuration, which we are).
If the address range for the transfer includes an address in the range
0-&1F, and the aborting instruction is within the RISC OS "ROM" image,
then RISC OS executes the transfer itself (in 32-bit PC mode), as ROM code
is considered kosher. This is mainly to allow FIQ claimants such as ADFS
floppy drivers or Econet to set up their FIQ code while executing in
26-bit PC mode. It also allows the FPE to set up the undefined instruction
vector (although of course the FPE still has to know that it will get
called in undef_32 mode).
If the aborting instruction is not in the ROM image, then the usual abort
list is checked. If however the address is not in the list, or the routine
exits with V set, then instead of calling the current data abort handler,
the OS calls its default data abort handler (this was so I could then do a
*ShowRegs and find out where the program went bang, rather than have the C
exception handler swallow it up).
Note that if you set up a node to respond to vector poking, and you want
to accept the transfer, you'll have to switch to SVC32 to execute it (this
is why I may change the entry to be called in SVC32.
10.1.2 New SWI: OS_AbortTrap (&66)
----------------------------------
SWI OS_AbortTrap provides calls to add or remove abort trap routines.
On entry, r0 provides a reason code which determines which operation is
performed.
10.1.2.1 Add abort trap (0)
---------------------------
This reason code adds a trap routine to RISC OS's list.
On entry: r0 = 0 (reason code)
r1 = lowest trapped address
r2 = highest trapped address +1
r3 = address of trap routine
r4 = workspace pointer for trap routine
On exit: All registers preserved
The entry and exit conditions for the trap routine are described in
section x.y.z.
10.1.2.2 Remove abort trap (1)
------------------------------
This reason code removes a trap routine from RISC OS's list.
On entry: r0 = 1 (reason code)
r1 = lowest trapped address
r2 = highest trapped address +1
r3 = address of trap routine
r4 = workspace pointer for trap routine
On exit: All registers preserved
Registers r1 to r4 on entry should be identical to those previously
passed to reason code 0.
Doc/5thColumn/Manual deleted 100644 → 0
View file @ 3da129d2
; > 5thColumn
RISC OS Support for extension ROMs
==================================
Author: Tim Dobson
Status: Draft
Issue: 0.03
History:
Date Revision Changes
11-Oct-90 0.00 Started
16-Oct-90 0.01 Completed first draft
08-Feb-91 0.02 Updated to reflect reality
23-Apr-91 0.03 Added note about directly executable
extension ROMS
This document describes the enhancements to RISC OS to support extension (or
"5th column") ROMs.
Extension ROMs are ROMs fitted in addition to the main ROM set, which
provide software modules which are automatically loaded by RISC OS on
power-on.
The availability, size and number of extension ROM sockets depends on which
type of RISC OS computer you are using.
In general, however, RISC OS recognises extension ROMs or ROM sets which are
8, 16 or 32 bits wide, provided the ROM adheres to the specification below.
32 bit wide extension ROM sets are directly executable in place, saving on
user RAM. 8 or 16 bit wide sets have to be copied into RAM to execute.
Creating an extension ROM
=========================
Extension ROMs appear in the ROM area of the memory map, ie between
&03400000 and &03FFFFFF. An extension ROM set must end on a 64K boundary or
at the start of another extension ROM. This is normally not a problem as it
is unlikely you would want to use a ROM smaller than a 27128 (16K), and the
normal way of addressing this would mean that the ROM would be visible in 1
byte out of each word, ie within a 64K addressable area.
Extension ROMs have a header at the end of the ROM image which indicates the
presence of a valid extension ROM. The header is at the end because RISC OS
scans the ROM area downwards from the top.
At the end of each ROM set of size 'n' bytes must be a 16-byte header as
follows:-
Byte address Contents
n-16 1-word size field containing n
n-12 1-word checksum (bottom 32 bits of the sum of all
words from addresses 0 to n-16 inclusive)
n-8 2-word id "ExtnROM0" indicating a valid extension
ROM, ie
n-8 &45 ; "E"
n-7 &78 ; "x"
n-6 &74 ; "t"
n-5 &6E ; "n"
n-4 &52 ; "R"
n-3 &4F ; "O"
n-2 &4D ; "M"
n-1 &30 ; "0"
Note that the ROM header will not necessarily appear in the memory map in
the last 16 bytes if the ROM set is 8 or 16 bits wide. In the 8-bit case,
the header will appear in one of the four byte positions of the last 16
words, and in the 16-bit case, in one of the two half-word positions of the
last 8 words. However, RISC OS copes with this.
Extension ROMs also have a header at the *start* of the ROM set, which is
identical to the format of an expansion card's identity space. This is
because the Podule manager module handles much of the extension ROM
processing.
The format of the header at the start is as follows:-
Byte address Contents Meaning
0 &00 Extended expansion card identity,
not requesting IRQ or FIQ
1 &03 bit 0 set => there is a chunk
directory
bit 1 set => interrupt status
pointers defined (necessary because
bit 0 is set)
bits 2,3 = 0 => 8-bits wide (NB this
should be set to 0 irrespective of
the actual width of the ROM set)
2 &00 Reserved, must be zero
3 &87 Product type (lo-byte)
4 &00 Product type (hi-byte)
See below
5 Manuf(lo) Manufacturer code (lo-byte)
6 Manuf(hi) Manufacturer code (hi-byte)
See below
7 Country Country code - see below
8 to 15 &00 Interrupt status pointers (extension
ROMs do not generate interrupts!)
16 onwards Chunk directory - see below
Product type code: Note that &0087 has been allocated as a product type code
for all extension ROMs.
Manufacturer code: All manufacturers of expansion cards and/or extension
ROMs should have a code for manufacturer. If you have not already been
allocated one, you should consult Acorn.
Country code: Every extension ROM should have a code for the country of
origin. These match those used by the International module, except that the
UK has a country code of 0 for expansion cards and extension ROMs. If you do
not already know the correct country code for your country, you should
consult Acorn.
The chunk directory in an extension ROM is identical to that in an expansion
card - see the chapter "Expansion Cards: Technical Details" in the RISC OS
Programmer's Reference Manual.
Note
====
In extension ROMs which are directly executable (ie which are 32 bits wide),
the word immediately preceding the start of each module must contain (size
of module +4), ie an offset from itself to the first word after the module.
It is recommended that all extension ROMs be created like this, irrespective
of whether they are directly executable.
Additional interfaces to support extension ROMs
===============================================
Changes to Podule manager
=========================
The Podule manager module is responsible for recognising extension ROMs,
although it is the kernel which is responsible for loading modules contained
in them.
The numbering scheme for expansion card slots has been extended to include
extension ROMs. The numbers for extension ROMs are -2, -3, -4... (-1 is
reserved for the main ROM, although the Podule manager itself does not
accept -1 for any of its SWI calls).
All Podule manager SWIs which take an expansion card slot number as a
parameter allow an extension ROM specifier instead.
The SWIs Podule_ReadID, Podule_ReadHeader, Podule_EnumerateChunks,
Podule_ReadChunk operate as one would expect when presented with an
extension ROM specifier.
The SWIs Podule_ReadBytes, Podule_WriteBytes, Podule_CallLoader will
normally fail because extension ROMs have no code space or loader.
SWI Podule_RawRead will read successive bytes out of the extension ROM,
taking the ROM width into account.
SWI Podule_RawWrite must not be used with an extension ROM specifier, as
writing to the ROM area can reprogram the memory and video controllers.
SWI Podule_HardwareAddress returns the base address of the specified
extension ROM, although this is not in general useful as the ROM width can
vary.
New SWIs
--------
SWI Podule_EnumerateChunksWithInfo
in: R0 = chunk number (zero to start)
R3 = expansion card slot number or extension ROM number
out: R0 = next chunk number (zero if final chunk enumerated)
R1 = size (in bytes) if R0<>0 on exit
R2 = operating system identity byte if R0<>0 on exit
R4 = pointer to a copy of the module name if the chunk is a relocatable module, else preserved
R5 = pointer to a copy of the module's help string if the chunk is a relocatable module, else preserved
R6 = address of module if the chunk is a directly executable relocatable module
or 0 if the chunk is a non-directly-executable relocatable module
else preserved
SWI Podule_HardwareAddresses
in: R3 = expansion card slot number or extension ROM number
out: R0 = raw hardware address
R1 = combined hardware address
For an expansion card, the "raw hardware address" is the base address of the
expansion card, and the "combined hardware address" is the raw hardware
address (in bits 12-25) combined with the base address of the expansion
card's private CMOS RAM (in bits 0-11) (as returned by SWI
Podule_HardwareAddress).
For an extension ROM, the two addresses are the same, and are the start
address of the extension ROM (ie the address of the first byte of the ROM).
Star commands
-------------
*Podules now displays the extension ROMs in the system as well as expansion cards.
Changes to kernel
=================
SWI OS_Module
-------------
OS_Module 17 (Add expansion card module) - This call now allows R3 to be
either an expansion card slot number or an extension ROM number.
OS_Module 19 (Enumerate ROM modules) - This call now enumerates
over all ROM sections, ie extension ROM modules as well as main ROM and
expansion card modules. R2 on entry now specifies the ROM section number to
start scanning from, with the order of enumeration as follows:-
-1 (main ROM), 0, 1, 2, 3 (expansion cards), -2, -3, -4,... (extension ROMs)
Edition 1 of the PRM is incorrect when it states that on exit R1 (the
module number to scan from) is incremented and R2 (the expansion card number
to scan from) is preserved.
In fact R1 returns the module number of the found module plus one, where
modules are numbered from zero within each ROM section, and R2 returns the
ROM section number of the found module, which may be in a different ROM
section from the value passed in R2 on entry, if there are insufficient
modules in the specified section.
The values returned in R1 and R2 are therefore set up for the next call to
OS_Module 19.
The call returns the error "No more modules" (error number &107) if there
are no more modules from the point specified in the ordering.
New call
--------
OS_Module 20 (Enumerate ROM modules with version)
This call is identical to OS_Module 19, except that on exit R6 holds a BCD
(binary coded decimal) form of the module's version number, as derived from
the module's help string. The top 16 bits of this value hold the integer
part of the version number, and the bottom 16 bits hold the fractional part,
eg if the version number of the module is "3.14" then the value returned
would be &00031400.
Module initialisation
---------------------
The way in which the kernel initialises modules has been changed. If there
is more than one version of the same module present in the ROM (which
includes all ROM sections) then only the newest version of the module is
initialised, where newest means the version with the highest version number.
(If there are two copies of the same version, then directly executable
versions (ie in main ROM or in a 32-bit wide extension ROM) are considered
"newer". If they are equal in this respect, then the later one in scanning
order is considered to be newer.)
The kernel first scans down the list of modules in the main ROM. For each
module in this list, the kernel initialises the newest version of that
module.
For each module in the main ROM, the newest version of that module
If an extension ROM contains a newer version of a module in the
main ROM, then the newer version will be initialised at the point in the
initialisation sequence where the main ROM version would have been
initialised. This allows main ROM modules to be replaced without the
problems associated with initialisation order.
The kernel then applies the same rule to all of the expansion cards in turn.
In each case the newest version of the module is initialised, but with the
hardware address (in R11) corresponding to that of the expansion card.
The kernel finally initialises any extension ROM modules that are the newest
versions, but which have not already been initialised in lieu of a module in the
main ROM or on an expansion card.
Star commands
-------------
*ROMModules now displays the version number of each module, as well as the
other information. Extension ROM modules are now included in the list. Note
that extension ROMs are numbered 1, 2, 3... in this command - these
correspond to ROM section numbers -2, -3, -4... respectively.
*Unplug can now unplug extension ROM modules, as well as modules in the main
ROM or in expansion cards. The syntax is now
*Unplug [<moduletitle> [<ROM section number>]]
*Unplug with no parameters does the same as it used to, ie display any
unplugged modules.
*Unplug with a module name but no ROM section number specified unplugs all
versions of that module in the system, and kills off any active module of
that name.
If a ROM section number is specified then only versions of that module
in that ROM section are unplugged.
The action of *RMReInit has changed slightly. If the specified module is
active, then the effect is as before, ie the module is killed and then
re-initialised.
If the specified module is not active, but is in the ROM, then the unplug
bit in CMOS RAM is cleared for all versions of the specified module, and
then the newest version of the module is initialised.
New star command
----------------
*RMInsert <moduletitle> [<ROM section number>]
If no ROM section number is specified, then this command clears the unplug
bit for all versions of the specified module, without reinitialising any of
them.
If a ROM section number is specified, then this command clears the unplug
bit for all versions of the specified module present in the given section,
without reinitialising any of them.
Doc/A540Extend deleted 100644 → 0
View file @ 3da129d2
; 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 @ 3da129d2
> 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 @ 3da129d2
; > 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 @ 3da129d2
; 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/MemMaps/130 deleted 100644 → 0
View file @ 3da129d2
000 App space
01C System heap/svc stack
01E Soft CAM copy/und stack
01F Sound/pointer/random
020 RMA
02C L2PT and L1PT
030 I/O
038 ROM
040 Screen
060 Free pool
0E2 Sprites
164 Font cache
1E6 RAM disc
268 Another area 1
2EA Another area 2
36C Another area 3
3EE Another area 4
470 Another area 5
4F2 Another area 6
574 Another area 7
5F6 Another area 8
678 Another area 9
6FA Another area 10
77C Another area 11
7FE Nothing
800 Phys space copy
A00 Another area 12
A82 Another area 13
B04 Another area 14
B86 Another area 15
C08 Another area 16
C8A Another area 17
D0C Another area 18
D8E Another area 19
E10 Another area 20
E92 Another area 21
F14 Another area 22
F96 Nothing
Doc/MemMaps/258 deleted 100644 → 0
View file @ 3da129d2
000 App space
01C System heap/svc stack
01E Soft CAM copy/und stack
01F Sound/pointer/random
020 RMA
02C L2PT and L1PT
030 I/O
038 ROM
040 Screen
060 Free pool
162 Sprites
264 Font cache
366 RAM disc
468 Another area 1
56A Another area 2
66C Another area 3
76E Nothing
800 Phys space copy
A00 Another area 4
B02 Another area 5
C03 Another area 6
D04 Another area 7
E05 Another area 8
F06 Nothing
Doc/Mode22 deleted 100644 → 0
View file @ 3da129d2
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 @ 3da129d2
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 @ 3da129d2
; > 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 @ 3da129d2
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.
Reason codes
============
1 - Read palette
in: R0 = logical colour
R1 = type of colour (16,17,18,24,25)
R4 = 1 (reason code)
out: R2 = 1st flash colour (&BBGGRRSS) - device colour
R3 = 2nd flash colour (&BBGGRRSS) - device colour
R4 = 0 => operation complete
2 - Set palette
in: R0 = logical colour
R1 = type of colour (16,17,18,24,25)
R2 = &BBGGRRSS - device colour
R4 = 2 (reason code)
out: R4 = 0 => operation complete
3 - Set first flash state
in: R4 = 3 (reason code)
out: R4 = 0 => operation complete
4 - Set second flash state
in: R4 = 4 (reason code)
out: R4 = 0 => operation complete
5 - Set default palette
in: R4 = 5 (reason code)
out: R4 = 0 => operation complete
6 - Blank/unblank screen (only available from RISC OS 3.08 onwards)
in: R0 = -1 (read blank state)
or 0 (unblank screen)
or 1 (blank screen)
R4 = 6 (reason code)
out: R0 = old state (0=unblanked, 1=blanked)
R4 = 0 => operation complete
This call blanks or unblanks the screen, independently of the current
palette settings.
In the SS bits mentioned in calls 1 and 2 above, bit 7 is the current
supremacy bit, other bits are reserved.
How old OS calls map onto PaletteV
----------------------------------
Initial suggestions were that VDU 19 and OS_Word(12) should ignore the
bottom 4 bits of RGB values passed to them, and duplicate the top 4 bits in
the bottom 4 bits before calling PaletteV. This was so that old style
programs which set the low nybbles to zero would work correctly on machines
with 8-bit per gun palette hardware.
However, I believe that this damages the usefulness of the above calls
unnecessarily. As long as the default palettes read back true 8-bit values,
and the PaletteUtil module duplicates the nybbles when setting the colours,
it should not be necessary to alter the parameters to VDU 19 and
OS_Word(12).
So the OS will pass the values through to PaletteV, and, assuming there is
no-one else on the vector, will get the values itself. At this point it will
just store the top 4 bits of each value in its soft copy, and in the
hardware if appropriate (when setting the 1st and 2nd flashing colours it
only updates the hardware if that flash state is current).
The calls to read the palette on earlier versions of the OS return a value
which corresponds to how the palette entry was programmed, ie 0..15 if a BBC
style colour was selected, 16 if steady RGB colours were used, 17 or 18 for
flashing colours, 24 for border colours and 25 for pointer colours.
Since PaletteV does not return this information, the OS will try to make up
this information itself. It can easily cope with the 24,25 cases. If the two
colours returned are different, it will substitute 17 or 18 as appropriate,
otherwise it will use 16. It will no longer return values in the range 0 to
15.
Also, when setting the palette, PaletteV does not understand BBC colours
0..15. In order to provide the necessary functionality, the OS calls to set
the palette will trap these values and convert them to type 16 calls (for
0..7) or pairs of type 17 and type 18 calls.
This requires a slight change to the specification of what type 17 and 18
calls do. At the moment, these calls NEVER update the VIDC palette, instead
they only update the relevant soft copy, and when/if the flash state
changes, the colours are updated. But programming a BBC flashing colour
takes effect immediately even if the flash state is 'frozen'.
I therefore propose to make the 17 and 18 calls also update the VIDC palette
if the current state is 1st or 2nd respectively. It's still not quite ideal
because you really want to update both flash colours atomically, in case the
state changed in between the two calls.
Doc/PrivDoc/5thColumn/Concept deleted 100644 → 0
View file @ 3da129d2
; > 5thColumn.Concept
RISC OS Support for extension ROMs
==================================
Author: Tim Dobson
Status: Draft
Issue: 0.02
History:
Date Revision Changes
11-Oct-90 0.00 Started
16-Oct-90 0.01 Completed first draft
04-Feb-91 0.02 Updated to reflect reality
This document describes the purpose of the extension ROM system and
discusses various design issues. For the full technical documentation, refer
to the document "5thColumn.Manual".
The extension ROM system allows the development of hardware platforms fitted
with a normal 32 bit wide RISC OS ROM set plus one or more 8, 16 or 32 bit
ROMs or EPROMs containing software modules which add to or replace modules
in the main ROM set. This allows the same main ROM set to be used in a wider
variety of hardware platforms, removing the extra cost and lead times of
re-romming, and possibly reducing costs by allowing bulk purchase of the
main ROM set.
The extension ROM(s) appear in the memory map in unused parts of the low
(&03400000 to &037FFFFF) or high (&03800000 to &03FFFFFF) ROM areas. A 32
bit wide extension ROM set is directly executable in place, saving on user
RAM. 8 or 16 bit wide sets have to be copied into RAM to execute. By using
the low ROM area (whose access time is programmable independently from the
high area containing the main ROM set) slow EPROMs can be used.
A particularly attractive configuration might be to have 8 ROM sockets on
the board, 4 for the main ROM set, and the other 4 capable of taking either
one 32 bit wide set (eg a large set of applications eg Internet) or up to 4
individual 8 bit wide ROMs containing smaller applications or utilities.
The scheme also allows a machine to have limited protection against
unauthorised access, if the extension ROM contains a module which requires a
password to be entered before continuing.
In order to allow different sizes of EPROMs to be used without having to
have links on the board, the software will look for extension ROMs at higher
addresses first, and work backwards. This means that the high order address
lines (which should be tied to +5v on smaller sizes of EPROM) will be pulled
high initially, although they will be pulled low later on when looking for
further extension ROMs.
The way in which the kernel initialises modules has been changed. If there
is more than one version of the same module present in the ROM (which
includes the main ROM, expansion card ROMs and extension ROMs) then only the
newest version of the module is initialised. If an extension ROM contains a
newer version of a module in the main ROM, then the newer version will be
initialised at the point in the initialisation sequence where the main ROM
version would have been initialised. This allows main ROM modules to be
replaced without the problems associated with initialisation order.
Doc/PrivDoc/MMPM deleted 100644 → 0
View file @ 3da129d2
; > PrivDoc.MMPM
Still to do on memory management, as of 26-May-93:
; Must be TMD
+ Make SoftCAMMap variable size
+ Finish routine to allocate backing L2 for an area
+ Write routine to allocate logical addresses for areas
+ Write routine to check for overlapping areas
+ Complete Create dynamic area routine
(done apart from final OS_ChangeDynamicArea to get required size)
+ Write Remove dynamic area routine
(done apart from initial OS_ChangeDynamicArea to shrink to zero size)
+ Write Return info on dynamic area routine
+ Write Enumerate dynamic areas routine
+ Write Renumber dynamic areas routine
+ Change OS_ReadDynamicArea to use new list
+ Change OS_ValidateAddress to use new list
+ Put in new error messages properly
* If CreateArea fails to grow area to required size, it should kill area and return error
* Change ChangeDynamicArea code to use lists:
+ Check enough is working for Wimp_ClaimFreeMemory to use OS_DynamicArea(create)
* Check PreShrink and PostShrink work completely OK
* Check PreGrow and PostGrow work (apart from passing in page blocks)
* Migrate existing areas to new world:
* Update InitDynamicAreas initially to fake up a node for the RMA, and check it works
* Use DynamicArea_Create to create RMA from scratch (if feasible)
* Update InitDynamicAreas to fake up a node for the system heap + check it (no way of using create routine)
* Change OS_ReadRAMFsLimits to use OS_ReadDynamicArea
* Write RAMFS area handlers
* Create RAMFS dynamic area using DynamicArea_Create, + check it works
* Do similar for font cache, sprite area
* Put in code to split grow block into chunks, and create page blocks (without checking for updates from PreGrow)
* Put in checks for PreGrow requesting particular pages, and call alternative code:
* Do the double shuffle
* Issue Service_PagesUnsafe/Safe
* Stop it getting the static pages (esp. cursor/sound page, L1 and maybe L2)
* Put in extra code to cope with doubly-mapped areas
* Write area handlers for screen, and move it to new world
* Change size of application space to 24M (check all refs to 16M in whole image)
* Put in indirections for hardware vector poking
* Change FPE to use indirections (KWelton)
* Move RMA to &02100000, and change size of app space to 28M
* Conversion to do late aborts
; Could be done by ANOther
* OS_Memory:
a) conversion bits
b) read phys.memory arrangement
c) read amounts of various sorts of memory
d) read controller addresses
\ No newline at end of file
Doc/PrivDoc/ScreenMode deleted 100644 → 0
View file @ 3da129d2
; > PrivDoc.ScreenMode
Still to do on screen mode selection, as of 21-Jul-93:
Key: + Done and tested
- Done but not tested
* Still to do
x Not done for a good reason
+ Make OS_ReadModeVariable work with mode selectors
+ OS_ScreenMode(ReturnMode)
+ OS_ScreenMode(EnumerateModes)
+ Create variable holding video bandwidth
+ Add this reason code to just load up video bandwidth, VideoSize and issue service
+ Service_ModeExtension additions
+ Load up r4 and r5 with video bandwidth, VideoSize respectively
+ Change vdugrafg:SetUpSprModeData:04 to check for mode selector, and goto 10 if so
+ Check other occurrences of BranchIfKnownMode to look for similar bits
+ Put code to handle new sprite mode word into PushModeInfo (any monitor only?)
+ Remove new sprite mode word fudging in vdugrafg:SetupSprModeData and
vdugrafl:SwitchOutputToSprite
+ Make SwitchOutputToSprite(new format) set up ECFIndex (it doesn't at the moment!)
+ Make sure tests for equal mode numbers don't assume equal ptrs to mode selectors are equivalent
+ Modify NewModes module to respond to Service_EnumerateScreenModes, to test enumeration.
+ OS_ScreenMode(SetMonitorType)
+ Allocate soft copy for monitortype
+ Write routine to update soft copy from CMOS
+ Call this routine in initialisation
+ Make *Configure MonitorType update soft copy
+ Change ReadMonitorType to read from soft copy
+ Add this reason code to either store given value or update from CMOS
+ Make sprites which have mode selectors as their mode word illegal
+ Move conversion of mode selectors to new format sprite mode words
into PreCreateHeader, rather than PostCreateHeader, so that it
doesn't call SetupSprModeData with a (now illegal) mode selector
-> MT ScreenModes module
-> AG Make switch output to sprite for a new format sprite make mode selector for current mode?
-> AG *ScreenSave in mode 50 seems to produce a sprite with a palette.
-> NK Trying to set a WimpMode with XEigFactor=27 caused data abort.
Investigate and/or range-limit values.
-> AG Put in support for returning errors from PushModeInfo (for bad mode
selectors and new format sprite mode words):
+ Make mode change routine check for error from PushModeInfo and FindOKMode
+ Make FindSubstitute check errors from PushModeInfo
+ Make FindOKMode check errors from FindSubstitute
+ Make CheckModeValid check errors from FindOKMode
+ Make SetupSprModeData capable of returning errors:
+ Ditto SpriteV handler (already OK)
+ Ditto PreCreateHeader
+ Ditto CreateHeader
+ Ditto GetSprite
-> AG Make SwitchOutputToSprite/Mask check errors from PushModeInfo
- Design and code algorithm for working out FIFO reload position for VIDC20
(Still need explanation from ARM of why 7 quad-words doesn't always work)
* OS_ScreenMode(SelectMode)
+ Make normal mode selection routine into a subroutine
+ Write veneers to put round call to this in OS_ScreenMode(SelectMode)
* Change actual mode change code to cope with mode selectors
+ Prevent main routine looking at shadow bit in mode selector
+ Modify FindOKMode to cope with mode selector
+ Modify OS_CheckModeValid to cope with mode selector
+ Make all pushed mode variables into words (not bytes)
+ Modify PushModeInfo to cope with mode selector
+ Make YEigFactor default to 2 if yres < xres/2 (and change spec. to reflect that)
+ Make numbered modes work after loading mode file
+ Allocate space for OS copy of mode selector
x Make OS mode selector part of saved VDU context
(not needed since sprites can't have mode selectors as their mode)
x Sort out internal mode variables PalIndex, ECFIndex wrt
converting existing mode numbers into mode selectors (no need, still use old workspace-getting code)
x Make mode selector blocks for all existing numbered modes
(no need, constructed on fly since only needed during svc call)
* Check that copying mode selector has no adverse effects
* Sort out why issuing a mode change with invalid mode selector doesn't give error
* Modify FindOKMode to cope with 16 and 32 bpp modes somehow
* Prevent pointer position from going into the sync pulse (causes screen picture disruption)
* Adjust borders on all modes, to cope with VIDC20 problem
(Needs algorithm from ARM that works!)
* Mode change happily passes round any old rubbish to Service_ModeExtension - it should:-
* First check that value is word-aligned - if not it may be a new sprite mode word
* Do a Validate_Address on fixed bit of block?
* What should *ScreenLoad do with a new format sprite?
Doc/ReadSysInf deleted 100644 → 0
View file @ 3da129d2
; > Doc.ReadSysInf
Title: ReadSysInf
Author: Tim Dobson
Version: 0.03
Started: 19-Mar-91
Last updated: 21-Oct-91
Status: Preliminary
History:
19-Mar-91 TMD Created
04-Apr-91 TMD Updated OS_ReadSysInfo(2)
Extensions to SWI OS_ReadSysInfo in RISC OS 2.11 and later versions
===================================================================
SWI OS_ReadSysInfo has been extended since RISC OS 2.00 - the full
specification is as follows:-
*****************************************************************************
SWI OS_ReadSysInfo - Read various system information
in: R0 = reason code
out: Depends on reason code
Reason codes:-
-------------------------------------------------------------------------
in: R0 = 0
out: R0 = amount of configured screen memory, in bytes
This sub-call is the same as on RISC OS 2.00, with the exception that two
bugs in the call have been fixed:-
a) It no longer goes wrong if less than 20K configured on 8K or 16K page
size machine;
b) It now properly ignores the top bit of the CMOS location holding the
configured value.
-------------------------------------------------------------------------
in: R0 = 1
out: R0 = Configured Mode/WimpMode
R1 = Configured MonitorType
R2 = Configured Sync
Note that from RISC OS 2.09 onwards, the configured Mode and WimpMode have
been merged. Both *Configure Mode and *Configure WimpMode control the same
CMOS RAM location.
Note also that if any of Mode/WimpMode, MonitorType or Sync have been
configured to Auto (see "Doc.MonLead"), then the appropriate value for the
attached monitor will be returned.
-------------------------------------------------------------------------
in: R0 = 2
out: R0 = IOEB ASIC presence flag
0 => absent
1 => present (type 1)
Other values are reserved for future versions of IOEB which are
not backwards compatible.
R1 = 82C710 (or similar) presence flag
0 => absent
1 => present
R2 = LCD ASIC presence flag
0 => absent
1 => present (type 1)
Other values are reserved for future versions of LCD ASIC which
are not backwards compatible.
R3 = word 0 of unique machine ID
R4 = word 1 of unique machine ID
Some RISC OS computers are fitted with a chip providing a machine ID number
which is unique to each computer. Machines not fitted with an ID will return
zero in both R3 and R4.
-------------------------------------------------------------------------
in: R0 = 3 (*** Only available from RISC OS 3.01 onwards ***)
out: R0 = 82C710/82C711 basic features mask 82C710 82C711
Bits 0..3 Basic IDE type 1 1
Bits 4..7 Basic FDC type 1 1
Bits 8..11 Basic parallel port type 1 1
Bits 12..15 Basic 1st serial port type 1 1
Bits 16..19 Basic 2nd serial port type 0 1
Bits 20..23 Basic Configuration type 1 2
Bits 24..31 Reserved
R1 = 82C710/82C711 extra features mask
Reserved for upwards compatible additional functionality
R2-R4 Undefined (reserved for future expansion)
The 82C710 family of chips are composed of several sub-units, each of which
might change under future revisions of the chip. Current sub-units are as
follows:
IDE hard disc interface
Floppy disc interface
Parallel port
Serial port 1
Serial port 2 (only present in 82C711)
Chip configuration (different on 82C710 and 82C711)
New versions of the chip may have some sub-units which are incompatible with
earlier versions, while leaving the functionality of other sub-units
unchanged.
This call allows drivers which are only interested in particular sub-units
to tell whether they can work on the particular hardware running in the
machine.
Different values of each sub-field correspond to incompatible versions of
the corresponding sub-unit. A sub-field of zero indicates that the sub-unit
is not present.
If a sub-unit gains additional backwards-compatible functionality in future
versions of the chip, this will be indicated by having bits set in the value
returned in R1.
Information on extra sub-units will be accomodated in the remaining bits of
R0, or in R2-R4.
Doc/TVmodesMed,dde deleted 100644 → 0
View file @ 3da129d2
%OP%VS4.13 (28-Apr-92), Tim Dobson, R4001 0202 1006 4799
%OP%FGTrinity.Medium
%OP%FS12000
%OP%WC162,1898,210,1494,1,22,0,0
%CO:A,2,0%%CO:B,17,72%Medusa screen modes
This spreadsheet gives the horizontal and vertical timings for the Medusa screen modes.
For the numbered screen modes, these timings are almost identical to the RISC OS 3 timings.
However, on VIDC1 the horizontal front and back porch timings are forced to be an odd
number of pixel times, whereas on VIDC20 they have to be even, therefore all horizontal back
porch timings have been reduced by one pixel, and front porch timings increased by one pixel.
The figures below show that our timings for the 800 x 600 modes differ from the VESA
manufacturing guidelines in that we have hsync=100, hbpch=100, whereas they have
hsync=72, hbpch=128; ie the total times are the same, and the time from the start of the hsync
pulse to the start of the display area is the same, but our sync is wider. It is likely that I will
change RISC OS to match the VESA standard - I don't believe this will have an effect on the
horizontal position of the display (this is something I will have to check out).
It is likely that as well as adding the VESA modes described below, RISC OS will also
provide several modes obtained by doubling the dot frequency of standard modes, eg 1280 x
480, 1600 x 600, 2048 x 768.
It may also be possible to provide 1280 x 1024 at some pixel depths, although this may
involve running VIDC20 and/or the VCO out of specification. I don't have any timing
diagrams for 1280 x 1024; if you can get hold of these (is there a VESA standard for this?) it
would help establish the feasibility of this (the Taxan 875 Plus LR monitor spec. gives the line
frequency for this at 60 and 70Hz frame rates, but not the detailed timings (eg the dot
frequency)).
Tim (22-Mar-93).
Horizontal parameters for Monitortype 1 modes
0,3,4,8,11,12,14,15
1,2,5,6,7,9,10,13
16,17,24
33,34,35,36
(overscan)
18,19,20,21
25,26,27,28
(VGA)
29,30,31
(SVGA)
37,38,39,40
(DTP - ega)
41,42,43
(EGA - pcemu)
44,45,46
(CGA - pcemu)
800 x 600 (56 Hz)
VESA guideline
800 x 600 (60 Hz)
VESA guideline
800 x 600 (72 Hz)
VESA standard
1024 x 768 (60 Hz)
VESA guideline
1024 x 768 (70 Hz)
VESA standard
Vertical parameters
0,1,2,4,5,8,9,10
12,13,15,16,24
3,6,7,11,14,17
33,34,35,36
18,19,20,21
25,26,27,28
29,30,31
37,38,39,40
41,42,43
44,45,46
800 x 600 (56 Hz)
VESA guideline
800 x 600 (60 Hz)
VESA guideline
800 x 600 (72 Hz)
VESA standard
1024 x 768 (60 Hz)
VESA guideline
1024 x 768 (70 Hz)
VESA standard
%CO:C,6,60%
sync
%V%%R%%D0%72
%V%%R%C34/M34*1000
%V%%R%%D0%36
%V%%R%C37/M37*1000
%V%%R%%D0%108
%V%%R%C40/M40*1000
%V%%R%%D0%76
%V%%R%C43/M43*1000
%V%%R%%D0%56
%V%%R%C46/M46*1000
%V%%R%%D0%96
%V%%R%C49/M49*1000
%V%%R%%D0%100
%V%%R%C52/M52*1000
%V%%R%%D0%118
%V%%R%C55/M55*1000
%V%%R%%D0%76
%V%%R%C58/M58*1000
%V%%R%%D0%72
%V%%R%C61/M61*1000
%V%%R%%D0%72
%V%%R%C64/M64*1000
%V%%R%%D0%128
%V%%R%C67/M67*1000
%V%%R%%D0%120
%V%%R%C70/M70*1000
%V%%R%%D0%136
%V%%R%C73/M73*1000
%V%%R%%D0%136
%V%%R%C76/M76*1000
(rasters)
%V%%R%%D0%3
%V%%R%%D0%3
%V%%R%%D0%3
%V%%R%%D0%3
%V%%R%%D0%2
%V%%R%%D0%2
%V%%R%%D0%3
%V%%R%%D0%3
%V%%R%%D0%3
%V%%R%%D0%2
%V%%R%%D0%4
%V%%R%%D0%6
%V%%R%%D0%6
%V%%R%%D0%6
%CO:D,6,48%
porch
%V%%R%%D0%62
%V%%R%D34/M34*1000
%V%%R%%D0%30
%V%%R%D37/M37*1000
%V%%R%%D0%72
%V%%R%D40/M40*1000
%V%%R%%D0%82
%V%%R%D43/M43*1000
%V%%R%%D0%112
%V%%R%D46/M46*1000
%V%%R%%D0%46
%V%%R%D49/M49*1000
%V%%R%%D0%100
%V%%R%D52/M52*1000
%V%%R%%D0%58
%V%%R%D55/M55*1000
%V%%R%%D0%36
%V%%R%D58/M58*1000
%V%%R%%D0%162
%V%%R%D61/M61*1000
%V%%R%%D0%128
%V%%R%D64/M64*1000
%V%%R%%D0%88
%V%%R%D67/M67*1000
%V%%R%%D0%64
%V%%R%D70/M70*1000
%V%%R%%D0%160
%V%%R%D73/M73*1000
%V%%R%%D0%144
%V%%R%D76/M76*1000
%V%%R%%D0%16
%V%%R%%D0%16
%V%%R%%D0%19
%V%%R%%D0%18
%V%%R%%D0%32
%V%%R%%D0%22
%V%%R%%D0%9
%V%%R%%D0%9
%V%%R%%D0%34
%V%%R%%D0%22
%V%%R%%D0%23
%V%%R%%D0%23
%V%%R%%D0%29
%V%%R%%D0%29
%CO:E,6,36%
border
%V%%R%%D0%88
%V%%R%E34/M34*1000
%V%%R%%D0%44
%V%%R%E37/M37*1000
%V%%R%%D0%106
%V%%R%E40/M40*1000
%V%%R%%D0%0
%V%%R%E43/M43*1000
%V%%R%%D0%0
%V%%R%E46/M46*1000
%V%%R%%D0%0
%V%%R%E49/M49*1000
%V%%R%%D0%0
%V%%R%E52/M52*1000
%V%%R%%D0%0
%V%%R%E55/M55*1000
%V%%R%%D0%0
%V%%R%E58/M58*1000
%V%%R%%D0%0
%V%%R%E61/M61*1000
%V%%R%%D0%0
%V%%R%E64/M64*1000
%V%%R%%D0%0
%V%%R%E67/M67*1000
%V%%R%%D0%0
%V%%R%E70/M70*1000
%V%%R%%D0%0
%V%%R%E73/M73*1000
%V%%R%%D0%0
%V%%R%E76/M76*1000
%V%%R%%D0%17
%V%%R%%D0%20
%V%%R%%D0%0
%V%%R%%D0%0
%V%%R%%D0%0
%V%%R%%D0%0
%V%%R%%D0%0
%V%%R%%D0%0
%V%%R%%D0%0
%V%%R%%D0%0
%V%%R%%D0%0
%V%%R%%D0%0
%V%%R%%D0%0
%V%%R%%D0%0
%CO:F,6,24%
display
%V%%R%%D0%640
%V%%R%F34/M34*1000
%V%%R%%D0%320
%V%%R%F37/M37*1000
%V%%R%%D0%1056
%V%%R%F40/M40*1000
%V%%R%%D0%768
%V%%R%F43/M43*1000
%V%%R%%D0%640
%V%%R%F46/M46*1000
%V%%R%%D0%640
%V%%R%F49/M49*1000
%V%%R%%D0%800
%V%%R%F52/M52*1000
%V%%R%%D0%896
%V%%R%F55/M55*1000
%V%%R%%D0%640
%V%%R%F58/M58*1000
%V%%R%%D0%640
%V%%R%F61/M61*1000
%V%%R%%D0%800
%V%%R%F64/M64*1000
%V%%R%%D0%800
%V%%R%F67/M67*1000
%V%%R%%D0%800
%V%%R%F70/M70*1000
%V%%R%%D0%1024
%V%%R%F73/M73*1000
%V%%R%%D0%1024
%V%%R%F76/M76*1000
%V%%R%%D0%256
%V%%R%%D0%250
%V%%R%%D0%288
%V%%R%%D0%512
%V%%R%%D0%480
%V%%R%%D0%600
%V%%R%%D0%352
%V%%R%%D0%352
%V%%R%%D0%200
%V%%R%%D0%600
%V%%R%%D0%600
%V%%R%%D0%600
%V%%R%%D0%768
%V%%R%%D0%768
%CO:G,6,30%
border
%V%%R%%D0%88
%V%%R%G34/M34*1000
%V%%R%%D0%44
%V%%R%G37/M37*1000
%V%%R%%D0%106
%V%%R%G40/M40*1000
%V%%R%%D0%0
%V%%R%G43/M43*1000
%V%%R%%D0%0
%V%%R%G46/M46*1000
%V%%R%%D0%0
%V%%R%G49/M49*1000
%V%%R%%D0%0
%V%%R%G52/M52*1000
%V%%R%%D0%0
%V%%R%G55/M55*1000
%V%%R%%D0%0
%V%%R%G58/M58*1000
%V%%R%%D0%0
%V%%R%G61/M61*1000
%V%%R%%D0%0
%V%%R%G64/M64*1000
%V%%R%%D0%0
%V%%R%G67/M67*1000
%V%%R%%D0%0
%V%%R%G70/M70*1000
%V%%R%%D0%0
%V%%R%G73/M73*1000
%V%%R%%D0%0
%V%%R%G76/M76*1000
%V%%R%%D0%17
%V%%R%%D0%20
%V%%R%%D0%0
%V%%R%%D0%0
%V%%R%%D0%0
%V%%R%%D0%0
%V%%R%%D0%0
%V%%R%%D0%0
%V%%R%%D0%0
%V%%R%%D0%0
%V%%R%%D0%0
%V%%R%%D0%0
%V%%R%%D0%0
%V%%R%%D0%0
%CO:H,6,20%
porch
%V%%R%%D0%74
%V%%R%H34/M34*1000
%V%%R%%D0%38
%V%%R%H37/M37*1000
%V%%R%%D0%88
%V%%R%H40/M40*1000
%V%%R%%D0%98
%V%%R%H43/M43*1000
%V%%R%%D0%88
%V%%R%H46/M46*1000
%V%%R%%D0%18
%V%%R%H49/M49*1000
%V%%R%%D0%24
%V%%R%H52/M52*1000
%V%%R%%D0%28
%V%%R%H55/M55*1000
%V%%R%%D0%16
%V%%R%H58/M58*1000
%V%%R%%D0%146
%V%%R%H61/M61*1000
%V%%R%%D0%24
%V%%R%H64/M64*1000
%V%%R%%D0%40
%V%%R%H67/M67*1000
%V%%R%%D0%56
%V%%R%H70/M70*1000
%V%%R%%D0%24
%V%%R%H73/M73*1000
%V%%R%%D0%24
%V%%R%H76/M76*1000
%V%%R%%D0%3
%V%%R%%D0%3
%V%%R%%D0%2
%V%%R%%D0%1
%V%%R%%D0%11
%V%%R%%D0%1
%V%%R%%D0%0
%V%%R%%D0%0
%V%%R%%D0%25
%V%%R%%D0%1
%V%%R%%D0%1
%V%%R%%D0%37
%V%%R%%D0%3
%V%%R%%D0%3
%CO:I,6,10%
Total
%V%%R%%D0%sum(C34H34)
%V%%R%I34/M34*1000
%V%%R%%D0%sum(C37H37)
%V%%R%I37/M37*1000
%V%%R%%D0%sum(C40H40)
%V%%R%I40/M40*1000
%V%%R%%D0%sum(C43H43)
%V%%R%I43/M43*1000
%V%%R%%D0%sum(C46H46)
%V%%R%I46/M46*1000
%V%%R%%D0%sum(C49H49)
%V%%R%I49/M49*1000
%V%%R%%D0%sum(C52H52)
%V%%R%I52/M52*1000
%V%%R%%D0%sum(C55H55)
%V%%R%I55/M55*1000
%V%%R%%D0%sum(C58H58)
%V%%R%I58/M58*1000
%V%%R%%D0%sum(C61H61)
%V%%R%I61/M61*1000
%V%%R%%D0%sum(C64H64)
%V%%R%I64/M64*1000
%V%%R%%D0%sum(C67H67)
%V%%R%I67/M67*1000
%V%%R%%D0%sum(C70H70)
%V%%R%I70/M70*1000
%V%%R%%D0%sum(C73H73)
%V%%R%I73/M73*1000
%V%%R%%D0%sum(C76H76)
%V%%R%I76/M76*1000
%V%%R%%D0%sum(C83H83)
%V%%R%%D0%sum(C86H86)
%V%%R%%D0%sum(C88H88)
%V%%R%%D0%sum(C90H90)
%V%%R%%D0%sum(C92H92)
%V%%R%%D0%sum(C94H94)
%V%%R%%D0%sum(C96H96)
%V%%R%%D0%sum(C98H98)
%V%%R%%D0%sum(C100H100)
%V%%R%%D0%sum(C102H102)
%V%%R%%D0%sum(C105H105)
%V%%R%%D0%sum(C108H108)
%V%%R%%D0%sum(C111H111)
%V%%R%%D0%sum(C114H114)
%CO:J,4,0%
pix
usec
pix
usec
pix
usec
pix
usec
pix
usec
pix
usec
pix
usec
pix
usec
pix
usec
pix
usec
pix
usec
pix
usec
pix
usec
pix
usec
pix
usec
%CO:K,6,42%
H Freq
KHz
%V%%R%%D3%1000/I35
%V%%R%%D3%1000/I38
%V%%R%%D3%1000/I41
%V%%R%%D3%1000/I44
%V%%R%%D3%1000/I47
%V%%R%%D3%1000/I50
%V%%R%%D3%1000/I53
%V%%R%%D3%1000/I56
%V%%R%%D3%1000/I59
%V%%R%%D3%1000/I62
%V%%R%%D3%1000/I65
%V%%R%%D3%1000/I68
%V%%R%%D3%1000/I71
%V%%R%%D3%1000/I74
%V%%R%%D3%1000/I77
%V%%R%1000000/I35/I83
%V%%R%1000000/I38/I86
%V%%R%1000000/I44/I88
%V%%R%1000000/I47/I90
%V%%R%1000000/I50/I92
%V%%R%1000000/I53/I94
%V%%R%1000000/I56/I96
%V%%R%1000000/I59/I98
%V%%R%1000000/I62/I100
%V%%R%1000000/I65/I102
%V%%R%1000000/I68/I105
%V%%R%1000000/I71/I108
%V%%R%1000000/I74/I111
%V%%R%1000000/I77/I114
%CO:L,6,32%
disp
cntr
usec
%V%%R%(C34+D34+E34+F34/2)/M34*1000
%V%%R%(C37+D37+E37+F37/2)/M37*1000
%V%%R%(C40+D40+E40+F40/2)/M40*1000
%V%%R%(C43+D43+E43+F43/2)/M43*1000
%V%%R%(C46+D46+E46+F46/2)/M46*1000
%V%%R%(C49+D49+E49+F49/2)/M49*1000
%V%%R%(C52+D52+E52+F52/2)/M52*1000
%V%%R%(C55+D55+E55+F55/2)/M55*1000
%V%%R%(C58+D58+E58+F58/2)/M58*1000
%V%%R%(C61+D61+E61+F61/2)/M61*1000
%V%%R%(C64+D64+E64+F64/2)/M64*1000
%V%%R%(C67+D67+E67+F67/2)/M67*1000
%V%%R%(C70+D70+E70+F70/2)/M70*1000
%V%%R%(C73+D73+E73+F73/2)/M73*1000
%V%%R%(C76+D76+E76+F76/2)/M76*1000
Hz
Hz
Hz
Hz
Hz
Hz
Hz
Hz
Hz
Hz
Hz
Hz
Hz
Hz
%CO:M,6,22%
pix
clock
KHz
%V%%R%%D0%16000
%V%%R%%D0%8000
%V%%R%%D0%24000
%V%%R%%D0%16000
%V%%R%%D0%24000
%V%%R%%D0%25175
%V%%R%%D0%36000
%V%%R%%D0%24000
%V%%R%%D0%2*25175/3
%V%%R%%D0%16000
%V%%R%%D0%36000
%V%%R%%D0%40000
%V%%R%%D0%50000
%V%%R%%D0%65000
%V%%R%%D0%75000
vert
center
%V%%R%%D0%(C83+D83+E83+F83/2)
%V%%R%%D0%(C86+D86+E86+F86/2)
%V%%R%%D0%(C88+D88+E88+F88/2)
%V%%R%%D0%(C90+D90+E90+F90/2)
%V%%R%%D0%(C92+D92+E92+F92/2)
%V%%R%%D0%(C94+D94+E94+F94/2)
%V%%R%%D0%(C96+D96+E96+F96/2)
%V%%R%%D0%(C98+D98+E98+F98/2)
%V%%R%%D0%(C100+D100+E100+F100/2)
%V%%R%%D0%(C102+D102+E102+F102/2)
%V%%R%%D0%(C105+D105+E105+F105/2)
%V%%R%%D0%(C108+D108+E108+F108/2)
%V%%R%%D0%(C111+D111+E111+F111/2)
%V%%R%%D0%(C114+D114+E114+F114/2)
%CO:N,8,0%
\ No newline at end of file
OldTestSrc/A600tlb deleted 100644 → 0
View file @ 3da129d2
;
; A600tlb
;
; POST procedure for checking the TLB in A600 MMU.
;
; for each of level 1, level 2 small-page, level 2 large-page
; construct page table
; flush cache
; start timer
; for 32 addresses (with different mappings)
; check address mapping
; save timer
; for same 32 addresses
; check address mapping
; compare test times (did 2nd test require table walk ?)
Use a list of addresses that cover a good mixture of virtual addresses
Build a page table that maps these to physical RAM addresses in various ways
Access the addresses in such an order that the cache rotates, scrapping
one entry each time through the list, and loading another. So each cache
entry gets used 31 times, then is lost.
Choice of physical mapping should ensure that the cache entries contain
lots of different values of page and section base addresses.
Choice of virtual test address should ensure that cache tag varies as
widely as posible, too. PRBS ?
Very widely varying values of cache tag require that a large number
of mappings exist .. if these are 2-level mappings, that requires
a lot of RAM. Page tables should be multiply-mapped.
RISC OS puts lots of stuff below the 4M mark. Limits App space to 16M
for backwards compatibility. Probably worth testing outside these
limits to ensure Gold doesn't fall over, but failure rates would be
very low.
;
; POST procedure for checking access faults (was PPL test)
;
; for each of level 1, level 2 small-page, level 2 large-page
; construct page table
; for user, supervisor mode
; check address alignment fault
; check section translation fault
; check
; check page translation fault
; for 3 domain types
; for 16 domains
; check access permissions
;
;
; POST procedure for checking IDC
;
;
OldTestSrc/Arm3 deleted 100644 → 0
View file @ 3da129d2
; > TestSrc.ARM3
TTL RISC OS 2+ POST ARM version determination
;
; Reads ARM3 version register, returns 0 if ARM 2 fitted.
;
;------------------------------------------------------------------------
; History
;
; Date Name Comment
; ---- ---- -------
; 20-Apr-89 ArtG Initial version
;
;
;------------------------------------------------------------------------
A3Cid CN 0
A3Cfls CN 1
A3Cmod CN 2
A3Ccac CN 3
A3Cupd CN 4
A3Cdis CN 5
A3CON CP 15
ts_ARM_type
MOV r13,lr
;
; First, set up an undefined instruction vector to catch an ARM 2
; (or a faulty ARM 3 ??) when the copro instruction is run.
; Only applies on systems where ROM isn't mapped at zero.
[ CPU_Type = "ARM2" :LOR: CPU_Type = "ARM3"
MOV r0,#0 ; set a page at logical 0
MOV r1,r0
BL ts_set_cam
ADR r0,ts_ARM_undefined
LDMIA r0,{r2,r3}
MOV r1,#4
STMIA r1,{r2,r3} ; set the undefined instruction trap
]
;
; Read ARM3C0 version I.D.
;
MOV r0, #(-1) ; should always be altered
MRC A3CON,0,r0,A3Cid,A3Cid ; Read control register 0
MOV r12, r0
[ CPU_Type = "ARM2" :LOR: CPU_Type = "ARM3"
MOV r1,#0
BL ts_set_cam_idle ; remove the vector page again
]
MOVS r0, r12 ; return the ID (0 for ARM 2)
MOV pc,r13
;
; Trap to be taken when ARM 2 is fitted
;
ts_ARM_undefined
MOV r0,#0
MOVS pc,r14_svc
10
ASSERT ((%10 - ts_ARM_undefined) / 4 = 2)
END
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment