The Apple II’s LGR (Lo-Res Graphics) and DLGR (Double Lo-Res Graphics) video modes are very coarse by today’s standards. LGR has a screen resolution of 40 x 48 and DLGR has a screen resolution of 80 x 48. When the Apple II’s mixed text and graphics (“mixed”) mode is used, LGR and DLGR screen resolution is reduced from 48 to 40 in the vertical axis leaving room for 4-lines of text at the bottom of the screen. If a program is designed to use mixed mode LGR’s text is in 40-column text mode and DLGR’s text is in 80-column text mode.
The Apple II LGR and
DLGR modes are very coarse and not very suitable for displaying content from
continuous tone images like the dithered conversions shown above unless the
input file is carefully prepared and patiently “fine-tuned”. Even then the
results will not be “stellar”. (The lettering above was added to the preview
image at 1:1 scale in a paint program after the initial dithered conversion,
and the preview image was then converted without dithering. Since the preview
image palette matched the conversion palette the pixels in the dithered area
were not altered in any way nor was the lettering altered).
Converted Content –
Apple IIe 80 x 48 NTSC DLGR |
|
|
If you have no patience for careful
preparation and “fine-tuning” of continuous tone images, LGR and DLGR output
files from verbatim pixel-art(scaled 1:1) like those in the examples shown
above from Beagle Bros. Mini-Pix Disk One (artwork by Fred and Sara Krone), and
colored in a paint program in a matching palette, will probably work better for
you. I call this “direct pixel mapping”.
A third compromised alternative
that I call “Ghost-busting”(merged pixel mapping) is to work with pixel-art conversions
from other (larger) legacy displays like the IBM-PC 320 x 200 x 4 color CGA
mode. Simple legacy images with few colors offer the potential of re-coloring
in the DHGR palette. Bmp2DHR’s built-in scaling generally merges a simple image
colored in the DHGR palette with fewer color “errors” than dithering even if
scaling from a much larger screen resolution. Limiting the number of colors can
preserve “perceived detail” (depending on image content of course).
Ghost-Busting the Three Bears
Merging a group of pixels together by even factors into a single pixel, using the linear RGB values was also called “Squashing” in one company I worked for back in the late ‘80’s and early ‘90’s when we did true-color continuous tone images and needed some thumbnails for our menus. Squashing was quick and easy to program and the in-between colors were supported and looked fine and were without visible error since there is no palette, fixed or otherwise, in a continuous tone image. Bmp2DHR uses micro-level squashing as its built-in scaling. It’s not very sophisticated but usually does as good a job of preserving detail as anything else when dealing with even factored scaling and it keeps the code size down and can easily be done “in-line” with a control structure without much performance degradation. If you don’t like the way Bmp2DHR handles this you can always pre-scale to verbatim nominal resolution in an external editor like The GIMP. On a modern display however, you may change your mind since a verbatim image is so darned small.
LGR and DLGR are smallest of all, and by the time you get down to even DLGR’s verbatim nominal resolution of 80 x 48 some editors like The GIMP start throwing more grey than your inner psycho-vision wants to look at. That part is a matter of personal preference and we all do that part differently. Even gamma correction can be a matter of debate. I prefer to correct gamma at intervals during scaling and fine-tune by eye because content quality varies madly and we have no way of knowing if an image source is gamma corrected or not for a variety of reasons including ignorance but also intentional imbalance especially on illustrations and artistic renderings.
So to make a long story short, results will vary, and experience is a better teacher than some rules of thumb. Keeping in mind that LGR and DLGR (like DHGR) use the same fixed NTSC palette of 15 colors,
Legacy Image –
IBM-PC 320 x 200 CGA BSAVE format Recolored using Bmp2DHR’s default conversion palette |
Matching Palette – Bmp2DHR default conversion colors Sheldon Simms DHGR NTSC colors from tohgr |
Converted Content – Apple IIe 80 x 48 NTSC DLGR |
Legacy Image –
IBM-PC 320 x 200 CGA BSAVE format Recolored using Bmp2DHR’s default conversion palette Converted Content – Apple IIe 80 x 48 NTSC DLGR |
Legacy Image –
IBM-PC 320 x 200 CGA BSAVE format Recolored using Bmp2DHR’s default conversion palette Converted Content – Apple IIe 80 x 48 NTSC DLGR |
Legacy Image –
IBM-PC 320 x 200 CGA BSAVE format Recolored using Bmp2DHR’s default conversion palette Converted Content – Apple IIe 80 x 48 NTSC DLGR |
Converted Content – Additional Colors - NTSC DLGR |
Converted Content – Additional Colors - NTSC DLGR |
Converted Content – Additional Colors - NTSC DLGR |
Converted Content –
Apple IIe 80 x 48 NTSC DLGR |
|
|
Don Joyce did the first artwork for the PrintMaster program (Unison World’s competitor to Broderbund’s “The PrintShop”). Like Beagle Bros. “Mini-Pix”, PrintMaster was distributed with better 88 x 52 graphics than PrintShop (which is, by the way, very close to DLGR’s 80 x 48 resolution making these excellent graphics to color and convert to DLGR files). Three of Don’s PrintMaster images are shown above after coloring and conversion using Bmp2DHR. Some 16 years ago, Don sent me the following “short story”:
“When I first came
upon computers in the early 80s, I was impressed with the then current
philosophical approach to creating graphics interfacing which suggested that
the goal was to get the computer to act like your brain does, to be intuitively
useable. Then this all reversed and didn't seem to matter anymore. Rather
suddenly, we had to learn with difficulty art programs that had and have little
to do with how our art brains want to work. When stuff like Adobe appeared, the
goal was then to force your brain into compliance with distinctly unintuitive
graphic processes. Computers were no longer trying to be like us, we were
trying to be like computers. That's backwards, and that's when I got out of
computer graphics for good. I still like computers, they're great for writing
and probably a few other things, but they remain to this day the worst and most
unsympathetic of all mediums to attempt visual art on. Unless you have a
hollywood million to work with, they're just plain klunky and force you up
against more road blocks than you can shake a mouse at as far as serious art
(the human brain type) is concerned.” -
DJ (Don Joyce) 1999
Lo-Res Art is not simply running a Lo-Res image conversion program despite the fact that Bmp2DHR is artfully written. Lo-Res Art is also not simply adding pixels or color to some old “Mini-Pix” that someone like Don Joyce painstakingly drew pixel by pixel in 1984. The effective expression of the creative process on the Apple II’s Lo-Res display depends on 3 competencies:
Since Bmp2DHR will generate a preview image that can be edited and reprocessed, the Lo-Res Artist can use the preview from any converted image as a starting point, and “fine-tune” in a modern editor and “re-do” just as many times as necessary. Bmp2DHR’s support for iterative conversion provides the Lo-Res Artist with a ready Paint by Number “canvas” and the ability to focus on capitalizing the Apple II’s LGR and DLGR display medium to its full potential from the comfort of a modern computer. An example created by this technique is shown below:
Converted Content –
Apple IIe 80 x 48 NTSC DLGR |
|
|
Input Content –
24-bit BMP |
|
|
In order to advance
“beyond the realm” of pixel to pixel mapped conversions, or even what pixel art
means, the artist must change his or her “view” of how the Apple II’s LGR or
DLGR display works as an artistic medium . This is a matter of study and of
perspective; just as appreciating the work of the “Old Masters” broadens ones
own horizons. Rather than view the technical limitations of LGR and DLGR’s limited
palette of 15 fixed NTSC colors and coarse resolution in a digital context the
artist must free his or her art from the programmer’s rigid digital imagery by
transcending to a “Psycho-visual” level of expression. If we have learned
anything about computer art since the time of the Apple II it is that an artist
will always be artful, and those who are not will no,t regardless of what
“brush” is used.
Converted Content –
Apple IIe 80 x 48 NTSC DLGR |
|
|
Input Content –
24-bit BMP |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Bmp2DHR provides conversion from Windows BMP files to Apple II Lo-Res Graphics (LGR) and Double Lo-Res Graphics (DLGR) files. Output is limited to 2 – size variations; full-screen (48 lines) and mixed text and graphics full-screen (40 – lines). Conversion to LGR and DLGR image fragments is not provided, nor is output longer or wider than the Apple II LGR or DLGR screen.
LGR and DLGR output is in color only (LGR and DLGR do not offer a higher monochrome resolution), and can either be optionally rendered or directly mapped from the palette of your choice. This works in the same fundamental way as Bmp2DHR’s conversions to Hi-Res Graphics (HGR) and Double Hi-Res (DHGR) graphics; the same “common” fundamental command options are used for LGR and DLGR output as are used for HGR and DHGR output. Some additional command options exclusive to LGR and DLGR output are also provided.
Some of Bmp2DHR’s conversion features include::
Bmp2DHR is a command line utility. It is not a graphics editor or a paint program; good graphics editors like “The GIMP” are readily available. A graphics editor or a paint program is required to prepare images for conversion with Bmp2DHR and to convert these images to the BMP formats and sizes that Bmp2DHR accepts for conversion. One of Bmp2DHR’s strengths is the fact that it can be compiled and run on almost any “modern” computer, from MS-DOS machines to Windows, Linux and Mac OSX machines. Good graphics conversion to Apple II native formats can be complicated and so must be precise and must capitalize on the Apple II’s strengths and display capabilities. Bmp2DHR was written from “the ground-up” to do exactly that!
Bmp2DHR works with a range of fixed-size BMPs only. The reason that BMP2HR works with BMPs only rather than supporting a variety of input formats like JPEG, PNG, and GIF is because good graphics editors like “The GIMP” already have the ability to import many modern formats and to “export” or “save-as” BMP. Bmp2DHR is portable and simple, so its binaries are small in size and since it works with the simple BMP input file format only, does not depend on 3rd party libraries to load graphics files, which makes Bmp2DHR both small and portable even to low-memory and older environments, and because it is compiled code it runs quickly. Most people who would use Bmp2DHR already have a graphics editor or a paint program that they are familiar with, so to use Bmp2DHR all they need to do is use the graphics editor that they are familiar with and follow the rules for the BMP input sizes and formats that Bmp2DHR will accept, which in turn allows Bmp2DHR focus on providing the best conversion possible to Apple II native format.
Scaling images is a big part of controlling the quality of the BMP input files to get the most out of the Apple II output. One of the important considerations when scaling images is the fact that today’s displays are usually square-pixel but LCD panel screens are wide and do not match either the pixel aspect ratio for the Apple II’s various graphics modes or the Apple II’s 4:3 screen aspect ratio. This is a “very complicated business”. Also BMP input files can come from older displays like 640 x 480 square-pixel displays or 320 x 200 displays that do not have square pixels. There are other considerations as well; Bmp2DHR outputs both full-screen Apple II files and HGR and DHGR image fragments (“Sprites”). Sometimes you will want to ignore the input file’s screen aspect altogether to produce “verbatim” pixel art and other times you will want to produce dithered output from continuous tone images. There are simply too many variables to consider for Bmp2DHR to guess at what it is you want to do, so instead of guessing, Bmp2DHR controls the quality of your output by requiring a selected range of input sizes which un-complicates the whole matter of Apple II graphics file conversion.
Bmp2DHR will not put an Apple II graphics file on an Apple II disk image or a real Apple II disk for you. Its output is quick and in binary format but you must place the output files on the Apple II disk or disk image yourself. A file utility like CiderPress is required to do so. In order to properly place files on the Apple II you need to know how to use such a file utility. You also need to decide whether you will be using your graphics in ProDOS or DOS 3.3. You also need to decide if you will be using your output files in an AppleSoft BASIC program or if you are capable of loading them in a C program or an Apple II program written in a more capable manner than a “pure” AppleSoft BASIC program.
You have 3 options for outputting Apple II native binary graphics files in Bmp2DHR to assist you with placing these properly. You can use “unadorned” output, you can use CiderPress file attribute preservation tags in the output file name (the file itself is “unadorned”) or, if you are outputting for DOS 3.3 you can put a DOS 3.3 header at the beginning of the output file(s). ProDOS is like a modern computer and stores its file attributes in the filing system, but DOS 3.3 stores its file attributes in the file itself. If you are using CiderPress you can “Add files” to a disk with or without using tags. So if you are not using tags, you would add LGR or DLGR files as a “Non-type” (without tags or text conversion) and edit the file attributes afterwards. For a ProDOS disk you would set the LGR or DLGR File Type from $00 to Binary $06 and the Auxiliary Type to $0400 (the address of the Apple II text screen). If you are not using tags in DOS 3.3 you will need a DOS 3.3 4-byte header at the start of the file and add as a “Non-type” (CiderPress calls these $F2 files, DOS 3.3 catalogs these file type $08 files as type ‘S’), and afterwards change them to Binary (CiderPress calls these $06 files, DOS 3.3 catalogues these file type $04 files as type ‘B’) with a load address of $0400 (CiderPress calls the load address an Auxiliary Type).
To clear-up any confusion you may now have about CiderPress; CiderPress provides support for a number of Apple II disk “archive” formats including disk images. To be consistent in its menus and in its tags, CiderPress uses ProDOS equivalent types so a DOS 3.3 disk will display DOS 3.3 Binary Type $04 as ProDOS Binary Type $06 in its menu, and will add DOS 3.3 binary files using the same tags as ProDOS.
Output Command |
Output File Description |
Output File Extension |
Output File Size |
B2d input.bmp L TOP B2d input.bmp L B2d input.bmp L A B2d input.bmp DL TOP B2d input.bmp DL B2d input.bmp DL A |
40 x 40 Raster Oriented 40 x 48 Raster Oriented 40 x 48 BSAVE 80 x 40 Raster Oriented 80 x 48 Raster Oriented 40 x 48 BSAVE File Pairs |
.STO .SLO .SL2 .DTO .DLO .DL1 and .DL2 |
802 bytes 962 bytes 1016 bytes 1602 bytes 1922 bytes 1016 bytes each |
Target Format Command Options |
Description |
File Attribute Preservation Tag |
Output File Size Increase |
T DOS |
Append CiderPress Tag to Name Create File with DOS 3.3 Header |
#060400 None |
None 4 bytes |
Rendering Options (partial list) |
Description |
Range |
External File Support (text files) |
P D |
Conversion Palettes Error Diffusion Dithering |
P0 to P16 and “Pseudo-Palettes” D1 to D9 and User-Definable |
The GIMP gpl, Comma Delimited, etc. User Definable Dithering “templates” |
Input Sizes |
Legacy Input Source |
Nominal Full-screen Window Size |
Nominal Mixed-Screen Window Size |
88 x 52 |
|
|
|
For some Apple II’s there is no safe way to BLOAD an LGR or DLGR BSAVE image in a DOS 3.3 AppleSoft BASIC program. There is no way t all to BLOAD an LGR or DLGR screen image in a ProDOS 8 AppleSoft BASIC program. This is because loading a BSAVE LGR or DLGR screen image overwrites the non-visible areas of the Lo-Res screen memory. These non-visible areas
Bmp2DHR comes with no guarantee or warranty of any kind. But even if it did, it would not be guaranteed for fitness of use for the Apple IIgs, or for the Apple IIe or Apple IIc with an RGB display. In fact, output from Bmp2DHR on any display that is not an Apple IIe NTSC display is guaranteed to be just as wrong as the color and monochrome rendering on those displays, or you can return Bmp2DHR for a full refund. Since Bmp2DHR is absolutely free, nothing is guaranteed.
Bmp2DHR converts monochrome, 16 color, 256 color, or 24 bit Version 3 uncompressed BMP files (without color-space info), to standard Apple II Hi-res Graphics (HGR) files, Double Hi-Res Graphics (DHGR) files, or Lo-Res Graphics (LGR) and Double Lo-Res Graphics (DLGR) files that can be loaded in a DOS 3.3 or ProDOS program written in BASIC or C (including Apple II graphics editors and paint programs). Bmp2DHR is a command-line utility written in Ansi C . It runs in text-mode, and comes with source code, so it is portable and can run on almost every modern computer on The Planet. It has been compiled and run in MS-DOS and on Windows, Linux, and Mac OSX. It was written for educational purposes (and “for the hellery of it”), uses “standard parts” combined with original code written by its primary author (Bill Buckels) and others (see attributions in the source code and documentation), and has only one main restriction; you must agree that its primary author and the other “contributors” are not liable in any way for its use and distribution , and the use and distribution of its documentation, demos, and the other related baggage that it comes with.
Win32 and latest version complete with source: http://www.appleoldies.ca/cc65/programs/dhgr/bmp2dhr.zip
MS-DOS: http://www.appleoldies.ca/cc65/programs/dhgr/bmp2dhrMSDOS.zip
Other: (Linux, OSX): http://hoop-la.ca/apple2/appleoldies/bmp2dhr/
Bill Buckels bbuckels@mts.net
December 25, 2014