This describes a project for the Apple II to have a simple and robust reboot option. The intent of this post is to be repository for describing the project, rationale, solutions considered, and status of the project.
I have spent many months chasing affordable options to perform a simple and reliable reboot. In a very real way the project has become my “White Whale”.
The post will be updated as more is learned.
GOALS: The goal of the project is to have a single button reboot any Apple ][+ or //e without modifications to the base system. Mezzanine boards are ok but chip modifications are not. The solution should not present setup menus that require boot up configuration, multiple keystrokes, or menus when “the button” is pressed. One button to force a simple and complete reboot of the Apple II. See more details and rationale for these goals below in the ‘Background’ section.
STATUS as of August 2024:
After a year of “hunting” I am officially declaring victory on this project! The solution from my European collaborator is perfect. I even modified the eprom with some functional and cosmetic enhancements. In the end, it was what I call the “Wildcard” approach that won the day for simplicity and flexibility. Special thanks to Ralle and his patience in educating me on the design behavior of IO cards for the Apple II. Here is Ralle’s GitHub page for the project: https://github.com/rallepalaveev/A2RESET
STATUS as of July 2024:
Another person (a really nice guy from Europe) contacted me about the project and suggested an approach more like the ‘wildcard’ but based on his proven modern design for a memory expansion card. Ignore that the base design was for memory expansion, the bigger point is he has a working IO card that allows him to smartly interact with the Apple II via the IO slot. The design uses a single PLA making the logic on the card very clean. It also allows us to have a custom EPROM on the reset card with my code to reset the Apple II. Basically it makes my reset code available to the 6502 in firmware on the IO card and when the external reset button is pressed and instructs the 6502 to reset itself using my firmware instead of the Apple II. It mostly works but I am still testing and looking for ways to better understand the operating principles of the PLA.
Firmware Operations: The reset vector is set to $FFE3 – this is at locations $FFFC (E3) and $FFFD(FF). When the button is pressed, reset goes low and at the same time the card code is enabled and the original ROMs on the motherboard are disabled. When the button is released, the reset line is also disabled and the processor takes the address $FFE3 from the reset vector at $FFFC-$FFFD which is $FFE3 – the start of the program.
$FFE3 – $FFEC moves the code $FFF1-$FFFF to locations $03F1-$03FF. This is done, because the program needs to disable the ROM on the card and re-enable the ROMs of the motherboard. It has to be done from the RAM, because if it is done from the card ROM location, the moment the ROM is disabled, the code will crash as it will disappear
Notice also that addresses $03F3 and $03F4 are taking the values of $FFF3 (30) and $FFF4 (AD), which disrupts the reset checksum – EOR with A5
$FFEE – performs a jump to the new location $03F1
$FFF1-$FFF6 ($03F1-$03F6) – peeks $3003 twice – this peek disables the card and enables the motherboard ROMs
$FFF7 ($03F7) – jumps relatively to the address, which is stored in $FFFC-$FFFD (the reset vector). As the motherboard ROMs are now active, it will jump to what the original reset vector points; usually this is FA62. There, as $03F4 is not the correct result of $03F3 and A5, the program will perform a cold restart procedure.
STATUS as of February 2024:
Someone contacted me with a rather simple design we decided to prototype. The prototype almost worked (his lab, I never touched it). There were apparently a couple of simple routing errors and required a bodge wire or two and the diode was maybe reversed. We both got sick and busy; what remains in my hands is the original board design.
As I understand it the board did some clever things by hardwiring the memory phase timing using TTL delays and hardcoding the clearing of the soft reset vector. There are also some theory of operation notes on the schematic in blue font.
As of this moment I have to consider this effort on hold till I hear back from the designer or find someone interested in partnering with me.
In parallel I have been looking at a Wildcard clone produced several years ago. Note the clone is of a Wildcard “1” and a Wildcard 2 was produced in the late 80’s. The original WC1 has known limitations fixed with the WC2. I don’t know yet if the WC1 clone has similar limitations. Still being investigated. See more comments on WC based issues below.
BACKGROUND: The motivation for this project includes ……
(1) The solution must be compatible with the nature of a 7 year old child
We have an Apple II lab of 6 machines, a mix of II+ and IIe. Some have joysticks. We do not have any GS machines. The collection started from my own obsession with Apple II but has now become an education lab for 7-10 year old youth. We introduce the kids to computing fundamentals and software development. Without apologies, the raw and transparent nature of the Apple II nurtures a deeper grasp of computing and software. Without this foundation, their only exposure to computing is icons on an iphone. So the FIRST important nuance is that I am dealing with 7 year olds, they are my customer. I want to focus on core computing and software; not “3 finger salutes” unique to the model of the computer or the state of the computer. As further context, we encourage exploration….floppies are constantly flying and rebooting the Apple is done frequently. Another consideration due to age is patience…. if things are not working they quickly get frustrated and impatient…. the very opposite of the experience we want to create. The software titles are too numerous to list but include mostly educational titles and games. The older kids are introduced to a number of Beagle Bros utilities to create software. There are hundreds of titles in total and I encourage exploration.
(2) Power Cycle Reboot.
The Apple PSU is an early implementation of switching power supplies and is fragile. Frequent on-off cycles and the accompanying power surges to the PSU contribute to lower MTBF. I have repaired them many times. Also, the rate of decay of DRAM contents is unpredictable and slow. Even a 10 second off cycle is frequently not enough to get a clean reboot. In short, power cycling the PSU is unreliable and reduces PSU MTBF.
(3) Reset Vector in DRAM and requirement to clear memory as part of a reliable reboot
Apple supports a reset vector in memory (introduced primarily as a form of DRM) which allows software authors to bypass a simple and clean reboot. Only the reset vector needs to be cleared, but I’ve assumed it’s just as easy to clear the lower 48k of DRAM as part of the reliable reboot button. This issue links to #2 and the unpredictable decay time of DRAM. The nature of dynamic ram is very different from the static ram we use today. Dynamic ram has an uncanny ability to hold its charge for a vey long time. It is fairly common to power up an Apple II only to see it crash immediately because the reset vector in dram has some decayed content that sends the cpu into never never land. Crazy but true. This is why I want to clear memory before jumping to the reboot code in prom
(4) Avoiding customization of the Apple II
This is a strong want. As an Apple II enthusiast I want to avoid modifications to the machine. Not just for religious reasons, but also because some solutions result in different modifications for different Apple II revisions. I would like to have a single solution that works for all the machines in the lab.
(5) modification of the system ROM to alter the core logic of system reset.
Custom system ROMs or adding a ROMX to each machine would allow me to do a clean reboot but again I am fairly sure there would be different images for different machine revisions. ROMX is a bit intrusive to the 7 year old experience, still violate my desire to avoid customization, and turns ROMX (an excellent product by the way) into an expensive 1 trick pony in my environment. This option may need deeper investigation on my part.
(6) Macro Keyboard
Creating the ability to inject keystrokes to cause the clean reboot would actually be a cool feature to have. In fact I have a macro keyboard developed for the Apple II on one of my machines but it would require customization of the onboard keyboard interface and any macros would need to know the state of the machine prior to running
(7) I have begun to think I am making my IO card reboot idea harder than needed. Because each IO card has ROM space mapped to main memory the only thing I need to do is cause a NMI and let the 6502 execute the program in peripheral ROM. The only logic I need is to properly capture the button press and trigger the initial NMI and associated control lines. This is greatly over simplified and apparently naive on my part with respect to the control of the 6502 program counter.
(8) The Pico based solution very is attractive because it has current development that can be leveraged, has up to date people working with it, and paves the way for potential future extensions but from a technology perspective is more complicated.
REFERENCES:
Github link to PLA based design
Apple II Interfacing & Digital Experiments
Decoding IO Address for Peripheral Cards
GitHub to possible solution using PiPico