I've been a lurker for a long time, but I've got an Apple IIe board here that made me decide it was time to create an account and ask for the help of the experts.Before getting to the current issue I'm facing, the short story of this board:What I have here is an 820-0064-B that came from with a lot of various other discarded computer motherboards from an ham radio fair, and that was probably 10 years ago.It sat forgotten in my storage room until I had to move a few months ago, when I "rediscovered" it in a box, wrapped in an antistatic bag.
It originally came as board only, pretty clean, no scratches but obviously tampered with:
- Video, CB and EF roms were replaced with EPROMS by previous owner
- IOU pin 21 was broken and it was "repaired" by sticking a short piece of rigid wire into the socket to make contact with the stump from the chip
Things I did before firing up the motherboard for the first time:
- unsocketed the IOU, soldered a thin piece of the leg of a resistor to act as a pin
- Removed the original and damaged IOU socket and replaced it with a turned pin socket. Lucky the original sockets are very easy to desolder
- dumped all the roms and checked the MD5 of their dumps. Video matched 341-0161-A, EF matched 342-0134-A, CD matched 342-0135-B, character matched 341-0132-B (this was still original)
- Checked the HAL chip. I have a custom tool that can analyze registered PALs, the equations I got out of it are the same ones you can find on applelogic, so I considered it ok.
So, the motherboard is of an unenhanced IIe.
You can see the board under test in attached a2e_board_under_test.jpg
Time to fire it up. Aaaand... garbage on screen. See a2e_screen_garbage.jpg . Removing the EF ROM made very little difference, so to me it looked like the CPU wasn't executing much.Lucky me, I had a few 6502s around. Replaced it with another and finally got a looping self diagnostic (I was testing with the keyboard disconnected, and according to https://support.apple.com/kb/TA38047 it's normal to get a loop).
Fine, I needed I keyboard to go on with the testing, and maybe a speaker. I have the carcass of another IIe, so I pulled it out and connected both the speaker and the keyboard.Got the "]" prompt, and when running the diagnostic I now got a "KERNEL OK" message, still I noticed something weird: no beep from the speaker nor CR2 led lighting up.
While I was at it, I decided to see what would happen by converting the machine to an enhanced variant:
- Installed a 65C02
- Burned and installed a 342-0303-A for EF
- Burned and installed a 342-0304-A for CD
- Left the char 341-0132-B untouched, will get to it in the future
This got me the new prompt (with "Apple //e") and now the diagnostics report "SYSTEM OK", but still no speaker sound nor CR2 lighting up.
Had to give another look at the schematics, and found out that speaker is toggled by pin 8 of the IOU, that then goes into a small driving circuit for the speaker.After I verified that pin 8 was not shorted to GND, I attached my oscilloscope probe to the end of C79 that is connected to pin 8. What I saw is in picture a2e_iou_spkr_noise.jpg To me, it looks like noise, and doesn't change while performing the self-test.
I also attempted to input a program that should generate a continuous note, but did not see changes in the output.
So... Either the IOU has a dead pin or something before it is not allowing it to decode properly. Any idea of what else to check here? Any hints? Things that I could have missed?And if we get to the worst, does anyone here has a spare IOU chip and is willing to sell it? Or knows of a CPLD reimplementation?
Thanks for taking the time to read through this!
sometimes the contacts in the speaker wire of the pin headers are pretty corroded. You can use contact cleaner to clean both. Or another method is to just ever so slightly bow the pins (like a milimeter) and repeatedly insert and remove the cable cleaning the contacts that way. See if you get sound. also examine the wire end for a disconnect, a cut in the cable, or a detached wire on the speaker.
Sadly this won't be of much use: I tested continuity of the speaker wires and connector and found no issue. Also, I tested the speaker by itself and it can buzz just fine.
As I mentioned above, the issue is apparently tied to the SPKR signal not being driven at all, I tested it with an oscilloscope and found just noise on the line that comes out of the IOU.
Great diagnosis and thanks for all the details!
I am not the most expert of this forum but if there is nothing coming out of pin 8 of the IOU, I'd say that you may need another IOU.
The manual I have says the Speaker is software controlled via the IOU. I believe you should see a square wave out of the IOU. CTRL-G also plays a BEEP.
I'm wondering if you could see the beep square waves out of the IOU if you lifted pin 8 - but given that the IOU is not easy to find, I'll leave the decision to you.
CR2 is not normally on on my system either. To be honest I am not sure what its purpose is.
Thanks a lot for the pointers! I didn't know about CTRL-G, much easier than coding the beeping program in assembly every time!
I disconnected pin 8 of the IOU and tried it outside the socket. I can see a faint, minuscule change in the noise when I trigger the beep, something in the range of millivolts. At this point I fear that it really is the IOU. What a weird issue to develop...
I wonder if I could implement a decoder for writes on $C030 externally on a GAL and feed the substitute SPKR signal back into the circuit. Of course going through the pain for this and then finding another issue would be extremely annoying...
From what I understood, CR2 is more or less like a "replacement" for the speaker when you can't connect one. Should turn on when the speaker beeps. Probably to help test boards outside the case.
Ahhh yes! I disconnected the speaker on my board and indeed CR2 flashes whenever a BEEP is expected! Thanks!
I've connected my scope and below is the boot BEEP scope'd on pin 8 of the IOU. Indeed it's a 5V square wave.
I am not sure whether it could be something else causing this issue. I understand that if you poke a memory address the IOU outputs the signal - were you able to run memory tests and system tests and pass them all? If that is the case, maybe you need a new IOU unfortunately.
Well, for now I limited myself to the internal diagnostic test: incomplete as it may be, it's the only thing I can run for now. And yep, that passed.
I could replace the memory banks, but I don't expect that to change much. I'll sleep on it, we'll see if I can think of something.
Thanks for the help!
My idea was just to try to make sure that nothing else is wrong as the IOU - AFAIK - is not easy to find. I hope other may have other simpler solutions! Let us know how it goes!
Yes, you can do that. You must decode just $C03x means A4 .. A15. And you must toggle a flipflop/register.
The only easy issue would be a missing pull-up. The IOU's output is obviously an open collector output, that's why there is a 3.3K resistor as a pull-up to 5V. If that was broken/not connected, then the signal would look dead, as the IOU can only pull the output to ground. That'd be really lucky and an easy fix. Otherwise it indeed looks like an issue with the IOU, unfortunately...
ah, very good point. So probing pin 8 of the IOU when lifted won't show a square wave because there is no pull-up resistor connected - apologies for the bad advice.
Heh, and this is another reminder for me to stop trying to troubleshoot when I feel sleepy.
Just to be super-sure, I pulled out the pin again, checked the presence of the pullup from RP1 (it's there, 3.3k as it should), and anyway added an external pullup resistor directly on the pin while leaving it out from the socket: same result, and now it's evident that the IOU itself is pulling SPKR low (in a very unclean and noisy way).
I guess this pin in the IOU is shot. At this point I could really recover the decoding logic from an Apple II schematic and add it on top of the IOU, hoping not to find another dead functionality!
Ok, had some time to play around with reimplementing the decoding logic to beep the speaker.
I used a 74LS373 to latch the addresses coming into the IOU, and a GAL16V8 to act as an AND gate for the latch signal, and then as the actual decoder for the addresses, as a flip-flop and ultimately producing the SPKR signal with an OC output.
Well, it works! Video with sound attached :)
I don't like flying wires on my boards, so I will get a small pcb produced that sandwiches between the IOU and its socket and will add the space for the two new ICs. Will publish it with the GAL programming file.
Well done! It would be great to see a schematic to better understand what you have done.
It's pretty simple: this is taken from the schematics I used to produce the PCB. I will release it in full once I've checked that there are no issues with placement. The wiring is actually the same I did in my prototype (except that ORA0-3 on the 74LS373 are not needed for this and were not connected).
The file to program the GAL has the following equations:
chip IOU_SPKR GAL16V8
CLK=1 PHI0=2 PRAS=3 A6=4 Q3=5 LA7=6 LA4=7 LA5=8 C0XX=9 GND=10
o12=12 o17=17 rf18=18 o19=19 VCC=20
/o17 = VCC
o17.oe = /rf18
rf18 := /rf18
rf18.oe = VCC
o12 = /C0XX * /LA7 * /A6 * LA4 * LA5
o12.oe = VCC
o19 = PHI0 * PRAS * Q3
o19.oe = VCC