Hi Friends
I have an Apple III that I restored back to health and it's about 99% working for me. For some reason, when using System Ulities 1.3 I can not get the keyboard to be read correctly - it will acknowledge up an down arrows in the main menu but will not recognize any of the valid key strokes (D,F,Q).
Now - I've confirmed this is not an alpha lock issue. Of note I've confirmed the keyboard is working - from Apple III Basic - I can echo all the characters to the screen including upper and lower case. I've also written a short program to echo the ASC code of each key hit - so I can confirm all keys are working and represent the accurate ASC code.
It's only when I go into system utilities 1.3 that it won't sense the keys - it keeps saying press a valid key whenever I hit valid keys.
Of note, I replaced the keyboard encoder because it was not working at the start with a JCM encoder - I've since had JCM send me a newly tested one and they have confirmed it works on their Apple /// which seems to suggest this is a "My Machine" issue.
I've attached videos so you can see how it works for both Basic and within the utilities. Of note System Utilities 1.1 works - however I need 1.3 because of the toolset included in that version.
This must have something to do with how pascal is reading the keyboard but for the life of me can't solve this one
Basic example showing the keyboard works: Basic Video
System Utilities showing the issue happening : System Util 1.3 Video
Thank you for any help you can provide -up to this point I've not received any thoughts across Facebook/Redit
Michael
Are you using original disks, or some you freshly created from a downloaded image?
The disks could be bad. Also, note the Apple /// has a fully configurable keyboard. Each boot disk contains a "driver" for the keyboard (stored in the SOS.DRIVER file in the root directory of your boot disk, esentially containing a table with a key to character mapping). This is what allows the Apple /// to be configured to different keyboard layouts (US QWERTY, US DVORAK, or French/German/whatever). One of the advanced and very flexible Apple /// features which Apple did not keep for the Apple //e.
The SOS.DRIVER file could be damaged - or not contain a valid keyboard mapping. And of course, also the executable itself (SOS.INTERP on the disk) could be damaged.
Hard to run the system config program (to examine the sos.driver file) if the Sys Utilities disk is broken. Maybe just copy the sos.driver file from the (working?) business basic disk over the one on the system utilities disk?
I made the same comment about configurable keyboard mapping over in the Apple III facebook group a few weeks ago.
I've forgotten - do you (OP) have ADTpro for the /// working? Can you make a new Sys Utils disk?
If you could make an image of the non working disk and share here, then we could have a look at it. And also try on another machine
Retro-Tinker
Yes - that was me - I swapped out the keyboard encoder. Per my note above I will try copying the SOS.Driver to a copy of my util disk and see if that fixes it.
I don't have ADTPRO - but don't need it as I have Applesauce and drive to write my own disks and Floppy Emu.
To date I've tried the original Utilitiy disk, floppy emu images from online asmiov and floppy images I copied to dsk
Yes, please see attached dsk image - for purposes of this forum I've changed the extention to .img - please change to dsk obviosuly.
Apple3SOS1.3SysUtils.img
I took the SOS.Driver from the BASIC disk and copied it over to the utilities disk and wrote a new 5.25 disk. Same problem - pushing the lettered options results in an error stating to please pick one of the options listed.
Tested Software:
WORKS as EXPECTED
BOS works as expected
All demo programs work as expected
Apple Emulation works as expected
System Util 1.0 works as expected (this is not a fix however because most tools I need are on >1.2
Apple /// Software Revision Utility worsk as expected
DOES NOT WORK as expected
- System Utilities 1.2 and higher
- Apple Backup ///
Both seem to use the same menu system - hopefully these hints can help someone direct me to the problem!
I created a floppy disk from the image that was posted. It boots to Sys Utils and works as expected on my machine. It ran SCP; I loaded the driver.sys file off the floppy and gave it a cursory inspection - everything looks good there too.
Don't know if this helps very much, but seems to point more towards a hardware specific problem.
I also had a try in MAME, and it all works correctly as well.
I'm thinking that bit7 from the keyboard might be stuck high. I did a quick test program to check it. Just load keyboard portb value (LDA $c008) and store in the first screen location (STA $0400) and keep looping. bit7 here is from the keyboard.
Ctrl-reset-openApple to get into the monitor.
2000:AD 08 C0 8D 00 04 4C 00 20
2000G
Then top left char becomes a normal square bracket ( ] ) when a cursor key is pressed and held down. And an INVERSE square bracket when a letter is pressed and held down. I tested this on my Apple3 here, MAME seemed to not need the key to be kept pressed, so thats something that might need looking at.
Give that a try and let us know what it shows.
I tried again now to make sure. Yes, i'm seeing it toggle between inverse ] with letter down, and \ with the key released. For cursor keys, toggles between normal ] pressed and \ released. for the cursor keys, it looks like it has an underline for me as well.
It seems that the high bit is probably working ok then.
The full description of that keyb bits is here:
https://archive.org/details/a3srm/page/n144/mode/1up
Funny, I was just reading chapter 8 in the service reference manual too.
I noticed you get a different ascii code for RETURN on the keyboard and ENTER on the keypad. In the video, it looks like the error message also shows up when you hit RETURN. Does the same thing happen for ENTER?
Thinking about common failures in anything electronic, and the fact that this seems unique to Shafferm's machine, I wonder if the problem isn't with the ribbon cable between the keyboard and the motherboard or with one of the connectors? Maybe a very careful visual inspection?
EDIT1: In the real world (actually poking at my hardware) I see that Business Basic doesn't care if either the Open or Closed Apple keys are held down when pressing a letter key. However, Sys Utils gets *really* upset when either of those modifier keys is held down and you press a (menu valid) letter key. I would start focusing in that area - keys, cable, connectors, maybe even the pull-up resistors (RP-11) on the motherboard.
EDIT2: It appears the CLOSED APPLE key being held down perfectly mimics the problem. The arrow keys still work, but every other key results in an error message.
EDIT3: One side effect of the closed apple key stuck on in business basic is that you lose auto-repeat. Is that a symptom you see? (Just hold down any regular alpha key and see if it repeats or not.)
EDIT4: In the monitor (open apple/control/reset), read C008. Do you get 7D or 5D?
Thanks for all your comments -
Enter and Return in the program yield the same results.
From monitor reading c008 yields 5D with a [ after it
C008: 5D [
Probably the best clue is that from BASIC I do not get autorepeat at all! So I do think you're on to something with the closed Apple key.u
So again to your point that leads to potentially : a bad cable (I have a replacement I can try), a bad pull up resistor, or a bad switch.. Tomorrow I'll put a volt meter across the swtich to rule that out first.
Thanks!
Reading 5D at C008 means bit 5 is low, which says the closed-apple key is pressed/stuck on. You should get 7D.
You can see on the web page that Rob linked to above that bit 5 = 0 is indeed "Apple 2 switch depressed".
Thats a great pickup for the closed applekey retro-tinker, it does look like its getting closer to the problem now.
One more comment on the Closed Apple key, this is run through a flipflop as it's also used to trigger the faster repeat rate for a held key. And that flipflop is clocked by the anykey signal. It means for it, you can only detect it is pressed after another key has been pressed. More things to check for it.
see schematic here https://archive.org/details/a3srm/page/n151/mode/1up
Interesting - when I picked up this machine, the encoder was bad and had to be replaced, wondering if something in-line took a hit as well.. Will check that after I hit the easy stuff (Cable, Switch, etc)
I was curious why reading C008 in the monitor returns 7D when nothing else is pressed on the keyboard. According to the "Memory Address Reference" on pg 8.5 of the service ref manual, this would mean the shift key is depressed. Why doesn't it read 7F? Turns out it does read 7F when either shift key is actually pressed. Bit 1 is an output directly from the keyboard encoder, so the inversion must be happening in there.
Also, the 2nd column in that same table should read "KB PORT (C008)"
I'll be really surprised if the flip flop (at H11) in the closed-apple signal path is bad. I think it is rare that only 1/2 of an IC fails - but stranger things have happened. There is another 74LS74 at location H7. The same half is used to drive the speaker (if you believe the schematics) so swapping the 2 parts may be an option for testing purposes.
Well - a big thank you to Retro-Tinker and RJustice.
1. Checked the cable - that was fine - no issue
2. Check the LS74 chips identified above - both tested good - no issue
3. Tested continuity on the Open Apple Switch and that show a closed connection - when powered off - so I'd assumed it was the switch, popped it out replaced it with a new one - but no dice same problem!
4. I flowed the trace back to my arrow keys - about 6 months ago I'd replaced one of those hard to find double click arrow keys and after I did so, the "Double" click on it stopped working - annoyed, I figured I'd deal with it later. Well later was today - apparently something must have shorted in that switch causing a problem down the line - pulled out the bad "double click" arrow key and replaced that.
Sure enough, everything is working as expected - including my System Utilities!
Thank you to all who helped - I'd never have thought that the Open Apple key would cause problems like this in only certain programs - hopefully this thread will stand the test of time for the next person who comes along with the same issue..
Thanks again!
Michael
I'm glad you fixed the problem! An often overlooked feature is the high speed repeat, which is activated by both the Closed Apple key and a hard-press on the arrow keys. (Although the previous post keeps mentioning the open apple key) Unfortunately, the scan of the keyboard matrix on page 8.3 in the service ref manual is really fuzzy - but you can kind of make out where the arrow "speed" keys are wired into the same line as the closed apple (aka apple 2) key.
That's really great you fixed it, well done. It certainly was an odd problem to find.