letzter Beitrag von Retrofan am
Zer0-X hat sich den U64 schonmal genauer angeguckt ... Spielkrams läuft wohl recht zuverlässig ohne Probleme, Demos sind allerdings ein Glücksspiel.
Halt das übliche ... die ersten 98% gehen schnell, die restlichen 2% dauern dann wie beim TC64 'lange' oder werden eingespart.
(Ich zitiere [sinngemäß] einen bestimmten Emulatorentwickler: "C64-Emu der Giana packt schreibste mit bisschen Ahnung an einem Wochenende - und die Details dauern dann Monate oder Jahre").
Also Gideon hat seinerzeit eine FPGA Implementierung eines C64 gebastelt mit 1541.
Dann kamen C-One und der C64DTV.
Darauf hin hat er das Produkt als unnötig erachtet,den 1541 Core extrahiert und die 1541 Ultimate erschaffen.
Also der Core ist durchaus abgestanden,wie gut er ist könnte Cyberdyne ( war das so ?! ) sagen wenn er bereits ein Board hat.
Mit einer Aussage wie "dies oder das läuft nicht" das Projekt aber auch ordentlich torpedieren.
Woher hast Du diese Info. Ich weiss, das Gideon mal ein Bild eines Prototypen gepostet hatte. Von Core und Extraktion war da aber damals nicht die Rede, soweit ich weiss.
Das wurde hier doch alles schon zigfach erwähnt. Die Infos kommen aus einem Interview mit Gideon.
Zum eigentlichen Thema (das wir ja immer wieder mal haben): Ich denke die Entwicklung tatsächlicher Spiele usw. spricht letztendlich für sich. Man kann sich natürlich vieles herbeiwünschen, aber man sieht ja irgendwo auch bereits zur genüge belegt, dass die Entwickler da scheinbar nicht interessiert dran sind.
Und ja, man müsste sich durchaus mal fragen, ob Sam's Journey den selben Hype und Beliebtheitsgrad erhalten hätte, wenn es ein Spiel wäre, das eine SuperCPU oder einen anderen Turbo benötigen würde, um überhaupt zu laufen. Nicht nur, weil es dann weniger Leute spielen könnten, sondern auch, weil es dann irgendwie vielleicht "nix besonderes" wäre bzw. so wirken würde.
Etwas was aber durchaus funktionieren KÖNNTE, wie jemand anders schon schrieb, wären Spiele wie Test Drive usw, diese sind ja framerate-unabhängig programmiert und würden dann im Turbo einfach flüssiger laufen, auf einem normalen C64 jedoch trotzdem einigermaßen spielbar sein. Betonung liegt auf einigermaßen 
Alles anzeigenDie C64 Szene ist quasi die Einzige die sich noch nicht mit so einem Hardwarewahn zerrissen hat.
Fast alle anderen Heimcomputer setzen Extrahardware voraus oder es gibt nicht 'den Standard'.
Selbst beim Atari2600 wird es zunehmend unattraktiv durch dominierende ARM CPUs auf den Carts.
Was fuer den C64 ist, muss am C64 laufen. Grosses Lob an Sam's Journey sich daran gehalten zu haben. Wer seinen C64 kaputtbastelt oder Ports mit Getuedel belegt muss sich bewusst sein, damit den Standard zu verlassen.
Rufe nach REU/Turbo/etc. werden hoffentlich ignoriert oder laeuten das Ende einer/der/dieser C64-Aera ein. Das ist keine Schwarzmalerei, sondern war bei allen anderen Systemen exakt so.
Zum Glueck kommen sie eigentlich nie von Entwicklern bisher.
Die Idee ist tolle Spiele mit diesen Rahmenbedingungen zu schaffen. Zeha zeigt ja zB mit Frogs dass es nichteinmal besonderer technischer Tricks bedarf, um eine tolle Spielidee umzusetzen.
8 Sprites, eine passende Musik und vor allem Spielspass. Nicht immer: mehr Grafik, mehr Farben, mehr mehr mehr.
Das ist meine Sicht auf die Dinge und ich verfolge Softwaretrends fuer diverse System ueber so einige Jahre.
Den Post würde ich echt gerne vorne ans Forum tackern. Und nicht nur an dieses, sondern an die Foren von jeder Retro-Plattform. Sogar beim Vectrex geht der Scheiß schon los.
Früher hatte man auch sicher Angst, wenn man eine REU vorraus setzt, das man nur 5 Kopien verkauft. Oder dass man sich mit Käufern rumschlagen muss, die die Beschreibung nicht richtig gelesen haben (Für dieses Spiel wird eine Ramerweiterung benötigt") und das Spiel zurück geben wollen.
Und heute hat's dieses aber auch andere Probleme:
Meine Retroplattform soll aber bitte kein PC sein, sondern Charakter haben.
*unterschreib*
Vielleicht hilft es ja, die Frage mal aus Programmiersicht zu betrachten. Da stellt es sich wie folgt dar:
Grundsätzlich hat man bei Beschleunigern die Wahl, ob man nur für einen bestimmten Beschleuniger schreibt (z. B. SCPU) oder das Programm so anlegt, daß es mit mehreren verschiedenen zusammen läuft. Wahrscheinlich wird man sich eher für letzteres entscheiden (und dann z. B. die neuen Befehle der SCPU vermeiden), um den Kreis der Nutzer nicht zu weit einzuschränken.
Mir sind zur Zeit vier verschiedene Beschleuniger bekannt:
1.) C128 im 2-Mhz-Modus
2.) DTV
3.) SCPU
4.) TC64
Die Beschleunigung mittels $d030 beim C128 ist dabei bereits damals[tm] in einigen Spielen schon vorgenommen worden, sprich: Wer damals[tm] einen C128 besaß, konnte in den Genuß einer Beschleunigung kommen. Beschleunigung an sich ist also nicht C64 untypisch.
Von Nachteil ist, daß alle vier Beschleuniger eine spezielle Behandlung brauchen. So bedeutet Beschleunigung beim C128, daß diese nur außerhalb des Bildschirms vorgenommen werden kann, da der VIC quasi abgeschaltet wird. Bei den anderen sieht es aber nicht besser aus. Das Problem ist, daß sie alle über ein anderes Timing verfügen; die Beschleunigung wirkt sich also stets anders aus. Das macht die Gestaltung zeitkritischer Routinen, insbesondere des Rasterinterrupts, sehr schwierig. Aus diesem Grunde mußte ich z. B. bei Test Drive II die Beschleunigung während des Bildschirmaufbaus generell abschalten, da ansonsten die Graphik zerstört wird. Den Aufwand, einen Rasterinterrupt an alle Beschleuniger anzupassen, wird man sich kaum machen. Dies wäre auch unmöglich zu leisten, denn keiner weiß, ob und inwiefern neue Boards oder ein neues TC64 nicht wieder Änderungen im Taktverhalten mit sich bringen werden.
Wenn also eine saubere Rasterinterrupt-Programmierung (für Splitscreens, Sprite-Multiplexer etc) für viele verschiedene Beschleuniger gleichzeitig nicht möglich ist, wird man die Beschleunigung analog zum C128 begrenzen auf die Zeilen außerhalb des regulären Bildschirms. Das bedeutet auch, daß sich die Beschleuniger nicht so stark auswirken, wie man es zunächst vermutet, wenn auch noch durchaus erkennbar, und daß desweiteren ein PAL-C64 mehr davon profitiert als ein NTSC-C64.
Soll ein Programm nun Beschleuniger unterstützen, muß
1.) zu Beginn des Programms einmalig der Beschleuniger erkannt und eingerichtet werden,
2.) müssen ein oder zwei zusätzliche Interrupts eingebaut werden, um die Beschleuniger bildschirmabhängig ein- und auszuschalten,
3.) müssen Routinen zur Verfügung gestellt werden, die diese Beschleunigung sauber aktivieren und deaktivieren, um z. B. von Diskette nachladen zu können.
Das erfordert ein wenig Aufwand, ist aber an sich kein Problem. Nur noch einmal: Niemand weiß, wie zukünftige Beschleuniger funktionieren. Es gibt hierzu keinen Standard. Schreibe ich jetzt ein Programm, daß mit den oben genannten Beschleunigern zusammenarbeitet, ist dies keine Garantie dafür, daß es auch mit einem künftigen läuft, denn Beschleunigung bedeutet beim C64 anders als beim Amiga keine einfache absolute Beschleunigung durch Austausch des Prozessors. Dies ist generell aufgrund der Kompatibilität zu vielen zeitkritischen Routinen nicht möglich.
Allgemein würde ich für eine optionale Beschleunigung plädieren, da diese meiner Ansicht nach den C64 nicht spalten würde. 3d-Spiele oder Strategiespiele mit langer Bedenkzeit könnten von einer optionalen Beschleunigung profitieren, so wie schon damals beim C128. Das wäre für den C64 keine Gefahr, denn die Programme an sich würden weiterhin auf jeder Plattform laufen. Beschleunigung hat auch den Amiga nicht getötet, weder der 68020 des Amiga1200 noch eine 50Mhz-Turbokarte, weil selbst "Zeewolf" noch brauchbar auf dem Amiga500 lief. Zum Verhängnis wurde dem Amiga eher der nach und nach vollzogene Austausch grundlegender Hardware und die generelle Voraussetzung einer solchen wie Graphikkarte oder der kompletter Wechsel des Prozessortyps, d. h. Hardware, die nicht kompatibel war zum ursprünglichen Hardware- und Programmiermodell.
Die C64 Szene ist quasi die Einzige die sich noch nicht mit so einem Hardwarewahn zerrissen hat.
Fast alle anderen Heimcomputer setzen Extrahardware voraus oder es gibt nicht 'den Standard'.
Das ist leider so nicht mehr richtig, denn ein ähnlicher Effekt läßt sich bereits jetzt in der C64-Szene beobachten. Heutzutage ist es gang und gäbe eine zur Originalhardware inkompatible Erweiterung wie das SD2IEC zu verwenden und von den Entwicklern dann zu verlangen, daß die Programme gefälligst Kernalload verwenden sollen. Daß Kernalload auf Originalgeräten schnarchlangsam ist und viele Probleme mit sich bringt (kein Interrupt, keine Sprites), wird dabei völlig ignoriert. Mit anderen Worten: Moderne "Retro"-Hardware bestimmt heute schon beim C64, wie Programme auf alten Rechnern auszusehen haben, nämlich angepaßt an ihr inkompatibles Verhalten. So gesehen ist die Verwendung einer Beschleunigung das viel kleinere Problem, aber es kommt halt immer darauf an, zu welcher Gruppe man selber gehört und wie groß diese ist.
Sorry, daß ich auf diesen blinden Fleck hingewiesen habe. War Absicht.
Falsch. Software wurde einiges entwickelt. (VAss16, MD, Wings , Wheels64 usw.) Noch heute gibrs vereinzelt neue Software für.
Wie man's nimmt.
- VAss16, MD kenn ich nicht.
- Wings wurde nie fertig entwickelt und ist in der vorhandenen Form für nix zu gebrauchen, die anderen OS (Clips, Jos) wurden eingestellt bzw. in Wings aufgegangen
- Wheels 64 läuft ohne SCPU, setzt nur eine REU voraus. Oder meinst Du Wheels SC, welches speziell für die SCPU entwickelt hätte werden soll?
NICHT STREITEN KINDER! WIR SIND EINE GLÜCKLICHE COMMUNITY!
Keine Sorge wir haben uns alle, ganz toll lieb. 
Seine Aussagen zum Ultimate 64 Turbomodus sind auch hier nachzulesen: The Ultimate-64 - Neues C64 FPGA Board
Danke das hab ich vorhin, in der FB-Gruppe, gesucht.
Das bei erweiterten Hardware Probleme mit der Standard-Konfiguration bestehen kenne ich vom C128 her.
Z.B. setzt MP3 128 einen VDC mit 64 KB RAM voraus.
Ist der nicht vorhanden -> Pech gehabt.
Es bleiben von daher drei Möglichkeiten.
- Auf's Programm verzichten
- Rechner aufrüsten
- Rechner tauschen
Soweit sollte es eigentlich beim C64 nicht kommen, wäre wirklich schade.
Aber eine optionale Unterstützung wäre, aus meiner Sicht, mehr als wünschenswert.
Wie ZeHa am Beispiel TestDrive gesagt hat, läuft mit oder ohne SCPU.
Mit SCPU (mehr Speed) halt einfach besser.
Ich seh's ja an Wheels 64 welches mit oder ohne SCPU läuft, mit SCPU geht's halt einfach flüssiger z.B. Fenster vergrössern.
Es ist halt so, gewissen Sachen gehen einfach nicht mit 1 MHZ bzw. nicht vernünftig.
Gruss C=Mac.
Habe ich das schon gemacht.
Ja, ist aus einem anderen Thread "geklaut" 
Danke für die Info aus Programmiersicht.
Sorry, daß ich auf diesen blinden Fleck hingewiesen habe. War Absicht.
Ist doch kein blinder Fleck. 
Es geht nur ab und zu vergessen, dass das SD2IEC keine Floppy-Emulation ist.
Gruss C=Mac.
M.J.
Jammern wenn es z.B. nicht auf SD2IEC laeuft ist aber dann doch noch eine Minderheit. Aber vor 5 Jahren haette sich das zumindest noch keiner getraut - stimmt
Es ist nicht schlimmer geworden, es gibt nur mehr Leute die von der Materie selbst keine Ahnung/Vorstellung haben und dennoch Teil der Community sind und nun lauter anfangen 'Forderungen' zu stellen.
Und ja, das ist auch Gift fuer eine aktive, produktive Community um eine Hardware herum leider.
Davon ab ist Gideon eher der Hardwaremensch. Was die Software angeht, glaub ich eher nicht, dass er neben der Hardwareentwicklung noch Zeit für einen 100% C64 Core
hatte. Letzteres überhaupt dazu in der Lage wäre.....
Ja so langsam wissen wir es (wie du darüber denkst), schon 1000 Male hast du genau das in jedem U64 bezogenen Thread schon verlauten lassen. Is' langsam 'mal gut damit.
Gideon hat schon vor Ewigkeiten (vor der 1541 Ultimate noch, denn diese war gar nicht sein eigentliches Ziel sondern von Beginn an bereits eine Art FPGA U64.. !) mit der Nachbildung begonnen, btw. .. .
Steht alles auf seiner HP. Das (U64) hat er nicht erst 'mal eben ganz schnell in den letzten vier Monaten gezaubert.
Etwas was aber durchaus funktionieren KÖNNTE, wie jemand anders schon schrieb, wären Spiele wie Test Drive usw, diese sind ja framerate-unabhängig programmiert und würden dann im Turbo einfach flüssiger laufen, auf einem normalen C64 jedoch trotzdem einigermaßen spielbar sein. Betonung liegt auf einigermaßen
Ja, das wäre ja nur optional und keine zwingende Vorraussetzung.
Es ist nicht schlimmer geworden, es gibt nur mehr Leute die von der Materie selbst keine Ahnung/Vorstellung haben und dennoch Teil der Community sind und nun lauter anfangen 'Forderungen' zu stellen.
Was wurde zum Beispiel auf den Programmierer von Civilization 64 eingeredet, dass eine Umsetzung ohne Verwendung "moderner Hardware" ein Ding der Unmöglichkeit sei: CIVILIZATION-1 auf dem C64 möglich?
Ich finde vanille c64 mit reiner Datasette oder Floppy allein langweilig. Von daher nutze ich auch Erweiterungen die den C64 einfach noch besser machen. Interessant finde ich teils die Doppelmoral einiger Leuten hier. Da wird auf Zusatz Hardware geschimpft aber im gleichen Atemzug aufs Mega 65 geschielt.
Ja so langsam wissen wir es (wie du darüber denkst), schon 1000 Male hast du genau das in jedem U64 bezogenen Thread schon verlauten lassen. Is' langsam 'mal gut
Wenn ich deinen Erguss dazu lesen will, lass ich Dich das schon wissen. Keine Angst.
