Thank you Richard for your most relevant and useful contribution.

[It seems that the smartest thing one could do in this case is to select the slowest input clock frequency that will still allow everything to function. Someone has already touched on that in passing, but it will serve a number of useful purposes, not the least of which is saving power, since this looks as though it should be a battery-operated application.]
>
Yes, but after a certain point there's going to be some inaccuracy coming in, altho if it's the same for both players it wouldn't matter so long as they don't notice it -- that would be fatal for the clock's credibility. If I wanted to really cover all the bases I could add a lo/hi speed switch for people wanting to save power; maybe the slow setting would have an autonomous speed-up if the players started playing fast towards the end of a time control or when someone's losing on time. I suspect this isn't even a possibility: how could you change crystals in mid-stream?
I wonder what the slowest speed would be, it seems to be left open in the data sheet for the AT89C2051. I did find a reference to a 1MHz crystal in an Atmel doc.

[If he's using a "character" LCD, which, IIRC, has a typical update execution time of not less than 40 microseconds, I'd say any sort of clock as fast as, or faster than that might be adequate, since it will still take a number of clock ticks to time out the minimal switch debounce interval.]
>
[While I agree that many speed chess players can make more than a move or even two in a second, including the button press, it's unlikely that such a pace will proceed for long. For the sort of thing that's being built here, it's probably important to have considerable tactile feedback, and possibly even a noise-maker of some sort to provide a click when a button is pushed. Perhaps that can waste some more time, and it will be useful to ensure that that the button-push has been recognized.]
>
I'm using the Cherry G15 which has a built-in click. It's heavy-duty and has a shiny button to aim at.

[If it's possible, it should, indeed, waste as much of the total time wasted in a power-down mode, to maximize battery utilization. Unfortunately, the LCD, if it's of the HITACH 44780-based type, will consume more power than the MCU.]
>
This really surprised me as I was only thinking in terms of the basic LCD display which supposedly doesn't use any power at all between updates. Ouch!

[A pair of real 7-segment clock displays, with separate segment inputs for each digit would probably yield longer battery life. All that's needed for them is a routine to complement the backplane and digit potential each time the debounce timer overflows. These displays often use too many pins to be practical on a DIP-40 part, but if you use pairs of 2-digit displays, the same 14 segments can be used to drive four of them with only four back plane-drive pins required to make them work if the multiplexing is properly timed. LCD's do respond rather slowly, so that should all be transparent to the casual observer.]
>
This sounds too complicated too me -- I'm not saying it IS too complicated, just that I don't understand it. Can't I go with a four-pack of alkaline AAs (2500 mAh capacity each)? The Lumex LCM-X00801DXX-Y only shows a typical current drain of 2ma.

[There is one condition that's been overlooked, I believe. Occasionally, and certainly at the end of a game, it's desirable to stop, but not clear, both clocks. If, for some reason, the game board has to be abandoned, time needs to be halted for both players, and, at the end of a game, it is sometimes of interest to compare the amount of time used by each competitor. With mechanical clocks, pressing both buttons simultaneously accomplishes this. Maybe that capability needs to be provided as well.]
>
I had planned on a Pause button and I'm just in the process of implementing it! I can't find another external interrupt so I'll go your route with the INT0 & 1 PB ISRs checking each other and if it's set, doing a Pause. I guess this is where I'm going to have to go with debouncing. I hadn't until now as I was setting a flag in the ISR, checking it in main which ignores any further flags for that INT. With two PBs together, I guess I would have to delay for 10 milli secs (?) in main after seeing the first INT and then check for the other flag. Does that sound right to you?

Thanks again,
Peter