Tuesday, August 11, 2015

Getting optimal Apple ][ screenshots w/NTSC emulation

A while ago over at MobyGames, AppleWin NTSC was recommended (okay, by me) for obtaining Apple ][ shots.  However, it's a bit of a pain to use, since the built-in screenshot function doesn't work.  Also the NTSC output is still not *quite* ideal (there's some ghosting/ringing going on, and black/white areas are somewhat 'noisy').

Thankfully Michaelangel007 has provided a newer build which addresses both of these issues.  The full discussion is on github, but here's a quick-start guide to make your lives easier and your screenshots better:
  • Grab Applewin.exe here (feel free to *rename* it and drop it into your AppleWin dir).
  • Run it.  You'll want to be in TV mode (cycle through with F9), with "50% scanlines" disabled.
  • Hit PrintScreen to capture a .BMP shot in the same path as the disk image.
There's still some post-processing to do however.  For some reason, the rendering in this build is rather blurry - luckily this is not hard to fix, since only every *other* scanline is interpolated (so no image data is lost).  Plus we still get a border, which we typically don't want.

To do it all the easy way, and convert to .PNG while we're at it, I use this simple batch file with ImageMagick:

FOR %%a in (*.bmp) DO convert -crop 560x384+23+17 -interpolate integer -filter point -resize 100%%x50%% -scale 100%%x200%% -format png %%a %%~na.png & del %%a

Save as .bat in a folder with all your BMPs, run it and you're done. Note that the original BMPs will be deleted, and of course you'll need the PATH in your environment to point to your ImageMagick directory (or just stick the path before 'convert' above).

Here are a few results (click to enlarge):


These improve on the previously-available AppleWin NTSC, which itself is already much more faithful than other emulators out there.  Hopefully a version of this (without the blurry, cross-scanline interpolation) can be merged into mainline AppleWin, and adopted by others -- maybe then we'll stop seeing plain wrong shots like these all over the internet.

Sunday, August 9, 2015

101 Monochrome Mazes: why not color?

[ Note: this post is here to supplement a discussion on MobyGames, because it's simply easier to present the info in this format.  Plus, it'll stay accessible in case someone needs a source for the trivia later on, because nobody expects the Spanish Mobyite Inquisition. ;-) ]

One Hundred and One Monochrome Mazes was a 1983 IBM release, part of its 'Personally Developed Software' line of PC titles created by outside authors.  Rather unusually for a game, it's not just monochrome - it's so monochrome that it won't run on a color card at all.  Indeed, a rather amusing review in PC Magazine gloated in mock smugness about how "sobersided, industrious monochromers" finally have a game just for themselves, lording it over those "frivolous, irresponsible colorists" who got left out in the cold.

Question is, why would they limit their potential audience with such a restriction?  After all, the only thing a monochrome adapter ever does is show 80x25 text using a fixed character set (we're talking about IBM's original MDA, not the Hercules or other such advanced hardware).  Color cards - CGA and descendants - do the exact same thing just fine, so there doesn't seem to be a very good reason not to support them.  There's a plausible technical explanation however, and oddly enough it has to do with how the game maps are stored.

Thursday, August 6, 2015

8088 MPH Final: Old vs. New CGA (and Other Gory Details)

At long last, the final version of 8088 MPH is out.  There's a very nice rundown of the fixes and changes in Scali's blog post; much of the visible (i.e., graphical) portion of those changes involved making the demo compatible with all IBM CGA cards.

The party version targeted the earlier, pre-1983 revision of the IBM CGA card (or as we've come to call it, "old" CGA).  This was partly because we had better data for this model: reenigne owns such a card, and he had been working on some of these tweaks long before we decided to make a demo about it.  Also, when we did our first tests on a "new" CGA card – the post-1983 revision – we discovered that our "secret sauce" extra-color modes weren't yielding very predictable/useful color palettes.  Fortunately, this was largely fixed by fine-tuning several CRTC values; this can now be done from the new calibration screen, but more on that later.

Still, ensuring proper colors on both CGA types meant that most of the graphics had to be redone for new-style CGA.  The 1024-color palettes proved to be extra sensitive to the old vs. new difference – hopefully this image shows why:

(Click to enlarge)
The root of all this trouble lies in how the 16 'direct' colors are generated on the CGA's composite output stage.  With an old-style CGA, those colors that carry chrominance information (i.e. all except the grey shades) differ only in phase.  With the revised new-style design, IBM added some extra circuitry which feeds the (weighted) R, G, B, and I signals into the mix.  This allows for 16 different levels of grey in B&W mode, which is probably why they did it.

To get our 1024 colors, as shown in my previous post, we take bits and pieces of these direct color waveforms and rearrange them into new composite signals of the right frequency.  And since each CGA type gives us different "building blocks", the resulting palettes end up very different indeed:

(click to enlarge)

Monday, August 3, 2015

New design

Going to put up some actual new posts soon, but I've been messing with the blog design a little and customizing the stylesheet.  Why do I feel the need to share this thoroughly uninteresting piece of news, you ask?  Because if anything looks b0rked now, I want to know about it.

Oh, yeah: that new font you're (hopefully) seeing is Fantasque Sans Mono, and the one I've been using for titles is Nouveau IBM Stretch, which does a good job of rendering those classic VGA 9x16 text mode characters in the right aspect ratio.  (*Cue "the more you know" animation*)