CVS commit: [netbsd-10] src

["Martin Husemann" <martin%netbsd.org@localhost>]

Module Name:    src
Committed By:   martin
Date:           Thu May 16 12:27:50 UTC 2024

Modified Files:
        src/distrib/notes/hp300 [netbsd-10]: hardware
        src/share/man/man4/man4.hp300 [netbsd-10]: topcat.4
        src/sys/arch/hp300/dev [netbsd-10]: diofb.c diofbvar.h topcat.c
            topcatreg.h

Log Message:
Pull up following revision(s) (requested by tsutsui in ticket #690):

        sys/arch/hp300/dev/topcat.c: revision 1.7
        sys/arch/hp300/dev/topcat.c: revision 1.8
        sys/arch/hp300/dev/topcat.c: revision 1.9
        sys/arch/hp300/dev/diofb.c: revision 1.8
        sys/arch/hp300/dev/diofb.c: revision 1.9
        sys/arch/hp300/dev/diofb.c: revision 1.10
        sys/arch/hp300/dev/topcat.c: revision 1.10
        sys/arch/hp300/dev/topcat.c: revision 1.11
        sys/arch/hp300/dev/topcat.c: revision 1.12
        sys/arch/hp300/dev/topcatreg.h: revision 1.5
        distrib/notes/hp300/hardware: revision 1.28
        sys/arch/hp300/dev/diofbvar.h: revision 1.5
        share/man/man4/man4.hp300/topcat.4: revision 1.8

Increase DELAY() for waitbusy macroes as pre-wscons and 4.4BSD did.

It looks necessary for sane palette ops at least on HP98543 topcat
on 68030 HP 9000/360.

Move a check of topcat(4) specific fb width quirks to topcat.c.

We need to check fb->planes but it's propbed in topcat.c after
common diofb_fbinquire() is called.

Also add a comment that it looks these 1 bpp and 4 bpp boards have
VRAM with sparse address layout and we have to handle
512 pixels per line with 1024 bytes per line.

Fix MD allocattr to return proper attributes what MI rasops(9) expects.
Use proper planemask per a vaild number of planes.

Check tc_waitbusy() before writing palette registers in topcat_setcolor().
This seems to make palette operations more stable on my HP360 with HP98543.

Add DELAY(9) to make palette register settings stable on 98543 in HP360.
Note 98547 (6 bpp variant) on HP370 (68030 33MHz) doesn't need these
DELAYs so maybe only some old variants (98543 and 98545?) on 020/030
have such restriction (actually only one nop seems enough.)

Fix topcat(4) problems on some models that cause garbages on screen.
- Make sure that windowmove (hardware BITBLT) ops complete by checking
  tc_busywait() before calling putchar functions by MI rasops(9).
  It looks CPU accesses against VRAM during windowmove (copy, erase,
  and cursor) ops causes unexpected garbages at least on 98543 on HP360,
  98547 on HP370, and also on 98543 on 040 HP380 (but not on 98549).
- Handle 'sparse VRAM' on 98543 (and probably 98542) properly:
 - Prepare and use own topcat_putchar1_4() function for sparse VRAM.
 - Pass proper 'VRAM width' rather than actuall font width to all
   windowmove (copycols, erasecols, copyrows, eraserows, and do_cursor)
   operation functions.
Now all topcat(4) consoles on 98543 on HP360/HP380 and 98547 on HP370
work fine, and no visible regression on 98549 on HP380 and 98544 on HP360.

Note that 98542 and 98543 variants are also supported by topcat(4).

Add 98542 and 98543 framebuffers to supported "Graphics Devices" section.
I hope someone will sync a list of supported devices in port wiki pages
with one in this installation notes.

Add comments about quirks of 98542/98543 framebuffers with 1024x400 pixels.


To generate a diff of this commit:
cvs rdiff -u -r1.26.2.1 -r1.26.2.2 src/distrib/notes/hp300/hardware
cvs rdiff -u -r1.7 -r1.7.54.1 src/share/man/man4/man4.hp300/topcat.4
cvs rdiff -u -r1.7 -r1.7.6.1 src/sys/arch/hp300/dev/diofb.c
cvs rdiff -u -r1.3 -r1.3.90.1 src/sys/arch/hp300/dev/diofbvar.h
cvs rdiff -u -r1.6 -r1.6.2.1 src/sys/arch/hp300/dev/topcat.c
cvs rdiff -u -r1.2 -r1.2.90.1 src/sys/arch/hp300/dev/topcatreg.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.