Definier mal "IC-Abstände"...
Es gibt zwei ICs, die so nahe beisammen sind (= deren "Footprints" so wenig Abstand haben), dass sie nicht ohne Gewalt bestückt werden können. Ich musste bei einem IC sogar das Gehäuse stirnseitig abschleifen. Ich kann's gerne raussuchen oder ein Foto machen.
Nicht nötig, danke.
Ist also ein rein mechanisches Problem. 
Es gibt bei den Gehäusen extreme Unterschiede. Hab schon welche gesehen, die standen an beiden Enden 1mm über den Sockel hinaus.
Hab auch schon Arcade Bootlegs gesehen, da saßen 2 Chips drauf, die bildeten ein Hausdach. Gleiches Problem. 
ZX81plus38. Dessen Design ist ... mangelhaft. Begonnen beim Oszillator, IC-Abstände, usw.
Man muss aber dazu schon sagen, dass das ein Prototyp ist und der Autor bisher noch nichtmal sein eigenes Exemplar fertiggebaut hat.
Er freut sich aber bestimmt über Verbesserungsvorschläge, das GitHub-Projekt dazu ist hier: https://github.com/mahjongg2/ZX81plus38
Hab mir grad nochmal die PCB-Fotos angeschaut und folgende Fragen dazu:
- JP12: da steht unten auf dem Board, man solle den "changen", also vermutlich die Vorbelegung durchtrennen und den JP als Brücke dann auf der bislang unverbundenen Seite bestücken, wenn 32KB RAM verwendet wird. HM62256 ist 32KB RAM, aber JP12 ist jungfräulich...
- gelb-schwarzes Kabel, das an den Elko unterhalb des Edge-Connectors geht: Ist das eventuell die aktuelle Stromversorgung, oder wird über USB eingespeist? Zuwas dann dieses Kabel? Denn -wenn die PCB keine Innenlagen hat- wären die Leiterbahnen für Versorgung schon sehr sehr dünn gewählt, d.h. fällt da min. einiges an Spannung ab und die Impulsfestigkeit leidet natürlich auch...
- Reinigung der PCB nach Lötarbeiten: man sieht teilweise erhebliche Harz-Rückstände und sogar "Lötnebel" auf der PCB, wenn diese Luft-Feuchtigkeit ziehen, kann das zu Fehlfunktionen führen...
- CD4002 Baustein (Uralt Harris aus 1997 bestückt): So wie es auf der unbestückten PCB aussieht, wurde der CD4002 aktiv eindesignt, wozu dient der Baustein, Schaltplan (-Auszug)? Denn das wäre ja nun ein Baustein, den man nicht durch LS oder HCT ersetzen kann und der zu einer nochmals anderen Logikfamilie gehört, da wäre schon zu hinterfragen, warum man ein solches "Mischmasch" produziert...
- einige Lötstellen sehen "eingefallen" aus, wurde beim Bestücken an den eng an eng liegenden Sockeln überprüft, ob da kein Lötzinn oben auf der Bestückungsseite rausgeflossen ist und nun möglicherweise Kurzschlüsse verursacht?
Generell: die Anordnung der ICs ist schon recht abenteuerlich, auch der Quarz mehr oder minder auf der PCB-Kante ist suboptimal, zudem sollte das Quarz möglichst nah an sowohl den Oszillator, als auch dieser wiederum an der CPU liegen, um unnötige Störabstrahlung zu vermeiden, wie auch die Funktionssicherheit zu erhöhen (lange Leiterbahn: verschliffenes Signal). Viele Leiterbahnen sind unnötig dünn ausgelegt, ebenso die Vias. Da gehe ich mit kinzi konform: das Layout hat definitiv noch Verbesserungspotential!
Viele Hinweise und Fotos etc findet man u.a. hier: http://searle.x10host.com/zx80/zx80.html
ZX81plus38. Dessen Design ist ... mangelhaft. Begonnen beim Oszillator, IC-Abstände, usw.
Man muss aber dazu schon sagen, dass das ein Prototyp ist und der Autor bisher noch nichtmal sein eigenes Exemplar fertiggebaut hat.
Er freut sich aber bestimmt über Verbesserungsvorschläge, das GitHub-Projekt dazu ist hier: https://github.com/mahjongg2/ZX81plus38
Ja, das ist mir bekannt, und ich habe ihn auch schon per E-Mail kontaktiert. Leider habe ich bisher keine Antwort erhalten.
Vielleicht einfach das Repo forken? Das könnte etwas Liebe gebrauchen, die ZIPs gehören so da ja nicht hin; eine Website als GitHub Pages wäre schön, eine FAQ und so weiter...
- JP12: da steht unten auf dem Board, man solle den "changen", also vermutlich die Vorbelegung durchtrennen und den JP als Brücke dann auf der bislang unverbundenen Seite bestücken, wenn 32KB RAM verwendet wird. HM62256 ist 32KB RAM, aber JP12 ist jungfräulich...
So wie ich das verstanden hab wird von dem HM62256 nur 16KB RAM verwendet. Es gibt ja auch kaum Software für den ZX81, die mehr als 16KB verwendet.
Trotzdem wurde ein 32KB RAM eingebaut, weil das am besten erhältlich und damit preiswert verfügbar ist.
Der Entwickler hat mit JP12 aber trotzdem die Möglichkeit hardwaremäßig vorgesehen die vollen 32KB RAM zu verwenden, was aber nur mit Anpassungen im Basic funktionieren würde.
Standardmäßig ist JP12 so gesetzt, dass nur 16K verwendet werden.
Überhaupt sind alle Jumper so vorbesetzt, dass man mit der Bestückung von der BOM (die ich ja weitgehend verwendet habe) zu einem funktionierendem System kommen sollte.
Zitat vom Entwickler (aus dem Thread von mikrocontroller.net):
- gelb-schwarzes Kabel, das an den Elko unterhalb des Edge-Connectors geht: Ist das eventuell die aktuelle Stromversorgung, oder wird über USB eingespeist? Zuwas dann dieses Kabel? Denn -wenn die PCB keine Innenlagen hat- wären die Leiterbahnen für Versorgung schon sehr sehr dünn gewählt, d.h. fällt da min. einiges an Spannung ab und die Impulsfestigkeit leidet natürlich auch...
Das führt zu einem Reset-Taster. Der überbrückt C5. Den hab ich mal hinzugefügt um zu sehen, ob das Board mit einem manuellen Reset startet. Siehe Post #15
Könnte ich jetzt entfernen, da das Board ja inzwischen korrekt startet. Bei meinem Board #2 hab ich den Reset-Kondensator übrigens von 1µF auf 3.3µF erhöht um einen sichereren Start zu gewährleisten.
- Reinigung der PCB nach Lötarbeiten: man sieht teilweise erhebliche Harz-Rückstände und sogar "Lötnebel" auf der PCB, wenn diese Luft-Feuchtigkeit ziehen, kann das zu Fehlfunktionen führen...
Ja, Danke für den Hinweis, werde ich noch machen. Glaube aber nicht, dass das den Fehler behebt.
- CD4002 Baustein
... ist so vom Entwickler vorgesehen. Hab ihn deshalb auch eingebaut. Funktioniert z.B. bei bigby 's Board ja auch.
- einige Lötstellen sehen "eingefallen" aus, wurde beim Bestücken an den eng an eng liegenden Sockeln überprüft, ob da kein Lötzinn oben auf der Bestückungsseite rausgeflossen ist und nun möglicherweise Kurzschlüsse verursacht?
Aus dem Grund hab ich gestern eine zweite Platine aufgebaut um Lötfehler auszuschließen. Es ist relativ unwahrscheinlich, dass auf 2 Boards an derselben Lötzinn oben auf der Bestückungsseite rausgeflossen ist und dort dann zu demselben Fehler führt.
Leute, vielen lieben Dank für Eure Vorschläge, hat mir auch schon ein ganzes Stück weitergeholfen.
Aber ich werde jetzt erst mal die Lieferung von Kessler abwarten und die vom Entwickler vorgesehenen Bausteine 1:1 verwenden. Hoffe, dass es damit klappt.
Bei bigby 's Boad läuft es so ja auch. Das bekräftigt mich in dieser These.
Eine Frage hätte ich noch an die Leute, die das Board bereits erfolgreich aufgebaut haben.
Es betrifft das Widerstandsnetzwerk RP2.
Laut Schaltplan soll hier 8x10K eingebaut werden. Lt. BOM aber 8x22K. Ich habe 8x22K bestückt.
bigby : Was hast Du da bestückt?
Könnte hier evt. der Fehler begraben sein?
Es gibt zwei ICs, die so nahe beisammen sind (= deren "Footprints" so wenig Abstand haben), dass sie nicht ohne Gewalt bestückt werden können.
Spannend. Ich kann mich nicht erinnern, dies Problem gehabt zu haben. Anscheinend habe ich ICs mit kleinerem Gehäuse erwischt.
Vielleicht einfach das Repo forken? Das könnte etwas Liebe gebrauchen, die ZIPs gehören so da ja nicht hin; eine Website als GitHub Pages wäre schön, eine FAQ und so weiter...
Wenn der eigentliche Entwickler scheinbar kein Interesse an solcher Mithilfe und Mitwirkung hat, dann bringt das Forken auch nicht so viel. Ich habe es letztes Jahr mit einem ersten, kleinen Pull-Request versucht. Aber der wurde bisher ignoriert und das Ticket dazu ohne Kommentar zur Sache geschlossen. 
Überhaupt sind alle Jumper so vorbesetzt, dass man mit der Bestückung von der BOM (die ich ja weitgehend verwendet habe) zu einem funktionierendem System kommen sollte.
Das kann ich bestätigen, ich habe auch keinen der Jumper verändert.
Aber ich werde jetzt erst mal die Lieferung von Kessler abwarten und die vom Entwickler vorgesehenen Bausteine 1:1 verwenden. Hoffe, dass es damit klappt.
Bei bigby 's Boad läuft es so ja auch. Das bekräftigt mich in dieser These.
Der Ordnung halber: Das stimmt meiner Erinnerung nach nicht ganz. Ich meine, ich habe den einen oder anderen LS/HCT Baustein verwendet, wo in der BOM HC stand.
Laut Schaltplan soll hier 8x10K eingebaut werden. Lt. BOM aber 8x22K. Ich habe 8x22K bestückt.
bigby : Was hast Du da bestückt?
Könnte hier evt. der Fehler begraben sein?
Ich glaube nicht, dass das die Ursache für Dein Problem sein kann. Was ich da bestückt habe, müsste ich mal nachschauen. Im Zweifel den Wert aus der BOM.
Ruudi Siehe Beitrag #8 hier im Thread.
Ich sehe da eine Z84C00020PEC, also 20 MHz C-MOS Variante.
Dafür ist das SRAM mit 120ns etwas langsamer als bei Manfred.
Was genau unter dem roten "ZX81" Aufkleber als ROM werkelt, hab ich jetzt nirgends gefunden...
An HC Typen sehe ich ausser bei der Takterzeugung nur die Flipflops HC74
Was genau unter dem roten "ZX81" Aufkleber als ROM werkelt, hab ich jetzt nirgends gefunden...
Nein, das ist auf dem Bild nicht natürlich nicht zu erkennen: Das ist ein W27C512.
Hab heute die Lieferung von Kessler electronic erhalten.
- An Board #1 zuerst U6 74HC125 gegen ein 74LS125 (Leitungstreiber 4-fach Tristate) getauscht. Keine Änderung.
- Dann U4 74HC574 gegen ein 74HCT574 (Select One of 64 possible Characters from ROM; D-FlipFlop 8-fach) getauscht. Auch keine Änderung.
- Als nächstes war U9 dran. Das vorhandene 74HC165 gegen ein 74LS165 (Pixel Shift register; Schieberegister 8bit parallel) getauscht. Damit waren auf dem ersten Board die korrumpierten Zeichen weg, aber es verhielt sich nun exakt wie Board 2, also es gab nur noch ein Quadrat als Cursor, aber keine Zeichen mehr.
Komischerweise funktionierte die Auswahl der Bordercolor mit JP6 (den ich inzwischen bestückt habe) mit dem LS165 nicht, aber mit dem HC165, deshalb hab ich den wieder zurückgetauscht.
Damit war das Board exakt so bestückt, wie vom Entwickler vorgesehen. Leider hat sich meine Hoffnung somit nicht erfüllt, so zu einer funktionierenden Zeichendarstellung zu kommen.
Hab zusätzlich auch noch ein HCT393 als Ersatz für U7 bestellt, weil das auch an der Zeichendarstellung beteiligt ist (count colomn of displayed characters).
Aber es spielte keine Rolle, ob das HC oder das HCT eingesetzt war.
In der Folge hab ich noch etwas rumprobiert und in der Bastelkiste vorhandene Bausteine probehalber getauscht.
Das HC86 gegen ein LS86 getauscht, aber es ergab keine Änderung.
Auch die HC74 Flip-Flops gegen HCT74 getauscht aber es spielte keine Rolle.
Dann hab ich das RAM mal gegen die vorhandenen getauscht. Dabei hat sich herausgestellt, dass es auch vom verwendeten RAM-Baustein abhing, ob die Zeichen korrumpiert dargestellt werden (wie in Board #1) oder nur als Quadrat (wie Board #2).
7 RAMs hatte ich da. 4 davon zeigten das Quadrat, 2 davon hatten das Verhalten wie Board #1 (korrumpierte Zeichen), einer ging gar nicht (kein Bildaufbau).
Dann hab ich noch 1 HM62256 extra aus einer funktionierenden Universal Cardridge (UC 1.5) von Diddl ausgebaut und in die Platine eingesetzt.
Es zeigte das Verhalten mit dem Quadrat.
Übrigens zeigt auch das Board #2 dasselbe Verhalten, je nachdem welches RAM man einsetzt.
Noch was, was mir aufgefallen ist...
Wenn ich U4 74HCT574 (Select One of 64 possible Characters from ROM; D-FlipFlop 8-fach) gar nicht eingesetzt habe, bleibt das Verhalten des Boardes gleich.
Also auch mit unbestücktem U4 verhält sich das Board gleich, wie wenn es bestückt ist. Da scheint irgendwo der Hund begraben zu sein.
Leider verstehe ich nicht ganz, wie die Zeichenselektion beim ZX81 funktionieren soll.
Alles etwas seltsam, vor allem das Verhalten bei verschiedenen RAM-Bausteinen.
Nur leider bin ich bis jetzt noch nicht zu einer funktionierenden Zeichendarstellung gekommen.
Ich glaube inzwischen fast, dass das Verhalten mit dem Quadrat das richtige Verhalten ist, nur dass halt die Auswahl des Zeichens aus dem ROM nicht funktioniert.
Das bekanntermaßen funktionierende RAM aus der UC1.5 hatte jedenfalls auch dieses Verhalten an den Tag gelegt...
Klingt fast so, als gäbe es da ein Timing-Problem mit den Output Enable-Signalen für das RAM und U4...
So Leute, ich hab eine Lösung gefunden. 
Der User "Sascha Ittner" in diesem Thread aus mikrocontroller.net hatte exakt dasselbe Problem wie ich und hat Dank besserer Messausrüstung und besserem Verständnis ein Workaround gefunden.
Die Zeichen-Pattern während des Refreshzyklus kommen nicht richtig im Schieberegister an.
Bei der Messung hat er festgestellt dass, das EPROM zu schnell angesprochen wird (bei ihm 21ns)
Der Workaround besteht darin, der CPU einen invertierten Takt zuzuführen, dann hat das EPROM ca. 150ns Zeit und das reicht dann um die Zeichendarstellung korrekt zu adressieren.
Ein ungenutztes FlipFlop in U18 (74HC74) wird dazu als Inverter missbraucht um das zu bewerkstelligen.
Ich hab das bei meinem Board #1 gleich mal Quick&Dirty nachgebaut.
Bei U18 Pins 1 und 4 hochgebogen. Pin 1 mit dem 3.25MHz Takt verbunden. Pin4 mit Masse.
Bei der CPU Pin 6 (Takteingang) hochgebogen und mit Pin6 von U18 durchverbunden.
Das sieht dann so aus.
Dann kam der Moment der Wahrheit....
... und tatsächlich das ersehnte "K" erschien auf dem Bildschirm und ich konnte ein erstes Programm eingeben. 
Das dunklere Bild im unteren Bereich ist übrigens nur vom Abfotografieren mit dem Smartphone. Ist in echt alles gleich hell.
Hurraaaaaa, das Board läuft endlich.
Mein Gott, das war eine schwere Geburt, aber wichtig ist immer, dass man nicht aufgibt. Wie sagte ein früherer Chef mal zu mir:
"Wenn man nicht auf dem geraden Weg zu einer Lösung kommt, muss man halt einen Umweg gehen. Wichtig ist, dass man das Ziel erreicht!". Wie wahr.
So... ich werde jetzt dann noch ein wenig rumexperimentieren welche Chipvariationen laufen (RAM-Bausteine, HCT/LS vs. HC- Versionen) usw.
Das Problem mit dem "Quadrat" statt Zeichen (Verhalten von Board #2) bedarf auch noch einer Lösung.
Mal sehen ob ich das zweite Board auch noch zum laufen bekomme.
Vielen lieben Dank an alle guten Hinweisgeber in diesem Thread vor allem an kinzi, bigby , 1570, ADAC und die anderen. Ohne Euch wäre ich nicht so weit gekommen. 
Es zeigt sich hier, dass die Version 1.6 des ZX81+38-Boardes doch noch einiges an Verbesserungspotential hat.
Ich denke ich werde mich im mikrocontroller.net anmelden und mich bei Sascha Ittner bedanken und meine Erfahrungen auch dort einbringen.
Er hat übrigens ein Redraw von Mahjongg's Entwurf mit einigen Änderungen/Verbesserungen erstellt. Siehe hier
Viele Grüße
Manfred
Machst Du dann auch noch ein bischen was mit dem zx81 ? Vielleicht paar kleine Programmierprojekte, die man hier im Forum zeigen könnte?
manfred.moser Glückwunsch zum laufenden Board und Respekt für Dein Durchhaltevermögen! 
Machst Du dann auch noch ein bischen was mit dem zx81 ? Vielleicht paar kleine Programmierprojekte, die man hier im Forum zeigen könnte?
Ich muss zugeben, dass ich nicht so der Software-Crack bin. Die Hardware macht mir mehr Spaß.
Aber wer weiß... wenn ich mich in den ZX81 eingearbeitet habe.. vielleicht geht dann ja doch was in der Richtung
manfred.moser Glückwunsch zum laufenden Board und Respekt für Dein Durchhaltevermögen!
Vielen Dank für die Glückwünsche. Bin auch froh, dass es schließlich doch noch geklappt hat.
Es lässt mich halt einfach nicht los... je schwieriger das Problem wird, desto größer die Herausforderung... und ich liebe Herausforderungen 
Mit demselben Workaround läuft inzwischen auch das zweite Board.
Hab mal testhalber alle von Kessler gekauften HCT/LS-Versionen wieder gegen die ursprünglich eingesetzten HC-Typen getauscht. Beide Boards laufen jetzt auch mit denen.
Testweise auch mal ein RAM-Baustein gegen einen, der vorher nur das Quadrat brachte, getauscht. Und auch damit kommen die Zeichen jetzt ohne Probleme.
War scheinbar also wirklich ein Timing-Problem und dabei passiert dann halt Unvorhersehbares.
Der 3D-Drucker läuft inzwischen fürs zweite Gehäuse und dann kann ich - wenns zeitlich passt - ja auch noch die drei restlichen Boards in Angriff nehmen. 
Na, das sind doch interessante Nachrichten! Gratulation zum Fahndungserfolg!
Frage an manfred.moser : Ne NMOS-CPU hast Du jetzt nicht wirklich mal verbaut gehabt, oder?
Ich hatte ja leider zu spät erst gesehen/kapiert, dass die von Dir eingesetzte CPU von Anfang an auch ne C-MOS war...
Wäre interessant, ob auch ne ECHTE NMOS Z80A CPU mit den HC-Bausteinen, resp. der bunten Mischung läuft, RAM und EPROM wären dann ja immer noch C-MOS.
Dass sich nun rausstellt, dass das Board grundsätzlich nicht lauffähig war, ist natürlich ne Riesensauerei, wenn man bedenkt, in welchen Mengen das über verschiedenste Kanäle verkauft wurde und noch wird...
Kann aber bestätigen, dass ein ECHTER ZX80, egal ob auf "slow mode" modifiziert nach Grant Searle oder original ab Werk NICHT läuft, wenn man ALLE LS durch HC ersetzt, selbst mit HCT an ein paar Stellen ging es nicht. Setup mit 4K/8K Original ROM von Sinclair, 2 x 2114 RAM und NMOS-CPU.
Hatte extra meinen ZX80 dafür aus der Vitrine geholt 
Komplette Umrüstung auf C-MOS incl. CPU, RAM, ROM und eben "TTL"-Logik könnte ich mal noch probieren, aber dazu müsste ich mir fürs RAM nen Adapter bauen, denn 2114 als "echtes" C-MOS habe ich nicht, bin mir auch nicht sicher, ob es das je gab... Beim ROM könnte man hingegen die Adapter vom C64 etc. nutzen (2332/2364 auf 27C64)...
edit: lt. ebay gibt es wohl 21C14 Bausteine: https://www.ebay.de/itm/183270559156, auch Sanyo LC3514 ist wohl kompatibel, aber intern C-MOS, aber deutlich kleinere Zugriffszeiten als das Original, das könnte auch wieder Ärger machen, von denen müsste ich noch welche haben -die hatte ich zunächst gar nicht auf dem Schirm- das probier ich bei nächster Gelegenheit mal...
