home *** CD-ROM | disk | FTP | other *** search
/ Enigma Amiga Life 113 / EnigmaAmiga113CD.iso / software / utilities / viewer / source / prg-shouldread next >
Encoding:
Text File  |  1999-11-28  |  11.8 KB  |  269 lines
  1. o General:
  2.  
  3. The   source-code  of  "Viewer4.4"  is  not  public  domain  software.  It's
  4. freeware.  I,  as  the  author of the source-code, will allow you to improve
  5. this  source-code  so long you don't remove MY copyright notice. If you have
  6. got  improved  "Viewer's"  source-code,  you  have  to  place  that modified
  7. source-code and the object-file of it into the pd-pool - also as freeware!
  8.  
  9. The  object-file of "Viewer4.4" may be enclosed to a commercial product - as
  10. a  text  or ILBM-viewer. The source-code of "Viewer4.4" may be also enclosed
  11. to  any  assembler  package  as  an example, so long the copyright notice is
  12. unmodified.  You,  as  an commercial dealer, or as a programmer of the above
  13. mentioned  package,  is  it allowed to modify the source-code of "Viewer4.4"
  14. so  that  it  can  be assembled with your assembler - although I didn't used
  15. any   specific   advantage   of   the  "HiSoft  Devpac  Amiga  3"  assembler
  16. (preassembled include-files are a standard).
  17.  
  18. Needless  to  say that I can't be held for any errors, lost of data, lost of
  19. profit or anything else may happen using "Viewer" as object- or source-file.
  20.  
  21.  
  22. o Known bugs:
  23.  
  24. At  the  moment  I  don't  know  about  any bug which will cause "Viewer" to
  25. crash.  In fact, "Viewer" didn't crash my "A2000-B, ks 1.2, 68000 CPU, 512kB
  26. chip,  2  MB  ranger  RAM",  "A500, ks 1.3, 68000 CPU, 1 MB chip, 1MB ranger
  27. RAM", nor my "A4000-D, ks 3.0, 68040 CPU, 2MB chip, 16MB fast".
  28.  
  29. "Viewer4.4"  was  successfully  tested  with  "SegTrecker",  "Enforcer"  and
  30. ""Mungwall".
  31.  
  32. Remainder:
  33. If  you  want  to  improve  "Viewer", test that modified file with the above
  34. named programs.
  35.  
  36. A hint:
  37. An addressing mode like:
  38.     movea.l    _What(Ax),Ax
  39.     cmpa.l    0.w,Ax
  40.     beq    _There
  41.     ....
  42.  
  43. will  cause  an  Enforcer-hit  - because it compares really the value of the
  44. address, here: contents of address zero.
  45. Although
  46.  
  47.     cmpa.l    #0,Ax
  48.  
  49. is  allowed  (no  Enforcer hit), don't use it. Some assemblers optimise this
  50. code to
  51.  
  52.     cmpa.l    0.w,Ax
  53.  
  54. which  isn't  allowed  -  so for your and my sake change the above to:
  55.  
  56.     tst.l    _What(Ax)
  57.     beq _There
  58.     movea.l _What(Ax),Ax
  59.     ....
  60.  
  61. Shown bugs:
  62. Under  ks  1.2  (v33)  to  beta  ks 2.0 (v36) the border of the screen shows
  63. blank  and  not  the  picture's border. This is a bug in those kick-starts -
  64. the ignored flag: "SCREENQUIET" ( - don't display screen's title bar).
  65.  
  66. Fonts taller than 15*10 are trashing the "Auto-Requester" window or leave it.
  67.  
  68. X-  and  Y-  aspect  not  really  set  when running above of ks 1.3. You can
  69. improve that on your own.
  70.  
  71.  
  72. o What is not implemented and what will never be done through me:
  73.  
  74. I  will  not  support  IFF-anim-x  formats  because  they  are too slow when
  75. running high-resolutions and a lot of colours, e.g. 768*580 and 256 colours.
  76.  
  77. Also 24-bit images dithering to 5/6/8 bit planes I will not support.
  78.  
  79. AAA  (RTG)  resolutions - (if the Amiga is staying alive) - for such a small
  80. program  like  "Viewer" it's too much to look forward to AAA resolutions and
  81. the RTG-standard.
  82.  
  83. 3rd  party  graphic  devices  are  not  supported  directly; my speculations
  84. depend  on  the  fact that a bitmap, which isn't a standard Amiga bitmap, is
  85. created  through  an  alien  software  package and thus a graphic, layer and
  86. intuition  emulation  is  running.  Since  all 3rd party graphic devices are
  87. originally  from  the  IBM  compatible  PC  I  guess  that it cannot support
  88. Overscan  and other AMIGA specific stuff. This means also that no 8 bits per
  89. gun  colour  palette  is  in  screens available, which are not 24 bits deep.
  90. "Viewer"  will  actually not care about this fact, which result in incorrect
  91. colours  on  that device since LoadRGB32() will not correct this on its own.
  92. The  next  problem  is  that  the  Amiga  OS cannot handle 24 neither 16-bit
  93. bitmaps.  This means that although "Viewer" will allocate a temporary bitmap
  94. with  24  bit planes, the higher 16 bit planes cannot be copied (blitted) to
  95. the  visible  24  bit screen which was created through the graphic emulation
  96. since  the  Amiga  OS functions (used by "Viewer") take only the first 8 bit
  97. planes into account.
  98. Currently  a  well-made  graphic  emulation  is  not available for the AMIGA
  99. although  "CystGraph"  will  allow "Viewer" to display images on its screens
  100. (with a few limits).
  101. It's  not  possible to display super-bitmap screens on a "VanGogh96" display
  102. although  the screen is taller than the displayable part (unsupported change
  103. of View^dx and View^dy).
  104. Any  3rd  party  software  package to emulate the Amiga OS graphic functions
  105. should   now   work,   but  only  if  the  monitor(s)  are  adapted  by  the
  106. system-functions.
  107.  
  108.  
  109. ASL-file-requester  -  no  directory  caching and - directories are shown at
  110. the bottom - thus I do not support it.
  111.  
  112.  
  113. o Talking about the source:
  114.  
  115. - Take  a  look  at  the  routine "_StrToLong" and you know that all numbers
  116.   that  are  converted (string to number) can be over given in decimal, dual
  117.   or hexadecimal - e.g. tool types. 
  118. - The  complete  binary  code  of  "Viewer3.B"  can  be  holding resident in
  119.   memory.  If  you  are  going  to  improve  "Viewer"  try  and write it for
  120.   resident use, too.
  121.  
  122.  
  123. -- Problems of current kickstarts (including 3.1):
  124.  
  125. - Console device.
  126. The  console-device output is so slow that it makes no difference if you are
  127. calling  it from assembler or from ARexx! I hope that we get in the future a
  128. faster   console   output,   otherwise   I   write   my   own   (problem  of
  129. Layers/Gfx-library).  You  can increase output's speed when you decrease the
  130. number  of  bit  planes  of the screen "Viewer" appears on to 1. If you know
  131. think  that  you  only have to change RastPort's rp_Mask to %00000001 (1 bit
  132. plane),  you'll  get  the wonder, output is not sped up, instead it flickers
  133. only  harder (tested only in PAL-mode). If coloured texts are printed out to
  134. the  console-window,  the  output speed is decreased again, approximately by
  135. 300%.  The  thing  that  helps  in  this  case is only to reset the complete
  136. console-window - press therefore the "R"-key.
  137.  
  138. The  routine  to  enter  the search string has been stripped. It now doesn't
  139. support  cursor moving anymore. This is mainly because the code grew by this
  140. about  1.2  KB,  -  for  a  simple  line editing routine!! With the original
  141. routine  Viewer  was  more  a  text-editor than a viewer! The reason why the
  142. routine  was  so  tall is because it fully supported tabs, which is a little
  143. difficult to handle.
  144.  
  145. - Bug in v39 of dos-library.
  146. When  a  read/write  error  occurred  and the Read/Write routines of the dos
  147. returned  to  the  program-code,  the  base register A6 didn't contained the
  148. DOSBase any more - this bombed my A4000 a lot times! - Example:
  149.  
  150.     movea.l    _DOSBase,A6
  151.     jsr    _LVORead(A6)
  152.     tst.l    D0
  153.     bmi    Error
  154.     ....
  155. Error
  156.     jsr    _LVOIoErr(A6)    ; Amiga bombed! -
  157.  
  158. because A6 doesn't contains the pointer to the DOSBase!
  159.  
  160. - Intuition gadgets.
  161. I  would  have  used  a normal intuition gadget with a border around it when
  162. there  wasn't  a  bug  in  the  Intuition-  library: although you can change
  163. RastPort's  rp_Mask  to  3  (2  bit  planes)  before adding and displaying a
  164. gadget,  all  bit planes are used by intuition to draw the gadget - when now
  165. the  screen  has  8 colours (3 bit planes) and the GADGHCOMP-flag is set for
  166. the  gadget, the selected gadget looks ugly - the only things which helps is
  167. to  draw  gadgets  with  the  GadTools-library  -  but...  GadTools  is  not
  168. available on ks 1.2 neither on 1.3 so I made it via images.
  169.  
  170. - Message handling is not what it should be...
  171. Although  you  can tell intuition to stop sending messages to a message port
  172. (PA_IGNORE),  it  will  ignore  (like  the flag tells) our wish. The message
  173. that has reached us got other in its back that will also be sent to us.
  174. Commodore  has  made  a  C-subroutine  (see CloseWindowSafely) to ignore all
  175. soon  coming  messages  -  I  didn't implement this in "Viewer" because each
  176. times  this  routine is called and ignores messages, the system will lose 40
  177. bytes of memory.
  178. I did it via GetMsg() and ReplyMsg() - the same effect but no lost of memory.
  179.  
  180. - FreeMem().
  181. If  you  allocate  memory  with  a  size which is not divisible by eight (8)
  182. AllocMem()  will round it up to a size of eight (maximal plus 7 bytes). When
  183. now  FreeMem()  is called the over given size is de-allocated - means it may
  184. happen  that  you  lose  maximal  7 bytes of memory - and that each time you
  185. call  FreeMem().  It seems that allocating & freeing memory of FAST-RAM type
  186. works correctly - but not with chip-ram!!!!
  187. What  occurs  when  this  happens  should  be  known  by  everybody - memory
  188. fragmentation through memory corps!
  189. To  avoid  this,  aligned  each  size which should be allocated to eight and
  190. when this memory block should be freed, align the size again, example:
  191.  
  192.     move.l    _FileSize,D0
  193.     move.l    #MEMF_CLEAR,D1
  194.     addq.l    #7,D0
  195.     andi.l    #-8,D0
  196.     movea.l    _SysBase,A6
  197.     jsr    _LVOAllocMem(A6)
  198.     move.l    D0,_FileAddress
  199.     beq    Error
  200.     .....
  201.     movea.l    _FileAddress,A1
  202.     move.l    _FileSize,D0
  203.     addq.l    #7,D0
  204.     andi.l    #-8,D0
  205.     movea.l    _SysBase,A6
  206.     jsr    _LVOFreeMem(A6)
  207.  
  208. - Direct hardware access.
  209. The  picture  viewer of "Viewer" makes directly use of the hardware, but not
  210. for  displaying  the  picture,  instead of it for checking if a mouse button
  211. (right  or left) is pressed or released. This can cause trouble under future
  212. (if there will be a future for the Amiga) versions of the custom-chip set.
  213. The  routine  which checks if a printer is turned on or off is also hardware
  214. coded, it works only well with "Epson" printers.
  215.  
  216. - PowerPacker-library.
  217. Through  PowerPacker-library  packed  files  are  supported,  but  I  (will)
  218. remove(d)    the    de-crunch-code    and    replace(d)    it    through   a
  219. PowerPacker-library call.
  220.  
  221. - ILBM-files.
  222. Because  it's  close  to  impossible  to  detect  if  a  colour-map ("CMAP")
  223. contains  colours  of 8-bits wide, the highest bit of BMHD->pad1 is set when
  224. the  colour-map  entries  are  valid  8-bits  (newer programs set this bit),
  225. otherwise  this bit is cleared. "Viewer" looks for this bit. When it is set,
  226. the  colours  are taken as 8-bit values for LoadRGB32() otherwise out of the
  227. high-nibble  of  each colour (upper four bits) the 8-bit value is computed -
  228. if  the picture does not contain more than 32 colours - else I guess that it
  229. contains the right palette order but didn't set the BMAP->pad1 bit.
  230.  
  231. - ASCII extraction
  232. _ANY_  IFF-file  that  contains  the  CHRS-chunk  can  be  used as input for
  233. _LoadFCFile().  You  have  only  to  insert  a  line  in  _CheckFile() which
  234. compares  the  type  of  the  file (currently only SWRT#### and FTXT#### are
  235. supported).
  236.  
  237. - AUTO-requester
  238. The  auto-requester  can be easily extended (modified) for OS2.0 and up when
  239. using  OS  built  in function: Intuition's EasyRequestArgs() - although this
  240. routine  has  got  a  bug: If the font used for the Requester is too tall to
  241. display  it  doesn't  use  an  other,  it  will always use the one currently
  242. installed  for  the screen. This may result in non-click able gadgets and in
  243. non-readable messages. Same problem with ReqTools.library functions....
  244.  
  245. - CODE optimisations
  246. ViewerV4.4  has  not been optimised in any case. After I got the idea it was
  247. immediately written down. Thus there is enough room to do it.
  248. Some  general:  If  you  study the execution time of a command such as "DBF"
  249. (DBRA)  and  you write your own cycle-peeker you'll get strange results. Did
  250. you  know  that  a bloody boring "subq.w #1,Dx bcc.s "LABEL"" is much faster
  251. than a "DBF Dx,"LABEL"" (MC68040)?
  252. So,  trial  (and  error)  can  result  in much faster programs than studying
  253. execution times :-(
  254.  
  255. - Dirty code
  256. Some  parts of the source code I wrote are in a badly written code-style. My
  257. excuses  at  this  point. Some functions / implementations were written late
  258. at  night.  With  half  open eyes it's hard to follow the guidelines... Also
  259. much  code  has  been written after riding my motorbike at its and my limit.
  260. Because of this I lost during typing the pleasure for a clean source-code.
  261.  
  262.  
  263.  
  264.  
  265.            Jörg van de Loo
  266.            Hövel 15
  267.            47559 Kranenburg
  268.            Germany
  269.