Posts by M. J.

    <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". :/

    für 75$ könnte schon mehr Sinn machen. 32 MB SDRam, SD Karten Interface und noch IO Pins für ps/2 z.B.

    Alles schön und richtig, doch die Anforderungen sind ja noch viel höher. Es muß auch USB sein für Tastatur und Keyboardcontroller, und dafür braucht man noch einen ARM onboard, der die Kommunikation mit den USB-Geräten übernimmt. Das läuft am Ende auf einen MiSTer hinaus. Nichtsdestoweniger denken einige dann immer noch, daß man so einen Rechner für 50€ bekommen kann... :/

    Jetzt kommt immerhin die Meldung

    "DOS Error: @".

    Bei Autostart Einstellungen Häkchen machen bei

    - Behandle präzise Floppy-Emulation

    und bei PRG Autostartmodus "DIsk Image" auswählen.


    Bei Floppy Einstellungen btte nur Radiobutton auswählen bei

    - 1541-II

    - Nie erweitern

    - Trap idle

    und keine Erweiterungen oder Parallel Kabel


    Läuft es dann?

    wie bekommt man 'Giuild of Thieves' im Vice [..] zum Laufen?

    Ein Häkchen bei "Einstellungen->Floppy Einstellungen->Präzise Floppy Emulation"

    Kein Häkchen bei "Einstellungen->Virtuelle Geräte Traps"

    Kein Häkchen bei "Einstellungen->Peripherie Einstellungen" (neues Fenster) "Laufwerk 8->IEC Gerät aktivieren"

    Hatte ich schon mal vor 'ne Weile hier im Forum gepostet.

    Hat aber keiner angebissen ;-\

    Hatte es mir angesehen, konnte aber den großen Vorteil dieser MMU für einen 8-Bitter nicht erkennen. Auch das komplizierteste Bankswitching kann den engen Adreßraum von 65536 Adressen für den Direktzugriff nicht aufheben. Je kleiner die Segmente sind, die in den Adreßraum eingeblendet werden, umso schwieriger wird zudem die Umrechung einer größeren Adresse.

    Nehmen wir an, man möchte auf eine 24 Bit-Adresse zugreifen. Dafür muß über die MMU oder ein sonstiges Bankswitching (s. auch Mega65) ein bestimmter Teil des erweiterten Rams in einem Fenster erscheinen. Wenn das Fenster z. B. 4 kb groß ist, geben die untersten 10 Bits die Position im Fenster an und die anderen 14 Bits die einzublendende Bank. Diese 14 Bits werden in das Bankregister/die MMU für ein bestimmtes Fenster geschrieben. Da der 6502 nur 8 Bits schreiben kann, müssen sie wiederum aufgeteilt werden auf 8 und 6 Bits. Danach muß man sich noch einen Zeiger basteln aus den unteren 10 Bits, der auf die Position im Fenster zeigt, und dann endlich kann man den eigentlichen Wert laden/schreiben. Ein MMU-System kann zwar als Grundlage dienen für ein Multitasking-Betriebssystem, sofern man sowas mit einer 1 Mhz CPU wirklich benutzen will, es macht aber die Verwaltung von externem Ram nicht leichter.

    In dieser Hinsicht finde ich die Lösung beim AppleII ganz brauchbar: Externes Ram wird jeweils in den gesamten normalen Arbeitsspeicher eingeblendet. Aus historischen Gründen ist hierbei der Bereich von $c000..$ffff ausgenommen, da sich dort der IO-Bereich und das Rom befindet. Zum normalen Arbeitsbereich gehören somit die Adressen $200.. $bfff. Die ersten beiden Speicherseiten wurden bewußt ausgelassen, weil sich dort die Zeropage und der CPU-Stapel befinden. Außerdem wird unterschieden zwischen Lese- und Schreibzugriffen, d. h. man kann den Arbeitsspeicher fürs Lesen auf $10200..$1bfff schalten und fürs Schreiben auf $00200.. $0bfff. Besser wäre es noch, wenn die Lesezugriffe des Prozessors ebenfalls gesondert eingestellt werden könnten. Da dies beim AppleII nicht funktioniert, werden Zugriffsroutinen auf den externen Speicher entweder im Bereich $d000..$dfff oder $0..$1ff angesiedelt. Nebenbei: Dieser Bereich kann ebenfalls umgeschaltet werden mit einem weiteren Schalter.

    Der externe Speicher wird nun ausgewählt, indem man die obersten 8 Bits der 24 Bit-Adresse in das Auswahlfenster schreibt. Die unteren 16 Bits bilden dann wie üblich den Zeiger auf die Speicherstelle. Nachteil beim AppleII: Man kann nur 47,5 KB des externen Speichers als einen durchgehenden Bereich einblenden. Bei einem anderen Rechner könnte man es aber auch so halten, daß z. B. lediglich der Bereich von $000.$3ff ausgenommen ist und die Transferroutinen enthält. Am allerbesten wäre es jedoch, wenn wie gesagt Befehlszugriffe getrennt werden könnten von normalen Lese- und Schreibzugriffen, denn dann wäre es egal, an welcher Stelle im Ram sich die Transferroutine befindet. Letztendlich lassen sich aber auch damit Strukturen > 64 kb nicht wirklich gut ansprechen. Dafür braucht man dann einen Prozessor mit größeren Zeigern, sei es als Zeiger in der Zeropage oder gleich als Adreßregister (eines 32 Bit-Prozessors). Das System des 65816 mit seiner Bankauswahl ist hingegen auch nicht wirklich optimal.

    Robocop 3: Man kann den Hintergrund der Textzeile ohne Halte-Farbe darstellen und dann den Text drüberkopieren. Das Alpha-Blending (Das ist doch der gerasterte Zaun?) bekommt man ggf. sogar besser realisiert weil die Farbe des Zeilenabschnitts ja noch in der Liste geändert werden kann und noch nicht final auf dem Bildschirm ist.

    :nixwiss: Ich meinte das 3d-Spiel "Robocop 3" von Digital Image Design. Im dritten Level "Police Strike" wird zum einen viel Text über die 3d-Graphik eingeblendet. Drückt man z. B. direkt nach de Start <F9> sieht man zum anderen das Polizeiauto mit rot und blau blinkendem Licht. Das blinkende Licht wird dadurch erzeugt, daß ein Kreis gemalt wird, in diesem Kreis jedoch nur abwechselnd jedes zweite Pixel auf rot bzw. blau gesetzt wird in der Form

    Code
    1. x x x x
    2. x x x
    3. x x x x
    4. x x x

    Auf diese Weise kann man teilweise noch durch den Kreis hindurchgucken, was halt eine Art "Alphablending" darstellt.

    Vielleicht gibt es ja auch genug Farben dann muss man sich keine zusammenrastern.

    Vielleicht gibt es ja ne Char-Plane als Overlay.

    Vielleicht gibt es ja auch Sprites.

    Wenn es genug Farben gibt, z. B. 256, wird man wahrscheinlich eh drüber nachdenken, ob man nicht mit Texturen arbeitet oder Phong Shading. Dann wäre der Rechner aber eigentlich auch kein Retrorechner mehr im Stil der 80er, sondern der 90er. Gleiches gilt für Char-Plane als Overlay.

    Los gib dem Modus ne Chance ...

    Habe nichts dagegen, den Modus mal auszuprobieren, aber wer schreibt dafür den Emulator?

    Die ISA.

    Für die ISA hatte ich vor einiger Zeit ein PDF-Dokument erstellt. Das ist aber nichts hier zum Posten. Ich schau mal, daß ich eine Zusammenfassung der wichtigsten Eigenschaften in Kurzform zusammenstelle.

    "Rechner, auf dem man auch in einer BASIC-artigen Sprache ein nettes Arcade-Spielchen programmieren koennte, auf dem man aber insgesamt komfortabler unterwegs sein kann als in den 80ern und der sich an eine Zielgruppe richtet, die sich gerne in einem retro-artigen Rahmen das Programmieren beibringen moechte".

    Eine Architektur in diese Richtung fände wahrscheinlich vom Spaßfaktor her die größte Zielgruppe, zumal ein Hardwarenbasteln und -frickeln gar nicht ausgeschlossen wird, anders als bei einer Supermegaspielmaschinenkonsole.

    nur sagen, dass es für viele Spiele extrem wichtig wäre, DASS es funktioniert

    Genügend Prozessorpower vorausgesetzt kann man auch Scrolling in Software erledigen. Auch der AppleII hatte Spiele, bei denen gescrollt wurde, aber nur Bitmap und keine Scrollregister. Das ist ja gerade der Punkt: Es wird Hardware vorausgesetzt ohne zu wissen, ob sie überhaupt notwendig ist. Warum nicht erst einmal ganz leicht anfangen, schauen, wie weit man kommt, und dann - wenn es wirklich nicht anders geht - auf Hardwareerweiterungen setzen? Aber eben irgendwann einmal anfangen und nicht vorab schon irgendwelche Hardware bestimmen.

    Und du bist z. Z. der einzige, der daran sitzt

    Wie ich schrieb, gibt es noch jemanden, der an einem 8 Bit-System arbeitet. Wie weit das gediehen ist, kann ich aber nicht sagen. Aber auch wenn es zwei sind, ist das viel zu wenig. Damit wirklich ein gutes Ergebnis herauskommt, braucht es mehr Entwickler, die sich hinsetzen und mal Sachen ausprobieren und nicht nur reden.

    Was hattest du erhofft? Das sich unaufgefordert 3 andere auch ein FPGA-Board besorgen und damit parallel etwas machen?

    Nein, natürlich nicht. Nichts derartiges, zumal ich wiederholt klar gesagt habe, daß ein FPGA nur eine Umsetzung von vielen ist. Das FPGA-Board nehme ich für mich persönlich, weil ich Verilog lernen will, und weil das Herumspielen mit einem FPGA generell Spaß macht. FPGA ist keine Voraussetzung für eine Rechnerarchitektur.

    Ich hatte nicht mitbekommen, dass du irgendwelche Erwartungen (an wen auch immer) hattest. Hattest du irgend etwas gefragt, auf dass es keine Antwort gab oder einen Aufruf getätigt, dem niemand gefolgt ist? Haben wir da irgendwas überhört?

    Eine Rückmeldung wäre z. B. eine Frage, welcher Befehlssatz die CPU hat. Wie der Grafikcontroller organisiert ist. Wie die Tonerzeugung funktioniert. Wie man die SD-Karte anspricht. Irgendeine Rückfrage halt. Oder auch: "32 Bit ist für mich zu viel. Ich gehöre zu der 8-Bit-Gruppe." Dann könnte man vielleicht mal die verschiedenen Ansichten bündeln anstelle wild durcheinander mal dies mal das zu fordern. Null Reaktion heißt tatsächlich null Reaktion. Kein Interesse an einer realen Umsetzung, sondern einfach nur weiterreden.

    Auch die C64-Entwickler wussten ab einem bestimmten Punkt, ob das Ding eine Spielkonsole oder ein Computer (mit Tastatur) oder ein Rasenmäher werden sollte

    Sollte nicht nach 53 Seiten endlich mal feststehen, daß es sich um einen Retro-Rechner handelt und nicht um eine Spielkonsole? Müssen wir darüber jetzt noch wirklich diskutieren? Mal ehrlich, die Entscheidung ist dermaßen trivial, daß man sie seit 53 Seiten voraussetzen sollte.

    Wenn es dich stört, dass es um EINE Hardware-Form bei den Diskussionen geht, denk dir einfach, es ginge um die ERSTE zu realisierende Hardware-Form.

    Es geht weder um die EINE Hardware-Form noch um die ERSTE Hardware-Form. Beides existiert nicht. Hardware ist irrelevant. Wichtig ist die Definition der Architektur. Die muß sich nach dem strecken, a) was Emulatoren und FPGAs leisten können. Da kann man sagen, daß eine normale Retroarchitektur von heutigen Rechnern bzw. FPGAs abgebildet werden kann. b) was für eine Architektur im Retrostil sinnvoll ist. Also keine 256 Sprites, Dualplayfield-Supergroße-Kacheln, sondern am besten klein anfangen mit einfacher Bitmap.

    Es macht keinen Sinn, jetzt darüber zu philosophieren, ob und vielleicht wie sich eine bestimmte Definition in Zukunft auswirken kann, wenn a) diese Definition überhaupt nicht existiert, b) diese nichtexistierende Definition nicht in irgendeine brauchbare Form umgewandelt wurde. Die wahren Beschränkungen lernt man nämlich erst dann kennen, wenn man etwas in der Praxis austestet. Aber davon sind wir hier melienweit entfernt. Die Geschichte der Hardwareentwicklung zeigt doch genau das immer wieder und wieder: Man beginnt ein Projekt, stellt dann fest, daß irgendwas nicht so richtig funktioniert, und ändert es dann. Aber man beginnt das Projekt zuerst einmal. Es gibt doch noch nicht einmal einen einzigen Benutzer dieses nichtexistierenden Systems. Warum soll man sich Gedanken machen, daß ein nichtexistierender Benutzer eines nichtexistierenden Rechners Probleme mit einer nicht existierenden nachträglichen Hardwareänderung bekommt?

    Letztlich entscheidet aber diese erste Form, ob es überhaupt weitere geben wird

    Bei einer offenen Architektur gibt es keine erste und auch keine letzte Form. Jeder kann sie für sich umsetzen, wie er/sie will. Es geht nur darum, daß die Definition eingehalten wird. Wie die Umsetzung real aussieht, spielt keine Rolle. Das System ist zuallerst nur eines: virtuell. Aber ich merke halt, wie sich viele an die Vorstellung einer Hardware klammern. Das mag bei einem Mega65 der Fall sein, weil er ja dem C65 nachempfunden ist. Das mag beim Foenix der Fall sein, weil er von einer Hardware-Ingenieurin entwickelt wurde, die für sich eine bestimmte Hardware bauen wollte. Diese Hardwareverflechtung muß aber nicht so sein. Im Gegenteil wäre es besser, wenn sie nicht mehr vorhanden ist. Denn dadurch wird die Umsetzung einfach flexibler und leichter.

    Und dass es von dem Rechner mindestens eine Software- (Emu) und eine Hardware-Version geben soll, da waren wir uns eigentlich immer einig

    Ja, weil es z. B. für die Softwareentwicklung von Vorteil ist. Waren wir uns aber auch darüber einig, daß man z. B. eine Hochsprache einfach mal in einer anderen Hochsprache schreiben kann? Wie oft wurde gesagt: "Auf dem Rechner soll es diese oder jene Hochsprache geben." Möchte man aber eine Hochsprache haben, muß man sie definieren und dann dafür einen Interpreter/Compiler schreiben. Dafür braucht man den Zielrechner nicht. Das kann man auch auf dem PC. Insofern hat ZeHa hier genau den richtigen Schritt gemacht. Leider ist er hier der Einzige, der sich mal wirklich Gedanken gemacht hat, wie sowas aussehen kann und es auch in der Praxis ausprobiert.

    Bei anderer Software wie Texteditor oder Betriebssystem verhält es sich nicht anders. Wenn man ein OS haben will, muß man es schreiben. Man muß es aber nicht auf dem Zielrechner schreiben. Man kann es auch erst einmal abstrakt in C, C++, Java, Python, Ruby, Schlagmichtot auf dem PC entwickeln. Wichtig ist, daß man ein praxistaugliches Konzept entwickelt. Wie sieht es hier aus? Fehlanzeige.


    Das ist, was mich an dieser ganzen Diskussion stört: Die wirklich wichtigen Sachen werden nicht besprochen und kaum einer macht sich mal die Mühe, irgendwas real umzusetzen. Für ein OS oder eine Hochsprache ist es ziemlich unerheblich, ob eine Auflösung 240x192 oder 386x512 oder sonstwas ist. Aber sie sind die wichtigen Kernpunkte, an die man ran muß, wenn man eine Architektur auf die Beine stellen will.

    auf deinem FPGA nicht so einfach umsetzen konntest

    Was ich mit meinem FPGA umsetzen kann, ist irrelevant. Was ich persönlich umsetzen kann, ist irrelevant. Kurz: Ich bin hier völlig irrelevant. Wichtig ist, daß es eine Definition gibt einer zunächst virtuellen Maschine, die sich jeder auf seine Weise zusammenstricken und ausprobieren kann. Dann kommt die Diskussion, was man besser machen könnte.

    Ein bisschen "in Stein gemeißelt" klang das schon.

    Tut mir leid, wenn das so rübergekommen ist. Da habe ich mich wohl falsch ausgedrückt. Tatsächlich gehe ich vom Gegenteil aus. Die Beschränkungen, die ich meine, beziehen sich jetzt auf einen bestimmten temporären Status einer möglichen Umsetzung. Sprich: Mit meinen Mitteln kann ich bei einem FPGA die von Dir genannten HD-Auflösungen nicht realisieren. Das heißt aber nicht, daß sie deswegen generell nicht möglich sind. Ich habe den Bedarf danach sehr wohl erkannt und bin auch gerne bereit, mich darauf einzustellen und z. B. diese an einem Emulator mal auszutesten. Nur mit meiner FPGA-Hardware läßt es sich nicht umsetzen.

    war aber wohl schon zu spät.

    Noch ist gar nichts zu spät. Wir haben ja nicht einmal eine feste Definition einer virtuellen Architektur. Noch existiert gar nichts. Aber man könnte ja endlich mal eine Definition erstellen, diese so gut es geht umsetzen und dann schauen, was es bringt.

    auch weil die wenigsten hier dir wirklich helfen könnten

    Es geht nicht darum, ob mir jemand helfen kann. Ich kann mein Projekt auch ganz alleine durchziehen. Habe ich schon oft genug gemacht. Es geht darum, daß andere Leute mal konkrete Konzepte entwerfen für z. B. eine Hochsprache und diese in irgendeiner Form austesten. Davon können alle anderen profitieren. Merke: Das Commodore Basic kam auch von Microsoft. Das wurde nicht im Hause Commodore kreiert.

    Sorry, wenn ich darüber nachdenke, wie denn überhaupt die Grafik auf so einer Kiste aussehen könnte – ich dachte, wenigstens DAS wäre Teil MEINES Jobs, wen ich schon nicht beim Coden oder Löten helfe.

    Ist doch alles in Ordnung. Die Überlegungen sind gut und richtig, aber man darf sie nicht als Grundlage nehmen für eine Entwicklung eines bestimmten Systems. Eine Entwicklung sollte viel mehr so wie eine Baumwurzel aussehen. Es gibt einen Wurzelansatz CPU. Darum kümmern sich diejenigen, die Spaß am CPU-Design haben. Dann gibt es einen Ansatz Sound. Das können die Leute machen, die sich mit Tonerzeugung auskennen. Andere entwerfen vielleicht ein Gehäuse, wieder andere kümmern sich um Farbpaletten und Auflösung. Am Ende wächst diese Wurzel zusammen zu einem einzigen Baum, der virtuellen Maschine mit bestimmten Definitionen. Und aus diesem Stamm entwickeln sich dann die verschiedenen Umsetzungen (FPGA, Emulator...)

    Das Problem, das ich hier immer wieder sehe ist, daß vorausgesetzt wird, daß der Stamm komplett existiert, bevor man sich daran macht, sich mit den einzelnen Wurzeln auseinanderzusetzen. Oder man konzentriert sich nur auf eine Wurzel (Videochip), weil sie so schön anschaulich ist, und übersieht dabei alle anderen Aspekte.

    Ich denke, es ist das, was Daybyter meinte mit den Modulen: Jeder Wurzelansatz entspricht einem Modul. Jedes Modul kann für sich auf mehrere Arten entwickelt werden. Welche davon am Ende zu einem Stamm zusammenwachsen, muß zum jetzigen Zeitpunkt überhaupt nicht entschieden werden. Aber das Modul, das muß erst einmal existieren. In der Hinsicht sieht es nach 53 Seiten immer noch trübe aus, sowohl in bezug auf Software als auch Hardware.

    Nichts von dem, was hier (zumindest von der interessierten "Kernbelegschaft") besprochen wurde, dürfte sich gegen das richten, was du so parallel anstellst.

    Wäre mir auch ziemlich egal. :P Aber ernsthaft: Wäre es nicht vielleicht sinnvoll, dem Thread ein bißchen mehr Struktur zu geben und z. B. mal Module zu bestimmen, über die dann ein wenig sauberer getrennt diskutiert werden kann? Man muß ja nicht gleich für jedes Modul einen eigenen Thread starten (halte ich für keine gute Lösung). Doch es könnte u. U. helfen, wenn man die wichtigsten Definitionen festhält, daraus Unterbereiche (Module) ableitet und Posts beim Schreiben danach kennzeichnet, z. B. "[Grafik]". Sowas in der Art. Nur so als Vorschlag...