Posts by M. J.

    - Programmiereinstieg an der Schule auf einem AppleIIe mit UCSD-Pascal.:love:

    - In Pascal einige kleine Spiele geschrieben (mit Turtlegraphics), da es aber recht langsam war, angefangen den UCSD-Assembler für kleine Unterroutinen zu verwenden (, wodurch Programme plötzlich irreschnell wurden).

    - Da es kaum Handbücher gab zur Programmierung in Assembler, wurde der im Rom eingebaute Monitor des AppleIIe eifrig genutzt, um fremden Code zu disassemblieren und daraus zu lernen. Applesoft-Basic hat man sich irgendwie nebenbei angeeignet.

    - Leider ist die Handhabung von Assembler im UCSD-System sehr umständlich und langsam, daher Wechsel auf den Merlin-Assembler unter DOS 3.3.

    - Zumindest bis zum Kauf des C128. Für diesen im C64-Modus einen Assembler aus der 64'er abgetippt: AE64. Kennt den eigentlich jemand? Damit erste Programme auf dem C64 geschrieben, wobei der eingebaute Monitor des C128 ebenfalls sehr nützlich war.

    - Der AE64 erfüllte zwar seinen Zweck, basierte aber wie die meisten Assembler damals[tm] auf dem Basic-Zeileneditor, was nicht sehr komfortabel ist. Daher lag der Entschluß nahe, einen eigenen Assembler mit 80 Z/Z-Bildschirmeditor zu schreiben und fortan zu verwenden.

    - Zumindest bis zum Kauf des Amiga500. Auch hier das Problem: Es gab kaum (preiswerte) Literatur. Das Grundwissen über die Hardware hat man sich aus den Zeitschriften zusammengesucht. Der einzig verfügbare Assembler war der SEKA-Assembler (eine der ersten Versionen). Und wieder ein grauenhafter Editor...

    - Daher lag der Schluß nahe, einen eigenen Assembler zu schreiben. Diesmal neben Texteditor auch mit Disassembler verpackt in einem eigenen System, was direkt von Diskette bootete und sich gut dafür eignete, in fremdem Code herumzuwurschteln.

    - Sämtliche Programmierung auf dem Amiga geschah zunächst wieder in Assembler, doch sehnte ich mich auch nach einer Hochsprache wie Pascal. Das mitgelieferte AmigaBasic konnte jedoch so gar nicht überzeugen. Anderes hatte ich aber nicht. Also bastelte ich noch einen kleinen Interpreter/Compiler mit dem Ziel, damit alte Pascalspiele wieder zum Leben zu erwecken. Hat erstaunlicherweise funktioniert.

    - An der Uni kam ich im Grundstudium kurz in Kontakt mit Modula-2 auf dem AtariST. An sich eine schöne Sprache (in vielen Punkten besser als Pascal). Leider war auch dieser mitgelieferte Editor eine Katastrophe. Es blieb eines der großen Rätsel der Informatikgeschichte: Warum nur kriegten die es nie hin, zur Sprache auch einen guten Editor mitzuliefern... ;(

    - Eher aus Jux hatte ich mir mal vorübergehend einen alten 286er PC ausgeliehen und darauf mit TurboPascal und Unterroutinen in x86-Assembler einen kleinen AppleII-Emulator geschrieben, aber schnell die :aerger: segmentierte Adressierung verflucht. Alle weiteren Schritte auf dem eigenen PC liefen dann größtenteils im 32-Bit-Modus und unter C/C++, Java, Perl etc. Aber das fällt dann nicht mehr in die Rubrik "Homecomputer".


    Ich denke, meine Erfahrung mit der Programmierung auf den Homecomputern hat mich ziemlich geprägt. Auch heute noch, wenn es darum geht, was Neues zu lernen wie z. B. die Programmierung in Verilog, suche ich mir zunächst Informationen aus dem Netz zusammen hauptsächlich in Form von realem Code anderer Entwickler, studiere diesen dann ausgiebig, um daraufhin eigene Lösungen für die gesetzten Ziele zu entwickeln. Kurz gesagt: Mehr Learning by doing als langes Lesen von Einführungsbüchern.

    Das ist Ameisen-Parsing.

    Okay, daß der Interpreter bei der Ausführung einen Lookahead von 1 hat, ist ja nichts ungewöhnliches. Würde ich auch so machen. Aber beim Durchgang durch den Code hangelt er sich ja immer nur von Token zu Token, d. h. trifft er auf ein Zahlentoken, wird der nachfolgende Wert auf den internen Wertestapel gepackt (, sofern der Modus Termbehandlung aktiv ist, ansonsten gibt es einen Syntaxerror). Da jede Zahlenkonstante also stets von einem Token eingeleitet und damit geschützt wird, kann der Interpreter bei normaler Schritt-für-Schritt-Ausführung niemals auf ein (falsches) Nullbyte oder Doppelpunkt etc einer Zahlenkonstante stoßen. Dies wäre nur dann der Fall, wenn der Interpreter Programmcode überspringen und sich irgendwo später wieder in den Codestream einklinken muß. Bei einem normalen Basic-Interpreter würde ich davon ausgehen, daß dies nur bei der Suche nach der nächsten DATA-Anweisung der Fall ist, wenn nur auf das DATA-Token und das Nullbyte getestet wird. Bei Verwendung einer Zahlenkonstante müßte man folglich die Zahlentokens ebenfalls erkennen und die Zahlenwerte überspringen. Ich kann mir aber nicht vorstellen, daß dafür wesentlich mehr Interpretercode notwendig ist. Im Gegenteil dürfte die normale Interpreterschleife als Ausgleich dafür verkürzt und beschleunigt werden, da jedes gelesene Zeichen nicht mehr automatisch auf eine Ziffer getestet wird.

    Aber der Interpreter merkt sich (quasi im Cache) weder die Adresse der "aktuellen" Zeile noch die Folgezeilenadresse.

    :facepalm:Heißt das ernsthaft, daß bei einem IF das Überspringen der Befehle nach dem IF bzw. der Sprung in die nächste Zeile dadurch realisiert wird, daß anhand des Nullbytes die nächste Adresse gesucht wird, anstelle die Adresse der neuen Zeile direkt aus dem Programmcode zu entnehmen? Das wäre allerdings eine ziemlich bescheidene Vorgehensweise, weil a) umständlich und b) langsam. Bei einer nicht zeilenorientierten Sprache wie Pascal wäre so etwas wohl notwendig, aber Basic hätte zumindest hier mal einen kleinen Vorteil gegenüber richtigen Hochsprachen. Diesen nicht zu nutzen ist ... suboptimal.

    Ich denke, weil man das über Konstanten sehr leicht selber optimieren kann, wenn es einem auf die Geschwindigkeit ankommt.
    Beim PET hätten die zusätzlichen Routinen vielleicht nicht mehr ins vorhandenen ROM gepasst und hätten das Gerät teurer gemacht.

    Mehr Platz im Rom für den Basic-Interpreter könnte ein Grund sein, obgleich ... wäre das wirklich so viel? Irgendwann müssen die Zahlen ohnehin geparst und umgewandelt werden. Bliebe wohl nur die Ausgaberoutine ("LIST"), die die zusätzlichen Tokens zurück in Zahlen konvertieren müßte. Und natürlich das von JeeK erwähnte Problem.

    Was die Geschwindigkeit anbelangt, sind Variablenkonstanten wohl schneller als Zahlstrings, aber auch das Parsen der Variable kostet einiges an Zeit. Echte Zahlenkonstanten dürften im Vergleich dazu nochmals schneller sein.

    BBC Basic macht das.

    Danke für die Info. Könnte ein Grund sein, warum BBC Basic (auch bei 1 Mhz) schneller ist als andere Interpreter.

    Ist problematisch, weil ja das High- und Low-Byte 0, $22 (") und $3A (:) enthalten kann. Die werden exklusiv für das Zeilenende, für String-Delemiter und Kommandoende vom Interpreter verwendet, ungeachtet dessen, welche Token eventuell so einen Wert einleiten.

    Guter Einwand. Leider kenne ich mich mit dem C64-Basic-Interpreter nicht so gut aus. Daher weiß ich nicht, wann an welcher Stelle z. B. nach dem Zeilenende gesucht wird. Dieses ist ja eigentlich bereits in dem Link auf die nächste Zeile enthalten. Eine einfache Differenz zwischen Linkwert und Zeilenadresse dürfte das gleiche Ergebnis liefern, aber deutlich schneller sein. Während der Programmausführung lassen sich Zeilenende und Zahlenwert eigentlich gut unterscheiden, denn ein Zahlentoken würde nur auftreten in einem Term oder einer DATA-Anweisung. In anderen Fällen gäbe es einen ?SyntaxError. Wird die Ausführung einer Zeile vorzeitig abgebrochen z. B. bei Nichterfüllung einer IF-Bedingung, würde es ausreichen, den Link auf die nächste Zeile in die Programmadresse zu laden. Von daher kann ich mir als Basic-Laie keine Situation vorstellen, in der man dieses Nullbyte wirklich suchen muß. :gruebel Gleiches gilt auch für den Doppelpunkt oder das Anführungszeichen. (Nebenbei: Damals[tm] hatte ich auf dem Amiga mal so eine Art Minipascal-Interpreter geschrieben, bei dem Schlüsselwörter im Text durch Tokens ersetzt wurden teils mit Adresszeiger auf ein Sprungziel im Text. Neben den Adressen konnten auch die Tokennummern alle Werte enthalten (z. B. den Returncode), ohne daß dadurch der Interpreter durcheinandergeraten wäre...)

    Die Umwandlung das Konstanten-Strings in die Binärrepräsentation (egal ob Integer oder FP) ist vergleichsweise aufwändig.

    Mal eine dumme Frage: Warum hat man eigentlich Zahlenwerte nicht auch tokenisiert? Platz in der Tokenliste wäre ja noch gewesen. Z. B. hätte man einfache Bytewerte speichern können als Token+Byte und 16 Bit-Werte als Token+Lowbyte+Highbyte und dann natürlich echte Fließkommawerte als Token+Exponent+Mantisse... Gibt es irgendeinen (triftigen) Grund dafür, daß Zahlenkonstanten stets als Zeichenkette abgelegt werden?:gruebel

    Also ich bin sehr begeistert von dem Spiel.

    Yep, ich find's auch toll. Interessant finde ich auch den Ansatz, die Spieldaten mit Hilfe einer XML-Struktur zu erstellen und von einem Konverter in eine C64-Datei zu übersetzen, die dann über einen Interpreter ausgeführt wird. Das sollte das Entwickeln weiterer Adventures vereinfachen.

    Die Idee eines Daten-Interpreters (in diesem Fall sogar in Basic) selber ist nicht neu - wenn ich mich recht erinnere, hat schon Scott Adams auf solch ein System zurückgegriffen, und ich meine, es gab mal ein Basic-Buch über Adventures, welches als Listing einen Dateninterpreter enthielt -, die Anwendung dieser Systeme war und ist jedoch sehr mühsam, wohingegen EgonOlsen71s Ansatz für die Erstellung und Bearbeitung der Daten auf dem PC dem Schreiber eines Adventures viel Arbeit abnimmt. Zwar gibt es mit Inform eine ausgewachsene (und komplizierte) Adventuresprache, aber dafür ist die Ausführung der erzeugten Spieldaten auf dem C64 häufig mit viel Geduld verbunden, sofern überhaupt möglich. Andere und vor allen Dingen einfach zu handhabende Adventuresysteme für Textadventures (also solche mit Befehlseingabe über dir Tastatur) für den C64 würden mir jetzt auch nicht einfallen.:gruebel Von daher würde mich interessieren, wie weit das System trägt, d. h. welche Adventures mit welchen Operationen damit möglich sind.

    Vielen Dank für das Spiel!:thnks:

    Auch super: Hab direkt im Computerladen mal quergecheckt und Self Control kam in der Tat in paar Monate vor dem Geschehen in dem Spiel raus. Drei Daumen hoch!

    Nicht zu vergessen der aprilfrische Duft der Prilblumen... ^^


    Wenn gestattet würde ich gerne drei Punkte zum Spiel anmerken:


    1.) Vorschlag:

    Wenn nach einer EIngabe mehr als 24 Zeilen Text ausgegeben werden, erscheint keine Anzeige "[Pause]" oder ähnliches, bei der auf einen Tastendruck des Spielers gewartet wird um sicherzustellen, daß der Spieler wirklich alle Zeilen lesen kann. Spätestens beim Ende des Spiels wäre das sehr hilfreich. Frage: Läßt sich sowas nachträglich in den Interpreter einbauen? Wäre es außerdem möglich, die übliche Abkürzung "i" für "Inventar" zur Wortliste hinzuzufügen?


    2.) Frage:

    Der Parser versteht zwar eine einfache Form einer Verknüpfung von Befehlen wie im erwähnten Beispiel "schau Schrank und oeffne ihn und nimm ZX81 und benutze ihn mit dem Fernseher", gibt man jedoch "n und n" ein, so meldet der Parser

    'n' kenne ich nicht!

    > 'n'

    'n' kenne ich nicht!

    Woran liegt das? Gelten Richtungsangaben nicht als Verben?


    3.) Kritik:

    Das Spiel hat ein großes Manko: Es ist zu kurz. :cry: Besteht vielleicht Hoffnung auf mehr Textadventures von Dir? :dafuer:

    Also der Noob macht, und der Pate z.b. testet und gibt Hilfestellung/codesnippets usw. Hauptarbeit hat aber der Anfänger.

    Bei allen bisherigen F64-Compos war Teamarbeit ausdrücklich gestattet, d. h. es wäre möglich gewesen wie von Dir beschrieben, daß sich ein Anfänger und ein erfahrener Programmierer zusammentun und gemeinsam etwas kreieren. Was dazu fehlt, ist eigentlich nur, daß sich derjenige, der solch ein Projekt starten möchte, nach Mitarbeitern umschaut. Für eine Compo wäre es vielleicht etwas von Nachteil, wenn eine solche Anfrage zu offen stattfinden würde in der Form "Habe dieses und jenes Spiel vor. Dies und das wird passieren. Es gibt diese und jene Spielmechanik und solche Grafik...", da dies vorab zu viel über das Projekt verraten könnte. Aber sicherlich fände sich auch ein anderer Weg, um auf sich aufmerksam zu machen und einen Mitstreiter ins Boot zu holen. Man muß es halt versuchen und einfach mal anfragen. Mehr als eine Absage kann man sich ja nicht einhandeln.

    Eine Art Anfänger Competition wäre witzig.

    Tja, eigentlich schon, aber unter welchen Bedingungen gilt man als "Anfänger"? Es ist eher unwahrscheinlich, daß ein Programmierer in allen möglichen Spielgenres Meister ist. Jemand, der z. B. ein RPG programmiert hat, kann trotzdem noch Anfänger sein bei einem Ballerspiel. Von daher dürfte es schwierig sein, die Kategorie genau zu definieren. :/ Meiner Beobachtung nach waren eigentlich alle vergangenen Compos extra so organisiert, daß man auch als Anfänger und/oder Basic-Programmierer daran teilnehmen konnte. In dieser Hinsicht waren keine Hürden gesetzt. Die wahre Hürde besteht eher im Kopf, sich über einen längeren Zeitraum mit einem Projekt zu befassen und dieses dann auch einzureichen.

    aber solls eigentlich mal wieder ne Forum64 Game DEVELOPMENT Compo geben?

    Hatte ich mich auch schon gefragt. Okay, wegen diesem :aerger: Corona war es dieses Jahr (zumindest bei mir) ein wenig ungünstig, aber generell wäre es schön, wenn es eine neue Compo geben könnte. Mein Vorschlag: 64kb-Compo. Spielgenre egal, aber das Spiel muß vollständig in den Speicher passen (ohne nachzuladen). Basic-Programme sind ausdrücklich erwünscht. Wie wäre das?

    <etwas offtopic, ich bitte um Verzeihung>


    Disassemblieren kann ich mir die zur Not auch selbst

    Ich hatte mal angefangen, die AppleII-Version zu disassemblieren, da es die Version ist, die ich am meisten in den Denkpausen spiele. (Diese Version ist ein wenig betulicher als die C64-Version und daher eher geeignet für ein Mal-eben-so-zwischendurch. ^^ ) Bei der C64-Version würde ich aber heute anders vorgehen und diese zunächst mit einem automatischen Disassembler (sowas wie Deinem Z80-Disassembler) vorbearbeiten. Was würdest Du denn anschließend mit dem Code anstellen wollen?

    Als Original habe ich alle mir bekannten Versionen in der Vitrine stehen.

    Auch die AppleII-Version?


    </etwas offtopic, ich bitte um Verzeihung>

    Hat gar keinen Kopierschutz ..

    Ist schon klar.^^ Meinte das eher in die Richtung: Stephan beschreibt hier schöne Zutaten für einen möglichen Kopierschutz, sofern man es darauf anlegt, Cracker so richtig schön zu nerven. Jedoch zeigt das Beispiel auch hier: Selbst der beste Kopierschutz hat bei Stephan keine Chance.:D

    Soweit ich das jetzt herausgefunden habe, befinden sich die Tabellen für das abspielen der Demo auf Track 35 Sektor 01 bis 06.

    Ah, super! Vielen Dank für den Hinweis! :thumbup: Track 35, Sektoren 1 bis 6... Welch Wunder, daß bei den anderen Versionen die Demo nie funktionierte. Da die Sektoren bei Dir nun richtig übernommen werden, kann man wohl davon ausgehen, daß die Demo jetzt korrekt abläuft. :)

    Wurde da alles weggeworfen, wenn eine Firma dicht machte?

    Sicherlich gab es auch Programmierer, die den Source auf einer Kopie-Diskette nach hause mitgenommen haben.

    Besonders in den Anfangsjahren der Homecomputer entstanden wohl die meisten Spiele nicht in irgendeinem Büro in einer Firma, sondern zuhause bei Privatpersonen. Die Spiele wurden erst nach Fertigstellung von einem Publisher (Br0derbund, Sirius, Penguin etc) veröffentlicht bzw. nach Vorlage einer aussagekräftigen Demo (= mindestens halbfertiges Spiel) bis zur Fertigstellung vom Softwarehaus gefördert. Die Entwicklung geschah jedoch (wie beispielsweise bei "Elite", dessen BBC-Code ebenfalls veröffentlicht wurde) dann am heimischen Rechner. Die Frage ist daher: Wieviele Programmierer von damals haben es geschafft (oder sich überhaupt die Mühe gemacht), ihre privaten Disketten über all die Jahre hinweg zu retten, um deren Inhalt Jahrzehnte später auf den PC zu übertragen? Zum einen sind viele Programmierer von damals leider schon verstorben. Zum anderen haben sich viele später anderen einträglicheren Berufen zugewandt, sprich: deren Interessen haben sich komplett verlagert.

    Aus diesen Gründen werden die meisten Original-Sourcecodes wohl für immer vernichtet worden sein. ;( Disassemblierung ist somit die einzige Möglichkeit zu erfahren, wie die Programme von damals funktionieren. Nur als Beispiel: Neulich habe ich die Grafikroutinen von "Mission Asteroid" (sowie weitere ähnliche Spiele von Sierra Online) disassembliert und dabei festgestellt, auf welch interessante Art und Weise sich der/die Programmierer dabei von hinten ins Knie geschossen haben. All dieses Programmierwissen wird wohl verloren gehen, was auch daran liegt, daß es zum einen kaum Interesse daran gibt. Der Kreis derer, die sagen "Oh, schön zu sehen, wie das funktioniert, wollte ich schon immer mal wissen..." ist halt sehr gering. Zum anderen steht auch stets die Frage im Raum, inwieweit solch ein archäologisches Disassemblieren mit Zurschaustellung des disassemblierten Codes legal ist. Persönlich hätte ich mir schon längst gewünscht, daß ein Magazin wie "Return" in einer Kolumne diverse alte Programmiertechniken bespricht und darstellt (ohne den Aspekt, daß sie jetzt besonders gut sein müssen). Selber könnte ich wahrscheinlich Tonnen an Material dafür liefern. Doch neben der mangelnden Nachfrage gibt es wohl auch den rechtlichen Aspekt, der dagegen spricht.:/

    Schade wenns kein original Quellcode ist. Aber löchen werde ich das nun nicht. Ich habe mir die Dateien noch nicht mal richtig angesehen.

    Um Himmels willen bloß nicht löschen! Selbst wenn sich hier jemand "nur" die Arbeit gemacht hat, den Originalcode eines Spiels zu disassemblieren und zu kommentieren, ist das schon sehr viel wert. Und - wie gesagt - Disassemblieren dürfte wahrscheinlich heutzutage die einzige Methode sein zu erfahren, wie das Programm arbeitet.

    Gibts auch Impossible Mission als original Quellcode?

    Soweit mir bekannt ist, gibt es nur den (unfertigen) Code für "Impossible Mission II" auf dem AppleII zum Herunterladen. Doch der ist anders gestrickt als die Ursprungsversion. Auch hier hilft wohl nur Disassemblieren. Welche Version suchst Du denn? C64? CPC (falls es die gab)?

    Einigermaßen....was funktioniert denn da nicht ganz so wie es sollte?

    "Einigermaßen" war nicht so ganz ernst gemeint. Besser wäre "nicht wie erwartet in Anlehnung an die AppleII-Version". Die grundlegende Frage ist: Wie sind die Demos überhaupt programmiert? Es gibt ja zwei Möglichkeiten: 1.) Der Programmierer hat die Tastendrücke bzw. Joystickbewegungen aufgezeichnet und läßt sie im gleichen Tempo wieder abspielen. 2.) Die Bewegungen der Spielerfigur sind rein algorithmisch. In beiden Fällen wäre noch relevant, ob zu Beginn der Demo der gleiche Seed für die Zufallszahlen vorliegt. Falls nicht, wird Methode 1) nicht funktionieren, da gemessen an der zufällig erzeugten Situation die falschen (= unpassenden) Bewegungen ausgeführt werden. Bei Methode 2) würde es hingegen bedeuten, daß der Ablauf der Demo immer verschieden ist. Beispiel für Methode 2) wäre "Uridium". Das Spielerraumschiff wird zufällig bewegt, bis es zerstört wird oder eine bestimmte Zeit abgelaufen ist. Beispiel für Methode 1) wäre "Lode Runner".

    Beim Betrachten der Demo von "Wings of Fury" fiel mir auf, daß beim zweiten Durchgang das vom einem feindlichen Flugzeug verfolgte Spielerflugzeug andauernd Kreise flog, was eher nach einer algorithmischen Vorgehensweise (Methode 2) aussieht. Dagegen spricht aber der Eindruck bei den kaputten Demos, daß das Spielerflugzeug stur bestimmte Aktionen vornahm, die zum Handlungsgeschehen nicht paßten. Möglich wäre es also, daß auch hier der Eingabepuffer für die verschiedenen Demos kaputt ist.

    Um herauszufinden, welche Methode nun tatsächlich im Spiel verwendet wird, müßte man sich wahrscheinlich die Tastatur-/Joystickbearbeitung anschauen. Dort müßte es ein Flag geben, welches Tastendrücke/Joystickbewegungen wahlweise in Echtzeit von der Hardware oder aus einem Puffer (mit Zeitzähler) übernimmt. Aber ob solch ein Aufwand sich jetzt wirklich lohnt...?

    Achja, Highscore Daten werden immer nach $0200-$02FF geladen. Du kannst dir ja vorstellen, dass das bei Kernalload auch Probeleme bereitet.

    Wie man sehen kann, habe die Coder des Games, Programmteile genau dahin gemacht, wo die Paramerter für $ffba und $ffbd stehen.

    Noch soeine Schote. Die Hauptinterrupt Routine des Spiels liegt genau dort, wo die Vektoren für die Getbyte Lade- und SaveRoutine stehen.

    Klingt nach einem guten Kopierschutz... ^^

    Übrigens, ist schonmal jemanden aufgefallen, dass alle gecrackten Versionen nicht richtig funktionieren?

    Oh ja.....

    Wow! Gratuliere!:verehr:Übrigens auch die erste mir bekannte Version, bei welcher die Demo einigermaßen funktioniert. Andere Versionen stürzten an der Stelle ab, oder die Demo hängte sich zu Beginn auf.

    Kleine Frage: Wird es auch eine Version geben für die normale 1541?

    Was ich auch eigenartig finde ist das ich in dem Video ausser dem vllt. etwas grossen Alien-sprite eigentlich nichts sehen kann was da jetzt den Beschleuniger brauchen sollte.

    Hmm... sieht für mich aus wie ECM-Modus oder Hires-Bitmap. Aufgrund der Farbänderungen beim Bewegen der Aliens würde ich vermuten, daß es sich nicht um Sprites, sondern um Shapes handelt, die entweder als Zeichen in den Zeichensatz oder als Bitmap-Shape in die Grafik kopiert werden. Das mag ein wenig aufwendiger sein, als Sprites zu verwenden, ist aber auch meiner Erfahrung nach noch lange kein Grund, deswegen einen Beschleuniger zu verlangen. Da gab es auf dem AppleII (nur Bitmap ohne Sprites) viel kompliziertere Spiele, die auch problemlos mit 1 Mhz liefen.

    Ansonsten sieht das Spiel ganz gut aus. Hiresgraphik ist ja bei C64-Spielen nicht so häufig vertreten. Da fällt solch ein Malstil natürlich besonders auf.


    Edit: Beim Ansehen des ersten Videos verwundert allerdings, daß in der alten Fassung die Scoreanzeige unten Multicolour-Zeichensatz ist, wohingegen in der neuen WIP3 auch hier Hiresgraphik verwendet wird analog zur Spectrum-Version. Desgleichen scheinen im alten Video die Aliens tatsächlich aus Sprites gebastelt zu sein. Inwieweit ist damit die WIP3 wirklich eine Weiterentwicklung?:gruebel

    Alles schön und gut, aber wie speichert man offiziell in 'Lode Runner'? Wenn ich das richtig sehe hat das Spiel 150 Level. Das spielt doch keiner am Stück durch. Die einzige Option, die ich gefunden habe ist ein 'Level advance', aber auch das springt immer nur ein Level weiter.

    Hat Lode Runner nicht die eingebaute "Eingabeaufforderung", mit der man einzelne Level gezielt auswählen sowie mittels Editor verändern kann? Oder gibt es dieses Feature nicht in der C64-Version?

    Aber was bitte meinst Du mit zweistimmig?

    Soweit meine Ohren hören können, beschränkt sich die Umsetzung von "Equinoxe 5" sowohl beim Titel als auch während des Spiels auf zwei SID-Stimmen: Bass und Melodie. (Die dritte dient im Spiel zur Erzeugung der Geräusche.) Beim Titel wäre es möglich, daß die Melodie gedoppelt ist, d. h. zwei SID-Stimmen spielen die gleichen Töne, wenn auch leicht zeitlich versetzt, was einen volleren Klang ergibt. NIchtsdestoweniger sind es mit Bass und Melodie nur zwei musikalische Stimmen.

    [Video]

    Das mag das Bild sein, was dein Board in den Upscaler (der mit deinem Board nichts zu tun hat) schickt. Was der dann rausschickt, sollte lupenreines Full-HD sein!!!!

    Keine Ahnung, was der Upscaler daraus macht. Ich habe keinen und werde mir auch keinen kaufen, da ich den FPGA nicht am Fernseher betreibe. Mit VGA kann man kein lupenreines Full-HD ausgeben. Soviel sollte doch wohl klar sein. Dafür braucht man einen HDMI-Anschluß. Wenn Du also lupenreines Full-HD haben willst, kannst Du das tun, indem Du Dir einen entsprechenden FPGA kaufst. Ist nur eine Sache des Geldes. Brauchst Du bloß im Netz zu bestellen.

    Noch einmal: VGA soll nur dabei helfen, eine HD-Auflösung auf einem VGA-Bildschirm softwaremäßig zu simulieren. VGA ist nicht dafür gedacht, an einem 16:9-Fernseher ein Full-HD-Bild zu erzeugen. Das kann es nicht und wird es auch nie tun.

    Das wäre seeeehr unbefriedigend. Damit könnte ich NICHTS anfangen.

    Aha. Also mit 320x200 kannst Du was anfangen, aber mit 320x180 nicht. Alles klar - oder auch nicht. Wird hoffentlich für Dich irgendeinen Sinn ergeben.

    "Deine" Auflösungen sind scheiße.

    Wenn Du denkst, daß das, was andere machen, scheiße ist, gebe ich Dir einen guten Tip: Mach es selber.

    Aber eigentlich brauche ich hier gar nicht weiter diskutieren, bis sich die Grafik-Problematik geklärt hat. Beim jetzigen Status Quo wäre ich hier ohnehin raus.

    Da sind wir uns ja einig. Ich bin hier raus.

    Oh Mann, Leute, Ihr schreibt hier so viel, daß man überhaupt nicht mitkommt...:gluck


    [I/O, Video]

    Danke für die vielen Beiträge und Beispielbilder zur Verdeutlichung. Allerdings habe ich den Eindruck, daß hier ein Mißverständnis vorliegt.

    VGA bedeutet das, was auch für den Commander X16 gilt:

    "at a fixed resolution of 640x480@60Hz"

    Das heißt, daß alle Bilder immer mit genau dieser Auflösung ausgegeben werden: 640 Pixel horizontal. Oder so wie es schon in den alten Schriften der heiligen VGA von Antiochia steht: "640 Pixel sind es, und bis 640 Pixel sollst Du zählen. Nicht 720. Auch nicht 576, es sei denn, Du zählst weiter bis 640. Die 1920 scheidet völlig aus."

    Das heißt, daß alle Bitmaps automatisch eine Breite haben von 640/320/160/80/40 Pixeln. Auch wenn man als Programmierer eine niedrigere Auflösung wählt, z. B. von 160, muß der Videocontroller dafür sorgen, daß daraus wieder 640 Pixel horizontal werden, denn das und nur das ist der Standard.

    Jedem steht es natürlich frei, von dieser Bitmap nur einen Teil zu verwenden und in den ungenutzten Pixeln der Bitmap einen beliebigen eigenen Rand zu malen, meinetwegen auch mit Blümchen oder Wölkchen. Aber es ändert nichts daran, daß das Bild, das an den Fernseher/Bildschirm geschickt wird, weiterhin ein Bild ist im Format 640x480. Was der Fernseher dann mit diesem Bild macht, ist allein seine Sache. Er kann es in die Breite ziehen oder schwarze Balken anzeigen oder sonstwas.

    Aus diesem Grunde würde ich RexRetro mit seiner Einschätzung recht geben, wenn er eine softwaremäßige Auflösung von 640x360 vorschlägt. DIese kann man später, wenn man über einen HDMI-Anschluß verfügt sehr leicht in HD (*2) oder FullHD (*3) umwandeln. Das hätte natürlich auf alten VGA-Bildschirmen den Nachteil, daß auf diesen dann ein großer schwarzer Rahmen oben und unten zu sehen ist, aber damit könnte ich vielleicht leben.

    Als einzige Möglichkeit für eine andere hardwaremäßige Auflösung sehe ich noch 640x400@70, da diese horizontal die gleiche Frequenz aufweist wie 640x480@60. Dann wäre auf einem VGA-Bildschirm der Rand etwas schmaler, aber dafür die Pixel in der Höhe gestreckt. Wie sich das auf eine Darstellung auf einem 16:9-Gerät auswirkt, und ob andere Geräte überhaupt in der Lage sind, diese Auflösung sauber zu erkennen, weiß ich nicht.

    So oder so handelt es sich bei einer VGA-Ausgabe um eine Übergangslösung bis wir alle über fette FPGAs mit eingebautem HDMI-Anschluß verfügen. Für eine Emulation spielt es sowieso keine Rolle, es sei denn man möchte auch am Laptop FullHD sehen.

    Von daher würde ich für die von RexRetro genannten Auflösungen plädieren, da sie mir nach einiger Überlegung noch am praktikabelsten erscheinen. Grundsätzlich gilt, daß man auch als Programmierer lieber mehr Zeichen in der Breite hat als in der Höhe. 80 Zeichen halte ich auch beim Programmieren für ein Muß. Die Anzeige des PICO-8 ist mir persönlich viel zu schmal. Was die Zeichenhöhe anbelangt, so hat RexRetro ebenfalls damit recht, daß es sich ja um einen Bitmap-Modus handelt und nicht um Zeichensatz. Es ist daher überhaupt kein Problem, einen Font von 7 oder 8 oder 9 Zeilen Höhe zu verwenden. Bei 360 / 8 hätte man 45 Textzeilen zu 8. Bei 180 / 8 ergäbe das 22 Textzeilen mit einem Rest von 4 Zeilen, die man für eine Umrandung etc nutzen könnte. Nebenbei wäre eine zusätzliche leere 9. Zeile zwischen den Textzeilen sogar ganz gut für eine bessere Lesbarkeit. Daher denke ich nun, daß man sich mit sowas arrangieren kann.

    Was meinen Videocontroller anbelangt, so ist bei diesem wie früher beim AppleII die Datenmenge pro Auflösung nicht stets gleich, sondern variabel. Der Apple//e kannte z. B.

    - 40x48 LowRes (ca. 1 kb)

    - 80x48 Double LowRes (ca. 2 kb)

    - 280x192 HighRes (ca. 8 kb)

    - 560x192 Double HighRes (ca. 16 kb)

    Das heißt in meinem Fall, daß man horizontal eine Auflösung auswählen kann von 40, 80, 160, 320 oder 640.

    Vertikal kann man auswählen aus 45, 90, 180, 360.

    Davon unabhängig ist die Anzahl der Farben: 2, 4 oder 16. Eine Farbpalette von 256 Farben würde ich ausschließen, weil ich sie a) nicht wirklich für Retro halte, und b) das Pixeln dadurch völlig anders wird (wie Retrofan oft beschrieben hat). Bei noch mehr Farben (HiColor 65536) kommt noch hinzu, daß die Datenmenge viel zu groß wird für a) die CPU, b) den Speicher, c) den Datenbus. Solche Auflösungen benötigen eine eigene Videokarte mit abgetrenntem Videoram. Das hat für meinen Geschmack dann überhaupt nichts retromäßiges mehr.

    Kurz: Nach letztem Stand der Dinge wären mögliche Auflösungen u. a.:

    - 640x180x2

    - 320x360x4

    - 40x45x16

    ...


    [Ram]

    Mein persönliches Design geht aus von 512 kb Ram. Das ist - wie Daybyter schreibt - die Menge an SRam auf dem Shield und zufällig das, was der Amiga500 auch hatte. Mehr Speicher wird man für einen Retrorechner eher nicht benötigen, da man heutzutage die Möglichkeit hat, sehr schnell neue Daten von SD-Karte nachzuladen (kein Vergleich zum 1541-Laufwerk aber auch den Diskettenlaufwerken des Amiga oder AtariST).

    Das Ram ist über einen 16 Bit-Datenbus angebunden (256x16). Ein breiterer Datenbus würde einen Haufen mehr Anschlüsse (Pins) am FPGA erfordern, die wir aber nicht haben. 16 Bit sind jedoch ausreichend, damit bei einer Auflösung von 640@16 Farben sich Videocontroller und Prozessor nicht zu häufig in die Quere kommen. Zur Erinnerung: Am Amiga500 bedeutete 640@16 Farben, daß der Prozessor um nahezu die Hälfte gebremst wurde.


    [Sprache. Zeileneditor]

    1.) Bitte keine Zeilennummern.

    2.) Bitte keine Zeilennummern.

    3.) Bitte keine Zeilennummern.

    4.) Bitte keine Zeilennummern.

    5.) Bitte keine Zeilennummern.


    Was habt Ihr gegen einen Texteditor? Warum wollt Ihr Euch mit einem Screeneditor herumquälen? :nixwiss: Als jemand, der damals[tm] seine ersten Programmierschritte auf dem AppleII mit UCSD-Pascal und einem Texteditor gemacht hat, fand ich diese Fixierung auf den umständlichen zeilenorientierten Screeneditor immer als etwas merkwürdig. Da auch sämtliche Assembler auf dem C64, die ich so kannte, diese krude Eingabemethode verwendeten, habe ich mir schon damals[tm] einen kleinen 80 Zeichen-Editor (virtuelle 80 Zeichen realisiert als scrollendes 40 Zeichen-Fenster) für die Assemblerprogrammierung gebastelt. Viel, viel leichter zu bedienen mit viel mehr Übersicht über die Programmstruktur. Von daher habe ich nicht vor, unter dieses Niveau von damals[tm] zu gehen. Ein Zeileneditor ist für mich persönlich komplett ausgeschlossen.


    [Sprache, Direktmodus]

    Die gleiche Frage wie beim Zeileneditor drängt sich auch hier auf: Wozu braucht man das? Um DOS-Befehle einzutippen? Ernsthaft? Auch das haben wir damals[tm] beim UCSD-Betriebssystem (von 1979!) schon mit einem simplen Menüsystem (genannt "Filer") gemacht: "L" für "List Directory". "C" für "Change fIle name" usw. Wozu soll man immer irgendwelche Befehle eintippen? Das war damals[tm] schon nerviger Blödsinn und allein den Tatsachen geschuldet, daß a) es kein Platz im Rom gab, um ein anständiges Menüsystem unterzubringen, b) der C64 gar kein Betriebssystem kennt, sondern jedes Gerät seine eigenen Befehle hat, die man (noch umständlicher) erst dahin schicken muß. Nicht ohne Grund haben damals[tm] schon zig Steckmodule diese Befehlstipperei abgelöst durch einfaches Drücken einer Funktionstaste. Will man wirklich davor zurückfallen? Also, wer's mag, kann sich ja sowas programmieren, den Sinn darin sehr ich allerdings nicht.


    [Sprache, Editor]

    Man erkläre mir bitte den Unterschied zwischen

    a) dem Tippen von "RUN" <RETURN>

    und

    b) dem Drücken auf die <F1>-Taste.

    Beide Male wird das aktuelle (im Editor vorhandene) Programm gestartet. Ob dazu gehört, daß es vorab tokenisiert oder gar vollständig kompiliert wird, ist dabei völlig egal. In beiden Fällen benutzt man die Tastatur, um das Programm zu starten, und einmal drückt man mehr Tasten und das andere Mal nur eine.
    Gerade wenn man Programmierer ist, wird man Methode b) nach einiger Zeit deutlich bevorzugen, weil einfach schneller und nicht so umständlich: Man tippt einen Text im Texteditor ein, drückt auf <F1>, das Programm wird gestartet, und am Ende kehrt man automatisch in den Editor zurück. Simpler geht es doch gar nicht. Wozu sich das Leben unnötig schwer machen?


    [Sprache, Interpreter/Compiler]

    Idealerweise wäre die Sprache geeignet sowohl für einen Interpreter auf der Zielmaschine zum unmittelbaren Entwickeln/Austesten als auch für einen Compiler z. B. als Cross-Compiler auf dem PC. Schließlich wurde auch damals[tm] schon Basic häufig (in Bytecode) übersetzt.

    Voraussetzung dafür aber ist, daß die Sprache

    a) an sich leicht übersetzbar/interpretierbar ist. D. h. es gibt nur wenige spracheigene Schlüsselwörter und Konstrukte. Grafikbefehle o. ä. sind keine sprachinternen Befehle, sondern können nach Belieben durch Bibliotheken ergänzt werden. Das setzt voraus, daß sie die gleiche Syntax aufweisen wie selbstdefinierte Prozeduren/Funktionen. (Gegenbeispiel Basic: Hier gibt es häufig einen Mischmasch von Klammern und Nichtklammern wie "line 0,0 to 279,191" und "chr$(13)" oder "sin(1234)".)

    b) keine Features aufweist, die sich nur per Laufzeit ergeben. Das "NEXT" in Basic ist so ein Fall. Der Aufwand für den Compiler, herauszufinden, auf welches FOR sich dieses NEXT bezieht, ist immens. Bitte nicht. Das kann man auch anders und besser lösen.

    c) Variablen haben einen festen Datentyp. Dieser wird deklariert, damit Interpreter und Compiler ihn in ihren Bezeichnerbaum eintragen können und sofort bescheid wissen, wie sie vorgehen müssen, wenn sie auf den Bezeichner treffen.


    Nebenbei: (Klassisches Retro-)Basic hat m. A. n. neben den Zellennummern noch ganz andere Nachteile:

    1.) Es gibt keine lokalen Variablen. Ganz schlecht für eine strukturierte Programmierung.

    2.) Es gibt keine Parameter bei Funktionen oder Prozeduren.

    3.) Es gibt keine Trennung zwischen INTEGER und FLOAT/REAL bzw. CHAR und STRING (sehr ungünstig fürs Kompilieren).

    4.) Es gibt keinen boolschen Datentypen.

    5.) Es gibt keine Verbundstrukturen.

    6.) Es gibt keine getrennten Namensräume und damit auch keine vernünftige Möglichkeit für eine Bibliothek.

    7.) Es gibt keine public/private-Markierung....

    Okay, an dieser Stelle sollte man besser aufhören, weil es einfach zu viele Dinge gibt, die es in Basic nicht gibt, aber für eine saubere und auch schnellere Programmentwicklung nötig wären.


    Einen Compiler direkt auf der Zielmaschine laufen zu lassen, halte ich nicht für unmöglich, aber eher unrealistisch. Vielleicht könnte man den VBCC-Compiler mit sich selbst kompilieren und dann auf der Zielmaschine zum Laufen bringen, doch vermute ich mal, daß er sich mit 512 kb nicht begnügen wird. Die Zwischensprache, auf der heutige Compiler aufbauen, braucht pro Node schon einen so großen Haufen Bytes, daß man mit einem nativen Compiler nur sehr kurze Programme übersetzen könnte. Generell halte ich es aber für eine gute Idee, den VBCC-Compiler als möglichen Sprachencompiler heranzuziehen, vorausgesetzt sein Erschaffer willigt ein.


    Da sich C jedoch als Interpreter- oder Einsteigersprache weniger gut eignet, hatte ich wiederholt eine Oberon-ähnliche Sprache vorgeschlagen. Sie ist einerseits Basic sehr ähnlich, andererseits aber mächtig genug auch für sehr große Programme. ZeHas Beispiel einer FOR-Schleife sähe darin z. B. so aus:

    FOR i := 1 TO 10 BY 2 DO

    ...

    END

    Nun kann man sich darüber streiten, ob es BY oder STEP heißen soll, aber daran sollte es eigentlich nicht scheitern, oder?

    Was die Machbarkeit anbelangt, so habe ich vor vielen Jahren solch eine Sprache bereits auf dem PC als Interpretersprache entwickelt. Das geht also. Wie hoch die Geschwindigkeit auf der Zielmaschine dann sein wird, kann man jetzt noch nicht sagen; ich gehe aber davon aus, daß es deutlich schneller wird als BASIC 2.0. Ein Schritt, den man auf jeden Fall vorher machen sollte, ist die vollständige Tokenisierung des Programmtextes, d. h. nicht nur Bezeichner werden in Tokens umgewandelt wie bei BASIC 2.0, sondern auch alle Konstanten (Zahlen, Zeichen, Strings...) Dabei kann je nach Aufwand auch eine Teilprüfung auf syntaktische Korrektheit ausgeführt werden, so daß diese beim Interpretieren wegfallen kann. Wenn also die Tokens bereits besser vorbehandelt sind als beim BASIC 2.0, dürfte bei einer ca. 8 Mhz-CPU (in Relation zum 68000) genügend Power da sein, um damit auch kleine Spiele schreiben zu können.


    [Rom]

    Generell gilt für Sprache, Betriebssystem usw., daß sich diese nicht im Rom befinden, sondern auf SD-Karte und damit beliebig austauschbar sind. Und ja, dieses Konzept gab es auch schon damals[tm], nämlich wieder auf dem AppleII, der sowohl DOS 3.3 (hauptsächlich für Basic) als auch das UCSD-System (für Pascal oder Fortran) oder ProDOS (für fortgeschrittene Applikationen o. ä.) booten konnte.

    Wichtig: Ein Flashrom hängt zumeist nicht direkt am Datenbus. Der Prozessor kann nicht direkt darauf zugreifen, um sich z. B. Befehle zu holen. Stattdessen ist das Flashrom über eine serielle Leitung (SPI) mit dem Rechner verbunden. Um darauf zuzugreifen, muß der Prozessor erst einen Befehl an das Flashrom senden und kann dann anschließend die Bytes Bit für Bit in Empfang nehmen. Aus diesem Grunde kopieren die Retrosysteme ihr "Rom" nach dem Einschalten in ein Ram. Ob man aber jetzt die Daten aus einem Flashrom lädt oder von SD-Karte, spielt keine Rolle. Das Booten wird dadurch nicht langsamer und bleibt genauso schnell wie beim C64, d. h.: Einschalten und da.

    Mein Vorschlag wäre daher:

    a) Ein kleines Autostartrom sucht nach einer SD-Karte als bootbares Medium.

    b) Ist eine SD-Karte mit speziellem Bootbereich vorhanden, wird letzterer geladen und gestartet.

    c) Wird kein bootbares Medium gefunden, kann aus dem Flashrom eine Ersatzdatei geladen werden, die dann gestartet wird.


    Noch einmal kurz zusammengefaßt:

    1.) Sowohl die Hardwarebasis (FPGA, Emulator..) ist letztendlich irrelevant.

    2.) Die Wahl der Sprache ist ebenso irrelevant. Es kann Basic geben oder Forth oder C oder Oberon...

    3.) Das Betriebssystem ist irrelevant. Es kann mehrere verschiedene Lösungen geben, einmal vielleicht eine Art CP/M oder andermal eher etwas wie GEOS.


    Das Einzige, was zählt, ist, daß es $irgendjemanden gibt, der diese Dinge entwickelt.

    Auf keinen Fall würde ich aber irgendeine Programmiersprache oder ein OS als verbindlich vorschreiben, weil es genau das ist, was mich an den PCs (oder Retrocomputern, die meinen, sie müßten sich so verhalten) nervt. Vielmehr soll jeder sich selbst eine Sprache/ein OS/einen Emulator/einen FPGA zusammenbasteln können. Vielfalt statt Einfalt. Das ist die Freiheit, die ich mit alten Retrorechnern verbinde, und die ich gerne wieder haben möchte. Darum geht es mir.

    [I/O] Bisher ist niemand von den technisch Versierten auf meinen Vorschlag eingegangen, das "Retro-Board" komplett vom "Modern-Board" mit den modernen Schnittstellen zu trennen, intern also "oldschool" (VGA, PS/2) zu reden und nur nach außen modern.

    [I/O] Ich muß gestehen, daß ich das nicht verstanden habe. Was willst Du wovon trennen? Was bedeutet hier innen und außen? Wenn Du meinst, daß der FPGA ein VGA-Signal erzeugt, welches später durch andere Hardware auf HDMI umgesetzt wird: Ja, das geht. Vielleicht gibt es auch einen Konverter für PS/2-Tastatur und USB-Tastatur. Bin kein Techniker und kenne sowas nur von meiner alten Maus. So oder so: Wenn der FPGA den VGA-Standard 640x480 erzeugt, wird daraus auch nach der Umwandlung nur 640x480. Andere Auflösungen, die sich an HD orientieren, sind für VGA bzw. den Konvertern "krumm", d. h. es kann passieren, daß diese als nichtkonforme Auflösung verweigert werden und die Anzeige dunkel bleibt. Und zuletzt bringt anderes VGA-Timing bei anderen Auflösungen das interne Timing des FPGAs kompletet durcheinander. Zur Zeit arbeiten die Schaltungen im FPGA (Video, Prozessor, Tastatur, SD-Karte, Audio) auf Grundlage eines 50 Mhz-Taktes. Eine von 640 abweichende VGA-Auflösung würde einen anderen Takt verlangen mit Auswirkungen auf alle anderen Module.

    [I/O] Was tut eigentlich der von mir hier verlinkte, aktive Adapter von USB-Gerät auf PS/2-Buchse?

    [I/O] Hast Du den Link noch irgendwo? Ich kann ihn nicht mehr finden.

    Kann man also sagen, ohne das überprüft zu haben, Bluetooth wäre noch schlimmer?

    Ob "schlimmer" oder "ein bißchen weniger schlimm" spielt keine Rolle. Der Aufwand ist in beiden Fällen sehr groß-

    BlueTooth und USB sind anders als z. B. ein Joystickanschluß. Es reicht nicht aus, einzelne Bits auszuwerten, um zu sagen: Jetzt wird der Joystick nach oben bewegt" oder "jetzt wird der Button gedrückt". Beide verhalten sich so wie HTML zu Ethernet. Um im Internet surfen zu können, reicht es auch nicht aus, einfach nur das Kabel in den Rechner zu stecken. Dazu gehört, daß es im Rechner ein Programm gibt, welches in der Lage ist, Internetpakete zu senden und (geordnet) zu empfangen. Und darauf aufbauend bedarf es noch eines Browsers, der die Inhalte der Datenpakete passend interpretiert als z. B. ftp oder http. Für letzteres z. B. ist notwendig, daß der Browser die Sprache html mit ihrer Syntax und den Schlüsselwörtern versteht, um daraus dann die eigentliche Seite aufzubauen. Mit USB oder BlueTooth ist es ähnlich, wenn auch nicht ganz so schlimm. Auf unterster Ebene muß zunächst mal dafür gesorgt werden, daß überhaupt eine Kommunikation stattfindet. Hier können bei BlueTooth z. B. gesonderte Chips helfen. Aber früher oder später kommt die Ebene, in der man die empfangenen Daten interpretieren muß (also ftp oder html beim Internet). Dazu muß man aber erst einmal wissen, wie die Syntax aufgebaut ist, welche Befehle es gibt, und was die genau bewirken. Und dann muß man daraus irgendwie eigenen Code entwickeln, der das alles leistet.


    Und jetzt stell Dir mal vor, dies sollte ein neuer 8 Bit-Rechner schaffen... Unmöglich. Allein der Code, der dafür notwendig ist, sprengt die 64 kb des Homecomputers, abgesehen davon, daß er zu langsam ist für die Kommunikation.


    Und jetzt stell Dir mal vor, dies sollte ein neuer 32 Bit-Rechner schaffen. Nicht ganz unmöglich, aber zu welchem Preis? Man braucht auch hier zusätzliche Mengen an Speicher und Code, nur um das USB-Protokoll zu bedienen. Das wiederum bedeutet, daß es ein Betriebssystem geben muß, welches die Daten rechtzeitig (per Interrupt) übernimmt und auswertet. Und das ist der Todesstoß für jede bare metal-Programmierung, wenn stets im Hintergrund ein OS mitlaufen muß, welches Dein Programm unterbricht wann und wie es will, nur um eine Taste in Empfang zu nehmen oder zu wissen, ob ein Button an einem Controller gedrückt wurde.


    Abgesehen davon ist ebenso eine Voraussetzung dafür,

    a) daß die Art und Weise, wie die Geräte kommunizieren, offen einsehbar ist, d. h. die Herstellerfirmen stellen freiwillig im Internet die Informationen zur Verfügung, wie ihre Geräte funktionieren, und verdongeln diese stattdessen nicht mit ihrem Treiber,

    b) daß es eine oder mehrere Personen gibt, der/die ohne Bezahlung den Fulltime-Job übernehmen und in monatelanger Arbeit eigene Treiber schreiben.


    Kurz: Selbst wenn es für einige Sache vorgefertigte (Chip)Lösungen gibt, bleibt es ein enormer Kosten- und Zeitaufwand.


    Eine gängige Lösung ist daher, daß der Rechner aus zwei Rechnern besteht: a) die Zielplattform (der Retrorechner) und b) ein ARM mit einem Linux(artigem) System, welches die USB-Kommunikation übernimmt und nur noch das fertige Ergebnis an den Retrorechner sendet. Das Verhältnis zwischen Retrorechner und ARM ist jedoch ungefähr so, als hätte man Steve Wozniak damals[tm] gesagt: "Okay, dein Apple-Rechner ist ja ganz in Ordnung, aber das mit der Tastatur, das geht so nicht. Dafür mußt du deinen Apple an eine Cray anbinden."

    [I/O] Die Frage ist, ob man das muss. Müssen tut das ja meistens nur der Erste, der so etwas machen will. Wären wir "der Erste?"

    [I/O] Die Allerersten. Selbst wenn man - wie gesagt - teilweise auf vorgefertigte Chips zurückgreifen kann, die einen Teil der Arbeit übernehmen (z. B. Codierung für die BlueTooth-Übertragung), bleibt es am Ende ein Riesenaufwand. Frage: Warum verwendet auch der Commander X16 nur PS/2-Tastaturen und VGA? Antwort: Genau deswegen.

    Die Frage ist eher, ob man auf dem großen Fernseher kantenscharfe Retro-Pixel sehen will

    [Video] Wäre dafür. Warum soll man sich verwaschene Bilder angucken? Nur weil die Qualität der Bildschirme damals[tm] schlecht war? Gerade, wenn man auch mal irgendwie Text schreiben will, braucht man eine saubere Darstellung.

    Mögliche native Auflösungen hatte ich ja schon zur Genüge genannt

    [Video] Da das FPGA zunächst nur die Standard-VGA-Auslösung 640x480 erzeugt, müßte man alle anderen Auflösungen da reinpressen. Wenn danach noch die VGA-Auflösung an einen HD-Bildschirm ausgegeben wird, hat man lustige, dicke schwarze Balken überall. Und ja, im Prinzip hätte ich auch gerne einen 16:9-Bildschirm bei entsprechend aufgelöster Grafik. Geht aber zum jetzigen Zeitpunkt leider nicht.

    einen zweiten günstigen FPGA

    [FPGA, Video] Daybyter hatte ja schon gepostet, was so ein billiges Board mit HDMI kostet. Das wäre einfacher und wohl auch günstiger als zwei FPGAs zu nehmen, die auf einem speziell dafür gemachten Motherboard sitzen. Man muß sich dann aber von dem Gedanken verabschieden, daß sowas mit 50 € zu machen ist.

    Dieser letzte Kollege sagt, dass er eine HDMI Ausgabe hat? Das überrascht mich jetzt mal...

    In der Tat. Das wäre eine tolle Leistung. Leider gibt es keinen Link auf den Source.

    Ich muss immer daran denken, wie lange es gedauert hat, bis Linux einen halbwegs stabilen stabilen USB Stack hatte. Also wenn ihr das selbst schreiben wollt, dann wird das allein wohl etliche Monate brauchen.

    Würd ich mir nicht zumuten wollen.

    USB Protokoll ist schon die Hölle... Das kann bare metal also ohne große etablierte Bibliotheken anderer quasi vergessen wenn damit halbwegs die Mehrheit der Tastaturen laufen soll. Dass man da auf PS2 geht verstehe ich sofort.

    Ja, so ist das, aber was nutzt es? Man kann es zigmal im Thread schreiben, aber ein paar Seiten später heißt es dann wieder "ein heutiger Rechner muß unbedingt USB haben". :/