Want support for color displays and bitmaps

[masinter]

there were some D machines with Color (michele has a color board 512x512x24 bits).

[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.

[MattHeffron]

@nbriggs Just a note on our brief look into 24 bits-per-pixel bitmaps during the Zoom meeting today. Digging more deeply (into LLDISPLAY) it seems that, although one can create a 24 BPP bitmap, many of the bitmap manipulation functions appear to do nothing or that they will fail. (E.g., in BITMAPBIT, handling 24 BPP bitmap calls \GETBASE24 and \PUTBASE24, neither of which appear anywhere else in the sources directory structure.)

[nbriggs]

@MattHeffron Thanks for looking at that -- the \GETBASE24 and \PUTBASE24 functions get defined in library/LLCOLOR, which is also where the BITBLT for BIGBM bitmaps lives. It's all rather convoluted!

[MattHeffron]

So, without loading the LLCOLOR (etc.) file(s), BITMAPBIT will fail! However, it looks like the maximum size of a bitmap is \MaxBitMapWords (131066) [ == 262132 bytes] Dividing by 3 bytes/pixel gives 87,377 total pixels, which is only 295x295 pixels. :-(

Dealing with the larger bitmaps for 24BPP color will need much redesign.

[masinter]

PR #1398 Pull in newer missing library .teditfiles picks up some tedit files for medley/library. I didn't sort them out or rename them to be uppercase. There are 3 different COLOR*.TEDIT files. There are some differences between releases about what it says for color and what runs on what.

On Wed, Nov 8, 2023 at 6:07 PM Matt Heffron @.***> wrote:

So, without loading the LLCOLOR (etc.) file(s), BITMAPBIT will fail! However, it looks like the maximum size of a bitmap is \MaxBitMapWords (131066) [ == 262132 bytes] Dividing by 3 bytes/pixel gives 87,377 total pixels, which is only 295x295 pixels. :-(

Dealing with the larger bitmaps for 24BPP color will need much redesign.

— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/6#issuecomment-1803050996, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIQTK3GDHRSYZDMGTV2FPTYDQ3EPAVCNFSM4P2TXHRKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBQGMYDKMBZHE3A . You are receiving this because you were mentioned.Message ID: @.***>

-- https://LarryMasinter.net https://interlisp.org

[nbriggs]

@MattHeffron if you want to spend any more time on it, have a look at the BIGBM functions - e.g., BITMAPCREATE.BIGBM, though I agree that 24 bpp is not an easy path. I think we could resurrect the 8-bit color-mapped display code with only some cleanup in Lisp - most of the work would be in the Maiko code.

[phantomics]

Does the 8bpp mode use a static color map or can you swap the palettes? If it doesn't, it could be worth extending to add the option to do palette swaps - maybe that could work at the Maiko level. Then you could have all 2^24 or more colors of host systems available, but only so many at a time in a defined palette.

Pixel art is popular, see https://pixeljoint.com/, and the key to pixel art is using a constrained color palette. Indexed color systems based on palettes allow for some effects and creative choices that other systems don't; you can express many different moods with a . All the current computer graphics systems I know of are based on explicit color coding rather than color mapping, it's more complicated to do color mapping at the GPU level so it's not something that most display tech designers even think about. That means it could be a major unique point for Medley and attract pixel artists to work on the platform.

Using palettes 8bpp is more than enough, 256 colors is quite excessive for most pixel art palettes. 32 or 16 colors are more common. With 8bpp you could use multiple palettes on a screen without doing any kind of palette swap. At https://lospec.com/palette-list/ you can see a collection of color palettes to give you an idea of this design approach.

[nbriggs]

You can set the palette to anything you want.

[phantomics]

Can it be reset while the system is running or even dynamically while the screen is being drawn? I.e. have an area with a different palette than the rest of the screen.

[nbriggs]

I believe it is one map for the entire screen that can be loaded at any time that the underlying display controller permits it. It was used on Sun cgsix and cgfour color boards, I believe.

[MattHeffron]

While poking around in my "software pack rat accumulation", I discovered that I still have the September 1992 ldex for the HP-UX workstation I was using back then (HP 9000 Series 700, I think), and some contemporary sysouts. (It looks like it's the distribution TAR file.) So ... might it work on some "modern" 68K workstation? If so, then we could see what the color support was at that time.

[Michele31415]

On 12/28/2023 10:20 PM, Matt Heffron wrote:

While poking around in my "software pack rat accumulation", I discovered that I still have the September 1992 |ldex| for the HP-UX workstation I was using back then (HP 9000 Series 700, /I think/), and some contemporary sysouts. (It looks like it's the distribution TAR file.) So ... /might/ it work on some "modern" 68K workstation? If so, then we could see what the color support was at that time.

That's very interesting.  QEMU supports HP-UX and I have a color sysout from 1995 from my Kodak research days running on a Sparc 20. I didn't grab the ldex from then because I never thought I'd be able to afford my own Sun workstation.

Can you share your lde?

            - Michele

[MattHeffron]

Michele,

I just copied it to the Google Drive Interlisp upload folder (link to the file): https://drive.google.com/file/d/1CTCn2kkCq2X03pjFKNorsFNjwt_bB354/view?usp=drive_link It’s LispDevelopmentEnvironment.tar.gz

Matt

It is interesting that Google Drive shows the same “Last modified” date as on my PC. I would have thought that it would be the date/time it was uploaded.

[MattHeffron]

My recollection is that the color support was integrated into the standard display. I think that I noticed right away that Exec windows had colored borders and title bar.

[Michele31415]

On 12/29/2023 6:58 PM, Matt Heffron wrote:

My recollection is that the color support was integrated into the /standard/ display. I think that I noticed right away that Exec windows had colored borders and title bar.

That was my recollection too.  Color on the D0 did get handled by a second color monitor but when I was running Medley in 1995 at Kodak, all I had was one display on the Sun SS20 and it ran Lisp in color.

            - Michele