| Attachment | Size |
|---|---|
 retro_devices.zip | 132.23 KB |
In this thread: https://www.applefritter.com/comment/107057#comment-107057, retro_devices asks for help to program the MMU on some old Altera EPM7064LC44-10 and EPM7064LC68-10.I am starting this thread for that discussion.
The two devices are 64 macrocells, which is enough for the 58 macrocells the MMU currently requires.
I'm not too sure that this will be possible on MAX 7000 devices, though.
This is what I did / you can do:
- You need MAX+plus II, and the Advanced Synthesis. Both can be found here: https://archive.org/details/2002-altera-max-plus-ii-1023 (Click SHOW ALL, download 2002_altera_max_plus_ii_1023.7z, and 2003_max_plus_ii_advanced_synthesis.7z)
- Install MAX+plus II, apply the update, and install Advanced Synthesis.
- Unzip retro_devices.zip somewhere.
- Launch Advanced Synthesis and create a new project, add all the files located in "retro_devices\MMU Sources" to the project. (Or open retro_devices\MMU\MMU.max2syn in Advanced Synthesis)
- Assign -> Assign Family and Synthesis Settings, set Device Family to MAX7000
- Start a full compilation
This gives the error: "Error: Logic too complex for ':308' -- no synthesis found"
However, changing the device family to, say the MAX9000 family compiles without any problem.
This makes me think that it cannot be done with these devices.
@retro_devices, can you also try it and tell me if I'm missing something?
With MAX7000 MAX+PLUS II generates 63 macrocells, so the MMU fits. But the 44 pin devices I have lack 2 pins (e.g. they have 36 I/O pins only). But fir the single 68 pin device at my posession I don't have the wiring for the ELNEC/DATAMAN/Beeprog/BK-Precision programming adapter (PLCC68 to DIP48, p/n 70-0195)
https://www.elnec.com/en/products/programming-adapters/DIL48_PLCC68_ZIF_PLD-1/
If someone can show good pictures of the PCBs I think the wiring can be reversed from them. It is just wiring, no active components involved.
... I think I have a few in my basement, never used, at least not by me, as I always hated ALTERA's software pricing and licensing policy.
If you are interested, I will go looking for them and if I find them can tell you which type they are.
They are large (IIRC, PLCC68 or maybe even larger ) so they won"t fit between the pin rows of a DIL-40 but for testing of your design they may be OK. PLCC sockets are cheap and still available and will give you are 2.56mm raster on its pins, just right for WW or hand wiring.
- Uncle Bernie
Unfortunately my single EPM7064LC68 burned while testing the homebrew HILO programmer adaptor for that socket. I have EPM7064LC44 and working adaptor for them but these as discussed have insufficient pins for our purpose. I am expecting 84PLCC adapter bare PCB from a friend to make adaptor for my ELNEC programmer. I have one EPM7128ELC84 and a couple EPM7160ELC84. On the other hand I have dozen of XC9572 84pin PLCC...
So if someone was to put an MMU replacement on a small daughterboard that plugged int the 40 pin socket, how many, say 22V10 would it take? 5?
There is no such open source project available.
Not yet anyway.
I've got a //e motherboard that just needs an MMU... I'm hoping that sooner or later some solution will become available. Something that was like the keyboard encoder or 65C02/65C816 drop-ins that fit entirely in a 40 pin package size would be perfect but even something that took up a bit more room would work.
... I think "softwarejanitor" is right, 5 P22V10 can certainly do it, except that you also need 2 x 74LS257 multiplexers to do the DRAM address multiplexing. In my newest MMU design, I have moved the soft switches out of the GALs, into humble TTLs, except for the 'language card' function, and arrived at 4 smaller GALs (22V10 being overkill for that, the 22V10 has 132 Product Terms and only ~30 are needed per GAL .... the limit is the pins per package, and proper partitioning of the logic is tricky. This is why my first attempt was not all too efficient / lean. But it works, as evidenced by the Replica 2e prototype running all the Apple II software I have.
I've also resynthesized the whole MMU into a single Lattice ispLSI1016, but again, lack of pins forces the use of one 74LS257 for the muxed DRAM addresses. It's not efficient to do this in any PLD or CPLD. It's a total waste to do 2:1 multiplexers with costly macrocells.
Alas, this work has stalled when my ~Y2002 Tower PC on which the ispLEVER runs got too wonky, crashing too often, and screwing up the project database in the process. I have a plan to make a copy of the hard disk and then change the electrolytics on the motherboard. Hoping that I could continue to do LATTICE pLSI/ispLSI designs on it. But I have no fixed milestone / deadline planned for that. Too many plates spinning. All the designs using smaller PLDs (like GALs) I can do with more stable computers I also have.
- Uncle Bernie
I kind of figured that in a lot of cases the pin counts were the limiting factor. That's kind of what led me to figure around 5 22V10 would be needed. How much work would you think it would be to lay out a small day 100mm x 100mm board that would plug into the DIP 40 socket for the MMU that would be able to make a //e board work? That's less than optimal for things like slot access, but many cards are short enough it wouldn't be a problem anyway. And 22V10 and a couple 74LS chips is something that a large number of hobbiests can build at home. Inexpensive TL866CS/TL866-II+/T48 programmers can handle 22V10s, either the Lattice version or the more even more readily available Atmel AT22V10B.
It's too bad there is such an issue these days with 5V PLDs, both availability of the parts and also the development tools. That's one of the reasons why proprietary development tools suck, because they "rot" over time. The machines they run on become difficult to maintain, knowledge of how to use them dispears as people age, etc.
Yes, it's really a pain. That's the hardest part, and most frustrating. The IOU / MMU replacements should be available by now if it wasn't for the issue of finding the parts. But all the CPLDs I bought were bad, as well as those bought by Henry. And we wasted a lot of time making sure it was not the PCBs that were at fault.
Also, the irony is not lost on me; we want to replace obsolete ASICs with obsolete CPLDs... Still, I have ordered maybe 30 EPM7128STC100 from different vendors on ebay to see if we were just unlucky or not with our past batches.
Speaking of 5v devices, I just became aware of the ATF1504AS, which is an actively produced 5V CPLD with 64 macrocells, and the ATF1508ASL which is 128 macrocells. It's supposed to be compatible with the Altera MAX 7000S. They're expensibe though and I don't know just how much compatible they are.
As a plan B, I have designed a 3v3 alternative. They are much more complex however, as you can see:
Non working 3v3 IOU
All inputs must be level-shifted, and bidirectional signals must go through something like 74LVC245s and you also need a direction signal. It's more complex, but everything is available and cheap.
I initially used the iCE40UP1K-SG48 but I thought that there was not enough GPIOs. So, I switched to the iCE40LP1K-QN84, which is a dual-row QFN and is much more difficult to solder. My inexperience in designing PCBs really shows. There are several problems that make this version useless. One of which is that there are no PLLs nor internal oscillator in that particular package and I didn't see the footnote that mentionned this. So, there's no way to add the /RAS hold delay on the ORA lines. That means back to the drawing board with this. And there are in fact enough GPIOs with the iCE40UP1K-SG48; the open-drain pins can be used as GPIO with a special primitive. And this package has an internal oscillator.
Hopefully, version 2 will work. And all the bad EPM7128STC100 was just a fluke.
I'm quite familiar with this part : 5V, available, fairly cheap ($2-$6), and you can even use CUPL to design. Let me know if I can help.
This is amazing! Even though I don't need one right now, just knowing it's out there gives me peace of mind. Great work! God knows how many Apple IIe machines will be brought back to life because of this.
I'm really looking forward to when an MMU replacement of any kind is available, as I have a motherboard that is good to go otherwise. I also have an empty //e case, a power supply and I've got a Retroconnector //e USB keyboard adapter Rev 3 that I just need to figure out how to get the code built for in Adruino IDE.
In order to be able to program some PLDs I have related to MMU/IOU I am looking for someone who has and is able to check continuity for part of the pinout that is unknown to me for any of the following programmer adapters:
For HiLo:
ADP-7064S-PL44
ADP-7064S-PL68
ADP-EPM7128E-PL
ADP-EPM7064-PL
ADP-EPM7160E-PL
For ELNEC and compatibles (Dataman/BK Precision/Beeprog, etc.):
DIL48/PLCCnn ZIF PLD-1
DIL48/PLCC84 ZIF PLD-7
In post #10, frozen_signal wrote:
Yes, it's really a pain. That's the hardest part, and most frustrating.
Uncle Bernie comments:
That's called "technical progress". No snark / pun intended. Since I worked as a IC designer I saw what happens when going down the "shrink path". The first larger CPLDs, still 5V, were made in 0.8um CMOS processes. Such as the Lattice pLSI / ispLSI of the early 1990s. Ithink, but I'm not sure, that the much cheaper "E" series of them probably werde made in a 0.6um CMOS process. Many manufacturers skipped 0.5um, the last process node where you can have 5V supplies. They went to 350nm and this is 3.3V only. Down to 120nm CMOS you can use the rule of thumb that you divide the Lmin in nm by 100 to get the typical supply voltage (i.e. 180nm / 100nm = 1.8V). Many processes offer dual gox options where you can make so-called I/O transistors who are able to sustain higher voltages, but this drives costs up. And to keep costs low, these I/O transistors often don't use proper drain engineering and have all sorts of issues with impact ionization etc. Alas, if you want a 100k gates FPGA at a cheap price you have to use such advanced deep submicron processes. And since everything else in a modern system also follows the shrink path it uses lower supply voltages anyways, so no issue there. But with modern FPGA /CPLD designs for legacy 5V systems, which normally nobody does, we run into the supply voltage and logic levels problems. This is inevitable and not malice on behalf of the FPGA/CPLD manufacturers. They just can't beat Laws of Physics.
If you need a few Altera EPM7128, I think I have some in my basement, never used, but they are PLCC. Semd me a PM if interested.
- Uncle Bernie
Do you know if they support the LCELL primitive? I suppose they do since you can use Quartus II to generate the .POF file and then convert it for the ATF1504 with their POF2JED utility.Also, do you know if the USB Blaster works with them? Their programming cable (ATDH1150USB) seems a bit expensive for what it is.
Thanks UncleBernie, but my real problem is not having a supply of the EPM7128STC. There's no point developing a replacement using this device if all you can buy is bad fakes. I will wait and see how many bad chips I get from those I bought on eBay. If it's as bad as my last batch, we'll probably use the ATF1504/8 or a 3.3v design.
Some partial progress. I found my second and really last EPM7064LC68 and managed successfully to build a programmer adapter for it. The MMU fits in 63 macrocells when built with Max+Plus II. Still have to make a socket adapter for the Apple //e to try it in there.
mmu_altera_7064.jpg
That's fantastic news! What exactly is this unstability? If you hold the Return key at the BASIC prompt does it beep (and possibly goes into the monitor)? You may be missing the /RAS hold delay. If you have an oscilloscope, or a logic analyzer, you can check that the RA[7-0] signals hold their values about 40-50 ns past the falling edge of /RAS.
The synthesis possibly removes the LCELLs that adds this delay. Make sure that the option to keep these LCELLs is selected. If it can help, in Quartus II, it's in Settings -> Analysis & Synthesis Settings -> Ignore LCELL Buffers (should be OFF)
Other settings that might be a good idea would be to turn off 'Power-Up Don't Care' (init everything to '0'), and use Slow Slew Rate.
Congrats for your progress!
I am running saturn card extensive continuous Locksmith test. The value of LCELLS is increased to 17 and that uses all 64 macrocells now but still requires an external RC delay. Last experiments led to 1 indicated error in several hours so it is much more stable than you supposed. But any error inducing compared to authentic MMU is unacceptable. Still improving.
Very excited about the progress! Hopefully any remaining bugs will be worked out and an available chip will be usable and we'll soon have MMU replacements available.
Well, the progress is not great. I achieved no errors for about 12 hours in an Apple //e with properly selected RC group. I cancelled the tests at that point and removed the Saturn RAM card added a 128M RAMWORKS1 card to the AUX slot and that caused significant degradation. Even the selftest started reporting RAM errors. Then I moved to a Pravetz 8A clone motherboard of mine partly because of the better MMU scoket there. And to my surprise with the PLD MMU the computer was showing no signs of software/firmware life.
My conclusion for now is that the MMU logic is correctly represented in the leaked TTL schematics but the timings are critically imortant and have to be well tuned/delayed with a specific PLD that has sufficient resources for synthesizing delays. It looks the loading capability of the PLD outputs should be taken into account too.
In post #22, 'retro_devices' wrote:
" My conclusion for now is that the MMU logic is correctly represented in the leaked TTL schematics but the timings are critically important and have to be well tuned/delayed with a specific PLD that has sufficient resources for synthesizing delays. "
Uncle Bernie comments:
The TTL schematics are NOT the logic what is in the custom IC.
Timing of MMU signals is nowhere 'critical' as long as it is not in violation of some timing parameters of the DRAMs (check the /RAS and /CAS related address setup and hold times). I don't know if your 'Pravetz' computer has a knockoff of the TMG PAL but this one makes the /CAS for the main memory and if the timing there is wrong it won't work (the /CASEN from the MMU is only an 'enable' signal and the TMG PAL adds the proper timing) . The original TMG PAL also has an (unused) pin which is the legacy 'AX' signal that can be used to control the ROW/COL multiplexers.
There are some subtle timing details you can see if you analyze the transistor level schematic of the MMU custom chip. Such as where the soft switches get updated, how the RESET sequence detector really works, and how the MMU extends the hold time of its sole data output.
But none of these would require a PLD with a clock synthesizer. RC delays are good enough. The custom IC exploits the slow speed of the NMOS transistors for this purpose.
The exact time where the ROW and COL addresses are actively driven and where they go away also is important, as the IOU grabs them to get the addresses for its own soft switch activity. The IOU itself is a can of timing worms. Maybe it's the MMU/IOU interaction which does not work in your Pravetz (I had no problems making my MMU substitute work but my IOU substitute based on Jim Sather's book initally did not work at all: the computer did not start up. I had to change some of the timing massively, deviating from the book, to make it work).
Also, beware of the 6502 timing issue with the crumbling addresses after PHI2 from the 6502 falls. Apple II mitigates that a little bit by making 'fake' PHI1, PHI2 signals and does not use the 'official' ones offered by the 6502. There is a thread here on Applefritter about this problem which has 'bitten' many 6502 hackers. This problem gets worse (and manifests more often) with more modern ICs which are fast enough to react to the crumbling addresses. This does not affect DRAMs, though, as they latch the addresses on /RAS and /CAS fall. But crumbling addresses may wreak havoc with address decoder based enable signals, and the soft switches.
- Uncle Bernie
What is the logical difference?
I switched on my old 20 MHz oscilloscope and observed some spikes within the pulses on RA bus which are not present with the original MMU. Some race conditions with faster PLD may lead to this accompanied with the unknown synthesis inside the PLD. Added decoupling capacitors to filter power line but this changed nothing with the behavior of the MMU. Anyway, I am not desperate, I have sufficient number of real vintage Bulgarian MMUs for my needs and I am not going to invest more time (or purchase anything) into emulating MMUs for now. But will help frozen_signal with further testing when they come up with something more tuned to PLDs if I have necessary components at hand. The Pravetz 8A has analogue of the Apple 2e's HAL/PAL in a slightly different socket. Apple's MMUs work in Pravetz 8A and vice versa.
Just wanted to add I plugged the Apple HAL into the Pravetz computer and the Altera MMU still showed no signs of life. It seems that the most serious part of this project is to adjust the timings than recreating the Apple emulator schematics in VHDL alone. If someone wants to send me their POF file to test with EPM7064LC68-10 device here is the pinout of the wirings I used (automatically chosen with the first build and then kept):
CHIP mmuBEGIN MULTIVOLT_IO = OFF; |A11 : INPUT_PIN = 8; |A15 : INPUT_PIN = 9; |A12 : INPUT_PIN = 7; |A13 : INPUT_PIN = 10; |A9 : INPUT_PIN = 12; |A1 : INPUT_PIN = 17; |DMA_N : INPUT_PIN = 18; |ORA4 : OUTPUT_PIN = 19; |ORA5 : OUTPUT_PIN = 20; |ORA6 : OUTPUT_PIN = 23; |A7 : INPUT_PIN = 24; |A6 : INPUT_PIN = 25; |ORA2 : OUTPUT_PIN = 28; |ORA3 : OUTPUT_PIN = 29; |A0 : INPUT_PIN = 30; |A5 : INPUT_PIN = 32; |INH_N : INPUT_PIN = 33; |A4 : INPUT_PIN = 41; |R_W_N_245 : OUTPUT_PIN = 42; |ROMEN1_N : OUTPUT_PIN = 44; |ROMEN2_N : OUTPUT_PIN = 45; |A8 : INPUT_PIN = 46; |PRAS_N : INPUT_PIN = 47; |A14 : INPUT_PIN = 49; |A3 : INPUT_PIN = 51; |A10 : INPUT_PIN = 56; |A2 : INPUT_PIN = 59; |ORA7 : OUTPUT_PIN = 22; |ORA1 : OUTPUT_PIN = 4; |ORA0 : OUTPUT_PIN = 27; |EN80_N : OUTPUT_PIN = 57; |KBD_N : OUTPUT_PIN = 54; |MD7 : OUTPUT_PIN = 40; |CASEN_N : OUTPUT_PIN = 52; |CXXXOUT : OUTPUT_PIN = 37; |R_W_N : INPUT_PIN = 14; |PHI_0 : INPUT_PIN = 67; |Q3 : INPUT_PIN = 15; TURBO_BIT = ON; SECURITY = OFF; DEVICE = EPM7064LC68-10;END;
I am beginning to receive the CPLDs I ordered on eBay some weeks ago. So far, they seem functionnal. I have assembled an IOU with one of them and it works.
I will assemble a MMU in the coming days, more probably this weekend though. What do these spikes look like, like incorrect data or like signal integrity problem? I understand that your implementation works when an AUX card is not inserted, but doesn't when there is one present, is this correct? I have assembled a 3.3v MMU (on a MACHXO3D breakout board) with the latest sources in Feb. and I didn't notice any problem. There might be problems with the code, but if there is something, it must be pretty small, or as you said a timing problem.
Also, a big thanks for your help with the MMU!
Hi. There was not much help at all. Your 3.3V solution may work due to slower 3.3/5V buffers/converters that flatten the glitches within the supposed pulses. The MMU on my side became more and more stable once I added and gradually increased an RC delay on PRAS# input. With no external delay the computer hardly shows Apple "welcome" screen. I tried to isolate the delay only for the MMU by adding a 7400 elements in series to PRAS# and/or RC circuit but nothing gained. Plugging a RAM card in the AUX slot just spoils that hardly achieved stability. The errors as far as I diagnosed were RAM errors. The same Altera MMU does not work at all in another functional Apple //e clone that works perfectly with factory MMUs. My intuition tells me the root of the cause of instability in one computer is the same as for the completely failing issue in the other computer. What CPLDs are you receiving from ebay? What PLD were you using for your successful IOU tests?
In post #27, retro_devices wrote:
" The MMU on my side became more and more stable once I added and gradually increased an RC delay on PRAS# input. "
Uncle Bernie comments:
This is unexpected. /PRAS timing in the Apple II is sound. So it's worth to think about possible causations why you need to delay it by an RC.
Something else may be wrong in your design.
Check for the gating of your ROW/COL mux (when is it enabled ? /PRAS is far too late ... the mux must be enabled / start driving earlier).
Also, you need to be careful if you derive clocks or gating signal within your CPLD from any of the /PRAS, Q3, PHI0 signals. There may be races which may cause glitches. This may happen in any spot where two (or more) of said signals change state at the same time. The classical 'logic hazard' situation. The 'hazard' may manifest (or not) depending on the production lot / process corner of the PLDs, ad on random delay variations within the target system (how it makes said signals).
It gets worse when using FPGAs because of the added routing delays. CPLDs (or simple PLDs) often 'mask' the issue due to their differential column driver structure (it seems the designers of these ICs took care to make the propagation delays to the inverted and non inverted columns the same) but actually this may make matters worse as the ideal situation may go away with a different lot ... I could tell you stories how this has ruined a lot of projects of unwary designers who did not use my famous 'ambigous delay simulator' which would show the hazards in PLDs. Their companies may have saved five figures on my CAD tools but then lost projects worth millions (fair enough, cheapskates !).
As I still use my old tools for my own designs I saw some of these hazards in my early MMU and IOU substitute designs and fixed them by masking certain transitions with redundant PTerms or asynchronous latches. So I know the opportunity for hazards lurks in these designs, especially if you follow Jim Sather's book for designing the IOU. The circuits he shows in the book are OK to make readers understand the principles, but they won't work in the real world.
IMHO, neither the original MMU nor the original IOU are perfectly sound designs. The transistor level schematic of the MMU which has been leaked and can be found on the web uses gate delays (easily to be had with slow NMOS) and dynamic nodes to mitigate some of these issues. Any attempt to put the same logic 1:1 into a fast device must fail, sorry. No IOU transistor level schematic ever made it to me, but I think it's the same sort of compromise. Which was quite common back in the 1970s / early 1980s when NMOS reigned and was slow.
I have a hunch that the demise of certain vintage computers based on once great MOS full custom ICs like the 8-bit Ataris and the Amiga came not only from technical obsolescence (or incompetent corporate management) but from deeper root causes, I think they simply could not migrate their custom ICs to more modern process technologies which would have allowed smaller die sizes / lower cost AND adding more functionality. Part of the problem certainly is that the original designers of these ICs long had been laid off or had left the company. And the 'leftovers' were too weak of mind to understand all the concepts and potential pitfalls in the original grand designs.
Just as a footnote, even the spreading out of the MMU/IOU logic over several PLDs is full of timing hazards and pitfalls. Clocking two PLDs with the same clock does not mean you got a fully synchronous state machine which ought to work. Especially if the two PLDs are of different type, from different manufacturers, and/or of different speed grades. Paying attention to setup and hold times is essential. And the problem is that many PLDs are much faster than what is stamped into them, especially when they were made in the 1990s, using faster process technologies. There is a reason why typical datasheets never tell you a 'min' value for tpd and tco. So, how do you make sure that hold times are observed under all circumstances, including finite speed clock edges and ground bounce shifting the actual point in time where the flipflops get clocked ?
In college, all the synchronous state machine design looks trivial. In the real world, it is not, because real world effects have to be taken into account, and these get worse the faster the ICs get. This is why I avoid 'fast' CMOS PLDs as much as I can avoid them. If the manufacturer claims they can be clocked with 150 MHz (on a tester !) then this does not imply you can make a functional state machine with them, especially if your have more than one of those ICs which need to work together. Oh the horror ! (the fastest state machine I ever built which worked was running at 3.125 GHz clock speed, so believe me, I can do it, but I won't tell you how much time and money this 'fast' one did cost the company I designed it for).
- Uncle Bernie
We used the Altera EPM7128STC100 to develop a IOU replacement. A great CPLD that is easy to use.
Unfortunately, it's not produced anymore and buying these is like a box of chocolates; you never know what you're gonna get. Except in the case of the chocolates, they will all be good to some degree.
I have bought a bunch of these CPLDs back in december and they were all bad. I have since bought several other small batches from different vendors on eBay to see what, on average, should my expectations be when buying from these kind of 'suppliers'.
So far, the batch I received seem to be functionnal. I should be able to build a MMU with one of these this weekend and compare the official IOU vs my implementation.
The exact story behind these logic schematics and the MMU transistor level schematics is unknown to me, but I know they were obtained by Henry (Henry S. Courbis, founder of ReActiveMicro) at KansasFest 2016.
I asked him if he had the IOU transistor level schematics and said he didn't. They may be lost and I'd be surprised if they ever become available.
He also said that he doesn't know what exactly these schematics represented. We know that the logic schematics are for an emulator that combines both the IOU and the MMU.
And no one knows just how similar is the MMU transistor level schematics to the actual MMU.
In post #29, 'frozen signal' wrote:
" And no one knows just how similar is the MMU transistor level schematics to the actual MMU. "
Uncle Bernie comments:
True that, we can't be sure about which state of the MMU custom IC development these schematics represent, but I found that my MMU substitute based on this transistor level schematic can run in "lockstep" with the real MMU, while the earlier one I based on the TTL logic would not do that. Where the differences / bugs / mistakes made are located, I never found out. Once it works, it works ! ... and no need to find out what went wrong in earlier attempts.
And from lots of little details (or the absence thereof) on the schematic I'm pretty sure it was very close to the final one which then made it into silicon. Back then schematics were hand drawn and edits were either made by erasing / scraping off of minor faults (which leaves witness marks even in the blueprint copy) or, for larger edits of worse faults, pieces were cut out and new vellum paper was glued on to draw the new, corrected parts in. In this case, the "wire" lines never join perfectly, under magnification you can see that.
Absence of such hints means the schematic was close to the finish line, or the very first one before bugs were discovered. The info in the box in the lower right corner can help to rule out the latter. It's a "ADAM REDO" (so it's likely a "redone" = REDO version, not the first one), of the "FINAL LOGIC" and then there is a comment signed by Bob Bailey above the box dated 4/29/82 with the text "shows edits to make 3/34". Still. it is missing some signatures from "higher ups" to show acceptance by the customer (Apple) and to approve production. So it certainly is not the "final" schematic they ever had for the MMU.
Pretty much evidence that this is a further developed version with bugs fixed.
"Bob Bailey" might be the "Robert Bailey" which is mentioned as the 2nd inventor (other then Wendell B. Sander) in U.S.-Pat. 4,742,488
... which is the IWM patent but I see a pattern here that all the three custom ICs seen in the IIe/IIc (MMU, IOU, IWM) may have been designed by the same team at Synertek and Apple. Oh, if I only could get my fingers on a IWM transistor level schematic. This one is a much harder nut to crack than either the MMU or IOU.
- Uncle Bernie
I don't know if you can read/reverse engineer the silicon gates of a decapped IC, but if it's the case, you may be interested in this (micrograph of a decapped IWM): https://mirrors.apple2.org.za/ftp.apple.asimov.net/documentation/hardware/storage/disks/Apple%20IWM%20-%20Silicon.tif
Understanding these must take an incredible long time, but still I wish I could read them.
There are other specifications and documents in the same directory as the photo above, they may also be of interest to you.
In post #31, 'frozen signal' wrote:
" I don't know if you can read/reverse engineer the silicon gates of a decapped IC ..."
Uncle Bernie comments:
Of course I can do that - it's part of the skill set of an IC designer. You must be able to look down on a die mounted in a probe station through a stereo microscope, to target and shoot lasers at it (to remove passivation or cut a metal or poly run) and then to set probe needles on a specific node, to inject or measure signals. If it's smaller then maybe 0.5 um process then you can't do that directly anymore, you need a FIB machine (and its skilled operator) to drill a hole down and deposit a probing contact. This is part of the explosion of costs when you go down the 'shrink path'.
But this is based on knowledge of the circuit and the layout. Just working from a TIF image it can take man-years to extract the transistor level schematic. I saw that in the 'sanctuary' of some Eastern Bloc semiconductor companies I visited just after the "Iron Curtain" had fallen. They had huuuge enlarged photos of Western microprocessors mounted on walls, and every transistor and metal or poly line had hand written numbers on it. All this to reverse engineer long obsolete Western ICs. It eludes me why they went the hard way, and didn't do layer by layer removal, take photo, digitize, rectangle extract, transistor extract, network extract. All essentially automated ... and the software to do that can be written in a few months. But no, they worked on the top level photo like the TIF in your link.
Back to the IWM:
I can't spend 4 years working on reverse engineering the IWM (like the guy who did the 'Yellowstone' card, a 'Liron' clone plus extras, allegedly spent on his project). I had allocated 2 weeks to reverse engineer the whole IWM. I'm now 2 days past that deadline. The work is almost done, huge progress was made in the last days, I can now run more than 1 million clock cycles with random (but floppy-disk-ish) RDDATA pulses and the "C" model stays in lockstep with the real IWM in the test rig. The only open issue is to find out the exact nature of the 'dead zone' after a RDDATA pulse (flux change). So far I avoided that issue by just prohibiting two RDDATA pulses from being closer together than a bit cell. But this is an important detail which needs to be investigated thoroughly to get 'state machine equivalence'. It's the last missing piece.
There are, however, some subtle risks with that approach. The mathematical proof of 'state machine equivalence' is an algorithm which depends on knowledge of both netlists of the two candidate state machines. This works fine and is 'exact' in the mathematical sense if you have RTL #1 for a state machine and then RTL #2 for the same function, but with inner different workings (different partitioning, different state encodings...). Synthesize both into netlists and run the equivalence prover. Easy.
But I don't have the netlist for what is inside the real IWM. So there is a residual risk that the real thing has some 'side branches' or 'extra states' or 'extra transitions' which are not present in my RTL. Hence, my proprietary CAD software won't look for these unknown things. It can only look for known things in my RTL to be present in the real IC on the test rig. If a deviation is found, it's by happenstance. This is why I also employ random number based tests. The final run will comprise trillions of clock cycles, and not the mere million I run now.
With a transistor level netlist, all these residual risks of having missed some 'fine point' goes away. But we don't have that, and probably never will. It's all about how much time somebody wants to spend on the work. My RQLT is too precious to spend more than a few weeks on the IWM.
- Uncle Bernie
Which countries have you visited and which CPUs have you seen reversed that way?
In post #33, 'frozen signal' asks:
" Which countries have you visited and which CPUs have you seen reversed that way ?"
Uncle Bernie answers:
That was a stressful round trip over weeks through the whole ex-'Eastern Bloc' semiconductor industry, which I did for Western semiconductor companies as a consultant, they paid all the expenses. They wanted to probe if they could invest in wafer fabs there (hopeless) or to employ the IC designers there (mostly, very capable engineers only hobbled by the cr@ppy process technologies they had at their disposal). Sorry, but despite it was some 30+ years ago my contract is still binding me to not disclose where I went and for whom I worked on this mission.So I can't tell you about places, names, and critical details. But still, I can tell you some anecdotes from that 'adventure' ;-)
I think I can tell you that I was told in one of these places that the IC on the wall was from DEC (probably a LSI-11 or later versions of the PDP-11 ISA, but this is my conjecture, they did not tell me what it really was) and they also told me (somewhat proud) that they were able to 'partition it' into several ICs because with their CMOS process having a larger Lmin they could not do the die size needed to make it single chip. What a mess. If you go off chip you add delay, so the result will run even slower as what is caused by the slower process anyways.
This was a colossal waste of man-years and of capable engineers. I think that in less time, they could have designed their own compatible ISA from scratch, without any reverse engineering based on blown up die photographs. The Russians did that, so I was told. They had a single chip LSI-11 equivalent. Which was superior to the original LSI-11, which was a four IC affair. But I also met a Russian team on that trip by happenstance, and they told me that a) I was wasting my time with these inferior fabs and b) if I'm really looking for a good process technology, I should look at their 1um CMOS process they have in Russia. And they (the Russians) told me that their dual metal stack worked, but the "idiots" at this Czechoslovakian fab still were struggling with shorts between M1 and M2 (I don't know if the dolmetsch got the "idiot" right and they really meant that). Overall the Russians were boasting with confidence that they had the superior wafer fabs and the better engineers. Hmmm. Western wafer fabs had made the step to the 600nm node just two years earlier, and made he step to 350nm two years later. So even the Russians were lagging at the time, but not as bad as all the others in the ex-Eastern Bloc. (Western wafer fabs had the 1um node in Y1984). It seems to me that the Moscow based central planners did not allow any other Eastern Bloc nation to have the same (or a better) process technology than Russia itself.
There is a certain irony that their optical printers to make masks were made in East Germany, driven by a Russian computer (cyrillic character set).
Seems the plan had been all along that in case one of the Soviet 'satellite' nations would break off, they would lose access to tools/machines/spare parts they would need to keep their semiconductor industry running.
But one curious detail was that some of these semiconductor factories had huge departments which made their own process chemicals. Or purified them. It seems that this gave them some independence from broken supply chains, as far as these chemicals were concerned.
I never visited Russia because this was not the part of my mission (Western companies would not be allowed to invest in Russian semiconductor industry, and bring in their tools and their technology, all was under export ban). So I never saw what the Russians had. But what I saw elsewhere in terms of wafer fabs was shocking. I wonder how they made ICs that worked at all, would have good yields, or would be reliable over longer periods of time. But I wrote an accurate, factual report on what I saw and was told.
I got my money and expenses paid, and fulfilled my mission. I don't know if there ever have been investments / acquisitons of ex-Eastern bloc semiconductor companies by Western semiconductor companies. But years later a CTO of an American company told me that they had moved their whole 8-bit MCU development to Romania. IMHO a doubtful move, but certainly smarter than moving that work to, say, India. I once was Principal Engineer at one of the bigger semiconductor outfits and they had a development branch in Bangalore / India. Nothing useful ever came out if it. Except for some recipes for delicious Indian cuisine which were leaked to us. This was the most useful 'product' we got for our money invested in that venture.
I still wonder what is wrong with Asian brains that seems to block them from designing their own, competitive, ICs. Most of what they make is stolen IP from the Western semiconductor industry. The mainland Chinese have the worst industrial spies, they download whole engineering databases from company servers, and unless getting caught by the FBI, they then return to China to found their own semiconductor company based on the stolen IP. The IP theft / reverse engineering by ex-Eastern-Bloc semiconductor combinates (all owned 'by the people', mind you, what a scam) also is legend. But there are booby traps in many Western designs which are set to blow up in their faces (metaphorically speaking). One example are the knockout MOS transistors in the original Z80 CPU. It took the East Germans at "VEB Karl Marx Erfurt" many years to figure out why their U880 did not work properly. But eventually, they found the booby trap (as the story goes, planted by Federico Faggin himself) and took it out, and then, their U880 did work (I have a few, which I acquired to repair rare Chess computers "Made in GDR" aka East Germany --- the Eastern DIL packages are metric, so Western Z80 won't fit into the footprint on the PCB. Worse are the ROMs in these machines which don't last long, they die like flies, the bane of every Chess computer collector --- still, I'd like to get my hands on the one the "GDR" gifted to Fidel Castro, it is one of two examples of said Chess computer which was integrated in a chess table / furniture piece, all others were wooden boxes to be placed on a tabletop ... but they did have Hall effect based magnetic sensors for the pieces and for the keys, which in theory should last forever, but don't. Inferior processes strike again !).
Enough spy stories for today. My internet time is up (battery running low). Hope you enjoyed these stories.
- Uncle Bernie
One of the DEC VAX microprocessors had a curious phrase in the silicon:
СВАКС . . .
Когда вы эабатите довольно воровать настоящий лучший
https://micro.magnet.fsu.edu/creatures/pages/russians.html
Have you visited the places where MMU and IOU clones were produced? Form your story I am inclined to think you missed them.
That is hilarious! Actually it's "забатите", not "эабатите". The entire message was: "Когда вы забатите довольно воровать настоящий лучший", which according to a post on a russian forum is a very poor translation and most likely the russians who saw it didn't get it. It should have been "Kогда заботитесь о том, чтобы украсть самое лучшее", which is what they wanted to say. But even then they would not get it, since it's a Hallmark greeting card pun and they didn't have those in the Soviet Union at the time.
@frozen-signal How is the 7128 behaving in your tests?
I haven't been able to work on this as much as I thought I could. It doesn't work, but I see characters flicking very fast in text mode.
With a logic analyzer, I see that my /RAS hold delay is ~52ns (vs the official MMU which shows to be ~42ns), so that's likely not the problem.
And the ORA values generated by the MMU are correct for the addresses, so I'd think the CPLD is good.
The fact that the MMU still works fine with a MachXO3D board as well as with your CPLD makes me think that it's not the VHDL.
If I slightly shake my MMU adapter, I can see visual artefacts on the screen. So something on my adapter has possibly one or more weak solder joints somewhere, or something like that.
All this to say that I think it's my PCB adapter that is causing the problem.
I am slowly excluding possible causes, and slow progress is still better than no progress, I guess.
It works!
My MMU with the EPM7128STC100 works.
The short version of this long and frustrating investigation: Two things may have been the problem.
The MD0-7 lines were possibly crumbling too early versus the ASIC MMU when reading ROM. I added a small delay but didn't correct the problem.
I then noticed that the MD0-7 signal lines were very noisy when my prototype was inserted, but perfect when the ASIC MMU was inserted.
My prototype uses pin headers inserted into a 40-pin socket, and it's this socket that is inserted in the Apple IIe's MMU socket (in order not to damage the board's socket).
After breaking a pin on my prototype's socket, I replaced it with a new one and the prototype started working perfectly.
I'll have to check which one (maybe both) was the cause.
I haven't yet tested it thoroughly; only with the self-diags, the BASIC prompt and the monitor.
I'll test it more tomorrow.
But for today, I want to leave it on a positive note.
Hi. Your resulsts look very similar to mine. Is your MMU stable with RAMWORKS card plugged in AUX slot?
I have plugged a RAMWORKS III card with my prototype MMU and everything is working fine. The self-diagnostics reports "KERNEL OK" and so far, every game is running fine. I have been playing "Aliens" for a while now. This game used to terrorize me as a kid. Things sure have changed...
Would you share your POF file and pinout connections, I have now the same Altera as yours, able to try with it instead of 7064. Thanks.
Certainly! This file contains the .POF, the .PIN, as well as a more readeable version of the pins locations for the EPM7128STC100 version of the MMU:
MMU.zip
Sorry for the weird pin order; it was the most convenient order for my particular adapter.
Since you will be using the same CPLD as I do, once you're done with the MMU would you accept to try to assemble the IOU?
Again, thanks for your help!
I am encouraged by this progress!!!
Hm. Very sorry, my bad -- my chips are PLCC84, yours are 100-pin. Would you compile two POFs, one for EPM7128E (EPM7128ELC84-12), and one for EPM7128S (EPM7128SLC84-15), please choose one and the same pinout for both of them. Yes, I will test the IOU too, it would be great if you could achieve minimum pinout wiring difference between MMU and IOU.
Here is a MMU for the EPM7128SLC84-15:
MMU_EPM7128SLC84-15.zip
Included is the POF file and the pinout. My version of Quartus II don't seem to be able to generate for the EPM7128E. I'll try to find what version I need later. I will also generate you a IOU pof (with minimal pinout difference).
Hope it will work (I don't have the EPM7128SLC84, so I couldn't try it myself).
Also, please tell me if you do anything special; I'd like to write a how-to-build guide on my github repo and your feedback would be very appreciated.
Well, the SLC chip that was given to me appears defective during programming. Expecting anoher one but meanwhile only my ELC version remains at hand. Very fragile chips I start to really dislike Altera for several things, one of which is secretive programming specs for the "parallel programmed" chip versions.
I will try to compile it with Max+plus ii for the ELC version. Any difference from the initial sources you gave me?
I have added a delay on /ROMEN1 and /ROMEN2. This delay don't seem necessary, but I wanted the signals from my implementation to be closer to the ASIC MMU.
Here are the updated files for the MMU:
MMU_Sources.zip
In Quartus II, I have to set these project settings:
Pages