info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Massenspeicher und GEMDOS
20 views
Skip to first unread message
Gerhard Stoll
Sep 4, 2016, 1:01:57 PM9/4/16
to
Hallo,
ich würde gerne einen Treiber für einen Massenspeicher erstellen,
welcher im Prinzip einer Diskette im MS-DOS (FAT12) Format entspricht.
Allerdings frage ich mich im Moment ob das GEMDOS damit zurecht kommt.
Wobei es mir speziell um das GEMDOS vom Milan bzw. MagiCMilan 6.2 geht.
An Daten hätte ich das die Sektorgröße zwischen 128 und 512Bytes liegen
kann und es nur ein FAT gibt. Letztes scheint wohl das Hauptproblem zu
sein, denn ich lese immer nur das es beim Atari zwei FATs sein müssen.
Kann jemand sagen ob das genannte System damit zu recht kommt? Ich finde
dazu keine richtige Information.
Wenn das geht, dann frage ich mich noch was man im BIOS Parameter Block
beim dem Eintrag "Start der 2. FAT" angibt. Oder ist das unwichtig, wenn
in bflags das entsprechende Bit sitzt?
<http://toshyp.atari.org/de/00300b.html#BPB>
Gerhard
ich würde gerne einen Treiber für einen Massenspeicher erstellen,
welcher im Prinzip einer Diskette im MS-DOS (FAT12) Format entspricht.
Allerdings frage ich mich im Moment ob das GEMDOS damit zurecht kommt.
Wobei es mir speziell um das GEMDOS vom Milan bzw. MagiCMilan 6.2 geht.
An Daten hätte ich das die Sektorgröße zwischen 128 und 512Bytes liegen
kann und es nur ein FAT gibt. Letztes scheint wohl das Hauptproblem zu
sein, denn ich lese immer nur das es beim Atari zwei FATs sein müssen.
Kann jemand sagen ob das genannte System damit zu recht kommt? Ich finde
dazu keine richtige Information.
Wenn das geht, dann frage ich mich noch was man im BIOS Parameter Block
beim dem Eintrag "Start der 2. FAT" angibt. Oder ist das unwichtig, wenn
in bflags das entsprechende Bit sitzt?
<http://toshyp.atari.org/de/00300b.html#BPB>
Gerhard
Christian Zietz
Sep 4, 2016, 4:08:44 PM9/4/16
to
Gerhard Stoll schrieb:
> ich würde gerne einen Treiber für einen Massenspeicher erstellen,
> welcher im Prinzip einer Diskette im MS-DOS (FAT12) Format entspricht.
> Allerdings frage ich mich im Moment ob das GEMDOS damit zurecht kommt.
>
> Wobei es mir speziell um das GEMDOS vom Milan bzw. MagiCMilan 6.2 geht.
>
> An Daten hätte ich das die Sektorgröße zwischen 128 und 512Bytes liegen
> kann und es nur ein FAT gibt. Letztes scheint wohl das Hauptproblem zu
> sein, denn ich lese immer nur das es beim Atari zwei FATs sein müssen.
Speziell für den Milan kann ich Dir das nicht sagen, weil meine gesamte
Dokumentation aus der Zeit davon ist. Da bleibt im Zweifelsfall nur testen.
Das mit den zwei FATs galt definitiv für TOS 1.0x, in neueren Versionen
könnte es gefixt sein (oder auch nicht). Mit Sicherheit kann ich sonst
nur noch für EmuTOS sprechen, das weiterhin zwei FATs erwartet.
RAM-Disks haben das früher so gelöst, dass Zugriffe auf die zweite FAT
einfach auf die erste umgebogen wurden. Im "Scheibenkleister" ist das im
Beispiel "Luftschloss" beschrieben.
Ich würde mir aber eher Sorgen um die (logische) Sektorgröße machen.
Sektoren kleiner 512 Bytes sind/waren doch sehr unüblich und das
Profibuch verortet die zulässigen Werte zwischen 512 und 4096 Bytes. Wie
groß sind denn die Cluster auf dem Dateisystem?
Grüße
Christian
--
Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA
> ich würde gerne einen Treiber für einen Massenspeicher erstellen,
> welcher im Prinzip einer Diskette im MS-DOS (FAT12) Format entspricht.
> Allerdings frage ich mich im Moment ob das GEMDOS damit zurecht kommt.
>
> Wobei es mir speziell um das GEMDOS vom Milan bzw. MagiCMilan 6.2 geht.
>
> An Daten hätte ich das die Sektorgröße zwischen 128 und 512Bytes liegen
> kann und es nur ein FAT gibt. Letztes scheint wohl das Hauptproblem zu
> sein, denn ich lese immer nur das es beim Atari zwei FATs sein müssen.
Dokumentation aus der Zeit davon ist. Da bleibt im Zweifelsfall nur testen.
Das mit den zwei FATs galt definitiv für TOS 1.0x, in neueren Versionen
könnte es gefixt sein (oder auch nicht). Mit Sicherheit kann ich sonst
nur noch für EmuTOS sprechen, das weiterhin zwei FATs erwartet.
RAM-Disks haben das früher so gelöst, dass Zugriffe auf die zweite FAT
einfach auf die erste umgebogen wurden. Im "Scheibenkleister" ist das im
Beispiel "Luftschloss" beschrieben.
Ich würde mir aber eher Sorgen um die (logische) Sektorgröße machen.
Sektoren kleiner 512 Bytes sind/waren doch sehr unüblich und das
Profibuch verortet die zulässigen Werte zwischen 512 und 4096 Bytes. Wie
groß sind denn die Cluster auf dem Dateisystem?
Grüße
Christian
--
Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA
Gerhard Stoll
Sep 5, 2016, 1:41:36 PM9/5/16
to
Am 04.09.16 um 22:08 schrieb Christian Zietz:
> Speziell für den Milan kann ich Dir das nicht sagen, weil meine gesamte
> Dokumentation aus der Zeit davon ist.
Müsste von der Theorie wie beim Falcon sein, da es ja ein runderneuertes
TOS 4.04 ist.
> Ich würde mir aber eher Sorgen um die (logische) Sektorgröße machen.
> Sektoren kleiner 512 Bytes sind/waren doch sehr unüblich und das
> Profibuch verortet die zulässigen Werte zwischen 512 und 4096 Bytes.
Ich habe da ehr sorgen um die FAT gehabt. Sektorgrößen sind für mich nur
Speicherbereiche.
> Wie groß sind denn die Cluster auf dem Dateisystem?
Ein Sektor pro Cluster.
Gerhard
> Speziell für den Milan kann ich Dir das nicht sagen, weil meine gesamte
> Dokumentation aus der Zeit davon ist.
TOS 4.04 ist.
> Ich würde mir aber eher Sorgen um die (logische) Sektorgröße machen.
> Sektoren kleiner 512 Bytes sind/waren doch sehr unüblich und das
> Profibuch verortet die zulässigen Werte zwischen 512 und 4096 Bytes.
Speicherbereiche.
> Wie groß sind denn die Cluster auf dem Dateisystem?
Gerhard
Christian Zietz
Sep 5, 2016, 2:16:13 PM9/5/16
to
Gerhard Stoll schrieb:
> Sektorgrößen sind für mich nur
> Speicherbereiche.
Nützt halt nix, wenn sich das Betriebssystem beim Umrechnen in
Sektornummern vertut, weil niemand mit Sektoren kleiner 512 Byte
gerechnet hat. Wäre mir jetzt langweilig würde ich einfach mal ein
entsprechendes Image auf- und Hatari z.B. mit Falcon-TOS vorsetzen. Der
Milan (und noch mehr MagiCMilan) lassen sich meines Wissens nach nicht
emulieren.
> Ein Sektor pro Cluster.
Das wäre dann das nächste Problem, denn GEMDOS geht fest von zwei
Sektoren pro Cluster aus. Laut
<http://joo.kie.sk/wp-content/uploads/2013/05/Atari_HD_File_Sytem_Reference_Guide.pdf>
gilt das auch rauf bis zum Falcon.
> Sektorgrößen sind für mich nur
> Speicherbereiche.
Sektornummern vertut, weil niemand mit Sektoren kleiner 512 Byte
gerechnet hat. Wäre mir jetzt langweilig würde ich einfach mal ein
entsprechendes Image auf- und Hatari z.B. mit Falcon-TOS vorsetzen. Der
Milan (und noch mehr MagiCMilan) lassen sich meines Wissens nach nicht
emulieren.
> Ein Sektor pro Cluster.
Das wäre dann das nächste Problem, denn GEMDOS geht fest von zwei
Sektoren pro Cluster aus. Laut
<http://joo.kie.sk/wp-content/uploads/2013/05/Atari_HD_File_Sytem_Reference_Guide.pdf>
gilt das auch rauf bis zum Falcon.
Goetz Hoffart
Sep 6, 2016, 2:14:11 AM9/6/16
to
Gerhard Stoll <gerhar...@gmx.de> wrote:
> Wobei es mir speziell um das GEMDOS vom Milan bzw. MagiCMilan 6.2 geht.
>
> An Daten hätte ich das die Sektorgröße zwischen 128 und 512Bytes liegen
> kann und es nur ein FAT gibt. Letztes scheint wohl das Hauptproblem zu
> sein, denn ich lese immer nur das es beim Atari zwei FATs sein müssen.
Nein, mit Hyperformat konnte man Disketten (FAT12) mit nur einer FAT
> Wobei es mir speziell um das GEMDOS vom Milan bzw. MagiCMilan 6.2 geht.
>
> An Daten hätte ich das die Sektorgröße zwischen 128 und 512Bytes liegen
> kann und es nur ein FAT gibt. Letztes scheint wohl das Hauptproblem zu
> sein, denn ich lese immer nur das es beim Atari zwei FATs sein müssen.
erstellen und ein paar Bytes gewinnen. Zumindest nicht ganz alte
SingleTOSse (mind 1.4?) kamen damit zurecht.
Grüße
Götz
--
http://www.knubbelmac.de/
Christian Zietz
Sep 6, 2016, 1:31:01 PM9/6/16
to
Goetz Hoffart schrieb:
> Nein, mit Hyperformat konnte man Disketten (FAT12) mit nur einer FAT
> erstellen und ein paar Bytes gewinnen. Zumindest nicht ganz alte
> SingleTOSse (mind 1.4?) kamen damit zurecht.
Sicher? Ich habe mir gerade mit dem Diskeditor eine Diskette mit nur
einer FAT angelegt. Selbst TOS 2.06 scheitert daran kläglich, schreibt
trotzdem eine zweite FAT und überschreibt damit das Root-Directory.
Wenn eine Diskette natürlich frisch formatiert ist mit dem Eintrag für
nur eine FAT, aber immer nur an einem Atari mit diesem Bug verwendet
wird, fällt das nicht auf, dass der Atari trotzdem zwei FATs verwaltet
und das Root-Directory halt ein paar Sektoren zu weit hinten anlegt.
Aber wehe, man packt diese Diskette in ein System (MS-DOS?), das dann
tatsächlich nur eine FAT erwartet.
> Nein, mit Hyperformat konnte man Disketten (FAT12) mit nur einer FAT
> erstellen und ein paar Bytes gewinnen. Zumindest nicht ganz alte
> SingleTOSse (mind 1.4?) kamen damit zurecht.
einer FAT angelegt. Selbst TOS 2.06 scheitert daran kläglich, schreibt
trotzdem eine zweite FAT und überschreibt damit das Root-Directory.
Wenn eine Diskette natürlich frisch formatiert ist mit dem Eintrag für
nur eine FAT, aber immer nur an einem Atari mit diesem Bug verwendet
wird, fällt das nicht auf, dass der Atari trotzdem zwei FATs verwaltet
und das Root-Directory halt ein paar Sektoren zu weit hinten anlegt.
Aber wehe, man packt diese Diskette in ein System (MS-DOS?), das dann
tatsächlich nur eine FAT erwartet.
Goetz Hoffart
Sep 6, 2016, 2:14:01 PM9/6/16
to
Christian Zietz <newsgro...@chz.xyz> wrote:
> Sicher? Ich habe mir gerade mit dem Diskeditor eine Diskette mit nur
> einer FAT angelegt. Selbst TOS 2.06 scheitert daran kläglich, schreibt
> trotzdem eine zweite FAT und überschreibt damit das Root-Directory.
Ich müßte jetzt den Scheibenkleister raussuchen, der ist aber gerade
> Sicher? Ich habe mir gerade mit dem Diskeditor eine Diskette mit nur
> einer FAT angelegt. Selbst TOS 2.06 scheitert daran kläglich, schreibt
> trotzdem eine zweite FAT und überschreibt damit das Root-Directory.
nicht innerhalb Reichweite.
Christian Zietz
Sep 6, 2016, 2:36:22 PM9/6/16
to
Goetz Hoffart schrieb:
> Ich müßte jetzt den Scheibenkleister raussuchen, der ist aber gerade
> nicht innerhalb Reichweite.
Du hast Glück, bei mir liegt er aufgeschlagen in 20 cm Entfernung. Der
Screenshot (Bild 8-5) von Hyperformat zeigt zumindest schon mal keine
Möglichkeit, die Anzahl der FATs zu wählen. Man kann dort nur Sektoren
sparen, wenn man die Anzahl der Verzeichniseinträge im Root-Directory
ändert.
Auch der Screenshot auf
<http://www.clausbrod.de/cgi-bin/view.pl/Atari/Hyperformat> zeigt (aus
gutem Grund?) ebenfalls keine Option, um nur eine FAT zu verwenden.
Zum Thema FAT wird im Buch sogar mehrmals darauf eingegangen, niemals
nur eine FAT zu verwenden. Z.B. S. 97: "[...] Man kann die Anzahl auch
auf eins drücken, nur bringt das nichts, weil weder GEMDOS noch BIOS
darauf vorbereitet sind. Trotzdem viel Spaß [...] Absturzschilderungen
bitte an mich." Oder S. 115: "auf die zweite FAT einfach verzichten
[...]. Allerdings ist das Betriebssystem darauf nicht richtig
vorbereitet, der Versuch allein wird durch Datenverlust [...] bestraft."
Oder S. 128: "Experimente mit anderen FAT-Zahlen als 2 scheitern
spätestens hier."
> Ich müßte jetzt den Scheibenkleister raussuchen, der ist aber gerade
> nicht innerhalb Reichweite.
Screenshot (Bild 8-5) von Hyperformat zeigt zumindest schon mal keine
Möglichkeit, die Anzahl der FATs zu wählen. Man kann dort nur Sektoren
sparen, wenn man die Anzahl der Verzeichniseinträge im Root-Directory
ändert.
Auch der Screenshot auf
<http://www.clausbrod.de/cgi-bin/view.pl/Atari/Hyperformat> zeigt (aus
gutem Grund?) ebenfalls keine Option, um nur eine FAT zu verwenden.
Zum Thema FAT wird im Buch sogar mehrmals darauf eingegangen, niemals
nur eine FAT zu verwenden. Z.B. S. 97: "[...] Man kann die Anzahl auch
auf eins drücken, nur bringt das nichts, weil weder GEMDOS noch BIOS
darauf vorbereitet sind. Trotzdem viel Spaß [...] Absturzschilderungen
bitte an mich." Oder S. 115: "auf die zweite FAT einfach verzichten
[...]. Allerdings ist das Betriebssystem darauf nicht richtig
vorbereitet, der Versuch allein wird durch Datenverlust [...] bestraft."
Oder S. 128: "Experimente mit anderen FAT-Zahlen als 2 scheitern
spätestens hier."
Goetz Hoffart
Sep 6, 2016, 4:43:05 PM9/6/16
to
Christian Zietz <newsgro...@chz.xyz> wrote:
> Du hast Glück
... aber wohl eine lückenhafte Erinnerung. Danke für die Korrektur.
Grüße
Götz
--
http://www.3rz.org
> Du hast Glück
... aber wohl eine lückenhafte Erinnerung. Danke für die Korrektur.
Grüße
Götz
--
http://www.3rz.org
Gerhard Stoll
Sep 8, 2016, 12:41:58 PM9/8/16
to
Am 06.09.16 um 19:30 schrieb Christian Zietz:
> Ich habe mir gerade mit dem Diskeditor eine Diskette mit nur
> einer FAT angelegt. Selbst TOS 2.06 scheitert daran kläglich,
Was mich irgendwie verwundert, denn mit TOS 2.06 wurde das Bit für eine
FAT im BPB eingeführt.
Ich muss das die Tage auch mal mit dem Milan testen.
Gerhard
> Ich habe mir gerade mit dem Diskeditor eine Diskette mit nur
> einer FAT angelegt. Selbst TOS 2.06 scheitert daran kläglich,
FAT im BPB eingeführt.
Ich muss das die Tage auch mal mit dem Milan testen.
Gerhard
Christian Zietz
Sep 8, 2016, 1:21:15 PM9/8/16
to
Gerhard Stoll schrieb:
> Was mich irgendwie verwundert, denn mit TOS 2.06 wurde das Bit für eine
> FAT im BPB eingeführt.
Weitere Analysen zeigen, dass TOS 2.06 tatsächlich mit diesem Bit nur
eine FAT schreibt, dummerweise jedoch die zweite(!). Bzw. in die
Sektoren, in denen sonst die zweite FAT gewesen wäre. Das ist wohl gut
gemeint, aber falsch implementiert. Evtl. kannst Du dieses Problem mit
Deinem eigenen Treiber aber umgehen, wenn Du den Beginn der zweiten(!)
FAT (fatrec) im BPB auf Deine erste (und einzige) FAT zeigen lässt.
> Ich muss das die Tage auch mal mit dem Milan testen.
Aus Neugier interessiert mich, was dabei herauskommt.
Christian
--
Wie ich 25 Jahre lang vergessene ASIC-Designs des Atari ST wiederfand:
<http://www.chzsoft.de/asic-web/>
> Was mich irgendwie verwundert, denn mit TOS 2.06 wurde das Bit für eine
> FAT im BPB eingeführt.
eine FAT schreibt, dummerweise jedoch die zweite(!). Bzw. in die
Sektoren, in denen sonst die zweite FAT gewesen wäre. Das ist wohl gut
gemeint, aber falsch implementiert. Evtl. kannst Du dieses Problem mit
Deinem eigenen Treiber aber umgehen, wenn Du den Beginn der zweiten(!)
FAT (fatrec) im BPB auf Deine erste (und einzige) FAT zeigen lässt.
> Ich muss das die Tage auch mal mit dem Milan testen.
Christian
--
Wie ich 25 Jahre lang vergessene ASIC-Designs des Atari ST wiederfand:
<http://www.chzsoft.de/asic-web/>
Gerhard Stoll
Sep 11, 2016, 4:04:33 AM9/11/16
to
Am 08.09.16 um 19:21 schrieb Christian Zietz:
> Weitere Analysen zeigen, dass TOS 2.06 tatsächlich mit diesem Bit nur
> eine FAT schreibt, dummerweise jedoch die zweite(!).
Ist mit dem Milan TOS (4.08, 09.03.2003) und auch unter MagiC auch so.
Im Prinzip sieht man das ja schon am BPB. FreeMiNT bekommt es auch nicht
hin.
Intersanterweise zeigt Diskus bei der Struktur die erwartetet Werte an.
Sprich Start der 2. FAT bei Sektor 1.
Gerhard
> Weitere Analysen zeigen, dass TOS 2.06 tatsächlich mit diesem Bit nur
> eine FAT schreibt, dummerweise jedoch die zweite(!).
Im Prinzip sieht man das ja schon am BPB. FreeMiNT bekommt es auch nicht
hin.
Intersanterweise zeigt Diskus bei der Struktur die erwartetet Werte an.
Sprich Start der 2. FAT bei Sektor 1.
Gerhard
Goetz Hoffart
Sep 11, 2016, 4:13:52 AM9/11/16
to
Gerhard Stoll <gerhar...@gmx.de> wrote:
> Intersanterweise zeigt Diskus bei der Struktur die erwartetet Werte an.
> Sprich Start der 2. FAT bei Sektor 1.
Der liest das ja auch selbst/von Hand aus.
> Intersanterweise zeigt Diskus bei der Struktur die erwartetet Werte an.
> Sprich Start der 2. FAT bei Sektor 1.
Was für ein System hast du denn da, das du an den Milan anknoten willst?
Gerhard Stoll
Sep 13, 2016, 2:27:48 PM9/13/16
to
Am 11.09.16 um 10:13 schrieb Goetz Hoffart:
> Der liest das ja auch selbst/von Hand aus.
Dachte ich auch. Theoretisch könnte FreeMiNT das auch, denn es liesst
den Bootsektor aus und nutzt nicht den den BPB. Habe aber keine Lust das
näher zu untersuchen.
> Was für ein System hast du denn da, das du an den Milan anknoten willst?
Das PC Carddrive HPC301.
Gerhard
> Der liest das ja auch selbst/von Hand aus.
den Bootsektor aus und nutzt nicht den den BPB. Habe aber keine Lust das
näher zu untersuchen.
> Was für ein System hast du denn da, das du an den Milan anknoten willst?
Gerhard
Christian Zietz
Sep 13, 2016, 2:35:38 PM9/13/16
to
Gerhard Stoll schrieb:
> Ist mit dem Milan TOS (4.08, 09.03.2003) und auch unter MagiC auch so.
> Im Prinzip sieht man das ja schon am BPB. FreeMiNT bekommt es auch nicht
> hin.
Da Du ja den Treiber schreibst, um auf die Sektoren zuzugreifen, kannst
Du dann vorgehen, wie in meinem initialen Posting beschrieben:
Lesezugriffe -- egal ob auf die fiktive zweite oder die erste FAT --
immer auf die einzige FAT umbiegen. Schreibzugriffe nur auf die
scheinbare zweite FAT akzeptieren, Schreibzugriffe auf die erste
verwerfen. Wie gesagt, haben RAM-Disks auch so gemacht.
Grüße
> Ist mit dem Milan TOS (4.08, 09.03.2003) und auch unter MagiC auch so.
> Im Prinzip sieht man das ja schon am BPB. FreeMiNT bekommt es auch nicht
> hin.
Du dann vorgehen, wie in meinem initialen Posting beschrieben:
Lesezugriffe -- egal ob auf die fiktive zweite oder die erste FAT --
immer auf die einzige FAT umbiegen. Schreibzugriffe nur auf die
scheinbare zweite FAT akzeptieren, Schreibzugriffe auf die erste
verwerfen. Wie gesagt, haben RAM-Disks auch so gemacht.
Grüße
thott...@gmail.com
Oct 3, 2016, 10:24:55 AM10/3/16
to
entsprechende Bit im BPB gesetzt ist wird nur eine FAT geschrieben.
Problem hierbei ist die Getpbp() Funktion für Floppies im TOS, die geht
nämlich bei der Berechnung von fatrec und datrec immer noch von 2 FATs
aus. Ähnliches gilt für die Sektorgrösse, bei den meisten Berechnungen
wird dort die Angabe aus dem Bootsektor verwendet, bei der Überprüfung
auf Media-Change wird allerdings eine Prüfsumme über die ersten 6
Sektoren gebildet und dort wird von einer Sektorgrösse von 512 ausgegangen.
Es steht übrigens meines Wissens nirgendwo geschrieben daß fatrec der
Start der 2. Fat ist, es steht dort immer nur "Start der letzten FAT".
Bei nur einer FAT wäre das dann demzufolge der Start dieser, i.d.R.
also 1.
Grüsse,
Thorsten
PS.: eine komplette Version des GEMDOS ist hier verfügbar:
http://tho-otto.de/download/tos306de.tar.bz2
Mit dem Alcyon-Compiler aus dem Developer-Kit kompiliert, ergibt das
eine exakte Kopie des GEMDOS von TOS 3.06.
Christian Zietz
Oct 3, 2016, 11:25:45 AM10/3/16
to
thott...@gmail.com schrieb:
> GEMDOS aus TOS >= 2.06 müsste damit zurecht kommen, sofern das
> entsprechende Bit im BPB gesetzt ist wird nur eine FAT geschrieben.
> Problem hierbei ist die Getpbp() Funktion für Floppies im TOS, die geht
> nämlich bei der Berechnung von fatrec und datrec immer noch von 2 FATs
> aus.
Dann muss man also bei einem selbstgeschriebenen Treiber für einen
Massenspeicher, bei dem man Getbpb ja ohnehin ebenfalls selbst
implementieren muss, ja nur dieses Bit setzen und 'fatrec' auf die
(einzige) FAT zeigen lassen, wie ich in meinem Posting vom 8. September
schon vermutet hatte.
Das müsste Gerhard mal ausprobieren. Vielleicht zuerst mit einem
Datenträger, dessen Daten ihm nicht so wichtig sind, denn wer weiß, ob
auch in GEMDOS noch Bugs im Zusammenhang mit nur einer FAT schlummern.
Besonders gründlich getestet wurde TOS im Zusammenspiel mit Laufwerken
mit nur einer FAT ja offenbar nicht...
> GEMDOS aus TOS >= 2.06 müsste damit zurecht kommen, sofern das
> entsprechende Bit im BPB gesetzt ist wird nur eine FAT geschrieben.
> Problem hierbei ist die Getpbp() Funktion für Floppies im TOS, die geht
> nämlich bei der Berechnung von fatrec und datrec immer noch von 2 FATs
> aus.
Massenspeicher, bei dem man Getbpb ja ohnehin ebenfalls selbst
implementieren muss, ja nur dieses Bit setzen und 'fatrec' auf die
(einzige) FAT zeigen lassen, wie ich in meinem Posting vom 8. September
schon vermutet hatte.
Das müsste Gerhard mal ausprobieren. Vielleicht zuerst mit einem
Datenträger, dessen Daten ihm nicht so wichtig sind, denn wer weiß, ob
auch in GEMDOS noch Bugs im Zusammenhang mit nur einer FAT schlummern.
Besonders gründlich getestet wurde TOS im Zusammenspiel mit Laufwerken
mit nur einer FAT ja offenbar nicht...
Gerhard Stoll
Oct 16, 2017, 1:10:33 PM10/16/17
to
Am 13.09.16 um 20:27 schrieb Gerhard Stoll:
> Das PC Carddrive HPC301.
Ist zwar schon ein paar Tage her aber trotzdem zur Rückmeldung.
Ich hatte mich entschlossen keinen Gerätetreiber zuschreiben. Einmal
habe ich trotz dem Beispiel aus Scheibenkleister II da nix zustande
gebracht, zum anderem sind die Daten einer MemoryCard doch ziemlich
unterschiedlich das ich denke das das TOS damit nicht zurecht kommt.
Die Karten haben grundsätzlich eine FAT und einen Cluster pro Sektor.
Ein Sektor kann 128, 256 oder 512 Bytes besitzen.
Da ich eine Lib gefunden habe welche damit zurecht kommt habe ich diese
genommen. Für den Milan gibt das Ergebins als Programm hier:
<http://www.atari-forum.com/viewtopic.php?f=96&t=32412&sid=27daade0cb88e68a74c642ae49838219>
Schreiben geht auch, allerdings nur eine Datei auf einmal und nur ins
Wurzelverzeichnis.
Zur Technik des PC Carddrive HPC301:
Da ich keine Doku finden konnte habe ich den MS-DOS Treiber disassembliert.
Dabei hat sich heraus gestellt, das die Karte vier Adressen im ISA Bus
belegt.
Adr1 ist zum lesen und schreiben von Bytes
Adr2 und Adr3 zum setzen der Adresse auf der Speicherkarte.
Adr4 ist eine Status- und Steuerregister
Interessant bei der Sache ist das man an Adr2 und Adr3 nur einmal die
Adresse angeben muss. Greift man mit Adr1 auf ein Byte zu wird auf der
Karte weitergezählt und man bekommt mit dem nächsten Zugriff das nächste
Byte.
Das Lesen eine Sektors sieht dann in meinem Programm so aus:
--------------- cut ------------------
SetzeSektor ( sector ); /* Setzen der Adresse */
for ( i = 0; i < BPB.recsiz; i++)
{
*Buf = inb ( Adr1 );
Buf++;
}
--------------- cut ------------------
Angeregt durch einen Nutzer habe ich mal probiert ob es auch mit der
EtherNEC funkrioniert, was der Fall ist. Zumindest an meinem MegaST kann
ich das Inhaltsverzeichnis auslesen und den Status des
Schreibschutzschalter ermitteln. Letztes bedeutet das auch das Schreiben
geht.
Das obige Programm läuft nur auf dem Milan.
Gerhard
> Das PC Carddrive HPC301.
Ist zwar schon ein paar Tage her aber trotzdem zur Rückmeldung.
Ich hatte mich entschlossen keinen Gerätetreiber zuschreiben. Einmal
habe ich trotz dem Beispiel aus Scheibenkleister II da nix zustande
gebracht, zum anderem sind die Daten einer MemoryCard doch ziemlich
unterschiedlich das ich denke das das TOS damit nicht zurecht kommt.
Die Karten haben grundsätzlich eine FAT und einen Cluster pro Sektor.
Ein Sektor kann 128, 256 oder 512 Bytes besitzen.
Da ich eine Lib gefunden habe welche damit zurecht kommt habe ich diese
genommen. Für den Milan gibt das Ergebins als Programm hier:
<http://www.atari-forum.com/viewtopic.php?f=96&t=32412&sid=27daade0cb88e68a74c642ae49838219>
Schreiben geht auch, allerdings nur eine Datei auf einmal und nur ins
Wurzelverzeichnis.
Zur Technik des PC Carddrive HPC301:
Da ich keine Doku finden konnte habe ich den MS-DOS Treiber disassembliert.
Dabei hat sich heraus gestellt, das die Karte vier Adressen im ISA Bus
belegt.
Adr1 ist zum lesen und schreiben von Bytes
Adr2 und Adr3 zum setzen der Adresse auf der Speicherkarte.
Adr4 ist eine Status- und Steuerregister
Interessant bei der Sache ist das man an Adr2 und Adr3 nur einmal die
Adresse angeben muss. Greift man mit Adr1 auf ein Byte zu wird auf der
Karte weitergezählt und man bekommt mit dem nächsten Zugriff das nächste
Byte.
Das Lesen eine Sektors sieht dann in meinem Programm so aus:
--------------- cut ------------------
SetzeSektor ( sector ); /* Setzen der Adresse */
for ( i = 0; i < BPB.recsiz; i++)
{
*Buf = inb ( Adr1 );
Buf++;
}
--------------- cut ------------------
Angeregt durch einen Nutzer habe ich mal probiert ob es auch mit der
EtherNEC funkrioniert, was der Fall ist. Zumindest an meinem MegaST kann
ich das Inhaltsverzeichnis auslesen und den Status des
Schreibschutzschalter ermitteln. Letztes bedeutet das auch das Schreiben
geht.
Das obige Programm läuft nur auf dem Milan.
Gerhard
0 new messages