Subject: Re-org of console code

From: David Jones <[email-masked]>

> 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: [email-masked], finger for more info

---

From: [email-masked] (Markus Wild)

> code, perhaps along the lines of the Amiga software itself.  I forsee:

Just keep in mind that custom chips are not the only possible console
device, so anything that is not restricted to the custom chips (like
opening a display and letting the user scribble into it) should be

> - /dev/audio

That one is ok, should be split from the custom chips console.

> 	 blits, which do not go through the device driver.

Nope, define primitives that would be performed by the blitter on the
cc console, and provide generic ioctl's for the console. Other boards
want to profit from builtin gfx hardware too, if possible.

> 	 into their address spaces.

Basically possible with /dev/mem already, but I strongly discourage
its use, it's inherently custom choip specific.

> 	 processes bang the HW directly.

As a generic resolution-setting ioctl, yep. As a "lores/lace" or
"superhires/nolace/2plane" ioctl no. Do it generic, I don't want the
same problem with lacking RTG we have in AmigaDOS with BSD as well.

> - a floppy driver might want to use the blitter.

Yep, so the kernel should provide a blitter scheduler. 

> 	 the memory in and /dev/blit to render into it.

No, it will open /dev/grfX, put it into grafics mode with ioctl GRAFON,
map it into user space with mmap to get a framebuffer and register area
there. Blits are done with ioctls, if possible.

> of the code would be "high level".

I agree totally. Just thinking of a different "hilevel" layer.

-Markus
-- 
CHUUG/EUnet Switzerland				Markus Wild
Zweierstrasse 35	Tel: +41 1 291 45 80	[email-masked]
CH-8004 Zuerich		Fax: +41 1 291 46 42	S=mw;P=EUnet;A=EUnet;C=CH

---

From: David Jones <[email-masked]>

> Don't forget that netbsd code must run on all netbsd (pc, sun, ...)
> And don't forget that X-Window must run under graphic cards.
> (this is done by the graphic driver grf0 (custom chips) grf1 (retina card)
> )

Already we have system-specific software.

Look at XFree86.  It supports seven or so video cards.  Support that was not
abstracted out in the kernel.  I see no problem with the Amiga X server
having INTERNAL support for a number of video device drivers, including
custom chip/blitter and Retina.

Also, why shouldn't there be ANY Amiga-specific system calls available to
users?  Generic NetBSD software will still run, but there can be Amiga-specific
stuff too (such as X servers).

---

From: Harald Backert <[email-masked]>

>Look at XFree86.  It supports seven or so video cards.

This reminds me of a question, I always wanted to ask: Where can I get the
source of XFree86?  I already found then libs.  While that's ok for PC-users,
it is quite useless for us Amigans.

Bye, Harald
--
email: [email-masked]

---

From: [email-masked] (Robert Leland - PSI)

> it is quite useless for us Amigans.
The newest -full- release as XFree86-1.2.
Try:
      ftp.physics.su.oz.au (under /XFree86)
      ftp.win.tue.nl (under /pub/XFree86)

Then there is a XFree86-1.3.diff.gz which was only released as a patch
upgrade to the XFree86-1.2.

---

From: [email-masked] (Markus Wild)

> I would like to let everyone know that I am very close to finishing stage one of
> my retargetable graphics device for netbsd-amiga.

First: thanks alot for the big amount of time you're investing, sounds very
promising!

> after stage one, only one console device need to be written and it will work on
> all display cards (or chips) that have there module included in stage one.

I didn't get this fully from your article, do you plan to use your driver(s)
primarily for a console driver, or as well (in gfx mode) as base for an X11
server?

The problem I see in the later case is efficiency on the RWindows level. Upto
views, there are no problems, and your model (although much nicer structured
than my code) comes to a similar result than when implementing "modes" for
the current cc-handler, just as I already did for the Retina.

The problem with the RWindow approach is that you really DONT want to 
have a SetPixel operation be in a kernel driver, requiring a system call
for every invocation. Your X-server would creep...

> /* util functions */
> get_view;		/* get view this rwindow belongs to. */
> free_rwindow;
> set_pen;		/* set the the pens. */
> get_pen;
> set_mask;		/* set the draw mask */
> get_mask;
> 
> /* raster operation functions */
> write_pixel;		/* write a pixel. */
> write_pixel8;		/* write 0-8 pixels. */
> read_pixel;		/* read a pixel. */
> read_pixel8;		/* read 0-8 pixels. */

These should really not be inside the kernel, system calls are not like
under amigados mere subroutine invocations, they're done with TRAP and
cause quite a bit of overhead...

> .. need to add a bunch more, also these are good canidites for defaults,
> i.e. /dev/grf will use some basic (perhaps read/write_pixel8()) to implement
> any missing rwindow operation functions.

You have to provide some mmap interface to map the framebuffer,
I think that's the only viable solution...

> I will begin work on an X port that will sit on top of this device.
> ANYONE DOING THIS NOW PLEASE CONTACT ME.

Lets talk about this some more :-)

> I started working on new install documentation in texinfo format, it has been
> put aside.  I also wrote much better and safer devtofile/filetodev programs
> they are currently on wuarchive in the bsd directory called 'device-streams.tar.gz'.
> These utils understand RDB's and do lots of sanity checks (not to mention make
> things alot easier.)

Rah, I want more space on ftp.eunet.ch, will have to kick some linux stuff out ;-)

> I began writing a unix binary library that supported general access into binaries.
> this may get worked on some more.

Something similar as nlist() and/or the kvm.c functions?

> I wrote some very nice custom chip code that now resides in my kernel, this includes
> a chipmem heap, audio support, vbl server support, etc... I really need to get this
> to mtk for inclusion. (I modified the current ite and grf to use this stuff.)

Wanna have :-)

-Markus