The Datafile PD-CD 5/DATAFILE_PDCD5.iso/utilities/t/tornado/QandA/Paul1

Internet Message Format | 1995-06-26 | 7.7 KB

From: Paul Corke <[e-mail]>
Message-Id: <[e-mail]>
Received: by cent1.lancs.ac.uk; Sat, 24 Jun 95 12:02:29 +0100
Subject: Reply - part 1
To: [e-mail]
Date: Sat, 24 Jun 1995 12:02:29 +0100 (BST)
In-Reply-To: <[e-mail]> from "Niall Douglas" at Jun
6, 95 11:50:43 pm
X-Mailer: ELM [version 2.4 PL22]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 9952

Hiya,

> finish recoding it into assembler. I also need to write a millisecond timer,
> as blooming Acorn saw fit not to provide one. The most obvious course is to
> use the IOC latch 2Mhz timer, but this isn't RPC comp. Any ideas?

Could do one which is accurate to 10ms :).  I've got something here
somewhere which will do millisecond timing.  Question is, where!  It doesn't
appear to be on the hard-drive,  so it must be on one of the cartridges...
Right. It appears to attach itself to IRQ vector and watch for IOC/timer1.
Now as there is no IOC in a RiscPC,  the timer has to be derived from another
source.  I believe that the IOMD can supply a suitable ticker,  but without
the TRM I don't know what base address it's using.  With any luck, it's using
the same addr as IOC, but I'd have to knock up some code to try it.

> preemption is inefficiency, as the null return code can't be masked out (ie;
> the Wimp is always having to page in the task even when it may not be
> necessary).

Not sure what you mean about not being able to mask out null's.  Why can't
you?  If you're worried about too much paging,  then how about initialising
two apps for each real app.  For example "Impression" might take 600k,  but
it would mask out *all* events.  The co-app "ImpressionMsg" would mask any
events it doesn't want,  and pass any relevant ones on to the main app.  The
message gatherer might take 16k,  so only 4 pages need to be swapped in and
not 150.  I am assuming that the wimp isn't silly enough to page in tasks
before checking their poll mask...

>    In other words, the task behaves as normal, but say the user clicks on
> 'Recalculate spreadsheet' and then preemption is started up. Then RISC-OS

It would be nice to pre-empt all applications,  and not force them to be
written to support it,  but this is a step in the right direction.

> begins to look like the Mac, something I'm anxious to avoid. I think some

Then you could change the startup banner to read "Welcome to Acorn" and
change the error sprites to look like bombs... :)

> it. And I'd also stipulate that you should be able to plug 16 of these
Acorn's
> together by ethernet (or better) and have them all function as one huge

Distributed processing is currently a big research topic - there are all
sorts of problems - mainly associated with machines dying.  If some remote
machine dies then you don't know if it has executed the function you asked
it to.  For example if you ask a remote machine to add a record to a
database,  and it falls over for some reason,  how do you know if the record
was added or not?  Do you try to run the request again and risk two copies
in the DB?  Do you assume it was completed and risk the record not being
added?  I think you should leave the hooks for distributed processing,  but
don't try to write it for the first release!

>    Anyway, the way I have it is, upon receiving redraw, Tornado calls
> Wimp_RedrawWindow and Wimp_GetRectangle and stores the current graphics
>    I think this should work.

When you store the rectangles,  the Wimp will redraw the icons.  Then after
you have UpdateWindow'ed,  the icons will be drawn again.  Not a major
problem,  but it should work.  You may need to keep track of new rectangles,
though.  If something is being dragged accross your window,  then you might
get new rectangles to redraw before you have redrawn the old ones.

> Very very dodgy. If you have tried playing around with the memory map,
you'll

If the Wimp gets control and finds that someone has altered the mem map,  it
*will* quit and you'll lose all your work.

> I agree, but using better methods is far more time-consuming, and when
you'll
> have auto-compression after every heap op, it'll have to be quick. I've

Do you have to auto compress after each heap op?  Surely you only need to do
it when you fail to allocate memory:

* User requests block which is smaller than largest_block.  Allocate memory.

* User requests block which is larger than largest_block.  Compact heap.  If
  request is still larger,  extend heap or fail.  Allocate memory.

>    I believe there might be a problem under RO3.5 - Acorn have changed the
> OS_Heap format, and no doubt will go for some stupid relocatable

Have they?  The only reference to OS_Heap in the 3.5 PRM is:

PRM> RISC OS 2 and 3 place strong restrictions on the heap: the base of the
PRM> heap as specified in R1 must be word aligned and less than 32Mbytes, and
PRM> the size of the heap must be a multiple of 4 and less than 16Mbytes.
PRM>
PRM> In RISC OS 3.5 platforms the only restrictions are that the base of the
PRM> heap must be word-aligned,  and the size must be a multiple of 4 bytes.

If they have changed the format,  then they haven't told anyone about it.

> and reruns itself, keeping the original app intact. When the new app has

Isn't it a bit wasteful on memory to have two copies of an app loaded at
once? For example,  Impression Style with no files loaded takes up 600K of
wimpslot.  This is no problem on a 9Mb machine,  but what about 2Mb users?
Here's a possible solution.  Howabout the old app saves all it's data into
tfs: and the new app then loads it back.  A swi "Tornado_ReLoadApp" could do
it in the background:  the app saves it's data into tfs: and then calls the
swi.  The new app is loaded over the top of the old one,  and initialised.
When the Tornado App Manager sees a Message_TaskStarted it can send a
Message_DataLoad to the application to force it to load data back from tfs.

> Is done. Tornado hooks into Address exception etc. and catches any such

Hooking on to hardware vectors is not the same under RISC OS 3.5.  Two
reasons: the module area is now at &2100000.  If you were to assemble the
instruction "b &2100000" and disassemble it you will find that you've run out
of bits (dis: b &fe100000).  The second reason is the new
processor modes with the ARM6 and above - when an exception occurs
you get put in a 32 bit mode - 26bit code doesn't work in 32 bit
modes, so you have to switch back to 26bits.  Fortunately there is a swi
which can help you:  swi "OS_ClaimProcessorVector",  but looking at the docs
it seems that you can't use the addrex vector (prefetch and data aborts are
supported).

------------------------------------------------------------------------------

Quicks comment on release 1 of Tornado.

 - TFS

Does not work.  I've assembled it,  and loaded the module.  Typing *tfs
is fine, but any further * commands (such as *. *info *ex) fail.  They all
data-abort at &01c02084 - according to my memory map this is near the bottom
of the system heap (starts at &01c02000).

When I try to shutdown the computer,  I get the error FS_Entry Func 16 not
supported by tfs - I've looked up Func16 in the book and it is just called
shutdown.  On entry,  r0=16 - I think you can safely ignore this one and
not bother with the error.

 - HeapExt

Works,  but garbage collection doesn't appear to be very good.  At the left
of the bar,  it's mostly white with a few black lines;  to the right of the
used portion it is mostly black with a few white lines.  The right hand side
of the heap is completely black (because it's unused).

- TornMod and THeapMod

Some test code would be nice,  although from looking at the source I guess I
need ROS 2 to run THeapMod :)

------------------------------------------------------------------------------