Hello Everyone.
I'm new here and I'd like some help to understand what's going on.
In July of this year I assembled a replica of the Apple II Rev. 0. and over time I've been assembling the Expansion Cards (Disk II Controller and HDMI Video Card). Everything is working perfectly without crashes.
However, in the last month I assembled the Memory Expansion Card (Language Card), since then I've been having some strange problems.
Project: https://github.com/btb/LanguageCard
The card was installed in Slot 0, Apple Cillin and MECC-Computer Inspector recognize the Language Card and the memory test is performed successfully, without errors.
However, Apple II Confidence Program and Locksmith 6.1 found problems with the Language Card, several errors in all memory positions.
Some 64KB games load with the image corrupted and others crash. Several 64KB programs crash on startup.
I checked the Language Card Board with the multimeter for possible failure in the traces (shorts or lack of continuity in the traces), everything is correct.
All the chips on the expansion board were tested and replaced with other brands but the same problem continues.
Today I tried something new, I installed the language card in the last slot (Slot 7) and to my surprise the board worked perfectly without errors in LockSmith.
One thing I noticed is that if I install the card in other slots, the error appears with less intensity. The closer to Slot 0, the greater the number of errors.
I suspect that one of the causes of this problem is the 27C256 Rom Adapter board, perhaps it is causing some conflict on the data line?
I would appreciate any help to understand what is causing this strange problem.
Thanks
I suspect that there is an issue with the LC using INH to disable the the motherboard ROM. Since neither of these is standard Apple in your machine it could be either one. Or perhaps even an issue with the motherboard itself.
The LC works by substituting its ROM for the F8 motherboard ROM (when RAM disabled) and its RAM for the entire ROM space when enabled. It does this by pulling the INH signal low on the expansion bus. This in turn disables the motherboard ROM. If this is not happening, then both devices are competing with each other and you have a bus conflict which corrupts the data. It could also explain why the LC works better in higher slots as that is closer to the bus transceiver and would give it a stronger signal to overpower the motherboard ROM.
If I had to guess, I would start with the LC board. I see a jumper on the lower right side of the board. Not sure what that does but you could try removing it. Otherwise, you can check for the INH signal coming out of the board to your ROM replacement board. Here is where that comes from in the standard Apple Language Card:
Untitled.png
Those are good suggestions; I would also check the resistor pack RA01, because if it is too low value, the /INH line will be pulled up too strongly. The schematics show 1 kΩ, which might be a little too low? RA01 is immediately adjacent to slot 7.
The test results are not fake but Locksmith 6.1 is a fake.
Thank you very much @jeffmazur and @robespierre for the tips. You mentioned a factor that was decisive for the progress of solving the problem
Since the motherboard and Language Card have all ICs working perfectly, I took the time to analyze and perform some tests on the INH signal. It was certainly a timing problem.
1) I changed the INH line resistor. Three tests were carried out with the values: 500 ohm, 1 kOhm and 3k3 Ohm. It is possible to see that there is a time change in each resistor value. However, the problem persisted.
IMG_7411.jpg
IMG_7408.jpg
IMG_7410.jpg
2) Since the system ROM is not original and has a ROM replacement board, I suspected the Eprom's time, in addition to the fact that the ROM replacement board documentation does not specify the characteristics of the Eprom.
The original Eprom of the ROM replacement board was M27C256B-15F1 (150 ns). Luckily I have an old NEC 27256 eprom (120 ns). After replacing it with the faster Eprom, the problem was solved!All this time it was a slow eprom causing problem.
IMG_7437.jpg
IMG_7438.jpg
I also added some SMD decoupling capacitors to improve filtering.
IMG_7423.jpg
IMG_7424.jpg
Also, I found an interesting article from Cypress:
Cypress Sram Board Design
Thanks,
Daniel
Thanks for posting a followup.
All too often the original poster solves his problem and never reports back, so it is much appreciated that you did.
Cheers and good sleuthing.
The Apple ][+ (clones witth EPROMs) work nicely with slow 250nS EPROMs, it is very doubtful that the 30nS EPROM access time difference was the reason for the problem. It may be solved for now but I won't be surprised if it manifests again, most likely in different configuration (e.g. that very language card in another apple, or that motherboard with different cards).
Hello retro_devices.
During this period I did some tests and I got some interesting results that I would like to share.
Since the EPROM M27C256B-15F1 (150 ns) is having a problem and the old Eprom NEC 27256 (120 ns) is working normally, I started analyzing the datasheet between the "Standard" EPROM and the C series EPROM (CMOS).
The first difference I found between these two versions is that PIN E (Device Enable). The standard version is necessary to apply a TTL level signal. While the CMOS series requires CMOS High Signal.
Captura de tela 2024-11-07 195343.png
I placed a 2k2 resistor connecting between 5 volts and the PIN E (Device Enable) line. There was a small improvement but the error persisted.
Captura de tela 2024-11-07 204638.png
Analyzing the datasheet it came to my mind that perhaps the time to activate the Eprom (Pin E) could be delayed.I did an experiment:Since the Rom Adapter Board the PIN E (Device Enable) and PIN G (Output Enable) are connected together. I cut the connection to the PIN E and I connected it to GND. This way, the EPROM will always be on. The PIN G was kept in its original connection.
I've been running programs and memory test for almost two weeks and so far no errors.
Apparently switching from standby mode to on mode was having some delay.
I found a mention on this subject:
IMG_7474.jpg
Thank you,
Daniel