Beiträge von i440bx

    Es gab nach langer Zeit mal wieder Zuwachs in Chips und Merch.


    Ein paar Sockel, ein Edison Modul mit Basisplatine, ein 386 Schlüsselanhänger und ein paar Kleincomputer.


    Ein paar besondere Chips. Die 3 um den Intel Soma-B3 sind hervorzuheben:
    1x PIC16F877 als Engineering Sample (tuts!)

    1x Mostek MK28P75/02H - mit EPROM Sockel direkt oben drauf :)

    1x ST52E420 als Engineering Sample. Ein µC mit einem eigenen Fuzzy-Logic-Core <3


    Ein paar 8" Disketten


    Und wirklich viele Intel Käfer und ein Coprozessor Mauspad


    Und eine sehr große Liste an S775/S1155/S1156 CPUs - aber die sind "nur so dabei" denn die schönen Chips sind die mit 2 Reihen von Beinchen.


    ---


    Es fehlt noch einiges an Neuzugängen (unter anderem von matt oder H.EXE ) - das kommt später als Posting

    Zum Taktgeber: hier könntest du auch einen Raspberry Pi Pico nehmen. Da kommst du von 0,xxxHz bis zu 64MHz hoch.

    Also perfekt um zu testen.

    Danke für den Tip, aber es gibt bis heute keine 64MHZ 80186 CPU :D


    Ich tummle mich in bereichen bis ~16MHZ CPU (32MHZ Crystal) rum. Dafür kann ich dann einen Quarz bzw. Oszillator nehmen.


    Zum testen brauche ich aber wirklich wenig Frequenz und dafür ist der kleine Digispark ausreichend.

    Der Nachtrag.


    Die CPU ist weitestgehend "freifliegend" bis auf die Datenpins die per Widerstände auf den OPCode "NOP" gepullt sind. Also von A0-7: 10010000 A8-A15: 00000000 (Ein 8Bit Befehl)


    Was die CPU dann machen *sollte* ist: Daten von Startadresse lesen, einmal alle 65536 Adressen hochzählen, Daten von Startadresse + 1 lesen, einmal alle 65536 Adressen hochzählen, Daten von Startadresse + 2 lesen ... und so weiter.


    Was die CPU anfangs gemacht hat:


    Was sieht man?

    Ganz rechts zwei LEDs die Anzeigen ob gerade der LOW-Bus (A0, grün) oder der HIGH-Bus (BHE, rot) aktiv ist Im Falle von NOP solle immer nur LOW aktiv sein, da der Befehl ein 8Bit befehlt ist.

    Danach sinds nochmal 8 grüne LEDs für A1-A8, 8 gelbe LEDs für A9-A16 und 4 rote LEDs für A16-A19

    Die CPU taktet derweil mit 100Hz extern, 50Hz intern und da NOP 3 Takte je ausführung braucht (50 / 3 = 16,67Hz) sollte die A1 LED gut vor der Erkennungsschwelle blinken.


    Was sieht man noch?

    Naja. Irgendetwas tut er. Die grünen LEDs zählen auch.... irgendwie. Aber sauber ist das auf keinen Fall.


    Dann habe ich mal angefangen zu tüddeln. Das Verhalten der LEDs veränderte sich wenn ich die Finger hinten an die Pins gedrückt habe und wenn ich die CPU im Sockel hin und herbewegte. Ganz am Ende der Sequenz drücke ich den Reset-Knopf, aber er wacht direkt mit Datenmüll auf.


    ---


    Dann bin ich durch probieren und löten auf den Trichter mit den fehlenden Widerständen gekommen (siehe das Posting weiter oben). Der groschen ist gefallen als ich folgendes geändert habe:


    Die Datenpins A8-A15 waren zu anfang *frei fliegend* also nicht gepullt. Das sieht man oben in der ersten Sequenz - die gelben LEDs rasten voll aus, die grünen sind so halbwegs am Start. Ich zog die Datenpins A8-A15 also auf Masse und siehe da - die gelben LEDs fingen an einen erkennbaren Status zu haben.


    Aber: Sowie die CPU nach einem Durchlauf neue Daten geholt hatte rastete die Kiste wieder voll aus.


    Der Grund: Nach dem Reset legt die CPU die Adresse FFFF0 an. Hat also annähernd alle Adresspins oben - auch A16-A19. Die Adresspins A16-A19 sind aber keine Datenpins, sind also nur an einen Latch angeschlossen. Die Lacht'es wiederrum sind am Eingang hochomig wenn die Adresse angelegt wurde und die Adresspins 0-15 zu Datenpins werden.


    Schlussfolgerung: Die hochomigen Latch'es und Treiber sind zu hochomig. Es tummeln sich noch Elektronen auf dem internen Bus und die HCT Chips interpretieren diese.


    Nachdem ich dann sehr viele Widerstände eingebaut habe sah es dann so aus:


    10Hz Eingangstakt - 5Hz CPU


    154Khz Eingangstakt - 77Khz CPU


    Ich nutze als Taktgeber einen Digispark Rev3 - und der kann mit maximal 154Khz einen Pin toggeln :)

    Jetzt wo ich es weiß ist die Erklärung simpel... Ich habe bidirektionale Aus- und Eingänge mit unidirektionalen Eingängen gemischt.


    Ist "wie früher" gemalt, hab ich aus Serviceschaltplänen direkt von Intel abgekupfert. Was ich aber nicht bedacht habe ist, das die 74HCTxxx Bausteine, die ich nutze so empfindlich, sind das Reflektionen und nicht abgebaute Spannungen zu Problemen führen.



    Auf dem Bild sieht man oben wie es war und unten wie es nun ist.


    Durch die 74HCTxxx Bausteine kommt es zu einem Phänomen was ich eher den frei fliegenden Elektronen satt der Reflektionen zuorde:

    Die CPU ließt die Daten vom Datenbus:
    - der AD3 Pin wird zum Datenpin mit der Richtung "Receive" (also in die CPU rein)
    - der Richtungs-Pin der CPU geht auf Low um dem Treiber zu sagen wohin es gehen soll
    - der Treiber legt das Signal auf die Leitung und die CPU empfängt es

    Jetzt kommt das Problem: Die CPU "futtert" nicht alle Elektronen, sodass nachdem der AD3 Pin wieder hochomig wird noch Ladungsträger auf der Leitung sind

    In der zwischenzeit legt die CPU eine Adresse an:
    - der AD3 Pin wird zum Adresspin, in dem Fall gibts nur die Richtung "Transceive" (also aus der CPU raus)
    - der Latch enable Pin wird aktiv und der Latch....

    ---- nimmt sich entweder das HIGH Signal vom AD3 Pin oder wenn der Low ist:

    ---- nimmt er sich das HIGH Signal was von der Datenaktion *vorher* noch auf der Leitung liegt

    - die Adresse die die LEDs anzeigen stimmt also *nicht* mit dem überein was die CPU will


    Dazu kommt noch:

    Die CPU merkt nicht das Datenmüll auf dem Adressbus liegt und geht jetzt - nachdem die Adresse angelegt wurde - wieder in den Lesemodus.


    Aber diesmal empfängt sie den Müll der *immernoch* auf dem internen Bus rumfliegt weil die Ladungsträger immernoch nicht alle weggeflossen sind.


    ---


    Ich lade morgen mal ein paar GIFs oder Links zu Videos hoch. Sieht total geil aus wenn der interne Bus ausrastet. Hat aber ziemlich gedauert bis ich den Fehler eingrenzen konnte und ihn schlussendlich beseitigt hatte.



    Zu guter letzt die Revision 2 des Taktgebers und der Resetschaltung.


    Wie vorab beschrieben habe ich beiden Schaltkreise ausgelagert, damit es auf der CPU Karte nicht so wild aussieht.


    Außerdem besteht dann die Möglichkeit auch einen Digispark o.Ä. einzusetzen wenn man den Takt oder Reset genauer steuern will.


    Da wollen wir die 5V Schiene doch mal ordentlich auslasten =)


    Diese Karte ist vollgestopft mit LEDs und 7Seg Anzeigen.


    Was zeigen die an? Na das was drauf steht. Die EPROMs und der kleine Microcontroller sind so programmiert/angeschlossen, dass mir die HEX-Werte der Daten & Adressen ausgegeben werden.


    So kann man in Ruhe troubleshooten :)

    Irgendwann heute Nachmittag nebenbei das EPROM gebrannt.



    Danach n paar Kabel gebaut damit ich nicht im Molex Footprint rumsaue und mal Saft drauf gegeben:



    Hm. Doof. Ok, Chiptester ran:



    Alle Chips die mit dem Chiptester geprüft werden können mal geprüft aber keine Leiche gefunden. Mal, wie Adrian sagt, ein bisschen "poking to the pcb" und siehe da:



    Hm. Kalte Lötstelle? Arschbacken zusammenkneifen und mal eben 500 Lötstellen nachgelötet. Danach das PCB auch mal gereinigt.



    Leider immernoch nicht.


    Er ist eine Zicke. Wenn er einmal gestartet ist, gehts. Aber der Kaltstart nach längerer Zeit klappt nicht sofort.


    Puh. Ist mir erstmal egal. Nächste Baustelle ist dem Ding via RS232 ein weiteres Lebenszeichen zu entlocken.