Liebe Programmier-Gemeinde, die meisten von euch haben den Klang des Instruments vielleicht schon gehört. Der E-mu Emax 1 war Mitte der 80er einer der ersten Sampler für das semi-professionelle Portemonnaie und wurde von zahlreichen Bands benutzt, so z.B. Depeche Mode. Auch heute noch hat das Gerät wegen seines Lo-Fi Sounds einen legendären Ruf und wird tausendfach verwendet. Beispielsweise haben kreative Köpfe in der Community Wege gefunden, die Sound-Libraries von CompactFlash- und SD-Kartenleser zu laden. Allerdings hat das Emax OS eine Limitierung, die beim Formattieren dazu führt, dass max. 40 Banks gespeichert werden können (00 Floppy Drive, 01-40 HD). Beim Nachfolger, dem Emax II konnten Banks auf den freien HD-Slots 01-99 gespeichert werden. Ich denke die Limitierung auf 40 Speicherplätze hängt damit zusammen, dass die HD-Version damals mit einer 20MB Festplatte verkauft wurde und der nicht-erweiterbare RAM 512kByte groß ist (= 40 Banks). Im Zeiten von CF-/SD-Cards im GB-Bereich ist das natürlich kein Problem mehr. Wenn ihr auf die Software schaut (wenige kBytes - Floppy Zeitalter ;-)), wäre es da ohne große Mühen möglich aus der Limitierung von 40 Banks, ebenso 99 zu machen? Bzw. wäre theortisch sogar noch mehr drin ohne das 16x2 LCD zu überfordern? Grober Technischer Aufbau: https://nonaudio.wordpress.com/emulatorarchive/emax/technical/ Die detaillierte Service Manual: https://elektrotanya.com/emu_emax_sm.pdf/download.html Vielen herzlichen Dank! PS.: Ggf. bitte in korrektes Sub-Forum umsortieren. Danke!
Angehängte Dateien:
-
EEPROM.png
220 KB
:
Verschoben durch User
Freddy B. schrieb: > Wenn ihr auf die Software schaut (wenige kBytes - Floppy Zeitalter ;-)), > wäre es da ohne große Mühen möglich aus der Limitierung von 40 Banks, > ebenso 99 zu machen? Da die Software nicht im Sourcecode vorlieg, ist das nicht ohne große Mühen drin. Man müsste die Software mindestens durch einen passenden Disassembler jagen und dann anfangen, die Struktur des unkommentierten und ohne Funktions- und Variablennamen aufgebauten Codes zu verstehen. Und 260 kByte Binärcode sind schon eine ganze Menge, das ist kein "kleines" Programm.
:
Bearbeitet durch User
Das ist natürlich schlecht. Pardon, ich kenne mich leider nicht mit der Materie aus und hatte gehofft, das sei recht übersichtlich mit 100kB :-) Was könnte ich denn jetzt unternehmen, damit sich das noch realisieren ließe? Oder abhaken?
Abhaken. Der eigentliche Prozessor ist ein 32008, das ist ein schon lange ausgestorbener Exot, den vermutlich kaum noch jemand kennt: https://en.wikipedia.org/wiki/NS320xx Dafür ein Entwicklungssystem aufzutreiben dürfte ... interessant werden.
Rufus Τ. F. schrieb: > Der eigentliche Prozessor ist ein 32008, das ist ein schon lange > ausgestorbener Exot, den vermutlich kaum noch jemand kennt: > > https://en.wikipedia.org/wiki/NS320xx > > Dafür ein Entwicklungssystem aufzutreiben dürfte ... interessant werden. Es fängt ja schon damit an, dass ich trotz fünf Minuten Googlen nicht mal eine instruction set reference dafür auftreiben konnte. Nur ein AN von NatSemi, welches auf schmalen 4 Seiten ein paar Optimierungstricks zeigt.
c-hater schrieb: > Es fängt ja schon damit an, dass ich trotz fünf Minuten Googlen nicht > mal eine instruction set reference dafür auftreiben konnte. Einfach noch weitere 5 Minuten dran hängen!
Rufus Τ. F. schrieb: > Der eigentliche Prozessor ist ein 32008, das ist ein schon lange > ausgestorbener Exot, den vermutlich kaum noch jemand kennt: > > https://en.wikipedia.org/wiki/NS320xx > > Dafür ein Entwicklungssystem aufzutreiben dürfte ... interessant werden. http://www.cpu-ns32k.net/Overview.html Inklusive Soft-Core-Implementierung... -- Michael
me schrieb: > http://www.cpu-ns32k.net/Overview.html Beeindruckend. Dennoch dürfte die Aufgabenstellung Dissassemblieren-Verstehen-Ändern deutlich mehr Arbeit verursachen als eine komplette Neuentwicklung. Heutige µCs sind bestens dokumentiert, es gibt freiverfügbare Entwicklungssysteme, sie können in Hochsprachen programmiert werden, und sie sind leistungsfähiger, können mehr Speicher ansprechen und können auch mehr Speicher on-Chip enthalten, als dieser Sampler. Klar: Das ist dann nicht "retro".
Mit allem Respekt, aber was der Sampler konnte, lässt sich heute in SW realisieren. Das einzige, was man bräuchte, wären die Samples aus den EEPROMs.
Audiomann schrieb: > Mit allem Respekt... > Das einzige, was man bräuchte, wären die Samples aus den > EEPROMs. Mit allem Respekt, bei einem 256Bit EEPROM 9306 der da verbaut ist, können das wohl nicht gar so komplexe Samples sein... :-))
> Dafür ein Entwicklungssystem aufzutreiben dürfte ... interessant werden.
Lauterbach hat das Teil (zumindest früher) im eigenen Systemcontroller
des Trace32 drin. Es waren aber vermutlich einige der wenigen wo diese
Architektur verwendeten so daß die ebenfalls angebotenen Werkzeuge für
die Architektur als Zielsystem kaum mal verkauft wurden. Architektonisch
war das seinerzeit aber wegweisend für Workstations und hies anfangs
noch NS16000 bis mal einer der Marketingleute drauf kam dass 32 bit
hübscher wäre
Bankumschaltung ist nun kein Hexenwerk. Ihr denkt zu Kompliziert, das lässt sich sicher auf der HW Seite mit einem Schalter lösen z.b., in dem man die Schnittstelle des HD manipuliert. Ein Schaltplan wäre allerdings von Nöten zumindest um eine Kopfumschaltung zu ermöglichen. Gennau genommen genügt bei CF ein Adressbit zu setzen oberhalb der Bank 44 zu setzen. und bei Seriellen Laufwerken kann man im Interface die Adresse im Stream manipulieren. Namaste
Falls noch nicht bekannt, hier gibt es alle möglichen Resourcen zu den Produkten von EMU-Systems (nur nicht zu meinem Drumulator :-(: http://synthark.org/Emu/Sampler-Resource.html
Wenn es unbedingt Emu sein soll: Eine SB AWE32 kann man auch mit einem 64 MB EDO-RAM bestücken. Da werkelt dann auch ein Emu-Chip, und wer die Stiftleiste findet, kann sich sogar an SPDIF erfreuen. Die Verwaltung der Samples geht per PC naturgemäss einiges einfacher als mit einem kleinen Display und ein paar Knöpfen...
Winfried J. schrieb: > Ihr denkt zu Kompliziert, das lässt sich sicher auf der HW Seite mit > einem Schalter lösen z.b., in dem man die Schnittstelle des HD > manipuliert. > > Ein Schaltplan wäre allerdings von Nöten zumindest um eine > Kopfumschaltung zu ermöglichen. Sorry, aber Du weißt nicht, wie Festplatten oder Dateisysteme funktionieren. Die einzige Festplattenbauform, bei der eine Kopfumschaltung tatsächlich einfach manipulierbar war, ist schon vor etwa dreißig Jahren ausgestorben - das waren Festplatten mit dem ST506-Interface. > und bei Seriellen Laufwerken kann man im Interface die Adresse im Stream > manipulieren. Und das ist bei mindestens 1.5 GBit/sec Datenübertragungsrate (nicht Durchsatz) natürlich total trivial. Da klemmt man 'nen AtTinyIrgenwas rein, und der wuppt das dann.
Rufus Τ. F. schrieb: > Sorry, aber Du weißt nicht, wie Festplatten oder Dateisysteme > funktionieren. doch dasweis ich sehr wol Rufus Τ. F. schrieb: > Die einzige Festplattenbauform, bei der eine Kopfumschaltung tatsächlich > einfach manipulierbar war, ist schon vor etwa dreißig Jahren > ausgestorben - das waren Festplatten mit dem ST506-Interface. um ein Gerät aus dieser zeit geht es und Freddy B. schrieb: > Allerdings hat das Emax OS eine Limitierung, die beim Formattieren dazu > führt, dass max. 40 Banks gespeichert werden können (00 Floppy Drive, > 01-40 HD). Beim Nachfolger, dem Emax II konnten Banks auf den freien > HD-Slots 01-99 gespeichert werden. > > Ich denke die Limitierung auf 40 Speicherplätze hängt damit zusammen, > dass die HD-Version damals mit einer 20MB Festplatte verkauft wurde und > der nicht-erweiterbare RAM 512kByte groß ist (= 40 Banks). Im Zeiten von > CF-/SD-Cards im GB-Bereich ist das natürlich kein Problem mehr. Rufus Τ. F. schrieb: > Und das ist bei mindestens 1.5 GBit/sec Datenübertragungsrate (nicht > Durchsatz) natürlich total trivial. Da klemmt man 'nen AtTinyIrgenwas > rein, und der wuppt das dann. Eine Speichererweiturung auf 1 MB habe ich im 8 Bit Atari auf Basis der 320 K Ramdisk selbst mit bankswitching in dyn. RAM realisiert. Kurz nach dem Mauerfall. Ebenso einen 32 Bit Pararalleport , Eprommer und RS232. Auch 8Stück XF555 FD Laufwerke habe ich im 386er simuliert über eine 5V "RS232"-SIO IN PDS Basic schneller als die Floppy Ich Hab so gar noch eine ROM_Diskplatine hier liegen. Der Trick ist die Richtige Stelle im Interface zu manipulieren. Falk das ist kein Hexenwerk Namaste
:
Bearbeitet durch User
Winfried J. schrieb: > Eine Speichererweiturung auf 1 MB habe ich im 8 Bit Atari auf Basis der > 320 K Ramdisk selbst realisiert. Kurz nach dem Mauerfall. Ebenso einen > 32 Bit Pararalleport , Eprommer und RS232. Ja. Gewiss. Und damit weißt Du, was nötig ist, um eine SATA-Schnitttelle zu manipulieren? Ich habe schon vor dem Mauerfall an 8-Bit-Rechnern herumgelötet, mir meinen ersten sogar komplett auf Lochrasterplatinen gefädelt, aber ... Nein, da gibt es keine "richtige Stelle im Interface".
Rufus Τ. F. schrieb: > Winfried J. schrieb: >> Eine Speichererweiturung auf 1 MB habe ich im 8 Bit Atari auf Basis der >> 320 K Ramdisk selbst realisiert. Kurz nach dem Mauerfall. Ebenso einen >> 32 Bit Pararalleport , Eprommer und RS232. > > Ja. Gewiss. Und damit weißt Du, was nötig ist, um eine SATA-Schnitttelle > zu manipulieren? > > Ich habe schon vor dem Mauerfall an 8-Bit-Rechnern herumgelötet, mir > meinen ersten sogar komplett auf Lochrasterplatinen gefädelt, aber ... > tja ich kam erst 1986 an eigene HW > Nein, da gibt es keine "richtige Stelle im Interface". my, ich will nicht die Sata manipulieren sondern die originale HW-Schnittstelle vor dem Interface zum neuen Laufwerk. Aber das benötigt Einsicht in den Schaltplan. Wenn man so alte HW mit moderner verbindet braucht es einen Busadapter, der den kleinen im größeren Speicherraum adressiert. Der größere besitzt irgendwo mehr Adressbits (diskret oder im Protokoll), welche der Kleinere Adressbus nicht anzusprechen vermag. Diese zu manipulieren simuliert ein Bankswitching. Namaste
:
Bearbeitet durch User
Winfried J. schrieb: > Wenn man so alte HW mit moderner verbindet braucht es einen Busadapter, > der den kleinen im größeren Speicherraum adressiert. Festplatten wurden auch damals nicht in den Adressraum des Prozessors eingeblendet, insofern ist Dein "Busadapter"- und "Speicherraum"-Konzept hier nicht zielführend.
Der Emax war nicht nur "irgendein" Sampler, er hatte immerhin einen analogen Signalpfad nach den 12-bit DA Wandler. Die analogen Tiefpassfilter (resonanzfähig und 24 dB/Oktave, SSM 2047) haben den Sound wesentlich beeinflusst. Und die Manipulation des OS des Emax mit dem Atari 800 zu vergleichen, ist auch nicht ohne. Der Atari hatte zum einen deutlich weniger Code in den ROMs (ca 16 kB) und war deutlich besser dokumentiert. Beim Emax muss man wohl hier bei Null anfangen. Ein visierter Assembler-Hacker kann sowas schon schaffen, aber das will niemand bezahlen, denn das geht nicht in ein paar Stunden.
irgend ein IF muss es geben. Freddy B. schrieb: > Ich denke die Limitierung auf 40 Speicherplätze hängt damit zusammen, > dass die HD-Version damals mit einer 20MB Festplatte verkauft wurde und > der nicht-erweiterbare RAM 512kByte groß ist (= 40 Banks). wenn eine Floppy dran passte dann ist ein Shugartbus wahrscheinlich 20MB HDs hatten imho noch ST506-Schnittstelle https://de.wikipedia.org/wiki/ST506-Schnittstelle Namaste
:
Bearbeitet durch User
https://nonaudio.wordpress.com/emulatorarchive/emax/technical/ ebenda Support Chips One standard 6850 UART chips provides MIDI and RS422 serial interfacing. The floppy disk gets the usual WD1772 controller. The floppy drive is the most expensive single component in an Emax at $250. Unbelievable ! Hard Disk The optional internal SCSI hard disk requires a SCSI upgrade, which is possible with later versions of the Emax. The drive is a Miniscribe (later Maxtor) 8425S with 20 MB of space. Nabitte alte Bekannte das selbe zeug was Atari benutzte vor der XF551 und weiter dort Circuit Board Versions There are 3 main circuit boards in the Emax, the digital board for the processors, memory and E chip (sometimes this sits on a daughter board), a front panel board for the controls, and an analog output board. The digital and analog board went through three main versions, as the Emax was developed with further hardware features and as bugs were fixed in the electronics.The digital board versions are important as they determine whether a SCSI interface can be added. Version 1 – initial digital board found in just the first few basic Emax’s – it cannot be upgraded to take a Hard Disk or SCSI Version 2 (PC326) – has 24-pin boot ROM, SCSI controller chip socket and can be upgraded to HD/SCSI with modifications. Version 3 (PC333) – already has a SCSI controller socket and 28-pin Boot ROM. Easy to upgarde to external SCSI, especially if the Emax is already a HD model. ....nix hexerei nur Fleiß gefordert loggen, analysieren, interface basteln, manipulieren, checken Namaste
:
Bearbeitet durch User
Interessante Diskussion. Also mit dem OS Mod kann ich ja dann abhaken. Da bin ich scheinbar der naiven Vorstellung erlegen, der Experte müsste nur eine Programmier-Programm öffnen und irgendwo die (arbitrare) Festlegung auf 40 Banks ändern. Da ihr ja auch viel über die Hardware gesprochen habt und deren Parallelen zu damaligen Computern. Gibts es im Bezug auf diesen kultigen 80er Jahre Sampler/Synthesizer andere interessante Mods die man nachverfolgen könnte?
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.