I've spent the day diagnosing my homebrew Apple 1 replica, based around Vince Briel's Replica 1 Plus. The Woz Monitor is loading and I can get into BASIC using E000R on the larger ROM, so that's a great sign. I'm using a real CRT screen but input is via serial to PuTTY on my Windows 10 machine.
The only real trouble I'm having with it still is with repeating characters. Whenever I type a 'space' it produces a single space character. But whatever character I type next, it first produces another space character, before sending the requested character. So I'm basically getting double spaces between every word and command. It's not just the space character, either.
I get doubles every time with the space character, about 80% of the time with the 0 (zero) character, and about 10% of the time with other characters. It even happens with Return, for example, if I type F000, and then Return, I will sometimes get an extra 0 before the Return character it sent, which sends F0000 and produces an error. I'm suspecting the Propeller has an issue, I've checked my work carefully several times and it seems like an oddly specific error.
I haven't actually wired up a PS/2 keyboard yet, I need to do that next to see if I get the same repeats, just to narrow things down further.
Have any Apple 1 replica owners/builders had an issue like this?
How are you sending serial data in? Could you have a mismatch in number of bits or something? Is the propellor bit banging the serial?
The manual has:
9600 baud
8 data bits
1 stop bit
No flow control
No parity
Obviously set to all these, still the same problem. I can actually change these settings and still get a working terminal with some lee-way, but still doesn't fix the extra space character.
Today I'm getting very few other characters repeating, but still always an extra space!
Not knowledgeable enough to know whether its 'bit banging' or not, the Replica 1 Plus that I've built this around uses a FT232R breakout for serial connectivity. The Propeller P8X32A controls the keyboard, serial I/O and video. The computer otherwise seems to be 'computing' just fine. Might need to get another Propeller and note any differences, if any.
Quick update on this, I'm getting the same problem with a different Propeller chip, I've also tried multiple combinations of 6502 and 6821 PIA chips, so I'm assuming it's my wiring somewhere. This just doesn't make sense to me though, it's still such a specific misfire. I may try replace the RESET and CLEAR buttons, these seem to be a bit flaky, I don't know how they would affect sending text over serial, but want to eliminate everything possible.
It could also be the FT232R breakout, I have a replacement but will need to solder it in.
Even with the PS/2 keyboard hooked up, I am getting the odd space. But for some reason now, they are much less frequent.
This is starting to sound like a shorted wire or pin somewhere.
It is possible that it is a gound plane or other signal integrity issue. If you have looked for ground bounce during keyboard reads?
regards,
Mike Willegal
Thanks for the advice all. I tend to agree with all the above - while I have checked my soldering and pins several times now, I still may have missed something, and resoldering a few connections won't hurt. Not having a ground plane is interesting, and I can assume when dealing with sensitive electronics such as this, ground plane and induction could definitely come into play.
When pushing a text file over terminal to the Apple 1, the errors get much worse, lots of missing 0s and just strange misfirings. Could line up with the above diagnoses.
There are a few things I want to try:
- Replace the reset and clear buttons, or remove them completely, to rule out any shorts in the physical switch
- Add more paths to ground (this could be key?)
- Reroute the connections between the PIA and the Propeller away from everything else, to rule out induction
- Add filtering capacitor to Propeller (this absolutely needs to be done, I don't know why I skipped it).
What is the best way to look for a ground bounce?
Did a bit more thinking on this, and Mike is on to something, since it's worse with serial than PS/2, but the problem still manifests it is leaning towards a ground problem. If you have access to an optoisolator on the serial and it acts more like the PS/2, then ground it is. I'd also check the ground to make sure you have enough copper in the ground plane. Also try to add some extra decoupling caps just in case not just to the propeller, but around the whole board. Use Tantalums they are better than ceramic caps for this.
Thanks Corey. Got some more symptoms for you all.
After turning off, then back on after 24 hours, I was able to physically manifest random characters on the screen just by moving or touching one of the buses between the PIA and the Propeller. This included non-Apple characters that are still in the Propeller firmware, like arrows, etc. After a minute no amount of prodding would cause any affect, but still getting the odd space character. I would still say it's less often with the PS/2 keyboard.
I've also noticed that when sending text over serial, or typing very very very quickly (like the same character over and over), I will occasionally get a \ character (like when you reset the CPU) and get a carriage return, except that I stay in BASIC. To me this seems like a mini-crash, like the CPU isn't getting enough power for the briefest of moments.
I'm going to focus on increasing the amount of copper to ground, I've noticed now that I have daisy-chained a single pitiful TINY copper wire between the PIA, RESET switch, ROM and then to the RS232 board, think this wasn't a good move. The RS232 has two ground connections and I'm only using one (well the other one is connected - to ground. D'oh!!) EDIT: Also just noticed that I have daisy chained ground from the Propeller, to the EEPROM, to the logic gates, to the 6502, to the ROM, then to the RS232 - really don't know what I was thinking here, I know enough about this sort of thing to know to add plenty of ground.
I think I'll start replacing all the ground connections with thicker copper wiring, and run everything twice to each pin on the RS232. Would it be worth running separate copper wiring for each IC's ground pin(s) back to the RS232, rather than chaining them together? Would this help with any induction and overall electric capacity? Perhaps I should separate the Propeller and EEPROM from the rest of the circuit by using different paths to ground?
The Propeller is the only IC missing a filtering cap, every other IC has one including the logic gates. I must have just ran out and forgot. I think I have some spares, and it'll be an easy fix.
Not much more to say at this point, except that despite the problems, it feels super awesome to have this sort of working. I'm a talented amateur with electronics but far from perfect, this was a really big project for me. I'm actually thrilled to have gotten this far. I really wanted to push myself to avoid a PCB and 'enjoy' all this problem solving.
We're in business! Extra paths to ground now, and I added the filter cap, and I'm getting flawless keyboard and serial input.
This is awesome.
I had a replica 1 ten (red) with a strange problem
as soon as i had a finger or a hand nearby the propeller / pia
I had series of reset, not reset of 6502 but reset of the propeller...
I had lines with prompts...
I fixed it with a 10k resistor between pin 11 (reset) and pin 32 (3.3v) of the propeller
I placed it at the back of the pcb
the reset stopped...
and now the replica 1 is working fine
I also had a previous version of the replica 1
the same problem can occurs but very rarely
Well, I finally got around to another pet project of mine. About 2 years ago i picked up a Replica-1 and put it together and although it works i had some issues with it from the get go. Mostly repeating and scrolling of characters that would push all text off the screen and make the unit unusable...
so my thinking was, resolder it all but i also know that some of the issue I was seeing might be related to the USB board as connecting via serial i had little issues but still had some functionality that wasn't 100% perfect... So i ordered a new USB board and pin strips and just finished desoldering and installing a new one. Now the text is rock steady, not a single funky character or repeated characted and no scrolling. Litterally worked like it should... so if anyone has one and seeing this. This is what fixed mine. its a fairly cheap part from Digikey (10-15 bucks i believe but for me was worth it since mine was malfunctioning).
note I did try all the known fixes like soldering a jumper from the usb board to the CPU, etc. nothing fixed my issue and i just tucked the replica-1 away for a rainy day... or in my case feeling slightly under the weather so staying home from work today...
? L
000 LDA #'A'
001 LOOP JSR $FFEF
002 CLC
003 ADC #$1
004 CMP #'Z'+1
005 BNE LOOP
006 RTS
007
? A
0300-030C
? R $300
ABCDEFGHIJKLMNOPQRSTUVWXYZ
? ▒
... meaning all the Apple-1 builds based on MIMEO, Newton or Replica-1 PCBs (aka the Open Source Gerbers).
I'm well aware that Vince Briel's thingy is quite a different animal, but builders using the "real TTL grave" may see similar symptoms, which are: duplicate or missing characters, and end up on this thread, so I can't resist to post the symptoms and the remedy here, just to help those builders who have the problem with the "real" clones:
PDRM0961.JPG
The same issue seen with the terminal section exerciser found in both my (unreleased) DIAGNOSTICS PROM SET and my BURN-IN PROMS (which I use to make my famous tested and burned-in IC kits):
PDRM0874.JPG
In both cases the culprit was the 74123 oneshot pulse for the handshake logic being out of spec, some 2.8us instead of the 3.5us specified in the original schematics. The irony is that I was "lucky" enough to hit the very narrow region around 2.8us where the problem manifests itself in one of my burn-in platforms. And those missing or duplicate characters do not happen very often. And a small temperature change using a heat gun or cold spray on the 6520 PIA can make it go away until the PIA is back at room temperature. I replaced the 10K timing resistor with a trim pot and found out that the region where the problem manifests itself is very narrow and I found it only with the 6520s and not with any 6820 or 6821. If the trimmer is dialed to either the shorter or longer side of the narrow problem region, the problem either goes away or happens too rarely to see it, but I don't know if it really goes away forever.
So it is not an issue of the oneshot pulse either being a little bit too short or a little bit too long, but juuuust being at a "sweet spot" were the problem occurs. (Would "bitter spot" be more correct ?)
To me, it looks like synchronizer metastability causing the edge detector in the 6520 doing the wrong thing once in a while. The edge detector circuit in the 6820 / 6821 seems to be more robust against this, at least I was not able to find a (reasonable) setting of the trimmer where this problem would manifest itself, when using a 6820/6821.
If it is a metastability problem, somebody did not observe the setup/hold time requirements of flipflops within the PIA.
However, I could not find setup/hold time specs for that input in any of the 6520 datasheets I have. Hmmm. Same mindset at work as with the infamous 6522 shift register "bug" which ain't no bug in the 6522's circuit at all, but just a lousy datasheet leading designers using the VIA's shift register in external clock mode into pitfalls ?
We know that any input event violating setup and hold time requirements of an innocent flipflop used as a synchronizer may cause metastability. And we know that the MOS6520 is a blatant knockoff of the Motorola 6820. Maybe a not-so-good knockoff that missed some fine points hidden deep in the transistor level circuitry, such as more metastability robustness.
BTW, the Disk-II controller card also had an occasional metastability problem due to the D-Flipflops that synchronize the incoming RD_DATA stream to the Woz machine clock. But with this bit stream being jittery, due to the noisy nature of the floppy disk read signal, it is highly likely that the next retry to read the sector does not suffer from metastability again, and so the user does not notice much except the occasional retry.
The synchronizer metastability problem plagued all FDC designs of the time being, and got worse in hard disk controllers, so countless engineering hours were spent to find a remedy, and the number of patents claiming "metastability free synchronizer circuits" from the 1980s and 1990s are legion. All of them are bogus, though. Metastability free synchronizers don't exist. They are the perpetuum mobile of digital electronics. The patent office should have known that.
The solution is use of oversampling and voting in a carefully designed circuit consisting of several synchronizer flipflops clocked from multiple clock phases. If one of these flipflops gets metastable, in theory there shall be at least two further flipflops which are not metastable at the same time and the voting circuit should then be able to ignore the metastable one. So far the theory, but practical implementations use more than three flipflops. I once got a patent on such a thing, which allowed a 3.125 Gb/s SERDES chip to have zero bit error rate even with channel "eye diagrams" almost closed. Alas, I didn't get rich with it, but my employer who owned the patent sued everybody who used the same scheme and raked in more money from these lawsuits (or threats of lawsuits) than with the chip we had designed. Clown world !
Have fun !