SCPU ist geil! Metal Dust ist geil!
SCPU auf TC64 möglich ?
-
peiselulli -
19. März 2014 um 15:41 -
Erledigt
Es gibt 106 Antworten in diesem Thema, welches 15.258 mal aufgerufen wurde. Der letzte Beitrag (
-
-
Ich habe Chester nochmal kontaktiert - grundsätzlich ausgeschlossen hat er den Port aufs Chameleon nie, und wenn's letztlich nur um "samples abspielen" und "Kanäle mischen" geht, ist auch keine 65816 CPU erforderlich. Ich kann mir überhaupt nicht vorstellen, dass irgendwas auf dem Chameleon nicht geht, was auf einer Flash-8 möglich ist - dafür ist der Turbo im Chameleon zu mächtig. Da müsste man schon massiv mit 16-Bit Operationen hantieren, was aber bei einem Spiel ehr unwahrscheinlich ist.
Jens
-
Ich habe Chester nochmal kontaktiert - grundsätzlich ausgeschlossen hat er den Port aufs Chameleon nie
Super. Wenn er keine Lust dazu hat, dann nehm ihm das Chameleon64 wieder ab und gibt es mir

-
REU wäre nichtmal nötig, auf dem chameleon kann man ja auch einfach dessen MMU benutzen, was im ergebnis sehr viel besser performed.
Was die Software betrifft, geht das, klar. Aber wie wird das Spiel dann geladen? Eine 1581 anschließen, ist keine echte Alternative, da man das Chameleon ja nutzen will, um von den Disketten weg zu kommen. Und im .d64-Format will das sicher auch keiner haben. DA bietet sich ein REU-Image doch an, da die Möglichkeit bereits im Chameleon integriert ist.
Ein nativer SD-Karten-Zugriff der auf CBM-DOS-Befehle hört wäre eine denkbare Alternative, aber der steht wohl nicht auf der Todo-List oder?mmh naja. die kann man nur leider nicht so leicht abspielen wie die bisher verwendeten pwm samples... ich denke nicht dass das sinnvoll machbar ist.
Man wird doch wohl noch einen hochauflösenden Mixdown oder Multitracks aufbewahrt haben, oder? Damit wäre doch ein Remaster in jedes beliebige Format möglich, unter Anderem 8-Bit.
Welche anderen Games haben den um 1990 rum Digi Soundtrack gehabt.
Ganze Soundtracks wohl nicht, aber Spiele, die 4-Bit-Samples über Lautstärkeregister in der Musik verwendeten, gab es schon einige. Vor allem sogar ältere Titel, da der 6581 besser dafür geeignet ist.
wohl eher keins, was in der hauptsache aber daran liegt das die samples so viel speicher fressen, und man ohne turbokarte dann halt auch nur zwischen samples abspielen oder spielen wählen könnte =P
Tetris ist der beste Gegenbeweiß, denn da spielen auch Lautstärkeregistersamples während des Spiels. Gut, das Spiel lebt jetzt nicht von Animationen, aber hier soll es ja darum gehen, was mit Turbo möglich wird. Also 3 mal 8-Bit-Samples sollte mit Turbo doch möglich sein, oder?
Wie präzise ist der Turbo eigentlich? Also die zeitliche Toleranz, wenn man jetzt z.B. alle 64 Microsekunden ein paar SID-Register schreiben möchte. Die Bad-Lines bleiben im Falle von IO-Zugriffen auf VIC und SID bestehen, oder?
-
Aber wie wird das Spiel dann geladen? Eine 1581 anschließen, ist keine echte Alternative, da man das Chameleon ja nutzen will, um von den Disketten weg zu kommen. Und im .d64-Format will das sicher auch keiner haben. DA bietet sich ein REU-Image doch an, da die Möglichkeit bereits im Chameleon integriert ist.
Ein REU-Image zu laden bedeutet nicht, dass Du es nur mit der REU auch benutzen kannst. Das wäre nur das Werkzeug, um den Chameleon-Speicher zu beschreiben. Die MMU kann dann die Bereiche des Speichers einblenden, die man gerade braucht, ohne dass die REU mit ihren lahmen 1MByte/Sekunde etwas tun müsste.Man könnte sich MMU-Configs für die Musikroutine, für die Sample-Mix Routine und für die game-Routine bauen, so dass man in jedem context-switch maximale Speichermenge verfügbar hat, ohne dass man kopieren müsste.
Ein nativer SD-Karten-Zugriff der auf CBM-DOS-Befehle hört wäre eine denkbare Alternative, aber der steht wohl nicht auf der Todo-List oder?
Das ist für kaum ein game eine Alternative, weil es AFAIK keine Software gibt, die die 32MB des Chameleon sprengen. Lieber kompletten preload, und wenn die 16M+60k nicht ausreichen, dann nimmt man halt noch ein Georam-Image mit dazu. Erst wenn das gesprengt ist, unterhalten wir uns über eine Änderung des Menüsystems (Stichwort "keine neuen Features").Wie präzise ist der Turbo eigentlich? Also die zeitliche Toleranz, wenn man jetzt z.B. alle 64 Microsekunden ein paar SID-Register schreiben möchte. Die Bad-Lines bleiben im Falle von IO-Zugriffen auf VIC und SID bestehen, oder?
Richtig, Badlines bleiben bestehen, denn da laufen die Daten auf dem gleichen Bus, der auch vom SID verwendet wird. Die Präzision des NMI-Timings ist aber schon wieder ein gutes Stück besser, denn der ganze IRQ-Service (Stack beschreiben, Vektor holen) passiert im schnellen Chameleon-Speicher - durchschnittlich in einem C64-Takt. Wenn Du jetzt den NMI so legst, dass er am Ende einer Badline mit Zeilenfrequenz ausgelöst wird (63 Zyklen ist hoffentlich nah genug an Deinen gewünschten 64 Mikrosekunden dran), sollte das Abspielen eines Sample im NMI recht bequem gehen. Ich denke da an die allerersten NMI-Sample Routinen wie sie in "To be on top" oder "Bad Cat" verwendet wurden.Jens
-
Was die Software betrifft, geht das, klar. Aber wie wird das Spiel dann geladen? Eine 1581 anschließen, ist keine echte Alternative, da man das Chameleon ja nutzen will, um von den Disketten weg zu kommen. Und im .d64-Format will das sicher auch keiner haben.
Man könnte D81 Images Support in den nächsten Updates vom Chameleon 64 einpflegen. Noch besser wäre sogar eine frei
wählbare Leerpartition wie die Native Partition von den CMD Geräten. Dann gibts auch in Zukunft keine Platzprobleme mehr.
-
Man könnte D81 Images Support in den nächsten Updates vom Chameleon 64 einpflegen.
Hast Du Dir mal überlegt, was das auf Hardwareseite bedeuten würde? Ein weiteres 6502-Subsystem mit einem bisher nicht in VHDL verfügbaren MFM-Chip und einer nicht näher definierten (weil unterschiedlich ausgeführten) 3,5" Mechanik müsste komplett emuliert werden. Viel besser könnte man den Begriff "feature creeping" eigentlich nicht beispielhaft erklären
Noch besser wäre sogar eine frei wählbare Leerpartition wie die Native Partition von den CMD Geräten. Dann gibts auch in Zukunft keine Platzprobleme mehr.

Und hier wieder das Gleiche: Du willst also, dass eine IEC-Hardware sich wie ein CMD-Gerät verhält, ergo läuft das wieder auf ein 6502-Subsystem hinaus, das Zugriff auf die SD-Karte hat. Machbar ist das alles, aber wer bezahlt's? Und.. wer nimmt sich die Zeit und testet den riesigen Rattenschwanz der da dran hängt? Schließlich reden wir über Zugriff auf *eine* SD-Karte von *zwei* Seiten: Menüsystem (läuft auf dem C64) und die "externe SD-Floppy" müssten sich darüber einig sein, wer denn jetzt schreibt, und sie müssten auch einen "Querkanal" haben, über den die schreibende Seite die andere Seite darüber informiert, dass geschrieben wurde.Noch irgendwelche Ideen, die mal eben so die Komplexität verdreifachen ;-)?
Jens
-
Bringt erst mal CL13 zum Laufen. Solange Bugs drin sind, halte ich einen Feature-Freeze für sinnvoll.
-
Und hier wieder das Gleiche: Du willst also, dass eine IEC-Hardware sich wie ein CMD-Gerät verhält, ergo läuft das wieder auf ein 6502-Subsystem hinaus, das Zugriff auf die SD-Karte hat. Machbar ist das alles, aber wer bezahlt's?
Über was für Kosten sprechen wir hier denn genau ?
Und.. wer nimmt sich die Zeit und testet den riesigen Rattenschwanz der da dran hängt?
Das bekäme ich wohl noch so hin

-
Allerdings nur wenn man auf genaue Emulation einer 1581 viel Wert legt.
Man kann das auch so dirty machen wie es die SD2IEC Firmware macht. Das reicht für 95% aller D81 Images. Halt als reines Containerformat verwenden ohne genaue Geräteemulation. Das funktioniert halt nichts anderes ausser DOS Commands und Burstmode/Jiffy. Das entspricht auch etwas gefühlt die Kompatiblität in freier Wildbahn. -
Allerdings nur wenn man auf genaue Emulation einer 1581 viel Wert legt.
Man kann das auch so dirty machen wie es die SD2IEC Firmware macht. Das reicht für 95% aller D81 Images.Genau. Das SD2IEC zeigt das ja sehr schön.
-
Bringt erst mal CL13 zum Laufen. Solange Bugs drin sind, halte ich einen Feature-Freeze für sinnvoll.
ja - das ist auch mein reden - und NUR daran arbeiten wir auch bis zum ende der beta phase. also nicht speziell an CL13 :o), sondern am fixen der noch vorhandenen fehler in bereits bestehenden features. zusätzliches wird es nur dann geben wenn es mehr oder weniger trivial ist.Über was für Kosten sprechen wir hier denn genau ?
eine gute faustregel ist "um irgendetwas nicht triviales zu entwickeln braucht man mindestens 6 monate". mal (in dem fall) zwei personen. plus das was diese zeit lagerhaltung und weiteres verschieben des finalen release indirekt kostet (zinsen usw usf). ich täte einen betrag im mitleren 5 stelligen bereich ansetzen - wobei das komplett geraten ist, denn die einzige zahl die ich kenne ist mein eigenes gehalt
Allerdings nur wenn man auf genaue Emulation einer 1581 viel Wert legt.
Man kann das auch so dirty machen wie es die SD2IEC Firmware macht. Das reicht für 95% aller D81 Images. Halt als reines Containerformat verwenden ohne genaue Geräteemulation. Das funktioniert halt nichts anderes ausser DOS Commands und Burstmode/Jiffy.
das ändert nur leider kaum etwas an der komplexizität - in dem fall bräuchte man keinen MFM controller, müsste aber dafür einen relativ grossen haufen mehr oder weniger komplizierter software schreiben.
davon ab steht das durchaus auf unserer todo liste - aber unter dingen die irgendwann vielleicht mal kommen - NACH dem ende der betaphase. -
davon ab steht das durchaus auf unserer todo liste
Ist die Todo-Liste öffentlich? Würde mich mal interessieren, was da sonst noch so drauf steht.
Aber ich bin natürlich auch dafür, daß erstmal Bug-Fixes anstehen. -
Ist die Todo-Liste öffentlich? Würde mich mal interessieren, was da sonst noch so drauf steht.
Aber ich bin natürlich auch dafür, daß erstmal Bug-Fixes anstehen.Könnte man dafür nicht einen Bitte melde dich an, um diesen Link zu sehen. eröffnen? Wenn genug Geld zusammen kommt, dann wird das Feature eingebaut, wenn nicht dann eben nicht. Hat natürlich den Vorteil, dass die Entwickler nicht in Vorleistung treten müssen, mit dem Risiko, dass nur 2-5 Forum64 User das ganze wirklich haben wollen.
-
Kickstarter ist ausschliesslich fuer Amerikaner.
-
startnext.de dann eventuell ?
-
Kickstarter war ja auch nur ein Beispiel, weil ich da zweimal erfolgreich ein Projekt mitfinanziert habe. Jede andere Crowdfunding-Plattform geht natürlich auch

-
Ist die Todo-Liste öffentlich? Würde mich mal interessieren, was da sonst noch so drauf steht.
nein, schon darum weil wir bei niemandem falsche hoffnungen auf features wecken wollen die es vielleicht niemals geben wird. der interessante teil der liste, sprich das was auf jeden fall noch passieren wird, ist dem wiki zu entnehmen
-
sprich das was auf jeden fall noch passieren wird, ist dem wiki zu entnehmen

Wo denn da genau? Ich sehe vor allem, was bereits drin ist, und welche Fehler noch auszubessern sind. Letzteres ist natürlich auch eine Todo-List, aber hier ging es ja um zusätzliche Features, die evtl. nach der Beta-Phase implementiert werden könnten.
Besonders interessiert mich:
Ist die PAL-Emulation noch während der Beta-Phase geplant?
In welcher Phase kann man mit einer Parallelkabel+Floppy-RAM-Erweiterung zwecks Dolphin-DOS rechnen? Sofern man nicht vor hat, externe Jiffy-DOS-Geräte zu betreiben, wäre das wohl deutlich überlegen.Ich hätte da noch eine andere interessante, eher hypothetische Frage zur 1541-Emulation: Wenn das mit G64 mal perfekt läuft, könnte man da einfach die Kapazität erhöhen, indem man die Half-Tracks gesondert beschreibt? Oder würde es das Zerstören der benachbarten Spuren mit emulieren? Was ist, wenn man die Modulation ändert, um mehr Daten schreiben zu können, als es auf echten Medien möglich ist? Würde die Emulation dann auch Fehler produzieren? Und wenn auch die inneren Tracks mit der höchsten Dichte beschrieben werden? Ich meine jetzt damit keine Änderungen am Core, sondern diese Trickserei nur mit einer modifizierten 1541-Firmware zu erreichen?
Würden eigentlich 80-Spuren auf einer echten 1541 nutzbar sein, wenn man einen 80-Spur-Kopf einbaut?Jede andere Crowdfunding-Plattform geht natürlich auch

Das wäre ja mal interessant, obwohl ich mir nicht vorstellen kann, daß der Bekanntheitsgrad sowie Interesse für so eine Hardware wie das Chameleon groß genug ist, um da genug Leute zum Finanzieren zu motivieren. Man müßte dann ja auch für jedes geforderte Feature ein eigenes Projekt starten.
Mir persönlich wäre ein PC-Core mit Soundblaster und VGA wesentlich mehr Wert als eine 1581. Da wäre ich bei einem Crowdfunding-Core eher zu begeistern.
Die 1581 ist zwar ein klasse Laufwerk, welches ich selbst besitze, aber es gibt wohl kaum Software, die entsprechende Originalhardware voraussetzt. Da wäre ein CBM-DOS-kompatibler Direktzugriff auf die SD-Karte bestimmt nützlicher, da fast alle Programme, die von großen Speichermedien profitieren, praktisch auch CBM-DOS-kompatibel sind. -
Mir persönlich wäre ein PC-Core mit Soundblaster und VGA wesentlich mehr Wert als eine 1581. Da wäre ich bei einem Crowdfunding-Core eher zu begeistern.
Lol. Bitte nicht.
-