Also ein Sirius hat 2 serielle Schnittstellen: PortA und PortB
und eine paralle Schnittstelle: PPORT
SIW ist für die Verwendung von PORTSET das Laden der Trieber (PORTA und/oder PORTB) notwendig.
Bei Kermit-Nutzung war das nicht notwendig.
Schätze mal, Deine Vicky könnte mit PORTA klarkommen...
Great News!!
Sie redet mit mir!! 
Also der Reihe nach:
Mit com1 hatte es ja nicht funktioniert, und dann hatte ich alles mögliche ausprobiert: tty, aux, porta, portb, ser usw. Da ich das alles im Blindflug mache, hatte ich natürlich keine Ahnung, was daran jetzt verkehrt war. Ich war ja schon der Meinung, die Vicky kennt den CTTY Befehl nicht.
Wobei aux ganz gut aussah (wenn ich etwas dahin kopiert habe, hat sie was gemacht und nicht nur versucht, auf Diskette zu schreiben - allerdings kam am seriellen Port nichts an).
Kurz und gut, ich habe nochmal alle für den Victor/Sirius verfügbaren Handbücher studiert. Dort sind an einer Stelle explizit die "benannten" Geräte aufgeführt: "AUXIN, AUXOUT, LST, PRN, CON". Die haben mir aber nicht geholfen. Und dann habe ich in einem Syntaxbeispiel ein Gerät SERIALA gefunden - und das wars dann.
CTTY SERIALA - und wir können es miteinander. Sozusagen headless 
Jetzt habe ich meine Disketten untersucht, ob da was hilfreiches drauf ist, und habe zumindest ein MSBASIC (das komplett über DOS geht, und deshalb mit der Umleitung zurechtkommt) und vor allem einen SID gefunden.
Mit letzterem habe ich auch schon etwas im System rumgestochert - wenn ich den Bildschirmspeicher (der mit ganz komischen Sachen gefüllt ist 
) mutwillig mit irgendeinem Mist beschreibe, passiert tatsächlich was auf dem Bildschirm. Allerdings erscheinen keine "Zeichen", sondern ich ändere zunächst mal nur die Attribute (invers in verschiedenen Helligkeiten). Aber immerhin ...
Momentan ziehe ich mir einen kompletten Speicherdump über die serielle Schnittstelle auf meinen Host - da kann ich dann in Ruhe und mit besserem Werkzeug weitersuchen.
Achja - ich wollte doch die Laufwerke singen hören. Das klappt noch nicht; der Format-Befehl arbeitet interaktiv und präsentiert ein Menü - allerdings schreibt er direkt in den Bildschirmspeicher, und somit konnte ich zunächst mal nichts mit anfangen.
Immerhin hat sich bei der Gelegenheit etwas auf dem Bildschirm getan - es sind zwar nur wilde Muster, aber es sind Muster. Nicht mehr nur schwarze oder grüne Blöcke. Ich denke, jetzt kann ich einigermaßen gezielt weitersuchen.
Leider habe ich jetzt wieder einen Termin, aber ich melde mich, wenn es weitergeht. Dann gibt's vielleicht auch ein paar Bilder.
Also ein Sirius hat 2 serielle Schnittstellen: PortA und PortB
und eine paralle Schnittstelle: PPORT
SIW ist für die Verwendung von PORTSET das Laden der Trieber (PORTA und/oder PORTB) notwendig.
Danke, aber die waren zum Glück schon in meinen Konfigurationsdateien (CONFIG.SYS und CONFIG.BAT) drin. Wobei der PORTSET gar nicht nötig ist; die Einstellungen kann man dem Treiber beim Laden mitgeben. Den braucht man wohl, wenn man die Einstellungen später ändern will.
Grüße und Danke in die Runde für die Unterstützung und Motivation 
Georg
Ich hab' mich jetzt nicht tief in das vorhandene Material eingearbeitet, hab' dafür aktuell auch keine Zeit, wollte aber ein paar Gedanken einbringen, die vielleicht hilfreich sein können. Soweit ich den 6845 bislang überblicke, ist er eigentlich dafür gedacht, Character mittels eines Character-RAMs/ROMs auf den CRT zu bringen. Victor hat den wohl etwas vergewaltigt, indem es ihn als Adress-Generator benutzt, dessen ausgegebene Adressen zum Teil mittels einer LUT (die beiden SRAMs) "übersetzt" werden, so dass nun die Character aus dem Hauptspeicher geholt werden können. Dazu müssen nun aber aus einem einzelnen 6845-Zugriff zwei Zugriffe für den Hauptspeicher generiert werden, damit aus zwei 8-Bit-Werten ein 16-Bit-Wert entsteht, von dem 11 Bit ins Schieberegister transferiert werden. Das" aus-ein-macht-zwei-Zugriffe" wird wohl von den Fujitsu-Bausteinen erledigt.
Mit diesem Konzept ist es dann möglich, einen Art Graphikmodus zu generieren - wenn in der LUT unter jeder Adresse die Adresse selbst eingetragen wird, fliegt diese quasi raus - der Bildspeicher kann dann als fast-Graphikspeicher dienen - fast deshalb, weil er wg. der nur genutzten 11bit etwas "löchrig" ist. Ich vermute aber, das Victor das tatsächlich nutzt, sonst macht für mich der ganze Aufwand irgendwie keinen Sinn (denn ladbare Zeichensätze mit unterschiedlichen Grössen lassen sich allein mit einem Character-RAM, statt einem Character-ROM realisieren).
Das für das Problem aber entscheidende ist - die Adressen kommen letztlich immer vom 6845!
PS: U.U. gibt es sogar einen "Hack", der es erlaubt, im "Graphikmodus" die kompletten 16bit zu nutzen, so das der Graphikspeicher gar nicht "löchrig" ist!?
Danke für Deine Gedanken und Deine Zeit. Leider bin ich nicht sicher, ob ich Dich 100% verstanden habe; an einigen Stellen kann ich Dir folgen, an einigen anderen habe ich inzwischen andere Eindrücke bekommen.
Ich versuche es mal Schritt für Schritt.
Soweit ich den 6845 bislang überblicke, ist er eigentlich dafür gedacht, Character mittels eines Character-RAMs/ROMs auf den CRT zu bringen.
Klar, aber nicht dass dadurch der Eindruck entsteht, der 6845 liefert diese Zeichen in irgendeiner Form selber aus. Er produziert nur das Timing. Das ist zunächst der äußere "Rahmen" in Form von HSYNC und VSYNC, und innerhalb dieses Rahmens liefert er zu jedem Zeitpunkt die Information: "Jetzt muss von dem Zeichen, dass an Adresse x im Bildschirmspeicher steht, die soundsovielte Rasterzeile ausgegeben werden."
(Abgesehen von Zusatzfunktionen wie Cursor, Lichtgriffeleingang etc.)
Victor hat den wohl etwas vergewaltigt, indem es ihn als Adress-Generator benutzt, dessen ausgegebene Adressen zum Teil mittels einer LUT (die beiden SRAMs) "übersetzt" werden, so dass nun die Character aus dem Hauptspeicher geholt werden können.
Funktional gesehen stimme ich Dir zu, würde das aber nicht als Vergewaltigung sehen. Das ist meiner Meinung nach seine ganz normale Aufgabe. Die Abweichung besteht im Wesentlichen darin, dass sich üblicherweise der Bildschirmspeicher eher im Hauptspeicher befindet und das Character-ROM (Zeichengenerator) außerhalb. Hier ist es umgedreht. Und ob man den Zeichengenerator als Lookup-Table bezeichnen kann mag ich nicht entscheiden: Tatsache ist bei alle Designs, die ich kenne, dass der 6845 die Adresse eines Zeichens (im Bildschirmspeicher) ausgibt; die Daten, die dort gefunden werden (in der Regel ein erweiterter 8-Bit-ASCII-Code, aber dann ist man auf 256 Zeichen beschränkt, und Victor wollte mehr), dienen dann wieder als (oberer Teil der) Adresse der "Zeichenmatrix" im Character-ROM.
Die fehlenden unteren Bits (nämlich genau die Information, welche Zeile der Zeichenmatrix uns gerade interessiert), liefert der 6845 parallel an seinen Row-Address-Ausgängen.
Der Zeichencode stellt also "im Wesentlichen" die Adresse für das Character-ROM, und die Ausgangsdaten des ROMs gehen zum Schieberegister zwecks Serialisierung.
Victor macht's im Grunde genauso; nur dass nicht der reine ASCII-Code zur Adressierung des Character-RAMs genutzt wird, sondern ein erweiterter Code (der sich aber für den "normalen" Zeichensatz aus dem ASCII-Code errechnen lässt) und der gleichzeitig berücksichtigt, dass die Adressen des Zeichengenerators - anders als bei einem eigenständigen ROM - quasi irgendwo mitten im Adressraum der CPU liegen.
Dazu müssen nun aber aus einem einzelnen 6845-Zugriff zwei Zugriffe für den Hauptspeicher generiert werden, damit aus zwei 8-Bit-Werten ein 16-Bit-Wert entsteht, von dem 11 Bit ins Schieberegister transferiert werden. Das" aus-ein-macht-zwei-Zugriffe" wird wohl von den Fujitsu-Bausteinen erledigt.
Das halte ich für ein grundlegendes Missverständnis, denn der 6845 greift überhaupt nicht auf den Hauptspeicher zu. Er adressiert zwar Positionen im Hauptspeicher (allgemein: im Bildschirmspeicher), aber die dort stehenden Informationen lässt er andere Teile der Logik bearbeiten - wie geschrieben, werden die gefundenen Daten (je nach System eben 8 oder 16 Bit breit oder auch nur Teile davon) einfach als Adresse an das Character-ROM/RAM angelegt.
Die Datenleitungen, die der 6845 durchaus hat, dienen nur dem Beschreiben und ggfs. Lesen der Register.
Mit diesem Konzept ist es dann möglich, einen Art Graphikmodus zu generieren - wenn in der LUT unter jeder Adresse die Adresse selbst eingetragen wird, fliegt diese quasi raus - der Bildspeicher kann dann als fast-Graphikspeicher dienen - fast deshalb, weil er wg. der nur genutzten 11bit etwas "löchrig" ist.
Da stimme ich halbwegs zu, allerdings sind die tatsächlich noch etwas geschickter drangegangen. Zunächst einmal wird wirklich das gleiche Konzept wie im Textmodus verwendet, allerdings wird im Grafikmodus der Bildschirmspeicher mit 1250 "Zeichen" gefüllt, die alle einen anderen Code haben (das ist vermutlich das, was Du mit "unter jeder Adresse die Adresse selbst" meinst). Im Wesentlichen zeigen dann diese 1250 Zeichen dauerhaft auf 1250 aufeinanderfolgende, voneinander unabhängige "Zeichenbeschreibungen" im Hauptspeicher. Dort wird dann die Grafik erzeugt. Also eine etwas ungewöhnliche Logik: Der Inhalt des Bildschirmspeichers bleibt konstant, dafür wird ständig der "Zeichengenerator" den Erfordernissen angepasst. Im Hauptspeicher liegt tatsächlich ein lineares Bild aller Pixel auf dem Bildschirm. Löcher entstehen deshalb nicht, weil im Grafikmodus alle 16 Bit des "Zeichengenerators" genutzt werden (das ist wohl der von Dir vermutete "Hack"). Deshalb kommen die auch mit 1250 "Zeichen" aus: Diese Zeichen habe 16 Pixel Höhe (wie immer), aber jetzt 16 Pixel Breite.
256 Pixel/"Zeichen" * 1250 Pixel sind genau die 320.000 Pixel, die im 800*400 Modus möglich sind.
U.A. muss aber deshalb das Schieberegister sowohl 10 Bit (Zeichenbreite im Textmodus) als auch 16 Bit ("Zeichen"breite im Grafikmodus) schieben können.
Das für das Problem aber entscheidende ist - die Adressen kommen letztlich immer vom 6845!
Nein, nur die Adressen für die Zeichen(-codes) im Bildschirmspeicher. Die Adressen für die Zeichendarstellung (Character-RAM) kommen i.W. aus den Daten des Bildschirmspeichers.
Und dazwischen und rundherum sind noch eine Menge Register und Bustreiber und Multiplexer und was weiß ich noch für Zeugs, die u.A. ja etwas Adressarithmetik, Entkoppelung von der CPU etc. machen müssen. In meinen Augen auch viele Kandidaten für einen Fehler.
Sorry für den Umfang; ich hoffe, es war noch lesber. Ich habe grundsätzlich Probleme, komplexe Sachverhalte mit wenigen Worten treffend zu beschreiben. 
würde das aber nicht als Vergewaltigung sehen
"Vergewaltigung", weil der 6845-Buszugriff "missbraucht" wird - eigentlich möchte der 6845 mit seinem Buszugriff eine Zelle im Hauptspeicher adressieren, indem er die nächste Adresse zum Adressieren des Character-RAMs/ROMs findet - diese Adresse befördert er über seine Datenleitungen an das Character-RAM/ROM. Hier aber wird der Zugriff quasi entführt - die Datenleitungen laufen ins Leere, während die Adressen teilweise via SRAM/LUT "übersetzt" werden, aus eigentlich einem Zugriff in den Hauptspeicher um eine Adresse zu holen, werden zwei Zugriffe gemacht (verantwortlich wohl ein MB156xy), die Characterpixel aus dem Hauptspeicher holen.
Das halte ich für ein grundlegendes Missverständnis, denn der 6845 greift überhaupt nicht auf den Hauptspeicher zu.
Da liegt kein grundlegendes Missverständniss vor, das ganze ist eine Frage, wie man das, was geschieht, umschreibt - wenn ich sage, der 6845 greift zu, beschreibe ich das, was der 6845 meint zu tun - dass ihm der Zugriff weitestgehends geklaut wird, geht an ihm vorbei.
Und ob man den Zeichengenerator als Lookup-Table bezeichnen kann
Nicht der Zeichengenerator ist die LUT, sondern das SRAM, in dem Fall eine LUT zum übersetzten von Adressen (meistens werden mit einer LUT Daten übersetzt).
Nein, nur die Adressen für die Zeichen(-codes) im Bildschirmspeicher. Die Adressen für die Zeichendarstellung (Character-RAM) kommen i.W. aus den Daten des Bildschirmspeichers.
??? Nicht gut, zwei anscheinend unterschiedliche Dinge mit dem gleichen Namen ("Bildschirmspeicher") zu belegen.
Für mich ist das SRAM eine LUT, der Bildspeicher liegt im Hauptspeicher und enthält Character (die Zugriff erfolgen dann quasi "random") oder eine Grafik (dann erfolgt der Zugriff "liniar nacheinander").
Und die Adresse kommt eigentlich nur vom 6845, sie wird nur teilweise übersetzt. Wenn sie nicht korrekt ist, wird sie auch nach der Übersetzung nicht korrekt sein (die LUT korrigiert schließlich nichts).
PS. Natürlich kann die Adresse auch bei der Übersetzung oder danach verfälscht werden - wegen des "konstanten Offsets" vermute ich den Fehler aber an einer Stelle, nach der noch "gerechnet" wird - und das könnte eben am ehesten im 6845 sein (ich seh' im Moment keine notwendigkeit, dass in einem MB156xy gerechnet werden müsste).
Hi,
da liegen wohl zwei ziemlich unterschiedliche Vorstellungen von der Funktion und den Fähigkeiten des 6845 vor, und ich fürchte, dass wir darüber das Ziel etwas aus den Augen verlieren.
Offensichtlich gibt es einen zentralen Punkt, an dem wir auseinander laufen:
eigentlich möchte der 6845 mit seinem Buszugriff eine Zelle im Hauptspeicher adressieren, indem er die nächste Adresse zum Adressieren des Character-RAMs/ROMs findet - diese Adresse befördert er über seine Datenleitungen an das Character-RAM/ROM.
Ich lese das so, dass der 6845 eine Adresse ausgibt, um das unter dieser Adresse befindliche Byte (mit Hilfe seines Datenports) zu lesen und in einem zweiten Schritt (wieder über seinen Datenport) an das Character-ROM/RAM zu schicken.
Das lese ich im Datenblatt anders. Dort steht z.B. in der Einleitung:
"The CRTC provides video timing and refresh memory adressing." (Mit refresh memory ist der Bildschirmspeicher gemeint.)
Und in der Beispielapplikation aus, die Du im Posting 6 angehängt hast, werden ebenfalls die Datenausgänge des Refresh RAM/Bildschirmspeichers direkt über ein Latch an das Character-ROM geliefert; der CRTC liefert nur 4 Rasterzeilenadressen dazu.
Immerhin scheinen wir uns (bis auf evtl. Begrifflichkeiten) einigermaßen einig darüber zu sein, wie der 6845 im Victor/Vicki eingesetzt wird. Ich denke, das sollte die Basis für die weitere Fehlersuche sein
Im Übrigen finde ich Deine Unterstützung großartig und freue mich immer wieder über neue Impulse von Dir.
Georg
??? Nicht gut, zwei anscheinend unterschiedliche Dinge mit dem gleichen Namen ("Bildschirmspeicher") zu belegen.
Ich weiß, es liest sich sperrig, aber ich denke, dass ich es richtig geschrieben habe. Bildschirmspeicher (im Datenblatt Refresh Memory) ist der Speicher, wo ein zeichenbasiertes Videosystem seine Inhalte anlegt, d.h wenn auf dem Bildschirm links oben "Hallo Welt!" erscheinen soll, steht am Anfang des Bildschirmspeicher so was wie
48h, 61h, 6Ch, 6Ch, 6Fh, 20h, etc.
Für "das andere" habe ich einigermaßen konsequent den Begriff Character-RAM bzw. -ROM genutzt - dort steht eben, dass das Zeichen 48h (z.B.) so aussieht:
00000000b, 11000110b, 11000110b, 11111110b, 11000110b, 11000110b, 00000000b
Jetzt noch mal mein Satz von oben:
"Nein, nur die Adressen für die Zeichen(-codes) im Bildschirmspeicher. Die Adressen für die Zeichendarstellung (Character-RAM) kommen i.W. aus den Daten des Bildschirmspeichers."
Ich benutze zwar zwei mal den Begriff Bildschirmspeicher, aber einmal rede ich von dessen Adresse, und beim zweiten mal von seinen Daten:
CRTC liefert die Adressen für die Codes -> Bildschirmspeicher.
Bildschirmspeicher liefert Daten - diese dienen als Adressen für die Zeichendarstellung -> Character-RAM.
Das lese ich im Datenblatt anders. Dort steht z.B. in der Einleitung:
"The CRTC provides video timing and refresh memory adressing." (Mit refresh memory ist der Bildschirmspeicher gemeint.)
Und in der Beispielapplikation aus, die Du im Posting 6 angehängt hast, werden ebenfalls die Datenausgänge des Refresh RAM/Bildschirmspeichers direkt über ein Latch an das Character-ROM geliefert; der CRTC liefert nur 4 Rasterzeilenadressen dazu.
Ich hab' das sicherlich etwas missverständlich formuliert - besser vielleicht so - der 6845 adressiert den Bildspeicher, so dass dieser auf dem Datenbus die Adresse des nächsten Characters ausgibt (ob der 6845, bei einfachen Systemen mit seinem Datenbus an diesem Datenbus hängt oder bei aufwendigeren Systemen mit mehrenen Bussen und Bussegmenten über Treiber/Multiplexer abgetrennt ist, ist Nebensache, da er selbst diese Adresse ja nicht braucht, sie ja nur zum Character-ROM befördern muss). Und das tut er - in besagtem Bild über den gleichen Weg, wie er auch den Refresh durchführt - der Refresh selber ist nur ein Goodie, der fast kostenlos dazugegeben werden kann, weil dieser Adressierungspfad existiert und sicherlich auch Sinn macht, weil dann der Refresh in die Austastlücke geschoben werden kann.
Und natürlich liefert der CRT auch die Adresse für die aktuell auszugebene Characterzeile.
"Nein, nur die Adressen für die Zeichen(-codes) im Bildschirmspeicher. Die Adressen für die Zeichendarstellung (Character-RAM) kommen i.W. aus den Daten des Bildschirmspeichers."
Ich würde das Character-RAM nicht im Bildspeicher verorten sondern im "Hauptspeicher" (bei Victor), selbst wenn der dafür genutzte Speicherbereich im Graphikmode als "Bildspeicher" genutzt wird. Im Bildspeicher stehen im Chracter-Modus die Ascii-Zeichen, im Grafik-Modus die Grafik - und nur im Grafik-Modus befinden sich gegebenenfalls im Bildspeicher Character.
Das ist aber Ansicht- oder Definitionsache - man muss nur verstehen, was der andere meint - ich hatte immer den Eindruck, dass bei Dir das, was ich als LUT bezeichne, auch unter Bldlspeicher läuft.
Und das tut er - in besagtem Bild über den gleichen Weg, wie er auch den Refresh durchführt - der Refresh selber ist nur ein Goodie, der fast kostenlos dazugegeben werden kann, weil dieser Adressierungspfad existiert und sicherlich auch Sinn macht, weil dann der Refresh in die Austastlücke geschoben werden kann.
Noch 'ne kleine Ergänzung - während der 6845 bei einem Refresh nur die RAS-Adressen über dies Adresspfad liefert, werden über diesen Pfad bei "normalen" Zugriffen nacheinander die RAS-, dann die CAS-Adressen transferiert.
Wenn ich jetzt etwas genauer (eigentlich sollte ich was anderes machen) ins Datenblatt schaue, komm' ich echt ins grübeln 
- mein zweiter Eindruck allerdings, hier scheint mir die Motorala-Beschreibung ziemlich dämlich zu sein. Die reden vermutlich von Refresh Memory, wenn andere von DRAM sprechen und von Refresh Adressen, was andere mit RAS/CAS-Adressen bezeichnen. Ich wüßte auch nicht, wo im allgemeinen sonst die Adressen herkommen sollen (bei der Vicki kämen natürlich noch Fujitsu-Bausteine in Frage), die CPU würde das komplett überlasten!
Ich finde nicht mal einen passenden Block im 6845, der dafür zuständig sein könnte, das zu liefern, was man landläufig als "Refresh-Adresse" bezeichnet. Weiß' jetzt gar nicht mehr woher ich die Information mit dem Refresh in der Austastlücke her habe - doch nicht etwa aus der inflationären Verwendung des Begriff "Refresh" im MC6845-Datenblatt.
Andererseits führt bei dem 9000 Plan eine Linie von CRT zu einem Block Namens "Refresh Control" (aber keine Adressen!), so dass das mit dem Refresh in der Austastlücke doch wahrscheinlich ist.
Vorläufiges Resümee - der 6845 liefert gar keine "Refresh-Adressen (im landläufigen Sinn) und selbst das Multiplexen der RAS-, dann der CAS-Adressen muss extern gemacht werden.
Ich komme mir vor, wie die Königskinder, die nicht zueinander finden 
Können wir uns mal einigen, was wir unter Bild(schirm)speicher verstehen?
Für mich ist das immer das SRAM. Auch wenn im Grafikmodus darin sicherlich nichts steht, was irgendwie mit dem Inhalt des Bildschirms zu tun hat. Und das Character-RAM liegt im Hauptspeicher - auch wenn im Grafikmodus dort keine "Zeichenaufbauinformationen" liegen.
Ich bin halt eindeutig textorientiert; liegt vermutlich daran, dass ich aktuell nur den Textmodus der Vicki untersuche.
Dagegen scheint für Dich der Begriff Bildspeicher grundsätzlich den Speicherbereich zu benennen, der das Aussehen des Bildschirms bestimmt, und das ist je nach Modus mal das SRAM (Textmodus), mal die 40k Hauptspeicher (Grafikmodus).
man muss nur verstehen, was der andere meint - ich hatte immer den Eindruck, dass bei Dir das, was ich als LUT bezeichne, auch unter Bldlspeicher läuft.
Richtig - was im Textmodus vermutlich auch bei Dir zu keinem Widerspruch führt.
So, jetzt noch kurz zum Thema Refresh:
Ich hatte das bisher nie angeschnitten und möchte mich damit eigentlich auch gar nicht beschäftigen. Die SRAMs (Bildschirmspeicher ) brauchen keinen Refresh, und der Hauptspeicher muss so oder so refreshed werden - nicht nur die 4K-40K, mit denen der CRTC (indirekt) zu tun hat (und der in der Standardapplikation eh ein ROM ist).
Das kommt durch die unglückliche (antike) Terminologie in dem Datenblatt: Der Videospeicher muss periodisch den Bildschirm "auffrischen" und heißt deshalb in dem Papier Refresh Memory. Hat mit dem Thema Speicherrefresh oder DRAM zunächst mal gar nichts zu tun - wobei ich auch im Kopf hatte, dass der 6845 - wie Du beschrieben hast - als Nebenprodukt seinen *Videospeicher* (d.h. die max. 16 KB), so es sich denn um DRAM handelt, tatsächlich mit einem "Speicherrefresh" versorgen kann. Ist aber egal, wichtig ist der Unterschied: refresh memory (dient zur Auffrischung des Bildes) vs. memory refresh (frischt den Speicher auf).
Schau mal in mein Posting, ich habe extra den aus dem Original zitierten Begriff "Refresh Memory" übersetzt (natürlich wieder mit Bildschirmspeicher - Georg ist im Textmodus), weil ich selber schon drüber gestolpert war ...
Ich wollte genau diese Verwirrung vermeiden, wollte aber auch das Zitat nicht verändern 
Ok - wenn ich Fig. 4 betrachte und lese "When the CRTC detect the rising edge of LPSTB in this period, the CRTC sets the Refresh Memory Address 'M+2' into the LIGHT PEN REGISTGER" wird klar, dass das ein richtige Addresse eines Zeichens auf dem Bildschirm ist, und nicht das, was man in Verbindung mit DRAM als "Refresh-Addresse" bezeichnet.
Im MC6845-Datenblatt ist mit "Refresh-Memory" nicht ein DRAM gemeint, sondern der Speicher, aus dem der Bildschirm "refreshed" wird!
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 ... 
Dagegen scheint für Dich der Begriff Bildspeicher grundsätzlich den Speicherbereich zu benennen, der das Aussehen des Bildschirms bestimmt, und das ist je nach Modus mal das SRAM (Textmodus), mal die 40k Hauptspeicher (Grafikmodus).
Yepp - so würde ich es sehen. Und weil das SRAM in beiden Fällen letztlich eine Adressübersetzung macht, ist es für mich "die LUT"
So, jetzt aber genug für diese Nacht
Yepp - gute Nacht
Für mich ist das immer das SRAM. Auch wenn im Grafikmodus darin sicherlich nichts steht, was irgendwie mit dem Inhalt des Bildschirms zu tun hat. Und das Character-RAM liegt im Hauptspeicher - auch wenn im Grafikmodus dort keine "Zeichenaufbauinformationen" liegen.
Das SRAM im Grafik-Modus "Bildspeicher" zu nennen, macht meines Erachtens keinen Sinn.
Darüber hinaus wird der Bildspeicher in vielen gängigen 6845-Systemen im Hauptspeicher liegen, und das "separate Ding" ist dann das Character-ROM (und könnte auch ein Character-RAM/SRAM sein). Gut möglich (ist müsste die Postings mal durchgehen), dass ich mitunter den gängigen Fall im Sinn hatte, Du die kongreten Vicki-Verhältnisse.
"Referring to Figure 2, the CRT controller generates the refresh addresses (MA0-MA13), ..."
Ja, dies und ähnliches haben bei mir sicherlich den Eindruck entstehen lassen, das der 6845 auch das DRAM-Refreshen übernehmen kann!
Jetzt wieder zum eigentlichen Problem - ich möchte einen schon genannten Punkt etwas hervorheben.
Wenn "irgendwo" Bit5 auf "1" geklemmt ist, werden aus großen Buchstaben kleine Buchstaben, mithin könnte man von einem Offset von 32 sprechen - das träfe aber auf die kleinen Buchstaben nicht zu, die blieben was sie sind, ihr Offset wäre 0. Wenn also über alle Zeichen hinweg ein konstanter Offset im Spiel ist, muss meines Erachtens "Rechnen" im Spiel sein. Gerechnet wird im Bild im gelben Block - ob eine fehlerhafte Rechnung selbst einen konstanten Offset erzeugen wird, halte ich jetzt nicht für übermäßig wahrscheinlich - eher habe ich die Operanten im Verdacht. Und über das Start Address Register kam da bei mir eben auch das ROM ins Spiel. Auch wenn der Check dies quasi ausschließt, würde ich das noch nicht ganz abhacken - der Check ist vermutlich nicht so toll (ich gehe mal davon aus, dass dort keine Fletcher-Summe gebildet wird, müsste das aber noch überprüfen), so dass sich zwei Fehler durchaus auch aufheben könnten. Auf jeden Fall würde ich den Fehler wg. des konstanten Offsets vor der roten 'Linie vermuten.
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.
Es lag mir schon seit Samstag auf der Zunge
Sicher was dran - allerdings lernt man so die Systeme auch etwas besser kennen und erspart sich vielleicht auch den einen oder anderen unnötigen Tausch.
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
