Want support for color displays and bitmaps about medley

[johnwcowan]

The first step to this, I think, is relatively easy and will help a good number of users: a setting (perhaps an environment variable MEDLEY_COLORS or a new or existing config file) that defines how Medley's "black" and "white" are actually rendered externally. By swapping them, we will have a "dark mode", something very popular nowadays. (I personally use black type on white paper, as God and Gutenberg intended.)

[masinter]

There was D-machine hardware for color frame buffers for Dolphin and Dorado. Michele Dember has one.
Interlisp used it. Theres a file called MAIKOCOLOR but no idea what the status is/was for using it.

[nbriggs]

John's note is for a completely different feature, which is already part of the LISP code -- (VIDEOCOLOR T) or (VIDEOCOLOR NIL) which inverts the sense of black and white on the display (while leaving the cursor alone, I think).

Abe's fix to change what the foreground and background colors are may interact with (VIDEOCOLOR ...) in odd ways, or perhaps not, depending on how X passes that on down. The maiko code uses BlackPixelOfScreen() and WhitePixelOfScreen() -- so if these are changed by the foreground and background X color settings it might work as hoped (but it will still flip when you call (VIDEOCOLOR T))

What this issue was really about, though, was to get full color support under X (as a separate window) where maiko/Medley running on a Sun workstation could access a full-color display in the same manner as it accessed the external color display on a Dorado.

[masinter]

VIDEOCOLOR(T) helps with legibility with modern higher resolution screens. The only problem is that it doesn't invert the mouse cursor, which gets lost in the all-black regions.

There seem to be several ways to go:

1. Color in a separate frame buffer (like Dorado). This is the least interesting.
2. Color in the main frame buffer.
3. Revive XMAS -- output to color X windows

Amount of code changes and incompatibilities, effect on legibility using LED displays are some of the cosiderations.

[nbriggs]

"The only problem is that it doesn't invert the mouse cursor, which gets lost in the all-black regions." -- the code used to try, but failed, to implement the cursor display as inverting. Since it didn't actually work, and since the original behavior on a D machine was NOT to do that, all the related code was removed.

[masinter]

I'll self-assign until there is a plan. I think the feature of 'color' interacts with many other directions and can't be evaluated alone (modern fonts, bigger high-resolution displays). Need to investigate BITBLT support for bitmap as common-lisp 2D array)

[masinter]

The conversation at the meeting Monday about color and bigbitmaps made me want to look into it again.with 2 or 4 bits per pixel, you can do a lot with anti-aliasing fonts on the display.
What I'm imagining is doing more with \DISPLAYLINE if the font is a TrueType font, even with kerning.
Define \BLTCHAR to be \DISPLAYLINE of a one-character line.

I think we might want to add a scale factor to display points so we can do fractional widths.

 I think we might have to restrict the fonts to support a likely assumption that font widths are monotonic in the strings of characters (   width(A) + width(B)  >=  width (A + B)  ) do if you concat two strings it's bounded above by their respective widths.   

[masinter]

@Anzus @MattHeffron @Interlisp/core what version of Medley supported color? Might we have a system that works on X color? Do any of the release notes talk about color support?

[nbriggs]

@masinter - there's no color support implemented under X. There's code to support Sun cgfour color displays as raw framebuffers via /dev/fb. There's some support for cgeight /dev/fb, with 8/24 bpp color - like the cgfour display it depends on the SunOS pixmap and raster-op code which went away with Sun OpenWindows/Motif/OpenLook. There's code to support 8-bit (color map) color bitblt operations on big-bitmap structures. All the character operations remain 2-color (it will only do char-blt operations transforming the 0/1 in the original character bitmap to one of two 8-bit colors). There's a little bit of code to draw 8-bpp lines in a bitmap, no anti-aliasing it just changes the pixels that a 1-bpp drawline would change.

In the Lisp code -- I'd look for Dorado color support, I don't know of anyone who was doing color with Lisp on Dolphins. I did some color support for the color board for the Dove/Daybreak but that was only making it possible to do AISBLT from an AIS file to the color display. The Dove/Daybreak color board was cancelled after one or two were built, so we never went any further with that.

[Anzus]

There are three files mentioning color, maiko/src/llcolor.c (for the low-level Sun stuff) and medley/library/llcolor and medley/library/maikocolor that implement the lisp layer. I think at one time either Carl or Jarl were fooling around with color, there might be something in their directories in the Envos stuff. They had at least one color Sun at Envos, but most were black and white. There wasn’t color support in the DOS port either. …arun

…

On Mar 4, 2023, at 8:46 PM, Nick Briggs ***@***.***> wrote: @masinter - there's no color support implemented under X. There's code to support Sun cgfour color displays as raw framebuffers via /dev/fb. There's some support for cgeight /dev/fb, with 8/24 bpp color - like the cgfour display it depends on the SunOS pixmap and raster-op code which went away with Sun OpenWindows/Motif/OpenLook. There's code to support 8-bit (color map) color bitblt operations on big-bitmap structures. All the character operations remain 2-color (it will only do char-blt operations transforming the 0/1 in the original character bitmap to one of two 8-bit colors). There's a little bit of code to draw 8-bpp lines in a bitmap, no anti-aliasing it just changes the pixels that a 1-bpp drawline would change. In the Lisp code -- I'd look for Dorado color support, I don't know of anyone who was doing color with Lisp on Dolphins. I did some color support for the color board for the Dove/Daybreak but that was only making it possible to do AISBLT from an AIS file to the color display. The Dove/Daybreak color board was cancelled after one or two were built, so we never went any further with that. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[nbriggs]

The pixrect reference manual: http://www.bitsavers.org/pdf/sun/sunos/3.0/800-1254-03A_Pixrect_Reference_Manual_198602.pdf in case one wants to understand what some of the llcolor.c code is doing.

[Michele31415]

On 3/4/2023 9:24 PM, Larry Masinter wrote: @Anzus <https://github.com/Anzus> @MattHeffron <https://github.com/MattHeffron> @Interlisp/core <https://github.com/orgs/Interlisp/teams/core> what version of Medley supported color? Might we have a system that works on X color? Do any of the release notes talk about color support?

I have a sysout I used at Kodak dated 7/25/95 that was in color. When I try to run it on my Sun T4-1 using a current Medley ldeether, it just reports "Lisp VM is too old for this emulator. (version is 4928, must be at least 35010)." When I try to run it in the ldex from the lfg directory from the PARC public ftp server it tries to start up (brings up the Lisp window with scrambled lines) then quickly goes to URaid with "OP_subrcall: invalid alpha byte 0210." So yes, Lisp used to work, windowed, in color in the mid 90's, on a Sun SparcStation 20.  Which version was current in 1995?  I'm guessing Medley 1.0? Section 19.16 in the 1983 IRM is called "Color Graphics".  That refers to D0/Dorado color, but the same functions still worked in 1995.             - Michele

[Michele31415]

On 3/4/2023 9:47 PM, Nick Briggs wrote: ... In the Lisp code -- I'd look for Dorado color support, I don't know of anyone who was doing color with Lisp on Dolphins.

I did.  I still have a color board for my D0 (if I could only get it to boot - still working on that).  My Pacman program in Lispusers from 1983 optionally uses the D0 color display.             - Michele

[nbriggs]

"Lisp VM is too old for this emulator. (version is 4928, must be at least 35010)."

Must be Medley 1.0, since 1.15 had a minimum required Lisp version of 15000.
But, unless we have a Sun workstation with a (maiko and SunOS supported) color frame buffer running something up to about Solaris 2.8 we're not going to get very far resurrecting that.

[nbriggs]

When I try to run it in the ldex from the lfg directory from the PARC
public ftp server it tries to start up (brings up the Lisp window with
scrambled lines) then quickly goes to URaid with "OP_subrcall: invalid
alpha byte 0210."

A subr call with alpha byte 0210 is a call to tell Maiko to initialize the color display and pass the base address of the color bitmap to be used for the color screen, which would be passed to cgfour_init_color_display() where it will open /dev/fb and do some memory mapping and copying (not sure which direction) between the Lisp byte-map and the screen memory.

This is jogging my memory about the trouble we had when Sun introduced the GPU accelerated display controllers -- you could no longer memory map the display pixels, so Lisp was unable to use them.

[Michele31415]

On 3/5/2023 6:33 PM, Nick Briggs wrote: A subr call with alpha byte 0210 is a call to tell Maiko to initialize the color display and pass the base address of the color bitmap to be used for the color screen, which would be passed to |cgfour_init_color_display()| where it will open |/dev/fb| and do some memory mapping and copying (not sure which direction) between the Lisp byte-map and the screen memory.

From what I can find, the SS20 base graphics card was CG6, with an optional CG14.  The CG4 IIRC was very early, as in Sun 3/60 and 4/110.  I know for sure that I wasn't using those at Kodak.  It must have worked with CG6.             - Michele

[nbriggs]

Looking at cgfour_init_color_display() I'd say it didn't do anything that was specific to the cg4, rather it opens /dev/fb and uses the pixrect library and mmap() to associate the framebuffer memory with the Lisp 8-bpp bitmap. As long as the display controller presented the raw display as mappable memory Lisp was OK with it. An ldex is not compatible with the pixrect color code -- it would have to be an ldesingle or ldemulti. Since we don't have the pixrect library on modern Solaris, or any machines where /dev/fb is the best solution, we don't (and likely can't without a bunch of work) build those anymore. It looks as though hemlock has an ast device which Oracle describes as

[...] the graphics device driver for the AST2200 KVMS module in the ILOM for SPARC servers. This driver provides kernel terminal emulator support for the text console, and frame buffer support for the Xorg server.

[masinter]

Do you think the HP UX system @MattHeffron used might be runnable with a HP-UX emulator?

[nbriggs]

See library/COLOR.TEDIT and library/MAIKOCOLOR.TEDIT. We should be able to make an X11 color window that uses about the same interface that MAIKOCOLOR was using for, say, the cgfour display on the Sun. I haven't extracted the details of that yet, but I think it's just the #ifdef COLOR subrs in subr.c, along with creating an identifiable color display type in the \InterfacePage so the Lisp code knows what it is working with.

Also worth a look: library/COLOR-BRAINSTORMING.TEDIT.

[nbriggs]

@masinter -- I don't see any added value in trying to build the old software for an HP-UX emulator.
@Michele31415 -- the MAIKOCOLOR code seems to acknowledge the existence of cgthree, cgfour, cgsix, and cgtwo.

[masinter]

I wasn't thinking we would try to build old software but I did find a hpux.hp9000 folder...
Now in /history/1990s/1993-envos/users-sybalsky/maiko/hpux.hp9000

[nbriggs]

The executables in that hpux.hp9000 folder are for an X display, and the code was compiled without COLOR support, as evidenced by the three occurrences of the string "Color is not supported" (which are what the three cgfour_... routines compile to when COLOR was not defined.)

[masinter]

This issue is related to #39 "support larger displays" by divvying up one bitmap into several and taking the conjunction.