I brought home my first Apple IIgs in the fall of 1987. That was year that CompuServe released the initial GIF specification (along with clarification that the “G” is soft). Up until then, the graphics files worth looking at existed mostly in Amiga IFF/ILBM, Atari ST Neochrome and DEGAS, and Apple MacPaint image formats. At the time, getting images of these platform-specific formats loaded on different systems was not easily done. The purpose of GIF, the “Graphics Interchange Format,” was to solve this problem by giving developers a standard format to target that could properly encode graphics generated by most of the systems of the day.
Once GIF caught on, and it did so quickly, GIF viewers (or “converters”) appeared on most modern platforms — systems with “high” resolution displays and thousands (or hundreds) of colors in their palettes — right away. For older systems with relatively meager graphics and CPU capabilities, on which crunching on a modern graphics file was somewhat Herculean, the arrival of GIF converters took longer.
The 8-bit Apple II series was one such platform. With a 1.02MHz 6502 CPU, 64K of RAM, and just six colors in its 280×192 pixel High Res graphics mode (the enhanced IIe and //c brought twice the RAM and a 16-color Double-High Res graphics mode), it wasn’t a graphics powerhouse. Despite this, developer Jason Harper was right out of the gate in 1988 with ][GIF, an 8-bit program that could convert and display GIFs in the Apple II’s various graphics modes. The results were definitley crude but the Apple II could now view images created on other, modern platforms. And, that was pretty great. Jason went on to write SHRConvert (later to become SuperConvert) for the much more graphically advanced 16-bit Apple IIgs that took advantage of its improved capabilities in conveting GIFs as well as as native images from other platforms.
|Original||][GIF to DHGR mode|
|Super Conv to DHGR mode||Bmp2DHR to DHGR mode|
Flash forward 26 years to 2014 and hobbyist programmer Bill Buckels releases Bmp2DHR, a utility for converting BMP images (which support 24- and 32-bit truecolor, beyond GIF’s 256-color limitation) to various Apple II image formats. As Buckels describes it,
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)…
I just learned of this project in the past few days and was stunned by the quality of the Apple II images Bmp2DHR generates. While it’s true that BMP images can be of higher quality than GIFs, the Apple II video modes are so relatively crude as to make that distinction of minor impact to the rendering of the output images. What makes the resultant images so striking are the image processing algorithms Buckels has employed — numerous dithering options, color bleed controls, and the like that are discussed in some detail on the Bmp2DHR info page. As someone who has been using an Apple II on and off for over 30 years, I find it hard to believe the results I’ve seen on the screen.
To be fair to Jason Harper’s ][GIF and SuperConvert, it is worth underscoring the fact that those programs were written (largely) in assembly language and ran within the constraints of the Apple II, while Bmp2DHR is a C program that can be compiled and run on modern systems boasting orders of magnitude more computing resources. Still, in the end it comes down to an image file that can be displayed on standard Apple II video hardware, and those that Bmp2HDR generates are pretty amazing.
In diving down this rabbit hole, I came to find that there exist several other image converters that read in files of various modern image formats and spit out impressive looking Apple II image files. There’s the Ghetto Image Converter, Brendan Roberts’s Outlaw Editor, and Sheldon Simms’ tohgr, which generates Apple IIgs Super High Res “3200” images (a 16-color palette per scanline). All of these converters, like Bmp2DHR, run on modern systems — not on an Apple II. Somehow I was totally unaware of all of these developments over the years, but I suspect there are a few other II fans who were as well.
In closing, I’ll say the timing of all of this is rather interesting. It was just last weekend that I loaded up ][GIF (for the first time in a couple of decades) to get my “6502 Week” entry done for Reddit’s /r/RetroBattlestations. Video below.
UPDATE: A month following this post, Bill Buckles shared a few disks of images converted to Double Hi-Res Graphics with Bmp2DHR. I made a video of an 800K slideshow disk running on my 128K enhanced Apple IIe. I’ve aimed the camera at the Apple Color Monitor II (composite) connected to the IIe, so the images can be seen in all their artifacted glory. Enjoy!
UPDATE: A variety of image slideshows on Apple ProDOS volumes can now be downloaded from Bill Buckle’s website, for your Apple II viewing pleasure.
Pingback: Bmp2DHGR Revisited: A Slideshow Running on Real Metal | Byte Cellar
I have not been able to find the actual procedure to use Bmp2DHR , what syntax to use in the cmd prompt, and to make matters worse, there are several executables in the Bmp2DHR folder, there appears to me at least, that the author/creator of Bmp2DHR seems to boast how it works without publishing to his website exactly what to type, to make it work, such as options… or even what executable to use. All i see, so far, is a bunch of paragraphs with zero instruction of the command syntax. As a person who wants to use this software, wouldn’t you want to know how to use it ? Or is this FictionWare ?
James Larson, get stuffed!
alright, i will
It really wouldn’t hurt if the author would clarify the command syntax in a readme file rather than having to rely on the vague instructions the executable presents when run. It seems more like it was written by a markov chain than a person with a firm command of the English language.
Pingback: Firing Up the Apple //c for "Not x86 Week" - Byte Cellar
There is additional discussion about the program in the header for the source file. One place to find this:
Some experimentation is required. This should be fine: I cannot imagine how someone not interested in experimentation can be interested in 40-year-old bare-metal operating systems. :D
@bill-buckels : thank you for sharing your work. It’s a great information source.
Pingback: Full Motion, Double High-Res Video Playback on the Apple IIe - Byte Cellar
Pingback: A Colorful "Peek" at the Graphics Performance of the Apple II - Byte Cellar