Hallo Besucher, der Thread wurde 70k mal aufgerufen und enthält 484 Antworten

letzter Beitrag von Rob64 am

[Kerberos] C64 MIDI Interface mit Flash und PC-Dateitransfermöglichkeit

    ich glaube, kein ernst zu nehmender musiker hatte oder wollte jemals am c64 midi sequencing betreiben, da gab es zu jedem zeitpunkt in der geschichte bessere geräte. in die andere richtung, midi noten reinschicken und abspielen, ja das wollen und machen viele. warum nicht ein midi file abspielen und in cynthcart die einzelnen spuren ausperformen und in der daw aufnehmen und abmischen? ergebnis sicher spekatulärer und auch lustiger in der produktion als ein stumpfes abspielen, und es wäre sogar abwechslungsreicher als die üblichen "chiptune" youtube versionen bekannter songs.

    Zitat von manne_sahne

    Gibt es einen Fastloader der vom EF1 des Kerberos gestartet werden kann, bzw. gibt es überhaupt einen Schnellader, der auf dem EF1 funktioniert?
    Das Multi Easy scheint nicht zu funktionieren (ist vermutlich nur für EF3).


    Was genau läuft dort nicht? Habe es eben mal geladen und geflasht und kann z.B. "EPYX FAST LOAD" starten, was dann ein LOAD von einer 1541 sehr stark beschleunigt.

    Zitat von gartenzwerg

    Wenn das MIDI-Interface geschlossen wird, dann sendet Windows haufenweise Note-Off Messages, wohl um zu vermeiden, daß Töne hängenbleiben. Eigentlich sollte daß das Menü nicht interessieren, da per Checksumme auf gültige Nachrichten getestet wird, aber könnte schon sein, daß es dann abstürzt. Habe mal einen Bug-Report dazu angelegt: https://github.com/FrankBuss/kerberos/issues/11 Habe allerdings aktuell nicht viel Zeit, könnte was dauern bis ich dazu komme mir das anzuschauen. Ist aber auch kein kritischer Bug, denke ich.

    Nur um zu präzisieren, das Menü ist weniger das Problem aber mehr über Transfer gestartete Programme.
    Ich kann also nicht mal eben ein Programm vom PC starten und dann den PC ausschalten. In der Tat sendet Windows beim schließen massenhaft Midi Daten.

    Mir ist kein Verfahren bekannt, wie man Windows davon abbringen kann die Note-Off Daten zu senden. Eine mögliche Low-Tech Lösung wäre, das MIDI-Kabel abzuziehen, bevor man das Programm am PC schließt. Ich habe das Cartridge so gebaut mit ESD Schutzmaßnahmen per Dioden, Kondensatoren und Widerständen wie vom MIDI-Standard vorgesehen, daß ein Abziehen des Kabels ohne Beschädigung des Interfaces oder des C64 während des Betriebs möglich ist.

    Sieht gut aus. Habe es jetzt nicht getestet, aber anhand der angegebenen Adressen sollte es mit der DATEL Emulation funktionieren. Compilieren braucht man da nichts, sollte auch so schnell genug sein, da es eine Assembler-Erweiterung für Basic ist.

    Zitat von Maverick188

    Finde ich auch gut - wo kann man das den herbekommen"


    Äh hier:

    Zitat

    erschienen in: GO64! - Das Magazin für wahre Computerfreaks, Ausgabe 4/98

    Ich vermute mal, weil die GO64! Disks als CD-ROM (bei Vesalia sicher bis 2012) verkauft wurde, deshalb nicht so einfach in freier Wildbahn zu finden.

    Eine Google Suche nach d64 "midi basic" findet das Image (zweiter Link). Link posten sollte man aber nicht, vielleicht zuerst beim CSW-Verlag nachfragen, ob die was dagegen haben, wenn man die Disk-Images veröffentlicht. In einem anderen Thread wurde Ace explizit untersagt, eingescannte PDFs zu veröffentlichen. Aber vielleicht hat sich die Meinung des Verlages mittlerweile auch geändert, da auch bereits einige Ausgaben von GO64! als PDF-Scans auf archive.org zu finden sind.

    dachte mir schon sowas deswegen hatte ich auch keinen link gepostet.



    geschwindigkeit in basic - entgegen meiner behauptung das niemand den c64 als ernsthaften sequenzer nutzen will -- die kompakte c64 plattform (alles da in einem gehäuse +midi interface, [fast] kein löten mehr) -- hat meine meinung etwas nachhaltig verändert:



    ich würde mich gerne an sowas wie einem x0xbox drummachine lauflichtsequencer versuchen, mit der möglichkeit das an eine externe clock zu slaven.


    denke bei 24ppq wirds dann schon knapp wenn man von einem musikalischen bereich bis ~200 bpm ausgeht, zumal man midi 3 clocks zeit hätte nebenbei was zu rechnen bei 32tel noten - musikalisch realisitisch sind 1/16 noten und 6 zyklen, was bei 200bpm ca. einem kompletten 50Hz screenupdate entspricht.


    der bufferbereich im midibasic macht sicher sinn, vielleicht kann ich ja herausfinden welche werte geladen müssen und wo die einsprungadressen sind, so das ich direkt in asm stricken kann und den basic teil weglasse. crossdevelopment ist nix für mich, besser direkt am monitor.


    speicher ist auch noch so ein thema, um vernünfitg arbeiten zu können kommt man kaum unter 40k speicherbedarf für die patterns (überschlagsrechnung 160 patterns, 10 tracks per pattern), evtl. werden auch sachen wie CC werte per sequencer steuerbar gemacht oder es gibt eine preset-page wo man gewisse einstellungen für drumsynths rausdumpen kann bzw per paddle anpassen - wenn möglich sogar im play modus.


    es wäre auch möglich melodien zu sequenzen bzw. mehrere tonhöhen pro track zu haben, es scheitert wahrscheinlich nur am 50k limit. - toll wäre es wenn sich das programm per tastendruck neu speichert bzw. den datenbereich neu abspeichert, in einer form das es nur eine einzelne datei ist die man einfach transferieren und neu reinladen kann, evtl. kann man dafür die cartridge disks nutzen.


    ziel wäre es das ganze ohne bildschirm intuitiv bedienbar zu haben, evtl. am userport oder sogar joyport 16 leds multiplexen und einen k.i.t.t. ledstreifen über die oberste tastatur-reihe kleben. ja, das sind genau 16 tasten. der userport könnte aber mehrere triggerausgänge für analoge drum module bieten. soweit mal die ideen, vielleicht ist es in drei jahren schon realität.

    Zitat von oneBitman

    dachte mir schon sowas deswegen hatte ich auch keinen link gepostet.
    denke bei 24ppq wirds dann schon knapp wenn man von einem musikalischen bereich bis ~200 bpm ausgeht, zumal man midi 3 clocks zeit hätte nebenbei was zu rechnen bei 32tel noten - musikalisch realisitisch sind 1/16 noten und 6 zyklen, was bei 200bpm ca. einem kompletten 50Hz screenupdate entspricht.


    Das stimmt, Basic ist nicht unbeding allzu schnell. Du könntest aber der Einfachheit halber alles was GUI usw. betrifft, in Basic schreiben, und nur eine kurze Assembler-Routine für MIDI Record und Playback.


    Zitat von oneBitman


    es wäre auch möglich melodien zu sequenzen bzw. mehrere tonhöhen pro track zu haben, es scheitert wahrscheinlich nur am 50k limit. - toll wäre es wenn sich das programm per tastendruck neu speichert bzw. den datenbereich neu abspeichert, in einer form das es nur eine einzelne datei ist die man einfach transferieren und neu reinladen kann, evtl. kann man dafür die cartridge disks nutzen.


    Also mit Kerberos hast du kein 50k Limit. Es hat 128 kB externes RAM, das du nach dem Start deiner Anwendung beliebig verwenden kannst. Einfach die gewünschte Page mit den Registern RAM_ADDRESS_EXTENSION and RAM_ADDRESS_EXTENSION2 einblenden (siehe hier für die Registeradressen) und dann 256 Bytes ab $df00 lesen und schreiben.

    ja an so eine hybrid lösung hatte ich auch schon gedacht. denke es wird auch nötig sein das der acia einen interrupt auslöst wenn das register ausgelesen werden soll (clock), sonst wird das alles so dahinhumpeln. dazwischen drin könnten ja tastaturabfragen und bildschirmausgabe passieren. ich weiss auch gar nicht ob ein buffer sinn macht, denn es sollte ja möglichst alles schnell und ohne verzögerung abgearbeitet werden, am eingang sollte nur clock und start/continue/stop reinkommen.


    über die 128k habe ich auch schon gelesen, aber ich komme mit meinem gefährlichen halbwissen da nicht weiter. am einfachsten (für mein verständnis) ist es wahrscheinlich das ganze auf cartridge disk laufen zu lassen, über autostart mit einem prg, dann von disk die daten in die 128k zu schaufeln. bei einer gewissen tastenkombination wird der datensatz dann einfach neu auf cartridge disk geschrieben, bzw. vielleicht gibts einen weg immer alles aktuell zu haben so das man jederzeit abschalten kann und es beim einschalten wieder da ist. die 128k sind aber sicher eine super möglichkeit und man kann rumfuhrwerken ohne sich viele gedanken über die memory map zu machen.


    crossdevelopment (google groups), ich habe mir relaunch 64 am mac angeschaut, das ist sicher sehr komfortabel, wie ich das ganze soweit kriege das es dann per tastendruck ins kerberos injiziert wird und läuft muss ich mir aber noch anschauen. brauche dann wohl einen midi merger um "umsteckfrei" daten reinzuschicken und meinen test midiclock. es wäre schon cool immer am "real thing" tesen zu können, auch falls ich das mit dem 16 led lauflicht hinkriege, das geht so im vice nicht wirklich.


    mal schauen...

    Ohne Interrupt wird es schwierig. Auch wenn MIDI clock/start/continue/stop immer nur ein Byte sind, kannst du Pech haben, und ein Stop kommt direkt nach einem Clock. Mal ausrechnen: 31250 kbit/s ist MIDI schnell, also 3906 Bytes pro Sekunde. Sind bei 1 MHz Takt gerade mal 256 CPU Takte pro Byte. In der Zeit musst du erkannt haben, daß ein Byte ankam (also wenn du dauernd pollen wolltest) und das Byte auch schon gelesen haben, damit es nicht vom nächsten Byte überschrieben wird. In Basic ist das gerade mal das "P" von einem PEEK(x) :) aber auch in Assembler würde sowas sportlich werden. Also besser Interrupts verwenden. Könntest es dann in einem FIFO speichern, dann hätte Basic vielleicht wieder eine Chance es auszulesen. Aber das bringt wieder Verzögerung, vielleicht doch besser die ganze Sende- und Empfangslogik in Assembler programmieren.


    Mit meiner MIDI-Library und cc65 geht sowas übrigens ziemlich einfach. Schau mal das Synthesizer Beispiel an. Cross Compiler geht per Kommandozeile mit make, dann nochmal den Upload Button in der Kerberos App klicken. Das kompilierte C ist bedeutend schneller auf dem C64, als Basic.


    Ein MIDI-Merger ist ein schönes Nachmittagsprojekt auf einem Breadboard. Ich würde allerdings statt dem wired-or mit D3 und D4 ein richtiges OR-Gatter einsetzen, hat dann sauberere Flanken als wie mit dem R5 Pulldown.


    Cartridge Disk Write Unterstützung fehlt noch und ist generell noch recht experimentell der Cartridge Disk Teil. Ich hoffe über die Weihnachstzeit was mehr Zeit dazu zu haben, kann einige Tage Arbeit sein.

    Sind jetzt noch 7 Platinen da von der ersten Serie. Ich plane aktuell keine weiteren zu produzieren, aber mein Crazy Cartridge später wird auch MIDI als optionale Erweiterung haben, wenn ich mal dazu komme, bin momentan beruflich sehr beschäftigt. Zur Feier der letzten Kerberos Cartridges gibt es neue Gehäusefarben. Danke an alle Unterstützer, war ein interessantes Projekt.