RND-Zahlen von 0-10 in ASM

Zitat

Ob VICE das korrekt emuliert, keine Ahnung, ich würde aber nicht drauf wetten.

nein. erstens fängt er (im gegensatz zu einem echten c64) immer mit dem gleichen seed an. zweitens ist das polynom ansich falsch wenn ich mich recht erinner. sounddemon hat dazu ja mal nette tests gemacht... weiss nicht ob die patches mitlerweile in den mainstream resid einzug gehalten haben. hoxs64 macht es wohl richtig.

und zum thema kippende bits und wissenschaftlichkeit fällt mir nur wieder ein zitat ein:

Zwei Dinge sind zu unserer Arbeit nötig: Unermüdliche Ausdauer und die Bereitschaft, etwas, in das man viel Zeit und Arbeit gesteckt hat, wieder wegzuwerfen. <Albert Einstein>

Zitat

Die Basic-Routinen nehmen für RND(0) üblicherweise die CIA Timer und TOD-Counter. Die funktionieren auf dem Emulator, schätze ich mal, genauso. Mit den Zeilen/Spaltencountern bin ich unsicher und bei den SID-Quellen sehe ich schwarz.

aua. nein nein und nein. bitte da wo ich mich im ton vergreife (so bin ich halt) scheinst du dich an dinge zu "erinnern" die einfach falsch sind.

Zitat

Original von Oliver_A

Gerade der SID ist noch einer der besseren RNGs im C64, denn der Rauschgenerator generiert eine ungewöhlich lange Sequenz für einen Soundchip aus der Zeit (2^23 - 1). Ist im Prinzip auch nichts anderes als ein LFSR, dessen MSB sich auslesen lässt. Nimmt man dan noch andere Faktoren hinzu, die den Zeitpunkt der Initialisierung und des Auslesens beeinflussen (Tastendruck des Users) denke ich schon, dass man ein ausreichend grosses Maß an zufälligen Ereignissen generieren kann, aber nun gut.

Ah! Die Periode des Rauschgenerators war mir unbekannt. Klingt aber an sich gut. Müsste man mal testen. Wackeln die 0-Bits bei den AD-Wandlern eigentlich auch auf dem Vice-Emulator? Ich kann mich düster erinnern, dass die Dinger immer schön gewackelt haben.

Gerade getestet - Nein. Wackeln natürlich nicht.

Ich werde mal sehen, ob ich das mit dem Generator testen kann.

Ah, falls jemand zu der Aussage zur Initialisierung von RND(0) Einwürfe hat, verweise ich auf KERNEL $E09E. Bei RND(0) wird Timer A low+high sowie TOD 1/10 und sec geladen und in den Seed bei $62..$65 folgende gespeichert. Das sind also die Random-Quellen vom Betriebssystem.

Zitat

Original von cbmhardware
Ich habe auch mal eine Frage: Wie sieht es eigentlich mit nicht richtig dekodierten i/o-Bereichen im "echten" C64 aus ? - Kann man da evtl. einen Seed rausziehen ?

Nicht wirklich,denn sobald eine Erweiterung sich in diesen Bereich mapped, funktioniert das nicht mehr. Die Colorram Methode ist hingegen prinzipiell eine gute Idee. Aber auch nur als Seed.

@Hanno:

beim SID RNG bitte aufpassen, denn der Updated sich nämlich gemäß der Eingestellten Frequenz des Soundkanals. Auch sollte die Waveform natürlich auf Rauschen eingestellt sein, denn sonst liest man nämlich die weitaus deterministischeren Wellenformen wie Dreieck, Sägezahn oder Puls aus.

Zitat

Ich habe auch mal eine Frage: Wie sieht es eigentlich mit nicht richtig dekodierten i/o-Bereichen im "echten" C64 aus ? - Kann man da evtl. einen Seed rausziehen ?

nein, nicht wirklich... die werte die man da liesst sind nur augenscheinlich zufällig. in wirklichkeit sind sie aber alles andere als das, auf manchen c64 kann man in dem bereich sogar code laufen lassen bei interesse mal die ausführungen von marko makäla lesen (wenn ich mich recht erinner in der C=Hacking erschienen).

(und bevor es jemand probiert: das emuliert kein emulator korrekt soweit ich weiss)

edit: olli, liesst man beim colorram nicht auch (wie beim i/o) das was als letztes auf dem bus lag?

Zitat

Original von sauhund
edit: olli, liesst man beim colorram nicht auch (wie beim i/o) das was als letztes auf dem bus lag?

Ja, deswegen sage ich ja: aber auch nur als Seed. Ich glaube, dass wenn man alle Quellen miteinander kombiniert, man schon ein sehr zufälliges Muster erzeugen kann.

Zitat

Ja, deswegen sage ich ja: aber auch nur als Seed. Ich glaube, dass wenn man alle Quellen miteinander kombiniert, man schon ein sehr zufälliges Muster erzeugen kann.

mmmh, ich weiss nicht... da muss man zumindest sehr genau wissen was man tut, denn je nach setup ist das ja äusserst vorhersehbar. als seed würde ich immer irgendeinen timer laufen lassen und dann mit einer benutzereingabe verknüpfen, wie schon gesagt. das ist immer so zufällig wie es nur sein kann, und dazu sehr einfach zu realisieren

Hmmm, man müsste schauen. Das Colorram Bus Problem lässt sich u.U. auf das Rasterzeilen Problem zurückführen, da die VIC Fetches ja prinzipiell davon abhängen, in welcher Rasterzeile sich die CPU befindet. Ich persönlich bin ja der Meinung, dass SID RNG kombiniert mit Auswertung der Zeitintervalle des menschlichen Spielers ausreichen müsste. Das Problem ist jedoch da, sobald man Musik abspielen möchte. Andererseits müsste das Auslesen der CIA Timer dasselbe Ergebnis liefern. Naja, nicht ganz, weil die CIA Timer nur 16bit sind.

Ich komme zum Schluss: es gibt viele Wege, sich das Leben schwer zu machen.

Zitat

Ich komme zum Schluss: es gibt viele Wege, sich das Leben schwer zu machen.

das ist mal sicher

Damit alle, die es interessiert, den Test selbst machen können, hab ich die Random-Routinen nochmal um den Sid-Generator erweitert. Das Ding muss jetzt aber intensiv überprüft werden. Mit einem Basicprogramm reicht das meiner Meinung nach nicht. Ich habe die SID-struct für Assembler erstellt und dem random.tar-Archiv beigelegt, so dass der Registerzugriff schön übersichtlich und lesbar wird mit cc65.

Die längste Arbeit hat dabei die syntaktisch korrekte Erstellung des Includefiles gemacht. Die Befehle zum Auslesen des Registers sind natürlich trivial...

Hier habe ich mal eben eine kleine Statistik über den C64-Rauschgenerator programmiert. Die 256 Werte werden 256*100 vom Generator eingelesen, so dass normalerweise durchschnittlich 100 Hits in jedem Byte unseres Zählerarrays sitzen müssten.
Bei mir auf VICE kam ein furchtbares Ergebnis heraus mit sichtbarer Wiederholung. Und zwar waren alle 4 Ausgaben (Zeilenende meine ich siehe Basicprogramm) immer abwechselnd die Werte größer und kleiner, Beispiel: 113,73,116,87,125,78,116,72 usw. usf.

Ich bitte das mal auf einem Original 64er zu kontrollieren.

Tar liegt wie immer bei. Start der Routine bei $9000 out of the box. Basicprogramm müsst ihr selbst tippen.

Wenn mal jemand ein paar fertige Grafikroutinen hat, mach ich euch das sichtbar mit einem Bild. Aber ich hab gerade keine Lust, das Rad neu zu erfinden und noch eine Grafik-Lib zu schreiben.

äääh, du solltest zumindest den ton auch anschlagen und eine (vorzugsweise hohe) frequenz einstellen....sonst kommt da natürlich schrott bei raus.

Wenn ich das sehe, ist es nicht nötig, den Ton anzuschlagen. Ob die Frequenz einen Einfluss hat, das kann ich gern ausprobieren. Halte ich aber für unwahrscheinlich. Ich denke, der Rauschgenerator läuft mit einer stabilen Geschwindigkeit, der durch die Taktfrequenz des SID definiert ist und wird als Eingang für einen (durch die Frequenz) programmierbaren Bandpass beschickt, so dass ein rosa Rauschen bei herauskommt. Bitte mich zu korrigieren, wenn ich mich irre.

Ich habe keinen Einblick in die interne Verschaltung des SIDs jenseits des Blockschaltbildes, werde aber mal Frequenzeinstellungen testen. Halte das aber für unwahrscheinlich, dass das was ändert.

mmmh das der ton nicht angeschlagen werden muss könnte sein (also das OSC3 _vor_ dem hüllkurvengenerator abgegriffen wird) ... aber das da noch extra ein bandpass drinne ist glaube ich nicht, ist ja viel einfacher den oszillator schneller laufen zu lassen.

Zitat

Original von Hanno Behrens
Wenn ich das sehe, ist es nicht nötig, den Ton anzuschlagen. Ob die Frequenz einen Einfluss hat, das kann ich gern ausprobieren. Halte ich aber für unwahrscheinlich. Ich denke, der Rauschgenerator läuft mit einer stabilen Geschwindigkeit, der durch die Taktfrequenz des SID definiert ist

Nein, die Frequenz des Rauschgenerators lässt sich ebenfalls einstellen, da der Rauschgenerator im SID in erster Linie eine Soundgenerator ist.

Also ich habs gerade getestet. Der Anschlag des Tones sollte überhaupt keinen Einfluss auf den Ablauf des Oszillators haben, nur auf den Ablauf des Hüllkurvengenerators. Und der wird nicht abgegriffen auf SID+Sid::random.

Ich hab mir gerade nochmal das SID Datenblatt gesaugt. Steht aber auch nichts zu drin. Ich habe zwei verschiedene Frequenzen ausprobiert, einmal das C2 und das C7. Kein Unterschied, wie ich mir gedacht habe. Aber das ist weiterhin nur auf dem VICE. Bitte das mal auf einer Originalmaschine zu vergleichen. Die Werte bleiben jedenfalls stabil schlecht.

Nachtrag: rand.bin ist der gespeicherte Bereich $8f00 bis $8fff zur Kontrolle

Du darfst das nicht mit VICE testen, denn die SID Emulation lässt nämlich zu wünschen übrig. Was Du generell ausliest ist nämlich nicht irgendein spezielles Zufallsregister im SID, sondern die oberen 8 bit vom Waveform DAC von Kanal 3. Du solltest die Frequenz von Kanal 3 auf den höchstmöglichen Wert setzen.

Das C7 ist schon ziemlich am oberen Ende der Leiste. Also da kann ich nicht mehr viel machen. Damit jeder sehen kann, was ich hier für Werte bekomme, habe ich eben nochmal den Speicherbereich von $8f00 bis $8fff zum Tar hinzugefügt als "rand.bin". Nur zur Gegenkontrolle. Wenn diese Werte auf einem Original 64er besser werden, wäre es ja schön. Ich könnte mir aber auch nochmal ansehen, was meine Vice-Version an der Stelle macht. Ich hab hier eigentlich die neueste Version.

Sind die Werte auf einem Original nicht besser, halte ich sie für unbrauchbar. Zumindest in dieser Art des Gebrauchs.

ich habs grad mal aufm c64 laufen lassen und für mich sehen die werte eigentlich gut aus.... obwohl man deine funktion warscheinlich mal auf 16 bit zähler ändern müsste damit man mal aussagekräftigere werte kriegt.