Beiträge von stef

  • Epson HX-20 mit externem Monitor

    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

  • Epson HX-20 mit externem Monitor

    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.

  • Epson HX-20 mit externem Monitor

    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

  • HX20 leicht kaputt

    Arbeitet wieder. Ursache und Wirkung nach auslöten und Sockeln potentiell betroffener ICs, wie auch händisches Abgleichen mit den Monitor-Dump ggü den ROM-Dumps mehr oder minder unbekannt. Das einzige, was noch gemacht wurde, war das neuverdrahten der Batterie zum Board, weil sich am Steckverbinder ein Wackler eingestellt hatte, aber wäre es ein Lastproblem mit einhergehendem wegbrechen der Spannung gewesen, hätten sowohl die Nutzung vom Tape als auch Drucker eigentlich viel eher zu einem Ausfall führen müssen und eigentlich würde ich meinen, das das Beanspruchen des seriellen Ports, gar ohne angeschlossene Geräte, weitaus weniger Last beansprucht.

    So, wie der Fehler kam und auch wieder ging, kann ich das nur als Zufall werten. Die Ursache hätte mich schon interessiert, kann sie mir aber nicht zusammenreimen. Wichtiger ist, das die Kiste wieder arbeitet.

    Gruß Stef

  • Epson HX-20 mit externem Monitor

    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

  • HX20 leicht kaputt

    Moin,


    um den vorangegangenen Thread mit meinem Problemchen nicht weiter zu belasten, fange ich mal einen neuen an :)


    Also. Gestern habe ich noch fröhlich mit meinem selbstgebastelten TV-Adapter, den ich über "Serial" angeschlossen habe, experimentiert: Angemerkt: Nicht das erste mal.

    Dem Controller am UART und HX20-Serial vorgeschaltet war ein HC14, um die seriellen Signale zu invertieren. Die Lösung entspricht zwar "nicht ganz" den erwarteten Pegeln, hat aber soweit funktioniert.


    Nun, heute stellt sich das Problem so dar, das bei einem Aufruf von "Screen 1" oder dem öffnen des Com-Port die Kiste sich immediat resettet, sieht sogar nach einem kurzen wegcutten der Spannung aus.

    Nun könnte man annehmen - IC 6/RS232 (75188) oder IC7(4050) hat durch die serielle Aktion einen Hau wegbekommen - Fehlanzeige. Selbst wenn IC6 vollständig fehlt, passiert das gleiche. Der letzte Im Strang könnte noch der 4016 an der Main-CPU sein, aber hier sehe ich keinen Anlass, warum das zum Reset führen könnte.

    Initialisieren, Batterie weg, warten und Co hilft nichts. Der Vollständigkeit halber: Tape und Drucker funktionieren; d.h. "Ampere" sind ausreichend vorhanden.

    So fällt der Verdacht eher dorthin, das etwas mit der ROM-Addressierung nicht stimmen könnte, wobei ich eher vermuten würde, das dies in einem Trap enden würde. Es ist ein seltsamer Zufall, das ausgerechnet jetzt diesbezüglich rumgesponnen wird; daher dachte ich ja auch eher an einen Hardwaredefekt, aber eigentlich ist er ausgeklammert. Die Kommunikation zwischen Main und Slave-CPU klappt ja über High Speed Serial.

    Daher meine Frage - gibt es irgendwo eine vollständiges Firmware bzw Basic-Listing oder weiß jemand von einen Addressbereich, in dem die RS232-Routinen abgelegt sind, so das ich zumindest in den ersten paar Bytes schauen kann, ob der Inhalt ansich in Ordnung ist und der entsprechende Stein auch angefahren wird? Das Binary zum Gegenvergleich habe ich.

    Besten Dank & viele Grüsse
    Stef

  • Epson HX-20 mit externem Monitor

    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

  • Epson HX-20 mit externem Monitor

    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