Hello, Guest the thread was called28k times and contains 825 replays

last post from RexRetro at the

Neuer Retro-Computer im 8-Bit Style

  • Nein, ich stelle hier kein weiteres, in Entwicklung befindliches, Gerät vor. (Und schon wenden sich 90% der Leute, die in die "Clickbait"-Falle getappt sind, enttäuscht ab) ;)


    Gerade in letzter Zeit wurden ja einige Retro-Computer (im wirklichen Sinne) vorgestellt: C256Foenix, Mega65 und Commander 16 (vorläufiger Name). Die Geräte haben gewisse Gemeinsamkeiten aber auch gravierende Unterschiede. Und jedes der Geräte baut seine eigene Fanbase auf und will natürlich erfolgreich sein – weil die Entwicklung ja auch aufwendig und spätestens in der Herstellung teuer ist.


    Dies ist ein Luftschlösser-Thread!!! (nicht, dass jemand später behauptet, ich wolle etwas bauen (lassen) – Es geht um reinen Gedankenaustausch)


    Mir fiel auf, dass mich keines der Projekte wirklich dahingehend überzeugen kann, es zu kaufen – am ehesten noch der Commander 16 (wegen des angepeilt günstigen Preises). Warum nicht? Naja, es sind die "Dream"-Computer anderer Leute und halt nicht MEIN Dream-Computer. Jetzt ist es aber nicht so, dass ich schon ein fertiges Konzept von meinem Traum-Retro-Rechner in der Schublade hätte. Ich weiß eher, was ich alles NICHT will. Und die bisherigen Konzepte führen natürlich schon dazu, dass man gewisse Eigenschaften sieht, die man auch in einem eigenen Gerät gerne sehen würde. Ich würde euch gerne hier ein paar (für mich wünschenswerte) Merkmale meines Retrotraumrechners auflisten und ihr könnt dazu ja mal was sagen oder ergänzen oder eure eigenen Vorstellungen hier posten.


    Vielleicht ist das am Ende nur eine Ansammlung der unterschiedlichsten Rechner-Konzepte, vielleicht kristallisieren sich aber auch Gemeinsamkeiten heraus, die zu einem weiteren "Kompromiss"-Rechner führen, den dann ja vielleicht doch jemand bauen will – weil sich viele darauf einigen konnten. Das wäre dann ein demokratischer Retro-Rechner. ;)



    Nun meine Gedanken zum Thema Retro-Computer:


    Kompatibilität: Ist eine Kompatibilität zu einem "alten" Rechner erforderlich (wie beim Mega65)? Ich bin mir da nicht ganz klar darüber. Will man ein neues Gerät kaufen, um vorwiegend alte Software darauf laufen zu lassen oder alte Geräte daran anzuschließen? Soll das neue Gerät die alten Geräte schonen, damit sie in der Vitrine bleiben können? Ich weiß es nicht. Vielleicht könnte man es als zusätzliches Feature bewerben, wenn der FPGA Core (oder was auch immer) auch C64-, Atari-, Specci- oder Apple-Software abspielen könnte? Ich denke, zentral für jeden Retro-Rechner ist es, einen Modus zu haben, für den neue Software entwickelt werden kann. Und dieser Modus muss attraktiv für Entwickler sein – über welche Features auch immer.


    Formfaktor: Soll das Gerät ein Tastatur-Rechner sein? Diese Lösung hat natürlich was – es ist einfach DIE Bauform für einen Homecomputer. Allerdings sind die Kosten dadurch immens, denn es muss nicht nur ein großes Gehäuse her (das für die heutige Technik gar nicht mehr benötigt werden würde), sondern auch Tastatur-Mechanik, Tastenkappen mit passender Bedruckung etc. Gut, man könnte natürlich davon Abstand nehmen, dass Gehäuse und Keyboard einer alten Vorlage ähnlich sehen sollen, dann könnte man auf Standard-Bauteile zurückgreifen. Allerdings hat ein Tastatur-Computer den Nachteil, dass alle Kabel (zumindest Strom) zu ihm geführt werden müssen und er deswegen nicht unbedingt Wohnzimmer-tauglich wäre (Stolperfalle). Da wäre ein Kasten besser geeignet, der z.B. in der Nähe des TVs/Monitors aufgebaut wird und den man über Funk bedienen kann – wie man es von heutigen Spielkonsolen her kennt. Trotz der kleinen Kiste sollte das Design nicht vernachlässigt werden, denn darüber laufen viele Emotionen. Vielleicht stellt der Kasten sein Logo selber dar, so ähnlich, als würde man ein leuchtendes Atari-Fuji oder C= Logo auf dem Tisch stehen haben. Das wäre ein cooles Statement.


    Aufstellung: In welchem Zimmer des Zuhauses hätte man denn überhaupt einen neuen Homecomputer stehen? Ich denke, er kann im Arbeits-/Hobby-Zimmer stehen aber auch im Wohnzimmer. Eigentlich ganz ähnlich, wie früher. Manch einer hatte ein Computer-Zimmer, andere hatten den Computer am Wohnzimmer-TV angeschlossen. Wer selber Programme darauf schreiben will, wird den Rechner wohl auf einen Schreibtisch stellen, wer damit spielen will, wird vielleicht den Fernseher im Wohnzimmer favorisieren. Beides sollte so ein Rechner gut hinbekommen. Der Homecomputer sollte auf jeden Fall recht portabel sein, sodass man ihn auch schnell mal mit zu einem Computer-Treffen oder zu Freunden mitnehmen kann.


    Preis: Für mich wäre ein Retro-Homecomputer vor allem auch ein Home-Computer. Der sollte kostengünstig sein. Und um so bezahlbarer er ist, desto besser wird er sich verkaufen – was wiederum die Wahrscheinlichkeit erhöht, dass ihn Software-Entwickler für sich entdecken. Für nur 1.000 Computer wird sich niemand hinsetzen und ein aufwendiges Spiel schreiben. Bei 100.000 Computern sähe die Situation schon anders aus. Der Preis, den der 8-Bit-Guy beim Commander 16 anstrebt, ist schon sehr ambitioniert: Zwischen 50 und 100$. Ich denke, 99$ sind halt eine gewisse Grenze, 199$ auch. darüber wird die Luft dann schon dünner. Man muss bedenken, dass die potentiellen Käufer schon andere Geräte haben werden, sei es Spielkonsolen oder alte/neue Rechner, Smarte TVs und dazu noch Smartphones und Tablets. Ein Retro-Homecomputer ist also kein Must-have, sondern ein Goodie, dass man sich zusätzlich gönnt. Natürlich gibt es auch eine Anzahl von Leuten, die das noch bei 500$ tun würden – aber eben schon deutlich weniger als beim halben Preis. Ich fände so um die 100 $/€ ganz angenehm und bei dem von mir angedachten Formfaktor gäbe es ja auch nicht so teure Teile, wie Custom-Keyboards.


    Technik: Für mich persönlich ist nicht entscheidend, ob so ein Retro-Rechner den Output per Emulation, einem FPGA oder mit dedizierten Bausteinen erzeugt. Wichtig ist halt, dass da nichts ruckelt oder "laggt" und sich halt alles "nativ" anfühlt. Unter den gegebenen Lösungen wäre ich wahrscheinlich am ehesten für eine FPGA-Lösung zu haben – aber wie gesagt, letztlich kommt es darauf an, wie es sich anfühlt. Emulation hat den Nachteil, dass alles etwas beliebig wirkt und es quasi auf jeder Hardware laufen könnte. Ich könnte mir vorstellen, dass sich das nachteilig auf die Akzeptanz auswirkt, weil es einem nicht "echt" genug vorkommt.


    Fähigkeiten:


    CPU: Es sollte halt vom Feeling her ein (leistungsfähiger) 8-Bit-Computer sein. Aber muss es dafür ein waschechter 8-Bitter sein? Bei 2 der 3 genannten Retro-Rechner soll der 6502-kompatible (aber 16-bittige) 65816 zum Einsatz kommen. Ich finde die Wahl sehr gut. Andere würde vielleicht was Z80-kompatibles bevorzugen aber ich bin halt ein 6502-Kind. Bei FPGA oder Emulation könnte man auch ohne große Kostenprobleme Hybrid-Lösungen erdenken, bei denen zwischen verschiedenen CPUs umgeschaltet werden kann – ähnlich Apple IIe oder C128 aber vielleicht noch stärker ineinandergreifend. Fiele die Wahl auf den 65816, könnte man natürlich gucken, ob man die dafür existierende Software (SNES oder Apple IIGS) lauffähig bekommt, quasi als Einstiegshilfe, solange es noch keine neue Software gibt (die es ja vielleicht auch nie geben wird). Bei der Taktfrequenz gäbe es auch noch einiges zu klären. Beim IIGS lief die CPU mit 2.8 MHz, im SNES mit 3.6 MHz in der SuperCPU mit 20 MHz. Ich würde vielleicht auf 8 bis max. 16 MHz plädieren. Der Rechner sollte aber schnell genug sein, dass man in einer Hochsprache duchaus brauchbare Software schreiben kann und dafür nicht automatisch zu Assembler greifen muss.


    Grafik: Ganz schwierig und für mich oft der Showstopper bei den kommenden Retro-Rechnern. Um authentisch zu wirken und auch, um eine Herausforderung für die Pixelkünstler zu sein, darf man die Leistung nicht zu hoch schrauben. Meines Erachtens darf so ein Retro-Computer im 8-Bit-Stil die 16-Bit-Rechner von damals™ nicht überflügeln. Das heißt konkret: bei 640 Pixeln Breite muss Schluss sein. Vertikal sogar bei 200 oder 256 Pixeln. In typischen Spielmodi müssten 320 Pixel horizontal ausreichend sein. Bei den Farben: Eine Palette von 4096 Farben mit sehr eingeschränkter Nutzung? Oder sogar eine feste Palette von 256 oder weniger Farben. Z.B. 64 Farben wäre schon ein riesiger Unterschied zum C64. Nur weil damals ein C65-Prototyp (allerdings erst 1991) vielleicht schon mehr konnte, muss man dem ja nicht folgen – "unsere Kiste" ist ohnehin ein Fantasie-Rechner (der gedanklich von 1985 stammen könnte). Dediziertes Video-RAM könnte weitere Einschränkungen bei gleichzeitig darstellbaren Farben vs. Auflösung bringen. Sprites finde ich ein Muss, Scrolling auch. 3D sollte man vielleicht besser nicht explizit unterstützen.


    Sound: Da bin ich gewiss kein Fachmann. Ich würd da einfach mal sagen: Ensoniq ES-5503


    RAM: Der kostet heute nicht mehr viel Geld und der 65816 kann z.B. 16 MB adressieren. Ich würde aber aber auf 2 oder 4 MB setzen, zu viel bringt hier auch nichts.


    Schnittstellen: Würde ich Legacy-Schnittstellen unterstützen? Eher nicht. Ich glaube nicht, dass man an so einen Rechner einen alten Paralleldrucker anschließen will und auch keine Datasette oder 1541. Alles, was es an alter Software gibt (wenn man dazu überhaupt kompatibel sein will), ist längst auf modernen Medien (oder medienlos) zu bekommen. Uralte Maus/Keyboard-Schnittstellen? Warum? soll das das Retro-Feeling verbessern? Ich würde sagen, der Rechner könnte eine kleine Kiste sein, mit einem leicht erreichbaren Einschalter und SD-Card-Slot vorne. Joystick-Ports? Da kann man wieder streiten, ob 2 reichen oder besser gleich 4. Da würde ich doch fast sagen: nehmen wir Bluetooth und unterstützen wir meinetwegen bis zu 8 Joysticks, wenn ein Spiel das will. Das kostet keinen Platz auf der Platine und keine zusätzlichen Bauteile oder Gehäuse-Öffnungen. Ein Hurra für Multiplayer-Games im Wohnzimmer – ganz ohne Kabelsalat, egal wo man sitzt. Keyboard und Maus dann auch über USB oder Bluetooth. Damit hätten wir dann auf der Rückseite nur einen Anschluss für Strom (Micro-USB, weil man dann das Netzteil auch weglassen kann), 4x USB-A für diverse Geräte, Audio-Klinke und einen Monitor/TV-Anschluss (Mini-DVI, HDMI oder was anderes verbreitetes).


    Interface: Mir gefällt die Idee vom 8-Bit-Guy (und anderen), dass der Retro-Computer sofort nach dem Einschalten in eine Programmierumgebung springen soll – das kennt man einfach von den alten Homecomputern. Ein GUI wäre hier fehl am Platz, weil es um das "alte Feeling" geht. Bei einem echten alten Computer sähe das für mich anders aus – da versucht man das Maximum herauszuholen und will vielleicht auch die Neuzeit auf die alten Kisten bringen. Bei einem Retro-Computer ist das nicht der Fall – der kommt schon aus der Neuzeit und tut nur so, als sei er alt. Im Gegensatz zum 8-Bit-Guy würde ich aber nicht versuchen, ein bestimmtes altes BASIC zu verwenden. BASIC an sich wäre OK, PASCAL fände ich aber ebenso gut geeignet. Wenn man das ganze aus einer didaktischen Sicht betrachtet, sollte der Rechner nicht zu einem schlechten Programmierstil auffordern, von daher sollte man vielleicht auf Zeilennummern und GoTos verzichten, vielleicht lässt man sie aber auch drin und empfiehlt einfach nur modernere Konstrukte. Auf jeden Fall muss der Einstieg so einfach wie möglich bleiben, denn das ist aus meiner Sicht eine Kernfunktion des Retro-Rechners. Im Gegensatz zum C64 würde ich für einen Volltext-Editor plädieren, bei dem man sich frei im Quelltext bewegen kann und automatisch hoch- und runtergescrollt wird. Mit einer Taste, wie Run/Stop, könnte man aus dem Editor in den Direkteingabe-Modus springen, in dem man dann z.B. RUN eingeben kann, um das Programm zu starten. Mit LIST käme man wieder in den Editor. Aus Performance-Gründen könnte der Quelltext vielleicht optional in eine Art Zwischencode übersetzt werden (wie das früher bei PASCAL der Fall war).


    Das sind natürlich alles nur ein paar einzelne Eckpunkte, die grob einen Rahmen abstecken würden. Aus den paar Infos könnte wahrscheinlich niemand einen Rechner konzipieren – aber über Bussysteme etc. weiß ich halt nicht viel. Aber darum geht es in einem ersten Schritt ja auch gar nicht, sondern darum, erst einmal zu gucken, was es so für Ideen und Vorstellungen gibt und ob die teilweise vielleicht sogar recht deckungsgleich wären. Wenn man sich anguckt, wie schnell die Stefany ihren C256Foenix hochzieht (und der 8-Bit-Guy helfende Hände findet), könnte aus einem forumsgeborenen Luftschloss ja vielleicht sogar Realität werden, wenn es auf begeisterte Hardware-Architekten träfe. Aber erstmal: rumspinnen ....


  • Technik: Für mich persönlich ist nicht entscheidend, ob so ein Retro-Rechner den Output per Emulation, einem FPGA oder mit dedizierten Bausteinen erzeugt.

    Weil du hier die Emulation erwähnst:


    Ich habe mich schon öfter bei den Vorstellungen von neuen Retrocomputern gedacht: Mir würde es vollkommen ausreichen, wenn man die vorgestellten Konzepte als gute Emulation für aktuelle Rechner anbieten würde.


    Da ist einfach schon alles vorhanden, nichts muss neu angeschafft oder gekauft werden und jeder kann sich so "seinen Wunsch-Computer" rein durch Softwareentwicklung "zusammenbasteln".


    Wieso sollte sich jeder Retrocomputerentwickler aufs Neue Gedanken um Gehäuse, Tastaturen und Bildausgabe machen? Das lenkt doch nur vom eigentlichen Ziel ab: Einen Retrocomputer zu entwickeln.


    Auch im Sinne von Nachhaltigkeit wäre es sinnvoller auf "echte Hardware" zu verzichten. Einen flotten PC oder Laptop hat ja eh schon jeder Zuhause.

  • Mir würde es vollkommen ausreichen, wenn man die vorgestellten Konzepte als gute Emulation für aktuelle Rechner anbieten würde.

    Es gibt ja auch Konzepte, bei denen man sich eine virtuelle Hardware ausgedacht hat und es davon nur eine Emulation gibt – bei Konsolen z.B. Pico-8. Ich finde das auch sehr gut und hatte das vor vielen Jahren (vor dem Pico-8) hier mal angeregt – das wurde aber (nach meiner Erinnerung) nicht positiv aufgenommen.


    Ich glaube, der Mehrheit ist das zu virtuell, um es "ernst zu nehmen". Die wollen etwas in der Hand halten, das gebaut wurde. Bei einer Emulation würde ja auch das (vielleicht hübsche) Gehäuse und die spezifischen Hardware-Anschlüsse wegfallen (der 8-Bit-Guy möchte ja z.B. Commodore-Floppys anschließen können).


    Auch im Sinne von Nachhaltigkeit wäre es sinnvoller auf "echte Hardware" zu verzichten.

    Da hast du natürlich recht. Alles was man herstellt, verbraucht erstmal Ressourcen und muss irgendwann auch wieder entsorgt werden. Da muss man halt gucken, ob einem das "Ding" (Computer, Auto, Handy, Haus, ...) es wert ist, die Entropie weiter voranzutreiben und die Welt dem Abgrund etwas näher zu bringen. Nachhaltig ist das Bauen von "sinnloser" Hardware sicherlich nicht – allerdings ist unser ganzen Leben wenig nachhaltig – leider.

  • Wenn ich mir einen Wunschrechner im Sinne von @Retrofan zusammen stecken könnte, den es auch vor 1990 schon hätte geben können (zumindestens die verwendeten Chips), würde er in etwa so aussehen: ganz klar ein Tastaturrechner, die größte Schwierigkeit hierbei ist ein preislich attraktives Gehäuse und Tastatur zu finden, dass auch noch einigermaßen gut aus sieht (aber wird wohl nur als Gehäuse und mit externer Tastatur zur realisieren sein wenn es max. 99 € kosten darf).

    • Prozessor 65816, max. mit ca. 8 MHz getacktet
    • 2 MB RAM und höchstens 4, da bin ich ganz bei Retrofan, um nicht endlos Ressourcen zur Verfügung zu haben
    • Als Soundchip Yamaha YM3812 (oder etwas vergleichbares, steht glaub ich noch recht günstig zur Verfügung, gab es schon 1985), ganz bewusst kein SID! (nun werde ich gesteinigt :D )
    • Zur Ergänzung noch einen Chip oder kleinen FPGA der 2 (max. 4) Digikanäle zur Verfügung stellt (16 Bit)
    • Einen Grafikchip vergleichbar Yamaha V9958 (gab es schon 1983), die Specs finde ich ansprechend

      • Video RAM: 128 KB + 64 KB of expanded VRAM
      • Textmodes: 80 x 24 und 32 x 24
      • Auflösung: 512 x 212 (4 oder 16 Farben aus 512) und 256 x 212 (16, 256, 12499 oder 19268 Farben)
      • Sprites: 32, 16 Farben, max. 8 pro horizontaler Linie
      • Hardwarebeschleunigung für kopieren, linie, füllen
      • Interlace für doppelte vertikale Auflösung
      • Horizontale und vertikale Scrollregister

    Schnittstellen

    • Video per HDMI
    • Optional Sound per 3,5 mm Klinke
    • Maus und Tastatur per USB
    • 2x Joystickports, SNES Controller, haben mehr Buttons zur Verfügung was es für Spiele interessanter macht und sind gut zu bekommen
    • 10/100 Ethernet und WLAN, nicht um Netzwerk an dem Rechner zu haben, sondern als Kommunikation für CrossDev Tools und z. B. für Modemverbindung und Datenaustausch per FTP auf der SD-Karte
    • SD-Kartenslot und native Unterstützung für FAT16/32 Filesystem, denn ich denke niemand möchte mehr mit Disketten rumhantieren
    • GPIOs zum steuern, regeln und experimentieren
    • Eine Art Expansionsport, um auch hier die Kreativität für interessante externe Erweiterungen zu fördern
    • MIDI-Port

    System

    • Kernal/Systemfunktionen
    • Basic samt Editor, vergleichbar wie bei einem C64/C128

      • Das Basic sollte auch hier den User begrüßen wie es bei vielen der alten Kisten der Fall war
      • Der Befehlssatz sollte mind. dem Basic 7.0 entsprechen (ohne Zeilennummern, bissel moderner darfs schon sein)
    • Maschinensprache Monitor
    • Integrierter Assembler und Editor
    • Ein Systemmenü ähnlich wie beim Ultimate64 oder Turbo Chameleon
    • Integrierter "Freezer" mit ein paar rudimentären Debugfunktionen
  • Es gibt ja auch Konzepte, bei denen man sich eine virtuelle Hardware ausgedacht hat und es davon nur eine Emulation gibt – bei Konsolen z.B. Pico-8. Ich finde das auch sehr gut und hatte das vor vielen Jahren (vor dem Pico-8) hier mal angeregt – das wurde aber (nach meiner Erinnerung) nicht positiv aufgenommen.
    Ich glaube, der Mehrheit ist das zu virtuell, um es "ernst zu nehmen". Die wollen etwas in der Hand halten, das gebaut wurde. Bei einer Emulation würde ja auch das (vielleicht hübsche) Gehäuse und die spezifischen Hardware-Anschlüsse wegfallen (der 8-Bit-Guy möchte ja z.B. Commodore-Floppys anschließen können).

    Danke für den Hinweis zum "Pico-8". Da lese ich mich mal dazu bisschen ein.


    Wenn ich einen Retrocomputer entwickeln würde, dann wäre für mich ein reines Softwareprodukt (Emulation) sowieso der erste Schritt, bevor ich auch nur ein "echtes" Bauteil anfassen würde.


    Dann könnte ich zum einen erstmal "real" testen, ob das Konzept auch das ist, was ich umsetzen will und zum anderen habe ich dann schonmal eine Plattform, die man zum Entwickeln für das System verwenden kann (lange bevor das Produkt verfügbar ist). Den entsprechenden Download kann man kostenlos anbieten und erreicht damit um Dimensionen mehr potentiell Interessierte als mit echter Hardware, die man entweder fertig kaufen oder zusammenbauen muss.


    Was will man letztendlich mit einer Hardware, die sich vielleicht weltweit 200-300 mal (mal so als Wert eingeworfen) verkauft? Wer entwickelt dafür mehr als mal paar Demozeilen? Da fehlt eine halbwegs stabile Basis, die das Gerät auch zur Verfügung hat.


    Nachtrag:
    Pico-8 kostet 15 US$ und bietet (soweit ich es überblicken kann) keine kostenlose Demoversion an.


    Ich bin allerdings dabei auf TIC-80 gestossen:


    https://tic.computer
    https://github.com/nesbox/TIC-80/wiki


    Ist kostenlos (Pro Version kostet 5 US$) und verfolgt ein ähnliches Konzept. Klingt erstmal interessant.

  • Ich habe so meine Zweifel, ob von den geplanten Rechnern alle Realität werden. Es gibt mittlerweile einfach zu viele.


    Warum würdet ihr euch einen holen, was reizt euch daran? Was wollt ihr damit machen, arbeiten, spielen, programmieren...?


    Am Mega hatte mich die Vorstellung gereizt, einen Nachbau des legendären C65 zu haben. Einen neuen alten Commodore, der unglaublicherweise doch noch hergestellt und verkauft wird. Mittlerweile ist mir das Gerät aber zu weit davon abgekommen. Es hat vielleicht auch einfach zu lange gedauert, es wurde zu viel diskutiert und schlecht geredet, die Faszination ist jetzt weg.

  • @tilobyte ich glaube nicht dass der Thread den Anspruch hat, dass hier wirkliche Projekte draus entstehen. Ich denke es geht hier eher einfach nur mal darum, sich gedanklich damit zu beschaeftigen. In der Tat ist es mir auch schon aufgefallen dass es immer mehr solche Projekte gibt, und so langsam fragt man sich, wer soll die alle nutzen. Ich selbst habe auch mal angefangen sowas rein virtuell zu programmieren, also sowas wie PICO-8 aber halt eher nach meinem Geschmack, habe ich aber schnell wieder auf Eis gelegt weil es einfach ein Fass ohne Boden ist - und auch wirklich schon genug Alternativen gibt.


    Was ich mir tatsaechlich zufaellig heute aber auch mal ueberlegt habe: Wie wuerde ein C64-Nachfolger aussehen, der zum C64 kompatibel waere, aber ohne dafuer einen zweiten Modus zu besitzen. Also nicht wie der C128 oder der C65, bei denen man dann "GO64" eingibt und man ploetzlich im C64-Modus ist, sondern ob es auch moeglich waere, einen Nachfolger zu bauen, der zu jeder Zeit kompatibel ist, aber einfach noch mehr kann. Zum Beispiel mit mehr Speicher, der dann ueber ein bislang ungenutztes RAM-Register gemappt wird (logischerweise wuerde das die Kompatibilitaet fuer diejenigen Programme "breaken", die dieses Register schon fuer was anderes nutzen - aber je nachdem welches Register man nimmt koennten das dann wirklich nur Ausnahmen sein). Oder mit mehr Farben, die mithilfe der oberen 4 Bit des Color-RAM festgelegt werden koennten, usw. Das faende ich irgendwie einen interessanten Ansatz. Aber auch hier ist klar, dass das nur eine von vielen Moeglichkeiten ist, und es auch keinen wirklichen Grund gibt, das jetzt genau so zu machen.

  • 8-Bit Style
    Persönlich finde ich neue Computer mit 8 Bit-Prozessoren nicht interessant genug. Echte 8 Bit-Computer wie C64, CPC, AppleII, AtariXL etc gibt es bereits genug, die alle ihren eigenen Charme haben, und deren Potential immer noch nicht ausgeschöpft ist. Ein neuer 8 Bit-Computer steht in direkter Konkurrenz zu diesen alten Schätzchen, und diesen Vergleich wollen die Entwickler neuer Hardware zu ihren Gunsten dadurch entscheiden, indem sie ihren neuen Kisten Fähigkeiten verleihen, die den damaligen[tm] nicht entsprechen wie z. B. viele superbunte Sprites und hochauflösende Bitmapgraphik. Doch dieser Widerspruch zwischen echtem 8 Bit-Style und den künstlich aufgebohrten Eigenschaften neuer "Traumcomputer" wirkt auf einige Leute eher abschreckend als motivierend, zumal das Ungleichverhältnis zwischen Graphikfähigkeiten und Prozessorpower dazu führt, daß auch weitere Teile wie die Prozessorgeschwindigkeit weiter hochgeschraubt werden, was am Ende mit 8-Bit Style wenig zu tun hat.


    CPU:
    Ein 65816 ist ein 16 Bit-Prozessor mit einem Adreßraum von 16 MB. Und dazu noch etwas umständlich zu programmieren. Meines Erachtens keine gute Wahl. Doch folgt im Grunde genommen ein 16 Bit-Prozessor den Wünschen nach einem im Rom eingebauten Assembler sowie anderer Software. Denn diese ist nur dann wirklich möglich, wenn man einen Rechner definiert, der in seinen Grundeigenschaften in einer höheren Liga angesiedelt ist als pure 8 Bit. Die Frage wäre daher wohl: Warum nicht gleich so ehrlich sein und einen Prozessor nehmen, der mindestens ein 16 Bit-, besser ein 32 Bit-Prozessor ist wie z. B. der 68000 (s. Kiwi)? Der Vorteil wäre dabei, daß man für solch ein System auch in einer Hochsprache Programme schreiben könnte, die mittels eines simplen Compilers in Assembler übersetzt werden. Die 6502-Familie ist bezüglich Hochsprache ja eher eine ungünstige Zielplattform. Möchte man schnell viele, neue Software haben, sollte man sich nicht darauf verlassen, daß sich alle Leute mit Assembler herumquälen wollen. Beim C64 lernt man zuweilen auch viele Jahre später noch freiwillig Assembler, weil man halt damals irgendwie damit angefangen hat und nun gerne wissen will, wie der alte Rechner und seine tollen Demos denn intern funktionieren. Sich heutzutage in eine komplett neue Hardware einzuarbeiten und diese dann in Assembler anzusprechen, ist hingegen eine sehr zeitraubende Herausforderung, die bei Normalsterblichen schnell für Frust sorgen kann und nur für Programmierfreaks auf Dauer interessant genug bleibt.
    Apropos interessant: Wenn es ein neuer Rechner sein soll, würde ich erwarten, daß der Rechner auch neue, spannende Konzepte mitbringt, um reizvoll genug zu sein, damit seine Freizeit zu verbringen. Ein Prozessor, der vor Jahrzehnten schon langweilig oder unzureichend war, bietet keine ausreichende Motivation. Das kennt man alles schon. Da kann man gleich beim C64 bleiben. Aber ein Prozessor mit neuem Design, das sich signifikant unterscheidet vom klassischen 6502/Z80/6809/68000, dürfte auch länger für Spaß bei der Erforschung der Möglichkeiten sorgen.


    Preis:
    Was spräche tatsächlich für den Kauf eines neuen Systems? Spiele spielen? Kann man woanders genug. Programmieren lernen? Geht besser auf dem PC. 100 Euro halte ich daher für eine Schmerzgrenze, vielleicht noch bis 150 Euro, aber dann dürfte bei vielen Schluß sein, denn Kosten für eine eigentlich sinnfreie Anschaffung dürfen nicht weh tun, zumal man für so viel Geld schon ganz andere, leistungsfähigere Hardware bekommt, und wenn ein Gerät nicht einmal den Nostalgiefaktor besitzt wie ein C64, könnte die Anzahl der Käufer sehr klein bleiben.


    GUI:
    Natürlich sollte ein neues Gerät direkt in eine GUI booten. Dazu gehört auch ein brauchbares OS und kein "OPEN15,8,15 blabla s0:datei blabla CLOSE". Nur weil man damals in der Benutzerführung wenig erfinderisch und masochistisch spartanisch war, bedeutet das nicht, daß man sich heutzutage damit zufrieden geben müßte. Wenn man schon umfangreiche Software im Rom will, sollte man auch deren Aufruf simpel und komfortabel gestalten. Wir haben damals[tm] an der Schule mit UCSD-Pascal gearbeitet. Das kannte zwar keine Graphik, aber dafür ein Menüsystem, bei dem man durch einfaches Eintippen eines Buchstabens Funktionen wie "Datei löschen", "Kompilieren" usw. aufrufen konnte. Dieses System wurde für den AppleII entwickelt Ende der 1970er, erschien also noch vor dem C64.


    Sprache:
    Bitte kein Basic. Und schon gar nicht ein zeilenorientiertes. Das war damals schon schlecht. Wenn schon, dann bitte einen echten Texteditor, mit dem man Programme z. B. in Pascal schreiben kann. Wie ich woanders schon öfters angemerkt habe: Aus einem aufgepeppelten Basic wird früher oder später sowieso was Pascal-ähnliches. Da kann man auch das Original nehmen, zumal sich damit Programme besser schreiben lassen als in Basic. Fragt sich allerdings, ob es wirklich eines Ccompilers oder Assemblers auf dem Zielrechner bedarf. Selbst wenn der Rechner mit 100 Mhz laufen würde, wäre er immer noch erheblich langsamer als ein Crossassembler/-compiler auf dem PC. Bitte nicht vergessen: Damit das Assemblieren/Kompilieren einigermaßen schnell vonstatten geht, ist es notwendig, den Programmtext bzw. den daraus erzeugten Tokencode im Speicher zu halten zusammen mit dem zu generierenden Objektcode. Die 64 kb eines echten 8 Bit-Rechners sind dafür zu wenig. Zumindest würde ich mir die Konsequenzen (Aufteilung eines Programms in viele, viele, kleine Module) heute nicht mehr antun wollen.


    Kompatibilität:
    Halte ich für keine Voraussetzung. Wäre ein netter Bonus, aber... kompatibel zu was? C64? CPC? AppleII? Es gibt ja außerhalb des Forum64 auch Anhänger anderer Rechner (und vereinzelt sogar hier). Egal welchen Homecomputer man als Vorbild nimmt, wird man mit der Wahl irgendwelchen anderen Retrofans vor den Kopf stoßen.

    Fiele die Wahl auf den 65816, könnte man natürlich gucken, ob man die dafür existierende Software (SNES oder Apple IIGS) lauffähig bekommt

    Bedaure, aber das halte ich für utopisch. Dies würde bedeuten, daß man diese Programme disassembliert und alle Hardware, aber auch OS spezifischen Routinen anpaßt an das neue Zielsystem. Der Aufwand ist viel zu groß, und es dürfte auch kaum jemanden geben, der dazu in der Lage wäre.


    Grafik:
    Alles bis zu einer Auflösung von 640x400 halte ich noch für vertretbar. 640x200 gab es schon auf dem CPC oder dem Apple//gs, und falls man ernsthaft Anwendersoftware für ein neues Gerät schreiben wollte, wären Auflösungen von 640 horizontal, aber auch 400 vertikal besser geeignet. Wichtig ist, sich zu fragen, wie hoch die Farbanzahl sein "darf". Der Amiga konnte mittels Interlace schon 640x400x16 aus einer Palette von 4096 realisieren, ist aber auch kein 8 Bit-Rechner mehr. HiColour in solch hoher Auflösung halte ich für zu viel und wäre technisch aufwendig zu realisieren. Eine Palette aus 512 Farben wäre für mich persönlich noch akzeptabel. Grundlegend ist es aber schwierig, hier eine feste Grenze zu ziehen, aber eine Grenze braucht es sicherlich, denn: Je mehr Farben, desto höher die Ansprüche der Benutzer, je größer die Arbeit für Graphiker, umso weniger Spaß für die Entwickler.


    Hardware und Emulator:

    Wenn ich einen Retrocomputer entwickeln würde, dann wäre für mich ein reines Softwareprodukt (Emulation) sowieso der erste Schritt, bevor ich auch nur ein "echtes" Bauteil anfassen würde.

    :dafuer: Das halte ich für einen sehr brauchbaren Weg. Zuerst einmal das Konzept an einem Emulator ausgiebig austesten und erst später, wenn wirklich alles stimmig ist, in Hardware gießen. Ein kostenloser Emulator dürfte zur Verbreitung sicherlich beitragen ähnlich wie Vice, WinUAE oder AppleWin. In dieser Hinsicht ist es für mich unverständlich, warum es bei den neuen Systemen keine Emulatoren gibt, die die Fähigkeiten der neuen Hardware nachbilden, aber dabei für Programmierer wichtige Tools mitbringen wie Debugger und Assembler. Man stelle sich vor, daß Software für den C64 nicht am PC mittels Vice (oder anderer Emulatoren) entstehen könnte, sondern nur am Original-C64. Wieviele Neuerscheinungen gäbe es dann pro Jahr? Wie sähen die aus?


    C64 kompatibel:

    Zum Beispiel mit mehr Speicher, der dann ueber ein bislang ungenutztes RAM-Register gemappt wird

    Wie meinst Du das mit dem RAM-Register? Zusätzliches Banking wie beim Easyflash?

    Oder mit mehr Farben, die mithilfe der oberen 4 Bit des Color-RAM festgelegt werden koennten

    Da dürfte es mit einigen existierenden Programmen Probleme geben, die irgendwelche Werte in die oberen 4 Bits schreiben. Der Gewinn von zusätzlichen 4 Bits wäre auch nur minimal. In dem Thread zum Mega65 hatte ich eine andere Lösung vorgestellt, wie man die klassischen Graphikmodi des C64 für Zeichensatz und HiRes-Bitmap mit Hilfe einer zusätzlichen 64 kb-Bank farblich erweitern kann, ohne daß sie ihre C64-Artigkeit verlieren.


    Traum-Typen:
    Wenn ich mir so die Diskussionen angucke, bemerke ich zwei Typen von "Traumcomputer": 1.) Ein neuer Rechner unabhängig von bestehenden Systemen, aber irgendwie alter Hardware entsprechend. 2.) Eine Weiterentwicklung eines alten Rechners nach dem Prinzip: Was wäre damals möglich gewesen?
    Schwierig wird es, beide Vorstellungen miteinander zu vereinen. Beim Mega65 sehe ich noch nicht richtig, wie das funktionieren soll. Die echten Bitmapfähigkeiten des C65 sind ziemlich unbrauchbar, dafür gibt es andere, neue, die das Niveau eines 8 Bit-Rechners überschreiten.
    Mir persönlich würde z. B. ein Rechner vorschweben, der (wie in dem anderen Thread beschrieben) den VIC in seinen Fähigkeiten behutsam erweitert, aber noch so, daß sie vertraut und beherrschbar sind. Außerdem sollte der Prozessor ersetzt werden mit einer ISA, die zwar 6502-kompatibel bleibt, jedoch ansonsten mehr Register und mehr Adressierungsmodi bietet, welche ihn zum einen eigenständig und interessant machen für eine Programmierung direkt in Assembler und zum anderen auch als Zielplattform für Hochsprachen geeignet machen. Ich bin sicher, ein Nachfolger eines C64 in dieser Art wäre machbar, hätte aber keine Ähnlichkeit mit dem doch eher unausgegorenen offiziellen Nachfolgerversuch C65. Und sicherlich würden sich viele Stimmen erheben, die sagen, solch ein Rechner würde den C64 kaputtmachen. Von daher dürfte Typ 2 "Weiterentwicklung" tatsächlich stets ein Traum bleiben. Bei Typ 1 liegt es halt "nur" am Willen und Können der Entwickler.

  • Ich schließe mich eher der Fortsetzungs-Fraktion an und bin da ganz bescheiden ...
    Ein C64 mit einem zusätzlichen VIC-II-Char-Mode wünsche ich mir:


    Und zwar analog zu diesem ..
    00 = Bildschirmfarbe
    01 = Multi1
    10 = Multi2
    11 = Farbspeicher für 8 Farben mit HiRes-Option


    noch diesen ..
    00 = Bildschirmfarbe (oder Kachel-Hintergrundfarbe, s.u.)
    01 = Unteres Nibble eines zusätzlichen 1kB-RAM-Abschnitts in aktueller VIC-Bank
    10 = Oberes Nibble .. s.o.
    11 = Farbspeicher für 16 Farben ohne HiRes-Option


    und noch besser wäre es mit dem oberen Nibble des Farbspeichers für die jeweilige Kachel-Hintergrundfarbe.
    Ob andere Spiele darin herum "poken", ist egal, denn es muss bei den bisherigen Modi ja keinen Effekt hervorrufen.


    Spiele, die auf MC-Char-Mode basieren, ob SCUMM-Adventures oder Shoot-'Em-Up-Scroller, sähen mit einem solchen Modus um ein Vielfaches besser aus, ohne dass man schon an der Palette schrauben müsste.


    Beispiel: Warum ist es wohl draußen immerzu dunkel (dunkelblau), wenn man in Zak McKrackens Wohnung durch Wohnzimmer- oder Küchenfenster schaut? Weil braun (09) für Fensterrahmen und Küchenzeile und hellgrau (15) für die Wände und Decke bereits die Multi-Register belegen und dann ein Hellblau (14) nicht mehr möglich ist. ZLORFIK! Die ganze Bude hätte in echtem Multicolor viel besser ausgesehen.


    Man kann natürlich diesen Modus so in etwa per Programm nachahmen. Der 6510 hat ja auch sonst nix zu tun. Ist aber wohl eher nichts für schnelle Scroller.



    Ansonsten vllt. noch: Vier bis sechs SID-Stimmen hatte ich immer gern gewollt, allein schon, um Musik und Sounds besser parallel abspielen zu können.
    Und last but not least: Das direkte schnelle Nachladen von einem Flashspeichermedium, damit das Warten und Discjockeyspielen ein Ende findet.

  • Auflösung: 512 x 212 (4 oder 16 Farben aus 512) und 256 x 212 (16, 256, 12499 oder 19268 Farben)

    Ich finde andere horizontale Auflösungen als nur immer 320 oder 640 auch ganz interessant, 400, 480 oder 512 sind auch mal ganz schön. Wenn man dennoch 80 Zeichen (außerhalb von Bitmap) darstellen will, müsste man weitere Char-Mode Varianten anbieten, die nicht mit 8 Pixel breiten Chars arbeiten, sondern z.B. mit 6 Pixeln (bei 480 wären das dann 80 Zeichen). Wäre das wohl auf einem 8-Bitter denkbar ohne große Performance-Verluste?


    Video per HDMI

    In einem der anderen Threads wurde davon gesprochen, dass HDMI Lizenzkosten-pflichtig wäre. Und zwar nicht nur pro Stück (das wäre verschmerzbar), sondern auch mit einer zusätzlichen Einmalzahlung (was für ein kleines Projekt dann nicht zu stemmen wäre).


    Eine Art Expansionsport, um auch hier die Kreativität für interessante externe Erweiterungen zu fördern

    Du hast recht, auch an die Hardware-Bastler sollte man denken und da was anbieten.


    So ein Ensoniq ES-5503 klingt nicht mehr nach SID..
    Der hat Wavetable OnBoard und kann Samples abspielen, passt das zu 8Bit- Rechner?

    Ich dachte halt, es würde gut zum 65816 passen. Vielleicht ist das aber doch etwas zu viel. Ein bisschen 8-Bittiger darf es ruhig klingen.


    Ich habe so meine Zweifel, ob von den geplanten Rechnern alle Realität werden. Es gibt mittlerweile einfach zu viele.
    Warum würdet ihr euch einen holen, was reizt euch daran? Was wollt ihr damit machen, arbeiten, spielen, programmieren...?

    Um mich vom Kauf zu überzeugen, müsste das Gerät "coole" Features haben, die bei einem anderen Gerät (zumindest in der Kombination) noch nicht (oder in seltener Form) existierten. So ein Rechner muss sich abheben von schon existierenden Geräten. Mit "abheben" meine ich aber nicht "übertreffen". Wahrscheinlich darf es aber auch nicht ZU anders sein, weil sich dann evtl. keine Entwickler daran trauen und dafür was programmieren. Obwohl man für die natürlich auch neue Herausforderungen schaffen muss, weil es sonst zu langweilig wäre. Es ist wahrscheinlich eine Gradwanderung. Ich persönlich fände es cool, wenn man das Gerät in einer Hochsprache programmieren könnte – aber so, dass das Ergebnis wirklich "professionell" wäre, nicht wie das meiste, was in BASIC produziert wurde. Dafür bräuchten man entweder einen Compiler oder die Kiste müsste schnell genug für den Interpreter sein. Die Grafik müsste "schlecht genug" sein, damit das manuelle Pixeln noch wirklich Sinn macht. So ab Amiga-Fähigkeiten würde ich wahrscheinlich Sprites und Backgrounds nur noch 3D-rendern und das Ergebnis dann weiter verwursten. Ich würde versuchen, direkt auf der Machine ganz einfache Sachen zu coden (nur so zu Trainingszwecken), wenn die Fähigkeiten der Maschine dafür ausreichen. Klar, spielen will ich natürlich auch – und zwar nicht nur 1:1-Umsetzungen bekannter Titel, die ich genauso auf einer anderen Maschine spielen könnte. Irgendwas muss halt "besonders" und typisch sein. Was das genau sein soll, versuche ich hier gerade heraus zu bekommen.

  • und noch besser wäre es mit dem oberen Nibble des Farbspeichers für die jeweilige Kachel-Hintergrundfarbe

    Da hast Du recht. Das ist eine gute Idee. :thumbup:


    (*herauskram...*)
    Mein Vorschlag sah folgendermaßen aus:
    - Speichererweiterung auf mindestens 128 kb, entweder mittels zweier 8 Bit-Busse wie beim AppleII mit 80 Zeichenkarte oder als 16 Bit-Bus mit Auswahl des upper/lower-Bytes beim Lesen und Schreiben.
    - VIC und Prozessor bekommen die Möglichkeit, in jedem Taktzyklus auf 16 Bit im Speicher zugreifen zu können, 8 Bit aus der 64 kb Bank 0 und 8 Bit aus der 64 kb Bank 1.
    - Die Lage von Textspeicher, Zeichensatz oder Bitmap wird unverändert durch $d018 und der ausgewählten VIC-Bank bestimmt. Bei einem neuen Modus würde dann jedoch der Textspeicher z. B. bei $400 liegen und der neue, zusätzliche Farbspeicher bei $10400.
    - Die Farbinformationen werden ermittelt wie von atomcode beschrieben:
    00 = Kachel-Hintergrundfarbe (obere 4 Bits im Farbram)
    01 = Unteres Nibble eines zusätzlichen 1kB-RAM-Abschnitts in aktueller VIC-Bank, aber in der Speicherbank 1
    10 = Oberes Nibble .. s.o.
    11 = untere 4 Bits im Farbram
    - Zusätzlich zu dem erweiterten Farbspeicher kann auch der Zeichensatz gedoppelt werden. Die erste Hälfte liegt - wie gehabt - in Bank 0. Die zweite Hälfte in Bank 1. Für die Ermittlung des obigen Bitmusters werden nicht zwei aufeinanderfolgende Bits des Zeichensatzes genommen, sondern ein Bit aus Zeichensatz 0 und ein Bit aus Zeichensatz 1. Der Zeichensatz ist damit organisatorisch in sich aufgebaut wie im normalen HiRes-Modus (Standardzeichensatz). Aufgrund der neuen Bits im zweiten Teil erreicht man jedoch vier Farben pro Zeichen im HiRes-Modus und damit eine Auflösung von 320x200 Pixel anstatt 160x200.
    - Auf gleiche Weise kann die Auflösung der Sprites verdoppelt werden. Multicolour entspricht dann ebenfalls dem jetzigen HiRes (320x200).


    Mit dieser kleinen Änderung umgeht man einige (zuweilen doch recht nervige) Beschränkungen, ohne daß solch ein Nachfolger-VIC in seinem Charakter zu sehr von seinem Vorgänger VIC II abrückt, was ihn hoffentlich auch für VIC II Pixler interessant macht.


    Was man bräuchte auf Softwareseite, wäre ein neues VIC-Register, mit dem man diese erweiterten Fähigkeiten ein- und ausschalten kann, z. B.:


    - Bit 0:
    1 = Deaktivierung der Umschaltung zwischen HiRes und Multicolour im Zeichensatzmodus (unteres Nibble im Farbram ist nur Farbe)
    - Bit 1:
    1 = zusätzliche Hintergrundfarbe im Farbram (oberes NIbble)


    - Bit 2:
    1 = zusätzliches Farbram in Bank 1 für zwei individuelle Farben pro Kachel
    - Bit 3:
    1 = Dopplung des Zeichensatzes bzw. der Bitmap für neuen 4-Farben HiRes-Modus (analog zum alten Multicolour-Modus)
    - Bit 4:
    1 = Dopplung der Sprites (wie bei Bit 3)



    Rein technisch sollte solch ein VIC-Nachfolger möglich sein, da zwar die Auflösung behutsam angehoben wird, aber die sonstige Vorgehensweise intern ziemlich identisch ist.


    Als echten neuen Modus würde sich vielleicht ein 640x200 Bitmapmodus anbieten, der ähnlich funktioniert wie der jetzige 320x200 HiRes-Modus. Damit ließe sich dann eine freie 80 Zeichen-Textausgabe erreichen für Anwendungsprogramme. Bei einem 80 Zeichen-Textmodus wäre ich jedoch skeptisch, ob man den wirklich braucht.


    Retrofan : Was würdest Du von solch neuen Darstellungsmodi halten? Wäre das noch im Rahmen des Vertretbaren oder schon zu gut?

  • Hey,


    warum in die Ferne schweifen wenn das Gute liegt so nah ... heute und morgen sogar in München auf der Make:
    ein neuer 6502-Computer zum Mitbauen - das Steckschwein: https://steckschwein.de/


    Eine Lanze für die alten BASIC-Dialekte:
    Um ein Verständnis für die Arbeitsweise einer CPU zu erlangen, waren die alten Basic-Dialekte ideal. Einfacher in der Anwendung als Assembler aber die Programmlogik nahe an der Arbeitsweise der CPU:
    - die Zeilennummern - so liegt das Programm im Speicher
    - GOTO Zeilennummer - Einsprungadresse JMP
    - GOSUB + RETURN - Rücksprungadresse auf dem Stack
    - READ + DATA - so liegen Anwendungsdaten im Speicher
    - PEEK und POKE - direktes Interagieren mit der Hardware
    All das fehlt den derzeitigen "Einsteigersprachen". Mag sein, dass man mit Python verschiedene Programmierparadigmen ausprobieren kann und es sich auch für die verschiedensten Aufgabengebiete eignet, aber ein Verständnis für die Hardware vermittelt Python nicht. Von Scratch ganz zu schweigen...
    Fazit: nichts geht über einen Computer, den man bis ins letzte Bit beherrschen kann: Retro oder Homebrew


    Grüße

  • dieser Widerspruch zwischen echtem 8 Bit-Style und den künstlich aufgebohrten Eigenschaften neuer "Traumcomputer" wirkt auf einige Leute eher abschreckend als motivierend, zumal das Ungleichverhältnis zwischen Graphikfähigkeiten und Prozessorpower dazu führt, daß auch weitere Teile wie die Prozessorgeschwindigkeit weiter hochgeschraubt werden, was am Ende mit 8-Bit Style wenig zu tun hat.

    Das sehe ich genauso. Ganz wichtig ist die Balance aller Bestandteile. Und man darf es nicht übertreiben.


    Ein 65816 ist ein 16 Bit-Prozessor mit einem Adreßraum von 16 MB. Und dazu noch etwas umständlich zu programmieren. Meines Erachtens keine gute Wahl. Doch folgt im Grunde genommen ein 16 Bit-Prozessor den Wünschen nach einem im Rom eingebauten Assembler sowie anderer Software. Denn diese ist nur dann wirklich möglich, wenn man einen Rechner definiert, der in seinen Grundeigenschaften in einer höheren Liga angesiedelt ist als pure 8 Bit. Die Frage wäre daher wohl: Warum nicht gleich so ehrlich sein und einen Prozessor nehmen, der mindestens ein 16 Bit-, besser ein 32 Bit-Prozessor ist wie z. B. der 68000 (s. Kiwi)?

    Vom Programmieren her mag ein 68000 angenehmer sein als ein 6502 (bzw. Nachfolger). Aber sobald die Leute an 16/32-Bit denken, steigen die Wünsche und Hoffungen noch viel weiter als bei den 8-Bit-Konzepten. Ich denke, man kann den Interessenten einen hochgerüsteten 8-Bit-Rechner besser schmackhaft machen als einen abgespeckten 16-Bit-Rechner.


    Ich könnte mir durchaus vorstellen, einen Rechner zu haben, der eine 68000-CPU drin hat aber geringere Fähigkeiten als ein Amiga (was Grafik und Sound angeht). Aber irgendwie ist man dann beim Ur-Atari-ST, oder? Da haben wir 320/640 x 200 Pixel in 16 Farben und 640 x 400 Pixel monochrom. Eigentlich das, was ich mir durchaus vorstelle für meine "Dream-Machine". Also ist es eigentlich ein ST, den ich haben will. Perfekt, den muss ich nicht bauen, den habe ich schon hier. ;)


    Aber Spaß beiseite – wie schon gesagt: Mit einem "ungewöhnlichen" 8-Bitter kann man sicherlich mehr Leute locken als mit einem "schwachen" 16-Bitter.


    Die 6502-Familie ist bezüglich Hochsprache ja eher eine ungünstige Zielplattform. Möchte man schnell viele, neue Software haben, sollte man sich nicht darauf verlassen, daß sich alle Leute mit Assembler herumquälen wollen.

    Ich sehe es auch so: Die neue Maschine soll mit einer Hochsprache daherkommen, die was taugt. Was genau macht den 6502 für Hochsprachen ungeeignet? Der Apple II wurde doch seit eh und je mit PASCAL programmiert (Apple/UCSD-Pascal).


    Aber ein Prozessor mit neuem Design, das sich signifikant unterscheidet vom klassischen 6502/Z80/6809/68000, dürfte auch länger für Spaß bei der Erforschung der Möglichkeiten sorgen.

    Du plädierst als für einen "neuen" Prozessor für die Retro-Maschine. Einen, der vielleicht weitgehend 6502-kompatibel ist aber Fähigkeiten modernerer Prozessoren aufweist (ohne ein 65816 oder 4502 (der im C65 steckte) zu sein). Gut, in einem FPGA kann man ja quasi jede erdenkliche CPU abbilden, auch welche, die es in echt nicht gibt. Eine neue CPU könnte das Projekt zusätzlich interessant machen.


    100 Euro halte ich daher für eine Schmerzgrenze, vielleicht noch bis 150 Euro, aber dann dürfte bei vielen Schluß sein, denn Kosten für eine eigentlich sinnfreie Anschaffung dürfen nicht weh tun

    Das deckt sich mit meinen Vorstellungen. 2 der 3 oben genannten Systeme sind aber leider raus aus der Definition.


    Natürlich sollte ein neues Gerät direkt in eine GUI booten. Dazu gehört auch ein brauchbares OS und kein "OPEN15,8,15 blabla s0:datei blabla CLOSE". Nur weil man damals in der Benutzerführung wenig erfinderisch und masochistisch spartanisch war, bedeutet das nicht, daß man sich heutzutage damit zufrieden geben müßte.

    Ich bin ja für ein Booten in den Quelltexteditor (der deutlich mehr sein sollte als der vom PET/C64). Einfach für das originale 8-Bit-Fealing. Das soll aber nicht heißen, dass es keine Annehmlichkeiten bzgl. Benutzerführung geben soll. Natürlich soll man sehr einfach auf Ressourcen, wie die SD-Karte, zugreifen können, ohne sich dafür komplizierte Kommandos merken zu müssen. Ich gehe schon von Menü-Steuerung und solchen Sachen aus. Das kannte ich auch schon in den 80ern, allerdings von Multiuser-Systemen.


    Bitte kein Basic. Und schon gar nicht ein zeilenorientiertes. Das war damals schon schlecht. Wenn schon, dann bitte einen echten Texteditor, mit dem man Programme z. B. in Pascal schreiben kann. Wie ich woanders schon öfters angemerkt habe: Aus einem aufgepeppelten Basic wird früher oder später sowieso was Pascal-ähnliches.

    BASIC hat halt den Vorteil, dass es viele zu kennen glauben. PASCAL kennen halt nicht so viele aus ihrer Kindheit. Deswegen plädierte ich ja schon mal für eine Mischkonstruktion, die zwar wie PASCAL funktioniert aber viele Befehle in BASIC-manier nutzt. Es ist ja letztlich egal, ob man print oder writeln schreibt. Man könnte so eine Maschine sogar mit unterschiedlichen Programmiersprachen ausliefern und es dem User überlassen, welche er im Editor verwenden will. All die entstehenden Programme (erst recht, wenn sie kompiliert wurden) würden ja auf der Maschine laufen.


    Selbst wenn der Rechner mit 100 Mhz laufen würde, wäre er immer noch erheblich langsamer als ein Crossassembler/-compiler auf dem PC. Bitte nicht vergessen: Damit das Assemblieren/Kompilieren einigermaßen schnell vonstatten geht, ist es notwendig, den Programmtext bzw. den daraus erzeugten Tokencode im Speicher zu halten zusammen mit dem zu generierenden Objektcode. Die 64 kb eines echten 8 Bit-Rechners sind dafür zu wenig.

    Ich denke, die meisten sprechen hier von einem Rechner, der im Bereich RAM nicht sehr große Einschränkungen hat. Mein Apple IIGS hat 3 MB drinstecken und sowas in der Richtung schwebt vielen hier vor. Über 64 KB (oder 2 Bänke à 64 KB) wollen die meisten dann doch nicht mehr reden. Ich fände es aber zusätzlich cool, wenn man eine Programmiersprache hätte, die interpretiert, wie kompiliert laufen könnte, damit man die turn-around-Zeiten verringern kann. So könnte man während der Entwicklung schnell Probeläufe machen und am Schluss dann kompilieren, um die volle Performance zu bekommen (und Laufzeitfehler zu vermeiden).


    Kompatibilität:
    Halte ich für keine Voraussetzung. Wäre ein netter Bonus, aber... kompatibel zu was? C64? CPC? AppleII?

    Zu was auch immer. Einfach nur, damit man schon am Anfang mal was starten könnte, solange noch keine nativen Apps existieren. Man könnte ja wahrscheinlich recht einfach einen vorhandnen Core in den FPGA packen (wenn man einen FPGA als gute Lösung ansieht und der Platz dafür reicht).


    Bedaure, aber das halte ich für utopisch. Dies würde bedeuten, daß man diese Programme disassembliert und alle Hardware, aber auch OS spezifischen Routinen anpaßt an das neue Zielsystem. Der Aufwand ist viel zu groß, und es dürfte auch kaum jemanden geben, der dazu in der Lage wäre.

    Da hast du mich evtl. falsch verstanden. Ich meinte nicht, dass man die Programme portieren soll, sondern in den FPGA um die identische CPU herum optional die ganze andere Plattform abbilden könnte, um die Programme laufen zu lassen. Der IIGS wäre wahrscheinlich einfacher nachzubilöden als das SNES, denke ich. Und den IIGSD haben auch nur wenige herumstehen, was die Software für viele User exotisch macht. Und man hätte gleich schon ein GUI (GS/OS) zum Herumspielen mit der Maus.


    Alles bis zu einer Auflösung von 640x400 halte ich noch für vertretbar. 640x200 gab es schon auf dem CPC oder dem Apple//gs, und falls man ernsthaft Anwendersoftware für ein neues Gerät schreiben wollte, wären Auflösungen von 640 horizontal, aber auch 400 vertikal besser geeignet. Wichtig ist, sich zu fragen, wie hoch die Farbanzahl sein "darf". Der Amiga konnte mittels Interlace schon 640x400x16 aus einer Palette von 4096 realisieren, ist aber auch kein 8 Bit-Rechner mehr. HiColour in solch hoher Auflösung halte ich für zu viel und wäre technisch aufwendig zu realisieren. Eine Palette aus 512 Farben wäre für mich persönlich noch akzeptabel.

    Wie oben beschrieben: 640 Pixel (bzw. 80 Zeichen, als Bitmap bräuchte ich das gar nicht) wäre schon ganz schön. Für einen Editor (oder andere Anwendungen) würde die Pixelverdopplung in der Vertikalen aber nicht viel bringen, da dadurch nicht mehr Zeilen dargestellt werden könnten. Das Schriftbild wäre halt noch ein bisschen feiner aber ich habe gesehen, dass der C128 in 80 Zeichen (mit meinem Font) schon ganz gut lesbare Texte produzieren kann.


    Das halte ich für einen sehr brauchbaren Weg. Zuerst einmal das Konzept an einem Emulator ausgiebig austesten und erst später, wenn wirklich alles stimmig ist, in Hardware gießen. Ein kostenloser Emulator dürfte zur Verbreitung sicherlich beitragen ähnlich wie Vice, WinUAE oder AppleWin. In dieser Hinsicht ist es für mich unverständlich, warum es bei den neuen Systemen keine Emulatoren gibt, die die Fähigkeiten der neuen Hardware nachbilden

    Das Konzept gefällt mir auch. Erstmal einen Emulator entwickeln und dort gucken, ob das alles gut zusammenpasst – und erst dann das alles in Hardware gießen.


    Wenn ich mir so die Diskussionen angucke, bemerke ich zwei Typen von "Traumcomputer": 1.) Ein neuer Rechner unabhängig von bestehenden Systemen, aber irgendwie alter Hardware entsprechend. 2.) Eine Weiterentwicklung eines alten Rechners nach dem Prinzip: Was wäre damals möglich gewesen?

    Ja, die beiden Typen gibt es wohl.


    Mir persönlich würde z. B. ein Rechner vorschweben, der (wie in dem anderen Thread beschrieben) den VIC in seinen Fähigkeiten behutsam erweitert, aber noch so, daß sie vertraut und beherrschbar sind. Außerdem sollte der Prozessor ersetzt werden mit einer ISA, die zwar 6502-kompatibel bleibt, jedoch ansonsten mehr Register und mehr Adressierungsmodi bietet, welche ihn zum einen eigenständig und interessant machen für eine Programmierung direkt in Assembler und zum anderen auch als Zielplattform für Hochsprachen geeignet machen. Ich bin sicher, ein Nachfolger eines C64 in dieser Art wäre machbar, hätte aber keine Ähnlichkeit mit dem doch eher unausgegorenen offiziellen Nachfolgerversuch C65. Und sicherlich würden sich viele Stimmen erheben, die sagen, solch ein Rechner würde den C64 kaputtmachen.

    Ich könnte mich damit auch anfreunden. Allerdings müsste da deutlich mehr RAM rein als z.B. in den C128. Irgendwas im niedrigen MB-Bereich wäre schon ganz angenehm, vor allem für die Hochsprachen.

  • Aufgrund der neuen Bits im zweiten Teil erreicht man jedoch vier Farben pro Zeichen im HiRes-Modus und damit eine Auflösung von 320x200 Pixel anstatt 160x200.
    - Auf gleiche Weise kann die Auflösung der Sprites verdoppelt werden. Multicolour entspricht dann ebenfalls dem jetzigen HiRes (320x200).


    Mit dieser kleinen Änderung umgeht man einige (zuweilen doch recht nervige) Beschränkungen, ohne daß solch ein Nachfolger-VIC in seinem Charakter zu sehr von seinem Vorgänger VIC II abrückt, was ihn hoffentlich auch für VIC II Pixler interessant macht.


    Retrofan : Was würdest Du von solch neuen Darstellungsmodi halten? Wäre das noch im Rahmen des Vertretbaren oder schon zu gut?


    Die Grafik würde wahrscheinlich etwas NESsiger aussehen – ich könnte mir das ganz schick vorstellen – und es wäre wohl auch nicht "zuviel des Guten". Was die Grafik eines Systems aber auch immer sehr typisch macht, ist die Farbpalette. Ich könnte mir eine etwas optimierte C64-Palette vorstellen (es gibt deutlich schlechtere) – oder aber es gibt eine größere Palette (aber bitte nicht zu groß), aus der man sich seine 16 Farben (pro Screen) auswählen kann.


    Was noch ein großer Nerv-Faktor beim jetzigen VIC II ist, ist die Tatsache, dass man für Multicolor-Spites nur je eine Farbe frei wählen kann und alle anderen Farben identisch sein müssen. Ohne diese Einschränkung (also 2 oder alle 3 Farben frei wählbar) könnte man deutlich buntere Spiele gestalten.

  • Ohne diese Einschränkung (also 2 oder alle 3 Farben frei wählbar) könnte man deutlich buntere Spiele gestalten.

    Also das ist eben so eine Sache. Will man unbedingt mehr, dann bitte mit dem Amiga oder andere echter Hardware.


    Es gibt mitlerweile Spaßcomputer, die es nicht wirklich gibt, die sehr limitiert sind. Das ärgert mich richtig, J-Snake zeigte mir ein Spiel, das es auch bei Steam gibt, das lief auf einem C64er ähnlichen Maschine von der Grafik her, die es in Wirklichkeit nicht gibt. Aber Rechenzeit hat das Ding viel viel mehr als der C64er.


    Hat mich richtig geärgert.