5,25" Floppy aus DDR-Produktion...
Thomas Stein
Am Wochenende habe ich wieder mal meine Ramschkiste durchstöbert und
dabei ein etwas merkwürdiges Floppy-Laufwerk gefunden:
Baugröße 5,25"
Platinen darauf von TEAC
Schwarze Frontblende
Auf der Rückseite ein silberner Aufkleber mit schwarzer Schrift:
K 5601 / CM 5643 | VEB ROBOTRON -
FABR.-NR. 199012 | BUCHUNGSMASCHINENWERK
HERGESTELLT IN DER DDR | KARL - MARX - STADT
Kennt jemand von euch dieses Laufwerk? Ist das ein Standard 1,2MByte
Floppy? (Ich wolllte schon immer mal DDR-Technik in meinem PC haben *g*)
MfG
Thomas Stein
P.S.: Auf der Unterseite des Laufwerks befinden sich mehrere Jumper,
leider habe ich keine Belegungstabelle :-(
Gerhard Lenerz
> Kennt jemand von euch dieses Laufwerk? Ist das ein Standard 1,2MByte
> Floppy? (Ich wolllte schon immer mal DDR-Technik in meinem PC haben *g*)
Teac hat "drüben" auch produziert?
Gerhard:wq
--
No signature today!
Martin Etteldorf
>
> On Sun, 23 Sep 2001 18:49:32 +0200, Thomas Stein wrote:
>> Kennt jemand von euch dieses Laufwerk? Ist das ein Standard 1,2MByte
>> Floppy? (Ich wolllte schon immer mal DDR-Technik in meinem PC haben *g*)
>
Noe, aber Robotron hat "drueben" (von deren Seite aus gesehen) einge-
kauft <8)
Martin.
Thomas Stein
> On Sun, 23 Sep 2001 18:49:32 +0200, Thomas Stein wrote:
>> Kennt jemand von euch dieses Laufwerk? Ist das ein Standard 1,2MByte
>> Floppy? (Ich wolllte schon immer mal DDR-Technik in meinem PC haben
>> *g*)
>
> Teac hat "drüben" auch produziert?
>
Mich wundert das auch, aber auf den Platinen ist deutlich TEAC zu
lesen, außerdem auf dem Metallrahmen (Aluminium), der die ganze
Mechanik/Elektronik trägt. Vielleicht wurden die Teile ja importiert...
MfG
Thomas Stein
Holger Krull
ja dir DDR ein "fortschrittliches" Land war,
musste zu Ablenkung der Arbeiter und Bauern ein robotron-Aufkleber drauf....
Gruß
Holger
"Thomas Stein" <tst...@fh-lausitz.de> schrieb im Newsbeitrag
news:hp5lo9...@ID-62875.user.dfncis.de...
Thomas Stein
Ich habe auf http://www.robotron-net.de einen Link zu einer
Beschreibung des Laufwerks gefunden. Es handelt sich um ein Floppy für
den KC85. Die Speicherkapazität der Disketten wird mit maximal 800KByte
angegeben. Was ist das für ein Format? Kann ich das Laufwerk in meinem
PC (AMD Athlon 900 MHz, ich weiß, arg off-topic) betreiben?
MfG
Thomas Stein
Marco Nuessgen
Marco Nuessgen
Also, in dem Artikel wurde beschrieben, dass eine einfache Suchanfrage
("Deckname des Spions") erst nach bis zu einer 3/4 Std das Ergebnis
(Personendaten) brachte. Auf den abgebildeten Fotos waren "normal"
aussehende 19Zoll-Schraenke zu sehen (mit blauem Dekor), jede Menge
Tape-Laufwerke, ein paar Zeilendrucker. Es wurde noch berichtet, dass
von dieser Maschinenserie nur noch ein Rechner ueberlebt hat. Der
vorletzte wurde von der Bundeswehr verschrottet, weil die Jungs nicht
schlau genug waren um die Baender zu entschluesseln. Mich wuerde am
meissten die Technologie der Maschinen interessieren. Ein plumper
Nachbau kann es ja nicht sein. Ich erinnere mich noch gelesen zu haben,
dass dieses Rechnermodell der Stolz des Ostblocks war, da jedes
Mitgliedsland etwas dazu beigetragen hat. Die Platten kamen z.B. aus
Ungarn. Die sahen stark nach DEC-Waschmaschine aus.
Gruss,
Marco.
Axel Schwenke
Thomas Stein <tst...@fh-lausitz.de> writes:
> Nachtrag:
>
> Ich habe auf http://www.robotron-net.de einen Link zu einer
> Beschreibung des Laufwerks gefunden. Es handelt sich um ein Floppy für
> den KC85.
Dafür wurde es u.a. verwendet. Allerdings nicht nur. Es ist mechanisch
und elektrisch weitgehend kompatibel zum FD-55FV von TEAC[1]. Und dazu
gibt es noch Datenblätter bei TEAC. Eine Jumperbelegung habe ich noch
in einer alten MP[2], falls du die brauchst.
> Die Speicherkapazität der Disketten wird mit maximal 800KByte
> angegeben. Was ist das für ein Format?
Das ist das Maximum, was man aus einer DD/DS Floppy rausholen kann.
2 Seiten x 80 Spuren x 5 Sektoren a 1024 Byte
Ganz mutige haben noch einen weiteren Sektor mit 256 Byte auf der
Spur untergebracht. Das war aber eher ein Lotteriespiel. Wenn das
schreibende Laufwerk ein bischen zu schnell drehte, konnte man sich
so prima den Anfang des ersten Sektors überschreiben...
> Kann ich das Laufwerk in meinem
> PC (AMD Athlon 900 MHz, ich weiß, arg off-topic) betreiben?
Sicher. Als 5 1/4 Zoll DD Laufwerk mit 360KB :-/
Mit einem Betriebssytem (z.B. Linux) auch 800KB.
[1] Tatsächlich wurden in einige Chargen der Bürocomputer von Robotron
Original-TEAC verbaut, bis man die Fertigung der Mechanik selber
im Griff hatte. Später wurden nur noch die Platinen eingekauft,
ganz zum Schluß nur noch die Chips für die Platinen.
[2] Mikroprozessortechnik. Sozusagen die iX der DDR ;-)
XL
--
|-----------------------------------------------------------------------|
| Axel Schwenke, Systemadministrator @ jobpilot AG |
| www.jobpilot.{at,be,ch,cz,de,dk,es,fr,hu,it,net,nl,no,pl,se,co.uk...} |
|_____ Linux is like a Wigwam: no Windows, no Gates, Apache inside _____|
Gerhard Lenerz
Mir fällt da nur was ein, wovor ich selbst schon gestanden habe:
http://www.hnf.de/museum/eser.html
Gerhard:wq
Thomas Stein
> Es ist mechanisch und elektrisch weitgehend kompatibel zum FD-55FV
> von TEAC[1]. Und dazu gibt es noch Datenblätter bei TEAC. Eine
> Jumperbelegung habe ich noch in einer alten MP[2], falls du die
> brauchst.
Nehm ich gern. Kannst Du mir das einscannen? Bei TEAC habe ich nach 3
Stunden Suche aufgegeben...
>> Kann ich das Laufwerk in meinem
>> PC (AMD Athlon 900 MHz, ich weiß, arg off-topic) betreiben?
>
> Sicher. Als 5 1/4 Zoll DD Laufwerk mit 360KB :-/
> Mit einem Betriebssytem (z.B. Linux) auch 800KB.
Was für Disketten muß ich dann verwenden? Und wie muß das Laufwerk im
BIOS anmelden? Als 360KByte oder als 1.2MByte?
MfG
Thomas Stein
Axel Schwenke
Thomas Stein <tst...@fh-lausitz.de> writes:
> Axel Schwenke <schw...@jobpilot.de> schrieb:
>> Es ist mechanisch und elektrisch weitgehend kompatibel zum FD-55FV
>> von TEAC[1]. Und dazu gibt es noch Datenblätter bei TEAC. Eine
>> Jumperbelegung habe ich noch in einer alten MP[2], falls du die
>> brauchst.
>
> Nehm ich gern. Kannst Du mir das einscannen? Bei TEAC habe ich nach 3
> Stunden Suche aufgegeben...
http://www.teac.com/DSPD/pdf/5fd0020a.pdf
(TEAC USA -> Data Storage -> Support -> Manuals)
Nicht daß dir das wirklich weiterhelfen würde...
Aber ich werde mal in den alten Zeitschriften stöbern gehen.
>>> Kann ich das Laufwerk in meinem
>>> PC (AMD Athlon 900 MHz, ich weiß, arg off-topic) betreiben?
>>
>> Sicher. Als 5 1/4 Zoll DD Laufwerk mit 360KB :-/
>> Mit einem Betriebssytem (z.B. Linux) auch 800KB.
>
> Was für Disketten muß ich dann verwenden?
Das schrob ich doch schon. DS/DD = double sided, double density
und 5 1/4 Zoll natürlich ;-) Also das typische C64-Futter
HD-Disketten gehen übrigens definitiv *nicht*
> Und wie muß das Laufwerk im
> BIOS anmelden? Als 360KByte oder als 1.2MByte?
Auch das schrob ich bereits: 360K (IBM schreibt nur 4.5KB pro Spur
und außerdem nur 40 Spuren). Extra deswegen gibt es einen "XT" Jumper
auf dem Laufwerk, damit es Doppelschritte macht. Außerdem wird in PCs
(aus Sparsamkeit) nicht voll decodiert, so daß von ursprünglich mal
4 möglichen Laufwerken gerade mal 2 bleiben. Durch den üblen Trick mit
den verdrehten Adern im Kabel werden zudem noch alle Drives auf die
gleiche ID (IIRC 1) gejumpert. Ein /MO (Motor On) gibts im PC auch
nicht -> Motorsteuerung auf /SELECT jumpern.
AFAIK gibt es noch einen Treiber (für DCP 3.30 = MS-DOS 3.30) von
robotron, um auch abweichende Formate lesen zu können. Schau mal auf
www.robotron-net.de. Ansonsten natürlich noch anadisk & Konsorten.
Axel Schwenke
Gerhard Strangar <ger...@brue.net> writes:
> Axel Schwenke wrote:
>
>> Sicher. Als 5 1/4 Zoll DD Laufwerk mit 360KB :-/
>> Mit einem Betriebssytem (z.B. Linux) auch 800KB.
>
Da fehlt ein Smiley.
Wenn nicht - Ketzer!
;-)
> Mit Kernel 2.2.14 konnte ich jedenfalls überformatierte Disketten nur
> dann benutzen, wenn mir das Format bekannt war. Ein einfaches mount
> /floppy führte zwar zu schönen Effekten, aber die Daten waren nicht
> lesbar.
Autosensing beim Diskettenformat will man nicht wirklich. Deswegen
gibts ja so viele Aliases /dev/fdXdyyy.
Marc-Jano Knopp
> In article <ar8lo9...@id-62875.user.dfncis.de>,
> Thomas Stein <tst...@fh-lausitz.de> writes:
>> Nachtrag:
>> Die Speicherkapazität der Disketten wird mit maximal 800KByte
>> angegeben. Was ist das für ein Format?
> Das ist das Maximum, was man aus einer DD/DS Floppy rausholen kann.
> 2 Seiten x 80 Spuren x 5 Sektoren a 1024 Byte
[...]
>> Kann ich das Laufwerk in meinem
>> PC (AMD Athlon 900 MHz, ich weiß, arg off-topic) betreiben?
>
> Sicher. Als 5 1/4 Zoll DD Laufwerk mit 360KB :-/
[...]
Hmm.... driver.sys? (Oder wie dat Ding hieß...)
Marc-Jano
Gerhard Lenerz
> Gerhard Lenerz <lene...@uni-trier.de> wrote:
>> Teac hat "dr?ben" auch produziert?
>
> Noe, aber Robotron hat "drueben" (von deren Seite aus gesehen) einge-
> kauft <8)
Dachte ich mir... ich hätte den Smilie wohl deutlicher schreiben
sollen, oder?
Gerhard:wq
Marco Nuessgen
Gerhard Lenerz wrote:
[...]
> Mir fällt da nur was ein, wovor ich selbst schon gestanden habe:
> http://www.hnf.de/museum/eser.html
So habe ich die in Erinnerung. Ich werd wohl doch mal zum HNF fahren.
Danke fuer den link.
Gruss,
Marco.
Mario Klebsch
>Axel Schwenke wrote:
>> Autosensing beim Diskettenformat will man nicht wirklich. Deswegen
>> gibts ja so viele Aliases /dev/fdXdyyy.
>Woher will man denn wissen, welches Format die Diskette hat, soll man es
>vielleicht auf die Hülle schreiben?
Das Format der Diskette ist i.d.R. vollkommen egal, es kommt auf das
Format des auf der Diskette gespeicherten Filesystems an. Du kannst
z.B. eine Diskette mit 10 Sektoren pro Seite formatieren, und dennoch
nur neun davon für das Filesystem benutzen.
73, Mario
--
Mario Klebsch ma...@klebsch.de
PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB 1483 30CE 9FB2 A047 9CE0
Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5 8B98 9464 53FF 9382 F518
Thomas Stein
> In article <nabno9...@id-62875.user.dfncis.de>,
> Thomas Stein <tst...@fh-lausitz.de> writes:
>> Nehm ich gern. Kannst Du mir das einscannen? Bei TEAC habe ich nach 3
>> Stunden Suche aufgegeben...
>
> http://www.teac.com/DSPD/pdf/5fd0020a.pdf
> (TEAC USA -> Data Storage -> Support -> Manuals)
>
> Nicht daß dir das wirklich weiterhelfen würde...
> Aber ich werde mal in den alten Zeitschriften stöbern gehen.
>
Ist nicht mehr nötig, trotzdem Danke! Ein Kumpel mit KC85 hat das
Floppy abgestaubt...
MfG
Thomas Stein
Axel Schwenke
Gerhard Strangar <ger...@brue.net> writes:
> Axel Schwenke wrote:
>
>> Autosensing beim Diskettenformat will man nicht wirklich. Deswegen
>> gibts ja so viele Aliases /dev/fdXdyyy.
>
> vielleicht auf die Hülle schreiben?
Ich weiß ja nicht, wie viele Diskettenformate du verwendest. Aber ich
kann eigentlich ganz gut zwischen den Standard-Dingern und den 800KB
CP/A Disketten unterscheiden. Außer zum nostalgischen Stöbern in alten
Schätzen verwende *ich* sowas jedenfalls nicht.
Und - wenn es funktioniert - ist Autosensing ja wirklich nett (dann
aber bitte auch Automount), nur in der Praxis funktionierts halt nicht.
>> |_____ Linux is like a Wigwam: no Windows, no Gates, Apache inside _____|
> ^^^^^^^^
> <haarspalt>
> Apache ist nicht Bestandteil von Linux, und Linux hat sehr wohl Gates:
> Call-Gates und Interrupt-Gates.
> </haarspalt>
Aber keine Bill-Gates. Und abgesehen davon <weinerlich> mach ich dir
etwa deine Sig kaputt? </weinerlich> <trotzig> Jetzt geb ich dir meine
Sandförmchen nicht mehr. Bäh! </trotzig> ;-)
Christian Corti
>> Sicher. Als 5 1/4 Zoll DD Laufwerk mit 360KB :-/
>> Mit einem Betriebssytem (z.B. Linux) auch 800KB.
> Was für Disketten muß ich dann verwenden? Und wie muß das Laufwerk im
> BIOS anmelden? Als 360KByte oder als 1.2MByte?
Weder noch. Als 3,5" 720kB. Das Format ist identisch zu 5,25" QD.
Wenn wir schon mal bei Laufwerken, BIOS usw. sind, hier eine ewige Frage:
Gibt es einen DOS-Treiber, um sekundäre Floppycontroller an Adresse $370
(IRQ und DMA wie beim primären) zu betreiben? DRIVER.SYS funktioniert nicht
mit sekundären FDCs! Muß ich mir wirklich selber einen Treiber schreiben?
Christian
Heiko Nocon
wrote:
>Das Format der Diskette ist i.d.R. vollkommen egal, es kommt auf das
>Format des auf der Diskette gespeicherten Filesystems an. Du kannst
>z.B. eine Diskette mit 10 Sektoren pro Seite formatieren, und dennoch
>nur neun davon für das Filesystem benutzen.
Nur sehr, sehr dumme Filesysteme sind auf ein bestimmtes physikalisches
Sektorformat festgelegt. Selbst das nicht gerade anspruchsvolle FAT12
kann _im Prinzip_ beliebige Geometrien voll nutzen.
Joerg Wunsch
> Ich habe auf http://www.robotron-net.de einen Link zu einer
> Beschreibung des Laufwerks gefunden. Es handelt sich um ein Floppy
> für den KC85.
Es ist ein DD-Laufwerk, hat aber im Gegensatz zu den
5.25"-DD-Laufwerken des IBM-PC 80 Zylinder. Bei Standard 512 Byte
Formatierung kommt man also auf 720 KB.
> Die Speicherkapazität der Disketten wird mit maximal 800KByte
> angegeben. Was ist das für ein Format?
80 * 2 * 5 * 1024. Das ist bei Einhaltung normaler Längen für Gap 3
die Maximalformatierung, die man auf einem DD-Medium erreichen kann.
> Kann ich das Laufwerk in meinem
> PC (AMD Athlon 900 MHz, ich weiß, arg off-topic) betreiben?
Das hängt von Deinem Floppytreiber ab, ob er damit umgehen kann. Es
müßte im Prinzip gehen, wenn Du es als 3.5" DD Laufwerk (720 KB)
kennzeichnest, zu dem ist es am ehesten kompatibel. Allerdings dürfte
der Bus zumindest in der bei robotron genutzten Jumperung anders
belegt sein als im PC. Ich bin mir beispielsweise ziemlich sicher,
daß die Laufwerke noch /READY-Signale geliefert haben. Andererseits
sind sie nicht PC-AT-,,optimiert'' mit diesen verdrehten Kabeln, mit
denen man zwischen Laufwerk 0 und 1 auswählen konnte.
Ob Du dann auch 800 KB Medien bearbeiten kannst, hängt vom
Floppytreiber Deines Betriebssystems ab. Das BIOS selbst kann es
nicht, da es nur mit 512 Byte Sektorgröße zurecht kommt.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Juergen Ilse
... wird aber nur das nutzen, was als format im Bootsektor (im "Bios-
Parameterblock" des Bootsektor) angegeben ist ...
Allerdings gibt es auch von dieser Regel (leider!!!) Ausnahmen. Ich
habe mal einen Laufwerkstreiber einer OEM-Version eines MSDOS3.1 (das
war fuer eine Firma namens "Falcom" angepasst worden, von der ich noch
nie vorher gehoert hatte) gepatcht. Die Regeln anch denen versucht wurde
das Diskettenformat zu bestimmen, waren stellenweise wirklich abenteuer-
lich ...
1.) Der Bootsektor wurde ausgelesen. Wenn im Bootsektor
nicht im ersten Byte ein Sprungbefehl der 8086-Maschinen-
sprache (0xE9 oder 0xEB) stand, wurde versucht, das Diket-
tenformat nicht aus den Daten des Bootsektors sondern aus
dem "Diskmediabyte" zu bestimmen, das als erstes Byte der
Fat zu finden war.
2.) Wenn die letzten beiden Bytes des Bootsektors nicht die
Wert 0x55 und 0xAA hatten, wurde nicht der Bootsektor sondern
das Diskmediabyte ausgewertet.
3.) Fuehrte auch der Versuch, das Diskmediabyte auszuwerten
nicht zu einem brauchbaren Ergebnis (weil dort ein "nicht
erkannter" Wert stand), wurde davon ausgegangen, dass es sich
um eine 160KB-Diskette handeln muesse (8 Sektoren/Spur, einseitig).
4.) Da die hoeheren DOS-Funktionen den vom Laufwerkstreiber
bereitgestellten Bios-Parameterblock nur dann ausgewertet
haben, wenn sich das Diskmediabyte gegenueber dem letzten
Aufruf geaendert hat (was das sollte, konnte mir bisher nie-
mand wirklich plausibel erklaeren), musste der Laufwerkstreiber
sicherstellen, dass unterschiedliche formate im Bios-Parameter-
block auch mit unterschiedlichen Diskmediabytes ausgestattet
waren. Da fuer 720KB und 1,2MB Disketten aber der selbe Wert
(0xF9) verwendet wurde, pruefte der Laufwerkstreiber die Anzahl
an Datensektoren auf der Diskette und patchte im Falle einer
1,2MB-Diskette das diskmediabyte von 0xF9 zu 0xF7 (der Wert
0xF8 war fuer Festplatten reserviert) ...
Um diesen Laufwerkstreiber sowie die entsprechenden DOS-Funktionen, die
manchmal den Biosparameterblock nicht ausgewertet haben, dazu zu bringen
auch mit Atari-ST Disketten ordentlich umzugehen, habe ich damals ca.
1 Woche an dem DOS herumgepatcht. Spaeter habe ich mir mal die entspre-
chenden Passagen in einem IBM PC-DOS angesehen, da war das ganze noch
chaotischer (ich weiss, das ist schwer zu glauben, aber es ist war eine
Tatsache, dass die entsprechenden Stellen in PC-DOS 3.1 und PC-DOS 3.2
noch schrecklicher waren ...). Schlimmer kann das in dem DDR-Dois-Clone
garantiert nicht ausgesehen haben.
Tschuess,
Juergen Ilse (il...@asys-h.de)
--
Wenn ich auch nur aus jedem 1000. Bug in einem M$ Produkt|Juergen Ilse
einen Tag trauern wollte, also da muesste ich 300 Jahre |Internet POP Hannover
alt werden und wuerde mehrere Dutzend schwarze Anzuege |Vahrenwalder Str. 205
aufbrauchen. (Detlef Bosau in dcoulm) |30165 Hannover
Joerg Wunsch
> Mich wuerde am meissten die Technologie der Maschinen
> interessieren. Ein plumper Nachbau kann es ja nicht sein.
Nun ja, »plump« ist im Zusammenhang mit dem Nachbau einer DEC- oder
IBM-Maschine sicher ohnehin eine Untertreibung. ;-) Zumal ich von
mehreren Stellen gehört habe, daß in die ersten ES1834 auch noch
original DEC-Karten reingepaßt haben und dort (unter VMS, ähem SVP)
auch liefen.
Wenn es ein Großrechner war, kann es eigentlich nur ein IBM-Clone
gewesen sein.
> Ich erinnere mich noch gelesen zu haben, dass dieses Rechnermodell
> der Stolz des Ostblocks war, da jedes Mitgliedsland etwas dazu
> beigetragen hat.
Das war für praktisch alle RGW-Rechentechnik so. Besonders
belieb^H^H^H^H^H^Hgefürchtet waren die ausfallfreudigen bulgarischen
Fest-/Wechselplattenlaufwerke. :-/
Allerdings waren alle wichtigen Konsumenten nicht auf die selbst
produzierten Rechner angewiesen, sondern die lebten (teilweise) von
COCOM-getunnelten Importen. Das betraf beispielsweise die ganze
Halbleiterindustrie, insofern ist es mehr als unwahrscheinlich, daß
eine wichtige (und infolge Verschlüsselung rechenintensive) Datenbank
des MfS nicht auf einem Importrechner gelaufen wäre.
Joerg Wunsch
> Mit Kernel 2.2.14 konnte ich jedenfalls überformatierte Disketten
> nur dann benutzen, wenn mir das Format bekannt war.
Das ist logisch und normal.
Beschriebene 800 KB Floppies könnte der Treiber sicher auch so noch
unterscheiden (dank 1 KB Sektorierung), da die aber im PC-Bereich fast
niemand benutzt, ist es nicht verwunderlich, daß er davon keine Ahnung
hat. Bei Floppies mit 512 Byte Sektorierung ist es aber praktisch
nicht mehr möglich, eine automatische Formaterkennung von
,,überformatierten'' Disketten vorzunehmen.
Jörg (der zwar kein Linux hat, dafür aber den FreeBSD Floppytreiber
über weite Strecken gepflegt hat / noch pflegt)
Marco Nuessgen
Joerg Wunsch wrote:
[...]
> IBM-Maschine sicher ohnehin eine Untertreibung. ;-) Zumal ich von
> mehreren Stellen gehört habe, daß in die ersten ES1834 auch noch
> original DEC-Karten reingepaßt haben und dort (unter VMS, ähem SVP)
> auch liefen.
Ist das wahr? Meine Guete, das haette ich nicht gedacht. Ich haette
wesentlich mehr eigene Entwicklung erwartet.
[...]
> Allerdings waren alle wichtigen Konsumenten nicht auf die selbst
> produzierten Rechner angewiesen, sondern die lebten (teilweise) von
> COCOM-getunnelten Importen. Das betraf beispielsweise die ganze
> Halbleiterindustrie, insofern ist es mehr als unwahrscheinlich, daß
> eine wichtige (und infolge Verschlüsselung rechenintensive) Datenbank
> des MfS nicht auf einem Importrechner gelaufen wäre.
Hoert sich plausibel an. Der Spiegel erwaehnte trotzdem die angestrengte
Suche nach einem DDR Modell als den einzigen Hoffnungsschimmer um die
Daten auswerten zu koennen.
Den Verschluesselungsalgorithmus hat ein einfacher Mitarbeiter nebenher
herausgefunden. Kann nichts wildes gewesen sein, zumal es eine strenge
Richtlinie gab, dass die Baender nicht kopiert werden durften und das
Ministerium nicht verlassen durften.
Hmm, das enttaeuscht mich jetzt aber. Ich habe da mehr eigene
Entwicklungsarbeit (und eigene Wege) erwartet. Einfach abgekupfert,
baeh.
Weistt Du wie kompatibel dieses SVP war? Was bedeutet die Abkuerzug?
Gruss,
Marco.
Joerg Wunsch
>> Und wie muß das Laufwerk im
>> BIOS anmelden? Als 360KByte oder als 1.2MByte?
> Auch das schrob ich bereits: 360K (IBM schreibt nur 4.5KB pro Spur
> und außerdem nur 40 Spuren). Extra deswegen gibt es einen "XT"
> Jumper auf dem Laufwerk, damit es Doppelschritte macht.
Wenn er es als 720 KB anmeldet, läßt es sich auch als solches benutzen
(allerdings dann keine 360 KB Floppies ohne spezielle Treiber,
schließlich müßte der Treiber ja dann die Doppelschritte machen).
Nicht stören lassen, daß 720 KB nach PeeCee-Meinung den Formfaktor
3.5" hätte, sollte trotzdem tun.
<Haarspalten>
IBM schreibt natürlich 80 Spuren (auf 40 Zylindern).
</Haarspalten>
Joerg Wunsch
>> Autosensing beim Diskettenformat will man nicht wirklich. Deswegen
>> gibts ja so viele Aliases /dev/fdXdyyy.
> Woher will man denn wissen, welches Format die Diskette hat, soll
> man es vielleicht auf die Hülle schreiben?
Verzichte aufs ,,Überformatieren'', und Du bist den Grund zur Klage
los...
Unter CP/M mußte man aber wirklich jedes Format exakt wissen. CP/A
hatte zumindest für wesentliche Formate Autosensing, aber das dürfte
westlich der DDR kaum benutzt worden sein. :)
Joerg Wunsch
> Muß ich mir wirklich selber einen Treiber schreiben?
Kein DOS benutzen. ;-)
Zumindest für FreeBSD behaupte ich mal, daß das tut. Leider konnte
ich's noch nicht verifizieren, weil ich noch keinen FDC gefunden habe,
den ich wirklich sowohl mit IO-Port als auch IRQ als auch DMA umbiegen
konnte.
Christian Corti
> Christian Corti <Christi...@studserv.uni-stuttgart.de> schrieb:
>> Muß ich mir wirklich selber einen Treiber schreiben?
> Kein DOS benutzen. ;-)
Muß/Will ich aber. Ich habe einen DOS-Rechner als Multifunktionstalent
aufgebaut mit 3,5" HD und 5,25" HD am primären Controller, 5,25" DD/QD und
8" SS/DS am sekundären. Außerdem noch Lochstreifenleser und -stanzer (beides
mit DOS-Programmen angesprochen) sowie C1541 über StarCommander.
Wichtig ist bei meinem Rechner auch, daß er bedingungslos
FM-fähig ist, um Daten von RX01, IBM 3740, IBM System/34,
Mupid usw. mit entsprechenden DOS-Tools (z.B. ANADISK, 22DISK oder auch
selbstgeschriebene) lesen zu können (schreiben natürlich auch).
Einen DOS-Treiber bräuchte ich, um auch 5,25 DD Disketten XT-tauglich
beschreiben zu können. Außerdem gab es offensichtlich auch 8"
MS-DOS-Disketten, habe zumindest eine, auf der MS-DOS irgendwas draufsteht.
> Zumindest für FreeBSD behaupte ich mal, daß das tut. Leider konnte
Ich kenne kein UNIX/Linux/BSD, das FM-Disketten oder auch
Mixed-Mode-Disketten (z.B. System/34 mit Spur 0/Seite 0 in FM, der Rest nach
Wahl) unterstützt. Ich sollte wohl mal einen neuen Floppy-Treiber für Linux
schreiben, der das kann. Aber dann würde es ja nicht mehr auf einem 286er
laufen.
> ich's noch nicht verifizieren, weil ich noch keinen FDC gefunden habe,
> den ich wirklich sowohl mit IO-Port als auch IRQ als auch DMA umbiegen
> konnte.
Muß man ja auch nicht, I/O-Port genügt. Wenn man immer nur einen FDC auf
einmal anspricht, genügt es, den jeweils anderen per Reset ($00 ins digital
output register schreiben) stillzulegen. Beim zweiten FDC muß man aber den
Timer-Interrupt zum Ausschalten des Motors selber schreiben. So habe ich es
mit meinem IBM-Disketten-Programm gemacht und es läuft mit einem 2. FDC
besser als ANADISK u.ä.
Christian
Joerg Wunsch
>> IBM-Maschine sicher ohnehin eine Untertreibung. ;-) Zumal ich von
>> mehreren Stellen gehört habe, daß in die ersten ES1834 auch noch
>> original DEC-Karten reingepaßt haben ...
> Ist das wahr? Meine Guete, das haette ich nicht gedacht. Ich haette
> wesentlich mehr eigene Entwicklung erwartet.
Warum? Der robotron R300 war möglicherweise noch eine vollständige
Eigenentwicklung, weiß ich nicht. Aber ansonsten war es doch
vernünftig, Clones zu bauen, um halt auch fremde Software übernehmen
zu können. Wobei Du Dir das Clonen einer Vax-CPU alles andere als
einfach vorstellen mußt: na klar werden da Schicht für Schicht
abgeschliffen, aber man kann natürlich nicht etwa die hübschen farbig
gezeichneten Transistorstrukturen erkennen, die man von den gängigen
Lehrbüchern über sowas kennt. ;-) Man kann eigentlich nur die
Leitbahnsysteme völlig sicher erkennen, schon bei Dotierungen wird es
schwieriger -- und welche Technologie dann exakt zu dem Vorgefundenen
geführt hat, ist letztlich /die/ Rätselfrage. Sprich, man muß die
Technologie natürlich nicht nur beherrschen, sondern auch noch deren
Erscheinungsbild reproduzierbar erkennen. Kommt hinzu, daß es
natürlich von diesen CPUs und anderen Platinen nur /sehr/ begrenzte
Stückzahlen für das reverse engineering gab... Auch liefen danach
natürlich große Rechenjobs, die versuchten, die gefundenen Ergebnisse
zu verifizieren.
Alles in allem ist derartiges reverse engineering in der Welt eine
gängige Technologie. So kompliziert auch immer die Beschreibung
aussehen mag (mein Chef hat da einiges aus dem Nähkästchen geplaudert,
er hat früher bei robotron in diesem Bereich gearbeitet), sie kostet
dennoch weniger Aufwand als eine vergleichbare Neuentwicklung einer
CPU. Diejenigen, die das damals bei robotron federführend gemacht
haben, waren nach der »Wende« plötzlich gefragte Fachleute im Ausland.
> Weistt Du wie kompatibel dieses SVP war? Was bedeutet die Abkuerzug?
Die Abkürzung bedeutet »System Virtualnej Pamjat'i« (bitte schlag'
mich nicht für die Kasus-Endungen, so gut ist mein Russisch auch
nicht). Wenn Du das ins Englische übersetzt, hast Du ein »Virtual
Memory System« oder auch VMS genannt... Und genau das war es dann
wohl auch. Warum robotron hier eine russische Abkürzung genutzt hat,
weiß ich nicht, sonst war das eher untypisch. RSX-11 hieß MOOS-1600
(modular operating system; die robotron PDP-11 Clones nannten sich
K1630), CP/M nannte sich SCP (system control program oder sowas),
WordStar darauf hieß dann TP, (MS-)DOS wurde zu DCP (diskette control
program?). Aber praktisch zeichneten sie sich alle dadurch aus,
geklaut zu sein, lediglich diese Buchstaben waren ausgetauscht.
Kompatible Eigenentwicklungen bzw. nennenswerte Erweiterungen an
Software gab es schon. Die Dresdner Ingenieurhochschule (später mit
der TU vereinigt worden) produzierte einen RSX-11 Clone namens OS/RW
(war glaub' ich auch eine russische Abkürzung), der hatte einiges mehr
an Funktionsumfang als das MOOS-1600 und war entsprechend beliebt.
Das Institut für (hmm, habe ich vergessen, sorry) der Akademie der
Wissenschaften produzierte einen CP/M-Clone namens CP/A, der auch
deutlich beliebter als SCP war. Unter anderem konnte der automatische
Formaterkennung für einer Reihe gängiger CP/M-Floppies, hatte einiges
mehr an BIOS-Funktionalität bis hin zu einer Art »Kerneldebugger«
(Monitorprogramm). Das BIOS davon kursierte als Assemblercode, den
man sich nach eigenen Bedürfnissen beliebig modular linken konnte.
Das BDOS war original DR, der CCP geringfügig aufgebohrt, was der
Platz noch zuließ (es gab eine primitive Implementierung dessen, was
man unter Unix als $PATH bezeichnen würde -- ausführbare Programme
wurden außer auf dem aktuellen Laufwerk auch noch auf dem Bootlaufwerk
und ggf. in der user area 0 gesucht).
Joerg Wunsch
>>> Muß ich mir wirklich selber einen Treiber schreiben?
>> Kein DOS benutzen. ;-)
>
> Muß/Will ich aber.
Ja, gut, war ja auch'n Smiley dahinter.
[Interessante Beschreibung gelöscht.]
>> Zumindest für FreeBSD behaupte ich mal, daß das tut. Leider konnte
> Ich kenne kein UNIX/Linux/BSD, das FM-Disketten oder auch
> Mixed-Mode-Disketten (z.B. System/34 mit Spur 0/Seite 0 in FM, der
> Rest nach Wahl) unterstützt.
Ist doch überhaupt kein Problem. Naja, ist schon eins. :)
FreeBSD wird das in Zukunft unterstützen, auf meinem Laborrechner
läuft FM schon. Mit dem Formatieren habe ich noch irgendwo einen Bug,
insofern habe ich im Moment als einzige echte Quelle zum Testen eine
derartige mixed-mode Floppy. robotron hat sowas nämlich auch gebaut,
für seine A71xx Computer, und eine derartige Floppy liegt hier noch in
der Kiste. mixed-mode habe ich allerdings nicht als eigenes
komplettes Format implementiert, man kann es aber bequem mit einem
dd-Kommando realisieren, das zum Lesen der ersten Spur ein anderes
/dev/fd<irgendwas> nimmt als zum Bearbeiten der restlichen Spuren.
>> ich's noch nicht verifizieren, weil ich noch keinen FDC gefunden habe,
>> den ich wirklich sowohl mit IO-Port als auch IRQ als auch DMA umbiegen
>> konnte.
> Muß man ja auch nicht, I/O-Port genügt. Wenn man immer nur einen FDC
> auf einmal anspricht, genügt es, den jeweils anderen per Reset ($00
> ins digital output register schreiben) stillzulegen.
Nu ja, derartige Verrenkungen würde ich in einen Unix-Treiber nicht
reinbauen wollen (zumindest nicht in einen offiziellen). Lieber
kratze ich Leiterplatten. Leider nur habe ich zu beiden meinen noch
herumliegenden Uralt-Controllern gar keine Doku, deren Adreßdekoder
sind aber mit einem GAL implementiert, so daß man nicht einfach nur
das Schaltbild abzunehmen braucht und dann schon weiß, welcher Jumper
was bedeutet.
Joerg Wunsch
>> Ich kenne kein UNIX/Linux/BSD, das FM-Disketten oder auch
>> Mixed-Mode-Disketten (z.B. System/34 mit Spur 0/Seite 0 in FM, der
>> Rest nach Wahl) unterstützt.
>
> Ist doch überhaupt kein Problem. Naja, ist schon eins. :)
Der Satz bedarf vielleicht noch einer kleinen Erläuterung:
Prinzipiell muß man ja eigentlich nicht mehr tun, als das MFM-Bit im
entsprechenden FDC-Befehl weglassen. Da Unix-Treiber in C geschrieben
sind, ist sowas relativ einfach zu erledigen. Nichtsdestotrotz habe
ich derzeit Probleme mit dem Formatieren von FM-Floppies, die ich mir
einfach noch nicht erklären kann.
>> Muß man ja auch nicht, I/O-Port genügt. Wenn man immer nur einen FDC
>> auf einmal anspricht, genügt es, den jeweils anderen per Reset ($00
>> ins digital output register schreiben) stillzulegen.
>
> Nu ja, derartige Verrenkungen würde ich in einen Unix-Treiber nicht
> reinbauen wollen (zumindest nicht in einen offiziellen).
Naja, vielleicht könnte man sowas ja doch mal vorsehen. Ich würde
den/die jeweils anderen Controller nicht in den Reset pressen, weil
sie dann auch die Kennung über die aktuelle Zylindernummer vergessen
haben. Schade ist nur, daß die NE765 & Co. keine sinnvolle
Möglichkeit haben, auf einem shared IRQ wirklich »shared« zu arbeiten,
sprich man kann sie nicht nach dem Auftreten eines IRQ pollen, wer
denn nun genau den Interrupt abgegeben hat. Das hätte die Sache noch
vereinfacht.
Christian Corti
> der Kiste. mixed-mode habe ich allerdings nicht als eigenes
> komplettes Format implementiert, man kann es aber bequem mit einem
> dd-Kommando realisieren, das zum Lesen der ersten Spur ein anderes
> /dev/fd<irgendwas> nimmt als zum Bearbeiten der restlichen Spuren.
Wie wäre es mit einem block device unter Unix, das man per ioctl einstellen
kann, z.B. zwischen FM/MFM umschalten, direkt Seeks u.a. Befehle an den FDC
schicken usw?
>> Muß man ja auch nicht, I/O-Port genügt. Wenn man immer nur einen FDC
>> auf einmal anspricht, genügt es, den jeweils anderen per Reset ($00
>> ins digital output register schreiben) stillzulegen.
> Nu ja, derartige Verrenkungen würde ich in einen Unix-Treiber nicht
> reinbauen wollen (zumindest nicht in einen offiziellen). Lieber
Aha, ein Pluspunkt für DOS, das man immer dann nimmt, wenn man sowas machen
muß. Ich denke aber, daß man das unter UNIX trotzdem machen kann. Da ja nur
ein Treiber für beide FDCs vorhanden ist, bräuchte man nur darauf warten,
bis der andere fertig ist, um ihn kurzzeitig stillzulegen. Wobei, wenn ich
mich recht entsinne, unterstützt Linux zwei FDCs. Ich hatte das mal kurz
ausprobiert und mir war kein Problem begegnet, also wird es wohl schon so
gemacht.
Christian
Joerg Wunsch
> Wie wäre es mit einem block device unter Unix, das man per ioctl
> einstellen kann, z.B. zwischen FM/MFM umschalten, direkt Seeks
> u.a. Befehle an den FDC schicken usw?
Ziemlich umständlich, da ja der Treiber dann auch noch wissen muß, was
er als DMA abzuwickeln hat. Wenn immer möglich, sollte man die
FDC-Kommandos schon dem Treiber überlassen und nicht ins Userland
verlagern.
ioctl hat auch keinen Vorteil gegenüber der Methode, pro Schreibdichte
ein logisches Gerät anzulegen. Man bräuchte dafür ja auch ein
Userland-Kommando, das die ganze Sache bedient, da kann man auch
gleich stattdessen einen Script schreiben, der die einzelnen Spuren je
nach Schreibdichte mit dd behandelt. Seek-Kommandos aus dem Userland
muß man auch nicht haben, die sind implizit und entsprechen letztlich
dem skip-Parameter von dd.
> Aha, ein Pluspunkt für DOS, das man immer dann nimmt, wenn man sowas
> machen muß.
Ich will aber nicht extra noch ein DOS mit auf der Kiste haben...
Reboots sind lästig.
> Wobei, wenn ich mich recht entsinne, unterstützt Linux zwei
> FDCs. Ich hatte das mal kurz ausprobiert und mir war kein Problem
> begegnet, also wird es wohl schon so gemacht.
Aber eben nur 2. :-) Eigentlich sollten Unix-Treiber immer N Geräte
unterstützen, ohne das N im Treiber zu limitieren. (Daß sich andere
Beschränkungen für N ergeben, ist natürlich klar.) Aber ich schrieb
ja schon, daß man es natürlich im Prinzip machen könnte. Separate
FDCs mit komplett getrennten Ressourcen wären mir dennoch lieber. Ich
muß nochmal gucken, was sich mit Kratzen erledigen läßt...
Christian Corti
> Ziemlich umständlich, da ja der Treiber dann auch noch wissen muß, was
> er als DMA abzuwickeln hat. Wenn immer möglich, sollte man die
Na, Lesen und Schreiben, aber das weiß er doch jetzt schon.
> ioctl hat auch keinen Vorteil gegenüber der Methode, pro Schreibdichte
> ein logisches Gerät anzulegen. Man bräuchte dafür ja auch ein
Oh doch, oh doch, oder soll ich für eine Diskette gleich zig Geräte öffnen?
Denn man müßte ja nicht nur pro Schreibdichte, sondern auch pro Sektorgröße
ein Gerät anlegen. Zusätzlich das ganze nochmal für einseitige Disketten.
Auch wenn nur ein Treiber dahinter steckt, habe ich dann tausend Einträge in
/dev mit unterschiedlichen Minornummern.
> Userland-Kommando, das die ganze Sache bedient, da kann man auch
> gleich stattdessen einen Script schreiben, der die einzelnen Spuren je
> nach Schreibdichte mit dd behandelt. Seek-Kommandos aus dem Userland
> muß man auch nicht haben, die sind implizit und entsprechen letztlich
> dem skip-Parameter von dd.
Mir fällt noch etwas ein. Das IBM-Format kennt Möglichkeiten zur Markierung
von 1. schlechten Sektoren und 2. schlechten Zylindern. Um den Floppy-Treiber
eben nicht formatspezifisch gestalten zu müssen, muß einiges auch dem
Benutzer möglich gemacht werden. Schlechte Sektoren werden nämlich über eine
deleted data address mark gekennzeichnet plus einem 'F' (Hex. C6) im ersten
Byte des Datenbereichs des Sektors. Bei schlechten Zylindern werden binäre 1 in
alle Sektor-ID-Feldern geschrieben (!). Jetzt kommts: Die Spurnummer des
schlechten Zylinders wird in die physikalisch nächste Spur geschrieben
(sprich alle Spurnummern der folgenden Zylinder werden verschoben). Dabei
können bis zu zwei schlechte Zylinder "ausgeblendet" werden. Den
Floppy-Treiber möchte ich gerne sehen, der, ohne das Format zu kennen, z.B.
bei der physikalischen Spur 63 die Spurnummer 61 akzeptiert.
Wie schon erwähnt, muß ich DDAMs und NDAMs (normal data address mark) sowohl
lesen als auch schreiben können. Leere Inhaltsverzeichniseinträge werden
z.B. durch ein 'D' (Hex. C4) im ersten Byte plus einer DDAM (wichtig!)
markiert. Fehlt die DDAM, meckert z.B. der IBM 5110 mit dem Fehler 38. Wie
soll ich mit 'dd' (warum überhaupt dd?) diese Informationen lesen oder
schreiben, und zwar wahlweise für einzelne Sektoren?
>> Aha, ein Pluspunkt für DOS, das man immer dann nimmt, wenn man sowas
>> machen muß.
> Ich will aber nicht extra noch ein DOS mit auf der Kiste haben...
> Reboots sind lästig.
Dafür habe ich eine eigene Kiste.
> ja schon, daß man es natürlich im Prinzip machen könnte. Separate
> FDCs mit komplett getrennten Ressourcen wären mir dennoch lieber. Ich
Mir natürlich auch.
Christian
Joerg Wunsch
>> ioctl hat auch keinen Vorteil gegenüber der Methode, pro Schreibdichte
>> ein logisches Gerät anzulegen. Man bräuchte dafür ja auch ein
> Oh doch, oh doch, oder soll ich für eine Diskette gleich zig Geräte
> öffnen?
Wieso zig? Wir waren bei zweien.
> Denn man müßte ja nicht nur pro Schreibdichte, sondern auch pro
> Sektorgröße ein Gerät anlegen.
Ja, wobei natürlich die Schreibdichten der Geräte sehr wohl vom
Userland mittels ioctl manipulierbar sind. Du hast natürlich Recht,
man kann auch mit einem /dev Eintrag arbeiten und mittels ioctl dessen
Definition zwischendurch ändern.
> Mir fällt noch etwas ein. Das IBM-Format kennt Möglichkeiten zur
> Markierung von 1. schlechten Sektoren und 2. schlechten Zylindern.
Wir hatten hier letztens schon einmal diskutiert und waren dabei
rausgekommen, daß noch niemand gesehen worden ist, der deleted data
marks tatsächlich auch benutzt. Sowie ich den ersten Request eines
FreeBSD-Users habe, diese benutzen zu können, baue ich auch das noch
ein. :-)
> Den Floppy-Treiber möchte ich gerne sehen, der, ohne das Format zu
> kennen, z.B. bei der physikalischen Spur 63 die Spurnummer 61
> akzeptiert.
Auch das bekämen wir noch hin. Einen Request für Offset der
Sektornummern auf der Rückseite hatte ich schon, das ist auch drin.