On Jun 5, 4:11 am, gids...@sasktel.net wrote:
The machine is barefoot IIc (255) without any disk booted, not even
BASIC program entered.
I guess this makes it a hardware problem. Since you say it is a
barefoot (never heard that slang before - maybe bare bones instead :)
What about bare-naked? :-)
And, no, it's not a hardware problem at all. It exists in most (if not
all) Apple IIs.
And also I am not quite sure if interrupts would be enabled on any
hardware until something is at least plugged in although keyboard
buffering has the keyboard always plugged in but needs to be turned on
with software.
Just tried with (of course, *bare*) unenhanced IIe clone - same
behaviour, and it doesn't have any interrupts, so IRQs get ruled out.
I would try things in this order
If you can, plug another IIc keyboard in to eliminate sticking keys
and other keyboard problems
look for any black or cracked capacitors
and lastly, the big one, remove and replace all chips that can be
removed.
I forgot to say that the IIc is in perfect health condition and
everything works. Hardware faults were out of scope since the very
beginning, but I did not communicated it clearly enough.
It's just that firmware is not initialising the SP after RESET. RESET
catches few nested subroutines and that offsets SP each time. If you
happen to write "CALL-151" when SP is below some threshold you'll get
"?OUT OF MEMORY" and probably SP reinitialised. I found this bug
because I test short routines in Monitor (excellent tool) and do RESET
+ "CALL-151" too much.
So, this is present on IIe and IIc. Too lazy to test on IIgs right
now. But I wonder how it went unnoticed and unfixed for so much time.