home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / amiga / programm / 18044 < prev    next >
Encoding:
Internet Message Format  |  1993-01-02  |  2.5 KB
  1. Path: sparky!uunet!gatech!nscf!lakes!rock
  2. From: rock@lakes.trenton.sc.us (Rockerboy)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Going to the metal
  5. Message-ID: <RwqqwB5w165w@lakes.trenton.sc.us>
  6. Date: Sat, 02 Jan 93 03:32:26 EST
  7. References: <lk1di9INNrsa@exodus.Eng.Sun.COM>
  8. Reply-To: rock@lakes.trenton.sc.us (Rockerboy)
  9. Organization: Lakes Public Access
  10. Lines: 39
  11.  
  12. cmcmanis@pepper.Eng.Sun.COM (Chuck McManis) writes:
  13.  
  14. > The problem, presented in these terms, is much more simply stated:
  15. >   "The O/S model embodied in the Amiga is too complex and thus
  16. >    unsuitable for the development of short lifetime, real time
  17. >    applications."
  18.  
  19. I am in complete agreement on this point.  I have, in fact, mentioned it 
  20. several times.  (That is, that from a game perspective, coimptability is 
  21. not so terribly important...)
  22.  
  23. > One solution to this problem might be to provide an Operating system
  24. > model that is tuned to game writers. Clearly such an O/S would have
  25. > the appearance of writing directly to the hardware, however that
  26. > hardware could be suitably masked behind the OS. A really good example
  27. > of how one might accomplish this is the "virtual" 8086 mode of the
  28. > '386 and '486. Here a hardware page fault mechanism is used to "catch"
  29. > writes to the things that are hardware registers on the original
  30. > PC, and do something "useful" with them based on the actual hardware
  31. > of the system. Certainly something like that could be done on any
  32. > Amiga with a MMU, but it could also be done using the existing messaging
  33. > system. Imagine if you will a "spec" that says that address X contains
  34. > the X position of the mouse, Y contains the Y position, and Z contains
  35. > the state of the buttons. Further, J contains the bits associated with
  36. > joysticks 1 and 2 in the upper and lower 4 bits and at address I
  37. > is the bits for the display plane 0, I+n plane 1, etc. Now using this
  38. > virtual machine is just as easy as using the actual hardware, except
  39. > that now, the changes in the O/S are "invisible" to games that use
  40. > them.
  41.  
  42. I think this is a great idea, and an acceptable one at that.  Perhaps a 
  43. library of sorts, a hardware.library?  In fact, I suspect it would prove 
  44. itself nicely. Programmers might even release 'custom' versions, etc., as 
  45. we have seen with other libraries.  Then the only issue one would see 
  46. would be whther or not people were using the 'official' library.  It 
  47. would be patently obvious why programs crashed if the user were running 
  48. the 'elite7hardware.library'.  ;)
  49.  
  50. And with any luck, the library would not be written in C...
  51.