letzter Beitrag von Retrofan am
Ich finde vanille c64 mit reiner Datasette oder Floppy allein langweilig. Von daher nutze ich auch Erweiterungen die den C64 einfach noch besser machen.
Kannst du ja finden, wie du magst. Aber akzeptiere genauso, dass andere dieser Hardwareschlacht nichts abgewinnen können.
Kannst du ja finden, wie du magst. Aber akzeptiere genauso, dass andere dieser Hardwareschlacht nichts abgewinnen können.
Damit hab ich definitiv kein Problem.
Spiele wie Test Drive usw, diese sind ja framerate-unabhängig programmiert
Nicht ganz. Da hatten wir aber irgendwo hier einen Thread, wo das genau auseinandergedröselt wurde. War, glaube ich, hauptsächlich auf Test Drive 2 bezogen, aber der erste Teil zeigt da ganz ähnliche Verhaltensmuster. Grundsätzlich nutzt es weder den SCPU noch den TC64-Turbo voll aus. Eine deutliche Beschleunigung ist natürlich vorhanden, aber mit einer speziell angepassten Programmierung wäre sicher noch mehr drin. Die Amiga-Version hat allerdings das gleiche Problem, daß sie die schnellsten CPUs nicht annähernd ausschöpft.
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.
Oft benötigt man allerdings gar nicht das Maximum, sondern kommt locker damit aus, lediglich im Rahmenbereich zu beschleunigen, wie man das auch beim C128 gemacht hat. Beim TC64 kommt man so schon gut auf 5- bis 6-fache Geschwindigkeit. Das erwähnte Test Drive kommt damit auch schon an seine Grenzen.
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 man doch mal mehr als den Rahmenbereich für die Beschleunigung benötigt, könnte man sich natürlich damit behelfen, kurz vor dem eigentlichen Rasterinterrupt einen weiteren einzufügen, der lediglich den Turbomodus deaktiviert. Am Ende der eigentlichen Rasterroutine kann man den dann wieder einschalten. So kann der zeitkritische Rasterkram mit normaler Geschwindigkeit laufen und der Rest läuft beschleunigt.
Wenn ich deinen Erhuss dazu lesen will, lass ich Dich das...
Das tut mir aber leid, damit könnte ich dir ausnahmsweise leider 'mal nicht dienen.. .
Wer mehr Rechenleistung haben möchte, kann zum C128 greifen. Wieviel man an mehr benötigt ist ja gar nicht geklärt. Also, los, ran an den C128.
Ausgereizt ist der auf jeden Fall nicht. Das geht noch was, wenn man denn möchte.
Vorteil: Von dem Gerät gibt es mit Sicherheit die am weitesten verbreitete Alternative zum C64. Und nebenbei hätte man den C64 gleich noch dabei.
Man kann also gut vorhandene Sachen nutzen und muss gar nicht immer alles neu entwickeln.
Ich vergleiche C64-Beschleuniger gerne mal mit dem "SuperFX"-Chip fürs SNES.
Das ist aber ein ziemlicher Apfel/Birnen Vergleich
Nintändo hat den SuperFX Chip einfach mit ins Spielmodul gepackt, war so beim C64 doch garnicht möglich weil sich Spiele zu 99% doch nur durch Raubkopiererei verbreitet haben.
Gibt es Zahlen wie viele Stückzahlen von z.B. Turrican sich wirklich verkauft haben und man Vergleiche das mal mit dem StarFox Spie und dann mit den Ocean Spiele Modulen.
Micha
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.
Also Kernalload würde ich nie verwenden 
Ich habe selbst nur ne stinknormale 1541, zum Glück genügend funktionsfähige Disketten, und dass das Programm beim laden/speichern nicht vernünftig weiterlaufen kann ist für mich ein absolutes no-go. Aber naja, WENN ich mal was für den C64 entwickle mache ich es eh komplett frei und Open source (ist ja reines Hobby), von daher, wem es nicht passt, wie ich es umsetze, der kann es ja gerne selbst ändern 
kurz vor dem eigentlichen Rasterinterrupt einen weiteren einzufügen, der lediglich den Turbomodus deaktiviert. Am Ende der eigentlichen Rasterroutine kann man den dann wieder einschalten.
Das ist zunächst so wohl sicherlich möglich, stellt den Programmierer aber vor das Problem, daß der zusätzliche Wrappercode viel Aufwand erfordert. Da jeder Beschleuniger auf spezielle Art aktiviert/dekativiert wird, muß man entweder den Interrupt-Code zusätzlich patchen oder in mehreren Versionen anbieten. Und dann sollte der zusätzliche Code auch nur bei bestimmten Beschleunigern (also nicht C128) ausgeführt werden, damit es bei allen anderen Geräten keinen spürbaren Nachteil gibt. (Die zusätzlichen Interrupts werden durch die Beschleunigung kompensiert, bedeuten aber Ballast auf einem Vanilla-C64/C128.) Am Ende verbraucht man dann mal locker ein paar KB nur für die Interruptroutine und deren Anpassung, was sich negativ auf das eigentliche Programm auswirkt. Test Drive II ist in der Hinsicht besonders, daß es gleich über einen ganzen Haufen Rasterinterrupts verfügt. Eine vollständige Anpassung hätte damit niemals in den Speicher gepaßt.
Open source (ist ja reines Hobby)
Reines Hobby ist es bei mir auch. Rein theoretisch könnte jemand anders auch den Code übersetzen, aber letztendlich wird es an den Spezialtools scheitern, die für den Buildprozeß notwendig sind. So kenne ich zum Beispiel keinen anderen Assembler, der über Befehle verfügt, die Sektoren einer 1541-Diskette automatisch nach einem bestimmten Interleave-Wert anzuordnen (bzw. den bestehenden Interleave aufzuheben).
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.
Ich stimme dir voll und ganz zu, bis auf diesen zitierten Absatz: Es gab schon 1986 Leute, die hätten gerne diverse Software auf einer 1570/71 oder später 1581 laufen lassen, von daher wäre eine kompatible Lösung schon damals interessant gewesen, nicht erst mit dem SD2IEC. Siehe z. B. auch die Arbeit, die sich @Klaus Scheuer & Co. machen.
Ja, ist aus einem anderen Thread "geklaut"
Pustekuchen. Das Video habe ich selber gemacht und auf YT hochgeladen. Ätsch!!! 
Es gab schon 1986 Leute, die hätten gerne diverse Software auf einer 1570/71 oder später 1581 laufen lassen, von daher wäre eine kompatible Lösung schon damals interessant gewesen, nicht erst mit dem SD2IEC. Siehe z. B. auch die Arbeit, die sich @Klaus Scheuer & Co. machen.
Ich habe mitnichten etwas dagegen, wenn sich jemand die Mühe macht, Programme für die 1581 oder das SD2IEC zu konvertieren (, und das weiß er auch). Ich habe etwas dagegen, wenn jemand die Auffassung vertritt, daß Programme von vornherein SD2IEC kompatibel programmiert sein müssen, weil Tracklader "verpönt" sind.
Was die 1581 anbelangt, so denke ich, daß die Anzahl der Nutzer einer realen 1581 damals wie heute überschaubar ist, und wer sich eine 1581 zulegt, weiß auch, daß sie eben nicht kompatibel ist zum Standardlaufwerk 1541, und daß deswegen viele Programme nicht unbedingt direkt übertragbar sind.
Was die 1571 anbelangt, so stehe ich ehrlich gesagt auf dem Schlauch. Ich habe selber eine 1571, hatte aber noch nie Probleme wegen mangelnder Kompatibilität oder dergleichen. Von daher würde mich mal interessieren: Gibt es wirklich Software, die mit einer 1571 nicht läuft?
Von daher würde mich mal interessieren: Gibt es wirklich Software, die mit einer 1571 nicht läuft?
Ja - der Loader schreibt seine GCR-Decoder-Tabelle in genau den RAM-Bereich, in dem auch der 1571-Interrupt-Vektor liegt.
Nintändo hat den SuperFX Chip einfach mit ins Spielmodul gepackt, war so beim C64 doch garnicht möglich weil sich Spiele zu 99% doch nur durch Raubkopiererei verbreitet haben.
Das wäre doch mal eine Maßnahme gewesen, genau diese Raubkopiererei massiv zu erschweren. Die Industrie muß doch gemerkt haben, daß Diskettenkopierschütze den Aufwand nicht wert sind, da sie alle blitzschnell geknackt wurden. Und Dongles, die lediglich aus einem Widerstand bestehen, waren sowieso ein Witz.
Das wäre doch mal eine Maßnahme gewesen, genau diese Raubkopiererei massiv zu erschweren. Die Industrie muß doch gemerkt haben, daß Diskettenkopierschütze den Aufwand nicht wert sind, da sie alle blitzschnell geknackt wurden. Und Dongles, die lediglich aus einem Widerstand bestehen, waren sowieso ein Witz.
Von Seiten Commodores bestand kein Handluingsbedarf, wie auch Petro Tyschtschenko vor nicht allzulanger Zeit in einem Interview gesagt hat. Als reine, kurzsichtige Hardwarehersteller hatten die ja kein Interesse, ihren eigenen Umsatz durch zu rigide Maßnahmen zu schmälern. Auch die halbherzige GS-Konsole hatte ja keinen richtigen Kopierschutz, jetzt mal von der Modul-ROM-Grösse abgesehen.
Mal eine andere Frage: Wie könnte man heutzutage eine minimale, kostengünstige Turbokarte realisieren? Mit einer Beschleunigung um den Faktor 3 oder mehr.
Interessant finde ich teils die Doppelmoral einiger Leuten hier. Da wird auf Zusatz Hardware geschimpft aber im gleichen Atemzug aufs Mega 65 geschielt.
Ist das jetzt so ein Quark, wie einem Leute bei Autos vorwerfen dass man einen Oldtimer im Originalzustand fahren will, die Familienkutsche aber gerne mit modernen und praktischen Annehmlichlichkeiten hätte?
Komisches Argument.
So kenne ich zum Beispiel keinen anderen Assembler, der über Befehle verfügt, die Sektoren einer 1541-Diskette automatisch nach einem bestimmten Interleave-Wert anzuordnen
Wieso interessiert sich ein Assembler für Sektoren auf einer Diskette 
Interleave behandelt bei mir das Tool, das die fertigen Binaries auf das Diskettenimage schreibt (in meinem Fall mein eigenes, aber da gibt's ja auch noch andere). Hast du einen Assembler, dessen Output direkt ein Diskettenimage ist?
Was für den Buildprozess gebraucht wird sollte man wohl einfach dokumentieren (bei mir jetzt GNU make, cc65, exomizer, mkd64 und eine funktionierende C toolchain für das Host-System), das muss ich auch noch in meine README packen dann sollte das eigentlich jeder nachvollziehen können. Und wie gesagt, wenn jemand wirklich ums verrecken Kernalload haben will, dann viel Spaß beim umbauen
Nintändo hat den SuperFX Chip einfach mit ins Spielmodul gepackt, war so beim C64 doch garnicht möglich
Damals nicht, aber heute wäre es das. Und würde von einigen zutiefst abgelehnt und mit dem Untergang des Abendlandes gleichgesetzt.
Mein Punkt nochmal: Den SNES-Fans war es damals nur wichtig, auf IHRER Plattform ein tolles Spiel zu haben. Niemand wäre auf die Idee gekommen, zu sagen: "Aber das ist ja gar nicht mehr das richtige SNES, das verliert somit seinen Reiz". Auch einige C64-User wünschen sich tolle Spiele auf IHRER Plattform, dem C64. Wenn dazu eine gängige Erweiterung wie REU oder eben wie der Thread-Starter meinte, Turbomodi moderner Erweiterungen genutzt werden, ist es ihnen gerade recht. Andere wiederum (die Mehrheit) sieht den Reiz des C64 in seiner Limitiertheit allgemein - manche gehen ja sogar so weit, gerne Spiele von Tape zu laden.
Ich würde Erweiterungen nicht grundsätzlich verteufeln. Sam's Journey und viele andere alte und neue Titel zeigen: Man kann tolle Spiele auch ohne Erweiterungen bauen. So, da dies nun bewiesen ist, warum nicht mal ein Spiel mit REU-Support. Die REU ist schließlich von Commodore 1985 rausgebracht worden - allerdings mit max. 512K. Das fände ich nicht verwerflich.
ogd: es gibt sehr günstige FPGAs. Die Cyclone2 ICs fallen mir ein. Oder dieses Lattice 8$ Board:
http://www.latticesemi.com/en/…arlyGreyUPDuinoBoard.aspx
Darauf kann man doch nen CPU Core mit x MHz implementieren.
Vermutlich sind die Levelshifter das größte Problem.
Mich erinnert das ein bisschen an diese unsägliche Amiga-Diskussion, das alles komplett OS/System-konform und ja ohne Trackloader zu funktionieren hat, wenn man was programmiert.
Wenn man dann deswegen zu wenig Speicherplatz auf so nem original Amiga500 hat, dann sollen die Leute doch bitte hochrüsten auf 1MB ChipRam.
Als "Entwickler" für diese alten Kisten interessiert mich ehrlich gesagt nur die Originalkonfi.
