Victor Vicki - Fehlerhafte Bildschirmausgabe

Zitat von dlchnr

Ah - da haben wir wohl gleichzeitig an 'nem Beitrag geschrieben - also kein Schieberegister!
Wenn Du das Board ausbaust, leg' die Lötseite doch gleich mal auf den Scanner.

Yepp, kein Schieberegister, nur ein Haufen Bustreiber, Multiplexer und ein paar Gatter. Achja, unten rechts ein doppelter 4-Bit-Binärzähler ...

Das mit dem Sacnner werde ich noch mal versuchen - die Unterseite benötigt ja nicht so viel Tiefenschärfe

Zitat von retro64

Da trau' ich mich fast nicht, eine andere Idee einzuwerfen:

Ich selber habe einen fast funktionstüchtigen Sirius1, kenne dafür aber leider den Vicki nicht...
Trotzdem:
Beim Sirius kann man nicht nur die Helligkeit (via Tastatur) einstellen, sondern auch den Kontrast. Wenn der sehr weit runter ist, könnte die normale Schrift quasi verschwinden, und nur der hellere Cursor ist sichtbar.

Ups, das wäre natürlich extrem peinlich
Ich habe an den Tasten etwas rumgespielt, aber vermutlich habe ich nur die Helligkeit gefunden, denn der Cursor wurde eben dunkler.
Zusätzlich habe ich ja noch den ordinären Drehknopf dran (für eine Grundeinstellung?) Mal sehen, ob die Kiste mich morgen noch mag, dann werde ich das mit dem Kontrast auf jeden Fall prüfen. Wobei ich bei einer Einstellung per Software eigentllich erwarte, dass bei Systemstart ein "sinnvoller" Kontrast voreingestellt wird - was im Gegensatz zu einer Hardware-Einstellung ja möglich ist.

Zitat von retro64

Und zur Frage nach dem Boot ohne Floppy;
Wen beim Sirius kein Boot-Medium gefunden wird, wird ein Disketten-Sybol, etwa in der Mitte der letzten Bildschrimzeile, angezeigt. Zusätzlich blinkt noch eine nach unten zeigender Pfeil als Aufforderung eine Floppy einzulegen.

Danke, dass ist eine wichtige Information. Das würde nämlich bedeuten, dass der Zeichensatz doch nicht im ROM liegen *muss*. Wobei der Pfeil bei der Vicki zur Seite zeigen müsste, weil die Laufwerke rechts liegen
Ich habe eben versucht, in den Innereien der EPROMs was Sinnvolles zu finden. Irgendwie stelle ich mich aber wohl was blöd an; wenn ich die beiden Teile (Even/Odd) zusammenmische (In der Reihenfolge Even/Odd, oder?) startet der Code zwar halbwegs sinnvoll mit einem kurzen Sprung, aber dort passieren dann Dinge, die mir nicht ganz logisch erscheinen. Und sinnvolle Muster für einen Zeichensatz habe ich auch nicht gefunden (wobei ich überhaupt keine Ahnung habe, wie groß ein Zeichen sein soll - wenn's z.B. eine 10x10 Matrix ist, erkennt sowas kein Mensch in einem Hexdump).
Vielleicht habe ich aber auch einen Fehler beim Zusammensetzen gemacht. Ist ja schon was spät...
Wenn ich das geprüft habe, poste ich mal die ersten Bytes. Dann können die x86-Cracks ja mal ihre Meinung abgeben.

Morgen geht's weiter. Herzlichen Dank auf jeden Fall schon mal in die Runde!

Hallo,

kurzes (hust, doch etwas länger geworden ) Update:

Die Sache mit Helligkeit/Kontrast habe ich ausprobiert: Auf der Tastatur sind nur Symbole für Lautstärke und Helligkeit vorhanden; damit regele ich aktuell die Cursorhelligkeit
Für den Kontrast (Unterschied Hell/Halbhell) gibt's wohl den Drehregler. Also die einfache Lösung war's nicht.

Beim Reset mit warmer Bildröhre wird einmal kurzfristig der gesamte Bildschirm hell - theoretisch kann er das also noch...

Der böse Verdacht, dass wesentlichte Teile der Bilderzeugung in einem der beiden geheimnisvollen Fujitsu-ICs passiert, scheint sich zu bestätigen: Das Pixeltaktsignal (Pin 21 des 6845) kommt direkt aus diesem Chip, und das Cursor-Signal (Pin 19) verschwindet offenbar auch schnurstracks dorthin. Ich fürchte, das wird eine Sackgasse.

Der Scan von der Löstseite ist auch erstaunlich schlecht geworden - da das Board größer ist als meine Scannerflache liegt es auf der Umrandung auf und damit dort ein paar Millimeter höher - ausreichend, dass die eng aneinander liegenden Leiterbahnen auf dem Bild völlig ineinander verlaufen. Ich hänge es mal an, aber helfen wird es wohl wenig. Evtl. kann ich auch die andere Seite mal scharf abbilden und dann die beiden Hälften zusammenbauen ... Wird aber eh kein Spaß werden, so wie das dort aussieht.

Ich schätze, als nächstes werde ich versuchen, mich von "hinten" aus vorzuarbeiten, d.h. vom fertigen Videosignal. Leider wird das auf der (relativ kleinen) Backplane abgegriffen, und um da vernünftig arbeiten zu können, muss ich die Kiste schon ziemlich gründlich zerlegen.

Ansonsten habe ich mir noch etwas die Technik des Victor 9000 durchgelesen, um einige der Fragen hier evtl. in den Griff zu bekommen.
Der Bildschirmspeicher ist 4K groß und enthält 80*25 = 2000 Worte(!), die den einzelnen Bildschirmstellen im Textmodus entsprechen. Diese 16 Bit pro "Zeichen" teilen sich auf in einen 11-bit Zeiger auf den Zeichensatz (womit max. 2048 verschiedene Zeichen dargestellt werden können) plus 5 Bit für diverse Attribute (unterstrichen, halbhell, invers, unsichtbar - eins ist ungenutzt)
Diese Zeiger zeigen in den unteren Bereich des normalen RAM, wo der aktuelle Zeichensatz abgelegt wird - je nach Zeichensatz zwischen 128 und 2048 verschiedene Zeichen. Jedes Zeichen wird aus eine 10x16 Matrix gebildet; zum Speichern werden aber 16 Worte verwendet. Von jedem Wort werden 10 Bits zur Darstellung der Rasterzeile genutzt, ein Bit hat noch einmal eine Attributbedeutung (etwas unkar, warum es das einerseits an zwei Stellen und dann hier auch noch separat für jede Rasterzeile gibt). Macht bei 32 Byte pro Zeichen mindestens 4K Zeichengenerator bei dem kleinstmöglichen Zeichensatz von 128 Zeichen bis zu theoretisch 64K bei der vollen Ausnutzung (das Handbuch schreibt 4K bis 40K).
(Im Hires-Modus werden im Bildschirmspeicher 2000 komplett verschiedene "Zeichen" abgelegt, jedes dieser "Zeichen" verweist auf einen eigenen 16x16 Bit großen Bereich im Hauptspeicher, der dann die hochauflösende Grafik enthält - nur so nebenbei...)
Die Schieberegister müssen also (je nach Modus) 10 bis 16 Bit breite Worte serialisieren - sowas gibt es auf den beiden Platinen definitiv nicht.

Das sind jetzt alles Informationen zum Victor 9000 - vieles davon passt aber ganz gut zu dem Bild, das wir inzwischen von der Vicki haben. Die beiden SRAMs halte ich demnach (auch wenn es reizvoll ist, die als Ersatz für ein Zeichensatz-ROM anzusehen) doch für den Bildschirmspeicher.

Ob und wieweit mir das bei der Analyse hilft, wird sich zeigen. Diese Fujitsu-Käfer machen das Leben schon ziemlich schwer ...

Ach ja, der Vollständigkeit halber: Die beiden Platinenanschlüsse links oben führen nirgendwo hin und hängen im Rechner einfach in der Luft. Debugging, Produktions-Abschlusskontrolle, ???
Und meine Irritationen bzgl. der EPROM-Inhalte rührt von meiner mangelnden Erfahrung mit dem 8086 her: Der springt (wie ich mittlerweile weiß) beim Reset an die Adresse 0xFFFF0 - wenn man davon ausgeht, dass die EPROMs am oberen Ende des Speicherbereichs angesiedelt sind, steht dort direkt ein Sprungbefehl (falls ich nicht irre):

EA 00 00 D0 FF - Sprung nach FFD00

An dieser Stelle fängt gerade ein neuer Codeblock an (erkennbar daran, dass sich davor ein größerer ungenutzter, d.h mit 0x00 gefüllter Bereich des EPROMs befindet); dieser Code scheint auch auf den ersten Blick was Sinnvolles zu machen.
Leider fehlt mir sowohl Werkzeug als auch Erfahrung mit dem i8086, um der Boot-Sequenz weitere Geheimnisse zu entlocken.

Soviel zum Stand der Dinge. Wenig erfreulich, und frustrierend, da die Kiste gut aussieht, ein superscharfes Bild hat (beim Booten wird wohl ein Logo angezeigt - das resultiert bei mir in einem hellen Rechteck mitten auf dem Schirm) und sonst alles macht, was man von ihm verlangt - man sieht nur nichts ...

Da fällt mir ein - wir haben doch früher gerne mal die Konsole auf die serielle Schnittstelle umgeleitet!? Frage an die DOS-Experten: Wie ging das noch - irgendwas mit dem mode-Befehl? Und Frage an die Sirius-Fraktion: Gibt's den Befehl auch im MS-DOS 2.1 des Sirius?
Dann könnte ich die Kiste vielleicht mal über die serielle Schnittstelle betreiben. Ich würde zu gerne noch mal den Laufwerken beim Formatieren zuhören - die Sirius-Kenner wissen, was ich meine

Gruß
Georg

Danke, das meinte ich. Ich hatte nur noch n ersten Teil im Kopf.
Mal sehen, ob ich das blind hinbekomme Im Zweifelsfall spare ich mir die Einstellung der Schnittstelle und arbeite mit den Default-Werten.

Hallo Jonas,

das deckt sich ja weitgehend mit dem, wie ich diese Doku gelesen und verstanden habe.

Zitat von stynx

Leider keine Schaltpläne in der technischen Doku.

Auf der inzwischen bekannten Seite Home of the ACT Sirius 1 and VictorComputers finden sich durchaus einige Schaltpläne, auch wenn die sicher nicht 1:1 auf die Vicki übertragbar sind (andere Speicherausstattungen, 8088 vs. 8086 etc.).
Schlimmer ist aber, dass die Pläne meiner Meinung nach sehr unvollständig sind. Den Videoteil habe ich jedenfalls nicht gefunden

Georg

Eigentlich wollte ich die Kiste frustriert zusammenschrauben und wieder für einige Zeit ins Regal verbannen..

Auch der Versuch, mit der Maschine über die serielle Schnittstelle zu sprechen, ist komplett gescheitert. Obwohl es eigentlich normale DOS-Konstrukte sind, scheint der Rechner das CTTY nicht zu kennen, und ich habe sogar den Eindruck, dass er die serielle Schnittstelle nicht mit COM1 anspricht.

Jedenfalls hat jede Kombination von ctty (bzw. cttz, weil ich nicht sicher bin, ob ein Tastaturtreiber geladen ist), com1 (oder com2) zu keinem Ergebnis geführt (die Konsole müsste danach ja "tot" sein - passierte aber nicht). Beim Versuch, irgendwas nach COM1 (oder COM1: oder COM2 etc) zu kopieren, versuchte er offenbar, auf die Diskette zu schreiben, was wegen des Schreibschutzes zu einem Fehler führte.

Kann ich natürlich alles nicht sehen, außer an den Cursorbewegungen und den Reaktionen auf meine Tastendrücke ...

Ich habe auch immer wieder die vorhandenen Unterlagen studiert, und irgendwann habe ich von dem 132-Zeichen Modus gelesen: Die Victors können neben der 80x25 auch eine 132x50 Auflösung darstellen. Die Umschaltung erfolgt durch ein Programm 132c.exe - und siehe da, wenn ich das eingebe erscheint etwas auf dem Bildschirm. Nichts sinnvolles, aber es kommt etwas. Statt mit Leerzeichen ist der Bildschirm mit geöffneten Klammern gefüllt; auch alle anderen Zeichen werden durch falsche Zeichen ersetzt, und das auch noch "versetzt", d.h. in der obersten Rasterzeile erscheinen die Punkte, die eigentlich unten sein sollten, dann kommen ein paar leere Zeilen und dann kommt das eigentliche Zeichen, allerdings nur bis zur vorletzten Rasterzeile.

Irgendwie kommt die Videologik mit ihrer gesamten Adressierung durcheinander. Besonders auffällig: Die Zeichen sind zwar so klein, wie man sie erwartet (bei 800px * 400px und 132*50 Zeichen kommt man auf eine Zeichenmatrix von 6*8), aber es werden nur 80 * 25 davon dargestellt, und auch der Cursor hat seine ursprüngliche Größe von 10*16! Offenbar wird der 6845 nicht richtig umprogrammiert - da wundert man sich eigentlich, dass er beim Start mit immerhin halbwegs vernünftigen Werten programmiert wird, so dass er das normale Raster und den Cursor richtig hinbekommt ...

Und dann habe ich jetzt bei den weitere Nachforschungen doch noch den Befehl gefunden, mit dem ich die Konsole auf die serielle Schnittstelle umleite - das scheint eher wie bei CP/M zu gehen, nämlich durch Zuordnung von logischen Gerät zu physikalischem:

SETIO CON=TTY

und statt des MODE-Befehls gibt es dort wohl ein interaktives Tools namens PORTSET

Sieht so aus, als würde ich die Vicki wieder aus dem Regal rausholen und noch ein paar weitere Versuche machen müssen.

Zitat von retro64

hänge immer noch meiner Idee mit dem Kontrast nach...:

Bei meinem Sirius1 kann ich Phänomen prima "nachstellen", wenn ich den Kontrast nur weit genug "hochdrehe" (via Tastatur).

Du könntest, wenn Dein Rechner sich ähnlich wie ein Sirius1 verhält, mal folgendes probieren, wenn er gebootet hat:

prompt $e($ep$p_

Das führt beim Sirius dazu, dass alles weitere in "hell" und "revers" ausgegeben wird...

Alles anzeigen

Danke für den Tipp, werde ich auf jeden Fall ausprobieren, wenn ich wieder im Keller bei dem Schätzchen bin. Aber noch mal wegen der Kontrastregelung: Ich nehme mal an, dass der Sirius keinen Drehregler hat? Denn den hat die Vicky, aber über die Tastatur habe ich meiner Meinung nach nur eine Regelungsmöglichkeit.
Und im Übrigen zeigt ja das seltsame Bild im 132-Zeichen-Modus, dass da etwas grundlegendes nicht stimmt...

Die Umschaltung der Konsole auf die serielle hat wieder nicht funktioniert; den Befehl SETIO habe ich offenbar nicht auf der Diskette. Und als Zielgerät für z.b. COPY geht TTY auch nicht

Dafür habe ich aber mal die Darstellung im 132-Zeichen-Modus untersucht. im Anhang sind ein zwei Beispiele - zum einen ein "leerer" Bildschirm, und dann die Ausgabe des DIR-Befehls. Durch gezielte Tests habe ich herausgefunden, dass ich einen konstanten Versatz von 9 Zeichen habe, d.h. aus einem A wird ein J, aus der Ziffer 0 eine 9, und aus dem Größer-Zeichen > (0x3E) wird ein G (0x47). So wird z.B. aus dem Prompt A> die Kombination JG, die man auf beiden Bildern vor dem Cursor erkennen kann.

Das scheint sich durch den gesamten Zeichensatz durchzuziehen; es ist einfach nur dieser konstante Versatz, der sich meiner Meinung nach nicht durch einen Bitfehler o.ä. erklären lässt. Massiv irritiert mich auch die Auflösung 80 Zeichen * 25 Zeilen nach der Umschaltung und der nach wie vor sichtbare 10*16 Pixel große Cursor.

retro64: Kannst Du mir noch zwei weitere Fragen beantworten?
1. Welcher Cursor ist im 132-Zeichen-Modus zu sehen? Ist das auch ein Block, und wie groß ist der?
2. Weißt Du, wie man die serielle Schnittstelle ansprechen muss, wenn man z.B. eine Datei dorthin kopieren will?

Ich werde jetzt mal versuchen, die Ausgabe des DIR-Befehls zu "übersetzen", damit ich weiß, was ich überhaupt auf den Disketten habe. Sind keine Originaldisketten; ich habe insgesamt nur drei Stück, und ich habe keine Ahnung mehr, was ich da drauf habe ...

Danke und Gruß
Georg

Zitat von kpanic

Ich könnte mir also durchaus vorstellen, dass der 6845 nen Hau hat und den Zeichensatz falsch adressiert.

Ja, ich habe auch schon mit dem Gedanken gespielt, einfach mal testweise den 6845 zu tauschen. Muss mal sehen, ob ich den woanders noch gesockelt habe.

Ich würde eigentlich gerne verstehen, wie es zu diesem Problem kommt, d.h. was eigentlich kaputt ist, so dass solche Phänomene auftreten. Im Fall eines defekten CRTC ist das natürlich aussichtslos, der ist einfach zu komplex.

Ich habe übrigens die DIR-Ausgabe jetzt relativ schnell entziffert, dort steht i.W.:

COMMAND  COM    19456  11.01.84  18.01  @86      COM     4096  11.04.91  16.31CONFIG   BAK       44   1.01.80   0.14CONFIG   SYS      171   9.04.91  13.16CONFIG   BAT       57  16.04.91  18.44PPORT    EXE     1536  17.01.84  11.45PORTA    EXE     3584   7.01.84  13.48BASIC        <DIR>      8.04.91  13.15DOS          <DIR>      8.04.91  13.15	        9 File(s)    559104 bytes free

(Die 1 und 2 sind in der Darstellung so gut wie nicht unterscheidbar (Doppelpunkt und Semikolon), deshalb kann fast überall, wo eine 1 steht, auch eine 2 stehen)

Statt einer autoexec.bat gibts es hier also eine config.bat; das für mich interessanteste steckt natürlich im Unterverzeichnis DOS. Da darf ich dann noch mal ran.
Und ich frage mich natürlich, was es mit der @86.com (wenn ich das richtig übersetzt habe) auf sich hat, die offensichtlich 3 Tage nach Erstellung der Diskette verändert/angefasst wurde.

Zitat von retro64

Du könntest, wenn Dein Rechner sich ähnlich wie ein Sirius1 verhält, mal folgendes probieren, wenn er gebootet hat:

prompt $e($ep$p_

Das führt beim Sirius dazu, dass alles weitere in "hell" und "revers" ausgegeben wird...

Ja, damit wird es auch bei mir "hell" und "revers" - vorher war alles schwarz, jetzt ist alles grün (Siehe Anhang).
Also große Teile der Bildschirmsteuerung funktionieren, aber das Wesentliche irgendwie nicht ...

Zitat von dlchnr

Da der Cursor vom 6845 gemacht wird, wird er nicht mehr richtig bedient oder hat selbst einen Knacks, falls der sich die Größe des Cursors dem gewählten Mode anpassen müsste. Auch der konstante Versatz deutet an, dass hier kein Bit klemmt, 'ne Leitung 'nen Kurzschluss hat oder ähnliches sondern sondern ein Rechehwerk eine falsche Konstante oder falsche Basisadresse geliefert bekommt. Das könnte man durchaus damit erklären, dass der 6845 nicht mehr vollkommen ok ist, denkbar wäre aber auch, dass im ROM nicht mehr alle Bits ok sind. Da der 6845 wohl nicht gesockelt ist, würde ich vor einem Tausch des CRT versuchen, erst den ROM-Inhalt zu verifizieren.

Es ist ja nicht nur der Cursor, sondern auch das Zeichenraster - der CRTC generiert offenbar pro Textzeile immer noch 16 Rasterzeilen statt 8, und es sind auch immer noch nur 80 Zeichen pro Zeile.

Vor dem Auslöten des 6845 habe ich auch Respekt, aber die ROMs habe ich weniger im Verdacht. Immerhin wird der 80*25-Modus (zumindest vom Raster, Cursor etc.) offenbar korrekt programmiert. Umgekehrt wird der 132-Zeichen-Modus, der ja ganz offensichtlich nicht korrekt initialisiert wird, per Software (über das Tool 132c.exe) eingestellt. Das hieße, dass eher dieses Tool kaputt ist.
Wegen der fehlenden Zeichen im 80-Zeichen-Modus muss es aber auch außerhalb des 132c.exe einen Fehler geben. Ich denke also, dass es eher an einem zentralen Teil der Video-Hardware liegt.

BTW, die Maschinen sind offenbar so selten, dass es wohl wenig Chancen gibt, das ROM zu verifizieren

Zitat von x1541

PS. wenn wir dieses jahr eine Vicki und einen Victor aufstellen, steigen die Chancen, dass die Besitzer sich wieder melden

Das war wohl ein Wink mit dem Zaunpfahl

h&e ist Hobby & Elektronik in Stuttgart?
Ist mir etwas weit, und außerdem wollt Ihr doch eigentlich nur lauffähige Systeme dabei haben

Zitat von dlchnr

Der Vorschlag, erst das ROM zu verifizieren mache ich nicht, weil ich den Fehler mit größerer Wahrscheinlichkeit im ROM erwarten würde, sondern weil es einfach viel einfacher ist als das Auslöten (vorausgesetzt, es steht eine Reference zur Verfügung).

Klar, ist ein triftiges Argument

Aber ich zweifle trotzdem dran. Einerseits habe ich nicht den Eindruck, dass viel Funktionalität in dem Eproms steckt - ich denke, es ist (anders als beim PC) eher eine Art IPL. Victor scheint mir vieles per nachladbarer Software gemacht zu haben, evtl. auch das BIOS. Offensichtlich ist noch nicht mal ein Zeichensatz vorgegeben.

Außerdem erwarte ich von einem "anständigen" Boot-ROM, dass es einen Selbsttest macht, und den habe ich offenbar auch gefunden:

ffd39:	b9 00 10     mov    $0x1000,%cx
   ffd3c:	b8 00 fe     mov    $0xfe00,%ax
   ffd3f:	8e c0        mov    %ax,%es
   ffd41:	33 f6        xor    %si,%si	
   ffd43:	33 c0        xor    %ax,%ax	


   ffd45:	26 03 04     add    %es:(%si),%ax
   ffd48:	46           inc    %si		
   ffd49:	46           inc    %si
   ffd4a:	e2 f9        loop   0xffd45		


   ffd4c:	3d 52 21     cmp    $0x2152,%ax	
   ffd4f:	74 03        je     0xffd54		


   ffd51:	e9 8e 00     jmp    0xffde2		


   ffd54:	b8 00 d0     mov    $0xd000,%ax
   ffd57:	8e d8        mov    %ax,%ds
....


   ffde2:	b0 02        mov    $0x2,%al
   ffde4:	ba ff ff     mov    $0xffff,%dx
   ffde7:	ee           out    %al,(%dx)
   ffde8:	eb fd        jmp    0xffde7

Wie gesagt, ich bin kein 8086-Fachmann, aber die Schleife ffd45-ffd4a bildet ganz offensichtlich eine Prüfsumme von fe000 bis fffff, die dann in ffd4c mit dem Sollwert verglichen wird. Im Fehlerfall geht's dann zur Endschlosschleife um ffde7.

Da die Kiste allerdings weiterläuft, scheint die Prüfsumme zu stimmen.

Und nein, so richtig vorstellen, was da los ist, kann ich mir auch nicht: einerseits stimmt die Startinitialisierung im Wesentlichen(Anzahl Zeilen, Anzahl Zeichen, Anzahl Pixel pro Zeile, Cursorgröße, Horizontalsync, Vertikalsync ...) und nur etwas marginales scheint schief zu laufen, und andererseits klappt später die Umprogrammierung irgendwie überhaupt nicht .... An sinnvolle Default-Werte glaube ich bei dem 6845 überhaupt nicht.
Es bleibt ein Rätsel ...

Danke übrigens für den Hinweis auf den 6845 in der Bucht. Ich hatte auch schon auf die Schnelle mal gesucht, aber zunächst nur die Chinesen, Bulgaren und völlig überteuerten Amerikaner gefunden ...

Zitat von retro64

1) Bei mir ist der Cursor im 132-Mode ein Block, der aber höher als eine Zeile ist (siehe Foto)
2) hab bisher seriell nur Kermit gearbeitet - da geht das direkt. DOS-pur gibt es das "PORTSET" Kommando. Daraus ableitend würde ich für den Device-Namen auf "porta" oder "portb" tippen (ist aber ein blinder Versuch...)

Danke für die Rückmeldung, und besonders für die Bilder. Da sieht man schon mal, worauf man sich freuen kann

Das mit dem Block und der Größe war mir wichtig, denn das bedeutet, dass bei der Umschaltung in den 132-Zeichen-Modus auf jeden Fall der Cursor umprogrammiert werden muss (Anfangs- und Endzeile) - und das ganz offenbar bei mir auch nicht passiert.

Für die serielle Schnittstelle habe ich momentan das Gerät "AUX" im Verdacht, aber das muss ich erst noch verifizieren. Bin jetzt zwei Tage nicht bei der Vicki gewesen.
Ich werde es auch mal mit PORTA oder PORTB versuchen (wobei die Vicki nur eine serielle hat) . Auf der Diskette sind mir zwei Programme PORTA.EXE und PORTB.EXE aufgefallen - PORTA.EXE liegt im Wurzelverzeichnis, PORTB.EXE im Unterverzeichnis DOS. Zusätzlich gibt es das Programm PPORT.EXE - mir ist noch nicht ganz klar, was ich davon halten soll. Umleitung der Druckerausgabe? Konfiguration geht wohl auch bei der Vicki mit PORTSET.COM.

Zitat von dlchnr

Der Cursor befindet sich auf beiden Bilder in einer Zeile ohne Buchstaben mit Unterlänge, also ohne g, p, q, etc. - wenn ich davon ausgehe, dass die Buchstaben nicht die komplette Zeilenhöhe einnehmen (also z.B. die oberste und die unterste Pixelreihe schwarz ist), damit die Buchstaben verschiedener Zeilen nicht aneinander stossen, könnte der Cursor vielleicht doch genau die Höhe einer Zeile haben!?

Zitat von dlchnr

Wenn man die neuen Bilder mit den Bild aus Beitrag 40 vergleicht, fällt auch auf, dass die Basis des Cursor an unterschiedlichen Stellen liegt - einmal eher auf der Unterlängenlinie, bei Georg auf der Grundlinie.

Da gebe ich Dir weitgehend recht, allerdings fangen die Buchstaben ganz offensichtlich am oberen Rand der "Zelle" an (bündig mit dem Cursor), darunter ist eine Zeile für eine angedeutete Unterlänge (sieh' Dir das y in byte an), und dann noch eine Rasterzeile als Abstand zur nächsten Bildschirmzeile.

Bei 132*50 ist alles ziemlich eng; in der Breite hat eine Zelle gerade mal 800/132=6 Pixel, in der Höhe 400/50=8 Pixel. Bleiben nach Abzug von "Luft" und Unterlänge eine Matrix von 5*6 für die Großbuchstaben. Ist knapp, geht aber.

Der Cursor füllt dagegen die ganze Zelle, ist also 6*8 groß.
Wichtig, auch wenn man es den Bildern nicht auf Anhieb ansieht: Mein Cursor ist viel größer, denn der hat noch das 80x25-Format von 10*14 Pixeln.

Noch eine kurze Aktualisierung: Mit Hilfe des 132-Zeichen-Modus und des konstanten Versatzes habe ich jetzt auch das DOS-Verzeichnis meiner Floppy "dekodiert":

.            <DIR>      8.04.91  13.15
..           <DIR>      8.04.91  13:15
PORTB    EXE     3584   7.02.84  14.12
FORMAT   DAT     1934  19.07.83  13.04
FORMAT   EXE    39377   9.01.84  14.37
CHKDSK   COM     6480  25.01.84  12.30
PRINT    COM     3808  25.01.84  11.17
RECOVER  COM     2304  25.01.84  12.46
MORE     COM     4368  25.01.84  12.45
DISKCOPY COM    16817  13.01.84   8.38
FIND     EXE     6331  25.01.84  12.41
MODCON   EXE    14738   7.02.84   9.12
MSBASIC  COM    31744   9.06.83  13.35
FILCOM   EXE     2585  25.01.84  11.17
EDLIN    COM     8080  25.01.84  12.36
PORTSET  COM     6144   3.02.84  13.34
MV       EXE    30936  23.11.83  11.30
FGREP    EXE    31080  23.11.83  11.30
SEARCH   EXE    53016   9.01.84  12.33
LS       EXE    31480  23.11.83  11.31
EXESIZE  EXE     1371  13.02.84  12.09
DISKID1          4096   5.03.84  13.10
SYS      EXE    20481  30.01.84  18.37
SORT     EXE     1632  25.01.84  12.48
132C     COM    47321  11.01.84  16.55
132ON    COM      273  10.01.83  13.25
132OFF   COM      273  10.10.83  13.27
CPM      EXE     5632  20.09.83  14.58
DISKID2          2065   1.01.80   0.36
RDCPM    COM    11214  21.11.83  11.33
CALC     COM     4917  23.08.82   1.03
CONCAT   EXE    26216  23.11.83  11.33
TAIL     EXE    30712  23.11.83  11.33
WC       EXE    28184  23.11.83  11.34
       34 File(s)    559104 bytes free

Und dann habe ich mich weiter im ROM umgesehen; und muss zumindest eine Fehleinschätzung :rotwerd: zugeben: Es befindet sich doch ein Zeichensatz drin, allerdings (bisher) nur ein rudimentärer.
Ich habe aufeinanderfolgend die Ziffern 0-9 und die Buchstaben A-F gefunden (ich schätze für Fehlermeldungen mit Adressangaben), dann kommen zwei Zeichen, die zusammen ein Diskettensymbol ergeben und nochmal zwei Zeichen, die einen Pfeil darstellen - also die Symbole, die beim Start ohne Diskette normalerweise angezeigt werden. Es folgen auch noch ein paar weitere Zeichen, aber die habe ich noch nicht analysiert. Liefere ich nach ....