CVS log for src/share/man/man4/man4.hp300/topcat.4

Up to [cvs.NetBSD.org] / src / share / man / man4 / man4.hp300

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

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.

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

Sync with HEAD

New sentence, new line. Sort SEE ALSO. Use Dq. Noun is "setup". Fix a Dd.

- update SYNOPSIS and SEE ALSO for wscons support
- remove descriptions about obsolete ioctl

Use .In instead of .Aq Pa for header files.

file topcat.4 was added on branch uebayasi-xip on 2010-03-22 18:58:32 +0000

Use .In instead of .Aq Pa for header files.

Move UCB-licensed code from 4-clause to 3-clause licence.

Patches provided by Joel Baker in PR 22309, verified by myself.

Generate <>& symbolically. I'm avoiding .../dist/... directories for now.

Use standard headers, sort sections and SEE ALSO.

Overhaul of HP300 documentation:
- improve cross-referencing
- pages for recent drivers
- use correct driver names