Apple II+ hard reset

I've wanted this for a long time.   WILDCARD has the capability but requires scrolling through the menu to select "clear memory and reboot".  Because of the reset vector in ram I believe all Apple resets are soft so a "RESET!" is what's required.   Tell me I am wrong.   This means we actually need to clear a few bytes of memory before initiating a "hardware" reset.   I'm thinking this is a good candidate for an esp32 softcard project.   But yes I also would like to have a push button RESET!

Every Apple II already has the "hardware switch" you're looking for - it's called the Reset switch. While you may need to also hold down the ctrl key, hitting Reset always causes the CPU to execute the reset routine in ROM. Just like powering on the machine.

The culprit preventing you from doing what you want is the Autostart Monitor. This was an improvement to the original F8 Monitor ROM and one of these improvements was the addition of a "soft reset" vector in RAM. This allowed for a warm start function that treated Reset differently after the machine was first powered on. It also allowed programmers to disable the normal action of hitting Reset. Very enticing to commercial (i.e. game) publishers to help prevent copying.

The solution for you would be to create a modified Monitor ROM that always performs a cold reset. You could burm this into an EPROM but then would need an adapter socket to use in an Apple II. A better option might be the ROMX which makes it very easy to modify the ROM while giving options to quickly switch to alternate images. You'll probably also want to use "kiosk" mode by changing the BootDelay to 0 on the ROMX.

Jeff, it might be a good idea to add a little blurb when you plug the ROMX to the effect of "I designed the ROMX, and receive a cut of every unit sold".

Your ROMX-related posts come off as a bit disingenuous otherwise; you're not a random happy end-user of the ROMX, but rather someone who stands to profit when someone takes your advice.

cryu wrote:

Your ROMX-related posts come off as a bit disingenuous otherwise; you're not a random happy end-user of the ROMX, but rather someone who stands to profit when someone takes your advice.

 

While the ROMX was conceived and developed right here on Applefritter, I must admit that not everyone would be aware of my collaboration with Dean Claxton on this project. Nevertheless, my posts are not necessarily disingenuous. I'm just pointing out what I truly believe would be a good solution for the OP.  

At less than $50 for the ROMX, I can assure you that neither Dean, myself, or ReActive micro are getting wealthy off this endeavor. You are correct however that while not "random," I am a happy end-user as well. But your point is well taken. 

tony359 wrote:

If someone feels like amending the ROM so the RESET key has that effect, it would have my eternal gratitude :)

 

 Hi Tony,

Sorry I didn't recognize you from your earlier thread on the Europlus. Since you already have a writable ROM replacement, here is a one byte patch that should answer your need:

Change the byte at $FA89 from $A5 to $00. That will defeat the "warmstart" function and every ctrl-reset will now do a cold boot!

It sounds like you want a "kiosk" where people can easily REBOOT by pressing the Reset key. But, would you still want to be able to do a normal RESET?

On the Apple //e, it's Control+OpenApple+Reset to REBOOT, and Ctrl+Reset to RESET.

I was thinking that if it's an Apple II+, and you have the shift-key modification, it wouldn't be too difficult to make Shift+Reset (or Ctrl+Shift+Reset) do a reboot and still have the Reset (or Ctrl-Reset) do a RESET, or vice versa.

I think having a ROMX to play around with this sort of stuff sounds more and more appealing.

If it drops to basic with pressing reset, doesn't a PR#6<return> accomplish the same thing as powering it on and off? If so, perhaps a sign telling people to do that after hitting reset would solve the issue? I've never dealt with anything prior to IIe, so I could be completely wrong in my suggestion. I'm spoiled with my OA-ctrl-reset. 

tony359 wrote:

how do I get to Basic if hitting "RESET" reboots the whole thing every time?

 By having a disk that just boots to Applesoft.

Or you could add a switch that reverts back to the standard ROM (insert disingenuous plug for ROMX here :)

nick3092 wrote:

If it drops to basic with pressing reset, doesn't a PR#6<return> accomplish the same thing ...

 That would work with the standard warmstart entry. But most commercial software change this to something else, either to restart their program or do ANYTHING BUT drop to Basic!

Looks like you have Applesoft + Autostart Monitor in the 2nd bank of your EPROM. So the offset to the byte that needs to be changed is $4000+$3A89 = $7A89.

Modified image file uploaded to your OneDrive link.

I can't imagine why changing that single byte would cause it not to boot. Perhaps something in the way you loaded/burned the EPROM?

Here's a video of the exact file I sent you loaded into a ROMX card so you can see how it should work:

This is indeed strange. I've uploaded another file which modifies your original image with a different byte. This should work normally except that when you power on it will say "ARPLE ][" instead of "APPLE ][" at the top of the screen. Let's see if this works.

tony359 wrote:

working fine :)

Ah OK. So I think the issue is that changing FA89 to 00 was a bad choice. Anything other than A5 should do what you want. But it turns out that the random power up values of RAM locations $3f3 and $3f4 are likely to be the same. And EOR'ing with 00 bsically leaves the original value the same.

So the solution is to use any other value EXCEPT 00! Change FA89 to, say 44 and it should work now.

tony359 wrote:

One thing: I thought CTRL-RESET would initiate a cold-boot, but I see that even just RESET does that. 

If RESET works by itself, then your keyboard encoder is set to do that. There is a switch (S1) on the board that determines whether you need to hold the CTRL key as well. Usually it is set to require that but yours might be in the other position (or possibly not even there) and thus allows RESET to work by itself. Unfortunately, there is only one RESET signal and it works in one of the two ways above. You cannot have RESET do one thing and CTRL-RESET do something else (at least not without wiring up the CTRL key to something like one of the game port switch inputs and modifying the ROM even further).

I operate an Apple II lab for young kids with a mixture of models and ROM versions so the custom ROMX does not have a lot of apeal to me.  Dont get me wrong.... I think ROMX is great.  There was a card called the "wildcard" that did almost exactly what I need for the kids in my lab.  It had a momentary contact button that would activate the card, present a simple menu, and allow several options for how to preserve memory.  the primary use of the card was to bypass all the DRM on floppys and allow users to capture and reload all of memory.... so they could preserve (and yes, share illegally) games and such where the disk copy protections were very creative.  BUT one of the menu items on the card was "clear memory and reboot". This is the closest thing to a true hard reset I have seen for the Apple II.  Even power cycling failed due to the long time it takes for DRAM contents to decay and as we've been discussing in this thread, there is a reset vector in memory that plays a role in what path the reset logic takes when one of the several multikey options are pressed.  I know its kind of silly, but I want the kids to have a seperate mechanical button that clears memory and jumps to the reboot logic in system ROM.  No menus, not thinking, just a 'hard' reset.  After several rabbit holes I believe the Wildcard approach is my best bet but do not have the skills to build a modern version.  Using todays tech I believe the "easiest" way to do this would be with a PiPico on an IO card, it is fast enough to do DMA on the 6502 memory buss. I am willing to be wrong about the PiPico approach; eeprom and a couple bus transceivers may be all that is needed for this "one trick pony".   I'd be willing to pay someone to help make this happen..... I want to build 6 of these cards.  

The Wildcard and Snapshot cards do come up once in a while but they can be pricy and finding 6 of the would take a while. I've seen a few attempts to clone these but never seen them become available. And to be honest, they are much more complicated for what you want to do. And designing one with a Pico, DMA, etc. is also way overkill.

Let's start with exactly what you need. Is it really necessary to completely clear all memory? Would something like the //e open-apple reset work?

Is the approach described above only lacking a simple way to perform soft reset vs. hard reset?

While the ROMX does eliminate the memory decay issue that you describe and can also be run without displaying a menu, it too might be overkill unless you have use for its other features. And while we do have a new board in the works that uses NMI to switch to a given image (e.g. Senior PROM), this would take a small tweak to have it clear memory and then do normal reset.

But I believe you can get what you want with nothing more than a custom F8 ROM image. This could go directly into the motherboard socket, perhaps on a Language card (with trivial modification), or on something like a MultiROM board. I could also help you design your own board if you really want. Just let me know exactly what machines you need this for (model, memory, 16K RAM card present and type, other slot cards, etc.)

David Mutimer did a "reboot" of the Wildcard a few years ago.  Perhaps if there is demand maybe he could produce some more or at least PCBs that someone else could populate.  Or maybe someone else could replicate the Wildcard board.  It wasn't a particularly complicated one.

softwarejanitor wrote:

David Mutimer did a "reboot" of the Wildcard a few years ago.

 

Yeah, there's a couple of these available here. It is much simpler than the Snapshot or the later Wildcard 2. But it still seems a bit overkill and more expensive for what the OP needs. Nevertheless, barryhills, you might want to grab one of these or contact David to see if you can get more. Or just clone it yourself!

If you have an authentic Language Card from Apple, or a clone 16K card that includes a ROM socket (eg: UNITRON), then you really should go with the suggestion from @jeffmazur in comment 28.

Here's a diagram showing where to make the "trivial modification" he was suggesting.  The diagram adds a further option to use a 2732 EPROM so that you could switch between two banks of F8 firmware, one for "clear-on-reset" and the other for "standard".  (It's also easier to source 2732 EPROMs than 2716 EPROMs, another benefit!)

Language card 2716 or 2732.png

Although it sounds like an interesting experiment, the original Wildcard is loaded with hardware-compatibility issues that might make it unsuitable for your purpose:

• Wildcard will just hang/crash if you activate any expansion card that uses the IOSTRB bus signal and leaves its firmware enabled.  This includes 80-column cards (eg: Videx VideoTerm), advanced printer cards (eg: Grappler+), and any Apple //e with a card installed in its AUX slot.
• Wildcard requires a secret keypress to activate its menus -- otherwise it just hangs until the user presses the right key.
• Wildcard adds a non-standard 6800 ohm pullup loads onto address bus signals A0, A7, A14, A15, which could affect the stability of the address bus.  This is a "dirty hack" that they got away with because other cards don't do it.  (If two cards used this hack, neither would work while the other was installed.)

S.Elliott wrote:

Here's a diagram showing where to make the "trivial modification" he was suggesting. 

Thanks for the info on the Wildcard. I never had one and was not aware of what tricks they played like adding pullups to the address bus!

However, the trivial modification I was referring to was actually disabling the F8 (E)PROM on the card. They use  the INH line to override the motherboard ROM and that can conflict with other ROM replacements like the ROMX or MultiROM. See pages 14-17 of the ROMX Installation Guide. There are pros and cons to your modification that always switches to ROM on Reset. Some software might not like that!

I made a simple cold reset card: https://github.com/rallepalaveev/A2COLDRESET/

I made yet another card - A2RESET. It now has 3 external buttons:

1. RESET - this is just a standard reset - pulling the reset line low, may seem redundant, but I hear some early machines do not have a reset button, so may be useful.

2. COLD RESET - this is the same function as my earlier post - it scrambles $03F4 checksum and jumps to ($FFFC), effectively mimicking power on reset.

3. WARM RESET - this button puts $FF69 in the vector $03F2 and the correct checksum in $03F4 and then jmps to ($FFFC), so the computer drops into the monitor.

Link: https://github.com/rallepalaveev/A2RESET

This is a great solution.

While it may be an immensely useful addition to have a keypress Cold Reset option on an Apple II+, haveing the regular "warm" reset (as oppised to your modified warm reset) is also immensely useful - to break out of a BASIC program in a loop, to quickly exit the montitor, to cleanly exit the VIDEX 80 column screen, etc.  There are dozens of needs for the regular RESET and opting it out to do a cold reset without the former option doesn't make sense to me.

I'm going to look into that card of yours.  

I think he means that the regular Reset button will do the Warmstart as usual if it is set up. The third button should be called Monitor not WARM RESET

BTW, be aware that there will be issues when a Language Card (and even most 16K cards) are installed in the same machine.

Eventually my solution has a single button with 2 actions:

1. Single push - cold restart: disrupts $03F4 and jumps to $FA62.

2. Double push - drop to monitor: sets the reset vector to point $FF69, corrects $03F4 and jumps to $FA62.

The name of the GitHub repo is A2RESET.

I am interested to know if anyone experiences issues with a language card. I don't expect any, but do tell.

rallepalaveev wrote:

 

I am interested to know if anyone experiences issues with a language card. I don't expect any, but do tell.

If the CPU is running code from a Language card, or from a ROM card while /INH is active by another card when your card's reset is pressed then the crash is imminent. This scenario includes an Integer or FP BASIC loaded in and active from the language card, running other language like Pascal, or tools like Boot Tracer, etc that run code extensively from the Language card.

If you're following my "Mythbuster" series on Facebook, here's a snippet from the next installment. It seems worth posting here as it relates to the current conversation:

"...which brings us to the first myth to dispel: "all Language Cards and 16K RAM Cards work the same so they are interchangeable." This is not true on many levels. For example, the Language Card has an F8 ROM, many boards treat the effect of a Reset differently, and compatibility with other ROM and RAM cards is all over the map. Let's see how we got here.

Early Apple II's all had Integer BASIC on the motherboard along with what we now call the non-Autostart ROM. When the II Plus came out, these were replaced with Applesoft and the Autostart ROM. In between, we had Applesoft on cassette tape which was loaded into the motherboard RAM. This was soon followed by the Apple II Firmware (ROM) Card which had the Applesoft and Autostart ROMs on a card that plugged into Slot 0. This essentially gave you both an Apple II and II Plus in the same machine with a switch to determine which would be active after a Reset. Software control was also added that allowed DOS to select the appropriate language when a program was loaded. In a glimpse of future-proofing, it is worth noting that this board also had provisions for using the DMA lines of the expansion bus to allow orderly control of similar ROM replacement cards in higher numbered slots (to a degree).

When Apple introduced the Pascal Language System, they realized that by adding another 16K of RAM to the computer, they could replace the motherboard ROM with whatever "firmware" they chose to load into that RAM. This quickly became the de facto standard for most Apple II's - the 64K machine. The original Language Card also contained an Autostart ROM which would always replace the motherboard's F8 chip. This had the advantage of giving old Apple II's the new Autostart functionality without having to swap chips. But since there was no simple way to disable this ROM, it would come back to bite developers of later cards. Unfortunately, it is also notable that Apple did not carry forward the "ROM-sharing" mechanism from the earlier ROM Card. And importantly, this board only had a simple power-on reset circuit to select the motherboard ROM when first turned on. Subsequent Resets would leave the card in its same state (enabled or disabled); this meant that the actual Reset vector could come from either motherboard ROM or the Language Card's RAM. More on this later.

The market was soon filled with many clones of the Language Card which eliminated the ROM and were just called "16K RAM" cards. Some even eliminated the usual DIP jumper that was required to operate the Dynamic RAM on the board. What followed next was a slew of boards that offered 64K, 128K, and even more RAM to expand the computer's capabilities. But developers often took different paths in how these boards operated leading to another myth: "all RAM cards revert to the motherboard ROM on Reset." The Saturn 128 card is a good example because it has been "rebooted" several times. Most of these new designs also lack the ROM-Sharing control as did the Saturn board. But while the original Saturn card followed Apple's lead with the Language Card - a Reset would leave the RAM/ROM selection unchanged - many of the rebooted designs always restore access to ROM on Reset. Since the IIe and later machines with MMU chips also do this, this is not surprising. But it certainly calls into question anyone who claims 100% compatibility with the original. And that can lead to unexpected results with some software. Worse yet, without the ROM-Sharing protocol it can result in bus contention.

Bus contention, or bus fights, happen when more than one device tries to drive the data bus at the same time. When this happens, the data is probably going to be corrupted, large currents can be generated between the competing devices, and hardware failures are even possible. Unfortunately, we still see new boards being designed today that can still cause these ill effects."

jeffmazur wrote:

Most of these new designs also lack the ROM-Sharing control as did the Saturn board. But while the original Saturn card followed Apple's lead with the Language Card - a Reset would leave the RAM/ROM selection unchanged - many of the rebooted designs always restore access to ROM on Reset.

 

My old Staurn clone fully complies with the orginal Saturn card's behavior on reset and I think it is important for debugging and cracking advantages to be able to replace the reset vector:

https://www.tindie.com/products/retro_devices/apple-2-ii-plus-e-iie-2e-saturn-rocket-128k-ram/

I looked at the design files I agree that language cards completely take over instaed of the ROMs on the motherboard and this will cause a conflict with the reset card. So caution must be exercised when used.

I can look at the possibility to use DMA to change a single byte - $03F4, and then perfom reset. Than should be the cleanest way to perform a cold reset.

retro_devices wrote:

I think it is important for debugging and cracking advantages to be able to replace the reset vector:

 

I agree.

rallepalaveev wrote:

Than should be the cleanest way to perform a cold reset.

That could work. Would you perform a hardware Reset or just JMP(FFFC)?

If someone has a clone that uses EPROMs (or uses an adapter/EPROM combo), the cleanest way is to use our Coldstart image. Just use the F8 portion from $2800-$2FFF in this file to burn the EPROM. This won't take up a slot either.

Certainly changing a singe byte in the ROM can do the trick - for instance changing $FA8B form F4 to F3 would do the trick. However, the task is not to mod the computer...

Just finished a new card, performing cold reboot of Apple2 by changing $03F4 with a DMA cycle and then performing reset: https://github.com/rallepalaveev/A2RESET/blob/main/A2DMA-RESET.jpg

I now have 4 of these and they work fantastic

Thank you!!!

rallepalaveev wrote:

Just finished a new card, performing cold reboot of Apple2 by changing $03F4 with a DMA cycle and then performing reset

The A2DMI is vast improvement and a valiant effort. It will work in 90% of Apple II configurations. To achieve 100% you'd need to address 16K RAM cards that do not disable on Reset (like the Saturn 128K). Let's finish the job and use DMA to also disable ALL 16K cards with an access to $C081. Then you'll have a bullet-proof solution!

jeffmazur wrote:

Let's finish the job and use DMA to also disable ALL 16K cards with an access to $C081. Then you'll have a bullet-proof solution!

You cannot dsable "ALL" RAM cards this way. Only the RAM card in slot #0 can be disabled via $C08x. Up to 7 more RAM cards could be installed in the remaining slots. I am fine with the old-fashioned way of powering OFF/ON to reset the computer instead of wasting one slot and still pressing a remote non-standard switch.

While the solution to the original post was provided by post #24, this thread has taken on a new life of its own. While I agree with retro that "wasting" a slot and the use of an external switch is not optimal, the use of the power switch to perform a cold boot has its own issues. It places extra strain on the power supply (especially the power switch, if not controlled externally with a power strip) as well as the motherboard and all expansion cards. It can also lead to the dreaded "phantom RAM" issue requiring a longer off cycle before turning back on.

And while multiple RAM cards can indeed be placed in a single machine, for the reasons outlined in post #39 this is not a desirable configuration. Without true bus support (or even an accepted protocol) this can lead to many problems if not even hardware failures. While no solution may address all of these issues, we found the ROM++ firmware running on a ROMX+ to be a very useful option to allow cold booting (using the existing Reset key) as well as a host of other improvements to the standard Autostart F8 monitor ROM.

*Usual disclaimer here that I am part of the ROMX team and may not be truly unbiased.

jeffmazur wrote:

While the solution to the original post was provided by post #24, this thread has taken on a new life of its own. While I agree with retro that "wasting" a slot and the use of an external switch is not optimal, the use of the power switch to perform a cold boot has its own issues. It places extra strain on the power supply (especially the power switch, if not controlled externally with a power

The power switch on Bulgarian Pravetz 82 clones is very rugged and manufactured by Bulgarian no longer existing electrical/electronics industry, I never saw one damaged from regular use, I still have many new spares, just leftover after devastation of the country's industry. Most likely it was military grade and is convenient and larger too. If something else burns from power cycle then it has reached its lifetime already and is to be replaced anyway. Multiple RAM card configuration is well supported by Locksmith 6 for example and is perfectly legal. Another example -- at least 2 RAM cards are needed, one for Boot Tracer, and one for the debugged program in case the latter needs a language card. Disk Muncher also utilizes multiple RAM cards as far as I remember.