How to update ROMs de RiscOS 3.1?  by Jerome Mathevet
(speedsterh@yahoo.com) v0.021 06/06/1999

0 Warning All information is given in good faith, I tested when I
could what I affirm, but it can remain of the errors.  If you have a
problem, that I am faulty or not, I do not feel responsible (but if
you unearth an obvious error, prevent me that I correct).  This
document is used to gather a certain number of knowledge on the
subject, not to make trade.  RiscOS 3 is a product Acorn, it was sold
to you, you cannot do anything of it (not to surely redistribute it,
in software or material form).

Manipulations apply only to the pre-riscPC (A5000, A4, A540...).  In
particular, the significance of the addresses (system map) has nothing
to do with what one finds on RO3.5 and beyond where the hardware
changed much (where the IOMD replaced the VIDC and the MEMC).  Thus,
if you want dumper RO 3.5, clear up you!

1 Introduction  If you have RiscOS 3.1 since step badly of time,
perhaps hoped that Acorn thinks of you and proposes an update with
more recent versions of Draw, various modules having bugs known for a
long time (SerialUtils on 3.10, etc...), the nested window to manage,
the Internet modules, of beautiful icons and why not Toolbox.  It is
all the more desirable since the machines which have this already old
OS version are rather limited by the extension in RAM (12 Mo for A540,
8 Mo for A5000 and 4 Mo for A4).  One then finds oneself to give the
responsability the RMA (zone of the modules) to mitigate vetusté of
the parts in ROM, with the result that a large part of this ROM
becomes useless (and that one cannot make any more turn of
applications).

Had Acorn already proposed an update of ROMs for those which had RO2,
then why not with RO3?  As you know it already, Acorn is not any more
and one will not have to count on their substitutes, well too occupied
wanting to sell RiscOS4/Phoebe/Autre.

/As always in this kind of situation, one should count only on oneself,
or in all cases, on those which have the motivation without the
financial interest.  A small recent debate in the news on this subject
shows that interest, there is.

Initially, I gather the state of knowledge on the matter, if that can
stimulate the ' recherche' in this field.  If ever there is a quasi
infallible method which is set up, with why not diagrams of engraver
and a method to modify the old modules, I will try to hold the up to
date document.

2 ROMs  On A5000, RO3.1 is provided on 4 ROMs 8 bits of 512 KB (I read
in the news that some had 2 ROMs of 1 Mo, but that is not documented
in my TRMs), for a total of 2 Mo of ROMs.  Each one is numbered from 1
to 4 and provides part of the word (a byte in fact) located at a
certain address N of the system.  Thus, when the system reads the word
located for example in & 3800000, the 4 ROMs are requested (Which
knows in which order are arranged ROMs, i.e. the correspondence
between the number of ROM and that of the provided byte?).

On A4, I believed to read that OS was on 2 ROMs, as on the riscPCs I
do not know any more.

About A540, I know some even less.

Does the system know ROMs via the addresses (logical?)  & 3400000 with
& 4000000, this zone being separate into two:  Low ROM beyond &
3800000 (which give access to ROMs of origin) and high ROM in on this
side & 3800000 (space of addressing of the ROM 5th column).  The space
of addressing is 12 Mo, certainly planned so large for the day when
new mother boards would support of ROMs broader, without having to
change the ' system map' (finally, that will not have been useful
since RiscPC did not profit from this delicate attention).

It is possible to specify the size of ROMs principal (up to 1 Mo) by
moving the riders LK10 on 1-3 and 2-4.  In the same way, the ROM 5th
column can go up to 256 KB by displacement of rider LK15 on 1-2.  Only
apparatuses JEDEC (do not ask me what it is!)  are recognized for the
ROM 5th column.  For ROMs principal, EPROMs compatible
stitch-with-stitches with the 27C080 (8Mbits = 1Mo) or 27C040 (4Mbits
= 512Ko) seem to be appropriate.

RiscOS 3 holding out of 2 Mo, it would be possible to take the image
of existing ROM and to supplement it until filling 4 Mo (by modifying
the end of the chain of modules - to see further).  Nevertheless, that
would not exempt a regraver to you 4 EPROMs.

The low ROM (of size 8 Mo) is the only readable part with a machine of
origin.  One realizes that there is a looping of 2 Mo which makes that
the contents read enter & 3800000 and & á00000, & á00000 and &
3c00000, & 3c00000 and & é00000, & é00000 and & 4000000 are the same
one.  This looping is due to the fact that ROMs are requested
according to the signals which they receive.  The logical addresses &
3800000 with & 4000000 are physically addresses enters & 0 and &
7FFFFF (8 Mo - 1).  If one takes 4 ROMs of 512Ko, the signals of
strong weights will not be received by ROMs, and those will react only
according to the weaker bits of weight.  From where looping.  With 4
ROMs of 1Mo, looping would be made nothing any more but 2 times.

The high ROM (of size 4 Mo) is inaccessible by defect (No readable
memory At this adress).  These addresses give access the ROM 5th
column, if it is present (source:TRM).

While I am there, I make a point of clarifying the myth around this
ROM 5th column ' which is automatically recognized by OS if one gives
him the structure of a podule '.  The ROM 5th column could not be used
to save RAM:  the modules launched since this ROM will be recopied in
RAM before.  The only benefit of manipulation could be a faster boot,
the insurance to have certain modules some is the state of tiredness
of the hard disk, to test modules to see whether they are ROMmables
before buying grosses ROMs 8Mbits, other?

3 Dump of OS Nothing simpler, and this stage is preliminary first of
all serious.  Ensure you to have at least 3-4 Mo of free on your hard
disk IDE (not to awake infamous the bug which corrompt the map) and
type:

* save ROM 3800000 á00000

And here you are with a file ROM in the current directory which
contains RiscOS 3.1.  This file is not distributable, if not
gnagnagni-gnagnagna Acorn comes out of its tomb to bring you a
lawsuit.

You can try to make * save ROM2 á00000 3c00000, you should obtain the
same file exactly (to compare with the program BASIC UUencodé with
the end).

The command * save updates the ' load address' file, that makes it
possible with Zap to find the instructions with the address where they
will be carried out.

Try to accustom you to his structure, examine how the image of ROM is
ridge, that will be able to avoid you some blunders.

4 Structure of the ROM It is relatively simple:  - a heading at the
beginning, which will charge RiscOS - the ' BootStrap '.  On RO3.10,
it finishes in & 0380c288 (excluded).

- a chained list of modules EM ROM.  The chaining is done by a word
right before the module, indicating displacement (offset) to make to
point on the following module.  Therefore if toto% point on the
beginning of a module (cf the result of * modules), you have the
following into toto%+(toto%!-4).  An offset of 0 indicates the end of
the chain of modules.  I never found this information in StrongHelp (I
badly sought?)

- data at the end which are useful for the ' Easter eggs ' in RiscOS,
they are primarily a list of people who contributed to the realization
of the system.  Reassure you, even if that can represent for you a
waste of ROM, one is far from MicroSoft which includes a flight
simulator in Excel!

The structure seen of Slipping by (Apps, Font, Resources) is créee by
certain modules with starting by calling the SWI '
ResourceFS_RegisterFiles '.  Defer to the documentation of this SWI to
know some more.  The killed modules withdraw To spin their files
associated by the SWI ' ResourceFS_DeregisterFiles '.  Ex:  *  RMKILL
Messages, then go in the structure of files in ROM - there are almost
nothing any more, attention, Filer complains about this fact (a bug
certainly).  Then * RMREINIT Messages, any cost as usual.

The Messages module is very significant for several reasons:  � size!
  (~200Ko) � It creates a chain of ' clean ' ResourceFS_RegisterFiles
files in the direction where it is it which finishes the module.  One
thus can very easily the bidouiller to add files with the system, to
prevent the loading of files by other modules, and to propose
replacements in that one!  It is by this module that I besides will
put others sprites system.

5 How to replace of the old modules by more recent modules?    Several
problems are made day if one wants to add new modules or more recent
versions of modules existing already in ROM:

- the badly written modules write in their zone of code and not in
their workspace.  Even if the pointer of workspace does not point
directly on the module itself (what is very improbable), it may be
that at certain times, the module car-is modified nevertheless.

You can also look at the contents of a module periodically with Zap
(Create->Get Module) to see whether bytes changed (with a diff, or my
small programme of comparison in appendix (1)). Attention, even if at
the end of several days of use with the module, you do not perceive
any change between 2 ' copies' modules at different moments, that does
not prove anything!  On the other hand, if you see a difference
between 2 copies of different times, that will prove a thing:  the
module is not ROMmable.

     [ In practice, I have the impression that if the module is
badly written, one knows it from the very start, with the first '
grab'.  In the same way, if an author badly wrote a module, one can
expect that it continues with others.  Lastly, Congratulations with
John Kortink of which all the modules which I saw of him are a priori
ROMables ].

Very significant remark:  The modules grabbés in RAM with Zap do not
have the same length inevitably as the version disc (even if the
module is not compressed).  The difference in size can go up to 12
bytes, that comes from what Zap allocates of memory RMA with OS_Heap
with a multiple of 16 close (??) putting the contents of the module at
it.  To check with the original file where start the differences.  If
it is outwards, there are no badly chances that it is potentially
ROMable.

Other possibility (with RiscPC under the hand or * perhaps * A5000
with module DDA of Justin Fletcher):  to carry out the module in
Dynamic Area with reading alone.  If the module dies and/or displays
errors, it is not of course good step (Concretely, how that is done
it?).

- It is extremely possible that modules make direct calls with modules
in ROMs by Branches (towards Shared C Library, e.g.).  If it is
necessary to take again with zero the ROM, one will move the LIB, one
will thus need ' ajuster' the Branches cablés (hard!  hard!).

- In order to circumvent the thorn-bush problem of Shared C Lib, one
could leave it where it is, and to move the other front modules or
after it, according to their new size.  This will probably require '
to cheat ' on the size of one of the modules (p.ex that the preceding
immediately SCL), and to lose some bytes of ROM by the same occasion,
but it is ' for the good cause '.  It is the solution which I will
choose.

Modules candidates to be put in ROM (a priori):  See list in appendix
(2).

Modules ROMmables perhaps ROMable after a certain processing:  -
modules of Toolbox:  Attention those are compressed and are
décompressent with launching (They adjust also static links towards
the LIB).  It is necessary for you to launch the modules since the
disc, then the ' grabber' with Zap (' Get module').  This obliges you
to keep the LIB in the same place as at the time when you made the '
grab'.  I did not succeed in having a versionde these modules ready to
put in ROM. - DrawFile 1.43, ColourPicker:  They adjust static links
towards the LIB

Modules ' recalés'???:  See list in appendix (2).

You can use the tools provided in appendix (5 and 6).  In appendix
(3), you will find a program to insert a file in the structure of
ResourceFS.  For the edition of the chain of the files of ResourceFS,
I use Zap (ex directly:  I seek the head of chain of ResourceFS, with
a find ' SWI ResourceFS_RegisterFiles '.  I seek the value of R0 right
before the SWI.  I go to this place, I course the chain to the place
which interests me.  Then, with the cursor on the beginning of the
structure, Ctrl-U a number which is the word count or bytes to erase -
according to the mode - then Shift-Delete).  To check that the chain
is always valid with the RFS_Analyse program, that will avoid you
problems.

6 is possible to put programs BASIC freeware in ROM?    The short
answer is:  a priori, yes.  Alarm, Tanks and Calc are in BASIC, their
code is in ROM and carried out in ROM.  I thus do not see why the
weather would not be possible to be similar with other programs BASIC.
The easy way that use Alarm, Calc and the others are to regulate the
wimpslot then to chain a very small program BASIC of nothing the whole
called!Runlink by the true program BASIC (I let to you examine
yourselves the!Runlink and draw your conclusions).

**time-out** in any event, the!Runlink have need of little of RAM,
therefore it take at least 32K on the machine have a MEMC of which it
be the size of page.  It is also the minimum for the true program
BASIC.  The direct consequence of this, it is that it is useless to
want to put in ROM a program BASIC of less 32K. Problème:  The
programs BASIC of more than 32K are not legions: (

There are fortunately some exceptions:  Webster, Printers, ChangeFSI,
Templed (rather for the programmers, but if you read that, you are
one, not?),  To organize...

Good, besides the life is not so pink... because the large programs
like Webster and Printers use the capacities of LIBRARY of the BASIC,
which disturb the installation in ResourceFS completely
(Include/understand:  I did not succeed in making them turn in
ResourceFS... grrr).

However, I had the joy of seeing turning Templed and Organiser with of
Wimpslot of 38Ko and 56Ko (instead of 108Ko and 140Ko) in
ResourceFS...

It's a pity that one passed beside the possibility of having a browser
HTML (Webster) requiring 100Ko RAM!

For a list of my échecs/réussites with the programs BASIC, defer you
to the appendix

7 I do a list have of Modules to engrave, I do what now?    It is
necessary to prepare an image of ROM, before the gravage.  That
returns to concaténer the loader, the modules, and to make sure that
the chain is valid (there is in appendix a program BASIC which does
that).  Attention, CRUCIAL thing, SharedCLibrary of your image must be
with the same position as those of ROMs of origin.  That affects
certain applications in ROM (written into C), the modules of Toolbox,
and perhaps of other hidden things.

Also should be used the Splitter program (appendix 4) to separate the
bytes from the original file (1 word gives 4 bytes).

8 Engraving  Already, it is necessary to know which will be the
support.  There are at least the choice between ROM (risky, and not
obvious to find in the catalogues), of the EPROM or the EEPROM (3 to 4
times more expensive than the EPROM), or of the flashROM (as there are
some on certain cards SCSI).  Some mention static RAM (to 15 NS!!!)
to which the price is close to that of the EPROM but it is RAM and not
of the ROM, it must be needed a feeding in a permanent way (??), and '
logic of écriture', because RAMs, even statics, do not contain data
with starting.

For the EPROM 1 Mo (8 Mbits), model 27C080 (I have the technical cards
of STMicroelectronics and Atmel) is appropriate pin for pin with the
supports of A5000 (Attention, pin 1 of the supports of ROM is
appellée Vpp on TRMs and not Vpp/A19 as / I think / one would need it
- rider LK12 makes it possible to lead the 20th overhead bit in order
to reach until 1024*1024 addresses).

Engraving requires a tension which is not available on our machines
(between 12.5 and 13.5 V). One thus needs specialized hardware
(perhaps that a store can carry out this manipulation for you).  I was
likely to fall on an electronics specialist who makes me manipulation
' free of load ' in Taipei.  Even if it is necessary for you to spend
a little bit, it is always less expensive than to buy the engraver
(for PC under DOS or Windows):  to count 3000 FF for an engraver of
EPROMs 8Mbits.

9 Last recommendations  If you want to put different modules than
those given on my list, here some precautions.

- Zap will be probably never ROMable.  It is a choice deliberated on
the current mainteneurs:  Less RAM taken, less fragmentation in the
event of crash of Zap, parts of code incomprehensible that it is quasi
impossible to change: -)  It is from my point of view very damage bus
Zap itself now borders (1.42) the 200 KB.  For the modes of extension,
rare are those which do not write in their code, and moreover, it is
essential that the Zap module starts before the modes of extensions.
In all the cases, one can nothing make: - (

- Toolbox:  Who succeeded in obtaining ROMables versions of these
modules?  **time-out** they make part of RO3.7 and must not pose of
problem in theory.  In practice, I did not succeed in anything making
some.

- Module of replay of music (DSym, QTM, Matrix, DigitalCD, etc...):
Do not even think of it.  If these modules were in ROM, I think that
they would make so that the routine of replay point in the body of the
module.  This would like to say a slower execution.  In light, the
machine time taken for the reading of a piece would be increased and
if your machine could not it, you would have a monstrous cacophony in
your loudspeakers.

8 Thanks  Frederic Elisei for the attentive second reading.  Jean
Richard for the sending of TRMs. Richard Murray for the translation in
English (Hey!  Your french' S getting better!)  Darren Salt and
Christopher Bonet for the ideas and warnings in the newsgroup.

9 APPENDIX  All the programs are in BASIC (& FFB) Appendix (1) -
CmpFiles

A comparator of file in BASIC.  Favour compared to diff:  it asks less
place memory and treats the files an unspecified length.
Disadvantage:  Much less options.

Appendix (2) -  Carryforward

A nonexhaustive list of ROMables modules

Appendix (3) -  File2RFS

add with a disk file a heading in order to be able to insert it in a
chain for the SWI ' ResourceFS_RegisterFiles '.

Appendix (4) -  Splitter

cut an image of ROM in 4 files.

Appendix (5) -  Modules

analyze the current chain of the modules and optionnellement allows to
save one of the modules in RAM.  The size of the modules is also
indicated.

Appendix (6) -  ROMMod

analyze the current chain of the modules and optionnellement allows to
save one of the modules in RAM.  The size of the modules is also
indicated.

Appendix (7) -  RFS_Analys

list the files attached to ResourceFS in a module, being given an
offset since the beginning of the module.

Annexe(8) - basicprgs List of the programs BASIC which it seems
possible to put in ResourceFS.