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