a2.nib
This is a preliminary Apple ][ emulator for NeXTstep. It is based on a UNIX emulator that runs termcap and curses in a Terminal window. To get it to run, you need to (1) get copies of the Apple ][ ROMs. Since the ROMs are copyrighted, they cannot be distributed freely. There is a file inside the "a2" directory called "Snarf" that gives one approach to getting the ROM images. Once you have the ROMs, start up a Terminal window, 'cd' to the "a2" directory, and type "a2". The Apple ][ text screen (40 colummns) appears in the Terminal window and the hires screen appears simultaneously in a NeXTstep window. This is a *bad* hack, and the emulator will eventually become a very nice NeXTstep application. For more information about the Apple ][ emulator project, send a message to "na2sig-request@byu.edu" and you will be placed on the project mailing list. Eaves- droppers are welcome. Credits: see the various text files inside the emulator. Complete source is included, as well as a stripped executable. - unknown (Mat -- mjhostet@athena.mit.edu?) Mar 20 1992 I've improved the emulator several ways. - It compiles and runs under Nextstep 3.3 - It's now quad-fat and will run on Intel and Sparc hardware in addition to NeXT hardware. It will also probably run on HP hardware, but I can't test that. There should be no more hardware dependencies that aren't handled at compiletime. - It's in color rather than just B&W. - It supports hires page #2 as well as #1. - The command-line options to a2 now work. - The escape character now works and is really set to ~ - Decimal mode arithemetic is now implemented. (Sabotage works!) - Compile options for Intel Joystick support, non-buffered keyboard support, color/B&W support, and text page #2 support. There are several compile options now available. Change them in the Makefile.preamble file. - There is minimal joystick support if you compile with -DJOYSTICK_SUPPORT. This also requires the use of the Intel joystick device driver. Use the "recalibrate" command to calibrate the joystick. - There is a compile-time option to determine whether keyboard buffering is enabled. Buffering is nice, but some apple II games don't work if buffering is enabled. Use -DKEYBOARD_BUFFER to turn it back on. - There's a compile-time option to select color or greyscale graphics. Greyscale works much faster, but color looks better on systems that support color. Use either -DUSE_COLOR=1 or -DUSE_GREYSCALE=1 - Text page #2 might work if you compile with -DTEXT2 usage: a2 -m Load MONITOR.ROM instead of AUTOSTART.ROM at $F800 -i Load INTEGER.ROM instead of APPLESOFT.ROM at $D000 -c Enter command mode before executing any instructions -d <FILE> Insert <FILE> as disk 1 on startup The default disk is Samp.disk. Note that you still need to supply your own ROMs. I installed my ROMs and disks in ~/Library so I could easily upgrade and/or switch between emulators. This should also make it obvious for users what ROMs are needed as well as what they are named (It wasn't obvious in the original documentation). For the record, you need: -rwx------ 1 mkienenb wheel 10240 Mar 23 1992 APPLESOFT.ROM* -rwx------ 1 mkienenb wheel 2048 Mar 23 1992 AUTOSTART.ROM* -rwx------ 1 mkienenb wheel 256 Mar 25 1992 DISK.PROM* - Mike Kienenberger mkienenb@alaska.net Nov 3, 1997
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.