Modifikation GEM/generalmusic S2/S3/S2R turbo Modifikationen

[microbug]

Das ist auch ein ganz normales HD-Floppylaufwerk, genau wie der Controller auch ein Standardbauteil ist, mit denen kann man aber trotzdem andere Formate kreieren, wie man ja am Beispiel des Kawai Q-80 oder der Ensoniq-Synths sehen kann.
Solche erweiterten Formate gabs schon zu Atari-Zeiten, da haben aber nicht alle Laufwerke das mitgemacht, weil die meisten erweiterten Formate noch auf DD basierten und HD erst mit den Falcon und TOS 3.06 Einzug hielt, auf den STE-Modellen aber offiziell nachgerüstet werden konnte.
Das Grundformat ist bei allen das Gleiche und geht auf eine alte IBM zurück, darauf wird auch in allen Datenblättern von Floppycontrollern zurückgegriffen.

Ich empfehle für 68k Assembler die Bücher von Günter Schmitt aus dem Verlag Oldenbourg, der hatte auch vorher welche zum Thema 6802/6809 und zuletzt zum Thema AVR geschrieben. Vorteil dieser Bücher ist, daß da auch Hardwaresteuerungen im Detail besprochen werden.

Was mich ja mal interessieren würde: der interne Uhrenchip hat eine Jahresgrenze, geht glaubich nur bis 2012, und ich frage mich, ob das vom Chip kommt oder von der Firmware, und ob man da einen neueren Chip nutzen könnte, falls es von diesem kommt.

Außerdem wäre es interessant zu sehen, wie der Port auf dem Turboboard zu nutzen wäre, der meines Wissens für SCSI vorgesehen war - und ob es da bereits Ansteuerungen für einen SCSI-Chip gibt. Beim Chip würde ich auf den üblichen 5380 tippen, der meines Wissens auch im Nachfolger Equinox eingesetzt wurde - da müßte ich die Unterlagen hier haben.

 

[jmech]

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 ...

Da stimme ich Dir absolut zu, und das war auch mein erster Gedanke. Ich bin mir noch nicht sicher, wo die Instruktionen anfangen.
Hier mal die ersten paar Bytes von dem HARDCPY-Programm:

00000000  01 01 01 0b 02 01 00 00  00 00 00 00 08 de 00 00  |................|
00000010  23 40 70 00 4e 40 70 01  4e 40 70 02 4e 40 70 03  |#@p.N@p.N@p.N@p.|
00000020  4e 40 70 05 4e 40 70 06  4e 40 70 07 4e 40 70 08  |N@p.N@p.N@p.N@p.|
00000030  4e 40 70 09 4e 40 70 0a  4e 40 70 0b 4e 40 70 0c  |N@p.N@p.N@p.N@p.|
00000040  4e 40 70 0d 4e 40 70 0e  4e 40 70 0f 4e 40 70 10  |N@p.N@p.N@p.N@p.|
00000050  4e 40 70 14 4e 40 70 15  4e 40 70 16 4e 40 70 18  |N@p.N@p.N@p.N@p.|
00000060  4e 40 70 19 4e 40 70 00  4e 75 70 00 4e 41 70 01  |N@p.N@p.Nup.NAp.|
00000070  4e 41 70 02 4e 41 70 03  4e 41 70 04 4e 41 70 00  |NAp.NAp.NAp.NAp.|
00000080  4e 42 70 01 4e 42 70 02  4e 42 70 03 4e 42 70 04  |NBp.NBp.NBp.NBp.|
00000090  4e 42 70 05 4e 42 70 06  4e 42 70 07 4e 42 70 00  |NBp.NBp.NBp.NBp.|

Die ersten sechs Bytes sind allen PRG-Files gemein und werden vom UNIX file-Kommando als
Signatur fuer 'a.out SunOS mc68010 demand paged executable not stripped' interpretiert. Entweder ist das Zufall, oder das Format ist tatsaechlich eine Abwandlung einer 68xxx binary. Vielleicht koennen dazu Leute mit Atari-Erfahrung mehr sagen. Danach kommen eine Reihe NULL-Bytes und ab Offset 0x11 eine repetitive Struktur, die ich so auch in den anderen PRG-Files auf der Freeware-Disk gesehen habe. Der Sampletranslator sieht allerdings da wiederum ganz anders aus.

Es gibt auf allen Disketten mit Programmen noch den Loader LOADER.LOD, vielleicht muesste man zuerst den verstehen.

 

[jmech]

Den Disassembler-Code habe ich jetzt mal in ein Github-Repo gesteckt: https://github.com/jmechnich/s3asm

In der README-Datei ist eigentlich schon das wichtigste erklaert. Mit einer Steuerdatei (i.e. control.txt) kann man den Disassembler fuer die Datensegmente abschalten und dem Segment einen Namen geben, der als Kommentar in den Output eingefuegt wird. Jetzt muesste man das ROM von vorne bis hinten durchgehen und die Datensegmente rausfinden.

Beim Assemblieren gibt es noch Probleme mit beiden Assemblern, die ich probiert habe. Grundsaetzlich verstehen sie die Syntax, nur manchmal sind sie mit einzelnen Instruktionen unzufrieden. Ich hoffe, dass das an Spezialfaellen liegt, die man manuell im Assemblercode aendern muss (oder vielleicht passiert das auch an Stellen, die eigentlich Daten sind, aber vom Disassembler trotzdem irgendwie in Assemblerinstruktionen umgewandelt wurden).

An einer Stelle habe ich zum Beispiel so etwas:

vasm:
fatal error 2035 in line 433 of "program.asm": illegal opcode extension
>	btst.b #$4,d2              	; 0x6d6

asmx:
program.asm:433: *** Error:  Illegal addressing mode ***
0006D4                  	btst.b #$4,d2              	; 0x6d6

Immerhin sind sich schon einmal beide Assembler einig. btst.b wird an anderer Stelle akzeptiert, deshalb gehe ich davon aus, dass das Problem das d2-Register ist. Der Original-Code ist uebrigens 0802 0004.

Falls sich damit noch jemand die Zeit vertreiben moechte, aber das ROM-Image nicht hat, kann ich das gerne auch noch irgendwo hinlegen und den Link (vielleicht per PM) verschicken.

@DanReed:
Der Codingstyle sieht jetzt so aus (die TABs werden hier allerdings nicht authentisch wiedergegeben):

...
	dc.l $100                	; 0xf4
	dc.l $100                	; 0xf8
	dc.l $100                	; 0xfc
;
; code
	stop #$2700              	; 0x100
	move.w #$afff,$f2.w        	; 0x104
	move.b #$0,$f5.w           	; 0x10a
	move.w #$3e00,$fff836.l    	; 0x110
	move.w #$401,$fff834.l     	; 0x118
	move.w #$3e02,$fff832.l    	; 0x120
	move.w #$ff,d0             	; 0x128
	lea.l $200000.l,a0        	; 0x12c
lab_0	move.l #$400100,(a0)+      	; 0x132
	dbra d0,lab_0            	; 0x138
	move.w #$e,d0              	; 0x13c
	lea.l $fff000.l,a0        	; 0x140
	lea.l $158.l,a1           	; 0x146
lab_1	move.w (a1)+,(a0)+         	; 0x14c
	dbra d0,lab_1            	; 0x14e
	jmp $fff000.l           	; 0x152
	move.w #$1,$fff834.l       	; 0x158
	move.w #$3c00,$fff836.l    	; 0x160
	move.w #$801,$fff830.l     	; 0x168
	jmp $400176.l           	; 0x170
lab_64	moveq #$0,d1              	; 0x176
	bra.b lab_2               	; 0x178
	dc.w $46fc               	; 0x17a
...

 

[DanReed]

btst.b #$4,d2

btst.b wird an anderer Stelle akzeptiert, deshalb gehe ich davon aus, dass das Problem das d2-Register ist. Der Original-Code ist uebrigens 0802 0004.

Könnte mir vorstellen, daß hier einfach keine hexadezimale Angabe für die Bitnummer erlaubt ist, da ja nur die Zahlen 0 bis 31 möglich sind. Dann müßte der Disassembler bei btst eine unmittelbar angegebene Bitnummer dezimal ausgeben:
btst.b #4,d2

Der Codingstyle sieht jetzt so aus [...]

Wow! Du bist schnell! Sieht schon sehr gut aus.

Ich will nicht undankbar erscheinen, aber frei raus, ich hätte da jetzt schon zwei Kleinigkeiten:
1) die Original-HEX-Codes hinter den Adressen wären einfach sehr hilfreich, meinetwegen in Klammern
2) Bei der Adressierung "absolut kurz" ist ".w" üblich, aber bei "absolut lang" wird ".l" grundsätzlich weggelassen

Wäre es zuviel verlangt, die Datei program.combined.1.dis bei Gelegenheit upzudaten? Das sieht nämlich schon sehr lesbar aus.

Es gibt auf allen Disketten mit Programmen noch den Loader LOADER.LOD, vielleicht muesste man zuerst den verstehen.

Ja, das denke ich auch. Ich hatte übrigens oben schon anekdotisch angedeutet, daß der S2/3 nichts mit dem Atari zu tun hat. Und das Binary deutet nun sogar klar darauf hin, daß die Software auf einer Sun compiliert wurde. Das hatte mir Jürgen Schmitz nicht erzählt, sonst hätte ich es natürlich weitergegeben.

 

[jmech]

Könnte mir vorstellen, daß hier einfach keine hexadezimale Angabe für die Bitnummer erlaubt ist, da ja nur die Zahlen 0 bis 31 möglich sind. Dann müßte der Disassembler bei btst eine unmittelbar angegebene Bitnummer dezimal ausgeben:
btst.b #4,d2

Nope, das ist es nicht. btst.l #$4,d2 geht, aber es kommt dann eben 08 02 00 04 raus.

Ich will nicht undankbar erscheinen, aber frei raus, ich hätte da jetzt schon zwei Kleinigkeiten:
1) die Original-HEX-Codes hinter den Adressen wären einfach sehr hilfreich, meinetwegen in Klammern
2) Bei der Adressierung "absolut kurz" ist ".w" üblich, aber bei "absolut lang" wird ".l" grundsätzlich weggelassen

Wäre es zuviel verlangt, die Datei program.combined.1.dis bei Gelegenheit upzudaten? Das sieht nämlich schon sehr lesbar aus.

Klar, kein Problem. Wie gesagt benutze ich dieses capstone-Framework, das macht eigentlich die Hauptarbeit und man muss nur noch etwas am Output tunen. Ich werde mal schauen, ob ich das komplette ROM damit updaten kann, denn momentan hoert der Disassembler auf, wenn er nichts mehr versteht (damit man die Datensegmente einfacher finden kann).

 

[jmech]

Wäre es zuviel verlangt, die Datei program.combined.1.dis bei Gelegenheit upzudaten? Das sieht nämlich schon sehr lesbar aus.

In dem Dropbox-Verzeichnis gibt es jetzt eine neue Datei, program.asm.gz.

 

[DanReed]

Könnte mir vorstellen, daß hier einfach keine hexadezimale Angabe für die Bitnummer erlaubt ist, da ja nur die Zahlen 0 bis 31 möglich sind. Dann müßte der Disassembler bei btst eine unmittelbar angegebene Bitnummer dezimal ausgeben:
btst.b #4,d2

Nope, das ist es nicht. btst.l #$4,d2 geht, aber es kommt dann eben 08 02 00 04 raus.

Ahh! Der Fehler ist, daß btst mit Datenregister als Ziel immer .l ist, also immer alle 32 Bit ansprechen kann, während Speicheradressen als Ziel immer .b sind, d.h. es lassen sich nur die 8 Bit der Zelle testen. btst mit Datenregister als Ziel und 8 Bit geht einfach nicht.

Weil die Operandenbreite implizit schon im Befehl (eben durch das Ziel) enthalten ist, wird grundsätzlich ".b" oder ".l" weggelassen.

Gilt so übrigens auch für bclr, bset und bchg.

 

[DanReed]

Ich hab mir die neue program.asm angesehen und schon ein bischen editiert (siehe Anhang unten).

Dabei sind mir noch folgende Kleinigkeiten aufgefallen:
1) lea.l -> lea (da immer .l)
2) dbra -> dbf (wobei dbra von den meisten Assemblern auch akzeptiert wird und meinetwegen auch ok ist)
3) Alle Adressen/Hexadezimalwerte in Kommentaren vielleicht immer mit Präfix "$" und nie "0x" (C-Syntax vermeiden, auch wenn's zunächst schwer fällt)

Und ich habe schon ein paar kleine Konventionen eingeführt (gerne änderbar):
1) "JM:" bist Du, "DR:" bin ich (so kann man leicht suchen)
2) "@JM:" oder "@DR:" jemand hat eine Frage an den anderen
3) "*JM:" oder "*DR:" am Zeilenanfang: Der folgende Instruktionsblock wird erklärt

*DR:	Some hardware register

*	MC68302 IMP Configuration Control
*	For details see e.g. http://www.manualslib.com/manual/596278/Motorola-Mc68302.html?page=42

cpu_bar		equ	$0f2		; peripheral base address register (BAR)
cpu_scr		equ	$0f4		; system control register (SCR)
*...

*DR:	@JM: Doku?
*BR0	equ	$fff830	; ROM base address
*BR1	equ	$fff834	; RAM base address
*OR0	equ	$fff832	;
*OR1	equ	$fff836	;


		TEXT

*JM:	Initialize stack pointer with $fff200 and program counter (i.e. where the very first instruction is executed)

          	dc.l	$fff200             	; 0x0  (00 ff f2 00) 
          	dc.l	start                	; 0x4  (00 00 01 04) 

*DR:	All exeption vectors and traps point to an initial stop instruction (which activates the Trace mode and then restarts the ROM)

          	dc.l	traps                	; 0x8  (00 00 01 00) 
          	dc.l	traps                	; 0xc  (00 00 01 00) 

*Eine Menge Zeilen hab ich der Übersichtlichkeit halber gelöscht, man sollte für diesen gesamten Block nämlich folgendes schreiben:
*		dc.l	traps, traps, traps, traps, ...
*		dc.l	..., traps, traps, traps, traps

          	dc.l	traps                	; 0xf8  (00 00 01 00) 
          	dc.l	traps                	; 0xfc  (00 00 01 00) 


*DR:	All traps start here. Activate the Trace mode and then continue at standard start (which is the following instruction)

traps     	stop	#$2700              	; 0x100  (4e 72 27 00) 


*DR:	This is the first instruction to be executed after the machine is switched on.
*   See http://www.manualslib.com/manual/596278/Motorola-Mc68302.html?page=43:
*   The CPU BAR (Base Address Register) is a 16-bit, memory-mapped, read-write register. It consists of the high address bits
*   (Bits 0-11, here set to $fff and representing the address $fff000 as 12 less significant 0-Bits are added to achieve a full
*   24-Bit address (p.44) where a 4kBytes block of on-chip peripherals starts which contains e.g. the 1176-byte dual-port RAM (p.44ff.)),
*   the compare function code bit CFC (Bit 12, here set to 0 meaning that the FC bits are ignored), and the function code bits FC
*   (Bits 13-15, here set to a %011 but ignored).
*JM:	0xf2 is MC68302 IMP Configuration Base Address
*	Base Address: 0xfff000, starting address of Dual-port RAM
*	CFC: 0 -> FC bits are ignored

start      	move.w	#$afff,cpu_bar.w+2        	; 0x104  (31 fc af ff 00 f2) 

*JM:	write 0x0    to 0xf5 (MC68302 IMP Configuration System Control)
*	ERRE:0, VGE:0, WPVE:0, RMCST:0, EMWS:0, ADCE:0, BCLM:0

          	move.b	#$0,cpu_scr.w+1           	; 0x10a  (11 fc 00 00 00 f5) 

*JM:	$fff836 is OR1
*	MRW: 0 -> masked
*	Base Address Mask: 0xf00000
*	DTACK: 1 -> 1 wait state

          	move.w	#$3e00,$fff836      	; 0x110  (33 fc 3e 00 00 ff f8 36) 

*JM:	$fff834 is BR1
*	Set new RAM base address
*	EN: 1 -> /CS1 is enabled
*	Base Address: 0x200000

          	move.w	#$401,$fff834       	; 0x118  (33 fc 04 01 00 ff f8 34) 

*JM:	$fff832 is OR0
*	MRW: 1 -> not masked (->read-only)
*	Base Address Mask: 0xf00000
*	DTACK: 1 -> 1 wait state

          	move.w	#$3e02,$fff832      	; 0x120  (33 fc 3e 02 00 ff f8 32) 

*DR:	Initialize 1 kByte in RAM from $200000-$2003ff with #$400100 (meaning?)

          	move.w	#$ff,d0             	; 0x128  (30 3c 00 ff) 
          	lea.l	$200000,a0          	; 0x12c  (41 f9 00 20 00 00) 
lab_0     	move.l	#$400100,(a0)+      	; 0x132  (20 fc 00 40 01 00) 
          	dbra	d0,lab_0            	; 0x138  (51 c8 ff f8) 

*DR:	Copy 30 bytes (the 4 instructions at lab_0x158) from lab_0x158 to $fff000 (somewhere into the RAM?!) and execute them

          	move.w	#$e,d0              	; 0x13c  (30 3c 00 0e) 
          	lea.l	$fff000,a0          	; 0x140  (41 f9 00 ff f0 00) 
          	lea.l	lab_0x158,a1             	; 0x146  (43 f9 00 00 01 58) 
lab_1     	move.w	(a1)+,(a0)+         	; 0x14c  (30 d9) 
          	dbra	d0,lab_1            	; 0x14e  (51 c8 ff fc) 
          	jmp	$fff000             	; 0x152  (4e f9 00 ff f0 00) 


*DR:	This code was copied into the RAM and executed (set new )

*JM:	0xfff834 is BR1
*	Set new RAM base address
*	EN: 1 -> /CS1 is enabled
*	Base Address: 0x0

lab_0x158  	move.w	#$1,$fff834         	; 0x158  (33 fc 00 01 00 ff f8 34) 

*JM:	0xfff836 is OR1
*	MRW: 0 -> masked
*	Base Address Mask: 0xe00000
*	DTACK: 1 -> 1 wait state

          	move.w	#$3c00,$fff836      	; 0x160  (33 fc 3c 00 00 ff f8 36) 

*JM:	0xfff830 is BR0
*	Set new ROM base address
*	EN: 1 -> /CS0 is enabled
*	Base Address: 0x400000

          	move.w	#$801,$fff830       	; 0x168  (33 fc 08 01 00 ff f8 30) 

*DR:	Since new ROM base address now is $400000, this jump directly returns to lab_64 (so back into the ROM)

          	jmp	$400176             	; 0x170  (4e f9 00 40 01 76) 


lab_64    	moveq	#$0,d1              	; 0x176  (72 00) 
          	bra.b	lab_2               	; 0x178  (60 46) 

*DR:	When is this used? Or is it dc...
          	dc.w	$46fc               	; 0x17a  (46 fc) 
          	move.l	d0,-(a3)            	; 0x17c  (27 00) 
          	moveq	#$1,d1              	; 0x17e  (72 01) 
          	bra.b	lab_3               	; 0x180  (60 02) 
          	moveq	#$0,d1              	; 0x182  (72 00) 
lab_3     	nop	                    	; 0x184  (4e 71) 
          	reset	                    	; 0x186  (4e 70) 
          	reset	                    	; 0x188  (4e 70) 
          	reset	                    	; 0x18a  (4e 70) 
          	reset	                    	; 0x18c  (4e 70) 
          	reset	                    	; 0x18e  (4e 70) 
          	reset	                    	; 0x190  (4e 70) 
          	reset	                    	; 0x192  (4e 70) 
          	reset	                    	; 0x194  (4e 70) 
          	reset	                    	; 0x196  (4e 70) 
          	reset	                    	; 0x198  (4e 70) 
          	reset	                    	; 0x19a  (4e 70) 
          	reset	                    	; 0x19c  (4e 70) 
          	reset	                    	; 0x19e  (4e 70) 
          	reset	                    	; 0x1a0  (4e 70) 
          	reset	                    	; 0x1a2  (4e 70) 
          	reset	                    	; 0x1a4  (4e 70) 

*DR:	Code but strange: waiting 17*10T, then doing something with the BAR ...
          	moveq	#$10,d0             	; 0x1a6  (70 10) 
lab_4     	dbra	d0,lab_4            	; 0x1a8  (51 c8 ff fe) 
          	cmpi.w	#$bfff,$f2.w        	; 0x1ac  (0c 78 bf ff 00 f2) 
          	bne.b	lab_5               	; 0x1b2  (66 06) 
          	move.w	#$afff,$f2.w        	; 0x1b4  (31 fc af ff 00 f2) 
lab_5     	move.b	#$20,$f5.w          	; 0x1ba  (11 fc 00 20 00 f5) 


*@JM:	Insert your comments
lab_2     	move.w	#$1800,$fff832      	; 0x1c0  (33 fc 18 00 00 ff f8 32)

ACHTUNG: Hinsichtlich BAR korrigiert

 

[Riley]

Well hi there (I hope you guys can speak English well enough, been reading this topic via google translator).

For a while now I've been looking into GEM S-series stuff, i own two S3 Turbos and so...

Having found some floppy images on the internet (that Finnish site!), and finding out that editdisk (a japanese tool) can read/write these FAT12 images perfectly, I went into reversing the executable format, and it seems you have done so also.

A month ago or so I found a ROM dump of an S3 Turbo online (it seems the S3 Turbo I've been using to test stuff has a different version of the ROM anyway, based just on some function pointers i grabbed), and I started disassembling it with IDA (loading it at base address 0x400000, is this right? or does the bootloader itself move it there?), and figuring things out from that Sample Translator 2.0 code that was on gemclub at one point.

Today I tried to code some small program to implement some small protocol to dump ram over MIDI (having coded small stuff in asm, and in C, using vbcc/vasm.., and having figured out the executable format, it seems you also did so, if not, then basically, the structure after those 6 bytes is 3 DWORDs, first is the base address, second is the entrypoint, and third is.. actually, I'm not sure, seems to point to some structure i haven't figured out yet? Anyway the executable gets loaded at that base address starting at offset 0x10 (entrypoint address)), and still trying to disassemble various bits to figure out the API, which seems to have functions all over the place.

Having found this site before, i assumed this thread was dead.. but to my amazement there's been some posts in the last week or so! And with so much progress! Interesting that someone started to code an emulator, I planned to do so myself, if only to get at that debug output, and to not have to write a floppy image every time I wanted to test a binary...

Oh, and by the way, a screenshot of my first proof of concept getting something running on the S-series ended up in PoC||GTFO11, I wonder if anyone here saw it. If not, here's a picture:

 

[jmech]

Sorry, es hat mit der Antwort etwas laenger gedauert...

Dabei sind mir noch folgende Kleinigkeiten aufgefallen:
1) lea.l -> lea (da immer .l)
2) dbra -> dbf (wobei dbra von den meisten Assemblern auch akzeptiert wird und meinetwegen auch ok ist)
3) Alle Adressen/Hexadezimalwerte in Kommentaren vielleicht immer mit Präfix "$" und nie "0x" (C-Syntax vermeiden, auch wenn's zunächst schwer fällt)

1) habe ich geandert
2) habe ich erstmal so gelassen
3) habe ich zumindest in den Assemblerfiles geaendert, da man sich dort ja an die Motorola-Syntax halten kann. In den Textfiles wuerde ich gerne bei dem 0x-Praefix bleiben, da das m.E. genereller ist und auch z.B. von Shells und Python direkt so verstanden wird.

Es gibt jetzt ein Unterverzeichnis von s3asm, wo ich alle Disassembler-Control-Files abgelegt habe, sowie die Disassemblate der Freeware-Programme. Das ganze ist mittlerweile soweit, dass sich die asm-Dateien wieder mit vasm 1:1 zurueckuebersetzen lassen. Das gleiche gilt auch fuer den Sample Translator, allerdings wollte ich das Disassemblat nicht oeffentlich stellen. Als naechstes wollte ich noch den s3img-Befehl erweitern, damit man aus einem lokalen Verzeichnis wieder ein Image erzeugen kann, um modifizierten Code per Floppy auf den Synth zu kriegen.

Gibt es einen Vorschlag, wie wir am besten gemeinsam am Kommentieren des Assembler-Codes arbeiten koennen? Wenn git nicht gefaellt, koennen wir auch was anderes nehmen, aber irgendein Versionskontrollsystem werden wir schon brauchen.

 

[jmech]

Well hi there (I hope you guys can speak English well enough, been reading this topic via google translator).

For a while now I've been looking into GEM S-series stuff, i own two S3 Turbos and so...

Having found some floppy images on the internet (that Finnish site!), and finding out that editdisk (a japanese tool) can read/write these FAT12 images perfectly, I went into reversing the executable format, and it seems you have done so also.

Hi! Great that this thread is attracting non-Germans as well as there don't seem that many places left to talk about the guts of the S-series. I have been watching the Italian turboforum but it looks pretty dead to me. I haven't come across editdisk so far, I will definitely have a look.

A month ago or so I found a ROM dump of an S3 Turbo online (it seems the S3 Turbo I've been using to test stuff has a different version of the ROM anyway, based just on some function pointers i grabbed), and I started disassembling it with IDA (loading it at base address 0x400000, is this right? or does the bootloader itself move it there?), and figuring things out from that Sample Translator 2.0 code that was on gemclub at one point.

The MIOS version string starts at offset 0x6000 of the ROM, DanReed and I have version 2.0 from 28.3.91. So far I haven't looked deeper into anything past offset 0x20a of the first ROM but it seems that the RAM base address is set to 0x400000 at offset 0x1c8 and the ROM base address is set to 0x0 at offset 0x1d8. Interesting that you found a version of Sample Translator 2.0 online, would you be able to provide it to us? It might be useful for finding it in the Turbo ROM.

Today I tried to code some small program to implement some small protocol to dump ram over MIDI (having coded small stuff in asm, and in C, using vbcc/vasm.., and having figured out the executable format, it seems you also did so, if not, then basically, the structure after those 6 bytes is 3 DWORDs, first is the base address, second is the entrypoint, and third is.. actually, I'm not sure, seems to point to some structure i haven't figured out yet? Anyway the executable gets loaded at that base address starting at offset 0x10 (entrypoint address)), and still trying to disassemble various bits to figure out the API, which seems to have functions all over the place.

That is very interesting! I had been looking at those three DWORDS as well which are very similar for the Freeware programs but were very different for the Sample Translator 1.0, so I got a bit confused.

• 
  *Offset 0x6: 0x0 for LOADER.LOD and the three Freeware PRGs, but $1e0000 for ST1.0. I am guessing that this base address is relative to the RAM base address?
  
  *Offset 0xa: Could be the entrypoint although I cannot make a lot of sense of the asm code around that location for any of the programs. What did you mean by 'loaded at that base address starting at offset 0x10'? Where is the 0x10 coming from?
  
  *Offset 0xe: Might actually just be the offset of the program end (possibly +- a constant offset to account for the file header). As far as I can tell this offset is always just behind the string section at the end of all programs.

EDIT: I just noticed that the ST1.0 program starts with the magic numbers 0101010c0201 while the others start with 0101010b0201. Maybe the former hints at a program which can be started later by pressing the Option-Key while the latter is executed right away (or it could also refer to the program's multi-tasking mode). Anyhow, this might also be the reason why they are loaded to very different offsets.

BTW I have been successful in disassembling the binaries with capstone (as IDA is not available to me) and re-assembling with vasm (using -m68000 -no-opt -Fbin -rangewarnings). Interesting that you have managed using vbcc. I just tried to get a working setup but I am not exactly sure how. Could you maybe share your vc.config and maybe your vbcc compilation options as well? It would be great if I could start writing C-code and try matching it to the assembly I got so far!

Having found this site before, i assumed this thread was dead.. but to my amazement there's been some posts in the last week or so! And with so much progress! Interesting that someone started to code an emulator, I planned to do so myself, if only to get at that debug output, and to not have to write a floppy image every time I wanted to test a binary...

Heh, actually I was pretty worried as well before posting here the first time (especially as also all other relevant forums seem to be down or very rarely visited).
With respect to the simulator: Unfortunately, it is far from useful so far but it would be great it you manage to improve on it. Our current route right now is starting with working on the disassembly of one of the user programs and the ROM.

Oh, and by the way, a screenshot of my first proof of concept getting something running on the S-series ended up in PoC||GTFO11, I wonder if anyone here saw it.

Haha, that's great!
Have you edited one of the strings at the end of LOADER.LOD for this? In any case, very nice work getting something 'published' already!

If you are interested in collaborating (which would be very welcome) we might also just move the discussion to some other place where we can openly chat in English (I am actually not sure about the forum rules here as I am a newbie here as well). As it was probably you who forked the repos on Github, maybe we can just do it over there?

 

[jmech]

Bzgl. RAM-Dump:
Wenn man dem S3 erst den Sysex-Befehl STAT_REQUEST (+ D_WAIT und D_ACK) und dann F_ACK schickt, faengt er an, den RAM ueber MIDI zu dumpen. In meinem Tool hat das zeitweise nicht mehr funktioniert, aber es geht jetzt wieder mit

./s3midi -cRAM_DUMP

Das ganze ist leider etwas langwierig: fuer die komplette Laenge von 2097060 Bytes braucht es ca. 20 Minuten. Es ist zwar moeglich, den Dump vorzeitig abzubrechen, aber bisher weiss ich noch nicht, ob man eventuell auch einen speziellen Bereich auswaehlen kann.

 

[Riley]

Interesting that you found a version of Sample Translator 2.0 online, would you be able to provide it to us? It might be useful for finding it in the Turbo ROM.

Here: http://lucasm.cf/?yzzjn

and here's my partial documentation of some of the structures seen in that code that are defined in headers that I don't have and are probably lost forever now: http://pastebin.com/5mMJrpEL

Where is the 0x10 coming from?

I of course meant 0xa. (decimal 10) -- I guess I was both excited to find others working on this, and in a rush at the same time!

EDIT: I just noticed that the ST1.0 program starts with the magic numbers 0101010c0201 while the others start with 0101010b0201. Maybe the former hints at a program which can be started later by pressing the Option-Key while the latter is executed right away (or it could also refer to the program's multi-tasking mode). Anyhow, this might also be the reason why they are loaded to very different offsets.

Actually I think it might be something to do with freeware vs. protected program, as in, the exe on that freeware floppy that copies .PRGs between S-series floppies doesn't copy "protected" programs, but I'm not sure. Besides, all the quick stuff i coded uses 0B there and base address the same as ST1.0 (as I could not get it working otherwise).

BTW I have been successful in disassembling the binaries with capstone (as IDA is not available to me) and re-assembling with vasm (using -m68000 -no-opt -Fbin -rangewarnings). Interesting that you have managed using vbcc. I just tried to get a working setup but I am not exactly sure how. Could you maybe share your vc.config and maybe your vbcc compilation options as well? It would be great if I could start writing C-code and try matching it to the assembly I got so far!

Sorry, not quite yet. My vc.config links with an asm module that provides some API calls, and after compiling I have to add the header too. (because otherwise it won't use the correct base address) I need to modify vlink to output S-series executables, though I haven't done that yet, been too busy trying to figure out the API.

Heh, actually I was pretty worried as well before posting here the first time (especially as also all other relevant forums seem to be down or very rarely visited).
With respect to the simulator: Unfortunately, it is far from useful so far but it would be great it you manage to improve on it. Our current route right now is starting with working on the disassembly of one of the user programs and the ROM.

I can give you my IDB of the ROM if you want... I use one of the leaked IDA 6.8s btw.

Haha, that's great!
Have you edited one of the strings at the end of LOADER.LOD for this? In any case, very nice work getting something 'published' already!

Nope, custom code. In ASM: http://pastebin.com/2LRvKchM and in C: http://pastebin.com/KmqXN6tC
(btw, now I know that "API_0_1" is actually called "m_status", and the "API_0_1( (void*) (dword_1 + 0x880), 0x203,&dword_3 );" line puts into dword_3 a pointer to the "GENMAN" (general manager?) function table which includes pointers to things like file management functions (create_file, delete_file etc).)

If you are interested in collaborating (which would be very welcome) we might also just move the discussion to some other place where we can openly chat in English (I am actually not sure about the forum rules here as I am a newbie here as well). As it was probably you who forked the repos on Github, maybe we can just do it over there?

I didn't fork the repos on github, but I was the person who filed the issue on s3turbo. I've been looking at s3sim and the ROM and trying to implement emulation for the serial (RS-232) hardware that is used for debugging, but I'm.. not that experienced in m68k stuff, not even sure how it talks to the hardware....

I can create an IRC channel on my network if you want, and maybe in time set up a wiki to document what we find.

 

[microbug]

Mal so nebenbei: sollen wir das hier weiterführen, weil sehr speziell, oder vielleicht eine Mailingliste bzw Google Gruppe dafür anlegen?
Hätte den Vorteil, daß man das auch über einen Mailclient bedienen könnte. IRC ginge auch, Mailingliste oder Gruppe fände ich besser, da hat man ein Archiv.

Besides: should we keep this here or set up a mailing List or Google Group for that? This would have the advantage of working with a Mail client. IRC may do, but mailing List or Google Group are better because you always can read the old posts.

 

[jmech]

Mal so nebenbei: sollen wir das hier weiterführen, weil sehr speziell, oder vielleicht eine Mailingliste bzw Google Gruppe dafür anlegen?
Hätte den Vorteil, daß man das auch über einen Mailclient bedienen könnte. IRC ginge auch, Mailingliste oder Gruppe fände ich besser, da hat man ein Archiv.

Besides: should we keep this here or set up a mailing List or Google Group for that? This would have the advantage of working with a Mail client. IRC may do, but mailing List or Google Group are better because you always can read the old posts.

Excellent point, I have created a Google Group here. Maybe we can have an IRC channel or try https://gitter.im/ if it becomes necessary.

 

[microbug]

Ok, bin jetzt auch in der Gruppe.

Da hier alle Kenner gerade versammelt sind: auf Facebook in der Gruppe Synthesizer Klub hat ein Kollege gerade ein Problem mit seiner S2R, die bleibt mit einem zerpixelten Displaybild beim Start hängen. Da kommen jetzt gerade schon die üblichen Standardtips von Leuten, die die Dinger nicht kennen, und die bringen ihn nicht weiter, vielleicht hat ja von Euch einer eine Idee dazu, er meldet sich möglicherweise auch hier im Thread.

Für mich sieht das nach einem defekten DRAM aus. Kann leider keinen Link auf den Beitrag setzen.

 

[tss]

Hallo Danreed oder wiie immer du auch heisst. Ich bin der Tonny aus Holland und habe seit 22 jahre eine GEM S3 Turbo. Ich benuetze dieses Instrument vor allem als MIDI controller. Letztes Wochenende war dan mein Keybpoard ploetzlich im Stoerung, auf den Display gab es streifen Blau und nichts. Ich habe dann viel gelesen ueber Batterieschaden USW und auch mein Keyboard hatte dann dieses Problem. Ich habe die Batterie gewechselt durch einen NiMh und dass angresende IC erneuert. Das Display ist jetzt wieder hell Blau aber die Maschine macht keinen durchstart. Ich habe schon manche Leute gesprochen, auch den neuen Eigner von GEM in Finland. Erhat mich was geschickt aber Ich glaube Ihr Jungs, du und Microbug) seit besser drauf. Ich habe auch die Power Supply nachgemessen, die ist soweit OK, 5V und 12V. Die Maschine habe ich damals eingeschaltet ohne Diskette, danach eine Song Diskette hinein geschoben und den richtigen Song geladen. Als ich dan zuruck kam, war die Machine Tot.

Ich habe auch die Umgebung der Batterie gut angesehen auf Schaden und dazu das IC67, DS1202, auf '4' und '8', geprueft ob dar ach die Batterie Spannung da war, dass hat dan funkioniert

Ich weiss nicht mehr was ich tun soll um die Machine zu retten. Ich vermute das beim laden irgendwas faslch gewesen ist und deshalb den EEprom mit OS drauf verstoert hat. Ich habe zwar gesucht auf OS Disketten aber nicht gefunden bis Ich dein Eintrag in das Forum sah, wo du schreibst, du haettest auch die ROM Inhalte. Wie kann ich eine diskette oder Datei bekommen mit das MIOS?

Ich moechte dich im Voraus bedanken fuer dien Mitarbeit. Du kannst mich erreigen auf meine E-Mail adresse

TSS

 

[microbug]

Am OS liegt das sicher nicht, ist in EPROMs (nicht EEPROM oder Flash) gespeichert, und die muß man mit einer UV-Lampe löschen.

Für mich hört sich das an, als wäre das Netzteil hinüber und hätte einen thermischen Schaden, denn offenbar startet das Gerät ja, aber geht auch wieder aus.

 

[DanReed]

Ich würde microbug zustimmen. Nach vielen Jahrzehnten kann in einem EPROM zwar mal ein Bit umkippen, aber das ist äußerst selten. Und warum sollte ausgerechnet das eine Bit in einem so großen Betriebsystem (wo mehr als die Hälfe Sounds und Sequenzerdaten sind) dann so schwerwiegende Folgen haben? Sehr unwahrscheinlich.

Ich denke vielmehr, daß die ausgelaufene Batterie noch mehr zerstört hat, als Du denkst. Die Säure frist sich entlang der Durchkontaktierungen auch auf die andere Seite der Platine durch.

Hast Du das Mainboard komplett ausgebaut?

Hast Du Fotos von beiden Seiten? Wenn ja, bitte jetzt posten, bevor das große Spekulieren losgeht.

 

[microbug]

Im Bereich der Batterie liegt auch mindestens ein Kabel, was für die Andressierung des Turboboards gebraucht wird, und wenn es da Kontaktprobleme gibt, hat man auch eine feine Absturzquelle.

 

[tss]

Ich habe ein paar Foto's dazu, Ich habe bedenke ich mich jetzt die Foto's noch nicht so genau angesehen. Das IC 74HC32B1 soll auch gewechselt werden. Habt Ihr dann zufaellig eine Idee wo mann spare parts bekommen kann, oder ein anders Keyboard kaufen kann. Ich habe shon einiges probiert, aber ist scher zu kriegen.

Dan habe Ich noch ne Frage: Ist das CPU Board von den S2 und S3 Turbo tat saechlich gleich? So steht es jeden gfals in die Srvice Manuals. Das wurde den Chnage Unterteile zu bekommen zweifag steigern.

Ich werde den Kabel auch nochmal pruefen, Danke Euch..

Tonny

 

[microbug]

Versuche mal ohne Blitz zu fotografieren, da sieht man die Details besser, braucht halt ordentlich Licht.
Die Kabel zum Turboboard sind ok.
Was ich auch sehen kann: das Ist ein neueres Mainboard mit machgerüstetem Turbokit, denn es ist bereits die Diode neben der Batterie eingezeichnet, wo dort ein Widerstand sitzt, der zum Laden des Akkus dient. Ich habe bei meiner S3T eine Lithiumbatterie eingebaut und die vorgesehene Diode, so wie auf Deinem Ausschnitt aus dem Schaltplan zu sehen. Eine CR2032 ist wahrscheinlich zu schnell leer, gibt aber auch Zellen wie CR2 mit mehr Ladung.

Der 74HC245 (IC54) direkt an der Rückseite des Akkus sieht mitgenommen aus, hier würde ich mindestens mal das alte Lötzinn absaugen, neu löten und auch die Leitungen prüfen. Das ist ein 8bit bidirektionaler Bustreiber, sowas sitzt normal an den Datenleitungen, in diesem Fall müßte ich gucken, was der genau macht. Der 74HC32 darüber scheint zumindest bei den Pins 1 und 2 auch nicht ganz sauber zu sein.

Das sind Standardbauteile, die gibts in jedem gut sortierten Elektronikladen: 74HC245 und 74HC32 sind die bezeichnungen.

Warum ein anderes Keyboard? Die Tastatur ist doch ok? Die stammt übrigens von Fatar, die Kontakte und der poly AT drunter sind aber eine Eigenentwicklung vom GEM und so auch bei den Elka MK55/88 zu finden, die vom gleichen Entwickler stammen.

Die CPU Boards der Geräte sind identisch, der Unterschied liegt ja nur in der Tastaturgröße und wird dann im Betriebssystem gemacht.

Die Geräte gibts immer wieder mal bei ebay oder ebay Kleinanzeigen hier in D.

 

[tss]

Hallo Microbug, danke Vielmals für die Erklärung sämptliche Bauteile. Ich habe das IC54 bereits gewechselt. IC 53 ist jetzt auch wieder sauber. Was könnte zich weiter noch messen, tun? Ich bin kein Electroniker, und bin angewiesen auf mein gesundes Verstand. Ich habe auch shon gelesen mann könnte ohne Display starten, da scheint es auch Fehler zu geben.

Übrigens Keyboard heisst bei uns das totale Instrument, nicht nur die Tasten. Die sind OK soweit Ich weis. Ich versuche Bauteile zu kaufen, oder also das ganze Instrument. Die Ich dann wieder als Reserveteile verwenden kann.

Kannst Du auch sagen Ob dieses Mutterboard(?) bi-layer oder multi-layer ist? Es kan ja sein dass sich das Säure sich intern in das Board gefressen hat?

Als Ich das Instrument geöffnet habe war so ne Staub rundum die '-' Seite der Batterie. Das ist dan wol die Säure gewesen. Kan mann dieses Board ohne weiteres 'waschen' mit Demi Wasser? Habe Ich auch gelesen. Damit sollte das hintergeblieben Salz herab gewaschen werden. Das muss dan denke Ich ohne Batterie. :|

Tss

 

[DanReed]

Kannst Du auch sagen Ob dieses Mutterboard(?) bi-layer oder multi-layer ist? Es kan ja sein dass sich das Säure sich intern in das Board gefressen hat?

Das Board hat vier Layer und ja, die Säure kann sich auch in die Layer gefressen haben.

Ich würde mindestens die beiden Chips auslöten, die Platine gründlich und großflächig reinigen und anhand des Schaltplans die Widerstände aller betroffenen Leitungen durchmessen.

Du hast ja schon eine Leiterbahn ersetzt, bist Du sicher, daß sie nun immer noch alle vorigen Verbindungen herstellt?

 

[Jarreenzo]

Hallo,

Welche Chip hat eigentlich die OS. Ich habe eine S2 MB in eine S3 eingebaud aber es zeight S2 im LCD und die letzte 15 tasten functionieren nicht. Iche habe de S3 turbo Platine behalten und nur die S2 MB gewechselt.

Grüßen, Jarreenzo.

 

[microbug]

S2 und S3 haben unterschiedliche OS, auch beim Turbo, alleine schon wegen der Tastatur. Du brauchst das OS für die S3. Die passenden Dateien haben wir und einer von uns kann Dir das auch sicherlich in ein EPROM brennen, ich wüßte nur gerade selbst nicht, welcher Chip in welchen Sockel kommt, sind 4 Stück.

 

[Jarreenzo]

Danke Microbug,

Welche 4 chips meinst du? Sind es die 4 VLSI chips? Ich kann die von S3 board ausnehmen und in das S2 board stecken oder? Die S3 functioniert gut.

Die 4 sind Disp, 2x Filter und Reverb (die 4 VLSI). Aber wenn es die 4 auf die Turbo platine sind, dan sind die schon S3 weil ich das board nicht geanderd habe.

 

[DanReed]

Welche 4 chips meinst du? Sind es die 4 VLSI chips? Ich kann die von S3 board ausnehmen und in das S2 board stecken oder? Die S3 functioniert gut.

Die 4 sind Disp, 2x Filter und Reverb (die 4 VLSI). Aber wenn es die 4 auf die Turbo platine sind, dan sind die schon S3 weil ich das board nicht geanderd habe.

Es sind nicht die VLSI Chips! Die solltest Du nicht wechseln. Außerdem können sie leicht beschädigt werden.

Die Erkennung führt die Keyboard-CPU durch, indem sie die Tastenkontakte der Tasten oberhalb der 61. Taste eines 5-Oktaven-Keyboards abfragt. Bei 5 Oktaven sind alle Kontakte offen, ansonsten sind die oberen Kontakte geschlossen und die unteren offen.

Aber es kann sein, daß diese Erkennung nur durchgeführt wird, wenn dafür kein Wert im RAM vorliegt (z.B. weil das Gerät nach Herstellung zum ersten Mal eingeschaltet wird). Du müßtest also das RAM mal von der Puffer-Batterie trennen, wobei alle selbst gespeicherten Klänge verloren gehen.

 

[Jarreenzo]

Hallo Dan,

Das Keyboard-CPU is auf das I/O board so die hat sich nicht geandert. Ich habe nur die MB von S2 im S3 eingebauwd. So ich brauche nur zu wissen in welchen chip(s) die OS sitzt. Dann kann ich die von das S3 board auf das S2 board setzen nicht?

Was macht das IC66 eigentlich? EEPROM aber sehr klein.

 

[DanReed]

Dann sieh bitte mal in diesen Beitrag fast am Anfang dieses Threads: viewtopic.php?p=872652#p872652

Im ersten Foto siehst Du die vier EPROMs, wie sie nebeneinander auf dem Turbo-Board stecken (genauer: rechts neben dem orangen Kreis).