Posts by Georg

Sorry, dass ich das Thema jetzt erst aufgreife, aber damals ging es gerade nicht. Interessiert mich aber sehr, weil ich dieses Phänomen leider selber auch habe.

An einer Wang PCS-2 war es nur ein "Nebenschaden", denn dort war der Hals der Röhre gebrochen, und sie musste sowieso ersetzt werden. Aber ich habe noch ein Terminal von Wang, das ähnliche Erscheinungen hat - irgendwie gammelt dieses Zeugs zwischen den beiden Glasscheiben.

Bei befreundeten Sammlern habe ich auch schon solche Bildschirme gesehen (es sind meistens Rechner/Terminals aus den 70er Jahren, danach hat man sowas offenbar nicht mehr gemacht). Ich habe aber noch keine Reinigungsaktion in Bildern gesehen wie hier - schönen Dank dafür.

Da ich früher oder später auch dran muss interessiert mich natürlich, ob es sonst noch Komplikationen gab. Mir wurde einmal erzählt, das Zeug stinkt zu Himmel(?). Und dann ist natürlich die Frage, ob die Röhre anschließend irgendwie empfindlicher ist. Denn die Funktion dieser "Doppelverglasung" ist mir nicht ganz klar: Geht es da um optische Effekte (Entspiegelung, Entzerrung oder ähnlich), oder dient es doch irgendwie dem Schutz der Bildröhre?

Die Probleme, die andere mit trockenen Elkos haben, habe ich offenbar nur mit den MP-Filter-Kondensatoren in den Astec-Netzteilen (Osborne, Tandy)

Heute ist mir wieder einer ziemlich eindrucksvoll um die Ohren geflogen. Zugegeben, der Rechner hatte vorher ein paar Jahre gestanden; zwei Minuten nach dem Einschalten hat's dann jedenfalls heftig geknallt, gebrutzelt, gestunken - freundlicherweise ist der Rechner weitergelaufen, aber das habe ich kaum noch mitbekommen, weil ich natürlich reflexartig abgeschaltet habe.

Mittlerweile ist gelüftet, die Leiche ausgelötet (siehe Anhang), und der Rechner läuft wieder. Leider habe ich keinen exakten Ersatz - ich weiß nur, dass diese Kondensatoren für den Betrieb natürlich nicht nötig sind.

Deshalb meine Frage an die analogen Experten hier:

Wie kritisch sind die Werte für diese Kondensatoren? Mir geht es speziell um den Kondensator, der zwischen Drossel und Gleichrichter parallel zur Eingangsspannung liegt (im angehängten Schaltbild C32). Bei (fast?) allen Astec-Netzteilen, die ich bisher in der Hand hatte, war das ein 0,1uF Kondensator - unabhängig von der Leistung des Netzteils.

Ich habe von diesen speziell geschützten Typen (X2) nur welche mit 0,22uF da. Damit laufen die Netzteile genauso wie komplett ohne . Aber was ist (im Sinne der urspünglichen Störunterdrückuing) besser? Laut den Original-Unterlagen wird an dieser Stelle in den amerikanischen 115V-Versionen (50/60Hz) auch ein 0,22uF Typ verwendet, während die anderen Werte (C30, C31=4700pF, C33=0,01uF) identisch mit den Werten von den deutschen Netzteilen sind.

Ach ja, die Astec-Netzteile, die hier in D eingesetzt wurden, können von 115V auf 230V umgebaut werden. Die Filterschaltung liegt aber, soweit ich das gesehen habe, vor dieser Stelle, so dass die Dimensionierung der Kondensatoren wohl eher wenig mit der Eingangsspannung zu tun hat.

Hi Andreas,

herzliche Glückwünsche! Tolles Ergebnis, und jetzt zum Schluss ging es ja auch erstaunlich flott voran. Sorry, dass ich nicht mehr viel beitragen konnte; mir fehlte die Zeit und auch ein bisschen die Ideen.

Die Sache mit dem ROM würde ich auch über zwei 2732er angehen - da bin ich schon auf Seite 2 drüber gestolpert, dass Du da den Aufwand mit dem Adapter überhaupt getrieben hast.

Und das Sockeln aller RAMs - Respekt! Echte Fleißarbeit. Aber auch ein Investition in die Zukunft, denn so ein RAM kann ja immer mal wieder ausfallen.

Dann viel Spaß noch mit der Maschine.

Gruß
Georg

PS. Ich bin neidisch. Das Logo auf dem Bootscreen des Sirius 1 sieht viel schöner aus als das auf der Vicki

Kann ich nicht ganz glauben. Rechts sind relativ sicher 32 x 4164 zu erkennen, das sind 256 KB. Links dürfte das gleiche sein (kann ich nicht so gut erkennen).
Die Doku signalisiert auch, dass die Karte in der Regel 512 KB hat.
Bist Du sicher, dass Du alle Schalter richtig gesetzt hast?

Quote from hexagon

Ich hab meinen Schaltplan durchsucht (den von http://www.actsirius1.co.uk/, aber da ist der Prozessor gar nicht drauf? Ok, ein Pinout für die 8088 finde ich, aber habt ihr vollständige Pläne für die Maschine? Bin irgentwie gerade verwundert...

Das Problem habe ich ja auch schon gehabt Die Video-Logik ist auch nicht dabei - nur der analoge Teil. Im Wesentlichen geht es dort um die Speicherkarten und die Floppylogik.

Quote from achimhb

Soeben sah ich auch, dass Du aus Bergisch Gladbach kommst. Ich komme aus Euskirchen, also die A61 hoch und fertig.
Abholung wäre damit möglich. Dann ist das Gewicht auch egal.

Das steigert meine Motivation erheblich. Nach Deinem Profil hätte ich Dich irgendwo bei Eisenach gesucht - und da habe ich wenig Hoffnung gehabt, dass wir das mit dem Transport geregelt bekommen. Aber so ist das kein Problem.

Quote from achimhb

PS: "IBM Ecke" klingt grandios. Vielleicht gibt es noch mehr, was "übrig" ist.

"Übrig" ist bei mir eher selten
Und IBM-Ecke ist vielleicht was übertrieben - PC-Ecke passt besser. Ich habe das eher gesagt, weil ich dort auch noch seit 2 Monaten für Klaus nach einem IBM AT schauen will.
IBM5100 o.ä. habe ich jedenfalls nicht

Aber ich werde trotzdem mal die Augen aufmachen - Du warst doch auch an Festplatten und Cartridges interessiert.

Quote from sirius1victor9000

Wenn es hilft, kann ich auch den kommentierten Original-Source Code vom 3.6 Universal Boot-ROM zur Verfügung stellen.

Prima, das habe ich mir sofort mal angesehen und auf Anhieb einiges wieder erkannt. Mit Kommentaren wird auch manches klar, wo ich vorher nur gerätselt habe ...

Aber am Ende kommt dann der Brüller schlechthin:

pcflag	dw	0FFFFh;		flag that we are IBM PC compatible

(VCKINIT.ASM, Zeile 526)

Da haben wir aber alle mal herzlich gelacht

Außer dem Drucker war alles dabei. Ich hoffe, dass ich auch alles wieder finde.

Lass mich erst mal danach schauen. Das kann aber eine Weile dauern, das liegt alles ziemlich unzugänglich und ich bin zeitlich arg eingeschränkt. Aber immerhin gibt es jetzt schon 2 Gründe, die IBM-Ecke zu durchforsten...

Versand wird allerdings schwierig. Einerseits glaube ich nicht, dass Du mit 10kg hinkommst (das schafft ja schon fast die Tastatur ), und andererseits ist da ein Monitor bei. Sowas versende ich normalerweise nicht - gibt nur Bruch. Und dafür ist's zu schade

Ich habe vor Jahren mal ein IBM-Gerät aus einer Firma vor dem E-Schrott gerettet, weil es so aussah wie ein Computer. Irgendwie bin ich aber nicht warm damit geworden - vielleicht, weil irgendwie alles textlastig war und ich das Betriebssystem nicht gefunden habe oder was auch immer ... ist lange, lange her.
Seitdem steht es tief versteckt im Lager. Zustand völlig unbekannt. Disketten waren mal dabei, aber ich kann nicht sagen, ob ich sie auf Anhieb finde. Und was vielleicht das größte Problem ist: Meinem Displaywriter fehlt der Writer - der Drucker war mir einfach zu groß und zu schwer (und ich dachte ja, ich hätte da einen Computer - wer braucht da einen Drucker?).

Wenn Du trotzdem interessiert bist, würde ich mal in die Ecke klettern und nach dem Schätzchen suchen.

Quote from hexagon

So, ich hab meinen Sirius wieder auf dem Tisch. Zustand unverändert. Nach dem Einschalten Lüftergeräusch, an beiden Diskettenlaufwerken brennt die rote LED.

Das ist der gleiche Zustand wie bei meinem (Vicki), als ich das Boot-ROM manipuliert habe. Die Boot-Sequenz setzt zunächst 2 oder 3 Variablen im RAM, initialisiert dann den Stackpointer, bringt den CRTC in eine stabile Grundposition (einfach nur Register 1 - Anzahl Zeichen pro Zeile - auf 0 setzen), und bildet anschließend die Prüfsumme über das ROM. Dort hatte ich meinen dann aus dem Tritt gebracht. (Dass ich dann nicht die erwartete Fehlermeldung 2, sondern 33 bzw. 0x21 gemessen habe, ist noch ein zu klärendes Phänomen )

Als nächstes habe ich den Eindruck, dass er nach ROM-Erweiterungen sucht, und wenn nichts gefunden wird, kommt jetzt der RAM-Test. Erst das Video-RAM, dann der Hauptspeicher. Der Test des Video-RAMs bedeutet: Das wird zuerst komplett mit einem Muster gefüllt, dann wird alles invertiert, und zum Schluss wird alles gelöscht.
Davon sieht man beim Einschalten vielleicht nichts, weil der Monitor noch nicht warm ist (oder hat der einen unabhängigen Einschalter?), aber wenn man den "laufenden" Rechner (ausnahmsweise ) mal aus- und sofort wieder einschaltet, sollte man den Effekt erkennen. (Reset reicht nicht, der springt meiner Meinung nach nicht in diese Prüfroutinen).

Wenn Du also diesen Test machst, und der Monitor bringt keine Regung, gibt's eigentlich nur zwei Möglichkeiten: Die CPU tut überhaupt nichts von dem, was sie soll, oder das ROM ist nicht ok.

Wenn der Bildschirm aber kurz hell wird, weißt Du immerhin:
- Die CPU läuft und arbeitet ihr ROM ab
- das ROM ist in erster Näherung ok

So oder so würde ich als nächstes mal den Tastkopf reinhalten und prüfen, was sich so am Prozessor tut. Wenn beim Start grobe Fehler festgestellt werden, die nicht auf dem Bildschirm angezeigt werden können, rennt das ROM immer in eine extrem kurze Schleife, in der die Fehlernummer ausgegeben wird. Auch wenn wir die Interpretation der Fehlernummer noch nicht ganz im Griff haben , kann man mit der kurzen Schleife (ca. 5 us) ein schönes stehendes Signal erhalten - das ist eigentlich wunderbar charakteristisch.

Irgendwo in den Unterlagen hatte ich auch mal ein Auflistung der Fehlercode gefunden - muss ich noch mal suchen

So, jetzt habe ich gerade auch den neuen Beitrag von s19v gesehen - soweit stimmen unsere Überlegungen wohl überein - nur die leuchtenden Disketten-LED haben meiner Erfahrung nach nichts zu bedeuten, denn die haben bei mir auch geleuchtet, als ich den ROM-Fehler eingebaut habe. Und das ist weit vor jeder Initlialisierung der 6522-Bausteine.

Ach ja, noch was: Ganz am Anfang hatte ich nach dem ersten Auseinanderschrauben und Zusammenbauen auch den Effekt, dass nichts ging und nur die LEDs leuchteten. Ist beim nächsten Aufmachen von selber verschwunden und nie wieder aufgetreten. Ich habe den Verdacht, dass ich evtl. irgendwo einen losen Kontakt hatte; evtl. sogar an den Boards, die ich in der Folge dann ja mehrfach rausgezogen und wieder reingesteckt habe.
Vielleicht sollte man wirklich auch einfach mal die Steckverbindungen unter die Lupe nehmen.

Grundsätzlich würde ich aber eher die systematische Vorgehensweise wählen

Edit: Habe gerade den letzten Beitrag genauer gelesen: Die Ausgabe des Fehlercodes ist dann bei Deinem Rechner eher weniger zu erwarten - nichtsdestotrotz würde die kurze Schleife (in dem Fall noch kürzer) ein eindeutiges Signal abgeben, dass der Prozessor läuft und sein ROM ordnungsgemäß abarbeitet. Dann muss man halt die aktuelle Adresse ablesen - s1v9 dürfte dann relativ schnell mit der Fehlerquelle zur Hand sein - wenn es sich denn so darstellt ...

Gruß
Georg

Hallo s1v9,

Quote from sirius1victor9000

erstmal herzlichen Glückwunsch zum wiederbelebten Vicki. Leider bin ich erst kürzlich (zu spät) auf dieses Forum gestoßen, ansonsten hätte ich bei dem ein oder anderen Rätsel sicher helfen können.

Ja, nachdem ich Deinen Beitrag durchgelesen habe (ich habe wirklich bis zum Ende durchgehalten ) denke ich das auch. Eine Menge der Fragen, die uns in den letzten Tagen beschäftigt haben, kannst Du offensichtlich so aus dem Handgelenk beantworten. Zusätzlich stand aber auch noch eine Menge weitere Informationen drin, z.B. zum Thema Grafik (mit der wir uns angesichts der Problematik nur am Rande beschäftigt haben) und insbesondere zu den Besonderheiten der Speicherorganisation.

Eine Ergänzung möchte ich aber noch machen - zumindest habe ich das aus den Referenzen so rausgelesen: Die "Pixeldarstellungen" können nicht nur in den unteren 64 KB untergebracht werden, sondern wohl auch im nächsten 64KB Block. Die gesamten ersten 128 KB sind als dual ported RAM (Du nennst es shared memory) ausgelegt.
Die Auswahl der Bank erfolgt über ein freies Adressbit des 6845 (MA12). Der benötigte Speicherbereich darf allerdings die 64KB-Grenze zwischen Bank1 und Bank 2 nicht überschreiten.

Deine Ausführungen zur Grafik sind sehr interessant; ich hatte bisher nur vage Vorstellungen davon. Allerdings sehe ich bei mir in absehbarer Zukunft auch nicht die nötige Freizeit, mich intensiver mit diesem Thema beschäftigen zu können. Eher interessieren mich die Themen, die Du in dem anderen Thread zum Datenaustausch angesprochen hast => PN.

Was mich allerdings noch beschäftigt (ich könnte es mit dem lauffähigen Gerät vermutlich rausbekommen, aber ich schätze, Du kennst die Antwort schon): Wie machen die das mit dem 132-Zeichen Modus? Dafür wird ein eigener Zeichensatz geladen, und angesichts der Strukturen wäre es eigentlich sinnvoll, den CRTC entsprechend auf 50 Zeilen á 132 Zeichen zu programmieren - aber dann bräuchten wir 50*132=6600 Vektoren im Videospeicher - der fasst aber nur 2048 Worte. Ich kann mir also nur vorstellen, dass dieser Modus im Grafikmodus läuft - dann frage ich mich nur, warum der Zeichensatz (den das System natürlich immer noch benötigt), immer noch in dem platzraubenden 16*16-Raster abgelegt wird (benötigt werden pro Zeichen 8*6 Pixel). Weißt Du mehr?

Quote from sirius1victor9000

Ich habe selbst 2 Vicki, von denen einer nicht mehr bootet. Leider bin ich eher ein Experte für Systemprogrammierung und weniger was Hardware-Reparaturen angeht. Im Moment ist auch die Zeit recht knapp bemessen. Vielleicht kann mich ja zukünftig jemand aus dem Darmstädter Raum bei der Wiederbelebung unterstützen.

Du kannst es natürlich versuchen wie ich - mit Fernunterstützung hier durch das Forum. Das größte Problem dabei könnte der Zeitbedarf sein.
Den "klassischen Fehler" laut Home of the ACT ... hast Du schon geprüft? Scheint eher was für Maschinen zu sein, die intensiv genutzt wurden - könnte also bei Dir passen . Allerdings hatte ich damals (tm), als ich die Vicki bekam, ja auch zunächst ein ganz anderes Problem, irgendwo im Netztteil ...

Gruß
Georg

So, wie angekündigt habe ich das mal probiert.

Also: Image eines der beiden Boot-ROMs im Hexeditor modifiziert (harmlose Stelle, an der Definition der Symbole fürs Disketteneinlegen) und ein neues Eprom gebrannt. Vicki wieder aufgeschraubt und das Eprom gegen das Original ausgetauscht.

Ergebnis: Vicki ist wieder mausetot - schlimmer als je zuvor. Aber das war ja so erwartet

Jetzt Oszilloskop angeschlossen: -WR (wie vorgeschlagen), darauf auch getriggert, und dann nacheinander die Datenleitungen abgehorcht. Funktioniert erstaunlich gut, so dicht am Prozessor in so einer kleinen Schleife bekommt man stabile und saubere Signale.

Leider passt das Gemessene aber nicht ganz mit der Theorie überein - statt des Musters 0000 0010 (bei Checksum-Fehler sollte der Code 2 kommen) habe ich 0010 0001 gelesen, also 0x21

Jetzt werde ich wieder Doku wühlen und das Boot-ROM weiter anaylsieren müssen, um rauszukriegen, was das nun soll, oder ob ich wieder was überlesen oder falsch interpretiert habe.

Im Anhang habe ich drei Bilder:

• Einmal vom Digitaloszilloskop mit den Datenleitungen D0 bis D2
• Nur -WR und D0 auf einem uralten Analoggerät, um zu zeigen, dass das auch ausreicht
• Und schließlich ein Blick mit dem LA - unten sind die 8 Datenleitungen, darüber die -WR-Leitung. Rechts sieht man das Datenwort bei aktiver Schreibleitung.

Fazit: Grundsätzlich scheint das zu funktionieren, aber irgendwo ist noch eine Wissenslücke oder ein Denkfehler

Nachtrag:
Gerade habe ich mir nochmal den Hinweis von dlchnr durchgelesen:

Quote from dlchnr

Eigentlich ist es am einfachsten, sowohl beim 8086, wie auch beim 8088, bei dieser Loop auf die steigende Flanke von /WR zu triggern

Steigende Flanke? Dann habe ich ja dauernd an die falsche Stelle geguckt Vielleicht haben wir da schon den Fehler. Zumindest auf dem ersten Bild passt auch alles - nach dem Anstieg von -WR wechseln die drei unteren Bits von 001 auf 010 - das gefällt.

Bei der Kontrolle der anderen Bits kommt dann aber die Ernüchterung: Insgesamt hätten wir dann 1110 1010 - passt also doch nicht.

Und jetzt mal im Ernst: das Schreibsignal -WR ist aktiv low, und die Datenleitungen enthalten das zu schreibende Wort, solange -WR aktiv, d.h. low ist. Also interessiert uns doch, was nach der fallenden Flanke auf dem Datenbus ansteht - oder habe ich wieder irgendwas vergessen?

Quote from H.Bothur

Dann mal viel Spaß damit

retro64 hat nicht nur das Turbo-Pascal (3.01 wenn ich mich nicht täusche) sondern meine komplette Entwicklungsumgebung. Dazu gehörte auch eine erweiterte Oberfläche, ein Formatter für Pascal-Source und ein Full-Screen-Maskeneditor/Generator.

Mal sehen, ob mir für diese Fülle an Material die Zeit reicht. Aber interessant hört sich das schon an.

Quote from H.Bothur

Ich hätte das ja gerne alles nochmal getestet als ich die sachen abgegeben habe - aber leider bootete der Rechner nicht mehr sauber

Na dann - schließe Dich doch an! Andreas macht auch mit seihnem Victor weiter

Quote from H.Bothur

Übrigens ... ich hab da - neben anderen Spielen - auch ein StarTrek mit Sprachausgabe ... heute ganz normal, damals echt die Krönung !

Das kann ich mir gut vorstellen, aber ich fürchte, das ist einer der wenigen Punkte, wo die Vicki nicht mithalten kann. Der Victor hatte irgend so eine Einheit zur Sprachaufnahme/wiedergabe - das hat die Vicki afaik nicht.

Herrlich ^^

Schöne Beiträge zu einem eigentlich verrückten Thema, aber man sieht, dass es irgendwie tiefer geht.

Was mich aber wirklich interessiert ist die Frage, wie sich dieser gesellschaftliche (deutsche) Konsens bei der Geschlechtsbestimmung von Rechnertypen entwickelt. Denn das ist doch das lustige: Natürlich ist "der Computer" als Gattungsbegriff in vielen Fällen geschlechtsbestimmend; die weiblichen Varianten sind eher die Ausnahme, und die meisten der Ausnahmen hängen irgendwie mit dem Namen zusammen (Vicki, Lisa, oder auch Sun). Dabei bildet der Amiga dann die Ausnahme von der Ausnahme - man wundert sich schon wieder, dass sich da an die Regel gehalten wird.

Hauptsächlich wundert mich aber, dass sich alle in den weitaus meisten Fällen absolut einig sind über das Geschlecht. Bei einer so willkürlichen Einordnung hätte ich da mehr Chaos erwartet (wie bei dem Beispiel Laptop). Einzig bei der/dem Schneider Joyce habe ich den Eindruck, dass es beide Varianten gibt - liegt aber vielleicht auch an dem Doppelnamen (Joyce/PCW).

Noch eine Idee, warum viele Dickschiffe weiblich sind: Es gibt ja nicht nur die Kategorie "Computer", sondern auch noch "Maschine", "Anlage" oder "Workstation". Ist vielleicht auch ein Grund dafür, dass größere Rechner (was nicht unbedingt die räumliche Größe sein muss, eher sowas wie Leistung - siehe Indy/Sun vs. gleich großem PC) gerne weiblich sind. ist vielleicht auch der Grund, dass es *der* ENIAC und *die* Cray sind ....

Aber verdammt, es ist auch *die* Zuse Z1

Quote from dlchnr

See da eigentlich keine grosse Schwierigkeiten - mit einem Kanal auf M/IO (8086) bzw. IO/M (8088) triggern, und mit dem zweiten Kanal die Datenbits vom Bus fischen.

Stimmt, so sollte es möglich sein. Vielleicht probiere ich das heute Nachmittag direkt mal aus.

Quote from hexagon

Nachdem das in letzter Zeit so hier an Fahrt aufgenommen hat und doch ein paar hier sind die Victormäßig helfen können - ich bau die Kiste heute mittag wieder in der Werkstatt auf den Tisch und mach dran weiter. Ihr motiviert mich.

Erstes Etappenziel erreicht

Quote from dlchnr

Würde an Deiner Stelle da jetzt nicht aufhören und die erzielten Erkenntnisse und weitere Untersuchungen zumindest soweit fortführen, bis ein Blockschaltbilod für die Vicki gewonnen ist
(der Aufwand für ein Blockschaltbild sollte sich in Grenzen halten verglichen mit dem Aufwand, 'nen kompletten Schaltplan zu generieren)!

Da fehlt es mir leider an allem: Erfahrung, Ehrgeiz und Zeit.

Wie Du gemerkt hast, kann ich "sinnvolle" Zusammenhänge oft nicht erkennen, weil ich nicht die nötige Übung/Erfahrung/Praxis habe. Ich dilettiere ein bisschen bei der Suche nach Fehlern; ich habe noch nie so eine Architektur selber entworfen und weiß deshalb nicht, worauf es ankommt.

Meine Vorgehensweise folgt einer Art "Minimalprinzip" (auch wenn manche hier die Erfahrung haben, dass forsches Ausprobieren oft schneller zum Erfolg führt als meine nächtelangen Analysen ) - ich werde aktiv, wenn ich einen Fehler habe, und versuche dann das konkrete Umfeld zu analysieren und den Fehler zu lokalisieren. Was dabei an Informationen anfällt - prima, aber ich fange in der Regel nicht an, darüber hinaus zu forschen, wenn es für das aktuelle Problem nicht hilfreich ist. Wenn alles klappt, habe ich nach einer Weile Beobachten, Messen, Nachdenken und Ausprobieren dann den defekten Baustein isoliert und kann den gezielt austauschen. Klappt nicht immer, aber oft.

Und schließlich gibt es noch eine Menge anderer Rechner neben der Vicki. Und davon leider auch immer wieder welche mit Defekten. Die Wangs z.B. kommen hier durchweg kaputt an - von dem knappen Dutzend Maschinen haben höchstens zwei bei ihrem Eintreffen auf Anhieb gearbeitet. Und das Thema "Auslaufende Kondensatoren in den CBM-Floppys" macht mir auch schon Sorgen.

Von daher: Ich bin froh, dass die Vicki läuft, ich werde sie jetzt noch etwas von der Anwenderseite aus untersuchen (ist über 20Jahre her, dass ich zuletzt was mit ihr gemacht habe); ich werde prüfen, inwieweit ich mit ihrer Untertützung bei dem Victor von Andreas helfen kann - und dann kommt vermutlich schon wieder der nächste Patient dran.

Wobei die Schlepptops (Osborne, Kaypro, TRS-80 4p, Compaq Portable usw.) ja einen Riesenvorteil haben: Man kann sie jederzeit aus dem Regal holen und aktivieren - ohne einen passenden Bildschirm und Tastatur zu suchen, ohne großen Kabelverhau etc.

Sie hat also gute Chancen, immer mal wieder an die frische Luft zu kommen ....

Quote from H.Bothur

Glückwunsch !!! Software für den Victor - und damit auch für die Vicki - dürfte hier ja genügend im Umlauf sein.
In Berlin sind ja gerade zwei Boxen voll gelandet - mal sehen was ihr da an Schätzen habt

Danke, Hans.
Wenn ich das richtig verstanden habe, gab's dabei auch Turbo Pascal für den Victor - das fände ich prima, denn das war meine Sprache der Wahl. Erst unter CP/M und dann auch unter DOS. Käme auf der Vicki großartig. Ich versuche, am Ball zu bleiben, und kläre das mit retro64.

Nein, es geht nicht um die typischen Sub-D-Adapter - ich wollte nur mit dem Titel etwas in die Irre führen

Mir geht es um die Frage, welches Geschlecht unsere Computer haben. Blöde Frage? Ja, irgendwie schon. *Der* Computer ist natürlich männlich. Aber so einfach ist es nicht:

Fangen wir doch direkt mit einem sehr berühmten Beispiel an: Seymour Crays gleichnamige Computer (Cray-1, Cray-XMP) werden in aller Regel als Damen bezeichnet: "die Cray-1", "die Cray-XMP".
Und auch seine früheren Rechner von Control Data (CDC Cyber) trugen bei uns die Artikel "die".

Weiter gehts mit den Rechnern von DEC: Sowohl die PDPs als auch die Vaxen sind typischerweise weiblich. Warum? Auch wenn die PDP kein Computer, sondern ein "Processor" ist, müsste es eigentlich immer noch ein der sein.

Bei den kleineren Rechnern ist das anders. Da gibt's zwar die "richtigen" Mädchen wie die Lisa oder auch die Vicki, aber in der Regel sind die Home- und Personalcomputer männlich: von A wie Apple // über C wie C64 bis Z wie ZX81 ist irgendwie alles männlich. Allerdings - und jetzt wird es völlig verwirrend - ausgerechnet die Freundin ist dann wieder ein "Er": "der Amiga".

Auch der IBM PC ist ein Kerl, während seine richtig großen Geschwister wieder Mädchen sind: die /360 oder die AS400, um zwei bekannte Beispiele zu nennen.

Also eine Frage der Größe? Kleine Computer sind männlich, große sind weiblich?

Passt aber leider auch nicht - beim ENIAC sind wir wohl alle einig, dass *er* richtig groß war. Oder Colossus. Oder Deep Thought

Aufgekommen ist mir die Frage, weil meine Rechner von WANG für mich auch immer weiblich waren: Die Wang 2200B, die PCS, die VP etc.

Was ist also das Geheimnis???

Da ich ja jetzt den Kopf wieder frei habe für Dinge rechts und links, andererseits aber noch ganz gut im Thema Victor drin bin, wollte ich mal nachfragen, wie es denn mit dem Victor von Andreas inzwischen aussieht. Immer noch schüchtern und zurückhaltend?

Wie ich aus dem Boot-ROM herausgelesen und zwischenzeitlich auch in irgendeinem Handbuch bestätigt gefunden habe sendet der Victor beim Booten einen Fehlercode an Port 0xffff, wenn er den Bildschirm nicht mehr ansprechen kann. Den könne der Servicetechniker dann mit dem Oszilloskop an "geeigneter Stelle" abgreifen.

Das sieht dann z.B. so aus:

B004              mov al,0x4     ; Fehler 4
          BAFFFF            mov dx,0xffff
Loop:     EE                out dx,al
          EBFD              jmp short Loop

Leider schweigt sich das Handbuch darüber aus, wo und wie man den abgreift - auf den Datenleitungen selber ist vermutlich selbst bei dieser kurzen Schleife zuviel los, und ob die den Port dekodiert haben und irgendwo in Hardware diese 8 Bit eingebaut sind ist fraglich.

Wär' aber bei völlig totem Rechner einen Versuch wert.
Ich könnte das z.B. problemlos provozieren, indem ich ein unwesentliches Byte im Boot-ROM ändere - die Prüfroutine gibt dann den Fehlercode 2 aus.

So, ich bin wieder auf den Beinen. Danke für die Genesungswünsche (weiß nicht, ob es dadurch schneller ging, aber es hat gut getan) und auch für die Glückwünsche zur Reparatur. Ich bin heute Abend noch mal unten gewesen und habe die Vicki wieder zusammengebaut - und sie läuft immer noch

Vorher habe ich aber noch mal die Messspitzen reingehalten, um diese Frage endlich zu klären:

Quote from dlchnr

Ich hatte die obere Variante erwartet, da die mir besser ins Blockdiagramm der 9000 reinpasst

Deine Ferndiagnose war vollkommen korrekt - ich hatte mich wohl zu lange mit dem Bus jenseits des 245 beschäftigt und deshalb fest im Kopf, dass ich *alles* jenseits dieses Transceivers gefunden hatte. Tatsächlich hängen die Eingänge des 374 also doch direkt am SRAM. Sorry, dass ich das falsch geschrieben habe.

Quote from retro64

Das mit dem 132er tut mir leid, gelobe Besserung (genauere Beschreibungen).

Ist schon ok Was vermutlich zu selbstverständlich für Dich.
Apropos Software: Was für Disketten verwendest Du an der Maschine? "Moderne" HD-Disketten oder DD? Oder tatsächlich 4D-Disketten (die doch ziemlich selten sind)?[imgwidth][/imgwidth]

Quote from GolfSyncro

Kannst du das Binary mal hier Hochladen ist bei malinov auch weg...

Was habe ich mir denn da angesehen? Falsches Projekt?
Ich habe mir die Dateien tvga9000i (Version 3.51 bzw. 4.01) aus dem Projekt ISA Super VGA runtergeladen. War das falsch?

Das einzig Auffällige ist, das die beiden Teile eines 16-Bit-ROMs (even und odd) hintereinander in einem 8-bit-ROM abgelegt sind. D.h. erst kommen 16kb even und dann 16kb odd.
Aber da ich nichts von der Architektur weiß, hoffe ich mal, dass das so OK ist.

Also ich möchte mich ja jetzt nicht zu weit aus dem Fenster lehnen - ich kenne das Projekt gar nicht. Aber soweit ich das sehe sind das einfach Binärfiles - da kann prinzipiell nichts "böse" sein für den Eprommer. Außer die Datei wurde nicht vollständig runtergeladen und ist gerade dort zu Ende - dann würde ich aber keinen write-error erwarten.

Sicher, dass der Eprommer ok ist? Hast Du mal ein 256er Eprom mit anderen Daten gebrannt?

Quote from dlchnr

Ich hatte die obere Variante erwartet, da die mir besser ins Blockdiagramm der 9000 reinpasst.

Wenn ich wieder an die Vicki rankomme, werde ich das nochmal prüfen. Ich habe gerade noch mal einen Blick in meine Notizen geworfen - die sind an der Stelle aber nicht eindeutig. Das hat mich jetzt verunsichert

Leider kann ich im Moment aber nichts machen, weil mich eine Erkältung umgehauen hat - jetzt, wo es der Vicki besser geht, bin ich krank: Fehlfunktion von Hals und Lunge. Obere I/O-Kanäle verstopft. Nur noch halbe Rechenleistung. Trotz Runtertakten erhöhte Core-Temperatur.
Irgendeiner 'ne Idee?

Quote from dlchnr

Super, dass die Vicki wieder läuft
Trotzdem würde mich noch interessieren, welche Veriante meiner Bilds nun tatsächlich vorliegt - die obere oder untere?

Der defekte 374er lag definitiv an den "Ausgängen" oder besser gesagt an der "Gegenseite" des Transceivers (ist ja bidirektional). Also das untere Bild.

Quote from dlchnr

Wird überhaupt überprüft, ob in Deinem System 256kByte Hauptspeicher zur Verfügung stehen, oder könnte es sein, dass im System effektiv nur 64kByte vorhanden sind, weil zwei Adressbits klemmen?

Quote from dlchnr

Ob Du da nicht doch auf dem gemultiplexten Adress-/Datenbus des 8086 (Primärbus) gelandet bist und der gefundene 374er allein der RAS-/CAS-Adressgenerierung bei 8086-Zugriffen auf den Haupspeicher dient?

Du kannst einem ja Hoffnung machen Ich habe wirklich angefangen zu zweifeln

Naja, aber hin und wieder darf man dann doch mal Glück haben. Ich habe wie beabsichtigt mit dem Oszilloskop die Ein- und Ausgänge von den Flipflops verglichen (unter Berücksichtigung der Clock und -OE-Eingänge) und tatsächlich zwei Ausgänge gefunden, die bei aktivem -OE dauernd auf 1 gingen - obwohl der Dateneingang vorher eindeutig auf 0 lag (siehe Anhang).

Ich hab's dann riskiert, den 20-poligen Käfer rausgelötet und durch einen Sockel ersetzt, einen 74LS374 eingesetzt und -

Als "Beweis" habe ich ein Bild nach dem Booten - auch ohne mein Hilfsprogramm wird das Logo und alle Texte angezeigt. Und schließlich auch noch einen Eindruck vom 132-Zeichen-Modus - der auf dem kleinen eingebauten Bildschirm aber eher unangemessen ist.

Ich bin glücklich

So, jetzt sind ein paar Danksagungen fällig.

Allen voran natürlich dlchnr - Du hast eine Menge Ideen und Input geliefert; teilweise war es sehr kontrovers mit Dir, aber Du hast mich dadurch auch dazu gebracht, sehr intensiv über alles nachzudenken. Vor allem aber warst Du unermüdlich - man hätte meinen können, es geht um Deinen Rechner

retro64 - Danke für die harten Fakten zum Victor. Hin und wieder ist es gut, wenn man nicht immer nur spekulieren muss, sondern auch mal was Handfestes bekommt. Du hättest mir aber früher verraten können, dass der 132-Zeichen-Modus mit dem 132c.com nur vorbereitet, aber noch nicht aktiviert wird
Achja, wir könnten uns demnächst mal über Software unterhalten. Ich muss aber zuerst ein paar passende Disketten zusammensuchen.

kpanic - der Fachmann für PCs und DOS: kurze, knackige, präzise Beiträge

Toast_r - Ich freu' mich schon auf Deine Lötvorführung. Ich habe heute für den 20-Pinner 10 Minuten gebraucht - Dein Angebot steht hoffentlich noch (40 Pins in 5 Minuten)

stynx - Auch Dir ein Dankeschön für die Interpretationshilfen und die Analyse der Handbücher

x1541 - Jetzt, wo die Vicki wieder gesund ist, wäre Stuttgart ja nur noch eine Kür?! Ich denke trotzdem drüber nach.

fritzeflink - nein, ich habe keinen Genie mehr für Dich! Aber vielleicht kann das mit Stuttgart was werden ....

felge1966 - hast uns ja schon recht früh verlassen, aber dennoch danke für Deine Beiträge.

So, ich hoffe, ich habe keinen vergessen ... Für alle gilt: Herzlichen Dank!

Und jetzt dürft Ihr gratulieren ...

Huh, ich hab' erst gedacht, das ist ein Bild vom gemeinsamen Grillen

Das gibt Arbeit ...

Quote from dlchnr

Wollte nicht ausschließen, dass es so ist, sondern nur ein wenig davor warnen, sich darauf zu versteifen.
Ist das aus der Doku der Victor 9000 oder der Vicki? Wenn Vicki - super - dann ist dieser Punkt geklärt - wenn 9000, liegt die Vermutung nah, dass es auch geklärt ist, kann aber auch anders sein!

Wär schön, wenn ich was zur Vicki gefunden hätte, aber da gibt's irgendwie gar nichts

Da aber die beiden Systeme softwareseitig kompatibel sind und insbesondere die gleichen Leistungsdaten im Videobereich haben, bin ich ganz optimistisch, dass die interne Logik weitgehend identisch ist. Und was ich bisher rausgefunden habe, passt auch dazu.

Ich habe heute abend etwas das Board analysiert; war etwas mühsam, aber da ich relativ genau wusste, wonach ich suche, war es doch überschaubar. Ich habe mich dabei tatsächlich an die Empfehlungen aus einem der ersten Postings von dlchnr gehalten, nur eben beschränkt auf die Datenleitungen der SRAMs. Die landen zunächst mal über einen Bus-Transceiver auf einem (sekundären) Datenbus - mit entsprechend vielen unübersichtlichen Verbindungen in alle möglichen Richtungen.

Aber an einer Stelle geht es recht offensichtlich für einen Teil der Datenleitungen zum Adressbus des Hauptspeichers:

SRAM-Daten <=> 245 Bus Transceiver => 374 D-Flipflop => Adressbus

Der 245 müsste ok sein, weil z.B. die CPU die Daten richtig liest. Ich habe also im Moment den 374 im Verdacht. Mal sehen, was die Messungen ergeben - und dann kann vielleicht endlich gelötet werden

Danke für alle Rückmeldungen!

Wegen der Sache mit den Adressen habe ich mal das Original-Blockdiagramm aus der Victor-Doku angehängt und dann eine zweite Version, in der ich die Texte lesbar erneuert habe. Die folgende Beschreibung gilt grundsätzlich für den Textmodus; im Grafikmodus sieht es minimal anders aus:

Der 6845 hat zwar 14 Adressleitungen (kann also 16KB adressieren), nutzt aber nur die unteren 11 (MA0-MA10), um die 2048 Worte des SRAM zu adressieren. Die restlichen 3 Leitungen sind ungenutzt bzw. haben Sonderaufgaben (s.u.).

Von den 16 Bit, die als Daten von den SRAMs ("Screen Buffer RAM") geliefert werden, werden 5 Bits für die Attribute verwendet und völlig separat genutzt, während die restlichen 11 Bits (um die Verwirrung zu maximieren ist das wieder die gleiche Anzahl wie bei den 6845-Adressen; es handelt sich aber um völlig andere Signale) zusammen mit 4 Rasterzeilenadressen (die wiederum direkt vom 6845 kommen) die Zeichentabelle ("Dot Matrix RAM") im Hauptspeicher adressieren.
Die 4 Bits dienen dazu, eine der 16 Zeilen, aus denen ein Zeichen besteht, auszuwählen; mit den 11 Bit aus dem SRAM können 2048 verschiedene Zeichen adressiert werden. Insgesamt ist das ein Bereich von 32K Worten oder 64KB.

Eines der freien Adressbits des 6845 (s.o.) wird nun zusätzlich verwendet, um eine von 2 Speicherbanken (d.h die ersten oder die zweiten 64K im Hauptspeicher) auszuwählen (man kann also durch Umprogrammierung des CRTC zwischen zwei Zeichensätzen umschalten). Insgesamt müssen die Zeichendefinitionen auf jeden Fall in den unteren 128 KB des Hauptspeichers liegen - das steht so auch in der Doku.

Die Adresse einer Pixelreihe im Hauptspeicher wird also folgendermaßen aufgebaut:

000B SSSS SSSS SSSR RRR0

Dabei ist B das Bankselect-Bit vom 6845, S ist der 11 Bit lange "Font Cell Pointer", der vom SRAM geliefert wird, und R ist die 4 Bit lange Rasterzeilen-Adresse vom 6845.

Die defekten Bits kommen also eigentlich aus dem SRAM - dort stehen sie aber richtig drin, wenn sie der Prozessor ausliest. Deshalb komme ich auf die nachfolgende Multiplexer-Demultiplexer-Logik als Ursache (denn die Daten der SRAMs müssen je nach Zustand entweder auf den Datenbus oder den Adressbus des Prozessors gelegt werden - je nachdem ob es sich um einen Datenzugriff des Prozessors oder einen Videozugriff des CRTC handelt. Und genauso müssen die Adressleitungen der unteren 128 KB mal vom Prozessor, und mal von der Video-Logik adressiert werden - dual ported).

Ich weiß, das ist eine schwierige Materie, wenn man sich nicht intensiv damit befasst, aber ich hoffe, es ist etwas klarer geworden.

So,

im Anhang ist ein Bild. Heute von der Vicky geschossen, kein Fake ^^

Gut, ein bisschen musste ich nachhelfen, und der "Effekt" ist auch nicht wirklich von Dauer. Aber der Reihe nach.

Zuerst mal habe ich festgestellt, dass der Befehl 132c.com den 132-Zeichen-Modus nur vorbereitet, aber nicht einschaltet. Im Wesentlichen wird der spezielle Zeichensatz und vermutlich ein Stück Programmcode geladen.
Mit dem Befehl 132on.com wird der Modus dann umgeschaltet, und als ich das probiert habe, passierte folgendes: Der CRTC wurde umprogrammiert, das Raster war auf einmal 50*132, der Cursor klein, und auf dem Bildschirm erschien ein lustiges Durcheinander von Zeichen und Bitmustern.

Für mich war das ein weiteres Indiz, dass der 6845 vermutlich in Ordnung ist - die fehlende Umschaltung, die ich immer vermisst hatte, hatte es einfach noch nie gegeben.
Und außerdem wurde mir klar, dass das System im normalen Textmodus (25*80) offenbar zufällig auf den zusätzlichen Zeichensatz des 132-Modus gestoßen war, und da eben nicht "passend" (das wär auch des Zufalls zuviel gewesen).
Und offenbar wird der kleine Zeichensatz - obwohl für die 6*8 Pixel locker 8 Byte pro Zeichen gereicht hätten - wieder in je 16 Worten abgelegt, so dass der "Zeichenversatz" immer gleich blieb und auch mit dem 10*16-Raster nur eines der kleinen Zeichen dargestellt wurde.

Die nächste Aufgabe war nun die Suche des Zeichensatzes im RAM. Dazu habe ich per 132c.com den zusätzlichen Zeichensatz geladen und dann wieder über die serielle Verbindung einen kompletten Speicherdump der ersten 128 KB gemacht. In diesem Dump habe ich die Zeichen gesucht und gefunden: Die Klammer, die immer statt eines Blanks gezeichnet wurde, liegt von 0xD088 bis 0xD0A7. Allerdings fehlte unten ja immer eine Pixelreihe, und oben waren Pixel eines anderen Buchstabens zu erkennen, so dass offensichtlich die Bytes an den Adressen 0xD080 bis 0xD09F gelesen werden.

Das "echte" Bitmuster des Blanks liegt dagegen von 0x1080 bis 0x109F. Ergo sind da zwei Bits gesetzt, die nicht gesetzt sein dürften:

0001 0000 1000 0000b - erwartete Startadresse des Zeichenmusters
1101 0000 1000 0000b - tatsächliche Startadresse

Die unteren 5 Bits dieser Adresse werden durch die Rasterzeilenadressbits des CRTC geliefert, die oberen Bits dagegen aus dem Bildschirmspeicher (Refresh Memory/LUT - auf jeden Fall das SRAM), genauer aus dessen Datenausgängen. Da dieser Speicherbereich beim Auslesen korrekte Werte anzeigt, werden diese beiden Bits offenbar auf dem Weg von den Datenausgängen des SRAM zu den Adressleitungen des Hauptspeichers verändert. Das ist jetzt ein überschaubarer Bereich, den ich mir als nächstes mit dem Oszilloskop anschauen werde.

Um meine Theorie zu prüfen, habe ich ein Miniprogramm geschrieben, dass den Zeichensatz von seiner "korrekten" Position an die "erwartete" Position im Speicher kopiert. Original: 0x00c80 - 0x02c7f, Kopie: 0x0cc80 - 0x0ec7f

Und danach habe ich den Screenshot angefertigt

Natürlich ist das nicht von Dauer, weil das nächstbeste Programm beim Laden diesen Zeichensatz wieder überschreibt. Aber die eingebauten DOS-Befehle kann ich problemlos absetzen, und mir geht es zunächst nur ums Prinzip.

Jetzt hoffe ich nur, dass die Adress- und Buslogik nicht auch in dem Fujitsu-Käfer steckt. Eigentlich hat es auf dem Board genügend Decoder/Multiplexer etc.
Und vielleicht wiord dann auch endlich gelötet

Jungs, da bin ich wieder ...

Quote from Toast_r

Einerseits ist es ja recht interessant, was ihr da so alles überlegt.
Andererseits würde mir die Geduld fehlen, zumal das meiste ja sowieso auf Vermutungen basiert.
In der Zeit hätte längst den 6845 augelötet, gesockelt, und das ganze mit einem anderen getestet.

Jeder auf seine Weise. Wenn es darum geht, einen 40 poligen Käfer auszulöten, versuche ich halt erst mal sicher zu gehen, dass sich das lohnt. Gut, das Sockeln ist immer ein Gewinn, aber es ist schon ein ziemlicher Aufwand, verbunden mit einem gewissen Risiko.
Und was die Zeit angeht: Handbücher und Datenblätter studieren, Zusammenhänge suchen und im Forum diskutieren kann ich fast immer und überall. Die Vicky und die Lötstation stehen dagegen im Keller, und da komme ich an vielen Tagen nicht länger als eine halbe Stunde hin.

Quote from kpanic

Funktioniert aber auch anders herum.
Ich hab auch schon aus Spaß an der Freude eine voll funktionstüchtig e CIA am C64 gesockelt. Übung schadet nie

Kann ich sogar nachvollziehen, aber einerseits habe ich die Zeitbegrenzung, und andererseits ist ein C64 zum Üben deutlich geeigneter als das Mainboard einer Vicky.

Wie auch immer, ich habe mich an den 6845 bisher noch nicht rangetraut, und ich bin auch immer weniger überzeugt, dass er der Schuldige ist (siehe nächstes Posting).

Ich wollte es nicht !!

Jetzt habe ich aber doch noch mal ins Datenblatt geschaut, und vermutlich die Stelle gefunden, die einen so leicht ins Bockshorn jagt:

"Referring to Figure 2, the CRT controller generates the refresh addresses (MA0-MA13), ..."

Da liest unsere Generation natürlich beim flüchtigen Überfliegen sofort eine Refresh-Möglichkeit für den Speicher raus.
Tatsächlich wird auch an allen anderen Stellen, die ich gefunden habe, von "refresh memory address" geschrieben, das dann schon deutlicher macht, dass das keine Refresh-Adresse, sondern die Adresse des Refresh Memory ist.

So, jetzt aber genug für diese Nacht ...