Hallo Besucher, der Thread wurde 180k mal aufgerufen und enthält 1853 Antworten

letzter Beitrag von Retrofan am

Neuer Retro-Computer im 8-Bit Style

    Zitat von Snoopy

    Und auch als tragbares Terminal oder "Versicherungsrechner" wurden die Dinger verwendet. Ich habe darauf auch schon einfache Spiele gesehen. Als zusätzliches(!) Display fände ich das eine nette Idee und "mal was anderes".

    Ich glaube halt, das ein "Versicherungsrechner" nicht das ist, was sich viele hier wünschen. Es drehte sich doch bislang alles um bunte, tolle Games – entweder darum, sie zu spielen oder sie zu programmieren. Da scheint mir so ein paarzeiliges Display (ähnlich dem Atari Portfolio oder dem HX-20) einfach nicht sehr zielführend. Aber trotzdem natürlich danke für die zusätzliche Idee.


    Zitat von Snoopy

    Ich habe irgendwie das Gefühl, dass bei dir jeder Millimeter oder Pixel, der nach oben oder unten von deiner Vorstellung von Limitierung abweicht, auf Argwohn stößt.

    Das stimmt nun wirklich nicht. Hier wird ja nun "in jede Richtung ermittelt" und bin ich weit davon entfernt, auch nur einen Bruchteil davon zu kommentieren. Aber wenn mir persönlich eine Idee nicht gefällt, weil ich einfach nicht weiß, wie man sie im Canon der anderen Ideen unterbringen soll, dann werde ich das doch wohl mal schreiben dürfen. Auch ich habe eine persönliche Meinung und äußere die ab und zu.


    Ansonsten sind wir hier doch nun wirklich noch extrem offen, egal ob es die CPU angeht, die Geschwindigkeiten, die Grafikauflösung, die Farben, den Sound, den Formfaktor des Gehäuses, die Programmiersprache oder was auch immer. Da ist noch gar nichts andeutungsweise festgelegt (können wir auch gar nicht). Trotzdem darf natürlich auch jeder sagen, was er von neu eingebrachten Ideen hält.

    Zitat von Snoopy

    Der Epson HX20 zum Beispiel wurde seinerzeit als portables Gerät von Geschäftsleuten verwendet. "Anspruchslose" Texte konnte man damit problemlos tippen. Und auch als tragbares Terminal oder "Versicherungsrechner" wurden die Dinger verwendet. Ich habe darauf auch schon einfache Spiele gesehen. Als zusätzliches(!) Display fände ich das eine nette Idee und "mal was anderes".

    Das ist aber kein realistischer Usecase mehr, denn keine Firma würde sich so eine Gerät als Arbeitsrechner holen. IMO ist die mögliche Zielgruppe auf Democoder, Retrofans oder IT Studenten (zu Lernzwecken) beschränkt. Falls so ein Gerät gute Spiele produziert, eventuell auch noch einige Gamer, aber da gibts ja auch die Konkurrenz wie Switch die da einen grossen Vorsprung hat und auch moderner wäre und natürlich der PC sowieso.

    Zitat von sparhawk

    Das ist aber kein realistischer Usecase mehr, ...

    Heutzutage würde das natürlich so keiner mehr verwenden. :) Mir ging es darum, paar Beispiele aufzuzeigen, was man mit so einen "kleinen Displays" damals so alles gemacht hat. Da war man halt schon froh. dass der tragbare Rechner nicht 25 Kilo wog. :D


    Ich sehe es eher als eine Idee, so ein LCD-Display ZUSÄTZLICH mit ins Gehäuse zu bauen. Als kleines "Gimmick" zum extra Programmieren zusätzlich zum normalen Grafikmodus. Das könnte zum Beispiel für eine Uhr/Wecker sein, als Anzeige für den Namen des aktuell eingelegten Discimages, als Anzeige für Highscores usw. Also als frei programmierbaren ZUSATZ für paar kurze Texte.


    Als alleiniges Display wäre es schon wirklich arg "limitiert". Das hätte zwar auch seinen Reiz, aber nicht für einen Rechner in dem hier angedachten Sinn. ;)

    Zitat von Snoopy

    Heutzutage würde das natürlich so keiner mehr verwenden. :) Mir ging es darum, paar Beispiele aufzuzeigen, was man mit so einen "kleinen Displays" damals so alles gemacht hat. Da war man halt schon froh. dass der tragbare Rechner nicht 25 Kilo wog. :D

    Ein CBM SX-65 wog nur 10,5 Kg.
    ;-)

    Das sind Laptops. Interessant waere es, wenn das Heimcomputer waeren mit regulaerem Anschluss an TV/Monitor UND einem zusaetzlichen LCD-Display. Aber solang das LCD-Display das einzige Display ist, welches das Geraet besitzt, ist es glaube ich wirklich nicht ganz das, was wir hier besprechen. Als naechstes werden noch die 1-zeiligen BASIC-Taschenrechner gepostet, das ist ja alles schoen und gut aber das ist dann doch etwas am Thema vorbei. Die Idee, ein LCD-Display zusaetzlich zur Verfuegung zu stellen, ist durchaus interessant, fuer manche Anwendungen koennte das wirklich einen Zusatznutzen haben, aber jetzt hier einfach alle moeglichen Ur-Laptops aufzuzaehlen um zu zeigen dass es Rechner mit LCD-Display gibt, soll genau was bringen?

    Meinen Raspberry habe ich zwar schon bekommen, aber irgendwie will der nicht so richtig. Muss mal mit einem Kollegen reden der mit sowas schon gearbeitet hat. Habe zwar die Anleitungen befolgt aber ich bekomme gar nichts, als wenn der nicht läuft.
    Unabhängig davon habe ich mir aber mal angesehen wie man den programmieren muss und habe festgestellt dass man auf dem auch Qt zur Verfügung hat, also habe ich erstmal ein Projekt erstellt um die grobe Projektstruktur festzulegen und ein "Hello World" geschrieben das einfach nur ein Fullscreen Window öffnet und darin pixelbasiert zeichnet.
    Das läuft auch flott genug, so dass ich mir vorstellen kann dass man eine vernünftige Geschwindigkeit hinbekommen sollte, aber das muss ich noch prüfen wie schnell das auf einem Raspberry dann ist.


    Das wird dann im Wesentlichen die Grundlage für die Graphikhardware werden, über die ich mir auch schon ein wenige Gedanken gemacht habe. Da das ganz schön geklappt hat, werde ich dann mal drangehen und einen Layer schreiben, der eben die Grafikhardware abbilden soll. Meine Vorstellung davon ist, dass man den so programmieren kann wie man das halt von den alten Rechner gewöhnt ist. Also indem man direkt in die Hardwareregister schreibt um irgendwelche Effekte auszulösen. Wenn dann mal das Basic läuft kann man dann wie früher mit PEEK und POKE auch arbeiten, oder auch mit Assembler (oder compilierten Modulen).


    Also z.B. sowas wie:


    Code
    1. REM Switch to 80x40 character display mode by setting the appropriate char width and line height.
    2. POKE <SCREENMODE_REGISTER>, 3
    Zitat von sparhawk


    Das wird dann im Wesentlichen die Grundlage für die Graphikhardware werden, über die ich mir auch schon ein wenige Gedanken gemacht habe. Da das ganz schön geklappt hat, werde ich dann mal drangehen und einen Layer schreiben, der eben die Grafikhardware abbilden soll. Meine Vorstellung davon ist, dass man den so programmieren kann wie man das halt von den alten Rechner gewöhnt ist. Also indem man direkt in die Hardwareregister schreibt um irgendwelche Effekte auszulösen. Wenn dann mal das Basic läuft kann man dann wie früher mit PEEK und POKE auch arbeiten, oder auch mit Assembler (oder compilierten Modulen).

    Hast du dabei einen konkreten Grafikchip als reale Hardware im Kopf, den du möglichst gut nachbilden willst oder bastelt du "deine eigene" Grafikhardware als Software?


    Schön, dass du dich da dran machst! :thumbup:

    Zitat von Snoopy

    Hast du dabei einen konkreten Grafikchip als reale Hardware im Kopf, den du möglichst gut nachbilden willst oder bastelt du "deine eigene" Grafikhardware als Software?
    Schön, dass du dich da dran machst! :thumbup:


    Konkrete Hardware habe ich da nicht vor, sonst wirds ja "nur" ein Emulator. Allerdings nehme ich mir echte Hardware zum Vorbild (soweit ich die kenne), damit es sich dann halt so wie "damals" anfühlt wenn man damit arbeitet.

    Zitat von sparhawk

    werde ich dann mal drangehen und einen Layer schreiben, der eben die Grafikhardware abbilden soll.

    Feine Sache. In welcher Sprache schreibst Du den? C? Am besten denk Dir zu Beginn einen einfachen "Videochip" aus, der z. B. nur über 320x200x2 Bitmap verfügt. Damit kann man dann herausfinden, wie schnell die Ausgabe tatsächlich wird.


    Bei der Definition Deiner Videoausgabe mußt Du vorab ein paar Eigenschaften festlegen:
    - Verwendet Deine Ausgabe den allgemeinen Arbeitsspeicher, in dem sich auch das Programm befindet (wie z. B. beim C64), oder basiert es auf einem getrennten Videospeicher?
    - Wo in dem Speicher befinden sich die Videodaten? Beim AppleII war das z. B. der Bereich $2000..$3fff bzw. $4000..$5fff, wohingegen es beim C64 schon recht flexibel zugeht. Für den Anfang reicht es aus, die Videodaten stets von derselben (Start)Adresse zu holen.
    - Welche Methode willst Du verwenden, um Änderungen des Videospeichers (z. B. durch den Prozessor) im Anzeigebild wiederzugeben?
    Hierfür stehen vier verschiedene Ansätze zur Verfügung:
    1.) Schreiben auf den Datenbus führt direkt zum Update von Pixeln auf dem Bildschirm
    Jedes Mal, wenn der Prozessor einen Wert schreibt, wird geguckt, ob die Adresse zum Speicher gehört, der für die Anzeige verwendet wird. Ist das der Fall, werden die Bits des geschriebenen Bytes direkt umgewandelt in die Farbpixel für die Bildschirmanzeige. Schreibt der Prozessor nicht in den Videospeicher (oder liest er nur Daten) hat der "Videochip" folglich nichts zu tun. Das spart Rechenzeit. Macht man zusätzlich zur Bedingung, daß der neue Wert sich von dem alten Wert unterscheiden muß, hat man eine Methode, die sehr schnell ist und ganz gut funktioniert bei einer Videoausgabe wie z. B. beim AppleII. (Der Apple2000-Emulator auf dem Amiga verwendet diese Methode). Voraussetzung hierfür ist, daß das Aussehen der Pixel allein auf dem einen Byte beruht, das geschrieben wird, und nicht auf zusätzliche Register wie z. B. Farbregister. Bei Änderung eines Farbregisters müßten nämlich alle Bytes der Anzeige neu umgerechnet werden in die Farbpixel der Anzeige und nicht nur das einzelne geschriebene Byte. Das kann dann bei vielen schnell aufeinanderfolgenden Veränderungen der Farbregister das Videochip-Programm ziemlich lahmlegen.
    2.) Hat man also zusätzliche Register wie Farbe oder Anzahl der Farben (HiRes, Multicolour etc) kann man sich der Methode bedienen, nach einer bestimmten Anzahl von Taktzyklen des Prozessors den ganzen Bildschirm (einen kompletten Frame) neu zu malen. Bei einem Prozessor wie dem 6502 mit 1 Mhz ergibt sich, daß bei einer Bildrate von 60 Bildern pro Sekunde die komplette Anzeige nach 1.000.000 / 60 = ~16.667 Takten neu gezeichnet werden muß. Das Neumalen kann man hierbei eventuell beschleunigen, indem man einen Cache einführt. Das Videochip-Programm merkt sich, welches Byte zuletzt an der Stelle im Speicher stand plus einige andere Eigenschaften der Anzeige. Nur wenn sich zwischen den beiden Frames eine Änderung ergeben hat, wird die Anzeige aufgefrischt. Die Frame-Methode ist für viele Spiele schon ausreichend, aber nicht für Spiele, die einen Rasterinterrupt einsetzen, um Splitscreen-Effekte zu erzeugen (Ändern von Bildschirmauflösung oder -modus mitten im Bild).
    3.) Dafür braucht man mindestens eine zeilenbasierte Wiedergabe. Bei dieser wird die Anzeige nicht nach jedem Frame neu berechnet, sondern bereits nach jeder Zeile. Hiermit lassen sich einfache Rastereffekte schon gut darstellen. (Die ersten Versionen des Frodo-Emulators benutzten diese Methode.) Auch hier kann man einen Cache einsetzen zur schnelleren Bearbeitung. Bei einem C64 bedeutet dies, daß nach 65 Prozessortakten die nächste Zeile gemalt werden muß.
    4.) Eine vollständige Emulation eines komplizierten Graphikchips verlangt am Ende eine taktzyklengenaue Wiedergabe, d. h. Prozessor und Videochip führen abwechselnd ihre Berechnungen für je einen Takt durch. Diese Methode ist zwar die genaueste, braucht jedoch ziemlich viel Rechenkapazität.


    Die Vorgehensweise bei den letzten drei genannten ist ziemlich gleich (folgender Code ist nur ungetesteter Pseudocode):


    Welchen Weg Du auch immer wählst: Viel Spaß und Erfolg beim Coden!

    Ich habe mir mal die ganzen Kommentare hier durchgelesen und mich sozusagen up-to-date bei diesem Thread gebracht.


    Ich frage mich: lässt sich nicht so ziemlich jeder Wunsch, den hier geäußert wurde, durch Umbauten am C64 realisieren? Man kann das Basic verbessern, dem Gerät mehr Speicher verpassen (ich erinnere mich da an die 60KB Erweiterung), dem C64 ein vernünftiges Dateisystem gönnen. Mit dem FPGASID gibt's doch schon einen Digitalkanal, oder? Eine Entwicklungsumgebung ließe sich auch einbauen. Und die CPU wird doch gerade als FPGA nachgebaut. Das Ding ließe sich dann erweitern, um bestimmte Aufgaben zu beschleunigen. Und was für die 6510 gilt, klappt doch dann auch für den VIC, oder nicht? Dann ließen sich auch neue Grafikmodi umsetzen. Natürlich hat man die Beschränkung von 16KB Videospeicher und kann pro Rasterzeile nicht beliebig viele Lesezugriffe auf das RAM machen, so dass mehr Sprites nur möglich wären, wenn sie schmaler sind, aber 16 frei wählbare Farben und Sprites mit beliebiger Höhe sollten im Bereich des Möglichen sein. Nur der von vielen gewünschte 80-Spalten-Modus dürfte schwierig werden.


    Jeder kann sich bei dem Feature austoben, das ihm am wichtigsten erscheint und am Ende entsteht ein aufgebohrter C64, der weitesgehend softwarekompatibel zum Original ist.

    Der VIC III aus dem C65 hat ein 80-Zeichen-Modus.


    Mir würde eher interessieren ob man den SID z.B. 6 Stimmen verpassen könnte in Stereo bei beibehaltung nur einer I/O Adresse. Also nicht Stereo indem man 2 SIDs einbaut, sondern den SID selbst quasi intern verdoppelt.

    Zitat von Freddy

    Der VIC III aus dem C65 hat ein 80-Zeichen-Modus.

    Ich glaube aber, dass der Takt des C64 nicht ausreicht, um 80 Bytes pro Rasterzeile einzulesen. Wenn du einen 4x8 Font verwendest, gibt es vielleicht ein paar verrückte Lösungen, ansonsten wären wohl 64-Spalten das Maximum, wenn man noch ein bisschen CPU-Zeit übrig haben möchte...