Subject: Re: dt 1.1.4 on SE/30 w/ 1.2?
To: None <port-mac68k@NetBSD.ORG>
From: Dale R. LaRoe <dlaroe@lab.housing.fsu.edu>
List: port-mac68k
Date: 10/28/1996 00:02:18
On Fri, 25 Oct 1996, Denton Gentry wrote:
> Is dt supposed to work on the 512x350 screen? The README
> says it hasn't been tested, but comments in the rcs history
> in grf.c imply that it should work.
> Denny
I'm having the same problem. The last version that worked on the SE/30s it
seems was 1.0.1, and it doesn't have sound. I tried using the code frags
that Ken Nakata recommended but I couldn't get them to work (prob. my lack
of coding, not bad advice).
It would be nice to get dt 1.1.4 running on the SE/30. X slows the machine
down too much for my taste.
To refresh everybody's memory, I've included what I was talking about:
From: Ken Nakata <kenn@eden.rutgers.edu>
To: Andrew Brennan <brennan@crashprone.hahnemann.edu>,
NetBSD Mac68k <port-mac68k@NetBSD.ORG>
Subject: Re: dt on a SE/30 ?
> ... any chance this can be made to work? I've started it once or twice
> and it causes the screen to go white and I end up rebooting (although I
Probably this problem is caused by same reason Xmacbsd.950912 on puma
doesn't work with the SE/30 internal video. I know the bug actually
is in the kernel but I haven't been able to hunt the bug yet.
There's probably lines like this in the source:
vaddr = mmap(fd, blah blah);
if (vaddr == (caddr_t)-1) {
/* failed to mmap the frame buffer */
where 'fd' is an open file descriptor of /dev/grf0 device and 'vaddr'
stands for virtual address. Variable names may be different from
this. If you find the code fragment, change to:
if (ioctl(fd, GRFIOCMAP, &vaddr) == -1) {
/* failed to map the frame buffer */
<snip>
--
dlaroe@lab.housing.fsu.edu BAN NEANDERTHALIC CAPTAINAGE!
"We apologize for the inconvenience."