EPROM Files für Studer A807 + PR99
#1
Hallo,

ich habe gerade zufällig auf dem holländischen Studer/Revox Manual Server ein Verzeichnis mit EPROM Files für Studer A807 + PR99 entdeckt
https://www.reeltoreel.nl/studer/Public/...m%20Files/

MfG, Tobias
Strom kann erst dann fliessen, wenn Spannung anliegt.
Zitieren
#2
Hallo Tobias,

vielen Dank für den Hinweis - die Fassung 20-92 habe ich auch in meiner A807. Leider habe ich vom Assembler für den 8603 keine Ahnung - so bleibt das disassemblierte Ergebnis noch vor meiner Interpretation (und erst Recht vor Änderungsversuchen) verschont...

Viele Grüße
Andreas
Zitieren
#3
Kann es sein, daß du einen MC6803 von Motorola meinst ?
Dafür gab/gibt es bestimmt Disassembler und Assembler sowieso.
Der MC6800 wurde vom gleichen Team entwickelt, wie kurz danach der 6502 von MOS Technology: Bill Mensch , Chuck Peddle und Kollegen.

MfG Kai
Nachtrag: Übersichts-Infos und Links zu ~ 37 MB Referenz-Literatur gibt es hier:
https://de.wikipedia.org/wiki/Motorola_6800
Zitieren
#4
(29.06.2021, 10:17)kaimex schrieb: Kann es sein, daß du einen MC6803 von Motorola meinst ?

..das war sicherlich ein Schreibfehler.
Sowohl die PR99 als auch die A807 haben eine MC6803 CPU.
Das Disassemblen ist spannend aber etwas für Leute mit seeeehr viel Zeit ;-)
Erinnert mich sofort an die guten, alten Studentenzeiten wo ich mit "Entdonglen" mein Bafög aufgebessert habe...(ist mittlerweile hoffentlich verjährt)

Beste Grüße,
Wilhelm
Wir lösen ständig nur Probleme die wir ohne uns nicht hätten
Zitieren
#5
Man muß der Struktur der Hardware durchschauen und Zugriff auf die alten Software-Tools von Ende der 70er Jahre ... Mitte der 80er Jahre haben oder das benötigte in den Retro-Computing-Zirkeln finden, die es ähnlich gibt wie die Freunde veralteter Analog-Technik.
Ich habe hier zwar auf dem Wohnzimmer-Tisch einen Raspberry Pico liegen und seit kurzem einen Teensy 4.0, bin aber seit Wiederfinden eines bislang unbenutzten µP-Boards von ca. 1983 im Keller dabei, das in Assembler zu programmieren und alte Software ähnlicher Boards zu disassemblieren (6502 Prozessor Familie). Den Disassembler habe ich selber mal im vorigen Jahrhundert geschrieben  und gelegentlich zwischendurch von Apple II zu IBM PC unter DOS und jetzt Windows 7 wiederbelebt und verschlimmbessert.
Aber als Rentner hat man ja auch viel Zeit, denn man wird wach, wenn die Sonne aufgeht...
Es gibt übrigens erstaunlich viele Leute und Gruppen, die sich mit so einem simplen und nach heutigen Maßstäben völlig veralteten Prozessor wie dem 6502 beschäftigen. Produziert werden er und seine Nachfolger inzwischen auch noch bzw wieder und auch als Core in größeren, komplexeren Chips verwendet.
Man braucht für die Beschäftigung damit nicht mehr Zeit, als dafür, altersschwache Bandgeräte am Leben zu erhalten.
Kombinieren kann man die Themen auch. Auf einem Teensy 4.0 mit Audio-Shield läßt sich "ohne weiteres" die ganze Audio-Entzerrung eines Bandgerätes implementieren.

MfG Kai
Nachtrag: Ein kurze Suche im Netz nach "6800 Disassembler" führte bereits in der ersten Ergebnisliste auf 5 verschiedene passende Disassembler. Manche laufen allerdings auf damaligem Equipment (oder heute vielleicht in Emulatoren).
Zitieren
#6
(29.06.2021, 11:16)kaimex schrieb: Es gibt übrigens erstaunlich viele Leute und Gruppen, die sich mit so einem simplen und nach heutigen Maßstäben völlig veralteten Prozessor wie dem 6502 beschäftigen.

..auch auf die Gefahr hin, dass es jetzt wieder -off topic - werden könnte...
In der FPGA-Programmierung sind die "alten" Prozessoren (6803, 8086, Z80,..) absolut super wenn es darum geht,  "mal eben" einen Prozessor für einfache Arbeiten per IP-Core mit einzubauen. Der Ressourcenverbrauch ist (bei mittleren bis grossen FPGA's) eher vernachlässigbar und die alten Tools (bzw. Toolchains) können ohne Probleme wieder verwendet werden.
Größter Vorteil: solch ein Prozessor wird niemals abgekündigt und ein Z80 läuft auf diese Weise locker mit 50MHz Big Grin

Beste Grüße,
Wilhelm
Wir lösen ständig nur Probleme die wir ohne uns nicht hätten
Zitieren
#7
Hallo Kai, hallo Wilhelm,

einen Disassembler habe ich schnell gefunden (f9dasm), und er hat auch ohne Fehlermeldung das Firmware-File verarbeitet.

Mein Kommentar bezog sich eher auf meine fehlenden Kenntnisse in Assembler, speziell für den 6803 (ja, war ein Schreibfehler, sorry...), aber auch generell; über ein paar erste Schritte auf dem 6510 im C64 kam ich damals nicht hinaus. Deswegen liest sich der disassemblierte Code für mich "nicht so flüssig" wie gewohnte Hochsprachen - um nicht zu sagen, ist noch völlig unverständlich. Das wäre sicher auch ein interessantes Hobby... aber davon habe ich schon zu viele.

Viele Grüße
Andreas
Zitieren
#8
(29.06.2021, 16:51)andreas42 schrieb: Deswegen liest sich der disassemblierte Code für mich "nicht so flüssig" wie gewohnte Hochsprachen - um nicht zu sagen, ist noch völlig unverständlich.

reiner Assembler-Code ist immer schwerer zu lesen als ein Hochsprachen-Programm und es hängt extrem davon ab, wie gut der Programmierer ihn dokumentiert hat. Es gibt zwar auch Assembler, welche mit pseudo-Hochsprachen Makros arbeiten können (das erleichtert das Lesen manchmal etwas..), aber beim disassemblierten Code hast du immer (mindestens..) drei Herausforderungen:
- die Kommentare sind (natürlich) nicht mehr drin im Code
- die Symbolnamen der Funktionen (Unterprogramme) werden durch die Adressen ersetzt und sind somit nicht mehr intuitiv
- Funktionsparameter werden über (indirekte..) Speicheradressen und/oder dem Stack ausgetauscht.
Wenn Studer die Firmware damals nicht in Assembler sondern schon in C geschrieben hat, können für ein einfaches printf() schon mal mehrere Din-A4 Seiten Assembler generiert werden (abhängig vom Compiler & Optimierung).
Bei Lizenzfähigen Compilern wird häufig (abhängig vom Lizenzmodell) auch noch jede Menge (sinnloser..) pseudo-code erzeugt.
Und, wie Kai schon angemerkt hat, muss man natürlich die Architektur des Prozessors (Befehle, Stack-Aufbau,Adressierung,..) und der angeschlossenen Hardware kennen, um den (Dis-)Assembler Code vernünftig zu durchschauen.
Es ist eine absolut spannende Sache...für die ich vor 20 Jahren gerne die Nächte geopfert hätte...heute sieht es aber (leider?...Gott sei Dank?)...anders aus ;-)

Beste Grüße,
Wilhelm
Wir lösen ständig nur Probleme die wir ohne uns nicht hätten
Zitieren
#9
Mir ist beiläufig aufgefallen, daß anscheinend in der PR99 nur ein 32 KBit EPROM 2732 verwendet wird (es sei denn das Manual ist unvollständig), der Binär-File für die A807 ist dagegen 32 KByte lang. Sind die Geräte so unterschiedlich, daß ein 8-fach längeres ROM gebraucht wird ? Oder deutet das auf die Verwendung einer Hochsprache hin ?
Es sind allerdings darin keine lesbaren Compiler-Relikte zu sehen, wie sonst bei compilierten Hochsprachen schlampiges Brauchtum.

MfG Kai
Zitieren
#10
Hallo Kai,

die A807 ist komplexer als die PR99 was die Parametrierbarkeit & Steuerung betrifft. So lassen sich zwei komplett verschiedene Bandsorten einmessen und abspeichern. Das Einmessen kann dabei über das Tastenmenue erfolgen oder über die serielle Schnittstelle. Die Schnittstelle stellt viele Parameter zur Verfügung, die von einer externen Applikation über RS232 Befehle abgefragt und gesetzt werden können. Allein die Implementierung eines dafür notwendigen Parsers dürfte etliche Bytes mehr benötigen als in der PR99.
Natürlich kann auch eine andere Toolchain dazu beigetragen haben..das ist im Nachhinein leider nicht mehr zu überprüfen.

Beste Grüße,
Wilhelm

Nachtrag:
Ob ein Hochsprachen-Compiler zum Einsatz gekommen ist, könnte man eventuel doch über das Disassembly herausfinden. Viele Compiler erzeugen Code, welchen man als Assembler-Programmierer so nicht schreiben würde und sichern den Stack bei Funktionsaufrufen oft nach ähnlichem Muster (als Ressourcenbewusster Assembler Programmierer würde man zu 32KByte-Zeiten z.B: niemals mehr sichern als wirklich nötig..)
Wir lösen ständig nur Probleme die wir ohne uns nicht hätten
Zitieren
#11
Was läuft denn bei der PR99 überhaupt über den Mikrocontroller? Nur das Zählwerk und der Locator, glaube ich... ansonsten ist das doch eigentlich fast eine B77, meine ich.

Zitat:aber beim disassemblierten Code hast du immer (mindestens..) drei Herausforderungen

Ja, damit habe ich gerechnet - alle menschenlesbaren Hinweise sind verschwunden, das hat man ja auch, wenn man einen Stacktrace nach einem segfault von einem Binary ohne Debug-Symbole anschauen will. Dass der ursprüngliche Code besser lesbar sein sollte, hoffe ich auch, Kommentare und Labels machen ja schon viel aus - aber auch dann wäre ich aber kein "native speaker". Einer meiner Kollegen pflegte zu sagen, C sei eigentlich keine Hochsprache, sondern ein Makro-Assembler Wink

Ja, früher hätte ich mich da auch mit Vergnügen Tage und Nächte drangehängt, alleine um was neues zu lernen. Inzwischen ist das nicht mehr so einfach. Interessant wäre natürlich schon, die Firmware selbst weiter verändern zu können (z.B. Play Rückwärts auch über die Schnittstelle nachrüsten, oder sowas) - aber auch nicht dringend notwendig.

Viele Grüße
Andreas
Zitieren
#12
Bei einfachen Prozessoren wird manchmal beklagt, daß garnicht alle möglichen Op-Codes mit nutzbaren Funktionen besetzt wurden.
Die vollständige Nutzung aller möglichen Op-Codes kann jedoch durchaus das Disassemblieren erheblich erschweren, wenn gar nicht bekannt ist, wo Programm Code im Adressbereich liegt und wo Daten.  Denn, wenn alle Codes auch Op-Codes sein können, werden auch Daten auf den ersten Blick als Code interpretierbar, ohne daß eingesprenkelte ungültige Codes anzeigen, daß das wohl eine Fehl-Interpretation ist.

Glücklicherweise braucht man zum Patchen von Software nicht unbedingt Kenntnis des gesamten Programms. Es genügt, die "heißen Stellen" zu kennen, bzw deren Funktion.
Es wäre natürlich sehr hilfreich, wenn noch lebende Insider Hinweise auf den Source-Code geben könnten oder der sogar in noch vorhandenen technischen Unterlagen von Studer  aufgetrieben werden könnte.

MfG Kai
Zitieren
#13
Vielleicht könnte eine (qualifizierte) Anfrage an Revox nach dem Quellcode was bringen?
VG Jürgen
Zitieren
#14

Eine maschinenfremde, aber dennoch objektnahe Aussage zu dieser Thematik: im Zusammenhang mit der SW der A-810 erläuterte 'uns' Martin Berner vor Jahren, wie die Programmierung & Softwarepflege zu dieser Maschine IRL stattfand. Nix Hochsprache: Assemblerprogrammierung, z.T. auf opcode-level Ebene. Es mußte mangels 'Quellcode' der firmeneigene Binärcode disassembliert werden, um Änderungen einzupflegen! Bei späten Versionen der 810 (Timecode-Ergänzungen & Korrekturen) mußte der zuständige Programmierer, da nicht identisch mit dem inzwischen ausgeschiedenen Ur-Coder, die SW zu Teilen "neu" schreiben, da es an Dokumentation mangelte. Daher ist auch die Stabilität der 'letzten bekannten' SW nicht so gut wie die 'best known SW' für die Kiste [01/88].

Martin Berner war bis zuletzt verantwortlich für Schulung & Kommunikation 'nach außen' was  die gesamte Palette der softwarebehafteten STUDER Maschinen anging. Er schrieb jahrelang auch sattelfeste Kommentare in der inzwischen untergegangenen 'Studerlist' bei Fred Thal, Insiderwissen vom Feinsten! Hab' heute noch ein mail-Archiv davon, wo ich ab und zu nachgucken muß...

Für die A-810 liegen sämtliche EPROM files selbstverständlich im Bedarfsfalle vor.

Pit


PS: bei der A-810 war folgendes definitiv nicht der Fall:

(29.06.2021, 17:24)Reel2Reel4ever schrieb: [...]Wenn Studer die Firmware damals nicht in Assembler sondern schon in C geschrieben hat, können für ein einfaches printf() schon mal mehrere Din-A4 Seiten Assembler generiert werden [...]


PPS: so kann das aussehen (für @bitbrain2101)

   


02/'23: Hexdumps TLS aus dem wirklichen "holy grail (ab 2:26)"...

   
   

IC12_SW_25/86:

.txt   A810 IC12 25-86 cksm 06EA.bin.txt (Größe: 8 KB / Downloads: 1)

vorhandene TC-EPROMs (noch nicht in .bin-Form verfügbar):

   

hier brandaktuell (09/2023) ein Schmankerl von Martin Berner: A-810 inside & A-800 busanalyzer

.pdf   A800_Bus_Analyzer_10.023.002.00.docx(excl._by_Martin_Berner)_opt.pdf (Größe: 342.6 KB / Downloads: 5) 0-2 dl per 9.10.23 3 dl per 1.1.'24

zum 1. Advent 2023 noch ein paar Insights, z.B. die im '23-er .PDF erwähnte Memorymap:

               

©DK1TCP 10.023.002.00 busanalyzer Memorymap Busstruktur
(2024)  A-810 live-Reparatur;
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste