Commit 8c1ef639 authored by ROOL's avatar ROOL 🤖
Browse files

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

Sprout from HAL 2001-03-29 14:45:57 UTC Dan Ellis <dellis@gitlab.riscosopen.org> '  Baud rate return is more correct.'
Delete:
    BlackLog
    Changes
    Dev/IICTest/Makefile
    Dev/IICTest/MkClean,fd7
    Dev/IICTest/MkRom,fd7
    Dev/IICTest/s/IICTest
    Doc/5thColumn/Manual
    Doc/MemMaps/130
    Doc/MemMaps/258
    Doc/PrivDoc/5thColumn/Concept
    Doc/PrivDoc/MMPM
    Doc/PrivDoc/ScreenMode
    Docs/!ReadMe
    Docs/0197276.02
    Docs/32bit
    Docs/5thColumn/+Access,ffd
    Docs/5thColumn/+SrcIndex
    Docs/5thColumn/+SrcIndexO
    Docs/5thColumn/Manual
    Docs/A540Extend
    Docs/AMBControl
    Docs/HAL/ADisNote
    Docs/HAL/ARMop_API
    Docs/HAL/Entries
    Docs/HAL/HAL_API
    Docs/HAL/Init
    Docs/HAL/MoreEnts
    Docs/HAL/NewAPI
    Docs/HAL/Notes
    Docs/HAL/OS_Hardware
    Docs/HAL/OpenBusAdapter
    Docs/HAL/Serial
    Docs/HiResTTX
    Docs/Kernel
    Docs/KernlSplit
    Docs/MMUControl
    Docs/MemMaps/+Access,ffd
    Docs/MemMaps/+SrcIndex
    Docs/MemMaps/+SrcIndexO
    Docs/MemMaps/130
    Docs/MemMaps/258
    Docs/Mode22
    Docs/Modes
    Docs/MonLead
    Docs/PaletteV
    Docs/PrivDoc/+Access,ffd
    Docs/PrivDoc/+SrcIndex
    Docs/PrivDoc/+SrcIndexO
    Docs/PrivDoc/5thColumn/+Access,ffd
    Docs/PrivDoc/5thColumn/+SrcIndex
    Docs/PrivDoc/5thColumn/+SrcIndexO
    Docs/PrivDoc/5thColumn/Concept
    Docs/PrivDoc/MMPM
    Docs/PrivDoc/ScreenMode
    Docs/ReadSysInf
    Docs/TVmodesMed,dde
    HelpStrs
    Makefile
    MkClean,fd7
    MkExport,fd7
    MkRom,fd7
    MkRomInst,fd7
    NewModes/Make,feb
    NewModes/NEWF2
    NewModes/NEWFORMAT
    NewModes/OldFormat
    NewModes/OldPSSrc
    NewModes/OldToNew,ffb
    NewModes/PSSrc
    Resources/UK/CmdHelp
    Resources/UK/Messages
    Resources/UK/Morris4/Messages
    Resources/UK/Omega/Messages
    Resources/UK/Ursula/Messages
    TestSrc/A600tlb
    TestSrc/Arm3
    TestSrc/Begin
    TestSrc/Cmos
    TestSrc/ErrorCount,ffb
    TestSrc/ExtCmd
    TestSrc/ExtIO
    TestSrc/InitModule
    TestSrc/Ioc
    TestSrc/LEDDelay
    TestSrc/MEMC1
    TestSrc/Mem1IOMD
    TestSrc/Mem1MEMC1
    TestSrc/Mem2
    TestSrc/Mem3
    TestSrc/Mem4
    TestSrc/Mem5
    TestSrc/ROMCard
    TestSrc/ShowIOMDRs
    TestSrc/TestMain
    TestSrc/ToggleLED
    TestSrc/Vidc
    Version
    hdr/ARMops
    hdr/Copro15ops
    hdr/EnvNumbers
    hdr/ExportVals/!HowTo
    hdr/ExportVals/Makefile
    hdr/ExportVals/Mk,fd7
    hdr/ExportVals/s/GetVals
    hdr/ExportVals/values
    hdr/HALEntries
    hdr/KernelWS
    hdr/KeyWS
    hdr/ModHand
    hdr/OSEntries
    hdr/Old/Arthur/PublicWS
    hdr/Old/Arthur/Space200
    hdr/Old/NewSpace
    hdr/Old/VickySpace
    hdr/Options
    hdr/PublicWS
    hdr/RISCOS
    hdr/Variables
    hdr/VduExt
    s/AMBControl/AMB
    s/AMBControl/Memory
    s/AMBControl/Options
    s/AMBControl/Workspace
    s/AMBControl/allocate
    s/AMBControl/deallocate
    s/AMBControl/growp
    s/AMBControl/growshrink
    s/AMBControl/main
    s/AMBControl/mapslot
    s/AMBControl/mapsome
    s/AMBControl/memmap
    s/AMBControl/readinfo
    s/AMBControl/service
    s/AMBControl/shrinkp
    s/ARM600
    s/ARMops
    s/Arthur2
    s/Arthur3
    s/ArthurSWIs
    s/ChangeDyn
    s/Convrsions
    s/ExtraSWIs
    s/FlashROM
    s/GetAll
    s/HAL
    s/HeapMan
    s/HeapSort
    s/KbdResA1
    s/KbdResPC
    s/KbdResRCMM
    s/Kernel
    s/LibKern
    s/MEMC1
    s/MEMC2
    s/MOSDict
    s/MemInfo
    s/Middle
    s/ModHand
    s/MoreComms
    s/MoreSWIs
    s/Morris
    s/MsgCode
    s/NewIRQs
    s/NewReset
    s/Oscli
    s/PMF/Buffer
    s/PMF/Def
    s/PMF/IIC
    s/PMF/Internat
    s/PMF/KbdDrA1
    s/PMF/convdate
    s/PMF/i2cutils
    s/PMF/key
    s/PMF/mouse
    s/PMF/osbyte
    s/PMF/oseven
    s/PMF/osinit
    s/PMF/osword
    s/PMF/oswrch
    s/PMF/realtime
    s/SWINaming
    s/Super1
    s/SysComms
    s/TickEvents
    s/UnSqueeze
    s/Utility
    s/vdu/vdu23
    s/vdu/vdu5
    s/vdu/vducursoft
    s/vdu/vdudecl
    s/vdu/vdudriver
    s/vdu/vdufont
    s/vdu/vdufontl1
    s/vdu/vdugrafa
    s/vdu/vdugrafb
    s/vdu/vdugrafc
    s/vdu/vdugrafd
    s/vdu/vdugrafdec
    s/vdu/vdugrafe
    s/vdu/vdugraff
    s/vdu/vdugrafg
    s/vdu/vdugrafh
    s/vdu/vdugrafi
    s/vdu/vdugrafj
    s/vdu/vdugrafk
    s/vdu/vdugrafl
    s/vdu/vduhint
    s/vdu/vdumodes
    s/vdu/vdupal10
    s/vdu/vdupal20
    s/vdu/vdupalette
    s/vdu/vdupalxx
    s/vdu/vduplot
    s/vdu/vdupointer
    s/vdu/vduswis
    s/vdu/vduttx
    s/vdu/vduwrch
parent d068e40f
hdr/** gitlab-language=armasm linguist-language=armasm linguist-detectable=true
s/** gitlab-language=armasm linguist-language=armasm linguist-detectable=true
**/s/** gitlab-language=armasm linguist-language=armasm linguist-detectable=true
*,ffb gitlab-language=bbcbasic linguist-language=bbcbasic linguist-detectable=true
This diff is collapsed.
This diff is collapsed.
# Copyright 1997 Acorn Computers Ltd
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
# Makefile for IICTest
#
#
# Paths
#
EXP_HDR = <export$dir>
#
# Generic options:
#
MKDIR = cdir
AS = aasm
CP = copy
RM = remove
CCFLAGS = -c -depend !Depend -IC:
ASFLAGS = -depend !Depend -Stamp -quit -module -To $@ -From
CPFLAGS = ~cfr~v
#
# Program specific options:
#
COMPONENT = IICTest
SOURCE = s.IICTest
TARGET = rm.IICTest
EXPORTS = ${EXP_HDR}.${COMPONENT}
#
# Generic rules:
#
rom: ${TARGET}
@echo ${COMPONENT}: rom module built
export: ${EXPORTS}
@echo ${COMPONENT}: export complete
install_rom: ${TARGET}
${CP} ${TARGET} ${INSTDIR}.${COMPONENT} ${CPFLAGS}
@echo ${COMPONENT}: rom module installed
clean:
${RM} ${TARGET}
@echo ${COMPONENT}: cleaned
resources:
# ${MKDIR} ${RESDIR}.${COMPONENT}
# ${CP} Resources.${LOCALE}.Messages ${RESDIR}.${COMPONENT}.Messages ${CPFLAGS}
# @echo ${COMPONENT}: resource files copied
${TARGET}: ${SOURCE}
${AS} ${ASFLAGS} ${SOURCE}
${EXP_HDR}.${COMPONENT}: hdr.${COMPONENT}
# ${CP} hdr.${COMPONENT} $@ ${CPFLAGS}
# Dynamic dependencies:
| Copyright 1997 Acorn Computers Ltd
|
| Licensed under the Apache License, Version 2.0 (the "License");
| you may not use this file except in compliance with the License.
| You may obtain a copy of the License at
|
| http://www.apache.org/licenses/LICENSE-2.0
|
| Unless required by applicable law or agreed to in writing, software
| distributed under the License is distributed on an "AS IS" BASIS,
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
| See the License for the specific language governing permissions and
| limitations under the License.
|
Dir <Obey$Dir>
amu_machine clean
| Copyright 1997 Acorn Computers Ltd
|
| Licensed under the Apache License, Version 2.0 (the "License");
| you may not use this file except in compliance with the License.
| You may obtain a copy of the License at
|
| http://www.apache.org/licenses/LICENSE-2.0
|
| Unless required by applicable law or agreed to in writing, software
| distributed under the License is distributed on an "AS IS" BASIS,
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
| See the License for the specific language governing permissions and
| limitations under the License.
|
Dir <Obey$Dir>
amu_machine rom
; Copyright 1997 Acorn Computers Ltd
;
; Licensed under the Apache License, Version 2.0 (the "License");
; you may not use this file except in compliance with the License.
; You may obtain a copy of the License at
;
; http://www.apache.org/licenses/LICENSE-2.0
;
; Unless required by applicable law or agreed to in writing, software
; distributed under the License is distributed on an "AS IS" BASIS,
; WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
; See the License for the specific language governing permissions and
; limitations under the License.
;
; > s.IICTest
GET Hdr:ListOpts
GET Hdr:Macros
GET Hdr:System
GET Hdr:Machine.<Machine>
GET Hdr:ImageSize.<ImageSize>
$GetCPU
$GetIO
$GetMEMC
$GetMEMM
$GetVIDC
GBLL med_00001_debug
med_00001_debug SETL {FALSE}
AssemblingArthur SETL {TRUE}
GBLL Module
Module SETL {FALSE}
GBLL ChecksumCMOS
ChecksumCMOS SETL {TRUE}
GBLL CacheCMOSRAM ; Whether to keep a RAM copy of CMOS RAM for faster access
CacheCMOSRAM SETL MEMM_Type = "ARM600" :LAND: {TRUE} ; (Space only allocated on ARM600 versions)
GBLL ProtectStationID ; if TRUE, disallow OSBYTE &A2,0,n
ProtectStationID SETL {TRUE}
GBLL TestHarness
TestHarness SETL {TRUE}
GET Hdr:ModHand
GET Hdr:Proc
GET Hdr:CMOS
GET ^.^.hdr.PublicWS
GET ^.^.hdr.KernelWS
! 0, "NVRAMSize at ":CC::STR:(NVRamSize)
LEADR Module_LoadAddr
TAB * 9
; Module workspace allocation
^ 0, R12
i2cWorkSpace # 256
corruption_test # 4
NVSize # 1
NVSpeed # 1
RTCFlag # 1
NVBase # 1
IIC_WorkspaceSize * :INDEX: @
; **************** Module code starts here **********************
Module_BaseAddr
DCD 0
DCD IIC_Init -Module_BaseAddr
DCD IIC_Die -Module_BaseAddr
DCD IIC_Service -Module_BaseAddr
DCD IIC_Title -Module_BaseAddr
DCD IIC_HelpStr -Module_BaseAddr
DCD IIC_HC_Table-Module_BaseAddr
DCD 0
DCD 0
DCD 0
DCD 0 ; Code to manually decode swi name (not needed)
IIC_Title
DCB "IICTest",0
IIC_HelpStr
= "IICTest"
= TAB, TAB
= "0.01 (06 Mar 1997)", 0
ALIGN
; *****************************************************************************
IIC_HC_Table * Module_BaseAddr
IIC_Service * Module_BaseAddr
IIC_Init
ENTRY
LDR r2, [r12] ; Hard or soft init ?
TEQ r2, #0
BNE %FT00
; Hard init
LDR r3, =IIC_WorkspaceSize
TEQ r3, #0
BEQ %FT00
MOV r0, #ModHandReason_Claim
SWI XOS_Module
LDMVSIA sp!, {pc}
STR r2, [r12]
00 MOV r12, r2
LDR R0, =&5C5C5C5C
STR R0, corruption_test
[ CacheCMOSRAM
BL InitCMOSCache
]
BL ClaimByteV
EXIT
IIC_Die ENTRY
TEQ r12, #0
LDRNE r12, [r12]
BL ReleaseByteV
EXITS
; *****************************************************************************
; ByteV handling routines.
ClaimByteV
ENTRY "r1,r2"
MOV r0, #ByteV
ADR r1, ByteVHandler
MOV r2, r12
SWI XOS_Claim
EXIT
ReleaseByteV
ENTRY "r1,r2"
MOV r0, #ByteV
ADR r1, ByteVHandler
MOV r2, r12
SWI XOS_Release
EXIT
ByteVHandler
Push "r0,r1"
TEQ r0, #&A2
BEQ OsbyteA2
TEQ r0, #&A1
Pull "r0,r1",NE
MOVNES pc, lr
; If &A1 then drop through to...
; *****************************************************************************
; OS_Byte &A1 and &A2 handlers pulled from s.PMF.osbyte. We declare our own
; MyOsbyte macro to exit our handler by claiming the ByteV call.
MACRO
MyOsbyte $cond
Pull "r0,r1,pc",$cond,^
MEND
; Read CMOS RAM
OsbyteA1 ; R1 = address , R2 = result
CLRPSR I_bit, R0 ; this may take some time
MOV R0, R1
BL Read ; Read CMOS ram at address <R0>
MOV R2, R0 ; Result in R0, return in R2
MyOsbyte
; Write CMOS RAM
OsbyteA2
CLRPSR I_bit, R0 ; this may take some time
[ E2ROMSupport
MOVS R0, R1
|
ANDS R0, R1, #&FF ; only look at bottom byte
]
[ ProtectStationID
MyOsbyte EQ
]
; This bit is conditioned out to make life easier...
;
[ {FALSE}
; Protect machine address CMOS (if not corrupt)
ASSERT EtherCheckCMOS = EtherAddrCMOS+6
CMP r0, #EtherAddrCMOS
BLT %FT10
CMP r0, #EtherCheckCMOS
BGT %FT10
Push "r0,r1"
BL GetMachineAddressCMOS
Pull "r0,r1"
MyOsbyte EQ ; don't allow write if address is valid
10
]
MOV R1, R2
BL Write
MOV R1, R0 ; R1 is supposed to be preserved
MyOsbyte
; *****************************************************************************
; Include the i2cutils source file from the Kernel sources.
GET ^.^.s.PMF.i2cutils
END
; > 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.
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
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
; > 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.
; > 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
; > 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?
> !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!
This diff is collapsed.
This diff is collapsed.
File deleted
directory
Manual fff 0 Mike_Stephens 28144883 31060a64 0
directory
Manual fff 1 Mike_Stephens 28144883 31060a64 0
This diff is collapsed.
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