Na das könnte doch wieder so eine Loop sein, in der 'n Fehhlercode ausgegeben wird - allerings müsste es dann wohl ein OUT DX,AX sein (also 16bittig - wg. Doppelzugriff) - ihr könnt ja mal in den Sourcen schauen, ob derartige Fehler-Loops mit einem OUT.DX,AX vorkommen.
Als nächstes dann die weiteren Bits feststellen! ==> xxxx xxx1 xxxx xxx1
Sirius 1 / Victor 9000 - keine Funktion, was tun?
-
-
Die vielen Interessierten hier im Forum haben mich motiviert endlich einen schon lange geplanten Blog über den Sirius zu starten.
http://sirius1victor9000.blogspot.de/
Dort habe ich unter anderem ein paar Schematics hinterlegt. Ich bin mir nicht sicher, ob die schon alle bekannt bzw. vorhanden sind. Aber in jedem Fall sollten sie hilfreich sein. Seite 16 enthält auch den 8088.
Im Falle eines Universal ROM Fatal Error Loop, wird übrigens immer mit DX=FFFF auf den I/O Port geschrieben. AL enthält dann den Fehlercode.
-
OUT DX,AX
Könnte natürlich sein, dass sich der 8088 den Luxus erlaubt, jedweden Zugriff des 16-bittigen 8086 in eine Doppelzugriff umzuwandeln, unabhängig davon, ob der 8086 an dieser Stelle einen 16-bit-Zugriff oder nur eine 8-bit-Zugriff auf die even oder odd Adresse ausführt. Ich konnte dazu bislang keine Infos finden. -
Im ROM wird OUT DX,AL verwendet. Also sowieso nur 8-bit. Aber grundsätzlich muss der 8088 doch jeden 16-bit Zugriff in 2 8-bit Zugriffe unterteilen, egal ob odd oder even, oder?!
-
Bei einem OUT DX,AL auf eine gerade Adresse bleibt das Signal /BHE (Bus High Enable) inaktiv, legt also den obern Teil des Busses eigentlich "lahm" - infolge dessen müsste ein 8088 diesen deaktivierten Teil des 8086-Zugriffs auch nicht "emulieren".
Ein erster Eindruck sagt mir aber, dass es sich die Intel-Leute da sehr einfach gemacht haben und die Möglichkeit, das Bustiming, geschwindigkeitsfördernd ordentlich optimieren zu können, total ungenutzt gelassen haben. -
Andererseits hat der 8088 gar kein /BHE-Signal - die Intel-Leute konnten es sich also gar nicht "leicht gemacht" haben - es wäre von außen nicht möglich, aktive und inaktive Buszyklen zu unterscheiden. Die Oszi-Aufnahme zeigt also eine 16-bit Zugriff oder zwei aufeinanderfolgende 8-bit-Zugriffe!
-
Das BHE macht doch beim 8088 auch gar keinen Sinn, da es ja nur D0 bis D7 gibt. Im Prinzip stellt also jeder 16-Bit Zugriff zwei aufeinanderfolgende 8-Bit Zugriffe dar. Hilft aber bei der Interpretation der Aufnahme auch nicht weiter
-
sirius1victor9000: Danke für die Pläne in Deinem Blog. Hab ich schon ausgedruckt und will mir die jetzt vornehmen.
Aber erst mal was anderes, praktisches: Wie macht ihr das beim Messen? Ist einfach lästig das die Diskunit eingesteckt sein muss. Ich hab da ne Lösung mit Panzerband realisiert, aber das ist einfach nicht das Gelbe vom Ei. Werde mal probieren ob ein längeres Flachbandkabel dazwischen Abhilfe schafft so das man das Ding neben den Sirius kriegt...
Viele Grüße
Andreas -
Für mich sieht das aus, als wenn würde der 6845 CTRC mit falschen Werten initialisiert.
-
Ja, ein 6845 erzeugt das Bild. Hast du auch mal wieder die Monitore getauscht, hat der andere genauso geflimmert?
-
Den 6845 hab ich mittlerweile auch gefunden. Das stand in der zweiten Zeile auf dem Chip.
Von Hitachi.
Die Monitore tausche ich nochmal gegen und suche heute abend weiter.Viele Grüße
Andreas -
Habe mir das mit dem Jumper gerade nochmal angeschaut. Bist du dir sicher, dass das so richtig ist? Wenn ich das richtig interpretiere, hast du anstatt der zwei 2732 a 4KB jetzt einen 8KB. Die alternativen Jumper auf dem Schaltplan sprechen aber von 64K. Könnte es sein, dass das ROM dann bei Adresse F0000 platziert wird? Dann kann es eigentlich nicht funktionieren. Oder bin ich gerade komplett auf dem falschen Dampfer?
-
Nach genauerem Hinsehen, macht das nicht so richtig Sinn was ich eben geschrieben habe. Die Jumper regeln nur den Chipselect und die Übersetzung der A11 bis A13 Adressen in A11/A12 bei den 4K Varianten. 64K im Plan bezieht sich natürlich auf 2764K ... Hat mich irgendwie verwirrt.
-
Hallo,
man müsste prüfen an welcher Adresse das ROM in einen Loop geht, bzw. falls es ein Universal ROM ist, welcher Wert auf den I/O Bus gesendet wird (mit OUT DX=0FFFFh,AL). Wenn der Rechner in einer solchen Schleife hängt, müssten regelmäßige Muster auf A0-A19 bzw. D0-D7 zu erkennen sein, die man dann auswerten kann. Da du selber ROMs brennst, wäre natürlich auch eine Möglichkeit sich schnell ein eigenes Diagnose ROM zusammenzubasteln, das z.B. über die LEDs an den Diskdrives (als eine Art Morsecode o.ä ) eine Statusmeldung gibt, falls kein Signal auf dem Monitor erzeugt werden kann. Allzu aufwendig sollte das im ersten Schritt nicht sein.
Leuchten die LEDs mit dem neuen ROM eigentlich immer noch nach dem Einschalten? Welche ROM Version verwendest du im Moment?Gruß,
Axel -
Ich versuch mich jetzt auch mal am bitzählen...
Hab' mich auch mal ans Bitzählen gemacht - mein Ergebnis:
0x9FDDF,0x32
0x2FD15,0xAA
0x00103,0x55
0x9FDDF,0x32
Allerdings ist insbesondere die Adresse bei der Auflösung und ohne ALE-Signal mehr geraten als festgestellt! -
Ich hab nochmal versucht bessere Bilder zu machen - und die Machine ging heute in eine einfachere Sequenz (warum auch immer):
Viele Grüße
Andreas -
Das ist ziemlich sicher ein Zugriff auf 0x0FFFF mit dem Wert 02!
Die Adresse ist zum Zeitpunkt der gelben Linie zu nehmen, die Daten zum Zeitpunkt der blauen Linie.
Das zweite Bild (AD2) zeigt dann auch den Fall, bei dem das Ablesen der Adresse etwas zum Ratespiel wird, wenn die zeitliche Auflösumng etwas gering ist und eine parallele Darstellung von ALE fehlt (wozu man nat. ein 4-kanal Oszi benötgt) - deshalb besser mit einer höheren zeitlichen Auflösung arbeiten.
Achja - und den Triggerzeitpunkt bei dieser Messung besser in die Bildmitte. -
Hallo,
die Werte der zweiten Messung hören sich auf jeden Fall logischer an.
Wenn es wirklich FFFF,02 ist, würde das einen Fehler der ROM Checksum bedeuten. Melde mich später nochmal dazu.Gruß,
Axel -
OH YEAH!
Der Sirius lebt!
Danke Euch allen die ihr mich hier technisch und moralisch unterstützt habt, ohne Euch wäre das nicht möglich gewesen.
Die letzten Erkenntnisse dieses Threads brachten mich zur Überlegung: Ich muss wissen ob die RAM Chips in Ordnung sind, ansonsten kann ich in der Logik eh keine Fehler finden. Also hab ich mich dran gemacht sämtliches RAM aus dem Sirius zu entfernen und Sockel einzulöten.
Erstmal die beiden 6116 SRAM. Zum Test musste ne 1541 herhalten, wie praktisch das die auch eins drin hat. Die beiden erwiesen sich aber als in Ordnung. War ja klar. Dann zum Hauptspeicher. Hier passt praktischerweise das Sirius RAMtestgerät, auch Commodore 64 genannt. Im Hintergrund noch mit geplünderter Bestückung zu sehen. Dabei stellte sich herraus das 2 der 16 Chips defekt sind! Also neue rein, immer noch nix. Der Hinweis auf den ROM-Fehler brachte mich dazu mein gebranntes Eprom noch mal anzusehen. Im anderen Sirius lief das. Aber hier hatte ich den Eindruck das ich wohl eine Leiterbahn im Jumperfeld nicht tief genug gecuttet hatte. Das würde den ROM-Fehler erklären. Hab das dann gemacht, Jumper eingelötet - immer noch nichts. Dann habe ich die Jumper umgesteckt und die beiden originalen P1 2732 eingesetzt. BILD IST DA UND BOOTET! Yeah. Jetzt kann ich die Kiste Stück für Stück wieder zusammensetzen.
Allerdings würde ich schon gerne auf das neuere ROM umsteigen, woran das hängt das es nicht geht muss ich noch herrausfinden...
Viele Grüße
AndreasP.S.: DIL-16 Sockel sind in diesem Haus definitiv ausgegangen. Und Entlötlitze auch...
-
Super! Einen Sirius haut so einfach eben nichts um
Also technisch müsste der Rechner auch mit F3F7 laufen. Wenn der Chip im anderen Rechner bootet, kann es eigentlich nur an den Jumpern liegen. Evtl. muss man sich den Schaltplan auch nochmal genau anschauen, ob die Einstellungen mit dem 64kBit ROM wirklich passen. Kann man auf dem anderen Board dazu etwas erkennen?
Gruß,
Axel -
Unabhängig von der Frage warum der Rechner nicht mit dem 64kbit booten wollte: was spricht dagegen das F3F7 ROM zu splitten und auf zwei 32kbit Chips zu brennen?
-
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ß
GeorgPS. Ich bin neidisch. Das Logo auf dem Bootscreen des Sirius 1 sieht viel schöner aus als das auf der Vicki
-
Hallo Andreas, ich bin begeistert. Da hast du ein echtes Schmuckstück für deine Sammlung. Bringst du den Sirius mit zur CC?
-
Hallo,
ich hab noch ein bisschen dran weiter gesucht. Wahrscheinlich war das mit dem nicht laufenden ROM nur ein Kontaktproblem. Jetzt gehts meistens. Da steckt ein Präzisionssockel mit runden Beinchen in einer alten Low-Cost Fassung. Ich denke ich werde ich beiden ROM-Sockel und den Prozessorsockel noch gegen Präzisionsbauteile austauschen. Für die Stabilität von Maschinen habe ich da auch bei anderen Rechnern nur gute Erfahrungen mit gemacht. Auch werde ich für das ROM ein Adapterplatinchen einsetzen, der Sockel-mit-Kabel Umlöt-Hack ist einfach nicht so schön.
was spricht dagegen das F3F7 ROM zu splitten und auf zwei 32kbit Chips zu brennen?
Hauptsächlich die Tatsache das ich keine 2732 Bausteine da hatte - und mein simpler Eprommer diese auch gar nicht brennen könnte. Aber es stimmt schon - es ist die schönere Lösung, dann entfällt das Adapter-Gedöns.Und das Sockeln aller RAMs
Ich glaub da gibts noch mehr Arbeit - ich mache einen neuen Thread für das Erweiterungsboard was in der Maschine steckte...Bringst du den Sirius mit zur CC?
Ja, denke schon. Die sieht man viel zu selten auf CCs, der muss mitIch werde sicher noch viele Fragen hier haben - mein Background ist eben das ich den Sirius nicht von früher kenne, sondern die Maschine für mich neu ist. Hat mich aber schon lange interessiert, daher freue ich mich jetzt mal damit beschäftigen zu können.
Viele Grüße
Andreas
