Vermutlich würde sich eine Sammelbestellung lohnen, aber abgesehen vom "Graus" sie zu finden, fehlt mir leider auch die Zeit... Ja, ich bin "schrecklich" 
Hallo Besucher, der Thread wurde 98k mal aufgerufen und enthält 933 Antworten
letzter Beitrag von AndiraC64 am
Sonic the Hedgehog für C64/128 mit REU
- mrsid
- Erledigt
-
-
Gibt's nich schon ne Weile einen Open-Source-REU-Nachbau aus relativ günstigen Komponenten?
-
Gibt's nich schon ne Weile einen Open-Source-REU-Nachbau aus relativ günstigen Komponenten?
Zeig mal.
Stefan
-
Der 512kb wrap Bug sollte bei einer REU-Neuetwicklung entfernt werden.
Gerade NICHT, denn sonst laufen REU-Programme in Zukunft nicht mehr auf echter Hardware.
-
Der 512kb wrap Bug sollte bei einer REU-Neuetwicklung entfernt werden.
Gerade NICHT, denn sonst laufen REU-Programme in Zukunft nicht mehr auf echter Hardware.
Genau, dieser Bug und diverse andere Quirks sollten nicht entfernt, sondern eher optional gemacht werden.
Und dann auch nur abgeschaltet werden, wenn die Software wirklich mehr REU-RAM braucht, als auch die maximal ausgebauten Original-REUs liefern können.
-
Original von Commodore gabs doch nur die REUs bis 512 KB, alles andere waren doch "aufgebohrte" REUs, die nachträglich mit mehr Speicher erweitert wurden und genau die haben diesen Wrap Bug. Ich vermute mal, dass Commodore das so nicht rausgegeben hätte, wenn sie eine größere REU angeboten hätten, sondern auch den Adressbereich des DMA-Chips erweitert hätten.
-
Der 512kb wrap Bug sollte bei einer REU-Neuetwicklung entfernt werden.
Gerade NICHT, denn sonst laufen REU-Programme in Zukunft nicht mehr auf echter Hardware.
Genau, dieser Bug und diverse andere Quirks sollten nicht entfernt, sondern eher optional gemacht werden.
Und dann auch nur abgeschaltet werden, wenn die Software wirklich mehr REU-RAM braucht, als auch die maximal ausgebauten Original-REUs liefern können.
Soweit ich die Sache überblicken kann hätte ein fixen dieses Bugs keine negativen Auswirkungen, da der Workaround kompatibel wäre.
Die Software packt kleinere Pakete aber trotzdem passen die eine große Paketbox, umgekehrt wäre es anders.
-
Der 512kb wrap Bug sollte bei einer REU-Neuetwicklung entfernt werden.
Gerade NICHT, denn sonst laufen REU-Programme in Zukunft nicht mehr auf echter Hardware.
Das wird passieren und zwar bewusst, da bestimmte Software halt >512KB benötigt oder gar mehr als >2MB.
Es dürfte kein großes Problem sein eine Erkennung einzubauen die die Menge an Speicher erkennt und das vorhanden sein des Warp Bug prüft und entsprechend entweder die Ausführung verhindert oder eine Eingeschränkte Version startet.
-
Es dürfte kein großes Problem sein eine Erkennung einzubauen die die Menge an Speicher erkennt und das vorhanden sein des Warp Bug prüft und entsprechend entweder die Ausführung verhindert oder eine Eingeschränkte Version startet.
Es geht um existierende Software, nicht Neuentwicklungen.
Wenn irgendeine Emulation oder Nachbau daherkommt und Dinge umstößt, auf die sich bestehende Software verlässt (und dann kläglich scheitert), weckt das eher wenig Vertrauen in die neuerfundene Hardware.
-
Es dürfte kein großes Problem sein eine Erkennung einzubauen die die Menge an Speicher erkennt und das vorhanden sein des Warp Bug prüft und entsprechend entweder die Ausführung verhindert oder eine Eingeschränkte Version startet.
Es geht um existierende Software, nicht Neuentwicklungen.
Wenn irgendeine Emulation oder Nachbau daherkommt und Dinge umstößt, auf die sich bestehende Software verlässt (und dann kläglich scheitert), weckt das eher wenig Vertrauen in die neuerfundene Hardware.
spielt in diesem Fall aber keine Rolle, weil es keinen Unterschied macht.
-
Es dürfte kein großes Problem sein eine Erkennung einzubauen die die Menge an Speicher erkennt und das vorhanden sein des Warp Bug prüft und entsprechend entweder die Ausführung verhindert oder eine Eingeschränkte Version startet.
Es geht um existierende Software, nicht Neuentwicklungen.
Wenn irgendeine Emulation oder Nachbau daherkommt und Dinge umstößt, auf die sich bestehende Software verlässt (und dann kläglich scheitert), weckt das eher wenig Vertrauen in die neuerfundene Hardware.
spielt in diesem Fall aber keine Rolle, weil es keinen Unterschied macht.
Wenn der Nachbau nur sehr bedingt zur Original kompatibel ist (insbesondere bei Datenmengen, die das Original auch kann), ist das eigentlich kein Nachbau, sondern ein inkompatibles neues Produkt, das dann auch einen anderen Namen braucht.
-
Der Wrap Bug wird aber von keiner Software benötigt, der ist nur lästig und man muss drumherum programmieren. Wenn man dies tut, läuft die Software aber auch, wenn der Bug nicht existiert, z.B. der Nuvieplayer und Breadamp laufen sowohl mit als auch ohne Wrap Bug.
Es handelt sich hierbei um einen Adressierungsbug, der auftritt, wenn man einen Transfer über eine 512K-Grenze hinaus macht (Grenzen sind $080000, $100000, $180000, ..., $E80000, $F00000, $F80000).
Um das zu umgehen, sorgt man in seiner Software dafür, dass man keinen Transfer über diese Grenzen hinaus macht. Das kann man entweder machen, indem man die Daten in der REU so anordnet, dass z.B. ein Bild / Datenpaket nicht über solch eine Grenze geht (z.B. bei Nuvies oder bei Breadamp) oder im Programm dafür sorgt, dass ein "grenzübergreifender" Transfer in zwei Transfers gesplittet wird (z.B. von $07xxxx - $07FFFF und von $080000 - $08yyyy).
Macht man das nicht und überschreitet beim Transfer z.B. die Grenze von $080000, liest er nicht ab $080000 weiter, sondern ab $000000 oder ab $F80000 (habe beides schon erlebt, hängt offenbar von der Emulation ab), was natürlich nicht das ist was man möchte (ergibt dann Datenfehler, z.B. korrumpiertes Bild).
Ist der Bug nicht vorhanden und das Programm erwartet den Bug und splittet den Transfer in zwei Teile passiert gar nichts: dann macht das Programm trotzdem den gesplitteten Transfer, auch wen er nicht nötig wäre und erhält die korrekten Daten.
Mir ist kein Programm bekannt, dass diesen Adressierungsbug benötigt / ausnutzt. Mir fällt auch kein Szenario ein, wo man diesen Bug sinnvoll zu seinem Vorteil nutzen könnte, er ist in der Regel einfach nur lästig und zieht die Performance der Programme runter, weil sie mit zusätzlichen Prüfungen und Transfers um den Bug herumarbeiten müssen (musste ich z.B. bei meinen Videoplayer mit dem DoReCo-Video, da kam "Daten ausrichten" nicht in Frage, weil ich da so große Lücken gehabt hätte, dass das Video nicht in die 16 MB gepasst hätte).
-
Ist der Bug nicht vorhanden und das Programm erwartet den Bug und splittet den Transfer in zwei Teile passiert gar nichts: dann macht das Programm trotzdem den gesplitteten Transfer, auch wen er nicht nötig wäre und erhält die korrekten Daten.
Mir ist kein Programm bekannt, dass diesen Adressierungsbug benötigt / ausnutzt. Mir fällt auch kein Szenario ein, wo man diesen Bug sinnvoll zu seinem Vorteil nutzen könnte, er ist in der Regel einfach nur lästig und zieht die Performance der Programme runter, weil sie mit zusätzlichen Prüfungen und Transfers um den Bug herumarbeiten müssen (musste ich z.B. bei meinen Videoplayer mit dem DoReCo-Video, da kam "Daten ausrichten" nicht in Frage, weil ich da so große Lücken gehabt hätte, dass das Video nicht in die 16 MB gepasst hätte).
Ein weiterer Punkt ist der Amber-Cow-Effekt.
Wenn es eine Implementation ohne Bug gibt, wird es früher oder später eine Software geben, bei der der Erfinder nichts von dem Bug wusste.
Dann läuft die super in der Emulation, aber nicht auf echter Original-Hardware.
-
solche Bugs hat die 6502-CPU doch auch... muss man halt lernen damit zu leben
-
Mir ist kein Programm bekannt, dass diesen Adressierungsbug benötigt / ausnutzt. Mir fällt auch kein Szenario ein, wo man diesen Bug sinnvoll zu seinem Vorteil nutzen könnte, er ist in der Regel einfach nur lästig ...
Es geht darum, dass der Bug nun mal in den orginialen REUs drin ist. Und wenn man möchte, dass alle Programme, auch die zukünftigen, die die REU benötigen, auch auf der originalen REU korrekt laufen, dann muss man diesen Bug zwangsläufig mit einplanen und damit leben bzw. damit programmieren und das völlig egal, wie die Nachbauen das ohne diesen Bug machen (würden).
-
Ich würde meinen, eine Variante zur "Umschaltung" sollte alles abdecken. Dann wäre der Bug für alle jenen enthalten, die ihn gerne nutzen möchten, weil sie sagen, er gehört nunmal dazu, auch wenn er eventuell VIELLEICHT keine Rolle spielen würde, wenn - und er ließe sich abschalten für alle künftigen und noch in Arbeit befindlichen Programme, die mehr als die klassischen 512 K nutzen wollen & könnten, wenn sie den Bug dafür nicht umständlich umgehen wollen. mit BUG = Retro und klassische Variante - ohne Bug = moderner und einfacher für neue Projekte...
Dann muss man nicht länger streiten, was nun besser WÄRE und müßte und könnte, weil oder weil nicht... - und einig werden scheint auch irgendwie nicht absehbar - aber mit Umschaltmöglichkeit sollten BEIDE Seiten zufrieden gestellt werden können, oder?
-
Mir ist kein Programm bekannt, dass diesen Adressierungsbug benötigt / ausnutzt. Mir fällt auch kein Szenario ein, wo man diesen Bug sinnvoll zu seinem Vorteil nutzen könnte, er ist in der Regel einfach nur lästig ...
Es geht darum, dass der Bug nun mal in den orginialen REUs drin ist. Und wenn man möchte, dass alle Programme, auch die zukünftigen, die die REU benötigen, auch auf der originalen REU korrekt laufen, dann muss man diesen Bug zwangsläufig mit einplanen und damit leben bzw. damit programmieren und das völlig egal, wie die Nachbauen das ohne diesen Bug machen (würden).
Und da drehen wir uns jetzt im Kreis, weil Sonic ja selber ein Spiel ist, das am C128 nur mit einer "modernen" REU läuft, weil es den 2 Mhz-Modus nutzt, der bei den originalen REUs eben ab Werk und dokumentiert nicht funktioniert.
-
Es geht darum, dass der Bug nun mal in den orginialen REUs drin ist. Und wenn man möchte, dass alle Programme, auch die zukünftigen, die die REU benötigen, auch auf der originalen REU korrekt laufen, dann muss man diesen Bug zwangsläufig mit einplanen und damit leben bzw. damit programmieren und das völlig egal, wie die Nachbauen das ohne diesen Bug machen (würden).
Aber geht das denn überhaupt? Original wären ja "nur" 512 k vorhanden - neue Projekte wollen aber mehr RAM haben und DA schlägt - wenn ich das richtig verstanden habe - der Bug zu - aber wenn das Programm sowieso MEHR RAM haben will - wie soll es dann überhaupt auf der klassischen REU laufen?
Oder wo denke ich da jetzt falsch? -
... aber mit Umschaltmöglichkeit sollten BEIDE Seiten zufrieden gestellt werden können, oder?
Vielleicht verstehe ich dich jetzt falsch, aber wenn man die orginal REU als Basis nimmt, auf der auch REU-Software laufen soll, dann muss der Bug zwangsläufig mitberücksichtig werden. Am Original kann man den Bug nicht abschalten, der ist einfach da.
-
Klar, aber da hast Du ja eh "nur" die 512 k verfügbar?!? Aber irgendwo stand, erst bei MEHR RAM tritt das Problem auf, bzw. der BUG - also bei neueren Nachbauten, die mehr RAM onboard haben? Und das sind ja eh keine originalen REU mehr, oder? Bin gerade verwirrt...
