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