Hi all,
as an old Apple//e enthusiast, I'm happy to join this forum I've been looking at for months. Now that I just bought a machine a few weeks ago (at last! a PAL version)...it fails. Symptoms are :
- Power LED on, no beep (some random cracks sometimes), random characters on full screen (when RAM installed) or complete solid white screen (if RAM pulled out).
After reading as many posts as possible in this forum, here's what I did already following "Sams Computerfacts troubleshooting guide" :
- PSU seems ok (recapped RIFA) : +5.2V, -5V, +11.85V, -11.5V
- Installed new S02, F109, LS138, CPU (65C02) and ROMs CD + EF (on EPROMS, 27c256 with bended pins 26&27)
- Complete motherboard cleanup & deoxidizer, IC reseating.
- RST pin 40 (CPU) goes high after being low when pressing ctrl-reset.
- NMI, IRQ on CPU stay high.
- Clock in pin 37 (CPU) is right (but 4V only).
- Oscillating signals (14, 7, 3.5 and 1 MHz) are present on IOU, HAL/PAL, out of S02 and F109 BUT never exceed 3.5/3.7 V (instead of 5V as expected in the manual).
- Input signal out of LS125 and into pin 4 of F109 has the right 4.2V amplitude but output on pin 6 F109 (and all following signals) are weaker (those 3.5 to 3.7V I mentioned)
- The HAL/PAL (PLA), LS166 and TCA650 (video) get hot rather quickly then stabilize.
I'm afraid I did most required tests without solution. Could the weak voltage out of F109 be the issue ? is it worth changing Q4 & Q6 transistors (2N2458, a bit hard to find) ? Or any other clue ?
Just ask if some additional info is needed, I'll do my best.
I'd be happy if problem could be from other circuits than IOU, MMU or HAL, obviously.
Any help would be highly appreciated, thanks a lot and have a nice day !
Few things come to mind.
First, how 'new' is your new 65C02? If it's a brand new Western Design WDC65C02, it won't work. You need to make a little mod first.
Make sure your ROMs are the correct ones; a 65C02 will only work with enhanced ROMs.
The /RESET going high, and the correct display of characters (even though they're random) tells me your IOU is fine. Did you retry with the original CPU and ROMs after all the cleaning you did?
The fact there is no beep and no "Apple //e" screen tells me the bootstrap ROM is not being executed or it's not the right one.
Frozen is correct about the WDC CPU. However, a IIe will work fine with a "correct" 65C02 and non-enhanced ROMs. I'm also a little suspect about your 27c256 EPROMS. Did you burn them? And by "bended pins" do you mean you bent them out so as not to go into the socket?
thanks JeffMazur and Frozen for your prompt answers.
- The 65C02 is a VL65NC02_04PC from VTI I had as a spare, the original 6502 was fried (I could not test anything with it). I'll check specs with more details on this CPU, might not be the best component.
- good news for the IOU (I wasn't sure).
- I burned the EPROMs, yes. Pins 26 and 27 are bended (in an intermediate socket where the EPROM is inserted, so to avoid damaging her pins) in order not to get in contact with the motherboard socket. Those pins are for highest address bits A13 and A14, I want to use only lowest 8KB of the ROM (that contains 32KB). I tried to ground both pins to force them to zero in case open pins would be considered as 1, but no influence.
Your question drove me to test by swapping CPU with another Apple II (plus), a standard 6502 one : no changes on the faulty IIE and the 65nc02 worked perfectly in the IIplus. I was trusting the CPU so much that I didn't even think about swapping. But maybe the IIe is highly sensitive to CPU version ?FWIW, you don't need to do that. The unused address pins are tied high on the motherboard. So I would have just burned the EPROM with four identical images concatenated together to fill the entire chip. Then it wouldn't make any difference what those pins had on them.
In any case, you might want to check the CE and address lines going to the EF ROM to see if it's being enabled and if the address lines are changing.
yes, I'll try that so no risk of finding an empty bank. I'll update results when done.
Cheers
I re-burned EPROMS before night break, but unfortunately, even by concatenating 4 similar ROMs into one chip it still doesn't start. So it seems CPU doesn't read ROMs no matter what.
If there is no other idea, I'll go for a long task checking all address lines, continuity between components even in unlikely places, chip enabler, aso.
And in your opinion low voltage on oscillating signals beyond the 74F109 is not an issue (3.5V instead of 5V) ? Having a display - even if steady - discards this possibility ?
TTL will see anything at or above 2.0v as logic high. But seeing 3.5v is strange indeed. You could have a short somewhere. Maybe check all caps for shorts?
From your posts, I think you have an oscilloscope? Maybe also check the CXXX, /ROMEN1 and /ROMEN2 on the MMU for activity. Also check for activity on the RA7-0 bus. Since the MMU is pretty critical, let's make sure it's working.
EDIT:
I just checked the pin 6 of the S109 on my unit and it's 3.52v
Thanks Frozen,
yes I have an oscilloscope, I'll make a more extensive test on signals, including ROMENx, when I'll get back from the office.
Hi Frozen
I took my time to test properly the following :
- All address lines have some activity and all data lines too
- ROMEN2 (for ROMEF) has a regular 60kHz signal
- No activity on ROMEN1 except some unsignificant interferences (background noise)
- and no signal on CXXX at all. Pin stays low continuously. So no triggering of LS138 at all.
I could not find any short in the PCB (hope I did not forget some place).
Does it mean MMU is (partially) dead ? if yes, is there a way to replace at least this CXXX function with some add-on circuitry. If this makes sense.
I's hard to say what exactly is the problem. For example no activity on CXXX is not normal, but is it the ROMs that are feeding the wrong values and the rest of the system hangs? Or is it the MMU that has a problem? With only an oscilloscope, it can be hard to know.
If that can help you, here's a logic analyzer capture of the first 400 ms after power-on:
ASIC_MMU_32CH_CXXX.zip
You can load and explore that trace with KingstVIS: https://www.qdkingst.com/download, and compare with what you are seeing on your system.
For example, here's an image around when /RESET is pulled-up:
MMU_signals.jpg
You can see activity on both /ROMEN1, /ROMEN2 and CXXX. The MMU drives the ORA bus when PHI_0 is HIGH, so maybe check that the lines aren't stuck high, low, or are floating.
thanks again Frozen for you kind help.
I'm going to investigate on how to perform the analysis you're suggesting. Maybe I'll need to ask some questions anyway.
This weekend I wanted to eliminate potential problems coming from my EPROMs and the CPU so I ordered an enhancement kit, that I found rather cheap. Not sure it will completely solve my issue but at least have a clean situation from that side.
I'll keep you posted. Have a nice day
Hi again,
I just received the AIIe enhanced chip kit with new CPU and ROMs and nothing changed. So I can definitely discard this option on troubleshooting.
Your traces seem really useful : I only have a 2-line oscilloscope and have to find a way to trace signals to compare to that reference. I'll deep dive into the available functions of my hardware.
In worst case maybe I should explore building an FPGA-based MMU (assuming it's the guilty component) using schematics I found on this site but I'll need to learn a lot before. Exciting but should take some time...
Which one do you have? I've been looking at their 32 channel option, but also having concerns about the sampling rate with full channel use. I'm a big fan of Logic software but Salea hardware but 16 channels the price is not for me. I've seen the kingST software is very similar to Logic so been thinking of giving it a try for 1/3 the price. You like it?
I have 3 logic analyzers. For anyone interested in tinkering with digital circuits, having a logic analyzer makes life so, so much easier.
The first one I bought was a Kingst LA1010. It's a cheap LA and when I bought it, I though that anything would be better than nothing. This is a "100MHz" LA, but that speed can only be used with 3 channels, the max sampling quickly drops as you use more channels, plus it has no internal memory. To anyone interested in this model, I don't recommend this one. You'll regret not going with a better model.
I also have a Rigol DHO924S, which is an oscilloscope with a logic analyzer. You need to buy their pretty expensive cable to use the LA though. I haven't used it as much as I though I would, but it's the more precise LA I got. Each probe has its own ground connector. A trigger will stop both the LA and the scope, and I think you can apply functions to the signals. So I suppose it would be possible, for example, to trigger when say a 4-line bus has a specific value.
The last one is a Kingst LA5032, and is the one that I used to record the traces above. It's the LA I use all the time. It's a 500MHz LA with 2ns resolution, and can capture 32-channels at full speed. It also has internal memory, and I have no problem capturing long traces for example a 1 second, 32-channels trace at 500MHz. It can only trigger for one type of event (rising edge, falling edge, HIGH, or LOW) on a single channel, however. It only have one ground connector per 8-channel group, so you can see an occasional glitch here and there, but it's not really a problem. I also love their software, which is relatively basic, but is easy to use and does everything I need. If you are looking for a 32-channel LA and the price is acceptable to you, then the Kingst LA5032 is definitely a good choice.
There are two projects that are replicating the IOU and the MMU. One is by UncleBernie, and you can read his posts here on Applefritter; they contains tons of interesting infos. The other one is my project, which I have released with a Creative Commons Zero licence (public domain) here: https://github.com/frozen-signal/Apple_IIe_MMU_IOU. The store ReActiveMicro.com will release replacement adapters hopefully soon.
The latest news I have from Henry (owner of ReActiveMicro for those who don't know) is that he is currently crawling under the workload. He is in the process of relocating his business, and he told me that some time ago he has lost his helper and must do everything himself.
He wanted to finish another project before doing the IOU/MMU replacement. He recently sent that project for review, so I can now talk about it. It's a copy of the Apple IIe motherboard. Henry lent me a prototype of this board for the devlopment of the IOU and the MMU. At first, I did not know it wasn't an official Apple IIe board and thought "How the hell did he get that board so clean!?". If it was not for a ReActiveMicro logo on the underside, I would have had a hard time believing that it wasn't an original board. Every detail is there -- truly a magnificient hommage and love-letter to the Apple IIe. Henry told me that the only missing detail is that the original has is silkscreen on exposed pads (See "1" and "2" of row "F" on an Apple IIe motherboard to see what I mean), which he could not find a PCB house that could do it / do it at a reasonable price.
I have since returned this board to Henry and can't check if the HAL chip was an original Apple or not. But if it wasn't, when testing my IOU and MMU prototypes together, I may have inadvertently assembled the very first homebrewed Apple IIe.
hi Frozen,thanks for your kind answer.I have no significant info to provide, except I found both of your sites a few weeks ago and the contents told me clearly that I had still a lot to learn before being able to anything around FPGAs. I'm really impressed about your achievements, enthusiasm is really a strong engine.So is it also for Henry as I understand : wonderful story of patience and engineering. I hope he'll do well in this busy situation, there's no hurry on my side, I still have several items to fix on my stuff. Including other tests on LS244 following GGB's advice (thanks also to you GGB).I'll keep you posted,regardsThanks, the 5032 was the one I've been eyeing and I've got several others too. I've got the original Salea Logic (8 ch digital only, and love the Logic software but it's slow even with only a comple channels has trouble even at 8Ms/s) Analog Discovery (both the 2 and 3, like they can both linked and trigger of a simgle event, but hate the software!). Saw a cowoker's wingST and that looked to be very similar software to Logic, so that has my interest! Glad to hear it can do 32 at a fairly fast sample rate the onboard memory is maybe the most important thing as even USB3 seems to have issues with the data rates (and that doesn't really make sense). That image is qutie impressive, lots to see!!
applesharp, as is the case with a lot of these troubleshooting things, there are lots of potentials so the approach of ruling stuff out is the way to go, it could just take a while.
In line with what frozen had said about the signals, I'll share I had recently had what I consider a really strange experience with a platinum //e in that it wouldn't boot, just some random garbage screen displayed. I did the normal approach, supply good
Tangental thought... a recapped RIFA is really nothing with regard to the power supply and it's abilty to produce good outputs. The RIFA is just a filter the power part of the supply is the result of all the other electrolytics and other components on the board. If you have a scope, it would be suggested to monitor all 5 lines while powering up to look for any singal problems all should be fairly stable, but when disk drive spins up 12V gets pulled low (up to 1V) and as a result of also being sourced from 12V the -12V and -5V will show somethig similar. Recovery should be quick.
Back on topic: the RAM was not socketed so that was not easy to check, ROM (single ROM) was pulled, read and verified). Super puzzling so I started looking at all the signals. Too much time in fact, but that's where I went. I found the socket for the ROM wasn't great because the data from the ROM was not showing up at the 6592 several of the data lines were flat. I found continuty between several of the the ROM data pins and 6502 pins was not good, as data at the ROM and 6502 was different and the 6502 was zero. But the ROM was "good" so I replaced the crappy single wipe socket with a double wipe socket and again had good continuity from ROM data lines to 6502 data lines but somthing wasn't right. With the help of our local Uncle I used his RAM test ROM to verify RAM was good so things wree getting more confusing!
I then started looking deeper at the ROM and decided since Bernie's test ROM was working why not try the ROM on an EPROM (BTW, not sure if mentioned or not, but you don't need to wing out any pins on the EPROM with the //e, the board is wired for both without anything special) Guess what... the EPROM worked! So now I've got a "good" ROM which is really bad and a good socket where a bad socket was.
That all being said, I'm not convinced the problem isn't somewhere else capacitance somewhere is slighlty off throwing off the circuit timing. I did find I had another platinum system with the single ROM and in that system the ROM had already been replaced with an EPROM, I don't know why, but found the bad good ROM also didn't work there. I plan to wire up a test rig and compare the timing because whatever the EPROM programmers are using to read work, and the //e can't read correctly.So while checking out the 244 may be worth toning out the inputs and outputs to make sure they've got good signal paths too.
The RIFA capacitors have no influence over the quality of DC power supplied, or on the computer's operation. They are required by regulations limiting radio interference by electronic devices.
In a clocked (or synchronous) circuit, slight changes in signal propagation from "capacitance somewhere" are irrelevant. Timing is always controlled by clock edges.
Beware of overly simplistic "testing" techniques or tools. Reading a ROM in a device programmer will not necessarily reveal if the I/O pad ring is damaged, resulting in drastically weaker drive ability on outputs. You need to use a scope to see that.
I'm assuming since you included the capacitance comment this is in response to my other comment, so I'm puzzled because I think you and I were making the same point. My comment was in repsonse to the OP statement about the supply seeming ok because of its recapped RIFA and "good" measured voltages. Since I didn't see anyone called it out, I was pointing out the RIFA is really a moot point in terms of good outputs. That why I mentioned using a scope cuz we know these aren't always stable with bad components. I may not have done a good job explaining that if you felt I needed to be corrected... So if that's not what you got from my comment, I did a bad job making a point!
I may not have done a great job with the details on why the capacitance could be a factor, my concern was more about bad edges, even with very wite windows very transition times can be effected by capacitance. The problems I've run into have been with higher frequency signals like i2C / hdmi and I've seen capactiance create problems. So that's why I'm looking there first. I could be wrong, but it's also easy to check.
Please don't get distracted by the logic analyzer talk that's more for other things and only because of the great view of 32 signals that I even broght that up. I've got great gear and the background with this stuff including rework. Although my low-level II circuit knowledge is in need of a refresher, and I'm glad this is still pretty basic system design LOL
These ROMs aren't the best but since it was working before tearing the ICs out, reading and cleaning... I don't have much else to go on. I'm surprised that pull, read, clean and rinstall would be enough to cause a problem. Sounds like the OP also has the ability to burn EPROMs so maybe that would be worth trying some custom ROMs that just do some basic tests like Uncle Bernie's ROMs.