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.