Hello everyone, I have recently found my old Apple IIe computer in my father's garage. That led me down a rabbit hole and I am now trying to understand the schematics of the MMU.
These:
Apple IIe - Schematic - MMU Logic - 1 of 2
and
Apple IIe - Schematic - MMU Logic - 2 of 2
These schematics seem to be official Apple documents and they are dated Feb. 1983 -- after the Apple IIe's release. So, they are probably very close to the final MMU design.These schematics also probably went through multiple iterations and verifications and should be free of obvious errors.
Yet, there is something really weird behind the logic for the evaluation of INH' (located near C-2 of "MMU Logic 2 of 2", middle right). I'm probably missing something, but all the logic behind and up to the component L8 is ignored.
-If 64K is HIGH, H3-6 will be high-impedance and the value of INH'/SC0 (an input on the MMU, pin 15) will be used.
-If 64K is LOW, H3-6 will be the result of all the logic behind, but it doesn't matter since the N4-9 pin of the OR gate will be HIGH.
Truth table for this:
There is another schematic for the MMU, maybe that one could help us understand:
This one is much harder to read, but it is really fantastic to look at -- to think all this was drawn and designed by hand!As a hobbyist, it's difficult to know if my understanding of it is wrong (it most probably is).This is what I understand of it's implementation of INH'
There are two pairs of NOR gates NOR_1 and NOR_2 in the top-middle, and NOR_3 and NOR_4 below. Both NORs in a pair have the same inputs, but the top NOR of the pair seems to be an enable/disable for the other NOR. (I have never seen such a notation on the NOR output before but again, I'm an amateur)
The output of the pair can be HIGH or High-Impedence, and the two pairs operate one the inverse of the other.
Since a JFETs will block current if it's gate is HIGH and allow current if it's gate is High-Impedence, this is what I think Ob will be:
The input of DET.R is connected to both Ob of DET.U and INH'/SC0. I'm not sure exactly what DET.R does but I think it function similar to a pull-down resistor. So IA of DET.U will HIGH if Ob or INH'/SC0 is HIGH.
Merging everything gives this truth table:
We get the same values for INH' in both schematics. That can't be right because in both cases, INH' can be simplified to:
(not 64K) or (64K and INH'/SC0)
We don't need L8!
I'd be grateful if someone could tell me where I'm wrong.
I've been hoping for a long time that someone will develop a CPLD or FPGA based replacement for the //e MMU (and also the IOU) chip. These parts are getting hard to find. They are basically the only parts that currently would prevent the ability to build a more or less new //e from scratch like can be done with a ][+.
I don't think pin 15 on the MMU is just an input. In the Apple IIe it's being pulled up by a 3.3k resistor that is part of the RP1 matrix, so if 64K is low, pin 15 of the MMU will be whatever comes into H3.
That isn't the circuit symbol for a JFET, and JFETs were not used to make LSI logic chips. Those are MOSFETs.
To understand the function of the circuit, you need to pay attention to those "40/6" figures. They weren't written in for the hell of it. Those numbers specify the width and length of each transistor's channel. The notation is "width over length" because that is proportional to transconductance (g). On a broad view you can think of g as the "strength" of each channel when in the conducting state.
Because the gate of a MOSFET normally has no connection to its drain or source, it acts as a capacitor: once charged high, it will stay high until it is discharged low. So "high impedance" inputs do not switch the transistor on or off, but leave it in its previous state. This implies that your understanding that
must be incorrect, because it would leave both the high-side and low-side FETs switched on at the same time, causing shoot-thru and destruction of the chip.
Looking at "DET. R" is also interesting because it deploys a channel without a gate as a resistor (with a channel length far greater than width), and another FET as a capacitor (with its gate connected to its source, it will be "off" forever and just act as a capacitance). This produces a R-C delay between the input and output of that block, so when the signal feeds back into IA, it is ANDed with a different TS than before. I think this logic means that inhibit is true (logic low) when TS transitions from low to high after D or the /INH/SC0 input has been low.
This makes me seriously question the many voices on the web that expressed the opinion that the IIe ASICs can be "trivially" implemented in FPGA. There is clearly more than synchronous logic there.
Forget the second schematic, but the first one seems to be of an emulator for the MMU chip built with standard TTL chips. Has anyone tried to build it and see if it works? Maybe a full length extension card with a ribbon cable that plugs into the MMU's socket.
If you search mentions of INHIBIT' in this book:
Understanding the Apple IIe
It seems to be an input only pin. Plus, according to the complete MMU schematics, it also seems to be an input only pin.
Thanks robespierre, understanding this schematic will be much more difficult than I though. Two things though:
One, I think the 64K line is not really a 'signal'; it is labeled a 'bonding option'. I think it's value is 'hard-wired' in the ASIC because if you look at the other bonding option, it's called DIANA which was one of the codenames for the Apple IIe. All this to say that it is possible that the TS input is hard-wired HIGH or LOW.
And two, CVT is right. I *has* been done. I can't seem to find it but I remember seeing a photo on the internet of the prototype of the MMU and IOU all done entirely with TTL chips by Apple engineers before the IIe was released. An impressive board of chips but that shows that if there are async effects in the MMU, they are not essential.
In post #4 Robespierre wrote:
"Looking at "DET. R" is also interesting because it deploys a channel without a gate as a resistor (with a channel length far greater than width), and another FET as a capacitor (with its gate connected to its source, it will be "off" forever and just act as a capacitance). This produces a R-C delay between the input and output of that block, so when the signal feeds back into IA, it is ANDed with a different TS than before. I think this logic means that inhibit is true (logic low) when TS transitions from low to high after D or the /INH/SC0 input has been low."
"This makes me seriously question the many voices on the web that expressed the opinion that the IIe ASICs can be "trivially" implemented in FPGA. There is clearly more than synchronous logic there."
Uncle Bernie comments:
DET.R is not a RC delay circuit (the grounded gate turns the transistor off, no channel formed, almost no capacitance). Instead, it's the classic ESD protection structure used in NMOS technologies. For the sake of understanding the logic, you can ignore it and replace it with a direct connection from the pad to the inputs of the logic gates.
The third link of post#1 is a very poor quality scan of a schematic - all I can decipher from it is that the circuit design was done by SYNERTEK targeting their NMOS depletion load process (same process as for the 6502). I think there is some dynamic logic inside although it's such an eyesore I don't want to dig into it any deeper. This can be tricky to implement in an FPGA - you can't do it directly. All the dynamic storage nodes need to be replaced with a register. If there are precharged bus lines which get conditionally discharged by more than one gate, it gets even more tricky. But tools have been written to take a transistor level (SPICE) netlist, automatically analyze it, and then generate Verilog code which mimicks the logic. This Verilog then can be re-synthesized to full custom CMOS or FPGA or whatever. It has been done for the 6502, based on the netlist from the visual 6502 project (www.visual6502.org). And the 6502 has many foul dynamic logic tricks and precharged busses inside. So it can be done. If you have an accurate SPICE netlist. We we don't have (yet) for the MMU or the IOU.
"CVT" in post #5 is right, the first two links point to schematics for TTL based "breadboards" which emulate the desired functions of the planned full custom IC. This was the standard method back in the day. Expecially when replacing existing logic with a custom or semicustom IC. You had to build that "breadboard" which then plugged into the target system. And surprise, surprise - in most cases it did not work at the first power up despite the "breadboard" was 100% the same function of the datasheet(s) of the ICs to be substituted. And then the ICE and the Logic Analyzer where thrown into the battle. The root cause found often was some timing bug in the target system violating the datasheet spec, or the programmer of the code in that target system had "exploited" some undocumented feature of the IC(s) to be substituted. Been there, done that. Since I used PLDs (later: GALs) for my "breadboards" the fix was quick, and after a few iterations everything worked and the customer signed the design off to be cast into a full custom or semicustom IC (aka "gate array"). The advantage of using PLDs was that their source equations could be automatically translated to the form needed to feed the (often proprietary) CAD system of the semiconductor manufacturer.
This said, based on my own professional background, I think the most efficient route to get to a MMU into a FPGA would be to first analyze their "emulator" / "breadboard" circuit and put it into a few GALs. Then build it an plug it into the Apple IIe. Once it works and is debugged, you can then put the PLD equations into an FPGA.
Why not using an FPGA from the beginning ? The reason is, it is much harder to debug together with the target system (the Apple IIe). If you want to hunt a bug down you need access to one or more inner nodes of the logic. With FPGAs you can route inner nodes to pins and attach a Logic Analyzer there, but this is much more time consuming than in case with the (simpler) PLDs where every node is readily accessible on a pin (don't use PLDs with buried registers). Furthermore, any change to the FPGA to route inner signals to pins causes re-fitting of the logic and problems may mysteriously go away or new ones may appear. Despite the actual, active logic should have stayed the same. Only if you start with a "clean slate" design where you don't need to fight unknowns in strange logic made by other persons (in this case, decades earlier), you would use FPGA from the beginning. Because then, you can develop, simulate and the test the FPGA stand alone and then everybody downstream must make their stuff work with your FPGA. This is a completely different situation. Of course, opinions differ and some FPGA offer better ways to probe internal nodes but I found if the function can be done with half a dozen to a whole dozen simple PLDs, then using them for the initial debugging of such substitution projects is quicker and more painless than using FPGAs. I know of cases where designers have used FPGAs and failed to deliver the substitute and then the customer came to us and we did it with PLDs, in two weeks, while the FPGA attempt had wasted months. Typically, these FPGA failures involved those surprising quirks in the hardware and/or software of the target system. I can only imagine how desperate this FPGA designer got when he had two "black boxes" with dubious contents - the target system and his FPGA. Because yet another complication with FPGAs is that the actual logic inside is NOT the logic you wrote in the HDL. This can lead to nasty surprises every time you press the "re-synthesize" and "fitter" button. Only when ALL aspects of the design work to do are fully known and documented ("clean slate" design), FPGAs reign supreme. Otherwise they are a PITA. Take this as a warning. Hobbyists have wasted years of their life trying to re-implement vintage, poorly documented functions in FPGA based "replica" machines. And never arrived at a 100% perfect substitute. And never found out where the differences come from. So, for certain missions, it may be better to dial back the level of technology used to get results quicker.
- Uncle Bernie
Uncle Bernie, your post was the perfect read for a friday evening.
I was a young kid in the early 80s when the Apple IIe came out. And to borrow the words of a wise old man: "I am old enough to have witnessed a lot of 'first times'". I have witnessed the 'first time' people realized computers could be a household item. I read your post and I think you lived through the golden age of hardware development; mature enough to be undertood but still so much to explore and discover. Reading the schematics and books of that era makes me realize how a magical this time must have been. "Anemoia" is probably the correct word.
As for the weird INH' signal, we're fortunate enough to have lots of books written on the Apple IIe. I want to design something as close as possible to the original, but if that's not possible at least the behavior from the outside is well documented. Plus, the Apple IIe is heavily inspired from the II+ and have heavily inspired the IIc. Two systems that are also well documented. And finally, we have AppleWin, an emulator that is very mature and can certainly help us understand the Apple IIe circuits.
In post #8, frozensignal wrote:
"Reading the schematics and books of that era makes me realize how a magical this time must have been."
Uncle Bernie comments:
Yes, these were the glorious 1970s. The birth of the microprocessor. I was there (played as a teen with the first ones, like 8080, and then the 6502) and later became a professional IC designer. One must-read book for true aficionados is:
Mead / Conway "Introduction to VLSI Systems"
These can be had very cheap ( ~ $15) on Ebay and from used book sellers. It's a wonderful book which explains NMOS depletion load dynamic logic design and how to make the layouts. The examples for that 16-bit processor on the cover the students of Prof. Carver Mead have designed have very pretty and clear layouts, although some aspects are ludicrous, such as using excessively long poly runs at some places. Lambda design rules also are area inefficient (although very easy to learn). Professionals didn't do that. But still, once you have understood what is in this book, you can go on the visual6502 web site and understand everything seen there. If you had the original 6502 schematics from MOS Technology, you could read them, too. There are not too many people in the world who have them.
It was a magical time indeed. And I can say that almost everybody who jumped onto that bandwagon back then (full custom IC design, first NMOS, then CMOS) had a very lucrative, rewarding, and satisfying career.
Most are retired now (like me) and have no regrets. We had a good run over 40-50 years. Now the whole semiconductor industry is losing momentum and process technologies have progressed to a point of diminishing returns at exploding costs, both to build these 5nm and below wafer fabs, and to design new products leveraging the powers and capabilities of these leading edge technologies. The problem, as I see it, is that there are not many product types / functions which a) require billions of transistors on a chip and b) can be sold by the 100's of millions before they get obsolete. In other words, they are hitting a wall. Diminishing returns on investment. The big players in the field with deep pockets (lots of $$$ or $$$ credit lines) hoovering up all the smaller players is one sign of that. Salaries for IC designers will fall, same thing what happened with automobile designers, and as a consequence the brighter minds will go elsewhere, towards other industries where the money fountains still are full open throttle. The inevitable consequence of this consolidation process (which happens to every industry once it reaches maturity) is that the products will become more and more dubious and crappy. You can see this already with some consumer products whose ICs obviously were designed by idiots who don't know the very foundations of what they are doing. As an example, cheap flat panel TVs now show a loss (or ignorance) of subtle know-how what IC designers for such functions still had back in the 1990s. Possibly designed by some rookie engineers somewhere in India or China who get the pay of a Walmart greeter and never have seen a real, analog TV in real life. Sure, analog TV is on the way out, but proper support of these legacy systems still should be there.
I think the complexity of and the frustration with these modern electronics is a key factor why more and more hobbyists (and retired professionals) return to the "good old days" where men were men, women were momen, and transistors were transistors. And where discrete components like resistors and capacitors did not look like what comes out of a pepper grinder.
Oh, the good ol' days !
I wish I had a time machine to travel back to 1978. It should also rejuvenate me by the same amount of years traveled. Oh, and of course I'd want to keep my knowledge of modern semiconductor technologies. I could become a real world Tony Stark. Alas, it's just a dream.
Good night !
- Uncle Bernie
I think I have a general idea of what this is. I was way off target it seems.
Thanks to "CVT"; you set me on the right path with your comment that pin 15 not being just an input pin. Initially, I though what if this pin is a bidirectional pin? But why then is it linked to the bonding options?
There is another pin that also use DET.U and DET.R (DMA'/C06X'). What is the link between DMA and C06X (cassette read and joystick input)? And in the pin INH'/SC0, what is SC0?
And finally, if these pins are bidirectional, why isn't it even mentionned in any book?
I started to understand when I tried (in the big MMU schematic) to find other circuit parts that looked similar to DET.U, but whose function were known. MD7 pin is very similar, and we know that it is an output pin. So, I believe that the TS line of DET.U must mean Toggle Switch and DET.U will be an input pin or an output pin depending on TS. And the name INH'/SC0 must mean that the pin will be an input INH' or an output SC0 depending what bonding option was selected at manufacture time. As for SC0, by examining what logic makes up L8 (signals related to the language card), SC0 must mean something like "Slot Connector 0".
We'll probably never know the history behind these input/output bonding options, but they were probably only used at some point during the development of the Apple IIe. And it is clear that no production MMU has these pins configured as outputs with C06X' and SC0. I haven't decided if I should include or exclude the "alternate" pins functions in the HDL code. We'll see.
Also, while searching on the internet I found a photo of the prototype made by Apple:
DISCRETEMMU+IOU.png
(Source: http://www.applelogic.org/files/DISCRETEMMU+IOU.png)
And these are actual delayered MMU and IOU photos:
MMU:
https://commons.wikimedia.org/wiki/File:344-0010_Apple_8314_cleaned_enh_med.jpg
https://commons.wikimedia.org/wiki/File:344-0010_Apple_8314_delayer_med.jpg
IOU:
https://commons.wikimedia.org/wiki/File:344-0020_Apple_8317_die_240nmpp.jpg
In post #10, frozensignal wrote:
"We'll probably never know the history behind these input/output bonding options, but they were probably only used at some point during the development of the Apple IIe. And it is clear that no production MMU has these pins configured as outputs with C06X' and SC0. "
Uncle Bernie comments:
I don't have the time to look into it, but nobody puts useless circuits on ICs. So there are only two possibilities what these "unused" inputs might do:
a) extra functionality which was foreseen for future Apple IId,e,f products but never used.
b) test functions for testing these ICs at their manufacturer.
It is quite common that ICs have pins / pads with undocumented test functions. To find out, analyze under which condition these pins turn into inputs. If that condition is "weird" (meaning: not useful in the target system or makes no sense from the viewpoint of the target system) then it's most likely a test function.
- Uncle Bernie
Haven't the first chips of a series been manually bonded into housings like this?http://www.syntezmicro.ru/uploads/images/service/5u6.jpg
5u6[1].jpg
So it shouldn't be a problem to use some 52 pin housing for the test chip and 44 or 48 pin for the final product.
Beside that the actual chip is larger than needed.
Also there have been a lot of strange IC hosings like the ones below, they would give a lot of possibilities to bond extra test pads:
https://www.cpu-world.com/CPUs/3870/Mostek-MK38P70-02%20(97400A).html