Beiträge von Georg

    Hi Michael,


    Das ist wirklich nicht OK:


    Da muss eine Schraube durch wie hier:

    (habe leider gerade keine besseren Bilder gefunden)

     


    Die fixe Einstellung der Adresse auf dem Disk-Controller stammt übrigens nicht von mir. Nicht meine Schrift, nicht meine Labels. :)


    Und die Stellen mit den durchgebrannt Leiterbahnen habe ich auch gefunden:

    Wie schon oben geschrieben: die zweite Schreibschutzkerbe deutet auf die Verwendung in einer 1541 hin.

    Wenn da also mal was Wang-spezifisches drauf war, dürfte das wohl überschrieben worden sein.

    Und die Hinweise auf die Nutzung in einem Wangwriter bedeuten ja nicht, dass da mal was für einen Wangwriter drauf war.

    Alles in allem bin ich ziemlich sicher, dass das keine der gesuchten Systemdisketten sind.

    Cartouce: Super, Danke!


    Ein paar Worte zur Track0-Einstellung:


    Auf der Achse des Schrittmotors für den Kopfantrieb befindet sich ein Alu-Arm, der sich durch eine Gabellichtschranke bewegt und dabei die Spur 0 festlegt (Die Lichtschranke ist auf dem Bild demontiert, um den Arm sehen zu können):



    Dieser Arm ist mit einer kleinen Imbus-Schraube auf der Motorwelle fixiert und kann somit eigentlich recht einfach justiert werden.

    Leider ist es etwas komplizierter: Der Motor hat (wie man lesen kann) 200 Schritt pro Umdrehung. Die Platte kann aber über 220 Spuren ansteuern, so dass diese Lichtschranke sowohl bei der Spur 0 als auch im Bereich der Spur 200 anschlägt. Um das jetzt eindeutig zu machen gibt es einen zweiten Sensor (das ist das Platinenteil links vom Schrittmotor, ebenfalls eine optische Lichtschranke mit LED und Phototransistor), der wohl direkt vom Kopf ausgelöst wird. Dieser Sensor gibt eine grobe Information, dass der Kopf "innen" steht, während der Sensor an der Welle eine exakte, aber dafür nicht eindeutige Information über die Kopfposition liefert.


    Die Elektronik der Platte kombiniert nun diese beiden Informationen und setzt nur dann die Leitung TRACK0, wenn beide Sensoren aktiv sind.


    Wenn ich nun den Arm auf der Welle verstelle bewege ich mich eine Zeitlang in dem aktiven Bereich des zweiten Sensors. Ungefähr ab Spur 10 liefert dieser zweite Sensor aber kein Signal mehr - und damit endet mein Einstellbereich hier. Wenn ich den Arm soweit verstelle, dass ich aus dem Bereich der Plattenschäden raus bin (ab ca. Spur 20) bekomme ich überhaupt kein TRACK0-Signal mehr.


    Mein aktueller Plan sieht jetzt so aus:


    1. Modifikation des zweiten Sensors, so dass er dauernd aktiv ist. Entsprechend bekomme ich dann über die knapp 230 Spuren der Platte zweimal das Signal TRACK0 - einmal innen, und einmal außen.

    2. Justierung des Arms, so dass die innere TRACK0-Position im Bereich der ehemaligen Spuren 20-30 liegt.

    3. Umdrehung der Anordnung: Logische Verlegung der Spur 0 auf die äußere Position


    Der Rest wird in der Software erledigt. Bei der Initialisierung wird der Kopf zunächst für ca. 250 Schritte nach außen bewegt. Die Endabschalter verhindern dabei, dass er an einen mechanischen Anschlag stößt. Anschließend wird er nach innen bewegt, bis das Signal TRACK0 erscheint. Damit ist die Spur 0 festgelegt.

    Der zweite (innere) TRACK0-Impuls nach 199 oder 200 Spuren signalisiert das Ende des nutzbaren Bereichs. Das wird zwar primär über das Zählen der Steps gesteuert, aber dieses Signal stellt eine zusätzliche Sicherheit dar, um nicht in den Bereich des Headcrashes zu kommen.


    Dass die Platte dann nur noch 200 Spuren hat ist für mich völlig unerheblich.


    Natürlich hat das Ganze nur wirklich Sinn, wenn das mit dem Lesen und Schreiben wieder klappt....


    Übrigens: Wenn ich von Spuren schreibe sind i.d.R tatsächlich Zylinder gemeint. Die tatsächliche Position eines Sektors wird durch Sektornummer, Spur und Kopf bzw. Plattenoberfläche festgelegt.

    Mein Beileid für diesen schmerzlichen Verlust :(

    Wenn wenigstens kein Headcrash vorläge, denn nun ist die Platte auch optisch beeinträchtigt.

    Danke :cry:

    Wobei ich einen solchen Headcrash bzw. dessen Spuren grundsätzlich für ganz anschaulich halte - immerhin ist das ein typischer Fehler bei diesen Platten gewesen. Ist halt im konkreten Fall wirklich blöde, weil ich bis dahin ja recht erfolgreich mit dem Lesen und Beschreiben der Platte war, woran jetzt nicht mehr zu denken ist.

    Die Welt ist um beeindruckende 6MB ärmer ....

    Hier ein kleines Andenken aus meinem YT Video, als sie sich noch munter drehte: https://youtu.be/biPoxiFeGZk?t=586

    Danke, hat mich gefreut! Genau so etwas habe ich mir hier vorgestellt.


    Joe_IBM , Digitalmax , Logout: Danke für Eure Angebote und Wünsche! Ich habe auch schon über einen Wechsel der Platte nachgedacht. Ich habe sowohl Cartridges als auch lose 14-Zoll-Scheiben hier - allerdings keine Ahnung, ob ich das mechanisch hinbekommen würde.

    Davon abgesehen fehlt es mir an einem geeigneten Arbeitsplatz:



    Ich habe zwar schon selber alte 5,25 Zoll Festplatten stundenlang ohne Deckel betrieben, ohne dass es irgendwelche Störungen gab, aber das ist keine Garantie dafür, dass diese Platte auch so robust gegen Staub ist.

    Und dann bleibt natürlich noch die Frage, welche Schäden der Schreib-/Lesekopf bei der Gelegenheit davon getragen hat.


    Mmh, ich sehe da zwei Probleme:

    Tatsächlich stellt sich die Frage, ob der Kopf zum Teufel ist. Die Scheifgeräusche sind zur Zeit nur auf den inneren ca. 20 Spuren zu hören - auf dem Rest der Platte hört sich das noch ganz normal an.

    Ich weiß auch nicht, wie die Rückseite der Platte aussieht. Möglicherweise ist der zweite Kopf und die zweite Oberfläche noch intakt - dummerweise habe ich bei meinen letzten Leseversuchen immer nur die erste Seite angesprochen. Und inzwischen habe ich die Platte wieder im Regal stehen und alle Messaufbauten abgebaut :rolleyes:

    Ich habe allerdings auch den Verdacht, dass ich beim Versuch, die Spur 0 zu verstellen, etwas an der Elektronik gegrillt habe. Jedenfalls roch es kurzfristig mal etwas streng. :fp:

    Steppen, Anschläge, Spur 0 etc. funktioniert noch alles, weshalb es kein großflächiger Schaden sein kann. Aber auf der Leseleitung habe ich nur noch irgendwelche wilden Peaks.


    Trotzdem werde ich natürlich den Strohhalm ergreifen und das Ganze nochmal auf der Rückseite ausprobieren - vielleicht ist mir ja doch eine 3MB-Platte geblieben.

    Die Welt ist um beeindruckende 6MB ärmer ....


    Viele Besucher der diesjährigen CC haben die 14-Zoll-Festplatte Philips X1250 bestaunt, die unter ihrem Klarsichtdeckel interessante Einblicke gewährte, sich eifrig drehte und dabei lustige Tänze mit ihrem Kopf aufführen konnte.


    Tja, offenbar war die Reise zur CC und der dortige Einsatz etwas zu viel für die alte Dame - wieder zurück in der Heimat zeigten sich bei der 41-jährigen die ersten Anzeichen einer Erkrankung: Vergesslichkeit, Lesefehler und dazu unangenehme Kratz- und Schleifgeräusche.

    Wie man sieht hat es einen Headcrash gegeben - dummerweise auf den Anfangsspuren (Spur 0 ist bei der Platte innen). :cry2:

    Ich habe versucht, den Kopfantrieb umzujustieren, aber das ist aus technischen Gründen zunächst unmöglich. Dazu müssen auch Teile der Elektronik umgebaut werden.


    Zusätzlich ist mir auch irgendetwas anderes kaputt gegangen; jedenfalls bekomme ich auch auf den anscheinend unbeschädigten Spuren nichts anständiges mehr gelesen.


    Schade, das war ein hübsches Spielzeug und auch ein spannendes Forschungsprojekt.


    Es würde mich freuen, wenn Ihr Eure Bilder oder Videos, die Ihr auf der CC von dem Schätzchen gemacht habt, hier posten bzw. verlinken würdet, um Eure Anteilnahme auszudrücken und mich etwas zu trösten .... :cry:

    An dieser Stelle möchte ich mal ein großes Dankeschön an Toast_r richten und meinen Respekt für deinen Einsatz und deine Arbeit zum Ausdruck bringen. :anbet:  :bussi:

    Ich versuche mir vorzustellen, was das für einen Haufen Arbeit ist, und alleine diese Vorstellung macht mich schwindlig....


    Herzlichen Dank, Christian!! :thumbup:

    Für mich ist die CP/M - Option interessant. Wenn es also geht konkretisiere ich:


    1 Stk 19" Rahmen mit Trafo und Spannungregelung

    1 Stk Parallel Eingabe

    1 Stk CPU 8085

    1 Stk Floppy Controller

    1 Stk Video 8.4

    1 Stk RAM/ROM 64k

    1 Stk RAM/ROM unbestückt

    1 Stk Bus-Signalanzeige


    Dafür verzichte ich auf das Drucker-Interface.

    Ich nehme, soweit noch vorhanden:


    1 Stk 19" Rahmen evtl. ohne Backplane

    1 Stk Trafo-Einschub

    1 Stk Spannungsregelung

    1 Stk Parallel Eingabe

    1 Stk CPU 8085

    1 Stk Floppy Controller

    1 Stk Video

    2 Stk RAM/ROM

    1 Stk Drucker-Interface

    1 Stk Bus-Signalanzeige

    Es gibt Neuigkeiten...

    Zum einen ein YT-Video zu der Platte von mikemcbike. Allerdings hat er bisher nur den Spindelmotor in Betrieb genommen und nicht den Kopfmotor (die beiden dafür nötigen Pins /DIR und /STEP wurden ja oben bereits genannt).

    Davon abgesehen ist es eine schöne Präsentation der Platte - vorausgesetzt, man steht auf den Humor der zwei Macher :).


    Und dann bin ich mal PAW s Hinweise zu den Signalen gefolgt, und natürlich war da noch ein Klops in meiner Adaption der Platte: von meinen ersten Versuchen mit dem Oszilloskop waren noch die Pullup - Widerstände an den Ausgängen vorhanden, die gegen 5V geschaltet sind.

    Inzwischen habe ich das alles entfernt und die Signale neu vermessen. Hier die Schreibsignale:


    Interessanterweise ist das Maximum immer noch im Bereich von 3,2V statt 5V. Aber beim Lesen sieht es jetzt anders aus:


    Hier bewegen wir uns jetzt im Pegelbereich des 3.3V-Systems um den Teensy. Die negativen Überschwinger sind hoffentlich nur Messfehler (schlechte Masseverbindung?).


    Das Interessante: Seit der Modifikation sind die Schreibaussetzer weg! Ich habe jetzt bei meinen Tests pro Spur nur noch ein oder zwei Fehler, die auch noch reproduzierbar sind. Da scheint die Platte tatsächlich echte Fehler zu haben - aber zum Glück recht selten.

    Damit konnte ich nun eine Spur formatieren und bis auf einen alle Sektoren wieder lesen. Allerdings musste ich mein Timing noch etwas korrigieren und die Pulse um ein paar Prozent kürzer machen, weil ich sonst mehr als eine Umdrehung brauchte und mit dem letzten Sektor den Anfang des ersten überschrieben habe.


    Nächste Aufgabe: Schreiben einzelner Sektoren - dort muss ich genau den vorbereiteten Bereich treffen und die Daten so schreiben, dass davor und dahinter nichts zerstört wird.

    Ok, da braucht man sich um die Treiber keine Sorgen zu machen. Trotzdem sehen die Schreibsignale etwas grenzwertig aus.


    Hier die Oszillogramme von den Schreib- und Lesesignalen:



    Beim Schreiben habe ich einen Hub von nur 2,7V, vor allem aber einen Low-Pegel von 400mv - das ist schon arg eng, oder?


    Zum Vergleich die korrespondierenden Signale an der Leseleitung:



    Wie man auch sieht, habe ich die 1000ns mit meinem Timing fast genau getroffen; hier sind es 1020ns. An anderer Stelle können es auch mal ein paar Nanosekunden mehr oder weniger sein. Auch beim Lesen haben wir eine Abweichung, die aber ebenfalls leicht variiert.


    Ich hatte tatsächlich auch schon den Verdacht gehabt, dass ich z.B. Pulse mit 1020ns und die Platte in einem festen Raster von z.B. 1040ns schreibt. Dann hätten wir tatsächlich nach einiger Zeit einen so großen Versatz, dass ein Puls verloren geht - u.U. auch mit einer entstehenden Lücke.

    Um das auszuschließen habe ich dann mal bewusst längere Pulse (1050 oder 1100 Nanosekunden) geschrieben - und die Aufzeichnungen auf der Platte wurden dann entsprechend länger. Die oben gezeigten Unterschiede entstehen also eher durch Messungenauigkeiten oder Gleichlaufschwankungen.


    Auf den Verdacht bin ich übrigens gekommen, weil die Platte grundsätzlich - d.h. völlig unabhängig von der Länge des negativen Impulses beim Schreiben - den negativen Impuls immer mit einer Länge von genau 200ns liefert. Da dachte ich, dass vielleicht auch die positiven Impulse über entsprechende Zeitglieder produziert werden. Das ist aber wohl nicht der Fall.

    Hi PAW,


    Ja, die Schreibdaten habe ich mir auch angesehen, die waren OK. Also im Sinne der Vollständigkeit.

    Die Pegel waren etwas schwach (3,xxV) und die Flanken nicht die Schönsten, aber meineserachtens in Ordnung.

    Ich hatte auch schon den Verdacht, dass die Pullups in der Platte etwas zu "rustikal" für die Treiber des FLUXCOPY sein könnten, aber dann müsste das genau auf der Grenze des korrekten liegen, weil ja 99% der Pulse richtig geschrieben werden.


    Mit den Pulsdauern habe ich einiges ausprobiert. Ich habe mit den 200ns angefangen, die ich auch beim Lesen erhalte. Dann habe ich es auch mal mit 50% probiert, und die dritte Variante war 250ns, weil das besser in das Zeitraster passt.

    Ich habe auch mit größeren Abständen experimentiert, also 1250 oder 1500ns. Dabei waren die "Verluste" aber noch viel höher. Die Impulslängen scheinen also in der Plattenelektronik eingebaut zu sein. Genau wie die 200ns - die liefert die Platte immer, egal wie ich geschrieben habe.


    Die besten Ergebnisse habe ich tatsächlich mit den Kombinationen 200ns/300ns, 200ns/550ns und 200ns/800ns.

    Mal ein paar blöde Ideen:

    Ist die Datenmenge/Drehzahl von der Spur abhängig?

    Drehzahl auf keinen Fall, die ist konstant.

    Datenmenge/Datenrate grundsätzlich auch nicht - es sind immer 60 Sektoren, aber tatsächlich hatte ich auf der innersten Spur eine etwas andere Formatierung mit minimalen Änderungen im Verhältnis Nutzdaten zu Synchronisationsdaten.

    Aber das ist quasi eine Schicht höher - meine Fehler liegen in ausbleibenden / überflüssigen Fluxwechseln.


    Gibt es vielleicht Zwischenspuren, die für Positionsdaten und nicht für Daten sind?

    Schreibst du vielleicht in den Nicht-Benutzerbereich?

    So etwas kennt diese Platte nicht. Jedenfalls waren die beiden Spuren, die ich bisher zum Testen genommen habe, vorher normal formatiert und enthielten z. T. auch normale Daten/Programmcode.

    Da war doch was mit einem Pre-Comp beim Schreiben?

    Hatten manche Datenträger nicht eine abweichende SChreib-/Leseposition (irgendwie in die Richtung es wird XXxs vorher geschrieben.

    Ja, da habe ich mir auch Gedanken drüber gemacht. Aber erstens spielt das in der Regel nur bei den inneren Spuren eine Rolle - außen sollte das kein Thema sein. Und ich teste absichtlich auf einer Spur ganz außen und einer ganz innen. Das Problem tritt in beiden Fällen auf.


    Außerdem wird die write precompensation nach meinem Verständnis nur bei speziellen Bitkombinationen benötigt, um zwei dicht aufeinander folgende Fluxwechsel zu entzerren - mal wird dazu etwas früher geschrieben, mal etwas später.


    Bei meinen Versuchen habe ich aber einfach nur in festem Abstand Fluxwechsel geschrieben. Dabei gingen hin und wieder einfach Fluxwechsel verloren - egal ob ich die im Abstand von 500ns oder 1000ns geschrieben habe.


    Ich habe den Verdacht, dass die Schreibverstärker nicht ausreichend starke Signale erzeugen und das entstandene schwache Signal beim Lesen nicht reicht, um bei der folgenden Digitalisierung wieder ein Ausgangssignal zu liefern.


    Georg

    Hier mal wieder ein Update zu meinen Forschungsarbeiten an der Platte.


    Mittlerweile kann ich große Bereiche der Platte lesen. Dabei muss ich aber gelegentlich meine Parameter anpassen, um fehlerfreie Ergebnisse zu erzielen. Manchmal klappt das garnicht, und es bleibt bei CRC-Fehlern im Datenbereich des Sektors.

    Dazu kommt der Eindruck, dass verschiedene Teile der Platte unterschiedlich formatiert sind. Insgesamt sehr seltsam.


    Mittlerweile habe ich auch versucht, die Platte zu beschreiben. Leider habe ich da wenig Erfolg - auf der Platte landet nie genau das, was ich schreibe.


    Ich habe das dann systematisch mit wechselndem Timing und Pulsbreiten durchgetestet und dabei festgestellt, dass im Schnitt alle 120-150 Fluxwechsel einer oder mehrere davon verloren gehen. Das passiert ziemlich sicher beim Schreiben, denn mit dem Oszilloskop kann ich diese Fehler bei wiederholten Lesen jedesmal wiederfinden. Gelegentlich wird an dieser Stelle aber auch eine Folge zu schneller Fluxwechsel gelesen.


    Es wird also irgendetwas geschrieben, das beim Lesen mal mehrere schnelle Fluxwechsel und mal gar keinen Wechsel liefert.


    Trotz aller Bemühungen konnten diese Fehler nicht reduziert werden, weshalb ich jetzt nicht mehr richtig weiter weiß...


    Ein sinnvolles beschreiben der Platte ist jedenfalls aktuell nicht möglich!

    Mit meinen GNT kann ich ziemlich sicher jeden ASCII - Code stanzen. Ich kann leider gerade nicht sagen, welches Modell ich habe (4604?). Aber ich bin sicher, dass ich schon mal Streifen mit allen 256 Zeichen erstellt habe.


    Problematisch könnte das PC-Programm sein - wenn es z. B. 0x0d automatisch um 0x0a ergänzt.

    Genau so sieht es aus: Kein Platz für nichts, und dazu der Verdacht, dass das keine Dauerlösung ist.


    Ich werden mal Arnos Meinung abwarten, wie er es mit der Originalität seines Genies halten will - sonst kommen zumindest an den kritischen Stellen neue Sockel rein.

    Hoffentlich bekomme ich die ganzen Erweiterungen mit ihrem Drahtverhau nachher wieder richtig zusammen.

    Tja, genau die Sorge habe ich.


    Jetzt weiß ich nicht, wieviel Sinn es hat, in den Sockeln die Federn wieder "auf Spannung" zu biegen - wenn sowas überhaupt geht. Oder den Aufwand treiben und alle Sockel tauschen? Denn im Video-RAM zeigen sich auch lustige Phänomene, die am ehesten durch Kontaktprobleme zu erklären sind.

    Ja, ich erinnere mich auch an den Genie 16. Meines Wissens nach wurde der untere Teil als Genie 16A verkauft - ein 8086 ohne Laufwerke und damit ohne DOS. Möglicherweise hatte der auch noch ein BASIC im ROM, wie der originale PC? Denn sonst kann man ja garnix damit anfangen.


    Die große Box darüber mit vermutlich Controller und Laufwerken machte den dann erst zum DOS-Rechner Genie 16B - aber leider nicht IBM-kompatibel.


    Ein Kumpel bekam den damals von seinen Eltern - was habe ich den beneidet! Dabei war das nach meiner Erinnering eher ein klappriges Ding mit Schlabbergehäuse. Viel gemacht hat er damals mit dem Ding übrigens nicht. Zum Spielen taugte er nicht ...

    Kleines Update:


    Mit Hilfe meines Testprogramms habe ich tatsächlich drei RAMs identifiziert, die offenbar defekt sind.


    Nach dem Austausch ist zwar mein RAM-Test zufrieden, aber richtig laufen will der Rechner noch nicht. Mindestens im VideoRAM stimmt noch etwas nicht, und außerdem habe ich die luschigen Sockel (einseitige Federkontakte) im Verdacht, Blödsinn zu machen.


    funkenzupfer, hast Du die bei dir dringelassen oder ausgetauscht?

    Für mich sieht es jedenfalls so aus, dass im Video-RAM die normalen ASCII-Zeichen stehen (statt irgendwelcher Zeichencodes).

    Nur zur Info, falls jemand Details braucht.


    Das originale VideoRAM (auf jeden Fall der Genie I) hat kein Bit 6. D.h. das A (0x41) wir als 0x01gespeichert. Das Character ROM war auchgenauso ausgelegt.

    Damit es beim Lesen wieder nach ASCII aussah, gibt es ein Gatter fuer Bit 6, welches die 0x01 wieder zu einer 0x41 macht.

    D.h. für mich ist das transparent? Ich schreibe 0x41, lese 0x41 zurück, aber im RAM steht 0x01?

    Ist natürlich wichtig zu wissen, wenn ich dann wirklich Ausgaben auf dem Bildschirm machen will.


    Wenn ich einen oder erst recht mehrere Genies hätte oder ernsthaft in den Genie-Service einsteigen wollte, könnte ich mich evtl. für Deinen Vorschlag erwärmen.

    Dann wird's aber mal Zeit. :)

    Nein, sorry, weder das eine noch das andere. Für das erste fehlt mir der Platz, und für das zweite die Zeit.


    Sollte ich Sehnsucht nach einem Genie haben weiß ich ja, wo ich mir ein paar ansehen kann. ::heilig::

    Klar, aufwendiger als ein "einfaches" Test-ROM, aber deutlich universeller und ohne das Öffnen des Gehäuses einsatzbar.


    Nur mal als Diskussionsgrundlage.

    Hi funkenzupfer,


    Danke für die Anregungen. Wenn ich einen oder erst recht mehrere Genies hätte oder ernsthaft in den Genie-Service einsteigen wollte, könnte ich mich evtl. für Deinen Vorschlag erwärmen.


    Aber so ist mir das zu viel Aufwand. ;)


    Ich habe mir inzwischen einen Adapter gebaut. Bei den ROMs handelt es sich um 9332 von General Instrument. Die haben zwei CS-Eingänge auf den Pins 20 und 21, deren Logik anscheinend ebenfalls kundenspezifisch programmiert werden kann.



    In unserem Fall sind beide Eingänge active low und im Genie sogar zusammengeschaltet. Passt recht gut zum 2732. Ich musste jetzt nur noch die Pins 18 und 21 vertauschen.


    Zunächst habe ich jetzt mal eine kleine Testroutine reingeschrieben, die den Bildschirm in einer Schleife mit allen Zeichen von 0 bis 255 füllt:

    Das funktioniert ganz gut. Geht natürlich zu schnell, um Genaueres zu erkennen, aber man sieht schon, dass er den Zeichensatz durcharbeitet.


    Ich habe mich mit dem Aufbau des Video-RAMs noch nicht beschäftigt und habe das nur auf gut Glück probiert. Für mich sieht es jedenfalls so aus, dass im Video-RAM die normalen ASCII-Zeichen stehen (statt irgendwelcher Zeichencodes). Wo eine Zeile beginnt und endet weiß ich auch noch nicht, aber das war für den Test auch völlig egal.


    Soweit also ganz gut. Zumindest habe ich jetzt die Möglichkeit, auf dem Bildschirm die Ergebnisse auszugeben, wenn ich den RAM-Test schreibe.

    Scouter3D:

    Ich wüsste auf Anhieb keine vernünftige Quelle oder Literatur. Aber vielleicht lohnt sich ein separater Thread für solche Fragen und Antworten. Vielleicht finde ich mal etwas Zeit dafür. Oder ein anderer springt da mal ein?

    Den RCT habe ich natürlich mit großem Interesse verfolgt, bin aber bisher zu der Erkenntnis gekommen, dass sich der für mich nicht lohnt.


    schufti:

    Richtig, grundsätzlich ist das eine einfache Sache. Allerdings sind die ROMs eben nicht kompatibel zu 2732, sondern zu den 2532, und sowas habe ich hier nicht und bin auch nicht sicher, ob ich sie programmieren könnte. Also Adapter...


    Aber grundsätzlich reizt mich der Ansatz schon. Wenn's nämlich an einem RAM liegt komme ich mit meiner Methode schnell an Grenzen. Das Genie (wie auch der TRS 80) nutzt viele Sprungtabellen im RAM, die dann bei etlichen Funktionen verwendet werden.

    Danke für die Tipps.


    Scouter3D: der zweite Kanal ist eminent wichtig - und manchmal kann auch ein externer Trigger sehr hilfreich sein und fast einen dritten Kanal ersetzen.

    Beides setze ich aber erst ein, wenn ich schon einen konkreten Verdacht habe. Und soweit bin ich noch nicht.

    Wenn ich einen vernünftigen Tester für die RAMs hätte, wäre das eine Überlegung wert; ein reihenweises Tauschen auf Verdacht ist aber nicht so mein Ding.

    Da würde ich eher die Variante von schufti nehmen und einen mehr oder weniger gründlichen RAM-Test in ein EPROM programmieren.

    Allerdings fürchte ich, dass ich da noch einen Adapter bauen muss, weil die unteren Adressen in einem ROM liegen.


    Ich werde das auf jeden Fall mal prüfen.


    Die Sache mit dem Rückbau zum Original klingt vernünftig, ist mir aber momentan noch etwas zu knifflig. Aber auch das kann sich noch ändern.


    Insgesamt fürchte ich aber, dass ich es bis Arnos Abreise nicht hinbekomme. Wir haben uns Inzwischen drauf geeinigt, dass der Rechner bis zu seinem nächsten Heimatbesuch bei mir bleibt - so habe ich noch etwas mehr Zeit.

    Kurzer Zwischenstand vom Wochenende:


    Ich habe den Logikanalysator an den Z80 angeschlossen (Adressbus sowie /M1, /MREQ, /RD, /WR), um der CPU beim Boot bzw. NMI zuzuschauen.

    Ich denke, das läuft ziemlich gut, jedenfalls arbeitet sie die Befehle ab, die zu erwarten sind. Leider werden bei der Initialisierung des Systems viele Schleifen verwendet, um Speicherbereich zu löschen oder zu verschieben. Da kommen dann schon ein paar Tausend Speicherzugriffe zusammen, bevor wieder etwas interessantes passiert. Da bin ich immer noch dran.


    Ich habe bisher nur eine Stelle gefunden, wo die Abfolge nicht wie erwartet war, und das war nicht reproduzierbar.


    Fortsetzung folgt...

    Danke an fritzeflink und funkenzupfer für die schnellen Antworten.


    Die Erweiterungen (Aufsteckplatinen) sind wie hier:

    Prima! Das scheint damals ja dann doch recht verbreitet gewesen zu sein. Bei Bedarf werde ich gerne auf die ROM-Inhalte zugreifen.

    Oder ist meine Analyse doch falsch?

    Passt alles. :thumbup:

    Du kannst ja mal einen Pullup an D0 machen, dann siehst du ja ob die 1,2V an D0 durch ein nicht getriebenes Signal kommt.

    Stimmt! Danke für den Zugriff auf Deinen Erfahrungsschatz :thumbup:

    Der mit RESET beschriftete Knopf loest einen NMI aus.

    Ok, dass muss man dann anders checken. Aber vielleicht sind die NMI Interrupts ja disabled ... 8o


    Schmakerl? Na ja. ;) Eher backen und braten.

    Hat jemand den Dachrinnenloetkolben gesehen? :)


    Kannst du mal schauen, was fuer IC das zusaetzliche ist.

    Wo gehen denn die 2 Leitungen nach links weg? In der Uebersicht sieht man das nicht.

    Hmm, hätte ich da irgendwelche Ironie-Tags setzen müssen? Ich dachte, das war ziemlich deutlich. Und Arno ist das vermutlich auch etwas peinlich, dass ich hier seine Jugendsünden präsentiere. :)


    Wie in den Unterlagen von Fritz zum Thema Snow Shovel zu lesen ist, gehen die Kabel zu einem Umschalter an der Rückseite. Das dritte Kabel geht an Pin 15 von einem 74LS175 unterhalb der Tastatur (Z3 laut Fritz' Doku).


    Video Schnee entfernen

    ....


    Super! Passt exakt. Sieht halt in der Beschreibung deutlich ordentlicher aus als im vorliegenden Fall.


    Momentan habe ich den Rechner wieder beiseite gestellt, weil morgen normale Erwerbsarbeit angesagt ist. Ich denke aber, dass ich in den nächsten Tagen mal meinen LA anschließe um zu sehen, bei welchen Adressen sich der Z80 rumtreibt.


    Achja - und den Trick von funkenzupfer mit dem Pullup probiere ich natürlich auch mal aus...

    Hier sind die gewünschten Bilder und auch ein paar Fragen.


    Überblick über die Boards:



    Es folgt die ROM-Erweiterung. Sie ist kopfüber eingebaut, deshalb einmal im eingebauten Zustand und einmal mit der Bestückungsseite nach oben:


              


    Auf der anderen Seite findet sich meiner Meinung nach der Zeichengenerator. Auch der steckt kopfüber:


            


    Da sich neben dem EPROM auch zwei statische RAMs dort finden denke ich, dass damit irgendwie ein ladbarer Zeichensatz realisiert wurde.


    Hier noch ein Schmankerl mitten auf der Platine. Soweit Arno sich erinnern konnte hatte das mit dem priorisierten Zugriff der CPU auf den Videospeicher zu tun, der zu Störungen im Bild führen konnte (ich nehme an, ähnlich wie der Schnee bei den frühen CGA-Grafikkarten). Diese Schaltung drehte diese Priorisierung angeblich um.




    Jetzt zu meinen ersten Beobachtungen. Ich hatte ja bei unseren ersten Versuchen mit dem Oszilloskop ungültige TTL-Pegel von ca. 1,2V gefunden. Das sieht dann etwa so aus (gelb: D0, blau: /MREQ):



    Um sicher zu gehen, dass wir wirklich nur Speicherzugriffe haben habe ich auch mal /IORQ gemessen, konnte dort aber keinerlei Aktivität erkennen.


    Als nächstes habe ich /RD und /WR zusammen mit D0 vermessen, um zu klären, ob dieser Effekt bei Lese- oder bei Schreibzugriffen passiert:


    Read:


    Wie man sieht, ist /RW immer inaktiv, wenn die ungültigen Pegel erscheinen.

    Das gleiche gilt aber auch für Schreibzugriffe: Auch hier erscheinen die 1,2V-Pegel nur bei inaktivem /WR:



    Zum Schluss habe ich noch D0 mit /Refresh gemessen, und da sieht man deutlich den Zusammenhang:



    Immer, wenn /Refresh aktiv wird, steigt der Pegel an der Datenleitung auf den ungültigen Wert und bleibt dort, bis nach dem Refresh-Zyklus ein echter Speicher-Zugriff passiert.

    Das hat mich zunächst etwas irritiert, aber vermutlich ist das korrekt, denn zum Refresh-Zyklus sagt das Z80-Handbuch, dass zwar /MREQ aktiv wird, aber /RD inaktiv bleibt um zu verhindern, dass der Datenbus von verschiedenen Quellen gleichzeitig beschrieben wird. Es gibt also in dem Zyklus kein eindeutiges Signal auf dem Datenbus und damit diese unsinnigen Werte.

    Wie gesagt, ich schaue nicht so oft einem Z80 bei der Arbeit zu, deshalb hatte ich sowas nicht auf dem Schirm. Oder ist meine Analyse doch falsch?


    Die regelmäßigen, langsam schwingenden Pulse auf den hohen Adressleitungen, die ich - vermutlich fälschlicherweise - mit dem Refresh in Verbindung gebracht habe, habe ich heute übrigens nicht mehr messen können. Jetzt finden sich da unregelmäßige Pulse von 1-2us im Abstand von etwa 8 bis 16us.


    Was ich noch gefunden habe: Der Reset-Button ist offenbar wirkungslos. Jedenfalls hat er keine Auswirkung auf den /Reset-Pin. Ein manuelles Auslösen (/Reset kurzzeitig auf GND) zeigt aber deutliche Auswirkungen auf z.B. die Adressleitungen; leider ändert sich am Bildschirminhalt nichts :(