Subject: Re: toe in the water
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Darrin B. Jewell <jewell@mit.edu>
List: port-next68k
Date: 08/14/1999 16:23:15
der Mouse  <mouse@Rodents.Montreal.QC.CA> writes:
> - What is the state of SCSI support?  As of yesterday morning, -current
>    still had the SCSI stuff commented out in GENERIC, but on the other
>    hand I recently was told face-to-face that it now works (albeit by
>    someone not directly involved in the port as far as I know).  The
>    web pages seem to imply that progress has been made but that it's by
>    no means ready for prime time yet.

SCSI is not working.  1.4 shipped with the current hacked-up state of
the driver commented out in GENERIC.   If you turned it on, it would probe
the scsi chain successfully and even try to i/o operations, but transfers
were unreliable, and would result in dropped bytes.  This is where my meager
time goes when I get some to work on it, but we still have no documentation
on the dma chip or how it interacts with the ncr53c90a scsi device.  Last
week I shifted to trying to do dma to a single continuous bounce buffer,
and may eventually have a slow but working scsi driver with that approach.

If people are interested, perhaps I should begin a discussion here
that includes my understanding of the dma hardware.  Someone else
co-hacking on the dma driver and scsi support will hopefully keep the
effort from stalling on my slow progress.

> 
> - I built a kernel with WSEMUL_SUN instead of WSEMUL_VT100.  It seems
>    to work in that I can wsconscfg -e sun, and use TERM=sun.  But
>    standout doesn't work - it's visually the same as non-standout.  Is
>    this normal and/or known, or should I try to figure out what's
>    wrong?
> 
> - At boot time the framebuffer appears as
> 	nextdisplay0 at mainbus0: 1152 x 832, 2bpp
>     ...but I know that hardware, and it's really 1120x832.  What's up?
> 

If you look in the nextstep 2.0 header files there is fhe following:
#define	NPPB		4		/* Pixels per byte */
#define	VIDEO_W		1120		/* Visible pixels per scanline */
#define	VIDEO_MW	1152		/* Actual pixels per scanline */
#define	VIDEO_H		832		/* Visible scanlines */
#define	VIDEO_MH	910

I think 1152 is the row size of the framebuffer.  Matt Debergalis works
on wscons for the next and can hopefully fill in details.

Darrin