Epson HX-20 mit externem Monitor

cool -...ich wusste gar nicht, dass man den überhaupt an einen Monitor anschliessen kann

Ich hatte vor Jahren mal Emailkontakt mit dem Entwickler. Bauen will er solche Teile nicht mehr. Irgendwo habe ich Scans von seinen Schaltungsskizzen.

Alternativ gibt es von Martin Hepperle einen Monitor Simulator, der auch schon mal hier besprochen wurde: Epson HX-20 - Display Controller Emulator

Der läuft mit Java unter Windows, Linux, Mac und simuliert einen externen Monitor. Außerdem kann man damit Dateien vom PC direkt an den HX-20 übertragen. Ich hab es selber ausprobiert und es funktioniert echt prima.

Hey,

I wanted to make a composite terminal display for the HX-20 that implements the peripheral protocol, but unfortunately there is something wrong with the port of my HX.

The service manual barely covers the relevant schematic, my guess is that the RS232 level converter is failing. If I'll have some free time I would like to revisit this project. Would anyone be interested?

Zitat von Toast_r

Der Monitor wird ja auch nicht an den HX-20 angeschlossen.

Eigentlich ist das Gerät 'ein halbes Terminal', also eines nur mit Anzeige, aber ohne Eingabe.

Der HX-20 schickt die Konsolenanzeige auf dem seriellen Port raus, die Eingabe läuft über die interne Tastatur.

Guten Morgen

2 Screens für die Mitleser,

Tach auch,

da ich gerade selbst Probleme mit meinem HX20 habe, das Internet zzT nach Lösungen abgrase und hier gelandet bin, wollte ich erwähnen, das ich vor einiger Zeit eine externe Composite-Ausgabe mit faktisch 50*25 auf S/W inkl Grafikfunktionen auf Assembler mit einem 1284P zfür den HX20 zusammengeklöppelt habe, Das Kommunikationsprotokoll hat es ziemlich in sich.

Das ging auch ganz gut, es sei aber erwähnt, das die Ausgabe nicht gerade die schnellste ist; hat weniger etwas mit dem Aufbau ansich zu tun, sondern weil ziemlich viel Kommunikation gehändelt werden muss. Dabei wird nicht einfach nur ein Bildspeicherinhalt vom HX an den Bildschirmprozessor geschoben; jener macht quasi über Char-Generieren, Grafik usw alles selbst.

Fall mein HX20 wieder läuft - dummerweise ist es genau die Screen-Funktion, die nicht mehr arbeitet, er resettet sich sofort nach Eingabe von "Screen 1" - ROM oder Hardwarefehler, initialisieren bringt nichts - will ich über kurz oder längerfristig mal versuchen, einen externen Videochip in die Sache zu involvieren, um auch Farbe zu ermöglichen.

Aber: Es ist zwar nützlich, den Screenoutput auf dem externen Schirm zu haben, aber so richtig Laune macht das nicht; ich glaube, auch nicht mit einer verbesserten Variante.

Problem #2 ist halt auch: Was macht man damit. Das Basic selbst ist bekannterweise viel zu langsam, um irgendwas brauchbares damit anstellen zu können. Hier müsste man stärker in Assemblerprogramme Zeit investieren; daran mangelts dem HX ja grundsätzlich.

Edit: So sah das damals aus. Sorry für das Chaos. Da waren gerade mehrere Sachen am "laufen" und wenn ich mal auf "Basteldrehzahl" bin, ist die Ordnung bei gleich null. Aber damit bin ich anscheinend nicht alleine

https://imgur.com/a/Dc3xLgc

Kannst du deine Lösung mal genauer vorstellen?

Gruss Jörg

Gerne . Der 1284P kommuniziert auf UART2 mit dem HX20 über dessen Serial-Port; der 1284P selbst schiebt seine Grafikdaten über UART1 im SPI-Modus und einem Sync-Ausgang auf Composite. Der Bildpuffer für das 50*25-Char-Raster liegt im AVR-RAM - das mit knappen 16K halt leider etwas beschränkt ist, aber der 1284 hat kein externes Speicherinterface im klassischen Sinne; d.h. der Zeitaufwand, um externes RAM per in/out zu kontrollieren, wäre zu hoch. Der Charactersatz liegt neben dem Programm im Flash - vorläufig mal vom C64 "geklaut".

Daneben gibts halt noch einen UART2-Buffer, dann Routinen, die das EPSP (ESPS?)-Protokoll abhandeln und entsprechende Unterroutinen für die Erzeugung der Chars, Cursorpositionierung, Grafikfunktionen usw. Den Cursor, falls aktiviert, generiert der AVR selbst.

Es wird halt zur Bildausgabe relativ viel Zeit verbraucht. Es bleibt schon etwas "über", aber nicht allzu viel. Farbe ist damit leider nicht möglich. Es gibt zwar Lösungsansätze für den AVR mit einem externen RGB zu Compositewandler, würde aber auch lieber (aus Rechenzeitgründen) den Weg über den 6847 gehen. Vielleicht auch, um mit der gewonnenen Zeit noch zusätzlich den AVR mit einem SD-Interface auszustatten. Glaube allerdings, im Falle des HX lohnen sich solche Speichergrößen vs der effektiven Softwareverfügbarkeit und dem Aufwand der Implementation ggü Einspeisen per Com-Port oder Tape-Port mit Ziel der internen Kassette nicht wirklich.

Gruß

Stef

Hey stef,

I have run into the same issue with my HX-20, the fast serial port just gave up on me at some point, but my plan was to use an ESP32 as video output so that there is enough room for double buffering, and a dedicated core to handle the serial traffic and the SD card.

Answer to Problem#2 - Was macht man damit --> I would like to make the external display a permanent part of the HX-20 installation in the Museum so visitors can understand the real implications of what that machine meant in 1982 on the market. ( Sitting next to a 1981 Osborne ).

Also my problem could be solved with some original hardware that seems to be impossible to find.

cheers,

m.

Hi @nilseuropa,

yes, transferring the entire Construction to another platform is something i was also thinking about. The problem is, that my entire solution is based on Assembly language - I have a long term knowledge in programming 8 Bit MCUs like AVRs and X51, but also Assembly Programming on Cortex MCUs (to a certain grade) and i am quite unfamiliar with high level languages on MCUs (on regular PC Platforms i could handle at least Ruby) .

The ESP32 would be sure a good choice, but thats something i cannot work on, because the ESP cannot be programmed in Assembly language (due the fact that it is more or less "closed source").

My initial choice for another platform was an ATSAM4S Cortex M4; it could (in theory) provide enough speed and sufficient amount of RAM (depending on the model), but there i wanted to use a minimum amount of components to keep the construction also as simple as possible - and thats something quite tricky, because its integrated DAC, which i had chosen for Video output, has a rather slow conversion rate - and cannot provide voltages below 0.5 Volts. So at least an external DAC would be needed.

I keep my eyes open for a ARM-based MCU with better specifications and at best 5 Volt input tolerance. As soon as i get the serial port working again, i´ll see what i can do, but i am not very confident that i can find a fast solution for my problem - although i am quite familiar with analyzing and repairing old computers. Not always successfull, but at least i try my best.

Kind regards
Stef

Found the port issue. stef do you have the protocol documentation?

Got it.

Sorry that i didn't answer in time, i didn't check this forum for the past day or two.

I hope you find the protocol information useful, i got it from the Technical reference manual. I will proably release the .hex-File - as soon as i get certain problems fixed. Picture output isn't very stable as well - it depends on the instruction that has been executed before the AVR jumps into the ISR. This can be fixed in a small range, but not complete.

Keep in mind that not much can be achived in terms of performance. There is a lot much communication between the HX and Display Unit going on - at only 38.4 Kbits. That sounds a "lot", but a fairly big amount of this bandwidth is used for addressing the slave, transmitting the command, transmit the command contents - and reply to the host. If Performance would be needed, maybe in order to be able to program complex games including sprites/shapes, i would rather go for a Video Chip like the 6847, which is directly attached to the Expansion slot.

But i am currently not sure if writing to a Address above $7FFF, where the ROMs reside, is blocked by the hardware in any way. I guess not, but i didnt check that so far.

Here is another Video that tries to show the amount of communication between the HX and the "Display Unit". The rather big amount of data shown in the terminal window is another "list" command after the first one. The AVR itself could paint the lines way faster (the X-Axis is currently limited to 0-255, 400 is possible), but he is blocked by the serial communication.

https://imgur.com/a/fYPpjgH

If you need any help, don't hesitate to contact me!

Kind regards
Stef

The reason why Text output is also rather slow is given through the fact, that the HX doesn't transmit an entire line to be displayed in a single command packet; each Character is transmitted by a separate command.

Also keep in mind that you have to send back the contents of the current display line location, if the HX is asking for that. He does -not- keep track of the keys or commands being typed in.

Hey,

to be true, the EPSP documentation is rather hard to read, but not impossible

I've started to throw together the protocol implementation in C++, it is a bit hacky at the moment. I'll clean the code once I've got it working properly. The handshake and CRT negotiations are already working. But looking at your video You have already done all this

You are saying, that you wrote all that in AVR assembly?

Video chip on the expansion BUS sounds awesome. I do have an empty ROM box, so it could fit right there perfectly.

Actually it would save me a lot of time to just replicate your AVR solution as I don't want to develop high speed graphic games on the HX-20 -- I am doing this just to show Museum visitors, that the HX-20 was more than a manager calculator ( what their usual reaction is when they see it ).

So yes, I would like to try it if you could send me wiring diagram and the hex.

Although I tend to finish what I start I plan to use the `libepsp` I am writing in an ESP32 so one core could just deal with communication while the other could deal with the frame buffer and composite signal generation.

cheers,

m.

Very great

Tbh, a more recent Version than mine would be better, because the only thing that the AVR can do is Composite output, which would need an converter or an proper Display -and- i am not quite sure if my Implementation works on all Displays with Composite input; it meets "somehow" the specification, but who knows. If the ESP could generate VGA output and that in Color, even better. That would be only possible on the AVR with additional attached hardware.

So i would say - keep on ! If you are able to manage the protocol - and that seems to be clearly the case, 80% of the work is already done. I would be glad if i could help you in any way with programming, but C++ is, as i said, unfortunaly not "my language".

Kind regards
Stef