Floppygeräusche? Geil! Das war für mich das geilste Feature im UAE. *g*
Wird das dann auch schön in den SoftSID rein gemischt?
Oder muss ich einem alten PC dafür den PC-Speaker klauen?
Es gibt 104 Antworten in diesem Thema, welches 17.600 mal aufgerufen wurde. Der letzte Beitrag (
Floppygeräusche? Geil! Das war für mich das geilste Feature im UAE. *g*
Wird das dann auch schön in den SoftSID rein gemischt?
Oder muss ich einem alten PC dafür den PC-Speaker klauen?
Ein Problem von Beschleunigerkarten ist, dass bei Softwarespeedern das Timing zwischen C64 und 1541 so ausgetüftelt ist, dass der C64 exakt mit 1MHz laufen muss (schon der Unterschied zwischen einem PAL- und einem NTSC-C64 kann zu Problemen führen). Wenn jetzt die Karte mit mehr als 1MHz läuft, dann werden viele Programme mit eigenen Laderoutinen nicht gehen, es sei denn man patcht sie. Fantastisch wäre dies: Die CIA ist alle 32 Bytes gespiegelt, d.h ein LDA$DD00 ergibt den gleichen Registerzugriff wie ein LDA$DD20, LDA$DD40, ... LDA$DDE0. Wenn man jetzt bei jedem Zugriff eines Programms auf $DD00 (nur $DD00 ohne Spiegelungen) die Beschleunigerkarte für ca. 1000µs auf die ursprünglichen 1MHz zurücksetzen würde (und danach wieder auf den schnelleren Takt), dann sollten auch die Softwarespeeder funktionieren. Wenn man ein Programm schreiben möchte, bei dem ein Zugriff auf dieses Register ohne Reduzierung des Takts erfolgen soll, dann würde es einfach auf $DD20 zugreifen, wobei dann eben keine 1MHz-Takt-Reduzierung erfolgen würde. Das ist aber nur so eine Idee. Ich denke, das wäre recht aufwändig und würde viel vom FPGA belegen.
ZitatDas ist aber nur so eine Idee. Ich denke, das wäre recht aufwändig und würde viel vom FPGA belegen.
ich würde ganz im gegenteil denken das das mit einer handvoll gatter zu erschlagen ist, bischen auskodierung und ein zähler ![]()
allerdings könnte man alternativ auch einfach die emulierte floppy im gleichen verhältnis schneller laufen lassen, dann klappen auch die loader ![]()
Nur Beschleuniger ohne vernünftigen Protokoll sind timing abhängig. Also serielle Speeder die alle Leitungen für Daten benutzen.
Ich würde begrüßen wenn das FPGA auch ein parallel Kabel (SpeedDos) unterstützen würde. Dan würden alle technisch vernünftigen Speeder und parallel Tools laufen.
Ideal wäre natürlich auch noch 8KB SRAM für die 1541 Emulation zu spendieren! ![]()
allerdings könnte man alternativ auch einfach die emulierte floppy im gleichen verhältnis schneller laufen lassen, dann klappen auch die loader
Das ist natürlich auch eine gute Idee!
ZitatNur Beschleuniger ohne vernünftigen Protokoll sind timing abhängig. Also serielle Speeder die alle Leitungen für Daten benutzen.
äääh... also ersmal hat das eine mit dem andren nichts zu tun, und ausserdem ist das auch kein argument, man will schliesslich das möglichst viel existierende software funktioniert ![]()
Nur Beschleuniger ohne vernünftigen Protokoll sind timing abhängig. Also serielle Speeder die alle Leitungen für Daten benutzen.
Dann sind nur unvernünftige Protokolle auch schnell. Und mal abgesehen davon: Selbst das lahme original Commodore Protokoll ist Timingabhängig, obwohl es CLK für CLK und DATA für DATA verwendet.
Dann sind nur unvernünftige Protokolle auch schnell.
Das gilt sicherlich bei rein seriellem Commodore IEC bus ...
Selbst das lahme original Commodore Protokoll ist Timingabhängig, obwohl es CLK für CLK und DATA für DATA verwendet.
Weil es schlecht gemacht ist.
OpenCBM verwendet zwei serielle Protokolle (S1 und S2) und die sind sauber programmiert, da wartet jeweils jeder Partner auf den anderen. Deshalb kann da auch der Schirm an bleiben und es würde auch ein IRQ keine Probleme machen (obwohl trotzdem SEI verwendet wird).
Richtig vernünftig UND schnell ist sowieso nur seriell per Hardware (zb. burst mode der 1571/1581) oder parallel (Speed-Dos, Dolphin, Prologic, Prof-Dos, IEEE-488). Alles andere ist Homecomputer Billiglösung ...
wann kann man den so ungefähr mit dem modul rechnen.. weiss den niemand was genaues?
ZitatAlles andere ist Homecomputer Billiglösung ...
eine homecomputer billiglösung? und das beim C64? wer denkt sich denn sowas aus? ![]()
Hab ich mir auch gerad gedacht. (...)
doch, doch. aber bitte mit kopfrattern und floppymusik ; )
OpenCBM verwendet zwei serielle Protokolle (S1 und S2) und die sind sauber programmiert, da wartet jeweils jeder Partner auf den anderen. Deshalb kann da auch der Schirm an bleiben und es würde auch ein IRQ keine Probleme machen (obwohl trotzdem SEI verwendet wird).
Was soll an doppeltem Handshaking "sauberer programiert" sein als bei synchroner Übertragung oder einfachem Handshaking? Das sind einfach nur andere Übertragungsmethoden, und die synchrone Variante ist nunmal deutlich die schnellste.
ZitatRichtig vernünftig UND schnell ist sowieso nur seriell per Hardware (zb. burst mode der 1571/1581) oder parallel (Speed-Dos, Dolphin, Prologic, Prof-Dos, IEEE-488). Alles andere ist Homecomputer Billiglösung ...
Verglichen mit einem brauchbaren Softwarefastloader ist der Burst-Modus eine lahme Krücke. Und was der parallel-Addon Kram soll, obwohl der C64 auch über den IEC-Bus schnelle Geschwindigkeiten kann, hab ich noch nie verstanden.
Verglichen mit einem brauchbaren Softwarefastloader ist der Burst-Modus eine lahme Krücke.
Der Burstmode überträgt ein Byte in 2*8 µs, kein serielle Speeder ist so schnell wie der Burst. In 16 µs macht eine 6510 mit 1MHz Takt nämlich fast gar nix. Zudem braucht die CPU dafür keinen Finger zu rühren (ein STA).
Ist aber auch gar nicht notwendig. Die wahre Bremse ist ja die GCR Dekodierung und die geringe Umdrehungsgeschwindikeit. Bei 5 Umdrehungen pro Sekunde und maximal 21 Blöcken zu 254 Byte kommt nur alle 37µs ein Byte vom Controller. Wenn man alle 350 GCR Bytes übeträgt für g64 Images bracuht man "NUR" alle 27µs ein Byte übertragen.
Der Burstmode kann da immer mithalten. Das parallel Kabel auch! Die seriellen Routinen der schnellsten Speeder beißen sich da schon die Zähne aus ...
Der Burstmode überträgt ein Byte in 2*8 µs, kein serielle Speeder ist so schnell wie der Burst. In 16 µs macht eine 6510 mit 1MHz Takt nämlich fast gar nix. Zudem braucht die CPU dafür keinen Finger zu rühren (ein STA).
Die CPU muss in einen IRQ springen, von dort das Byte vom Schieberegister abholen, in den Speicher schreiben, den IRQ bestätigen und dann zurückspringen. Und die 16 µs sind sehr theoretisch. Die Jungs bei Commodore haben nicht ohne Grund wesentlich längere Taktzeiten gewählt.
ZitatDer Burstmode kann da immer mithalten. Das parallel Kabel auch! Die seriellen Routinen der schnellsten Speeder beißen sich da schon die Zähne aus ...
Ob der Kram mithalten kann oder nicht ist ziemlich egal. Es ist Hardwareoverkill für so gut wie keinen Vorteil. Für den Burstmodus hat man in jede 1571 noch eine extra CIA eingebaut. Wofür? Für nichts, denn jeder 2-Bit Fastloader ist schneller.
Floppygeräusche sind nun wirklich das Letzte was wir da brauchen.
Also ich hatte beim DAC nicht an Floppygeräusche gedacht. Vermutlich auch unseen nicht. Ich hatte das eher auf das "Standalone" bezogen. Aber das ist so sehr gemutmaßt, dass ich lieber nichts mehr dazu schreibe.
Wofür? Für nichts, denn jeder 2-Bit Fastloader ist schneller.
Ja, ich liebe diese Fastloader. Jedes zweite Demo hat einen anderen und hübsch inkompatibel mit meiner 1571, 1581, FD, RL und HD sind die meisten auch (ein großes Lob an die, die zeigen, dass man es auch besser machen kann). Und wenns (nur) mit der 1571 klappt, muss ich oft genug vorher die gesammte andere Peripherie vom IEC-Bus abklemmen. Bäh! Sowas verdirbt mir den Spaß. Aber so ist das eben, dem einen gefällts, dem anderen nicht.
Gruß WTE
Ja, ich liebe diese Fastloader. Jedes zweite Demo hat einen anderen und hübsch inkompatibel mit meiner 1571, 1581, FD, RL und HD sind die meisten auch (ein großes Lob an die, die zeigen, dass man es auch besser machen kann). Und wenns (nur) mit der 1571 klappt, muss ich oft genug vorher die gesammte andere Peripherie vom IEC-Bus abklemmen. Bäh! Sowas verdirbt mir den Spaß. Aber so ist das eben, dem einen gefällts, dem anderen nicht.
Was hat das ganze mit Demos zu tun? Die Democoder haben überhaupt keine Wahl. Für Trackloading braucht man nunmal eigene Fastloader, denn das unterstützt KEINER der Fastloader in den Erweiterungen und Commodore DOS sowieso nicht.
Und dass das ein 2-Bit ATN Fastloader ist (man beachte das ATN, was ich oben nicht erwähnt habe weil ich es oben nicht meinte), können sie auch nichts. Das ist nämlich die einzige Möglichkeit, einen 2-Bit Loader mit Handshaking zu machen. Ohne Handshaking wäre Trackloading unmöglich, ohne 2-Bit auf einmal wäre der Loader viel zu lahm. Die Trackloader sind eigentlich auch mit 2-Bit ATN viel zu langsam, was sich an den doch recht langsamen Fluss der Demos zeigt.
2-Bit OHNE ATN Loader die ich meinte: Action Replay, Final Cartridge 3, Warpcopy etc. Und das sind 2 Bit loader OHNE ATN, also kein problem wenn mehr als 1 Gerät am IEC-Bus hängt.
was genau ist an "standalone" unverständlich ?
Einzelheiten wäre mal nett. Standalone ist recht schwammig.
Von mir mal ein Sprung zurück zu einer anderen Thematik hier:
Du erwähntest hier einen RTC-Chip. Was mich dabei interessieren würde: Falls der verbaut wird, ist der dann auch vom C64 abrufbar? Also könnte man dann z.B. einen Treiber für GEOS programmieren, der Datum und Uhrzeit auslesen kann? Nach all den "Wunderdingen", die Chameleon kann/können soll würde mich das nun noch zusätzlich faszinieren.
Abgesehen davon - in Anbetracht dessen, wie nach meinem Eindruck immer mal wieder ganz nebenbei neue Features genannt werden - frage ich mich, was da evtl. noch verheimlicht wird... ![]()
@sauhund: Hast Du (oder jemand anderes) vielleicht schon eine Demo in Arbeit, die die Möglichkeiten von Chameleon vor Augen führt?
Zitat@sauhund: Hast Du (oder jemand anderes) vielleicht schon eine Demo in Arbeit, die die Möglichkeiten von Chameleon vor Augen führt?
noch nicht... ![]()
Diese Woche hat's ein ewiges Auf und Ab bei der Bauteilebeschaffung gegeben. Zunächst hat Samsung die 200MHz-Rams letzte Woche bestätigt, dann am Montag dieser Woche gleich die Absage: "ist kein Standard-Typ, machen wir nicht". Ausweichen auf Hynix: Steht im Datenblatt, zunächst vom Distributor fernmündlich bestätigt, dann aber abgesagt, nachdem ich eine Bestellung platziert habe (immerhin haben die vorher keine Auftragsbestätigung geschickt).
Also rückwärts paddeln, schließlich läuft der Prototyp mit 133MHz ordentlich, alles was drüber ist, ist Bonus. Die Bestellung bei Samsung auf 166MHz-Typen geändert, zwei Tage später wieder der Anruf vom Distri: Nicht zu bekommen. Bei Hynix das Gleiche - keine Chance auf mehr als 133MHz.
Ich bin jetzt bei einer kleinen Taiwan-Bude namens Etron gelandet - die haben die 166MHz-Typen nicht nur im Datenblatt, sondern bauen die auch wirklich. Muster zur Freigabe sind unterwegs, Lieferzeit für die Serie ist "wenige Wochen", was auf Lagerware hindeutet, die auf dem preiswertesten Weg nach Europa gebracht wird.
Ein ähnliches heiß-Kalt-Spiel gab's bei dem Devkit zu einem Bauteil, das ich hier nicht näher bezeichnen will. Der Hersteller hat den Liefertermin 26.6.2009 angegeben, was ich jetzt nicht wirklich toll fand, wo ich gleich in der ersten Januarwoche danach gefragt hatte. Alarmiert von der Knappheit dieser Teile habe ich durch die Weltgeschichte telefoniert, und noch son Devkit aufgetrieben. Nachdem meine Bank tatsächlich nach mehrtägigen 'Rumhampeln die US-Dollar Überweisung vorgenommen hat, geht das Teil in der kommenden Woche auf die Reise. Für die Entwicklung der neuen Features ist jetzt fast alles in trockenen Tüchern - lediglich die RTC-Frage ist noch nicht geklärt.
Ein Geos-Treiber für die RTC ist ganz sicher kein Problem. Die Hardware wird komplett dokumentiert, aber wir können mit dem Teil ganz netzte Tricks machen, die beispielsweise das Überschreiben der TOD-Register in der CIA verhindern. Das Startmenü von Chameleon würde die RTC auslesen, die CIA entsprechend initialisieren, TOD setzen und dann die entsprechenden Registger vor Überschreiben schützen. In der Praxis würde das bedeuten, dass die TI$ Variable einfach immer richtig geht. Wenn Geos die Uhrzeit auch aus der CIA nimmt (alles Andere wäre Blödsinn), würde man immerhin für die Uhrzeit keinen Treiber brauchen. In Sachen Datum wird's aber wohl nicht ohne Extra-Software gehen, die wir NICHT schreiben werden. Um Geos-Treiber darf sich jeder Andere kümmern, aber mehr als Hardware-Dokumentation wird dafür von meiner Seite nicht kommen.
Jens