Modifikation GEM/generalmusic S2/S3/S2R turbo Modifikationen

[DanReed]

Hallo Leute,

suche Mitstreiter beim Modifizieren des GEM/generalmusic S2/S3/S2R turbo.

Besitze seit ein paar Wochen einen Turbo samt Schaltplänen und ROM Inhalten. Drei simple Mods habe ich bereits entwickelt:
1) Der Kopfhörerausgang hat viel zu viel Power und rauscht. Zwei 47kOhm-Widerstände lösen beide Probleme und verbessern Klirrfaktor und Frequenzgang (Bauanleitung im nächsten Beitrag!).
2) Die Wandler zeigen beim Ausklingen hörbare Nulldurchgangsverzerrungen. 8 Widerstände und 4 Spindeltrimmer reduzieren dies beim Main-Out deutlich. Für die zusätzlichen vier Ausgänge benötigt man das ganze nochmal.
3) Neue Sägezahnwelle ohne hörbare Bandbegrenzung.

Ein paar Eckdaten: Haupt-CPU ist eine Motorola 68302 mit 16MHz (übrigens beherrsche ich 68000-Assembler im Schlaf). Dort sind neben der Peripherie maximal 4MB RAM und 2MB ROM angeschlossen. Da 16MB addressiert werden können, ist noch Luft, z.B. für eine Vergrößerung der RAM-Disk auf bis zu 11MB. Die vier hochqualitativen 18-Bit-D/A-Stereo-Wandler laufen mit 83,3kHz (2faches Oversampling). Sie hätten Luft bis über 700kHz. Bereits durch geringfügiges Übertakten könnte aus der Basisfrequenz von 41,7kHz (die bedenklich nahe an der Hörgrenze liegt) gute 44,3kHz oder sogar 46,9kHz werden. Dann wäre einiges im ROM zu tun (MIDI-Takt-Teiler, 440Hz- und Filter-Stimmung, LFO- und ENV-Zeitkonstanten anpassen).

Folgende schwere System-Bugs bringen mich nun zu tiefgreifenden Mods, auch im ROM:
1) Bei einer Peformance mit 4 parallelen Single-Oszillator-Sounds werden bei schnellem 8stimmigem Spiel immer wieder Oszillatoren von Stimmen geklaut, die eigentlich gehalten werden. Hier ist offenbar bei der Turbo-Version die Reservierung der Oszillatoren für neue Töne falsch programmiert.
2) Das interne Datum läßt sich nicht auf den 1.1.2012 oder später setzen.

Reizvoll wären natürlich Änderungen wie:
1) Beide Filter durch unterschiedliche ENV steuern können
2) Resonanzen durch mehr Quellen als nur Velocity modulieren können
3) Auch bei 32 Stimmen die Filter durch mehr Quellen als nur Velocity und Pressure steuern können
4) Zweiter LFO
5) Portamento
6) Oszillator-Reset (Key Trigger) ausschalten können
7) Mehr Velocity-Kurven
8) Key Trigger beim LFO deaktivieren können
9) Mehr Parameterstufen als nur -7..7 bei Modulationen
10) Oszillatorzahl durch Optimierungen von 32 auf 36-40 erhöhen
11) ...

Vieles kann beim GEM S durch ein Mod des MIOS (das aktuelle ist Version 2.0 vom 28.3.91) erreicht werden. Man könnte auch die gesamte Bedienung ergonomischer gestalten (z.B. wie beim ESQ-1/M, SQ-80 ohne ständiges Bestätigen).

Wer das Gerät besitzt, sich über die vielen unnötigen Limits ärgert, von Hard- und/oder Software-Modifikation Ahnung hat und Lust hat mitzumachen, antworte doch bitte.

Gute Ideen, was man noch tun könnte, sind ebenfalls herzlich willkommen.

 

[DanReed]

1. Projekt: Kopfhörerlautstärke-Mod

Schließt man einen Kopfhörer an den GEM S2, S3 oder S2R an (Turbo egal), hört man auch bei Reglerstellung 0 erhebliches Grundrauschen und bekommt bereits bei der Hälfte des Reglerwegs wegen der enormen Lautstärke taube Ohren.

Um das Rauschen zu unterbinden und die Maximallautstärke deutlich abzusenken (aber für Ohrenschmerzen immer noch ausreichend), habe ich für mein Gerät folgenden Mod entwickelt. Dazu muß man keine Platine ausbauen, da von oben gelötet wird.

1) Die üblichen 9 + 5 Schrauben an der Unterseite lösen.
2) Deckel vorsichtig senkrecht nach oben abheben und nach hinten legen. Man sieht folgendes:

3) Den in obigem Bild orange umrandeten Bereich sieht man hier in der Vergrößerung, wobei die vier relevanten Lötpunkte ebenfalls orange markiert sind:

4) Die beiden dort vorhandenen Widerstände (Farbkode von rechts nach links: rot-rot-gelb-gold = 220kOhm) sollen überbrückt werden mit 47kOhm-Widerständen. Deren Beinchen einfach U-förmig biegen, dann gleichlang abschneiden und vorsichtig anlöten, zuerst den unteren ("R4"), dann den oberen ("R2"). Die Kabel in der Nähe (vor allem das benachbarte Flachbandkabel!) abziehen und aus dem Gefahrenbereich des Lötkolbens bringen. Das Endergebnis könnte so aussehen:

Bitte nehmt zwei gleiche Widerstände und messt sie trotzdem auf geringe Abweichung durch. Und man sollte große Erfahrung im feinen Löten haben und sehr wenig Lötzinn verwenden, sonst besser jemanden fragen, der das beherrscht.

Danach beginnt der Kopfhörerausgang erst im oberen Viertel des Lautstärkereglers leise zu rauschen und trotzdem ist die Maximallautstärke, z.B. der Demosongs erheblich.

Technischer Hintergrund: Durch die kleineren Widerstände wird die Gegenkopplung im Kopfhörerverstärker erhöht. Dies bewirkt eine um 15.1dB geringere Verstärkung, wodurch das Grundrauschen um den gleichen Betrag herabgesetzt wird. Positive Nebeneffekte: Die Bandbreite wird größer und die Verzerrungen werden geringer.

 

[microbug]

Sehr schön. Auch wenn ich meine S3 nicht mehr besitze, so bin ich gerne dabei, habe ja noch alle Unterlagen, und habe die Geräte nicht abgeschrieben.

Für mich wäre vor allem eine ordentliche Nutzung des Sysex-Formates bzw dessen Dokumentation interessant.

Vielleicht ließen sich auch damit die nicht-Turbos ausstatten.

 

[DanReed]

Freut mich sehr, microbug, daß Du Dich gemeldet hast! Dann wären wir ja schon zwei

Es läuft darauf hinaus, daß zuerst das Turbo-ROM disassembliert (und im Fall der ursprünglich in C geschriebenen Passagen auch decompiliert) werden muß. Da geht einfach kein Weg dran vorbei. Wir müßten ev. zuerst einen angepaßten Disassembler/Assembler programmieren (z.B. als Unix-Commando). Wer hat denn Lust, bei sowas mitzuwirken (68000er Assembler) und so die totale Macht über die GEM-Maschinen zu erlangen?

Die verwendeten Eproms sind 27C4001D mit 512MByte im DIP32-Gehäuse. Wer kann die denn brennen? Meine betagten Brenner reichen nur bis 27C512.

Wie gesagt: Ich habe die Hi/Lo-Teile der Eproms schon zusammengesetzt und herumgestöbert. Alles gut strukturiert, oft tauchen Strings in C-Syntax auf (enthalten "%d", u.s.w.).

Selbst wenn man den S2/S3 nur als Masterkeyboard einsetzen wollte, wäre die Implementation des Running-Modus (wurde wohl seinerzeit ignoriert) und besserer/mehr Fingerkraft-Velocity-Wert-Tabellen wohl notwendig und wenig aufwendig (gibt hier nur einen 5stufigen Parameter soft bis hard und linearen/logarithmischen Verlauf). Sysex ist da bedeutend aufwändiger, aber klar machbar!

 

[microbug]

Ich hab den Quellcode des 6803-Disassemblers in Visualbasic von Colin Fraser hier, mit dem er den JX-10 analysiert hat. Ich nutze endlich mal das seit langen rumliegende RealBasic (neu: Xojo), das kann VB migrieren, das könnte man dann erweitern. Meine in BASIC geschriebenen Disassembler auf dem 8bit Rechner sind für sowas nicht verwendbar, weil rein prozedural. Ok, man könnte auch mit Lazarus arbeiten, aber Pascal, örgs.

Es gibt da diesen finnischen Server, auf dem ne Menge Atarizeugs liegt, davon hab ich mir etliches gezogen, iirc war da auch ein Disassembler für ne andere Plattform dabei. Kommerziell kenne ich sonst nur IdaPro, und der kostet doch etliches.

Vor der Firmwareanalyse steht die Memorymap, also die Analyse der Adreßdekodierung. Das macht's um einiges leichter, wenn man genau sagen kann, in welchem Bereich was liegt.

Die Peripheriechips sind ja alle dokumentiert, also FDC, Uhrenchip, Displaycontroller. Schwerer wird's bei den Customchips.

Interessant wäre auch zu wissen, ob und wie die für SCSI vorgesehene Schnittstelle auf dem Turboboard schon irgendwie angesprochen wird und was da noch für ein Chip in die leere Fassung gehört.

Was auch fehlt, wäre eine Velocity-Begrenzung, zB um alte Yamaha DX7-Module anständig ansteuern zu können.

Die EPROMs sollte mein Brenner können, hab einen Mega-Adapter dafür. Ich hab das Ding von mcumall.com, kann ich nur empfehlen.

Würde aber vorschlagen, sich für sowas einen Simulator zu bauen, das spart die Brennerei. Hab ich früher mal gemacht, nur etwas weniger aufwendig als die Schaltung aus der c't (PEPS). Wenn man sich da ne Parallelportmimik baut, braucht man auch keinen uC dafür, mit einem USB-UC und einer CF-Karte geht's auch und ist vielleicht auch weniger Aufwand bei der Verdrahtung.
Vielleicht gibt's ja auch schon irgendwo einen fertigen DIY-Simulator im Netz. Der PEPS kam damals ohne uC aus.

 

[DanReed]

Danke für die vielen guten Punkte:

1) ROM-Simulator per USB
Einfach zu realisieren wären 2MBytes gebuffertes SRAM, das mittels ein bischen Logik z.B. vom Arduino beschrieben werden kann.

Noch einfacher wäre es, wenn wir eine externe Software schreiben würden, die wie der Sample Translator beim Non-Turbo hinzugeladen und ausgeführt werden konnte. Dazu müßten wir nur das exe-Format des damaligen stand-alone Sample Translators analysieren!

2) Adreßraum und Peripheriechips
Recht hast Du! War ich etwas zu vorschnell. Das kann man aus der verbauten Logik im Schaltplan ablesen. Vielleicht ist es das Beste, beides zeitgleich zu machen, denn man sieht ja auch in der Firmware, auf welche Adressbereiche wie zugegriffen wird.

3) Disassembler
Der 6803 wird uns nicht helfen, denn der 68000 hat als CISC Prozessor zwar nur 56 Grundbefehle, aber durch die 14 Adressierungsarten und unterschiedlichen Datentypen kommt man auf über 1000 Befehlskombinationen. Es dürfte also einfacher sein, vom Source-Code eines bestehenden 68k-Disassemblers auszugehen und ihn an die Bedürfnisse anzupassen (gerne kein Pascal, meinetwegen auch in Visual Basic, aber muß es Real Basic sein? Vielleicht ist Perl die Sprache der Wahl? Oder MatLab/Octave/Scilab, dann könnte man schnell Daten visualisieren).

4) Velocity-Begrenzung
Ich stelle mir sogar vor, daß wir eine frei konfigurierbare Kurve bereitstellen (wie bei den bereits vorhandenen Tracking-Kurven). Dann kann man beliebige Dynamikbereiche komprimieren, expandieren oder limitieren.

5) SCSI
Das wird irgendein Chip zur Adressdekodierung sein. Der komplette Controller fehlt und sollte wohl mal an die Pfostenstecker des Turboboards angeschlossen werden. Würde ich Vergangenheit sein lassen und in Richtung SD-Card gehen!

 

[microbug]

1) ROM-Simulator per USB
Einfach zu realisieren wären 2MBytes gebuffertes SRAM, das mittels ein bischen Logik z.B. vom Arduino beschrieben werden kann.

Das klingt vernünftig.

Noch einfacher wäre es, wenn wir eine externe Software schreiben würden, die wie der Sample Translator beim Non-Turbo hinzugeladen und ausgeführt werden konnte. Dazu müßten wir nur das exe-Format des damaligen stand-alone Sample Translators analysieren!

Ja, das wäre eine Idee, ob dieses Format aber ohne Firmwareanalyse rauszubekommen ist? Den Translator hast Du?

2) Adreßraum und Peripheriechips
Recht hast Du! War ich etwas zu vorschnell. Das kann man aus der verbauten Logik im Schaltplan ablesen. Vielleicht ist es das Beste, beides zeitgleich zu machen, denn man sieht ja auch in der Firmware, auf welche Adressbereiche wie zugegriffen wird.

Eigentlich sollte das der erste Schritt sein, je nach Struktur des OS. Ich hab solche Analysen in 8Bit-Zeiten öfter gemacht, und da wurden auch gerne im ROM einfach Tabellen und Strings mittenrein gepackt und nicht als Block zusammen. Liegt sicher auch daran, daß man den Kram damals direkt in Assembler gemacht und nicht jeder Ordnung gehalten hat. Die ROMs der damaligen Heimcomputer, aber auch damalige Software, war da sehr unordentlich. Wenn man da nicht den Adreßraum kennt, fliegt man da schnell auf die Nase.

3) Disassembler
Der 6803 wird uns nicht helfen, denn der 68000 hat als CISC Prozessor zwar nur 56 Grundbefehle, aber durch die 14 Adressierungsarten und unterschiedlichen Datentypen kommt man auf über 1000 Befehlskombinationen. Es dürfte also einfacher sein, vom Source-Code eines bestehenden 68k-Disassemblers auszugehen und ihn an die Bedürfnisse anzupassen (gerne kein Pascal, meinetwegen auch in Visual Basic, aber muß es Real Basic sein? Vielleicht ist Perl die Sprache der Wahl? Oder MatLab/Octave/Scilab, dann könnte man schnell Daten visualisieren).

Ok. Ich hab mal im Netz geschaut, da scheint es ja durchaus vorhandene Sourcen zu geben. Warum RealBasic bzw Xojo? Weil ich bei den Sprachen recht eingeschränkt bin. Assembler, bevorzugt Rockwell/Motorola, kann ich, ebenfalls BASIC und bissl Pascal (Forth ist zu lange her), aber alles, was mit C-Syntax zu tun hat, geht nicht an mich - versuche das immer mal wieder, aber das wird nix. Xojo hätte zudem den Vorteil, daß die IDE nix kostet und man auf allen 3 Plattformen (Mac, Windows und Linux) damit Programme bauen und auch ablaufen lassen kann, eine Lizenz dagegen braucht man nur, wenn man standalone-Programme erzeugen will. Xojo ist VB-kompatibel und es gibt einen Migrationsassistenten. Matlab kenne ich nicht, klingt nach einer Windows-Only-Software.

4) Velocity-Begrenzung
Ich stelle mir sogar vor, daß wir eine frei konfigurierbare Kurve bereitstellen (wie bei den bereits vorhandenen Tracking-Kurven). Dann kann man beliebige Dynamikbereiche komprimieren, expandieren oder limitieren.

Das klingt ziemlich gut.

5) SCSI
Das wird irgendein Chip zur Adressdekodierung sein. Der komplette Controller fehlt und sollte wohl mal an die Pfostenstecker des Turboboards angeschlossen werden. Würde ich Vergangenheit sein lassen und in Richtung SD-Card gehen!

Sowieso, oder auch CF, denn CF ist noch einfacher einzubinden, weil parallel und braucht keinen Controllerchip. Noch besser wäre aber USB Mass Storage, denn bei den Speicherkarten, insbesondere SD Card, gibts immer neue Grenzen bei der Größe, die man bei USB Mass Storage so nicht hat. Da gibts dann auch fertige Controller dafür.

 

[DanReed]

Hm, in diesem Forum scheint wirklich sonst niemand weiter interessiert zu sein. Ist die Kiste nun also doch endgültig auf dem absteigenden Ast?

ob dieses Format aber ohne Firmwareanalyse rauszubekommen ist? Den Translator hast Du?

Leider nicht. Aber selbst wenn, ich komme an die echten Daten nicht ran, weil sie nur als Binary für dieses unsägliche inkompatible Gem-Diskettenformat vorliegen und damit auch die ganzen Disketten-Block-Header, ... enthalten. Das habe ich schon mal mit Sounds von den Sound-Disks versucht und bin auch am völlig verrückten Format gescheitert.

Floppy-Programmierung ist einfach nicht meine Welt

Um jetzt schnell zu einem Eprom-Emulator zu kommen, müßte man wohl die vier Eproms mit RAMs (z.B. der Ram-Disk) austauschen, ihre Stromversorgung durch die interne Batterie buffern und sie bei ausgeschaltetem S2 z.B. mittels Arduino beschreiben können. Da wären dann zwei Sets von Bustreiber-Chips nötig, die die Adress- und Datenleitungen des S2 hochohmig machen, wenn der Adruino aktiv ist, und umgekehrt.

Also müßte man z.B. in die Sockel der Eproms eine Adapterplatine einsetzen, die man selber entworfen hat. Ok, wer hat Lust dazu?

Um auf der sicheren Seite wegen Buslänge und Terminierungswiderständen zu sein, könnte man statt dessen ein alternatives Turboboard entwerfen, das am bisherigen angelehnt ist (Reverse engineering), aber die vier Ram-Sockel, zwei Sets Bustreiber-Chips, ein bischen Logik und einen Arduino-Anschluß enthält.

Wenn dazu niemand Lust hat, dann müssen wir wohl doch Eproms löschen und beschreiben. Wo bekommt man denn die 512kBytes-Dinger schnell und günstig?

 

[microbug]

Nö, die Kiste ist nicht auf dem absteigenden Ast, sondern die, die Interesse an einer Mitarbeit hätten, sind hier eher rar. Da müßte man im Turboforum mal anklopfen, da gabs schon Interessenten.

Den Schaltplan fürs Turboboard habe ich bei meinen Unterlagen, bin aber nicht fit in Eagle. Vielleicht ließe sich ja Kollege nordcore dazu gewinnen, uns zu helfen? Man könnte natürlich auch hingehen und gleich für größere EPROMs bzw Flash vorzusehen, das macht das OS-Basteln einfacher, bedeutet aber auch mehr Aufwand, da man sinnigerweise einen Bootblock vorsehen sollte.

Das Diskformat des GEM ist ja schon normales DOS, aber eben erweitert. Es gibt bzw gab im Netz ein DOS/Win-Utility, mit dem man die Disketten lesen/schreiben konnte, müßte ich hier liegen haben, ebenso wie den Translator als Einzelnes. Ich packe meine Sachen am Besten mal alle auf meinen Server und maile Dir den Link, damit wir Gleichstand haben.

Interessant wäre es ja zu gucken, wieviel von den Zusatzsachen man der normalen, nicht erweiterten S2/S3 spendieren könnte. Die EPROMs sollte man bei Reichelt bekommen, ansonsten hab ich sicher noch welche hier, Alternativ Kessler oder auch Hinkel.

 

[DanReed]

Im Turboforum ist ja leider schon lange mau.

Den Schaltplan fürs Turboboard habe ich bei meinen Unterlagen

Spannend! Dropbox? Oder mach einen Vorschlag. Meine Email hast Du ja.

nicht fit in Eagle

Ich auch nicht, aber was nicht ist, kann ja noch werden Wenn ich ein Ziel verfolge, arbeite ich mich auch gerne in mir unbekannte Software ein.

Als Neuling kenne ich "Kollege nordcore" noch nicht, da müßtest Du also Deinen Charme spielen lassen ... Oft reicht ja Hilfe zur Selbsthilfe

Diskformat des GEM ist ja schon normales DOS

Ja, aber die TD0-Dateien sind Images und damit praktisch unbrauchbar. Wenn Du den Sample Translator z.B. als Teledisk Image hast, dann wüßte ich nicht, wie man da das eigentliche Programm herausholen soll (Es gibt ja außer dem Sample Translator z.B. ein Utility um Hardcopies vom Display zu machen, hast Du das auch?).

Das ist ohnehin ein Frust beim S2: Sounds ließt und schreibt er nur im eigenen Format, das man sonst nicht bearbeiten kann (eben nur Images am Stück). Der Sample Translator dagegen kann auch von DOS importieren, aber natürlich keine Sounds, sondern nur einzelne Samples. Wenn Du da eine Lösung hättest ...

PS.: Trotzdem hätt ich so gern einen S3 Turbo, aber wo bekomm ich den?

 

[virtualant]

PS.: Trotzdem hätt ich so gern einen S3 Turbo, aber wo bekomm ich den?

ich hab den S3 Turbo von Microbug

Bei eurer technischen Arbeit kann ich nicht mitmachen, das ist nicht mein Gebiet, leider.

 

[microbug]

@DanReed: Das Turboboard ist ja nix Wildes, nur Speichersockel, bissl Dekoder etc. Bin gerade am Ort hinter dem Schrägstrich und hab daher keinen Zugriff auf meine Daten, werde am Montag den Kram mal auf meinen Server packen und Dir den Link mailen. Falls ich den Plan des Turboboards nicht elektronisch haben sollte, wird der gescannt und dazugepackt. Diese TD0-Images stammen vom DOS-Programm "Teledisk", und meines Wissens nach gibts Windows-Sofware, die das lesen kann, muß ich mal schauen.

Das Hardcopy-Utility habe ich nicht, wohl aber davon gelesen, das gabs nur für die Entwickler, und wenns einer hat, dann eher Jürgen Schmitz. Was ich habe sind Originaldisketten für eine nicht erweiterte S3, denn meine wurde erst nachtäglich aufgerüstet. Muß ich durchgucken, wenn ich wieder zu Hause bin.

Habe hier noch echte PC-Diskettenlaufwerke und da ließen sich auch Images anfertigen, muß nur schauen, in welchem Format. Kannst ja mal einen Vorschlag machen. Die letzten Images, die ich gemacht habe, waren mit dem Tool für den Floppyemulator HxC.

 

[jmech]

Hallo alle,

tut mir leid, dass ich diesen Thread nach drei Jahren aus dem Jenseits zurueckhole. Schade, dass sich nicht mehr Leute finden konnten, um sich mit dem Reversen des GEM S2/S3 auseinanderzusetzen. Nachdem ich vor ca. einem halben Jahr mit DanReed per PM Kontakt hatte, als ich meinen S3 Turbo beim beruechtigten Akkutausch kurzzeitig lahmgelegt hatte, habe ich mich ueber die letzten Monate etwas mit der Sysex-Implementation, Floppy-Images und ROM-Dumps beschaeftigt. Um anderen Interessierten die Arbeit zu ersparen bzw. einige Tools zu teilen, wollte ich hier kurz zusammenfassen, wie weit ich bisher gekommen bin.

Auf https://github.com/jmechnich/s3turbo finden sich einige Skripte zur

• 
  Kommunikation mit dem Synthesizer (s3midi)
  Auflisten/Entpacken von Floppy-Images (s3img)
  Formatieren/Lesen/Schreiben von Floppies (s3floppy)

Weitere Dokumentation findet sich auf der Githubseite. Es ist moeglich, so gut wie alle Daten ueber MIDI aus dem Synth auszulesen. Leider habe ich es nicht geschafft herauszufinden, wie man Dateien auf den Synth hochladen koennte. Vielleicht ist das auch einfach nicht im MIOS implementiert. Teilweise habe ich die internen Dateiformate entwirren koennen, allerdings gibt es insbesondere bei den Soundpatches noch etwas Arbeit. Samplefiles lassen sich im Prinzip einfach dekodieren (siehe s3dump_TXL), aber Loop-Informationen scheinen in den Patchfiles zu stehen. Allgemein muss ich leider sagen, dass die Kommunikation mit dem Synth teilweise etwas buggy ist und einen Neustart notwendig machen koennen. Auch daher waere es attraktiv, das ROM zu entschluesseln und patchen zu koennen. Das fuehrt mich zum naechsten Punkt...

Auf https://github.com/jmechnich/s3sim findet sich der Anfang des Versuchs, mit Hilfe der gedumpten EPROMs einen Simulator zu schreiben. Der Code basiert auf dem m68k-Emulator Musashi, ist aber noch ziemlich unvollstaendig. Immerhin bootet das Teil, bleibt aber recht bald mangels der Implementation der Peripheriechips haengen. Eigentlich war mein Plan, die ROMs nach C zu dekompilieren, was mir leider erstmal zu aufwendig erschien, da mir die entsprechenden Tools und Erfahrung fehlen.

Die Programm-EPROMs und Sample-ROMs habe ich mit einem Mikrokontroller gedumpt, dazu mehr Infos auf https://github.com/jmechnich/ROMDump.
Kleine Anekdote dazu: die Sample-ROMs enthalten 16-bit signed Daten, die sich direkt abspielen, bzw. in einen Waveeditor importieren lassen, im Synth selbst sind aber nur 14 der 16 Datenleitungen angeschlossen -> es werden nur 14-bit ausgelesen. Deshalb sind die Samples i.A. auf einen Bereich von [-8192,8192] normalisiert - bis auf einen Drumsound im ersten ROM-Chip (ich glaube, es war eine Kickdrum). Vielleicht wurde der letztendlich einfach nicht verwendet, sonst muesste er eigentlich im Synth clippen.

Ich hoffe, jemand kann was mit dem Kram anfangen...
Bei Fragen stehe ich natuerlich gerne zur Verfuegung, und vielleicht hat ja sogar jemand Interesse, an der Dekompilationsgeschichte weiterzumachen. Grundsaetzlich bin ich auch sehr interessiert, falls jemand noch MIOS-Entwicklungscode/-werkzeuge besitzt. Gab es eigentlich irgendeine externe Software fuer den S2?

P.S.: Im uebrigen habe ich bei der Entwicklung ausschliesslich Linux verwendet. Es koennte gut sein, dass sich das meiste ohne Probleme auch unter OS X verwenden laesst, aber bei Windows waere ich mir da eher unsicher.
P.P.S.: Das Hardcopy-Utility ist mit zwei weiteren Programmen (Disk Copy und Disk Directory) auf der Freeware-Disk, die zumindest bei meinem S3 Turbo mit dabei war. Bei Bedarf kann ich das Image zur Verfuegung stellen.

 

[DanReed]

Gute Arbeit! Ohne weiteres Feedback hatte ich schnell jeden Spaß verloren.

Zuletzt hatte ich meinen S2 auf 20MHz übertaktet, so daß mein Sampletakt statt mit 41.6kHz gegenwärtig mit 52.1kHz läuft, was bei einigen Multisamples erhebliche Brillanz bringt. Die Custom-Chips machen dabei überhaupt keine Probleme (aber es ist natürlich nicht problemlos). Jedenfalls erhöht sich damit die Spitzenleistung der Haupt-CPU von 4 auf 5 MIPS, was viel Raum für zusätzliche Modulationen und Updateraten ließe.

Außerdem hatte ich für die Hauptwandler Spindeltrimmer nachgerüstet, um das (zugegeben sehr leise) Aliasing noch weiter reduzieren zu können:

Falls jemand das auch machen möchte, hätte ich noch ein vollständiges Set aus vier Spindeltrimmern und 8 Metallfilm-Widerständen (das für mein Zweitgerät geplant war, welches ich aber leider nie fand). Aber Warnung: Es ist äußerst schwierig, die Trimmer bei laufendem Gerät zu justieren, und außerdem ist der erreichbare Erfolg sehr bescheiden.

Als ich damals herausfand, daß nur 14 Bit genutzt werden, war ich zunächst enttäuscht, aber bei 32 Oszillatoren braucht man für übersteuerungsfreie Addition 5 Bit Headroom und die Resonanzen der Filter brauchen weiteren Headroom, so daß tatsächlich nicht die Sampleauflösung, sondern die 18-Bit-Wandler das eigentliche Nadelöhr sind. Dewegen die Spindeltrimmer.


Hättest die ganzen Dumps von mir haben können.

Meine Fragen an Dich:
1) Hast Du auch das: "MIOS ready version 2.0 28.3.91 j/s new initialised!"?
2) Hast Du den "Sample Translator", der sich ja als Software nachladen läßt?
3) Schaltplan des Turbo-Boards fehlt auch immer noch.
4) Kannst Du .TD0-Dateien in sinnvolle Binaries umwandeln?
5) Kannst Du die Betriebssystem-Eproms brennen (27C4001D, 512MByte)?

Dann könnte man damit anfangen, den Inhalt zu modifizieren und wieder laufen zu lassen. z.B.:
a) Man müßte den schweren Bug in der Key-Oszillator-Zuordnung korrigieren, der bei Sounds mit vier Layern einzelne Layer einzelner Tasten ausschalten läßt (hatte ich schon im Eingangspost geschrieben).
b) Bei LFO und vielleicht auch bei Oszillatoren einen RESET- oder KEY TRIGGER-Schalter zum Abschalten hinzufügen, damit die Sounds lebendiger werden.
a) Ich glaube zu wissen, wo die 5 Velocity Curves gespeichert sind, von denen mir keine einzige paßt.

Hardwaremäßig könnte man vielleicht den Uhrenchip DS1202 durch einen DS1302 ersetzen und so das Problem der falschen Uhrzeit beseitigen.

Bitte stelle die Disk-Utilities zur Verfügung!

 

[microbug]

Die Images hätte ich auch gerne, obwohl ich derzeit keine GEM mehr habe, wohl aber noch Unterlagen und Disketten. Überlege mir aber schon länger, mir wieder zumindest eine S2 just for Fun hinzustellen.

 

[Sequialter]

Die Images hätte ich auch gerne, obwohl ich derzeit keine GEM mehr habe, wohl aber noch Unterlagen und Disketten. Überlege mir aber schon länger, mir wieder zumindest eine S2 just for Fun hinzustellen.

Ich besitze auch noch immer meine Gemsen ,S2 Turbo + S3 Turbo,allein das Spielgefühl mit dem polyphonen Aftertouch ist unübertroffen .....!

 

[jmech]

Wow, das ging aber flueggs!

Was die Images angeht, habe ich einen Haufen im Netz gefunden. Es gibt die (wie glaube ich vorher schon erwaehnt) einerseits im etwas unpraktischen Teledisk (TD0) Format, aber auf einem finnischen Server auch als RAW-Images, die sich z.B. mit dd (oder dem Tool s3floppy in meinem Repo) auf eine Floppy-Disk schreiben lassen. Ich habe mal einen GEM Dropbox-Ordner
Dropbox-Ordner angelegt.

Dort finden sich u.a. ein Image der Freeware-Disk, sowie ein Tiddly-Wiki mit allerlei Infos zu den Images und diverse Weblinks (html-Datei erst speichern, dann oeffnen).

@microbug: weisst Du zufaellig, welche Unterlagen sich genau in Deinem Fundus befinden?

@DanReed: das mit den Spindeltrimmern ist ja interessant, praktischerweise gabs dafuer ja schon Platz auf dem Board.
Und bzgl. der Dumps: damit hatte ich unabhaengig vom S3 angefangen, aber bin dadurch wieder darauf gekommen, mich wieder mehr mit dem Synth zu befassen. Also alles gut.

Zu Deinen Fragen:
1) Ja, ich habe die gleiche Version der ROMs (siehe auch Checksummen im s3sim Repository)
2) Der Sampletranslator ist bei mir durch Turbo schon onboard, aber ich glaube, dass auf dem finnischen Server mit den RAW-Images die Vorgaengerversion im Tools-Ordner mit dabei ist.
3) Habe ich leider nicht, nur die Installationsanleitung
4) Habe ich teilweise gemacht, war aber zum Glueck nicht immer notwendig. Die RAW-Images auf dem finnischen Server waren teilweise korrupt und ich habe dann versucht, meine eigenen Images von TD0 zu konvertieren. Das war aber ein ziemliches Gefrickel und hat nicht immer funktioniert. Ich wuerde ja gerne die Images sortieren und eine 'definitive Bibliothek' ins Netz stellen, aber aus rechtlichen Gruenden waere das ws. keine so tolle Idee (siehe auch letzter Absatz).
5) Ich habe keine Hardware zum Brennen von EPROMS; die Idee mit dem batteriegepufferten RAM + Arduino fand ich jedoch recht sexy. Es waere natuerlich supercool, wenn man einfach ein kleines uC-Board mit SD-Card-Reader einbauen koennte, ueber das man alle Diskimages + Custom-ROM ins Geraet bringen koennte. Zum Dumpen habe ich einen Teensy benutzt, der hat noch etwas mehr Power (und auch recht viele IO-Pins). Der kann uebrigens auch USB MIDI out-of-the-box.

Zu den Modding-Vorschlaegen:
Das sind alles sehr gute Punkte und wahrscheinlich wuerden mir auch noch ein paar Sachen einfallen (und wenn es nur um die Verbesserung der Oberflaeche geht), nur kann ich da ohne ein Dekompilat der ROMs nach C, oder zumindest eines wesentlich besseren Verstaendnisses des Assemblercodes nicht wirklich dazu beitragen. Ich habe in den Dropboxordner mal noch meine Disassemblies der ROMs gepackt, von denen ich noch nicht einmal sicher sagen kann, wie viel Sinn die machen. Ich komme eher aus der High-Level-Ecke und schaue mir nur alle Schaltjahre Binaercode an; daher bin ich leider noch etwas 'behindert', aber lernwillig.
Ich dachte erstmal daran, die existierenden Sysex-Funktionen im ROM zu finden, um die fehlende Dokumentation zu vervollstaendigen und hoffentlich auch eine Option zum Hochladen von Dateien ins S3-Filesystem zu finden. Dann waere man unabhaengig von den Floppy-Disks/Images.

Noch ein paar Fragen von mir:
1) Haben die Motorola-CPUs eigentlich irgendeine Debugging-Schnittstelle (z.B. JTAG)?
2) Hat sich schon mal jemand diese RS232-Schnittstelle angeschaut, die wird anscheinend auch von dem Turbo-Board benutzt, aber vielleicht geht da noch mehr?
3) Waere es moeglich, gemeinsam ein Dokument zu erstellen, in dem die bekannten funktionalen Teile des Program-ROMs aufgeschluesselt sind? Mein Versuch ist leider ziemlich schnell im Initialisierungscode versandet, das Dokument sollte eigentlich auch viel abstrakter sein.

Zum reversen allgemein:
Ich weiss nicht, ob es hier alle auf dem Radar haben, aber General Music ist ja vor ein paar Jahren bankrott gegangen, und die Ueberreste wurden von einem Finnen aufgekauft. Es gab von dem dann eine Indiegogo-Kampagne, um ELKA Synthex Synths aus NOS-Teilen zu bauen, die (nicht ganz ueberraschend) gescheitert ist. Jedenfalls sieht man ihn in dem Kampagnenvideo traurig durch eine grosse Lagerhalle laufen, in der allerlei Kisten mit GEM-Aufdruck herumstehen. Als mein S3 defekt war, hatte ich versucht, den zu kontaktieren, um vielleicht ein Austausch-Mainboard zu ergattern: leider erfolglos. Langer Rede, kurzer Sinn: ich habe mir die Frage gestellt, wie man mit den Intellectual Property-Aspekten beim Reversen des S3 umzugehen hat, da die Rechte mittlerweile wahrscheinlich diesem Finnen gehoeren. Im speziellen: was alles kann man im Netz veroeffentlichen, ohne sich juristisch angreifbar zu machen? Vielleicht hat da ja jemand gute Gedanken dazu.

 

[jmech]

2) Der Sampletranslator ist bei mir durch Turbo schon onboard, aber ich glaube, dass auf dem finnischen Server mit den RAW-Images die Vorgaengerversion im Tools-Ordner mit dabei ist.

Ich habe es gerade mal probiert: das richtige Image ist Tools and info/Sampletr.img und wie angedeutet die Version 1.0 des ST.

Der Inhalt sieht uebrigens so aus:

$ s3img read Sampletr.img 
--------------------------------------------------------------------------------
Volume: <empty>           11:16:16 26/10/1992 Filename: Sampletr.img
--------------------------------------------------------------------------------
      Name         Size     Time      Date    Att Cluster (hex)
--------------------------------------------------------------------------------
A:
  PROGRAM               0 11:16:50 26/10/1992  10       2 (0x2400)

A:\PROGRAM
  ST      PRG       61204 17:16:46 23/10/1992   0       3 (0x2800)
  ST      AUT       61204 17:16:46 23/10/1992   0      63 (0x11800)
  LOADER  LOD        2664 08:06:56 24/06/1992   0     123 (0x20800)

ST.PRG und ST.AUT sind uebrigens identisch, keine Ahnung, was das soll.

Das Freeware Image enthaelt:

--------------------------------------------------------------------------------
Volume: FREEWARE          16:39:58 27/08/1992 Filename: FreewareDisk.img
--------------------------------------------------------------------------------
      Name         Size     Time      Date    Att Cluster (hex)
--------------------------------------------------------------------------------
A:
  PROGRAM               0 16:56:42 27/08/1992  10       2 (0x2400)

A:\PROGRAM
  LOADER  LOD        2664 08:06:56 24/06/1992   0       3 (0x2800)
  HARDCPY PRG        9096 18:59:54 15/06/1992   0       6 (0x3400)
  DISK_DIRPRG       14200 01:16:38 19/06/1992   0      15 (0x5800)
  COPY_PRGPRG        9948 08:28:46 24/06/1992   0      29 (0x9000)

Meines Wissens sind das auch schon alle 'User Programs', die es gibt.

 

[microbug]

Meine Unterlagen sind nur der Schaltplan und zumindest das Layout des Turboboards.

Bei der Tastatur hab ich inzwischen rausgefunden, daß das die alte Version der Fatar TP/8S ist, allerdings nur die Mechanik, bei den Kontakten haben die einen Eigenbau druntergesetzt, der genauso aussieht wie bei den Elka Masterkeyboards (die ebenfalls von Jürgen Schmitz entwickelt wurden). Hab inzwischen zwei Keyboards mit dieser Tastatur hier, das Roland A-70 mußte für einen Umbau herhalten, habe dessen Tastatur in meinen 76er Kurzweil PC3 eingebaut (und das restliche A-70 noch über).

Herr Schmitz ist übrigens wieder aktiv, derzeit wohl für Korg Italy bei der PA-Serie, er hat die Bilder auch von der GEM auf seiner Facebookseite gezeigt.

Witzig, wenn ich die Endungen sehe, die komplette Firmware scheint auf einem Atari entwickelt worden zu sein, die Parallelen sind doch sehr deutlich, alleine bei den Icons war mir das schon aufgefallen.

 

[DanReed]

Hab gerade einen Blick auf das Disassemblat geworfen. Super! Es ist sehr wichtig, daß man dem Disassembler eine Steuerdatei geben kann, in der die Adressen von Datenblöcken stehen, damit die nicht zu etwas unleserlichem werden. (Schon der Bereich von $#000000 bis $#000100 ist ja ein Datensegment, nämlich außer SP und PC die Sprungadressen für die Traps).

Hast Du diese Möglichkeit?

Hast Du außerdem den entsprechenden Compiler, der aus der program.combined.1.dis wieder das Binary erzeugt, so daß die Checksumme stimmt, wenn man nichts ändert?

Was ich gerade gesehen habe, sieht ja schon sehr gut aus. Und dann würde man die Doku direkt in den Assemblercode mit Kommentaren realisieren, damit man nicht zwischen zwei Dateien hin- und herwechseln muß.


Debugging geht. Dazu gibt es Trace. Das wird durch einen Stop realisiert, wie er an Adresse §#100 steht. Ich vermute mal, daß man in den ja im MIOS eingebauten Tracer/Debugger kommt, wenn ein Trap ausgelöst wird (das was beim Atari Bomben schmiß), da alle Traps auf #$100 zeigen.

Spannend, aber ich verliere mich gerade in Details.

Ein guter Anfang wäre, den Sample-Translator zu disassemblieren, dann könnte man nämlich ein eigenes Helper-Programm einschleusen.

Ich sehe das mit dem Copyright auch eher eng und respektiere die Rechte anderer. Daher würde ich z.B. keine Sounddateien öffentlich zum Download anbieten, die aus einem Synthesizer oder seiner Libary kommen.

 

[DanReed]

Ich denke program.combined.2.dis ist ein komplettes Datensegment mit den Sounds. Wir haben es für die Doku also erstmal "nur" mit 1MByte zu tun, das zudem am Ende mit FF gefüllt ist (hat man bei Eproms immer gemacht, da das Brennen dann schneller ging) und viele Datentabellen und Strings enthält.

Aber vor dem ersten Schritt sollte das fehlerfreie Assemblieren des Disassemblats sichergestellt und die Syntax noch auf einen konfortablen Stand angehoben werden (könnte ich auch machen, aber Du hast mit dem Source des Disassemblers viel mehr Erfahrung, da Du ihn offenbar schon debugged hast). Meine Vorschläge hierzu:

1) Alle "<rom+0x...>" weg (wenigstens als Option)
2) Tabulatoren mit ausgeben: Alle Adressen gerne als Labels (kleines "l", dann hexadezimal und sechsstellig, also sieben Zeichen), dann Doppelpunkt, kein Space, sondern dann direkt der Befehl, so daß eine Zeile ohne Label (was bald der Defaultfall sein wird, wenn alle Datensegmente markiert sind, und dann alle Adressen, auf die nicht referiert wird, automatisch gelöscht werden können) mit einem 8-Zeichen-Tab beginnt und beim Assemblerbefehl-Beginn bündig wird. Nach dem Befehl wieder Tab, dann erst die Datenregister/Adressierung. Dann zwei Tabs das Kommentarzeichen ";" und der Hexcode (den man ja nur braucht, wenn man Zweifel am Disassemblat hat). Dahinter der eigene Kommentar in eine Zeile (vielleicht abgetrennt mit einem zweiten ";", damit man später den Hexcode automatisch löschen kann).
3) Hinter Assemblerbefehlen wurde die Wortgröße nicht direkt, sondern durch einen Punkt abgetrennt angegeben: Z.B. "movel" wird zu "move.l", erhöht die Lesbarkeit um Welten.
4) d0-7, a0-7, pc, usp(/ssp), sr und ccr sind 68000er Schlüsselwörter und brauchen kein vorangestelltes "%" (erhöht die Lesbarkeit ungemein)
5) nicht "fp" statt "a6" schreiben (Relikt?!)
6) Bei den Adressierungsarten hat Motorola eine wunderschöne Syntax, ohne die der Code jetzt nur schwer zu lesen ist:
z.B. "(a0)+" statt "%a0@+", "offset(a0)" statt "%a4@(offset)", "$bb(a5,a1.l)" oder besser "-85(a5,a1.l)" statt "%a5@(ffffffffffffffbb,%a1:l:4)", ...
7) Hexadezimalzahlen immer mit "$"-Präfix (denn Biärzahlen bekommen Präfix "%" und Dezimalzahlen haben kein Präfix; Konstanten haben zusätzlich "#", aber das ist ja schon realisiert)

Man könnte hier natürlich z.B. mit Perl einen Postprozessor schreiben ...


PS.: Woher ich weiß, daß es einen eingebauten Debugger gibt? Bei meinen Ausflügen hatte ich folgendes gefunden. Am Schluß kann man an Jürgen Schmitz' Humor teilhaben. Er hat das MIOS (=Musical Instrument Operating System) übrigens mit 38 Jahren (weitgehend?) in C auf einem von ihm gebauten Entwicklerboard mit einer Alpha Version des 68302 von Motorola programmiert:

DEBUG__
(T)race    
(B)reak    
(G)o       
           
(R)egs.    
(W)atch    
R(e)start  
^(S)tep     
(D)ump     
...
 Dis. ? (y/n) 
Watch     ->  
Invalid address.
Watchpoint already exists. Rebuild ? (y/n) 
(PC)
(PC,
dc.w
movep
...
1|ERROR|Test Text Fehler        ja sowas!|nix||ojeh||weiter
2|WARNING|Test Text Warnung     ja so ein Mist!||nix|ojeh|weiter|
3|DIALOG|Test Text Dialog       porca vacca, caro Lei!|nix||||weiter
4|FATAL ERROR|hi hi hi hi !?!?  porca vacca, caro Lei!|nix||||weiter

 

[DanReed]

PPS.: Schöne Beispiele, wie der Code aussehen könnte, sind auch hier: https://en.wikipedia.org/wiki/Motorola_68000

Ich empfehle übrigens das Buch "Programmierung des 68000" (C. Vieillefond, Sybex.Verlag). Gibts wohl nur noch auf dem Flohmarkt

 

[swissdoc]

Der Thread ist damals an mir vorbeigegangen, allerdings kann ich ausser Interesse und mentalem Support eh nicht viel beitragen.

Ich verstehe den Unterschied zwischen TD0 und Image Format nicht ganz. Man braucht ja jeweils ein passendes Floppy-Laufwerk am PC um das schreiben zu können. Ich habe mal ein paar Disks bei http://www.deepsonic.ch gefunden, alles in 4 Zip-Archiven im IMG Format, welches ich mit Omniflop auf Disks schreiben konnte. Oder ist die Konvertierung von TD0 nach Image schwierig und nur einem Legacy Program vorbehalten? Eine Analyse des Formates ist doch bei beiden eher hässlich, oder nicht?

Was den Trimmer am DAC betrifft, so schaue man im Datenblatt nach. Mit dem MSB Trim kann man die THD+N Verzerrung minimieren, mit Aliasing hat das nichts zu tun. Dazu müsste man ja entweder den Sample Content ändern (so könnte man Aliasing von der Aufnahme begegnen) oder man müsste die Sample-Rate ändern bzw. das Rekonstruktionsfilter.

Im Datenblatt ist übrigens eine Application Note enthalten für einen Musik-Synthesizer mit 6 Ausgängen, evtl. hat GEM genau dieses Konzept verwendet...
http://www.analog.com/media/en/technica ... ad1865.pdf

 

[jmech]

Ich verstehe den Unterschied zwischen TD0 und Image Format nicht ganz. Man braucht ja jeweils ein passendes Floppy-Laufwerk am PC um das schreiben zu können. Ich habe mal ein paar Disks bei http://www.deepsonic.ch gefunden, alles in 4 Zip-Archiven im IMG Format, welches ich mit Omniflop auf Disks schreiben konnte. Oder ist die Konvertierung von TD0 nach Image schwierig und nur einem Legacy Program vorbehalten? Eine Analyse des Formates ist doch bei beiden eher hässlich, oder nicht?

Das IMG-"Format" ist eigentlich nichts anderes, als der sequentielle Inhalt z.B. der Floppy Disk in Bytes. Insofern ist das eigentlich die native Form der Daten (zumindest meiner Meinung nach). Allerdings enthaelt dieses Image keinerlei Information, wie die Daten auf dem Datentraeger gespeichert waren. Wenn man so ein Image wieder auf eine Diskette schreiben moechte, muss man dem Laufwerkstreiber vorher manuell sagen, wie er das tun soll.

Man kann sich jetzt auch komplexere Imageformate ausdenken, in denen diese Information mitgespeichert wird, vielleicht noch irgendwelche Checksummen fuer Daten einzelner Spuren auf der Diskette etc. Dazu gehoert z.B. das Teledisk-Format. Als ich vor ein paar Monaten mit den Images rumhantiert habe, bin ich auf ein Windows-Tool mit Sourcecode gestossen, dass ich dann nach Linux portiert habe. Auf der Github-Seite sind die Links zum Original, da wird das etwas detaillierter erklaert.

Man braucht uebrigens kein dediziertes Laufwerk fuer die verschiedenen Formate, nur eine Software, die das Laufwerk entsprechend konfiguriert, die Diskette vorher vielleicht noch formatiert und dann die Daten uebertraegt. Es kann natuerlich sein, dass manche Laufwerke da nicht so gut mitspielen. Ich habe bei mir eins aus meinem ersten PC (486 DX 33) eingebaut, das laeuft noch wie ne Eins...

 

[jmech]

Ich denke program.combined.2.dis ist ein komplettes Datensegment mit den Sounds. Wir haben es für die Doku also erstmal "nur" mit 1MByte zu tun, das zudem am Ende mit FF gefüllt ist (hat man bei Eproms immer gemacht, da das Brennen dann schneller ging) und viele Datentabellen und Strings enthält.

Das war auch zunaechst meine Vermutung, aber ich bin mir mittlerweile nicht mehr so sicher, ob zwischendrin nicht auch noch Code haengt. Urspruenglich dachte ich, dass in ROM 3 und 4 nur die 100 Presets liegen, die mit der Turboversion hinzukamen (wenn ich mich da nicht vertue).

Aber vor dem ersten Schritt sollte das fehlerfreie Assemblieren des Disassemblats sichergestellt und die Syntax noch auf einen konfortablen Stand angehoben werden (könnte ich auch machen, aber Du hast mit dem Source des Disassemblers viel mehr Erfahrung, da Du ihn offenbar schon debugged hast). Meine Vorschläge hierzu:

1) Alle "<rom+0x...>" weg (wenigstens als Option)
2) Tabulatoren mit ausgeben: Alle Adressen gerne als Labels (kleines "l", dann hexadezimal und sechsstellig, also sieben Zeichen), dann Doppelpunkt, kein Space, sondern dann direkt der Befehl, so daß eine Zeile ohne Label (was bald der Defaultfall sein wird, wenn alle Datensegmente markiert sind, und dann alle Adressen, auf die nicht referiert wird, automatisch gelöscht werden können) mit einem 8-Zeichen-Tab beginnt und beim Assemblerbefehl-Beginn bündig wird. Nach dem Befehl wieder Tab, dann erst die Datenregister/Adressierung. Dann zwei Tabs das Kommentarzeichen ";" und der Hexcode (den man ja nur braucht, wenn man Zweifel am Disassemblat hat). Dahinter der eigene Kommentar in eine Zeile (vielleicht abgetrennt mit einem zweiten ";", damit man später den Hexcode automatisch löschen kann).
3) Hinter Assemblerbefehlen wurde die Wortgröße nicht direkt, sondern durch einen Punkt abgetrennt angegeben: Z.B. "movel" wird zu "move.l", erhöht die Lesbarkeit um Welten.
4) d0-7, a0-7, pc, usp(/ssp), sr und ccr sind 68000er Schlüsselwörter und brauchen kein vorangestelltes "%" (erhöht die Lesbarkeit ungemein)
5) nicht "fp" statt "a6" schreiben (Relikt?!)
6) Bei den Adressierungsarten hat Motorola eine wunderschöne Syntax, ohne die der Code jetzt nur schwer zu lesen ist:
z.B. "(a0)+" statt "%a0@+", "offset(a0)" statt "%a4@(offset)", "$bb(a5,a1.l)" oder besser "-85(a5,a1.l)" statt "%a5@(ffffffffffffffbb,%a1:l:4)", ...
7) Hexadezimalzahlen immer mit "$"-Präfix (denn Biärzahlen bekommen Präfix "%" und Dezimalzahlen haben kein Präfix; Konstanten haben zusätzlich "#", aber das ist ja schon realisiert)

Der "Disassembler" ist eigentlich gar keiner. Ich habe mir aus einem Posting im Netz abgeschaut, ein Motorola ROM-Image mit den GNU binutils erst mit objcopy in ein ELF-Image zu konvertieren und dann mit objdump zu disassemblieren. Auf diesem Weg kann man noch den Codeoffset aendern, Symbole hinzufuegen/entfernen, etc. Bei einem ROM-Image ohne Symbole und Segmentinformation passiert da natuerlich nicht viel. Zudem hat man bei der Ausgabe nur die Wahl zwischen AT&T und Intel Syntax. Die Motorola-Syntax, die Du vermutlich meinst wird von GNU nicht unterstuetzt, und bei dem GNU Assembler bin ich mir nicht so sicher. Ich kann jedenfalls jetzt schon bestaetigen, dass ich die Ausgabe von objdump mit m68k-linux-gnu-as und objcopy zumindest prinzipiell wieder in ein Image umwandeln kann.

Mittlerweile bin ich jedoch soweit, einen Custom-Disassembler zu schreiben, da sich im ROM Code- und Datensegmente munter abwechseln und man fuer den oben dargelegten Weg das ROM skript-gesteuert aufteilen, separat disassemblieren, etc muesste. Es gibt da zum Glueck Capstone mit verschiedenen Bindings (C,Python,...), das seit ein paar Monaten auch m68k Unterstuetzung mitbringt. Damit habe ich in Python angefangen, einen Disassembler zu schreiben, und das funktioniert soweit auch gut. Ich werde das demnaechst mal hochladen und hier Bescheid sagen. Soweit ich das sehen kann, kriegt man davon auch automatisch die Motorola-Mnemonics. Man braeuchte dann nur auch wieder einen Assembler, der das versteht. Wenn die Sache mal grundsaetzlich laeuft, werde ich mich um die einzelnen Punkte von Dir kuemmern.

Falls Du da bessere Ideen hast, bin ich natuerlich offen. Die Pro-Variante ist wohl, IDA Pro zu nehmen. Damit kann man interaktiv disassemblieren, aber die Freeware-Variante unterstuetzt den m68k nicht, und die Standardvariante kostet 500 Dollar/Euro.

PS.: Woher ich weiß, daß es einen eingebauten Debugger gibt? Bei meinen Ausflügen hatte ich folgendes gefunden. Am Schluß kann man an Jürgen Schmitz' Humor teilhaben. Er hat das MIOS (=Musical Instrument Operating System) übrigens mit 38 Jahren (weitgehend?) in C auf einem von ihm gebauten Entwicklerboard mit einer Alpha Version des 68302 von Motorola programmiert:

DEBUG__
(T)race    
(B)reak    
(G)o       
           
(R)egs.    
(W)atch    
R(e)start  
^(S)tep     
(D)ump     
...
 Dis. ? (y/n) 
Watch     ->  
Invalid address.
Watchpoint already exists. Rebuild ? (y/n) 
(PC)
(PC,
dc.w
movep
...
1|ERROR|Test Text Fehler        ja sowas!|nix||ojeh||weiter
2|WARNING|Test Text Warnung     ja so ein Mist!||nix|ojeh|weiter|
3|DIALOG|Test Text Dialog       porca vacca, caro Lei!|nix||||weiter
4|FATAL ERROR|hi hi hi hi !?!?  porca vacca, caro Lei!|nix||||weiter

Ja, das habe ich auch gesehen, allerdings keine Ahnung, wie man den triggern koennte (daher meine Frage nach der RS232-Schnittstelle). Ich hab es nur mal zufaellig geschafft, einen Memorydump ueber Sysex auszuloesen, kann es aber mittlerweile nicht mehr reproduzieren.

 

[DanReed]

Urspruenglich dachte ich, dass in ROM 3 und 4 nur die 100 Presets liegen, die mit der Turboversion hinzukamen (wenn ich mich da nicht vertue).

Ich vermute, daß alle (350?) Presets aus den zwei Vor-Turbo ROMs ins dritte und vierte ROM gewandert sind, weil z.B. für den Sample Translator mehr ROM gebraucht wurde. Jetzt hat der GEM S2/3 ja 500 Presets. Aber vielleicht ist da wirklich noch anderes ... Egal, das erste MB ist genug Arbeit und man wird ja sehen, ob es ins zweite MB geht.

Der "Disassembler" ist eigentlich gar keiner. [...]

Ich hab bisher noch nichts installiert, nur die Sourcen überflogen. Aber die Story klingt halsbrecherisch

Falls Du da bessere Ideen hast [...]

Nö, bin ja fast zufrieden bis auf meine Anmerkungen. Wie gesagt, ein Postprozessor in Perl (oder einer ähnlich mächtigen String-Verarbeitungssprache) könnte es vermutlich richten. Vielleicht sogar das Abarbeiten einer Tabelle, die sagt, welche Codes in dc.b, dc.w und dc.l umgewandelt werden sollen (denn ds.b, ds.w oder ds.l sind im ROM irgendwie sinnlos und Wechsel zwischen TEXT und DATA/BSS werden dem Programmierstil wohl nicht gerecht).

Problem dieser Lösung dürfte sein, daß ein Disassembler aus dem Tritt kommen kann, wenn er dc-Bereiche übersetzt, so daß man ihn zu einem Neuansatz zwingen müßte, dann aber alle Adressen korrigieren.

Also, Postprozessor ist nicht einfach ...

keine Ahnung, wie man den [Debugger] triggern koennte

z.B. indem man einen NMI auslöst (etwa mit einem Taster an den entsprechenden CPU-Beinen)

Der Thread ist damals an mir vorbeigegangen

Aber jetzt bist Du ja da

MSB Trim kann man die THD+N Verzerrung

Ist mir schon klar (war Tippfehler), die Dimensionen der Trimmers und der Widerstände hatte ich natürlich aus dem Datenblatt des Wandlers. Möchte mich hier nicht profilieren müssen (aber ganz genau ist es Centerclipping). Und Du brauchst es auch nicht, hatte Dich schon längst als höchst kompetenten Schaltplanleser eingestuft.

Hatte auch irgendwo "Compiler" geschrieben, wo "Assembler" stehen mußte. Laßt uns fehlertoleranter sein, wer bis hier alles verstanden hat, ist absoluter Experte.

Wäre klasse, wenn wir Dich als Eagle-Experten befragen könnten, denn das Turbo-Board durch ein Arduino/Teensy-Board mit batteriegepufferten z.B. 8MB SRAM RAM (2 als ROM-Ersatz, 2 als Ersatz für die auch jetzt schon vorhandene RAM-Disk und 4 als zukünftige RAM-Disk-Erweiterung ) und ein paar Bus-Treibern zu ersetzen, wäre natürlich für die Entwicklung der absolute Hit. Fünf Stück könnte man sicher gebrauchen, denn es könnte noch Zuwachs geben, wenn man in einschlägigen englischsprachigen Foren sucht.

 

[DanReed]

PS.: Vielleicht ist es das beste, mit dem Disassemblieren beim Hardcopy-Binary der Diskette zu beginnen. Es ist extrem klein und erlaubt uns vielleicht, das Prinzip zu durchschauen und einen "Virus" zu programmieren ...

Ich glaube, so ist tatsächlich der schnellstmögliche Soforterfolg drin (das ist ganz heißer Shice)

Beispielsweise könnte man von dort aus Unterroutinen des ROMs aufrufen, ein eigenen Mini-Kernel laufen lassen, den ganzen Synth zum Sklaven machen ...

 

[virtualant]

nicht schlecht, ich versteh nur Bahnhof

Wäre klasse, wenn wir Dich als Eagle-Experten befragen könnten, denn das Turbo-Board durch ein Arduino/Teensy-Board mit batteriegepufferten z.B. 8MB SRAM RAM (2 als ROM-Ersatz, 2 als Ersatz für die auch jetzt schon vorhandene RAM-Disk und 4 als zukünftige RAM-Disk-Erweiterung ) und ein paar Bus-Treibern zu ersetzen, wäre natürlich für die Entwicklung der absolute Hit. Fünf Stück könnte man sicher gebrauchen, denn es könnte noch Zuwachs geben, wenn man in einschlägigen englischsprachigen Foren sucht.

was habt ihr vor? einen 8MB chip entwicklen mit mehr Speicherplatz für samples und sounds? Daran hätte ich auch Interesse. Hab ja noch meine gute S3 Turbo als Masterkeyboard.

 

[swissdoc]

Das IMG-"Format" ist eigentlich nichts anderes, als der sequentielle Inhalt z.B. der Floppy Disk in Bytes. Insofern ist das eigentlich die native Form der Daten (zumindest meiner Meinung nach). Allerdings enthaelt dieses Image keinerlei Information, wie die Daten auf dem Datentraeger gespeichert waren. Wenn man so ein Image wieder auf eine Diskette schreiben moechte, muss man dem Laufwerkstreiber vorher manuell sagen, wie er das tun soll.

Klar, wenn man z.B. mit Omniflop schreibt, so muss man den Treiber genau angeben.

Man kann sich jetzt auch komplexere Imageformate ausdenken, in denen diese Information mitgespeichert wird, vielleicht noch irgendwelche Checksummen fuer Daten einzelner Spuren auf der Diskette etc. Dazu gehoert z.B. das Teledisk-Format. Als ich vor ein paar Monaten mit den Images rumhantiert habe, bin ich auf ein Windows-Tool mit Sourcecode gestossen, dass ich dann nach Linux portiert habe. Auf der Github-Seite sind die Links zum Original, da wird das etwas detaillierter erklaert.

Danke für die Info, das mit TD0 -> Teledisk-Format hatte ich noch nicht realisiert. Aber da ich ja schon ausreichend IMG Files hatte, war das auch nicht weiter wichtig. HxC nutzt sicher so ein komplexeres Imageformat.

Man braucht uebrigens kein dediziertes Laufwerk fuer die verschiedenen Formate, nur eine Software, die das Laufwerk entsprechend konfiguriert, die Diskette vorher vielleicht noch formatiert und dann die Daten uebertraegt. Es kann natuerlich sein, dass manche Laufwerke da nicht so gut mitspielen. Ich habe bei mir eins aus meinem ersten PC (486 DX 33) eingebaut, das laeuft noch wie ne Eins...

Nun, entscheidend ist hier das Vorhandensein eines echten Floppy Controllers, der dann das Drive steuert. Bei den Drives gibt es auch Unterschiede. Nicht alle können alles. Beim Casio FZ1 Format scheitern die meisten PCs, aber es geht, wenn man denn das richtige Laufwerk hat. Das bezieht sich auf die Nutzung im PC mit Omniflop etc. Im S3 weiss ich es nicht, wenn ich Dich richtig verstehe, so ist der S3 da nicht so wählerisch.

 

[jmech]

Im S3 weiss ich es nicht, wenn ich Dich richtig verstehe, so ist der S3 da nicht so wählerisch.

Meines Wissens ist das ein ganz normales PC-Laufwerk. Um auf die S3-Disketten zugreifen zu koennen, muss man den Controller im PC auf 10 Sektoren, 80 Cylinder und eine Sektorengroesse von 1kB stellen, Das ergibt dann die 2 * (10*80*1024) = 1638400 bytes, die auf die S3-Disks passen (der Faktor von 2 sind ws. die zwei Seiten der Disk). Ohne es genau zu wissen, schaetze ich mal, dass 1,44MB Standard-Floppies mit 72 Cylindern konfiguriert sind.