Apple II Projects

For many years I designed server systems for Hewlett-Packard, but for fun, Apple II's remain my all-time favorite computers! Some of my projects are described below.

A Fast Arc Generator for the Apple II

No, not that kind of arc, the kind that's part of a circle!

Well, it happened. I'd no sooner posted FASTCIRC than I wanted to draw a rounded rectangle, and I realized that sometimes, only a part of a circle will do. I then noticed that a straightforward generalization of the FASTCIRC subroutine could generate partial circles, arcs, which could be even more useful while retaining the ability to create circles. FASTARC is the result, which effectively supercedes FASTCIRC.

Like FASTCIRC, FASTARC is self-relocating and, like FASTCIRC, runs about 70 times faster than code using sine and cosine calculations. FASTARC is somewhat larger (492 bytes) and contains its own 16 byte table of single-byte cosines, plus code to create arcs of any radius from zero (a point!) to 214 pixels.

A circle is specified by the X,Y coordinates of its center of rotation and its radius. An arc requires two additional parameters: its its starting angle, (in 64ths of 360 degrees), and its length (also in 64ths of a circle). These extra parameters can also be used to specify whether: 1) the arc should be drawn counterclockwise or clockwise from the starting point of the arc, and 2) whether the starting point should be connected to the last HPLOTted point (to allow for arcs to be connected by a line to the previously plotted graphic element).

FASTARC makes it relatively easy, using the "connected" option, to draw rounded rectangles, spirals, and decorative borders. See "demo5" and "demo6" for examples. As a convenience, FASTARC provides a FASTCIRC entry point to plot circles without the need to POKE the length and start parameters.

Here's a more complete description of FASTARC and related downloads.

A Fast Circle Generator for the Apple II

Circles are common elements in graphic art, including Apple II high-res graphics. Unfortunately, the common method of drawing a circle is computing several dozen points on the circle using trig functions and connecting the points by straight line segments, which is quite slow due to the slow speed of Applesoft trigonometric functions. For example, using SIN() and COS() to compute 50 points on a circle requires 3.5 seconds on a 1MHz Apple II.

This article presents FASTCIRC, a considerably faster method of generating the circumference points in their natural order without invoking the trig functions. The time required to generate a circle depends on the radius and the proportion of the circumference that is clipped, but the typical time to draw a circle is approximately 50 milliseconds, or twenty per second--70 times faster than invoking trig functions!

Here's a fuller description of FASTCIRC and related downloads.

Floating-Point Engine

Some years ago, I obtained a Floating-Point Engine (FPE) made by Innovative Systems. This peripheral card interfaces the Apple II peripheral bus to the Motorola 68881 floating-point coprocessor, which performs floating point operations, including trig and trancendental functions, much more rapidly than software floating-point implementations on the Apple II (including the Apple IIgs).

The 68881 was designed for a 16-bit bus, and so all data transfers are two-byte transfers. This requires two 8-bit reads or writes for data transfers, which the IIgs can do reasonably efficiently since it also does 2-byte loads and stores automatically in two bus cycles. The FPE card is also supported for use on 8-bit Apples, but they require pairs of loads or stores to move data from/to the card, increasing communication overhead.

Nevertheless, hardware-supported floating-point is so much faster than software implementations that I wanted to explore options for using the FPE with my Apple //e. To that end, I wrote a package of macros for the Merlin assembler which would allow convenient use of the FPE in assembly language programs. The package consists of three "include" files: FPEDEFS is a "put" file containing the definition of the interface to the FPE and the framework to allow selective inclusion of runtime routines, FPEMACS is a "use" file containing macros which provide a convenient assembly interface to the 68881, and FPERUN is a "put" file which generates only the communication and translation routines actually used by the programmer.

Programming a math kernel to run in the 68881 provides a fairly rich environment, with eight extended-precision registors, trig and trancendental functions, hardware conversion between BCD and binary FP formats, and a bunch of built-in FP constants, so significant computation can be done wholly within the 68881--a method of use which minimizes the movement of data between the coprocessor and Apple memory. These FPE libraries are designed to ease programming the 68881 using its native big-endian IEEE-754 format, which is the most efficient way to use it. This is illustrated in N.BODY listing.pdf, which contains a short I/O test and a longer section which is the integration loop to compute gravitational orbits of N bodies (based on the AppleSoft version described below). It is presented here only as an example of the use of the 68881 computational resources. Note that most of the listing is non-code generating macro expansion, which can be turned off to remove distractions (N.BODY.S is the source file).

As an experiment, I decided to also write a program to patch FPBASIC to use the FPE to do its floating-point calculations, if for no other reason than to see how it would affect the performance of math-intensive AppleSoft programs. This was tested in a DOS 3.3 environment, since the patched FPBASIC.FPE could be loaded into the Language Card area and used from there. The more general alternative would be to burn it into EPROMs to replace the built-in FPBASIC.

Patching the AppleSoft interpreter is definitely a suboptimal way to access the 68881, because for each floating-point operation, the operand(s) must be converted to IEEE-754 format, moved to the coprocessor, the operation performed, then the result status retrieved, the result itself moved to Apple memory, and the IEEE format converted to AppleSoft FP format. As a result, I had my doubts about speeding up simple things (like floating add) significantly, but I hoped that the speedup on longer computations (such as trig functions or even divides) might make a useful difference.

In fact, it did produce modest speedups on small programs and larger improvements for math-intensive programs. Unfortunately, FP math-heavy programs are uncommon on the Apple II, and the average speedup was considerably less than for an accelerator, such as a Zip Chip. Further, the FPE card makes use of the /RDY line to pause the 6502 for a data transfer, and the Ready line is incompatible with the Zip Chip, so one must choose between these accelerators. For me the choice was easy--the Zip Chip was much more generally useful than the FPE. Your mileage may vary if, for example, you have a heavy FP workload that you can program mostly within the 68881, or if you have an Apple IIgs, which incurs less overhead because of 16-bit transfers, or you may have an accelerator which implements the /RDY line, allowing for it to be used synergistically with the FPE.

So my investigations of the FPE came to a halt, but since there seems to be renewed interest in the community in 68881-based FP accelerators, I decided to make my FPE work visible to others who may wish to build on it.

Here is a link to a ShrinkIt archive of the Merlin source files for FPEDEFS, FPEMACS, FPERUN, and N.BODY and FPEPATCH, including the patched binary file FPBASIC.FPE, and here is a link to the listing of FPEPATCH which reads FPBASIC from ROM and patches it to create FPBASIC.FPE at $3000 in RAM.

Burroughs 220 Simulator, v2.1

B220SIM v1.2 was designed to run on a 64KB Apple //e, and since 30KB of memory was occupied by the simulated memory of the B220, its capabilities were limited by the memory available to implement them.

Version 2.1 of B220SIM requires a 128KB Apple //e or IIc, and provides a more complete implementation of the B220 magnetic tape subsystem and also implements the Caltech interactive graphics extensions to the B220. The simulator runs in the Auxiliary memory bank and the main memory contains the human interface code, a buffered I/O implementation, and the simulation of the CRT graphics display and keyboard interface.

This B220SIM version supports the Burroughs Algebraic Compiler, better known as BALGOL, which was first released in 1961. This is a one-and-one-half pass compiler of the Burroughs variant of Algol 58, which is substantially more advanced than contemporary versions of FORTRAN, and even late 1960s versions. By one-and-one-half passes, I mean that the compiler reads the source in a single pass, but all library and address fixups are performed in memory by a loader (characterized colloquially as a "half" pass). This made it a "compile-and-go" system which was very well suited to batch shops and student computing. It was used as the primary student computing platform at Stanford until they installed their B5000 computer several years later. The combination of BALGOL's capability, reliability, and speed while running on a 5000-word, 5000 instructions per second machine was one of the wonders of the computing world at the time!

Version 2.1 fixes a few esoteric bugs and adds a few general features, like simulated I/O activity indicators, in addition to the major implementation changes. I also added a "trace" capability not included in the help menu, but available to assist with B220 code debugging.

Information about the B220 is available in the links provided for version 1.2 and here's a link to the B220 BALGOL Manual, March 1963 and here's a link to the listing of SIMPS.BAL, a sample BALGOL program listing showing its generated code and appended libraries.

B220SIM v2.1 and its use is described in this paper.

You can also peruse the B220SIM v2.1 listing, or you can download the B220 ProDOS hard disk image and use it yourself (or even modify it, since the source is included) together with numerous sample and utility programs. The contents of the hard disk image are listed here.

Helix Labs Bubble Memory Card

Several years ago I purchased a few Helix Labs Bubble Memory Cards for the Apple II. These were the first non-volatile solid state "disk drives" for the Apple, and they emulated a 128KB floppy drive under a special version of DOS 3.3 that they termed "BUBDOS", as well as a Pascal 1.1 driver. Its only adaptation was to the lower capacity of the bubble memory chip, 128KB instead of 140KB. Documentation has been hard to find, and the various ROM revisions complicate matters further. Later firmware versions supported ProDOS and CP/M. For your enjoyment, here are scans of the Bubble Memory Card manual, for ROM v1.2, the CP/M driver for ROM v3.00, and the ProDOS adaptation for ROM v3.40. I've also included a .dsk image of v1.2 software, containing BUBDOS, a patched FID, a card diagnostic, and an image of the v1.2 ROM.

Burroughs 220 Simulator, v1.2

If my enthusiasm for the Apple II can be chalked up to nostalgia, then this Apple II project must be nostalgia squared! I previewed B220SIM at KFest 2016, and decided to make it more widely available, just in case there are others who are similarly afflicted. ;-)

The Burroughs 220 was the last commercial vacuum tube computer, and the first machine I programmed to do interactive graphics. The B220 I used had 5000 words of 11 BCD digits each, and a rather elaborate instruction set. After numerous past musings about simulating it on my Apple II, I finally had an epiphany (all too obvious in hindsight) that made an efficient simulation feasible.

Version 1.1 of B220SIM added an I/O Configuration screen that allows the user to map simulated B220 I/O devices to ProDOS file names, eliminating the file renaming tedium that made using the simulator difficult.

This new version, v1.2, fixes several bugs uncovered by running original B220 diagnostic programs, particularly in cases where arithmetic overflows occur. In addition, the Help lines now includes the Q)uit to BASIC command, which was always there, but undocumented. Also, the Keyboard Add (KAD) instruction is now mapped to HLT, to allow the user to modify data in the A register.

Information about the B220 is available in B220 Operational Characteristics, An Introduction to Coding the B220, and Operating Procedures for the B220.

The simulator and its use is described in this paper.

You can also peruse the B220SIM listing, or you can download the ShrinkIt archive and use it yourself, or even modify it, since the source is included. I've also included a small sample program and the SNAP assembler which I wrote in 1964 and is currently the largest B220 program I have in machine-readable form. And here is the SNAP manual, a relic of the computer industry's upper-case-only days that I OCRed from an IBM 1403 listing (not recommended!). I've fixed all the misrecognitions/typos I could find, and I think I succeeded. ;-)

The ShrinkIt archive now also includes a simulated paper tape file, REGRESS.OBJ, which runs one iteration of each of the diagnostics relevant to a simulator. It is run by entering 0 1000 04 0000 into the C register and pressing Go. This provides a quick regression test when making modifications to B220SIM. Many thanks to fellow Burroughs 220 enthusiasts Al Kossow and Paul Kimpel for acquiring the vintage diagnostic paper tapes and converting them into machine-readable format, respectively.

25-Machine AppleCrate Demo

I finally got around to daisy-chaining the AppleCrate I to the AppleCrate II, creating a 25-machine "AppleCrate". I made a video of this system running RatRace, which you can view here.

DMS Drummer: A Percussion Sequencer for the Apple II

With inspiration and musical mentoring provided by Seth Sternberger of 8-Bit Weapon, I've impemented a percussion sequencer/synthesizer for the Apple II. It allows a user to create sequences as long as 255 patterns, where each pattern is one of a set of 16 musical measures. Within each of these patterns, any one of 8 percussive voices can be played at each 1/16th note boundary. In addition, the "pitch" for playing back the percussion sample can be specified, which is useful for pitched drums, like tom-toms.

DMS Drummer Version II offers the option of playing the percussion instruments directly from the Apple II keyboard or via serial input from slot 2, In addition, the pitch resampling of percussion sounds is much improved.

Like RT.SYNTH (which Seth also offers as DMS Synthesizer) DMS Drummer uses the DAC522 5-bit 22kHz pulse-width-modulation wavetable synthesizer engine, driven by a sequencer that runs in real time. DAC522 represents "silence" as pairs of 6 cycle pulses spaced 46 cycles apart, regardless of whatever the code is doing--which subroutine it's calling or which branch path it's taking. Doing "general purpose" code while maintaining a constant stream of evenly spaced pulses is pretty tricky, but it must be done if the sequencer is to keep quiet except for the desired sounds.

Seth is offering the full version on his website for $15, but the demo version is free for you to play with! It is limited to 8 distinct programmable patterns and the Save function is disabled.

Listen to this sample, created by Seth, to hear the realistic rhythm line that an 8-bit Apple II can produce! The melody and bass lines are being played on RT.SYNTH, so the only non-Apple II-produced sounds are the "explosions" (which could also have been played by SOUND.EDITOR on an Apple II!).

Apple II Networking and Parallel Computing--NadaNet 3.1

Do you have more than one Apple II computer? Have you ever thought about what you could do if they were networked together? In the early 1990s I began thinking about this, and envisioned being able to send data easily from one machine to another and being able to run programs on other Apples while sitting at my main machine.

I knew that there were networking cards available for the Apple II machines, but they were all some combination of rare, expensive, or unsupported by software--and they were all designed to support the Apple II as a client machine, not as a full peer-to-peer network participant. And none of them was usable from BASIC, the premier Apple II language for experimentation and prototyping. So I considered how one might network Apple II computers using only the I/O capabilities built onto the main board, and wondered what might be done with such a network.

I have worked on this project over the intervening years, and the latest version, NadaNet 3.1, offers a new level of usability, reliability, and performance for experiments in Apple II networking, client-server computing, and parallel computing.

NadaNet 3.1 is now available for the Apple II platform. All related articles on this site have been updated to reflect the changes in version 3.1 if they are affected. Most changes are minor (like using the new &PEEKPOKE command to lock a control block on a remote machine instead of &PEEKINC).

The biggest change for me was updating the boot ROMs on the AppleCrate II to use the NadaNet 3.x message formats--that was like the electronic equivalent of brain surgery. Since it would be quite difficult to disassemble the AppleCrate II, the sixteen ROMs were replaced in situ, about four inches in from the edge of the board, and with the "neighbor" board only 3/4" above--talk about working in close quarters!

Fast Square Root Routine for Applesoft

After spending too long putting up with the terribly slow Applesoft SQR function, I finally decided to write a faster one. USR.SQR installs as a USR function and computes square roots more than nine times faster than SQR. If you have any Applesoft programs that take a lot of square roots, this can really make them fly!

AppleCrate II: A New Apple II-Based Parallel Computer

The 17-board AppleCrate II was first shown publicly at KansasFest 2008, and now it is documented here, along with some examples of what it can do--like play "When I'm 64" in 16-voice glory!

AppleCrate Polyphonic Music Synthesizer

I have developed a 16-voice polyphonic synthesizer using the AppleCrate and a highly modified version of SOUND.EDITOR's DAC522. For details, check out SYNTH documentation, the MIDI converter program, and source.

Here's a nice 8-voice example, a rendition of In My Life by The Beatles. It stretches the 8-processor AppleCrate I to its limits, since it actually would like to play ten voices simultaneously. I implemented a "scavenging" algorithm that reassigns the oscillator that has been playing a note the longest when I need an oscillator and all are busy. It usually works, but it occasionally overrides an audible note when a lot of notes are hit together (as you can hear in this piece if you listen closely). When the music is compiled for the AppleCrate II, with 16 oscillators available, no oscillator "stealing" is required.

Here is an earlier rendition of Eric Satie's Gymnopedie for your enjoyment.

NADA.PONG: A Graphic Demo of Apple II Network Gaming

At KansasFest 2007, in response to a challenging lunchtime question, I wrote a graphic demo of the use of NadaNet to support multi-Apple II gaming. It shows a simple Pong-like game animation with the "ball" (a bouncing Apple) being passed between machines via NadaNet. This demo won the HackFest contest that year! A short video of the demo is included for your amusement. ;-)

ProDOS File Server for NadaNet

In order to support more complex applications running on the AppleCrate, and to support a shared ProDOS file system for general NadaNet use, I have written a File Server. It can be accessed by any machine on the NadaNet, regardless of whether it is running ProDOS, DOS, or no OS at all. This provides a convenient way to gain access to common files as well as a way to publish large volumes of data to other machines on the network.

The file server handles the ProDOS BSAVE, BLOAD, BRUN, SAVE, RUN, CREATE, DELETE, LOCK, UNLOCK, RENAME, and VERIFY commands, with their parameters. There are also two supervisory commands: MON, to control monitoring of requests on the server’s display, and STATS, to read various statistical counters kept by the file server.

Sudoku Solver for the Apple II

Scott Hemphill and I collaborated to create a Sudoku puzzle solver for Apple II computers. The machine language solver is Scott's, with some adaptations by me, and I wrote the interactive Applesoft front-end.

SUDOKU v2.0 now runs on any 64KB or larger Apple II with lower case and Applesoft BASIC.

It is amazingly fast! Many Sudoku solvers run on modern PCs thousands of times faster than a 1MHz Apple II, and take seconds to solve a puzzle, but Scott's solver is so time- and space-efficient that it solves puzzles in seconds running on an Apple II--all while displaying its backtrack progress on-screen in real time!

Click here to read about and download the Sudoku Solver.

RT.SYNTH: Apple II Single-Voice Real-Time Synthesizer

Based on SOUND.EDITOR's DAC522 playback routine, I wrote a single-voice wavetable synthesizer for Apple II machines that can be played in real-time from the Apple keyboard. It can be run on any Apple //e, Apple IIc (or IIc+), or Apple IIgs, and permits not only real-time performance using user-selected instrument sounds, but recording and playback of performances.

For all the details, check out RT.SYNTH documentation and downloads.

Sound Editor

In 1993, I decided to push the limits to discover what could be done with sound on an 8-bit Apple II. I was eventually able to achieve excellent sound quality without the distortion and "screech" typical of SoftDAC sound players. SOUND.EDITOR uses DAC522 for its conversion, which operates at a sample rate of 11.025kHz, and converts with 5-bit precision and 22.05kHz oversampling, so that the "carrier" is ultrasonic (for most people ;-).

If you have any 64KB, lower-case-capable Apple ][ with Applesoft BASIC, you can try it out by downloading my Sound Editor v2.2. I guarantee that you will be amazed at the sound reproduction quality. In fact, you really need headphones or an external speaker to do it justice.

Here is a .zip file containing assembler listings of Sound Editor's 2:1 ADPCM sound compression/decompression routines.

Early (1981) Hex Dump Reader

In the old days, some programs were entered by typing in hex listings from magazines. Then the problem was verifying that what you typed was what was in the listing. The obvious way to do this was to display a hex dump of what you had typed, the compare it, line for line, with the printed listing in the magazine. As you can imagine, this verification step is very error-prone in itself, and quite mind-numbing.

It is possible to do much better if you can recruit someone else to read either the screen display or the magazine listing, so that you can compare what you hear to what you see, without constantly shifting your attention from one listing to another. This was my approach, with my wife as the "willing" volunteer, until it became clear that after ten minutes or so, it was no longer "quality time" spent together. ;-)

So my solution was to write a program to read back the hex dump of Apple memory, which I could then easily compare to the printed listing.

I first wrote a short machine language program to digitize sound (to 1-bit precision) at the cassette input for later playback through the speaker. I recorded the hex digits: "One, Two, Three,..., Able, Baker, Charlie, Dog, Easy, Fox". I then used an Applesoft program with game paddles to locate the beginning and end of each spoken digit in memory, and used that info to create a table with an entry for each hex digit. The rest was easy.

In the process of going through my old data cassettes, I found this program and am putting it online for nostalgia's sake. The program is unusual in two ways: 1) it is tricky to modify, since its ending address has been extended manually to include the digitized voice table, and 2) it contains all the code that was used in its development, including the voice digitization and exploration. Just RUN the program READ.HEX.DUMP and enjoy a blast from the past!

Click here to download a ShrinkIt archive of the Hex Dump Reader.

A note on "1-bit speech":

1-bit, or "infinitely clipped", or "fuzzed" speech sounds pretty harsh to most people, but it is quite familiar to most amateur radio operators. It is common practice to severely compress a speech signal (and then limit its bandwidth to 3.5kHz) before using it to modulate a transmitter, so that the effective energy of the speech modulation is as high as possible. This effectively clips the speech into a 1-bit audio signal. (A similar but more linear compression is used to increase the volume of commercials in broadcast programs. ;-)

Early (1981) N-Body Gravitational Simulation

Here is another fun program I wrote in my cassette days--an N-body gravitational simulation with hi-res plotting of the orbits. And here is a cheat sheet to its controls. It is unusual in that it allows the user to choose a display "point of view" from any of the bodies or from the system's center of mass.

Apple I Integer BASIC Disassembly

Here is a disassembly of Apple I Integer BASIC done on an Apple II. I've attempted to correct some of the typos in the listing, as noted.

Other Links:

Here's a fun source for electronic books!

You can email me by clicking here.

Last updated on December 5, 2022.