a2.nib
I picked this emulator up off the net somewhere and hacked in some reasonably fast hires support. I wasn't thinking about adding text, lo-res, double hi-res, etc, when I wrote it. Consequently, if this looks like a gross hack that was grafted on to another program, it is. I didn't originally write these routines for public consumption, but some of you are interested in it, so here it is. Hastily scrawled technical explanation: How the hi-res support works. --------------------------------------------------------------------- ObBenchmark: this emulator can fill the entire screen with a color and display it in grayscale on the NeXT screen in about .5 seconds. This is about 1/4 as fast as an Apple ][. I believe most of this inefficiency is in the 6502 emulator (just look what it does when they reference $C000!) The interface is entirely bogus. A window containing only a "WozView" appears. It lets you continually view HGR page 1 regardless of what graphics mode the Apple ][ is really in. Simultaneously the emulator is doing its own termcap thing somewhere. The WozView keeps track of a 2 bpp bitmap with 288x192 pixels. (It's 288 pixels wide instead of 280 because I wanted each row to be a multiple of 4 bytes wide; 288/(4 pixels/byte) == 72 bytes, 72 % 4 == 0). The extra pixels are outside of the NeXTstep window, so you can't see them anyway. Periodically, the emulator is halted and a routine is called which compares the last hires screen displayed to the contents of $2000-$3FFF. It marks the areas that have changed and converts them from Apple ][ format to NeXT format (in the WozView's frame buffer, which it makes public.) The WozView is then told which areas have changed and asked to update the screen with its version of the bitmap. The reason the WozView doesn't do the conversion itself is that I wanted the WozView to be just a frame buffer that other sections (text, lo-res, hi-res) could modify and display in a reasonably clean and efficient way. The way the Apple ][ graphics are actually converted is strange and wondrous. [Check out hgrconv.c]. There are two different modes: 1) Monochrome. Each byte on the Apple ][ hires screen contains 7 pixels and one color bit. These 7 bits are converted to 14 bits via a lookup table and then blasted to the WozView's frame buffer in the right place. This actually happens by packaging together the sequences of 14 bits into longs and blasting them out together, so the minimum number of memory writes are made. 2) Color. Apple ][ color is weird. The mapping from Apple ][ to NeXT won't always be perfect, but I made the best approximation I could. - A NeXT pixel will be black if the a2 pixel is off, and neither neighbor is an on, colored pixel. - A NeXT pixel will be white if the corresponding a2 pixel is on AND either 1) A neighboring a2 pixel is on, or 2) All a2 pixels <= 2 pixels away are off. The point of this is to make vertical lines that are one pixel wide look white. Just a heuristic. - A NeXT pixel will be colored if either 1) The a2 pixel is off and a neighboring a2 pixel is both on and its corresponding NeXT pixel is colored, or 2) The a2 pixel is on, neither neighbor is on, but a pixel 2 away is on. Which color is used depends on whether or not the pixel is an even- or an odd-numbered pixel. Since the NeXT bitmap only has 2 bits per pixel, the high bit of each byte is ignored. This means blue and green look the same, as do violet and orange. I doubt this will often be a problem. makehgrtable.c generates two 32K lookup tables which map 14 Apple ][ bits to 7 NeXT pixels via the above algorithm (one table for odd bytes, one for even.) The reason it maps 14->7 instead of 7->7 is that the neighbors of the boundary pixels are required to tell what color the boundary pixels should be. One of those 14 bits (the color bit for one of the bytes being considered) is ignored, so really we are converting 13 Apple ][ pixels to 7 NeXT pixels. Consider the following diagram listing the bits to be converted: xxx0123456xxx Here 0,1,2,3,4,5,6 represent pixels to be converted, and the x's are just there to provide more information for how to color those pixels.. The proof that you really need 3 x's on each side instead of just 2 is left as an exercise to the reader. :-) -Mat (mjhostet@athena.mit.edu)
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.