letzter Beitrag von echo am
Danke,dann sollte der ja auf meinem X2 2x1,6ghz ,1gb ram und der Geforce im Laptop tun ....
also ich hab nen e6700 (2 x 2,66ghz), nebst einer 8800gtx, x-fi fatality und 4gb ram. es wird eine gesamt-cpu-auslastung von 30-40% erreicht (winxp32 sp2).
während ladevorgängen erreiche ich eine warp-speed von ca. 500-600%. wenn nicht geladen wird bis ca. 1000%.
Hmm, dann dürfte ich auf meinen Computern so Pi mal Daumen ne Systemauslastung von 200-300% erreichen, es sei denn man kann zahlreiche rechenzeitraubende Features abstellen 
so, also ich höre immer erst auf meinem sid6581r3, dann nehm ich mir die SOASC-version bei, und dann die m64-version.
das teil ist in der hvsc unter "sounddemon/bojojoing.sid" sub1 zu finden, und ich muss leider sagen, daß wir da noch etwas zu tun haben.
von sog. "neu entdeckten wellenformen" möchte ich etwas abstand nehmen und das lieber erstmal als geschickt programmiertes mischen plus "missbrauch" der ringmod hinnehmen ... hoffe ich.
Okay aber wäre schon schön wenn Ihr es schafft mal eine 100%ige SID Emulation zu coden,
zur not mal bei HOXS64 anfragen 
der schein ja dicht dran zu sein.
Die Ausrede "missbrauch" kann ich da leider nich gelten lassen weil bei Cevi in alle Bereichen getrixt wird
deshalb macht Ihr ja auch eine neue VIC Engine da die bisherigen wohl alle nich 100% sind also beim
SID dann bitte auch. Denn eins ist mal sicher auf dem C64 wird ja getrixt bis das Silizium glüht 
Die Ausrede "missbrauch" kann ich da leider nich gelten lassen weil bei Cevi in alle Bereichen getrixt wird
deshalb macht Ihr ja auch eine neue VIC Engine da die bisherigen wohl alle nich 100% sind also beim
SID dann bitte auch. Denn eins ist mal sicher auf dem C64 wird ja getrixt bis das Silizium glüht
das war keine ausrede, sondern der versuch einer beschreibung, um was es sich bei den tönen wirklich handelt (im bezug auf die "neu entdeckten wellenformen", die ich nach wie vor für nicht existent halte).
Hmm, dann dürfte ich auf meinen Computern so Pi mal Daumen ne Systemauslastung von 200-300% erreichen, es sei denn man kann zahlreiche rechenzeitraubende Features abstellen
wie der bero schon geschrieben hat, gibts einen zweiten renderpath für schwächere maschinen.
deshalb hab ich bei meinen angaben ja extra erwähnt, daß es sich um sogenannte "ALLES HOCH" einstellungen handelt. 
Das hab ich wohl im Eifer des Gefechts überlesen. Na denn: Juhuu
Das hab ich wohl im Eifer des Gefechts überlesen. Na denn: Juhuu
das mit den verschiedenen renderpath hat bero selbst erwähnt.
dass ich die settings auf ganz hoch habe, davon hab ich anfangs des threads irgendwo mal gefaselt. 
eigentlich betrifft dies nur die sid-render geschichte. den eigentlichen leistungslevel wählt der m64 selber aus - also keine angst.
das war keine ausrede, sondern der versuch einer beschreibung, um was es sich bei den tönen wirklich handelt (im bezug auf die "neu entdeckten wellenformen", die ich nach wie vor für nicht existent halte).
Oh doch, man kann durch setzen des Testbits die Periode des RNG's der Rauschwellenform so stark verkürzen, so dass tatsächlich eine neue Wellenform entsteht. Dieser Trick ist relativ neu.
Toller Emu den ihr da baut. Schade nur das man die VIC-Emulation wegen mangelnden 50Hz-TFT nicht richtig werden geniesen kann. Und CTRs werden wohl mit der Zeit langsam aussterben.
Oh doch, man kann durch setzen des Testbits die Periode des RNG's der Rauschwellenform so stark verkürzen, so dass tatsächlich eine neue Wellenform entsteht. Dieser Trick ist relativ neu.
ok ... wieder was gelernt.
Toller Emu den ihr da baut. Schade nur das man die VIC-Emulation wegen mangelnden 50Hz-TFT nicht richtig werden geniesen kann. Und CTRs werden wohl mit der Zeit langsam aussterben.
lies dir den thread nochmal durch ... so von wegen pixelnachleuchten und so ...
Ahh... das hab ich garnicht so realisiert, das man mit dem pixelnachleuchten auch sowas nachbessern kann. Na dann ist die Freude um so größer mal endlich eine ruckelfreie Emulation an meinem TFT zu erleben.
Kann mirco64 auch mit dem ActionReplay umgehen? Also freezen und zwar so wie am realen C64. Weil der VICE hat da so seine Probleme. Als Beispiel nenne ich mal Turrican, wenn ich da im Spiel freeze lande prinzipiel dann im Freezemenü wenn die Ingamegrafik Pixelsalat zeigt und die Statusleise lesbar ist. Das ist am realen C64 nicht so.
Kann mirco64 auch mit dem ActionReplay umgehen?
Ja näturlich unterstützt Micro64 ActionReplay. Micro64 hat ja ein nahezu kompletten Cartridge Support, der zudem über DLLs/ELFs/etc. (das Betriebsystem jeweilige dazugehörige Dynamic Link Library Dateiformat) erweiterbar ist, z.B. für exotische neue Cartridge Hardware. Aber dazu muss ich allerdings auch noch ein SDk inkl. Doku anfertigen.
Das Projekt hört sich gut an, aber irgendwie gefällt mir nicht, wie geschlossen das alles abläuft. Wenn BeRo Interesse am Projekt verliert, dann ist es ja faktisch tot; niemand könnte es mangels Sourcecode fortsetzen. Das Zurückhalten von Hardwareinfos, die reverse engineered wurden, halte ich auch nicht für richtig - alle könnten von diesen Informationen profitieren (Man muss ja immer daran denken, dass die "C64-Community" nicht mehr sehr groß ist). Wenn ihr schon behauptet, dass der VIC-Artikel für den Papierkorb ist, dann möchte ich auch wissen wieso (OK, einige Fehler sind schon bekannt).
Das Projekt hört sich gut an, aber irgendwie gefällt mir nicht, wie geschlossen das alles abläuft. Wenn BeRo Interesse am Projekt verliert, dann ist es ja faktisch tot; niemand könnte es mangels Sourcecode fortsetzen. Das Zurückhalten von Hardwareinfos, die reverse engineered wurden, halte ich auch nicht für richtig - alle könnten von diesen Informationen profitieren (Man muss ja immer daran denken, dass die "C64-Community" nicht mehr sehr groß ist). Wenn ihr schon behauptet, dass der VIC-Artikel für den Papierkorb ist, dann möchte ich auch wissen wieso (OK, einige Fehler sind schon bekannt).
nun, also zuerst mal sollte man festhalten, daß das projekt freeware ist und bleibt. man bekommt am ende eine perfekte emulation für lau.
kein mensch finanziert einen aufwendigen reversing-prozess, ohne daß er selbst davon profitieren will. und so kann BeRo sich "von" schreiben, daß er am ergebnis teilhaben darf ... ohne finanzielle gegenleistung.
daß er sich da bereit erklärt, das projekt closed zu halten, ist doch nur normal - ob dir dieser ablauf nun gefällt oder nicht.
Natürlich ist das BeRos Entscheidung, aber ich halte sie eben einfach nicht für die Richtige. Interesse am Emulator habe ich natürlich trotzdem.
Ich hoffe, dass BeRo selbst oder ein Vertrauter sich möglichst bald an den OSX-Port macht. Die Userbasis ist ja weit höher als die von Linux (wenn man hier die ganzen Server abzieht, die nur reiner Server/Numbercruncher-Dienste ausführen) und die Nutzer stören sich auch weniger an Closed-Source Projekten als das bei den OS-Jüngern der Fall ist.
Zum Thema TFT-Sync: Sollte man nicht ein brauchbares Bild erhalten, wenn man den Screen auf 75Hz bringt und dann C64-Bilder teilweise mischt? Wenn man 50 Bilder auf 75 Bilder je Sekunde verteilen möchte, muss man ja immer 2 C64 Frames (1,2) auf 3 TFT-Frames (A,B,C) bringen. Wenn man das so macht, dass Frame A Frame 1 anzeigt, Frame B eine Mischung aus 1 und 2 und Frame C dann Frame 2, dann müsste es doch einigermaßen OK aussehen, oder? Und wenn man dann den ganzen Emu am Takt des Bildschirms aufhängt, müssten doch auch irgendwelche Zwischensprünge durch leichte Ungenauigkeiten wegfallen. Aber wahrscheinlich ist das alles viel komplizierter als ich mir das vorstelle, sonst hätten sie das ja schon überall eingebaut.
Hallo die 75Hz TFT Idee ist an und für sich Gut, wenn das TFT dann echte 75Hz ausgibt, das muss man dann aber im einzelfall mal Testen, wie gesagt die meisten Panels synchronisieren intern immer auf 60Hz, und ich hab schon einige durchprobiert :baby:
Anderer Punkt der echte Cevi macht keine genauen 50Hz sondern glaub ich 50,8 oder 51,2 weiss das jetzt leider nicht genau, das erklärt zumindest warum dann auch ein CCS oder VICE bei einem 50 Hz oder 100Hz doch alle paar sekunden sich mal kurz verschluckt.
Aber das nur zur Info. 
Oh doch, man kann durch setzen des Testbits die Periode des RNG's der Rauschwellenform so stark verkürzen, so dass tatsächlich eine neue Wellenform entsteht. Dieser Trick ist relativ neu.
http://noname.c64.org/csdb/forums/?roomid=14&topicid=24626
Hier der Link zur Technischen Diskussion wegen der neuen Wellenformen und wie man das ganze Programmiert! 
Nun, also zuerst mal sollte man festhalten, daß da sProjekt Freeware ist und bleibt. man bekommt am Ende eine perfekte Emulation für lau.
Ich habe überhaupt kein Problem damit, dass das Projekt Closed Source ist. Die beschriebenen Tricks zur Synchronität und allem sind ohne zweifel schwer umzusetzen und die ganze Arbeit soll auch entsprechend entlohnt werden. Dass er es sogar schafft, die REU-Tricks zu erlauben finde ich echt der Hammer.
Nein, das ist eine Software, für die ich auch bereit wäre, Geld auszugeben.
Davon abgesehen: Es wird einen Linux-Port, und damit entfällt für mich das Hauptargument gegen eine Closed-Source Version.
Allerdings muss ich gestehen, sollten die Informationen zu den Eigenheiten der Chips geheim bleiben, dann hinterlässt das bei mir schon auch einen faden Nachgeschmack. Das sind nicht Informationen, die geheim bleiben sollten. Und allzuoft gehen solche Informationen verloren, wenn die Firma nicht mehr existiert. Das darf nicht passieren. Ich hätte nichts dagegen, wenn die Informationen zwei bis vier Jahre geheim bleiben, aber irgendwann sollten sie öffentlich werden.
