In the last blog entry I focused on the basics of how to get an Apple //e up and running. In this entry I am going to focus on some of the more advanced issues that users may encounter with running software, programs and hardware on an Apple //e.
The Two BASICs and Memory
To understand the Apple //e in full, you must understand how the system evolved from the original Apple II and II+. When the Apple II was released in 1977, it shipped with firmware that included Integer BASIC, written by Steve Wozniak. The Apple II includes 6 sockets for firmware ROM chips and each socket can handle a 2KiB ROM chip. This firmware was 8KiB in size and came on 4 x 2KiB ROM chips. A fifth 2KiB ROM chip from Apple called Programmer's Aid #1 could also be installed but was a separate purchase.
Integer BASIC uses a > for a command prompt. Integer BASIC was soon found to have two substantial limitations. First, it lacked commands for drawing in HGR mode, which became increasingly seen as useful as memory prices fell and the Apple II added blue and orange to the original green and purple colors available to HGR. Second and more importantly, it lacked the ability to handle decimal point math, whether fixed point or floating point. Not blind to this weakness, which made writing a simple checkbook balancing program difficult, Apple had worked with Microsoft to port over its BASIC. Microsoft's 6502 BASIC supported floating point arithmetic and Applesoft BASIC was created from this collaboration between the companies.
Applesoft BASIC uses a ] for a command prompt and was originally released on cassette tape. (The first floppy Disk II drives were not released until the summer of 1978). Loading Applesoft BASIC, which replaced Integer BASIC, took several minutes by cassette deck and it had to live in 10KiB of valuable RAM. The demand for Applesoft BASIC was so great that Apple decided to make a minor refresh to the Apple II in the form of the Apple II+. The Apple II and II+ would use more-or-less identical motherboards, except that the II would come with the Integer BASIC firmware and the II+ would come with Applesoft BASIC firmware. The Applesoft BASIC firmware requires all six ROM sockets for a total of 12KiB of ROM.
Soon after the Apple II's replacement by the Apple II+ in 1979, Apple had to provide a compatibility option for people who had a II+ and wanted to use programs written for or relying on the Integer BASIC firmware. Also, Apple wanted to provide an upgrade option for II users who did not want to have to buy a new system just for the Applesoft BASIC Firmware ROMs. Apple's first solution was the Firmware Card. This was a card that plugged into Expansion Slot #0 of an Apple II or II+ and contained the firmware which was not installed on the system's mainboard. Then with a flick of a switch, the user could determine which firmware would be loaded when the system booted.
At the same time, RAM prices, which were very high in 1977, had dropped considerably so by 1979 a 48KiB of RAM equipped Apple II+ was affordable. The 6502 CPU in the Apple II and II+ can only address 64KiB of memory locations, so between 12KiB of ROM, 48KiB of RAM and 4KiB dedicated to I/O and peripheral cards, the memory map was all used up. When Apple released the Apple PASCAL programming language on floppy disks, 48KiB just was not enough RAM to run it. Its flavor of PASCAL required 64KiB of RAM, so included in the Apple PASCAL package was a Language Card. This card added 16KiB of RAM and plugged into Expansion Slot #0. It works by bankswitching, implementing special memory locations called "soft switches" which a programmer can access to swap in RAM for ROM in 4KiB banks (one 4KiB section has two 4KiB banks of RAM to swap).
Finally, when DOS 3.3 was released in 1980, Integer BASIC was totally obsolete except for backwards compatibility. As the widely cloned 16KiB Language Card had become a popular upgrade for II and II+ users, the Firmware Card had to go because both cards could not live in Slot #0. However, Apple had one last trick up its sleeve. When DOS 3.3's System Master diskette boots, it copies over the version of the firmware not on the mainboard into 12KiB of the Language Card's memory. Once you finish booting DOS 3.3 and are at a command prompt, you can freely switch between between Integer BASIC and Applesoft BASIC by typing FP and INT at their respective command prompts. Of course this will wipe out the memory of any program typed into memory, but the switch is instant.
All Apple //e systems include 64KiB of memory on the mainboard, Applesoft BASIC firmware and the circuitry to simulate the bankswitching of a Language Card. When an Extended 80-column 64KiB card is added to an Apple //e, then the main 64KiB and the extended 64KiB is bankswitched via softswitches. The Apple //e also contains 16KiB of ROM within a 12KiB addressing space by implementing bankswitching similar to that used by the Language Card.
Before DOS 3.3 - Cassettes and 13-Sector Disks
When the Apple II was first released, the only means of permanent storage the machine could use out of the box was a compact cassette. BASIC had commands for saving programs and data onto cassette and loading programs and data from cassette. The system would transmit bits serially via a crude DAC to be recorded as audio waves on the cassette and would try to read the audio signals from the cassette as decoded by an ADC. The system was slow and very touchy to use, and while the eight expansion slots of the Apple II (and II+) promised much in the ways of computer upgrades, disk drives were very expensive and required a high level of hardware and software proficiency to integrate existing technology with a new computer like the Apple II.
For 1977 and 1978, almost all computer software for the Apple II you could buy was stored on cassette tape. The introduction of the Disk II would eventually make cassettes obsolete for the Apple II by 1981, but for 1979 and 1980 quite a bit of software was released on disk and tape. Fortunately, an Apple //e has standard 3.5mm cassette audio minijacks, unlike some computers (Atari, Commodore, IBM & Tandy). So you can download audio .wav file backups of cassette programs here and use your favorite audio output program (I recommend Audacity) and start loading. I would suggest using a mono jack. Connect the audio cable from your PC's audio output to the Cassette Input jack on the Apple //e, which is the jack nearer the power supply. If you wish to save a program or data to tape, you will need to connect an audio cable from your Apple //e's Cassette Output jack (the one next to the video connector) to the line in of your PC's sound card or motherboard and record the audio using a program like Audacity. Of course, you can use real cassettes, but I suggest using a vintage cassette recorder with an auxillary input.
You may need to load Integer BASIC for many of these programs beforehand. Some cassettes will indicate the version of BASIC they use with the > or ] prompt. Unfortunately, in the unlikely event that a program freaks out at having 48KiB or more memory available (cassette programs are unlikely to know about the Language Card), there is not much you can do other than try to modify the BASIC code. Even if you only have a Disk II controller card or a drive or drive emulator and a DOS 3.3 diskette, you can still try dozens of Apple II programs on your Apple //e thanks to this archive.
In the previous article I identified the two prompts you will see in an Apple //e, the Integer BASIC prompt > and the Applesoft BASIC prompt ]. There is a third prompt which an Apple //e can produce, the System Monitor prompt *. The System Monitor lets you address memory directly and can run machine language code. Many cassette tape programs require using the System Monitor to load their programs into a specific memory location. While an original Apple II would default into showing the System Monitor prompt, the Apple II+ and Apple //e default to showing the Applesoft BASIC prompt. To enter the System Monitor prompt, enter the command CALL-151 at a BASIC prompt. To leave the System Monitor and return to the version of BASIC you were using, press Ctrl+B and then press Return.
When the Disk II was released in 1978, its format was somewhat different than the format that became widespread with DOS 3.3. In the beginning, the usable capacity of each side of an Apple II disk was 35 tracks x 13 sectors x 256 bytes per sector, which equals 116,480 bytes. The Disk II originally came with DOS 3.1, which was followed by DOS 3.2 and 3.2.1 in 1979, and these versions of DOS functioned similarly to DOS 3.3 but only worked with disks in the 13-sector format. Moreover, the Disk II Controller Card came with a pair of firmware PROMs (P5 & P6) which only worked with 13-sector disks.
When DOS 3.3 was released in 1980, it only worked directly with disks in the new 16-sector format (143,360 byte disks). DOS 3.3 also came with updated PROMs (P5A & P6A) which installed onto the Disk II Controller Card and only worked with 16-sector disks. DOS 3.3 included a utility called MUFFIN to convert 13-sector disks into 16-sector disks, but only if the disk is not copy protected. The utilities START13 and BOOT13 may also get a 13-sector disk working. DOS 3.3 came with a BASICS disk that may also get 13-sector disks booting. If you really want to explore the oldest Apple II games, you probably will need a Disk II Controller Card with 13-sector PROMs and a DOS 3.2 diskette. wDrive boasts the ability to boot 13-sector images.
Examples of Games on 13-Sector Disks
Beneath Apple Manor - Software Factory (original version from 1978, not the special version, also requires Integer BASIC loaded)
Best of MUSE
MicroChess 2.0 (requires 13-sector PROMs)
Other Venture 1: Classic Adventure - Adventure International
Hi-Res Adventures #1, 2 & 3 - On-line Systems (#1 with this title screen)
Temple of Apshai - Automated Simulations
To Enhanced or Not Enhanced Be - The Enhanced //e's Benefits and Drawbacks
Until the Apple //e Enhanced, all Apple IIs used the MOS 6502 CPU. This CPU was built on an NMOS process and while quirky found its way into most 8-bit US home computers and several 8-bit home consoles. In 1985, Apple replaced the venerable 6502 with the 65C02, a CMOS-based update from WDC that included new instructions and addressing modes. The original 6502 supported a matrix of 256 possible instructions (opcodes) but only used 151 of them. The other 105 opcodes were undefined, some did useful things, some did useless things and others did unpredictable things or crashed the CPU. The WDC 65C02 uses 178 opcodes and makes the rest of the possible unused opcodes in the matrix non-functional. Apple liked to use NCR 65C02s in its Enhanced Apple IIe motherboards, but WDC, Rockwell, Synertek and GTE manufactured 65C02s should be compatible. Some later 65C02s may need mods like this.
Unfortunately, by the time the switch was made, programmers already had five years to use unofficial opcodes. Occasionally programmers relied on these undefined or illegal opcodes. Ultima, the original California Pacific Co. release, is one such game. With a 65C02 it is impossible to shoot down enemy ships in space which is necessary to win the game.
Other original disks' copy protection, Choplifter, Seafox and David's Midnight Magic check the contents of ROM, and if the check fails (these games conclude they are running on a system with modified ROMs), then they fail. Unfortunately they were released before the //e Enhanced, which comes with new firmware ROMs. Most cracks of these games should have these protections bypassed, but if you want to use original images, you need a //e, not an Enhanced //e. Or you could boot Anti-M to eliminate most compatibility issues.
The Apple //e defined 256 separate glyphs in its Video Character ROM which can be accessed in text mode. The Apple //e Enhanced replaced some of the lesser-used text glyph patterns in the Video ROM with "Mouse Text" characters. Older programs expecting text characters at certain locations may display unintended Mouse Text characters instead.
On the other hand, upgrading a //e to an Enhanced //e is very easy. All it requires is swapping out the CPU from a 6502 to a 65C02 and updating the two firmware ROMs and the character graphics ROM. Unlike the Apple II and II+, the ROM sockets on a //e use an EPROM-friendly pinout. These ROMs are always socketed in a //e, so the upgrade is easy to do. ReactiveMicro sells an upgrade kit for $25.00. Given that it is so easy to do and emulators can emulate an Enhanced //e almost as easily as a regular //e, there are many cracks of games that will only run on an Enhanced //e. Additionally, the official Apple versions of ProDOS 2.x.x require an Enhanced //e. AppleWorks 5 and some features of AppleWorks 4 require an Enhanced //e. Fortunately the 4am Collection, the only trustworthy source for clean cracks, should not be affected, but some of the san inc cracks are. Only the firmware of an Enhanced //e can process commands typed in lowercase letters, but this is limited to Applesoft, ProDOS and the Monitor, not Integer BASIC or DOS 3.3 commands.
Slot 3 Peripherals
The Apple //e has seven expansion slots plus the Auxillary Slot, but they are not as general purpose as they may seem. The Auxillary Slot is only for memory upgrades, but some cards like the RAMWorks series can also use this slot to piggyback a graphics adapter. Certain slots have long-standing conventions about what kinds of cards go into them. The primary Disk II Controller card always goes into Slot 6. A Mockingboard or a Mouse Interface or a Z80 Softcard should go into Slot 4. Super Serial Cards. Modems and Grapplers should get to choose between Slots 1 & 2. Slot 5 is generally where a 3.5" Disk Drive Controller or a Hard Drive Controller go. Slot 7 is an alternative for the larger storage capacity interface cards but also is used by some video cards.
And then there is Slot 3, which is rarely populated in Apple //e systems. But in a way this is not entirely accurate, Slot 3 is being used, but by circuitry on the mainboard rather than in a card. This goes back to the Apple II+, which did not support 80-column text cards out of the box. This was something that had to be addressed for a business-friendly computer, and various companies developed 80-column text cards for the II+. The most popular 80-column card was the Videx Videoterm, which went into Slot 3. This card contained both the circuitry and RAM needed to implement 80-column text as well as firmware.
The Videx solution was sufficiently popular that Apple decided to simulate it with the //e's circuitry. The mainboard contains most of the circuitry and the firmware for the 80-column mode and routines, the 80-column card adds the RAM necessary (1KiB) for the video controller circuitry to display the extra characters. The 80-column text mode uses both memory I/O addresses and ROM locations assigned to Slot 3, which is why Apple does not recommend Slot 3 be used with other peripheral cards when the 80-Column Text Card or the Enhanced 80-column Text Card is plugged into the Auxillary Slot.
Despite what Apple said back in the day, Slot 3 card usage is not totally prohibited when the Auxillary Slot is occupied. Slots in the Apple II have certain memory locations assigned to them by the addressing circuitry on the mainboard. This makes it convenient for peripheral card manufacturers because they need not dedicate ICs to memory address decoding. Here is what Apple provided :
Input and Output is handled by the 4KiB of memory address space found at $C000-CFFF in the Apple II. The rest of the system is dedicated to RAM ($0000-BFFF) and ROM ($D000-FFFF). $C000-C07F is reserved for use by the mainboard I/O. Each slot is assigned 16 memory locations for whatever I/O needs that card requires, whether it be for registers, ports, buffers or a hardcoded ID. $C080-C08F was used for slot 0, $C090-C09F was for slot 1 and so on. Each slot except slot 0 is also assigned 256 bytes of memory locations for firmware ROM or memory buffering. $C100-C1FF was used for Slot 1, $C200-C2FF for Slot 2 and so on.
Each slot on the Apple //e has full access to the Apple II's addressing bus. A card can happily co-exist in Slot 3 so long as it avoids the firmware locations reserved for Slot 3, $C300-C3FF. This is quite feasible with the appropriate address logic. Examples of cards which can live in Slot 3 are found here.
Shift, Lower Case and Joysticks
One last thing that //e owners (especially Platinum //e owners) should know when they use their machines is how the Shift keys work. When the Apple II was released in 1977, the ability to display lowercase text was considered a luxury, not a necessity. The TRS-80, also released that year, did not support lowercase text but the third member of the 1977 Trifecta, the Commodore PET, did. But being that the Apple II invited tinkering and experimentation, it was only a matter of time before lowercase solutions appeared on the market.
The Apple II and II+'s keyboard's shift keys are not distinct from each other, pressing one means the same thing as pressing the other, unlike an IBM PC's keyboard where all keys have distinct scancodes. The Shift keys only function is to modify the scancode sent when number and punctuation keys are pressed in conjunction with a Shift key. Similarly, the Ctrl key only works with letter keys, modifying their scancodes for Control codes. Neither the state of the Shift keys nor the Ctrl key can be read by the CPU directly, only the keyboard controller can determine if they are pressed. There is no Caps Lock on these keyboards.
Implementing lowercase was a two-part procedure on the Apple II and II+. The first part was replacing the video character ROM with a ROM that supported lowercase text patterns or using an 80-column card which also could display lowercase text. The second part was telling the CPU that a lowercase character was required. The most popular way to do this, and the way Apple eventually adopted in the Enhanced //e Platinum, was the one-wire Shift-key mod. This required the Apple II or II+ user to connect the pin which identified the state of the shift keys to the pin on the Game I/O connector.
The Apple II's Game I/O connector supports four analog inputs (up to four paddles or two joysticks) and three digital buttons. As the third button, called PB2, rarely went used, the Shift-key mod used the state of that button to tell the system that a shift key was pressed and software which supported the Shift-key mod would react accordingly. Unfortunately this rendered the third button useless to game controllers. This is why most Apple II joysticks have only two buttons and the DE-9 joystick connector for the Apple //e and //c has lines for only two buttons.
The Apple //e and Enhanced //e does not by default implement the Shift-key mod but can if the jumper pad at X6 is bridged. They expand the number of scancodes the keyboard controller can output compared to the II and II+ and new scancodes are used for lower case keyboards. This is all good if the program recognizes those scancodes, but pre-IIe programs tend not to. X6 is not bridged by default on these systems, so PB2 can be used on these systems but you should check the state of X6 first. It is bridged by default on the Enhanced //e Platinum, and if a PB2 button is pressed on that system, there will be a short circuit which require the system to be rebooted. But if you find a program which will not recognize the lower case keys, then you need to consider implementing the Shift-key mod for your Apple //e or //e Platinum.
The Shift-key mod is mainly used by pre-Apple //e aware programs like Word Processor and Spreadsheet programs. Unlike the Apple II and II+, the Apple //e sends different scancodes for the letter keys when the shift key is pressed versus when it is not pressed and has a latched Caps Lock key which acts, when pushed down, as if you are always pressing shift when you press the letter keys, but not the number or punctuation keys. When the Caps Lock key is down, pressing shift for a letter key has no effect. Apple //e aware programs will know these scancodes and display the intended characters.
Finally, although the //e has the Game I/O internal connector of its predecessors, it also has the externally-accessible Game I/O rear connector. Joysticks for the Apple II, II+, //e and //c can all work in the //e with one option or the other. The two ports are electrically the same but the internal connector provides two additional analog axis inputs and the third pushbutton.
Jumpers and Connectors on the Apple //e
The Apple //e has a four pin connector near the video jack for a Sup'R'Mod II RF modulator or clone. There is also a single pin near it marked J12 which carries the video signal. There are seven jumper pads marked X1-X7 on the Apple //e revision B mainboard, but you should not need to touch them in normal operation except as noted above. The keyboard has a jumper on its circuit board which removes the need to press Ctrl with Reset to initiate a warm reset.
The Apple //e has a numeric keypad connector near the keyboard connector. This connector provides matrixed X and Y lines not really used on the 62-key keyboard that the Apple //e or //e Enhanced uses. Apple produced external keypads for the //e, the earlier one uses the double-shot injection molded keys of the very early //e computers, the later one uses the dye sublimated keys of the later Apple //e systems. The Apple //e Platinum's 80-key keyboard uses those lines with its built-in numeric keypad, so the connector is essentially superfluous for that system.
The Apple //e cannot tell the difference between keys on the main keyboard and that of an external numeric keypad or the Platinum's keypad. So if you press the 1 key above the letter Q, the program will act no differently than if you pressed the keypad's 1 key and vice versa. The state of the shift keys will not affect numeric keys.
Addendum 1 : Using the Apple II+
90% of what I have said in this blog entry and the previous one applies just as well to the Apple II+ as well as the Apple //e. The Apple II+ is very similar to its successor in that it has a 6502 running at 1.02MHz, usually comes with 48KiB of RAM and can be upgraded to 64KiB with that extra 16KiB being useful for many programs. It has a 53-key keyboard, which means it loses the following keys : Up Cursor, Down Cursor, `~, Tab, "', {[, ]}, \|, Open Apple, Closed Apple. The Apple II+'s firmware lacks the auto-repeat function of the Apple //e's firmware, so it instead has a physical repeat key which you press to simulate key repetition.
Apple II+ can have 48KiB of RAM on the mainboard. To upgrade to 64KiB requires installing a Language Card or a clone in Slot 0. This card has a ribbon cable with a socket connector to connect to one of the RAM chip locations on the mainboard. The RAM chip that occupied that socket is inserted into the Language Card. Without the Language Card installed, DOS 3.3 will not copy Integer BASIC into RAM.
I have already discussed what is required to achieve lower case and 80-columns capability on an Apple II+, it requires a Videx Vidterm card, a replacement Character Generator ROM and the Shift-key mod. The Apple II+ has no built-in diagnostics, so if something fails, you may be pouring over the Internet looking for a fix. Fortunately you can swap and remove memory chips to try to diagnose bad memory, only one bank of 16KiB is necessary for the system to run.
All chips on the Apple II+ are standard logic chips and can still be replaced and more importantly, they are all socketed. The keyboard is a bit trickier though, it has a few chips on a daughterboard PCB. One of them, the AY-5-3600, is the Keyboard Encoder which has the keyboard scancodes programmed into ROM memory internal to the chip. You will need to find a compatible replacement if that chip goes bad or use a solution like this. You should look for a Apple II+ with a RFI Revision mainboard, which are the most common. The RFI Revision contains all the fixes Apple did over the course of the Apple II and II+, is more stable and outputs better quality video than earlier revisions. The Apple II+ has jumpers which can be enabled to allow for monochrome PAL output but cannot show color without the assistance of a special video card.
In terms of game compatibility, the Apple II+ is not compatible with any game or software requiring either 128KiB of RAM or DHGR mode. Even though there are ways to give an Apple II+ access to more than 64KiB of RAM, the methods used are not compatible with the method in the Apple //e and later computers. Moreover, some games have detection routines that will stop the program if they detect a II or II+. Ultima V will not show the music selection menu or play music on an Apple II+ because the game requires 128KiB of RAM to play music. There is no DE-9 port for game controllers on an Apple II+, so you will have to find a joystick with a DIP-connector or make one.
Addendum II : Using the Apple //c
The Apple //c is a much more compact variant of the //e, and again, 90% of what has been said about the //e applies to the //c. The //c comes with the equivalent of a lot of extras packed in compared to the stock //e, an Extended 80-column card, a Disk II controller card and a built-in Disk II floppy drive and a port to attach a second drive, two Super Serial Cards and a Mouse Interface card. It has a volume wheel and a headphone jack for the internal speaker.
With all that functionality comes at a cost, the lack of any traditional card-based expandability. Also, the ability to load and save programs by cassette port is gone, so the ability to go backwards with the //c is not as strong as with the //e. All Apple //c computers use the 65C02 CPU, so compatibility with older software which uses illegal opcodes of the 6502 is nixed. Older software relying on the contents of older firmware will not recognize the //c's firmware. Joysticks and mice have to fight for the single port they can use. You cannot use the Macintosh Mouse M0100 with the //c without an adapter, but other Apple mice with a DE-9 connector should work. No numeric keypads available either.
If you wish to boot an external drive on the Apple //c, you will need to install an adapter like this. This is essential if you wish to use a floppy emulator. There is no expansion for sound cards, but a South Korean developer made a Mockingboard that installs inside the //c. It should be compatible with most Mockingboard games, but Ultima IV and Zaxxon require special patched versions to work with this device. External Mockingboards (Mockingboard D), connected via serial port, are not generally compatible with games. The keyboard switches which the Apple //c's keyboard uses are not that great, except for the Memory Expansion //c, which comes with much nicer ALPS Cream switches. The keyboard key above the keyboard switches between the QWERTY and the DVORAK layouts, something that required solder on an Apple //e.
Apple //c computers cannot output PAL color, even ones sold in Europe and Australia, unlike PAL //e computers. There is a connector for an external monitor, and this was used for a very rare LCD panel, an RF Modulator and more recently a VGA converter. Unlike an Apple //e, the Apple //c can boot into 80-column text mode with a switch above the keyboard. However, an Apple //c uses an external "brick on a leash" for a power supply, so you just cannot plug in a regular PC power cable.
No comments:
Post a Comment