Hallo! Nachdem ich neulich in diesem Forum schon mal fantastische Erfahrungen gemacht habe, wende ich mich erneut an euch. Ich bin Musiker und interessiere mich ziemlich für die alte Technik, die dahinter steckt, kenne mich leider aber nicht mit der tieferen Ebene dahinter aus, beispielsweise dem Programmieren. Ich arbeite gerade an einen E-mu Emulator III. Das Gerät mit 4MB RAM wurde von 1987-90 für etwa 20.0000 DM verkauft, die zusätzlichen 4MB haben nochmal etwa 4-5.000DM gekostet. Einer der besten Sampler aller Zeiten. Hat eine digitale CPU-Sektion, analoge Audiosektion. Die Firma E-mu gibts leider nur noch auf dem Papier. Sie wurde in den 90ern geschluckt und heute arbeitet dort niemand mehr von damals. Damals wurde angekündigt, das man ein 16MB RAM Speicher-Upgrade herausbringen würde, das wurde aber aus Gründen einer alternativen Produktpolitik nie verwirklicht. Ich habe jetzt mit jemandem Kontakt gehabt, der unglaubliches technisches Knowhow hat und der sagte, dass es technisch wahrscheinlich möglich ist, da die Technik 16MB theoretisch händeln könnte, was die ganze Sache nun wirklich spannend macht. Die Frage ist, ob das Betriebssystem das mitmacht. Deshalb wende ich mich an euch (ich habe das OS angehängt): 1) Ich habe grundsätzlich keine Ahnung davon, mit welchem Aufwand das theoretisch verbunden wäre. Was müsste man machen, damit das OS 16MB erkennt und nicht nur 8? 2) Gibt es heut zu Tage noch Experten unter euch, die das könnten? [3) Welches Freeware-Programm gibt es, dass ich mal selber ein wenig darin eintauchen könnte und mir die Programmiercodes anschauen könnte?] Möglicherweise wichtig - die Service-Manual, die auf die Technik eingeht, kann man hier lesen: http://www.theemus.com/documentation/emulatoriii/EmulatorIII_Service_Manual.pdf Ich stehe mit großem Enthusiasmus hinter der Sache und bin mir absolut sicher, dass es in dem entsprechenden Forum hunderte Leute gibt, die das genauso sehen, weil sich mit doppelt so viel Speicher viel mehr bewerkstelligen lässt. Hilfe und Antworten würden mich riesig freuen!!! Vielen Dank!! Beste Grüße, Frederic
Eher nicht. CPU: 6800----->Uralt, heute nicht mehr erhältlich andere Bausteine: Funktion unklar. Es erscheint mir mehr Aufwand, als das Ding neu zu entwickeln. Eventuell ein nachbau in VHDL, aber ... Gruss Robert
mit entsprechenden PALs für die Adressdecodierung sollten auch 16 MByte Sample RAM möglich sein, da die CPU ja 16M Worte adressieren kann.
Mikki Merten schrieb: > mit entsprechenden PALs für die Adressdecodierung sollten auch 16 > MByte > Sample RAM möglich sein, da die CPU ja 16M Worte adressieren kann. Hi, ok meinst ihr das es nicht so dramatisch viel Aufwand wäre? Gut aber muss nicht dennoch die Software angepasst werden? Würde mich freuen, wenn jemand einen Blick drüber wirft und mir sagen könnte ob das machbar ist. Würde den Aufwand auch dann anstandslos vergüten. Würde mich riesig freuen! PS: Welche Software für MAC oder PC gibt es mit der ich mir selber mal die Programmcodes anschauen könnte?
:
Bearbeitet durch User
R. Freitag schrieb: > Eher nicht. > CPU: 6800----->Uralt, heute nicht mehr erhältlich > andere Bausteine: Funktion unklar. Wieso 6800? Auf Seite 87 der Anleitung ist beschrieben, dass ein NS32016 (+FPU) eingesetzt wurde. Der Baustein ist allerdings noch wesentlich seltener als Bausteine der 6800-Serie. Die sog. "Scanner MPU" soll ein Rockwell 6500/11 sein, also vermutlich ein 6511 wie er im C64 verwendet wurde. Die Peripheriebausteine (WD1772 für die interne Floppy, NCR5380 für SCSI) sind wiederum Mainstream der damaligen Zeit.
Für einen NS32016 Prozessor dürfte es für MAC / PC sehr wenig geben, beim PC wohl allenfalls unter DOS ist ja mittlerweile über 25 Jahre her. War für seine damalige Zeit schon ein netter 32 Bit Prozessor.
Mikki Merten schrieb: > Für einen NS32016 Prozessor dürfte es für MAC / PC sehr wenig geben, > beim PC wohl allenfalls unter DOS ist ja mittlerweile über 25 Jahre her. Die Prozessorfamilie NS32000 wurde mindestens bis GCC 3.3.6 unterstützt, aber nicht mehr durch GCC 4.0. Einige Linux-Distributionen bieten noch alte Pakete für GCC 3.3 an, aber vermutlich nicht als fertigen Cross-Compiler für NS32000. Jedoch nützt einem der GCC alleine nichts, wenn man keine Quellen, sondern nur Binaries hat... Nachtrag: Während der "Hochphase" von NS32000-Systemen waren normale DOS-PCs viel zu leistungsschwach, um darauf sinnvoll Crosscompilierung usw. zu betreiben. Das war eher die Domäne von VAX/PDP-11 bzw. später UNIX-Workstations.
:
Bearbeitet durch User
Freddy B. schrieb: > ... > > Die Frage ist, ob das Betriebssystem das mitmacht. Deshalb wende ich > mich an euch (ich habe das OS angehängt): Wenn nix im Service-Manual dazu steht, dann kann es sein oder erst mit einem Update, dass nicht rausgekommen ist. > 1) Ich habe grundsätzlich keine Ahnung davon, mit welchem Aufwand das > theoretisch verbunden wäre. Was müsste man machen, damit das OS 16MB > erkennt und nicht nur 8? Wenn es keinen quelloffenen Sourcecode gibt und das OS das nicht unterstützt, dann sieht es sehr schlecht bis sehr aufwendig aus > 2) Gibt es heut zu Tage noch Experten unter euch, die das könnten? Einen Experten, der das auf anhieb kann, gibt's es sehr unwahrscheinlich. Alle anderen müssten sich erst reinarbeiten und das kostet (sehr) viel Zeit... > Einer der besten Sampler aller Zeiten. Da hat sich aber doch etwas getan in den letzten Jahren. Nicht nur die Speichergröße ist ein vielfaches, sondern auch das bedingte Timestrechting ohne Pitching kann sich hören lassen. Ausserdem gibt es echt gute Emulatoren und im Allgemeinen, also das normale Volk, erkennt den Unterschied nicht, da man nicht weiß, wie das Orginal ganz genau klingt. > ... E-mu Emulator III. Was sich echt lohnen kann, diese alten Geräte zu restaurieren. Hab schon ne Roland TB-303 für gar ned so wenig Geld gesehen...
Wenn man sich das Datenblatt des NS32016 mal genauer anschaut hat dieser zwar 24 Bit Adressen allerdings nur als Byte Adresse AD0 und /HBE werden hier für H/L Byte benutzt. Folglich steht ingesamt nur ein Adressraum von 16 MByte zur Verfügung. Dieser ist nochmals beim EMUIII in 4 gleich grosse 4 MByte Segmente unterteilt. Davon stehen 2 für Sample RAM zur Verfügung und werden auch von der Firmware entsprechend unterstützt. Mehr dürfte wohl umfangreichere Änderungen an der Hardware nach sich ziehen, von den erforderlichen Änderungen and der Firmware ganz zu schweigen. Da stellt man wohl eher ein neues leistungsfähigeres System mit aktuelle Bauteilen auf die Beine ;)
Ein Problem dürfte auch das verwendete DRAM sein. Die DRAMs haben ihre
Speichergröße in rascher Folge jeweils vervierfacht, manchmal gab es
noch Zwischenstufen mit zweifacher Größe, aber die waren noch seltener.
Dazu kommt, dass je nach Hersteller die Zahl der Refresh-Zyklen
unterschiedlich war. Ein RAM konnte 8*12 Bit oder 10*10 Bit organisiert
sein, das sieht man nur im Datenblatt, die Anschlußbelegung ist gleich.
8 Zeilenbits heisst 256 Refresh-Zyklen, 10 wären 1024. Wenn die
Ansteuerlogik 256 erwartet, werden drei Viertel des Rams nicht oft genug
angesprochen und vergessen ihren Inhalt.
In dem verlinkten Handbuch sehe ich nichts von 16 MByte, da steht nur 8.
Nur wenn Hardware und Software die 16 unterstützen funktioniert es. Ich
habe im Schaltplan keine Typbezeichnung für das DRAM gesehen ("150µsec"
ist die einzige Angabe, vermutlich die Zugriffs- oder Zykluszeit incl.
Rückschreiben), damit könnte man mal das Datenblatt suchen.
Christoph Kessler (db1uq) schrieb: > ("150µsec" ist die einzige Angabe, vermutlich die Zugriffs- > oder Zykluszeit incl. Rückschreiben) Nano-, nicht Microsekunden.
Also Wenn man die PALs gegen etsprechend programmierte GALs austauscht die die Wait States für die SPeicher und IO zugriffe richtig timen würde es schon gehen. Aber es liegen einige IO-Bausteine im Bereich C00000-FFFFFF. Da könnte man zwar das Adressdecoding der GALs auch anpassen aber es müßte auch die Software umgeschriebn werden. Also sollte man auf die "oberen" 4MByte besser verzichten. Und ob sich der Ganze aufwand dann für die extra 4MByte dann lohnt ?! Also ich hab im angängten Dokument nur mal die Schaltpläne überflogen und den IO-Adressraum. Wenn der 32016 Leitungen zur unterscheidung von Memory und IO-Zugriffen hat könnte man da relativ einfach was machen. Hab mir aber das Datenblatt von dem nicht angeguckt.
Hallo Freddy: Hast Du Dein Projekt realisiert? R. F. schrieb: > Es erscheint mir mehr Aufwand, als das Ding neu zu entwickeln. > Eventuell ein nachbau in VHDL, aber ... Das kam mir auch spontan in den Sinn. Müsste sich mit einem RAM doch leicht machen lassen. Gfs noch eine Filtersektion.
Lohnt eigentlich nicht. Eine Soundblaster AWE hat auch einen e-mu an Board und kann und unterstuetzt 64 MB im 30 pol. SIMM-Format. Der Nachfolger SB Live kanns sogar per PCI aus dem normalen RAM. Der NS32016 wurde von Siemens m.W. in ihren Sinixkisten verbaut. Vielleicht findet man da ja noch was. Ansonsten wuenche ich trotz der Hindernisse viel Erfolg.
Schade dass sowas angedacht und andiskutiert wird, aber niemals zu Ende gebracht wird. eMU war einfach Spitze! Schade, dass es die nicht mehr gibt und die Geräte so langsam aber sicher vor die Hunde gehen.
Interessant, aber nicht wirklich praktikabel. Jedenfalls nicht für einen Nutzer wie mich :-)
Ich habe mir das auch mal angeschaut. Da gibt es ja nicht nur die CPU, sondern auch die F-Chips, die wohl für Sampling und Wiedergabe zuständig sind. Da müßte man erst mal schauen, ob das mit diesen Chips möglich ist. Diese 'Custom' Chips sind wohl undokumentiert. Dann die 74XX Gräber auf der Platine, da möchte man doch nichts ändern, mit der Gefahr, dass irgendwas anderes dann nicht geht. Vielleicht ist das Gerät aus nostalgischen Gründen ganz nett. Aber die Funktionalität programmiert man doch in einer Woche auf einem Raspi plus USB-Soundadapter. Wäre vielleicht konsequenter so etwas zu programmieren und dann Open Source zur Verfügung zu stellen. Da haben dann mehr Leute etwas davon.
Die Besonderheiten am Emulator III waren seine hervorragende Bedienbarkeit, die sehr guten analogen Filter und die (z.B. durch die Filter und den Bearbeitungsmöglichkeiten bedingte) ebenfalls hervorragende Klangqualität. Für Musiker ist u.a. die riesige Sampledatenbank interessant, in welche die Bearbeitungsmöglichkeiten eingestrickt sind, also mal eben Samples übertragen ist nicht soo einfach. In der Vergangenheit wurde aber gern die SCSI-Schnittstelle zur Speichererweiterung mit Zip-Laufwerken o.ä. genutzt. (das Nachladen ganzer Live-Setups dauert nicht so lange. Ich hatte in den 90er Jahren (am Anfang) noch Konzerte erlebt, die öfter (mehrere Minuten) pausierten, weil die Programme auf den Disketten ihre Nachladezeit brauchten.)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.