home *** CD-ROM | disk | FTP | other *** search
/ The Datafile PD-CD 5 / DATAFILE_PDCD5.iso / utilities / t / tornado / TNdemo1 / Readme < prev   
Text File  |  1996-03-06  |  12KB  |  214 lines
  1. Readme for tornado 0.10b (06-03-1996)
  2.  
  3. by N. Douglas
  4.  
  5.    This is a temporary release of what is a small taster of what is to come.
  6. In this archive is !Tornado, the resource directory but with only the kernel,
  7. and !TornWin, a demo tornado window. This is a tornado window as it should
  8. hopefully end up looking like.
  9.    This is merely an intermediate program. I'm still writing it, as you'll
  10. see if you look through the code. ATM, I'm doing the icon stuff, and when
  11. that's done I'll finish off the string and attribute handling properly,
  12. including visual linking to code fragments. Then I'll convert the lot into
  13. assembler (then release), whack it into the shell module which isn't being
  14. released with this, and finish the multitasker (then release). I suppose that
  15. at this stage tornado would be something which theroretically people could
  16. actually write for.
  17.  
  18. Why release it now?
  19. -=-=-=-=-=-=-=-=-=-
  20.    I thought I'd release this copy now, mainly for two reasons. Firstly, a
  21. lot of people seem to think I'm some kid who came up with a good idea,
  22. flashed it around the networks and then got bored and went away. I'd like to
  23. say to all those who have been saying this *GO* *SCREW* *YOURSELVES*. I'd
  24. also _quietly_ ask that if you lot are so full of yourselves, then why don't
  25. you sit down and try planning and writing all this crap out, especially when
  26. you have a major amount of study for rather important exams soon. I'd love to
  27. see your (feeble and pitiful) attempts, honest! :)
  28.    Secondly, there has been a slight but noticeable increase in the number of
  29. people who are getting very gloomy about the future of RISC-OS, the
  30. architecture and Acorn in general. I hope this will show you that things
  31. aren't going to the dogs quite as easily as some of you might think, that
  32. some people are actually doing things about it. Cheer up! ;)
  33.  
  34.    Just as a statistic, I've been watching hensa's top 50 for a while now,
  35. and I've noticed that since its appearence in AU, it's never left the list -
  36. and seeing as I'd prefer it not to, I decided to knock out this. Some people
  37. already have a much much older version of this program, which on the front
  38. does the same thing, but in fact is a totally different program (I had to
  39. start all over because the code was getting too messy + it didn't use the
  40. kernel at all). So, if you have a copy, and are thinking "This hasn't changed
  41. much in 3 months or so", well, you're wrong!
  42.  
  43. Bugs
  44. -=-=
  45.    You'll notice that it all still has a few bugs. Firstly, scrolling by the
  46. scroll bars corrupts the display - and don't ask me why, I think it's
  47. rounding errors. I only finished this bit today (scrolling), so I still have
  48. a bit of leeway. Next, the tornado kernel has a MAJOR bug with post-wimp-slot
  49. heaps - it hates extending them (again, I don't have a clue why - it hasn't
  50. any problems with extending anything else). Next, the fonts aren't recached
  51. on mode change - changing mode from hires to lores or vice versa causes
  52. problems. In addition, nothing is done on mode change - so the RISC-OS dummy
  53. window may unstick from the tornado one by a pixel or two for example as
  54. RISC-OS tends to realign windows to the eigen factors on mode changes.
  55.    It also works much better if you reinitialise it before use (hence the
  56. yucky *RMReInit in the !Run file), mainly as it's becoming quite a horrible
  57. bit of code which has been tweaked a lot. When I first wrote the memory
  58. routines back in July-August 95, they worked perfectly. Since, I've changed
  59. the heap data format three times, tweaking the code each time. Also, they
  60. were written for speed, meaning the source is about as incomprehensible as
  61. the debugger output, so my skills as an assembly programmer were sorely
  62. tested, and I think I must have missed something somewhere surely. However,
  63. I'm sure the bugs will slowly iron themselves out in due course.
  64.  
  65.    You may think it runs very slowly. This may be because you are running it
  66. from a slow medium, and a log file is continually written to by the program -
  67. if so, either copy it to a quicker one (eg; RAM disc) or edit the !RunImage
  68. (change line 220 to log%=FALSE). The other thing is that you may have a
  69. 'slower' machine - it takes three seconds on mine to redraw fully in Mode 20
  70. with a standard palette. When dragging things around and over it though, do
  71. note how the window doesn't always redraw fully, but given a chance it does.
  72. This is a taster of what multitasking redraws look like - not hugely
  73. impressive here because the redraw code's in Basic, but when in assembler it
  74. should really kick ass. Also, of course, Basic won't multithread, so in fact
  75. it should be even more impressive with many sections being redrawn
  76. simultaneously.
  77.    You'll notice how it doesn't leave things unupdated like Win95 or System
  78. 7.x - this is because redraw threads are placed in the top priority, so they
  79. get the most CPU time. In fact, on tornado, redrawing is the THE top priority
  80. of all - nothing can be higher.
  81.    BTW, if it looks real gammy - there are two reasons for this. First, and
  82. probably most likely, is that you don't have enough colours on the screen -
  83. although I can't test it, it should look gorgeous in 24bit (and be quick too
  84. as there shouldn't be any need for colour translation tables). Anyway, in
  85. Mode 21 on my machine is looks bloody fine.
  86.    Second reason is if you aren't using a hires display. I haven't
  87. implemented lores operation yet (nor will I until /way/ into the future -
  88. after when the multitasker has been written), so it simply scales the sprites
  89. down to fit (which looks crap).
  90.  
  91. Documentation
  92. -=-=-=-=-=-=-
  93.    The two files _Kernel and _Shell give a few bits and pieces about each
  94. relevent module and what they will do. In particular, _Shell has a good few
  95. updates on the docs older than this release. The program MultiTtest
  96. implements a model of the tornado multitasker - would anyone with experience
  97. in multitaskers contact me as I have precious little information on how they
  98. should work?
  99.    Currently, the multitasker takes current CPU speed (based on screen mode,
  100. CPU speed etc) and the load on the RISC-OS desktop into account when sharing
  101. out time between individual tasks, and attempts to obtain the maximum
  102. efficiency it can (time spent executing code against time spent in
  103. multitasking the code).
  104.    The testbed multitasker as supplied was fed the data for the processors
  105. below, given eight tasks to switch between and told to (a) turnaround all
  106. tasks in 25cs and then pass control to the wimp and (b) turnaround all tasks
  107. in a second but every 25cs pass control to the wimp. Here's the results:
  108.  
  109. Type (a) multitasking:
  110.  
  111.   CPU         MIPS     Efficiency      cs per task     turnaround time (secs)
  112. 8Mhz  Arm2      4       99.75%          2               0.2
  113. 12Mhz Arm250    6       99.87%          3               0.26
  114. 25Mhz Arm3      12      99.93%          3               0.25
  115. 33Mhz Arm3      15      99.95%          3               0.25
  116. 30Mhz Arm610    26      99.97%          3               0.24
  117. 33Mhz Arm700    35      99.98%          3               0.24
  118. ??Mhz ArmXXX    50      99.98%          3               0.24
  119.  
  120. Type (b) multitasking:
  121.   CPU         MIPS     Efficiency      cs per task     turnaround time (secs)
  122. 8Mhz  Arm2      4       99.92%          7               0.62
  123. 12Mhz Arm250    6       99.95%          7               0.6
  124. 25Mhz Arm3      12      99.97%          7               0.58
  125. 33Mhz Arm3      15      99.98%          7               0.57
  126. 30Mhz Arm610    26      99.99%          7               0.56
  127. 33Mhz Arm700    35      99.99%          7               0.56
  128. ??Mhz ArmXXX    50      99.99%          7               0.56
  129.  
  130. The MIPS values are approximate, and the Arm700 one is for a prototype chip,
  131. not the production one. As you can see, the switcher is very optimised,
  132. achieving at worst a loss of 0.25%, and obviously the faster the processor
  133. the less the loss is.
  134.  
  135. Anyway, while all this is all well and good, there is a problem. As you can
  136. see, the multitasker can only handle a minimum of 1cs slices. Now, I don't
  137. know much about other architectures, but 1cs is an *awfully* long time, and
  138. it gives very little scope for multithreading as you only need ~25 processes
  139. running for cascade overlo