Hi all,
I found a IIe in the loft (PAL version) and it does not boot. Clock phases are correct and address/data lines look OK. Adr downstream of buffers 74LS244 also look OK and buffers test OK (in an LED & switch tester!). There is no beep.
Screen appears to show graphiccs (so IOU generating sync etc) but characters look as if text is being shown in graphics mode not text e.g. bit patterns repeat every 4 raster lines. A quick check with scope shows the MMU /C0xx line doesn't seem to be asserted. Following back to 74LS138 the enable on this seems stuck low and this is the CXXX line from the MMU. Checking with the logic analyser shows that A15-A12 are setting C and the line is resolutely low. I've changed the 74LS138 in case it was holding it down.
Do the MMU chips fail? Is there any other obvious test to try before having reluctantly to put this in the "non-fixable" pile since I presume the only source of the ASIC is another IIe.
(RAM & ROM tested in EPROM burner/silly little tester)
Alan
Can you provide a picture of what it shows on the screen?
Also did you run the built-in diagnostics? (Hold down both Apple keys and turn it on.)
There is an element of dynamic behaviour. If I repeat the reset I can end up with slight variations -- but this is the typical one and it does bear a resemblance to the character positions in the correct screen!
Self test appears to print stuff out on screen - but I cannot read it. It certainly looks like working processor behaviour rather than random garbage in video ram.
Apple IIe screen display boot failure
... just a few days ago with my MMU replacement based on PLDs ( if interested, see post #31 of this thread: https://www.applefritter.com/content/question-about-weird-thing-mmu-schematics). What I saw is that after powering up the machine, it would be in a lores graphics mode. Beep and so on was fine, I could type stuff which would appear on the screen, but not as characters, it was some lores graphics. It did not happen all the time. Diagnosing the problem lead to a timing issue on the multiplexed address bus (RA7...0) which in my MMU replacement was made by two 74LS257 (now stronger 74S257 to help the problem go away).
The failure mechanism is simple: the IOU has no address lines (except A6) and it "peeks" on the multiplexed address bus to see the lower addresses sent out by the 6502. If these signals are corrupted or too weak, then the IOU "sees" wrong addresses and does not set its internal soft switches correctly, ending up with wrong graphics modes. You may inspect these signals (RA7...0) for proper levels using an oscilloscope. These are routed into the DRAMs so there is a high capacitive load for them. A weak driver may not be able to get proper logic levels in due time for the IOU to see the right address. The Q3 and PHI0 signals control the timing of the RA7...0 and also may play a role if they went bad.
Rotten contacts in IC sockets can cause weak / bad signals, too. And there is yet another effect lurking within old ICs that still use gold bond wires: over time (decades) the gold / aluminum bond pad interface turns into intermetallic compounds. This is a sort of solution process. These intermetallic compounds are brittle and higher ohmic than the new bond joint is. The brittleness contributes to formation of cracks when the IC package is mechanically or thermally stressed. So it is not true that "ICs live forever if not powered up".
All this, of course is part of the "fun" in keeping vintage computers up and running. Good luck !
- Uncle Bernie
You might want to reseat the VIDEO ROM chip to see if that changes anything.
Also take a look at this post: https://www.applefritter.com/comment/102697#comment-102697
Also check your /RESET line. I had a screen exactly like yours when developing a replacement for the IOU. The IOU will drive the /RESET signal LOW for ~35 miliseconds after power-on (if a disk II interface is present, /RESET will be kept LOW for ~100 miliseconds). After that, a weak pull-up in the IOU will keep this signal HIGH. I had to manually place a pull-up resistor, and when I forgot, a screen showing exactly what's in your photo is what I would get.
Check this signal a couple of seconds after power-on. Check it directly on the IOU, pin 15. That will tell you if there is a problem with the IOU. And also check it elsewhere on the MB, like any slot from J1-J7 pin 31. This will tell you if there is a problem with the sockets, solder, or traces.
You can easily check if this is your problem by placing a pull-up resistor between +5v and /RESET. In the IOU/MMU emulator schematics a 3.3K resistor is shown, but I think it's a bit much. I used a 10K and worked just fine.
I used jumper wires, but you could use directly a resistor inserted 'behind' the spring thingy in the slot. Like this:
pull-up resistor.jpg
This is a very good point. I checked /RESET using a DSO at the IOU pin and it went low for a number of ms-pulse and then high again and stayed there so I think this one is OK.
That was interesting especially pointers to MMU schematics - although they do look as if they were for prototype physical HW. RA0-7 look OK on this board but I've not got a very high bandwidth non-sampling scope available in this workshop for watching them, but they are being driven over the correct voltage range - my Tek 7904 is several hundred miles away in the other workshop.
Interesting point about the bonding wires. I've been surprised by how well some old equipment does continue to function, but equally perplexed by some of the failures one encounters after years of sitting in storage. IC sockets and PSU capacitors make sense (although I still have a pair of 4uF 500V wet electrolytics from 1941 in use here, sometimes one is lucky I guess) but the IC failures are often perplexing.
But it looks like I may need another MMU to try and see if this is the fault, and I guess the only source is another Apple IIe...
Alan
Good luck finding an MMU without having to buy a whole other motherboard. They've been unobtanium for years, which is why a couple people are working on some kind of PLD based replacement. Hopefully sometime in the not too distant future we won't be in this predicament, but we're not there yet.
Having looked at some of the MMU diagrams it appears the MMU CXXX line is a rather more involved decode that just 1100 at the top of the address bus. Firstly a selection based on VLC (?) from CXXXOUT or PSELIO and then CXXXOUT seems to be an and of CXXX with /INTC300 /INTC8EN /CENROM1 and DIANA? Is anyone more familiar with the internals able to tell me more? (A little unclear over the negating of lines, the wire-or lines for addres blocks almost certainly are for negated lines but they seem marked without a bar)
There are four bonding options. VLC refers to "Very Low Cost"; one of the codenames for the Apple IIc. For the Apple IIe, consider VLC to always be LOW. DIANA is the codename for the Apple IIe and should be considered a constant HIGH. You can ignore anything tied to VLC being HIGH and anything tied to DIANA being LOW.
There are two more bonding options: "64K", apparently the design supports RAM that used 16K chips instead of 64K ones. And the last one is /INVIO which I don't know what it is but from the schematics should be considered as always LOW for the Apple IIe.
You said that you could enter the self-diagnostic mode but could not read the result because the text appeared as graphic blocks. You may "force" the video renderer to display text by forcing the "GR" signal LOW on the IOU (Pin 2, called LGR/TXT' in the schematics). But I'm not sure if it's safe to just "wire it to ground"; maybe use a resistor to limit current is safer. Probably someone on this forum will know.
Are the disks drives functionna? Can you run a game?
Your AI bot is good. However your game Coreball totally sucks.
Deleted link - Tom
In post #10, "afrb2" wrote:
"Having looked at some of the MMU diagrams it appears the MMU CXXX line is a rather more involved decode that just 1100 at the top of the address bus."
Uncle Bernie comments:
Yes, indeed. The CXXX output of the MMU has more functionality than the name implies. So it can't be replaced by just a decoder with f = A15 & A14 & !A13 & !A12. Bad luck if this pin would be faulty. You then would need a new MMU chip.
In post #11, "frozen signal" wrote:
"You may "force" the video renderer to display text by forcing the "GR" signal LOW on the IOU (Pin 2, called LGR/TXT' in the schematics). But I'm not sure if it's safe to just "wire it to ground"; maybe use a resistor to limit current is safer. Probably someone on this forum will know."
Uncle Bernie comments:
Not having the IOU schematics at hand (I'm on the road) I can't comment if it is possible to override the graphics mode by manipulating the GR output of the IOU. It certainly can't get the system out of hires graphics, because this happens deeper in the IOU circuit. But lores graphics and text address scan sequence being exactly the same, it indeed may be possible to trick the video recoding ROM into making text instead of lores graphics, but I didn't try that myself so we have to trust 'frozen signal' who suggested that trick.
The question about "forcing" anything can be answered as such: with aged ICs there is always a risk that something has weakened and breaks when being manipulated. But in the typical case, these old NMOS technologies are normally able to sustain shorting an output to ground, as the NMOS which drives the pin "high" acts as a current source which is weak enough to limit the "short circuit" current flowing out of the pin to sustainable levels which won't blow up anything. You can test that by just putting a multimeter in the 200mA current between ground (black wire) and the pin in question (red wire). Tap the pin briefly and read the current. Anything below 50mA should be sustainable, at least for a while, unless there is an issue with a deteriorated, aged, bonding contact (see the topic of intermetallic compounds above in this thread). It is not advisable to run any IC for long periods of time with a forced output pin, but for brief experiments it should be OK. I use that trick a lot. But don't try that with CMOS, or bipolar ICs. CMOS may get damaged, and bipolar (TTL) will almost always die.
If any of the two ICs in question (IOU or the video ROM) is socketed, you can pull it and carefully bend away a pin sideways (not the "needle" alone, the whole thing must be bent, where it comes out of the package). These are normally at a 90 degree angle to the package and if you bend them up to ~120 degrees, which is just a little bit, you can put the IC into the socket without the bent up pins making any contact. Then you can apply whatever logic level you want at the corresponding video ROM pin. Keep in mind that this pin bending trick works only once or twice. If you bend the pin too often away and then back, it will break. Whatever you do, do it at your own risk only. The video ROM can be replaced by an EPROM, so losing it is bit as bad as losing the MMU.
- Uncle Bernie
I usually prefer if possible rather than bending pins on a chip to insert the chip into a socket and then bend the pin on the socket. Sockets are often even more fragile pin wise than a chip, but they're cheap and readily available. If you break off a pin on an unobtanium chip like an IOU or MMU it is time to cry... A socket you shrug your shoulders, maybe utter a choice 4 letter word, chuck it into the waste bin and grab another socket.
So I tried both methods. with the PIN 2 out the socket I got the same display (i.e. repeated lines of the same dot pattern) but on a black background without the "zebra" stripes. With PIN 2 connected the current to earth was around 50mA which is a bit borderline so I just touched but confirm the same behaviour was observed.
Useful bent pin on the socket trick. I have had to do this when reading some of the TMS2716 eproms to supply the extra supply rails.
I think I'm going to have to get out the HP16500B on the full address bus to be sure that the program execution is continuing as planned. I did once repair a system where a mask ROM was putting out data when its OE was not asserted.
Hi 'afrb2' -
Since you got desperate enough to venture into the MMU schematics to 'save'your MMU, here is a little hint I can offer to you:
ROM1 = !INH & PHI0 & C8TF & INTC3EN " enable in [C800-CFFF] if INTC3EN set
# !INH & PHI0 & C3XX & !SS_INTC3 " enable in [C300-C3FF] if SS_INTC3 OFF
# !INH & PHI0 & C1TF & SS_C3ROM " enable in [C100-CFFF] if SS_C3ROM ON
# !INH & PHI0 & DXXX & RNW & !SS_RDRAM; " enable in DXXX if SS_RDRAM OFF
" CXXX output. Use negative polarity because the PT's actually are disables for CXXX.
!CXXXP = C8TF & INTC3EN
# C3XX & !SS_INTC3
# C1TF & SS_C3ROM
# LOWER48
# TOP12K;
These equations come from my PLD implementation of the MMU, which runs my Apple IIe. No warranties of any kind made that these are correct (at least the built in self-test and "Wings Of Fury" runs fine) but what you can see is that CXXX gets asserted in the address range $C000-$CFFF unless ROM1 gets asserted, if we ignore the additional factor of the INH and PHI0 signals. So you could try to replace the defective CXXX signal with:
CXXX = !ROM1 & A15 & A14 & !A12 & !A11;
Which could be done with a few TTLs. !ROM1 of course is the pin #20 of the MMU.
Maybe this helps you. I don't know, as I didn't try to build that, and since it's your Apple IIe which doesn't work, you have to spend your own time on trying it out.
Still, I'm curious to learn whether this klugde works or not. My best bet is that if it doesn't fix the issue, the fault is elsewhere (or deeper in the MMU, see all the soft switches and memory ranges involved). But if it's only a broken CXXX pin driver, then it should work (almost nothing uses !INH). I see a possibility of a glitch on CXXX, but if that happens, and if it causes trouble, it could be suppressed by an RC network or some further gating of tne 'new' CXXX with a slightly delayed PHI0.
Keep us current on your progress !
- Uncle Bernie
That was very helpful indeed. I stuck it in a hex file and was going to program into a little bipolar prom and them remembered the Data IO programmer is at the other end of the country! Will try with some 74xx!. But I would be grateful for any insight into the O notation in the MMU diagram. This N-MOS type design is older than anything which I'm really familiar with, but the circles looks like a wire OR, possibly used with active low signals (so what is denoted xx0x here is probably /xx0x since if any of A4-A7 is high it pulls up the line). But would be good to know from someone with actual experience of IC design! (I understand the module blocks like DET R (which seems input protection) and det B which is an inverter and a "super inverter" providing buffered signal and /signal).
ors.png
In post #17, afrb2 asked:
"But I would be grateful for any insight into the O notation in the MMU diagram. This N-MOS type design is older than anything which I'm really familiar with, but the circles looks like a wire OR, possibly used with active low signals (so what is denoted xx0x here is probably /xx0x since if any of A4-A7 is high it pulls up the line)".
Uncle Bernie answers:
Each larger bubble at a wire crossing stands for a NMOS transistor, its gate tied to the vertical input line, and its drain tied to the horizontal output line. The source is grounded. This yields a NOR gate with as may inputs as there are those bubbles. The pullup transistor to make the "H" level most likely is a depletion NMOS 'hidden' or implied in the little NOR symbol, i.e. the #60. This is not another NOR. It's the same for which the bubbles are the input transistors.
Note the "DET B" differential drivers. They have a "T" = True and a "F" = False output, the latter one inverts the input "I".
What happens is that any vertical signal getting "H"will activate all the bubble transistors attached to it, and this will pull the corresponding horizontal line low, so the output of the NOR will go low "L", which would be the node / signal line connected to the smaller bubble on the left hand side of the NOR symbol. These smaller bubbles not being at a wire crossing are genuine "inverting" bubbles. They can appear everywhere, even on gate or function block inputs.
This notation is confusing at first, and every semiconductor company had their own special little twists and rules. Just look how they (Signetics) draw the superbuffers. For those who never did NMOS full custom IC design, this stuff is almost incomprehensible, as if they wanted to obfuscate things.
I have the advantage that my first full custom IC design was done in a 3.5 um depletion load NMOS technology, using a two phase clock system. So I can read most of these schematics. Once we all died off, nobody will be left to understand them.
- Uncle Bernie
Thank you, that was most helpful. It took me long enough to identify the super inverter - I've only previously met the CMOS version of super inverter/buffer and yes, the relevant knowledge was focused on a specific period in time and probably only acquired by those needing to actually work with the designs of the times. I'm sure it was a fun time to be working in the field though.
Since we're talking diagram annotations I pressume the small numbers written x/y are used to denote channel size of the MOSFET? I assume width/length as that's the factor that appears the the transconductance formula which is fortunately units agnostic?
Alan
In post #19, afrb2 wrote:
" ... written x/y are used to denote channel size of the MOSFET? I assume width/length as that's the factor that appears the the transconductance formula which is fortunately units agnostic ? "
Uncle Bernie answers:
I never worked for Synertek, so I don't know their conventions for writing down transistor sizing. One clue from the pad drive transistors (which always are minimum channel length) the minimum channel length in this process is "6". My best guess is that this means 6 um, which is metric. Surprise ! At that time most of the semiconductor industry worked with "mil", 1/1000th of an inch. For instance, the first generation of the 6502 had Lmin = 0.35 mil, which is roughly 9 um. This was typical for Y1975 NMOS. They soon did an optical mask shrink, and could offer the faster 6502A and 6502B. So for Y1980, having Lmin = 6um looks about right.
It seems that they use W/L numbers all over the place, and what complicates matters is that stacked transistors within a gate may have different width. There also were weirder design rules in the industry using scale factors as W/L numbers, and the base unit was obscure. I once worked for a company where this evil concept was used. The idea was that these designs could be pulled out of a cell library and be plugged into any process node down the shrink path. I say "evil" because this concept fell apart around the 350nm node, causing a lot of rework of the cell library data bases.
I did not look into the sizing of that MMU schematic any further because for understanding the logic, the transistor sizing is irrelevant. And even if you somehow guessed it right, what could you do with it ? You don't have a SPICE deck for that long obsolete process.
I think that my MMU substitute (which currently runs my Apple IIe) faithfully reproduces the original IC, but frankly, most of the logic I already had finished RTL source code from earlier attempts, and only the "missing pieces", i.e. that hidden RS Flipflop controlled by access to $C3XX and $CFFF had to be analyzed from that schematic. I also did not know about that wicked reset sequence detector state machine. But all the rest of the logic can be designed from scratch in a 'clean room' setting by just using the description of the various soft switches in the official Apple documentation, in about two or three days. If you work from that Synertek schematic, you may need two or three weeks to arrive at the same result (synthesizable RTL).
- Uncle Bernie