Anonymous
User login
Please support the defense of Ukraine.
Direct or via Unclutter App
Active forum topics
Recent content
Navigation
No Ads.
No Trackers.
No Social Media.
All Content Locally Hosted.
Built on Free Software.
We have complied with zero government requests for information.
@retro_devices, if you're still working on this, I have found a problem with the signals /EN80 and /CASEN with my implementation.
It's very strange; the MMU works perfectly on an un-enhanced Apple IIe. But doesn't on an enhanced one.
See the issue here: https://github.com/frozen-signal/Apple_IIe_MMU_IOU/issues/41
The annoying thing is that the schematics for the emulator, for the ASIC, and from Sather are all different for this signal. I followed the emulator schematics in my implementation, I'll have to compare it with the two others to see just how much equivalent they really are.
Hi. I am slowly working on this. I was just fidlling with programming of these Altera chips. My jetprog programmer seems to damage 7128S at erasure (so far, not 100% proven because I am not risking the last chip that works ) but reads them properly. Luckily later version of a programmer I have writes them properly, the adapter I am using is common for both programmers. You may tell us when the MMU discovered problem is resolved then. In the meantime I may try the IOU if you provide the .POF files for the 84 pin and 100 pin 7128 IC. Thank you.
Which signal is named PCAS_N in your logs? There is no such pin on the MMU.
The PCAS_N signal is sampled directly on pin 33 of the AUX connector, shown as PCAS* on the Apple IIe's schematics.
I have found the problem. In short: The emulator schematics strikes again!
I was initially mislead into thinking that the emulator schematics for /EN80 were wrong. Between my job and my girlfriend complaining "you spend way too much time on that damn old computer!", I still managed to compare the different implementations (emulator schematics, transistor level schematics and Sather) and I re-wrote the code in my implementation to be more similar to the transistor schematics, which is much simpler than the other two.
To my surprise, it changed nothing. The issue was still there. But the simpler code made the problem obvious:
Here's a trace where the problem happens:
Screenshot 2024-04-16 172543.jpg
When accessing address $0700, and EN80VID is HIGH (also called 80STORE in Sather), the value of /EN80 should be determined (in my case) by the soft-switch PAGE2. When PAGE2 is LOW, the motherboard RAM should be selected.
PAGE2 is HIGH with my MMU, but must be LOW with the ASIC MMU.
Searching for $C055 (Address that set PAGE2 HIGH), I see this:
Screenshot 2024-04-16 172455.jpg
The address $C054 resets the PAGE2 soft-switch, as seen just before the vertical line. But PAGE2 is mysteriously set just after that, on the falling edge of PHI_0.
Well, you can't really see it on this screenshot, but as the address is crumbling, the MMU manage to see $C055 on the address bus and sets PAGE2.
The reason I said earlier that the emulator strikes again is that the C05X switches on the emulator schematics is common to the IOU and MMU and uses a latched address.
I didn't think I'd need the latch on the MMU and used the address directly.
I will fix this in the coming days and post the .pof file for the MMU and the IOU.
In post #55, 'frozen signal' wrote:
" Well, you can't really see it on this screenshot, but as the address is crumbling, the MMU manage to see $C055 on the address bus and sets PAGE2. "
Uncle Bernie comments:
Good catch ! I wrote about the fatal flaw of the 6502 bus cycle timing scheme several times here on Applefritter, and appreciate that you adopted the term "crumbling addresses". Which describes the phenomenon quite well. Using latches for soft switches in a 6502 system requires very careful timing of the latch enable signal. The latch gate must be closed before the addresses crumble. Which is not trivial, because there is no signal offered by the 6502 that changes state soon enough to use it for that purpose. This fatal flaw is fundamental - in my Replica 2e I use address latches with tristate outputs, and not only tristate drivers. These address latches allow me to keep the addresses of a cycle alive just long enough after PHI2 falls to avoid the problem you ran into.
In my own MMU substitute I use fully synchronous soft switches which are clocked with the rising edge of PHI2 (aka PhiO). In my Replica 2e this works fine - so far. If necessary, I could move the switch throwing events to the end of the PHI2 cycle.
I think that none of the Apple IIe/c soft switches are sensitive to the position of the change as long as it happens in the PHI2 cycle. The only possible exception from that rule might be the $C3XX/$CFFF switch. If thrown by a read access, the value being read could be different depending on whether the switch flicks early or late in the read cycle. So far I use rising edge of PHI2 on these soft switches, too, and all the known diagnostics disks flag no error.
These little, but important details tend to cost more time for testing / validation than for the circuit design itself. This is why progress with my various projects is so slow. Blindly copying what Apple designed circuits do is not the right way to cut down development time. In the past 40 years, semiconductor technology changed a lot, ICs got much, much faster, and hence, more sensitive to timing issues (and also to poorly laid out power and ground grids).
So it's no wonder that redesigning any Apple II related hardware takes longer than expected.
- Uncle Bernie
Maybe it is the right time to add external pins/inputs for configuring the MMU for //c and the IOU for PAL/NTSC framerate.
In post #57, 'retro_devices' wrote:
"Maybe it is the right time to add external pins/inputs for configuring the MMU for //c and the IOU for PAL/NTSC framerate."
My implementation of the IOU already supports European PAL video. It's on line 6 of the IOU top-level entity here: https://github.com/frozen-signal/Apple_IIe_MMU_IOU/blob/master/IOU/IOU.vhdl. A value of '0' will compile the IOU as a PAL IOU.
As for the //c MMU, according to the dates on the schematics we have, the idea of making an Apple //c would just have been few months old. It would be surprising if the //c part on these schematics didn't change significatively before the //c's release. Plus, Sather never wrote a "Understanding the Apple //c". For me, at least, his Apple IIe book has been an invaluable resource. And finally, up until a few months ago, I had never really used an Apple //c and know nothing about this model. I'm sure it can be done, but it really would be a challenge for me without more resource material.
In post #57, 'UncleBernie' wrote:
"and appreciate that you adopted the term "crumbling addresses" "
AddressCrumbling.jpg
You can see it takes a full 20ns.
I have fixed the problem I had with ALIENS, and "Apple IIe Diagnostic". As UncleBernie said he did, and as one can see on the transistor-level schematics, I added PHI_0 as a gate to the PG2 and HIRES soft-switches (i.e. prevent them from changing outside PHI_0)
In fact nearly all games seemed to work. Until I tried "The Black Cauldron".
(From my repo, issue #43: https://github.com/frozen-signal/Apple_IIe_MMU_IOU/issues/43)
The 'blank' screen (before the scene is drawn on) has some artifact, but the portions that have been drawn are correct.
Here's what it looks like while the scene is being drawn:
BlackCauldronIssue.jpg
On rare occasions, the game will fail to load, hanging on a loading screen. On even rarer occasion, the game will run perfectly.
This is possibly an even more interesting problem than the PG2 one.
I had a hunch this would cause problem since last summer, but didn't have a clear way to test it. So it remained on the "things to check" pile.
As people here on Applefritter may or may not know, the DRAM memory used in the Apple uses a multiplexed address scheme; a row part and a column part (RA7-0 on the MMU/IOU) is supplied independently. And on these these DRAM chips are two pins used to 'strobe' the row and column part of the complete address. They are active-low, meaning that the memory chip will 'read' (latch) the row or column on the falling edge of the corresponding signal.
The mainboard RAM uses the signals /RAS and /CAS as the address strobing signals. But the 80-Col card uses Q3 instead of /CAS to 'strobe' the column part of the address. In my implementation, the RA7-0 signals becomes High-Impedance (floating) on the falling edge of Q3, giving *no* CAS Hold Delay to the memory chips. But everything seemed to work just fine. I thought about how I could test whether or not a CAS Hold Delay was needed, maybe test by pulling-up the RA7-0 lines with a weak pull-up and see if it's still stable? Maybe then add some delay until it becomes stable? Anyways, I felt I needed to think more about it so it remained on the to-do list.
But now, with the "The Black Cauldron" problem, my instincts are telling me that it's the missing Q3 hold delay that's biting.
We'll see.
In post #58, 'frozen_signal' wrote:
" But now, with the "The Black Cauldron" problem, my instincts are telling me that it's the missing Q3 hold delay that's biting. "
Uncle Bernie comments:
You don't need 'instincts' to recognize that, all you need is a datasheet of your DRAMs.
Most call this hold time "Tcah", "column address hold" time, and it's huge: for instance, a 64k x 1 bit NEC uPD4164-3 specifies 30ns, minimum.
But watch out: the next generation DRAM, 64k x 4, where you would think it's faster and needs less, actually needs more: uPD41464-2, Tcah = 55ns.
The upside is that most DRAMs of these generations have a zero Column address setup time, Tasc.
And somewhere the DRAM must have a chance to grab the column address ...
Why did it work for you for a while despite violating the Tcah ?
Reason is: when you stop driving the multiplexed address bus, the address bits there won't disappear / "crumble" instantly. Let's call these leftovers "column address vapors". The problem with those is that they are very susceptible to any capacitive coupled kickback or crosstalk from other signals.
And here is a note about the Apple IIc:
I did not put an Apple IIc MMU on my test rig yet, because all I have are soldered in. But as I want to have a IIc emulation mode in my Replica 2e I must do that work at some time in the future. Since I know that the desoldering and handling of the MMU may damage it, even if done on a ESD safe workstation, I can do that only after I don't need the original IIc anymore to test other substitutes (i.e. an IWM substitute).
But I'm not so much concerned about the IIc MMU. What it does on the extra address decode pins should be easy to find out.
The really hard nut to crack is the IIc IOU, which (as Apple manuals claim) has a lot of mouse related functions added, with their own soft switches, which appear and disappear by another soft switch, and some of the information has contradictions. IIc uses the TAPE OUT / CASSO pin to bank select the 32kByte firmware ROMs, and so it seems Apple has limited the address range which can toggle that pin. All these deviations from the original Apple II concept are time consuming complications.
Since I'm stuck with the IWM reverse engineering (have no Rev B IWM yet) and it's the same test rig which is reconfigured by wire wrap between MMU, IOU and IWM mode, I can't proceed with any of the work.
But I'm confident that in the end (in 1 year ? 10 years ? 100 years ?) there will be faithful substitutes for all of these ICs ;-)
- Uncle Bernie
I just fixed the "Black Cauldron" issue. I was so sure it was the ORA bus enabling missing a delay past the falling edge of Q3. But adding even a small delay would cause visual glitches, and a larger delay would cause the game to hang completely.
It turned out to be again /EN80. The CPLD, being faster than the ASIC MMU, would make /EN80 change much earlier than on the ASIC. The fix was just to make sure /EN80 do not change before the falling edge of /PRAS.
It was relatively easy to spot with a signal trace... Having a logic analyzer feels like cheating.
That fixes the last known problem with my MMU implementaion. I have spent the afternoon testing with several games, and all these works perfectly:
- Fat City
- Impossible Mission
- Indiana Jones
- Karateka
- Prince of Persia
- Rescue Raiders
- Wings of Fury
- AirHeart
- Aliens
- Aquatron
- Black Magic
- California Games
- Dazzle Draw
- Dino Eggs
- Drol
- King's Quest IV
- Pirates!
- Summer Games
- The Black Cauldron
I still need to re-test everything on an un-enhanced Apple IIe, with a RamWorks III card, and test with a printer.
(I don't have a MockingBoard, but if the Disk Controller and the printer works, I assume all devices IO will work)
@retro_devices, here's a .POF of the fixed MMU:
MMU_EPM7128SLC84-15.zip
With this pintout:
A[0] PIN_4PHI_0 PIN_5Q3 PIN_6PRAS_N PIN_8ORA[0] PIN_10ORA[1] PIN_12ORA[2] PIN_15ORA[3] PIN_17ORA[4] PIN_20ORA[5] PIN_22ORA[6] PIN_24ORA[7] PIN_27R_W_N PIN_29INH_N PIN_31DMA_N PIN_33EN80_N PIN_35KBD_N PIN_37ROMEN2_N PIN_39ROMEN1_N PIN_41MD7 PIN_44R_W_N_245 PIN_46CASEN_N PIN_48CXXXOUT PIN_50A[15] PIN_52A[14] PIN_54A[13] PIN_56A[12] PIN_58A[11] PIN_60A[10] PIN_63A[9] PIN_65A[8] PIN_67A[7] PIN_69A[6] PIN_73A[5] PIN_75A[4] PIN_77A[3] PIN_79A[2] PIN_80A[1] PIN_81Wow! That's awesome!
In post #60, 'frozen signal' wrote:
" I was so sure it was the ORA bus enabling missing a delay past the falling edge of Q3. But adding even a small delay would cause visual glitches, and a larger delay would cause the game to hang completely. "
Uncle Bernie comments:
If you turn off the multiplexed address bus drivers on RA[7:0] before Q3 fall + tcah (column address hold time) you make the AUX RAM (on the 80 COL card) run on address bit vapors, which is not a robust solution. I would not dare to release anything which runs on address bit vapors.
If you see trouble when adding tcah, then something else is amiss, such as your multiplexers doing the wrong thing and selecting wrong addresses once Q3 is turned off.
I suggest you re-check your Verilog code for how the multiplexer select is controlled and where it changes. If you got that correct, then extension of the multiplexer output enable signal to cover tcah should work.
(Impatiently waiting for a plug-in MMU substitute for my Apple IIe whose MMU died in the reverse engineering process, and I don't want to design an adapter board to put my own MMU substitute in, as a one-off not worth my time, I'd rather buy one of yours, just to fix the machine. At the moment I must move my MMU/IOU substitute card from my Replica 2e to the Apple IIe if I want to test things on it, and then move it back, very nasty procedure).
- Uncle Bernie
I was told by a friend of mine who used a 100 -pin 7128S the latest version of MMU was worse. The previous one had in his setup only issues with the 80-col. text mode table symbols. He compiled IOU with different pinout to suit his breakout PCB wiring and he was very unpleased with the IOU -- it was very unstable.
Following UncleBernie's comment, I added again a delay to Q3. It didn't cause the visual glitches like in comment #60, probably the /EN80 issue was also preventing adding the delay.
I should be able to commit the change soon, but I need to test it more.
@retro_devices, maybe that delay will fix the issues with the MMU you say you friend has. As for the IOU, are you using a PAL version of the Apple IIe?
If you are using the NTSC one, it should work; there are two other people, in addition to myself, that has assembled the IOU and don't have experienced any issue.
Please, ask your friend to compare how he created his project to this procedure:
1. Create a directory RETRO_DEVICES
2. Download the sources from my repo here: https://github.com/frozen-signal/Apple_IIe_MMU_IOU/archive/refs/heads/master.zip
3. Decompress into RETRO_DEVICES, optionnaly removing the '-master' from the name
4. In Quartus II, create a new project in RETRO_DEVICES named IOU with top-level entity IOU.
- Add all files in Apple_IIe_MMU_IOU/COMMON
- Add Apple_IIe_MMU_IOU/CUSTOM/POWER_ON_DETECTION.vhdl
- Add Apple_IIe_MMU_IOU/CUSTOM/RAS_HOLD_TIME/VENDOR/ALTERA/RAS_HOLD_TIME.vhdl
- Add all files in Apple_IIe_MMU_IOU/IOU
- Add all files in Apple_IIe_MMU_IOU/TTL
- Select EPM7128STC100-10N as the device (Or the correct device)
- Select Synplify Pro as the synthesis tool and leave everything else as is and click Finish
5. In Edit Settings -> Analysis & Synthesis Settings, do this:
- Change optimization to Area (Optional)
- Make sure 'Power-Up Don't Care' is not checked
- In More Settings, make sure Ignore LCELL Buffers is OFF (IMPORTANT!)
6. In Edit Settings -> Fitter Settings -> More Settings, make sure Slow Slew Rate is ON
7. In the Pin Planner, assign all the pins, and set Slow Slew Rate ON on all output and bidirectional pins.
8. Synthetize everything and program the CPLD
*** The IOU need a 10K pull-up on /RESET
For the MMU, it's the same, except for the files:
- Add all files in Apple_IIe_MMU_IOU/COMMON
- Add Apple_IIe_MMU_IOU/CUSTOM/RAS_HOLD_TIME/VENDOR/ALTERA/RAS_HOLD_TIME.vhdl
- Add Apple_IIe_MMU_IOU/CUSTOM/ROMEN_HOLD_TIME/VENDOR/ALTERA/ROMEN_HOLD_TIME.vhdl
- Add all files in Apple_IIe_MMU_IOU/MMU
- Add all files in Apple_IIe_MMU_IOU/TTL
Also, tell me what hardware your friend uses. Is he using a enhanced or un-enhanced Apple IIe?
If I have the same setup as he does, I'll have better luck replicating the issue he's having.
A quick update: I can reproduce the problem with an un-enhanced Apple IIe. The changes I made for the /EN80 fix has the wrong timings. I made the mistake to hook my LA directly to the /CAS pin on the AUX Card to measure the Q3 hold timing. That pin is connected to Q3, but passes through a resistor which introduce an additional delay.
I will fix and keep you posted.
Hi. The IOU was built with pull-up resistor. The pinout was chowsen to suit his PCB. If you are interested I must be able to show you his short videos of the problems that appear with the IOU (and MMU) replacements?
I have (re-)fixed the /EN80 and Q3 delay issues and merged the fix moments ago.
I have tested with an enhanced and un-enhanced setup, with a bunch of double hires games and all works with my setup.
@retro_devices, you may pull the changes and re-test. Please note that I have renamed the two "hold time" components in the CUSTOM directory.
If you still have issues, please post the setup you use, as well as anything you think might help me fix the issue.
If you post your pinout, I can create you a Quartus II project for the IOU and MMU if you want.
This is the setups I used, so you can compare it to yours. Both replacement IOU and MMU were present for the tests. They both use an Altera EPM7128STC100-10.
In both cases, an AUX Card 820-0067-D (The short AUX card) was in the AUX connector.
Un-enhanced setup:
MPU: Synertek 6502
CD-ROM: 342-0135-A
EF-ROM: 342-0134-A
Enhanced:
MPU: NCR 65C02A
ReActiveMicro ROMs
Fantastic news!
@softwarejanitor your systematic exclamations are actually spamming and uttelry useless in this topic, e.g technically you are making noise only. You'd better take a soldering pen and build a testing setup, then you would have been helpful.
I absolutely disagree with you. Knowing that people care about what you are building provides the very often needed extra motivation. It also bumps up the topic to the top of the Active Topics list, which helps Google's algorithm to pick it up and expose it to more potential users. It’s an equivalent to a "like".
Awesome project, can you recommend a suitable chip carrier. I've used the EPM7128 in other projects.Thanks.
I hope someone else can help on this. I have only used the 100-pin SMD version.
In post #72, 'frozen signal' wrote:
" I hope someone else can help on this. I have only used the 100-pin SMD version. "
Uncle Bernie comments / offers help:
EPM7128 came in various packages. The datasheet I found on it lists the 100 pin PQFP and TQFP and the 84 pin PLCC. Only the 100 pin PQFP is skinny. All others are wider. The EPM7192 is also shown as a 160 pin PGA, but this is a different animal (and too expensive to buy anyways, greedy IC brokers ring up over $400 a piece). I'd need to know which EPM7128 is wanted.
I happen to work on the layout of SMD adapters since a few days, the largest of which would be for the mighty ispLSI3256A in a 160 pin PQFP.
Here are some ideas / hints / thoughts on SMD adapter design which may be useful for the MMU/IOU substitutes.
DIFFICULTY WITH SINGLE PCB ADAPTERS:
I dont think that even the skinny 100 pin PQFP could be squeezed between the pin rows of a DIL-40 along with the required trace routing.
This is a problem because it means no useful adapter can be built using only one PCB. We need a stack of at least two PCBs to do that. Note that in theory, a four layer PCB could also do it, if blind vias of larger diameter are possible. These would hold the pins of the adapter which go into the IC socket of the DIL ICs to be replaced. Note that the topmost layer of such a four layer PCB must not have any such holes to allow the SMD footprint being undisturbed. Alas, budget PCB manufacturers like JLCPCB can't make blind vias. And if we would try to solder the pins to flat pads with no holes, this connection would be too weak for many plug / unplug cycles.
UNCLE BERNIE'S CURRENT SIDE PROJECT: SMD ADAPTERS !
Because my work on the IWM and the Replica 2e is bogged down at the moment (no IWM Rev B in my hands yet, so I can't proceed with any of the work), out of boredom I started to look into designing SMD adapters just a few days ago. These are meant for the planned future Replica 2e kits: I want to avoid that less experienced builders ruin the expensive motherboard PCB when attempting to solder in larger SMD packages. It seems to be a better idea to have a bunch of small break-away adapter PCBs on which the SMDs are soldered in first. If this work is botched, the whole small PCB can be heated up to salvage the SMD. Or, if the SMD is cheap, thrown away with the PCB and rinse and repeat until a SMD is soldered in correctly with no shorts or opens.(There may be a learning curve of maybe 2-3 botched examples for SMD newcomers, depending on equipment and fine motor skills). This shall be the first component which goes into the adapter PCB. All other components come later (typically, pin header rows and power supply bypass capacitors).
PROPOSED SMD ADAPTER
The proposed SMD adapter will consist of two dual layer PCBs. The lower PCB will be an universal one which will hold the special pins that go into the DIL IC socket. It is for DIL-40 but can be sawed down to DIL-28 and DIL-24. The width will be wider than the DIL socket (whose pin rows are 0.6" apart). Here is the layout for this bottom PCB:
DIL-40_Adapter.JPG
(Don't get confused by the SMD footprint - this is just a 'triple' use of the basic PCB meant for different SO-28 SMDs).
Each SMD based design will have its own, customized PCB which is the top PCB. It will be connected to the lower PCB by pin header rows which are at a wider distance than 0.6" (the outer rim holes), such that the largest SMD can be fitted between these pin header rows. Here is a photo of the pin header strips:
PDRM4621A.jpg
The pin header rows can be used to solder the two PCBs permanently together, but the lower PCB could also get female pin contact rows, while the top PCB has the male pin rows. This allows to unplug the two PCBs and the top one now has pin rows which can go into the ZIF socket of a programmer. Very convenient for development work.
My own appliction for the latter option is to convert a EP910 in PLCC-44 to a DIL-40. I have much more EP910 in PLCC than in DIL.
LAYOUT FOR THE LOWER PCB
The pin header rows are easy to solder (2.54 mm raster) and would plug into to outer pin row of the bottom PCB whose layout looks like this:
DIL-40_Top_QFP44.JPG
This example is unfinished. I will derive various versions from that base layout. The trouble is, that every CPLD manufacturer used different pinouts, so the all important VCC and GND pins are in different locations. And you can't simply route these to the outer pads, as the length of the trace would mean an inductor of several nH (nano-Henry) - a good rule of thumb is 1 nH/mm) and at the internal switching speeds of 1990's CPLDs are fast enough to make these inductors look like open circuits - at least for a short while, enough to starve internal logic of its supply voltage and make it do stupid things. Such as toppling flipflop states.
In other words, such a CPLD with no local power supply bypass capacitors simply won't work robustly, or not work at all (More on this later).
PIN CARRIERS
In the first screen shot above you can see plated through holes with larger diameter in the pin positions for a DIL-40 package (the inner hole rows). Individual pins from a special pin carrier get soldered into these holes. So on the bottom side, there will be pins which have the right, small diameter to be plugged into a DIL-40 socket without overstressing its contacts. These pin carriers look like this:
PDRM4621.JPG
The important feature is that their pins are of a small enough diameter (0.45 mm and 0.54mm) which does not damage the contact springs of any DIL-40 socket. The golden ones with 0.54mm diameter are borderline, but still useful. These pins have the same diameter as with typical industry standard "machined contact" type DIL sockets. Any larger diameter is a no-no for adapter pins meant to be plugged into DIL sockets. (Never use the standard 0.6mm square pin rows in any IC socket ... they won't fit into a machined contact type socket anyways, but they sure can be forced into most other types of socket, and that's the ruination of that socket. These contacts are never reliable because the contact springs have not been designed for 0.6mm thick "pins").
Since these pins - only the 0.45 mm ones were specifically designed for adapters - also contain contacts for standard IC pins, the adapter PCBs so equipped can also serve as an interposer for a real DIL-40 (or, if sawed off, DIL-28 or DIL-24). Nice to have when working with hard to obtain custom ICs like the MMU, IOU, IWM. These would be plugged into the adapter, and the adapter gets plugged into anything where it must go, and if a pin of the adapter breaks off, it can easily be replaced. Some people use machined contact DIL sockets for this purpose, but it depends on the diameter of its pins if this will damage the DIL socket into which this contraption is plugged in. In my experience, some machined sockets have pins which are too large in diameter (> 0.54 mm), and although these may fit nicely into another machined contact DIL socket, and make a reasonably reliable contact, the socket's contacts will be loosened a little bit, and will never snugly grip regular IC pins anymore. IC sockets with the "snail" type stamped contacts can take it better, but they have other issues (pulling the IC out occasionally also pulls the whole "snail" out, and this means the socket is ruined).
The PCB seen in the first screen shot above is unified for DIL-40 sockets. All individual routing for different circuits, such as for MMU or IOU based on MAX7000 devices, would be done on the top PCB, which solders into this bottom PCB via the mentioned pin row headers.
UNIVERSAL SOLUTION ?
This seems to be a universal solution to make substitute plug-ins which would fit into DIL-40 sockets (MMU, IOU) or DIL-28 sockets (IWM).
Note that I am not intending to make any MMU, IOU, or IWM substitutes which plug right into the DIL sockets of existing Apple IIe and IIc. Unlike the work of 'frozen signal' who intends to do this, my own MMU, IOU (and, later, IWM) substitutes are scattered over multiple smaller PLDs and CPLDs, because I happen to have lots and lots of them. But I do have the above mentioned, perceived problem with SMD based motherboards for my Replica 2e project (or any other kit of similar magnitude): some builders will inevitably botch some SMD soldering and hence, ruin a large (and expensive) motherboard. By using smaller, breakaway PCB based SMD adapters of the proposed architecture this risk of damage to the expensive motherboard can be greatly reduced:
ADAPTERS HELP TO AVOID PERILS OF SMDs IN LARGER MOTHERBOARDS
I think that asking kit builders to tackle many SMD components with lots of pins on a single motherboard is asking too much. I know there are ways to do it without an expensive reflow oven, but this still involves a solder paste stencil (expensive) and a makeshift airtight reflow / vapor phase soldering vessel based on toxic chloroflorocarbons (CFC) solvents (it's essentially a CFC vapor soldering process, and the CFC boiling point sets the temperature). You can find these tricks on youtube but I won't give you the links because IMHO this approach is freaking dangerous, despite most CFC vapors are no explosion hazard. They are still toxic and any leak can turn your house (or garage) into a "Superfund" site. (Don't do that !)
Those builders who are wise enough to avoid such bulk soldering processes would need to solder each and every SMD IC by hand and IMHO this is asking too much. I do have a certain success rate with hand soldering 0.8mm pin pitch SMD packages pin-by-pin, but even for me it's not at 100%. Here is an example which worked fine:
PDRM4624.JPG
Note that I added two power supply bypass capacitors right at the pins of the ispLSI1016. Without them, the ispLSI1016 CPLD won't work. Still, the thin long traces for VCC and GND on this PCB are terrible. This will be discussed next:
SHORTCOMINGS OF "EBAY" SMD ADAPTER PCB SETS
A) Not all get used (= waste)
The above example was built based on a SMD adapter PCB bought off Ebay (for cheap, what I actually needed when I ordered them was a SO-16 footprint). One problem with these kits offering assorted SMD footprints is that only a few of them fit for a particular project, so most of the small breakaway PCBs will stay unused, and hence, are wasted. In this case, I used one SO-16 footprint and the one seen in the above photo. All the other small PCBs in the set probably will end up in the trash can.
B) Poor or non-existent power supply bypass capacitors
The next problem is the lack of power supply bypass capacitors on these PCB. Modern CMOS based CPLDs and FPGAs (beginning with the mid 1990s) are so freaking fast that they just won't work reliably without plenty of high performance power supply bypass capacitors and good ground planes and power rails. Any shortcomings with those will turn your SMD adapter board into a nightmare, because the failures / crashes (typically occuring only occasionally, which makes them hard to hunt down) will be pattern sensitive: depending on how many outputs switch at any given time, the poorly bypassed power supply will collapse locally (or the ground will bounce locally) and this may flip a flipflop within the ICs into a wrong state. There are some CPLDs from the 1990s out there (i.e. AMD MACH devices, but these are not the sole culprits) which switched so fast that it was practically impossible to make them work on dual layer PCBs. It was possible to make them work with four layer PCBs with a power and ground plane and lots of small, SMD, power supply bypass capacitors, though.
This problem manifested itself in many ICs of the time, at around the transistion to the 0.6um CMOS process node, and lead to the demise of corner pinning for power and ground on DIL packages (and most likely, the demise of larger DIL packages in general). Still, many PLD and CPLD datasheets or application notes of the time carried the warning: "Do not switch more than X outputs per bank at the same time".
Now, how to tell that to the logic synthesis software was not disclosed (those bastards, letting the customer figure out how to make their botched CPLD work in the application). The upside of all that speed of course was that you could clock these CPLDs with 50 MHz or more. But what good does this do if the ground and power bounce caused by a clock edge will topple one or more flipflops in the device in a quasi random manner.
This said, designing any adapter board for fast CPLDs is not a trivial exercise and the power and ground routing and the unavoidable power supply bypass capacitors must be carefully planned. I think for the small 28 pin SMD PLDs I designed the first layout for, one 100nF 0805 SMD power supply bypass capacitor is enough. Alas, one of the ICs, the SRAM, has corner pinning of VCC and GND and is also very fast. I don't know yet if this would cause trouble. If so, the first thing I'd do is to reduce its supply voltage from 5V to 3V - still adequate for driving TTL, but it would slow it down a lot, so much less ground and power rail bounce would happen. But this foul trick does not work with all IC. Such as CPLDs. Some have read amplifiers for the EEPROM array which won't work at such greatly reduced power supply voltages.( The datasheet will tell the story, some allow a wider range of VCC, others don't, and some CPLD families offer 5V andf 3.3V versions.) But this type of SRAM is specified to run at 5V and much lower supply voltages. I have thousands of them and want to put them to use ...
CONCLUSION
A set of SMD adapter PCBs is in the design phase. I could add one top PCB layout to the set which supports the EPM7128, but I'd need the exact type of package and the schematic how to wire it to the DIL-40 footprint for a MMU. (I also happen to have a few EPM7128 in PLCC-84 in my basement, and hope that this way I could get to a DIL-40 plug-in substitute for the dead MMU in my Apple IIe sooner. So far I'd need to move the slot card with my own multi-PLD MMU and IOU substitutes from my Replica 2e prototype to the Apple IIe, and this is very nasty and disruptive).
Anyone interested in this offer of mine ? I intend to commit the SMD adapter set to production in May, and expect to have them early June. Just tell me if I should add the EPM7128 / MMU option. You could get a set of these adapters from me at cost (ordering more will decrease the unit cost, which is also welcome for my own purposes).
- Uncle Bernie
Vapor-phase reflow is certainly no requirement for assembling using solder paste. It's much more common to use small toaster ovens retrofitted with PID temperature controllers as convection reflow ovens. The advantages of VPR are mostly in the resulting joint quality (since oxygen is excluded by the condensing fluid) and better ability to solder BGAs and CSPs without causing voids.
I don't think any CFCs were used for vapor-phase soldering: their boiling points are all too low. When VPR was first developed during the 1970s, it used 3M Fluorinert FC-70 (BP 215 °C), which is in the right range for soldering Sn60Pb40 (liquidus 183 °C). Today the fluid of choice is Solvay Galden HT230/LS230. Its boiling point of 230 °C will work with both tin-lead and lead-free solders such as SAC305 (liquidus 221 °C).
The perfluorocarbons, like Fluorinert, and perfluoroethers, like Galden, are basically inert and non-toxic, although under very high temperatures they decompose into toxic compounds. The reason that VPR systems have air seals and recovery pumps is economic, to save wasting the expensive fluid. Unfortunately the greenies are campaigning to ban "PFAS" chemicals which will impact VPR severely.
In post #74, "Robespierre" wrote:
" Vapor -phase reflow is certainly no requirement for assembling using solder paste. It's much more common to use small toaster ovens retrofitted with PID temperature controllers as convection reflow ovens."
Uncle Bernie comments:
Oh, I use such a modified small toaster oven from Walmart to grow sourdough starters ;-)
But this option won't help rookie builders with little or no SMD experience to build larger motherboards infested with SMD ICs:
First, this attempt would cause mission creep: buy a toaster oven and build the the PID electronics, and put them in.
Second, expensive stencil to print the solder paste still required. Will be used only once. Waste of money.
Third, my Replica 2e motherboard won't fit into the small toaster oven, and the larger ones are much more expensive.
So the toaster oven method is no viable substitute for my "little SMD adapter card" set. My mission is to make building Apple-1 and Apple II clones, replicas or substitutes as reliable and as cheap as possible. Builder success must be virtually guaranteed. The failure rate for my Apple-1 kits was below 1% and this was a guy from Sweden who fried the PCB in a terrible way and then gave up and sold the IC kit to another builder. Where it worked.
Never found out if he used a soldering gun from the garden tool shed which had been used to solder rain gutters. Or a similar inappropriate tool like a propane soldering torch. Or if he was a complete beginner with electronics projects.
The bottom line here is that any kit must be designed such that it's almost foolproof. So if SMDs are involved, it must be small, replaceable adapter PCBs of little value, so they are cheap to replace. Or could be sold readily assembled, programmed, and tested.
I think that SMDs are the main culprit that the electronics hobby which was very strong in the 1960s to 1980s is almost dead now. Buying ready made, fully assembled Raspberry Pi, or Arduinos and the "shields" is not the same thing as putting everything together from the components. It's not true DIY. And less satisfying. So as electronics hobbyists we need a way to tackle SMDs. Ironically, the industry has the same problem, as far as evaluation and prototyping is concerned. This is why semiconductor companies offer "evaluation boards" for all of their ICs. Because even the professionals can't handle this eyesand components anymore by hand.
- Uncle Bernie
P.S: my offer to make a EPM7128 adapter for the MMU has not been spoken for. If there are no takers then I have to wait for 'frozen signal' to go into production with his MMU substitutes. But I won't wait forever. I'd only need a few minutes with my tower PC to finish my MMU version for the Lattice ispLSI1016. Alas, I'd need to recap the motherboard of that tower PC first, which will take much, much longer.
I second what @retro_devices says. I stopped logging in and participating primarily due to @softwarejanitor's content-free cheerleading (and a now-vanished user who stole a TL866 from me).
If you can, do ... if you can't, but want to learn, ask questions, if you can't do either of those, please don't harass those who can.
It's been a few days and I am more of a de-escalation guy, but the way this thread has been going has been rubbing me the wrong way the whole time.
I thought I could just let go, but no.
I am *completely* on CVT's side and absolutely appreciate @softwarejanitor's comments.
I have been developping an open source version of the MMU and the IOU for about a year now, and let me tell you: there is no better motivation killer as indifference.
A simple comment such as "This is fantastic news!" from someone can carry you for months. Honestly, if it were not for comments such as @softwarejanitor's, I would have stopped posting on Applefritter's and moved on to another platform.
@retro_devices, I truly appreciate your help. Really. I have some Apple IIe hardware, but can't dream of testing my implementation on every piece of hardware. Your help is truly, greatly appreciated. But, please learn to live and let live. What you consider useless is very valuable to me.
As for you, @cryu, look at @softwarejanitor's history. He helped so many people. Your harsh comments are incredibly unfair.
Great progress, frozen signal. This is fantastic news!
Posts of encouragement are absolutely welcome.
What an irony -- the contents that allegedly were meant to last centuries actually survived just a few days due to the usual censorship of the forum owner. No wonder knowledgable people refrain from giving their know-how here. Great censorship owad! Great censorship owad! Great censorship! This is fantastic news!
What was censored?
I've confirmed that nothing in this thread has been edited, deleted, or otherwise censored.
retro_devices: I complimented frozen signal's work and affirmed that software_janitor's posts are welcome. Nobody has so much as said an unkind word to you. You remain welcome here.
Pages