Altera MAX 7000S series strange LCELL behaviour

Similar glitches I reported some time ago when inspecting my setup. I concluded the project has many more difficulties to overcome due to the different and obscured (by altera in this case) building bricks it uses. The circuit diagram on which MMU and IOU are based appears to be the smaller part of the task of emulating these devices with relatively contemporary technologies.

Uncle Bernie's take on this is:

DON'T  USE  THEM  FOR  MAKING EXTERNAL  TIMING SIGNALS !

The reason behind this advice is based on the fact that when using CMOS, unlike bipolar (TTL, LSTTL...), there is no such thing as a defined delay. The delay of simple CMOS gates is all over the place, depending on process corner, power supply voltage, and die temperature. There are some trick circuits which can partially compensate for these effects over process, supply voltage, and temperature, but the simpler ones are lacking, and the more elaborate ones use sophisticated analog circuits which draw current all the time, which is unwanted in most CMOS applications: customers expect that with no clock applied, the CMOS IC only draws a little bit of leakage current. So in the end, a lot of CMOS ICs featuring internal oscillators (or delays) have large tolerance bands on the frequency (or delay) or use factory trim to a target (i.e. many Microchip PIC MPUs with internal oscillator store a factory trim value in their EEPROM and the software must use it to get the oscillator right, and all programmers must have extra code to preserve the trim value so it does not get lost).

I don't know what Altera did to guarantee delay parameters for that LCELL, but I'd not be surprised if they did nothing.

So the use of any such delay cells must be limited to certain scenarios where it is used to pad up some internal signal path with extra delay to compensate for delay on another signal path. Done right, this can help to avoid hazards and critical races. It will work (usually) because all the gate delays in the same CPLD / FPGA track over process, supply voltage, and temperature.

But for meeting any timing criteria dictated by the external world these internal delay cells should better be avoided. You should use an external clock, or a sequence of signals coming from an external clock, to derive required timing for the external system. If you don't have any suitable signals, then you need to get creative or just add an external RC which you can adjust in production. Note that despite it's just a simple resistor and capacitor, the timing delay you will get depends on even more parameters unknown to you, such as the exact trip point of the input circuit, and you may need to add hysteresis to avoid ringing. If you do such a RC delay in an industrial, mass produced design, it either must be uncritical (so no trim is ever needed) or sooner or later you will be fired for making lousy designs. But we need to be pragmatic for hobbyist projects like your MMU and IOU replacements. These will never be mass produced and it is perfectly OK to leave out a SMD resistor, measure which value would be needed to get the right timing, and then put in the right resistor by hand soldering. I had the same situation with the 74123 oneshot in my Apple-1 IC kits, each 74123 had to get hand selected R's and C's to arrive at the correct time delays. This cost me about 3-5 minutes per set of 74123 and its R's and C's. Note that it is impossible to guarantee proper timing of the 74123 as needed by the Apple-1 just by putting in unselected components, even if you would specify 2% R's and C's, because the 74123 itself has  larger tolerances than allowed by the Apple-1 design. And with carbon composition resistors it's totally hopeless to hit the right timing anyways, unless pre-ageing, pre-soldering, and hand selection is used. So the Apple-1 is not a design which could have been produced in larger numbers. But for the 100-150 units the fledgling "Apple Computer Company" operating out of Woz' garage ever made, it was probably OK to hand tweak each one. And with your MMU and IOU substitutes, in all likelyhood, you also won't ever do larger production runs.

So using hand tweaked RC delays probably is OK for your application. A much cleaner solution would be to add one wire carrying the 14M clock signal to both the MMU and the IOU substitute drop-in carrier PCBs but then it would involve soldering one wire to an IC pin to put them into an Apple IIe or IIc. But believe me, ALL the insidious timing problems with the MMU and IOU would just go away if you had that 14M clock available. This, BTW, is the route I took with my own MMU and IOU substitute designs. Only the very first incarnation did not use 14M, it used some RC delays instead. I can do this without an extra wire because my solutions are not meant to drop into DIL-40 sockets on original Apple II motherboards.

Hope this helps to get your project back on track.

- Uncle Bernie

Slow rise time + no input  shmitt triger + fast input response ( Altera delay is about 2-3 ns ) = issue like this .

I see many of  this situation when i develoip my hardware .

I use too lcell  ( or similar ) delay technics ( of course this is unacceptable )  and not have issue if input signal is with fast rise time .

A friend of mine tested IOU and MMU in Pravetz 8A clone with Altera chips like yours and reported MMU working OK. The IOU almost worked but one row (not first) of  DRAM chips was not recognized in RAMWORKS1 and 3 cards unless it was replaced with faster 100nS DRAMs. With the original IOU everything worked without being picky on DRAM access time specs.

More information I got from the same person -- the above message was related to NMOS 6502. Once he raplaced it with 65C02  he had perfect results with enhanced rom, but not with nonenhanced ROM. Note: the ROM chips were identical in all tests tests with reprogrammed contents (they were fast more contemporary flash chips or 120nS EPROMs, no difference with both types). He promised to perform more tests soon.

Hi. The unenhanced ROM works fine with an NMOS 6502. The software for testing RAMWORKS cards was the official one from AE that pictures in HGR the card layout and its chips. When using slower DRAMs only one bank of the RAMWORKS card is not recognized, not the first one. Yes, you can put eight 4164 in the second row of your RW3. All reported tests were done with Pravetz 8A and one the same ROM chips.

Among my parts I found a Bulgarian MMU batch 1987 that has an interesting most likely a factory defect -- it does not detect the fetching of reset vector and therefore does not reset itself upon rebooting. Even the power off state must be somewhere between a minute and 5 min (!) for it to reset its softswitches. Shorting of its pins to GND when out of the socket or at power off does not help to discharge its memory effect. 

In post #9, 'retro-devices' wrote:

" Even the power off state must be somewhere between a minute and 5 min (!) for it to reset its softswitches. "

Uncle Bernie comments:

This is circumstantial evidence that the Bulgarian wafer fab must have been nice and spanking clean ... low leakage MOS transistors holding charge on dynamic nodes for 5 minutes can only be had in clean fabs.

I wrote a lot here on Applefritter about nasty "clean" DRAMs which hold some of their contents for several minutes without power. This foils all cold start / warm start discerning systems which rely on certain bytes of the RAM to change when power is off.

Very nasty to remedy. If we want to build replicas of these vintage computers with more modern ICs, then we need to add logic to manipulate the reads from that RAM location. For the MMU, it's hopeless (unless it detects the RESET sequence properly).

- Uncle Bernie