Announcement: there is an English version of this forum on 
VT100-Terminal (VGA+PS2) In einigen Mikrokontrollerprojekten (CP/M) erfolgt eine Datenausgabe/Eingabe über eine serielle Schnittstelle. Anbei ein passendes VT-100 Terminal mit VGA-Ausgabe und PS-2 Tastatur. Die Videoaufbereitung und Tastaturabfrage erfolgt über einen Propeller. Die Terminalschnittstelle wahlweise über USB oder RS232. Alle Unterlagen liegen hier: http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/VT100/?sortdir=down Die derzeit realisierten Steuercodes sind im Dokument VT100-Code.pdf zu finden. Wordstar oder Turbo Pascal laufen vollständig. Schaltungen im Verzeichnis /docs der Quellcode im Verzeichnis /source In der Version 1.0 war noch ein Hardwarebug. Im Schaltungsteil der Signalquellenumschaltung muss etwas manuell nachgebessert werden. Ansonsten ist die LP vollständig funktionsfähig. Ich würde alle noch vorhandenen Platinen (derzeit 10 Stück) jeweils bei Erstattung des Portos an Interessenten versenden. Außerdem gibt es eine Neuauflage mit korrekter Signalquellenumschaltung. Wer daran Interesse hat, meldet sich einfach per PM bei mir.
Angehängte Dateien:
-
VT100_1.jpg
360 KB -
VT100_2.jpg
55 KB -
VT100_3.jpg
49 KB
Ich würde mal so eine Platine nehmen wollen, evtl. auch gleich den Propeller dazu. Ich würde das Ding mit gängigen Editoren an einer PDP11 mal testen wollen und ich bin mir sicher das da noch etliche VT100 Sachen noch nicht so laufen werden wie es eine DEC PDP11 erwartet :-) Wie sieht es mit der Fuktion der Gold - Taste aus? Gruß, Holm
Hallo Joe, es wäre gut, wenn hier eine kleine Spec stehen würde, was das Ding genau macht und wie und wofür man es verwenden kann. Nicht jeder hat denn Thread von Anfang an mit verfolgt. Darüber hinaus kann nicht jeder einen propeller programmieren, liegt der dann dabei?.
Holm Tiffe schrieb: > Wie sieht es mit der Fuktion der Gold - Taste aus? Du solltest aber wissen, dass für die "besondere" Funktion der Gold-Taste die Software auf deiner PDP11 zuständig ist und nicht das Terminal. Da kommt - wie bei anderen Funktionstasten - nur ein ESC-Code raus. Außerdem hat er ja geschrieben: > Die derzeit realisierten Steuercodes sind im Dokument VT100-Code.pdf zu > finden.
Holm Tiffe schrieb: > Ich würde das Ding mit gängigen Editoren an einer PDP11 > mal testen wollen und ich bin mir sicher das da noch etliche VT100 > Sachen noch nicht so laufen werden wie es eine DEC PDP11 erwartet :-) Schätze auch, daß da einiges fehlt z.B. Umschaltung des keypad mode application/numeric), da der bisherige Benutzerkreis eher keine DEC-Computer daran anschließt. Aber du könntest die fehlenden Funktionen ja dann gerne beisteuern. > Wie sieht es mit der Fuktion der Gold - Taste aus? Das VT100 an sich hat keine Gold-Taste. ;) http://vt100.net/docs/vt100-ug/chapter1.html#F1-2 Die Terminalplatine ist für den Anschluß einer PS/2-Tastatatur vorgesehen. Deren numerisches Keypad hat leider eine Taste zu wenig. Auch wenn man die obere Reihe mit PF1 - PF4 belegt, wird sich z.B. EDT damit nicht blind bedienen lassen. Christian J. schrieb: > es wäre gut, wenn hier eine kleine Spec stehen würde, was das Ding genau > macht und wie und wofür man es verwenden kann. Nicht jeder hat denn > Thread von Anfang an mit verfolgt. Die "kleine Spec" findest Du tausendfach im Netz. Und den von Joe geposteten Link anschauen, oder mal im Beitrag "CP/M auf ATmega88" blättern, ist wirklich zuviel verlangt? > Darüber hinaus kann nicht jeder einen propeller programmieren, liegt der > dann dabei?. Doch, das kann jede/r, die/der Buchstaben und Zahlen auf Bildschirm und Tastatur unterscheiden kann, und beim Versuch, ein Kabel in eine Buchse zu stecken, auch mal trifft.
Ich gebe zu, mein Einführungstext war mehrdeutig. Allgemeines Wer die alte Version haben möchte, sende mir bitte nochmals eine Mail mit dem Hinweis „alte Version“. Wer lieber auf die neue Version warten möchte, den Hinweis „neue Version“. Die alte Version ist sofort verfügbar (10 Stück), die neue Version würde ich erst in Auftrag geben (8AT + Versand aus China). Propeller IC’c habe ich derzeit noch 10 Stück a 8.09 €. Für den Signalquellenumschalter benötigt man noch einen 74LV4053 (noch 8 Stück vorrätig). Als Gehäuse dient ein AKG 71 24 100 ME von Fischer. Propeller Die Software liegt als Quellcode und Bin-File im SVN. Die Programmierung kann sehr einfach über das zugehörige Propeller-Tool und die USB-Schnittstelle erfolgen. Da die Hardwareversion 1.0 den Mux direkt mit dem Propeller verbindet, kann man sich prima durch Fehlprogrammierung aussperren :-( In der Version 1.1 gibt es nun einen Jumper der dies verhindert. V24 Realisiert ist ein DTE an einem 9 poligen Stecker. Von der Software wird derzeit nur Rx und Tx unterstützt. Ich werde jedoch noch eine „Vollverdrahtung“ realisieren. Da es aber ein DTE ist, kann kein USB-Seriell-Adapter direkt angeschlossen werden. Dieser Stecker ist also tatsächlich für ein Nullmodemkabel vorgesehen.
Joe G. schrieb: > In der Version 1.0 war noch ein Hardwarebug. Im Schaltungsteil der > Signalquellenumschaltung muss etwas manuell nachgebessert werden. > Ansonsten ist die LP vollständig funktionsfähig. Hi! Ich hab grad die Doku durchgesehen. Was muss nachgebessert werden? Ich habe dazu nichts gesehen.
Harald Nagy schrieb: > Was muss nachgebessert werden? Der Unterschied wird zwischen den Varianten Version 1.0 und Version 1.1 deutlich. In der Version 1.0 ist der Multiplexer leider falsch beschaltet. Der Fehler läßt sich leich mit einigen kleinen Drähtchen korregieren. Ich hatte die Steuereingänge mit den Datenausgängen vertauscht :-( Als Quarz muß ein 5 Mhz Quarz bestückt werden, der Pieper muß entgegen der aufgeführten Bestückungsvariante um 180 Grad gedreht eingelötet werden. In der Ver. 1.1 ist nun zusätzlich die RS232 voll beschaltet, also mit DTR,DSR,RTS,CTS.
:
Bearbeitet durch User
So, Platine ist angekommen. Obwohl ich doch reichlich gesucht habe - aber einen Schaltplan und/oder Teileliste habe ich nicht gefunden. Von daher weiß ich gerade nicht weiter... Die "Idee" kann ich mir sicher aus der schon existierenden CPM/VGA-Platine ableiten. Daher würde ich annehmen, dass ich mindestens den FT232 und MAX232 weglassen kann und RX/TX von einem AVR direkt auf den Propeller geben kann, wenn ich kein USB oder RS232 haben will. Zum USB-Anschluss habe ich auch noch eine Verständisfrage: Wozu ist der gut? Ist das ein USB-Host, an den man den CPM-Stick anschließen könnte oder...? Dann könnte ich aber auch direkt die RX/TX drauf geben. Danke euch!
> Obwohl ich doch reichlich gesucht habe - aber einen Schaltplan und/oder > Teileliste habe ich nicht gefunden. Wo denn? Joe G. schrieb: > Alle Unterlagen liegen hier: > http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/VT100/?sortdir=down
Leo C. schrieb: >> Obwohl ich doch reichlich gesucht habe - aber einen Schaltplan und/oder >> Teileliste habe ich nicht gefunden. > > Wo denn? > > Joe G. schrieb: >> Alle Unterlagen liegen hier: >> http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/VT100/?sortdir=down genau hier - aber im DOC-Verzeichnis liegen ja nur die Layouts und ein Bestückungsplan ohne Werte und kein Schaltplan - oder bin ich blind?
Marcel A. schrieb: > dass ich mindestens > den FT232 und MAX232 weglassen kann und RX/TX von einem AVR direkt auf > den Propeller geben kann, wenn ich kein USB oder RS232 haben will. In der Tat, wenn du keinen Pegelwandler benötigst oder nicht auf eine virtuelle COM-Schnittstelle umsetzen möchtest, kannst du diese IC's (auch den (MUX) weglassen. Allerdings müßte dann der Propeller extern programmiert werden. Der USB-Anschluss ist nicht nur ein virtueller COM-Port sondern auch so beschaltet, dass darüber der Propeller programmiert werden kann.
Stimmt - dafür wäre es schon sinnvoll. Vielleich kann ich doch den FT232 geben einen billigen China-Stick austauschen... @Leo: Mea Culpa. Ich war tatsächlich blind... Danke :-)
Moin, @ Joe alles angekommen, vielen Dank. @ all die Platine läuft auch schon bei mir,allerdings habe ich 2 Fragen: 1. Wie soll die Umschaltung zwischen FTDI und RS232 denn gehen? Dazu müsste der Prop an P0 ein HIGH ausgeben, P0 bleibt aber auf LOW. Und wenn JP1 offen ist, würde das auch nicht gehen. Oder habe ich was übersehen? 2. CTS, RTS, DSR und DTR gehen direkt vom Prop an die RS232. Da liegen normalerweise ca +- 10V, wie beim TX vom MAX. Gruss Peter
Peter Zabel schrieb: > 2. CTS, RTS, DSR und DTR gehen direkt vom Prop an die RS232. > Da liegen normalerweise ca +- 10V, wie beim TX vom MAX. Bitte die Doku VT100_sheet.pdf verwenden NICHT VT100_sheet_V1_1.pdf > 1. Wie soll die Umschaltung zwischen FTDI und RS232 > denn gehen? Dazu müsste der Prop an P0 ein HIGH ausgeben, > P0 bleibt aber auf LOW. > Und wenn JP1 offen ist, würde das auch nicht gehen. > Oder habe ich was übersehen? JP1 existiert nicht in deiner Version. P0 = Low -> USB P0 = High -> RS232 Der Pulldown sorgt dafür, dass bei nicht programmiertem Propeller die Pogrammierung an USB liegt. P0 auf High, in der Software F5, ist noch nicht realisiert.
:
Bearbeitet durch User
Moin Joe, habe ich doch schon längst auf V 1.1 vom 10.1.2015 hochgerüstet (mit JP1). Gruss Peter
Peter Zabel schrieb: > habe ich doch schon längst auf V 1.1 vom 10.1.2015 > hochgerüstet (mit JP1). Na dann selber in der Software Hand anlegen oder bis zum WE warten :-) Ich werde es dann integrieren.
bin leider kein Progammierer, werde dann erstmal ne Brücke legen. Peter
Falls jemand zufälligerweise eine Reichelt-Bestellliste zusammengestellt hat möge er sie hier online stellen. Danke
Peter Zabel schrieb: > Dazu müsste der Prop an P0 ein HIGH ausgeben, P0 bleibt aber auf LOW. Ist jetzt eingebaut. F5 schaltet nun von USB auf RS232 und wieder zurück.
@ Joe Gerade ausprobiert und geht bei mir. Buzzer auch. Vielen Dank. Gruss Peter
Hi! Bin gerade am Zusammenstellen der Stückliste. Einige Fragen taten sich auf: 1) die vier Kondensatoren am MAX3232 sind 100n Kerkos? (lt. DB ist das ok) 2) die Widerstände, Kerkos und LEDs sind alle Größe 1206? 3) den LP2950 finde ich bei meinen üblichen Versendern nicht. Ginge da auch der TS2937CP33? https://www.reichelt.de/TS-2937-CP33/3/index.html?&ACTION=3&LA=446&ARTICLE=115972&artnr=TS+2937+CP33&SEARCH=TS+2937+CP33 4) der Buzzer sollte ja eher unkritisch sein. Ich hätte mir den hier ausgesucht https://www.reichelt.de/SUMMER-CPM-121/3/index.html?&ACTION=3&LA=446&ARTICLE=35924&artnr=SUMMER+CPM+121&SEARCH=piezosignalgeber Danke für's drüberschauen!
Harald Nagy schrieb: > Hi! Bin gerade am Zusammenstellen der Stückliste. Einige Fragen taten > sich auf: > > 1) die vier Kondensatoren am MAX3232 sind 100n Kerkos? (lt. DB ist das > ok) > 2) die Widerstände, Kerkos und LEDs sind alle Größe 1206? > 3) den LP2950 finde ich bei meinen üblichen Versendern nicht. Ginge da > auch der TS2937CP33? Was ist denn mit dem hier - oder muss es SMD sein? http://www.reichelt.de/index.html?ACTION=3;ARTICLE=122756;SEARCH=LP%202950%20ACZ3,3 > https://www.reichelt.de/TS-2937-CP33/3/index.html?&ACTION=3&LA=446&ARTICLE=115972&artnr=TS+2937+CP33&SEARCH=TS+2937+CP33 > 4) der Buzzer sollte ja eher unkritisch sein. Ich hätte mir den hier > ausgesucht > https://www.reichelt.de/SUMMER-CPM-121/3/index.html?&ACTION=3&LA=446&ARTICLE=35924&artnr=SUMMER+CPM+121&SEARCH=piezosignalgeber > > > Danke für's drüberschauen!
Harald Nagy schrieb: > 1) die vier Kondensatoren am MAX3232 sind 100n Kerkos? (lt. DB ist das > ok) Dürte Ok sein, das Datenblatt sagt dazu: The capacitor type used for C1–C4 is not critical for proper operation; polarized or nonpolarized capacitors can be used. > 2) die Widerstände, Kerkos und LEDs sind alle Größe 1206? Ja > 3) den LP2950 finde ich bei meinen üblichen Versendern nicht. Ginge da > auch der TS2937CP33? Ja, aber nur im TO-252 Gehäuse > 4) der Buzzer sollte ja eher unkritisch sein. Ich hätte mir den hier > ausgesucht passt Beim Quarz bitte einen 5 MHz verwenden!
:
Bearbeitet durch User
V1.1 realisiert zwei Kanäle (USB und RS232) mit Full-Null-Modem Beschaltung. Der Multiplexer ist dabei auch gleich weggefallen. Es können nun drei Varianten realisiert werden. 1. USB und RS232 2. nur USB 3. nur RS232 Die Programmierung des Propeller kann über RS232 oder USB erfolgen.
Auch dieses Projekt muss ich für mich als gescheitert erklären (vorläufig). Alles zusammen gelötet, alles durchgemessen. Angesteckt. USB Fehlermeldung wegen Gerätebeschreibung. Am Spannungsregler liegt nur rund 1 Volt an.... Hab heute keine Lust mehr...
Harald Nagy schrieb: > Auch dieses Projekt muss ich für mich als gescheitert erklären Gescheitert ist es erst, wenn du vor dem ziel aufgibst ;-) USB / FTDI ist ja eine Standardbeschaltung. Die 5Volt von der USB Schnittstelle sollten also immer anliegen. Wenn der Festspannungsregler korrekt arbeitet, sollten hinter ihm 3.3V sein.
:
Bearbeitet durch User
Und das ist nicht der Fall (beides). Es liegt nur 1 Volt an. Hinter dem Regler 0.8 was verständlich ist.
Es gibt eigentlich keinen Grund, warum die Spannung zusammenbrechen sollte. Es sei denn, es gibt einen satten Kurzschluss auf der 3.3V Seite. Löte doch mal den 3.3V Regler aus und schaue ob dann die 5V stabil anliegen.
Werde ich machen und doch nochmal alle Verbindungen überprüfen. Aber sollte dann nicht irgendwas rauchen oder zumindest warm werden? Der USB Port trennt ja auch nicht, sagt nur er erkennt das Gerät nicht. Trennung kommt nur wenn ich versuche die Spannung direkt an der USB Buchse zu messen. Da dachte ich mir das sei normal....
Sobald die 5 Volt anliegen, sollte der FT323 sofort als USB Gerät erkannt werden. Wenn der entsprechende Treiber (virtual COM Port) noch nicht installiert ist, sollte dieser nun noch eingerichtet werden. Einen Einfluss auf die 5V hat es jedoch nicht. Solange nicht mehr als 90mA fließen, schaltet der USB-Port nicht ab.
Angehängte Dateien:
-
VT100_Ready.jpg
420 KB
Die Version 1.1 ist aufgebaut und programmiert. Alle neuen Funktionen hatte ich schon hier Beitrag "Re: VT100-Terminal (VGA+PS2)" beschrieben. Die Software wie immer im SVN. Derzeit gibt es 10 Platinen dazu.
Hallo, ich besitze eine 1.0er Platine. Leider würde es keinen Sinn machen, mir alle SMD Teile einzeln zu bestellen, da ich absolut keine SMD Teile besitze (nur Through Hole). Hat jemand vielleicht diese Teile übrig und würde sie mir gegen eine kleine Spende schicken? ;)
Peter T. schrieb: > Gibt es noch Platinen und Spezialteile ? Ja, Platinen und Propeller IC's sind noch verfügbar.
zur Info Leiterplatte Version 1.1 2,30€/Stück, noch 9 Stück vorhanden Propeller 8.09€/Stück, noch 6 Stück vorhanden Porto+Polsterumschalg 1.65 Summe 12€/Satz @Pitt Dein Brief geht dir heute noch zu.
Hallo Joe, hast du noch eine VT100-Terminal (VGA+PS2) V1.1 Leerplatine und bereits programmierten Propeller? falls Du alle Bauteile vorrätig hättest würde ich auch gerne einen Komplettbausatz nehmen Nenn mir doch bitte die Zahlungsmöglichkeiten. Vielen Dank Michael
Hallo Joe, hast du noch eine VT100-Terminal (VGA+PS2) V1.1 Leerplatine und bereits programmierten Propeller? falls Du alle Bauteile vorrätig hättest würde ich auch gerne einen Komplettbausatz nehmen Nenn mir doch bitte die Zahlungsmöglichkeiten. Vielen Dank Michael
Michael S. schrieb: > hast du noch eine VT100-Terminal (VGA+PS2) V1.1 Leerplatine und bereits > programmierten Propeller? Eine Platine und ein Propeller-IC (unprogrammiert) ist verfügbar. Die Programmierung kann sehr einfach direkt über USB oder RS232 auf dem VT100 Board erfolgen. Die Software liegt sowol als Quelltext als auch als Binärfile vor. Die Zahlung erfolgt einfach nach Lieferung. Gruß Joe
Ich habe mal hier [1] versucht alle Informationen zum Aufbau des VT100 zu bündeln. Vielleicht macht es den Nachbau etwas einfacher :-) [1] http://www.openmechatronics.de/?Home
:
Bearbeitet durch User
Hier ist eine neue Test - Software für das Terminal. Da die Unterschiede zwischen der AVR-CP/M- und der Standalone-Version des Terminals gering sind, wurden die beiden Varianten zusammen gelegt. Es gibt in Zukunft also nur noch eine Software für beide Varianten (von mir). Mich würde nun interessieren, ob die Erkennung überall zuverlässig funktioniert. Außerdem würde ich mich freuen, wenn einige Leute weitere Funktionen testen würden, und Ihre Meinung/Kritik dazu abgeben würden. 1. Synchronisiert der Monitor zuverlässig? Mein LS-8 von Pollin ist etwas zickig und tat es mit den ursprünglichen Werten nicht. Inzwischen habe ich bemerkt, daß das Display mit den aktuellen Einstellungen auch nicht immer richtig synchronisiert. In der Datei 'vgacolour.spin' sind verschiedene Parametersätze zum Ausprobieren. 2. Welchen Font sollen wir nehmen? In der Test-Version sind 3 verschiedene Fonts eingebaut, die über das Setup-Menü (F7) gewechselt werden können. Mit der ESC-Sequenz 'ESC # 9' kann ein "Testbild" mit dem kompletten Font auf dem Bildschirm dargestellt werden. Inzwischen habe ich Terminus entdeckt. Der ist auch noch einen Versuch wert. 3. Farben? Ich habe versucht, die Farbpalette auf die Werte der Tabelle in [1] zu ändern. Die Zahlenwerte in Spalte 1, 'Standard VGA colors', (0, 85, 170, 255) entsprechen genau den Möglichkeiten unserer, Hardware, und die alte Palette paßt nicht in das ECMA-48, bzw. ISO-6429 Schema. Leider sieht das Ergebnis auf meinem Display sehr bescheiden aus. Helle und dunkle Farben sind kaum voneinander zu unterscheiden. Wie sieht das bei Euch aus? Zum Testen kann man z.b. die angehängte Datei 'colors.vt' auf das Terminal ausgeben. 4. Attribute Was braucht man denn noch, bzw. was wäre wünschenswert? Wir haben Farben, bright, und invers. Zusätzlich möglich wären Unterstreichen, bold, blinken (nur wenn man mich zwingt). Problem ist der Textspeicher Z.Zt. belegt jedes Zeichen 2 Byte. 8 Bit für das Zeichen und je 4 Bit für Vorder- und Hinter- grund-Farbe. Wenn man sich auf einen Font mit 127 Zeichen einigen könnte wäre ein Bit für ein Attribut frei. Zur Zeit ist das so für die Fonts 0 und 1 zum Unterstreichen realisiert. Ein Bit könnte man gewinnen, wenn man sich auf 8 Hintergrund-Farben beschränkt. Man könnte auch den Textspeicher um ein oder 2 Byte pro Zeichen erweitern. Dann hätte man genügend Platz um alle Attribute zu realisieren. Wahrscheinlich reicht dann aber der Platz für den Programmcode nicht mehr aus. ;-) Das reicht mal für den Anfang. Happy Testing [1] https://en.wikipedia.org/wiki/ANSI_escape_code#Colors
Für alle Tester unter Windows, bitte in der Keyb-de.spin den Quellcode
an dieser Stelle korregieren. Hier hat die Umlautkonvertierung Mist
gemacht.
{{ for keyboard-de start }}
cmp data,#de_ae wz 'replace ae
if_z mov data,#"ä"
cmp data,#de_oe wz 'replace oe
if_z mov data,#"ö"
cmp data,#de_ue wz 'replace ue
if_z mov data,#"ü"
Angehängte Dateien:
-
Pollin.jpg
130 KB
Kurze Rückkopplung. Super Arbeit! Auf dem PC-Monitor sieht Font 2 trotz fehlenden Abstand bei einigen Zeichen optisch am besten aus. Auf dem Pollin Teil Font 1. Font 0 sieht bei beiden Monitoren nicht so schön aus. Bei der Synchronisation sieht es bei beiden Bildschirmen am besten bei ' --> fH: 31,3 KHz fV 59,5 Hz aus. Sie synchronisieren sehr sauber. Zu den Farben kann nicht noch nichts sagen, das erfordert mehr Arbeit. Doch das angefügte Bild auf dem Pollin Bildschirm (10,4 Zoll) wollte ich dir nicht vorenthalten. Es ist tatsächlich ein Foto vom Bildschirm. Ein wirklich super Bild!
Joe G. schrieb: > {{ for keyboard-de start }} Das Properller-Tool tut so, als könnte es utf-8 verarbeiten, kann es aber nicht, im Gegensatz zu BST. Ich bin auch erst auf utf-8 umgestiegen, nachdem ich mich vergewissert hatte, daß man die Dateien problemlos auf utf-16 zurück konvertieren kann. Z.B. mit recode oder iconv. Ich habe das "Problem" jetzt so gelöst:
1 | cmp data,#de_ae wz 'replace ae |
2 | if_z mov data,#$E4 |
3 | cmp data,#de_oe wz 'replace oe |
4 | if_z mov data,#$F6 |
5 | cmp data,#de_ue wz 'replace ue |
6 | if_z mov data,#$FC |
Joe G. schrieb: > Auf dem PC-Monitor sieht Font 2 trotz fehlenden Abstand bei einigen > Zeichen optisch am besten aus. Mich stört der fehlende Abstand. Man müßte zwischen je 2 Zeichen eine zusätzliche Punktspalte einfügen. Mit der bestehenden Scanroutine ist das aber nicht zu machen. Wenn man 2 weitere Cogs spendieren würde, könnte es gehen. Ist aber verhältnismäßig viel Aufwand, und mit den Cogs habe ich eigentlich noch anderes vor. > Auf dem Pollin Teil Font 1. Was für eine Auflösung hat das Display denn? Auf meinem Pollin (LS-8, 1024x768) ist der Font zu dünn. Schräge Linien sehen etwas angefressen aus. > Font 0 sieht bei beiden Monitoren nicht so schön aus. Kein Wunder, das ist ein 8x8 Font, bei dem jede Zeile doppelt dargestellt wird. > Bei der Synchronisation sieht es bei beiden Bildschirmen am Besten bei > ' --> fH: 31,3 KHz fV 59,5 Hz aus. Sie synchronisieren sehr sauber. Ich glaube, daß geht bei mir auch am Besten. Die Parameter sind von hier: http://tinyvga.com/vga-timing/640x480@60Hz Die Werte in der "-->" Zeile sind das, was mein "richtiger" Monitor anzeigt. Dein Bild ist aber wirklich super. Damit meine ich jetzt nicht die Qualität des Videosignals. Ich kriegs so (mit meinem Händi) nicht hin. Entweder habe ich starke Spiegelungen, oder die Bildpunkte sind total überstrahlt. > Zu den Farben kann nicht noch nichts sagen, das erfordert mehr Arbeit. > Doch das angefügte Bild auf dem Pollin Bildschirm (10,4 Zoll) wollte > ich dir nicht vorenthalten. Es ist tatsächlich ein Foto vom Bildschirm. > Ein wirklich super Bild! Bei mir sieht das Grün auf dem LS-8 viel heller aus. Inzwischen habe ich auch noch mal auf dem PC-Monitor geschaut. Da geht es ganz gut. Aber jetzt bin ich dabei, die Palette einstellbar zu machen. (Steuersequenzen, und später auch über Setup). Aber sinnvolle Defaults braucht man trotzdem.
Angehängte Dateien:
-
eizo-palette-vga.jpg
140 KB -
ls8-palette-vga.jpg
140 KB
Jetzt habe ich es doch noch geschafft. Der HD-Monitor ist so eingestellt, daß das Bild nicht skaliert, sondern jeder Punkt 1:1 in der Bildschirmmitte dargestellt wird. In der unteren Hälfte (Bright Forground) sollten alle Zahlen zu sehen sein. Das ist auf dem LS-8 nicht der Fall. Weiß und Hellgrau (Hintergrund der letzten Spalte und der Schrift) sind praktisch nicht zu unterscheiden.
Angehängte Dateien:
-
Pollin_1.jpg
220 KB -
Monitor.jpg
190 KB
Leo C. schrieb: > 4. Attribute > Was braucht man denn noch, bzw. was wäre wünschenswert? > Wir haben Farben, bright, und invers. Ich kann wunderbar mit Font 1 (127 Zeichen) leben. Es muss nicht Codepage 850 sein. Font 1 enthält im unteren Bereich auch ganz nützliche Rahmensymbole. Die zweiten 127 Zeichen würde ich dem unterstrichenen Font spendieren, so wie es jetzt gemacht ist. Bold und blinken muss nicht sein. Bold kann ja individuell mit einer anderen Farbe belegt sein. > Was für eine Auflösung hat das Display denn? Genau 640x480, also optimal. Laut Pollindatenblatt ist es ein G104V1-T01 [1]. > Dein Bild ist aber wirklich super. Spiegelreflexkamera, dunkel, kurze Belichtungszeit, offene Blende :-) Bei mir zeigen beide Monitore das gleiche Farbverhalten (siehe Fotos, links Pollin, rechts Monitor). Das Pollindisplay ist sogar etwas besser im Kontrast. Die Streifen resultieren irgendwie aus der Überlagerung Display - Kamera. [1] http://www.display-solution.com/en/products/tft_displays/chimei_innolux_cmi_lcd/G104V1-T01_en.html
Welche Pollin-Displays verwendet ihr denn genau? Dann könnte ich mir mal eins bestellen.
Marcel A. schrieb: > Welche Pollin-Displays verwendet ihr denn genau? Leo C. schrieb: > Mein LS-8 von Pollin ist etwas zickig und tat es mit den Leo C. schrieb: > Auf meinem Pollin (LS-8, 1024x768) ist der Font zu dünn. Schräge Linien Leo C. schrieb: > Bei mir sieht das Grün auf dem LS-8 viel heller aus. Inzwischen habe ich
Joe G. schrieb: > Ich kann wunderbar mit Font 1 (127 Zeichen) leben. Es muss nicht > Codepage 850 sein. Font 1 enthält im unteren Bereich auch ganz nützliche > Rahmensymbole. So wirds wohl werden. > Die zweiten 127 Zeichen würde ich dem unterstrichenen > Font spendieren, so wie es jetzt gemacht ist. Unterstreichen habe ich jetzt im Treiber hinbekommen. D.h, man kann Speicher für die 128 unterstrichenen Zeichen einsparen. Pro Font sind das 2048 Byte. > Bold und blinken muss nicht sein. > Bold kann ja individuell mit einer anderen Farbe belegt > sein. Das haben wir ja jetzt. Aber solange Platz ist, werde ich weiterhin verschiedene Fonts zum Umschalten einbauen. Es scheint ja so zu sein, daß je nach Display ein Font mit schmaleren oder fetteren Strichen besser aussieht. Ladbare Farbpalette habe ich jetzt auch hinbekommen. Ich hatte die Idee, eine Hintergrundfarbe durch Unterstreichen zu ersetzen. Aber das funktioniert natürlich nicht, da das unterstrichene Zeichen dann ja keine Hintergrundfarbe mehr hätte... >> Laut Pollindatenblatt ist es ein G104V1-T01 Beim Pollin war's aber mit Controller, oder? Und es ist wohl nicht mehr lieferbar. Ich meine, das ist das Display, das ich auch mal kaufen wollte. Aber ich hatte das zu lange aufgeschoben.
Leo C. schrieb: > Beim Pollin war's aber mit Controller, oder? Es waren damals 4 Baugruppen. Display, VGA-Board, CCFL Inverter und Bedienpanel. Die Bestellnummer lautete 007-074-03. Keine Ahnung ob es das noch gibt.
Angehängte Dateien:
-
scs.jpg
98 KB
Im SVN ist ein Update, das die VT100 character sets unterstützt. Wenn wir Umlaute haben wollen, und bei 128 Zeichen bleiben wollen, müßten einige der Zeichen unter "DEC Special graphics and line drawing" ausgetauscht werden. Auf welche Zeichen könnten wir denn verzichten? Edit: Auf dem Foto ist noch ein Fehler zu sehen. Im SVN ist er aber korrigiert.
:
Bearbeitet durch User
Mir ist der Aufruf noch nicht ganz klar, ESC ( oder ) wählen G0 oder G1 und A, B oder 0 dann das jeweilige Set, doch bei mir passiert nichts.
Es gibt 2 Sets, zwischen denen man umschalten kann:
1 | Shift out SO 0x0E Selects G1 character set |
2 | Shift in SI 0x0F Selects G0 character set |
G0 und G1 sind aber nicht fest, sondern können mit verschiedenen Zeichensätzen belegt werden:
1 | Character Set G0 Designator G1 Designator |
2 | ------------------------------------------------------------------- |
3 | United Kingdom (UK) ESC ( A ESC ) A |
4 | United States (US) ESC ( B ESC ) B |
5 | Special chars and line drawing set ESC ( 0 ESC ) 0 |
6 | Alternate char ROM ESC ( 1 ESC ) 1 |
7 | Alternate char ROM - special chars ESC ( 2 ESC ) 2 |
Nach Start/Reset sind sowohl G0, als auch G1 mit US ASCII belegt. Man kann dann z.B. mit "ESC ) 0" den Zeichensatz mit den Spezial- und Liniensymbolen auf G1 legen, und anschließend mit SI und SO zwischen ASCII (G0) und "Special characters and line drawing set" (G1) umschalten. Die Alternate character ROMs haben wir nicht.
Im Anhang ist eine Liste aller derzeit unterstützten Steuerzeichen und -Sequenzen.
Leo C. schrieb: > Shift out SO 0x0E Selects G1 character set > Shift in SI 0x0F Selects G0 character set Danke! Das war der entscheidende Hinweis. Ich muss natürlich mit SI und SO umschalten. Außerdem geht es nur mit FONT 0 oder oder 2. Ich hatte es mit Font 1 versucht :-( > Im Anhang ist eine Liste aller derzeit unterstützten Steuerzeichen und > -Sequenzen. Das deckt sich ja fast mit den Kommentaren im Quelltext ;-) Ich werde in der Doku im Anhang diese Tabelle übernehmen. > Auf welche Zeichen könnten wir denn verzichten? Was so für lustige Zeichen existieren :-) Spontan würde ich sagen 96,98,99, 100,101,104,105 und 127. Die habe ich wirklich noch nie benötigt. Wobei ich mir nicht sicher bin ob bei 127 nicht noch ein Fehler ist. Die Tabelle mit der ich es verglichen habe [1] hat bei 127 das gleiche Zeichen wie bei 32. Für die deutschen Umlaute, also äöüÄÖÜ und ß würden wird 7 Zeichen benötigen. Lassen wir 127 weg, reicht es gerade ;-) [1] http://support.attachmate.com/techdocs/1184.html
> SO umschalten. Außerdem geht es nur mit FONT 0 oder oder 2. Ich hatte es > mit Font 1 versucht :-( Es gibt nur noch Font 0 und 1. Vorher waren das 1 und 2. Ich habe vergessen das Setup-Menu anzupassen. > Das deckt sich ja fast mit den Kommentaren im Quelltext ;-) Drapier ein paar CASE-Statements um die Listeneinträge, und Du hast wieder ein Programm. ;-) > 96,98,99, 100,101,104,105 und 127. Die habe ich wirklich noch nie Auf welche Tabelle bezieht sich Deine Numerierung? > benötigt. Wobei ich mir nicht sicher bin ob bei 127 nicht noch ein > Fehler ist. Die Tabelle mit der ich es verglichen habe [1] hat bei 127 > das gleiche Zeichen wie bei 32. 127 ist ein Steuerzeichen und kann im Grunde ignoriert werden. > [1] http://support.attachmate.com/techdocs/1184.html Da sind die verschiedenen Character Sets mal recht kompakt auf einer Seite.
Leo C. schrieb: > Auf welche Tabelle bezieht sich Deine Numerierung? Auf DEC Special Graphic Character Set (VT Emulation), bei dir Special chars and line drawing set.
Leo C. schrieb: > Im SVN ist ein Update, das die VT100 character sets unterstützt. Wenn > wir Umlaute haben wollen, und bei 128 Zeichen bleiben wollen, müßten > einige der Zeichen unter "DEC Special graphics and line drawing" > ausgetauscht werden. Auf welche Zeichen könnten wir denn verzichten? Deine Frage verstehe ich nicht. Warum willst Du die Umlaute in den Graphic-Character-Zeichensatz knallen? Dafür gibt es doch den German Character Set im VT102-Standard, auswählbar mit <ESC>(K (G0) bzw <ESC>)K (G1). Dabei werden die Zeichen \|{[]}~ durch die deutschen Umlaute bzw. das ß ersetzt. Oder ist dafür nicht mehr genügend Speicherplatz?
Joe G. schrieb: > Auf DEC Special Graphic Character Set (VT Emulation), bei dir Special > chars and line drawing set. Ich war zu schnell mit der Enter-Taste :-( Mit der Nummerierung meine ich den ASCII-Code (dezimal).
Frank M. schrieb: > Dafür gibt es doch den German Character Set im VT102-Standard, > auswählbar mit <ESC>(K (G0) bzw <ESC>)K (G1). National replacement character (NRC) sets Finde ich erst ab VT200, ist aber egal. > Oder ist dafür nicht mehr genügend Speicherplatz? Im Bildwiederholspeicher ist nur für 127 verschiedene Zeichen Platz, wenn wir ein Bit für ein Attribut nutzen. Also können wir nicht mehr Zeichen gleichzeitig darstellen. Mit NRC hätte man zwar die Spezial- und Graphik-Zeichen, aber \|{[]}~ nicht mehr. Und auf letztere will zumindest ich nicht verzichten.
Leo C. schrieb: > Im Bildwiederholspeicher ist nur für 127 verschiedene Zeichen Platz, > wenn wir ein Bit für ein Attribut nutzen. Also können wir nicht mehr > Zeichen gleichzeitig darstellen. Mit NRC hätte man zwar die Spezial- und > Graphik-Zeichen, aber \|{[]}~ nicht mehr. Und auf letztere will > zumindest ich nicht verzichten. Meines Erachtens geht das schon. In den 80ern hatte ich unter UNIX die Aufgabe, eine 8-Bit-fähige Curses-Bibkliothek zu schreiben, die sowohl Graphikzeichen als auch Umlaute als auch französische Sonderzeichen (und noch andere exotische Zeichen) auf den Bildschirm zu bringen, obwohl nur 7-Bit-fähige VT102-Terminals eingesetzt wurden.(*) Die Lösung war folgende: Als Basiszeichensatz wurde ISO8859-1 gewählt (weitestgehend identisch mit dem DEC-Multicharacter-Zeichensatz), also ein 8-Bit-Zeichensatz. Die DEC-Graphikzeichen wurden in den ungenutzten Bereich 0x80-0x9F "eingelagert". Ausgabe der 8-Bit-Zeichen In G0 wurde mittels <ESC>(B der USASCII-Zeichensatz geladen, damit hat man schon mal die halbe Miete. Solte jetzt ein nationales Sonderzeichen (obere 8-Bit-Hälfte von ISO8859-1) ausgegeben werden, wurde über eine Lookup-Tabelle mit "\033)K" /* GERMAN */ "\033)A" /* United Kingdom */ "\033)E" /* DANISH */ "\033)R" /* FRENCH */ "\033)Z" /* SPANISH */ "\033)0" /* GRAPHIC */ G1 mit dem jeweiligen nationalen Zeichensatz geladen, per SO auf G1 umgeschaltet, das 7-Bit-Zeichen ausgegeben und anschließend - wenn wieder ASCII ausreichte - wieder auf G0 per SI umgeschaltet. So konnte fast der komplette ISO8-Zeichensatz über 7-Bit-Output ausgegeben worden. Ein simples addch('ä') löste also den obigen Prozess automatisch aus. (Jetzt magst Du Dich fragen, wie ich das 'ä' überhaupt in den Editor auf einem 7-Bit-Terminal eingeben konnte. Ganz einfach: ich hab mir mit meiner eigenen Curses-Bibliothek als erstes einen 8-Bit-fähigen Editor für 7-Bit-Terminals geschrieben ;-) ) Die damalige Curses-Lib hatte aus Optimierungsgründen ein Abbild des kompletten Terminal-Bildschirmspeichers selbst im Speicher - inkl. der Attribute und Farben. Diese wurden pro Zeichen in einem separaten Byte gespeichert, nämlich 1 Bit für Unterstreichen 1 Bit für Fett 1 Bit für Blinkend 1 Bit für Invers 1 Bit für Rot 1 Bit für Grün 1 Bit für Gelb 1 Bit für Weissichnichtmehr Mit 3 Bit für die Farben (RGB) hat man insgesamt 8 mögliche Farben. Genau diese konnten damals auch damalige VT100/VT200-Terminal-Emulationen. > Im Bildwiederholspeicher ist nur für 127 verschiedene Zeichen Platz, > wenn wir ein Bit für ein Attribut nutzen. Frage: Was ist das für ein Attribut, was Du in dem Bit ablegst? Meines Erachtens ist diese ganze Hampelei mit den nationalen Zeichensätzen ziemlich aufwendig und kompliziert - auch wenn es geht. Wäre es nicht möglich, den kompletten ISO8859-1 (oder ISO8859-15) zu nutzen und die Attribute anderweitig abzulegen? Müsstest Du doch auch schon so machen, denn schließlich kann das Terminal doch mehr als nur 1 Attribut?!? -------------------------------------- (*) Ich habe das Ganze damals in der iX als Artikelreihe mit dem Namen "Zeichensalat" veröffentlicht.
:
Bearbeitet durch Moderator
Joe G. schrieb: > Auf DEC Special Graphic Character Set (VT Emulation), bei dir Special > chars and line drawing set. Ich nehme an, Du meinst die Numerierung in dem angehängten Bild. Den Diamond würde ich gerne behalten. Was wir zur Zeit haben, sieht man mit ESC # 9. Auf 0x02 und 0x7f sind zwei ähnliche Schachbrettmuster, von denen man eins vielleicht weglassen könnnte. Ausserdem könnte man auf das Zeichen auf Position 0 verzichten. Also hätte man 0, 2 oder 0x7F, 3, 4, 5, 6, 9 und 0x0A. Braucht jemand einen '§'?
Frank M. schrieb: > Frage: Was ist das für ein Attribut, was Du in dem Bit ablegst? Unterstreichen. Ich muß jetzt leider weg. Auf den Rest werde ich heute Abend eingehen. Nachtrag hier, da ich den Artikel davor nicht mehr ändern kann: > Was wir zur Zeit haben, sieht man mit ESC # 9. Nur die erste Hälfte ist relevant. Auf die 2. Hälfte wird nicht mehr zugegriffen, da das Unterstreichen im Videogenerator erledigt wird (vgacolor.spin).
:
Bearbeitet durch User
Leo C. schrieb: > Also hätte man 0, 2 oder 0x7F, 3, 4, 5, 6, 9 und 0x0A. Genau diese Zeichen Zeichen meinte ich, ich hatte den ASCI-Code notiert und nicht die Position im Zeichensatz. Ich würde dann lieber die 2 statt 0x7F weglassen, dann sind alle Umlaute in etwa im gleichen Bereich. Der '§' darf ruhig wegfallen. Er wird eh viel zu oft mißbraucht ;-)
Frank M. schrieb: > Als Basiszeichensatz wurde ISO8859-1 gewählt (weitestgehend identisch > mit dem DEC-Multicharacter-Zeichensatz), also ein 8-Bit-Zeichensatz. Die ... > So konnte fast der komplette ISO8-Zeichensatz über 7-Bit-Output > ausgegeben worden. Eben. Das Terminal selbst hatte ca. 256 Zeichen direkt im Zugriff. Nur der Übertragungskanal war auf 7 Bit beschränkt. > Meines Erachtens ist diese ganze Hampelei mit den nationalen > Zeichensätzen ziemlich aufwendig und kompliziert - auch wenn es geht. Das sehe ich auch so. Und wenn wir Platz für ISO8859-15 hätten, würde ich das auch realisieren, und die Umschalterei allenfalls noch aus Kompatibiltätsgründen einbauen. > Wäre es nicht möglich, den kompletten ISO8859-1 (oder ISO8859-15) zu > nutzen und die Attribute anderweitig abzulegen? Müsstest Du doch auch > schon so machen, denn schließlich kann das Terminal doch mehr als nur 1 > Attribut?!? Außer diesem einen Attribut haben wir noch 2 mal 4 Bit für je 16 Vordergrund- und Hintergrundfarben. Invers geht dann, indem man Vorder und Hintergrund tauscht. Statt Bold kann man auch auf eine helle Farbe (Bright) umschalten. Blinken nervt nur, und scheint zum Glück niemand zu wollen. Der Bildwiederholspeicher ist also 16 Bit breit und 80x30 Zeichen groß. (4800 Byte). Der Propeller hat 32 KByte RAM, in die Programm und Daten passen müssen. Ein Byte mehr pro Zeichen für Attribute wäre aber wahrscheinlich noch möglich. Allerdings könnte die derzeitige Scanroutine, die das Bild zum VGA-Ausgang schaufelt, nichts damit anfangen. In die Ausgabeschleife paßt kein einziger Befehl mehr. Es reicht schon, Befehle zu verschieben, damit das Bild instabil wird. Man könte sich auch mit 8 Hintergrundfarben begnügen, um ein Bit frei zu bekommen. Das ist dann nicht mehr mit Xterm und der Linux-Console kompatibel, Invers und Bold (Highlight) sind möglicherweise nicht mehr verlustfrei umkehrbar, aber vielleicht wäre das doch der bessere Kompromiss. Mal sehn, was wir noch an Propeller-Resourcen frei haben, wenn das Programm vollständig ist. Zur Zeit fehlen noch Flußsteuerung, eine bessere Tastaturunterstützung und vielleicht ein erweitertes Setup. Vielleicht kann man die Videoausgabe auf 3 oder 4 COGs (Prozessorkerne) verteilen, und das Videoram auf 32 bit erweitern. Dann hätte man Platz für je 6 Bit Vorder- und Hitergrundfarbe. Die Hardware hat für RGB jeweils 2 Bit. Man könnte also jede Farbe dierekt ansteuern und wäre nicht mehr auf eine Palette angewiesen. Für sonstige Attribute hätte man dann noch 4 Bit.
Leo C. schrieb: > Außer diesem einen Attribut haben wir noch 2 mal 4 Bit für je 16 > Vordergrund- und Hintergrundfarben. Komisch, ich dachte, der Standard würde nur je 8 Hintergrund- und 8 Vordergrundfarben vorsehen. > Invers geht dann, indem man Vorder und Hintergrund tauscht. Ja. > Statt Bold kann man auch auf eine helle Farbe (Bright) umschalten. Ja. > Blinken nervt nur, und scheint zum Glück niemand zu wollen. Ja, > Ein Byte mehr pro Zeichen für Attribute wäre aber > wahrscheinlich noch möglich. Gut. > Allerdings könnte die derzeitige > Scanroutine, die das Bild zum VGA-Ausgang schaufelt, nichts damit > anfangen. In die Ausgabeschleife paßt kein einziger Befehl mehr. Es > reicht schon, Befehle zu verschieben, damit das Bild instabil wird. Ließe sich das optimieren? > Man könte sich auch mit 8 Hintergrundfarben begnügen, Keine Vordergrundfarben mehr? Dann finde ich das eigentlich nicht so prickelnd. > Mal sehn, was wir noch an Propeller-Resourcen frei haben, wenn das > Programm vollständig ist. Zur Zeit fehlen noch Flußsteuerung, eine > bessere Tastaturunterstützung und vielleicht ein erweitertes Setup. Ich finde das echt klasse, was Ihr da leistet. Ich hätte da einen Vorschlag: Ich könnte mittels der MCURSES-Bibliothek, die ich mal verbrochen und hier auf µC.net abgelegt habe, eine Test-Suite erstellen. Dann kann man bestimmete Funktionalitäten wie Scrolling-Regions etc. direkt testen und zum Beispiel mit dem Output, welchen PuTTY oder die Linux-Console produzieren, direkt vergleichen. Wenn auf beiden Terminals immer das gleiche Bild entsteht, hat Euer Terminal den Test bestanden ;-) > Vielleicht kann man die Videoausgabe auf 3 oder 4 COGs (Prozessorkerne) > verteilen, und das Videoram auf 32 bit erweitern. Dann hätte man Platz > für je 6 Bit Vorder- und Hitergrundfarbe. Die Hardware hat für RGB > jeweils 2 Bit. Man könnte also jede Farbe dierekt ansteuern und wäre > nicht mehr auf eine Palette angewiesen. Für sonstige Attribute hätte man > dann noch 4 Bit. Ich muss mir den Source-Code mal näher anschauen, muss aber gestehen, dass ich von Propeller momentan keine Ahnung habe.
:
Bearbeitet durch Moderator
Angehängte Dateien:
-
vttest-11.6.6.1.jpg
95 KB
> Komisch, ich dachte, der Standard würde nur je 8 Hintergrund- und 8 > Vordergrundfarben vorsehen. Nach ISO 6429 gibt es 8 Farben in "Normal" und "Hell" (Bright). Die hellen Farben kann man nicht direkt auswählen, sondern über ein Attribut wie Bold oder "high intensity". Direkte Auswahl ist eine Erweiterung, die von aixterm kommt. Ein Link sagt mehr als 1000 Worte: ;) https://en.wikipedia.org/wiki/ANSI_escape_code#Colors >> Man könte sich auch mit 8 Hintergrundfarben begnügen, > Keine Vordergrundfarben mehr? Dann finde ich das eigentlich nicht so > prickelnd. 8 statt 16 Hintergrund- und weiterhin 16 Vordergrundfarben. Im Attributspeicher hätte man dann 3 Bit für Hinter- und 4 Bit für Vordergrund. So wars gemeint. > Ich hätte da einen Vorschlag: Ich könnte mittels der > MCURSES-Bibliothek, die ich mal verbrochen und hier auf µC.net > abgelegt habe, Kenne ich natürlich. Ich spiele mit dem Gedanken, Dein MCURSES für das Z180-Stamp-Projekt zu verwenden. Dort gibt es einen Monitor, der auf einem AVR läuft und über eine serielle Console bedient wird. Der Monitor kann auf dem Z180 ein Programm (z.B. CP/M) starten, und dessen Console transparent über die eingene Terminalschnittstelle zum User durchreichen. Nun wäre es praktisch, wenn man im AVR-Monitor ein Split-Screen machen könnte, damit die Ausgaben von beiden Systemen immer schön getrenn bleiben. Bisher habe ich das nicht realisiert, weil MCURSES die Fenstergröße zur Laufzeit nicht ändern kann. Das brauche ich, weil ich auf die Möglichkeit, das Xterm-Fenster den momentanen Platzverhältnissen auf meinem Monitor anzupassen, nicht verzichten will. Mein Versuch, MCURSES dafür zu erweitern, ist vor einer Weile kläglich gescheitert. (Ich schicke "ESC [ 6 n" (Cursor position report) ans Terminal und versuche die Antwort aus dem Input-Stream herauszufischen.) > eine Test-Suite erstellen. Dann kann man bestimmete > Funktionalitäten wie Scrolling-Regions ^^^^^^^^^^^^^^^^^ Gerade die fehlt noch. (Wenn überhaupt, dann nur eine) > etc. direkt testen und zum > Beispiel mit dem Output, welchen PuTTY oder die Linux-Console > produzieren, direkt vergleichen. Wenn auf beiden Terminals immer das > gleiche Bild entsteht, hat Euer Terminal den Test bestanden ;-) Davon wird Dich sicher niemand abhalten. :) Zur Zeit teste ich mit vttest. Das läuft nur auf Unix/Linux (irgendwo gibt es einen veralteten Cygwin Port) und leider nur dann richtig, wenn das zu testende Terminal auch die Login-Console ist. Wenn ich die Ausgabe auf eine serielle Schnittstelle umleite, wird statt CR/LF nur noch LF ausgegeben. Außerdem taugt das Programm nur für geht/geht nicht Tests. Die fehlerhafte Stelle zu finden, ist damit recht schwierig. Der Fehler im angehängten Bild kommt allerdings durch das CR/LF-Problem. > Ich muss mir den Source-Code mal näher anschauen, muss aber gestehen, > dass ich von Propeller momentan keine Ahnung habe. Ging mir vor ein paar Wochen auch so. ;) Der Propeller hat einen eingebauten Bytecode-Interpreter für die Programmiersprache Spin. Das ist eine Art Basic-Dialekt. Der Spin-Teil des Terminalprogramms ist sicher leicht zu verstehen. Zeitkritische Teile wie die Videosignalerzeugung müssen aber in Assembler programmiert werden. Und der Assembler ist schon sehr gewöhnungsbedürftig.
Leo C. schrieb: >> Komisch, ich dachte, der Standard würde nur je 8 Hintergrund- und 8 >> Vordergrundfarben vorsehen. > > Nach ISO 6429 gibt es 8 Farben in "Normal" und "Hell" (Bright). Die > hellen Farben kann man nicht direkt auswählen, sondern über ein Attribut > wie Bold oder "high intensity". Dann meinten wir beide dasselbe: 8/8 Farben in Bold und Normal. > Direkte Auswahl ist eine Erweiterung, die von aixterm kommt. Kenne ich von früher :-) > Ein Link sagt mehr als 1000 Worte: ;) > https://en.wikipedia.org/wiki/ANSI_escape_code#Colors Netter Link, danke. > 8 statt 16 Hintergrund- und weiterhin 16 Vordergrundfarben. Achso, okay. Wäre dann nicht sooo schlimm. "Fetter" Hintergrund (also in Bold) muss wirklich nicht sein. ;-) > Nun wäre es praktisch, wenn man im AVR-Monitor ein > Split-Screen machen könnte, damit die Ausgaben von beiden Systemen immer > schön getrenn bleiben. Scrolling-Region einbauen, die Du einmal in die obere Hälfte, das andere Mal in die untere Hälfte legst - je nachdem, wo Du Zeichen ausgeben möchtest ;-) > Bisher habe ich das nicht realisiert, weil > MCURSES die Fenstergröße zur Laufzeit nicht ändern kann. Ja, das ist ein Nachteil, den ich aber nicht sooo gravierend finde. Eine feste Maximal-Zahl von Zeilen/Spalten (z.B. 35/135) reicht Dir nicht? > Mein Versuch, MCURSES dafür zu erweitern, ist vor einer Weile kläglich > gescheitert. (Ich schicke "ESC [ 6 n" (Cursor position report) ans > Terminal und versuche die Antwort aus dem Input-Stream herauszufischen.) Schaue ich mir mal an. >> eine Test-Suite erstellen. Dann kann man bestimmete >> Funktionalitäten wie Scrolling-Regions > ^^^^^^^^^^^^^^^^^ > Gerade die fehlt noch. (Wenn überhaupt, dann nur eine) Aber die finde ich enorm wichtig. Ohne Scrolling Regions auch kein (simpler) Monitor bzw. Editor. > Davon wird Dich sicher niemand abhalten. :) Ich bau da mal was, lauffähig auf Linux & µC. > Zur Zeit teste ich mit vttest. Kenne ich nicht. > Das läuft nur auf Unix/Linux (irgendwo > gibt es einen veralteten Cygwin Port) und leider nur dann richtig, wenn > das zu testende Terminal auch die Login-Console ist. Wenn ich die > Ausgabe auf eine serielle Schnittstelle umleite, wird statt CR/LF nur > noch LF ausgegeben. Außerdem taugt das Programm nur für geht/geht nicht > Tests. Die fehlerhafte Stelle zu finden, ist damit recht schwierig. Der > Fehler im angehängten Bild kommt allerdings durch das CR/LF-Problem. Ich sehe das genau umgekehrt: Das Programm an der Linux-Console läuft verkehrt. Denn hier wird \n vom TTY-Treiber auf \r\n gemappt. Bei Umleitung auf die serielle Schnittstelle geht alles 1:1 durch und \n bleibt \n. vttest scheint also nur ein \n zu schicken, weil es auf das Mapping des TTY-Treibers vertraut. Dann arbeitet es aber nicht transparent. Tipp: Wenn Du umlenkst und dasselbe Mapping-Verhalten wie auf der Console haben möchtest: stty onlcr </dev/ttyxxx Damit schaltest Du das NL -> CR Mapping ein. > Der Propeller hat einen eingebauten Bytecode-Interpreter für die > Programmiersprache Spin. Das ist eine Art Basic-Dialekt. Der Spin-Teil > des Terminalprogramms ist sicher leicht zu verstehen. Zeitkritische > Teile wie die Videosignalerzeugung müssen aber in Assembler programmiert > werden. Und der Assembler ist schon sehr gewöhnungsbedürftig. Hm. Was zeichnet den Propeller aus, dass er gegenüber einem STM32 den Vorzug bekommen würde?
> MCURSES Dazu habe ich jetzt im MCURSES-Thread geantwortet: Beitrag "Re: MCURSES - Mini Curses Bibliothek für Mikrocontroller" > Aber die finde ich enorm wichtig. Ohne Scrolling Regions auch kein > (simpler) Monitor bzw. Editor. Ja, Ja. Aber die CP/M-Programme, für die das Terminal in erster Linie gedacht ist, machen keinen Gebrauch davon. Ich habe Scrolling Regions auch deshalb zurückgestellt, weil sie auf die Performance gehen, die eh (noch) zu wünschen übrig läßt. Wenn der Rest mal läuft, will ich die Routinen, die den Bildspeicher manipulieren (scrolling) in Assembler in einen eigenen Prozessorkern verlagern. > vttest scheint also nur ein \n zu schicken, weil es auf das Mapping des > TTY-Treibers vertraut. Dann arbeitet es aber nicht transparent. So ist es. > Tipp: Wenn Du umlenkst und dasselbe Mapping-Verhalten wie auf der > Console haben möchtest: > stty onlcr </dev/ttyxxx > Damit schaltest Du das NL -> CR Mapping ein. Danke, ich wußte, das es so etwas gibt, hatte es aber nicht gefunden. Inzwischen ausprobiert: Funktioniert leider nicht. vttest setzt die tty-Parameter selber. > Hm. Was zeichnet den Propeller aus, dass er gegenüber einem STM32 den > Vorzug bekommen würde? Das es ihn schon viel länger gibt? Den Chip gibts schon sehr lange und ist bei Hobbyisten sehr beliebt. Zu den Features zählen eingebauter Bootloader, einfache, Basic-artige Programmiersprache, eingebauter Video-Generator für VGA- und Composite-Signale. Fertige (Assembler-) Module für Video, Serielle Schnittstelle, PS/2-Keyboard und -Maus gibts auch fertig.
Leo C. schrieb: > Danke, ich wußte, das es so etwas gibt, hatte es aber nicht gefunden. > Inzwischen ausprobiert: Funktioniert leider nicht. Sorry, opost muss auch noch gesetzt werden, damit post processing überhaupt aktiviert ist. Also: stty opost onlcr </dev/ttyxxx > vttest setzt die tty-Parameter selber. Dann hätte es sich aber auf dem seriellen TTY als auch auf der Console gleich verhalten müssen?!? Jetzt war ich doch gespannt und hab mir vttest mal runtergeladen. Hm, sieht so aus, als ob nur Input-Flags manipuliert werden und die Output-Flags unangetastet bleiben. Daher sollte obiger stty-Befehl vor dem Ausführen von vttest durchaus funktionieren. Nichtsdestotrotz denke ich über eine Test-Suite nach ;-) > Das es ihn schon viel länger gibt? Den Chip gibts schon sehr lange und > ist bei Hobbyisten sehr beliebt. Zu den Features zählen eingebauter > Bootloader, einfache, Basic-artige Programmiersprache, eingebauter > Video-Generator für VGA- und Composite-Signale. Fertige (Assembler-) > Module für Video, Serielle Schnittstelle, PS/2-Keyboard und -Maus gibts > auch fertig. Hört sich wirklich gut an, gerade der Video-Generator.
:
Bearbeitet durch Moderator
Frank M. schrieb: > stty opost onlcr </dev/ttyxxx Danke, so gehts tatsächlich. >> vttest setzt die tty-Parameter selber. > Dann hätte es sich aber auf dem seriellen TTY als auch auf der Console > gleich verhalten müssen?!? Ich habe vttest inzwischen mit DEBUG-Log laufen lassen und gemerkt, daß es daran nicht liegt. > Jetzt war ich doch gespannt und hab mir vttest mal runtergeladen. Hm, > sieht so aus, als ob nur Input-Flags manipuliert werden und die > Output-Flags unangetastet bleiben. Daher sollte obiger stty-Befehl vor > dem Ausführen von vttest durchaus funktionieren. Kann ich jetzt bestätigen. :) > Nichtsdestotrotz denke ich über eine Test-Suite nach ;-) Gerne. ;) > Hört sich wirklich gut an, gerade der Video-Generator. Es ist eigentlich nur ein Schieberegister mit nachgeschaltetem Multiplexer. Der Prozessor kann auf den Ladezeitpunkt des Schieberegisters synchronisiert werden (d.h. angehlten, befehl 'waitvid'). Wenn er zu spät kommt, weil er zu lange braucht um die nächsten Bildpunkte aufzubereiten, gibts Bildsalat. Da der Chip aber 8 Kerne hat, die alle gleich ausgestattet sind, also auch 8 Videogeneratoren, können ein oder mehrere Kerne die nächsten Bildzeilen berechnen, während ein Kern die aktuelle Zeile ausgibt. Theoretisch könnte man also nahezu beliebig komplexe Videosignale generieren, wenn man nur genügend Kerne auf das Problem wirft. Leider ist der Speicher pro Kern auf 512 Worte a 32 bit beschränkt. Und die werden bei längeren Bildzeilen, vielen Farben oder komplexer Attributaufbereitung schnell voll.
Leo C. schrieb: > In die Ausgabeschleife paßt kein einziger Befehl mehr. Es > reicht schon, Befehle zu verschieben, damit das Bild instabil wird. Man könnte noch den Propeller mit 6 MHz übertakten. Mein Versuchsaufbau macht das gerade mit. Ob es jedoch für eine breite Anwendung reproduzierbar ist, müsste gestestet werden. Petr schrieb: > Wäre noch 1 Platine, bzw. 1 Set da? Ja, eine Platine und 1 Propeller IC sind verfügbar.
Joe G. schrieb: > > > Petr schrieb: >> Wäre noch 1 Platine, bzw. 1 Set da? > > Ja, eine Platine und 1 Propeller IC sind verfügbar. Ich würde beides gerne nehmen, heute Abend melde ich mich per PN (bin noch nicht registriert hier...)
Joe G. schrieb: > Man könnte noch den Propeller mit 6 MHz übertakten. Mein Versuchsaufbau > macht das gerade mit. Ob es jedoch für eine breite Anwendung > reproduzierbar ist, müsste gestestet werden. Nach dem, was man so im Netz findet, scheint das gut zu funktionieren. Aber im Moment reichen die 5MHz ja gerade. Aber gut zu wissen.
Hallo Joe, ich baue mir gerade die V1.1 für den Z180-Rechner zusammen. Zwei Dinge sind mir bislang aufgefallen: Könnte man in einer V1.2 auch vorsehen, die 5V extern zuzuführen? Also wie bei der AVR Stamp per Jumper schaltbar? So bliebe der 5V Anschluss nutzbar, auch wenn die Spannung von ECB kommmt. Hast du einen guten Vorschlag, wie ich das auf der V1.1 am besten mache? Die 5V_USB gehen ja zu vielen Stellen... Und ich bin bei der Anleitung nicht ganz durchgestiegen, welche Bedeutung die Jumper 1-4 haben. Wann sind sie für die Programmierung notwendig, wann für die Quellen-Umschaltung etc... Kannst du das noch mal bitte etwas aufdröseln? Danke und Gruß Marcel
Wenn du das Terminal über die RS232 anschließt, so benötigst du ja USB nicht. Damit kann die 5V über ein einfaches 5V USB Netzteil an der USB Buchse angelegt werden. JP2 und JP3 können offen bleiben. JP4 je nachdem über welche Schnittstelle du den Propeller programmierst. Also entweder über USB, dann JP4 auf USB oder RS232 dann JP4 auf RS232. Hier wird lediglich festgelegt, woher der Propeller sein Resetimpuls bekommt. JP1 muss geschlossen sein. Damit kann per Software von RS232 auf USB und umgekehrt geschaltet werden. Nach erfolgreicher Programmierung sollte der Jumper von JP4 ganz gezogen werden, damit die Schnittstelle über DSR oder RTS kein Reset auslöst.
Habe jetzt den Propeller bestückt und er wird auch von der IDE erkannt. Was mich wundert: Die rote und blaue (eigentlich grüne) LED leuchten immer. Nur die blau/grüne LED1 flackert beim Einstecken. Ist das normal?
Marcel A. schrieb: > Ist das normal? Nein. Die LED's sollten nur beim Senden oder Empfangen (über USB) leuchten.
Erfolg! Platine läuft (wie üblich ein Kontaktproblem und die Vergessene Drahtbrücke am MAX). Kann es sein, dass ich trotz 100facher Prüfung die LEDs verkehrt heraum eingebaut habe? Jedenfalls klappt die Umschaltung RS232/USB Port (LEDs gehen aus beim Umschalten auf RS232). Drei Fragen/Hinweise habe ich noch: Bei meiner WS3.0-Version stürzt der VT100-Stamp ab, sobald das Menü angezeigt werden soll. Es ist auf VT100 eingestellt. Im Terminal erscheint alles richtig mit gelben Codes und grünem Text. Vielleicht habe ich noch eine zu veraltete Firmware drauf? Habe die unter source, V1_1 (Rev 172, 6 Monate alt) genommen. Vielleicht sollte ich die aus dem Work-Verzeichnis nehmen? Wie ist denn der letzte Stand eurer Diskussion zum Thema Farbe? Hier steht in der Doku etwas von "Farbmodell der VGA Grafik (nicht full color mode). Jedem Zeichen wird ein Farbbyte zugeordnet mit den folgenden Aufbau zugeordnet. RRGGBB00. Damit sind pro Farbe drei Abstufungen möglich." Ich hatte bisher angenommen, dass für den ganzen Bildschirm nur eine Front- und eine Background-Farbe eingestellt werden kann? Ihr habt weiter oben so schön über Zeichensätze diskutiert. Gerade an den "Rahmensymbolen" hätte ich Interesse. Wie ist denn da der aktuelle Stand und ist schon irgendwo beschrieben, wie man diese Zeichensätze nutzt? Vielen Dank und Gruß Marcel
> Vielleicht sollte ich die aus dem Work-Verzeichnis nehmen? Unbedingt. ;-) Marcel A. schrieb: > Wie ist denn der letzte Stand eurer Diskussion zum Thema Farbe? Für jedes Zeichen kann die Vorder- und Hintergrundfarbe getrennt aus Palette mit 16 Farben gewählt werden. Die Palette kann in der Datei 'VGA_640.spin' angepaßt werden. Escape-Sequenzen dafür fehlen noch. > Ich hatte bisher angenommen, dass für den ganzen Bildschirm nur eine > Front- und eine Background-Farbe eingestellt werden kann? Das ist aber schon sehr lange veraltet. > Ihr habt weiter oben so schön über Zeichensätze diskutiert. Gerade an > den "Rahmensymbolen" hätte ich Interesse. Wie ist denn da der aktuelle > Stand und ist schon irgendwo beschrieben, wie man diese Zeichensätze > nutzt? Klar, im VT100-Handbuch [1]. Wie das mit den Farben funktioniert, ist in [2] ganz gut beschrieben. Und in [3] ist eine Liste der derzeit unterstützten Steuer-Sequenzen. [1] http://vt100.net/docs/vt100-ug/ [2] https://en.wikipedia.org/wiki/ANSI_escape_code#Colors [3] https://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/VT100/source/work/control-codes.md?view=markup
Marcel A. schrieb: > Kann es sein, dass ich trotz 100facher Prüfung die LEDs verkehrt heraum > eingebaut habe? Das sieht ganz so aus :-( Du kannst es jedoch sehr einfach prüfen. Es gibt ein sehr nützliches Tool [1] um die Pinkonfiguration des FDTI zu ändern. [1] http://www.ftdichip.com/Support/Utilities.htm#FT_PROG
Ich schau mal - aber eigentlich kann das doch nicht... Auf einer Seite hängen die LEDs an +3,3V. Der FTDI kann CBUS auf High oder LOW setzen - bei HIGH dürfte die LED aus sein, bei LOW an (Spannungsdifferenz). Wenn ich sie anders herum einbaue, dürfte sie ja nie angehen wegen Sperr-Richtung?
Angehängte Dateien:
-
vorher.png
11 KB -
nachher.png
3,2 KB
So, Thema 1: FTDI und die LEDs. Habe mit dem FTProg-Tool mal geschaut und da stimmten tatsächlich die Konfigurationen der Ausgänge nicht (siehe Bilder). Da der FT232 so Auslieferungszustand war - vielleicht sollte da irgendwo ein Hinweis rein, dass dieser umkonfiguriert werden muss. Thema 2: Firmware. Habe auf die Version in "work" (meldet sich mit "1.7.2 test serial 3") umgestellt. Die Schrift sieht besser aus - aber es werden keine Tastatureingaben angenommen (bzw. werden diese direkt zum USB-Port geschickt, da blinkt es dann) - folglich kann ich auch das Config-Menü nicht aufrufen oder mit F5 die Quelle umschalten. Komisch. Generell zum Menü: Könnte man statt F10-Speicherung und Schließen vielleicht auch F9 - nur schließen einbauen?
Marcel A. schrieb: > Da der FT232 so Auslieferungszustand war - vielleicht sollte da > irgendwo ein Hinweis rein, dass dieser umkonfiguriert werden muss. Eigentlich nicht. "CBUS0 Factory default configuration is TXLED#. See CBUS Signal Options, Table 3.99." Das war bei mir bisher auch immer so. > aber es werden keine Tastatureingaben angenommen Ist JP1 gesteckt und R3, 10k bestückt? Dieser Widerstand dient der Firmware u.a. der Hardwareerkennung. > Könnte man statt F10-Speicherung und Schließen > vielleicht auch F9 - nur schließen einbauen? Ja
:
Bearbeitet durch User
Das Setup befindet sich im Umbau. ----------------------------------------------------------------------- Ich habe angefangen, das Setup umzubauen. Sieht zwar noch gleich aus, funktioniert aber anders. Man muß es erst aktivieren, bevor man etwas einstellen kann. Hinein kommt man nun mit Ctrl-PrintScreen. Eigentlich sollte es Alt-PrintScreen sein, wie bei neueren DEC Terminals mit PC-Keyboard Layout. Aber bei unserem Keyboard-Treiber kommt bei Alt-PrintScreen nix. Raus kommt man z. Zt. mit nochmal Ctrl-PrintScreen, ESC oder F10. Nur bei F10 werden die Daten im EEPROM gespeichert. -----------------------------------------------------------------------
Danke Leo, das war es - neuer Menü-Einstieg. Sehr schön gemacht!
TP und WS sehen nun auch viel besser aus ("farbige" Hinterlegung).
Sobald ich in WS aber einen Text lade, stürzt das VT100 aber wieder ab.
Auch ist zumindest bei mir kein "CRTL" möglich -> CRTL-K wird wie
SHIFT-K interpretiert - es kommen Großbuchstaben. Damit kommt man weder
aus TP noch was WS raus :-)
Joe G. schrieb: > "CBUS0 Factory default configuration is TXLED#. See CBUS Signal > Options, Table 3.99." > Das war bei mir bisher auch immer so. Komisch - na, vielleicht ein Produktionsfehler bei mir - so kam er jedenfalls aus der Reichelt-Tüte :-) Falls also noch mal jemand das Problem haben sollte - damit gehts dann.
Vielleicht mache ich auch etwas grundsätzlich falsch (z.B. den richten
Zeichensatz nicht laden), aber es gehen auch keine Umlaute oder wichtige
Sonderzeichen wie {[]} ...?
Oben lese ich zwar, wie Zeichensätze mit ESC-Codes umgeschaltet werden
können, aber da sehe ich nur US und DECT. Auch frage ich mich, wie ich
ESC-Sequenzen außerhalb von Software an das System schicken soll?
> Auch ist zumindest bei mir kein "CRTL" möglich -> CRTL-K wird wie > SHIFT-K interpretiert - es kommen Großbuchstaben. Damit kommt man weder Kann es sein, daß dann nur noch Großbuchstaben kommen, egal ob CRTL oder SHIFT gedrückt ist, oder nicht? Den Fehler habe ich jedenfalls, wenn ich das Terminal als Linux-Console verwende. Wann der Fehler genau auftritt, habe ich noch nicht herausgefunden, aber vielleicht kannst Du ihn ja weiter eingrenzen.
> Oben lese ich zwar, wie Zeichensätze mit ESC-Codes umgeschaltet werden > können, aber da sehe ich nur US und DECT. Die Umlaute sind immer noch nicht im Zeichensatz. Vielleicht schnappst Du Dir mal einen Zeichensatzeditor... > Auch frage ich mich, wie ich > ESC-Sequenzen außerhalb von Software an das System schicken soll? $ echo ... >/dev/tty... > pip auxout:=con:
Nein, die CRTL-Taste wirkt wie die SHIFT Taste - lasse ich sie los, ist
auch alles wieder klein.
ALTGR-Ö gibt mir derzeit ] aus.
Hm...
Ich lade noch mal die 1.6er und prüfe das nach.
...
So. mit der 1.6er gibt es auch keine Umlaute. Aber {[]} klappt (über
ALTGR -7/8/9/0). Auch ALTGR-< gibt (links unten) gibt mir dann einen |
aus.
In der 1.7.2 ist kommen keine {[]} und ALTGR-< gibt ~ aus.
Alles getestet mit V24 an der AVR Console
Leo C. schrieb: >> Auch frage ich mich, wie ich >> ESC-Sequenzen außerhalb von Software an das System schicken soll? > > $ echo ... >/dev/tty... >> pip auxout:=con: Ähm, klar, wenn ich statt des AVR/Z180 Stamps meine Linux-Kiste anschließen würde. Ich meine, wenn ich den VT100 am Z180/AVR habe, dann kann ich das ja nur z.B. im Rahmen eines TurboPascal-Programms (writeln...) an das Terminal senden, aber nicht wenn ich mich einfach auf der AVR Console befinde.
>>> pip auxout:=con: > Ähm, klar, wenn ich statt des AVR/Z180 Stamps meine Linux-Kiste > anschließen würde. Also PIP ist ein CP/M-Kommando. Du kannst auch einfach Steuerzeichen am CCP-Prompt eingeben und dann Enter drücken. Im Debugger eine kleine Ausgabe-Schleife eintippen, geht schneller als ein TP-Programm. Mit Debugger Steuerzeichen in Speicher schreiben und als Datei speichern. Anschließend mit TYPE oder PIP ausgeben.
Leo C. schrieb: > Also PIP ist ein CP/M-Kommando. Stimmt :-) Hast du eine Idee, warum die {[]} nicht mehr kommen? Sind die im neuen Zeichensatz an eine andere Stelle gerutscht? Oder sind die genau wie Umlaute in den beiden Schriftarten noch nicht eingebettet? EDIT: Nach meinem Verständnis sind die Daten in der spin für diese Sonderzeichen drin (5B, 5D, 7B, 7D) Die beiden Schriftarten liegen offenbar in der Datei fonts-lin.spin - wie habt ihr die erstellt? Mit dem Malen von Umlauten ist es ja nicht allein getan, die müssen ja auch da stehen, wo sie von Programmen (German Character Set) üblicherweise erwartet werden, oder?
:
Bearbeitet durch User
Marcel A. schrieb: > So. mit der 1.6er gibt es auch keine Umlaute. Aber {[]} klappt (über > ALTGR -7/8/9/0). Auch ALTGR-< gibt (links unten) gibt mir dann einen | > aus. Version 1.6 finde ich bei mir nicht. Marcel A. schrieb: > Die beiden Schriftarten liegen offenbar in der Datei fonts-lin.spin - > wie habt ihr die erstellt? Copy&Paste. Wenn Du nach VGA_HiRes_Text.spin und vgacolour.spin, bzw. vgademo-0.0.4.zip suchst, findest Du die Quellen. Marcel A. schrieb: > Mit dem Malen von Umlauten ist es ja nicht allein getan, die müssen ja > auch da stehen, wo sie von Programmen (German Character Set) > üblicherweise erwartet werden, oder? Die kommen da hin wo Platz ist, bzw. geschaffen wird. Vom Terinalprogramm werden sie dann je nach Einstellung an die passende Position gemappt. Das wurde weiter oben ab ca. 22.9. diskutiert.
:
Bearbeitet durch User
Leo C. schrieb: > Marcel A. schrieb: >> So. mit der 1.6er gibt es auch keine Umlaute. Aber {[]} klappt (über >> ALTGR -7/8/9/0). Auch ALTGR-< gibt (links unten) gibt mir dann einen | >> aus. > > Version 1.6 finde ich bei mir nicht. Das ist die Version aus dem SVN unter Doku/VT100/source/V1_1 > Die kommen da hin wo Platz ist, bzw. geschaffen wird. Vom > Terinalprogramm werden sie dann je nach Einstellung an die passende > Position gemappt. Das wurde weiter oben ab ca. 22.9. diskutiert. Ich weiß, habe ich bisher nur nicht verstanden :-)
So, habe am Terminal mal etwas weitergemacht. Ich nutze am BastelPC dazu TeraTerm. Das mit den ESC-Sequenzen habe ich durchschaut - das klappt in TP als auch auf der CCP Console. Nur ESC # 9 - da passiert nichts. Bei der Farbe ist mir noch aufgefallen, dass die Einstellung für den Hintergrund in die 2. Zeile mitwandert. Hier mal zwei Outputs von Joes und meine Testprogramm.
1 | writeln('Start der Darstellung');
|
2 | |
3 | write(esc + '[34m'); {Text blau}
|
4 | writeln('Blauer Text');
|
5 | |
6 | write(esc + '[47m'); {Hintergrund weiss}
|
7 | writeln('mit weissem Hintergrund');
|
8 | |
9 | reset; {ESC [ m}
|
10 | |
11 | writeln('wieder normal');
|
12 | writeln('genau');
|
:
Bearbeitet durch User
Marcel A. schrieb: > Das ist die Version aus dem SVN unter Doku/VT100/source/V1_1 Gibts nicht. Meinst Du vielleicht 'trunk/VT100/source/V1_1'? Marcel A. schrieb: > Nur ESC # 9 - da passiert nichts. Gerade ausprobiert. Bei mir gehts. Ansonsten habe ich gerade nicht viel Zeit für das Terminal. Die Tastaturprobleme schau ich mir aber auf jeden Fall demnächts an.
Angehängte Dateien:
Marcel A. schrieb: > Bei der Farbe ist mir noch aufgefallen, dass die Einstellung für den > Hintergrund in die 2. Zeile mitwandert. Das macht z.B. XTerm auch, also das gehört so. :) Beim Scrollen wird die neue leere Zeile mit dem aktuellen Hintergrund gefüllt.
Leo C. schrieb: > Das macht z.B. XTerm auch, also das gehört so. :) Scheinbar aber nicht immer so? zum VT100: Leider habe ich von SPIN-Programmierung so gar keine Ahnung und ich wollte als nächstes eigentlich tiefer in die Z80-Programmierung einsteigen. Meine Herausforderung für die Feiertage ist die BIOS-Anpassung des NDR-NKCs zur Unterstützung von 3 Disketten-Laufwerken (habe dort einen mit HxC2001-Firmware erweiterten Gotek-Floppy-Emulator drin). Mein Hauptproblem ist es, dass ich mich immer wieder in vielen kleinen Baustellen verzettel (-> NDR, TRS-80, MFA, Apple, C128...). Nach der ganzen Löterei würde ich jetzt gerne wieder mehr SW machen.
Neue Erkenntnisse: Am PC-Terminal: - wenn der ESC-Reset vor einem Writeln kommt, dann ist die Ausgabe ok - Die Umschaltung SO/SI klappt bei mir nur mit TeraTerm unter Windows. Weder Putty unter Windows/Linux noch minicom schalten hier irgendetwas um - ESC # 8 geht (alles voller E), aber ESC # 9 macht nichts Am VT100 (1.7.2): - SO/SI zeigt keine Wirkung - CRTL wirkt wie Shift - Shift keine Funktion in TP (wohl aber im AVR Monitor) Generell Z180/AVR: PageDown/Up, Insert etc. erzeugen bei mir neben dem ESC-Code immer ein Tilde-Zeichen ~ Dieses wird dann nach einem PageDown in den Quelltext geschrieben.
> Scheinbar aber nicht immer so?
Doch. Wenn Zeichen gelöscht werden (müssen), gibt es 3 Möglichkeiten,
wie der Hintergrund gefüllt werden kann:
1. mit dem Defaultwert
2. mit der Hintergrundfarbe, die vorher an der entspechenden Stelle war
3. mit der aktuell gesetzten Hintergrundfarbe
Unser Propeller-Terminal, XTerm und die meisten anderen machen es nach
3. Beim Scrollen z.B. geht 2. nicht, da ja von unten eine neue Zeile,
die keine alte Hintergrundfarbe haben kann, ins Bild geschoben wird. Auf
meinem Bildschirmfoto oben sind die beiden ersten Ausgaben ohne
scrollen, die dritte mit.
Marcel A. schrieb: > Am PC-Terminal: > - wenn der ESC-Reset vor einem Writeln kommt, dann ist die Ausgabe ok eben. > - Die Umschaltung SO/SI klappt bei mir nur mit TeraTerm unter Windows. Zwischen was wird denn da umgeschaltet? > Weder Putty unter Windows/Linux noch minicom schalten hier irgendetwas > um Lies diesen Beitrag nochmal aufmerksam durch: Beitrag "Re: VT100-Terminal (VGA+PS2)" > - ESC # 8 geht (alles voller E), aber ESC # 9 macht nichts ESC # 9 ist ja auch ein Hack, den es nur bei unserem Teminal gibt. > Am VT100 (1.7.2): > - SO/SI zeigt keine Wirkung Wahrscheinlich das gleiche, wie bei Putty und co. > - CRTL wirkt wie Shift > - Shift keine Funktion in TP (wohl aber im AVR Monitor) Ja, da sind offensichtlich schwere Fehler drin, die ich noch nicht gefunden habe. > Generell Z180/AVR: PageDown/Up, Insert etc. erzeugen bei mir neben dem > ESC-Code immer ein Tilde-Zeichen ~ > Dieses wird dann nach einem PageDown in den Quelltext geschrieben. Die Tilde gehört mit zu der ESC-Sequenz und muß entsprechend ausgewertet werden.
Leo C. schrieb: > ESC # 9 ist ja auch ein Hack, den es nur bei unserem Teminal gibt. Erleuchtung :-) Da geht es natürlich. > Die Tilde gehört mit zu der ESC-Sequenz und muß entsprechend ausgewertet > werden. Hm... Ok, damit kommt aber TP nicht klar. z.B. ist PgDwn/PgUp als "ESC [ 5" (oder 6) bei TINST eingestellt. TINST akzeptiert aber "ESC [ 5 ~" nicht..." "Damals" gab es solche Tasten ja auch noch nicht :-) Somit funktionieren zwar Insert, Home, End, PageUp/Dn - aber werfen immer ein ~ Zeichen in den Quelltext. Werde ich mir halt die CTRL-Codes angewöhnen müssen. TeraTerm: - hier reicht es, SO zu senden, dann werden statt Kleinbuchstaben schöne Rahmen-Symbole dargestellt - ideal für GUIs Putty: - hier passiert bei SO/SI und ESC ) 0 gar nichts - normale Zeichen Betrieb Z180 an VT100-Stamp: - Der Quelltext eines TP-Programms sieht sehr wüst aus - überall ESC-Sequenzen drin... Ich bin mir recht sicher, dass ich TP für VT100 eingestellt habe, da es bei allen anderen Terminals (Win/Linux) gut aussieht. - Senden von SO/SI und ESC ) 0 zeigt nun auch dort anstelle der Kleinbuchstaben Sonderzeichen an - "Skatzeichen", Geschlechtssymbole, Paragraphen usw.
Marcel A. schrieb: > Somit funktionieren zwar Insert, Home, End, PageUp/Dn - aber werfen > immer ein ~ Zeichen in den Quelltext. Beschreibst du bitte noch mal den Fehler genau. Die Tasten PgUp, PgDn usw. der PS2-Tastatur am Propeller VT100 sollten eigentlich überhaupt keine ESC Sequenzen ausgeben. Hier kommt nur der Code des Tastaturtreibers zurück. (siehe keyb-DE.spin) Natürlich könnte man entsprechende ESC-Sequenzen noch programmieren. Oder habe ich dich gänzlich falsch verstanden?
Hallo Joe, stimmt. das gehört eigentlich in den Z180-Thread. Das VT100 Terminal macht mit den Sondertasten natürlich (noch) nichts. Den Effekt habe ich daher nur im Terminal am PC (Windows/Linux, minicom/putty/teraterm). PageDn/Up führt zu "ESC [ 5 ~" und "ESC [ 6 ~" TINST nimmt aber nur ESC[5 bzw. ESC[6 an (ohne ~). Bei PageDn springt es direkt (ohne Return) in die nächste Zeile des Konfig-Menüs (zeigt aber ~ an). Das "~" wird aber nicht abgespeichert. Ich meine, das wäre bei den alten AVRCPM-Varianten nicht so gewesen...
Marcel A. schrieb: > Ich meine, das wäre bei den alten AVRCPM-Varianten nicht so gewesen... Hab es gerade mal ausprobiert. Es war schon immer so. Da ich die CTRL-Codes nutze, ist mir das nie aufgefallen. In unserem VT100-Terminal könnte man es jedoch ohne Tilde einbauen.
Marcel A. schrieb: > PageDn/Up führt zu "ESC [ 5 ~" und "ESC [ 6 ~" > TINST nimmt aber nur ESC[5 bzw. ESC[6 an (ohne ~). Bei PageDn springt es > direkt (ohne Return) in die nächste Zeile des Konfig-Menüs (zeigt aber ~ > an). Das "~" wird aber nicht abgespeichert. Das habe ich mal angeschaut. Laut TINST-Doku sollten die Sequenzen 4 Zeichen lang sein dürfen, würde also gerade so passen. Es werden aber nur 3 Zeichen gespeichert. Die Sequenzen für die Tasten werden mit einem Längenbyte unmittelbar nacheinander im Programm (TURBO.COM) gespeichert:
1 | 4280 F5 7B 1A 01 0D 03 1B 5B 44 01 08 03 1B 5B 43 01 u{.....[D....[C.
|
2 | 4290 FF 01 FF 03 1B 5B 41 03 1B 5B 42 01 FF 01 FF 03 .....[A..[B..... |
3 | 42A0 1B 5B 35 03 1B 5B 36 03 1B 4F 48 03 1B 4F 46 01 .[5..[6..OH..OF. |
4 | 42B0 FF 01 FF 01 FF 01 FF 01 FF 01 FF 01 FF 01 FF 01 ................ |
5 | 42C0 FF 01 FF 01 FF 01 FF 01 FF 01 FF 01 FF 01 FF 01 ................ |
6 | 42D0 FF 01 FF 01 FF 01 FF 01 FF 01 FF 01 FF 01 FF 01 ................ |
7 | 42E0 FF 01 FF 01 FF 01 FF 01 FF 01 FF 01 FF 01 FF 00 ................ |
8 | 42F0 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
Für PageUp und PageDown habe ich die Tilde mal eingefügt und die Sequenzlänge jeweils auf 4 geändert.
1 | 4290 FF 01 FF 03 1B 5B 41 03 1B 5B 42 01 FF 01 FF 04 .....[A..[B..... |
2 | 42A0 1B 5B 35 7E 04 1B 5B 36 7E 03 1B 4F 48 03 1B 4F .[5~..[6~..OH..O |
3 | 42B0 46 01 FF 01 FF 01 FF 01 FF 01 FF 01 FF 01 FF 01 F............... |
4 | 42C0 FF 01 FF 01 FF 01 FF 01 FF 01 FF 01 FF 01 FF 01 ................ |
5 | 42D0 FF 01 FF 01 FF 01 FF 01 FF 01 FF 01 FF 01 FF 01 ................ |
6 | 42E0 FF 01 FF 01 FF 01 FF 01 FF 01 FF 01 FF 01 FF 01 ................ |
7 | 42F0 FF 00 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
8 | 4300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
Prinzipiell scheints zu funktionieren, aber sobald man eine der beiden Tasten drückt, wird der Anfang der Statuszeile gelöscht. Nicht tragisch, aber merkwürdig.
Angehängte Dateien:
-
P1011426.JPG
240 KB -
P1011425.JPG
230 KB -
P1011427.JPG
240 KB
Ich habe noch ein Problem mit der Firmware, zumindest in der "V1.7.2 test serial 3" (andere habe ich nicht getestet): Bei hohen Datenmengen werden Zeichen verschluckt. Das ist ähnlich wie bei meinem VT100 HP-Terminal, das habe ich später mit diversen Parametern in den Griff bekommen (Software XON / XOFF glaube ich). Anbei einige Bilder. Beim "Boot" ist noch alles ok, aber bei Help oder bei längeren Ausgaben unter CPM kommt es ins schleudern. Als wenn da ein Puffer überläuft. Habe die AVR CON über MAX... mit RX/TX/GND (3-adrig) an die VT100 Stamp angeschlossen... Am PC/Linux Terminal alles ok.
:
Bearbeitet durch User
Das sieht mir tatsächlich nach einem Pufferüberlauf aus. Im Bild P1011427.JPG kommen 16 Zeilen a 16 Zeichen = 256 Zeichen korrekt, dann kommt der Fehler. Dieser Fehler trat in einer frühen Version auch auf und ich hatte ihn durch Vergrößerung des Puffers beseitigt. In der jetzigen Version ist der Puffer wieder zugunsten der Flusskontrolle geschrumpft. Die Baudrate reduzieren sollte erst mal Abhilfe schaffen. Da ich gerade kein Spincompiler zur Hand habe, kann ich nicht nachschauen wie viel Speicher noch für eine mögliche Puffererweiterung zur Verfügung steht.
Joe G. schrieb: > Dieser Fehler trat in einer frühen Version auch auf > und ich hatte ihn durch Vergrößerung des Puffers beseitigt. Beseitigen läßt er sich dadurch nicht, nur verschieben. > In der jetzigen Version ist der Puffer wieder zugunsten der > Flusskontrolle geschrumpft. So könnte man es sagen. Ich habe vor ein paar Wochen angefangen, RTS/CTS und XON/XOFF Flußsteuerung in das Terminal und ins Z180-Stamp-Bios einzubauen. Leider komme ich z.Zt. kaum von der Stelle. > Die Baudrate reduzieren sollte erst mal Abhilfe schaffen. Füllzeichen einfügen geht auch [1]. ;-) > Da ich gerade kein Spincompiler zur Hand habe, kann ich nicht > nachschauen wie viel Speicher noch für eine mögliche Puffererweiterung > zur Verfügung steht. Es sind ca. 12 KByte frei. Sende- und Empfangspuffer lassen sich inzwischen getrennt einstellen (am Anfang von 'FullDuplexSerial.spin'), und die Größe muß auch keine 2er-Potenz mehr sein. [1] http://vt100.net/docs/vt102-ug/chapter6.html#S6.2.7.2 bzw. http://vt100.net/docs/vt102-ug/table6-12.html
Ich hab mich mal ran getraut... Der Tipp mit dem Buffer hat gut geklappt. Damit sieht es "erst" mal gut aus:
1 | CON |
2 | ' Buffer sizes |
3 | RX_SIZE = 2000 'Receive buffer size |
4 | TX_SIZE = 160 'Transmit buffer size |
Dann habe ich mal geschaut bzgl. des CTRL/SHIFT Problems und habe den Code aus dem Verzeichnis 1.1 (meldet sich mit 1.6) mit dem "aktuellen" verglichen. Folgender Tausch in den Zeilen 204ff hat etwas gebraucht:
1 | if ch > 0 |
2 | 'if ch & $FFC0 == $0240 'CRTL code |
3 | 'ch &= !$0020 'redefine as CTRL+char |
4 | |
5 | if ch > 608 and ch < 635 'CRTL code |
6 | ch:=ch-608 'redefine as CTRL+char |
Was auch immer das genau macht :-) Nun funktionieren die CTRL-Codes wieder. Und kurios: Turbo Pascal und Wordstar laufen nun "etwas". Zumindest die Startmenüs kommen, aber irgendwann steigt, unreproduzierbar an welcher Stelle, der VT100 aus. => Offenbar kommt er mit einigen Codes nicht klar? Dafür hatte ich 1 x den Effekt, dass SHIFT nicht mehr ging. Konnte ich aber nicht mehr reproduzieren. Und mir ist aufgefallen, dass bei WS der Bildschirm ziemlich zappelt (wie mit einem Handy neben einem Röhrenmonitor :-)). Es "zuckt" in der Darstellung. Sonst bei keinem anderen Programm. Ich hoffe, das hilft ein wenig. P.S.: Gerade lief WS recht stabil... Gruß Marcel
Marcel A. schrieb: > Und mir ist aufgefallen, dass bei WS der Bildschirm ziemlich zappelt > P.S.: Gerade lief WS recht stabil... Die Leiterführung zur VGA-Buchse ist, vorsichtig ausgedrückt, sehr unglücklich gewählt (tatsächlich Mist :-(. Lege mal den Quarz mit dem Gehäuse auf Masse (kleinen Draht anlöten). Bei deinen "Abstürzen" ist mir die Kausalität nicht ganz klar. TP und WS senden doch zunächst nur an das VT100. Dabei sollten beide Programme doch nicht abstürzen. Fehlerhaft kann nur das VT100 reagieren, wobei auch dabei nichts an WS oder TP gesendet werden sollte.
Das mit den Quarz erden probiere ich aus - wobei mir das nur bei WS aufgefallen ist - sonst alles bestens. Und richtig: Das VT100 stürzt ab, nicht WS/CPM. Der Bildschirm wird dunkel und der Monitor meldet "no signal".
:
Bearbeitet durch User
Marcel A. schrieb: > Folgender Tausch in den Zeilen 204ff hat etwas gebraucht: Hier ist tatsächlich ein Fehler. Ersetze mal bitte die Zeile ch &= !$0020 durch ch := ch-$260 Dann sollten die CTRL-Codes wieder gehen. ch := key.key if ch > 0 if ch & $FFC0 == $0240 'CRTL code ch := ch-$260 'redefine as CTRL+char
Prima, das hat geholfen! Und auch des Erden des Quarzes hat etwas gebracht: Kein Zucken mehr und WS/TP laufen bisher stabil. DANKE! Jetzt müsste ich mal schauen, wie das mit den Umlauten geht. Die waren ja mal drin, sind aber aktuell ja nicht drin (es kommt v, d und |).
Marcel A. schrieb: > Die waren > ja mal drin, sind aber aktuell ja nicht drin (es kommt v, d und |). Das VT100 kann derzeit keine Umlaute anzeigen. Sie sind ja nicht im Zeichensatz enthalten [1]. Oder meinst du das Senden von Umlauten? [1] Beitrag "Re: VT100-Terminal (VGA+PS2)" Nachtrag: Gesendet werden sie korrekt, habe ich gerade getestet.
:
Bearbeitet durch User
Ok, das mit den Umlauten wurde ja schon intensiv diskutiert. Ich traue
mich da aber (noch) nicht wirklich ran.
Inzwischen habe ich die für die TP-Entwicklung wichtigen Tasten {[]}
auch wiedergefunden.
Sie kommen bei ALTGR-I,O.K,L - ist das so gewollt oder an die falsche
Stelle gerutscht?
Denn laut Keyb-de.spin sind die eigentlich richtig:
1 | '$38 --- --- m j u 7 8 --- |
2 | ' ===== ===== ===== ===== ===== ===== ===== ===== |
3 | word $0000,$0000, "µ", $0000,$0000, "{" , "[" ,Sleep
|
4 | |
5 | ' |
6 | '$40 --- , k i o 0 9 --- |
7 | ' ===== ===== ===== ===== ===== ===== ===== ===== |
8 | word $0000,$0000,$0000,$0000,$0000, "}", "]", $0000 |
EDIT: Offenbar haben sich (wie man sieht) da einige Sonderzeichen eingeschlichen. Meine Parallax-Umgebung hat auch immer angemeckert irgendwas mit UniCode beim speichern - vermutlich sind die Windows - und Linux-Umgebungen nicht ganz Kompatibel im Dateiformat :-( Ich habe einfach die Tabelle table_alt_r aus der 1.6er drüberkopiert - UND NUN GEHEN DIE KLAMMERN!
:
Bearbeitet durch User
Ich habe mich nun mal ziemlich durch das Thema Zeichensätze und Fonts
durchgewühlt - der Code ist ja 1A dokumentiert...
Eines verstehe ich noch nicht:
Wir nutzen ja fonts-lin.spin - dort sind 2 Fonts a 127 Zeichen
definiert. Ich gehe davon aus, dass das jeweils die gleichen Zeichen
sind, aber unterschiedlich gemalt (Umschaltbar im Setup).
Dann haben wir noch 3 Zeichensätze (US, UK, Special) - wo sind die
definiert und vor allem - wo sind z.B. die Zeichen ("Malen") für den
Special Charakter definiert?
Marcel A. schrieb: > vermutlich sind die Windows - und > Linux-Umgebungen nicht ganz Kompatibel im Dateiformat Ja, so ist es leider [1]. > Wir nutzen ja fonts-lin.spin - dort sind 2 Fonts a 127 Zeichen > definiert. Genau dort stehen die Fonts. Es gibt auch nur diese beiden Fonts mit dem Format 8x16 Pixel, a 256 mögliche Zeichen. Um das Unterstreichen zu ermöglichen ist jeder Zeichensatz eigentlich doppelt aufgebaut - einmal ohne Unterstrich und einmal mit Unterstrich. Dadurch fehlt der Platz wie z.b. bei der Codepage 850. Um dennoch die Umlaute einzubauen hatten wir Platz gesucht [2]. Hier könnten sie also rein. Die beiden Zeichensätze unterscheiden sich übrigens durch die Pixelbreite. Bei Font 1 gibt es kein Leerzeichen zwischen einigen Zeichen. Das ist vor allem beo M oder O auffällig. Die Grafiksymbole (Zeichnen von Rahmen) gibt es nur im Font 0. Eine bessere Lösung ist uns noch nicht eingefallen. [1] Beitrag "Re: VT100-Terminal (VGA+PS2)" [2] Beitrag "Re: VT100-Terminal (VGA+PS2)"
Joe G. schrieb: > Genau dort stehen die Fonts. Es gibt auch nur diese beiden Fonts mit dem > Format 8x16 Pixel, a 256 mögliche Zeichen. Um das Unterstreichen zu > ermöglichen ist jeder Zeichensatz eigentlich doppelt aufgebaut - einmal > ohne Unterstrich und einmal mit Unterstrich. Das war mal so. Die Fonts haben jetzt tatsächlich nur noch 127 Zeichen. Die zweite Hälfte ist auskommentiert. Trotzdem wird das 8te Bit als Attribut für Unterstreichen verwendet. Marcel A. schrieb: > Dann haben wir noch 3 Zeichensätze (US, UK, Special) - wo sind die > definiert In der Font-Datei sind die Pixelmuster (Glyphen) für 128 Zeichen abgelegt. Welche Glyphe für welche Zeichensatzposition genomen wird, ist aber nicht starr (1:1), sondern hängt vom aktuell ausgewählten Zeichensatz ab [1]. Bisher gibt es 3 Mapping-Tabellen für die Zeichensätze US, UK und "Special characters and line drawing". Im Hauptprogramm unter CS_US, CS_UK und CS_DEC zu finden. > und vor allem - wo sind z.B. die Zeichen ("Malen") für den > Special Charakter definiert? Sende "ESC # 9" ans Terminal, und Du wirst es sehen. [1] http://vt100.net/docs/vt102-ug/chapter5.html#S5.5.2.16
Joe G. schrieb: > ch &= !$0020 durch > ch := ch-$260 > Dann sollten die CTRL-Codes wieder gehen. Gestern war ich zu müde zum Nachdenken, deshalb der Schnellschuss mit der Subtraktion. So hier wird es auch Leo C. wieder gefallen ;-) ch := key.key if ch > 0 if ch & $FFC0 == $0240 'CRTL code ch &= $001F 'redefine as CTRL+char
:
Bearbeitet durch User
Fein, ich bin nur verwirrt, dass 3 Charakter Sets auf 2 Fonts gemappt sind. US und UK unterscheiden sich ja kaum. Wenn ich also sowohl schöne Schrift (Font 1) haben will als als auch Grafiksymbole (aus Font 0) gleichzeitig, geht das überhaupt auf einer Seite? Wie kann ich denn überhaupt Font 0 und 1 per SW umschalten, ich dachte das wäre eine globale Einstellung mit VT100 Setup Menü. Oder ist das diese SO und SI? Derzeit sind die Umlaute ja auf Stellen wir FC und F6 gemappt, diese Bereiche sind ja auskommentiert. Also dann remapping auf die besagten Zeichen im Bereich < 127... Ich werde da mal ein bisschen fummeln.
Marcel A. schrieb: > Fein, ich bin nur verwirrt, dass 3 Charakter Sets auf 2 Fonts gemappt > sind. Nein! Die beiden Fonts haben mit dem Character-Set Mapping nichts zu tun. Schau Dir Die Artikel an, auf die Joe verwiesen hat oder den Link aus meinem letzten Posting. > Wie kann ich denn überhaupt Font 0 und 1 per SW umschalten Such mal in der Datei 'control-codes.md' nach font. > Also dann remapping auf die besagten Zeichen im Bereich < 127... Das war die Idee. Beitrag "Re: VT100-Terminal (VGA+PS2)"
Joe G. schrieb: > Gestern war ich zu müde zum Nachdenken, deshalb der Schnellschuss mit > der Subtraktion. So hier wird es auch Leo C. wieder gefallen ;-) > > ch := key.key > if ch > 0 > if ch & $FFC0 == $0240 'CRTL code > ch &= $001F 'redefine as So wars wahrscheinlich gedacht. Die Zeile
1 | ch &= !$0020 'redefine as CTRL+char |
läßt sich nur durch Blackout erklären. Alkohol wars jedenfalls nicht.
Inzwischen bin ich nicht mehr sicher, ob das so überhaupt richtig ist.
Warum wurde im ursprünglichen Code auf 608 < ch < 635
(0x260 < ch < 0x27B) getestet, statt auf 0x260 <= ch <= 0x27F ?
Ok, ^@ braucht kein Mensch und für {, |, }, und ~ gibt es auch auf der
US-Tastatur keine Tasten. Trotzdem leuchtet mir nicht ein, warum man die
entsprechenden Control-Codes ausfiltern sollte.
Aber der ganze Keyboard-Treiber ist für mich noch eine weiße Landkarte.
Leo C. schrieb: > Warum wurde im ursprünglichen Code auf 608 < ch < 635 > (0x260 < ch < 0x27B) getestet, statt auf 0x260 <= ch <= 0x27F ? Einfach der Bereich von CTRL-A bis CTRL-Z. Mann könnte natürlich auch den ganzen Bereich durchlassen.
Ich habe es geschafft, das Brett vor meinem Kopf zu durchsägen. Manoman... Die 127 Glyphen sind der maximale darstellbare Zeichenvorat und die Character Sets sind ein Mapping darauf... Somit ist klar, wie die Umlaute einzubauen sind. Für Font 0 hattet ihr ja euch schon auf die Stellen geeinigt. Ist auch wegen der Grafiksymbole der bessere Zeichensatz, obwohl ich Font 1 deutschlich geschmeidiger finde. Mal sehen, mangels einem richtigen Editor dafür werde ich mir entweder was in Excel basteln oder was programmieren. Man kann AUO ... dann ja recht einfach anpassen. Der Sonntag ist gerettet :-)
Angehängte Dateien:
-
P1011428.JPG
230 KB -
P1011429.JPG
230 KB
So, ich habe die Zeit genutzt und mit Excel und Papier den Zeichensatz
erweitert. Siehe Bilder.
Dazu musste ich erst einmal analysieren, wie in der fonts.spin die Daten
aufbereitet sind:
- jede Zeile enthält Zeichen - soweit klar
- Für jedes Zeichen gibt es pro Zeile 16 Werte 0..FF (Zeilen), welche
die 8 Bit Breite beschreiben.
- ACHTUNG 1: Die Daten sind spiegelverkehrt (Bits links erscheinen beim
Buchstaben rechts)
- ACHTUNG 2: Die Reihenfolge ist NICHT linear:
Block 1:
Zeile 4
Zeile 3
Zeile 2
Zeile 1
Block 2:
Zeile 8
Zeile 7
Zeile 6
Zeile 5
usw...
Folgende Belegungen wurden nun vorgenommen. Ich habe alles mit Kommentar
"Marcel" versehen, so dass man die Anpassungen schnell findet und wieder
in ein SVN etc. einpflegen kann:
1 | ASCII Code |
2 | DEC Special Pos in |
3 | DEC HEX Zeichen Zeichensatz |
4 | 98 62 Ä 03 |
5 | 99 63 Ö 04 |
6 | 100 64 Ü 05 |
7 | 191 65 ä 06 |
8 | 104 68 ö 09 |
9 | 105 69 ü 0A |
10 | ß 02 |
Im Moment scheitere ich aber am Matching. Einfach in der keybd-spin das Scancode-Mapping (z.B. für 52 - "ä") auf 03, 04 etc. zu setzen reicht nicht. Offenbar wird der Wert im Vorfeld mehrfach konvertiert. Ich habe es geschafft, dass verschiedene Zeichen angezeigt werden, aber die Umlaute habe ich nicht "getroffen", egal was für "Offsets" ich eingetragen habe - es lag immer um vielfache von 16 daneben in der der fonts-tabelle. Aber Anzeige allein reicht ja eh nicht aus. Letztlich müssen diese Buchstaben ja auch vom Zielsystem verarbeitet werden können - und ich denke, da klemmt es noch. Als was werden dann die Umlaute zum CPM-System geschickt und so weiter. Habt ihr eine Tipp sonst wühle ich mal weiter :-) P.S.: Zwischendurch hatte ich immer wieder das Problem, dass im TP-Editor manchmal ein einigen Zeile die SHIFT-Funktion nicht geht, in anderen Zeilen schon... sehr kurios. Bisher habe ich das keine Reproduzierbarkeit gefunden. Gruß Marcel
:
Bearbeitet durch User
Du warst schneller mit deinem Text, ich hatte gerade den Aufbau des Zeichensatzes beschrieben. Hier als Anhang.
Sehr gut! beim Mapping hast du jedoch noch einen Denkfehler ;-) Der Tastaturtreiber arbeitet schon korrekt mit den Umlauten, hier mußt du nichts ändern. Die eigenen Tastatureingaben werden auch nicht an das Terminal gesendet, sondern nur die Zeichen die von der V24 extern kommen. Genau diese Zeichen müssen über das Mapping auf den korrekten Zeichensatz gelegt werden. Das Mapping ist übder die 3 Tabellen, im Hauptprogramm unter CS_US, CS_UK und CS_DEC zu finden, realisiert [1]. [1] Beitrag "Re: VT100-Terminal (VGA+PS2)"
Marcel A. schrieb: > So, ich habe die Zeit genutzt und mit Excel und Papier den Zeichensatz > erweitert. Siehe Bilder. Super. > Folgende Belegungen wurden nun vorgenommen. Ich habe alles mit Kommentar > "Marcel" versehen, so dass man die Anpassungen schnell findet und wieder > in ein SVN etc. einpflegen kann: Das kannt Du gerne auch selbst einchecken. > Im Moment scheitere ich aber am Matching. Einfach in der keybd-spin das > Scancode-Mapping (z.B. für 52 - "ä") auf 03, 04 etc. zu setzen reicht > nicht. Terminal-Input und Terminal-Output, also Bildschirm und Tastatur haben nichts miteinander zu tun. Deshalb kommt die Datei "keybd-spin" (wahrscheinlich meinst Du keyb-DE.spin) hier überhaupt nicht ins Spiel. > Aber Anzeige allein reicht ja eh nicht aus. Letztlich müssen diese > Buchstaben ja auch vom Zielsystem verarbeitet werden können - und ich > denke, da klemmt es noch. Als was werden dann die Umlaute zum CPM-System > geschickt und so weiter. Genau. > Habt ihr eine Tipp sonst wühle ich mal weiter :-) Ein "National Replacement Character Set" (German) einbauen, siehe z.B.: http://vt100.net/docs/vt220-rm/chapter2.html#S2.4.3 http://vt100.net/docs/vt220-rm/chapter4.html#S4.4.1 und hier: Beitrag "Re: VT100-Terminal (VGA+PS2)" Dann muß man aber auf "\|{[]}~" verzichten, bzw. muß zwischen den beiden Char-Sets hin und her schalten, worauf CP/M-Programme ja auch nicht unbedingt eingerichtet sind. Eine andere, zusätzliche Möglichkeit, wäre ANSI, bzw DEC Multinational Character Set (teilweise) zu realisieren. Das wäre dann ein 8-Bit Zeichensatz, bei dem in unserem Fall die obere Hälfte sehr schwach besetzt wäre, da wir ja weiterhin nur 128 Zeichen insgesamt haben. Man hätte diese 128 Zeichen dann aber alle gleichzeitig im Zugriff. > P.S.: Zwischendurch hatte ich immer wieder das Problem, dass im > TP-Editor manchmal ein einigen Zeile die SHIFT-Funktion nicht geht, in > anderen Zeilen schon... sehr kurios. Bisher habe ich das keine > Reproduzierbarkeit gefunden. Das Problem habe ich auch.
Joe G. schrieb: > beim Mapping hast du jedoch noch einen Denkfehler ;-) Das war mir klar, nur nicht, welcher :-) Na, jedenfalls danke für den Hinweis. Ich schau heute Abend mal weiter. >Das Problem habe ich auch. Stimmt, das hattest du ja schon mal in ähnlicher Form erwähnt. Schaun wir mal. >Das kannt Du gerne auch selbst einchecken. Puh, damit habe ich noch nie gearbeitet. In meiner bisherigen Programmierer-"Karriere" kam ich immer mit Copy/Paste in Verzeichnissen aus... Brauche ich noch irgendwelche Berechtigungen?
> Brauche ich noch irgendwelche Berechtigungen? Nein. Du brauchst nur einen SVN-Clienten[1] für dein OS und das SVN-Password. Letzteres findest Du in Deinen Benutzereinstellungen. Hinweise gibts hier: https://www.mikrocontroller.net/articles/Hilfe:SVN Schnellanleitung: 1. Projekt in ein genehmes Unterverzeichnis auschecken. Wenn Du Platz genug auf Deiner Festplatte hast, kannst Du den gesamten Verzeichnisbaum auschecken. Die Repository-URL wäre dann: svn://mikrocontroller.net/avr-cp-m Ansonsten nur den interressierenden Teil. z.B: svn://mikrocontroller.net/avr-cp-m/trunk/VT100/source/work 2. Dateien editieren, oder Deine geänderten Dateien drüber kopieren. 3. Vor dem Einchecken darauf achten, daß die geänderten oder neuen Dateien im utf-8 Format sind. BST hat z.B. einen Schalter in den IDE-Preferences: "Save as UTF8". 4. Einchecken (Checkin) Dabei bitte unbedingt einen Grund für die Änderungen angeben (Log Message). Muß kein Roman sein, aber wenigstens ein paar Stichworte. Die Dateien, die geändert wurden, muß man in der Log-Message nicht angeben, da SVN darüber ja Buch führt. [1] z.B.Tortoise SVN (Windows) oder SVN Workbench (Linux)
Leo C. schrieb: > Eine andere, zusätzliche Möglichkeit, wäre ANSI, bzw DEC Multinational > Character Set (teilweise) zu realisieren. Diese Lösung halte ich für geeigneter als immer umzuschalten. Font 0 ist ja schon auf dem besten Wege dahin :-)
Joe G. schrieb: > Leo C. schrieb: >> Eine andere, zusätzliche Möglichkeit, wäre ANSI, bzw DEC Multinational >> Character Set (teilweise) zu realisieren. > > Diese Lösung halte ich für geeigneter als immer umzuschalten. Font 0 ist > ja schon auf dem besten Wege dahin :-) Ui, da lasse ich mal besser die Profis ran :-) Ich scheitere schon daran, dass ich meine Änderungen nicht ins SVN bekomme (angeblich gibt's meinen User da nicht). @Joe: Ich würde gerne mein TP von 25 auf 30 Zeichen umstellen. Nun fragt mich TINST, welchen "Screen" ich nehmen/ändern möchte (VT100 wird da ja nicht angeboten). Hast du hier ANSI genommen oder "31-other" und für VT100 alles zu Fuß eingestellt? Ich meine, bei 31 MUSS man alles neu eingeben oder werden mit "Enter" die aktuellen Einstellungen behalten? Ich will mir das nicht kaputt machen... EDIT: MIST. Habe es gerade versucht (mit ENTER - nun ist es zerschossen). Habe nun ANSI genommen (war das auch vorher ...?) und auf 30 Zeilen geändert - scheint gut zu gehen.
:
Bearbeitet durch User
Marcel A. schrieb: > Ich scheitere schon daran, dass ich meine Änderungen nicht ins SVN > bekomme (angeblich gibt's meinen User da nicht). Die Meldung kommt auch, wenn das Passwort nicht zum User paßt. Ich habe jetzt einiges ausprobiert. Mit dem Passwort, daß hier auf der Benutzerseite angezeigt wird, gehts nicht. Mit einem früher mal gespeicherten Passwort gehts.
Marcel A. schrieb: > Ich scheitere schon daran, dass ich meine Änderungen nicht ins SVN > bekomme (angeblich gibt's meinen User da nicht). Du hattest keine Schreibrechte, jetzt sollte es gehen.
Angehängte Dateien:
-
font.png
13 KB
Ich habe mir jetzt mal einen quick&dirty fonteditor (allerdings in .NET) gebaut, der direkt Codezeilen erzeugt bzw. einliest Wenn ich das ganz noch ein wenig mit Fehlerbehandlung versehen habe und vielleicht sogar 127 Zeichen gleichzeitig verarbeiten kann, stelle ich das EXE hier mal ein die Tage. Noch eine Frage: Ich finde zwar immer noch Font1 besser als Font0, aber wenn Font0 sich zum Standard entwickelt, können wir dann nicht den Platz von Font1 für weitere Zeichen etc. nutzen?
:
Bearbeitet durch User
Das sieht ja recht gut aus :-) Doch ich glaube, dass der Schwerpunkt besser auf dem Konverter Spin_to_Font und Font_to_Spin liegen sollte. Der Font sollte dann in einem der üblichen Formate (z.B. .bdf oder .fnt) vorliegen. Dazu gibt es dann genug Fonteditoren wie z.B. [1,2]. [1] http://hukka.ncn.fi/?fony [2] http://fontforge.github.io/en-US/downloads/windows/
Marcel A. schrieb: > Ich habe mir jetzt mal einen quick&dirty fonteditor (allerdings in .NET) > gebaut, der direkt Codezeilen erzeugt bzw. einliest Sowas gibts schon, z.B: http://www.rayslogic.com/Software/RaysFontEditor/RaysFontEditor.htm Neuere Version gibts im Forum ganz unten auf Der Seite: http://forums.parallax.com/discussion/141644/font-editor-preview-5/p3 > Noch eine Frage: Ich finde zwar immer noch Font1 besser als Font0, aber > wenn Font0 sich zum Standard entwickelt, können wir dann nicht den Platz > von Font1 für weitere Zeichen etc. nutzen? Nein. Joe G. schrieb: > Doch ich glaube, dass der Schwerpunkt besser auf dem Konverter > Spin_to_Font und Font_to_Spin liegen sollte. Der Font sollte dann in > einem der üblichen Formate (z.B. .bdf oder .fnt) vorliegen. Dazu gibt es > dann genug Fonteditoren wie z.B. [1,2]. Sehe ich auch so. Wir können dann auch ganz einfach bestehende Fonts einbinden. z.B. Terminus: http://terminus-font.sourceforge.net/
Leo C. schrieb: > Neuere Version gibts im Forum ganz unten auf Der Seite: > http://forums.parallax.com/discussion/141644/font-editor-preview-5/p3 Mist :-) Den Link hatte ich mir die Tage schon mal angesehen, dann aber im Eifer des Gefechts vergessen und selber angefangen. Export scheint das richtige Format zu unterstützen, beim Import ist er gerade abgestürzt - wahrscheinlich war da noch zu viel "Müll" im Textfile.
Marcels Umlaute jetzt können jetzt als deutsches National Replacement Character Set (NRC set) ausgewählt werden.
1 | ESC ( K SCS Select Character Set DE --> G0 |
2 | ESC ) K SCS Select Character Set DE --> G1 |
Die Platzierung im Zeichensatz erfolgt nach dieser Tabelle: http://vt100.net/docs/vt220-rm/table2-10.html
Das ja wirklich gewöhnungsbedürftig ;-) macht aber was es soll.
Joe G. schrieb: >> Eine andere, zusätzliche Möglichkeit, wäre ANSI, bzw DEC Multinational >> Character Set (teilweise) zu realisieren. > > Diese Lösung halte ich für geeigneter als immer umzuschalten. Font 0 ist > ja schon auf dem besten Wege dahin :-) Ist jetzt drin. Neue Steuercodes:
1 | ### C1 Control Characters |
2 | |
3 | Code Equiv. |
4 | Mnemonic (Hex) ESC Seq Name |
5 | ---------------------------------------------------------- |
6 | IND 84 ESC D Index |
7 | NEL 85 ESC E Next line |
8 | RI 8D ESC M Reverse index |
9 | CSI 9B ESC [ Control sequence introducer |
10 | ST 9C ESC \ String terminator |
11 | |
12 | ### Escape sequences |
13 | |
14 | ESC ~ LS1R Invoke G1 into GR |
15 | ESC n LS2 Invoke G2 into GL |
16 | ESC } LS2R Invoke G2 into GR (default) |
17 | ESC o LS3 Invoke G3 into GL |
18 | ESC | LS3R Invoke G3 into GR |
19 | |
20 | ESC ( < SCS Select Character Set DEC supplemental --> G0 |
21 | ESC ) < SCS Select Character Set DEC supplemental --> G1 |
22 | ESC * A SCS Select Character Set UK --> G2 |
23 | ESC * B SCS Select Character Set US ASCII --> G3 |
24 | ESC * K SCS Select Character Set DE --> G3 |
25 | ESC * < SCS Select Character Set DEC supplemental --> G3 |
26 | ESC * 0 SCS Select Character Set DEC special characters and line drawing set --> G3 |
27 | ESC + A SCS Select Character Set UK --> G4 |
28 | ESC + B SCS Select Character Set US ASCII --> G4 |
29 | ESC + K SCS Select Character Set DE --> G4 |
30 | ESC + < SCS Select Character Set DEC supplemental --> G4 |
31 | ESC + 0 SCS Select Character Set DEC special characters and line drawing set --> G4 |
Doku dazu im VT220 Manual, Kapitel 2 (Character Encoding) und Kapitel 4 (Received Codes) http://vt100.net/docs/vt220-rm/contents.html
Frohe Weihnachten! Zum Abspielen empfehle ich 9600 Baud. Auf der VT100-Platine gehts auch mit 115200, wenn man RTS/CTS FLußsteuerung verwendet, aber schöner wirds dadurch nicht.
Leo C. schrieb: > Frohe Weihnachten! Danke, Dir auch! Unglaublich was man mit so einem Zeichensatz alles erzeugen kann. Ich fühlte mich gerade wie bei einem Telespiel Ende der 70ziger.
Hallo Joe, kurze Frage die dicken SMD C's (9,11,10,6) sind das einfach nur 1206er? Oder was spezielles? Gruesse!
Verstanden, danke! Das ist doch der aktuelle Plan zum 1.1 Board? https://docs.google.com/viewer?url=http%3A%2F%2Fwww.mikrocontroller.net%2Fattachment%2F246743%2FVT100_sheet_V1_1.pdf ??? https://www.mikrocontroller.net/attachment/255285/VT100_Ready.jpg ???
Hi Joe, icke nochmal :) Ist das die Richtige? https://www.reichelt.de/index.html?ACTION=3;ARTICLE=52026;SEARCH=EB-DIOS .
Ja, sollte passen. Damit die Farbe auch noch zu Stecker paßt, gibt es die sogar in blau ;-) Best. Nr. EB-DIOS M06V
Joe G. schrieb: > die sogar in blau ;-) Best. Nr. EB-DIOS M06V Genau. blau/violett für Tastatur, grün/türkis für Maus, grau geht gar nicht. ;-) https://de.wikipedia.org/wiki/PS/2-Schnittstelle
:) Danke! Noch eine, hoffentlich letzte Frage. :) Das .bin auf den Propeller flashen, muss ich mir dafür die ganze Windows IDE installieren? Gibts was kleines für Linux? So ein propload.py :)
Eigentlich gibt es nur 100nF und 10µF. 0.1F würde sehr sehr groß werden ;-)
Grosser Mist, ich hab bei meiner Reicheltbestellung den BC817-25 und den Kurzhubtaster vergessen heul 0,19 CENT Warenwert ... Versandkosten ... 5.60 EUR Ob wohl hier jemand so nett wäre mir damit auszuhelfen? 2,50 EUR im Brief wäre ok?
Hallo W3ll, ich hatte Dir eine PM geschickt. Ist die nicht angekommen? Kopie war angekreutzt, und die kommt auch nicht. :( Wenn Du mit einem 2N3904 statt BC817 zufrieden bist, könnte ich Transistor und Taster heute noch zur Post bringen.
Hee Leo, nee Du, nischt angekommen ?! Ick nehm alles :) Joe, passt das 2N3904?
:
Bearbeitet durch User
W3ll S. schrieb: > Ick nehm alles :) Dann schick mir eine PM mit Deiner Postadresse. > Joe, passt das 2N3904? Es ist eher ein MMST3904, und ja, der passt. Gerade nochmal nachgemessen: Stromverstärkung reicht locker, und die Pinbelegung auch, auch wenn letzteres auf dem Datanblatt anders auszusehen scheint. Nachtrag, gerade mal nachgeschaut: Der Transistor sitzt auf meiner VT100-Terminal-Platine V1.1. Und die funktioniert.
:
Bearbeitet durch User
Arghh, ich glaube mein FT232RL hat einen Schuss ...
1 | Unbekanntes USB-Gerät (Fehler beim Anfordern einer Gerätebeschreibung.) |
Spannungen habe ich geprüft. :(
W3ll S. schrieb: > Arghh, ich glaube mein FT232RL hat einen Schuss ... > >
1 | Unbekanntes USB-Gerät (Fehler beim Anfordern einer |
2 | > Gerätebeschreibung.) |
> > Spannungen habe ich geprüft. > > :( So ein Mist, war eine Brücke in der USB-Buchse, ganz hinten drin :( Naja, ein FT232RL getötet und wieder was gelernt.
W3ll S. schrieb: > Naja, ein FT232RL getötet und wieder was gelernt. Ist der wirklich defekt? An welcher Stelle war den die Brücke?
Angehängte Dateien:
Joe G. schrieb: > W3ll S. schrieb: > Ist der wirklich defekt? An welcher Stelle war den die Brücke? Nachdem ich den FT232RL ausgelötet hatte, war er es :D Hätte ich sorgfältiger gesucht, hätte ich die Brücke in der USB Buchse gefunden. Die war ganz hinten drin.
:
Bearbeitet durch User
Joe, ich hätte da nochmal ein paar Fragen :) Liegt die 1.7 als Binary irgendwo rum? Port 0 = USB / Port 1 = SER? Kann man RX/TX im Sourcecode einfach tauschen? Ich hab nur Nullmodemkabel :D .
Die letzte Version sollte die V1.7.4 sein, anbei das Bin-File. Die PIN-Konfiguration des IC kannst du in der VT100_VGA_color.spin ändern. Derzeit sie sie wie folgt aus: Wenn du Rx/Tx änderst, stimmt die Treiberansteuerung jedoch nicht mehr. 'pin configuration KEY_DATA = 26 'Keyboard Data Pin KEY_CLK = 27 'Keyboard CLK Pin VIDEO = 16 'Video output Pin(s) TXD = 30 'Serial Transmit RXD = 31 'Serial Receive Nachtrag: Nochmals zum Schaltungsverständnis. RxD# ist ja mit den Treiberausgängen des MAX3241 und des FT232 verbunden. TxD# mit dessen Eingängen. Wenn du nun RxD und TxD im Prozessor tauscht (was möglich ist) sind jedoch dann Ausgänge auf Ausgänge und Eingänge auf Eingänge geschaltet. Das möchtest du sicher nicht. Bei verdrehten Kabel hilft also nur Kabel drehen ;-)
:
Bearbeitet durch User
Danke Joe! bei 1.7.3 will mein Keyboard nicht, es reagiert nicht auf F1.
:
Bearbeitet durch User
Das Menü wird nicht mehr mit F1 aufgerufen sondern mit Ctrl+PrintScreen Die aktuellen Quellen stehen übrigens hier: https://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/VT100/source/work/?sortdir=down
Prima, Glückwunsch! Dann viel Freude damit :-)
Joe G. schrieb: > Prima, Glückwunsch! > Dann viel Freude damit :-) Werd ich haben, ich mach gerade eine PDP11 für mich fertig, das kommt das dran :-) Übringens hab ich wieder viel gelernt, ich weiss nun auch was Errata ist :D Nachdem ich 2 Stunden lang Lötfehler gesucht hatte :)
:
Bearbeitet durch User
Bin neu im Forum und hab den Beitrag erst jetzt gefunden. Sehr interessantes Projekt !! Gibt es vielleicht noch eine Platine und/oder Chips ?
Leider sind nun alle Platinen aufgebraucht, auch Propeller IC's sind alle vergeben. Bei Bedarf (5-10 Stück) könnte ich jedoch eine neue Serie auflegen und Änderungswünsche berücksichtigen.
Joe G. schrieb: > alle vergeben. Bei Bedarf (5-10 Stück) könnte ich jedoch eine neue Serie > auflegen und Änderungswünsche berücksichtigen. Sehr schönes Projekt! Leider ist der letzte Post schon ja nun schon etwas älter. Hätte auch Interesse an 2 Platinen, weil ich gerade sowas für meine Retro Computer suche. Vielleicht finden sich ja noch mehr Interessenten.
w3llschmidt schrieb: > Also 2x, dann aber bitte mit USB Anschluss würde ich nehmen :) USB ist doch immer mit dabei, die V24 muss ja nicht bestückt werden ;-) Jetzt sind es ja schon 4 Platinen :-) Nochmal 2 und die Bestellung lohnt sich.
Zur Not nehme ich noch eine - für das NDR NKC Projekt :-) Dort läuft übrigens inzwischen ein Vinculum - für die Z180-Stamp warte ich da ja noch sehnsüchtig drauf :-)
Das schlechte Wetter hat heute zur Überarbeitung des VT100-Terminals eingeladen ;-) Ich habe folgende Änderungen implementiert: - zweiten EEPROM umschaltbar über JP2 - Audioausgang (JP3 und JP4) - programmierbar nur noch über USB Der zweite EEPROM bietet die Möglichkeit zwei unterschiedliche Softwareversionen zu implementieren oder zu testen. Werner [1] hat einige lustige Spiele (Tetris, Sokoban, usw.) für den Propeller geschrieben. Da die Hardware ähnlich aufgebaut ist, würden die Spiele auch auf dem Terminal laufen (zweiter EEPROM). Weiterhin erfolgt eine Soundausgabe über die Emulation eines AY-3-8910 Chip. Also habe ich den Soundausgang auch gleich mit auf die Leiterplatte gebracht. Leider bietet das Gehäuse keinen Platz für eine 3.5mm Audiobuchse, so dass ich einfach nur zwei Pins dafür vorgesehen habe. Johannes (Retro Nerd) würde die Bestellung der Leiterplatte übernehmen. [1] http://propeller.ws-nbg.de/main.php
Joe G. schrieb: > w3llschmidt schrieb: >> Also 2x, dann aber bitte mit USB Anschluss würde ich nehmen :) > > USB ist doch immer mit dabei, die V24 muss ja nicht bestückt werden ;-) > sich. Hi Joe, ich meinte als Tastaturanschluss.
W3ll S. schrieb: > Hi Joe, ich meinte als Tastaturanschluss. Verstehe, USB statt PS2-Tastatur. Dazu müßte ja ein USB-Host auf dem Propeller impelmentiert werden. Das habe ich jedoch nicht vorgesehen.
Ja, PS2 Keyboards gibts irgendwie nicht mehr so schöne. Ist aber nicht kriegsentscheidend.
Würde sowas für eine USB Tastatur funktionieren? https://www.amazon.de/LINDY-70002-USB-PS-Maus-Tastauradapterkabel/dp/B0037KJB96/ref=pd_lpo_vtph_147_tr_t_2?_encoding=UTF8&refRID=HAB82292ZRWCT2KBK6AZ&th=1
Retro N. schrieb: > Würde sowas für eine USB Tastatur funktionieren? Nur, wenn das eine bilinguale Tastatur ist, also die Tastaturhardware selbst sowohl das USB- als auch das PS/2-Protokoll kennt. Bei entsprechenden Tastaturen (und Mäusen) liegt so ein Adapter allerdings bei; ist so ein Adapter nicht vorhanden, kann davon ausgegangen werden, daß die Maus/Tastatur nicht bilingual ist, und dann funktioniert so ein Adapter nicht.
Das ist eigentlich die einzige Tastatur die stilecht passen würde :D https://www.ebay.de/itm/NEW-IBM-Model-M-1392934-clicky-Space-Saving-Keyboard-SSK-bolt-modded-ID-5043572/292328381678?epid=1500261303&hash=item4410211cee:g:flAAAOSwJtdaCiRK
:
Bearbeitet durch User
stilecht sind einige https://www.qwerkywriter.com/ https://www.kickstarter.com/projects/elretron/penna-retro-bluetooth-keyboard-starting-as-low-as https://gadgetswizard.com/azio-retro-classic-penna-typewriter-modern-keyboards-wearing-vintage-clothes
Retro N. schrieb: > Stilecht wäre das hier: > https://hackaday.com/2013/08/13/usb-adapter-for-an-old-vt100-keyboard/ Jepp. Die anderen Tastaturen davor waren alle PC- und keine echten VT100-Tastaturen. Ich selbst habe noch früher auf VT100-Terminals (und VT220) in C programmiert. Lang ists her.
:
Bearbeitet durch Moderator
Ich würde mich auch überreden lassen eine eigenes VT100 Keyboard zu designen. Cherry MX Tasten sind ja verfügbar und einen Controller für eine Tastaturmatrix auf PS2 bekommt man hier [1]. Bleiben für mich nur drei Fragen offen: 1. Welche Tasten und welche Anordnung sollte ein „Retro“ VT-100 Terminal haben? 2. Wo gibt es möglichst „schöne“ Keycaps für die deutschen Umlaute? Für ein US Layout findet man ja Anbieter [2]. 3. Gibt es dazu überhaupt Interesse? [1] https://www.codemercs.com/downloads/keywarrior/KW_Datasheet.pdf [2] https://de.aliexpress.com/store/product/Keycaps-Set-for-Mechanical-Keyboard-Gaming-Keyboard-Keycaps-60-68-87-108-keys-US-Layout-Keycaps/1815036_32808325110.html
Wäre prinzipiell auch an einer Platine interessiert, an einer Tastatur eher nicht, hab noch eine Cherry G81 1800l mit PS2 Anschluss...
Joe G. schrieb: > 2. Wo gibt es möglichst „schöne“ Keycaps für die deutschen Umlaute? Für Massdrop ... https://www.massdrop.com/buy/massdrop-x-mito-dsa-legacy-custom-keycap-set Dort legen die immer wieder Serien auf, oft auch mit ISO/NORDE Keycaps. Obwohl ich mittlerweile komplett auf US (ANSI)umgestiegen bin.
Aus der neuen Serie sind noch 6 Platinen übrig. Bei Interesse bitte PN an mich. Aufgrund der vorhandenen Nachfrage verschicke ich aber erst mal nur max. 2 Platinen pro Person - First come first serve. Bei größerer Nachfrage würde ich kurzfristig noch mal eine 2. Serie auflegen.
Joe G. schrieb: > Ich würde mich auch überreden lassen eine eigenes VT100 Keyboard zu > designen. Erstmal um dies richtig zu verstehen... ...ein "Brotkasten light", mit MiniDIN-PS/2 (anstelle der 6.3mm Klinke), ohne Funktionstasten, PCB, Gehäuse? (um dies an dein VT100-VGA anzuschliessen) Oder ...ein "Brotkasten light", mit onboard Propeller als VT100-VGA, an den direkt DC, VGA & Seriell angeschlossen wird, PCB, Gehäuse? (alternatives Design zum bisherigen VT100-VGA, in Tastatur integriert) Meine persönliche Meinung: Nur Tastatur dürfte wohl teuer werden. Retro-look hin oder her, das wird eine grosse aber eher "leere" PCB: viele cm^2 welche bloss als Tastenträger herhalten (auch wenn dies so sein muss). Tastaturen werden von vielen in Massen hergestellt, auch mit Cherry-Switches - ergiebt hier ein DIY / Keinserienprodukt Sinn? Hingegen den Propeller-VT100 direkt ins Tastaturgehäuse integriert... reduziert doch schon mal ordentlich den Kabelverhau im Betrieb und würde den Design- Eigenbauaufwand deutlich besser rechtfertigen. Immernoch meine pers. Meinung: Eine "marktgängige" (PS/2) Tastatur m. Cherry-Switches ausfindig machen, diese modifizieren sodass: - PS/2 Kabel weg kommt, - custom PCB m. Propeller-VT100 rein kommt. Ob dann das Tastaturgehäuse zus. zu Bearbeiten ist um DC, VGA, DSub9 Anschlüsse unterbringen zu können oder ob am urspr. Kabelausgang eine "Kabelpeitsche" mit den 3 Anschlüsse rauskommt, gilt es abzuklären. Ja, auf diesem Weg leidet der Retrofaktor. Wäre es der Gewinn aller F-Tasten & zivilisierte Anordnung d. Pfeiltasten nicht wert? (was dann mehr VT220 geht, erstmals ohne deren Funktionsumfang) (Ist kein Cog mehr frei, der die Tastenmatrix abfragen könnte?)
Angehängte Dateien:
-
vt100.png
790 KB
Countdown .... Noch 4 Platinen von der neuen Serie V1.2 verfügbar. Bei Interesse bitte PN an mich. Ich verschicke gegen eine Versandkosterstattung. Aufgrund der vorhandenen Nachfrage verschicke ich aber erst mal nur max. 2 Platinen pro Person - First come first serve.
:
Bearbeitet durch User
Angehängte Dateien:
-
Detail.jpg
260 KB
Bei der Bestückung der neuen V1.2 Platine habe ich Inkonsistenzen zwischen dem hier am 12.11.2017 veröffentlichten Schaltplan (Eagle PDF Ausdruck) und dem tatsächlichen Leiterbahnverlauf auf der Platine entdeckt. Dies betrifft die in V1.2 geänderte Verschaltung der EEPROMs (siehe Detailfoto der Platine). Zunächst fällt auf, dass beim 1. EEPROM (IC1) die Pins 1-4 direkt mit GND verbunden sind; laut Schaltplan dient A0 (Pin 1) aber zur Umschaltung zwischen EEPROM 1 & 2 über Pull up Widerstände und JP2. Ich vermute auf der Platine ist R21 "verrutscht" (sollte nur mit Pin 1 aber nicht mit Pin 2 von IC1 verbunden sein). Die Eagle Files wurden ja leider hier noch nicht gepostet, sonst könnte man sich die Signale im Layout nach Namen anzeigen lassen. Auch sollte der DRC hier einen "overlap" Fehler gemeldet haben. Des Weiteren habe ich per Messung festgestellt, dass beide Pads von R1 untereinander und mit 3,3V verbunden sind (per Durchkontaktierung auf der Rückseite der Platine). Damit liegen beide SDA Leitungen der EEPROMs fest auf 3,3V und ein Datenaustausch mit dem Prozessor ist nicht möglich. Bin ich der erste, der hierüber stolpert oder hat jemand schon einen Workaround hierzu? - Thomas
Angehängte Dateien:
-
VT100.jpg
170 KB
Ja, ich kann diesen Fehler auch auf meiner LP von Retro Nerd bestätigen. In meinem Layout (sie Anhang) ist dieser Fehler nicht vorhanden. Deshalb kann ich nur vermuten, dass er bei der Konvertierung der Eagleversionen (ich verwende die Versionen über 8.xx) aufgetreten ist. Der beidseitige 3.3V Pegel an R1 ist auch auf den verschobenen Widerstand R21 zurückzuführen. Da hilft wohl nur auf dem Layout „kratzen“. Anbei noch die kompletten Eagle Daten.
Danke für die schnelle Antwort und die Eagle Files; diese konnte ich übrigens problemlos mit Eagle 6.60 laden. Auch hier wird der korrekte Leiterbahnverlauf angezeigt und der DRC erzeugt keinerlei Meldungen.
Angehängte Dateien:
-
PCB-Fix1.jpg
270 KB -
PCB-Fix2.jpg
130 KB -
Top_view.jpg
190 KB -
Intro_screen.jpg
110 KB
Nach dem Durchtrennen 2er Leiterbahnen und dem Auflöten von R21 in bedrahteter Variante auf der Rückseite läuft auch meine fehlerhafte V1.2 Platine (siehe Fotos). Ist V1.74 zu finden im SVN Archiv unter /trunk/VT100/source/work/ die aktuelle Firmware?
Prima! Glückwunsch. Ja, die V1.7.4 ist die aktuelle Software.
Hallo Joe G., hast Du noch Leerplatinen vom VT100-Terminal? Danke Gruß Michael
Ahoi! Ich hätte Interesse an so einem Terminal, verfüge aber leider nicht über SMD-Verarbeitungsmöglichkeiten. Hat Jemand einen Tipp, wo ich sowas ggf. einfach "einkaufen" könnte?
Hi, SMD ist echt kein Thema. Wenn du löten kannst, ist SMD noch viel einfacher. Es kommt nur auf die Technik an! Du brauchst nicht jedes Beinchen unter dem Mikroskop einzeln löten. Der Trick ist ordentlich Flussmittel und dann großflächig die Chips mit Lötzinn bearbeiten. Dazu gibt es eine Menge guter Youtube-Anleitungen - echt kein Thema. Geht sogar schneller als die bedrahteten Bauteile. Gruß Marcel
Hallo Joe G. Ich habe die VT100 Platine V1.2 erfolgreich in Betrieb nehmen können. Die PS2 Tastatur und USB funktionieren einwandfrei. Die serielle Schnittstelle und die Tonausgabe über JP3/4 habe ich nicht bestückt. Ich habe von der URL: http://propeller.ws-nbg.de/main.php mir Tetris runtergeladen und auf die VT100 Karte geladen. Der Startbildschirm ist sichtbar, jedoch werden Eingaben über die PS2 Tastatur blockiert. Stört hier die USB Schnittstelle? Vielen Dank für Deine Mühe Gruß Michael
Es ist erst mal kein Hardwareunterschied zu erkennen. Im VT-100 Terminal werden zwar P0 bis P7 verwendet, in Teris jedoch nicht benutzt (soviel ich auf die Schnelle im Quelltext erkennen konnte). In der Defaulteinstellung von Teris ist ja der englische Tastaturtreiber eingebunden, hast du es mal mit dem deutschen versucht. Ich werde heute Abend auch mal selber den Versuch mit beiden Treibern starten.
Hallo Joe G. vielen Dank für Deine Rückantwort. Ich habe Tetris jetzt auch mit dem deutschen Tastaturtreiber probiert, jedoch ohne Erfolg. Wenn Du bitte kurz berichtest, ob es bei Dir funktioniert wäre für mich sehr hilfreich. Dann würde ich mich bei meiner VT100 an die Fehlersuche machen. Danke Dir Gruß Michael
Angehängte Dateien:
-
Tetris.jpg
230 KB
Michael S. schrieb: > Wenn Du bitte kurz berichtest, ob es bei Dir funktioniert wäre für mich > sehr hilfreich. Ich habe es gerade mit beiden Treiberversionen getestet, beide Versionen laufen bei mir. Nach dem Startbildschirm weiter mit "Space" und dann kommt man zu den Spielvoreinstellungen.
:
Bearbeitet durch User
Hallo Joe G. danke für Deine Nachricht. Dann werde ich mich mal auf die Suche machen. JP1 habe ich auch schon mal entfernt, ohne Verbesserung. Bei mir leuchtet die Num-Lock Led ständig auf. Sie läßt sich auch durch mehreres drücken nicht ausschalten. Hallo hängt die PS2 Tastatur. Danke Gruß Michael
So, hab den Fehler gefunden. Meine Tastatur mit PS2 Stecker machte das Problem, obwohl diese im VT100 Modus problemlos funktionierte. Eine Tastatur mit USB auf PS2 Stecker funktioniert problemlos. Darauf muß man erstmal kommen :-(. Letztendlich blieb diese Fehlerquelle als letztes übrig. Ganz verstehen tu ich es trotzdem nicht. Nochmals Danke Joe G. für Deine Unterstützung. Gruß Michael
An der Hardwareversion kann es nicht liegen. Ich habe mal spaßeshalber alle drei Versionen (1.0 – 1.2) mit Tetris geladen. Alle drei funktionieren bei mir. Es gibt auch keine Stelle im Quelltext wo P0 bis P7 vom Propeller bei Teris genutzt werden. Versuche es doch zunächst mal einer anderen PS2-Tastatur.
Hallo zusammen, ich habe den keyboard driver vom Joe G. ins PROPTRIS(Tetris) Verzeichnis kopiert. Den Originalen Keyboard driver habe ich umgennant. Den keyb-DE.spin(Joe G.) habe ich umgenannt in KEYBOARD_EN.spin. Nach erneutem Kompilieren ging dann auch meine "fehlerhafte" Tastatur mit PS2 Stecker. Der keyboard driver vom Werner ist wohl etwas zeitkritischer geschrieben :-) . Gruß Michael
Hallo Joe G. könntest Du bitte über das Menu ein local echo ermöglichen? Es würde einen Test auch ohne angeschlossenes Gerät ermöglichen. Wenn es für euch keinen Sinn macht, auch ok. Danke Gruß Michael
Michael S. schrieb: > könntest Du bitte über das Menu ein local echo ermöglichen? Das Menü ist schon recht voll, so dass mir auf die Schnelle die Tastenkombination ALT+e (wie Echo) eingefallen ist. Also ALR+e toggelt nun zwischen Echo und keinem Echo, die serielle Ausgabe erfolgt immer. Bitte mal testen.
:
Bearbeitet durch User
Hallo Joe G. vielen Dank für die schnelle Einbindung. <ALT>e als local echo on/off funktioniert. ESC Seqenzen werden jedoch nicht verarbeitet. Z.B. <ESC>c kein Reset des Terminals Hab ich da einen Denkfehler? Gruß Michael
Hallo Joe G.,
ich nehme alles zurück. Mit dem deutschen keyboard driver von Dir
funktionieren auch die ESC Seqenzen.
Ich verwendete, da ich eine US-Tastatur verwende folgenden:
''***************************************
''* PS/2 Keyboard Driver v1.0.1 *
''* Author: Chip Gracey *
''* Copyright (c) 2004 Parallax, Inc. *
''* See end of file for terms of use. *
''***************************************
{-----------------REVISION HISTORY-----------------
v1.0.1 - Updated 6/15/2006 to work with Propeller Tool 0.96}
Jetzt muss ich mir den US keyboard driver anpassen.
Kannst Du mir da bitte einen Tip geben?
Danke
Gruß Michael
<ESC>c und andere Steuersequenzen funktionierten bei mir. Aber Großbuchstaben wurden zwar richtig übertragen, aber falsch angezeigt. Abhilfe bringt folgender Patch am Ende der main-Schleife:
1 | - key_send(ch) |
2 | + key_send(ch & $ff) |
Ob das der Weisheit letzter Schluß ist, weiß ich noch nicht.
Hallo Joe, im Moment habe ich gewaltige Probleme obwohl ich mit der Version 1.7.4 und dem keyb-de.spin Tastaturtreiber und deutscher Tastatur arbeite. Vom TeraTerm aus in Richtung VT100 funktioniert alles bestens. äüöß, [, ], ESC-Seqenzen CTRL-Sequenzen alles funktioniert. In Gegenrichtung VT100 zum TerraTerm funktioniert a-z, A-Z, 0-9, ESC c, ESC D, ESC E, CTRL-Sequenzen. Ich kann keine Zeichen die über <alt gr> zu ereichen sind am TerraTerm darstellen. <ß> wird als gefülltes Rechteck oben dargestellt(TerraTerm Fehler) Mit Version 1.7.5 neu und dem keyb-de.spin Tastaturtreiber und deutscher Tastatur stellt sich das so da: Normalmodus local echo off: Von TeraTerm aus in Richtung VT100 funktioniert alles bestens. äüöß, [, ], ESC-Seqenzen CTRL-Sequenzen alles funktioniert. In Gegenrichtung VT100 zum TerraTerm funktioniert a-z, A-Z, 0-9, ESC c, ESC D, ESC E, CTRL-Sequenzen(<CTRL> H...). Ich kann keine Zeichen die über <alt gr> zu ereichen sind am TerraTerm darstellen([]...). <ß> wird als gefülltes Rechteck oben dargestellt(TerraTerm Fehler) Im echo on Modus: Vom TeraTerm aus in Richtung VT100 keine Zeichenübergabe. Bei VT100 zu VT100 funktioniert a-z, A-Z, 0-9, ESC c, ESC D, ESC E, CTRL-Sequenzen(<CTRL> H...). Ich kann keine Zeichen die über <alt gr> zu ereichen sind am VT100 darstellen([]...). <ß> wird als <ß> dargestellt. Ist mein VT100 fehlerhaft? Vielen Dank für Deine Hilfe Gruß Michael
Michael S. schrieb: > Ist mein VT100 fehlerhaft? Eher nicht. Du wirst Dich wahrscheinlich mit den verschiedenen Zeichensätzen (character encoding, character sets, ...) beschäftigen müssen. Einfach mal hier im Thread (Seite 1) nach "Zeichensatz suchen". Und/oder das Handbuch [1] lesen. In der Datei "control-codes.md" findet man die Umschaltcodes. [1] https://vt100.net/docs/vt220-rm/chapter2.html
Nochmal genauer gelesen... > Normalmodus local echo off: > Ich kann keine Zeichen die über <alt gr> zu ereichen sind am TerraTerm > darstellen([]...). Bei mir sendet das VT100 die richtigen Zeichen. Kann das TerraTerm die empfangenen Zeichen als Hexcode darstellen? > Im echo on Modus: > Vom TeraTerm aus in Richtung VT100 keine Zeichenübergabe. Ich würde sagen, Joe hat genau das geliefert, was bestellt wurde. :-) > Bei VT100 zu VT100 funktioniert a-z, A-Z, 0-9, ESC c, ESC D, ESC E, > CTRL-Sequenzen(<CTRL> H...). > Ich kann keine Zeichen die über <alt gr> zu ereichen sind am VT100 > darstellen([]...). <ß> wird als <ß> dargestellt. Funktioniert hier auch wie erwartet. Um zu testen, welche Codes deine Tastatur liefert, könntest Du in "VT100_VGA_color.spin" die repeat-Schleife am Anfang der main-Prozedur entkommentieren. Die normale Funktion des Terminals wird dann nicht mehr ausgeführt, sondern nur noch die Tastencodes direkt auf dem Bildschirm angezeigt. Die Klammern sollten diese Codes liefern:
1 | 45B : [ |
2 | 45D : ] |
3 | 47B : {
|
4 | 47D : } |
Michael S. schrieb: > Im echo on Modus: > Vom TeraTerm aus in Richtung VT100 keine Zeichenübergabe. Der Fehler ist nun behoben. Das einführen des Echos gestern war ein Schnellschuss. Michael S. schrieb: > Ich kann keine Zeichen die über <alt gr> zu ereichen sind am VT100 > darstellen([]...). <ß> wird als <ß> dargestellt. Die <alt gr> Taste wird im VT100 nicht abgefragt. Welche Key-Codes möglich sind, steht am Ende des Programmes keyb-DE.spin. Derzeit sind nur die folgenden Kombinationen möglich. +100 if Shift +200 if Ctrl +400 if Alt +800 if Win
Hallo Leo, mit dem Umschalten der select character habe ich noch nichts brauchbares heraus bekommen. Irgendwie blick ich da noch nicht richtig durch. Kannst Du mir ausnahmsweise die richtige Umschalt-Sequenz nennen? Gibt es auch eine Möglichkeit vom deutschen keyboard ins englische umzuschalten(qwertz zu qwerty)? Was ich im Standard Zeichensatz gefunden habe: <alt> O = [ <alt> ö = ] <alt> ü = \ damit lassen sich auch mit local echo on die escape sequenzen ausführen. Vielen Dank Gruß Michael
Hallo Joe Du schriebst: Die <alt gr> Taste wird im VT100 nicht abgefragt. Welche Key-Codes möglich sind, steht am Ende des Programmes keyb-DE.spin. Derzeit sind nur die folgenden Kombinationen möglich. +100 if Shift +200 if Ctrl +400 if Alt +800 if Win Wenn ich noch rausbekomme, wie ich eine US-Tastatur trotz deutschen keyboard driver vernünftig bedienen kann(qwerty), brauch ich auch keine <altgr> Taste :-) Werde nochmals mit dem originalen keyboard.spin experimentieren. Vielen Dank an alle Gruß Michael
Michael S. schrieb: > Wenn ich noch rausbekomme, wie ich eine US-Tastatur trotz deutschen > keyboard driver vernünftig bedienen kann(qwerty), brauch ich auch keine > <altgr> Taste :-) Versuche es mal mit diesem Treiber, er ist das Äquivalent zum deutschen Treiber. Ich habe gerade mal alle Zeichen getestet und keinen Fehler festgestellt. Im Hauptprogramm einfach OBJ text : "VGA_640" 'Full Color VGA-640x480 Driver key : "keyb-EN" 'new Keyboard Driver ser : "FullDuplexSerial" 'Full Duplex Serial Controller config : "eeprom" einstellen.
:
Bearbeitet durch User
Hallo Joe, vielen Dank für den keyb-en.spin. Die normalen Zeichen stellt er alle richtig dar, Control H funktioniert auch. ESC wird bei mir nicht abgefangen, sondern als grafisches Zeichen dargestellt. Somit sind ESC-Sequenzen bei mir leider nicht ausführbar. Gruß Michael
Michael S. schrieb: > ESC wird bei mir nicht abgefangen, sondern als grafisches Zeichen > dargestellt. Der deutsche Treiber liefert bei ESC "1B" und der englische "CB". An der Stelle muss man eingreifen. Ich muss leider gleich weg, so dass ich jetzt nicht dazu komme.
Hallo Joe, danke für die Info!. Komme heute abend auch nicht mehr dazu. Werde mir morgen aber den Quellcode anschauen. V.G. Michael
Hallo zusammen, habe mir doch noch schnell den keyb-en.spin angeschaut. Folgende Zeile habe ich geändert: word $00CB '76 Esc in word $001B '76 Esc Erste Tests ergaben, das ESC-Sequenzen funktionieren V.G. MIchael
Michael S. schrieb: > Folgende Zeile habe ich geändert: Korrekt, an dieser Stelle wird den Scancode der Tastatur der ASCII-Code zugewiesen.
Hallo Joe, bringst Du ein neues Release 1.7.5 mit keyb-en.spin raus, oder gibt es noch was bzgl. 1.7.5 zum testen? Gruß Michael
Michael S. schrieb: > bringst Du ein neues Release 1.7.5 mit keyb-en.spin raus, oder gibt es > noch was bzgl. 1.7.5 zum testen? Ich habe die Version 1.7.5 im SVN hochgeladen (eigens Verzeichnis, nicht mehr in work). Der englische Treiber heißt keyb-US.spin, da ja tatsächlich der amerikanische Tastaturbelegung und nicht die UK-Tastaturbelegung genutzt wird. Ich habe selber auch nur eine US-Tastatur zum testen. Vielleicht findet sich ja noch jemand, der mit einer UK-Tastatur testet.
:
Bearbeitet durch User
Hallo Joe, danke für's "Releasen" der V.1.7.5 . Ich habe mal alle meine <qwerty> Tastaturen angeschaut, sind leider alle Pseudo US Tastaturen. Pseudo deswegen, weil sie die über 2 Tastaturzeilen verteilte <RETURN> Taste besitzen. Daher haben diese in der ASD Zeile am rechten Ende noch eine zusätzliche Taste wie die UK-Tastatur (|\ Taste) die bei der originalen US Tastatur in der QWERTY Zeile zusätzlich ganz rechts sich befindet. Daher kann ich die UK-Tastatur leider nicht testen. Gruß Michael
Hat jemand eine Quelle um ordentliche Frontplatten für das Gehäuse anfertigen zu lassen?
Hast du es mal mit dem Frontplatten-Designer von Schaeffer versucht? https://www.schaeffer-ag.de/frontplatten_designer/die_idee/
Joe G. schrieb: > Hast du es mal mit dem Frontplatten-Designer von Schaeffer versucht? > https://www.schaeffer-ag.de/frontplatten_designer/die_idee/ :) ich war zu faul zum austüfteln und dachte ich kann hier das Schaeferfile abgreifen :)
Hallo zusammen, ich habe die Bauteile bestellt damit ich die Platine endlich löten kann. Die sind dann endlich heute angekommen. Leider habe ich vergessen den MAX3241 mitzubestellen. ;-( Leider habe ich ihn nur bei den typischen großen Distributoren gefunden. Und der Preis ist auch nicht ohne. Hat jemand noch einen Typ wo ich ihn herbekomme oder weiss jemand einen kompatiblen Baustein? Danke schon mal Grüße Maik
Ja, da habe ich auch schon geschaut. Der will allerdings 20€ dafür und sitzt in England. Da sind die Distributoren günstiger... Wahrscheinlich werde ich wohl in den sauren Apfel beissen müssen und ihn dort bestellen.
Also mir listet ebay einen ein GB für 9,38€ inkl. Versand... Auch kein Schnapper, aber immerhin.
Maik D. schrieb: > Hat jemand noch einen Typ wo ich ihn herbekomme oder weiss jemand einen > kompatiblen Baustein? Ich würde in 3 Wochen (derzeit Urlaub) bei Mouser bestellen. Wenn du noch solange warten möchtest...
Joe G. schrieb: > Maik D. schrieb: >> Hat jemand noch einen Typ wo ich ihn herbekomme oder weiss jemand einen >> kompatiblen Baustein? > > Ich würde in 3 Wochen (derzeit Urlaub) bei Mouser bestellen. Wenn du > noch solange warten möchtest... Danke für dein Angebot. Zwischenzeitlich habe ich bei https://www.develektro.com bestellt. Der Shop ist wohl ein Partner von Farrell/element14. Den kannte ich noch nicht. Mal sehen wann die ankommen.
Joe G. schrieb: > Ich würde in 3 Wochen (derzeit Urlaub) bei Mouser bestellen. Wenn du > noch solange warten möchtest... MAX3241 Hallo Joe vielen Dank für das Angebot. Sind das dann der Typ SSOP und was würde einer dann mit Versand an Dich und dann nochmal an mich kosten? Viele Grüße Michael
Michael S. schrieb: > Sind das dann der Typ SSOP und was würde einer dann mit Versand an Dich > und dann nochmal an mich kosten? Ich würde genau den passenden Typ für das Layout bestellen. Ob es SSOP ist kann ich gerade nicht sagen (bin im Urlaub). Da ich eine größere Bestellung zu erledigen habe, würde die Versandkosten zu mir entfallen. Für dich sind es dann die Kosten für einen einfachen Kompaktbrief (0,85€).
Hallo Joe ich bin ab 06.08 selber für 3 Wochen im Urlaub. Falls der Preis >= 10€ ist, wäre es nett mir zwei MAX3241 mit zu bestellen. Wichtig wäre nur, dass es Typ SSOP oder TSOP ist. Danke Dir und schönen Urlaub noch. Gruß Michael
Ich verzweifel gerade... Ich wollte die V1.7.5 aufspielen und dabei gleich den Vorgang für die Dokumentation festhalten - aber weder Linux noch Windows finden den Port! Linux dmesg gibt mir aus: [404844.505175] usb 1-1: new full-speed USB device number 23 using xhci_hcd [404844.639095] usb 1-1: New USB device found, idVendor=0403, idProduct=6001 [404844.639106] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [404844.639110] usb 1-1: Product: USB-UART4 [404844.639114] usb 1-1: Manufacturer: TOPTEST [404844.639118] usb 1-1: SerialNumber: RTZ87DIH [404844.641441] ftdi_sio 1-1:1.0: FTDI USB Serial Device converter detected [404844.641584] usb 1-1: Detected FT232RL [404844.641897] usb 1-1: FTDI USB Serial Device converter now attached to ttyUSB0 [404845.890656] usb 1-1: USB disconnect, device number 23 [404845.891124] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [404845.891201] ftdi_sio 1-1:1.0: device disconnected Er wird sofort wieder getrennt. Wenn ich schnell bin sehe ich für 2-3 Sekunden, dass ein ttyUSB0 angelegt wird. LSUSB zeugt keinen FTDI an... Unter Windows "zuckt" der Gerätemanager - aber es kommt nix - auch kein unbekanntes Gerät.
Noch eine Ergänzung: Mit einer Knoppix-CD von 2014 ist das gleiche Verhalten.. Die LEDs (grün/rot) blinken beim Start. Ich habe das Teil aber doch mal genutzt! Ich hatte damals aber schon den Effekt, dass die Anschlüsse C0..C3 nicht richtig werksseitig gesetzt waren, das konnte ich mit FTProg richten. Da sich das Teil auch mit der richtigen Vendor/Product ID meldet, dann aber so komische Strings für Hersteller etc. ausgibt - ist das doch ein FakeChip, der stillgelegt worden ist? Oder ist der einfach nur hinne? EDIT: Nach einem Linux Neustart wird erst einmal gar nichts erkannt. Wenn ich dann den USB-Anschluss neu einstecke: 206.182966] usb 3-2: new full-speed USB device number 2 using xhci_hcd [ 206.569862] usb 3-2: New USB device found, idVendor=0403, idProduct=6001 [ 206.569872] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 206.569876] usb 3-2: Product: USB-UART4 [ 206.569880] usb 3-2: Manufacturer: TOPTEST [ 206.569884] usb 3-2: SerialNumber: RTZ87DIH [ 207.527650] usb 3-2: USB disconnect, device number 2 [ 207.659157] usbcore: registered new interface driver usbserial [ 207.659222] usbcore: registered new interface driver usbserial_generic [ 207.659279] usbserial: USB Serial support registered for generic [ 207.662843] usbcore: registered new interface driver ftdi_sio [ 207.662913] usbserial: USB Serial support registered for FTDI USB Serial Device LSUSB gibt aber nicht aus Dann wieder ab und dran und die Meldungen von oben kommen. Besten Gruß Marcel
:
Bearbeitet durch User
Hallo Aufregung umsonst - ich habe wieder Zugriff. Man muss bei der Version 1.1 den Jumper JP1 entfernen, sonst resetet sich der FTDI selber .... Trotzdem würde ich gerne noch die V1.2 aufbauen. Wo bekommt man den "günstig" den Propeller und den MAX her? Platinen würde ich dann in China machen lassen...
Marcel A. schrieb: > Wo bekommt man den "günstig" den Propeller und den MAX her? Den Propeller bekommst du hier [1]. Mouser ist günstiger (hat übrigens auch den MAX) aber du mußt erst mal über den Mindestbestellwert. [1] https://www.watterott.com/en/Propeller-P8X32A-Q44
Hallo Joe, tolles Projekt! Der letzten Meldung entnehme ich, dass es eventuell noch Bauteilsätze gibt. Wenn möglich hätte ich auch gerne eine Platine und möglichst viele der benötigten Bauteile. Damit könnte ich meine Retro-Aktivitäten ohne Gigahertz-PC betreiben :-) Gruß Siegfried