home *** CD-ROM | disk | FTP | other *** search
/ The Datafile PD-CD 5 / DATAFILE_PDCD5.iso / utilities / t / tornado / QandA / Paul2 < prev    next >
Encoding:
Internet Message Format  |  1995-07-14  |  6.5 KB
  1. From: Paul Corke <csc060@cent1.lancs.ac.uk>
  2. Message-Id: <3704.9506301324@cent1.lancs.ac.uk>
  3. Received: by cent1.lancs.ac.uk; Fri, 30 Jun 95 14:24:49 +0100
  4. Subject: Do you get these subject lines?
  5. To: ndouglas@digibank.demon.co.uk
  6. Date: Fri, 30 Jun 1995 14:24:48 +0100 (BST)
  7. X-Mailer: ELM [version 2.4 PL22]
  8. Mime-Version: 1.0
  9. Content-Type: text/plain; charset=US-ASCII
  10. Content-Transfer-Encoding: 7bit
  11. Content-Length: 6242      
  12.  
  13. Hello again,
  14.  
  15. > [millisecond timer]
  16. > Emm, it's not hugely important as I was merely thinking it'd be nice if
  17.  
  18. The timer I've got doesn't actually work on a RiscPC - attaches itself
  19. directly to hardware vectors so the installer need re-writing.  I'll look
  20. at the IOMD this weekend.
  21.  
  22. > preempted task has two problems: (a) its code must run for a minimum of 1cs,
  23.  
  24. Can't you mark tasks as `blocked'?  Then they wouldn't need to be switched in.
  25.  
  26. > Two points to this which makes it impractical: (a) Using OS_SetMemMap is
  27. > extremely quick, as it's only MEMC's internal pointers that are being
  28. altered,
  29.  
  30. If OS_SetMemMapEntries is so quick,  why do Acorn reccomend that applications
  31. for ROS3.50+ use dynamic areas,  and why does my desktop slow down when
  32. I have an app with a 4M wimpslot?
  33.  
  34. > [subtasks]
  35. >    What do you reckon?
  36.  
  37. Need to decide on a policy.  Execute at most once would seem logical - if
  38. there are any errors then assume that the subtask didn't do anything so
  39. perhaps start another subtask to try again.  This would mean that subtasks
  40. would have to work on temp files and not the actual files - if half a file
  41. is updated and an error occurs (Address exception at 0x12345, for example)
  42. then you won't have to wonder where to start processing from.
  43.  
  44. > On RO2, not doing anything about redraw is fine: the window is cleared.
  45. > Probably RO3+.
  46.  
  47. I tried this again to check it - unless you call Wimp_RedrawWindow and
  48. Wimp_GetRectangle you definately get another Event_Redraw and other
  49. apps don't get an event.
  50.  
  51. > See my problem with inefficiency? If you want to amalgamate all returned
  52. > rectangles while still allowing for the window to be resized, scroll offsets
  53.  
  54. I'll be looking at this over the next few days - I have an app which needs to
  55. pull chunks of data from CD,  convert from BMP format and use them to draw
  56. the screen.  There's a total of about 8Mb of sprites,  so I can't cache the
  57. lot.  This is a good candidate for background redraws,  so I'll let you have
  58. some of the code when it's done.
  59.  
  60. > Fraid subtasks are release II, next Christmas. I've written in to the brief
  61. > most of the protocols: I'll email it out to you when I can. Meanwhile, do
  62. you > want anything changed in the data structures etc? > 
  63.  
  64. > :-) _IF_ you had studied the heap data structure more carefully, you'd see
  65.  
  66. When I wrote most of my last letter I only had the first release - not Brief
  67. 0.01 so I didn't have the structure to read (only an introduction to the
  68. Tornado standard and a file called GBPB)...
  69.  
  70. > garbage is done. Anyway, the garbage can be optionally disabled, and even
  71. then
  72. > it would be pretty quick, being written in C and all.
  73.  
  74. Shurley assembler...
  75.  
  76. > :-). Hehe, I wasn't planning to overwrite the hardware vectors, but have
  77.  
  78. Pah! More fun that way!
  79.  
  80. > Tornado hook itself into the environment handlers. I think this works on the
  81. > RPC too? :-)
  82.  
  83. Yup.  OS_ChangeEnvironment is unchanged.
  84.  
  85. >    Also, any code written specifically for the RPC will use the 32bit mode
  86. > /all/ the time. Has to, as it's in the aims that Tornado code should be
  87.  
  88. Quoting the PRM (5-11):
  89.  
  90. PRM> The new generation of ARM chips used have two modes: 26 bit (which is
  91. PRM> backwards compatible with ARM2 and 3), and 32 bit.  RISC OS 3.5 only
  92. PRM> supports the 26 bit mode. *You must not execute code in 32 bit mode*.
  93. PRM> If you try to do so,  you may get unpredictable crashes, especially
  94. PRM> if you tru to run the code in address space over 64M
  95.  
  96. So it looks like 32 bit code is out.  Basically,  if you're in a 32 bit mode
  97. and an interrupt occurs,  the OS will return to you in a 26 bit mode.  This
  98. is likely to screw any uses of R15 and CPSR.
  99.  
  100. > IMHO it will be when using an internal bus, which is way way way faster than
  101. > any i/o interface or disc.
  102.  
  103. But the code has to be pulled off a disk into main memory.  I don't know
  104. if translation is done at load time or execute time.  There's a load of
  105. Taos stuff on http://www.acorn.co.uk/ - do you have w3 access?
  106.  
  107. > > - TFS
  108. > Works okay on RO3.1!
  109.  
  110. I'll have a lookie at it.
  111.  
  112. > This is *BLASTED* RO3+ for you! RO3 Fileswitch does lots of Func16 all the
  113. > time, even if they aren't supported (which according to my PRM's it doesn't
  114.  
  115. It doesn't do loads of Func16's.  It issues *one* when `Shutdown' is chosen
  116. from the task manager.  Func16 has nothing to do with wildcards...
  117.  
  118. >    The right is black, and blank, because it's meant to be! In reality,
  119. > Tornado would auto-shrink and extend if necessary and the appropriate bits
  120.  
  121. The heap looks something like this:
  122.  
  123.  +----------------------------------------------------------------------+
  124.  ||| ||| |||||| ||||    |     |     | |                                 |
  125.  +----------------------------------------------------------------------+
  126.  
  127. Okay,  so the small black bits on the left are your small free bits, but why
  128. are there some lines in the middle.  This is *after* garbage collection, btw.
  129. If you don't understand this I'll send you a UUcoded sprite.
  130.  
  131. > Sorry if I sounded a bit ratty above - I know you're busy, but TBH you
  132. > obviously haven't read all the docs very well.
  133.  
  134. As I said,  when I wrote most of that last mail I'd only had chance to read
  135. through the first archive.  I'd only glanced at the second.  What (and where)
  136. is LegoCad?  Do I have all the textfiles:
  137.  
  138. rel0:   GBPB, Info, Readme
  139. rel1:   Aims, Brief, Readme
  140.  
  141. I seem to have a file (GBPB) which refers to `guideline 5b' but no file which
  142. has guidelines 1..5a.  I've now had chance to look at the second archive
  143. properly (all the SWI / *com documentation) I should have a bit of a better
  144. idea what I'm on about!
  145.  
  146. > Let me know what you think? I'd like some input, and I'll be putting a
  147. message
  148. > onto fidonet asking for ideas.
  149.  
  150. Don't think you were too popular putting your message in c.s.a.hardware...
  151. .misc and .programmer seem logical,  but hardware?  Nothing personal,  but
  152. most denizens seem to be quite hostile towards messages in the wrong groups.
  153.  
  154. I'll get on with this background window redrawing now - let you know how it
  155. goes.
  156.  
  157. Paul.
  158. -- 
  159.  ____             _     ____           _        
  160. |  _ \ __ _ _   _| |   / ___|___  _ __| | _____ 
  161. | |_) / _` | | | | |  | |   / _ \| '__| |/ / _ \
  162. |  __/ (_| | |_| | |  | |__| (_) | |  |   <  __/
  163. |_|   \__,_|\__,_|_|   \____\___/|_|  |_|\_\___|
  164.  
  165.  
  166.  
  167.  
  168.  
  169.