headers
Mike Pumford | 2 Oct 2006 22:45
Picon
Picon

Re: Bad video output on RiscPC

Ben Harris wrote:

> In article <4503426F.10408 <at> black-star.demon.co.uk> you write:
> 
>>Looks like something is bad with the last set of changes to the 
>>vidcvideo driver in current. I get a display that my monitor syncs to 
>>okay but is completely unreadable from the moment the kernel starts.
> 
> 
> Hmm.  I saw something similar on my Risc PC, but whether it happened 
> seemed to be independent of which of my changes were present.
> 
Current from a couple of months ago (when I was messing around with 
timecounters) was no problem. Am compiling a netbsd 4 kernel right now.

> Can you test an equivalent kernel from the netbsd-4 branch and see if it 
> works any better?  I'd also like to know what screen mode you're booting 
> from.
> 
1024x768 16bit. The kernel is trying to setup 1024x768 8bit for some 
reason. Changing the RISC OS mode to match this doesn't appear to make 
any difference. As the kernel boots it appears as if the VIDC DMA engine 
is not being pointed at the right area of memory. A ghost of the last 
bit of RISC OS screen data appears when the bootloader finishes running 
and the kernel starts to boot. Eventually you can make out the kernel 
output appearing over the top of this but its completely scrambled.

I'll report back on the netbsd-4 kernel in a while.

Mike
(Continue reading)

Permalink | Reply | 12 comments |
headers
Mike Pumford | 2 Oct 2006 23:29
Picon
Picon

Re: Bad video output on RiscPC

Mike Pumford wrote:

> I'll report back on the netbsd-4 kernel in a while.
> 
Hmm. GENERIC 4-BETA still uses the old pre-wscons console code and 
unfortunatley it kernel panics in vidcrender_flash_go although the 
screen is readable at that point. I'll send-pr this as it fatally stuffs 
anyone attempting to run NetBSD 4.0 on acorn32.

RPC_WSCONS from 4-BETA does work correctly. That gives something to diff 
against. I'll carry on digging.

Mike
Permalink | Reply | 9 comments |
headers
Ben Harris | 9 Oct 2006 23:23
Picon

Re: Bad video output on RiscPC

On Mon, 2 Oct 2006, Mike Pumford wrote:

> 1024x768 16bit. The kernel is trying to setup 1024x768 8bit for some reason.
> Changing the RISC OS mode to match this doesn't appear to make any difference.
> As the kernel boots it appears as if the VIDC DMA engine is not being pointed
> at the right area of memory. A ghost of the last bit of RISC OS screen data
> appears when the bootloader finishes running and the kernel starts to boot.
> Eventually you can make out the kernel output appearing over the top of this
> but its completely scrambled.

I've done a few experiments.  The problem manifests more severely with 
VRAM installed than removed.  In the no-VRAM case the bottom line of the 
screen doesn't update, but everything else is fine.  With and without 
VRAM, vidcvideo(4) is using the same video mode.  In both cases, my 
keyboard seems not to respond at the "root device" prompt, but caps lock 
toggles correctly, and I can break into DDB wherethe keyboard works 
correctly.  This is all rather mystifying.

--

-- 
Ben Harris                                                   <bjh21 <at> NetBSD.org>
Portmaster, NetBSD/acorn26               <http://www.NetBSD.org/Ports/acorn26/>
Permalink | Reply | 1 comment |
headers
Ben Harris | 21 Oct 2006 19:13
Picon

Re: Bad video output on RiscPC

In article <452184A6.10705 <at> black-star.demon.co.uk> you write:
>RPC_WSCONS from 4-BETA does work correctly. That gives something to diff 
>against. I'll carry on digging.

I've done some digging myself, and I found one problem -- I'd broken the
initialisation of the IOMD FSIZE register.  I've fixed that now
(vidc20config.c rev 1.29), and that seems to have at least fixed 
640x480x8 on my machine.  Can you try a new kernel and see if there's 
anything else broken that you think shouldn't be?

--

-- 
Ben Harris                                                   <bjh21 <at> NetBSD.org>
Portmaster, NetBSD/acorn26               <http://www.NetBSD.org/Ports/acorn26/>
Permalink | Reply | 8 comments |
headers
Mike Pumford | 24 Oct 2006 00:58
Picon
Picon

Re: Bad video output on RiscPC

Ben Harris wrote:

> In article <452184A6.10705 <at> black-star.demon.co.uk> you write:

> I've done some digging myself, and I found one problem -- I'd broken the
> initialisation of the IOMD FSIZE register.  I've fixed that now
> (vidc20config.c rev 1.29), and that seems to have at least fixed 
> 640x480x8 on my machine.  Can you try a new kernel and see if there's 
> anything else broken that you think shouldn't be?
> 
Getting closer. Output is still wrong but definately jumps around a lot 
less with this change so this is one issue resolved. I'll have some time 
to dig at this tomorrow. I'll let you know how I get on.

Mike
Permalink | Reply | 7 comments |
headers
Ben Harris | 24 Oct 2006 14:10
Picon

Re: Bad video output on RiscPC

In article <Pine.LNX.4.61.0610092215220.13823 <at> smaug.linux.pwf.cam.ac.uk>
I write:
>I've done a few experiments.  The problem manifests more severely with 
>VRAM installed than removed.  In the no-VRAM case the bottom line of the 
>screen doesn't update, but everything else is fine.  With and without 
>VRAM, vidcvideo(4) is using the same video mode.  In both cases, my 
>keyboard seems not to respond at the "root device" prompt, but caps lock 
>toggles correctly, and I can break into DDB wherethe keyboard works 
>correctly.  This is all rather mystifying.

The keyboard problem turned out to be an entirely different bug in 
iomdkbc(4), which I've fixed separately.

--

-- 
Ben Harris
Permalink | Reply | 0 comments |
headers
Mike Pumford | 25 Oct 2006 16:49
Picon
Picon

Re: Bad video output on RiscPC

Mike Pumford wrote:

> Ben Harris wrote:

> Getting closer. Output is still wrong but definately jumps around a lot 
> less with this change so this is one issue resolved. I'll have some time 
> to dig at this tomorrow. I'll let you know how I get on.
> 
I think I've figured it out. The old code allowed for non-zero border 
sizes but your current implementation always sets the borders to 0. This 
is fine for 640x480 but some border is needed for 1024x768 to work. I'm 
working on an appropriate fix.

Mike
Permalink | Reply | 6 comments |
headers
Ben Harris | 25 Oct 2006 16:53
Picon

Re: Bad video output on RiscPC

On Wed, 25 Oct 2006, Mike Pumford wrote:

> Mike Pumford wrote:
>
>> Ben Harris wrote:
>
>> Getting closer. Output is still wrong but definately jumps around a lot 
>> less with this change so this is one issue resolved. I'll have some time to 
>> dig at this tomorrow. I'll let you know how I get on.
>> 
> I think I've figured it out. The old code allowed for non-zero border sizes 
> but your current implementation always sets the borders to 0. This is fine 
> for 640x480 but some border is needed for 1024x768 to work. I'm working on an 
> appropriate fix.

Ah, well done.  I thought the VIDC20 data sheet explicitly said that the 
minimum border width was zero, but I may be confused, and it's possible 
that the code actually asks for a negative border width or something 
similarly stupid.

--

-- 
Ben Harris                                                   <bjh21 <at> NetBSD.org>
Portmaster, NetBSD/acorn26           <URL:http://www.NetBSD.org/Ports/acorn26/>
Permalink | Reply | 5 comments |
headers
Mike Pumford | 26 Oct 2006 00:49
Picon
Picon

Re: Bad video output on RiscPC

Ben Harris wrote:

> Ah, well done.  I thought the VIDC20 data sheet explicitly said that the 
> minimum border width was zero, but I may be confused, and it's possible 
> that the code actually asks for a negative border width or something 
> similarly stupid.
> 
Maybe a red herring. All the VESA specs I can find suggest that 0 
borders(VESA calls them margins as you guessed) are okay as well. Based 
on the fact that the monitor is locking on to the mode and reporting the 
horizontal and vertical refresh rates I would expect for the mode I 
think these vidc registers correct. It looks more like the transfer 
between VRAM and VIDC is not being synced properly.

Mike
Permalink | Reply | 4 comments |
headers
Ben Harris | 27 Oct 2006 01:07
Picon

Re: Bad video output on RiscPC

On Wed, 25 Oct 2006, Mike Pumford wrote:

> Maybe a red herring. All the VESA specs I can find suggest that 0 borders(VESA
> calls them margins as you guessed) are okay as well. Based on the fact that
> the monitor is locking on to the mode and reporting the horizontal and
> vertical refresh rates I would expect for the mode I think these vidc
> registers correct. It looks more like the transfer between VRAM and VIDC is
> not being synced properly.

The VIDC20 data sheet does indeed allow zero border widths, and the Risc 
PC TRM doesn't suggest that the IOMD uses the border for anything.

I've been experimenting to try to work out what doesn't work at the 
moment.  I'm a little limited by the fact that  my Risc PC only has an 
AKF50 attached to it, so 1024x768 is out of reach.  At lower resolutions, 
it looks to me like a current GENERIC kernel now behaves the same as a 
netbsd-4 RPC_WSCONS kernel from before I made any serious changes.  What I 
see is:

8bpp 640x480: basically correct

8bpp 800x600: characters seem to have left and right halves swapped.  
Maybe slight fuzziness.

16bpp 640x480 and 800x600: basically correct

32bpp 640x480 and 800x600: disaster.  Left-hand half of screen has a mess 
of stretched , overlapping characters.  Right-hand half is full of 
horizontal stripes.  Everything is flashing unhappily.
(Continue reading)

Permalink | Reply | 3 comments |

Gmane