Apple II+ hard reset

retro_devices wrote:

If something else burns from power cycle then it has reached its lifetime already

 I'd argue that a higher percentage of electronic failures occur when power is first applied. So avoiding multiple unnecessary power cycles is a worthy practice. And the issue of multiple RAM cards is best resolved by making sure that all cards in slots other than 0 do disable on reset. Or rallepalaveev could just DMA $C091...$C0F1 to be absolutely sure.

jeffmazur wrote:

retro_devices wrote:

If something else burns from power cycle then it has reached its lifetime already

 I'd argue that a higher percentage of electronic failures occur when power is first applied. So avoiding multiple unnecessary power cycles is a worthy practice. 

Yes, mainly poorly designed semiconductor circuits can be succeptible. And not only electronics, but electrical like incandescent lamps are more vulenrable to much higher currents during power on cycles. Some CRT appliances even in the off state maintain powered heaters of their CRT tubes. But operation of computer devices is based on billions of internal binary switchings per second of their internal gates/circuits equivalent to power on/off cycles ;) To keep an Apple2 computer constantly switched on or refrain from power recycling because it may  fail is not very wise I think ;)

I would strongly disagree with that conclusion. There is a kernel of truth in it (the current pulse from gates switching is rather severe—milliamps over picoseconds in modern computers, somewhat less in the Apple II where the time constant is in nanoseconds. This dI/dt produces powerful magnetic fields) but in practice, there is much more stress on equipment from repeated heating and cooling cycles. Different coefficients of thermal expansion cause solder joints to crack and can make pins climb out of sockets. There is always a current in-rush when power is applied: the NTC thermistor is only partly effective at limiting damaging surge current, and it won't help at all when you toggle the switch off and on.

robespierre wrote:

I would strongly disagree with that conclusion. There is a kernel of truth in it (the current pulse from gates switching is rather severe—milliamps over picoseconds in modern computers, somewhat less in the Apple II where the time constant is in nanoseconds. This dI/dt produces powerful magnetic fields) but in practice, there is much more stress on equipment from repeated heating and coo

OK, keep your computers switched on, with at least possible power cycles if you think you are right. Or even worse don't switch them on fearing they will fail. I will switch mines like I did for the past 40 years whenever I wish to and deem necessary. I am confident enough since I can repair them freely, but I am also confident enough there will be no need. If you wish you can even make a technical  logbook like of an airplane for your apple2s and fill in there power cycles (startups). Just a hint -- airplanes also log running time ;)  

retro_devices wrote:

The power switch on Bulgarian Pravetz 82 clones is very rugged and manufactured by Bulgarian no longer existing electrical/electronics industry

Unfortunately Woz did not clone the Pravetz 82 when making the Apple II! If only the Bulgarian's had been first, we all could have benefited from that switch too! 

While the quality of the compoents found in the authentic II systems were top-of-the-line, the power switch on some early II systems has proven to be a weak link. This swich is also slightly different in size that there's no direct replacement.  Because of this, some will do whatever they can to avoid flipping the switch at all costs!!

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!

The dma reset card is a very simple, hardware only solution, driving reset after the single dma write cycle. So if access to another address is needed, then it may require a more complex circuitry, potentially involvong an MCU to generate addresses and access different locations before asserting reset. I was relying on the presumption that the reset line would activate the standard ROM of the computer. My RAM card for instance does that - it disables RAM reads upon reset. So if some RAM cards remain active for reading upon reset, it means that reset beahvior is never predictable with those and depends on the content of the RAM card?

Yes, that is how the Apple LC and Saturn card work. Unless you disable them with $C081. Which is what boards like Wildcard do.

rallepalaveev wrote:

I was relying on the presumption that the reset line would activate the standard ROM of the computer.

Nope, Aple's design-philosophy was different in 1979.

Apple's original vision was that the Language Card would function like customizable ROM.  For example, an original Apple II could load Applesoft into the Language Card to function exactly like a computer with Applesoft ROMs, even after pressing RESET.  In order to initialize itself without connecting to RESET, the Language Card schematic has a "POC" circuit (aka: "power-on clear") that activates exactly once at power-up.

Beyond BASIC, another example is Apple's implementation of Pascal 1.0, which used the Language Card to remap the ROMs and then required the user to RESET the computer in order to boot into the new language.

The inability to RESET the Language Card caused problems -- the computer could become inoperable if the Language Card was erroneously activated, or if its contents became corrupted.  So Apple abandoned that approach when they designed the Apple //e, which reverts to its built-in ROM whenever RESET is asserted.

An Apple //e can't boot Apple Pascal 1.0 because of that RESET revision.  Pascal 1.1 eliminated the RESET step and just asks the user to press RETURN to start the OS.

rallepalaveev wrote:

My RAM card for instance does that - it disables RAM reads upon reset. So if some RAM cards remain active for reading upon reset, it means that reset beahvior is never predictable with those and depends on the content of the RAM card?

Absolutely right: with its original design, reset behavior depends upon the contents of the RAM in the Language Card.  If Language Card RAM didn't contain a valid RESET routine then pressing RESET would transform the Apple II into a non-functional-brick.  Until the user switched-off the power.

So you made a good design choice by making your card switch-off on RESET.  Your card won't be able to boot Apple Pascal 1.0 (see previous comment), but I can't think of any other compatibility problems.  And it's a worthwhile tradeoff, as Pascal 1.0 became vanishingly-rare after Apple released the //e.  (The //e can't boot Pascal 1.0 either.)

The unpredictable RESET behaviour was so annoying that users sometimes modified their RAM cards by adding a RESET connection.  Pictured below, this Super Expander Plus RAM card has a silicon diode soldered to slot edge 31 (RESET) to deactivate the card any time RESET is pressed. 

DSCF4214.JPG

S.Elliott wrote:

I can't think of any other compatibility problems. 

Admittedly, if you have to choose, that is the way to go. But there were cases where the "soft" coded reset and interrupt vectors was quite useful. For debugging (and cracking) purposes. In any case, that is why we chose to add a switch to the RAMX128K card so users can pick what behavior they want.

thumbnail_image.png

jeffmazur wrote:

S.Elliott wrote:

I can't think of any other compatibility problems. 

Admittedly, if you have to choose, that is the way to go. But there were cases where the "soft" coded reset and interrupt vectors was quite useful. For debugging (and cracking) purposes. In any case, that is why we chose to add a switch to the RAMX128

My 2 cents at RAM cards, this one disables RAM reads upon reset assertion:

https://github.com/rallepalaveev/A2RAM128

A2RAM128.jpg

Screenshot 2024-08-26 084511.jpg

Yes, you have a fine board. As long as you don't claim 100% Saturn compatibility as some others do.