Does anyone know of a software technique for distinguishing between cold and warm resets?

Assuming that the 6502 has a power on reset circuit, and a user key for issuing a reset, I would like the power on resets to vector to a cold start area and the user key resets vector to a warm start area of code.

I know that this could be done with a flip-flop that is reset with the power on circuit and set from the cold start code, but this would require an I/O port, but this is what I am trying to avoid.

Any suggestions would be most welcome.

_________________
The Electronic Resource Guy

There has to be at least one bit of state somewhere.

Acorn's BBC microcomputer does this: there are two power-on-reset circuits, one of which resets only a 6522. The ROM can check the timer programming on this 6522: if it is in a reset state, then there was a cold reset. After cold reset, the ROM sets the timer for a 100Hz interrupt.

.
Can you accomplish the purpose a different way?

My workbench computer's reset routine stops and asks in the LCD, "New/Old/Init-Ap?" with each of the three keys in the left column of the keypad corresponding to one of the choices.

• Choosing "New" does the same thing as what you'd normally have the power-on reset do.
• Choosing "Old" refrains from re-initializing the Forth dictionary pointer and overwriting previously compiled and assembled stuff. Program and data are left intact. It just brings the computer back to a known state, ready for new instructions.
• Choosing "Init-Ap" does the same as choosing "Old" but additionally runs the routine whose address is in the init-ap variable. The purpose of this one is that if the computer crashes, you can press the reset button, then run the routine that sets up all the I/O, timers, interrupts, etc., whatever you've chosen to put in the init-ap routine, and be off and running again within a few seconds max.

I do have another button on the front, the "ABORT" key, which is not as drastic as the RST button. The ABORT key goes to an RC and Schmitt-trigger inverter for debouncing, and that output goes to VIA1's CA1 pin so pushing the button can produce an NMI to get the processor's attention even if the program is crashed with interrupts disabled. The benefit with this one is that the I/O ICs don't receive a RST pulse, so timers and whatever you have going there continue without so much interruption. VIA1 is the only thing I have on NMI. The other five I/O ICs are on IRQ. Obviously the VIA will have to be set up by software to generate the interrupt when the button is pressed, and your NMI routine will need to be able to poll whether the button was pressed.

The idea here is to not use any hardware other than ram. The 6502 simulator I am using always sets ram to 0's upon first start. Reset checks this location for 0 or not and then can decide where to go. In real ram, I have no such garuntee of an initial value upon power up.

_________________
The Electronic Resource Guy

That might not be dependable, depending on your RAM. I've seen SRAM hold data for days in the power-off state just because there was a 10uF capacitor holding it. OTOH if it's DRAM and it quits getting refreshed, it should die pretty quickly.

Real-world RAM data at start-up won't be predictable from one RAM chip to the next, although for a given RAM chip, it may be surprisingly consistent from one start-up to the next. You can't depend on it to be either all FF's or all 00's or even a random-number generator.

Yes, that is the challenge, SRAM may hold on to the data.

How did the 10uF capacitor not bleed out on the power rail?

I suppose that I could place a circuit to bleed off the capacitor when the power is off.

_________________
The Electronic Resource Guy

The problem with RAM is if it holds well enough to pass your warm start test but has in fact lost a few important bits.

If you're not worried about that, checking some special flag values which you place in RAM at cold start would do the trick. (You might check any vector table you placed in RAM, for example.)

On my Apple clone computer, to confirm the validity of RAM-based vectors, the firmware also wrote a simple checksum. In other words, each vector consisted of a low byte, high byte, and checksum.

You could do the same. On power up, the chances of the checksum for your warmstart vector being correct are very, very low.

Here's how it works. (65c02 code)



Give this a try. You could even increase the safety by making the checksum cover more bytes, but at the cost of more time.

Daryl

I, too, would suggest using a checksum or CRC mechanism.

One of the techniques the Commodore-Amiga used to locate libraries in ROM was to look for "ROM-Tag" structures. These are structures that contained meta-information about the library (how big its RAM-resident data is, where its entry-point jump-table was located, etc), plus pointers to itself (since it's statistically improbable that RAM will come up in a state where a back-pointer to an address exists exactly where you expect it), PLUS a checksum.

I don't recall precise details, but it looked more or less like this:

As you might imagine, while looking for ROM tags was never 100% guaranteed to be reliable (it's entirely conceivable that RAM *can* come up in just the right state to match a ROM Tag's signature), pragmatically it proved utterly reliable for the Amiga's entire 20+ year history. There has never been a case of a false positive. Ever.

Therefore, I suspect the best approach would be to adopt the above ROM-tag algorithm, but instead of storing library-specific information, you might want to leave its guts empty. That way, you'll need 4 words (64 bits) of memory to confirm whether or not a reboot was hard or soft. This is a 1 in 2^64 chance of a completely random RAM configuration matching your expectations.

Of course, it's trivial for an application to overwrite this information, and thus "force" the OS to assume a cold-boot condition upon reset. Changing any single bit of the 4 words will be sufficient to do that. You'll need to evaluate whether this is a problem for your specific needs though.

For a truly cold start, the risk is indeed negligible. But I'll say it again: if you've just suffered a momentary lapse of power, some of your RAM state may survive while some of it has decayed. Unless you're in a situation (like a planned sleep) where you were able to checksum all valid memory, you could falsely detect a warm start.

For a bench computer, no problem: for anything critical you'll need a piece of state which is sure to be cleared on power cycling but not affected by system reset.

The reset code can of course detect user input which causes it to do a cold reset on request: the BBC micro had a BREAK button for reset, and CTRL-BREAK tells the OS to do a full reset (I haven't checked the code)

It sounds to me like this possibility is considered by the author to neither be a cold- nor warm-boot condition. A momentary lapse in power indicates bigger problems, and in fact, this can never be totally designed for.

In scenario 1, you lose power just long enough to trip the warm/cold discriminator bit in your hardware. However, the RAM and CPU state are unhindered. This, when you think about it, is the same problem as debouncing a switch. So, you need to implement debounce logic in your discriminator.

In scenario 2, you lose power long enough to blow a few bits of RAM. I've never seen a condition where this didn't also blow the state of the CPU as well (particularly true on a 65816!!). But, suppose the CPU state remains intact enough to continue running. The CPU never sees a need to reset.

In scenario 3, you lose power long enough to guarantee a CPU reset. However, RAM may not have lost all its contents, particularly the warm/cold-boot data.

As you can see, no matter what you do, you're probabilistically screwed.

The only reliable solution to dealing with all three of these scenarios is to guarantee a reset sequence sufficiently long enough to allow a DMA operation to hard-write a value to someplace in RAM. E.g., while _RES is asserted and PHI2 is high, force the RAM address bus to $000000, the RAM data bus to $00 (it's convenient), and _WE asserted. Then, and only then, will you undeniably be able to detect a hardware reset-induced bootup.

However, I really cannot think of many situations where you'd need to go through these kinds of gyrations. You need to have some mighty specialized requirements to justify the expense of adding such equipment, however, simple it may be.

I don't think it's as bad as you suggest, although I agree there is difficulty in designing for such situations and nothing is guaranteed.

Your idea of DMAing into memory is rather like the Beeb's approach of using the VIA's reset state: you need a bit which is sure to be reset when power-on is detected. RAM doesn't generally have a reset input, so you need some other approach.

With that independent bit of state, I think one can make a solid design. The POR circuit is safeguarding the system: it needs to be more sensitive to rail fluctuations than any other component.

Without it, one is reduced to measuring the state of RAM and coming to a fuzzy judgement as to whether it is intact (we were reset) or not (we were power-cycled). That's fine, so long as it's understood and the indeterminacy suits the engineering goals.

If it doesn't cost much, I'd be inclined to measure more rather than less: not a single flag bit, nor a flag byte, but a whole table of static data. (A flag bit set by DMA at POR is of course fine, this is for the case where we lack any state other than RAM)