Neuer Retro-Computer im 8-Bit Style

Es gibt 1.853 Antworten in diesem Thema, welches 267.549 mal aufgerufen wurde. Der letzte Beitrag (12. April 2024 um 17:24) ist von Retrofan.

  • Ansonsten finde ich es uebrigens auch wichtig, dass man sich Gedanken macht, ob wirklich unbedingt alles "verbessert" werden muss.

    Genau das ist ja hier seit Anfang an Thema. Nein, es muss nicht alles verbessert werden im Sinne von höher, weiter, schneller. Und ich habe noch nicht einmal was dagegen, wenn man Features verschlechtert – Commodore hat ja auch beim Plus/4 die Sprites und das Scrolling weggelassen (es gibt also dafür Beispiele in der Geschichte). Wie gut andere damit klar kämen, weiß ich aber nicht.

    Denkbar waere natuerlich auch ein 640x480-Modus aber dafuer nur Monochrom, oder nur mit wenigen Farben. Diesen koennte man dann z.B. fuer den Code-Editor nutzen, oder fuer simple Anwendungen, waehrend Spiele dann doch eher in 320x240 oder 256x192 oder sonstigem laufen wuerden.

    Ganz ähnlich sehe ich das auch. Wir haben hier bisher nur über die Spiele-tauglichen Grafik-Modi gesprochen und sind da bei 320 x 200 Pixel (maximal) gelandet. Aber es sollte einen zusätzlichen 80-Zeichen-Modus geben – eben für Editoren und manche Anwendungen.

    Das sind ja fast CPC Farben.

    Bitte keine persönlichen Angriffe hier. ;)

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • Keine (rosa) Hautfarben und statt dessen Lila :wink: Das erinnert schon an CPC.

    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

  • Du pixelst ja meistens "flat", während ich zu denen gehöre, die sehr viel mit Helligkeitsverläufen und Schattierungen arbeiten. Ich guckte da weniger auf einzelne hübsche bunte Farben, sondern darauf, möglichst viele gute Abstufungen hinzubekommen. Da ist der C64 grundsätzlich besser aufgestellt als die meisten anderen Systeme (mit kleiner Palette). Braun würde ich bei deiner Palette schmerzlich vermissen – wie soll ich z.B. Bäume oder manche Tiere pixeln? Ich habe ja sogar noch die Natur-Farben um das zusätzliche Grün verstärkt, weil es mir so oft fehlte (und ich pixele nun wirklich nicht nur Wald-Szenen, wie man jetzt vielleicht meinen könnte). ;)
    Hier zeigt sich jetzt aber ein "Problem" bei einer festen Palette. Der, der sie vorgibt, definiert den Output-Style merklich mit. Bei einer Auswahl-Palette ist das natürlich weniger der Fall – aber wie gesagt: es bestände die Gefahr, dass es am Ende gar keinen typischen Output gäbe und die Darstellung verhältnismäßig beliebig aussähe.

    Ja da hast Du vollkommen recht, wie gesagt es war auch noch nicht als "final" anzusehen. War alles noch in nem recht fruehen Stadium und ich wollte das so nach und nach sich entwickeln lassen. Was braun und orange angeht, sind wir aber vermutlich auch vom C64 etwas verwoehnt, viele Rechner aus der Zeit haben sowas ja nicht. Trotzdem ist es natuerlich richtig, dass sowas dann einem irgendwie "fehlt". Auf der anderen Seite finde ich z.B. solche "technischen" Paletten wie beim Spectrum auch nicht ganz verkehrt (nur vielleicht etwas weniger LSD-maessig). Das unterstreicht dann wieder den "ich bin halt ein alter Computer"-Faktor :)

    Was das Gruen angeht, gebe ich Dir auch recht, ein dunkleres Gruen fehlt mir auf dem C64 manchmal auch. Auf der anderen Seite sind 3 Gruen-Toene halt auch schon wieder recht viel, wenn man insgesamt nur 16 Farben hat.

    @ Hautfarbe / CPC: Da gibt es in meiner Palette ja immerhin ein rosa und ein orange zur Auswahl.

    - neue Spiele für den C64 -
    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.

  • Hier uebrigens mal eine Auflistung von existierenden Projekten, von denen ich mal gehoert habe. Vielleicht in irgendeiner Form interessant zur Inspiration:

    Uzebox: Bitte melde dich an, um diesen Link zu sehen.
    BASIC Engine: Bitte melde dich an, um diesen Link zu sehen.
    Arduino BASIC PC: Bitte melde dich an, um diesen Link zu sehen.
    Amigo Computer: Bitte melde dich an, um diesen Link zu sehen.
    AVR BASIC Computer: Bitte melde dich an, um diesen Link zu sehen.

    - neue Spiele für den C64 -
    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.

  • Celeste ist auf einem Pico8 programmiert. Das ist ein Computer der 80er, den es nie gegeben hat.

    ...und der auch nicht aus den 80ern ist

    - neue Spiele für den C64 -
    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.

  • Auf der anderen Seite finde ich z.B. solche "technischen" Paletten wie beim Spectrum auch nicht ganz verkehrt

    Ich bin da kein Freund von. Und wenn man auch nur einen ernsthaften C64-Pixler für die neue Plattform begeistern möchte, wird das damit nicht gelingen. Bei nur 16 Farben kann man einfach nicht die 6 Grundfarben der additiven und subtraktiven Farbmischung plus schwarz und weiß nehmen und dann dazu irgendwelche Abdunkelungen oder Aufhellungen davon. Bzw. kann man natürlich schon, sieht aber nicht gut aus. ;) Auch der CPC-Versuch zeigt, dass technische Paletten so ihre Tücken haben. Dabei wurde hier sogar schon dreidimensional gearbeitet – aber halt in einem ungeeigneten Farbraum (und daher u.a. zu grünlastig) und mit Extremwerten statt gemäßigten Tönen.

    Auf der anderen Seite sind 3 Gruen-Toene halt auch schon wieder recht viel, wenn man insgesamt nur 16 Farben hat.

    Wenn man sich die Verteilung meiner Palette ansieht, kann man feststellen, dass sie (wie auch schon die C64-Palette) sehr ausgewogen ist, was "kalte" (blau und grün) und "warme" (gelb bis rot/braun) Farben angeht. Das hellste Grün kann man, wie bisher auch, wunderbar in eine Blau-Kaskade mit integrieren.

    @ Hautfarbe / CPC: Da gibt es in meiner Palette ja immerhin ein rosa und ein orange zur Auswahl.

    Pass mal auf, dass dir das nicht als Rassismus ausgelegt wird, wenn du nur helle Hauttöne anbietest. ;) Meine Palette ist so "pc", wie sie bei 16 Farben nur sein kann. ;)

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • Denkbar waere natuerlich auch ein 640x480-Modus aber dafuer nur Monochrom, oder nur mit wenigen Farben. Diesen koennte man dann z.B. fuer den Code-Editor nutzen, oder fuer simple Anwendungen


    Eine kleine Nachfrage: Wären die 640x480 progressiv oder im Interlace?

    Und ich habe noch nicht einmal was dagegen, wenn man Features verschlechtert – Commodore hat ja auch beim Plus/4 die Sprites und das Scrolling weggelassen


    Ohne Sprites muss man den Entwicklern was vergleichbares wie einen linearen Bitmapmodus anbieten, was mMn zu sehr in Richtung VGA-Mode 13 gehen würde und im Endeffekt auf einen "dummen" Framebuffer hinausläuft.

    PS: Der Plus/4 hat übrigens HW-Feinscrolling :)

  • Wenn das Ding auch außerhalb der C64 Welt erfolg versprechen soll, würde ich nicht zu nah am C64 bleiben, dafür gibt es C128, 64DTV, div. FPGA Lösungen (U64, Chameleon) und irgendwann den Mega65.

    Wen interessiert in so einem frühen Stadium die Farbpalette? Darum kann man sich kümmern wenn die Hardwarespecs und grundlegende Ideen zum System stehen. Soll es eine reine FPGA Lösung werden? Ein Mix wie beim Foenix C256? Oder lieber etwas basierend auf Chips die es in vernünftigen Stückzahlen und Preisen noch gibt und FGPA nur wo es sein muss? Ich würde zu letzterem tendieren (siehe auch mein Posting auf Bitte melde dich an, um diesen Link zu sehen.).

    Bitte melde dich an, um diesen Link zu sehen. C64 Speichererweiterung, Bitte melde dich an, um diesen Link zu sehen., Bitte melde dich an, um diesen Link zu sehen. Toolcollection fürs TapeCart, Bitte melde dich an, um diesen Link zu sehen.,
    Bitte melde dich an, um diesen Link zu sehen. [Assy 250466, 1541U2+, MixSiD, Keyman64, Overlay64, Reprom64, AC/64], Bitte melde dich an, um diesen Link zu sehen. [2xARMSID],
    Bitte melde dich an, um diesen Link zu sehen. [Rev 8A, TK68EC020], Bitte melde dich an, um diesen Link zu sehen. [Rev 1.3, ACA630], Bitte melde dich an, um diesen Link zu sehen. [Rev. 2B, ACA1233n]

  • Wären die 640x480 progressiv oder im Interlace?

    Ich würde ohnehin nicht auf 400 oder 480 Pixel vertikal gehen. 480 Pixel würden (bei 640 px horizontal) wieder 4:3 ergeben, was ich eher kontraproduktiv finde, wenn man heutige Monitore/TVs als Ausgabeeinheit favorisiert. Und 400 Pixel sind nicht notwendig für einen 80-Zeichen-Texteditor – interlaced will man das zu dem Zweck schon gar nicht. Ich würde den 640 x 200 px Modus gar nicht erst als Bitmap anbieten, sondern rein als Textmodus (durchaus in Farbe). dazu dann 320 x 200 px als Text- und Bitmap-Mode. So hätte man sogar weniger Grafikmodi als beim C64.

    Ohne Sprites muss man den Entwicklern was vergleichbares wie einen linearen Bitmapmodus anbieten

    Ich will nicht auf Sprites verzichten. Das war nur als Beispiel gedacht, um zu zeigen, dass es Verringerung von Fähigkeiten in der IT-Geschichte durchaus gegeben hat. Es ging nicht immer nur "vorwärts". Wenn jetzt jemand als Herausforderung vorschlagen würde: nur noch 4 Sprites je Scanline (dafür dann aber ohne Rastertricks beliebig viele untereinander), wäre das für mich auch OK – immer noch besser als bei Atari 8-Bit.

    Der Plus/4 hat übrigens HW-Feinscrollin

    Das wusste ich nicht.


    Ich habe noch ein paar gedankliche Optimierungen bei der "C64-Nachfolge-Palette" vorgenommen. An den grundsätzlichen Farben hat sich nichts geändert (also ein Grün mehr), ich habe sie jetzt aber in nur noch 3 Helligkeitsstränge sortiert (neutral, kalt und warm) mit insgesamt sogar 11 Helligkeiten (wobei "Helligkeiten" ein ganz eigenes Fass sind, das ich hier jetzt nicht aufmachen will). Die Töne stimmen weiterhin nicht zwingend, es geht nur um die logische Reihenfolge.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Damit müsste man so ziemlich alles pixeln können, was mir so vorschwebt (und das ist eine Menge). Vor allem die Künstler, die weiche Übergänge produzieren wollen, müssten an der Palette ihre Freude haben, auch wenn sie nicht so wenig gesättigt ist, wie wenn man beim C64-Monitor zusätzlich noch die Farbe rausdreht (was einige tun). Vielleicht darf jedes Programm auf diesem Retro-Rechner beim Start die Farb-Sättigung der Palette einstellen – das würde genau dem entsprechen, was manche früher mit ihren Monitor-Einstellrädchen taten (nur jetzt halt automatisch). Das wäre weniger als eine ganz neue Palette zu laden aber mehr, als wenn man gar keinen Einfluss darauf hätte.

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • Wenn das Ding auch außerhalb der C64 Welt erfolg versprechen soll, würde ich nicht zu nah am C64 bleiben

    Das kam halt daher, dass M. J. die Grafikfähigkeiten vom C64 abgeleitet hat – und ich fand das sehr gut. Außerdem sind wir hier alle verhältnismäßig C64-affin. Dazu kommt, dass der C64 nun mal mit Abstand der erfolgreichste Homecomputer war – es gibt schlechtere Vorbilder.

    Wen interessiert in so einem frühen Stadium die Farbpalette?

    Die Grafiker – für die so ein System auch interessant sein muss. Die Programmierer und Löter und Musiker kümmern sich um andere Sachen, die Pixler um die Farben. Es geht auch weniger um die konkreten Farben, sondern darum, zu eruieren, ob einem 16 Farben für alle Zeiten ausreichen oder ob man nicht auf eine größere Farbauswahl setzen muss, was dann ja auch wieder technische Auswirkungen hätte.

    Soll es eine reine FPGA Lösung werden?

    Momentan wäre ich (noch) dafür. Ich denke, alles andere macht die Sache nur unnötig komplex und teuer, oder? Ich verstehe die Projekte nicht, die unbedingt eine echte CPU haben wollen und dann die GPU mit einem FPGA realisieren – was soll der Mischmasch? Welche Vorteile hat das?

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • Eine echte CPU, Grafik- und Musicchip limitiert das System auf das was die Chips können. Bei einem FPGA besteht immer die Gefahr das die Entwickler dem Gerät Dinge hinzufügen "weil es halt geht" (so lange der FPGA nur groß genug ist) und dann kommt am Ende ein Mega65 raus, der nicht mehr viel mit dem C65 zu tun hat (außer das er auch einen C65 Mode hat, den wohl kaum jemand nutzen wird).

    Bitte melde dich an, um diesen Link zu sehen. C64 Speichererweiterung, Bitte melde dich an, um diesen Link zu sehen., Bitte melde dich an, um diesen Link zu sehen. Toolcollection fürs TapeCart, Bitte melde dich an, um diesen Link zu sehen.,
    Bitte melde dich an, um diesen Link zu sehen. [Assy 250466, 1541U2+, MixSiD, Keyman64, Overlay64, Reprom64, AC/64], Bitte melde dich an, um diesen Link zu sehen. [2xARMSID],
    Bitte melde dich an, um diesen Link zu sehen. [Rev 8A, TK68EC020], Bitte melde dich an, um diesen Link zu sehen. [Rev 1.3, ACA630], Bitte melde dich an, um diesen Link zu sehen. [Rev. 2B, ACA1233n]

  • Bei einem FPGA besteht immer die Gefahr das die Entwickler dem Gerät Dinge hinzufügen "weil es halt geht" (so lange der FPGA nur groß genug ist)

    Also hat das im Grunde mit Selbstbeschränkung zu tun. Wenn man also "aufpasst", dass man es an keiner Stelle überreißt (nur weil es ginge), dann könnte man (wahrscheinlich kostengünstiger?) mit einem FPGA auskommen, statt eine ganze Platine mit Bauteilen vollzulöten, von denen man nicht weiß, ob es sie "nächste Woche" noch gibt.

    Dazu kommt, dass man eben kreativ sein kann, was z.B. die CPU angeht und sie mit genau den Fähigkeiten versehen, die man für nötig hält (allerdings hier auch wieder verbunden mit einer gewissen Selbstbeherrschung).

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • Das wäre für mich der primäre Einsatzzweck eines möglichen Scrollingbeschleunigers, wodurch viele Arcadespiele grafisch profitieren können. Durch die Beschränkung auf drei bzw. vier beliebige Farben pro Kachel bliebe dabei auch der 8-Bit-Charme erhalten.

    Gehen wir mal von der Möglichkeit eines neuen, erweiterten VIC II aus. In dem Fall verfügt der neue Zeichensatzmodus nach dem Vorschlag von atomcode nicht nur über die gleichen farblichen Qualitäten des Bitmap-Multicolourmodus, sondern geht sogar darüber hinaus, da man 4 unabhängige Farben pro Zeichen erhält (anstelle von 3 Farben plus allgemeine Hintergrundfarbe). Das bedeutet, daß man im Textmodus den Bildschirm wie folgt zusammensetzen kann:
    Zeile 0: Zeichen 0 .. 39
    Zeile 1: Zeichen 40 .. 79
    ...
    Zeile 5: Zeichen 200 .. 239
    Zeile 6: Zeichen 0 .. 39 (2. Zeichensatz)
    ...
    Vor Zeile 6 (und weiteren Zeilen) schaltet man per Rasterinterrupt den Zeichensatz um.
    Dadurch erhält man eine quasi Bitmapdarstellung basierend auf dem Zeichensatzmodus. Will man nun die Anzeige nach links scrollen, reicht es aus, zuerst die Zeichen zu rotieren:
    Zeile 0: Zeichen 1 .. 39, 0
    Zeile 1: Zeichen 41 .. 79, 40
    ...
    Zeile 5: Zeichen 201 .. 239, 200
    Zeile 6: Zeichen 1 .. 39, 0 (2. Zeichensatz)
    Nun muß die neue Bitmapgraphik in die Zeichen 0, 40, 80... kopiert werden, und fertig ist das Bitmapscrolling. Dies ist wesentlich schneller als wenn man eine ganze Bitmap umkopieren müßte. (Das Verfahren kommt nicht von mir, sondern wurde schon bei "The Sentinel" eingesetzt.) Einen echten Bitmapmodus braucht man nach der Definition von atomcode gar nicht, da er keinen Vorteil bietet. Nur in dem Fall, daß man nicht Sprites, sondern Shapes (Bobs) über den Bildschirm bewegen möchte, würde das Malen komplizierter, da einzelne Zeichen im Zeichensatz übermalt werden müssen, d. h. die Maldaten nicht direkt hintereinander liegen. Dennoch würde ich auf kleinen Rechnern im Stil der Homecomputer bei scrollenden Spielen eher auf Zeichensatzscrolling setzen und Bitmap gebrauchen für sowas wie Anwendungen oder Rollenspiele, Adventures oder 3d-Spiele, wo man ein freies Plazieren von Graphik benötigt.

    Wie schaut es eigentlich mit freier Adressierung des Color-RAMs aus? Ist das erwünscht/vorgesehen und gibt es da auch FPGA-spezifische Hürden zu überwinden?

    Ich nehme an, Du meinst mit "Color-Ram" das Farbram bei $d800. Geht man weiterhin von einem VIC-Nachfolger aus, so müßte sich dieser vom Design her an dem alten VIC II anlehnen. Eine einfache Umsetzung der Logik des VIC II würde bei einem FPGA wohl so aussehen, daß das Farbram im Blockram des FPGA untergebracht ist, da er auf dieses schnell und dem Original entsprechend auch parallel zugreifen kann. Bei der Verlagerung des Farbspeichers in das normale Ram verändert sich das Zeitverhalten, da die Farbinformationen zusätzlich zu den Zeichendaten aus dem langsamen Speicher geholt werden müssen, entweder vorher oder nachher. Dies würde den Prozessor jedoch ausbremsen.
    Ein weiteres Problem wäre die Bestimmung der Position des Farbrams, denn es liegt beim VIC II eigentlich außerhalb des normalen Speichers (die berühmten zusätzlichen 0,5 kb) und außerhalb der VIC-Bank. Eine Adreßangabe müßte folglich so aussehen: Plazierung irgendwo im Arbeitsspeicher oder außerhalb. Kann man machen, ist aber irgendwie nicht so sauber. ^^
    Der Grund, warum Du Dir eine freie Adressierung des Farbrams wünschst, liegt - so vermute ich mal - darin, daß man dieses unsichtbar umkopieren bzw. plötzlich durch Wechsel der Adresse einblenden kann. Wie wäre folgender Vorschlag: Die Auswahl der Ram-Bank bezieht sich auch auf das Farbram, d. h. das Farbram besteht tatsächlich aus 16 Bit pro Adresse, und der 6502-Prozessor liest und schreibt jeweils davon nur ein Byte (oben oder unten). In einem Kontrollregister wird festgehalten, ob das untere (Standard) oder obere Byte angezeigt werden soll. Dadurch bestände zumindest die Möglichkeit eines Double-Buffering bzw. Malen im Hintergrund mit plötzlichem Einblenden. Wäre das ausreichend?

    Und falls man sich aus pragmatischen Gründen zunächst für VGA entscheidet: Welche Probleme sind bei einer späteren Wandlung oder Umrüstung auf digitale Ausgabe vieleicht schon abzusehen und können eventuell schon im Vornhinein berücksichtigt werden?

    Gute Frage. Keine Ahnung. Sicher wäre nur, daß es aus Programmierersicht keinen Unterschied machen darf.

    Pico8

    Der Pico-8 ist leider nur eine Spielkonsole mit vielen bunten Farben, aber zu niedriger Auflösung, als daß er als Homecomputer verwendbar wäre. Persönlich fand ich gerade den C64 deswegen so toll, weil man ihn nicht nur zum Spielen, sondern auch zum Programmieren oder für weitere Dinge (Messen, Steuern, Regeln) verwenden konnte.

    Es geht nicht um "Schwierigkeiten", sondern um Einstiegshürden.

    Das habe ich wohl verstanden, doch weiß ich nicht ganz, welche Einstiegshürden für welche Personen Du konkret meinst. Man kann ja folgende Typen unterscheiden:
    a) Die Person beherrscht bereits 6502-Assembler oder 68000. Dann ist der Einstieg leicht, weil viele Befehle ähnlich oder verwandt sind.
    b) Die Person beherrscht kein Assembler. Dann ist der Einstieg auch leicht, weil die Assemblersprache absichtlich einfacher gehalten ist als die vom 6502 oder 68000. Das mit dem "handvoll" meinte ich durchaus ernst. Es gibt tatsächlich nur sehr wenige Befehle und Adressierungsarten, weniger als man es von anderen CPUs gewöhnt ist. Leichter als dies kann man es einem Einsteiger eigentlich nicht machen. Die Grundkonzepte (Wie ist der Speicher aufgebaut? Was ist ein Stapel? Welche Funktion hat das Flaggenregister?) sind eh immer gleich ganz unabhängig vom CPU-Typ. Wer ernsthaft Assembler lernen will, muß sich so oder so damit beschäftigen. Die einzige Schraube, an der man drehen kann, ist der Befehlssatz, und genau der ist bewußt simpel gehalten. Ehrlich, ich weiß nicht, was man noch mehr tun soll... :nixwiss:

    Was die Hochsprache anbelangt, so denke ich mal, daß solch ein Rechner ein möglichst offenes System sein soll. Unter "offen" verstehe ich auch, daß man nicht auf eine bestimmte Sprache angewiesen ist, sondern frei entscheiden kann, was man nehmen will.
    Auf dem AppleII gab es dafür extra eine Speichererweiterung genannt "Language Card", die im Adreßraum parallel zum Rom angelegt war. Diese Erweiterung diente dem Zweck, Speicherplatz für andere Sprachen (Interpreter oder die Laufzeitumgebung) anzubieten. Die Sprachen mußten dann natürlich von Diskette geladen werden, was etwas dauerte (, wenn auch nicht viel).
    Beim Foenix-System sieht es so aus, daß beim Booten der Inhalt eines Flashroms zur Ausführung in den Speicher kopiert wird (ähnlich wie früher beim Amiga mit Turbokarte). Hier dient der Flashspeicher somit als schneller Datenträger für das System und die Sprache. Es ist sogar vorgesehen, einen Teil des Flashspeichers für den Benutzer überschreibbar und anpassungsfähig zu machen, d. h. jeder kann die Sprache seiner Wahl in das Flashrom kopieren.
    Nun würde ich allerdings zum Laden von System und Sprache nicht unbedingt ein Flashrom nehmen, sondern eine SD-Karte, da eine SD-Karte für den Benutzer einfacher zu handhaben ist als ein Flashspeicher. Das bedeutet: Beim Einschalten des Rechners wird das "Rom" (sprich: das System inklusive Sprache und anderen Tools) von SD-Karte geladen. Möchte man eine andere Sprache? Kein Problem. Andere Karte einstecken. Rechner starten. Fertig. Das ganze funktioniert dann quasi wie ein Kernal-Umschalter oder ein Steckmodul. Was die Zeit anbelangt, die es dauert, um die Daten von der Karte in den Speicher zu laden, so wäre dies selbst bei einer langsamen Übertragung per SPI noch schneller als der C64 seinen blauen Bildschirm anzeigt, also immer noch ein Gefühl von "einschalten und loslegen".
    Vorteil: a) Jeder hat die Sprache/das System, das er/sie gerne möchte. b) Die Software kann auch im Nachhinein ausgetauscht werden für Korrekturen und Ergänzungen. c) Jeder Programmierer kann sich sein eigenes "Rom" basteln oder überhaupt keines verwenden, sondern stattdessen direkt ein Spiel booten und damit von Grund auf das Metall schlagen. (Persönlich mochte ich immer genau diese Fähigkeit beim AppleII und auch Amiga: Man konnte ein eigenes Programm im Bootsektor unterbringen und dann nach Belieben Code nachladen und den Rechner komplett übernehmen ohne Rücksicht auf irgendein vorgefertigtes System.)
    Nichtsdestoweniger gilt aber stets: Jeder Interpreter und jeder Compiler muß von irgendjemanden geschrieben werden. Auch ein Pascal-Compiler fällt nicht plötzlich vom Himmel, nur weil ihn sich jemand wünscht. Aber wenn jemand Spaß daran hat, einen Basicinterpreter zu schreiben... Warum nicht?

    Wäre das so in Ordnung?

    Eine kleine Nachfrage: Wären die 640x480 progressiv oder im Interlace?

    Die normale Ausgabe, die ein FPGA direkt ohne Umstände erzeugt, ist 640x480 @60Hz. Möchte man 640x480 interlace ausgeben, würde man ein künstliches Flackern einbauen müssen, was nicht wirklich Sinn macht. Das bedeutet, daß für eine Auflösung vertikal > 240 die Daten für alle Zeilen im Speicher stehen bzw. pro 60 Hz Frame berechnet werden müssen.

  • Dadurch erhält man eine quasi Bitmapdarstellung basierend auf dem Zeichensatzmodus. Will man nun die Anzeige nach links scrollen, reicht es aus, zuerst die Zeichen zu rotieren ... Nun muß die neue Bitmapgraphik in die Zeichen 0, 40, 80... kopiert werden, und fertig ist das Bitmapscrolling. Dies ist wesentlich schneller als wenn man eine ganze Bitmap umkopieren müßte. (Das Verfahren kommt nicht von mir, sondern wurde schon bei "The Sentinel" eingesetzt.)


    Das ist ja interessant. Eine ähnliche Idee hatte ich auch mal, aber rein statisch ohne Scrolling. Haben das auch andere Spiele verwendet?

    Wie wäre folgender Vorschlag: Die Auswahl der Ram-Bank bezieht sich auch auf das Farbram, d. h. das Farbram besteht tatsächlich aus 16 Bit pro Adresse, und der 6502-Prozessor liest und schreibt jeweils davon nur ein Byte (oben oder unten). In einem Kontrollregister wird festgehalten, ob das untere (Standard) oder obere Byte angezeigt werden soll. Dadurch bestände zumindest die Möglichkeit eines Double-Buffering bzw. Malen im Hintergrund mit plötzlichem Einblenden. Wäre das ausreichend?


    Ja, klingt auch gut.

    Die normale Ausgabe, die ein FPGA direkt ohne Umstände erzeugt, ist 640x480 @60Hz.


    Gäbe es dann immer noch einen "Trauerrand" aka Border zu sehen?

  • Wenn jetzt jemand als Herausforderung vorschlagen würde: nur noch 4 Sprites je Scanline (dafür dann aber ohne Rastertricks beliebig viele untereinander)


    8 Sprites nebeneinander mit unbegrenzter Höhe ist noch besser. Entweder in dem ungenutzen 64. Byte eine Verlinkung zu den nächsten Spritedaten oder mit fortlaufendem Spritepointer in Verbindung mit zusätzlichren VIC-IIx-Registern, die die Anzahl und somit die Höhe der Sprites festlegen.

    Ich verstehe die Projekte nicht, die unbedingt eine echte CPU haben wollen und dann die GPU mit einem FPGA realisieren – was soll der Mischmasch?


    Die (Un-)Logik dahinter habe ich auch nicht verstanden.

  • Wen interessiert in so einem frühen Stadium die Farbpalette?

    Ach geht es hier jetzt um ein konkretes Projekt? Bisher postet doch jeder seinen persoenlichen Senf (nicht negativ gemeint) zum Thema "wie koennte mein Traum-8Bit-Rechner aussehen". Dass da jeder andere Schwerpunkte hat, duerfte eh klar sein. Und die Grafikeigenschaften eines Rechners stellen fuer viele nunmal etwas sehr charakteristisches dar. Klar, andere wollen diese und jene CPU drin haben und finden wichtig wie das RAM-Banking funktioniert. Andere finden es halt wichtig, dass es so und so viele Sprites gibt mit so und so vielen Farben, aber ob da nun ein Z80 oder ein 6502 drinsteckt, das ist ihnen erstmal egal.

    Ausserdem steckt hier im Thread doch auch viel Philosophie drin. Ab wie vielen Farben verliert der Rechner seinen Charakter, bis zu welcher Aufloesung ist es noch retro, duerfen moderne Anschluesse vorhanden sein, etc etc etc...

    - neue Spiele für den C64 -
    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.

  • Zum Thema Aufloesung: Als ich damals meinen Phantasie-Rechner angefangen habe zu entwerfen, habe ich mich fuer eine Aufloesung von 256x192 entschieden. Unter anderem mit dem Hintergrund, dass man diese Aufloesung in einem 320x240-Rahmen zentrieren kann und dann rundherum noch einen schoenen Rand hat. 320x240 wiederum laesst sich problemlos auf 640x480 skalieren, welches dem VGA-Standard entspricht und auch heute noch von so gut wie jedem Ausgabegeraet unterstuetzt wird. Somit kann man also relativ problemlos auf fast allen Monitoren den Modus 640x480 fahren, und darin zentriert das auf 512x384 hochskalierte Endresultat anzeigen. Der Bereich drumherum bekommt, wie beim C64 auch, eine Farbe zugewiesen. Somit gibt es auch keine Probleme mit etwaigem Overscan bei Roehrenbildschirmen usw, und es sieht halt "retro" aus durch den Rahmen. Das hat mir eigentlich sehr gut gefallen.

    - neue Spiele für den C64 -
    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.

  • Eine echte CPU, Grafik- und Musicchip limitiert das System auf das was die Chips können. Bei einem FPGA besteht immer die Gefahr das die Entwickler dem Gerät Dinge hinzufügen "weil es halt geht" (so lange der FPGA nur groß genug ist) und dann kommt am Ende ein Mega65 raus, der nicht mehr viel mit dem C65 zu tun hat (außer das er auch einen C65 Mode hat, den wohl kaum jemand nutzen wird).

    ACK. Ich hatte mir neulich erst angesehen, was der C65 genau ist und kann, und dachte dann so ... Hey man, das klingt interessant und gar nicht so übertrieben, und der hätte vmtl. damals das Zeug gehabt, meinen C64 abzulösen.

    Danach hatte ich mir angesehen, was der MEGA65 alles kann, und da war ich teils enttäuscht. Wie gut das Konzept mit den geschachtelten Modi funktioniert, sahen wir am C128 (Ich habe selbst einen, aber NIE genutzt). Wenn man einen Computer braucht, der viel mehr kann als man damit machen oder davon nutzen will, dann kann man sich auch gleich einen günstigen PC kaufen und den per Emulation im "Modus" XYZ nutzen. Dazu muss man nicht erst das Rad neu erfinden. Die Entwickler zählen dann immer stolz auf, was ihr Baby alles kann. Wenn aber die Grenzen und Hürden durch "ganz tolle" Features in die Ferne rücken, bleibt die einzige Herausforderung die der Softwareentwicklung an sich, der Idee, der Algorithmen, etc., eben wie auf dem PC, auf dem technische Grenzen nur noch bei modernsten 3D-Spielen diskutiert werden. Und wenn das immer noch nicht reicht, kommen halt wieder neue Grafikkarten für neue APIs zum Einsatz.

    Das ist irgendwie so, als hätte man die grandiose Idee, beim Hürdenlauf die Hürden einfach an den Rand zu stellen, damit die Läufer schneller voran kommen, während man gleichzeitig erwartet, dass die Läufer dennoch regelmäßig springen.
    Ich brauche keine WUXGA-Auflösung, sondern klare historisch typische Grenzen, und mit diesen begrenzten Möglichkeiten soll dann etwas möglichst Schönes und Spaßiges geschaffen werden. Es ist tatsächlich wie beim Sport, eine Disziplin.

    Zitat

    We choose to go to the Moon in this decade and do the other things, not because they are easy, but because they are hard.

    Es war eine außergewöhnliche Leistung, WEIL die technischen Möglichkeiten noch sehr begrenzt waren.

    Gerade ein weitgehend authentischer C65 zu einem möglichst noch bezahlbaren Preis hätte vielleicht das Zeug gehabt, noch verspätet zu Ruhm zu kommen.
    Wenn es einem nur darum geht, Spiele im "Retro-Look" zu entwerfen, sollte man sich vielleicht besser der Indie-Szene anschließen und seinen PC benutzen.

  • Kann der C 65/Mega 65 bitte in dem anderem Thread (Bitte melde dich an, um diesen Link zu sehen.) diskutiert werden. Dort wurden wir auch wegen Offtopic zurecht "rausgeschmissen" (Bitte melde dich an, um diesen Link zu sehen.)