MMU problem?

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.)

... 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

afrb2 wrote:

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. &nbs

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

afrb2 wrote:

UncleBernie wrote:

... 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).

That was interesting especially pointers to MMU schematics - although they do look as if they were for prototype physical HW.  RA0-

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.

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?

oerbel wrote:

There is a dynamic quality to the behavior. If I repeat the reset I can end up with tiny variations -- but this is the normal one and it does exhibit a resemblance to the character placements in the correct screen!

The results of the self-test appear on screen, but I

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.

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

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

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