home *** CD-ROM | disk | FTP | other *** search
/ ARM Club 3 / TheARMClub_PDCD3.iso / hensa / misc / tornado / t2demo011a1 / History < prev    next >
Text File  |  1996-12-17  |  6KB  |  154 lines

  1. History of the Tornado II Support Module:
  2. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  3.  
  4. 17-12-1996:
  5. -=-=-=-=-=-
  6. And then it hits me!!!! It may well be 3am, but I know what it is!!!
  7.  
  8. Tornado_RedrawWindow turns off preemption. But it doesn't really - it only
  9. turned off the *interrupt* routine - so if there the polling code had
  10. /already/ been requested by the interrupt routine and was pending - it would
  11. execute during the redraw loop, right where it mustn't.
  12.  
  13. Thus the error was randomish. The worst kind.
  14.  
  15. I hate these kinds of bugs.
  16.  
  17. Now it tests the semaphore in the actual polling code instead. I hate easy
  18. fixes to horrible bugs.
  19.  
  20. Changed the polling code so that if it's locked it sets a flag to tell
  21. Tornado_GetRectangle to restart preemption once it's finished. It's more
  22. efficient than interrupting every 1ms to see if the redraw's done yet.
  23.  
  24. Fixed a small potential bug in that should an app die during a redraw it will
  25. take the support module with it as preemption is still locked out and this is
  26. a global semaphore. Now it checks on app death to see if the semaphore is
  27. set, and if it is it unsets it. Should be enough as the context consistancy
  28. is maintained AFAICS.
  29.  
  30. Fixed another bug introduced by RO3 - apparently it doesn't like the
  31. environment handlers getting changed unless it changed them. This BTW breaks
  32. the RO2 API *again* in which you always set up your handler before using it -
  33. never relying on it being set to anything from previous settings as anything
  34. else might have changed it.
  35.  
  36. Obviously some twat at Acorn didn't think of this possibility ... anyway, the
  37. module now restores the callback handler state after it's finished with that
  38. handler.
  39.  
  40. Some odd bug still remains which causes preemption to halt and everything to
  41. hang. I'm dammed if I know what it is though, but it's rare enough to make
  42. myself feel okay in releasing it.
  43.  
  44. 16-12-1996:
  45. -=-=-=-=-=-
  46. Spent the day trying to figure out this damn GetRectangle bug ...
  47.  
  48. 15-12-1996:
  49. -=-=-=-=-=-
  50. Added error handling to the demo app.
  51.  
  52. Fixed a bug in the memory routines that was causing RMA usage mode to die.
  53.  
  54. Seems this GetRectangle bug is random. I have a window running here for the
  55. past ten minutes okay yet the one before it died after only a few seconds.
  56. Odd.
  57.  
  58. 14-12-1996:
  59. -=-=-=-=-=-
  60. Thought it was a bug on SprOp 52 but actually it was my preemptor code not
  61. exiting from the interrupt properly when a lock had been placed on
  62. preemption. Twat I am ...
  63.  
  64. Now everything works! At 6.52pm today I am proud to announce the first fully
  65. functional preempted RO multitasking application ever to run on the Acorn
  66. series!
  67.  
  68. Ooar - doesn't seem to work quite so well! Somehow for odd reasons crashes
  69. and dies with "Wimp_GetRectangle not called correctly". Odd.
  70.  
  71. Also the whole thing doesn't work on RO2. :( I think it's because RMA usage
  72. doesn't work too great!
  73.  
  74. 13-12-1996:
  75. -=-=-=-=-=-
  76. Yet another bug in RO has had me for a day now ...
  77.  
  78. This bug is in sprite area initialisation - when you initialise it with bits
  79. 8 and 9 clear it utterly bollocks the sprite area (not that any of the sprite
  80. routines notice of course but just blindly lock up the machine in a random
  81. nature). This one *definately* worked on RO2 ...
  82.  
  83. 12-12-1996:
  84. -=-=-=-=-=-
  85. This bug has had me for four days now ...
  86.  
  87. Found it! Subroutines like .getblk and .execathread as called from .callwimppoll
  88. use R13 which is a temporary variable in .callwimppoll!!!!
  89.  
  90. It was using the fp register dump as a stack for a while and other areas too.
  91. Nasty!
  92.  
  93. Added vdu redirection dumping. Redirection into mask calls not trapped yet
  94. though.
  95.  
  96. Bug found in RO! RO2 uses &2e,60,0,0,1 to return to screen - RO3.5 hangs on
  97. this. Needs &2e,512+60,0,0,1 apparently (twats at Acorn ...). This BTW yet
  98. again breaks API's *written* *in* *stone* in the RO2 PRM's but the twats just
  99. don't care ... :(
  100.  
  101. Added error handling throughout the module. It now traps all possible problems
  102. and sends them somewhere - when it can (it can't always). It also doesn't
  103. necessarily send them to a nice place - the current application's error
  104. handler is one such example ... ;)
  105.  
  106. Added facilities for a client application to handle errors occurring in the
  107. tornado preemptor routine and fix the problem where necessary
  108.  
  109. 08-12-1996:
  110. -=-=-=-=-=-
  111. Now is version 0.11alpha.
  112.  
  113. Added a trap to shut down the task as a preempted one should it die
  114. unnaturally.
  115.  
  116. Added check in module finalise for whether tasks are still using it.
  117.  
  118. Added check to Tornado_Initialise to stop it running more than 32 processes
  119.  
  120. Added memory freeing on call Tornado_Closedown - memory leakage now doesn't
  121. happen anymore
  122.  
  123. Added stacking and restoral of FP registers over Wimp_Poll - checks first to
  124. see whether the FPEmulator can handle multiloads and stores and uses them if
  125. it can.
  126.  
  127. 07-12-1996 (v0.10alpha release):
  128. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  129. Found the bug sticking me for a long time (since last night): R12 was getting
  130. corrupted by the APCS veneer for the 17,18 and 19 handler and then everything
  131. was accessing the wrong workspace!
  132.  
  133. Uploaded the first version of the support module (0.10alpha) to hensa and
  134. mailed it to a few friends.
  135.  
  136. 06-12-1996:
  137. -=-=-=-=-=-
  138. Ran through the code - found myself using SVC reliant code where I was in USR
  139. mode. Fixed it and it works (10.25pm)! (this also has the advantage as the
  140. SVC reliant code causes that bug in the SA so this is no longer a problem).
  141.  
  142. Added Wimp_Poll returns storage and Tornado_Poll to retrieve it all.
  143. Implemented support for 17,18 & 19 codes handler. Won't work though ... :(
  144.  
  145. 30-11-1996:
  146. -=-=-=-=-=-
  147. Cobbled together some old tornado I code and rewrote it for this new
  148. non-tornado context. Wrotes skeleton API's.
  149.  
  150. Awful skeleton module created but then refused to work. Realised 68000
  151. programming was the cause and fixed the problems. Never tested it though.
  152.  
  153. Then went back to Trinity for the last week of term ...
  154.