Hallo, Ich möchte mir zur selbstbildung einen 8 bit Computer basteln. Folgende Komponenten habe ich mir schon ausgedacht. Atmega 1284p mit einem stark modifiziertem Tinybasic als main core Atmega 328p für Ps2 Tastatur, SD, und i2c zusatzkomponenten wie rtc etc. Die beiden sollen dann per rx/TX oder i2c Daten austauschen. An den 1284p sollen dann auch wechselbare eeproms mit 512kb ran. Ich möchte die Ausgabe über VGA realisieren. Allerdings durch die wenigen mhz und der begrenzte Speicher schaffe ich keine tollen Auflösungen. Gibt es einen 8bit Chip im dip Gehäuse mit welchem ich VGA Auflösungen bis zu 800x600 schaffen könnte? Der Datenaustausch zum VGA Chip soll auch per rx/TX stattfinden. Es gibt da ein tolles teil- http://www.hobbytronics.co.uk/serial-vga allerdings zu teuer und nicht mehr im 8 bit Bereich. Ich möchte aber zwingend im 8 bit Bereich bleiben. Sonnst könnte ich für die VGA Ausgabe auch einen esp nutzen.
Was willst Du mit einem Controller, der weder viel Rechenleistung noch viel Speicher hat, mit relativ hoher Graphikauflösung anfangen?
640x480 wären auch in Ordnung. Möchte eigentlich erstmal nur Texte ausgeben.
:
Bearbeitet durch User
Viel Erfolg, Selbst habe ich die Z80 Hardware schon entsorgt. P.S. ich habe noch einen selbst gebauten Akustikkoppler (wer es nicht kennt: Telefonhörer) incl. 300Baud Modem im Keller. Na dass wäre mein ein Projekt für ein analoge Internetverbindung.
Du kannst immer 8 Pixel parallel in ein Schieberegister packen und dann raustakten, die eigentlichen Aufgaben macht der Controller dann ausserhalb des sichtbaren Bereiches.
:
Bearbeitet durch User
Das mit dem schiebe register habe ich auch schon gesehen. Werde es so eventuell auch erstmal umsetzen.
Sinnvoller wäre natürlich direkt ein FPGA Board (Spartan 3A/E) zu nehmen und es komplett zu Fuß machen. Das Gewürge aus nem AVR nen VGA Bild raus zu bekommen entfiele dann komplett und du hättest komplette Kontrolle über die Architektur.
Adrian L. schrieb: > Gibt es einen 8bit Chip im dip Gehäuse mit welchem ich VGA Auflösungen > bis zu 800x600 schaffen könnte? VGA-Auflösung ist 640x480. > Der Datenaustausch zum VGA Chip soll auch per rx/TX stattfinden. > Es gibt da ein tolles teil- http://www.hobbytronics.co.uk/serial-vga > allerdings zu teuer und nicht mehr im 8 bit Bereich. > > Ich möchte aber zwingend im 8 bit Bereich bleiben. Sonnst könnte ich für > die VGA Ausgabe auch einen esp nutzen. Kennst du das? https://www.linusakesson.net/scene/craft/ Da sind aber bei weitem keine 800x600 drin. Dafür ist alles auf einem AVR in Software implementiert. Ich finde das immer noch beeindruckend, was der da aus einem AVR rausholt, ganz ohne irgendwelche Zusatzchips.
:
Bearbeitet durch User
Adrian L. schrieb: > Möchte eigentlich erstmal nur Texte ausgeben. Na, das ist was anderes. Da Du eine Graphikauflösung angegeben hattest, schloss ich darauf, daß Du damit auch Graphikausgaben machen wolltest. Das Problem bei VGA ist die relativ hohe Pixeltaktfrequenz (etwas über 25 MHz), die auch im einfachen Textmodus verwendet wird. Die kann Dein AVR nicht ohne Nachhilfe zusätzlicher Hardware verarbeiten. Hier hat mal jemand entsprechende Hardware (mit einem übertakteten AVR) gebaut: Beitrag "AVR VGA Terminal" Rolf M. schrieb: > VGA-Auflösung ist 640x480. Im Textmodus nicht, da sind es 720x400 (80 Zeichen in 25 Zeilen, und jedes Zeichen besteht aus einer 9x16-Pixelmatrix). Der Pixeltakt (etwa 25 MHz) bleibt der gleiche, die Zeilenfrequenz bleibt auch die gleiche, aber die Bildwechselfrequenz steigt von 60 auf 70 Hz (was durch die Reduktion der Bildzeilen möglich ist).
Rufus Τ. F. schrieb: > Adrian L. schrieb: >> Möchte eigentlich erstmal nur Texte ausgeben. > > Na, das ist was anderes. Da Du eine Graphikauflösung angegeben > hattest, schloss ich darauf, daß Du damit auch Graphikausgaben machen > wolltest. Eigentlich nicht bzw. der "Textmodus" von 720x400 Pixeln ist noch schlechter geeignet, da bedingt durch die höhere Horizontal Auflösung der Pixeltakt auf 28,322 MHz steigt. Zum Nachrechnen: 900x449 Pixel Auflösung fürs komplette Bild, einschließlich nicht sichtbarer Bereiche bei einer Bildwiederholrate von 70,08 Hz. > Das Problem bei VGA ist die relativ hohe Pixeltaktfrequenz (etwas über > 25 MHz), die auch im einfachen Textmodus verwendet wird. Die kann Dein Wie oben geschrieben ist der Pixelclock im Textmodus sogar höher. > AVR nicht ohne Nachhilfe zusätzlicher Hardware verarbeiten. Das (graphik) VGA Bild besteht aus 800*525 Pixeln bei einer Bildwiederholrate von 59,94 Hz, macht also einen Pixeltakt von 25,175 MHz. Diese Übertaktung schafft ein AVR in der Regel problemlos. Alternativ kann man den Pixeltakt halbieren und gibt so effektiv eine auf 320 Pixel reduzierte Hozizontalauflösung aus, hat aber den Vorteil das gängige Monitore das Signal als VGA ausgeben können. Als Hardware benötigt man in jedem Fall nur das bereits genannte Schieberegister. > Hier hat mal jemand entsprechende Hardware (mit einem übertakteten AVR) > gebaut: > > Beitrag "AVR VGA Terminal" > > > Rolf M. schrieb: >> VGA-Auflösung ist 640x480. > > Im Textmodus nicht, da sind es 720x400 (80 Zeichen in 25 Zeilen, und > jedes Zeichen besteht aus einer 9x16-Pixelmatrix). > > Der Pixeltakt (etwa 25 MHz) bleibt der gleiche, die Zeilenfrequenz > bleibt auch die gleiche, aber Nein und ja, der Pixeltakt steigt, die Zeilenfrequenz bleibt gleich. die Bildwechselfrequenz steigt von 60 auf > 70 Hz (was durch die Reduktion der Bildzeilen möglich ist). Wobei durch den erhöhten Pixeltakt aber überhaupt nichts gewonnen wird.
:
Bearbeitet durch User
Adrian L. schrieb: > 640x480 wären auch in Ordnung. Möchte eigentlich erstmal nur Texte > ausgeben. Bitteschön: Beitrag "Re: CP/M auf ATmega88" oder doch mit Propeller: Beitrag "VT100-Terminal (VGA+PS2)"
:
Bearbeitet durch User
Sieh dir die Standard-VGA-Auflösungen und ihre Pixeltakt-Frequenzen an. Danach suchst du dir eine günstige Auflösung/Frequenz aus. So kann man bei einigen Auflösungen/Frequenzen Standard-Quarze verwenden und diese leicht runterteilen/halbieren sodass sie im Arbeitsbereich eines Mikrocontrollers liegen. Es bietet sich an eine gängige Auflösung zu wählen, falls es zukunftssicher sein soll.
Bla schrieb: > Sieh dir die Standard-VGA-Auflösungen und ihre Pixeltakt-Frequenzen an. > Danach suchst du dir eine günstige Auflösung/Frequenz aus. > > So kann man bei einigen Auflösungen/Frequenzen Standard-Quarze > verwenden und diese leicht runterteilen/halbieren sodass sie im > Arbeitsbereich eines Mikrocontrollers liegen. > > Es bietet sich an eine gängige Auflösung zu wählen, falls es > zukunftssicher sein soll. 640x480 hat schon den niedrigsten Pixeltakt. Wenn man mit halber Horizontalauflösung arbeiten will drängt sich geradezu SVGA mit 800x600 bei 60 Hz auf, nativ hat das einen Pixeltakt von 40 MHz, bei halber Horizontalauflösung sinds dann 20 MHz, was genau als maximal Clock für den AVR passt.
:
Bearbeitet durch User
Tim T. schrieb: > Nein und ja, der Pixeltakt steigt, die Zeilenfrequenz bleibt gleich. Hmpf. Natürlich. Muss man halt auf die 9x16-Matrix verzichten und eine 8x16-Matrix verwenden.
Adrian L. schrieb: > Gibt es einen 8bit Chip ... mit welchem ich VGA Auflösungen Hier hat es einer mit 8051 gemacht. Mit viel Gewürge und in Assembler. https://www.silabs.com/community/mcu/8-bit/forum.topic.html/random_latency_with-qfVn
Adrian L. schrieb: > Ich möchte aber zwingend im 8 bit Bereich bleiben. Sonnst könnte ich für > die VGA Ausgabe auch einen esp nutzen. Die make hatte da einen Artikel drüber: https://www.heise.de/select/make/2018/1/1519688503646911 Eigentlich müsste man eine Art Grafikkarte dazu stricken, weil 8 bit controllern die Hardware fehlt einen kontinuirlichen Bisstream im VGA Pixelclock zu liefern. http://martin.hinner.info/vga/timing.html
Wenn man ein Schieberegister zu Hilfe nimmt und den AVR übertaktet, dann bekommt man auch eine für vernünftige Textdarstellung nutzbare Auflösung hin. Ich verlinke das jetzt nochmal: Beitrag "AVR VGA Terminal"
> Gibt es einen 8bit Chip im dip Gehäuse mit welchem ich VGA Auflösungen > bis zu 800x600 schaffen könnte? Aus dem Bauch empfehle ich ein STM32F103-Board. Gibt es für unter 5 Euro (aus dem Reich der Mitte für die Hälfte) und hat recht ordentlich was unter der Haube.
Und ein STM32F103-Board ist ein "8-Bit-Chip" im Dip-Gehäuse?
C. A. Rotwang schrieb: > Adrian L. schrieb: >> Ich möchte aber zwingend im 8 bit Bereich bleiben. Sonnst könnte ich für >> die VGA Ausgabe auch einen esp nutzen. > > Die make hatte da einen Artikel drüber: > https://www.heise.de/select/make/2018/1/1519688503646911 Ja, aber 120x60 Pixel bei 4 Farben ist da nicht der Brüller. > > Eigentlich müsste man eine Art Grafikkarte dazu stricken, weil 8 bit > controllern die Hardware fehlt einen kontinuirlichen Bisstream im VGA > Pixelclock zu liefern. http://martin.hinner.info/vga/timing.html Das stimmt nicht, zum einen sind 8 Bitter wie die ATMegas durchaus in der Lage, mit geringer Übertaktung, einen kontinuierlichen Bitstream im VGA Pixelclock zu liefern und zum Anderen muss der Bitstream auch garnicht kontinuierlich sein, 20% der Zeit pro Zeile und ca. 26% der Zeit pro Bild hat der µC Zeit etwas Anderes zu machen. Nach dem sichtbaren Teil der Zeile könnte der µC z.B. schonmal die Register für die nächste Zeile setzen und nach dem sichtbaren Teil des Bildes, könnte er neue externe Daten ins RAM laden.
Rufus Τ. F. schrieb: > Wenn man ein Schieberegister zu Hilfe nimmt und den AVR übertaktet, dann > bekommt man auch eine für vernünftige Textdarstellung nutzbare Auflösung > hin. > > Ich verlinke das jetzt nochmal: > > Beitrag "AVR VGA Terminal" Wenn man SVGA 800x600 auf halber Horizontalauflösung fährt bekommt man mit dem Schieberegister Serialisierer ebenfalls eine vernünftige Auflösung (400x600) hin, sogar ohne den AVR zu übertakten.
Tim T. schrieb: > ebenfalls eine vernünftige Auflösung (400x600) Damit kann man keine 80 Zeichen in einer Zeile darstellen - jedenfalls nicht mit 8 Pixeln Zeichenbreite. Das wären - die Lücke zwischen benachbarten Zeichen eingerechnet - nur 5 Pixel Zeichenbreite, das mag für irgendwelche Demozwecke reichen, aber "brauchbar" ist so etwas nicht. 640 Pixel Horizontalauflösung sind daher das nötige Minimum.
Vielleicht ein wenig Literatur? Racing the Beam: The Atari Video Computer System (Platform Studies)
Hier noch ein Projekt mit dem STM32F103 (VGA 800 x 600): https://www.artekit.eu/vga-output-using-a-36-pin-stm32/
Rufus Τ. F. schrieb: > Damit kann man keine 80 Zeichen in einer Zeile darstellen - jedenfalls > nicht mit 8 Pixeln Zeichenbreite. Das ist sicher richtig. Aber welche Naturkonstante legt fest, dass man zwingend 80 Zeichen pro Zeile braucht? Tuen es nicht vielleicht auch 50? Ich kann mich erinnern, in den frühen 80ern den Atari800XL programmiert zu haben und dazu haben mir die da möglichen 40 Zeichen/Zeile auch gereicht. Scheint also eine derartige Naturkonstante nicht wirklich zu geben...
c-hater schrieb: > Rufus Τ. F. schrieb: > >> Damit kann man keine 80 Zeichen in einer Zeile darstellen - jedenfalls >> nicht mit 8 Pixeln Zeichenbreite. > Tuen es nicht vielleicht auch 50? Ich kann mich erinnern, in den frühen > 80ern den Atari800XL programmiert zu haben und dazu haben mir die da > möglichen 40 Zeichen/Zeile auch gereicht. Scheint also eine derartige > Naturkonstante nicht wirklich zu geben... Es gibt sowas, was der Naturkonstante ziemlich nahe ommt und das ist die Normseites des Verbandes deutscher schriftsteller und liegt die Anzahl der Zecihen pro zeile bei mindestens 60. Ansonsten sei an die Alten Zeiten erinnert, in denen (fast) jeder VGA Textmodus auf 80 Zeichen lief. Wuesst garnicht das Norton Commander oder Turbo-Pascal mit weniger laufen könnte.
Tim T. schrieb: > Das stimmt nicht, zum einen sind 8 Bitter wie die ATMegas durchaus in > der Lage, mit geringer Übertaktung, einen kontinuierlichen Bitstream im > VGA Pixelclock zu liefern Naja 320x200x60 (sichtbarer Bereich) sind 3.840.000 , also ein mit 12MHz getakterer AVR hatt 3 Takte ein Datum an die GPIO zu schaufeln und Pointer zu inkrementieren, wahrscheinlich sind aus diesem Grund bei dem Arduinobeispiel die Bilder sehr grobpixelig, also mehrere x-Pixel zwangsweise mit gleichen Wert. Und für die Arduino-lib steht geschrieben: "The library implement a 120x60px framebuffer where each pixel is stored as 2 bits (4 colors). The framebuffer is stored inside SRAM." https://forum.arduino.cc/index.php?topic=320238.0 Ja da wird schon was auf VGA rausgeschoben, das aber nur etwa ein Neuntel der ohnehin schon mickrigen VGA Auflösung bietet.
Dann hast du nicht Turbopascal unter CP/M auf einem Terminal programmiert. Wenn er ein Basic implementiert ist er da frei. Limitierend ist der VGA-Standard. Das VGA-Terminal mit dem AVR das oben verlinkt ist geht wenn man das Keybord an den richtigen IO ( siehe Korrekturen ) anschließt.
c-hater schrieb: > Ich kann mich erinnern, in den frühen 80ern den Atari800XL programmiert > zu haben und dazu haben mir die da möglichen 40 Zeichen/Zeile auch > gereicht. Ich habe sogar mal mit dem Filzstift Kästchen auf Lochkarten geschwärzt (das verstand der Lochkartenleser, man musste also keine Löcher verwenden), und einen Tischrechner damit programmiert. Aber bereits der IBM PC von 1981 konnte 80 Zeichen in der Zeile darstellen, wahlweise mit dem MDA oder der CGA-Karte. Und da es, wie dargelegt, offensichtlich möglich ist, eine nutzbare Textdarstellung mit einem AVR und wenig Zusatzbeschaltung hinzubekommen, warum sollte man freiwillig eine schlechtere verwenden? Um den armen AVR zu "schonen", weil man ihn nicht übertaktet?
Lothar schrieb: > Hier hat es einer mit 8051 gemacht. Mit viel Gewürge und in Assembler. Mit einem SiLabs 8051. Der rennt bis 72 MHz und die meisten Befehle brauchen nur 1-2 Taktzyklen. Das sollte man dazu sagen...
Also wenn ich an den C64 zurück denke hatte der auch nur 40x25 Zeichen also wayne. Gerade wenn man einfach nur zum Spaß einen Rechner baut, sehe ich so überhaupt keinen Grund auf 80 Zeichen pro Zeile fixiert zu sein. Ist ja nicht so als wollte der OP jetzt massenhaft bestehende Programme auf seine Maschine portieren... Und im Übrigen ging es weniger ums "Schonen" sondern vielmehr darum das ein 20 MHz Quarz doch eher verfügbar ist als ein 25,175 MHz.
:
Bearbeitet durch User
Adrian L. schrieb: > Ich möchte die Ausgabe über VGA realisieren. Allerdings durch die > wenigen mhz und der begrenzte Speicher schaffe ich keine tollen > Auflösungen. > > Gibt es einen 8bit Chip im dip Gehäuse mit welchem ich VGA Auflösungen > bis zu 800x600 schaffen könnte? Nein. Es gibt keine sinnvollen Möglichkeiten. Rein per Software geht BAS, also monochrom Video in Fernsehauflösung. VGA erfordert einiges an Zusatzhardware, und je nach Art und Menge der Zusatzhardware wird Dein AVR zu 80-100% nur mit dem Bildaufbau beschäftigt sein. Ich schlage ein Planänderung vor. Streiche VGA von Deiner List und ersetze es durch LCD. Dann gibt es nämlich einige TFT-Displays mit TFT-Controller-Board (Schlüsselwort SSD1963, das ist nämlich die Bezeichnung des Chips), die recht einfach mit AVRs anzusteuern sind. Diese Displays gibts bis 800*480, also WVGA, und damit wäre Dein Ziel erreicht. Um ein solches Display mit maximaler Geschwindigkeit ansteuern zu können, musst Du Deinen Plan ein weiteres Mal ändern. Ersetze den 1284 durch einen Mega2560 oder Mega2561. Ja, ich weiß, das ist jetzt kein DIL mehr, aber da musst Du jetzt durch. Der Grund für diese Planänderung ist, dass der Megsa 2560 ein externes Adress/Daten-Bus Interface hat, d.h. er kann in Hardware (! das ist wichtig) direkt externen Speicher ansteuern. Der TFT-Controllerchip wird genau wie externer Speicher angesprochen, und daher ist das wichtig. Ohne dieses EBI (External Bus Interface) müsstest Du das in Software durch GPIO-Ansteuerung machen, und das ist Faktor 5-10 langsamer. Willst Du also nicht. Bei dieser gelegenheit kannst Du gleich noch 32k oder mit Bankswitching 128k externes SRAM und ggf. paralleles Flash/EERPOM anschließen. Mit diesem Schwenk wird Dein Vorhaben problemlos möglich, ohne auf FPGAs etc auszuweichen. fchk
:
Bearbeitet durch User
Die Anzahl Zeichen je Zeile hängt von der gewünschten ausführbaren Anwendung ab. So braucht ein Assembler-Programm gewisse fixe Spalten für Opcodes, Mnemonics, Adressen usw.
Bla schrieb: > Die Anzahl Zeichen je Zeile hängt von der gewünschten ausführbaren > Anwendung ab. > > So braucht ein Assembler-Programm gewisse fixe Spalten für Opcodes, > Mnemonics, Adressen usw. Wirrer Unsinn.
Tim T. schrieb: > Wirrer Unsinn O.o Doch...das Problem ist krass bei 320x240 und 40 Spalten ...da wirds eng!
Bla schrieb: > So braucht ein Assembler-Programm gewisse fixe Spalten für Opcodes, > Mnemonics, Adressen usw. Schwachsinn. Aber Fortran 77 verwendete fixe Spalten:
1 | Col. 1 : Blank, or a "c" or "*" for comments |
2 | Col. 1-5 : Statement label (optional) |
3 | Col. 6 : Continuation of previous line (optional) |
4 | Col. 7-72 : Statements |
5 | Col. 73-80: Sequence number (optional, rarely used today) |
Aber trotzdem konnte mam in 40 Spalten locker den Fortran-Code unterbringem, wenn man den auf die Zeilennumerierung verzichtete. leo
Bla schrieb: > Tim T. schrieb: >> Wirrer Unsinn > > O.o > > Doch...das Problem ist krass bei 320x240 und 40 Spalten ...da wirds eng! Es ist aber eher nicht zu vermuten, dass der TO sich das Ding baut, um darauf Assembler-Code editieren zu können. Und 40 Zeichen scheinen mir im Übrigen gerade für Assembler-Code reichlich.
Rolf M. schrieb: >> Doch...das Problem ist krass bei 320x240 und 40 Spalten ...da wirds eng! > > Es ist aber eher nicht zu vermuten, dass der TO sich das Ding baut, Yep. Aber noch einmal: Assembler kennt keine Spalteneinteilung. leo
leo schrieb: > Assembler kennt keine Spalteneinteilung. Klarstellung: bei den mir bekannten Assemblersprachen kam das nie vor. leo
Tim T. schrieb: > Also wenn ich an den C64 zurück denke hatte der auch nur 40x25 Zeichen > also wayne. Der hatte aber auch einen extra displaycontroller (MOS Technology 6569) , ausserdem war der weniger zum programmieren/arbeiten als zum daddeln gedacht; 40x25 ist vielleicht die optimale auflösung für Tetris ;-) Und sobald der verbesserte Displaycontroller (MOS Technology 8563) auf dem Markt war, gabs softwarepatches für 80 zeichen: https://en.wikipedia.org/wiki/MOS_Technology_8563#/media/File:SpeedScript_128_in_action.png dagegen 40 Zeichen: https://upload.wikimedia.org/wikipedia/en/0/0b/Speedscript_3.2_for_Commodore_64.png Displaycontroller lassen sich auch 'diskret' aus 74* logik zusammensetzen, da braucht es nicht gleich ne asic-fertigung dazu (bspw Z1013 (Zeichensatzgrafik only) http://www.sax.de/~zander/z1013/z13_s.pdf). Ich finde es irgendwie schade, das heutzutage aus HW-Unkenntniss ein 25 MHz Controller verheizt wird, was ein 1 MHz Controller mit ein paar extra Gatter genauso zustande bringt.
Rufus Τ. F. schrieb: > Aber bereits der IBM PC von 1981 konnte 80 Zeichen in der Zeile > darstellen, wahlweise mit dem MDA oder der CGA-Karte. Mein Homecomputer konnte das auch. Aber das war nicht der Standard-Modus. Nach dem Einschalten war er immer in einem Modus mit 320x480 Pixeln bzw. 40x25 Textzeichen (eine Unterscheidung zwischen Text- und Grafikmodus gab es nicht). > Und da es, wie dargelegt, offensichtlich möglich ist, eine nutzbare > Textdarstellung mit einem AVR und wenig Zusatzbeschaltung hinzubekommen, > warum sollte man freiwillig eine schlechtere verwenden? Weil es ggf. programmiertechnisch einfacher ist, die geringer Auflösung darzustellen. Wenn man nicht mehr braucht, warum sich unnötig das Leben schwer machen? C. A. Rotwang schrieb: > Ich finde es irgendwie schade, das heutzutage aus HW-Unkenntniss ein 25 > MHz Controller verheizt wird, was ein 1 MHz Controller mit ein paar > extra Gatter genauso zustande bringt. Man kann's auch umgekehrt sehen und schön finden, dass ein billiger µC das in Software kann, wofür man früher ein TTL-Grab gebraucht hat. Was einem besser gefällt, kann auch davon abhängen, ob man das Programmieren oder das Löten als mühsamer betrachtet.
C. A. Rotwang schrieb: > Tim T. schrieb: >> Also wenn ich an den C64 zurück denke hatte der auch nur 40x25 Zeichen >> also wayne. > > Der hatte aber auch einen extra displaycontroller (MOS Technology 6569) > , ausserdem war der weniger zum programmieren/arbeiten als zum daddeln > gedacht; 40x25 ist vielleicht die optimale auflösung für Tetris ;-) > > Und sobald der verbesserte Displaycontroller (MOS Technology 8563) auf > dem Markt war, gabs softwarepatches für 80 zeichen: > https://en.wikipedia.org/wiki/MOS_Technology_8563#/media/File:SpeedScript_128_in_action.png > > dagegen 40 Zeichen: > https://upload.wikimedia.org/wikipedia/en/0/0b/Speedscript_3.2_for_Commodore_64.png > Daddeln oder nicht ist dabei doch nicht die Frage, der OP will halt einfach Text auf (S)VGA ausgeben, daß 40x25 Zeichen dabei nicht das Maß der Dinge sind steht wohl außer Frage, aber warum mehr Aufwand treiben? Für umfangreiche Anwendungen bräuchte man eh mehr Auflösung, außerdem nicht nur Text sondern auch Grafik, am besten in Farbe und weil die Monitore es eh haben, das Ganze noch über HDMI/DVI, wenn aber schon HDMI/DVI, dann direkt FullHD für die heimische Zweitglotze, merkst du was? Da kann man direkt nen Raspberry oder so von der Stange nehmen und muss garnix mehr machen... > Displaycontroller lassen sich auch 'diskret' aus 74* logik > zusammensetzen, da braucht es nicht gleich ne asic-fertigung dazu (bspw > Z1013 (Zeichensatzgrafik only) > http://www.sax.de/~zander/z1013/z13_s.pdf). > > Ich finde es irgendwie schade, das heutzutage aus HW-Unkenntniss ein 25 > MHz Controller verheizt wird, was ein 1 MHz Controller mit ein paar > extra Gatter genauso zustande bringt. Und ich finde es schade das wieder Äpfel mit Birnen verglichen werden, wenn du ein VGA Signal raushauen willst, kommst du einfach nicht um einen 25 MHz Pixeltakt rum, da irgendeinen BAS Kram zu vergleichen ist Mumpitz.
Offtopic: Bernd schrieb: > Hier noch ein Projekt mit dem STM32F103 (VGA 800 x 600): > > https://www.artekit.eu/vga-output-using-a-36-pin-stm32/ Danke für den Link. Darauf aufbauend gibt es auch etwas für echte 800x600 mit einem F4: https://hackaday.com/2015/01/04/800-x-600-vga-with-the-stm32f4/ (Das ist für uns hier eine interessante Lösung, um den alten 9"-CRT an der Sinumerik unseres Drehautomaten zu ersetzen.) Ontopic: Die Sinumerik 810T hier hat üblicherweise 41x17,5 Zeilen. Auch solche krummen Werte gibt es ;-) Welche exakte Auflösung die Grafikeinheit hat, habe ich noch nicht herausfinden können. Horizontal sollten es 41x16=656 Pixel sein (die Buchstaben bestehen wohl üblicherweise aus 16x16 Pixeln).
:
Bearbeitet durch Moderator
So vielen Dank für die guten Informationen, Ich werde nun erstmal ein 7" nextion Display testen, da das VGA doch ein Problem ist. Falls das nicht funktioniert werde ich ein stm32 als Gpu nutzen.
wenn die Grafikausgabe eine Hardware voraussetzt, die um ein vielfaches leistungsfähiger ist als der "Hauptrechner", dann wird das Gesamtsystem immer sehr unausgewogen sein. nimm gleich ein STM32 für alle Aufgaben statt einzelne ICs, dann bekommst du ein viel stimmigeres Gesamtsystem.
Dem Threadstarter geht es um Textdarstellung, allerdings mit einer gewissen Auflösung -- er hätte sonst nicht SVGA (800x600) bzw. VGA (640x480) als Auflösung gefordert: > 640x480 wären auch in Ordnung. Möchte eigentlich erstmal nur Texte > ausgeben. Insofern wäre ihm mit einer simplen Terminal-Lösung gedient.
Rufus Τ. F. schrieb: > Dem Threadstarter geht es um Textdarstellung, allerdings mit einer > gewissen Auflösung -- er hätte sonst nicht SVGA (800x600) bzw. VGA > (640x480) als Auflösung gefordert: Er fordert VGA weil sein Monitor unterhalb einer Zeilenfrequenz von 31,x kHz nicht funktioniert, alles darüber (SVGA) wäre natürlich schön aber es geht ihm einfach erstmal darum das es funktioniert. Da eine gewisse Mindestmenge Zeichen pro Zeile heraus abzuleiten ist schon ziemlich gewagt. > >> 640x480 wären auch in Ordnung. Möchte eigentlich erstmal nur Texte >> ausgeben. > > Insofern wäre ihm mit einer simplen Terminal-Lösung gedient. Die er dann wie an seinen Monitor bekommt?
captain obvious schrieb: > wenn die Grafikausgabe eine Hardware voraussetzt, die um ein vielfaches > leistungsfähiger ist als der "Hauptrechner", dann wird das Gesamtsystem > immer sehr unausgewogen sein. Warum? Selbst beim PC ist das nichts ungewöhnliches. Und es gibt ja z.B. auch WLAN-, GPS- oder GSM-Module für 8-Bitter, die meist selbst einen 32-Bit-µC mit viel mehr Rechenpower und Speicher haben als der Hauptprozessor.
Rufus Τ. F. schrieb: > Dem Threadstarter geht es um Textdarstellung, allerdings mit einer > gewissen Auflösung -- er hätte sonst nicht SVGA (800x600) bzw. VGA > (640x480) als Auflösung gefordert: > >> 640x480 wären auch in Ordnung. Möchte eigentlich erstmal nur Texte >> ausgeben. > > Insofern wäre ihm mit einer simplen Terminal-Lösung gedient. <KrümmelKackermodus ein> Textmodus und eine Angabe Displayauflösung in Hpixel X Vpixel statt rowsXcols sind aber zwei Paar Schuhe. Insofern glaube ich nicht, das der TO wirklich seine Anforderungen detailiert spezifiziert hat und "im Hinterkopf" immer noch mit einem Grafik- statt mit eim Textdisplay liebäugelt. Oder ein Textdisplay das sich auf Graphik "aufbohren" läßt. <KrümmelKackermodus aus> Mir scheint ohnehin, das der thread bisher am Thema vorbei schrammt, bevor eine konkrete Realisierung gestartet werden kann, sollte erst mal eine Architektur definiert werden, Anschliessend kann man daran gehen festzulegen, welche Funktionen (character ROM, X-Serialisierung, Spalzenvorschub, Syncerzeugung, --) wie realisiert werden (bspw. SW bit-toogling oder HW counter basierte puls generierung). Spezifiziert dr TO einen Zeichensatz von 8x8 und eine Textauflosung vom 80 Spalten und 60 Zeile ergibt sich eine Umsetzung mit 4800 byte Anzeigespeicher und 2kB Zeichen-ROM fast von allein. Dazu noch das Timing-Diagramm der gewünschten Anzeige (es gibt mehr Anzeigemöglichkeiten als SVGA - CRT altlasten) und man ist dem Wunschsystem schon deutlich näher. Persönlich würde ich mir eInk displays anschauen, das dürfte den Aufwand für den Controller deutlich vermindern, da nicht kontinuirlich Signale am AVR togglen müssen. Bspw. das: https://www.amazon.de/4-2inch-Resolution-Electronic-Interface-Raspberry/dp/B076B36NR3?th=1 Das ist dann zwar kein Graphikadaptar für einen Monitor, aber denoch ein Einfacher Computer mit textfähiger Anzeige. Sogar batteriefähig und tragbar :-)
>Dem Threadstarter geht es um Textdarstellung, >Die er dann wie an seinen Monitor bekommt dem uC, der das VGA Signal erzeugt ist es egal, ob die Pixeldaten Text oder Grafik sind. Letztlich ist nur die Farbtiefe und Auflösung entscheidend, die die Hardwareanforderungen definieren. Selbst 320x240x1bit@60Hz sind 562.5kByte pro Sekunde, die ein AVR in Echtzeit jedes mal neu errechnen muss, da er kein 1/2 MB RAM hat. Bei 640x480 sind es schon 2,2MB, 800x600 3,5MB, von Farbe wollen wir erst gar nicht anfangen. Es gibt genug Beispiele, wo jemand das geschafft hat. Mit einem uC, der mehr RAM hat wird die Grafikerzeugung wesentlich einfacher und es bleibt mehr Spielraum für die eigentliche Aufgabe.
captain obvious schrieb: >>Dem Threadstarter geht es um Textdarstellung, > >>Die er dann wie an seinen Monitor bekommt > > dem uC, der das VGA Signal erzeugt ist es egal, ob die Pixeldaten Text > oder Grafik sind. Nein. >Letztlich ist nur die Farbtiefe und Auflösung >entscheidend, die die Hardwareanforderungen definieren. Nur das bei Text die Farbtiefe inhärent 1bit ist, während VGA 8bit (Palette) vorsieht und für Textmodus gerade malbspw. 80 Zeichen mal 60 Spalten Elemente gespeichert werden müssen statt 640x480 . Hinzukommt der character rom aka Zeichengenerator der aber vernachlässigbar klein ist. Die Anforderung an den Controller unterscheiden sich also um mehrere Größenordnungen, dem µC ist es nicht egal ob Graphik oder Text.
captain obvious schrieb: > die ein AVR in Echtzeit jedes mal neu errechnen muss, Wenn es sich um Textdaten handelt, ist das Errechnen schon etwas überschaubarer, aber ja, so ein AVR hat dann schon zu tun. Sobald man zusätzliche Hardware einsetzen kann, ist das alles kein großes Problem; vor über einem Vierteljahrhundert habe ich mir mal ein Textterminal auf Basis eines 6809 und eines 6845 als Timinggenerator gebaut, das Zeichen in einer 9x12-Pixel-Matrix auf einem FBAS-Monitor ausgegeben hatte - mit 96 Zeichen in 25 Zeilen. Und wenn ich Interlace aktivierte, waren es 50 Zeilen (der Monitor brauchte dann aber brutal lang nachleuchtenden Leuchtstoff, sonst war das eklig). Der Text stand in einem 8-kByte-SRAM, der Prozessor hat nicht sehr viel mehr zu tun gehabt, als die Zeichen an die richtigen Adressen in diesem SRAM zu schreiben, und beim Scrollen dem Timinggenerator neue Startadressen mitzuteilen. Den Rest hat die Hardware erledigt - die halt, wie man das damals so gemacht hat, aus einer Handvoll Logikbausteine, einem Zeichengenerator-EPROM und einem Schieberegister bestand. Die gesamte Schaltung füllte eine Europakarte (Lochraster) und war mit CuL-Draht gefädelt. Da ich damals noch keinen VGA-Monitor hatte, reichten 16 MHz Pixeltakt. Heute würde ich mir einen ESP32 näher ansehen, der hat a) genügend RAM und b) genügend Rechenleistung und c) eine interessante programmierbare I2S-Schnittstelle. Aber das ist kein 8-Bit-µC und im DIP-Gehäuse gibt es ihn auch nicht ...
captain obvious schrieb: >>Dem Threadstarter geht es um Textdarstellung, > >>Die er dann wie an seinen Monitor bekommt > > dem uC, der das VGA Signal erzeugt ist es egal, ob die Pixeldaten Text > oder Grafik sind. Letztlich ist nur die Farbtiefe und Auflösung > entscheidend, die die Hardwareanforderungen definieren. > Selbst 320x240x1bit@60Hz sind 562.5kByte pro Sekunde, die ein AVR in > Echtzeit jedes mal neu errechnen muss, da er kein 1/2 MB RAM hat. > Bei 640x480 sind es schon 2,2MB, 800x600 3,5MB, > von Farbe wollen wir erst gar nicht anfangen. > Es gibt genug Beispiele, wo jemand das geschafft hat. > Mit einem uC, der mehr RAM hat wird die Grafikerzeugung wesentlich > einfacher und es bleibt mehr Spielraum für die eigentliche Aufgabe. Das gilt NICHT für Text. Also wenn die Seite 40x25 Zeichen darstellt und jedes Zeichen durch ein Byte darstellbar ist, brauchst du dafür 40 * 25 = 1000 Byte RAM als Puffer für die Textseite. Dazu kommt nochmal wenn ein Zeichen 8 Pixel breit und 16 Pixel hoch ist ein Char-ROM von maximal 256 Zeichen * 8 Pixel/Zeile * 16 Zeilen/Zeichen / 8 Pixel/Byte = 4096 Byte. Jetzt muss nur noch das Zeichen aus dem RAM geladen werden (LD Rd,Y+), die entsprechende Zeichenzeile aus dem Char ROM geholt werden (MOV ZH,Rz), (MOV ZL,Rd), (LD Rd,Z) und auf dem Port ausgegeben werden (OUT P,Rd). Geht also in 8(7) Takten. Wobei ZH die Zeichenzeile darstellt und nur einmal pro Zeile gesetzt werden muss, vorzugsweise im Blanking.
captain obvious schrieb: >>Dem Threadstarter geht es um Textdarstellung, > >>Die er dann wie an seinen Monitor bekommt > > dem uC, der das VGA Signal erzeugt ist es egal, ob die Pixeldaten Text > oder Grafik sind. Naja, ganz egal nicht. Für nur Text reicht ein deutlich kleinerer Framebuffer als für Grafik. > Selbst 320x240x1bit@60Hz sind 562.5kByte pro Sekunde, die ein AVR in > Echtzeit jedes mal neu errechnen muss, da er kein 1/2 MB RAM hat. Er braucht auch kein halbes MB RAM, da er nicht die 60 Frames für eine ganze Sekunde auf einmal speichern muss. Für einen Frame reichen auch 10k. C. A. Rotwang schrieb: > und für Textmodus gerade malbspw. 80 Zeichen mal 60 Spalten Elemente > gespeichert werden müssen statt 640x480 . Allerdings auch in 8 Bit, denn man speichert ja keine Pixel, sondern Textzeichen, von denen man in der Regel mehr als 2 darstellen können will. Die Ersparnis gegenüber Grafik (selbst bei 1 Bit/Pixel) ist dennoch erheblich. > Hinzukommt der character rom aka Zeichengenerator der aber > vernachlässigbar klein ist. Naja, 256 Zeichen mit je 16x16 Pixeln sind immerhin auch 8k. Aber beim Flash ist das meist weniger kritisch als beim RAM.
:
Bearbeitet durch User
Rolf M. schrieb: > Naja, 256 Zeichen mit je 16x16 Pixeln sind immerhin auch 8k. Aber beim > Flash ist das meist weniger kritisch als beim RAM. Ich dachte da eher an 8bit mal 8 bit wie beim seligen C64, und wenn man sich auf alphanumerische Zeichen beschränkt brauchts auch keine 256 Zeichen: https://opengameart.org/content/8x8-ascii-bitmap-font-with-c-source OK, die Chinesen sehen das natürlich anders.
Rolf M. schrieb: > 256 Zeichen mit je 16x16 Pixeln VGA verwendet 8x16 Pixel (bzw. 9x16 Pixel im echten Textmodus), und andere PC-Textmodi noch weniger: CGA 8x8, EGA 8x14, Hercules/MDA 9x14. 8x8 (das man auch von diversen Homecomputern kennt) ist so ziemlich die Untergrenze der Zumutbarkeit.
leo schrieb: >> Assembler kennt keine Spalteneinteilung. > > Klarstellung: bei den mir bekannten Assemblersprachen kam das nie vor. Es gab zumindest früher mal welche, bei denen Labels in der ersten Spalte anfangen mussten und bei Befehlen dort ein Leerzeichen erforderlich war.
:
Bearbeitet durch User
Einen noch - dann ist Schluss :) VESA 800x600 60fps non-interlaced mode (40 MHz fPixel) mit einem STM32F407: http://cliffle.com/article/2015/06/05/introducing-glitch/ Demo-Video https://www.youtube.com/embed/7yXxhvKmVb0
Wenn es wirklich nur um Textausgabe geht, kann man die über ein preiswert zu bauendes Terminal realisieren: http://www.geoffg.net/terminal.html Das Teil läßt sich auch anderweitig benutzen und die Programmierung der seriellen Ausgabe am AVR ist kinderleicht.
:
Bearbeitet durch User
Das von mir in diesem Thread zweimal verlinkte Projekt ("AVR VGA
Terminal") macht dasselbe, mit einem (übertakteten) AVR anstelle eines
32-Bit-PICs.
Icke ®. schrieb: > Wenn es wirklich nur um Textausgabe geht, kann man die über ein > preiswert zu bauendes Terminal realisieren: > > http://www.geoffg.net/terminal.html > > Das Teil läßt sich auch anderweitig benutzen und die Programmierung der > seriellen Ausgabe am AVR ist kinderleicht. "Graphics resolution is 480x288 pixels in VGA 25 line mode, 480x432 pixels in VGA 36 line mode, 288x216 in PAL composite and 264x180 pixels in NTSC composite mode" Bei den Leistungsdaten kann man auch eben einen übertakteten AVR benutzen, wahlweise als dedizierten Grafikchip.
Tim T. schrieb: > Graphics resolution is 480x288 pixels in VGA 25 line mode Dann würde das bedeuten, daß das Ding die angepriesenen > VGA can display 24 lines x 80 characters or an extended resolution of 36 lines x 80 characters ... Zeichen mit einer 6x12-Matrix darstellt. Da ist das übertaktete AVR-Terminal mit einer 8x16-Matrix attraktiver.
"Tasword Two" auf dem ZX Spectrum (?) hatte einen genialen Zeichensatz: ein "M" aus nur 3 Pixeln und so... :-)
Wenn man keine Interrupts benötigt und nur ein paar Zeilen Text, kann man auch AVGA benutzen, das läuft auf einem ATMega ohne extra Hardware (allerdings mit Quarz) in PAL, NTSC oder VGA. Wer Spass hat, kann dann auch einen Mega als Terminal mit AVGA benutzen und der andere füttert ihn. http://avga.prometheus4.com/
:
Bearbeitet durch User
Avga ist eher für Graphik- als für Textausgabe gedacht. Die Auflösung von allerhöchstens 320x240 ist ein Indiz.
Rufus Τ. F. schrieb: > 8x8 (das man auch von diversen Homecomputern kennt) ist so ziemlich die > Untergrenze der Zumutbarkeit. 6x8 (bzw. 5x7 ohne die Zwischenräume) ist auch völlig ausreichend. So wie man es z.b. hier sieht: https://fontstruct.com/fontstructions/show/847768/5x7_dot_matrix
>"Tasword Two" auf dem ZX Spectrum (?) hatte einen genialen Zeichensatz: > ein "M" aus nur 3 Pixeln und so... :-) Morsecode ist dicht und Dichter (duck und Weg);-) http://www.typophile.com/sites/default/files/old-images/CodePeanut-one-sample_3793.png
Rolf M. schrieb: > 6x8 (bzw. 5x7 ohne die Zwischenräume) ist auch völlig ausreichend. So > wie man es z.b. hier sieht: > https://fontstruct.com/fontstructions/show/847768/5x7_dot_matrix Für Leute, die nur ein paar Schriftzeichen ohne Unterlängen kennen, mag das ja ganz nett sein. Auf einem 7" TFT mit 800x480 "schafft" man damit 30 Zeilen mit 133 Zeichen (6x8). Aber wer will das denn lesen? bytefresser schrieb: > Ich werde nun erstmal ein 7" nextion Display testen, da das VGA doch ein > Problem ist. Unter 8 x 16 ist es m.E. eine Zumutung und selbst diese Darstellung ist auf einem 7" doch recht klein. Hat das nextion-Display einen eingebauten Zeichensatz? Wenn nicht, wird die Textausgabe nicht sonderlich schnell sein und bei größerer Darstellung noch langsamer werden. > Falls das nicht funktioniert werde ich ein stm32 als Gpu nutzen. Wenn Du Dir die ganzen Umwege sparen möchtest, solltest Du gleich damit beginnen.
bytefresser schrieb: > So vielen Dank für die guten Informationen, > Ich werde nun erstmal ein 7" nextion Display testen, da das VGA doch ein > Problem ist. > > Falls das nicht funktioniert werde ich ein stm32 als Gpu nutzen. BTW: Warum benutzt der TO plötzlich einen Gastaccount ??? -- Die Nextions haben wohl auch touch, das brauchst du doch garnicht? Mglw. kostet Dich das Lesbarkeit. Und nen ganzen stm32 als GPU für nen 8 bit'ter.. ich weiss nicht, dann lass doch gleich einen "AVR-Emulator" drauf laufen. Oder schneid den AVR-Zopf gleich ab.
m.n. schrieb: > Auf einem 7" TFT mit 800x480 "schafft" man damit 30 Zeilen mit 133 > Zeichen (6x8). Aber wer will das denn lesen? Es mag ja 7"-TFTs mit VGA geben, aber ich war davon ausgegangen, dass das nicht das Ziel war.
Moin, kann man dem AVR nicht einen Video Display Controller zur Seite stellen, so wie früher ein TMS9918 die Ausgabe für den Z80 gemacht hat? Oder gibt es solche Bausteine heute gar nicht mehr?
Doch, die gibt es noch, werden aber zumeist über einen 8/16 Adr.-/Datenbus angesteuert. Beispiel: S1D13705 und Nachfolger. Dann gibt es auch fertige Controller wie FT800/810 mit integrierten Zeichensätzen - ich mag sie nicht. Alternativ eine andere Lösung mit STM32F7xx, die nicht auf höchste Farbtiefe, aber auf hohe Ausgabegeschwindigkeit ausgelegt ist: Beitrag "4,3" TFT-Controller STM32F730" Was an Funktionen fehlt, kann man sich ergänzen. Ein Zeichensatz 8x16 ist vorhanden und bei reiner Textausgabe (17 Zeilen mit 60 Zeichen) wird am Zeilenende die nächste Zeile angefangen oder am Bildende die Ausgabe nach oben gerollt (scroll). Die ATmega kann man mit diesem µC fast weglassen ;-)
Es gab ja bei den Arduino VGA Spezis auch schon mal einen Ansatz, den ESP8266 dafür zu nehmen. https://github.com/smaffer/espvgax Eventuell wäre das ja ein Weg? Gruß Jörg
Joerg F. schrieb: > Eventuell wäre das ja ein Weg? Ein steiniger: > The VGA signal generation is stable only if you do not use any other hardware feature of the MCU (like Wifi or Serial).
So, ich habe mich jetzt für die VGA Ausgabe durch einen STM32 entschieden. Der die Daten vom 1284p per I2C empfängt.
>ich habe mich jetzt für die VGA Ausgabe durch einen STM32 entschieden. >Der die Daten vom 1284p per I2C empfängt. Welche Software nimmst Du da? Kannst Du den Link posten?
Adrian L. schrieb: > ich habe mich jetzt für die VGA Ausgabe durch einen STM32 entschieden. Der kann dann auch gleich die Aufgaben des ATmega1284 mit abwickeln. Und langweilt sich dabei...
Adrian L. schrieb: > An den 1284p sollen dann auch wechselbare eeproms mit 512kb ran. Der AVR kann keinen Code aus externem Speicher ausführen. Dafür mußt schon einen 8051 nehmen, z.B. AT89LP51RD2. Und bei 24MHz im Fast-Mode muß der externe Speicher auch noch verdammt fix sein.
Peter D. schrieb: > Adrian L. schrieb: >> An den 1284p sollen dann auch wechselbare eeproms mit 512kb ran. > > Der AVR kann keinen Code aus externem Speicher ausführen. Dafür mußt > schon einen 8051 nehmen, z.B. AT89LP51RD2. > Und bei 24MHz im Fast-Mode muß der externe Speicher auch noch verdammt > fix sein. Naja, so ganz stimmt es natürlich nicht, man könnte entweder den Code aus dem externen Speicher interpretieren oder häppchenweise ins Flash laden und von da aus dann ausführen. Schon klar das es streng genommen kein Ausführen aus dem externen Speicher ist und wirkt wie von hinten durch die Brust ins Auge, aber wenn man schonmal dabei ist einen STM als Grafikchip an einen AVR zu flanschen, geht auch sowas...
Adrian L. schrieb: > Ich möchte mir zur selbstbildung einen 8 bit Computer basteln. Folgende > Komponenten habe ich mir schon ausgedacht. > > Atmega 1284p mit einem stark modifiziertem Tinybasic als main core > Atmega 328p für Ps2 Tastatur, SD, und i2c zusatzkomponenten wie rtc etc. So, zur Selbstbildung. Nun, da halte ich deine Plattform-Auswahl für dezent ungeeignet. Wenn schon eine Art Homecomputer im Stil der 80er Jahre, dann eher ein Z80 System, wo CP/M drauf läuft. Das ist dann letzen Endes auch selbstfertil, also es gibt dafür (immer noch...) Assembler, Compiler und Interpreter, die auf eben dieser Hardware laufen. Und wenn du dir nen 20 MHz Z80 leistest und die übliche Peripherie (PIP,SIO,CTC) verzichtest - weil es die schwieriger gibt in 20 MHz - dann kann da sogar ein tatsächlich benutzbarer 8 Bit PC bei herauskommen. Als Peripherie würde ich da ne kleine CF-Karte sehen, dazu ne RAM-Floppy von 1 MB und wenn du dafür die Teile hast ne ROM-Floppy. Die Anbindung von Peripherie kannst du ja per PIC16F871 machen, der verträgt auch 20 MHz und er kann mit seinem Slaveport als I/O-Gerät vom Z80 aus benutzt werden. Ansonsten wäre für so ein Teil vielleicht ein wesentlich kleineres Display angemessen: zur Zeit gibt es welche bei Pollin (LCD, Varitronix, COG-VLGEM1277-01, 240x64 Pixel) sichtbar etwa 100x30mm für satte 0.95€. Immerhin wären da bei 6x8 Font 8 Zeilen à 40 Zeichen möglich. Und für den Anfang kannst du ja als Konsole nen FT245 nehmen und das Ganze per Terminalprogramm benutzen. Und JA! mit Asssembler auf Z80 und PIC16Fxx tut man was zur Selbstbildung - jedenfalls was das Grundlagenwissen und Können betrifft. W.S.
Nachtrag: jetzt müßte der TO wenigstens mal wieder aus seinem Versteck kommen. W.S.
Adrian L. schrieb: > Gibt es einen 8bit Chip im dip Gehäuse mit welchem ich VGA Auflösungen > bis zu 800x600 schaffen könnte? > > Der Datenaustausch zum VGA Chip soll auch per rx/TX stattfinden. > Es gibt da ein tolles teil- http://www.hobbytronics.co.uk/serial-vga > allerdings zu teuer und nicht mehr im 8 bit Bereich. > > Ich möchte aber zwingend im 8 bit Bereich bleiben. Sonnst könnte ich für > die VGA Ausgabe auch einen esp nutzen. Es ist zwar nicht ganz das was du suchst, aber wenn du ohnehin nur rx/tx nutzen willst, würde ich mal das Stichwort Gameduino in den Raum werfen. Damit hättst du etwas das fuktioniert und kannst schon mal anfangen, bevor du dich in Details verzettelst. In einem fotgeschrittenen Stadium kann man dann nochmal schauen, ob man die Grafik aufbohrt / umprogrammiert. Es ist zwar nicht die billigste Lösung, aber fertig und bezahlbar.
Wenn es auch etwas moderner als VGA sein darf: https://www.ftdichip.com/EVE.htm Sehr einfach über SPI ansprechbar, 8x8 font integriert.
Tim T. schrieb: > Peter D. schrieb: >> Adrian L. schrieb: >>> An den 1284p sollen dann auch wechselbare eeproms mit 512kb ran. >> >> Der AVR kann keinen Code aus externem Speicher ausführen. Dafür mußt >> schon einen 8051 nehmen, z.B. AT89LP51RD2. >> Und bei 24MHz im Fast-Mode muß der externe Speicher auch noch verdammt >> fix sein. > > Naja, so ganz stimmt es natürlich nicht, man könnte entweder den Code > aus dem externen Speicher interpretieren oder häppchenweise ins Flash > laden und von da aus dann ausführen. Und was soll das noch mal bringen? Programmabhängig den Flash neu schreiben... und wie oft kann der Programmbereich ausgeführt werden bevor der Flash stirbt?
Angehängte Dateien:
So, ich habe mir einen stm32 besorgt getestet und bin dann doch wieder komplett back to the roots. Die Grafikausgabe mache ich neben dem 1284p jetzt mit nem 328p der die Grafikausgabe per i2c empfängt. Zum Thema eeprom, habe gerade im Datenblatt nachgeschaut. Der schafft mehr als eine Million schreibe/lösch zyklen. Eventuel lege ich dort die Grafikdaten ab, der der 238p abrufen kann. Wie zb Bilder oder die Schriftart etc. Es ist ein wirklich tolles Projekt, habe die letzten Tage viel lernen können. Und das als Laie, wenn von euch jemand das sehen würde, würde derjenige vermutlich schreiend weglaufen. :-) Es ist alles soweit fertig bis auf die Grafikausgabe. Danach kommt das schöne, die Programmierung.
Adrian L. schrieb: > So, ich habe mir einen stm32 besorgt getestet und bin dann doch wieder > komplett back to the roots. Da bin ich ja auf die Begründung gespannt. > Es ist alles soweit fertig bis auf die Grafikausgabe. Mit einem ATmega328 wird das auch wohl so bleiben :-( Adrian L. schrieb: > An den 1284p sollen dann auch wechselbare eeproms mit 512kb ran. Es besteht ein Unterschied zwischen Bits und Bytes. Nicht immer alles gleich fressen ;-)
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.