Posts by Snear

    Interessant ist nun auch die erste Erweiterungskarte für Ethernet und SID (äh ja, was ne Kombination ;-)

    EXP-C100-ESID – SID/Ethernet Expansion Card

    IMG_20201115_155443-300x300.jpg

    Waren nicht der fehlende Ethernet-Anschluss und die fehlende SID immer die größten Kritikpunkte der Community? Vielleicht hat Stefany eingesehen, dass es vielleicht nicht verkehrt ist, auf die Wünsche potentieller Kunden einzugehen, wenn das Projekt nicht nur eine Herzensangelegenheit ist, sondern auch tatsächlich Erfolg haben soll.

    Dieses Buch bzw. das BASIC-Listing ist wirklich die reinste Folter. :) Als leidenschaftlicher Schachspieler habe ich schon diverse Schach-Engines selbst programmiert und mich durch jede Menge Code gewühlt, aber so etwas unlesbares und undurchschaubares habe ich noch nie gesehen. Selbst Assembler-Code mit vernünftigen Symbolnamen ist da besser lesbar. Aber gut - das war 1984. :) Wer nur BASIC kann und sich mit Schachprogrammierung beschäftigen möchte, dem empfehle ich das Buch "Schach am PC" von Markt und Technik. Da wird u.A. eine Engine in Quickbasic vorgestellt, die eine echte Suche hat und auf einem modernen PC vermutlich so 1600 ELO erreichen dürfte.


    Ich sehe gerade, dass jemand die Engine in Freebasic zum Laufen gebracht hat und eine GUI dazu gebastelt hat: https://www.freebasic-portal.d…chach-mit-minimax-87.html

    Die HDToolbox hatte ich auch schon gestartet und konnte so gar nichts damit anfangen. Aber nun habe ich es geschafft alles zu partitionieren und neu zu installieren. Auch WHDLoad läuft nun. Ich hatte im Anschluss noch das Problem, dass ich in keinen Order in der "WORK"-Partition wechseln konnte. Die HDD-Led hat dann lange geleuchtet, aber es ist nichts passiert. Die Workbench hat nur die Uhr gezeigt, die ich zwar noch bewegen konnte, aber sonst ging nichts mehr. Im Internet stand etwas von "max transfer auf 0x1fe000" setzen, aber das hat auch nicht geholfen. Jetzt habe ich die Partition mit fat95 formattiert und alles läuft.

    Danke für eure Hilfe!

    Ich habe heute mal das AmigaOS 3.1.4 auf einer CF-Karte im Amiga installiert. Soweit habe ich alles zum Laufen bekommen, auch der PCMCIA-CF-Adapter zum Datenaustausch funktioniert nach ein bisschen Frickeln wieder. Nun habe ich ein vermutlich lächerliches Problem. Ich kann nichts installieren, weil der Order "Workbench" immer voll ist. Ich habe als erstes DirectoryOpus installiert und im Anschluss wollte ich WHDLoad installieren. Die Installation schlägt aber bereits fehl, weil kein Platz mehr auf der Workbench ist. Auf dem "Desktop" habe ich zwei Ordner: Work und Workbench. Der erste ist 4 GB groß (die CF-Karte), der zweite nur 10 MB. Ich hatte keine Möglichkeit irgendetwas zu partitionieren. Kann ich da irgendetwas dran drehen?

    Puuuh, ich habe so viele Projekte hier derzeit am Laufen... gestern habe ich mich mal wieder dem C16 gewidmet und dem Umschalten des Kernels. Den alten Umschalter habe ich wieder im C64 gelassen (wo er sowieso bleiben sollte) und nun verwende ich den Umschalter von ebay (FaszinationC64). Der dürfte sicher bekannt sein. Im C64 funktioniert auch der wunderbar, aber im C16 passieren seltsame Sachen. Wenn er auf JiffyDos eingestellt ist, gibt es nur einen Startbildschirm mit "COMMODORE BASIC V3.5" und einem blinkenden Cursor. Kein weiterer Text und Tastatur reagiert nicht. Der normale Commodore-Kernel funktioniert.

    Ich suche mal nach einem 27C256er. Bisher habe ich nur 128er und 512er gefunden.


    genau! wie Du schreibst, nur die höherwertigen Bits auf GND oder VCC ziehen und fertig.

    Also irgendeinen Pin einfach auf VCC legen klingt irgendwie gefährlich... aber ich habe hier schon einen anderen Thread mit einer Schaltung gefunden. Ich schaue mir das mal genauer an.

    Ob natürlich viele C64-Spiele soviel Variabilität im Gameplay haben, dass sie E-Sport tauglich wären, ist wieder eine andere Frage. Die meisten wohl eher nicht, schätze ich, aber witzig wäre ein Versuch allemal.

    Es gibt jeden Herbst die Weltmeisterschaft im klassischen Tetris. Wer das noch nie gesehen hat, einfach mal bei Youtube nach CTWC suchen. Ich glaube das ist irgendeine SNES-Version, die da gespielt wird. Die Teilnehmer sitzen da immer noch an Röhrenmonitoren, weil quasi jede Millisekunde Reaktionszeit zählt.

    Oh Mann 65 Millisekunden :emojiSmiley-79:Ein Augenzwinkern braucht sogar 100 Millisekunden. Was man da alles verpasst.:emojiSmiley-16:

    Die Reaktionszeit eines Menschen variiert mit Körpergröße, Alter usw..., aber die besten liegen so bei 100-150ms. Wenn da plötzlich 50% obendrauf kommen, ist das schon ein großer Unterschied. Frag mal 'nen 100 Meter-Sprinter, wie viel 65 Millisekunden sind... die können schnell zwischen Gold und Blech entscheiden.


    Ich bin beim Lag relativ empfindlich und für mich gehört dieser "Zero-Lag" einfach zu den alten Spielen dazu. Wer es nicht merkt oder wen es nicht stört, der kann sich glücklich schätzen, aber soll bitte niemandem unterstellen, er bilde sich diesen Lag nur ein. :)

    Für das Brennfile habe ich einfach OriginalRom+JiffyDos+OriginalRom+JiffyDos mit einem HexEditor aneinandergeklatscht. Wenn ich den 512er so verwende, ist JiffyDos aktiv und der C16 funktioniert wunderbar. Ich hätte auch erwartet, dass Umschalter kompatibel sind.

    Ich versuche gerade einen Kernel-Umschalter für den C16 zu bauen, aber alles, was für den C64 gedacht ist, scheint dort nicht zu funktionieren. Ich habe hier u.A. einen funktionierenden Kernel-Umschalter für den C64, der aber im C16 nicht läuft (nur Blackscreen).


    Ich habe für den C16 ein 27C512 mit 2 verschiedenen Kernel gebrannt, die sich wiederholen, d.h. Bank0=Bank2 und Bank1=Bank3. Wenn ich den 27C512 einfach so einsetze, ist eine ungerade Bank aktiv. Gibt es eine ganz einfache Schaltung, mit der ich auf eine gerade Bank wechseln kann? Das würde mich schon reichen.

    [I/O] Ich finde es, ehrlich gesagt, schon recht gewagt, den Käufern des X16 zuzumuten, dass sie sich einen alten VGA-Schirm suchen sollen (was wahrscheinlich von der Beschaffung her noch die einfachste Übung ist) und darüber hinaus eine PS/2-Tastatur (die ich nur im Haus habe, weil ich auch SGIs sammle) und Nintendo-Controller (bei denen ich passen müsste). Und dieser Geräte-Zoo hat sicherlich einen WAF (und damit Wohnzimmer-Tauglichkeit) von exakt Null.

    Ich frage mich immer, was ihr alle für Monitore habt?! Ich habe gerade mal auf Geizhals nachgeschaut. Dort sind 2045 Monitore gelistet. 1698 davon haben HDMI und 1226 haben VGA. Selbst wenn ich die Monitore seit 2018 nehme: 1084 Monitore, davon 1051 mit HDMI und 510 mit VGA. Man kann also sagen, dass selbst bei neuen Monitoren noch jeder zweite einen VGA-Anschluss hat! Selbst bei den 2557 gelisteten Fernsehern haben 583 einen VGA-Anschluss. Bei Tastaturen kann ich den Einwand eher verstehen. Von 2130 kabelgebundenen Tastaturen kommen nur noch 136 mit PS/2. Aber wer sich eine Retro-Konsole für mehrere Hundert Dollar holt, der wird sicher auch noch einen Zehner für eine Tastatur übrig haben. :) Was die Nintendo-Controller betrifft: da gibt's doch immer noch billige Nachbauten in der Bucht.

    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.

    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.

    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.

    Wie schaut's aus, hat schon jemand neue Antworten erstellt?

    sonst müssen wir das mal machen und tauschen (denn die eigenen kann ich ja dann nicht spielen) :)

    Problem ist, dass man alles austauschen muss - und die Antworten sind doch recht zahlreich. Ich bin momentan dabei ein paar alte Klassiker neu aufzulegen, d.h. neu zu programmieren mit etwas besserer Grafik und mehr Spielwitz. Ist ja nicht sonderlich schwer die alten Versionen zu überbieten. Glücksrad steht bei mir aber nur an 2.Stelle. Die Deadline für das erste Projekt ist Ende November. Ich will da aber noch nicht zuviel verraten. Erst danach ist Glücksrad an der Reihe.

    Die Spezifikation sagt zwar, dass 640x480 der einzige Modus ist, aber die hinkt immer etwas hinterher. Es gibt tatsächlich Programme, die eine Auflösung von 320x240 haben, wie z.B. das hier:

    Dass der 640x480 Modus bei einer so schwachen CPU komplett überflüssig ist, da sind wir uns ausnahmsweise mal einig. Und ich bezweifle, dass man 128 Sprites bei der CPU überhaupt vernünftig handhaben kann. Das mag bei einer Feature-Demo vielleicht gehen, aber nicht bei einem Spiel. Da der 8-Bit-Guy auch großer VIC-20-Fan ist, gibt auch einen albernen 20x15 Textmodus. Da hätte man mal lieber den Grafikmodus des VIC-20 mit seinen 176x184 Pixeln nehmen sollen. Dann wäre 3D, Raycasting & Co drin gewesen. 48Khz 16 Bit Stereo passt auch gar nicht zum Computer. Dass man einen digitalen Kanal möchte, kann ich verstehen, aber 22Khz in 8 Bit hätten es da auch getan.


    Die Basic-Vernarrtheit des 8-Bit-Guys stört mich auch etwas. Niemand will heute mehr mit Zeilennummern programmieren. Aber soweit ich weiß, kann man auch den CC65 zum entwickeln nehmen und für den X16 kompilieren. Man hat also zumindest mal C. Wenn's da noch ein paar Librarys für Spritehandlung und Sound gäbe, wäre das jetzt nicht das Gelbe vom Ei, aber zumindest brauchbar.

    Der Foenix256 ist nicht wegen eines zu hohen Preises oder zu geringen Absatzes eingestellt worden.

    Die Entwicklerin war enttäuscht über den ihrer Meinung nach, zu geringen Beitrag von Entwicklern, die das Developer Gerät gekauft hatten.

    Sie hatte sehr hohe Erwartungen und gehofft, dass sich die Leute scharenweise auf die tollen Hardware-Features stürzen und Programme dafür schreiben.

    Meiner Meinung nach hätte da mit etwas mehr Geduld, etwas daraus werden können.

    Ich finde, sie hat zu früh das Handtuch geworfen.

    Die Frage ist, was denn die tollen Hardware-Features sind? Ich hatte einmal etwas zum Foenix256 hier im Forum geschrieben, wo sie drauf geantwortet hat. Die Kurzversion meiner Frage war "Can it run Doom?". :) Die lange Version meiner Frage war, was man denn für so eine Hardware schreiben soll? Selbstverständlich braucht man einen einfachen Einstieg für Anfänger, die man ja für so eine Plattform begeistern möchte. Aber um die alteingesessenen Entwickler zu begeistern, die in der Lage sind mal einen Top-Titel rauszuhauen, braucht man mehr als höhere Auflösungen und viele Farben. Und das fehlt mir sowohl beim Foenix256 als auch beim X16. Keines der Systeme eröffnet neue Möglichkeiten, sondern bietet einem lediglich die Plattform für das 1000.Jump&Run. Da bleiben die meisten lieber beim C64. Da gibt's garantiert ein paar Spieler und das Pixeln macht nur halb soviel Arbeit.


    Wer sich mal umschaut, was in naher Zukunft für den C64 kommt, der trifft auf Spiele wie Eye of the Beholder oder Limbo. Die Motivation der Entwickler ist klar. Hat's noch nicht gegeben auf einem Retro-System, ist mit trickreicher Programmierung möglich, also wird's gemacht. Ich glaube, dass ein System, was in der Hinsicht keine neuen Türen öffnet, auch keine Entwickler von anderen Plattformen abzieht.


    Ich habe mir gerade mal das Abschiedsvideo von Stefany angeschaut. Puuuh, da lässt sie aber mächtig Dampf ab. Leider erzählt sie zu keiner Zeit, was sie von den Entwicklern erwartet hat, also was für Spiele sie sich denn erhofft hat. Das hätte mich sehr interessiert. Sie hat immer nur von "exciting new games" gesprochen. Spannend wurde es als die sagte, dass sie alles über den C256 veröffentlichen wird, so dass jeder das Ding in China nachproduzieren lassen kann. Aber dann kam von ihr ein "bis auf den FPGA-Core!" hintenran. :) Sie möchte nicht, dass ihr Werk zerhackstückelt wird. Leute, die sich diesen Teil, also insbesondere die Grafikfähigkeiten, anders vorgestellt haben, sollen niemals das bekommen, was sie wollen. Irgendwie habe ich mich direkt angesprochen gefühlt... :)

    [Architektur, Thread] Das Problem dabei ist aber, das wir heute keine wirklichen (relevanten) Beschränkungen mehr haben, selbst bei der CPU nicht. Warum 8, 16 oder 32 Bit, wenn es doch auch 64 Bit gibt?

    Weil es keinen einfach zu verstehenden Prozessor mit 64 Bit gibt. Ich kenne die ARMs nicht, aber x64 ist doch schon so kompliziert, dass nicht einmal mehr die Chipdesigner da durchblicken - sonst wären da ja nicht unzählige Bugs drin.

    Das war uns auch schon sehr früh im Thread klar, daher ging es darum, was denn anders sein soll, was man mit den alten Kisten eben nicht gut machen konnte – und heute vielleicht gerne haben möchte. Fazit: Die Programmierung, vor allem von Spielen (DER zentralen Anwendung von Homecomputern), soll mittels Hochsprache und IDE sehr einfach möglich sein (im Gegensatz zu früher).

    Dass wichtigste am letzten Satz ist für mich das "sehr einfach". Dass eine Hochsprache dabei sein sollte, ist klar. Die braucht jeder zum Einstieg. Aber wenn man so ein Gerät auch einfach in Assembler programmieren kann, sehe ich keinen Grund, warum das nicht die vorrangige Programmiersprache sein sollte. Ich bin mit Basic und Assembler aufgewachsen und habe beides am C64 und 80286er programmiert. Soundprogrammierung und Grafikprogrammierung (Scrolling und Sprites) war auf dem C64 in Assembler sehr viel einfacher als dem 286er in Quickbasic. Trotzdem habe ich 90% der Zeit am 286er programmiert. Nicht, weil ich da bessere Sachen zustande bekommen habe, oder weil Basic einfacher als Assembler war, sondern weil der Komfort viel höher war.