home *** CD-ROM | disk | FTP | other *** search
/ Amiga GigaPD 3 / Amiga_GigaPD_v3_3of3.iso / netbsd / docs / mailinglist-archive / 1993-11 / text0124.txt < prev    next >
Encoding:
Text File  |  1993-06-25  |  4.8 KB  |  112 lines

  1. I am posting this to let people know that the new graphics stuff is
  2. done (well in beta now).  I send the patches to Markus, and I imagine
  3. that he will make them available when he is able.
  4.  
  5. For the time being here is my some info I send as a README to Markus, with
  6. some extra notes added.
  7.  
  8.  *** *** ***
  9.  
  10. | Ok first let me say that this is just a beta.  There are known cosmetic
  11. | (small) bugs with some of the code.  I felt it was necsesary to get
  12. | this stuff into the public ASAP.  For instance the X window people
  13. | really need to be using the new graphics system.  I am very concerned
  14. | that they have spent alot of time on code they will be re-writing now.
  15. | I asked them to drop me a note but no one replied.
  16. |
  17. | Anyway, there are few patches to the main amiga source tree all of 
  18. | which were nec. and proper.  Note however that I made a patch to
  19. | the main sources, sys/sys/ioctl.h had a bug (IOCBASECMD(x) was incorrect.)
  20. | my code depends on this being [ed: viewioctl.h] right so I included my change.
  21. |
  22. [ed: programing notes deleted]
  23. |
  24. | This release is a major update in the area of graphics.  All parts 
  25. | are not fully done yet but they work and work solidly.  The interface
  26. | (grf) for monitors can be considered frozen (we may add cosmetics 
  27. | later but nothing funcitonal.)  So that people wishing to write 
  28. | monitor code can do so now.  
  29. |
  30. | If you are going to write a monitor you can use my code as an example
  31. | it may get complex and overwhelming though because of the complexity
  32. | of supporting the custom chips.  So you may want to start of only 
  33. | with the grf_* stuff and then consult the grf_cc stuff when needed.
  34. |
  35. | In the area of the ite.  I have consolidated all the monitor dependent
  36. | files into a single ite_std.c file.  This was possible due to the 
  37. | new view device (more on that in a little bit)  The ite now has 
  38. | support for _underline_ and BOLD attributes as well as continuing 
  39. | support of inverse as before.  Becuase of these additions the font
  40. | programs need to be updated (I added the code in fontdumper and
  41. | changed the kernel_font.c.distrib to get you started.)  The only
  42. | thing that gets added is kernel_font_(baseline|boldsmear) attributes.
  43. |
  44. | All known ite scrolling bugs and repeating bugs are fixed in this version.
  45. | (actually there is one, but I need to get this out.)
  46.  
  47. It has to do with a new IOCTL to change the size of the ite
  48. at run-time, when done the process group owning the tty that uses this
  49. ite is not signaled.  So if you change the size of the ite with sya
  50. emacs running it doesn't know about the change.  Not a big deal for the
  51. time being.
  52.  
  53. | The new ``/dev/view??'' are the character devices that replace the
  54. | old ``/dev/grf''.  These new psuedo-devices represent a single monitor
  55. | screen.  They go through the new grf interface in a portable way.
  56. | All programs will interface graphics on Amiga-BSD through these devices.
  57. | (ite does)
  58. | I will shortly (a day or two) be releasing some example code on how
  59.  
  60. I will post a day after markus post I mean.
  61.  
  62. | to program with the view?? devices.  For now let me give you an
  63. | example on how to map the bitmap data into your process with the
  64. | view device.
  65. | bitplane_data = mmap (0, size, PROT_READ|PROT_WRITE, MAP_FILE, fdesc, 0);
  66. |
  67. | ``size'' is the number of bytes of bitmap data to map. ``fdesc'' is the
  68. | file descriptor returned from open().
  69. |
  70. | There are some major bugs with mmap()'ing the 709 grf device.  The largest
  71. | being the allowing of processes to quickly vm_fault the kernel. (one access).
  72. | These are gone now.
  73. |
  74. | Support for the custom hardware is now in the kernel, things such as a 
  75. | ``/dev/audio'' will probably be written.  Its easy now.  Any way, the ite
  76. | bell now goes through this interface.
  77. |
  78. | Some missing stuff: mouse pointer.  sorry sprites are not retargetable* 
  79. | X windows is however and when that is done you will get your pointer 
  80. | back (exactly what was it doing there anyway?)
  81. |
  82. | A screen blanker.  This is a very easy one I hope to have installed
  83. | into the system in a upcoming patch (maybe 20 lines of code needed)
  84. | Again I need to get this out now so it was skipped.
  85. |
  86. | I hope everyone enjoys the new code features.  Now i can try and get 
  87. | emacs working...
  88. | Chris...
  89. | (this was written after a 20 hour stint to try and finalize stuff please
  90. | forgive mispellings and improper grammar.  thanks)
  91. | --
  92. | (* spites could be but I didn't make them.)
  93.  
  94. While I am waiting for the new kernel I am working on a port
  95. of GNU binutils and Gas2.2 (the newest)  I hope to send the
  96. patches to Cygnus for inclusion.  I have them compiled but
  97. I still need to run them through the testsuite.  Then I will get
  98. started on gdb.  I need the new kernel before I can add stuff there 
  99. though so this may have to wait.
  100.  
  101. Anyway I am still using vi so if anyone has emacs working on an
  102. Amiga2000 with 8Megs of memory they might want to tell me how to
  103. get it to quit SIGSEGV'ing. :^)
  104.  
  105. Chris.
  106.  
  107.  
  108.