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

  1. > I looked at the source for grf_cc it seems that a new device is needed
  2. > I am gathering my own thoughts on how to implement this but probably
  3. > more object oriented. ie.
  4. >  o blitting copper layer - call it `monitor'  this layer will handle
  5. >                            all the current view's low-level work.
  6. >                            and hopefully provide a standard interface
  7. >                            to screens.
  8. >  o screen layer - these would corispond to devices I think
  9. >                   similar to tty's and then we can all have
  10. >                   our friendly screens back. (front-back flipping)
  11. >  o console layer - console drivers could then be made to work with
  12. >                    the screen layers.  no more copper list swapping
  13. >                    of lines I think.  It sure is fast but inappropriate
  14. >                    when multiple display modes are going to be manipulated.
  15. > I think this approach will also help port other graphic applications
  16. > like X...
  17.  
  18. I think that the custom chip code needs much re-organization.
  19.  
  20. There are a number of visual glitches that I observe.  For example, do
  21. 'ls /usr/bin'.  Sometimes, part of a line of the output will not be
  22. tabbed over correctly.  Do the ls again and the problem goes away or
  23. appears somewhere else.  Also, the mouse blanker doesn't poke a zero in
  24. the SPRDAT register when it shuts off the DMA.  This leads to streaks.
  25. I think most of these problems stem from the code not beam-syncing.
  26. Is it dangerous to direct-poke an active copper list (change a copper
  27. instruction in the middle of its execution)?  Perhaps double-buffered copper
  28. lists are in order.
  29.  
  30. For the sake of new devices too, we need to restructure the custom chip
  31. code, perhaps along the lines of the Amiga software itself.  I forsee:
  32.  
  33. - /dev/audio
  34. - /dev/blit -- user-space blits, the kernel will bounds-check the blit and poke
  35.      the blitter.  User blits will be scheduled alongside kernel-initiated 
  36.      blits, which do not go through the device driver.
  37. - /dev/chipmem -- works like /dev/mem, except that it goes to chip memory.
  38.      There should be a way for user tasks to allocate chip RAM and mmap it
  39.      into their address spaces.
  40. - functionality to allow user processes to open low-level displays with
  41.      different effects.  Sort of like Eurodemos, but we can't let user
  42.      processes bang the HW directly.
  43. - a floppy driver might want to use the blitter.
  44. - X Server will use /dev/console to put up a display, /dev/chipmem to map
  45.      the memory in and /dev/blit to render into it.
  46. - there's nothing wrong with copper-based screen scrolling.  But it must
  47.      be co-ordinated with the rest of the system.
  48.  
  49. To reduce problems with interacting with the custom chips, I believe that
  50. direct access to the custom chips should be kept to a minimum.  The rest
  51. of the code would be "high level".
  52.  
  53. I am willing to assist in the undertaking of this re-organization.  The first
  54. step would be to specify precisely what we want to provide.
  55. -- 
  56. David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto
  57. email: dej@eecg.utoronto.ca, finger for more info
  58.  
  59.