Hallo Besucher, der Thread wurde 116k mal aufgerufen und enthält 824 Antworten

letzter Beitrag von RexRetro am

Commander 16: The8BitGuy plant einen neuen 8-Bit Computer

    Zitat von ZeHa

    Ich glaube das Problem ist, dass viele einfach "etwas mehr" haben wollen, daher erscheinen 16 Farben zu wenig. Das dumme ist aber, 32 Farben oder 64 Farben ist technisch doof umzusetzen. 16 Farben kann man mit einem Nybble abbilden, und 256 Farben mit einem Byte. Aber solche Zwischenwerte sind irgendwie technisch unlogisch. Das einzige was gehen wuerde, waeren 16 Farben gleichzeitig, die man aus einer breiteren Palette waehlen koennte.

    Es gibt auch die Variante wie beim C16/Plus4 : 16 Farben mit 8 Helligkeitsstufen.

    Apropos 12bit-LUT .. Die 256 Byte große Farbtabelle beim X16 ist folgendermaßen vorbelegt:


    Die ersten 16 Farben entsprechen den C64-Farben.

    Dann folgt eine 16-stufige Graustufen-Rampe.

    Und danach kommen noch 224 handverlesene Farben in unterschiedlichen Helligkeiten und Sättigungsgraden.


    Das heißt, wenn man auf 4bpp umschaltet (zwischen 4 und 8 gibt's nix), hat man automatisch die guten alten C64-Farben zur Auswahl. Bei 1bpp ist es s/w. 2bpp gibt es auch noch.

    Ich werde mal schauen, ob diese Farben, die ja im 12bit-Format (also aus 4096) angegeben sind, den Colodore-Farben entsprechen, wenn man die ebenfalls ins 12bit-Format konvertiert.

    Zitat von ZeHa

    Ich glaube das Problem ist, dass viele einfach "etwas mehr" haben wollen, daher erscheinen 16 Farben zu wenig. Das dumme ist aber, 32 Farben oder 64 Farben ist technisch doof umzusetzen. 16 Farben kann man mit einem Nybble abbilden, und 256 Farben mit einem Byte. Aber solche Zwischenwerte sind irgendwie technisch unlogisch. Das einzige was gehen wuerde, waeren 16 Farben gleichzeitig, die man aus einer breiteren Palette waehlen koennte.

    Ich finde auch 32 oder 64 Farben technisch nicht falsch - wenn man denn etwas vernünftiges mit den oberen Bits anstellt und sie nicht einfach ungenutzt lässt. Eine Idee wären Ebenen (im Falle von 64 Farben hätte man 4 Stück), die die Sprite-Hintergrund-Priorität steuern. Wenn z.B. bei deinem Sprite alle Pixel in Ebene 2 liegen, werden nur die Pixel tatsächlich gerendert, bei denen die Hintergrundpixel in Ebene 0 und 1 liegen. So etwas ist auch für Anfänger leicht zu verstehen.


    16 frei wählbare Farben würde ich auch gut finden. Bei 64 Farben würde ich eine feste Palette besser finden.

    Zitat von Retrofan

    Ich finde, das Game zeigt schon ein wenig, dass meine Befürchtungen nicht ganz unbegründet sind.


    a) Es ist sicherlich in Assembler geschrieben, weil BASIC V2 in Kombination mit der CPU selbst für so simple Games, wie Pac-Man (kein Scrolling, 5 bewegliche Objekte), nicht mehr ausreicht.

    b) Die Festlegung auf das 4:3-Seitenverhältnis, dem immer mehr Bildschirme (vor allem TVs) nicht mehr entsprechen. War aber auch klar bei einem VGA-Ausgang – ein Hurra auf schwarze Flächen (oder alte Bildschirme).

    c) Bei 256 möglichen Farben in der (verglichen mit dem C64) hohen Auflösung offenbart sich gnadenlos, wenn der Coder keinen guten Grafiker an seiner Seite hat und sich selbst an Sprite-/Char-Grafiken und sogar Full-Screen-Bildern versucht. Das sieht dann halt auch so aus. One-Man-Shows sind bei solchen Hardware-Fähigkeiten eigentlich passé. Die (im Vergleich) geringen Grafikfähigkeiten eines C64 lassen die Diskrepanz zwischen Wollen und Können nicht ganz so hervortreten und solche Coder-Graphics-Ergebnisse können dann sogar einen gewissen Charme ausstrahlen. Hier eher nicht.

    Ja, es ist vollständig in Assembler geschrieben. Dieses Spiel erinnert mich an die gute alte DOS-Zeit: 320x200x8bpp und Adlib-Sound. Sieht exakt wie ein Homebrew-Spiel für den 286er aus und entspricht in etwa dem, was ich mit 10-12 Jahren in Quickbasic hinbekommen habe (von der framegenauen Spritebewegung mal abgesehen). Ich find's toll, dass Menschen die Motivation haben so etwas auf dem X16 zu machen. Mir fehlt sie, weil ich immer das Gefühl hätte, dass ich an genau der Stelle schonmal war.

    Und ich hatte genau das Problem, was du in c) beschreibst. Die Grafik meiner Spiele sah - gemessen an den Möglichkeiten, die einem der Mode13 gegeben hat - immer mies aus.

    Zitat von atomcode

    Ansonsten ist es eben wieder was, das (von System bezogenen Peeks, Pokes und Sys' abgesehen) 100% abwärtskompatibel zum C64 ist, nur acht mal so schnell und mit neuen Möglichkeiten.

    Das stimmt übrigens nicht ganz. Das BASIC hat ein paar neue Schlüsselworte, die man dann nicht mehr als Variablennamen benutzen kann, wie z.B. MB, MX und MY. Außerdem behandelt es TI und TI$ nicht mehr getrennt. Beide kann man jetzt setzen und sie laufen unabhängig voneinander.


    Persönlich finde ich die Nähe zum C64-BASIC gut, weil es damit einfacher ist, meinen Basic-Cross-Compiler auch die X16-Programme compilieren zu lassen. Wäre das BASIC sehr viel anders, würde ich mir die Mühe schlichtweg nicht machen. Diese ganze Diskussion gab es in der Facebook-Gruppe übrigens schon X-mal. Das Ding ist aber: Darüber reden ist billig, Wünsche haben auch. Aber das dann zeitnah und korrekt umzusetzen, das passiert einfach nicht. Und wenn man sich dann darauf verlässt, dann ist man verlassen. Von daher kann ich gut verstehen, dass das Projekt was bestehendes nimmt und anpasst. Das ist besser planbar als wenn irgendwer irgendein Hirngespinst programmieren will und es nie beendet. Dann steht man zum Release nämlich mit leeren Händen da.

    Zitat von EgonOlsen71

    Von daher kann ich gut verstehen, dass das Projekt was bestehendes nimmt und anpasst.

    Das kann ich auch verstehen. Wenn man bedenkt, wie viele Jahre(!) allein für die Hardwareentwicklung draufgeht, dann ist es nachvollziehbar, dass man bei der Software auf Bewährtes und Bestehendes aufbaut. Und man hat dabei auch noch eine "Brücke" - in dem Fall - zum C64. Das würde ich nicht unterschätzen! Ein neuer "8 bit"-Rechner der so gut wie keinen Bezug mehr zu den bekannten alten Geräten hätte, würde irgendwie im Niemandsland hängen.


    Welchen Reiz sollte ein Rechner mit CPU (superneu) und Programmiersprache (nochvielneuer) haben? Man müsste erstmal alles neu lernen und das, um auf einem "alten" Rechner zu programmieren, der komplett der Fantasie eines Menschen der Jetztzeit entsprungen ist und keinen Bezug zu den alten Kisten hat, mit denen wir damalstm unsere Freizeit verbracht haben.


    Insofern macht man das beim X16 und auch beim Mega65 ganz richtig. Bekanntes, auf dem man dann schon aufbauen kann und doch Neues, das man gerne erkunden möchte. Das ist eine gute Mischung um uns "Alte" das "Neue" schmackhaft zu machen.

    Zitat von EgonOlsen71

    Das stimmt übrigens nicht ganz.

    Danke für die Richtigstellung.

    Werde gleich auch noch was richtigstellen:


    Zitat von atomcode

    Die ersten 16 Farben entsprechen den C64-Farben.

    Na ja, nicht wirklich. Hab ich mir gestern Abend noch angesehen. Ok, wir wissen, Farbpalette mag jeder anders, aber das, was ich da gesehen habe, ist dran vorbei ... hellgrün ist da gelbgrün, hellblau hat einen fetten Türkis-Stich, dunkelbraun ist heller als dunkelgrau, usw. - sieht bestimmt "gut" aus, wenn Grafiken vom Cevi übernommen werden, die zumindest die richtige Reihenfolge der Helligkeit voraussetzen.


    Ich hatte es ausprobiert: Mit 12 bit Farbauflösung kann man die Colodore-Farben, mit denen man dabei sicher nichts verkehrt macht, ausreichend gut treffen. Ich würde mir die Tabelle also auf jeden Fall überschreiben. Mit der aktuellen Tabelle sollte man bei 4bpp-Einstellung nicht glauben, man hätte per Default schon die C64-Farben. Die sind lediglich vom C64 inspiriert. Das sagte der Guy allerdings auch.


    Zitat von atomcode

    Dann folgt eine 16-stufige Graustufen-Rampe.

    Ja, eigentlich kann man dabei ja nichts verkehrt machen, sollte man meinen. $000, $111, $222, ..., $FFF ist in der Tabelle eingetragen. Ruft man die Farben auf, bekommt man allerdings was völlig anderes: $FFF sollte weiß sein, also $FFFFFF entsprechen. Es ist aber tatsächlich $CCCCCC. Auch die anderen Farben zeigen was anderes als sie sein sollten. Umgerechnet wird es normalerweise, indem pro Einheit pro Stelle $11 auf die korrespondierende RGB-Stelle dazukommen. Also aus $123 wird $112233. Das passiert im Emu jedenfalls nicht.


    Zitat von atomcode

    Und danach kommen noch 224 handverlesene Farben in unterschiedlichen Helligkeiten und Sättigungsgraden.

    Ja, außer dass sie handverlesen sind; falsche Info, sorry. Sind generische Farben: 8 Farbwinkel * 4 Sättigungen * 7 Helligkeiten = 224 linear abgestufte Farben für Roboteraugen, aber nicht für menschliche.

    Manche Farben sind dadurch doppelt, und andere, vor allem mit bestimmten Farbwinkeln, fehlen komplett, bspw. ein ganz ordinäres Gelb. Halte ich für sinnlos so etwas.


    Man sollte farbwahrnehmungstechnisch sinnvolle Winkel benutzen, also keine lineare Aufteilung. Eine logarithmische Helligkeitsabstufung bringt auch mehr. Sättigung und Helligkeit und Farbkombination wechselwirken, was sich durch lineare Aufteilung der RGB-Werte nicht berücksichtigen lässt. Man muss das Rad auch nicht neu erfinden; es gibt bereits gut aufgeteilte Farbtabellen.


    Das beste ist aber, dass mich das eigentlich gar nicht interessiert, weil ich eh immer nur 16 eigene benutzen würde. ^^


    Zum Sound noch mal. Ich finde, man sollte den VERA-Sound weiterhin in Anlehnung an den SID erweitern: Hüllkurven, Sync, Ring und Filter, den Digi-Streamer ordentlich stutzen und die ganzen anderen Soundchips rauswerfen. Spart nebenbei Kohle. Er will ja nach wie vor unter 100$ kommen.

    Zitat von atomcode

    Ich glaube, ein Rechner für Einsteiger, für Kids und für die Schule, so wie Retrofan ihn beschreibt und einer für Retro-Fans wie uns, das sind eher zwei verschiedene Rechner.

    Genau.


    Zudem kommt aber noch hinzu, dass auch RetroFans völlig unterschiedliche Bedürfnisse haben.


    Der eine spielt hauptsächlich, der andere coded gern, beim einen geht es um Design, Farben, Aussehen, dem anderen geht es nur um die Technik.

    Zitat von Diddl
    Zitat von atomcode

    Ich glaube, ein Rechner für Einsteiger, für Kids und für die Schule, so wie Retrofan ihn beschreibt und einer für Retro-Fans wie uns, das sind eher zwei verschiedene Rechner.

    Zudem kommt aber noch hinzu, dass auch RetroFans völlig unterschiedliche Bedürfnisse haben.

    Der eine spielt hauptsächlich, der andere coded gern, beim einen geht es um Design, Farben, Aussehen, dem anderen geht es nur um die Technik.

    Genau so ist das. Und dann gibt es noch die, wo der Preis auch noch eine wichtige Rolle spielt.

    Im schlimmsten Fall kommen da 5 völlig verschiedene Rechner raus. :D


    Die ganze Diskussion hier dreht sich ja fast nur darum, was man selber am liebsten hätte und nicht darum, was die größte potentielle Zielgruppe am liebsten hätte. Das geht teilweise völlig aneinander vorbei und deswegen ist die Diskussion ja so :popcorn:.

    Zitat von detlef

    Genau so ist das. Und dann gibt es noch die, wo der Preis auch noch eine wichtige Rolle spielt.

    Im schlimmsten Fall kommen da 5 völlig verschiedene Rechner raus. :D


    Die ganze Diskussion hier dreht sich ja fast nur darum, was man selber am liebsten hätte und nicht darum, was die größte potentielle Zielgruppe am liebsten hätte. Das geht teilweise völlig aneinander vorbei und deswegen ist die Diskussion ja so :popcorn:.

    Wenn es danach geht, ist C64-Kompatibilität quasi Pflicht - die haben DTV und TheC64 ja auch zum Erfolg verholfen.

    Zitat von detlef

    Die ganze Diskussion hier dreht sich ja fast nur darum, was man selber am liebsten hätte und nicht darum, was die größte potentielle Zielgruppe am liebsten hätte. Das geht teilweise völlig aneinander vorbei und deswegen ist die Diskussion ja so :popcorn: .

    Egal, welcher Retro-Computer noch gebaut wird, so ziemlich jeder wird wohl ein wenig tolerant sein müssen, um einen davon gut finden zu können. Ich z.B. möchte eigtl. nur 16 Farben, kann aber ein Auge zudrücken, wenn der Rechner auch 256 kann, aber dafür andere Dinge genau nach meinem Geschmack sind.

    Ich denke dann, wenn jemand etwas in C64-Farben macht und das verhältnismäßig gut aussieht bzw. besser als ein dahingerotztes 256-Color-Game, würde man es auch erkennen und zu würdigen wissen, ähnlich wie bei den Indie-Games.


    Zitat von Freddy

    (in "Neuer Retro-Computer ...")

    Mein damaliger 16-Bitter (286er @ 12 MHz) hatte 'ne OAK VGA-Karte (mit 512k RAM), und das lief wunderbar.

    Interessant, weil 8bit-Guy meinte, dass sein X16 etwa so schnell wie ein 286er @ 12 MHz sei (Teil 2 @ 44:27), aber hier befürchtet wird, VGA wäre dafür zu viel.

    Der C65 kann noch viel höhere Auflösungen, und bei 256 Farben kann er knapp die Hälfte vom X16, hat aber auch nur knapp die Hälfte an MHz.

    Zitat von Freddy

    (in "Neuer Retro-Computer ...")

    Und genau wie beim PC damals, laufen die Spiele im 320x200 Modus.

    Auch das sagte er, dass 320x200 oder 320x240 in erster Linie für Spiele gedacht ist und die höhere Auflösung für Textanwendungen, Programmieren u.ä. Das schöne ist, dass man Grafik und Text ohne weiteres überlagernd nutzen und so auch mal schnell eine kleine Grafik hinzufügen kann bzw. umgekehrt. Ich glaube nicht, dass ein Entwickler automatisch immer die höchste verfügbare Auflösung nehmen würde, wenn er dadurch eine Reihe von Nachteilen in Kauf nehmen muss. Hatte man beim Amiga auch nicht gemacht.

    Zitat von Freddy

    (in "Neuer Retro-Computer ...")

    Ob man da jetzt 256 oder 16 Farben nutzt, entscheidet der Spieldesigner.

    eeebänd! Wer meint, dass er mit 256 Farben noch genug Animations-Frames unterbekommt und dann noch genug Speed für Action über hat und das ganze auch noch harmonisch und ansprechend aussehen wird, der soll es probieren. Ich muss den nicht bevormunden. Was am Ende besser ankommt, das wird man ja sehen. Auch wüsste ich nicht, wofür ich ein Sprite als Overlay-Sprite zur künstlichen Grafik-Erweiterung bräuchte, wenn ich auf der Leinwand ohnehin schon alle gewählten Farben direkt nebeneinander darstellen kann, und das mit quadratischen Pixeln, die mir auch das Drehen ermöglichen und dadurch der Gestaltung freien Lauf lassen. Selbst, wenn man den Sprites eigene Farben zuweisen könnte, lohnte sich der Rechenaufwand nicht, wenn man stattdessen einfach die Palette vergrößern kann.


    Beim C64 hingegen habe ich stattdessen aktuell wieder (im MC-BMP-Modus) das Problem, dass ich auf eine Gestaltungsmöglichkeit verzichten müsste, weil die nur in einer Ausrichtung möglich ist. Da ich darauf aber nicht verzichten will, habe ich mich nach langem Hin und Her entschlossen, ein Overlay-Sprite hinzuzuziehen, und das, obwohl es davon nur 8 Stück gibt. Kurzum, es ist eher umgekehrt: Ich nutze keine Sprites als Overlay-Sprites, nur weil ich davon viele habe, sondern, wenn es eine Bitmap-Grafik an bestimmten Stellen einfach notwendig, sinnvoll oder hübscher macht - was beim X16 gar nicht mehr gegeben ist, wohl aber beim C64. Der ganze Aufwand für einen "ui, das sieht aber für C64 ziemlich gut aus"-Effekt.


    ---

    Aber auch beim "boa, wie hat der das alles in den Speicher bekommen"-Effekt frag ich mich manchmal, welchen Sinn das hat, wenn man doch eigentlich nur seine Spielidee verwirklichen wollte.

    Beispiel für typische und langwierige Gedanken dazu:


    Da habe ich bis zu 8 Koordinaten pro Stage für Zugänge (1-7 Gegner, 1-2 Fahrstühle), wären normalerweise 16 Bytes. Mal 50 Stages pro Level sind aber schon 800 Byte. Und wenn man von Anfang an anfängt zu knapsen, damit nachher auch ja alles rein passt, dann denkt man so "OH NEIN, 800 Byte, das ist ja fast ein Kilobyte!!!1:emojiSmiley-33:!! Geht GAR nicht!"


    - Ok, x oder y sind nie größer als 10, brauchen nur ein Nibble, also zusammen damit, und wir sind bei 8x50=400 Bytes. Da keine Bits für Zusatz-Infos im Nibble mehr über sind, muss ich die Koordinaten noch zusätzlich so sortieren, dass die Fahrstühle (up/down) immer die beiden letzten Bytes sind, um sie zu erkennen. Ob es nur 1 oder 2 Fahrstühle sind, erkenne ich ja an der Etage (erste/letzte).

    - 400 Bytes ist aber auch noch viel. Also, wenn ich für die Zugänge einen Abstand von einem Segment von der Außenecke einhalte, komme ich mit max. 8 möglichen Position pro Außenwand aus. Ich definiere also 4 Linien à 8 waagerechte bzw. 6 senkrechte Positionen, die ich jeweils als Byte angeben kann, wobei ein Bit eine durch einen Zugang besetzte Position darstellt. Dann hätte ich nur noch 4 Bytes, insgesamt also nur noch 200 Bytes - klingt gut. Nur woher weiß ich jetzt noch, welche Bits in den 4 Bytes die beiden Fahrstühle repräsentieren?

    - Zwischen zwei Zwetschgenzweigen Zugängen gibt es immer mindestens ein Segment Abstand. D.h., zwischen den Bits ist immer ein Null-Bit. Dann setze ich hinter dem Bit eines Fahrstuhls also noch ein Bit und erkenne daran, dass es sich um einen FS handelt. Ich bräuchte also hinter dem letzten möglichen Bit noch ein zusätzliches; es gibt aber im Byte nur 8 davon. Vertikal sind statt 8 nur 6 Positionen möglich; also kann ich von zwei Bytes das MSB abzwacken und als 9. Bit der anderen zwei Bytes interpretieren. Heureka! Jetzt habe ich in nur 4 Bytes die Koordinaten von max. 8 Zugängen aus 28 (2*8+2*6) möglichen gespeichert, einschließlich der Information, was davon die Fahrstühle sind.

    - The End Aber wie erkenne ich, welcher davon der für Rauf und welcher für Runter ist, ohne es zusätzlich zu speichern? In der obersten Etage weiß ich, dass es nur einen für Runter gibt. In der nächsten darunter muss dann der an der gleichen Position der für Rauf sein. Der andere ist dann zwangsläufig wiederum der für Runter, usw.. Abzüglich Code hab ich dann ein halbes Kilobyte gespart.


    Während hier im Thread bei der Betrachtung vom Zusammenspiel von höheren Auflösungen und der CPU offenbar nur die Taktfrequenz betrachtet wird, vergisst man ganz, dass der C64 für solche Dinge häufig zusätzlichen Rechenaufwand benötigt und die anderen, besser bestückten, eben nicht; gleiches gilt für entfallende Multiplexer u.ä.


    Mit so was beschäftigt man sich dann, und die Leute wundern sich, warum einigen die Entwicklung länger dauert (Stichwort Bombjack DX und Speicherplatzmangel). Dabei macht es für das Spiel an sich ausschließlich in Bezug auf den C64 einen Unterschied, weil dadurch mehr hineinpasst oder herausragende Eigenschaften und Effekte erreicht werden. Absolut gesehen wäre es fürs Spiel aber egal, wie die Daten untergebracht sind. Wer Wert darauf legt, ein gutes Spiel unbedingt auf dem C64 zu machen, muss das wohl alles akzeptieren, sei es, weil man die Szene bereichern will oder man zeigen will, was man auf der Kiste tatsächlich noch alles machen kann, weil es immer noch der Liebling ist und man deswegen damit gern entwickelt, weil man Spaß an dieser Fummelei hat, oder weil neuere Systeme in der Retro-Szene eben einen geringeren Stellenwert haben.


    Das Projekt, wo ich derzeit bei bin, mache ich auf dem C64 fertig. Nur Krieg, Katastrophen oder Krankheit können mich davon abhalten. Aber es kann gut sein, dass ich mich dann auch dem X16 (und/oder M65) widme, um darauf Projekte viel schneller zu verwirklichen. Hängt natürlich auch ganz von dem Grad der Popularität solcher Systeme ab, denn ohne Interessenten bringt das schönste Spiel nichts. Und damit Schönes WE! :)

    Zitat von atomcode

    Interessant, weil 8bit-Guy meinte, dass sein X16 etwa so schnell wie ein 286er @ 12 MHz sei (Teil 2 @ 44:27), aber hier befürchtet wird, VGA wäre dafür zu viel.

    Der C65 kann noch viel höhere Auflösungen, und bei 256 Farben kann er knapp die Hälfte vom X16, hat aber auch nur knapp die Hälfte an MHz.

    Die MHz sind völlig irrelevant.

    Der 6502 ist eine RISC Architektur so wie der 86K und frühe ARM.

    Ein 1MHz 6502 kann mithalten mit einem 6MHz Z80.


    Beim 80286 ist es ganz schlimm, es ist reine CISC Archtitektur.

    Da sind 12 MHz gar nichts, wenn jeder Befehl zig Zyklen braucht für die Ausführung.

    Mal ganz davon zu schweigen, dass die Segmentierung und Protected-Mode sehr viel CPU Zeit frisst.

    Und auch im Real-Mode hat er auch nur 64K Adressraum, will er darüber hinaus muss er Segment Register setzen.

    Und da sind wir wieder beim Banking, hochgezüchtete 8 Bitter mit großen Speicher durch Banking setzen auch nur ein (Banking) Register.

    Zitat von RexRetro

    Keine Kommentare hier zu dem X16 Gehäuse und den Tastaturen die Perifractic vorgestellt (YT Link) hat?

    Ich bin durchaus ein Freund von Gehäusen mit abgesetzter Tastatur – weil es einfach praktisch im Gebrauch ist und zudem Produktionskosten sparen kann. Aber einerseits mag ich die hier vorgestellte Optik nicht besonders (erinnert mich ein wenig an die Colani-Gehäuse von Vobis), zum anderen wird durch die ganze Kabelei der Sinn des externen Gehäuses in Frage gestellt. Wenn ich schon das Keyboard von der CPU trenne, dann würde ich das gerne kabellos machen, damit ich den Homecomputer auch alternativ zum Fernseher stellen kann, während das Keyboard und die Controller auf dem Couchtisch liegen.


    Dieser Homecomputer scheint wirklich eher für die Bastel- und Computerecke gedacht zu sein (das Steckkarten-Design unterstützt die Vermutung), während ich einen Homecomputer eher im Wohnzimmer ansiedeln würde. Letztendlich werden für so eine Hardware doch eher Games als Büro-Software entwickelt – da würde ich die auch gerne (mit der Familie oder Feunden) im gemütlichen Wohnzimmer zocken – und nicht im Hobby-Keller neben der Lötstation.


    Man kann gut erkennen, der das 8-Bit-Guy doch eine ganz andere Vorstellung von einem "modernen" Retrocomputer hat, als ich. Da passen dann vielleicht auch die Nintendo-Controller, PS/2-Keyboard, Steckkarten, großes Desktop-Gehäuse, BASIC V2, VGA-Output usw. dazu.

    Zitat von Retrofan

    Dieser Homecomputer scheint wirklich eher für die Bastel- und Computerecke gedacht zu sein (das Steckkarten-Design unterstützt die Vermutung), während ich einen Homecomputer eher im Wohnzimmer ansiedeln würde.

    Das vermute ich auch. Meiner Meinung nach macht das aber sehr viel Sinn. Alles andere als Hardwarebasteln kann man mit Emulatoren viel besser machen. Und das Ding ist ja auch nicht retro, so dass man das Gerät aus nostalgischen Gründen (wie den C64...) in Original Hardware haben muss.


    Obwohl ich auch 3 C64 rumstehen habe, benutze ich VICE doch deutlich öfter...