ARM Club 3/TheARMClub_PDCD3.iso/hensa/misc/tornado/tndemo1/Readme

Text File | 1996-03-06 | 12KB | 214 lines

Readme for tornado 0.10b (06-03-1996)

by N. Douglas

   This is a temporary release of what is a small taster of what is to come.
In this archive is !Tornado, the resource directory but with only the kernel,
and !TornWin, a demo tornado window. This is a tornado window as it should
hopefully end up looking like.
   This is merely an intermediate program. I'm still writing it, as you'll
see if you look through the code. ATM, I'm doing the icon stuff, and when
that's done I'll finish off the string and attribute handling properly,
including visual linking to code fragments. Then I'll convert the lot into
assembler (then release), whack it into the shell module which isn't being
released with this, and finish the multitasker (then release). I suppose that
at this stage tornado would be something which theroretically people could
actually write for.

Why release it now?
-=-=-=-=-=-=-=-=-=-
   I thought I'd release this copy now, mainly for two reasons. Firstly, a
lot of people seem to think I'm some kid who came up with a good idea,
flashed it around the networks and then got bored and went away. I'd like to
say to all those who have been saying this *GO* *SCREW* *YOURSELVES*. I'd
also _quietly_ ask that if you lot are so full of yourselves, then why don't
you sit down and try planning and writing all this crap out, especially when
you have a major amount of study for rather important exams soon. I'd love to
see your (feeble and pitiful) attempts, honest! :)
   Secondly, there has been a slight but noticeable increase in the number of
people who are getting very gloomy about the future of RISC-OS, the
architecture and Acorn in general. I hope this will show you that things
aren't going to the dogs quite as easily as some of you might think, that
some people are actually doing things about it. Cheer up! ;)

   Just as a statistic, I've been watching hensa's top 50 for a while now,
and I've noticed that since its appearence in AU, it's never left the list -
and seeing as I'd prefer it not to, I decided to knock out this. Some people
already have a much much older version of this program, which on the front
does the same thing, but in fact is a totally different program (I had to
start all over because the code was getting too messy + it didn't use the
kernel at all). So, if you have a copy, and are thinking "This hasn't changed
much in 3 months or so", well, you're wrong!

Bugs
-=-=
   You'll notice that it all still has a few bugs. Firstly, scrolling by the
scroll bars corrupts the display - and don't ask me why, I think it's
rounding errors. I only finished this bit today (scrolling), so I still have
a bit of leeway. Next, the tornado kernel has a MAJOR bug with post-wimp-slot
heaps - it hates extending them (again, I don't have a clue why - it hasn't
any problems with extending anything else). Next, the fonts aren't recached
on mode change - changing mode from hires to lores or vice versa causes
problems. In addition, nothing is done on mode change - so the RISC-OS dummy
window may unstick from the tornado one by a pixel or two for example as
RISC-OS tends to realign windows to the eigen factors on mode changes.
   It also works much better if you reinitialise it before use (hence the
yucky *RMReInit in the !Run file), mainly as it's becoming quite a horrible
bit of code which has been tweaked a lot. When I first wrote the memory
routines back in July-August 95, they worked perfectly. Since, I've changed
the heap data format three times, tweaking the code each time. Also, they
were written for speed, meaning the source is about as incomprehensible as
the debugger output, so my skills as an assembly programmer were sorely
tested, and I think I must have missed something somewhere surely. However,
I'm sure the bugs will slowly iron themselves out in due course.

   You may think it runs very slowly. This may be because you are running it
from a slow medium, and a log file is continually written to by the program -
if so, either copy it to a quicker one (eg; RAM disc) or edit the !RunImage
(change line 220 to log%=FALSE). The other thing is that you may have a
'slower' machine - it takes three seconds on mine to redraw fully in Mode 20
with a standard palette. When dragging things around and over it though, do
note how the window doesn't always redraw fully, but given a chance it does.
This is a taster of what multitasking redraws look like - not hugely
impressive here because the redraw code's in Basic, but when in assembler it
should really kick ass. Also, of course, Basic won't multithread, so in fact
it should be even more impressive with many sections being redrawn
simultaneously.
   You'll notice how it doesn't leave things unupdated like Win95 or System
7.x - this is because redraw threads are placed in the top priority, so they
get the most CPU time. In fact, on tornado, redrawing is the THE top priority
of all - nothing can be higher.
   BTW, if it looks real gammy - there are two reasons for this. First, and
probably most likely, is that you don't have enough colours on the screen -
although I can't test it, it should look gorgeous in 24bit (and be quick too
as there shouldn't be any need for colour translation tables). Anyway, in
Mode 21 on my machine is looks bloody fine.
   Second reason is if you aren't using a hires display. I haven't
implemented lores operation yet (nor will I until /way/ into the future -
after when the multitasker has been written), so it simply scales the sprites
down to fit (which looks crap).

Documentation
-=-=-=-=-=-=-
   The two files _Kernel and _Shell give a few bits and pieces about each
relevent module and what they will do. In particular, _Shell has a good few
updates on the docs older than this release. The program MultiTtest
implements a model of the tornado multitasker - would anyone with experience
in multitaskers contact me as I have precious little information on how they
should work?
   Currently, the multitasker takes current CPU speed (based on screen mode,
CPU speed etc) and the load on the RISC-OS desktop into account when sharing
out time between individual tasks, and attempts to obtain the maximum
efficiency it can (time spent executing code against time spent in
multitasking the code).
   The testbed multitasker as supplied was fed the data for the processors
below, given eight tasks to switch between and told to (a) turnaround all
tasks in 25cs and then pass control to the wimp and (b) turnaround all tasks
in a second but every 25cs pass control to the wimp. Here's the results:

Type (a) multitasking:

  CPU         MIPS     Efficiency      cs per task     turnaround time (secs)
8Mhz  Arm2      4       99.75%          2               0.2
12Mhz Arm250    6       99.87%          3               0.26
25Mhz Arm3      12      99.93%          3               0.25
33Mhz Arm3      15      99.95%          3               0.25
30Mhz Arm610    26      99.97%          3               0.24
33Mhz Arm700    35      99.98%          3               0.24
??Mhz ArmXXX    50      99.98%          3               0.24

Type (b) multitasking:
  CPU         MIPS     Efficiency      cs per task     turnaround time (secs)
8Mhz  Arm2      4       99.92%          7               0.62
12Mhz Arm250    6       99.95%          7               0.6
25Mhz Arm3      12      99.97%          7               0.58
33Mhz Arm3      15      99.98%          7               0.57
30Mhz Arm610    26      99.99%          7               0.56
33Mhz Arm700    35      99.99%          7               0.56
??Mhz ArmXXX    50      99.99%          7               0.56

The MIPS values are approximate, and the Arm700 one is for a prototype chip,
not the production one. As you can see, the switcher is very optimised,
achieving at worst a loss of 0.25%, and obviously the faster the processor
the less the loss is.

Anyway, while all this is all well and good, there is a problem. As you can
see, the multitasker can only handle a minimum of 1cs slices. Now, I don't
know much about other architectures, but 1cs is an *awfully* long time, and
it gives very little scope for multithreading as you only need ~25 processes
running for cascade overload (ie; when total time to turnaround exceeds time
allowed for turnaround). This is _nothing_, as another testbed of mine proves
that when you move a tornado window around a lot you can start up to a
hundred new redraw threads. Obviously, 100cs is > than 25cs, and cascade
overload happens just like that! :(((
   So, what I'm wondering is, does ANYONE know of any method past this? Maybe
a different method of multitasking? Perhaps a method of scheduling interrupts
for periods smaller than 1cs on existing Acorn machines? You can hook code
onto the internal hardware ticker vector, which oscillates at (I think) 2Mhz,
but this is unsuitable for interrupt code as - well, how the hell would you
do it? Anyone got any ideas? Please contact me then!

   As a final point, I think the kernel's Tornado_Hourglass call still works
- if it does, have fun! (and make sure you save your work first!)

Cheers,
Niall Douglas



Methods of contacting me:
-=-=-=-=-=-=-=-=-=-=-=-=-

I am plugged into the various networks at the following addresses:

 Niall Douglas@fidonet#2:443/13.68
 [e-mail]
    - this is an internal Irish address and so is very cheap for me to use.
Please send anything to here if you're on fidonet.
      The internet address attached to it is very unreliable at the moment
(probably disconnected for good :( ), so if you don't get a reply try the
other ones below.

 Niall Douglas@fidonet#2:257/501.13
 [e-mail]
    - this is in the UK, which is at cross-channel rates for me (ie; VERY
EXPENSIVE). The internet address attached, unfortunately, also is expensive,
so if you use this address, please do NOT send anything largish, only
smallish messages.

 [e-mail]
    - this is my local internet PoP, but irritatingly doesn't have an offline
mail reader ie; I have to do all mailing while online which mounts up. It's
great for large uucodings though ie; if you want to send me a file, do so
through this address.


Finally ...
-=-=-=-=-=-
   I'd like to thank the following people:
 - Ricky Sarge, for your help with the memory copying code
 - Nava Whiteford, for your support and saying how wonderful my ideas are ;)
 - Justin Fletcher, for inspiring me with that data streaming and eyes and
hats and arrows etc stuff. BTW, how's Caroline? (rotten joke). If you're
wondering, Laura's doing just fine ... I still keep socialising with her ...
I'm thinking of asking her to my graduation dance ... ooar! ;)
 - Colin Turner, for being so /you/!
 - John Stonier, for never answering your mail! ;)
 - all the blokes on the Acorn fido-scene, and various people from the
internet for all your ideas and support. I hope I do justice to your
requests!

Last but not least ...
-=-=-=-=-=-=-=-=-=-=-=
   I'm looking for work in England for the summer for July and August. I'm
hard-working, excellent at computers ('specially Acorns of course), and
willing to take almost peanuts for pay! As you can see above, I'm pretty
handy with the programming, and I've serviced and upgraded my computer
entirely by myself. I can fix (almost) any problem with an Acorn, and can go
a long way to a solution with Macs, PCs or Unix boxes.
   I should get around 500 out of 600 points in my Leaving Cert in June and
would be willing to work anywhere in the UK. If you are interested in
employing me (and why not???), then email me above and ask for a CV. I'll be
emailing all the Acorn-related companies with email addresses anyway, when I
get a list that is!