Sirius 1 / Victor 9000 - keine Funktion, was tun?

Zitat von retro64

Zum Transfer: Als ich meinen alten noch hatte (leider weg) habe ich Kermit verwendet, was in der Tat sehr gut funktionierte. So habe ich meine Programmesourcen von damals noch in die "Moderne" gerettet.
Ich habe sogar noch eine Systemdiskette (mit DOS2.11) mit Kermit. Muss jetzt nur noch das alte Kabel finden...oder neu-bauen..

Habe dazu mal eine extra Thread aufgemacht:
Datenaustausch via seriellem Kabel

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.

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.

Zitat von 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.

Zitat von 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

Wobei ich vielleicht noch erwähnen sollte, dass die Messung beim 8086 deutlich einfacher sein wird - dort kann man auf die fallende Flanke von M/IO triggern und sieht danach den interessanten Schreibzyklus. Beim 8088 hat man das Problem, dass der Pegel des IO/M Signal beim interessanten Schreibzugriff mit dem Pegel des inaktiven Zustand übereinstimmt. Dort wird man besser auf das /WR Signal triggern. Da in der Loop der Out-Befehl der einzige Schreibbefehl ist, kann man auch so den interessanten Zyklus rausfiltern.

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

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:

Zitat von 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?

Das /WR-Signal geht schon während der Adressphase auf "0", deshalb ist die steigende Flanke schon der richtige Zeitpunkt - aber genau zum Zekitpunkt der Flanke, und nicht danach. Und zum Zeitpunkt der steigenden Flanke lese ich 0x021! Also irgendwas pass noch nicht richtig zusammen - flascher Code herausgesucht, Pins falsch gezählt, Strippen falsch angeschlossen, ...?

Die meisten Sirius haben ein P1 Boot-ROM. Dann müsste meiner Meinung nach auch ohne (funktionierenden) Diskettencontroller ein Diskettensymbol auf dem Schirm zu sehen sein wenn sonst alles funktioniert. Beim Universal Boot ROM müsste zumindest das "M" mit der erkannten Speichergröße zu sehen sein. Siehe Screenshots.
Die ROMs halten den Rechner bei schwerwiegenden Fehlern aber schon vor einer Bildschirmausgabe an. Dazu gehören: Checksum Fehler im Bootrom, VRAM Fehler, RAM Fehler. (Oder der 8088 selbst ist defekt...)Im Falle eines solchen Fehlers halten die P1 mit unendlichem JMP auf die Adresse des JMP Befehls an, Universal sendet in einer unendlichen Schleife per OUT einen Fehlercode auf den I/O Bus.
Erst nach dem Test auf schwerwiegende Fehler wird der Bildschirm angeschaltet und ein Mini-Zeichensatz ins RAM geladen, so dass Fehler angezeigt werden können. Ein fehlender Diskettencontroller dürfte das System eigentlich nicht aus der Ruhe bringen und müsste wie gesagt zumindest irgendeine Meldung auf dem Schirm hervorrufen. Die Tatsache, dass die LEDs leuchten zeigt auch, dass das Boot-ROM zumindest soweit kommt, dass es die 6522 Chips auf dem Floppy Controller anspricht. Also gehe ich davon aus, dass es zumindest keiner der erwähnten schwerwiegenden Fehler ist und der 8088 vermutlich auch ok ist.
Was passiert beim Schließen der Laufwerksverriegelungen? Springt einer der Motoren an? Bezüglich der nicht vorhandenen Bildschirmausgabe: ich würde prüfen, ob der 6845 ein Signal erzeugt, außerdem ist die Frage, ob auf dem Monitoranschluss des Mainboards auch Spannung anliegt, da der Monitor seine Spannung ja vom Computer aus erhält.

Zitat von 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

Wenn es hilft, kann ich auch den kommentierten Original-Source Code vom 3.6 Universal Boot-ROM zur Verfügung stellen. P1-ROM liegt mir nur Binary vor, das ist deutlich simpler und weniger aussagekräftig was Fehlermeldungen angeht gestrickt. Den groben Ablauf findet man hier
http://www.actsirius1.co.uk/pages/rom.htm

http://www.actsirius1.co.uk/pages/tech/appo.htm

Im Universal werden zuerst BT1INIT.ASM (ganz hinten ist "jmp far ptr reset_code" an FFFF:0) und dann BT1BASE.ASM ausgeführt (beim Vicki VCKINIT.ASM). Code ist relativ gut dokumentiert.

Ich bin übrigens an allen Boot-ROMS für den Sirius bzw. Vicki interessiert. Ich selbst habe Univ. 3.6 (Source+Bin), Univ. 3.7 (Bin), P1 Floppy, P1 HD. Ich würde mich über weitere Binaries freuen (z.B. ISSUE ROMs, oder auch ROMs vom Victor/Sirius VI).

Edit:

Zu den LEDs: die LEDs werden über einen der drei 6522 gesteuert. Der muss dafür nicht initialisiert werden, die LEDs sind direkt mit je einem Pin des 6522 verbunden, also muss zumindest ein Zugriff auf einen der 6522 erfolgreich gewesen sein.

Edit2:
Die Suche nach ROM-Erweiterungen dient zur Identifizierung von Diagnose-Karten, die früher vom Field Service genutzt wurden. Die haben sich auf D0000 gemappt und dann bei der Fehlerbehebung/-suche geholfen. Sobald an D0000 ein ROM gefunden wird verzweigt das BootROM sofort dorthin.

Zitat von 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

Das mit den Floppy-Köpfen kann ich natürlich erklären, aber wahrscheinlich weißt du das auch:

1 Kopf ist Single sided = 600 KB
2 Köpfe ist Double sided = 1.2 MB

Gruß HanS

ja, gab es ...

2 LW mit 600 KB und 128 KB Hauptspeicher = 9.995,- DM
2 LW mit 1,2 MB und 128 KB Hauptspeicher = 11.995,- DM
1 LW mit 1,2 MB und eine Festplatte mit 20 MB und 256 KB Hauptspeicher = 19.995,- DM

Speichererweiterungen gab es gegen Aufpreis, da weiß ich den Preis nicht mehr.
Aber den C. Itoh 8510B Nadeldrucker (9 Nadeln) gab es für 1.995,- Mark
Der benutzte übrigens ein Farbband der Gruppe 650 .... An was für nen Schiet man sich noch erinnert

Gruß
Hans

Hallo,

zum Prüfen der ROMs habe ich einen Thread mit allen mir zur Verfügung stehenden ROMs angelegt:

Boot ROMs Sirius 1 / Victor 9000 / Vicki - Suche/Biete,

Gruß,
Axel

Zitat von 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.

hallo, habe noch ein paar ungesichtete scans. werde versuchen die demnächst hochzuladen. Kann aber nichts versprechen. Vielleicht ist etwas dabei. Bin im Moment unterwegs. Wird wohl Samstag oder Sonntag.

Zitat von hexagon

die intel 2732A sind aus der Zeit als bei TI und anderen das Bauteil 2532 hiess

Das Pinout dieser Bausteine unterscheidet sich etwas - A11 liegt an unterschiedlichen Pins.