home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / amiga / programm / 16044 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  3.4 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!iggy.GW.Vitalink.COM!cs.widener.edu!dsinc!ub!galileo.cc.rochester.edu!rochester!rit!isc-newsserver!eas3714
  2. From: eas3714@ultb.isc.rit.edu (E.A. Story)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: New hardware reference guide?
  5. Message-ID: <1992Nov18.180612.15191@ultb.isc.rit.edu>
  6. Date: 18 Nov 92 18:06:12 GMT
  7. References: <1950@lysator.liu.se> <1992Nov13.023341.27459@mpifr-bonn.mpg.de> <Bxnwno.6ns@cck.coventry.ac.uk>
  8. Sender: news@ultb.isc.rit.edu (USENET News System)
  9. Organization: Rochester Institute of Technology
  10. Lines: 67
  11. Originator: eas3714@ultb
  12. Nntp-Posting-Host: ultb-gw.isc.rit.edu
  13.  
  14. In csg019@cch.coventry.ac.uk (-~=Zaphod=~-) writes:
  15. >In nn.mpg.de> mlelstv@specklec.mpifr-bonn.mpg.de (Michael van Elst) writes:
  16. >
  17. >>This is hardly right. In most cases you will end with a program that
  18. >>a)runs on some machines only 
  19. >It would work on any amiga with the custom chips at location $DFF000.
  20.  
  21. Other considerations... Does the machine have $C0 Fast ram?  Or is it
  22. $20? Or perhaps it doesn't have FAST ram in the original 24-bit address
  23. space at all. (A3000, A4000).  The OS thinks about all these things, do
  24. demo (or for that matter, game) programmers?
  25.  
  26. >>b)crashes with a new OS version or when started from system that is 
  27. >>  booted further than the initial CLI.
  28. >It would not crash under new OS versions, because it would only use a few
  29. >bare essential routines like Forbid() and Permit().
  30.  
  31. Most just hit INTENA and DMACON, anyway.
  32.  
  33. >>c) does generate bogus displays on either NTSC or PAL systems.
  34. >Depends what you mean by bogus displays.
  35. >NTSC users would loose a portion of the screen due to the fact that the
  36. >NTSC screen can't display as many lines at a PAL screen.
  37.  
  38. Well, I know what *I* mean by bogus displays.  How about one that
  39. doesn't work at all...  And it's easy to fix... I think 90% of these
  40. "demo" programmers are guilty of it too.  How 'bout waiting on a
  41. scanline that doesn't exist?  I can't tell you how many of these "PAL
  42. only" programs work on an NTSC machine by changing just one byte in a
  43. test on DFF004/6 or in a copper list that generates an interrupt.  It's
  44. absolutely ridiculous.  I can live with lossing a portion of my
  45. display.. its gotta happen, but when it doesn't work at ALL, thats
  46. stupidity.
  47.  
  48. >Easy enough to avoid, just :
  49. >
  50. >1.. Write another version where the graphics are kept withing a smaller
  51. >area on the screen.
  52.  
  53. Ya, but of course, most of these programmers are too lazy to do so....
  54. otherwise "PAL only" wouldn't be so popular a phrase.
  55.  
  56. >2.. Write a just an NTSC version, so all the lucky PAL owners have a chunk
  57. >of screen missing (*not big OR clever CINEMAWARE*).
  58.  
  59. Or just center the NTSC size screen on a PAL display.  
  60.  
  61. >>d) risks hardware damage with things connected to the serial or parallel port.
  62. >How could it *dammage* hardware?
  63.  
  64. I can't wait for the first complaint from a A4000 or A1200 owner when
  65. one of these demos hits the wrong register and the display goes to 31Khz
  66. on their 1084... You don't think THAT could damage hardware?  
  67.  
  68. The point is that the serial and parallel ports shouldn't even be
  69. active, yet I've seen my modem lights flash during demos... most
  70. annoying.
  71.  
  72. >>Ah, yes.. that's my experience with the creations from "demo coders".
  73. >Are you sure?
  74.  
  75. tee hee hee.. 
  76.  
  77. -- 
  78. "THAT is a DRY turtle.  That turtle is NOT moist!"
  79. Ezra Story, a student at RIT, and
  80. eas3714@ultb.isc.rit.edu, his trusty(?) mailing address.
  81.