rasops1 bug?

[Hugo Villeneuve]

I was wondering if it was only me having a issue with macfb or it
was somewhat related to rasops which is used on multiple arch.

When the console use the 12x22 font (when the resolution width is

12*80(960)) in monochrome mode, the delete characters operation create

unreadable garbage on screen. It's a common operation in curse.

You can test with this at the console:
#!/bin/sh
tput clear cup 3 0
echo " =>THIS TEXT WILL BE DELETED<===THIS FILLS THE GAP==><="
echo " =>THIS TEXT WILL BE DELETED<===THIS FILLS THE GAP==><="
tput cup 4 7 dch 25
echo -e "\n\n\n"

This does not occur when I set the color depth to 8 bits or use the
regular 8x16 font.


Maybe some other user of >960 pixels wide monochrome (1 bit) video
card using rasops could test it?

If I understand correctly that would be:

hp300: hyper framebuffer
luna88k: fb framebuffer (?)
sparc: bwtwo framebuffer
vax: smg framebuffer

Although they are technicaly color framebuffer, are those run in
monochrome simulation? (for speed?):

hp300: tvrx
sparc: cgeight, cgtwelve

Thanks.


Unofficial dmesg:
OpenBSD 5.0 (ROOTNFS) #8: Sun Aug 28 03:38:50 EDT 2011
***@mac.EINTR.net:/root/src/kernels/compile/ROOTNFS
Apple Macintosh Quadra 650, 68040 CPU+MMU+FPU, 4k on-chip physical I/D caches
real mem = 142606336 (136MB)
avail mem = 135516160 (129MB)
mainbus0 at root
obio0 at mainbus0
adb0 at obio0: II series
asc0 at obio0: Apple Sound Chip
macfb0 at obio0: DAFB, monitor sense 0
macfb0: 1024x768, monochrome display
wsdisplay0 at macfb0 mux 1: console (std, vt100 emulation)
sn0 at obio0: integrated ethernet adapter, address 08:00:07:9c:f8:76
esp0 at obio0 (pseudo-DMA): NCR53C96, 16MHz
scsibus0 at esp0: 8 targets, initiator 7
sd0 at scsibus0 targ 2 lun 0: <IBM, DPES-31080 !t, S31R> SCSI2 0/direct fixed
sd0: 1034MB, 512 bytes/sector, 2118144 sectors
cd0 at scsibus0 targ 3 lun 0: <SONY, CD-ROM CDU-8003A, 1.9a> SCSI2 5/cdrom removable
zsc0 at obio0
zstty0 at zsc0 channel 0
zstty1 at zsc0 channel 1
nubus0 at mainbus0
adb0: 2 targets
akbd0 at adb0 addr 2: extended keyboard (ISO layout)
wskbd0 at akbd0: console keyboard, using wsdisplay0
ams0 at adb0 addr 3: 1-button, 100 dpi mouse
wsmouse0 at ams0 mux 0
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
can't figure root, hope your kernel is right
nfs_boot: using interface sn0, with revarp & bootparams
nfs_boot: client_addr=192.168.12.50
nfs_boot: server_addr=192.168.12.70 hostname=mac
root on cpaq:/exports/mac/root
swap on cpaq:/exports/mac/swap

[Miod Vallat]

There used to be rasops bugs at < 8bpp with font width not being a
multiple of 8. I thought I had fixed all of them (at least for 1bpp and
2bpp, I am still aware of 4bpp problems). I'll try to check if I can
reproduce your problem shortly, and work on a fix.

Post by Hugo Villeneuve
Although they are technicaly color framebuffer, are those run in

tvrx for lack of documentation, the others for speed.

Miod

[Hugo Villeneuve]

Post by Miod Vallat
There used to be rasops bugs at < 8bpp with font width not being a
multiple of 8. I thought I had fixed all of them (at least for 1bpp and
2bpp, I am still aware of 4bpp problems). I'll try to check if I can
reproduce your problem shortly, and work on a fix.

Thank you for looking into it.

When making out that list of monochrome devices, I didn't expect
many people to either own them or have the ancient monitor compatible
with some of them


Right now I understand the issue and the work-around for me is easy
(ask the Mac Booter to change the resolution to 800x600), I'm no
longer affected by it.

It seems it will be hard to test all those <8bpp without mac68k. I
couldn't find rasops2 use by anything else than macfb and rasops4
was only use by macfb and lcd in arm/xscale/files.pxa2x0. (Or you
have a way to virtually test them?)

Just to see, I rebooted my Mac in 2bit and 4bit color depth and my
test case worked perfectly at those depth. Only in monochrome mode
I have an issue with the 12bits wide font.


Merci encore.

[Miod Vallat]

Post by Hugo Villeneuve
When making out that list of monochrome devices, I didn't expect
many people to either own them or have the ancient monitor compatible
with some of them

Oh, noone does.

As for the monitors, I myself use a good old Goldstar^WLG ``Flatron'' 17
inches CRT (probably older than 10 years by now), with a large set of
adaptor cables. Most of the older frame buffers can output to 3 or 5 BNC
connectors, and I am the lucky owner of a passive and complete (i.e. can
be used in both directions) VGA HD15 to 5 BNC cable (from an IBM
XStation X terminal), which I use a lot.

For Macintoshes, you can still find DE15 to VGA HD15 adaptors (with DIP
switches to select your preferred resolution and refresh rate), or even
cables hardcoding the monitor sense information. (I happen to have both
as well).

Anyway, back to your problem: the machine-independent rasops code is
indeed faulty (well, erasecols in rasops_bitops.h is), but this does not
show up on vax and hp300 because those special code (derived from X11R4
mfb X server code) for this operation.

I started to work on fixing rasops_bitops, to no avail so far [*], but
actually it will probably be much easier to move in the other direction,
and replace rasops_bitops with
known-to-be-good-from-years-of-actual-usage X11R4 derived code. Stay
tuned for a fix soon...

Post by Hugo Villeneuve
It seems it will be hard to test all those <8bpp without mac68k. I
couldn't find rasops2 use by anything else than macfb and rasops4
was only use by macfb and lcd in arm/xscale/files.pxa2x0. (Or you
have a way to virtually test them?)

2bpp and 4bpp modes are only used on mac68k (actually, 2bpp would be
used on NeXT systems too, but the port of the NetBSD/next68k code was
never completed due to a dire lack of interest). The ARM pxa lcd code
has theoretical support for 4bpp and 8bpp modes, but they have never
been used (or tested).

Post by Hugo Villeneuve
Just to see, I rebooted my Mac in 2bit and 4bit color depth and my
test case worked perfectly at those depth. Only in monochrome mode
I have an issue with the 12bits wide font.

The problem gets exposed when a character cell width is not aligned on a
byte boundary; at 1bpp the 12x22 font character cell is 12 bits wide and
exposes the bug; at 2bpp or 4bpp it is either 24 or 48 bits wide, both
values being multiples of 8.

Miod

[*] I don't have enough contiguous working brain cells to be able to
work on smaller-than-8bpp code those days. And, unlike the X11 code, the
rasops is a bit overengineered in that it is designed to work on 32 bit
pixel blocks, but allows for computed bit positions over 32, by
accessing the next 32 bit chunk if necessary. And then there's a comment
mentioning that this causes macros to be too complex and probably goes
against compiler optimization. One more reason to try simpler,
real-world-proof code, instead.