320K ---> 1.44MB kopieren

[Uwe Nass]

Hallo zusammen,

weiss jemand, wie ich ein 320K binary image auf
eine 1.44MB Diskette kopieren kann? Die 1.44MB
Diskette sollte also dem Rechner wie eine 320K
Diskette erscheinen. Das muesste unter Linux
moeglich sein, nur wie?

Besten Dank im voraus,

Uwe.

[Ralph Sontag]

Post by Uwe Nass
weiss jemand, wie ich ein 320K binary image auf
eine 1.44MB Diskette kopieren kann? Die 1.44MB
Diskette sollte also dem Rechner wie eine 320K
Diskette erscheinen. Das muesste unter Linux
moeglich sein, nur wie?

Das Device-File /dev/fd0u360 müßte das eigentlich leisten.
Also: dd if=image of=/dev/fd0u360

Ralph.

[Henning Paul]

Post by Ralph Sontag

Post by Uwe Nass
weiss jemand, wie ich ein 320K binary image auf
eine 1.44MB Diskette kopieren kann? Die 1.44MB
Diskette sollte also dem Rechner wie eine 320K
Diskette erscheinen. Das muesste unter Linux
moeglich sein, nur wie?

Das Device-File /dev/fd0u360 müßte das eigentlich leisten.
Also: dd if=image of=/dev/fd0u360

Das ist für 5,25"-Laufwerke...

Gruß
Henning

[Ralph Sontag]

Post by Henning Paul

Post by Ralph Sontag

Post by Uwe Nass
weiss jemand, wie ich ein 320K binary image auf
eine 1.44MB Diskette kopieren kann? Die 1.44MB
Diskette sollte also dem Rechner wie eine 320K
Diskette erscheinen. Das muesste unter Linux
moeglich sein, nur wie?

Das Device-File /dev/fd0u360 müßte das eigentlich leisten.
Also: dd if=image of=/dev/fd0u360

Das ist für 5,25"-Laufwerke...

Oh, sorry - stimmt. Also dann bezweifle ich ja, daß das Image
überhaupt mit einem 1.44-Format korrespondiert.

Vielleicht kann man das via Loopback mounten und dann den Inhalt
auf eine passende Diskette schieben? Ich weiß nur nicht, ob das dem
Fragesteller was nützt.

Ralph.

[Henning Paul]

Post by Ralph Sontag
Vielleicht kann man das via Loopback mounten und dann den Inhalt
auf eine passende Diskette schieben?

Da wird das "schieben" wieder das Problem. Was der Floppycontroller in
Hardware nicht kann, kann der Blockdevicetreiber auch nicht
unterstützen.

Da braucht man schon einen spezialisierten Floppycontroller:
http://www.jschoenfeld.de/products/catweasel.htm
bzw.
http://amiga.think42.com/news/news99.htm

Gruß
Henning

[Ralph Sontag]

Post by Henning Paul

Post by Ralph Sontag
Vielleicht kann man das via Loopback mounten und dann den Inhalt
auf eine passende Diskette schieben?

Da wird das "schieben" wieder das Problem. Was der Floppycontroller in
Hardware nicht kann, kann der Blockdevicetreiber auch nicht
unterstützen.
http://www.jschoenfeld.de/products/catweasel.htm
bzw.
http://amiga.think42.com/news/news99.htm

Ja. Wenn das Ziel die Erstellung so einer Diskette ist, stimmt das.
Wenn allerdings das Problem darin besteht, ein altes Image gefunden
zu haben, das man nun gern wieder lesen können möchte, reicht es
vielleicht, nur die Daten via Loopback zu retten.

Aber Hinweis auf die Controller ist gut!

Warten wir mal auf den Fragesteller ... :-)

Ralph.

[Henning Paul]

Post by Ralph Sontag

Post by Henning Paul

Post by Ralph Sontag
Vielleicht kann man das via Loopback mounten und dann den Inhalt
auf eine passende Diskette schieben?

Da wird das "schieben" wieder das Problem. Was der Floppycontroller
in Hardware nicht kann, kann der Blockdevicetreiber auch nicht
unterstützen.
http://www.jschoenfeld.de/products/catweasel.htm
bzw.
http://amiga.think42.com/news/news99.htm

Ja. Wenn das Ziel die Erstellung so einer Diskette ist, stimmt das.
Wenn allerdings das Problem darin besteht, ein altes Image gefunden
zu haben, das man nun gern wieder lesen können möchte, reicht es
vielleicht, nur die Daten via Loopback zu retten.

Es geht Uwe ja anscheinend darum, daß irgendein System die so erstellte
Diskette dann lesen kann. Und dafür muß man sich schon mit der
korrekten Anzahl an Spuren und Sektoren auseinandersetzen.

Gruß
Henning

[Henning Paul]

Post by Uwe Nass
weiss jemand, wie ich ein 320K binary image auf
eine 1.44MB Diskette kopieren kann? Die 1.44MB
Diskette sollte also dem Rechner wie eine 320K
Diskette erscheinen. Das muesste unter Linux
moeglich sein, nur wie?

Mit einem Laufwerk, das das kann. PC-3,5"-Laufwerke (genau gesagt, die
dazugehörigen Floppycontroller) können nur 720 oder 1440kB. Ist 320kB
einseitig?

Gruß
Henning

[Alfred Weidlich]

Post by Henning Paul

Post by Uwe Nass
weiss jemand, wie ich ein 320K binary image auf
eine 1.44MB Diskette kopieren kann? Die 1.44MB
Diskette sollte also dem Rechner wie eine 320K
Diskette erscheinen. Das muesste unter Linux
moeglich sein, nur wie?

Mit einem Laufwerk, das das kann. PC-3,5"-Laufwerke (genau gesagt, die
dazugehörigen Floppycontroller) können nur 720 oder 1440kB. Ist 320kB
einseitig?

Ich kenne nur die 5,25" Laufwerke des PCs.
Die konnten, 1,2MB, 360kB, 160kB wobei letzteres glaube ich einseitig war.
Könnte es ein non PC Format gewesen sein?
Welche Formate hatte denn der C64 zum Beispiel?

[Dirk Ohme]

Henning Paul schrieb im Newsbeitrag

Post by Henning Paul
Mit einem Laufwerk, das das kann. PC-3,5"-Laufwerke
(genau gesagt, die dazugehörigen Floppycontroller)
können nur 720 oder 1440kB. Ist 320kB einseitig?

So ganz aus dem hohlen Bauch heraus: 160kB bzw. 320kB war das ganz
ur-alte Diskettenformat bei PC-DOS 1.0 bzw. 1.1 - ab PC-DOS 2.0 gab's
dann 180 bzw. 360kB je 5 1/4"-Diskette ... organisiert sind die
160/320kB als 8 Sektoren je Spur bei 40 Spuren, ein- bzw.
doppelseitig. Die 180/360kB sind dann 9 Sektoren je 40 Spuren
ein-/doppelseitig.

Ich weiss ja nicht, in welchem Format denn das Image vorliegt - mir
scheint es am sinnvollsten, das Image als Device zu mounten und dann
per "cp" die Dateien auf eine sauber formatierte 1,44MB-Diskette zu
ziehen. Ansonsten dürfte es eine arge Frickelei sein, eine 3
1/2"-Diskette auf das Format zu bringen ...

Unter DOS würde ich ja noch sagen: format /8 ... allerdings auch nur
bei 5 1/4" ...

Gruß, Dirk

[Henning Paul]

Post by Dirk Ohme
Unter DOS würde ich ja noch sagen: format /8 ... allerdings auch nur
bei 5 1/4" ...

"fdformat /dev/fd0u360" unter Linux. Sind dann allerdings 360kB...

Gruß
Henning

[Holger Petersen]

Post by Dirk Ohme
Ansonsten dürfte es eine arge Frickelei sein, eine 3
1/2"-Diskette auf das Format zu bringen ...

Nun, mit einer Sequenz von "skip=###" sowie "bs=512 count=9"
Optionen an das Programm "dd" (unterschiedlich bei der Eingabe
zu den Angaben bei der Ausgabe) dürfte das klappen.

Niemand wird gezwungen, in die höheren Sektor-Nummern einer
Spur auch was reinzuschreiben...

Die eigentliche Frage wäre dann, ob das Zielsystem (Welches :-)
das auch so verarbeiten will. Lesen wahrscheinlich schon;
beim Schreiben wird es diffizieler...

Ein DOS 1.1 (gibt es irgendwo im Netz :-) auf einer 3,5-Zoll
Scheibe die in einem heutigen PC bootet wäre schon mal lustig.
Die läuft dann voll im CPU-Chache...

Gruss, Holger

[Uwe Nass]

Post by Holger Petersen

Post by Dirk Ohme
Ansonsten dürfte es eine arge Frickelei sein, eine 3
1/2"-Diskette auf das Format zu bringen ...

Nun, mit einer Sequenz von "skip=###" sowie "bs=512 count=9"
Optionen an das Programm "dd" (unterschiedlich bei der Eingabe
zu den Angaben bei der Ausgabe) dürfte das klappen.
Niemand wird gezwungen, in die höheren Sektor-Nummern einer
Spur auch was reinzuschreiben...
Die eigentliche Frage wäre dann, ob das Zielsystem (Welches :-)
das auch so verarbeiten will. Lesen wahrscheinlich schon;
beim Schreiben wird es diffizieler...
Ein DOS 1.1 (gibt es irgendwo im Netz :-) auf einer 3,5-Zoll
Scheibe die in einem heutigen PC bootet wäre schon mal lustig.
Die läuft dann voll im CPU-Chache...
Gruss, Holger

Hallo zusammen,

besten Dank fuer eure Hinweise! Ich habe dieselbe Frage
auch in de.comp.os.unix.misc gepostet, wie wohl einige auch
bemerkt haben. Es handelt sich bei "meinem" image um eine
5 1/4" Diskette DSDD, 40 Tracks und 8 Sektoren. Das kopieren
der Dateien ist kein Problem, aber dieses image ist bootfaehig,
d.h. es muesste auch der ERSTE Track kopiert werden.

Also, um ehrlich zu sein, es handelt sich um ein image von
CCP/M-86 v3.1! Die 5 1/4" Diskette bootet in einem alten
PC hervoragend. Mittels VMWARE ist dies wohl auch in neueren
PC's machbar (hat wohl schon jemand geschafft). Nur die
allerneusten PC's unterstuetzen nur noch EIN 3.5" Disketten
Laufwerk. Daher die Frage! Warum ich das will ist hoffentlich
nicht wichtig.

Bitte antwortet jetzt nur noch in dieser NG; das crossposting
faellt von meiner Seite jetzt weg.

Besten Dank nochmals,

Uwe.

[Holger Petersen]

Post by Uwe Nass
Also, um ehrlich zu sein, es handelt sich um ein image von
CCP/M-86 v3.1! Die 5 1/4" Diskette bootet in einem alten
PC hervoragend.
Bitte antwortet jetzt nur noch in dieser NG

Die Gruppe ' comp.os.cpm ' wäre allerdings 10^3mal besser geeignet, IMHO

Wenn ich mich nicht täusche hat jemand dort das 'Problem' schon mal
gelöst; ich überlese dort allerdings fast alle cp/m-86 Artikel.

-=-
Um wieder Linux-Bezug zu haben:
Es gibt analog zu den mtools auch cpmtools.

SCNR, Holger

[Sieghard Schicktanz]

Hallo Henning,

Post by Henning Paul

Post by Uwe Nass
weiss jemand, wie ich ein 320K binary image auf
eine 1.44MB Diskette kopieren kann? Die 1.44MB

...

Post by Henning Paul
Mit einem Laufwerk, das das kann. PC-3,5"-Laufwerke (genau gesagt, die
dazugehörigen Floppycontroller) können nur 720 oder 1440kB. Ist 320kB

Warum sollte ein 3,5*_Laufwerk _kein_ anderes Format können als das
üblicherweise verwendete? Es gab mal sogar "normale" Disketten für 3,5",
die nur für die halbe Kapazität der neueren "HD"- (High Density) Disketten
beschichtet waren. Das Problem könnte allerdings der _Treiber_ sein, der
für das "halbe" Format "double stepping" können muß, d.h. den
Kopfträgerschlitten für jeden Spurwechsel um _zwei_ Schritte weiterschalten.
(BTW, ich hab' hier noch solche alten Floppies von einem Siemens-PCPM (ja,
richtig, ein CP/M-Derivat) rumliegen, die sich sogar immer noch mit einem
passenden Leseprogramm verarbeiten lassen. Die ha(tt|b)en - auf "double
density"-Floppies - 640KB Kapazität, zweieitig, 40 Spuren pro Seite (aka
"40 Zylinder";).

Post by Henning Paul
einseitig?

Sicher einseitig bei 320KB (= 640KB/2).

----

[Henning Paul]

Post by Sieghard Schicktanz
Hallo Henning,

Post by Henning Paul

Post by Uwe Nass
weiss jemand, wie ich ein 320K binary image auf
eine 1.44MB Diskette kopieren kann? Die 1.44MB

...

Post by Henning Paul
Mit einem Laufwerk, das das kann. PC-3,5"-Laufwerke (genau gesagt,
die dazugehörigen Floppycontroller) können nur 720 oder 1440kB. Ist
320kB

Warum sollte ein 3,5*_Laufwerk _kein_ anderes Format können als das
üblicherweise verwendete? Es gab mal sogar "normale" Disketten für
3,5", die nur für die halbe Kapazität der neueren "HD"- (High Density)
Disketten beschichtet waren.

Klar, DD, 720kB. Kenne ich noch persönlich.

Post by Sieghard Schicktanz
Das Problem könnte allerdings der
_Treiber_ sein, der für das "halbe" Format "double stepping" können
muß, d.h. den Kopfträgerschlitten für jeden Spurwechsel um _zwei_
Schritte weiterschalten.

Der Linuxfloppytreiber kann das ganz bestimmt, sonst gäbe es die ganzen
fd0*-Devices nicht. Wo der Treiber auch nicht weiterhelfen kann, sind
vom PC-Standard abweichende Modulationsformen, wie z.B. GCR oder
(nicht-M)-FM. Da die Signalverarbeitung im Controller läuft, kann der
Treiber da nichts mehr reißen, selbst wenn das Laufwerk diese Disketten
noch unterstützt. Auch heutige Laufwerke unterstützen noch alle alten
Formate, da auf dem Floppyanschlußkabel ja nur die
Schrittmotoransteuerungssignale und die rohen Lese-/Schreibkopfsignale
laufen. Weshalb ein Floppycontroller wie der Catweasel ja mit einem
handelüblichen Laufwerk alle Formate lesen kann.

Post by Sieghard Schicktanz

Post by Henning Paul
einseitig?

Sicher einseitig bei 320KB (= 640KB/2).

Da man 3,5"-Disketten nicht umdrehen kann, wäre das aber eher
merkwürdig.

Wir haben ja aber zwischenzeitlich erfahren, daß es sich um
5,25"-Disketten handelt.

Gruß
Henning

[Sieghard Schicktanz]

Hallo Henning,

Post by Henning Paul
Der Linuxfloppytreiber kann das ganz bestimmt, sonst gäbe es die ganzen

Eben.

Post by Henning Paul
fd0*-Devices nicht. Wo der Treiber auch nicht weiterhelfen kann, sind
vom PC-Standard abweichende Modulationsformen, wie z.B. GCR oder
(nicht-M)-FM. Da die Signalverarbeitung im Controller läuft, kann der

Genau, mit der Modulation hat der Treiber nix zu tun, das macht der
Controller ganz allein und selbständig. Und da hat sich eben in der PC-
Welt die FM-/MFM-Modulation etabliert, ausgehend von den Anfängen als
Erweiterung der Kassettenaufzeichnung, und lediglich Apple hat da einen
Sonderweg beschritten und das GCR-Verfahren (AFAIR "Group Coded Recording"
o.s.ä.) erfunden und benutzt. Es gab auch nur recht wenige Controller für
dieses Verfahren, und noch viel weniger, die MFM und GCR konnten.

Post by Henning Paul
Treiber da nichts mehr reißen, selbst wenn das Laufwerk diese Disketten
noch unterstützt. Auch heutige Laufwerke unterstützen noch alle alten

Das Laufwerk "unterstützt" das nur insoweit was, als es die Anschlüsse des
Schreib-/Lesekopf direkt an die Controller-Platine herausführt...
Weitere Unterstützung kommt dann noch durch die Anschlüsse des
Schrittmotortreibers für die Kopfschlittenpositionierung, den Ein-Befehl
für den Antriebsmotor und die Schalterchen für die Disketten-Erkennung.
Achja, und das Schalterchen zum Unterbrechen des Schreibstroms, das der
Controller nicht überfahren kann (jedenfalls "normalerweise").

Post by Henning Paul

Post by Sieghard Schicktanz
Sicher einseitig bei 320KB (= 640KB/2).

Da man 3,5"-Disketten nicht umdrehen kann, wäre das aber eher
merkwürdig.

Wenn man den beidseitigen Beschichtungsprozess (noch) nicht beherrscht,
ist es schwierig, Disketten für doppeltseitige Aufzeichnung anzubieten.
Doppelseitige Beschichtung war zu Anfang der Diskettenzeit durchaus nicht
der Normalfall.
BTW, 5,25"_Disketten kann man _auch_ _nicht_ umdrehen, wenn man sie nicht
mechanisch vorbehandelt (es gab dazu sogar Modifikationswerkzeuge, und ein
paar Firmen haben sogar umdrehbare 5,25"-Floppies hergestellt - mit
_zwei_ Löchern in der Hülle für das Indexloch. ;).

Post by Henning Paul
Wir haben ja aber zwischenzeitlich erfahren, daß es sich um
5,25"-Disketten handelt.

Ja, das Original - aber das sollte ja auf 3,5" umkopiert werden.
Und zumindest _physisch_ spricht da nichts dagegen.

----

[Henning Paul]

Post by Sieghard Schicktanz
Wenn man den beidseitigen Beschichtungsprozess (noch) nicht
beherrscht, ist es schwierig, Disketten für doppeltseitige
Aufzeichnung anzubieten. Doppelseitige Beschichtung war zu Anfang der
Diskettenzeit durchaus nicht der Normalfall.
BTW, 5,25"_Disketten kann man _auch_ _nicht_ umdrehen, wenn man sie
nicht mechanisch vorbehandelt (es gab dazu sogar
Modifikationswerkzeuge, und ein paar Firmen haben sogar umdrehbare
5,25"-Floppies hergestellt - mit _zwei_ Löchern in der Hülle für das
Indexloch. ;).

Vom C64 meines damals besten Freundes kannte ich das nur so.

Gruß
Henning

[Sieghard Schicktanz]

Hallo Henning,

Post by Henning Paul

Post by Sieghard Schicktanz
Modifikationswerkzeuge, und ein paar Firmen haben sogar umdrehbare
5,25"-Floppies hergestellt - mit _zwei_ Löchern in der Hülle für das
Indexloch. ;).

Vom C64 meines damals besten Freundes kannte ich das nur so.

Der hatte dann wohl auch nur einen Lesekopf... Könnte sein, und es könnte
auch sein, daß diese "zwiegelochten" Disketten extra dafür hergestellt
worden sind.

----

[Helmut Hullen]

Hallo, Sieghard,

Post by Sieghard Schicktanz
lediglich Apple hat da
einen Sonderweg beschritten und das GCR-Verfahren (AFAIR "Group Coded
Recording" o.s.ä.) erfunden und benutzt. Es gab auch nur recht wenige
Controller für dieses Verfahren, und noch viel weniger, die MFM und
GCR konnten.

GCR hatte schon die CBM3040 - Doppellaufwerk für 5,25 Zoll.
Einer der Tricks scheint zu sein, dass ein eigener Kontroller die Daten
aufbereitet und dann auf einem Bus weitergibt.

Beim IBMpatiblen sitzt dieser Kontroller auf der Hauptplatine, in der
Nähe des Floppykabels.

Die CBM4040 hat im Mai 81 bei HEW nur 2984,- DM gekostet.
(Ich weiss - hat nix mit Linux zu tun ...)

Viele Gruesse!
Helmut

[Dirk Ohme]

Post by Helmut Hullen
GCR hatte schon die CBM3040 - Doppellaufwerk für 5,25 Zoll.
Einer der Tricks scheint zu sein, dass ein eigener Kontroller die Daten
aufbereitet und dann auf einem Bus weitergibt.

Jepp ... IEC/IEEE-Bus, an dem dann noch andere Geräte (u.a.
Messgeräte) hängen konnten. Bei den Home-Computern seriell ausgelegt,
bei den professionelleren Geräte parallel. Das führte dazu, dass im
Floppy-Gehäuse nicht nur der Controller, sondern eine extra CPU saß.
Beim Amiga hörte es dann auf mit dem Spaß und man verwendete
wenigstens Standard-Laufwerke, auch wenn das Aufzeichnungsformat noch
exotisch blieb ... aber immerhin sparten sie nicht mehr die Spur-0-
Lichtschranke ein, wie beim VC1541 ;-)

Gruß, Dirk

[Uwe Nass]

Hallo zusammen,

ich schein ja doch einige Verwirrung gestiftet zu haben.
Zum ersten, man kann eine 3.5" Diskette unter dem OS
DOSPLUS v1.2 ohne weiteres als 320K CP/M Diskette
formatieren. Nicht immer, aber immer oefters. Diese
ist dann auch leicht mit entsprechenden Programmen
zu fuellen. Was ich brauche, ist ein Hinweis WIE ich
den Bootsektor, also Track 0, Sektor 1-8 umkopiere!

Wenn das geht, kann ich natuerlich auch das ganze image
direkt kopieren. Daher meine Frage...

Gruss,

Uwe.

[Henning Paul]

Post by Uwe Nass
ich schein ja doch einige Verwirrung gestiftet zu haben.
Zum ersten, man kann eine 3.5" Diskette unter dem OS
DOSPLUS v1.2 ohne weiteres als 320K CP/M Diskette
formatieren. Nicht immer, aber immer oefters. Diese
ist dann auch leicht mit entsprechenden Programmen
zu fuellen. Was ich brauche, ist ein Hinweis WIE ich
den Bootsektor, also Track 0, Sektor 1-8 umkopiere!
Wenn das geht, kann ich natuerlich auch das ganze image
direkt kopieren. Daher meine Frage...

Ohne Gewähr:

for i in `seq 0 39`; do dd if=image.img of=/dev/fd0 bs=1k count=8
skip=`echo "8*$i"|bc` seek=`echo "18*$i"|bc`;done

Nimmt immer 8*2 Sektoren (Ober-/Unterseite) aus dem Image, schreibt sie
auf die Diskette und läßt dann 10*2 Sektoren frei, bevor er die
nächsten 8*2 Sektoren schreibt.

Auf diese Weise werden nur die jeweils 8 ersten Sektoren auf jeder Seite
und die ersten 40 Spuren beschrieben.

Gruß
Henning

[Henning Paul]

Post by Henning Paul

Post by Uwe Nass
ich schein ja doch einige Verwirrung gestiftet zu haben.
Zum ersten, man kann eine 3.5" Diskette unter dem OS
DOSPLUS v1.2 ohne weiteres als 320K CP/M Diskette
formatieren. Nicht immer, aber immer oefters. Diese
ist dann auch leicht mit entsprechenden Programmen
zu fuellen. Was ich brauche, ist ein Hinweis WIE ich
den Bootsektor, also Track 0, Sektor 1-8 umkopiere!
Wenn das geht, kann ich natuerlich auch das ganze image
direkt kopieren. Daher meine Frage...

for i in `seq 0 39`; do dd if=image.img of=/dev/fd0 bs=1k count=8
skip=`echo "8*$i"|bc` seek=`echo "18*$i"|bc`;done

Hmm, anscheinend ist das genau falsch, ich war davon ausgegangen, daß
sich Sektoren auf den entgegengesetzten Seiten direkt abwechseln, aber
anscheinend liegen alle Sektoren eines Tracks auf einer Seite in
linearer Adressierung direkt nebeneinander. Also eher

for i in `seq 0 79`; do dd if=image.img of=/dev/fd0 bs=512 count=8
skip=`echo "8*$i"|bc` seek=`echo "18*$i"|bc`;done

Gruß
Henning

[Uwe Nass]

Post by Henning Paul

Post by Henning Paul

Post by Uwe Nass
ich schein ja doch einige Verwirrung gestiftet zu haben.
Zum ersten, man kann eine 3.5" Diskette unter dem OS
DOSPLUS v1.2 ohne weiteres als 320K CP/M Diskette
formatieren. Nicht immer, aber immer oefters. Diese
ist dann auch leicht mit entsprechenden Programmen
zu fuellen. Was ich brauche, ist ein Hinweis WIE ich
den Bootsektor, also Track 0, Sektor 1-8 umkopiere!
Wenn das geht, kann ich natuerlich auch das ganze image
direkt kopieren. Daher meine Frage...

for i in `seq 0 39`; do dd if=image.img of=/dev/fd0 bs=1k count=8
skip=`echo "8*$i"|bc` seek=`echo "18*$i"|bc`;done

Hmm, anscheinend ist das genau falsch, ich war davon ausgegangen, daß
sich Sektoren auf den entgegengesetzten Seiten direkt abwechseln, aber
anscheinend liegen alle Sektoren eines Tracks auf einer Seite in
linearer Adressierung direkt nebeneinander. Also eher
for i in `seq 0 79`; do dd if=image.img of=/dev/fd0 bs=512 count=8
skip=`echo "8*$i"|bc` seek=`echo "18*$i"|bc`;done
Gruß
Henning

Hallo Henning,

besten Dank fuer dein zweites skript. Es laeuft zwar fehlerfrei
aber die disk bootet leider nicht. Probier jetzt mal den Hinweis
von Sieghard Schicktanz.

Danke nochmals,

Uwe.

[Henning Paul]

Post by Uwe Nass
besten Dank fuer dein zweites skript. Es laeuft zwar fehlerfrei
aber die disk bootet leider nicht.

Du könntest auch noch probieren, die Diskette vor dem Umkopiervorgang
auf DD (720kB) umzuformatieren:

fdformat /dev/fd0<hierkommtnocheinbuchstabehin>720

Gruß
Henning

[Hartmut Figge]

Probier jetzt mal den Hinweis von Sieghard Schicktanz.

Eigentlich sollte von einem von mir vor Urzeiten geschriebenen Programm
problemlos erledigt werden können. Läuft aber nur unter DOS und ist hier
somit OT. *g*

Hartmut

[Henning Paul]

Post by Hartmut Figge

Probier jetzt mal den Hinweis von Sieghard Schicktanz.

Eigentlich sollte von einem von mir vor Urzeiten geschriebenen
Programm problemlos erledigt werden können. Läuft aber nur unter DOS
und ist hier somit OT. *g*

Interessehalber: Wie arbeitet das denn grundsätzlich?

Gruß
Hening

[Hartmut Figge]

[320K -> 1.4M]

Post by Henning Paul

Post by Hartmut Figge
Eigentlich sollte von einem von mir vor Urzeiten geschriebenen
Programm problemlos erledigt werden können. Läuft aber nur unter DOS
und ist hier somit OT. *g*

Interessehalber: Wie arbeitet das denn grundsätzlich?

Sehr lange her. Hm. AFAIR hatte ich mir damals die Daten einer ganzen
Reihe von Formaten besorgt, die mit dem Diskettenkontroller kompatibel
waren.

Aus einem anderen Anlass hatte ich das Programm mal hochgeladen. Egal,
wer es probieren will:

http://www.triffids.de/pub/dos/

Hartmut

[Henning Paul]

Post by Hartmut Figge
[320K -> 1.4M]

Post by Henning Paul

Post by Hartmut Figge
Eigentlich sollte von einem von mir vor Urzeiten geschriebenen
Programm problemlos erledigt werden können. Läuft aber nur unter DOS
und ist hier somit OT. *g*

Interessehalber: Wie arbeitet das denn grundsätzlich?

Sehr lange her. Hm. AFAIR hatte ich mir damals die Daten einer ganzen
Reihe von Formaten besorgt, die mit dem Diskettenkontroller kompatibel
waren.

Ich meinte eher, ob das Programm auch Sektoren "überspringt", wie es der
dd-Ansatz tut. Und was der generelle Sinn diese Programms ist. Images
schreiben?

Gruß
Henning

[Hartmut Figge]

Post by Henning Paul

Post by Hartmut Figge
Sehr lange her. Hm. AFAIR hatte ich mir damals die Daten einer ganzen
Reihe von Formaten besorgt, die mit dem Diskettenkontroller kompatibel
waren.

Ich meinte eher, ob das Programm auch Sektoren "überspringt", wie es der
dd-Ansatz tut. Und was der generelle Sinn diese Programms ist. Images
schreiben?

Entstanden ist es zu einer Zeit, als es zum Kopieren einer Diskette noch
notwendig war, Quelle und Ziel mehrfach zu wechseln, wenn man nur ein
Laufwerk hatte.

Lästig, fehlerträchtig und einem Faultier nicht zumutbar.

Später tauchte dann dann das Bedürfnis auf, bootbare Disketten von 160K
auf 720K, 1.2M, 1.4 M etc. zu konvertieren.

Dann kamen einige Sonderformate dazu, eine Möglichkeit, mit defekten
Sektoren umzugehen etc. Zu faul, jetzt in den Source zu schauen. ;)

Hartmut

[Michael Baeuerle]

Post by Henning Paul
Hmm, anscheinend ist das genau falsch, ich war davon ausgegangen, daß
sich Sektoren auf den entgegengesetzten Seiten direkt abwechseln, aber
anscheinend liegen alle Sektoren eines Tracks auf einer Seite in
linearer Adressierung direkt nebeneinander.

So kenne ich das auch von alten Festplatten. Der Grund ist wohl, dass
das Umschalten des aktiven Kopfes zu lange dauert. Frueher hat man da
einen "head skew" von mehreren Sektoren benoetigt.

IIRC hat IBM sogar mal eine Platte gebaut, die nicht zylinderweise
geschrieben hat, sondern alle Tacks jeder Oberflaeche hintereinander
(weil sogar ein Seek auf die naechste Spur schneller ging wie das
Umschalten auf einen anderen Kopf des gleichen Zylinders). Das ergab
dann einen saegezahnfoermigen Verlauf der Transferrate.

Auch wenn Floppys langsamere Drehzahlen verwenden gab es das was du
vermutet hast da AFAIK nirgends. Die einzige Magnetplatte die es so
aehnlich macht ist wohl die Seagate ST-12450W "Barracuda 2HP", die
konnte nach diesem Schema pro Umdrehung zwei Tracks lesen und dadurch
bei gleicher Drehzahl die Transferrate verdoppeln. Sie hat aber dazu
nicht zwischen den Koepfen umgeschaltet sondern mit zwei
Auswertungs-units beide Tracks parallel gelesen die dann per Software
"interleaved" wurden.


Micha

[Henning Paul]

Post by Michael Baeuerle
Auch wenn Floppys langsamere Drehzahlen verwenden gab es das was du
vermutet hast da AFAIK nirgends. Die einzige Magnetplatte die es so
aehnlich macht ist wohl die Seagate ST-12450W "Barracuda 2HP", die
konnte nach diesem Schema pro Umdrehung zwei Tracks lesen und dadurch
bei gleicher Drehzahl die Transferrate verdoppeln. Sie hat aber dazu
nicht zwischen den Koepfen umgeschaltet sondern mit zwei
Auswertungs-units beide Tracks parallel gelesen die dann per Software
"interleaved" wurden.

Soweit ich weiß, lesen aber alle aktuellen Platten mit allen Köpfen
gleichzeitig und interleaven dann die Daten. Das kann einem allerdings
aufgrund der LBA-Adressierung egal sein.

Gruß
Henning

[Michael Baeuerle]

Post by Henning Paul

Post by Michael Baeuerle
Auch wenn Floppys langsamere Drehzahlen verwenden gab es das was du
vermutet hast da AFAIK nirgends. Die einzige Magnetplatte die es so
aehnlich macht ist wohl die Seagate ST-12450W "Barracuda 2HP", die
konnte nach diesem Schema pro Umdrehung zwei Tracks lesen und dadurch
bei gleicher Drehzahl die Transferrate verdoppeln. Sie hat aber dazu
nicht zwischen den Koepfen umgeschaltet sondern mit zwei
Auswertungs-units beide Tracks parallel gelesen die dann per Software
"interleaved" wurden.

Soweit ich weiß, lesen aber alle aktuellen Platten mit allen Köpfen
gleichzeitig und interleaven dann die Daten. Das kann einem allerdings
aufgrund der LBA-Adressierung egal sein.

Das kann ich nicht glauben, eine Platte darf doch heute nichts mehr
kosten. Woher hast du diese Information?

Ich weisz sicher, dass Seagate es schon bei der Barracuda 4 nicht mehr
so gemacht hat. Die Barracude 2HP hat dabei noch simple RLL Codierung
verwendet, bei heutigen Platten mit PRML waere wohl ein DSP pro
Datenseparator/Dekoder und damit Kopf noetig ... das waere finanziell
IMHO im besten Fall fuer high-end Platten akzeptabel (gerade die haben
aber eher viele Koepfe).

Ein weiteres Problem ist, dass es beim embedded Servo heutiger Platten
eigentlich gar nicht mehr moeglich ist mehrere Koepfe gleichzeitig zu
positionieren. Bei der Barracuda 2HP wurde dedicated Servo verwendet,
damit funktioniert es. Das kann man bei heutigen Datendichten aber nicht
mehr realisieren selbst wenn man alle 2s thermisch kalibrieren wuerde,
ausserdem verliert man einen Kopf und damit eine komplette Oberflaeche
=> Das tut bei wenigen Koepfen richtig weh [1].


Micha

[1] Die Barracuda 2HP hatte 10 Platters und 19 Koepfe, da fiel das
weniger ins Gewicht

[Henning Paul]

Post by Michael Baeuerle

Post by Henning Paul
Soweit ich weiß, lesen aber alle aktuellen Platten mit allen Köpfen
gleichzeitig und interleaven dann die Daten. Das kann einem
allerdings aufgrund der LBA-Adressierung egal sein.

Das kann ich nicht glauben, eine Platte darf doch heute nichts mehr
kosten. Woher hast du diese Information?

Ich habe eine diffuse Erinnerung an das "Plattenkarussell" in der c't,
möchte dafür aber auch nicht meine Hand ins Feuer legen.
Ich lese die aber auch schon im zwölften Jahr, und es kann durchaus
sein, daß es sich dabei um eine erwähnenswerte Spezialität eines
speziellen Modells gehandelt hat...

Post by Michael Baeuerle
Ein weiteres Problem ist, dass es beim embedded Servo heutiger Platten
eigentlich gar nicht mehr moeglich ist mehrere Koepfe gleichzeitig zu
positionieren.

Ok, das klingt durchaus alles plausibel und ich will Dir da auch gerne
glauben.

Gruß
Henning

[Alfred Weidlich]

Ich kenne nur Platten wo die Datenrate abnimmt um ganz gegen Ende wieder
anzusteigen.

[Henning Paul]

Post by Alfred Weidlich
Ich kenne nur Platten wo die Datenrate abnimmt um ganz gegen Ende
wieder anzusteigen.

Das wäre der Fall, wenn alle Plattenoberflächen ansich am Stück
beschrieben werden, jede zweite (bei nur 2 Oberflächen also _die_
zweite) dann rückwärte beschrieben wird. Ich habe damals in der c't als
noch Durchsatzkurven abgedruckt wurden _beides_ gesehen.

Gruß
Henning

[Holger Petersen]

Post by Henning Paul
Hmm, anscheinend ist das genau falsch, ich war davon ausgegangen, daß
sich Sektoren auf den entgegengesetzten Seiten direkt abwechseln, aber
anscheinend liegen alle Sektoren eines Tracks auf einer Seite in
linearer Adressierung direkt nebeneinander.

Es gibt (unter CP/M :-) fast alles.
Einige Möglichkeiten sind in der C'T 6/1985 ab Seite 125 beschrieben.

Wenn ich mal dazu komme, stelle ich diesen Artikel endlich mal Online ;-)

Gruss, Holger

[Sieghard Schicktanz]

Hallo Henning,
[Routine für partielles Kopieren]

Post by Henning Paul
Hmm, anscheinend ist das genau falsch, ich war davon ausgegangen, daß
sich Sektoren auf den entgegengesetzten Seiten direkt abwechseln, aber
anscheinend liegen alle Sektoren eines Tracks auf einer Seite in

Das ist bei CP/M alles ohne weiteres möglich, und noch mehr.
Auch möglich ist ein nettes Verwirrspielchen mit den Sektoren einer Spur:
da die alten Prozessoren langsam genug waren, auch bei Floppy-
Geschwindigkeit einen Sektor nicht schnell genug ablegen zu können, bevor
der nächste unter dem Kopf erschien, wurden vielfach die Sektoren nicht der
Reihe nach beschrieben, sondern mit Abständen, dem sog. "interleaving".
Das sah dann z.B. so aus, daß Sektor 1 als erster Sektor der Spur regulär
benutzt wurde, danach aber der zweite "logische" Sektor auf den physischen
Sektor 4 landete, und so weiter in der Reihenfolge (für 8 Sektoren/Spur)
1 - 4 - 7 - 2 - 5 - 8 - 3 - 6.
Das wäre ein 1:3 Interleave, es gab aber auch andere, und sogar solche
Schemata, wo der Interleave-Offset von Spur zu Spur variierte...

Also u.U. nix mit

Post by Henning Paul
linearer Adressierung direkt nebeneinander. ...

----

[Holger Petersen]

Post by Uwe Nass
Hallo zusammen,
Was ich brauche, ist ein Hinweis WIE ich
den Bootsektor, also Track 0, Sektor 1-8 umkopiere!

^^^ ^^^^^^^^^^

Was denn nun: *den* *einen* boot-Sektor
oder: die ganze Spur Null? :-)

Aber das scheint mir ganz einfach zu gehen:

dd if=Dein-image.bin bs=512 count=8 of=/dev/passendes.device


Du musst 'nur' noch herausfinden, welches das passende Device
ist...

Grübelnd, Holger

[Dirk Ohme]

Post by Uwe Nass
Also, um ehrlich zu sein, es handelt sich um ein image von
CCP/M-86 v3.1!

Dann bekommst Du eine ganz andere Antwort ;-)
http://www.cpm.z80.de/binary.html
... unter "CP/M-86" gibt es ein Image für 1,44MB-Disketten (dritter
Link im Absatz):
http://www.cpm.z80.de/download/144cpm86.zip

Insgesamt scheint http://www.cpm.z80.de/ recht interessant zu sein,
was das Thema "CP/M" anbelangt ...

HTH ;-)

Gruß, Dirk

[Dirk Ohme]

Post by Uwe Nass
Also, um ehrlich zu sein, es handelt sich um ein image von
CCP/M-86 v3.1!

Dann bekommst Du eine ganz andere Antwort ;-)
http://www.cpm.z80.de/binary.html
... unter "CP/M-86" gibt es ein Image für 1,44MB-Disketten (dritter
Link im Absatz):
http://www.cpm.z80.de/download/144cpm86.zip

Insgesamt scheint http://www.cpm.z80.de/ recht interessant zu sein,
was das Thema "CP/M" anbelangt ...

HTH ;-)

Gruß, Dirk

[Dirk Ohme]

Post by Uwe Nass
Also, um ehrlich zu sein, es handelt sich um ein image von
CCP/M-86 v3.1!

Dann bekommst Du eine ganz andere Antwort ;-)
http://www.cpm.z80.de/binary.html
... unter "CP/M-86" gibt es ein Image für 1,44MB-Disketten (dritter
Link im Absatz):
http://www.cpm.z80.de/download/144cpm86.zip

Insgesamt scheint http://www.cpm.z80.de/ recht interessant zu sein,
was das Thema "CP/M" anbelangt ...

HTH ;-)

Gruß, Dirk

[Wolfgang Bauer]

Dirk Ohme wrote:

Was ist denn da jetzt schief gelaufen? Du sendest dreimal das gleiche
Posting mit unterschiedlichen MIDs, ohne Referenc zum Posting auf das Du
antwortest.

Wolfgang

[Markus Wichmann]

Post by Wolfgang Bauer
Was ist denn da jetzt schief gelaufen? Du sendest dreimal das gleiche
Posting mit unterschiedlichen MIDs, ohne Referenc zum Posting auf das Du
antwortest.
Wolfgang

Gurgel Groups hat rumgezickt. Ich bekam gerade 4 Mails von ihm, wobei
die vierte die Erklärung enthielt.

HTH,
Markus

[Dirk Ohme]

Post by Markus Wichmann
Gurgel Groups hat rumgezickt. Ich bekam gerade 4 Mails von ihm, wobei
die vierte die Erklärung enthielt.

Sorry ... Google meinte jedesmal, dass es *nicht* geklappt hat. Jetzt
ist natürlich meine Glaskugel kaputt und ich weiss nicht, wann eine
Fehlermeldung von Google zutreffend, wann nicht zutreffend ist ...

Man möge mir das bitte nachsehen ... danke!

Gruß, Dirk

[Wolfgang Bauer]

Post by Dirk Ohme
Sorry ... Google meinte jedesmal, dass es *nicht* geklappt hat. Jetzt
ist natürlich meine Glaskugel kaputt und ich weiss nicht, wann eine
Fehlermeldung von Google zutreffend, wann nicht zutreffend ist ...

Ich habe auch in anderen Gruppen, von anderen Usern, gesehen, daß
Postings mehrfach gesendet wurden. Gmail ist anscheinend in Moment
kaputt.

Post by Dirk Ohme
Man möge mir das bitte nachsehen ... danke!

Nur wenn Du keinen anderen Newsclient benutzen kannst.

Wolfgang

[Jochen Lübbers]

Post by Wolfgang Bauer

Post by Dirk Ohme
Sorry ... Google meinte jedesmal, dass es *nicht* geklappt hat. Jetzt
ist natürlich meine Glaskugel kaputt und ich weiss nicht, wann eine
Fehlermeldung von Google zutreffend, wann nicht zutreffend ist ...

Ich habe auch in anderen Gruppen, von anderen Usern, gesehen, daß
Postings mehrfach gesendet wurden. Gmail ist anscheinend in Moment
kaputt.

Ist Google als Mail-Client nicht irgendwie immer kaputt? ;-)

EKNW/SCNR
Jochen.

[Dirk Ohme]

Post by Wolfgang Bauer
Nur wenn Du keinen anderen Newsclient benutzen kannst.

Von unterwegs leider nicht ...

[Wolfgang Bauer]

Post by Dirk Ohme

Post by Wolfgang Bauer
Nur wenn Du keinen anderen Newsclient benutzen kannst.

Von unterwegs leider nicht ...

http://www.newsoffice.de ist eine Alternative.

Wolfgang

[Alexander Skwar]

Post by Dirk Ohme

Post by Wolfgang Bauer
Nur wenn Du keinen anderen Newsclient benutzen kannst.

Von unterwegs leider nicht ...

http://www.newsoffice.de/ exisitert.

Alexander Skwar

[Holger Petersen]

Post by Wolfgang Bauer
Was ist denn da jetzt schief gelaufen? Du sendest dreimal das gleiche
Posting mit unterschiedlichen MIDs, ohne Referenc zum Posting auf das Du
antwortest.

Ein typischer Fall von:

| Path:
| kbbs.org!news.tng.de!news.addix.net!news.glorb.com!
| postnews.google.com!p47g2000hsd.googlegroups.com!not-for-mail
^^^^^^^^^^^^^^^^^

Fragend :-) Holger

[Dirk Ohme]

Post by Sieghard Schicktanz
Warum sollte ein 3,5*_Laufwerk _kein_ anderes Format können als das
üblicherweise verwendete?

Nun, es gibt manche exotischen Format, die man mit einem PC-Controller
einfach nicht lesen kann ... ich denke, bei 5 1/4" dürftest Du mit
Apple-II-Disketten Probleme bekommen, bei 3 1/2" mit Amiga-Disketten.
Die sind halt sehr "exotisch".

Post by Sieghard Schicktanz
[...] Das Problem könnte allerdings der _Treiber_ sein, der
für das "halbe" Format "double stepping" können muß, d.h. den
Kopfträgerschlitten für jeden Spurwechsel um _zwei_ Schritte weiterschalten.

Nun ... er hat ja ein Image und, wenn, dann ginge es ja um 5 1/4"
Disketten ... also brauchen wir uns um "double stepping" nicht
kümmern. Auch nicht um die Zwangsumschaltung der Drehzahl von 360 auf
300 U/min oder 300kbps statt 250/500kbps ...

Wenn er denn unbedingt das Image auf eine Diskette klatschen wöllte,
dann würde ich an seiner Stelle ausgehen von einer "normalen" PC-
Formatierung mit 720 oder 1440kB mit 80 Spuren zu je 9 oder 18
Sektoren, beidseitig. Und dann einfach nur die Sektoren beschreiben,
die im Image vorhanden sind, d.h. von jeder Spur nur den 1. bis 8.
Sektor. Das erfordert allerdings, dass das Image "intelligent"
geschrieben wird, indem 1 oder 10 leere Sektoren am Ende jeder Spur
eingefügt werden. Ich weiss jetzt auch nicht aus dem Stand heraus, ob
die zweite Seite sich jeweils spurweise oder am Ende der ersten Seite
einfügt unter Unix/Linux.

Also ein kleines Programm unter DOS oder Windows, das direkt auf die
jeweiligen physikalischen Sektoren zugreifen kann, wäre evtl.
schneller programmiert. Wenn das Betriebssystem dann so halbwegs
fehlerfrei programmiert ist, sollte es die Informationen aus dem
Bootsektor auswerten und erkennen, dass nur 8 anstatt von 9 bzw. 18
Sektoren Anwendung finden.

Post by Sieghard Schicktanz

Post by Henning Paul
einseitig?

Sicher einseitig bei 320KB (= 640KB/2).

Nope ... beidseitig, da 5 1/4".

Gruß, Dirk

[Uwe Nass]

Dirk Ohme wrote:

<snip>

Post by Dirk Ohme
Nun ... er hat ja ein Image und, wenn, dann ginge es ja um 5 1/4"
Disketten ... also brauchen wir uns um "double stepping" nicht
kümmern. Auch nicht um die Zwangsumschaltung der Drehzahl von 360 auf
300 U/min oder 300kbps statt 250/500kbps ...
Wenn er denn unbedingt das Image auf eine Diskette klatschen wöllte,
dann würde ich an seiner Stelle ausgehen von einer "normalen" PC-
Formatierung mit 720 oder 1440kB mit 80 Spuren zu je 9 oder 18
Sektoren, beidseitig. Und dann einfach nur die Sektoren beschreiben,
die im Image vorhanden sind, d.h. von jeder Spur nur den 1. bis 8.
Sektor. Das erfordert allerdings, dass das Image "intelligent"
geschrieben wird, indem 1 oder 10 leere Sektoren am Ende jeder Spur
eingefügt werden. Ich weiss jetzt auch nicht aus dem Stand heraus, ob
die zweite Seite sich jeweils spurweise oder am Ende der ersten Seite
einfügt unter Unix/Linux.
Also ein kleines Programm unter DOS oder Windows, das direkt auf die
jeweiligen physikalischen Sektoren zugreifen kann, wäre evtl.
schneller programmiert. Wenn das Betriebssystem dann so halbwegs
fehlerfrei programmiert ist, sollte es die Informationen aus dem
Bootsektor auswerten und erkennen, dass nur 8 anstatt von 9 bzw. 18
Sektoren Anwendung finden.

Post by Sieghard Schicktanz

Post by Henning Paul
einseitig?

Sicher einseitig bei 320KB (= 640KB/2).

Nope ... beidseitig, da 5 1/4".
Gruß, Dirk

Hallo Dirk,

du hast mein Anliegen bisher am besten verstanden! Es geht in der
Tat darum eine 1.44MB Diskette so zu beschreiben als waere sie eine
320K Diskette. D.h. man schreibe nur 8 Sektoren pro Track und nur
40 Tracks pro Seite, der Rest bleibt leer. Das muesste gehen, nur
wie?

BTW, die NG comp.os.cpm ist mir natuerlich bekannt und ich lese sie
regelmaessig! Gaby's CP/M Seite ebenfalls. Ich kenn auch einige DOS
Programme, die angeben mein Vorhaben zu beherrschen (IMG2DSK.COM,
DSKIMAGE.COM, etc.) aber es floppt nicht.

Besten Dank nochmals,

Uwe.

[Henning Paul]

Post by Uwe Nass
du hast mein Anliegen bisher am besten verstanden! Es geht in der
Tat darum eine 1.44MB Diskette so zu beschreiben als waere sie eine
320K Diskette. D.h. man schreibe nur 8 Sektoren pro Track und nur
40 Tracks pro Seite, der Rest bleibt leer. Das muesste gehen, nur
wie?

Wie willst Du dem gebooteten CP/M denn weismachen, daß es sich um ein
5,25" Laufwerk handele, wenn es sich in Wirklichkeit doch um ein 3,5"
Laufwerk handelt? Wäre es nicht einfacher, alle Dateien aus dem Image
mit den cpmtools auf eine CP/M-formatierte 3,5"-Diskette umzukopieren?

Das Problem ist meines Erachtens, daß viele hier in der NG glauben, die
Sektoren auf Disketten wären linear adressierbar und es würde
ausreichen, einfach die ersten 320k einer 1,44MB-formatierten Diskette
zu belegen. Ein Betriebssystem, das eine 320kB 5,25"-Diskette erwartet,
sagt nicht einfach "gib mir den Sektor Nummer 265885", sondern
adressiert den Sektor über BIOS-Routinen mit CHS-Notation.

Ich bin allerdings völlig überfragt, welche Diskettentypen CP/M
überhaupt unterstützt und ob es überhaupt die BIOS-Informationen über
die vorhandenen Laufwerke ausliest (bzw. verstehen kann). Ist das CP/M
für XT? Die hatten noch gar kein BIOS mit Floppykonfiguration, sondern
haben noch mit Dipswitches gearbeitet.

Gruß
Henning

[Dirk Ohme]

Henning Paul schrieb im Newsbeitrag

Post by Henning Paul
Wie willst Du dem gebooteten CP/M denn weismachen,
daß es sich um ein 5,25" Laufwerk handele, wenn es
sich in Wirklichkeit doch um ein 3,5" Laufwerk handelt?

Das brauchst Du nicht, weil es kein Betriebssystem kümmert ... wenn
man ein 5 1/4"-Laufwerk fest auf 300 U/min konfiguriert und im
BIOS-Setup als 1,44MB-Laufwerk deklariert, dann kannst Du wie beim 3
1/2"-Laufwerk 720 und 1440kB-Disks formatieren. Es gibt nämlich keine
Kennung am Shuggart-Bus, ob es sich um ein 3,5"-, 3 1/4"-, 3"- oder 5
1/4"-Laufwerk handelt!

Post by Henning Paul
Das Problem ist meines Erachtens, daß viele hier in der NG
glauben, die Sektoren auf Disketten wären linear adressierbar
und es würde ausreichen, einfach die ersten 320k einer
1,44MB-formatierten Diskette zu belegen.

Hey - wo habe ich das in news:***@o5g2000hsb.googlegroups.com behauptet? Es
ist nur so, dass unter Unix (und Linux, worum es sich ja hier in der
NG dreht) die Adressierung CHS auf lineare Sektoren gemappt wird.

Bitte lies doch nochmals mein Posting, auf das Du Dich indirekt
beziehst!

Post by Henning Paul
Ein Betriebssystem, das eine 320kB 5,25"-Diskette erwartet,
sagt nicht einfach "gib mir den Sektor Nummer 265885", sondern
adressiert den Sektor über BIOS-Routinen mit CHS-Notation.

Ja ... und diese Informationen über den Aufbau der Diskette befinden
sich üblicherweise im logischen Sektor 0 respektive im physikalischen
Sektor C/H/S = 0/0/1.

Post by Henning Paul
Ich bin allerdings völlig überfragt, welche Diskettentypen
CP/M überhaupt unterstützt [...]

Aha ... Rätselraten? Nun, es dürften weit mehr als 40 verschiedene
Formate sein ... u.a. auch noch solche auf 8"-Disketten. Insofern ist
CP/M einiges gewohnt an exotischen Formaten ;-)

Post by Henning Paul
und ob es überhaupt die BIOS-Informationen über
die vorhandenen Laufwerke ausliest

Die BIOS-Information interessiert nur dann, wenn man formatieren will.
Ansonsten hält sich das OS an den Bootsektor. Denn dort steht drin, um
was es sich handelt, wie der Aufbau ist. Das BIOS kann ja auch nicht
mitteilen, ob momentan eine HD- oder DD-Disk eingelegt ist ... das
"rät" das BIOS ja selber und schaltet solange um, bis was vernünftiges
über'n Äther kommt. Aber ob das DD-Format ein- oder beidseitig ist, 8
oder 9 Sektoren je Spur hat, das weiss es nicht. Auch nicht, ob im
HD-Format 12 oder 18 Sektoren je Spur gefahren werden.

[XT]

Post by Henning Paul
Die hatten noch gar kein BIOS mit Floppykonfiguration, sondern
haben noch mit Dipswitches gearbeitet.

Meinst Du? Na, da hatte ich aber andere Erfahrungen ... damals gab's
ja auch noch keine HD-Formate und 3 1/2" wurde auch erst ab MS-DOS
3.20 erstmalig unterstützt. Zu AT-Zeiten war aber PC-DOS 2.0 oder
MS-DOS 2.11 aktuell ... also die DIP-Schalter waren, soweit ich mich
erinnere, eher für die Konfiguration des installierten
Arbeitsspeichers und die Grafikkarte (MDA oder CGA) zuständig, nicht
aber die Floppy-Laufwerke, derer es damals noch 4 sein durften ...

Gruß, Dirk

[Henning Paul]

Post by Dirk Ohme
Es gibt nämlich keine
Kennung am Shuggart-Bus, ob es sich um ein 3,5"-, 3 1/4"-, 3"- oder 5
1/4"-Laufwerk handelt!

Das weiß ich wohl.

Post by Dirk Ohme

Post by Henning Paul
Das Problem ist meines Erachtens, daß viele hier in der NG
glauben, die Sektoren auf Disketten wären linear adressierbar
und es würde ausreichen, einfach die ersten 320k einer
1,44MB-formatierten Diskette zu belegen.

Mit "viele" meinte ich nicht Dich. :-)

Post by Dirk Ohme
Es
ist nur so, dass unter Unix (und Linux, worum es sich ja hier in der
NG dreht) die Adressierung CHS auf lineare Sektoren gemappt wird.

Klar, bei antiken Systemen aber nicht.

Post by Dirk Ohme
Ja ... und diese Informationen über den Aufbau der Diskette befinden
sich üblicherweise im logischen Sektor 0 respektive im physikalischen
Sektor C/H/S = 0/0/1.

Ok. Diese Information ist dann ja wohl in Uwes Diskettenimage enthalten.

Post by Dirk Ohme
Die BIOS-Information interessiert nur dann, wenn man formatieren will.
Ansonsten hält sich das OS an den Bootsektor. Denn dort steht drin, um
was es sich handelt, wie der Aufbau ist. Das BIOS kann ja auch nicht
mitteilen, ob momentan eine HD- oder DD-Disk eingelegt ist ... das
"rät" das BIOS ja selber und schaltet solange um, bis was vernünftiges
über'n Äther kommt. Aber ob das DD-Format ein- oder beidseitig ist, 8
oder 9 Sektoren je Spur hat, das weiss es nicht. Auch nicht, ob im
HD-Format 12 oder 18 Sektoren je Spur gefahren werden.

Ok. Dann sollte es ja tatsächlich ausreichen, dafür zu sorgen, daß die
richtigen Sektoren an den richtigen C/H/S-Adressen gefunden werden.

Post by Dirk Ohme
[XT]

Post by Henning Paul
Die hatten noch gar kein BIOS mit Floppykonfiguration, sondern
haben noch mit Dipswitches gearbeitet.

Meinst Du? Na, da hatte ich aber andere Erfahrungen ... damals gab's
ja auch noch keine HD-Formate und 3 1/2" wurde auch erst ab MS-DOS
3.20 erstmalig unterstützt.

Ja eben. Da gabs nix einzustellen.

Post by Dirk Ohme
Zu AT-Zeiten war aber PC-DOS 2.0 oder
MS-DOS 2.11 aktuell ... also die DIP-Schalter waren, soweit ich mich
erinnere, eher für die Konfiguration des installierten
Arbeitsspeichers und die Grafikkarte (MDA oder CGA) zuständig, nicht
aber die Floppy-Laufwerke, derer es damals noch 4 sein durften ...

Aber CP/M-86 ist doch für XT-Systeme gewesen, oder?

Gruß
Henning

[Helmut Hullen]

Hallo, Henning,

Post by Henning Paul
Aber CP/M-86 ist doch für XT-Systeme gewesen, oder?

Nein - nicht nur.

Viele Gruesse!
Helmut

[Dirk Ohme]

Post by Henning Paul
Aber CP/M-86 ist doch für XT-Systeme gewesen, oder?

Jo ... es konnte aber auch nur auf dem Aufsetzen, was als "Basis" für
MS/PC-DOS geschaffen war. Insofern musste man das auf BIOS-Ebene
kompatibel sein.

Gruß, Dirk

[Sieghard Schicktanz]

Hallo Dirk,

Post by Dirk Ohme

Post by Henning Paul
Ein Betriebssystem, das eine 320kB 5,25"-Diskette erwartet,
sagt nicht einfach "gib mir den Sektor Nummer 265885", sondern
adressiert den Sektor über BIOS-Routinen mit CHS-Notation.

Ja ... und diese Informationen über den Aufbau der Diskette befinden
sich üblicherweise im logischen Sektor 0 respektive im physikalischen
Sektor C/H/S = 0/0/1.

Nicht bei CP/M, wenigstens nicht bei den Formaten, die nicht spezifisch auf
MS-DOS-Kompatibilität ausgelegt waren. Das "media byte" ist eine MS-
Erfindung, die - wie bei solchen offenbar üblich - bei weitem nicht
konsequent angewandt wurde, so daß das tatsächliche Format in einigen Fällen
dann doch wieder durch "Raten" und Nachprüfen ermittelt werden muß.

Post by Dirk Ohme

Post by Henning Paul
Ich bin allerdings völlig überfragt, welche Diskettentypen
CP/M überhaupt unterstützt [...]

Aha ... Rätselraten? Nun, es dürften weit mehr als 40 verschiedene
Formate sein ... u.a. auch noch solche auf 8"-Disketten. Insofern ist
CP/M einiges gewohnt an exotischen Formaten ;-)

Kann man wohl sagen...

Post by Dirk Ohme

Post by Henning Paul
und ob es überhaupt die BIOS-Informationen über
die vorhandenen Laufwerke ausliest

Die BIOS-Information interessiert nur dann, wenn man formatieren will.
Ansonsten hält sich das OS an den Bootsektor. Denn dort steht drin, um
was es sich handelt, wie der Aufbau ist. Das BIOS kann ja auch nicht

Bei CP/M eben nicht - da kennt das System (BIOS) das Format, muß es kennen,
damit es damit arbeiten kann. Im BIOS mußte für jedes unterstützte Format
ein passender Deskriptor-Block vorhanden sein, der auch im normalen Lese-
Schreib-Betrieb benutzt wurde. Lediglich beim "Einloggen" einer Diskette
fragte das System ggfs. alle in Frage kommenden Formate ab und ermittelte
den passenden Deskriptor - falls das vom Systemersteller implementiert war.

----

[Dirk Ohme]

Sieghard Schicktanz schrieb im Newsbeitrag

Post by Sieghard Schicktanz
Nicht bei CP/M, wenigstens nicht bei den Formaten, die nicht
spezifisch auf MS-DOS-Kompatibilität ausgelegt waren. Das
"media byte" ist eine MS-Erfindung [...]

Ich rede *nicht* vom Media-Byte. Dieses wird ja ab Windows 2003 Server
nicht mehr beachtet.

Gruß, Dirk

[Henning Paul]

Post by Dirk Ohme
Sieghard Schicktanz schrieb im Newsbeitrag

Post by Sieghard Schicktanz
Nicht bei CP/M, wenigstens nicht bei den Formaten, die nicht
spezifisch auf MS-DOS-Kompatibilität ausgelegt waren. Das
"media byte" ist eine MS-Erfindung [...]

Ich rede *nicht* vom Media-Byte. Dieses wird ja ab Windows 2003 Server
nicht mehr beachtet.

Ansonsten enthält der BPB aber nur noch Informationen über Anzahl Bytes
pro Sektor, Sektoren pro Spur und Anzahl Köpfe
(http://support.microsoft.com/kb/140418). Die Anzahl Spuren ist nicht
festgelegt.

Gruß
Henning

[Dirk Ohme]

Henning Paul schrieb im Newsbeitrag

Post by Henning Paul
Ansonsten enthält der BPB aber nur noch Informationen über
Anzahl Bytes pro Sektor, Sektoren pro Spur und Anzahl Köpfe

... und die Gesamtzahl an Sektoren ;-)

Gruß, Dirk

[Henning Paul]

Post by Dirk Ohme
Henning Paul schrieb im Newsbeitrag

Post by Henning Paul
Ansonsten enthält der BPB aber nur noch Informationen über
Anzahl Bytes pro Sektor, Sektoren pro Spur und Anzahl Köpfe

... und die Gesamtzahl an Sektoren ;-)

In diesem Dateisystem, nicht auf dem gesamten Datenträger!

Gruß
Henning

[Dirk Ohme]

Henning Paul schrieb im Newsbeitrag

Post by Henning Paul
In diesem Dateisystem, nicht auf dem
gesamten Datenträger!

Also mir haben diese Angaben bei der Programmierung gereicht, um den
Zugriff auf die komplette Disk zu haben ... inkl. eigenem Treiber
für's FAT-Dateisystem. Deshalb weiss ich beim besten Willen nicht, was
Dir noch fehlt. Und: Nein, ich musst das das Media-Byte nicht
auswerten.

Gruß, Dirk

[Henning Paul]

Post by Dirk Ohme
Henning Paul schrieb im Newsbeitrag

Post by Henning Paul
In diesem Dateisystem, nicht auf dem
gesamten Datenträger!

Also mir haben diese Angaben bei der Programmierung gereicht, um den
Zugriff auf die komplette Disk zu haben ... inkl. eigenem Treiber
für's FAT-Dateisystem. Deshalb weiss ich beim besten Willen nicht, was
Dir noch fehlt. Und: Nein, ich musst das das Media-Byte nicht
auswerten.

Das bestreite ich ja nicht. Sieghard meinte ja, CP/M würde sich _gar_
nicht um die Geometrieinformationen im FAT-Bootsektor kümmern. Das
fände ich verständlich, da FAT ja vermutlich nicht das "native"
CP/M-Dateisystem ist. Kennen die CP/M-eigenen Dateisysteme auch einen
Sektor mit Geometrieinformationen oder haben die alle den FAT-BPB
übernommen?

Gruß
Henning

[Holger Petersen]

Post by Henning Paul
Kennen die CP/M-eigenen Dateisysteme

Es gibt nur *eines*..! [*]

Post by Henning Paul
auch einen
Sektor mit Geometrieinformationen

Nein; allerdings liegt der "Disk Parameter Block" wohl doch 'irgendwo'
im BIOS und das wurde damals von der Boot-Floppy geladen.

Post by Henning Paul
oder haben die alle den FAT-BPB
übernommen?

Haeee?

Was war zuerst da: "Die Henne oder das Ei?"

Zu obiger Frage:

CP/M entstand 1975; die Version 1.4 hatte schon die Möglichkeit, mit
unterschiedlichen Disk-Formaten umzugehen. Allerdings nur undokumen-
tiert fest im CDOS. Ich hatte einen SD-Sales Floppy-Controller mit
je einer 8-Zoll und 5.25-Zoll Boot-Floppy. [Gekauft Dez. 1997 in LA]

Die Version 2.x (mit x=0,1,2) kam wenig später heraus. Dort wurde der
DPB in das BIOS verfrachtet; zusammen mit den nötigen BIOS-Aufrufen.
Spätere BIOS-Versionen erlaubten es dann teilweise, für unterschied-
liche Floppy-Formate auch unterschiedliche DPBs zu aktivieren. Teil-
weise automatisch oder per Zusatz-Programm

Das MS/DOS mit dem FAT-Format kam erst 1981, wenn man von MSX absieht.

Gruss, Holger

[*] Ich denke, dass die unterschiedlichen Eigenschaften "Sektoren pro Spur",
Anzahl von Spuren und Seiten sowie Sektor-Anordnungen und -zählungen
trotzdenm ein einziges _Datei_-System beinhalten.
Siehe auch die schon zitierte C'T...

[Henning Paul]

Post by Holger Petersen

Post by Henning Paul
oder haben die alle den FAT-BPB
übernommen?

Haeee?
Was war zuerst da: "Die Henne oder das Ei?"
CP/M entstand 1975; die Version 1.4 hatte schon die Möglichkeit, mit
unterschiedlichen Disk-Formaten umzugehen.

Ich bezog mich jetzt auch ausschließlich auf CP/M-86. Welches
Dateisystem kam da zum Einsatz und waren dort auch
Geometrieinformationen im Sektor 0 zu finden?

Post by Holger Petersen
Siehe auch die schon zitierte C'T...

Auf die habe ich leider keinen Zugriff.

Gruß
Henning

[Sieghard Schicktanz]

Hallo Henning,

Post by Henning Paul
Das bestreite ich ja nicht. Sieghard meinte ja, CP/M würde sich _gar_
nicht um die Geometrieinformationen im FAT-Bootsektor kümmern. Das
fände ich verständlich, da FAT ja vermutlich nicht das "native"
CP/M-Dateisystem ist. Kennen die CP/M-eigenen Dateisysteme auch einen
Sektor mit Geometrieinformationen oder haben die alle den FAT-BPB
übernommen?

Soweit ich noch weiß, haben "die CP/M-eigenen Dateisysteme" _keine_
Geometrie-Informationen auf der Diskette. Den FAT-BPB können die
einigermaßen schlecht übernommen haben, weil, die waren ja schon früher
da... ;o)

(Bei CP/M war die erste Spur der Diskette ursprünglich für das reserviert,
was dann bei den IBM-PCs "BIOS" hieß - in der Maschine selber war nur ein
kleiner Lader im EPROM vorhanden, der genau dafür gut war, das "BIOS" in
den Speicher zu laden und das dann den Rest erledigen zu lassen. _Was_ im
einzelnen dieses "BIOS" enthielt und tat, war dem System(h)ersteller
überlassen.)

----

[Juergen Ilse]

Hallo,

Post by Dirk Ohme
Henning Paul schrieb im Newsbeitrag

Post by Henning Paul
In diesem Dateisystem, nicht auf dem
gesamten Datenträger!

Also mir haben diese Angaben bei der Programmierung gereicht, um den
Zugriff auf die komplette Disk zu haben ... inkl. eigenem Treiber
für's FAT-Dateisystem. Deshalb weiss ich beim besten Willen nicht, was
Dir noch fehlt. Und: Nein, ich musst das das Media-Byte nicht
auswerten.

Es sind alle notwendigen Daten vorhanden, und das Disk-Media-Byte ist
ein seit Jahrzehnten unnoetiges und groesstenteils unbrauchbares Relikt,
das idiotischerweise von DOS *trotzdem noch sehr lange mehr oder weniger
intensiv vom Treiberr verwendet wurde. Pikanterweise waren die Empfehlungen
fuer Diskettentreiber aus der M$-Programmierdokumentation den wirklichen
DOS-internen Treibern teils meilenweit voraus ...

Ich habe zu DOS3.1 Zeiten mal den DOS-internen Treiber der von mir ein-
gesetzten DOS-Version gepatched, und den ganzen "Media-Byte" (und sons-
tigen) Unfug gegen sinnvolle Plausibilitaetspruefungen der BPB-Daten
ersetzt. Das hatte mich damals eine Woche Arbeit gekostet. Anschlies-
sen d kam *meine* *gepatchte* DOS-Version auch ohne zusaetzlichen Trei-
ber mit z.B. Atari-ST Disketten klar ... Atari hat uebrigens in TOS1.4
damals in die Formatierroutine eingebaut, dass bei "nicht bootfaehigen
Atari-Disketten" in das erste Byte des Bootsektors ein Sprungbefehl der
8086-Maschinensprache eingefuegt wurde, weil MS-DOS idiotischerweise
darauf pruefte und sich bei "nicht vorhandensein" wieder auf die voel-
lig unbrauchbare "Disk-Media-Byte" Methode zur Bestimmung des Formats
verliess (was i.d.R. voellig daneben ging, wenn man nicht mit irgend
welchen "DISKPARM" Zeilen in der Config.sys irgendwelche Treiberinternen
Defaults "umgepatched" hatte ...). Die "treiberinternen Defaults" dienten
urspruenglich dazu, DOS1.x Disketten erkennen zu koennen, bei denen teils
noch kein asuwertbarer BPB im Bootsektor stand. Spaeter wurde dieser
Mechanismus dazu missbraucht, dem System bei fehlschlagen der unsinnigen
Pruefungen (fehlender 8086-Sprungbefehl am Anfang des Bootsektors) doch
noch eine Methode zum "erraten des Formats" bereitzustellen ...

Eigentlich war das alles voelliger Unfug und haette schon Jahre vorher
entsorgt gehoert, aber vermutlich findet man diesen Unfug teilweise
sogar noch bei Windows Vista ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

[Sieghard Schicktanz]

Hallo Uwe,

Post by Uwe Nass
du hast mein Anliegen bisher am besten verstanden! Es geht in der
Tat darum eine 1.44MB Diskette so zu beschreiben als waere sie eine
320K Diskette. D.h. man schreibe nur 8 Sektoren pro Track und nur
40 Tracks pro Seite, der Rest bleibt leer. Das muesste gehen, nur
wie?

Dann schau' Dir doch mal die schon erwähnten "cpmtools" an, da kannst Du
notfalls Dein Format sogar selber definieren. Eventuell mußt Du Dir aber
trotzdem eine "DD"-Diskette besorgen oder bei eienr HD-Diskette das
"unbenutzte" Loch (also nicht das für den Schreibschutz) zupappen.

Post by Uwe Nass
BTW, die NG comp.os.cpm ist mir natuerlich bekannt und ich lese sie
regelmaessig! Gaby's CP/M Seite ebenfalls. Ich kenn auch einige DOS
Programme, die angeben mein Vorhaben zu beherrschen (IMG2DSK.COM,
DSKIMAGE.COM, etc.) aber es floppt nicht.

Na, mein selber definiertes Format für das Siemens PCPM funktionierte
wenigstens bis vor kurzem schon:

/etc/diskdefs:

# BEGIN SIE3 Siemens PG-635 DSDD 3.5"
# DENSITY MFM,LOW
# CYLINDERS 80
# SIDES 2
# SECTORS 9,512
# SIDE1 0 1,2,3,4,5,6,7,8,9
# SIDE2 1 1,2,3,4,5,6,7,8,9
# ORDER SIDES
# LABEL SIE3
# BSH 4 BLM 15 EXM 0 DSM 350 DRM 255 AL0 0F0H AL1 0 OFS 4
# END
SIE3 512 160 9 2048 256 1 4 p2dos

# format sector tracks sectors block directory skew boot
# name size size size factor tracks
#
ibm-3740 128 77 26 1024 64 6 2 p2dos
4mb-hd 128 1024 32 2048 256 1 0 p2dos
pcw 512 40 9 1024 64 1 1 3
# this format uses 15 sectors per track, but 30 per cylinder
pc1.2m 512 80 30 4096 256 1 0 3
cf2dd 512 160 9 2048 256 1 1 3
# Royal alphatronic
# setfdprm /dev/fd1 dd ssize=256 cyl=40 sect=16 head=2
alpha 256 40 32 2048 128 1 2 2.2

Ist schon etwas angetagt... ;-)

BTW, aus der man page:
AUTHOR
Michael Haardt (***@cantor.informatik.rwth-aachen.de)

----

[Uwe Nass]

Post by Sieghard Schicktanz
Hallo Uwe,

Post by Uwe Nass
du hast mein Anliegen bisher am besten verstanden! Es geht in der
Tat darum eine 1.44MB Diskette so zu beschreiben als waere sie eine
320K Diskette. D.h. man schreibe nur 8 Sektoren pro Track und nur
40 Tracks pro Seite, der Rest bleibt leer. Das muesste gehen, nur
wie?

Dann schau' Dir doch mal die schon erwähnten "cpmtools" an, da kannst Du
notfalls Dein Format sogar selber definieren. Eventuell mußt Du Dir aber
trotzdem eine "DD"-Diskette besorgen oder bei eienr HD-Diskette das
"unbenutzte" Loch (also nicht das für den Schreibschutz) zupappen.

Post by Uwe Nass
BTW, die NG comp.os.cpm ist mir natuerlich bekannt und ich lese sie
regelmaessig! Gaby's CP/M Seite ebenfalls. Ich kenn auch einige DOS
Programme, die angeben mein Vorhaben zu beherrschen (IMG2DSK.COM,
DSKIMAGE.COM, etc.) aber es floppt nicht.

Na, mein selber definiertes Format für das Siemens PCPM funktionierte
# BEGIN SIE3 Siemens PG-635 DSDD 3.5"
# DENSITY MFM,LOW
# CYLINDERS 80
# SIDES 2
# SECTORS 9,512
# SIDE1 0 1,2,3,4,5,6,7,8,9
# SIDE2 1 1,2,3,4,5,6,7,8,9
# ORDER SIDES
# LABEL SIE3
# BSH 4 BLM 15 EXM 0 DSM 350 DRM 255 AL0 0F0H AL1 0 OFS 4
# END
SIE3 512 160 9 2048 256 1 4 p2dos
# format sector tracks sectors block directory skew boot
# name size size size factor tracks
#
ibm-3740 128 77 26 1024 64 6 2 p2dos
4mb-hd 128 1024 32 2048 256 1 0 p2dos
pcw 512 40 9 1024 64 1 1 3
# this format uses 15 sectors per track, but 30 per cylinder
pc1.2m 512 80 30 4096 256 1 0 3
cf2dd 512 160 9 2048 256 1 1 3
# Royal alphatronic
# setfdprm /dev/fd1 dd ssize=256 cyl=40 sect=16 head=2
alpha 256 40 32 2048 128 1 2 2.2
Ist schon etwas angetagt... ;-)
AUTHOR
----

Hallo Sieghard,

das SIE3 format ist fuer eine 720K 3.5" Diskette. DOSPLUS v1.2
erkennt sie als 160K CP/M Diskette. Lustig, nur hilft mir das nicht
weiter.

Das "Royal alphatronic" format ist uebrigens von mir!

Gruss,

Uwe.

[Sieghard Schicktanz]

Hallo Uwe,

Post by Uwe Nass

Post by Sieghard Schicktanz
Na, mein selber definiertes Format für das Siemens PCPM funktionierte

...

Post by Uwe Nass
das SIE3 format ist fuer eine 720K 3.5" Diskette. DOSPLUS v1.2

Stimmt, das kommt da so 'raus. Da war Siemens direkt mal richtig "modern";)

Post by Uwe Nass
erkennt sie als 160K CP/M Diskette. Lustig, nur hilft mir das nicht
weiter.

Ist ja auch nicht als Lösung für Dein spezifisches Problem angegeben,
sondern als Hinweis auf die Möglichkeiten dazu...

Post by Uwe Nass
Das "Royal alphatronic" format ist uebrigens von mir!

Na, dann hast Du doch beste Voraussetzungen, das für Dich richtige Format
selber zu definieren und dann auch zu benutzen!?

----

[Sieghard Schicktanz]

Hallo Dirk,

Post by Dirk Ohme
einfach nicht lesen kann ... ich denke, bei 5 1/4" dürftest Du mit
Apple-II-Disketten Probleme bekommen, bei 3 1/2" mit Amiga-Disketten.
Die sind halt sehr "exotisch".

Das gilt auch für 3,5", wenn die "Apple-moduliert" geschrieben sind.
Apple hat halt ein Aufzeichnungsverfahren benutzt, das k(aum )ein PC-
gängiger FDC kann (und die neueren im Chipsatz integrierten sowieso nicht
mehr). Aber wenn das Image schon im PC-Format vorliegt, dann muß es auch
für einen solchen Controller "verdaulich" sein, es geht "nur noch" um die
"physische Verteilung" der Sektoren. Und die bestimmt der Treiber in
Zusammenarbeit mit dem Laufwerk.

Post by Dirk Ohme
Nun ... er hat ja ein Image und, wenn, dann ginge es ja um 5 1/4"
Disketten ... also brauchen wir uns um "double stepping" nicht

Warum das? Es sollte doch eine 3,5"-Diskette beschrieben werden?

Post by Dirk Ohme
kümmern. Auch nicht um die Zwangsumschaltung der Drehzahl von 360 auf
300 U/min oder 300kbps statt 250/500kbps ...

Ob die Drehzahl oder die Datenrate geschaltet werden, ist egal - das
Aufzeichnungsformat muß halt stimmen.

Post by Dirk Ohme
Wenn er denn unbedingt das Image auf eine Diskette klatschen wöllte,
dann würde ich an seiner Stelle ausgehen von einer "normalen" PC-

..
Dann würde ich erstmal in meinem Fundus kramen, feststellen, daß ich ein
paar Programme habe, die auch solche Sonderformate können (und denen man
sogar weitere beibringen kann), und die dazu hernehmen.
(cpmtools, gibt's bzw. gab's zumindest schon fertig verpackt für diverse
Distributionen.)

Post by Dirk Ohme
Also ein kleines Programm unter DOS oder Windows, das direkt auf die
jeweiligen physikalischen Sektoren zugreifen kann, wäre evtl.
schneller programmiert. Wenn das Betriebssystem dann so halbwegs

Wozu neu programmieren, wenn's sowas schon in vielfacher Ausfertigung gibt?

----

[Dirk Ohme]

Post by Sieghard Schicktanz
Das gilt auch für 3,5", wenn die "Apple-moduliert" geschrieben sind.

Oh ja ... jetzt wo Du es sagst, kommen mir da auch solche
Erinnerungen ... ;-)

Post by Sieghard Schicktanz
..
Dann würde ich erstmal in meinem Fundus kramen, feststellen, daß ich ein
paar Programme habe, die auch solche Sonderformate können (und denen man
sogar weitere beibringen kann), und die dazu hernehmen.

Hast Du noch welche? Ich hatte mal welche, aber seit ich DOS vor 10
Jahren verlassen habe, gibt's da nichts mehr bei mir. Allerdings hatte
ich seit 10 Jahren auch keine Erfordernisse in diese Richtung ...

Post by Sieghard Schicktanz
Wozu neu programmieren, wenn's sowas schon in vielfacher Ausfertigung gibt?

Hast Du noch Links zu solchen Programmen?

Gruß, Dirk

[Sieghard Schicktanz]

Hallo Dirk,

Post by Dirk Ohme

Post by Sieghard Schicktanz
Dann würde ich erstmal in meinem Fundus kramen, feststellen, daß ich ein
paar Programme habe, die auch solche Sonderformate können (und denen man
sogar weitere beibringen kann), und die dazu hernehmen.

Hast Du noch welche? Ich hatte mal welche, aber seit ich DOS vor 10

Hab' ich noch welche. Für Linux hab' ich ja eins schon genannt: die
"cpmtools". Es gibt noch ein paar, aber ich bin damit soweit klar gekommen,
wie ich's gebraucht habe.
Für Dos habe ich auch noch was, eins nennt sich "AME86", das habe ich aber
eigentlich nie richtig in Benutzung gehabt, und dann habe ich da noch ein
"22DISK", das ich vor den Linux-"cpmtools" benutzt habe.

Post by Dirk Ohme
Hast Du noch Links zu solchen Programmen?

Brauchst Du welche?

----