Benutzer-Werkzeuge

Webseiten-Werkzeuge


oqtadrive

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen gezeigt.

Link zu der Vergleichsansicht

Beide Seiten, vorherige Überarbeitung Vorherige Überarbeitung
Nächste Überarbeitung
Vorherige Überarbeitung
oqtadrive [2021/09/23 16:18]
xelalex [Ansatz]
oqtadrive [2023/01/24 08:24] (aktuell)
xelalex
Zeile 4: Zeile 4:
 //**Ein Sinclair-Microdrive-Emulator**//, **Alexander Vollschwitz** //**Ein Sinclair-Microdrive-Emulator**//, **Alexander Vollschwitz**
  
-{{:oq-microdrive.jpg?300 |Microdrive-Laufwerk}}+{{:oq-microdrive.jpg?300&direct |Microdrive-Laufwerk}}
  
 Das //ZX Microdrive// von //Sinclair// ist ein magnetischer Massenspeicher, der kleine Endlos-Bandkassetten als Speichermedium nutzt. Es kam 1983 zunächst als externes Laufwerk für den //ZX Spectrum// Heimcomputer auf den Markt. Der ein Jahr später erschienene //Sinclair QL// hatte zwei Microdrives intern verbaut. Bereits damals waren Microdrives nicht gerade für ihre hohe Zuverlässigkeit bekannt. Das //ZX Microdrive// von //Sinclair// ist ein magnetischer Massenspeicher, der kleine Endlos-Bandkassetten als Speichermedium nutzt. Es kam 1983 zunächst als externes Laufwerk für den //ZX Spectrum// Heimcomputer auf den Markt. Der ein Jahr später erschienene //Sinclair QL// hatte zwei Microdrives intern verbaut. Bereits damals waren Microdrives nicht gerade für ihre hohe Zuverlässigkeit bekannt.
  
-{{ :oq-cartridge.jpg?350|Microdrive-Kassette}} +{{ :oq-cartridge.jpg?350&direct|Microdrive-Kassette}} 
-{{ :oq-cart-cass.jpg?350|Größenvergleich}}+{{ :oq-cart-cass.jpg?350&direct|Größenvergleich}}
  
 Heute ist es umso schwieriger, mit einem Microdrive zu arbeiten. Insbesondere die Bandkassetten sind oftmals nicht mehr nutzbar. Das motivierte den Bau eines Microdrive-Emulators. Anders als bereits existierende "neuzeitliche" Massenspeicher-Lösungen für den //Spectrum// und //QL//, geht es hierbei um eine völlig transparente und "historisch korrekte" Emulation der Microdrives. D.h. bei Nutzung des Emulators soll kein Unterschied zur Nutzung echter Microdrives bestehen. Daher setzt die Emulation auf Hardware-Ebene am Microdrive-Interface an und verzichtet auf System Hooks auf dem //Spectrum/QL//. Heute ist es umso schwieriger, mit einem Microdrive zu arbeiten. Insbesondere die Bandkassetten sind oftmals nicht mehr nutzbar. Das motivierte den Bau eines Microdrive-Emulators. Anders als bereits existierende "neuzeitliche" Massenspeicher-Lösungen für den //Spectrum// und //QL//, geht es hierbei um eine völlig transparente und "historisch korrekte" Emulation der Microdrives. D.h. bei Nutzung des Emulators soll kein Unterschied zur Nutzung echter Microdrives bestehen. Daher setzt die Emulation auf Hardware-Ebene am Microdrive-Interface an und verzichtet auf System Hooks auf dem //Spectrum/QL//.
Zeile 18: Zeile 18:
 ==== Das Original ==== ==== Das Original ====
  
-{{:oq-cartridge_and_case.jpg?250 |Microdrive-Kassette aus QL Software Suite}}+{{:oq-cartridge_and_case.jpg?250&direct |Microdrive-Kassette aus QL Software Suite}}
  
 ^ Hersteller | Sinclair Research | ^ Hersteller | Sinclair Research |
Zeile 27: Zeile 27:
 ^ Technologie | Endlos-Magnetband | ^ Technologie | Endlos-Magnetband |
 ^ Kapazität | max. 128KB, typ. 70-80KB | ^ Kapazität | max. 128KB, typ. 70-80KB |
-^ Band | 1,9mm x 5m |+^ Band | 1,9mm x 5m, 76cm/|
 ^ Format | 2 Spuren | ^ Format | 2 Spuren |
  
Zeile 35: Zeile 35:
 ^ Hardware | //Arduino Nano// | ^ Hardware | //Arduino Nano// |
 ^ Software | Firmware in //C//, Daemon in //Golang//, Web-UI basierend auf //Bootstrap// | ^ Software | Firmware in //C//, Daemon in //Golang//, Web-UI basierend auf //Bootstrap// |
-^ Projekt-Seite | [[https://github.com/xelalexv/oqtadrive|GitHub]] |+^ Projekt-Seite | [[https://oqtadrive.org|Home]], [[https://codeberg.org/xelalexv/oqtadrive|Codeberg]] |
 ^ Mitwirkende | Alexander Vollschwitz (Entwickler/Maintainer), Tom Dalby (Leiterplatten, Gehäuse, Tests), Stephan Preuß (Tests) | ^ Mitwirkende | Alexander Vollschwitz (Entwickler/Maintainer), Tom Dalby (Leiterplatten, Gehäuse, Tests), Stephan Preuß (Tests) |
 ^ Lizenz | GPL-3.0 | ^ Lizenz | GPL-3.0 |
  
-{{:oq-family.jpg?680|Familientreffen}}+{{ :oq-family.jpg?680&direct |Familientreffen}}
  
 Hier einige Mitglieder der "//OqtaDrive//-Familie" (gebaut von [[https://www.tomdalby.com/|Tom Dalby]]) - links und hinten Standalone-Lösungen in Original- und 3D-Druck-Gehäuse, vorn Minimal-Konfiguration für Verbindung mit PC Hier einige Mitglieder der "//OqtaDrive//-Familie" (gebaut von [[https://www.tomdalby.com/|Tom Dalby]]) - links und hinten Standalone-Lösungen in Original- und 3D-Druck-Gehäuse, vorn Minimal-Konfiguration für Verbindung mit PC
Zeile 47: Zeile 47:
 ==== Ansatz ==== ==== Ansatz ====
  
-{{ ::oq-inside.jpg?320|Innenleben (QL)}}+{{ :oq-inside.jpg?320&direct|Innenleben (QL)}} 
 Die Technik des Microdrives faszinierte mich schon immer sehr. Insbesondere hatte es mir der Ansatz angetan, mit Komponenten aus der Massenproduktion anderer Produkte (z.B. Tonkopf von Kassettenrecorder als Schreib-/Lesekopf) eine günstige Lösung zu bauen, die es dennoch mit den damals gängigen aber deutlich teureren Diskettenlaufwerken -halbwegs- aufnehmen konnte. Der Emulator sollte ganz in diesem Geiste auch mit möglichst wenigen und günstigen Komponenten entstehen. Die Technik des Microdrives faszinierte mich schon immer sehr. Insbesondere hatte es mir der Ansatz angetan, mit Komponenten aus der Massenproduktion anderer Produkte (z.B. Tonkopf von Kassettenrecorder als Schreib-/Lesekopf) eine günstige Lösung zu bauen, die es dennoch mit den damals gängigen aber deutlich teureren Diskettenlaufwerken -halbwegs- aufnehmen konnte. Der Emulator sollte ganz in diesem Geiste auch mit möglichst wenigen und günstigen Komponenten entstehen.
  
 Der //Arduino Nano// erschien mir da genau richtig und, falls irgend möglich, sollte er auch die einzige größere Hardware-Komponente sein, abgesehen von evtl. einigen Widerständen, Dioden oder Steckern. Dieses Ziel formte die Struktur von //OqtaDrive//: Der //Nano// fungiert als Protokoll-Konverter zwischen dem Microdrive-Interface und einem Daemon-Prozess, der auf einem beliebigen Rechner laufen kann und dort die Microdrive-Daten verwaltet. Der Vorteil hierbei ist zum einen, dass auf Speicherkomponenten (z.B. SD-Card-Leser) als auch auf UI-Komponenten zur Bedienung (LCD, Knöpfe) verzichtet werden kann, da sich der Daemon problemlos vom Daemon-Host aus steuern lässt. Zum anderen ergeben sich dadurch, dass der Daemon-Host für gewöhnlich mit einem Netzwerk verbunden ist, interessante Möglichkeiten für die Nutzung des Emulators und den weiteren Ausbau. Der //Arduino Nano// erschien mir da genau richtig und, falls irgend möglich, sollte er auch die einzige größere Hardware-Komponente sein, abgesehen von evtl. einigen Widerständen, Dioden oder Steckern. Dieses Ziel formte die Struktur von //OqtaDrive//: Der //Nano// fungiert als Protokoll-Konverter zwischen dem Microdrive-Interface und einem Daemon-Prozess, der auf einem beliebigen Rechner laufen kann und dort die Microdrive-Daten verwaltet. Der Vorteil hierbei ist zum einen, dass auf Speicherkomponenten (z.B. SD-Card-Leser) als auch auf UI-Komponenten zur Bedienung (LCD, Knöpfe) verzichtet werden kann, da sich der Daemon problemlos vom Daemon-Host aus steuern lässt. Zum anderen ergeben sich dadurch, dass der Daemon-Host für gewöhnlich mit einem Netzwerk verbunden ist, interessante Möglichkeiten für die Nutzung des Emulators und den weiteren Ausbau.
 +
 ==== Aufzeichnungsformat ==== ==== Aufzeichnungsformat ====
  
-{{ :oq-bits.jpg?320|1 und 0 Bits}}+{{ :oq-bits.jpg?320&direct|1 und 0 Bits}}
  
 Zunächst einmal musste ich aber herausfinden, wie das Microdrive Daten aufzeichnet, um dann abzuschätzen, ob das ganze mit einem //Nano// auch tatsächlich umsetzbar ist. Es gibt hierzu einiges an Information. Aber es macht natürlich auch Spaß, das verfügbare mit eigenen Nachforschungen anzureichern. Angefangen habe ich mit dem //Spectrum//. Ich hab mir hier die Signale am Microdrive-Port des //Interface 1// beim Formatieren einer Kassette angeschaut. Die Daten werden mithilfe des oben erwähnten Stereo-Kassetten-Tonkopfs auf zwei Spuren geschrieben, abwechselnd ein Byte in die eine, eines in die andere Spur. Die Bytes sind dabei um 4 Bit gegeneinander verschoben. Ein Bit dauert 12µs. Eine 0 wird durch einen gleichbleibenden Pegel signalisiert (ca. 41kHz), eine 1 durch einen Pegelwechsel nach 6µs (ca. 83kHz). Zunächst einmal musste ich aber herausfinden, wie das Microdrive Daten aufzeichnet, um dann abzuschätzen, ob das ganze mit einem //Nano// auch tatsächlich umsetzbar ist. Es gibt hierzu einiges an Information. Aber es macht natürlich auch Spaß, das verfügbare mit eigenen Nachforschungen anzureichern. Angefangen habe ich mit dem //Spectrum//. Ich hab mir hier die Signale am Microdrive-Port des //Interface 1// beim Formatieren einer Kassette angeschaut. Die Daten werden mithilfe des oben erwähnten Stereo-Kassetten-Tonkopfs auf zwei Spuren geschrieben, abwechselnd ein Byte in die eine, eines in die andere Spur. Die Bytes sind dabei um 4 Bit gegeneinander verschoben. Ein Bit dauert 12µs. Eine 0 wird durch einen gleichbleibenden Pegel signalisiert (ca. 41kHz), eine 1 durch einen Pegelwechsel nach 6µs (ca. 83kHz).
  
-{{:oq-first-contact.png?400 |Ein erster Erfolg}}+{{:oq-first-contact.png?400&direct |Ein erster Erfolg}}
  
 Weiter ging es dann mit dem logischen Format. Hier war das [[https://worldofspectrum.org/archive/books/spectrum-microdrive-book|Spectrum Microdrive Book]] von Ian Logan besonders hilfreich. Organisiert ist das Band in bis zu 254 Sektoren. Jeder Sektor besteht aus einem 27 Byte Header und einem 540 Byte Daten-Record, jeweils getrennt durch kurze Pausen (3,75ms nach Header, 7,0ms nach Record). Hier lag die größte Herausforderung: Der RAM des //Nano// (2KB) reicht bei weitem nicht, alle Sektoren einer Kassette aufzunehmen (144KB). Somit müssen die Daten kontinuierlich zwischen //Nano// und Daemon ausgetauscht werden. Bei einer Datenrate von 1Mb/s über die serielle Verbindung ist das rein rechnerisch möglich. Zum Glück zeigten meine ersten Versuche, dass die Verbindung bei dieser Geschwindigkeit auch stabil ist. Nach einigen Experimenten war es dann soweit - ich konnte alle Sektoren eines Format-Vorgangs korrekt empfangen. Weiter ging es dann mit dem logischen Format. Hier war das [[https://worldofspectrum.org/archive/books/spectrum-microdrive-book|Spectrum Microdrive Book]] von Ian Logan besonders hilfreich. Organisiert ist das Band in bis zu 254 Sektoren. Jeder Sektor besteht aus einem 27 Byte Header und einem 540 Byte Daten-Record, jeweils getrennt durch kurze Pausen (3,75ms nach Header, 7,0ms nach Record). Hier lag die größte Herausforderung: Der RAM des //Nano// (2KB) reicht bei weitem nicht, alle Sektoren einer Kassette aufzunehmen (144KB). Somit müssen die Daten kontinuierlich zwischen //Nano// und Daemon ausgetauscht werden. Bei einer Datenrate von 1Mb/s über die serielle Verbindung ist das rein rechnerisch möglich. Zum Glück zeigten meine ersten Versuche, dass die Verbindung bei dieser Geschwindigkeit auch stabil ist. Nach einigen Experimenten war es dann soweit - ich konnte alle Sektoren eines Format-Vorgangs korrekt empfangen.
  
 ==== Prototypen ==== ==== Prototypen ====
 +
 Nach dem ersten Erfolg in der Kommunikation mit dem Microdrive-Interface kam eine lange Phase der Prototypen, sowohl bei der Hardware als auch bei der Firmware für den //Nano// und der Daemon-Software. Über viele Iterationen und Refactorings hinweg entstand allmählich eine erste Version des Emulators, der alle Features des Microdrive -zunächst nur für den //Specturm//- abbilden konnte. Nach dem ersten Erfolg in der Kommunikation mit dem Microdrive-Interface kam eine lange Phase der Prototypen, sowohl bei der Hardware als auch bei der Firmware für den //Nano// und der Daemon-Software. Über viele Iterationen und Refactorings hinweg entstand allmählich eine erste Version des Emulators, der alle Features des Microdrive -zunächst nur für den //Specturm//- abbilden konnte.
  
-{{:oq-prototypes.jpg?420 |Die ersten zwei Prototypen}}{{ :oq-prototype-3b.jpg?224|Prototyp 3}} +{{:oq-prototypes.jpg?420&direct |Die ersten zwei Prototypen}}{{ :oq-prototype-3b.jpg?224&direct|Prototyp 3}} 
-{{:oq-patched-prototype.jpg?224 |Erweiterungen}}{{ :oq-prototype-2.jpg?360|Prototyp 2}}+{{:oq-patched-prototype.jpg?224&direct |Erweiterungen}}{{ :oq-prototype-2.jpg?360&direct|Prototyp 2}}
  
 ==== Support für den QL ==== ==== Support für den QL ====
 +
 Auf die Prototyp-Phase folgte aufgrund geänderter Prioritäten eine längere Pause. Anfang 2021 regten mich jedoch [[https://worldofspectrum.org/forums/discussion/58474/strange-microdrive-format|zwei]] [[https://worldofspectrum.org/forums/discussion/58258/microdrive-logic-flow|Diskussionen]] auf //World of Spectrum// dazu an, die Arbeit am Projekt wieder aufzunehmen und es auf einen Stand zu bringen, der eine Veröffentlichung erlaubte. Der größte noch offene Punkt war, auch den //Sinclair QL// zu unterstützen. Mein Ziel war dabei, eine separate Variante des Emulators zu vermeiden. D.h. ein und derselbe Adapter sollte sowohl mit //Spectrum// als auch //QL// arbeiten können, idealerweise mit //auto detect//. Auf die Prototyp-Phase folgte aufgrund geänderter Prioritäten eine längere Pause. Anfang 2021 regten mich jedoch [[https://worldofspectrum.org/forums/discussion/58474/strange-microdrive-format|zwei]] [[https://worldofspectrum.org/forums/discussion/58258/microdrive-logic-flow|Diskussionen]] auf //World of Spectrum// dazu an, die Arbeit am Projekt wieder aufzunehmen und es auf einen Stand zu bringen, der eine Veröffentlichung erlaubte. Der größte noch offene Punkt war, auch den //Sinclair QL// zu unterstützen. Mein Ziel war dabei, eine separate Variante des Emulators zu vermeiden. D.h. ein und derselbe Adapter sollte sowohl mit //Spectrum// als auch //QL// arbeiten können, idealerweise mit //auto detect//.
  
-{{ ::oq-ql-format-dir.png?400|Erster Erfolg mit dem QL}}+{{:oq-ql-format-dir.png?400&direct |Erster Erfolg mit dem QL}}
  
 Dafür ging es nochmal zurück ans Forschen und Experimentieren. Denn es zeigte sich schnell, dass es doch einige Unterschiede zwischen //Spectrum//- und //QL//-Microdrive gibt - angefangen bei einer höheren Datenrate (50/100kHz), vertauschten Spuren und kürzeren Pausen nach Header und Record, über eine geänderte logische Struktur der Sektoren bis hin zu einem gänzlich anderen Format-Prozedere gab es einige Überraschungen. //OqtaDrive//s Architektur erwies sich dabei jedoch als recht hilfreich, denn viele der notwendigen Anpassungen konnten im Daemon adressiert werden, was bzgl. der Softwareentwicklung deutlich einfacher ist. Irgendwann war es dann soweit - das erste erfolgreiche Formatieren. Dafür ging es nochmal zurück ans Forschen und Experimentieren. Denn es zeigte sich schnell, dass es doch einige Unterschiede zwischen //Spectrum//- und //QL//-Microdrive gibt - angefangen bei einer höheren Datenrate (50/100kHz), vertauschten Spuren und kürzeren Pausen nach Header und Record, über eine geänderte logische Struktur der Sektoren bis hin zu einem gänzlich anderen Format-Prozedere gab es einige Überraschungen. //OqtaDrive//s Architektur erwies sich dabei jedoch als recht hilfreich, denn viele der notwendigen Anpassungen konnten im Daemon adressiert werden, was bzgl. der Softwareentwicklung deutlich einfacher ist. Irgendwann war es dann soweit - das erste erfolgreiche Formatieren.
  
 ==== Open Sourcing ==== ==== Open Sourcing ====
-Anfang Mai 2021 war dann der Support für den //QL// vollständig, und der Adapter konnte wie angestrebt automatisch zwischen //Spectrum// und //QL// unterscheiden. Nach vielen Refactorings war die Codebasis auch soweit "aufgeräumt", dass eine Veröffentlichung auf [[https://github.com/xelalexv/oqtadrive|GitHub]] möglich war. Auf diesem Weg gewann //OqtaDrive// auch die ersten Mitstreiter.+ 
 +{{ ::oq-pcbs.jpg?300&direct|Von Standalone bis Micro}} 
 + 
 +Anfang Mai 2021 war dann der Support für den //QL// vollständig, und der Adapter konnte wie angestrebt automatisch zwischen //Spectrum// und //QL// unterscheiden. Nach vielen Refactorings war die Codebasis auch soweit "aufgeräumt", dass eine [[https://codeberg.org/xelalexv/oqtadrive|Veröffentlichung]] möglich war. Es war mir von Anfang an ein Anliegen, das Projekt unter einer freien Lizenz verfügbar zu machen, so dass ein Nachbau für alle Interessierten möglich ist. 
 + 
 +Durch die Veröffentlichung gewann //OqtaDrive// auch die ersten Mitstreiter. Tom Dalby hat mehrere Leiterplatten und 3D-Druck-Gehäuse für den Aufbau in unterschiedlichen Konfigurationen entwickelt - von //Standalone// mit //RaspberryPi Zero// an Bord bis hin zu einer minimalen Micro-Version. Stephan Preuß hat unermüdlich viele Pre-Releases getestet, auf //Spectrum// und //QL//, und einiges an Fehlern gefunden. Wichtig waren aber auch die Diskussionen, die sich über die Zusammenarbeit ergaben. So hatte ich z.B. einer //Standalone//-Konfiguration mit Steuerung über ein Web-UI ursprünglich keine besondere Aufmerksamkeit geschenkt. Durch Toms und Stephans Vorschläge und freundliches Insistieren ist es heute meine favorisierte Konfiguration :-D 
 ===== Status ===== ===== Status =====
  
Zeile 88: Zeile 98:
   * Kassetten-Abbilder und Snapshots können auf dem Daemon-Host abgelegt und von jedem Client aus gesucht & geladen werden   * Kassetten-Abbilder und Snapshots können auf dem Daemon-Host abgelegt und von jedem Client aus gesucht & geladen werden
   * Auflisten der virtuellen Laufwerke und der Inhalte von Kassetten   * Auflisten der virtuellen Laufwerke und der Inhalte von Kassetten
 +  * optional Ansteuerung eines Vibrationsmotors um auch den originalen Sound zu emulieren ;-)
   * Installations-Skript für Linux   * Installations-Skript für Linux
 +
 +{{ :oq-standalone.jpg?640&direct |}}
 ===== Virtueller Ausstellungstisch ===== ===== Virtueller Ausstellungstisch =====
  
-[[:hier_link_einfuegen|Zum virtuellen Ausstellungstisch]]+{{ ::oq-micro.jpg?280&direct|Micro}}
  
-Hier wird stehen, zu welchen Zeiten die virtuelle Ausstellung für Fragen, Diskussionen und allgemeinen Plausch geöffnet ist.+[[https://bbb.vcfb.de/b/xel-c5e-y6s-m3u|Zum virtuellen Ausstellungstisch]]
  
 ==== Anwesenheitszeiten ==== ==== Anwesenheitszeiten ====
  
 ^ Tag       ^ Uhrzeit          ^ ^ Tag       ^ Uhrzeit          ^
-|Samstag     00:00 - 00:00  | +|Samstag     10:00 - 12:30 / 13:30 19:00 | 
-|Samstag     | 00:00 00:00  | +|Sonntag     10:00 - 18:00 |
-| | +
-|Sonntag     00:00 - 00:00  | +
-|Sonntag     | 00:00 - 00:00  | +
  
 ==== Vorführungszeiten ==== ==== Vorführungszeiten ====
  
-Falls es neben allgemeinem Plausch am Ausstellungstisch auch spezielle Vorführungszeiten geben wird, können diese hier eingetragen werden.+{{ ::oq-config-internal.jpg?400&direct|Intern in Interface 1}} 
 +{{ ::oq-config-external.jpg?400&direct|Standalone}} 
 + 
 +Noch gibt es keinen Plan für feste Vorführungszeiten. Wir entscheiden einfach je nach Besucherzahl und Interesse. Gezeigt und vorgeführt werden die originalen Microdrives und verschiedene //OqtaDrive//-KonfigurationenIch habe auch vor, einen //OqtaDrive//-Adapter live zusammen zubauen :-P  
  
 ^ Tag       ^ Uhrzeit          ^  Demo          ^ ^ Tag       ^ Uhrzeit          ^  Demo          ^
 |Samstag     | xx:xx  | xxx | |Samstag     | xx:xx  | xxx |
-|Samstag     | xx:xx  | yyy | 
-| | | | 
-|Sonntag     | xx:xx  | xxx | 
 |Sonntag     | xx:xx  | yyy | |Sonntag     | xx:xx  | yyy |
oqtadrive.1632406725.txt.gz · Zuletzt geändert: 2021/09/23 16:18 von xelalex