Though this is not strictly Apple II related, since the Altera Max 7000 series CPLD is popular here, I feel I have a duty to warn.
I can't find the exact quote from UncleBernie, but I remember reading him telling about "in his days" people having their expectations about CPLD/FPGA being 'reajusted' by reality. The last couple of days have been such days for me.
I have been fixing/annoyed by/cursing at an issue with the AUX RAM / Motherboard RAM, where it seemed fixing one would break the other. To be precise, an issue with the enabling of the address bus by the IOU/MMU.
Let me first write a little refresher on what happens in the MMU / IOU for those unfamiliar or have forgotten how it works:
The RA bus on the Apple IIe is the multiplexed address bus and it is shared between the MMU and the IOU; the MMU drives the bus when PHI_0 is HIGH, and the IOU drives it when PHI_0 is LOW. When the MMU or IOU is not driving the RA bus, it sets it to a high-impedance state. If we consider the MMU, it drives the bus from the rising edge of /RAS in the previous cycle to the falling edge of Q3 of the current cycle. However, a requirement of the RAM used in the Apple II serie is that the RA bus must hold it's value for some short delay past the falling edge of Q3. One way to do this (a.k.a the way I do it), when using an Altera device, is to use the LCELL primitive; it adds ~5 ns per LCELL and is useful when precise timing is not required.
The LCELL is a buffer and, besides the delay, should not modify the signal in any way. I have simplified the problem to this VHDL code:
In short: TEST_SIGNAL is computed from Q3 not-and PHI_0, and is connected to LCELL_DELAYED through a series of 10 LCELLs. One should expect LCELL_DELAYED to be the same as TEST_SIGNAL, delayed by ~50ns.
But that's not what we have:
Yellow is TEST_SIGNAL,
Cyan is LCELL_DELAYED,
Magenta is PHI_0,
Blue is Q3
I have not forgotten to turn off the setting to ignore LCELLs in Quartus; you can see the cyan signal is lagging the yellow one by ~50ns.
But the above image is a bit crowded, so let's look at just TEST_SIGNAL and LCELL_DELAYED:
You can see LCELL_DELAYED dropping but TEST_SIGNAL is not!
It's the LCELLs that are causing this drop; this is what a 2-LCELLs looks like:
The more LCELLs you add, the more severe the drop is.
Normally, LCELLs behave as expected, but in the above case, I think it's due to the fact that TEST_SIGNAL is computed from a slow-changing signal (Q3):
As you can see the drop is ~50ns after the PHI_0 / Q3 change.
I am not finding anything on the internet about this. Maybe I just don't know what to google, but in any cases, it's something useful to be aware of.
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.
Oh, that's interesting!
Just to make sure I understand correctly:
- All tests were done on the same Pravetz 8A clone, with the same EPROM chips, only with different ROM images programmed.
- A NMOS 6502 with a RAMWORKS 1 or 3 card, unenhanced ROMs, and the replacement IOU would not work. It works if the official IOU is used, or if faster DRAM is used on the RAMWORKS card.
- A 65C02 with enhanced ROMs works with slow DRAM, but stop working with unenhanced ROMs. I understand that using the official IOU works in both these situations.
I have never been able to run unenhanced ROMs with a 65C02, even with an official IOU and MMU. jeffmazur said in another thread (https://www.applefritter.com/comment/108195#comment-108195) that it should work fine. Since it seemed unrelated to my IOU/MMU replacement, I just put that on the 'things to check later' list.
I'll try to replicate what you describe. I have a RAMWORKS III card, but I'm not really familiar with it. Can I just pull DRAMs from another Apple IIe and put the chips in the second row? (The DRAM from the other Apple IIe are MK4564-20)
Since it's related to the AUX RAM, you can try change the value of NUM_LCELLS_Q3 in this file: CUSTOM/DRAM_HOLD_TIME/VENDOR/ALTERA/DRAM_HOLD_TIME.vhdl
Each increment will add ~5ns. It's currently configured for a ~48ns delay (a few ns above what the MCM6664 datasheet says for the min tCAH delay for the slowest 6664A-20). Experimentally, I found that this delay can be extended up to ~275ns. Maybe adding a bit more of a delay could resolve the problem?
Also, what software do you use to test the RAMWORKs card?
I'll post if/when I find something.
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.
I ordered slow 4164 DRAM some time ago and finally arrived here. I will be able to test the RAMWORKS issue later this evening.
The DRAM chips I got are Hitachi HM4864P instead of the 4164 I expected. They are fast, so they works with the current version of the sources and are recognized by the AE software (AW3 Expander 1.3 Expander and Utilities).
So back to square one. I have bought other 4164s but should only arrive late july. I'll have to find more on ebay, I suppose.
In any cases, I'll keep you posted when I got anything new.
Sorry to spam this thread,
There was 9 chips in the 8-pieces kit I got. One of them was a 4164. I swapped one of the 4864 in the second row and tested it.
It is recognized by the RAMWORKS III card. I am using a 6502 with unenhanced ROMS, an official MMU, but the replacement IOU.
I'll continue to try to replicate the issue.
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
Just got another batch of 4164 I ordered from ebay. This time, I can replicate the issue.
I will investigate this weekend and keep you posted when this is fixed.
retro_devices, I can't replicate the issue you have with slow DRAM on a RAMWORKS.
I have tested with several (about 20) 4164s with the replacement IOU, a 6502 with unhanced ROMs, and on two different Rev.E RAMWORKS III cards. I have also tested with 41256 DRAMS. Everything works except a batch of 8x 4164 that seems to be bad; they also don't work when inserted on a AUX Memory Expansion card with all official ASICs.
All DRAMS are marked as KM4164B-15, but uses different fonts. So it's unclear what they really are. Two of them are clearly pulls and those works correctly with the replacement IOU.
I still am waiting for a batch of 10x 4164s that should arrive mid-july, but I don't expect a different result.
Please, can you tell me what exactly are the DRAM that fail only with the replacement IOU? I will try to buy some of these on eBay.
Hi. Please, don't buy anything else. I am just relaying here the information, the guy is on this forum (rumburak) but is not very fluent in English. Keep in mind you never published your pinout for the IOU along with your compiled file. Moreover in some of the tests Ruburak used Altera 160 instead of 128. He told me he had faced more problems than just the AUX DRAM recognition. Will post you updated.
badHGR.JPEG
The picture above shows the last report I got -- the latest version of IOU became worse, all DRAMs are recognized but HGR seems bad. Also I've been told the situation seemed good if both IOU and MMU were PLD versions, if mixed with authentic IOU or MMU problems like the above example appeared .