Jens: bei der REU reicht (mir) vollkommen wenn sie kann was andere koennen. Was sie nicht kann ist da wurscht. Wenn aus solchen bugs mal nen super-trick(tm) gebastelt wird, interessiert (mich) das wenig.
Der Begriff 'REU' wird eh als synonym fuer RAM+DMA verwendet... Soweit ich weiss unterscheiden sich da Reu, CMD-Reu, c1541u-Reu ohnehin schon in solchen Punkten...
Bloss keine Lebensenergien daran verschwenden ![]()
Ton kratzt/verzerrt bei BluREU Demo
-
Micha1982 -
7. April 2010 um 01:38 -
Erledigt
Es gibt 29 Antworten in diesem Thema, welches 4.902 mal aufgerufen wurde. Der letzte Beitrag (
-
-
doch, auf der bp, ganz sicher. müssen wir jetzt aber wirklich nicht ausdiskutieren :=)Nein, ganz sicher nicht. Warum sollte ich sowas behaupten, wenn ich doch genau weiss, dass wir das probiert haben und es nicht geklappt hat? Da hast du wohl eher selbst was interpretiert, was ich eventuell gesagt hab ist, dass wir die Musik per DMA von der REU streamen - was wir ja auch tun, aber halt nur nicht direkt auf die Register!
Zitat
selbiger ist btw auch sehr an irgendwelchen anims für kleinere REUs interessiert ... schliesslich wollen wir ja nicht diese demo als testcase nehmen, und dann irgendwann merken das sich die emulierte reu nicht wie eine richtige reu, sondern wie die verbuggte 1541u implementation verhält
Mal sehen, was sich machen lässt. Wir denken über ein BluREU lite nach, für auf 2MB aufgebohrte REUs, aber da die paar Leute, die sowas haben auch noch ein MMC64 (nicht MMCR) mit REU-plugin brauchen zum laden dürfte die Zielgruppe doch SEHR überschaubar sein! Dennoch waren im IRC gestern zwei Leute, Tuffi und Exin, die die entsprechende Hardware haben. Gibt's noch mehr? Meldet euch!
Für original-REUs wär's ziemlich sinnlos, 256kb bzw. 512kb ist einfach viel zu schnell voll! In 256kb passt grad mal eine Sekunde (12 frames), in 512kb 23 frames, d.h. 2 Sekunden Anim... Da hab ich nix ordentliches in BluREU, das kurz genug ist und loopen würde! Wobei... Wenn ich bei dem Pilzwürfel (29 frames) jeden zweiten Frame skippen würde könnt's klappen...
-
Zitat
Soweit ich weiss unterscheiden sich da Reu, CMD-Reu, c1541u-Reu ohnehin schon in solchen Punkten...
nur letztere von den ersten beiden, die cmd-reu benutzt ja genau den gleichen rec chip. -
Soweit ich weiss unterscheiden sich da Reu, CMD-Reu, c1541u-Reu ohnehin schon in solchen Punkten...
Inwiefern denn ? CMD Reu ist zu 100% der Commodorereu kompatibel.
-
Bezüglich der nicht-emulation des DMA-auf-Register-Problems: Hmm, das ist so ne Sache.... Bugs sollten eigentlich schon immer emuliert werden, weil wenn jemand darauf entwickelt geht's dann woanders nicht! Das ist bei den Konsolen-Emus immer ein ziemliches Problem, denn die emulieren Bugs nur recht selten - weil ja nur die existierenden Spiele einwandfrei drauf laufen müssen - und die umgehen Bugs in der real hardware ja sowieso!... Dummerweise eignen sich dann manche Emus nicht zum Entwickeln, fragt z.B. mal die Atari-VCS-Homebrew-Coder was sie von Stella halten, da gab's so einige Demos/Effekte, die leider auf real HW nicht gehen!

Passiert aber nicht nur auf Konsolen: Könnt ihr euch noch erinnern, als VICE den ROMchar noch nicht emuliert hat und Ambercow von Charged dann auf real hw buggte, weil die da ihre Sprites hingelegt haben?
Bitte melde dich an, um diesen Link zu sehen.
Und hätten wir BluREU ausschließlich auf VICE entwickelt würde das auf real HW auch nicht gehen, weil der VICE den $07ffff-wraparound-bug des REC nicht emuliert!....
Und jetzt lasst mal jemand ne Demo machen, die auf die Register schreibt!... Das löppt dann nie ordentlich auf echter Hardware - bzw. *nur* auf dem Chameleon!
Wie hat das TMR eigentlich gemacht? Der schreibt in seinem REU-Demo ja auch direkt auf $d020:
Bitte melde dich an, um diesen Link zu sehen.Vielleicht sollten wir den Bug genauer analysieren? Wann der genau auftritt usw?

Ach ja, Jens: Hast denn BluREU mal auf Chameleon ausprobiert?
Läuft das? Ich hab als wir's geplant haben ja mal ein bisschen rumgestöbert und die Threads im 1541u forum studiert, in denen womo ein paar REU-Testprogramme gepostet hat und bugs bei der REU-Emu des 1541u bemängelt hat (ein zyklus delay nach nem DMA und so kram!). Das sollte laut Gideon in kommenden Firmwares gefixt werden, aber ob's wirklich gefixt worden ist konnte ich leider nicht ermitteln, weder Gideon noch womo haben auf meine Mails diesbezüglich reagiert... -
Hm, diesen Ansatz in Ehren, aber das wird letzten Endes immer am coder haengen bleiben.
Beispiele:
Ueber meine Grey-dot-demo- sind alle hergefallen, dennoch ist der Effekt glasklar und nervt (wenn auch nicht auf allen C64), siehe GianaSisters & Co.ZIG Demos haben den Effekt-Sid-Sync in vice gemacht -> buffer-lag. DAS sieht man in der Tat (LAME).
Tape-loader fuer/in vice coden ist auch NOGO^10. Dennoch schaffen es Leute das sauber zu machen. Wer meint nen schnelleren Loader/streamer gecodet zu haben der dann nur in vice laeuft -> lame.
Vice (und NeoRAM) setzt die address-register auf 0 bei reset, GeoRAM nicht.
Vice setzt RAM auf 00,ff pattern bei init -> so mancher code crasht dann am echten C64 mit etwas pech -> lame.
BluREU laeuft ja eben nicht auf 'echter' REU (wenn auch nicht auf Grund von bugs natuerlich), sondern (bisher) nur auf 1541u.
Klar sollte das Cham. eher die echte REU als die 1541u-implementierung unterstuetzen aber naja.
Meine Aussage "bugs stoeren mich nicht" ist nicht schoen und auch gefaehrlich. Da die REU aber SOWEIT ausserhalb des Stock C64 liegt und wahrlich nicht sonderlich weit verbreitet ist (echte REU meine ich jetzt),
finde ich, dass es das Cham. damit nicht uebertreiben sollte.Tape, grey-dots stehen _bei mir_ viel weiter oben... =D
-
Bugs sollten eigentlich schon immer emuliert werden
selbstverständlich. aber sicherlich nicht die bugs der 1541u, denn die emuliert vice ja nicht
Und hätten wir BluREU ausschließlich auf VICE entwickelt würde das auf real HW auch nicht gehen, weil der VICE den $07ffff-wraparound-bug des REC nicht emuliert!....
das mag sein das vice das nicht emuliertE
trotzdem ist die emulation von vice deutlich näher an einer echten reu als es die 1541u istWie hat das TMR eigentlich gemacht? Der schreibt in seinem REU-Demo ja auch direkt auf $d020:
da ist es ja auch wurscht wenn mal ein schreibzugriff zu spät kommt oder garnicht. das geht ja prinzipiell, nur halt manchmal nichtDas sollte laut Gideon in kommenden Firmwares gefixt werden, aber ob's wirklich gefixt worden ist konnte ich leider nicht ermitteln, weder Gideon noch womo haben auf meine Mails diesbezüglich reagiert...
nein, das wurde niemals gefixt. und gideon antwortet diesbezüglich nicht auf mails weil ihm das offensichtlich egal ist und das "genörgel" nervt. und womo antwortete schon immer genau so selektiv auf mails wie ich zb auch =PKlar sollte das Cham. eher die echte REU als die 1541u-implementierung unterstuetzen aber naja.
tut es auch, eine kaputte emulation zu emulieren ist auch irgendwie sinnfrei. -
$07ffff-wraparound-bug des REC
Das ist kein Bug der Hardware, sondern eine Schwäche der Dokumentation von REU-Mods. Der REC hat nunmal nur 19 Bits in den Adresszählern, die Bits darüber werden nur festgehaten.Und jetzt lasst mal jemand ne Demo machen, die auf die Register schreibt!... Das löppt dann nie ordentlich auf echter Hardware - bzw. *nur* auf dem Chameleon!
Ist auf der einen Seite lame, das nur auf Chameleon zu testen und dann zu releasen. Auf der anderen Seite hast Du Recht, wir haben den Anspruch, besser als Emulation zu sein. Wenn das konsequent durchgezogen werden soll, müssten wir eigentlich auch die Bugs implementieren, die auf der Original-Hardware passieren. Ich frag' Peter mal, ob das Schreib-Timing in Abhängigkeit von der Quelle angepasst werden kann - auch wenn ich mich jetzt schon auf virtuelle Haue von ihm einstelle...Wie hat das TMR eigentlich gemacht? Der schreibt in seinem REU-Demo ja auch direkt auf $d020:
VIC und SID haben unterschiedliches Timing. Das Timing der REU ist immer konstant. Vermutlich ist die Mehrheit der VICs zufrieden mit der Haltezeit der Adressen/Daten, der SID jedoch nicht. Das müsste man wirklich mal genauer untersuchen. Vielleicht mal nen Haufen Daten in die Sprite-Register schreiben und vergleichen? Müsste man doch recht einfach mit der copy/verify Option der REU machen können. Roland?Jens
-
Hab zwei Brotkästen mit 6581 (R3&R4AR) bei denen der Ton bei Bluereu ziemlich am Anfang, wenn der Track ganz tief wird, total verzerrt. Bei zwei C64II ist alles normal. Kann das am 6581 liegen oder sollte ich die Brotkasten Boards mal checken?
-
Kann das am 6581 liegen [...]?
Ja, kann es, denn alle Musik bei BluREU ist auf 8580 ausgelegt.
-