-
Ich habe mir von neogain (aller(http://www.deutschlandangeln.de/images/smilies/herz.gif)lichstes (http://www.smiley-paradies.de/smileys/schild/schild_0015.gif) noch mal an ihn) meinen Haupt-Mega ST4 mit IDE und F-TOS erweitern lassen und möchte - da weitere einbauten zZ nicht möglich sind, passend für mienen Umgang erst einmal einrichten - dazu forab:
F-TOS ist folgendermaßen eingerichtet:
1. TOS 2.(0)6 - mit dem ich wohl auch am meisten arbeiten werde
2. TOS 1.(0)4 (Rainbow)
3. MagiC als ROM - läuft noch nicht richtig (bei ihm wohl auch nicht)
4. EmuTOS - wird von mir noch recht Stiefmütterlich behandelt, vielleicht erfreue ich mich, wenn ich es später besser kennengelernt habe
Mir schwebt jetzt folgendes vor:
neogain hat mir dazu mitgeteilt, daß jedes System sein eigenes Bootdrive benötigt - bislang hatte ich (Einrichtung Mega STE) folgende Konstellation:
C: Booten (30MB)
D: TeXten (alles Rund um Textverarbeitung - 180MB)
E: Grafik (alles rund um Grafig Bearbeitung - 150MB)
F: Programming (programmieren, entwickeln und compilieren - 150MB)
G: Other Progs (alle anderen Arbeitsanliegen - 150MB)
H: Unterhaltung (Speile, Demos, Musik etc. - 250MB)
I: alles Übrige - zB nichtflüchtiger Mülleimer, Sicherheitskopien etc. (restlicher Speicherplatz der 1GB)!
J: Syquest A
K: Syquest B
L: Syquest C
M: Syquest D
O: CD-ROM
Ich würde das gerne mit erhöhten Partitionsgrößen so beibehalten - also das beim späteren Arbeiten unter einem der Atari-TOSse nur 7 Partitionen Zugriff passieren kann und ab "J:" dann das evtl am ACSI-Port hängende Geräte angesprochen werden - das bedarf einiger Antworten:
Vorerst hat neogain nur auf der ersten Partition Daten abgelegt, nach dem ersten Testlauf arbeitete er unter TOS 2.(0)6 auch erwartungemäß! Ich denke, nach seinen Infos ist es unumgänglich, die CF-Karte neu einzurichten, dh. den Treiber neu konfigurieren - mir schwebt folgendes vor:
C: 40MB (Booten) - Bootdrive TOS 2.(0)6 - später im Treiber für die anderen TOSse versteckt
D: 300MB (TeXten)
E: 250MB (Grafik)
F: 250MB (Programmieren - Entwickeln)
G: 300MB (other Application)
H: 500MB (Unterhaltung - Games und Musikanwendungen)
I: rest (etwa 2,2GB)
part. 8 40MB (Booten) (Aufruf durch <J> in der Bootphase, wird zu "C:" für das TOS 1.(0)4)
part. 9 100MB (Booten) (Aufruf durch <K> in der Bootphase, wird zu "C:" für MagiC)
part 10 40MB (Booten) (Aufruf durch <L> in der Bootphase, wird zu "C:" für EmuTOS)
part 8 - 10 sollen später vor den jeweils anderen Systemen "versteckt" sein (nachdem ich sie mit entsprechenden (Boot-)Daten befüllte!
Läßt sich das überhaupt mit einem Treiber bewerkstelligen? (Wenn nicht, bleibe ich bei SCSI-Tools mit BigDOS im AUTO-Ordner)
Falls ja - welcher Treiber?
Falls nein - gibt es eine Möglichkeit, dem Atari (kompatiblen) TOS weitere "Laufwerke" als die 16 bekannten zu vermitteln? Mich stört irgendwie der Gedanke "nur" 4 Laufwerke (evtl. bei CD-ROM Betrieb gar nur 3) zusätzlich reservieren zu können! In dem Falle reicht es mir, die Laufwerke nicht im DESKTOP.INF bzw. NEWDESK.INF zu übernehmen und nur bei Bedarf "einzublenden"!
Alles weitere ist jetzt Einrichtungssache - dazu ggfs. in späteren Postings!
-
Da hast du mich falsch verstanden, Burkhard. Nicht jedes TOS braucht seine eigene Bootpartition, es richtet sich nach dem, was du machen willst. So habe ich auf C das komplette Environment für TOS 2.06, inkl. NVDI und allen ACC's, wo ich brauche. Bei TOS 1.04 boote ich von D, nachdem schon die Treiber geladen worden sind ;) du brauchst nur D zu drücken nach der Frage vom Treiber, was C sein soll. auf D habe ich dann BigDOS und TW7IDE.PRG, damit ich auch auf TOS 1.04 drauf zugreifen kann. Ansonsten ist das frei von NVDI und ACC's und kann das dann für Games usw. nutzen. Alles recht easy. Wenn der Treiber ja von C geladen ist, brauchst du auf keiner anderen Partition das nochmal zu machen. Außer bei Magic, wie du das schon mitgeteilt hast, muß ich mich noch drum kümmern. Ppera hat hier ja schon das Rom gemacht mit IDE support, trotzdem meckert er mit "Speicher durch Benutzerprogramm zerstört". Da bin ich bisher noch nicht weiter gekommen. Das ROM wo aber in den AMDs drin sitzt, ist 1 zu 1 von dem bereitgestellten PPera rom. Es geht hier wahrscheinlich nur um die Dateien, die für das Magic Desktop zuständig sind. Das werde ich auch noch hinbekommen. EMUTos... ja, etwas befremdlich, aber wenn man die treiber (bigdos und tw7) nachlädt, doch ganz performat. Ist auch nur wirklich eine spielerei mit dem Emutos, aber es funktioniert halt. Du hast auch auf der Games Partition noch ein paar Spiele von mir draufbekommen. Die kannste ganz normal unter Tos 1.04 starten und zocken. Sind Harddisk Adaptionen von Ppera. Hier möchte ich auch nochmal erwähnen, dass Ppera ein geniales Genie ist, wie er mit den Routinen handhabt, für diese Spiele von Festplatte am laufen zu kriegen.
-
Hast Du es auch mal probiert, ein Bootdrive für MagiC zu istallieren und den kompletten Ordner draufzukopieren - abgesehen von der Datei, die ins ROM gehört? Das wäre nämlich meine Idee - und MagiC nimmt sich halt was es braucht daraus! Wie heißt das Desktop Info, das EmuTOS ablegt? Auch "DESKTOP.INF"?
-
bootdrive nein, habe ich nicht gemacht. Das könntest du mal probieren. Bei Emutos bin ich mir nicht sicher, sollte aber auch Desktop.inf sein. Probier es einfach mal aus :)
-
So - ich habe heute gestern Abend per Emu einen Test gemacht und festgestellt, daß TOS 1.(0)4 mit einem vom EmuTOS erstellten "DESKTOP.INF" doch ein etwas merkwürdiges Aussehen hat (und umgedreht) was mich zu dem Schluß kommen läßt, jedem Betriebssystem könnte sein eigenes Bootdrive wichtig sein, da ich auch gerne mit unterschiedlichen Desktops arbeite! Das ich diese nicht vor den anderen Betriebssystemen "verstecken" kann ist mir nach reiflicher Überlegung und Check der verfügbaren Treiberprogs auch bewußt geworden - falls es doch anders ist, bitte ich noch um einen Hinweis. Ich benötige auch noch Hinweise, ob ich BigDOS auch als "*.APP oder *.TOS im AUTO-ORDNER automatisch starten kann und ob es ein Programm gibt das die Laufwerkverwaltung erweitert - oder ob Letzteres gar durch BigDOS geregelt wird!
Besten Dank schnmal!
-
Ich habe mich vor wenigen Tagen noch einmal um mein neues Schätzchen gekümmert! Da ich aber (noch) keinen Platz habe, wo ich das Gerät aufbauen möchte, können diese Sitzungen (vorerst) nur "sporadisch" erfolgen! Dabei mußte ich aber jetzt erst einmal erschreckend- und enttäuschender Maßen feststellen, daß ein am ACSI-Port hängendes Wechselplattenlattenlaufwerk nicht erkannt - dh. nicht ins System integriert wird, obwohl noch 4 Laufwerke verfügbar sein müßten! Darum konnte ich ihn auch nicht mit meiner Arbeitsumgebung bestücken. Da als Hauptdriver HUSHI.SYS installiert worden sein soll, habe ich mir meine SCSI-Tools Diskette hinzugezogen, um den Treiber evtl. neu zu konfigurieren. Aber die findet den ZTreiber nicht, dh. der Schalter "Treiber konfigurieren" bleibt ausgegraut. Alerdings hat er mir beim vorherigen ID Check auch die am ASCI hängende Wechselplatte erkannt - aber ein Zugriff darauf erbrachte nur eine Fehlermeldung - kann mich aber jetzt nicht mehr erinnern, welcher Art!
Meine Fragen:
Welcher (Haupt-)Driver ist wirklich installiert? (Versuche mit HDDriver hebe ich erst einmal zurückgestellt)
Wie bekomme ich ein ACSI-Laufwerk ins System eingebunden, um erst einmal die Vorinstallierten Daten zu sichern und dann die als Festplatte eingesetzte 4GB CF Karte neu zu konfigurieren? Meinen bisherigen Erfahrungen mit SCSI-Tools und reinen ACSI-Systemen zufolge war eine nachträgliche Konfiguration von HuSHi nie erforderlich, es wurden immer zusätzliche Festplatten anstandslos ins System eingebunden!
Zur Info: BigDOS zur Verwaltung großer Partitionen ist installiert! Und die angehängte Wechselplatte ist OK!
-
Da hier zuletzt keine Antwort zu erhalten war, habe ich mich eben nochmal mit dem Sorgenkind befaßt und es mit der HDDriver-Diskette probiert - ich erhalte einfach keinen Zugriff auf ein am ACSI-Anschluß hängenden Laufwerk, um davon meinen Mega ST einzurichten! Ich kann weder von SCSI-Tools noch vom HDDriver einen "Hauptreiber" istallieren (Schalter ausgegraut)! Jetzt habe ich einen Super ST und kann ihn nicht für meine Atari-Anwendung einrichten >:( - oder nur in einer langwierigen Sitzung über Disketten!
Also nochmal meine Fragen:
# neogain (Falls überhaupt ein solcher Treiber - würde mich wundern, wenn nicht - wie HuSHi, HDDriver oder Co. notwendig ist): Welcher ist eigentlich installiert? Und falls nicht - mit welchem Programm wurde die CF-Karte eingerichtet (um hier anzusetzen für eine entsprechende neu-Konfiguration des notwendigen Drivers)?
-
Du sagst nicht, was genau Du gemacht hast, was genau dabei nicht funktioniert hat und die Fehlermeldung hast Du auch vergessen.
Wie soll man dir da - ohne Kristallkugel - helfen?
-
Deine CF Karte habe ich unter Xubuntu mit geparted partitioniert. Jeweils in Fat16. Da sind 3 Primäre Partitionen drauf und eine erweiterte mit den restlichen logischen Laufwerken. Wie das mit hushi, hddriver und konsorten aussieht, weiß ich nicht, habe ich noch nicht probiert - brauchte ich bisher auch nicht. 16GB an Plattenplatz sind mir mehr als ausreichend, da brauche ich keine megafile usw ;)
-
Vermute mal das es da mit den normalen Atari Plattentreibern schlecht ausschaut ...
-
Xubuntu wird sicherlich den für Motorola68k IDE-Interfaces nötigen Byteswap nicht durchgeführt haben.
-
Xubuntu wird sicherlich den für Motorola68k IDE-Interfaces nötigen Byteswap nicht durchgeführt haben.
wie meinst du das? Nur mit Byteswap kann man IDE und ACSI gleichzeitig ansprechen?
-
Die Atari Treiber können doch normalerweise mit MSDOS FAT16 Partitionen nichts anfangen.
Die Atari TOS Partitionierung ist doch ein wenig anders ...
SCSITOOLS kann doch nur MSDOS FAT16 bis maximal 32MB und HDDriver ist doch mit TOS/WINDOWS kompatibel auch etwas spezielles ...
-
ah, verstehe. ich werde mal auf dem 1040er Burkhards Special Editon ST mal die SD Karte neu partitionieren und dann mal zwei 30MB Partitionen anlegen. mal schauen, ob ich meine SH205 mit dem IDE interface gemeinsam nutzen kann.
-
Das mit dem Byteswap habe ich bei den IDE Bauanleitungen von Pera Putnik - nach einer von denen hatte neogain das IDE nachgebaut - immer so verstanden, daß duch das Verdrehen der Datenleitungen (wie es auch bei mir durchgeführt worden war) Byteswap unberücksichtigt werden kann, weil er dadurch DOS-kompabel UND ST kompatibel sei (hier ein Beispielbild):
(http://www.spiny.org/atari/popsel/ATARI_ST_IDE_INTERFACE_V2_00/double_sided_version_1_4/ATARI%20ST%20IDE%20IF%20V2.00%20DOCUMENTATION%20DOUBLE%20SIDED%20VERSION00014im.jpg)
Eingesetzt ist eine 4GB CF ScanDisk über einen solchen Adapter:
(http://ecx.images-amazon.com/images/I/41GIKped8EL._SX425_.jpg)
Hier noch mal die Partitionsaufteilung, wie ich sie gerne hätte (aus dem Eingangspost):
C: 40MB (Booten) - Bootdrive TOS 2.(0)6
D: 300MB (TeXten)
E: 250MB (Grafik)
F: 250MB (Programmieren - Entwickeln)
G: 300MB (other Application)
H: 500MB (Unterhaltung - Games und Musikanwendungen)
I: rest
Aus weiterem Austausch mit neogain hat sich herausgestellt, daß es sinnvoll scheint, jedem TOS, das verfügbar ist, eine eigene Bootpartition zu geben - also habe ich im weiteren folgende Vorstellungen:
part. 8 40MB (Booten) (Aufruf durch <J> in der Bootphase, wird zu "C:" für das TOS 1.(0)4)
part. 9 100MB (Booten) (Aufruf durch <K> in der Bootphase, wird zu "C:" für MagiC)
part 10 40MB (Booten) (Aufruf durch <L> in der Bootphase, wird zu "C:" für EmuTOS)
Partition I: müßte am Ende also etwas mehr als 2GB haben!
Jetzt habe ich aber feststellen müssen, daß zwar einzelne Partitionen entsprechende Größenordnungen haben - aber eben nicht in dieser Reihenfolge - aber das ist jetzt auch nicht mein Hauptproblem - der Zugriff auf den DMA (ACSI) Port geht nicht!
Aber jetzt wird mir auch der Grund klar!
Deine CF Karte habe ich unter Xubuntu mit geparted partitioniert. Jeweils in Fat16. Da sind 3 Primäre Partitionen drauf und eine erweiterte mit den restlichen logischen Laufwerken. Wie das mit hushi, hddriver und konsorten aussieht, weiß ich nicht, habe ich noch nicht probiert - brauchte ich bisher auch nicht. 16GB an Plattenplatz sind mir mehr als ausreichend, da brauche ich keine megafile usw ;)
Also war ich wieder einem Mißverständnis aufgesessen - bisher hatte ich Dich nämlich immer so verstanden, daß ein Treiber wie HuSHi oder HDDriver installiert war ...
Du sagst nicht, was genau Du gemacht hast, was genau dabei nicht funktioniert hat und die Fehlermeldung hast Du auch vergessen.
Wie soll man dir da - ohne Kristallkugel - helfen?
Eigentlich sollte das aus Antwort #5 hervorgehen! Aber gut, dann etwas ausführlicher:
- Mega ST aufgebaut und Monitor angeschlossen
- ACSI über ein LINK97 mit einem 88er SyQuest Wechselplattenlaufwerk mit eingelegtem und vorher formatiertem 44er Medium im SCSI-Gehäuse verbunden
- Letzteres und Monitor eingeschaltet und als das Laufwerk Betriebsbereit war, den ST
- Beim Hochfahren erkannt: die Partitionen der Wechselplatte werden nicht aufgeführt und anschließend auch nicht gefunden
- SCSI-Tools von Disk gestartet
- Beim ID-Check wird Laufwerk gefunden, kann aber keinen Treiber (HuSHi) installieren ...
Jetzt ist mir klar, daß ich wohl mit folgender Vorgehensweise alles neu machen muß:
- mitgegebene Programme und Daten auf Disks auslagern
- SCSI-Tools starten und CF Karte am Atari neu organisieren und HuSHi (Treiber) installieren
Aber: Läßt sich dann noch ein Laufwerk von etwa 2GB erzeugen? Aus der "Liesmich"-Datei dazu geht hervor: Sektorgröße maximal 8kB, Partition max. 512MB!
Oder muß ich das Ganze doch mit anderem Treiberpaket realisieren?
edit: Der HuSHi (oä.) ist aber nur noch Pro Forma! Um mit den Größen zurechtzukommen, soll BigDOS in den Auto-Ordner! Dazu nochmals die Frage: BigDOS liegt als PRG vor. Würde es auch noch starten, wenn ich es statt BIGDOS.PRG als BIGDOS.APP im AUTO-Ordner hätte? Ein versehentliches "Ausschalten" per Bootselektor könnte dadurch vermieden werden!
-
Das mit dem Byteswap habe ich bei den IDE Bauanleitungen von Pera Putnik - nach einer von denen hatte neogain das IDE nachgebaut - immer so verstanden, daß duch das Verdrehen der Datenleitungen (wie es auch bei mir durchgeführt worden war) Byteswap unberücksichtigt werden kann, weil er dadurch DOS-kompabel UND ST kompatibel sei
Jetzt hast Du zwar immer noch nicht gesagt, welcher Harddisk-Treiber benutzt wird (das wäre schon wichtig), aber es ist auch so klar.
Mit den vertauschten Leitungen wirst Du mit keinem anderen HD-Treiber als mit dem von ppera Glück haben, bist also auf diesen festgenagelt.
Durch das Vertauschen der Datenleitungen spart man sich zwar den (sonst notwendigen) Byteswap beim Lesen und Schreiben DOS-kompatibler Medien, gleichzeitig ist aber Schluß mit der Treiber-Kompatibilität: die Kommandobytes an die Platte sind ja damit ebenso verdreht. Von der Rechnerseite sieht das so aus, als ob die Adresslage aller IDE-Register jeweils paarweise vertauscht wäre: dort wo z.B. normalerweise das Command/Status Register zu finden wäre, ist plötzlich das "Head"-Register und umgekehrt.
Der nach meiner Kenntnis einzige Treiber, der damit zurechtkommt, ist der von ppera.
Du hast also drei Möglichkeiten: den ppera-Treiber auch für ACSI verwenden (dann mußt Du wahrscheinlich aber auch damit partitionieren), die gekreuzten Leitungen rückgängig machen (dann kannst Du jeden beliebigen Treiber verwenden, mußt aber deutliche Geschwindigkeitseinbußen bei DOS-kompatiblen Medien hinnehmen) oder irgendwie eine Koexistenz zwischen dem ppera-Treiber (für IDE) und einem anderen (für ACSI) hinkriegen.
Letzteres könnte funktionieren, muß aber nicht (möglicherweise einer der seltenen Fälle, wo es sinnvoll ist, einen Treiber in den AUTO-Ordner zu legen). Jedenfalls müsstest Du den ACSI-Treiber erstmal dazu bringen, das IDE-Interface nicht anzuschauen (weil er dort nur Kauderwelsch sieht). Ob und wie das jeweils geht, weiß ich nicht.
Dein eigener Ansatz funktioniert jedenfalls nicht.
-
Jetzt hast Du zwar immer noch nicht gesagt, welcher Harddisk-Treiber benutzt wird (das wäre schon wichtig), aber es ist auch so klar.
Also hier ist die Seite mit dem Treiber, wo für das Interface benutzt wird: http://atari.8bitchip.info/astams.php
Man kann auch ein normals IDE Kabel anschließen ohne die gedrehten Datenleitungen. Dann muß aber auch der Treiber für das normale IDE verwendet werden. Im Anhang sind beide Treiber plus Installationsprogramm enthalten. Dieser ist auch auf der verlinkten Seite zu finden. Zusätzlich noch ACSI Treiber. Wenn ich das so richtig verstehe, ist es mit dem ACSI Treiber auch möglich Partitionen größer als 32MB zu nutzen (z. B. Ultrasan) mit dem BigDOS Treiber. Ich werde das mal ausprobieren.
Burkhard, tausche das gedrehte IDE Kabel gegen ein Normales aus. Partitioniere deine CF Karte dann wie du es kennst mal mit SCSI Tools. Der Datendurchsatz wird aber dann nur noch die Hälfte der Geschwindigkeit gegebenüber Twisted IDE betragen. Gestern hatte ich es mal probiert und AHDI Treiber hat auch das IDE Interface erkannt, konnte aber anhand der Dos Partitionen nichts damit anfangen und wolte die SD Karte formatieren.
Für mich selbst wäre das sowieso unnötig ACSI Laufwerke zusätzlich mit dem IDE Interface zu betreiben.
-
Man kann auch ein normals IDE Kabel anschließen ohne die gedrehten Datenleitungen. Dann muß aber auch der Treiber für das normale IDE verwendet werden. Im Anhang sind beide Treiber plus Installationsprogramm enthalten. Dieser ist auch auf der verlinkten Seite zu finden. Zusätzlich noch ACSI Treiber. Wenn ich das so richtig verstehe, ist es mit dem ACSI Treiber auch möglich Partitionen größer als 32MB zu nutzen (z. B. Ultrasan) mit dem BigDOS Treiber. Ich werde das mal ausprobieren.
Burkhard, tausche das gedrehte IDE Kabel gegen ein Normales aus. Partitioniere deine CF Karte dann wie du es kennst mal mit SCSI Tools. Der Datendurchsatz wird aber dann nur noch die Hälfte der Geschwindigkeit gegebenüber Twisted IDE betragen.
Die Einschränkung im Datendurchsatz existiert nur mit DOS-kompatiblen Medien (nur die benötigen Byte-Swap). Wenn man das nicht unbedingt braucht (und entsprechend Atari-kompatibles Format nutzt) sollte die Geschwindigkeit weitgehend identisch sein.
Wenn Du das Kabel tauschst, brauchst Du doch auch ein anderes (ungepatchtes) TOS, damit Booten von HD weiterhin funktioniert?
-
Wenn Du das Kabel tauschst, brauchst Du doch auch ein anderes (ungepatchtes) TOS, damit Booten von HD weiterhin funktioniert?
Nee, nur den eigentlichen Treiber muss man dann austauschen. Das gepatchte Tos selbst ist nur für die Erkennung des IDE Adapter zuständig für Autoboot. AHDI hat gestern wo ich es probiert habe auch die IDE Platte gefunden auf mit twisted IDE, bloß konnte halt nichts damit anfangen.
-
Habe mittlerweile gesehen, daß das gepatchte TOS mit "geradem" und "gedrehtem" Kabel umgehen kann.
-
So - ich habe heute gestern Abend per Emu einen Test gemacht und festgestellt, daß TOS 1.(0)4 mit einem vom EmuTOS erstellten "DESKTOP.INF" doch ein etwas merkwürdiges Aussehen hat (und umgedreht) was mich zu dem Schluß kommen läßt, jedem Betriebssystem könnte sein eigenes Bootdrive wichtig sein, da ich auch gerne mit unterschiedlichen Desktops arbeite! Das ich diese nicht vor den anderen Betriebssystemen "verstecken" kann ist mir nach reiflicher Überlegung und Check der verfügbaren Treiberprogs auch bewußt geworden - falls es doch anders ist, bitte ich noch um einen Hinweis.
Hallo Burkhard,
auch wenn meine Antwort schon ein wenig her ist. Warum verwendest Du keinen Bootmanager, wie XBOOT? Damit kann man auch DESKTOP.INFs für verschiedene Boot-KOmbis voneinander separieren. Klappt prima (hatte ich damals bei meinem MegaSTE mit Native TOS, MagiX/Gemini auch so gemacht).
Gruß
Johannes
-
Auch wenn XBOOT ein feines Programm ist: _Das_ Problem ist keins.
Wie bereits anderswo geschrieben: EmuTOS ist DESKTOP.INF (und was drin steht) genauso wurscht wie TOS das entsprechende EMUDESK.INF
-
Jetzt hast Du zwar immer noch nicht gesagt, welcher Harddisk-Treiber benutzt wird (das wäre schon wichtig), aber es ist auch so klar.
Ich habe an mehreren Stellen erwähnt, daß ich am liebsten mit SCSI-Tools/HuSHi arbeite - an das Paket habe ich mich gewöhnt, seit ich eine erste HDD dauerhafter am Atari nutzen konnte und der ist zudem mW von den Autoren freigegeben! Auch habe ich immer, wenn es um verschiedene Treiber geht, dieses Paket mit Namen bezeichnet und die Anderen eher beiläufig erwähnt - das sollte doch genug erklären - und für Deinen weiteren Text: Laut Beschreibung kommt es sehr wohl mit TOS- und DOS-kompatiblen HDD Konstellatienen und Byteswap zurecht!
Also hier ist die Seite mit dem Treiber, wo für das Interface benutzt wird: http://atari.8bitchip.info/astams.php
Man kann auch ein normals IDE Kabel anschließen ohne die gedrehten Datenleitungen. Dann muß aber auch der Treiber für das normale IDE verwendet werden. Im Anhang sind beide Treiber plus Installationsprogramm enthalten. Dieser ist auch auf der verlinkten Seite zu finden. Zusätzlich noch ACSI Treiber. Wenn ich das so richtig verstehe, ist es mit dem ACSI Treiber auch möglich Partitionen größer als 32MB zu nutzen (z. B. Ultrasan) mit dem BigDOS Treiber. Ich werde das mal ausprobieren.
Burkhard, tausche das gedrehte IDE Kabel gegen ein Normales aus. Partitioniere deine CF Karte dann wie du es kennst mal mit SCSI Tools. Der Datendurchsatz wird aber dann nur noch die Hälfte der Geschwindigkeit gegebenüber Twisted IDE betragen. Gestern hatte ich es mal probiert und AHDI Treiber hat auch das IDE Interface erkannt, konnte aber anhand der Dos Partitionen nichts damit anfangen und wolte die SD Karte formatieren.
Für mich selbst wäre das sowieso unnötig ACSI Laufwerke zusätzlich mit dem IDE Interface zu betreiben.
JETZT haben wirs - das ist genau die Info, die ich von Anfang an, wo ich meine Probleme äußerte, brauche! Pera beschreibt dort (wenn ich das beim kurzen Überflug richtig erfaßte) in englisch, daß sein Treiber mit IDE und ACSI zurechtkommt - also muiß ich mich mal mit den Seiten dort befassen! Den Zugriff auf ACSI benötige ich dann ja auch nur am Anfang, um meine Daten zu übertragen!
Ich denke, dann komme ich ach weiter! Den Einsatz eines normalen IDE-Kabels werde ich mir nur unter Vorbehalt als LETZTE Möglichkeit einplanen ;)
Ich denke, die nächsten Fragen werden bezüglich GOTEK kommen ...! Aber nicht jetzt! Wenn ich den Mega ST soweit nutzbar habe, kommt vor dem GOTEK Einbau erstmal MagiC an die Reihe! Ich denke, ich kann Dir dann auch schnell Tipps für die Anwendung geben!
Hallo Burkhard,
auch wenn meine Antwort schon ein wenig her ist. Warum verwendest Du keinen Bootmanager, wie XBOOT? Damit kann man auch DESKTOP.INFs für verschiedene Boot-KOmbis voneinander separieren. Klappt prima (hatte ich damals bei meinem MegaSTE mit Native TOS, MagiX/Gemini auch so gemacht).
Gruß
Johannes
Hallo Johannes!
Da wirst Du irgendwo was mißverstanden haben! Ich vetrwende einen Bootselektor, der mehrere Desktops verwalten kann (STARTUP.PRG von einer PD aus der ST-Computer Schiene von MAXON) - diese werden in Dateien mit dem Namen *.STD auf dem Bootlaufwerk abgelegt und die für die jeweilige Arbeitsumgebung zu verwendeten ACC's und PRG's des AUTO-Ordners kann man unter gleichem Namen abspeichern - dazu wird dann *.STP verwendet. Bis zu 10 lassen sich dann per Funktionstaste direkt aufrufen und die betreffende *.STD-Datei wird dann nach DESKTOP.INF kopiert!
Es hat sich aber auch herausgestellt, daß ich bei meinen Tests mit dem EmuTOS was falsch gemacht habe ...!
Nein - jedem TOS sein eigenes Bootdrive zu geben, ist schon sinnvoll, da ich sonst drei unterschiedliche Bootselektoren auf einem Bootlaufwerk nutzen müßte nämlich einen, der die Desktops nach DESKTOP.INF speichert (TOS 1.(0)4), einen für NEWDESK.INF (TOS 2.(0)6) und einen fürs EmuTOS, für den ein eigenes Bootdrive zudem sinnvoll ist, da hier wohl trotz eigener Namensverwaltung auch ein Schreibzugriff auf DESKTOP.INF zu erfolgen scheint!
Wie bereits anderswo geschrieben: EmuTOS ist DESKTOP.INF (und was drin steht) genauso wurscht wie TOS das entsprechende EMUDESK.INF
Das kann ich durch meine Tests mit EmuTOS nicht bestätigen - siehe vorhergehenden Absatz!
Ansonsten hätte ich unter TOS 1.(0)4 ohne Bomben wieder starten können müssen!
-
# neogain!
Ich habe mir jetzt die Seiten von Ppera einigermaßen durchgearbeitet - so wie es aussieht und ich es verstanden habe, muß irgendwas am Treiberpaket per Hand neu konfiguriert werden - ist dazu ein Utility von Dir auf der Karte mitgegeben/abgespeichert worden?
-
ja auf der APPS Partition glaube ich, ansonsten Anhang...
-
Vielen Dank, daß Du mir die Pakete nochmal angehängt hast! Jetzt konnte ich aus den Texten erfassen: Die Treiber arbeiten nur mit DOS-kompatiblen Partitionen! Vielleicht ist dqas schon des Pudels Kern, denn ich habe meine Medien am ST nur "normal" formatiert und partitioniert - dann muß ich das ganze also im DOS-kompatiblen Modus komplett neu machen und dann mal testen!
-
Mein Mega STE hat scheinbar schlapp gemacht, ich war die letzten 3 Tage überwiegend krank (verschleppte Erkältung und noch nicht richtig genesen) im Bett und nur kurze Passagen am PC, der STE zeigt nur noch beim Einschalten einen hellen Screen, dann schaltet der Bildschirm dunkel. Ich vermute irgendwas in der Reset Schaltung, womit auf die HDD gewartet wird! Eine Reparatur hebe ich mir für einen späteren Zeitpunkt auf ... - Vorher würde ich gerne diesen Mega ST endlich Einsatzfähig bekommen - allerdings hat es jetzt auch nicht geklappt mit DOS-kompatibel formatierten Medien für mein SyQuest! Eine Idee habe ich noch - meinen SCSI-Tower - der hat quasi auch einen Treiber und die 1GB Platte ist nahezu 1zu1 mit den Daten der STE HDD bestückt - wenn das nicht klappt, muß ich doch endlich meine GOTEK Atarikompatibel machen! Für den späteren Einbau habe ich mir auch schon die Anzeige vorbereitet:
(https://fbcdn-photos-f-a.akamaihd.net/hphotos-ak-xap1/v/t1.0-0/q84/p206x206/12108963_10201057310551885_9101850272966745047_n.jpg?oh=6faa1c5dbad2ac211dd238e5e81f2b7f&oe=56BBDBC7&__gda__=1455751692_31f73b3852d08d143ac03dc373ca780a)
Allerdings habe ich jetzt erst einmal was anderes in unserem Haushalt zu tun, dann nehme ich erstmal Kontakt mit PP auf und bitte ihn um Hilfe, vielleicht hat er als Urheber der IDE noch einen Rat für mich!
-
... allerdings hat es jetzt auch nicht geklappt mit DOS-kompatibel formatierten Medien für mein SyQuest!...
Wie hast Du partitioniert?
-
Wie schon erwähnt: IDE (CF-Karte) wurde auf einem PC partitioniert - leider verdauen die entsprechenden Treiber im Moment keine HDD am ACSI!
Probiert habe ich es erst mit normal partitionierten Medien und vor wenigen Tagen mit DOS-kompatiblen Medien (ich vermute mit Byteswap-Methode) die ich mit SCSI Tools erstellte am vorher noch funktionierendem STE!
Vielleicht muß ich einfach mal mit einer normalen ACSI (SCSI) HDD mit Treiber booten, aber das probiere ich, wenn ich mich auskuriert habe - jetzt ruft meine Frau erst mal zum essen! ;)
-
Burkhard, Du hast so eine putzige Art, auf meine Fragen mit allerhand Text _nicht_ zu antworten. Die macht's reichlich schwer, dir zu helfen.
Nochmal: wie hast Du die Syquest-Medien DOS-kompatibel gemacht?
-
Ich verwende SCSI-Tools - da heißt es in der Liesmich:
Byteswap [6.00]
Bei Wechselplattenlaufwerken, die sowohl als IDE- als auch als SCSI-Laufwerke vorliegen, gibt es beim Austausch der Medien Probleme. Wird das in einem IDE-Laufwerk partitionierte Medium in einem SCSI-Laufwerk bearbeitet, so erscheinen High- und Lowbyte eines Datenworts vertauscht! Das liegt (zum einen mal wieder) an der PC-Welt, wo ja im Intel-Format gearbeitet wird und aufgrund dessen diese High-/Low-Byte-Vertauschung stattfindet, und zum andern an ATARI, die ihr AT-Bus-Interface ja gleich hätten passend designen können!
`HuSHI' erkennt ab der Version 6.00 diese Vertauschung und berücksichtigt diese beim Datentransfer. Da bei dieser Tauscherei bei jedem Datentransfers mit der Platte ein Rücktausch erforderlich wird, sinkt natrlich die Datenbertragungsrate ab!
Auch `SCSI-Tool' kann solche Medien erkennen. Bei `Partition verändern' wird dies beispielsweise durch ein angehängtes `bs' hinter dem Partitionierungstyp angezeigt.
Beim Partitionieren selbst kann auch gewählt werden, ob die Platte im Byteswap-Modus beschrieben werden soll. Dazu dient -- wie könnte es anders sein -- der Schaltknopf `Byteswap'. Normalerweise sollten Sie ihn nicht verändern. Wenn Sie allerdings auf einer per IDE-Schnittstelle angeschlossenen Platte ein Medium partitionieren, das auch auf DOS-Rechnern lesbar sein soll, müssen Sie den Byteswap-Modus einschalten.
Achtung: im Byteswap-Modus beschriebene Platten sind nicht autoboot-fähig!
Ich habe allerdings einen [Byteswap]-Schalter nie wahrgenommen bei den letzten Versionen, wohl aber einen, um eine Platte/Partition "DOS-kompatibel" vorzubereiten - ich denke daher, daß das das Gleiche sein müßte, bin mir aber nicht sicher!
-
Wie auf der ppera-Seite zu lesen ist, braucht der kostenlose ACSI-Treiber von ihm eine DOS-kompatible Partitionstabelle. Können die SCSI-Tools eine erzeugen und wenn ja, hast Du das gemacht?
In deinem Zitat ist nur von Byteswap die Rede, das ist nur die Hälfte der Miete.
-
Soviel ich weiß brauchst du das Byteswap nur wenn du die Platte an einen PC anstecken willst um drauf zuzugreifen. Wegen Little Endian und Big Endian
-
Mir ist kein Atari Plattentreiber bekannt der richtig DOS kompatibel Partitionieren kann, oder habe ich da etwas verpasst ?
-
Mir ist kein Atari Plattentreiber bekannt der richtig DOS kompatibel Partitionieren kann, oder habe ich da etwas verpasst ?
HDDRIVER zumindest kann das, meine ich.
-
Mit HDDriver formatiere ich meine Syquest-Medien PC-kompatibel, um sie am PC lesen und zu beschreiben. Dann leg ich sie im STE ins Laufwerk und kann normal damit weiter arbeiten.
Klappt wunderbar.
-
Wie auf der ppera-Seite zu lesen ist, braucht der kostenlose ACSI-Treiber von ihm eine DOS-kompatible Partitionstabelle. Können die SCSI-Tools eine erzeugen und wenn ja, hast Du das gemacht?
In deinem Zitat ist nur von Byteswap die Rede, das ist nur die Hälfte der Miete.
Das ist nun wieder ein Buch mit 7 Siegeln für mich! Bisher bin ich am Atari nur mit ACSI Geräten und deren SCSI Adaption gefahren und der Mega ST ist der erste mit IDE. An dieser hängt ein Dual CF Cardreader mit einer 4 GB CF Card, die etwa folgndermaßen aufgeteilt sein dürfte: 4 kleinere Partitionen als Bootpartitionen für je eines der TOSse des mit eingebauten FTOS und mehrere größere als meine Arbeitspartitionen!
Bevor ich jetzt hier weiter mache, nehme ich aber erst einmal Kontakt mit Pera Putnik auf ...
-
Das mit HDDriver kenne ich und nutze es auch. Ist aber kein reines MSDOS FAT16 format sondern etwas mit Trick 17 meine ich, oder ?
Ein neues Massenspeicher Programm das neben Atari TOS und ext2 auch reines FAT16 und 32 kann wäre für die Firebee von Nöten ...
-
Die TOS/DOS kompatiblen Partitionen werden durch anlegen von 2 Bootsektoren realisiert, wenn ich das recht verstanden habe.
Genauer nachzulesen unter Punkt 2.3
http://joo.kie.sk/wp-content/uploads/2013/05/Atari_HD_File_Sytem_Reference_Guide.pdf
-
Wie auf der ppera-Seite zu lesen ist, braucht der kostenlose ACSI-Treiber von ihm eine DOS-kompatible Partitionstabelle. Können die SCSI-Tools eine erzeugen und wenn ja, hast Du das gemacht?
In deinem Zitat ist nur von Byteswap die Rede, das ist nur die Hälfte der Miete.
Das ist nun wieder ein Buch mit 7 Siegeln für mich! Bisher bin ich am Atari nur mit ACSI Geräten und deren SCSI Adaption gefahren und der Mega ST ist der erste mit IDE. An dieser hängt ein Dual CF Cardreader mit einer 4 GB CF Card, die etwa folgndermaßen aufgeteilt sein dürfte: 4 kleinere Partitionen als Bootpartitionen für je eines der TOSse des mit eingebauten FTOS und mehrere größere als meine Arbeitspartitionen!
Bevor ich jetzt hier weiter mache, nehme ich aber erst einmal Kontakt mit Pera Putnik auf ...
Wenn Du meine Fragen nicht beantwortest, sondern immer (absichtlich?) stattdessen 'ne neue Baustelle aufmachst, kann ich auch nicht helfen.
-
Ich denke, es war im Thread alles ausreichend genug beschrieben worden von mir, was ich versucht habe! Und das ich erläuterte, daß ich bislang nur Erfahrung mit ACSI-Geräten (bzw. SCSI Geräten am ACSI Port) habe, dürfte übriges erklären!
Etwas fällt mir aber gerade noch ein, was ich probieren könnte, solange ich auf Antwort von Ppera warte: ich habe noch nicht getestet, wie sich der Mega ST verhält, wenn ich seinen ACSI-Treiber aus dem AUTO Ordner der IDE Platte starte - vielleicht komme ich damit schon zum Zuge - aber das kann ich leider erst heute Abend testen!
-
Ich habe gerade entdeckt: Auf meine eMail an Pera Putnik kam eine "Mail Failed" zurück - dh. er hat meine Anfrage gar nicht erhalten können! Hat jemand von Euch vielleicht eine aktuellere oder andere Kontaktmöglichkeit? Die eMail-Adresse, die ich habe: pkpNOSPAMera{at}sezampro.yu - gab das "Mail Failed"!
-
PM über das atari forum.com geht auch ...
-
PM über das atari forum.com geht auch ...
Ja - nur Ppera, an den ich sie wohl richten müßte, war seit 2012 nicht mehr aktiv im Forum!
-
AtariZoll
-
AtariZoll
probier doch mal petari[at]8bitchip.info
Da bekommste ihn bestimmt ;)
-
AtariZoll
??? ??? ???
probier doch mal petari[at]8bitchip.info
Da bekommste ihn bestimmt ;)
Alles klar - besten Dank - habe gerade nochmal die gleich Mail an diese Empfenger-Adresse auf den Weg gebracht!
-
Ich verlagere das jetzt mal hierher ...:
@Burkhard
Nach meinen Recherchen zum 7722 gestaltet sich die Umsetzung doch etwas schwierig.
Nach dem ausgiebigen hin und her der Komponenten und Jumper schließe ich mich der Meinung von Lukas Frank an.
Der 7722 wird wohl am TT funktionieren, da der vernünftiges SCSI on Board hat.
Deshalb erspare ich mir weitere Tests mit anderen ACSI-Controllern und warte noch 4 Wochen
bis ich meinen TT wieder habe.
Warum nimmst du für den Datenaustausch ST/PC nicht deiner Syquest-Laufwerke?
Soweit ich mich erinnere, hast du welche angeschlossen!?
Habe ich ja versucht - ich bekomme aber mit meinem Mega ST (http://forum.atari-home.de/index.php?topic=12203.msg98200#msg98200) unter dem installiertwem IDE Treiber von Peter Putnik - von dem wohl auch das IDE Interface entwickelt wurde, keine ACSI mehr unterstützt, und wenn ich einen Treiber (SCSI-Tools) nachzuladen versuche, erkennt der zwar das Laufwerk, gibt sie aber als unpartitioniert aus!
ich verstehe immer noch nicht, warum du zum IDE-Treiber von ppera nicht einfach den zugehörigen ACSI-Treiber hinzulädst. Ist doch auf der Webseite genau so beschrieben?
Genau das habe ich erst vorgestern priobiert - den ACSI Driver von PP in den AUTO-Ordner gepackt. Ergebnis: Es werden 0 ACSI Devices angezeigt und dann hängt er sich in eine Dauer-Warteschleife (nix passiert mehr) ab! Zum Glück ließ die sich aber mit der ESC Taste beenden ...
Ich stand auch schon wegen meinem Problem mit Peter in Kontakt und er meint auch selber, daß ich einen herkömmlichen (SCSI-Tools oder HD-Driver - Letzteren hatte er persönlich empfohlen) Treiber anwenden muß und diesen VOR dem IDE Driver laden muß. Auch das hatte ich ja probiert ...
Ist deine Platte Unit 0 und MSDOS-partitioniert? BIGDOS mitgeladen?
Ich habe als SCSI ein SyQuest Laufwerk (für 88MB Medien) in einem SCSI Gehäuse angeschlossen, das ich anderswo schon als Zweitlaufwerk einsetzte. Ich glaube, ich hatte es intern auf ID1 gesetzt! Darin ein Medium, auf daß ich keinen eigenen Treiber installierte, weil ich dachte, ich könne es als Zweitlaufwerk angesprochen! Bigdos wird über den IDE Treiber und von der als IDE Platte eingesetzten CF Karte eingelesen!
Aber Deine Frage hat mir auch eine neue Idee beschert: Ich könnte die Platte aus dem M-STE ausbauen und in ein SCSI Gehäuse setzen - da ist ein Treiber drauf und die hat ID0, Das werde ich gleich morgen probieren - vielleicht kann ich so meine Daten auf den "neuen" ST bringen!
Der ppera-Treiber funktioniert (wie man auf der Website lesen kann) nur mit Unit 0.
Burkhard, wenn du mindestens 2 Syquest-LW hast, warum formatierst du nicht ein Medium DOS-kompatibel mit HDDiver und setzt es zwischen Atari und PC ein?
Hat bei mir bisher immer wunderbar funktioniert!
So bekomme ich rel fix auch rel. große Datenmengen zwischen den Rechnern kopiert.
Ich habe auf dem PC kein SCSI - und meine Laufwerke sind alle SCSI! Nein - laßt mich erstmal morgen testen, ob meine Idee von vorhin klappt - jetzt teste ich erstmal, ob das Laufwerk auf - ich gehe davon aus, daß Unit 0 = ID0 heißt - mit ID0 eingebunden wird ...
Ich habe jetzt mit dem auf ID0 umgeäanderten SyQuest noch einmal probiert - gleiches Ergebnis, wie als SyQuest ID1 war ...
-
Jetzt zum allerletzten Mal gefragt: DOS partitioniert? Wenn ja, wie gemacht?
-
Sch...e :( - das Du mich als nach "DAS Format" fragst, fiel mir gar nicht auf - natürlich habe ich die Medien auf dem Atari normal initialisiert, da ich dachte, ich könne auch den ACSI Port für weitere Laufwerke nutzen!
Naja - dann bleibt mir wohl nix andres übrig, als morgen erstmal mit der Festplatte zu probieren! Den ganzen Aufwand nochmal, die Medien neu zu Partitionieren (SCSI-Tools kann DOS-Partitionen initialisieren), tue ich mir nur in letzter Instanz an!
-
Ich wollte gestern mal probieren, MagiC - müßte v6.20 sein - im ROM nutzbar zu machen, indem ich die benötigten Dateien hier nochmal downgeloaded (http://atari.8bitchip.info/magic62.html) habe und auf das entsprechende Bootlaufwerk kopierte (unter Ubuntu am PC)! Was bei einem Start passiert, seht selbst (https://www.youtube.com/watch?v=0QpwWGcu1-8)!
Sorry, ich habe mit Handy gefilmt und keine besonders ruhige Hand!
Was nach weiterem Tastendruck noch passiert, könnt Ihr den 2 angehängten Fotos entnehmen!
Wie kriegt man das Prob in Griff?
Ich bin der Meinung, ich hatte mal irgendwo gelesen, daß MagiC eigene HDD-Driver mitbrinmgt und würde es gerne mal auf diesem Wege probieren!
-
Gut, dann hab ich wahrscheinlich doch nichts falsch gemacht, bei mir kommt dasselbe in Grün. Das Image sollte schon richtig sein von der Seite. Versuche mal ein komplett neues Magic einzurichten auf einer Partition die kleiner als 100MB ist. kopiere dann von einer regulären Quelle das Magic auf die Partition und mach nur den IDE Treiber mit drauf, kein bigDOS. Vermutlich ist das, des Rätsels Lösung.
Viel Glück
-
Gut, dann hab ich wahrscheinlich doch nichts falsch gemacht, bei mir kommt dasselbe in Grün. Das Image sollte schon richtig sein von der Seite. Versuche mal ein komplett neues Magic einzurichten auf einer Partition die kleiner als 100MB ist. kopiere dann von einer regulären Quelle das Magic auf die Partition und mach nur den IDE Treiber mit drauf, kein bigDOS. Vermutlich ist das, des Rätsels Lösung.
Viel Glück
So ganz verstehe ich jetzt nicht, wie Du das meinst! Wenn ich die Abfrage richtig gemacht habe, ist die Partition, die Du für mich für MagiC eingerichtet hast, ca. 80MB, also kleiner 100MB; und der IDE Treiber soll doch nur von der Partition gestartet werden müssen, die beim Start des ST an erster Stelle ist! Ohne BigDOS muß ich dann wohl auch auf die größeren Partitionen verzichten, was aber sehr unbefriedigend sein dürfte!
-
So - jetzt habe ich es geschafft, die ASCI-Schnittstelle anzusprechen und auch meine Daten auf dem Medium zu finden und habe mir die Dateien des ersten Medium auf die CF Karte übertragen! Zur Info: Die Lösung ist so Simpel wie sie auch nicht leicht zu erahnen ist: Ich habe einfach HUSHI.PRG aus dem AUTO-Ordner der SCSI-Tools Diskette per Hand nachgeladen. Der IDE-Treiber wird durch HuSHi scheinbar nicht aus dem System geschmissen, wie es beim HD-Driver der Fall sein soll, denn die Laufwerke vom IDE System bleiben erhalten! Nun habe ich mir HUSHI.PRG in den AUTO-Ordner des Drive C: kopiert, und kann so hoffentlich auch in Zukunft über den Zugriff auf ACSI verfügen!
-
Die einfachsten Lösungen sind oft die besten!
Ich gratuliere dir Burhard.
-
Das darf ja wohl nicht wahr sein! Jetzt hänge ich seit Stunden daran, um endlich die CF Karte neu zu initialisieren und installieren - aber bis vor wenigen Minuten nicht geschafft, überhaupt eine der vorhandenen Partitionen zu löschen, weil alles bezüglich Partitionen bei GPartEd ausgegraut waren! Jetzt habe ich entdeckt, die zu bearbeitende (löschende) Partition muß ausgehängt werden; beim Vorgang werden aber wiederum für jede Partition wieder mindestens 10 Minuten gebraucht, weil GPartEd bei jedem "Durchgang" erst einmal alle Laufwerke durchsucht und sich bei diesem Vorgang gerne aufhängt oder sich ganz aus dem Arbeitsspeicher verabschiedet - und dann nicht mehr startet! Was für'n Krampf!
edit: Gibt es unter Ubuntu vielleicht sowas wie'n Taskmanager, mit dem ich evtl Programmreste eines Programms, die sich im RAM verankerten und den Neustart desselben verhindern, aus dem Arbeitsspeicher zu eliminieren?
-
ps -ef | grep "suchbegriff"
oder
top
und nimm fdisk, wenn du keine UEFI Partition erstellen willst ist das besser da handlicher... ist halt nicht klickibundi sondern per console... geht also schneller und einfacher
-
So - nachdem ich abends erstmal aufgegeben habe und erstmal was anderes am PC machte, kam mir vorhin die Idee - ich hatte mir mal einen GPartEd Life Stick auf einem älteren USB ganz kleiner Größe (1/4GB) erstellt - es nochmal mit jenem zu probieren - und siehe da, in wenigen Minuten war das Ziel erreicht!
Übrigens: "fdisk" kenne ich nur von DOS, und einen Rechner mit diesem OS und Cardreader für CF habe ich leider nicht!
-
Übrigens: "fdisk" kenne ich nur von DOS
Dann gibt mal fdisk in der Shell Deines Linux-Systems ein.
Aber da ja jetzt alles geklappt hat...
-
fdisk /dev/sdX und dann kommst du ins fdisk rein, ist alles menügeführt ähnlich wie unter dos.
-
Aber da ja jetzt alles geklappt hat...
Naja - so ganz scheint es doch nicht geklappt zu haben! Ich habe zwar erstmal meine Laufwerke in der Größenordnung, wie ich sie haben will und der Treiber ließ sich dann (noch in der Nacht) am Atari auch einwandfrei installieren. Nachdem ich dann auf der offiziellen Partition "C:" den AUTO Ordner erstellte, und dann von der Partition, auf die ich die Dateien "zwischengelagert" hatte, mein BootDrive installieren wollten, sehe ich dort erst einmal ein korrektes Directory; nachdem ich aber einen Ordner öffne, nur noch Datenmüll! Vielleicht auch nur ein Umstand eines noch nicht installierten BigDOS, da ich das ja aus diesen Ordnern holen wollte! Vielleicht ist ohne dieses die Laufwerkkennung von Laufwerken jenseits 200MB (auf einem solchen liegen die) einfach nicht OK - werde ich gleich mal testen! Ansonsten - wenn es nicht daran liegt - sind die Proggies, die mir von @neogain auf die CF vorinstalliert waren, halt verloren, alles andere habe ich ja (hoffentlich) noch auf den Wechselplatten vorhanden! Also erstmal halb so schlimm!
fdisk /dev/sdX und dann kommst du ins fdisk rein, ist alles menügeführt ähnlich wie unter dos.
Kommt drauf an, ob fdisk überhaupt auf dem Ubuntu LifeSystem, das ich mir auf SD-Karte erzeugte und am PC (vorerst keine komplette Installation) verwende, überhaupt vorhanden ist! Jedenfalls habe ich dort kein Programm dieses Namens öffnen können und auch im Netz nichts dazu finden können!
-
Alles Roger! Lag tatsächlich am noch nicht installiertem BigDOS!
Dabei habe ich auch gleich feststellen können, daß BogDOS nicht als BIGDOS.APP aus dem Auto-Ordner startet!
-
Ist im AUTO-Ordner nicht seit jeher *.PRG nötig?
Kaum zu glauben, dass fdisk nicht vorhanden sein soll, ist es doch das Standard-Partitionierprogramm unter Linux. Näheres auf https://wiki.ubuntuusers.de/fdisk/
Insbesondere musst Du es natürlich mit "sudo" aufrufen, wie alles, was das System verändert.
-
Ist im AUTO-Ordner nicht seit jeher *.PRG nötig?
Für TOS 1.(0)2 war mir das auch bewußt, da sieht das im TOS integrierte DESKTOP.INF nur *.PRG, *.TOS und *.TTP als startfähige Programmfile vor, ließe sich wohl mit dem nachlade DESKTOP.INF aber erweitern. Ab TOS 1.(0)4 ist aber noch *.APP dazugekommen, für das mw die gleichen Regeln gesetzt sind wie für *.PRG, und ab TOS 2.(0)6 noch weitere! Ich habe weiter oben (bzw. einige Threadseiten weiter vorher mal gefragt, ob man auch APPs aus dem AUTO Ordner starten kann, weil ich BigDOS gerne vor meinem Bootselektor verstecken wollte, um versehentliches deaktivieren zu verrmeiden - naja, gät halt net!
Kaum zu glauben, dass fdisk nicht vorhanden sein soll, ist es doch das Standard-Partitionierprogramm unter Linux. Näheres auf https://wiki.ubuntuusers.de/fdisk/
Insbesondere musst Du es natürlich mit "sudo" aufrufen, wie alles, was das System verändert.
Da ich Linux (Ubuntu) nicht als Hauptsystem nutze, sind mir Aufrufe über Terminal noch nicht so geläufig! Wie erwähnt, ist es ein (persistentes) Lifesystem, was ich vorerst am PC anwende - und das ist vermutlich nur minimal eingerichtet! Da GPartEd vorhanden ist wurde wohl auf fdisk verzichtet! Könnte ich wohl (da persistent) zufügen, aber zZ benötige ich es ja nicht mehr!
-
APP ist rein für GEM-Programme vorgesehen, und als langjähriger User weißt du sicherlich, dass GEM-Programme nichts im AUTO-Ordner zu suchen haben. Im AUTO-Ordner werden nur PRG Programme unterstützt (die keine GEM-Aufrufe machen!). Eigentlich ist aber das inkonsistent, weil Programme die keine GEM-Aufrufe machen, ja eigentlich *:TOS Dateien sind. Wer weiß, was sich ATARI dabei gedacht hat...
Außerdem hast du in deiner Aufzählung noch *.GTP vergessen: (GEM takes parameter), das gibts seit TOS 2.0x/3.0x auch. Hat aber auch nix im Autoordner zu suchen, jedenfalls wenn man erwarten will, dass es beim Booten fehlerfrei gestartet werden soll.
-
Kommt drauf an, ob fdisk überhaupt auf dem Ubuntu LifeSystem, das ich mir auf SD-Karte erzeugte und am PC (vorerst keine komplette Installation) verwende, überhaupt vorhanden ist! Jedenfalls habe ich dort kein Programm dieses Namens öffnen können und auch im Netz nichts dazu finden können!
SINNLOS, warum stellst du denn dann noch fragen wenn du eh alles besser weißt ?
-
SINNLOS, warum stellst du denn dann noch fragen wenn du eh alles besser weißt ?
Was hat ...
Übrigens: "fdisk" kenne ich nur von DOS, und einen Rechner mit diesem OS und Cardreader für CF habe ich leider nicht!
... und ...
Kommt drauf an, ob fdisk überhaupt auf dem Ubuntu LifeSystem, das ich mir auf SD-Karte erzeugte und am PC (vorerst keine komplette Installation) verwende, überhaupt vorhanden ist! Jedenfalls habe ich dort kein Programm dieses Namens öffnen können und auch im Netz nichts dazu finden können!
... mit Fragestellen zu tun? Und außerdem bin ich hierbei (mein letztes Zitat von mir) nicht wissend, sondern vermute es nur! Alle integrierten Progamme, die ich bei Ubuntu bislang benötigte, konnte ich aus der Desktop-Shell mit der Maus aufrufen und starten!
Die einzige Frage war nach einem Equivalent zum Windows Task Manager, das auch dazu genutzt werden kann, um Programmteile, die sich nicht richtig aus dem Arbeitsspeicher verabschieden, zu eliminieren, damit das Programm bei einem Neustart wieder vernünftig startet!
-
Nein du stellst Aussagen von Leuten die es 1000%tig Wissen und jeder das hier weiss ständig in Frage. Belehrst Programmierer wie man Windows bedient und solche Scherze.Stellst aus Prinzip aussagen die hier getroffen werden in Frage. Solltest echt mal drüber nachdenken.
-
egal welches Linux, Terminal öffnen, fdisk eingeben und freuen (selbstverständlich mit den richtigen Paratmetern) ;)
-
Nein du stellst Aussagen von Leuten die es 1000%tig Wissen und jeder das hier weiss ständig in Frage. Belehrst Programmierer wie man Windows bedient und solche Scherze.Stellst aus Prinzip aussagen die hier getroffen werden in Frage. Solltest echt mal drüber nachdenken.
Wenn das so ist, dann ist das aber kein ...
... stellst du denn ... noch fragen ...
... sondern ein "in-Frage-stellen"!
egal welches Linux, Terminal öffnen, fdisk eingeben und freuen (selbstverständlich mit den richtigen Paratmetern) ;)
Da ich mich mit den Parametern nicht auskenne, war die Lösung mit GPartEd, wie ich sie Nachts erreicht hatte, doch auch die sinnvollere und bessere Lösung!
-
Burki, wie jeder (!) andere Linux-Befehl auch versteht der Befehl "fdisk" auch den Parameter "--help". Außerde hat jedes Linux man-pages an Bord. Da hilft dann z.B. der Befehlt "man fdisk" und außerdem gibts unzählige Webseiten, die per Google mit dem Suchbegriff "linux fdisk" auffindbar sind, auf denen der Umgang mit fdisk für Linux erklärt wird. Eigentlich braucht man dazu nichtmal die Webseite von ubuntu zu verlassen.
Du bekommst von mir gleich eine PN mit einem Downloadlink mit einem Linux-Buch, gedruckt hat der Wälzer 1200 Seiten, da kannst du dich mal mit beschäftigen. Da steht auch was zu fdisk drin und es ist in Deutsch. Viel Spaß.
-
Das Buch hilft mir beim fehlenden fdisk auch nicht weiter - aber trotzdem danke!
Ich habe es nämlich vorhin probiert, und es scheint auf dem persistenten System nicht verfügbar! Es gibt auch eine entsprechende Meldung - aber ich weiß nicht, wie ich einen Screnshot oder ähnliches mache - sonst hätte ich einen Beweis erstellt! Mittlerweile arbeite ich wieder unter Windows und wegen den recht langen Hochfahrzeiten des jeweiligen OS habe ich jetzt keine Lust, es nochmals nachzuvollziehen! Ich habe den gleichen Test auch unter einer vollwertigen Installation auf meinem Labtop vollzogen und dort startet es und ist, wie ich danach feststellte, auch im Applikationsfenster vorhanden und dort per Maus startbar! Auf dem Noti bringt es mir aber herzlich wenig da ich momentan keinen passenden USB Cardreader verfügbar habe!
Und lassen wir doch bitte endlich die Diskus um fdisk! Schließlich war ich ja mit GPartEd ohne Ubuntu-Umgebung erfolgreich!
Und Bezüglich des Dropbox Links in Deiner PN: Um was downzuloaden, muß man sich anmelden oder registrieren - ich hatte also recht in dem anderen Link, als es darum ging!
-
Nein, muss man nicht. Man kann es so runterladen. Wahrscheinlich brauchst du neben dem Buch auch eine Brille.
-
Nein - er hat definitiv ein Anmelden oder Registrieren verlangt, als ich auf DOWNLOAD ging! Und da war nirgends ein Link für "ohne Anmelden weiter" oder ähnlich! Da ich aber sowieso einen Account hatte, war das ja auch weiter kein Problem!
-
Schade, dass wir hier keinen Smiley haben, der mit dem Kopf gegen die Wand schlägt... (alternative Aussage: Wozu dann die Diskussion???)
-
Du, die Idee mit dem Facepalm-Smiley habe ich beim Herrn Administrator bereits kürzlich angebracht. Leider wurde mein Beitrag dazu von ihm aber gelöscht aufgrund angeblicher Provokation.
Zurück zum Thema: worum gehts hier eigentlich? Man hat irgendwie gar keine Lust mehr, sich das alles durchzulesen. ;D
-
Seid ihr einfallslos.
(http://www.smileygarden.de/smilie/Sauer/366.gif) (http://www.smileygarden.de)
(http://www.smileygarden.de/smilie/Sauer/365.gif) (http://www.smileygarden.de)
-
Wie hast Du das gemacht?
-
Wie hast Du das gemacht?
Tja...ne... da staunste Bauklötze (http://www.smileygarden.de/smilie/Frech/smileymania.at_11063.gif) (http://www.smileygarden.de)
- auf http://www.smileygarden.de (http://www.smileygarden.de) gehen
- Javascript einschalten
- Schriftzug "LINKCODE" unter dem gewünschten Smiley anklicken
- den BB Code unter "Forum-Link" auswählen und in die Zwischenablage kopieren
- hier im Beitrag einfügen
-
Ja die Seite kenne ich auch :) ist ja nur das einblenden von Bildern
-
Mensch, seid Ihr einfaltslos! meine ...
... (aller(http://www.deutschlandangeln.de/images/smilies/herz.gif)lichstes (http://www.smiley-paradies.de/smileys/schild/schild_0015.gif) noch mal an ihn) ...
... aus meinem Eingangspost habe ich mir aus verschiedenen anderen Foren zusammengeklau(b)t! ging recht einfach:
1. Anhang "Schritt 1.png"
2. Grafikadresse kopieren
3. hier in einer Antwort als IMG einfügen
http://www.forum64.de/wbb4/wcf/images/smilies/danke.gif:(http://www.forum64.de/wbb4/wcf/images/smilies/danke.gif)
weitere Beispiele entfernt, da sie mir ...
-
Nur nicht ausrasten... 8)
-
So - nach dem vielen OfTopic geplänkel möchte ich mich wieder dem Thema widmen:
Drive "C:" für TOS 2.(0)6 ist nach meinen Wünschen eingerichtet. Bei den folgenden Teststarts hängt sich NVDI5.PRG, das mir von @neogain auf der CF-Karte schon mal vorinstalliert war, auf. Es erscheint noch korrekter Weise die Bildschirmmeldung, dann hängt das System! Ich habe es also erstmal deselektiert, bis ich herausfinden kann, woran das liegt (entweder ist es durch Hin- und Herkopieren zerstört oder verträgt sich nicht mit zuvor geladenen Proggies)! Ich habe da folgende physikalische Ordnung im AUTO-Ordner
- Bootselektor (STARTUP.PRG)
- BIGDOS.PRG
- HUSHI.PRG (um ACSI nutzbar zu haben)
- METAFONT.PRG nebst BOS und DOS Treiber sowie CONFIG.SYS (vorerst aber deselektiert, da kein CD ROM angeschlossen)
- UIS_III.PRG (Fileselektor)
- nach einigen weiteren deselektierten Proggies NVDI5.PRx sowie weitere deselektierte Proggies, die sich auch teilweise nicht mit dem System vertragen scheinen (2 Bomben)
Das System fährt jetzt zwar mit einigen ACCs (Kontrollfeld, Harlekin) hoch, aber woran kann es liegen, daß NVDI5 nicht durchstartet?
-
Beim NVDI braucht es die Dateien im Gemsys Ordner und die assign.sys im Rootverzeichnis von C:\ ...
-
So - nach dem vielen OfTopic geplänkel möchte ich mich wieder dem Thema widmen:
Drive "C:" für TOS 2.(0)6 ist nach meinen Wünschen eingerichtet. Bei den folgenden Teststarts hängt sich NVDI5.PRG, das mir von @neogain auf der CF-Karte schon mal vorinstalliert war, auf. Es erscheint noch korrekter Weise die Bildschirmmeldung, dann hängt das System! Ich habe es also erstmal deselektiert, bis ich herausfinden kann, woran das liegt (entweder ist es durch Hin- und Herkopieren zerstört oder verträgt sich nicht mit zuvor geladenen Proggies)! Ich habe da folgende physikalische Ordnung im AUTO-Ordner
- Bootselektor (STARTUP.PRG)
- BIGDOS.PRG
- HUSHI.PRG (um ACSI nutzbar zu haben)
- METAFONT.PRG nebst BOS und DOS Treiber sowie CONFIG.SYS (vorerst aber deselektiert, da kein CD ROM angeschlossen)
- UIS_III.PRG (Fileselektor)
- nach einigen weiteren deselektierten Proggies NVDI5.PRx sowie weitere deselektierte Proggies, die sich auch teilweise nicht mit dem System vertragen scheinen (2 Bomben)
Das System fährt jetzt zwar mit einigen ACCs (Kontrollfeld, Harlekin) hoch, aber woran kann es liegen, daß NVDI5 nicht durchstartet?
Alles im Autoordner deaktivieren nur NVDI5 evtl. auch wdialog aktiv lassen und dann testen ...
-
Beim NVDI braucht es die Dateien im Gemsys Ordner und die assign.sys im Rootverzeichnis von C:\ ...
(http://www.forum64.de/wbb4/wcf/images/smilies/64.gif)Ich Idi ...(http://www.forum64.de/wbb4/wcf/images/smilies/64.gif)
Ist doch oft genug in anderen Threads behandelt worden, was ich mitgelesen habe! Habe den natürlich gelöscht weil ich dachte, MagiC zum nachladen benötige ich nicht mehr! Und das nutzt diesen Ordner ja auch!
-
Beim NVDI braucht es die Dateien im Gemsys Ordner und die assign.sys im Rootverzeichnis von C:\ ...
(http://www.forum64.de/wbb4/wcf/images/smilies/64.gif)Ich Idi ...(http://www.forum64.de/wbb4/wcf/images/smilies/64.gif)
Ist doch oft genug in anderen Threads behandelt worden, was ich mitgelesen habe! Habe den natürlich gelöscht weil ich dachte, MagiC zum nachladen benötige ich nicht mehr! Und das nutzt diesen Ordner ja auch!
Wenn man sicher sein möchte reicht das Umbenennen des Ordners statt gleich zu löschen. In den Ordner schauen bevor man ihn löscht ist auch hilfreich.
-
Naja - hinterher ist man ja doch schlauer - und da auch das ASIGN.SYS bei meiner Installation wahrscheinlich fehlt, bringt es ja auch nix, den Ordner, der vermutlich sowieso nur die MagiC Dateien enthielt, einfach umbenannt hätte, zudem die Dateileichen unnötig Speicherplatz kosten. Da ich die funktionierende Erstinstallation von @neogain aber glücklicherweise auch sicherte, dürfte es kein Problem sein, das jetzt noch zu korrigieren!
-
So - habe jetzt das mit dem Bootlaufwerk in Ordnung gebracht, dh. ASIGN.SYS und den GEMSYS Ordner mit auf das ROOT der Partition kopiert, aber ... daran lag es wohl doch nicht. Eigentlich auch nicht verwunderlich, ich würde erwarten, wenn korrekt programmiert, sollte ich eher eine Meldung zu fehlenden Dateien erhalten und der Bootvorgang dann fortgesetzt werden!
Werde am Tage dann mal den Tipp von @Arthur nachvollziehen!
-
Burkhard, natürlich kann man nicht "irgendeine" Assign.sys und "irgendeinen" Gemsys-Ordner nehmen, sodern das muss schon zu NVDI und der Hardware passen. Am besten, du besorgst dir mal die NVDI5 Diskimages und installierst das neu.
-
Das, was ich jetzt an GEMSYS Ordner und ASIGN.SYS installiert habe, ist genau die Version, die von @neogain vorinstalliert war - und damit lief es ja vor meiner "Korrigierung" der Harddisk-Partitionen!
Alles im Autoordner deaktivieren nur NVDI5 evtl. auch wdialog aktiv lassen und dann testen ...
@Arthur !
Du hast hier empfohlen, evtl auch wdialog aktiviert zu lassen! WDIALOG.PRG steht bei meinem System hinter NVDI.PRG und verursachte im Startvorgang auch Bomben und Absturz (Neustart)! Kann da bedeuten, daß es vielleicht vor NVDI gestartet sein muß (und daß NVDI ein eigenes WDIALOG benötigt), daß ich also die 2 Programme physikalisch tauschen muß? Werde ich auf jeden Fall mal testen!
Ich werde aber jetzt auch erstmal nach einem NVDI Image suchen und dort hoffentlich eine Anleitung haben, wie man installieren muß!
-
Hallo Burkhard, WDIALOG wird z.B. für den CPX-Server Cops benötigt wenn kein NVDI geladen ist... muss also eigentlich heissen entweder WDALOG oder NVDI aktiviren.
-
... Am besten, du besorgst dir mal die NVDI5 Diskimages und installierst das neu.
Leider konnte ich keine Downloadmöglichkeit für NVDI 5 finden, wohl aber als aktuellste version NVDI 2,50! Kann man die auch noch empfehlen?
Hallo Burkhard, WDIALOG wird z.B. für den CPX-Server Cops benötigt wenn kein NVDI geladen ist... muss also eigentlich heissen entweder WDALOG oder NVDI aktiviren.
Dann war Dein entsprechender Post etwas mißverständlich - WDIALOG.PRG kommt bei meiner Zuordnung direkt hinter NVDI.PRG und ist erstmal deselektiert; eine Umverlagerung der beiden Programme wird demnach nicht nötig sein!
edit: Das mit dem Erhalt von NVDI 5 hat sich dak @ditto erledigt!
-
Nur rein profilaktisch, weil es mich jetzt betreffen könnte:
Nachdem ich NVDI 5 downgelodet und direkt auf dem Windows-Desktop in einen Ordner NVDI5 entpackt habe, habe ich einen Ordner mit den Underordnern DISK1, DISK2 und UPDATE auf dem PC. Die Inhalte von DISK1 und DISK2 sind aber zu groß für physikalische DD-Disks. Ich werde also von Festplatte (bzw einer Partition der CF Karte) installieren müssen. Weil ich mich noch bei ditto per PN bedankt habe, habe ich ihn gleich gefragt, ob er weiß, ob das überhaupt möglich sei, und er hat mich auf einen betreffenden Beitrag und speziell auf dieses Posting aufmerksam gemacht:
Doch, das geht... Moment....
Kopier mal den Inhalt beider Disks in einen Ordner, dann müsste da eine Datei namens Disk1 und Disk2 (beim Namen bin ich mir nicht sicher) sein, die muss man löschen, wenn ich mich recht erinnere.
Dann klappt die Installation von HD, Hab ich beim Falcon schon oft gemacht.
Ich kann nachsehen, sobald mein Falke wieder läuft.
Gruß,
Stefan
Ich habe auch den kompletten Thread überflogen!
Wenn ich das recht verstehe, gehe ich nun folgendermaßen vor: Ich ziehe Ordner DISK1 oder DISK2 aus NVDI5 auf meinen Desktop, benenne ihn entsprechend des verbleibenden Ordners um und schiebe ihn wieder hinein, dann noch NEXTDISK löschen und ich habe ein von Festplatte mögliches Installationspaket ?!?
-
1.Ordner auf HDD erstellen.
2.Inhalt beider Disketten in den HDD-Ordner kopieren. (oder den Inhalt der Disk1 und 2 Ordner).
3.Nextdisk Datei löschen.
4.Install.prg aus dem Ordner starten. Vorher die Seriennummer notieren.
-
Alles klar - genau das wird durch die von mir beschriebene Weise erreicht! (Schritte 1 bis 3). Dann nur noch auf die CF Karte kopieren (zB unter Ubuntu) und dann auf dem Atari Schritt 4 ausführen!
Danke @Arthur !
-
WDIALOG wird z.B. für den CPX-Server Cops benötigt wenn kein NVDI geladen ist... muss also eigentlich heissen entweder WDALOG oder NVDI aktiviren.
Leider falsch, NVDI stellt nicht die Funktionen von WDialog zur Verfügung,
-
(Zitat aus Mega ST4 mit AT Bus TOS Card 2.06: SD-Karte statt IDE-Festplatte?) (http://forum.atari-home.de/index.php?topic=12889.msg206620#msg206620)
Thema hatten wir schön. Antwort: Nö, funktioniert aber mit CableSelect, das habe ich schon getestet.
@neogain
Ich plane für meinen Mega 4+ den Einsatz eines 1xCF Adapters neben einem ähnlichen Adapter, wie Du ihn dort verlinkst. Hast Du eine Idee, wie ich daber erreiche, daß die CF als Master (läßt sich auf allen passenden Adaptern die ich sichtete per Jumper eeinstellen) und die SD als Slave angesprochen wird?
-
Nur mal so ganz doof die Frage... welche Vorteile habe ich wenn ich SD Nutze anstatt CF ? Die Reader haben eh meist alle CF und SD in einem.
-
Nur mal so ganz doof die Frage... welche Vorteile habe ich wenn ich SD Nutze anstatt CF ? Die Reader haben eh meist alle CF und SD in einem.
Die Reader am PC ja (meist), wobei man heute auch immer mehr - zumindest bei den Kompakt PC - dabei abspeckt! Aber ich habe noch kein Notenbook mit Reader für CF gesehen, während SD Schächte fast überall zu finden sind!
-
Nur mal so ganz doof die Frage... welche Vorteile habe ich wenn ich SD Nutze anstatt CF ? Die Reader haben eh meist alle CF und SD in einem.
SD Karten sind günstiger und hat man überall rumfliegen (so ist das zumindest bei mir). Ansonsten gibt es keine großen Vorteile, außer vielleicht, dass der IDE Adapter schön kompakt ist und man diesen mit wenig aufwand in jeden Atari reinpappen kann. Ich für meinen Teil bin ein Fan von diesen Dingern (wo ich verlinkt habe).
-
Also ich hab für meine 4Gb Sandisk 8€ bezahlt was auch eine SD Kostet.. also Kosten ist kein Thema..
Platz nun gut man muß 1mm mehr ausschneiden in der dicke.
-
SD Karten sind günstiger und hat man überall rumfliegen (so ist das zumindest bei mir). Ansonsten gibt es keine großen Vorteile, außer vielleicht, dass der IDE Adapter schön kompakt ist und man diesen mit wenig aufwand in jeden Atari reinpappen kann. Ich für meinen Teil bin ein Fan von diesen Dingern (wo ich verlinkt habe).
Nunja - günstiger? habe ich eher den entgegengesetzten Eindruck - vor allem, wenn man Hersteller- und Größengleichheit sowie Anbieter mit in die Waagschale nimmt! Und leichter erhältlich sind SD gegenüber CF mAn auch - CF kommt ja scheinbat immer mehr aus der Mode! Aber für mich ist das alles eher Nebensächlich - am wichtigsten wäre mir, Datentausch mit möglichst allen bei mir angewandten Systemen, ohne gleich nach externen Cardreader zu fahnden. Notebooks haben idR heute alle einen SD Slot ...
Also ich hab für meine 4Gb Sandisk 8€ bezahlt was auch eine SD Kostet.. also Kosten ist kein Thema..
Platz nun gut man muß 1mm mehr ausschneiden in der dicke.
... und ca. doppelt so breit wie bei SD!
-
Ach kommt schon, ist doch völlig wurscht ob CF oder SD. Funktioniert doch beides. Das ist genauso eine Diskussion, ob Commodore oder Atari besser ist (naja nicht ganz). Soll doch jeder das verbauen, was er präferiert.
Hauptsache der Atari kann die Daten davon lesen, oder etwa nicht?
-
In dem Laden bei uns (Saturn werden nur noch cf mit 100MByte/s und mehr angeboten) die Preise sind uninteressant für einen ST der gerade um die 1MByte/s schafft. STs die aufgerüstet werden bekommen nur noch SD von mit verpasst.
-
Lassen wir das jetzt mal gut sein, welches bessere Speicherkarte ist! Ich denke an einen Zugang des externen Slot über dem Modulport! Dort habe ich den Dual-Adapter auch erstmal provisorisch fixiert! Da ich mir aber noch nicht ganz im Klaren bin, welche Karte es am Ende wird, mache ich noch keinen Ausbruch ins Gehäuse!
edit: Wenn ich keine Lösung für die Jumperlose SO als Slave finde, bleibe ich bei der CD und dem Dual-Adapter!
-
@Burkhard Mankel: Ich glaube, Du hast auf Deiner Tastertur die "."-Taste mit der "!"-Taste vertauscht. >:D
Ich persönlich finde so eine Speicherkarte als Wechseldatenträger als gute Lösung. Allerdings würde ich in den Rechner dennoch sowas wie eine SSD oder Festplatte einbauen, die dort auch fest verbaut ist und nicht immer wieder getauscht wird. Das hat den Vorteil, dass einem so schnell nichts verschütt gehen kann. SD- oder CF-Karten kann man dann doch mal verlegen und dann ist alles futsch im Extremfalle. Was beim Atari die Sache etwas schwierig macht, ist das Booten von einem Laufwerk, was nicht den Laufwerksbuchstaben "A" oder "C" hat. HDDriver bekommt das zwar hin, aber wenn das Bootlaufwerk dann den Buchstaben "D" hat anstatt "C" sind möglicherweise alle Einträge in den entsprechenden Konfigurationsdateien des Betriebssystems fürn Popo, wenn die Pfandangaben sich alle auf Laufwerk "C" beziehen. ???
-
@Nervengift
Meinen letzten Beitrag habe ich mit Handy getippt - das Wörterbuch setzt gerne irgendwas - auch Satzzeichen - nach Gutdünken um! Der Beitrag ist trotzdem recht verständlich - denke ich!
Ich persönlich finde so eine Speicherkarte als Wechseldatenträger als gute Lösung. Allerdings würde ich in den Rechner dennoch sowas wie eine SSD oder Festplatte einbauen, die dort auch fest verbaut ist und nicht immer wieder getauscht wird. Das hat den Vorteil, dass einem so schnell nichts verschütt gehen kann. SD- oder CF-Karten kann man dann doch mal verlegen und dann ist alles futsch im Extremfalle. Was beim Atari die Sache etwas schwierig macht, ist das Booten von einem Laufwerk, was nicht den Laufwerksbuchstaben "A" oder "C" hat. HDDriver bekommt das zwar hin, aber wenn das Bootlaufwerk dann den Buchstaben "D" hat anstatt "C" sind möglicherweise alle Einträge in den entsprechenden Konfigurationsdateien des Betriebssystems fürn Popo, wenn die Pfandangaben sich alle auf Laufwerk "C" beziehen. ???
Ich habe ja einen Dual-Adapter, bei dem eine CF sozusagen unantastbar als SSD-Ersatz intern verbleibt - Master - und der nach außen erreichbar montierbare Steckplatz eben ist als Slave gejumpert. Auch mit dem Booten ist das bei mir etwas anders, da bei mir F-TOS und passender Treiber von Pera Putnik Anwendung finden, wähle ich in der Hochfahrphase das jeweils zum eingestellten DOS vorinstallierte "Bootlaufwerk", das über "I:" liegt - und das wird durch den Treiber mit "C:" getauscht - ist also Infolge auch immer "C:"!
-
Meinen letzten Beitrag habe ich mit Handy getippt - das Wörterbuch setzt gerne irgendwas - auch Satzzeichen - nach Gutdünken um! Der Beitrag ist trotzdem recht verständlich - denke ich!
Ein ungebändigtes Wöterbuch. :D Ich dachte nur, Du bist vielleicht etwas angepieselt oder so und hast deswegen jedes Satzende mit einem "!" versehen. ;D
Ich habe ja einen Dual-Adapter, bei dem eine CF sozusagen unantastbar als SSD-Ersatz intern verbleibt - Master - und der nach außen erreichbar montierbare Steckplatz eben ist als Slave gejumpert. Auch mit dem Booten ist das bei mir etwas anders, da bei mir F-TOS und passender Treiber von Pera Putnik Anwendung finden, wähle ich in der Hochfahrphase das jeweils zum eingestellten DOS vorinstallierte "Bootlaufwerk", das über "I:" liegt - und das wird durch den Treiber mit "C:" getauscht - ist also Infolge auch immer "C:"!
Das ist dann die optimale Lösung, denke ich. Für Clones wie die Firebee oder den Milan funktioniert das aber nicht mit dem F-TOS, da dasselbe eine spezielle Anpassung ist für das TOS der originalen Atari-Hardware? Aber eine solche Option im EMU-TOS wäre schon für mich ein Killerfeature und dann sowohl für Clones als auch für Originalhardware einsetztbar.
-
Aber eine solche Option im EMU-TOS wäre schon für mich ein Killerfeature und dann sowohl für Clones als auch für Originalhardware einsetztbar.
Da brauchst Du nicht drauf zu warten, ist schon drin. Das aktuelle Snapshot-Release kann's.
-
Da brauchst Du nicht drauf zu warten, ist schon drin. Das aktuelle Snapshot-Release kann's.
Sehr cool! Mappt EMU-TOS auch das Bootlaufwerk dann als "C:\"? Und unterstützt EMU-TOS ASCI und IDE-Laufwerke? Mein Setup wäre sonst folgendes: EMU-TOS auf Festplatte/SSD/CF-Karte etc. installieren, falls das möglich ist? Dann von dem entsprechenden Medium booten (mit dem installierten EMU-TOS) und wie in dem Screenshot die Partition des Mediums auswählen von der weiter gebootet werden soll (Auto-Ordner). Oder muss sich EMU-TOS zwangsläufig im ROM oder auf DIskette befinden zum Booten?
-
Bei mir ist das EmuTOS im 4. TOS Slot. Da ich den ST aber noch nicht vollständig installiert habe, kann ich nicht viel dazu sagen, aber die Tests liefen problemlos! Ich kann mich aber mit dessen Grundgrafik nicht sonderlich anfreunden, und habe (ich liebe die Iconvielfalt) noch keine Tests mit Opaque gemacht - wenn positiv, werde ich mich auf jeden Fall umfangreich damit beschäftigen!
-
Da brauchst Du nicht drauf zu warten, ist schon drin. Das aktuelle Snapshot-Release kann's.
Sehr cool! Mappt EMU-TOS auch das Bootlaufwerk dann als "C:\"?
Nein. Das Bootlaufwerk ist das, das Du beim Booten auswählst. Drückst Du z.B. auf E, wird der AUTO-Ordner und die Accessories von E: geladen. EMUTOS "weiss" dann, daß das das Bootlaufwerk ist und die Laufwerkszuordnung wird dadurch nicht verändert.
Und unterstützt EMU-TOS ASCI
ACSI. Ja
und IDE-Laufwerke?
Ja.
(und noch 'ne ganze Menge mehr).
Mein Setup wäre sonst folgendes: EMU-TOS auf Festplatte/SSD/CF-Karte etc. installieren, falls das möglich ist? Dann von dem entsprechenden Medium booten (mit dem installierten EMU-TOS) und wie in dem Screenshot die Partition des Mediums auswählen von der weiter gebootet werden soll (Auto-Ordner). Oder muss sich EMU-TOS zwangsläufig im ROM oder auf DIskette befinden zum Booten?
Du kannst die Variante "EMUTOS.PRG" dafür verwenden. Das wird von TOS gestartet und "ersetzt" das ROM TOS durch ein im RAM geladenes EMUTOS. Damit lässt sich das realisieren (natürlich mit weniger freiem RAM, als wie's wenn's im ROM wäre).
-
Bei mir ist das EmuTOS im 4. TOS Slot. Da ich den ST aber noch nicht vollständig installiert habe, kann ich nicht viel dazu sagen, aber die Tests liefen problemlos! Ich kann mich aber mit dessen Grundgrafik nicht sonderlich anfreunden, und habe (ich liebe die Iconvielfalt) noch keine Tests mit Opaque gemacht - wenn positiv, werde ich mich auf jeden Fall umfangreich damit beschäftigen!
Du hast aber noch die EmuTOS 0.9.4 von mir auf den Roms bekommen. Gibt aber eine neue Version, wo die Ganzen erläuterten Funktionen implementiert sind. Zu finden hier (https://sourceforge.net/projects/emutos/files/emutos/0.9.5/). es ist die 256Kb Variante, wo in die Roms dann geflasht werden. Danach, wenn du mit dem Mega ST auf die IDE zugreifen willst, lädste den Treiber von PP von diskette nach. Was deine Iconvielfalt angeht, naja weiß ich nicht, ist mir auch egal, jedenfalls funktioniert EmuTOS erste Sahne auf den ST's.
-
Danach, wenn du mit dem Mega ST auf die IDE zugreifen willst, lädste den Treiber von PP von diskette nach.
Sollte man EmuTOS nicht auch Autoboot von pp's IDE beibringen können? Mit Atari TOS geht's ja auch.
-
Danach, wenn du mit dem Mega ST auf die IDE zugreifen willst, lädste den Treiber von PP von diskette nach.
Sollte man EmuTOS nicht auch Autoboot von pp's IDE beibringen können? Mit Atari TOS geht's ja auch.
Das müsste es schon können. Allerdings nicht das "verdrehte" IDE-Interface, wer das haben will, muß selbst Hand anlegen (sollte aber kein Problem sein, da werden schon verrücktere Interfaces unterstützt).
Dafür braucht man keinen Harddisk-Treiber (der ist schon drin) und man kann - wenn man will - DOS-partitionierte Medien verwenden. Bei IDE-Geräten findet es selbst raus, ob es Byte-Swapping machen muss oder nicht.
-
Allerdings nicht das "verdrehte" IDE-Interface, wer das haben will, muß selbst Hand anlegen (sollte aber kein Problem sein, da werden schon verrücktere Interfaces unterstützt).
Letztlich war es eine Änderung von nur drei(!) Zeilen im Quelltext, um EmuTOS das "verdrehte" IDE-Interface von ppera beizubringen. Es erkennt jetzt die SD-Karte in meinem 1040STFM und deren erste drei Partitionen. Allerdings werde ich wohl mit EmuTOS trotzdem nicht glücklich: Erweiterte Partitionen (im MS-DOS-Format) werden wohl nicht unterstützt, sodass ich keinen Zugriff auf die weiteren Partitionen auf der SD-Karte habe. Ich bleibe bei (gepatchtem) Atari TOS + pperas Treiber + BigDOS.
Sowieso scheint EmuTOS' Festplattenunterstützung noch etwas hakelig zu sein: die ACSI-Laufwerke an meinem anderen Atari werden erst gar nicht gefunden.
-
Klasse @cietz. Schreib doch bitte den Macher von EmuTOS hierzu an. Ich glaube, dass wird ihn auch interessieren.
-
Funktioniert EmuTOS nicht zusammen mit BigDOS? Dann müsste das mit den erweiterten DOS-Partitionen doch klappen?
-
...Allerdings werde ich wohl mit EmuTOS trotzdem nicht glücklich: Erweiterte Partitionen (im MS-DOS-Format) werden wohl nicht unterstützt, sodass ich keinen Zugriff auf die weiteren Partitionen auf der SD-Karte habe.
Erweiterte MS-DOS-Partitionen werden tatsächlich nicht unterstützt. Du kannst allerdings mit HDDRIVER im Atari-Format partitionieren (und trotzdem auf den HDDRIVER-Treiber verzichten). Ubuntu kann solche Laufwerke problemlos mounten (mal davon ausgegangen, dass Du sowieso kein Windows benutzst, nachdem Du mehrere Partitionen auf der SD-Karte hast).
Sowieso scheint EmuTOS' Festplattenunterstützung noch etwas hakelig zu sein: die ACSI-Laufwerke an meinem anderen Atari werden erst gar nicht gefunden.
Das ist dann ein Fehler. Müsste eigentlich funktionieren (wurde bereits so getestet).
-
Erweiterte MS-DOS-Partitionen werden tatsächlich nicht unterstützt. Du kannst allerdings mit HDDRIVER im Atari-Format partitionieren (und trotzdem auf den HDDRIVER-Treiber verzichten).
Mein oben genanntes Setup (ohne EmuTOS) funktioniert ja einwandfrei. Ich denke, ich verzichte stattdessen einfach darauf, in den noch freien Slot meines Flash-TOS EmuTOS zu packen...
Sowieso scheint EmuTOS' Festplattenunterstützung noch etwas hakelig zu sein: die ACSI-Laufwerke an meinem anderen Atari werden erst gar nicht gefunden.
Das ist dann ein Fehler. Müsste eigentlich funktionieren (wurde bereits so getestet).
Tja. Ich werde zudem aus den Debug-Meldungen auf der seriellen Konsole in dem Fall nicht schlau. OK, eines meiner Laufwerke ist eine SH204, die ist ja bekanntlich etwas "speziell", aber auch die andere ACSI-Platte mit ICD-Hostadapter wird nicht gefunden. Oder vielmehr, an der LED und an den Debugmeldungen sehe ich, dass auf beiden Platten eine Lesezugriff stattfindet, aber das war's dann mehr oder weniger. Gehört aber ohnehin nicht in diesem Thread und mein Interesse an weiterer Bugsuche ist in diesem Fall auch eher gering.
-
...Allerdings werde ich wohl mit EmuTOS trotzdem nicht glücklich: Erweiterte Partitionen (im MS-DOS-Format) werden wohl nicht unterstützt, sodass ich keinen Zugriff auf die weiteren Partitionen auf der SD-Karte habe.
Erweiterte MS-DOS-Partitionen werden tatsächlich nicht unterstützt. Du kannst allerdings mit HDDRIVER im Atari-Format partitionieren (und trotzdem auf den HDDRIVER-Treiber verzichten). Ubuntu kann solche Laufwerke problemlos mounten (mal davon ausgegangen, dass Du sowieso kein Windows benutzst, nachdem Du mehrere Partitionen auf der SD-Karte hast).
Sowieso scheint EmuTOS' Festplattenunterstützung noch etwas hakelig zu sein: die ACSI-Laufwerke an meinem anderen Atari werden erst gar nicht gefunden.
Das ist dann ein Fehler. Müsste eigentlich funktionieren (wurde bereits so getestet).
Wenn Du sowieso HDDriver benutzt, bringt Dir BigDOS nichts mehr - die vertragen sich nämlich nicht (laut Aussage von Peter Putnik)! Wenn Du BigDOS anwenden willst, solltest Du schon seine Treiber anwenden! Dann kommst Du aber auch mit sehr großen Partitionen (2GB - ich habe eine) zurecht! Manko von den Treibern - oder BigDOS: es kommt nur entweder mit ACSI oder IDE zurecht! Abhilfe: HUSHI.PRG im AUTO-Ordner. Das verträgt sich scheinbar mit BigDOS in Verbindung mit IDE und ermöglicht den Zugriff auf die ACSI Schnittstelle. Allerdings - wenn das ACSI Gerät nicht eingeschaltet ist, meldet es Fehler bzww. Fehlfunktionen!
edit: Sorry - hatte Deinen Beitrag wieder mal nicht komplett gelesen - Du verzichtest ja wohl doch auf den HDDriver Treiber!
-
... aber auch die andere ACSI-Platte mit ICD-Hostadapter wird nicht gefunden. ...
Ich war gerade dabei, dazu was zu setzen ...
Ich hatte vor einiger Zeit das Problem, auf meine zum Kopieren auf SyQuest Scheiben abgelegten Daten (SCSI-Laufwerk) zuzugreifen - lest mal ab Post #53 (bei mir auf Seite 3 des Threads)!
-
Nochmal: Es funktioniert alles wunderbar. :) Ich habe weder vor, auf EmuTOS noch auf HDDRIVER umzusteigen. Für den 1040STFM mit IDE schrieb ich es ja gerade schon: "Ich bleibe bei (gepatchtem) Atari TOS + pperas Treiber + BigDOS." Der 1040STF mit ACSI-LWen tut ebenso problemlos seinen Dienst mit TOS und CBHD.
Don't touch a running system.
-
Doch, Bigdos ist auf jeden Fall empfehlenswert, denn es ersetzt das gesamte GEMDOS durch eine modernere Fassung, die MS-DOS partitionierte Laufwerke bis 2 GB lesen und schreiben kann. Vor allem bei Wechselplatten, CF- und SD-Karten, etc. nützlich. Nebenbei bringt es TOS 1.02 bis 3.06 bei, mit TOS-Partitionen mit 1 GB umzugehen. Und Kompatibllitätsprobleme (sprich dass irgendwelche Programme nicht mehr laufen) habe ich bisher damit auch nicht gehabt (Ausnahme: Programme, die selbst den freien Speicher ermitteln und dafür das falsche Datenformat verwenden und dann negative großen freien Speicher auf der Partition ermitteln, aber das kann auch schon mit 256 bzw. 512MB Partitionen passieren.). (Und bitte jetzt die Westerwälder Luft weg lassen!)
-
Das ist dann ein Fehler. Müsste eigentlich funktionieren (wurde bereits so getestet).
Nebenbei: Bug in EmuTOS gefunden und über deren Mailingliste berichtet. Mal sehen, wie das Feedback so ist. Was mich wundert, ist, dass das bisher überhaupt bei einem Test funktioniert hat.
-
Das ist dann ein Fehler. Müsste eigentlich funktionieren (wurde bereits so getestet).
Nebenbei: Bug in EmuTOS gefunden und über deren Mailingliste berichtet. Mal sehen, wie das Feedback so ist. Was mich wundert, ist, dass das bisher überhaupt bei einem Test funktioniert hat.
Perfekt! So funktioniert OpenSource und macht Spass. Danke im Namen des Teams.
-
Letztlich war es eine Änderung von nur drei(!) Zeilen im Quelltext, um EmuTOS das "verdrehte" IDE-Interface von ppera beizubringen. Es erkennt jetzt die SD-Karte in meinem 1040STFM und deren erste drei Partitionen.
FYI: Die genannten, von mir vorgenommenen Änderungen sind seit heute offizieller Teil von EmuTOS. Allerdings ist keine automatische Erkennung "verdrehter" IDE-Kabel eingebaut, sodass EmuTOS für solche IDE-Interfaces mit der passenden Einstellung neu compiliert werden muss.
-
FYI: Die genannten, von mir vorgenommenen Änderungen sind seit heute offizieller Teil von EmuTOS. Allerdings ist keine automatische Erkennung "verdrehter" IDE-Kabel eingebaut, sodass EmuTOS für solche IDE-Interfaces mit der passenden Einstellung neu compiliert werden muss.
Wo kann man das Compilat herbekommen bzw kann man per Emu compilieren und mit welcher Programmierumgebung (Sprache)?
Und wie verhält sich das veränderte EmuTOS im normalen Emubetrieb?
-
EmuTOS wird auf dem PC compiliert. Es ist in C und Assembler geschrieben, der offiziell unterstützte Compiler ist Vincent Rivières Version des gcc: http://vincent.riviere.free.fr/soft/m68k-atari-mint/ (http://vincent.riviere.free.fr/soft/m68k-atari-mint/).
Wenn Du auf "verdrehtes" IDE-Kabel umkonfigurierst, funktionieren "normale" IDE-Kabel nicht mehr und umgekehrt. Davon abgesehen ändert sich durch die Modifikation nichts an EmuTOS.
-
EmuTOS wird auf dem PC compiliert. Es ist in C und Assembler geschrieben, der offiziell unterstützte Compiler ist Vincent Rivières Version des gcc: http://vincent.riviere.free.fr/soft/m68k-atari-mint/ (http://vincent.riviere.free.fr/soft/m68k-atari-mint/).
Wenn Du auf "verdrehtes" IDE-Kabel umkonfigurierst, funktionieren "normale" IDE-Kabel nicht mehr und umgekehrt. Davon abgesehen ändert sich durch die Modifikation nichts an EmuTOS.
Du weißt schon, daß dieser Thread von mir bezüglich eines meiner Mega ST4 begonnen wurde und ich irgendwo anfangs auch erwähnt habe, daß ein verdrehtes IDE Kabel erwähnt wurde?
-
Du weißt schon, daß dieser Thread von mir bezüglich eines meiner Mega ST4 begonnen wurde und ich irgendwo anfangs auch erwähnt habe, daß ein verdrehtes IDE Kabel erwähnt wurde?
Und? Was willst Du mir damit sagen? Ich weiß, dass Du ein verdrehtes IDE-Kabel einsetzt, daher ja (auch) an Dich der Hinweis, dass das dank mir von EmuTOS seit heute unterstützt wird.
Aber Du hast ebenfalls gefragt: "Und wie verhält sich das veränderte EmuTOS im normalen Emubetrieb?" und mein voriges Posting enthält die Antwort darauf.
-
Und? Was willst Du mir damit sagen? Ich weiß, dass Du ein verdrehtes IDE-Kabel einsetzt, daher ja (auch) an Dich der Hinweis, dass das dank mir von EmuTOS seit heute unterstützt wird.
Aber Du hast ebenfalls gefragt: "Und wie verhält sich das veränderte EmuTOS im normalen Emubetrieb?" und mein voriges Posting enthält die Antwort darauf.
Ich habe zwar von Anfang an ausgedrückt, daß ich kaum am EmuTOS interessiert bin, aber es ist nunmal ein Teil des von @neogain umgebauten Rechner und die überwiegend positiven Meinungen darüber erwecken in mir doch den Wunsch, wenn auch Stiefmütterlich, möchte ich mich doch mal damit befassen, wenn der Rechner (zZ wegen anderer Pflichten zurückgestellt und noch nicht ganz aus der Einrichtungsphase) im richtigen "Einsatz" ist!
Ich wollte mit dem letzten Posting auch nur zum Ausdruck bringen, daß es eben um einen entsprechenden ST geht und die von Dir angepaßte Version geradezu prädestiniert ist ...
Für mich wäre es aber wünschenswert, eine fertig compilierte Version verfügbar gemacht zu bekommen - könntest Du es nicht vielleicht auf Deiner Homepage verfügbar machen?
-
Hier: EmuTOS Snapshot 20160530 für IDE-Interfaces mit verdrehtem Kabel, 256kByte-Version zum Flashen ins ROM, deutsche Tastaturbelegung.
Allerdings ist EmuTOS ist ständiger Entwicklung und ich werde sicherlich nicht alle paar Tage eine neue Version compilieren.
-
Im anderen Forum habe ich gelesen das der Snapshot auch das Altram der MonSTer ohne externen Treiber unterstützt ...
-
Im anderen Forum habe ich gelesen das der Snapshot auch das Altram der MonSTer ohne externen Treiber unterstützt ...
Ja, das ist richtig. Der entsprechende Code ist in dem von mir geposteten Image auch aktiviert.
-
Also ein (http://previews.123rf.com/images/yayayoy/yayayoy1011/yayayoy101100007/8127893-Smiley-Thumb-up-Herz-Lizenzfreie-Bilder.jpg)lichstes (http://www.forum64.de/wbb4/wcf/images/smilies/danke.gif) an @czietz für seinen Einsatz und für das Bereitstellen der Image-Datei!
Habe sie mir auch gleich "gezogen" und auf Diskette (und am PC) gesichert!
edit:Übrigens habe ich auch nicht vor, alle paar Wochen eine überarbeitete Version in den Flashslot zu schieben!
-
Ich warte bis die 0.97 kommt ...
-
Im anderen Forum habe ich gelesen das der Snapshot auch das Altram der MonSTer ohne externen Treiber unterstützt ...
Ja, das ist richtig. Der entsprechende Code ist in dem von mir geposteten Image auch aktiviert.
Spannend. Wenn ich jetzt noch wüßte, wie ich das originale GEM-"Theme" EmuTOS beibringe … ich finde, ähem, den neuen Look eher häßlich, vor allem der Mauszeiger mit Schwindsucht …
(das ist jetzt dann aber doch off-topic, wie verschieb ich das denn jetzt?)
-
Spannend. Wenn ich jetzt noch wüßte, wie ich das originale GEM-"Theme" EmuTOS beibringe … ich finde, ähem, den neuen Look eher häßlich, vor allem der Mauszeiger mit Schwindsucht …
(das ist jetzt dann aber doch off-topic, wie verschieb ich das denn jetzt?)
Warum meinst Du das? Hier geht's doch in letzter Zeit nur noch um das EmuTOS und ...
Aber wie dem auch sei, mich stört nicht das komplette Theme, sondern eigentlich nur die verwendeten Ikone, die wohl zwar eine Unterscheidung der Objektarten zulassen, aber für mich nicht gerade die passende Art darstellt - außerdem die verfügbare Anzahl, da ich die Iconvielfalt liebe!
Opaque scheint nicht zu laufen - oder das war auch nur ein Emulatorproblem!
-
Ach. Ihr seid auch alle Gewohnheitstiere. ;D Ich mag das Theme. Ist etwas anderes und hat was. Der Grund für das "Theme", das EmuTOS verwendet, liegt darin, dass das GEM in EmuTOS nicht auf der verwendeten Version des TOS basiert, das Digital Research für Atari ursprünglich entwickelte und dann von Atari selbst weiterentwickelt wurde. Die Macher von EmuTOS konnten diese Grundlage aus rechtlichen Gründen nicht verwenden so viel ich weiß. Also hat man auf die Sourcen von GEM zurückgegriffen, die frei verfügbar sind und diese für das EmuTOS angepasst und neu compiliert. OpenGEM für den PC basiert auf denselben Sourcen und wenn man die beiden Themes vergleicht (also dasjenige des EmuTOS und OpenGEM), dann wird man schnell bemerken, dass diese beiden sich sehr ähneln. ;)
Wie sieht's denn aus mit der Unterstützung von deskicon.rsc-Dateien seitens EmuTOS? Vielleicht geht da ja noch was. Infolgedessen könnte dann jeder sein eigenes Theme verwenden. 8)
-
Wie sieht's denn aus mit der Unterstützung von deskicon.rsc-Dateien seitens EmuTOS? Vielleicht geht da ja noch was. Infolgedessen könnte dann jeder sein eigenes Theme verwenden. 8)
Auf jeden Fall wird keine Datei mit solchem Namen nachgeladen bzw. deren Inhalt erkennbar verarbeitet!
-
EmuTOS ist halt kein TOS 2.06. Da ist nichts mit Icons und Programme auf dem Desktop ablegen ist auch nicht ...
-
EmuTOS ist halt kein TOS 2.06. Da ist nichts mit Icons und Programme auf dem Desktop ablegen ist auch nicht ...
Ein Feature, welches ich nur noch ungern missen würde.
-
... Da ist nichts mit Icons und Programme auf dem Desktop ablegen ist auch nicht ...
Also doch ein Rückschritt in Richtung TOS 1. (0)x! Zu dessen Zeiten hatte sich aber doch jeder nach mehr Komfort gesehnt, was erst die Entwickler von TOS 2. (0)6 auf den Plan rief bzw wachrüttelte!
-
Also doch ein Rückschritt in Richtung TOS 1. (0)x! Zu dessen Zeiten hatte sich aber doch jeder nach mehr Komfort gesehnt, was erst die Entwickler von TOS 2. (0)6 auf den Plan rief bzw wachrüttelte!
Ihr müsst bedenken, das EmuTOS praktisch von Grund auf neu gemacht werden musste. Es ist auch ein Hobby- und Freizeitprojekt. Sicherlich ist vieles wünschenswert und erstrebenswert, aber ob das in der Realität so machbar ist, ist oft eine andere Sache. EmuTOS ist auch nicht als neues TOS 5 gedacht sondern als TOS für Emulatoren und echte Atarihardware und lehnt sich wohl infolgedessen an TOS 1.(0)x an. Aber die Entwicklung soll weitergehen man kann dem Entwickler ja entsprechende Vorschläge unterbreiten. ;D
-
Statt nur Wünsche zu äußern oder sich zu beschweren, was alles nicht geht, kann man übrigens auch selbst aktiv werden. Das ist bei Open Source Software ja ausdrücklich erwünscht und aus eigener Erfahrung kann ich sagen, dass EmuTOS ein angenehmes Projekt für die Mitarbeit ist.
"Aber ich kann gar nicht programmieren", ist übrigens auch keine gültige Ausrede. Für so etwas wie Artwork (Icons, Mauscursor etc.) braucht man keine Programmierkenntnisse. Der jeweilige Freiwillige sollte das vorher auf der Mailingliste ansprechen, aber ich kann mir vorstellen, dass es gegen verbesserte Icons keinen Widerspruch gibt.
-
Oder statt zu jammern, Gemini, Ease, Thing oder einen anderen alternativen Desktop starten...
-
Iconset aus os7 mopsen und einfügen XD
-
Wie sieht's denn aus mit der Unterstützung von deskicon.rsc-Dateien seitens EmuTOS? Vielleicht geht da ja noch was. Infolgedessen könnte dann jeder sein eigenes Theme verwenden. 8)
Die Icons sind weniger mein Problem, als das Aussehen der Buttons, des Mauszeigers und der Menüs. Ich finde den originalen Atari-GEM-Look deutlich ausgewogener und stimmiger.
-
Statt nur Wünsche zu äußern oder sich zu beschweren, was alles nicht geht, kann man übrigens auch selbst aktiv werden. Das ist bei Open Source Software ja ausdrücklich erwünscht und aus eigener Erfahrung kann ich sagen, dass EmuTOS ein angenehmes Projekt für die Mitarbeit ist.
"Aber ich kann gar nicht programmieren", ist übrigens auch keine gültige Ausrede. Für so etwas wie Artwork (Icons, Mauscursor etc.) braucht man keine Programmierkenntnisse. Der jeweilige Freiwillige sollte das vorher auf der Mailingliste ansprechen, aber ich kann mir vorstellen, dass es gegen verbesserte Icons keinen Widerspruch gibt.
Das rechtliche Problem ist zwar ein theoretisches, aber eigentlich dürften Patches für den alten Atari-Look ja eben nicht in den OpenSource-Zweig aufgenommen werden. Drum meine Frage, ob es ein nachladbares Theme o.ä. gibt, womit man typischerweise das Problem entschärfen oder umgehen kann.
-
Oder statt zu jammern, Gemini, Ease, Thing oder einen anderen alternativen Desktop starten...
Äh. Ich jammere nicht. Ich stellte eine Frage. Und Gemini, Thing und sonstwas ändern ja nichts am Aussehen der Menüs oder des Mauszeigers.
Macht aber auch nichts.
-
Naja - so ganz verstehe ich eigentlich nicht, warum man nicht um die Themes der ursprünglichen Atari TOSse hätte programmieren dürfen - andererseits finde ich auch gut, daß man schon mit dem ersten Blick das EmuTOS gut vom Atari TOS unterscheiden kann, aber hätte man das nicht trotzdem ein bißchen ansprechender gestalten können? Hier mal der Desktop aus (frühen) TOS 2.(0)6 Zeiten von mir - leider hatte ich damals keinen Weg gefunden, die Laufwerkbuchstaben passend zu platzieren, das hatte erst sehr viel später mit @ardi's Resource Master geklappt:
(http://forum.atari-home.de/gallery/2630_13_06_12_11_42_43.gif)
(die Icons stammen größten Teils aus meiner Opaque-Sammlung, mit denen ich nach und nach meine DESKICON.RSC bestückte)
Ich hatte sogar mal (über Umwege) geschafft, dem TOS 1.(0)4 (Image) verschiedene Icos aus dieser Sammlung zu patchen (Das Laufwerksymbol mit der Schublade, das hier das Drive "O:" versinnbildlicht - mein CD-ROM) kam als Laufwerksymbol zum Einsatz, das aufgeschlagene Buch als Programm Icon und der NeoDesk Mülleimer als Mülleimer. Daneben habe ich noch das "beschriebene" Blatt mit Hand, die einen Schreibgriffel führt, das man in Iconsammlungen gerne für 1stWord Dokumente verwendet hatte, als Dateiicon verwendet. Leider hatte aber die Vorgehensweise, wie ich das damals beim TOS 1.(0)4 anwendete, beim EmuTOS nicht geklappt.
-
aber hätte man das nicht trotzdem ein bißchen ansprechender gestalten können?
Man kann das ja immer noch "ein bißchen ansprechender gestalten". So ein Projekt lebt von der Mitarbeit Freiwilliger, die z.B. Mauscursor und Icons erschaffen, die keine eins-zu-eins Kopie von Atari TOS sind und schön aussehen. Also: Ran an das Zeichenprogramm...
-
Wenn's einem missfällt und man selbst aber nicht gewillt ist den Missstand (die Schreibeweise kommt mir auch als ein solcher vor) abzustellen, dann kann der Schmerz darüber nicht allzu groß sein. >:D
Ich finde den Look und Feel des EmuTOS echt nicht schlecht und ich sehe für mich echt keinen Grund, dass man den ändern müsste. Freiwillige vor! Die Idee der Auswahl eines Themes oder der Möglichkeit, ein eigenes Theme nachzuladen, halte ich aber für sehr gut. Schlecht wäre nur eine Lösung, wenn man ein neues Theme einführte und dann sind wieder einige am Quaken, weil's ihnen nicht gefällt. >:( So wäre einem zumindest der Grund genommen rumzuzicken, denke ich. ;D
-
Der Mauszeiger ist (mir) ja egal! Aber auf 8x8 Pixeln läßt sich auch nicht viel erzeugen, daß das Gleiche darstellen kann! Für mich sehen zumindest die Hauptpfeile zwischen Atari TOS, Mac OS und Kickstart (oder wie das grundsätzliche Amiga OS heißt) gleich aus!
Nachdem ich mir damals ein bißchen die Zähne ausgebissen hatte, meine Wunschicons einzubauen, hatte ich die an das Entwicklerteam weiter vermittelt, aber die waren nicht darauf eingegangen!
-
Was EmuTOS fehlt ist die Möglichkeit Programme/Dateien auf dem Desktop abzulegen und dann eine deskicon.rsc nachzuladen ...
-
Komischerweise ist es aber ein 256k TOS - wie das 2. (0)6er, bei dem das integriert ist!
-
Liegt vielleicht daran das EmuTOS und TOS 1.04 beide die AES Version 1.40 haben ...
-
Komischerweise ist es aber ein 256k TOS - wie das 2. (0)6er, bei dem das integriert ist!
Vermutlich weil du das große genommen hast... aber wie hier schon angesprochen wurde, macht das doch als Vorschläge die EmuTOS Entwickler sind sehr Aktiv und setzen Vorschläge in der Regel auch um.
Bezüglich der Desktop Icons denke ich könnte man schon ins build einbauen wenn sich jemand hinsetzt und ansprechende Icons Bastelt dann kann man die ja auch einbauen.
Hier ist findet man die Datein für die icons
https://sourceforge.net/p/emutos/code/ci/master/tree/desk/ (https://sourceforge.net/p/emutos/code/ci/master/tree/desk/)
-
@tuxie
Du irrst! Das "Große" hat 512k! Mir sind nur diese beiden Größen bekannt und die von @czietz angepaßte und einige Posts wo. verfügbar gemachte ist eben die Kleinere!
-
Ach echt ?
emutos-192k-20160530.zip
https://sourceforge.net/projects/emutos/files/snapshots/20160530/
Auszug aus der Readme
EmuTOS - 192 KB versions
These ROMs are suitable for the following hardware:
- ST / STf
- Mega ST
- emulators of the above
-
tuxie hat Recht. Es muss auch immer möglich sein, eine EmuTOS-Version in 192 kByte compiliert zu bekommen, ggf. unter Abschaltung optionaler Features. (So ist IDE-Unterstützung afaik erst ab der 256-kByte-Version enthalten.)
Und 192 kByte sind echt eng, da wird fast um jedes Byte Platzeinsparung gerungen.
-
Sorry bitte! Aber seit ich mich mit dem EmuTOS doch etwas stärker befasse, habe ich nur eine Download-Seite gefunden, über die die 256er und und die 512er Versionen zum Download angeboten wurden und daher bin ich davon ausgegangen, daß es eben nur diese Versionen gibt! Als bitte nochmals um Entschuldigung, daß ich hier aufgrund erlangter Fehlinfos selber fehlerhafte Infos weitergab!
-
Kein ding sowas hab ich mir schon gedacht... deswegen hab ich den Link gepostet.
-
Hallo Leute - ich muß hier mal weitermachen! Da meine Tests mit der GOTEK bislang nicht zum gewünschten Erfolg führten, habe ich mich erstmal mit weitere Einrichtungsarbeiten meines Mega ST4+ beschäftigt. Dabei sind neue Fragen aufgekommen:
- bezüglich EmuTOS:
Da hier zuletzt darüber recht positiv debattiert wurde, will ich mich doch auch ein bißchen stärker damit befassen, aber ich würde gerne das aussehen für mich ansprechender umgestalten lassen, da ich nicht selbst programmieren kann!
- bezüglich TOS 2.(0)6:
Beim Start erscheint erst einmal "Bad ... in ROM ...", es läßt sich aber im Desktop anstandslos arbeiten ohne erkennbaren Fehler! Mir waren solche Probleme bei Anwendung von SWE-Patch aufgefallen, wenn ich ein damit erstelltes TOS.IMG im STeEm testete - dann aber für beide ROMs! Worauf deutet das hin?
- bezüglich MagiC - Frage speziell an @neogain :
Mir ist aufgefallen, daß MagiC nach Wahl der betreffenden Bootpartition immer noch nicht einwandfrei startet - ich gehe davon aus, daß ich den Treiber noch nicht auf den czietz-Patch aktualisierte! Kann ich einfach einen der von ihm gepatchten Ppera Treiberinstaller starten, um den Treiber auf der CF zu aktualisieren oder hattest Du anschließend Startschwierigkeiten und mußtest alles neu einrichten?
-
Wegen dem TOS 2.06, das scheint nicht richtig gepatcht zu sein wegen dem CRC Fehler beim booten. Wieso musst du das denn überhaupt patchen ?
-
Wegen dem TOS 2.06, das scheint nicht richtig gepatcht zu sein wegen dem CRC Fehler beim booten. Wieso musst du das denn überhaupt patchen ?
Ich habe noch kein eigenes Flashing vorgenommen und das Flash-TOS so vorliegen, wie @neogain es mir einrichtete - daher kann ich nicht sagen, ob hier überhapt ein gepatchtes TOS oder das oTOS 2.(0)6 vorliegt!
-
Wegen dem TOS 2.06, das scheint nicht richtig gepatcht zu sein wegen dem CRC Fehler beim booten. Wieso musst du das denn überhaupt patchen ?
Ich habe noch kein eigenes Flashing vorgenommen und das Flash-TOS so vorliegen, wie @neogain es mir einrichtete - daher kann ich nicht sagen, ob hier überhapt ein gepatchtes TOS oder das oTOS 2.(0)6 vorliegt!
Du hast schon das gepatchte TOS2.06, sowie Magic drauf. Der Prüfsummenfehler hängt einfach damit zusammen, weil das TOS gepatcht ist und ich hier nicht die Prüfsumme gefixt hatte. Kannste aber nachholen mit dem Romsplit (http://atari.8bitchip.info/ROMSPLIT.ZIP). @czietz hat hier (http://forum.atari-home.de/index.php?topic=12577.msg202367#msg202367) die Treiber angepasst, damit man von MagiC booten kannst. Also nehmen und drüberkopieren, dann kannst du auch in MagiC booten. Inzwischen habe ich die TOSe komplett anders gestrickt bei meinen STs, du hast halt das Interface von mir bekommen, wo ich noch selber am rumbasteln war. Kannst aber alles umflashen nach belieben.
-
Vor ein paar Tagen habe ich jetzt den Treiber mit dem Patch von @czietz aktualisiert - und MagiC startet trotzdem nicht (Fehlerausgabe siehe Anhang)
Erst dachte ich, ich habe einen Fehler bei der Treiber Installation gemacht und habe es gerade eben noch einmal vollzogen - aber man kann eigentlich keinen Fehler machen: "I"(nstall) oder "S"(ave to Disc) - oder andere Tasten zum Abbruch!
Meine Bootpartition für MagiC ist "K:", ich drücke also bei der entsprechenden Anzeige die Taste <K>, damit diese Partition zu "C:" wird und MagiC das korrekte Drive als Bootdrive hat und dort seine Dateien findet, die ich über TOS 2.(0)6 auf deise Partition kopiert habe!
Alle anderen TOSse starten anscheinend korrekt ...
Worauf deutet der Fehler hin - wurden evtl. die MagiC-Dateien fürs Root nicht richtig auf die Festplatte kopiert?
edit: installiert habe ich die Treiberversion IDEP_98B (AUDU98B.PRG)!
-
Das sieht so aus, als hättest Du eben nicht den gepatchten Treiber installiert. Du hast wirklich das Programm aus idefix.zip(.pdf) genommen, das als Anhang an meinem von neogain verlinkten Posting hängt?
Leider hast Du auf Deinem Screenshot just die spannende Zeile weggeschnitten. Welche Versionsnummer taucht in der Zeile "IDE driver V[...]" auf?
-
TW IDE harddisk driver for DOS part's
V0.98ß P.Putnik, 2010. Use with BIGDOS !
Press F1 or Help for HELP
ST , TOS 6.0P , 4 MB
...
Partitions :10
...... und ich habe die Treiberdownloads genommen, die ich auf dem Thread gezogen habe, wo Du den Hinweis auf den Patch gegeben und diese eben zum Download verfügbar gemacht hast!
-
TW IDE harddisk driver for DOS part's
V0.98ß P.Putnik, 2010. Use with BIGDOS !
... und das ist die ungepatchte Version, die Du da installiert hast. Andernfalls stünde dort V0.98p.
Daher wiederhole ich meine Frage: Du hast wirklich das Programm aus idefix.zip(.pdf) genommen, das als Anhang an meinem von neogain verlinkten Posting hängt?
-
Die aus diesem Thread (http://forum.atari-home.de/index.php?topic=12577.msg202367#msg202367) meinst Du doch? Ja - die habe ich genommen - entweder hat er jetzt nicht korrekt den alten Treiber gelöscht und der alte Treber bootet noch! Anders kann ich mir das jetzt nicht vorstellen! Also - ich lade mir die aktuell noch mal runter und versuche nochmals das Darüber installieren - ansonsten, wenn es wieder schiefgeht, muß ich mir am PC das Drive C nochmal komplett löschen und dann am Atari neu einrichten - oder habt ihr für letzteren Fall noch 'ne andere Idee, die nicht so zeitaufwendig wäre?
-
Ja, den Thread meine ich. Und dort eben den Anhang:
* idefix.zip.pdf (17.26 KB - runtergeladen 25 Mal.)
... und nicht die ebenfalls im Thread verlinkten Originaldateien (IDEDUD91.ZIP und IDEP_98B.ZIP).
-
Oje - der Fehler liegt wohl bei mir wieder im Detail - ich habe wohl "nur" die Komplettarchive unter den Links gezogen! Danke für den Hinwes, ich kopiere die also nochmal auf meine Installationsdisk!
-
Jetzt habe ich mit dem gepatchten Treiber Installer den Treiber installiert und die Fehlerausgabe bei MagiC bleibt aus - aber es kommt immer noch kein Desktop! Auf der entsprechenden Partition (K: - wird nach Wahl zu C:) sind die Dateien für MagiC Root vorhanden!
Was läuft hier noch verkehrt?
Bei der RAM Version von MagiC war mal dokumentiert, daß MagiC einen AUTO-Ordner nicht weiter abarbeitet, weshalb der Starter auch als Letztes in den AUTO Ordner soll. Weil ich aber einen anderen Namen für die Einrichtung der Automatisch zu startenden Programme nicht kenne, habe ich hierfür auch einen "AUTO" Ordner angelegt!
-
Bei der RAM Version von MagiC war mal dokumentiert, daß MagiC einen AUTO-Ordner nicht weiter abarbeitet, weshalb der Starter auch als Letztes in den AUTO Ordner soll.
Wenn du mit "RAM-Version" das ganz normal installierte MagiC meinst -- dann ist das praktisch falsch. Wird der MagiC-Starter im Auto-Ordner ausgeführt, nach einem normalen ROM-TOS-Coldreset, dann installiert es den MagiC-Kernel und führt einen Reset aus. Nach dem Reset überspringt sich der MagiC-Auto-Starter dann und der AUTO-Ordner wird normal ausgeführt.
Auf den ersten Blick bzw. Coldreset-Boot sieht es also so aus, als ob nach dem MagiC-Lader nix mehr vom AUTO-Ordner ausgeführt wird. Auf den zweiten, bzw. MagiC-Boot, nicht mehr.
-
Du hast doch MagiC im Rom, brauchst du den MagiC Loader im Autoordner überhaupt ?
Bei meiner normalen Festplatten MagiC Installation ist der Loader das erste Programm im Autoordner ...
-
@Burkhard Mankel, siehe Anhang...
-
Burkhard Mankel, siehe Anhang...
Ja, das habe ich auf betreffendem Laufwerk - dh. den Inhalt von TO_C_ROOT direkt auf meine Partition "K:" kopiert!
Auf der entsprechenden Partition (K: - wird nach Wahl zu C:) sind die Dateien für MagiC Root vorhanden!
Du hast doch MagiC im Rom, brauchst du den MagiC Loader im Autoordner überhaupt ?
Bei meiner normalen Festplatten MagiC Installation ist der Loader das erste Programm im Autoordner ...
Ich habe doch gar nicht behauptet, daß ich den Loader aus dem AUTO Ordner starte bzw. noch dort habe!
Übrigens habe ich auch geschrieben, daß er dukumentierter Weise als eines der letzten PRGs in den AUTO Ordner soll!
-
Übrigens habe ich auch geschrieben, daß er dukumentierter Weise als eines der letzten PRGs in den AUTO Ordner soll!
Hast du da mal die Quelle? Das ergäbe nämlich IMHO überhaupt keinen Sinn …
-
Übrigens habe ich auch geschrieben, daß er dukumentierter Weise als eines der letzten PRGs in den AUTO Ordner soll!
Jetzt stellt sich die Frage wo ist das dokumentiert und was ist mit "als eines der der letzten PRGs" gemeint?
Im Handbuch zur Version 2 und 5 steht drin, es soll möglichst als erstes im AUTO-Ordner stehen, damit das Booten bei einem Kaltstart nicht zu lange dauert.
-
Übrigens habe ich auch geschrieben, daß er dukumentierter Weise als eines der letzten PRGs in den AUTO Ordner soll!
Jetzt stellt sich die Frage wo ist das dokumentiert und was ist mit "als eines der der letzten PRGs" gemeint?
Im Handbuch zur Version 2 und 5 steht drin, es soll möglichst als erstes im AUTO-Ordner stehen, damit das Booten bei einem Kaltstart nicht zu lange dauert.
ich weiß immer noch nicht, was das Problem von Burkhard ist. Auf die 4GB CF, wo ich ihm damals partitioniert und befüllt habe, war auch die MagiC Installation drauf. Den veränderten Treiber von @czietz hat er auch drauf, auf einer Partition auch die Sachen, die für MagiC relevant sind (sofern er die letzte Zip hier entpackt auf die Partition geschrieben hat), somit müsste es eigentlich starten.
-
ich weiß immer noch nicht, was das Problem von Burkhard ist. Auf die 4GB CF, wo ich ihm damals partitioniert und befüllt habe, war auch die MagiC Installation drauf. Den veränderten Treiber von @czietz hat er auch drauf, auf einer Partition auch die Sachen, die für MagiC relevant sind (sofern er die letzte Zip hier entpackt auf die Partition geschrieben hat), somit müsste es eigentlich starten.
Die CF Karte hatte ich mir doch neu organisiert (allerdings nicht ohne mir die Proggies Deiner Installation zu sichern), da Deine Vorinstallation nicht unbedingt meinen Verstellungen entsprach! Das war aber im Thread und per PNs zwischen uns schon besprochen worden!
Wenn ich nun MagiC starte, bleibt das System bei der Anzeige zur Bootlaufwerkwahl stehen, allerdings - dank gepatchten Treiber - ohne die Ausgabe "... Speicherblock durch Benutzerprogramm zerstört ..."! Für mich deutet das darauf hin, daß entweder noch was auf dem betreffenden Bootlaufwerk fehlt oder daß was mit der Bootlaufwerkwahl nicht für MagiC nicht korrekt läuft (denkbar, denn man sieht ja direkt beim Start eine kleine Animation - in der die benötigten Dateien gesucht werden könnten - und erst danach kommt die Wahl des Bootlaufwerks)!
-
ich weiß immer noch nicht, was das Problem von Burkhard ist. Auf die 4GB CF, wo ich ihm damals partitioniert und befüllt habe, war auch die MagiC Installation drauf. Den veränderten Treiber von @czietz hat er auch drauf, auf einer Partition auch die Sachen, die für MagiC relevant sind (sofern er die letzte Zip hier entpackt auf die Partition geschrieben hat), somit müsste es eigentlich starten.
Die CF Karte hatte ich mir doch neu organisiert (allerdings nicht ohne mir die Proggies Deiner Installation zu sichern), da Deine Vorinstallation nicht unbedingt meinen Verstellungen entsprach! Das war aber im Thread und per PNs zwischen uns schon besprochen worden!
Wenn ich nun MagiC starte, bleibt das System bei der Anzeige zur Bootlaufwerkwahl stehen, allerdings - dank gepatchten Treiber - ohne die Ausgabe "... Speicherblock durch Benutzerprogramm zerstört ..."! Für mich deutet das darauf hin, daß entweder noch was auf dem betreffenden Bootlaufwerk fehlt oder daß was mit der Bootlaufwerkwahl nicht für MagiC nicht korrekt läuft (denkbar, denn man sieht ja direkt beim Start eine kleine Animation - in der die benötigten Dateien gesucht werden könnten - und erst danach kommt die Wahl des Bootlaufwerks)!
Dann kommen wir der Sache schon näher. Wie groß ist deine Partition "K" mit den Magic Files? nimm mal eine Partition <100MB und schieb das dann da drauf. Wie ich deine CF eingerichtet habe, habe ich schon bewusst 4 Partitionen am Anfang mit jeweils <100MB Partitionen für die einzelnen Gegebenheiten eingerichtet.
-
Dann kommen wir der Sache schon näher. Wie groß ist deine Partition "K" mit den Magic Files? nimm mal eine Partition <100MB und schieb das dann da drauf. Wie ich deine CF eingerichtet habe, habe ich schon bewusst 4 Partitionen am Anfang mit jeweils <100MB Partitionen für die einzelnen Gegebenheiten eingerichtet.
Daran liegt es wohl doch nicht - ich habe das Bootdrive für EmuTOS ("L:" - 40MB) noch nicht eingerichtet und folglich leer! Dorthin die Rootfiles für Magic kopiert und ... Desktop erscheint trotzdem nicht!
-
Dann kommen wir der Sache schon näher. Wie groß ist deine Partition "K" mit den Magic Files? nimm mal eine Partition <100MB und schieb das dann da drauf. Wie ich deine CF eingerichtet habe, habe ich schon bewusst 4 Partitionen am Anfang mit jeweils <100MB Partitionen für die einzelnen Gegebenheiten eingerichtet.
Daran liegt es wohl doch nicht - ich habe das Bootdrive für EmuTOS ("L:" - 40MB) noch nicht eingerichtet und folglich leer! Dorthin die Rootfiles für Magic kopiert und ... Desktop erscheint trotzdem nicht!
Ich habe oben in Pascals Antwort noch eine Stelle hervorgehoben. Kann es vielleicht sein, dass Magic nicht damit klarkommt, wenn seine Bootdateien irgendwo weit hinten auf der SD-Karte sind? (Laufwerk K: oder L: sind ja wohl weit hinten.)
@Burkhard Mankel : Kommt denn überhaupt eine (Fehler-)Meldung oder gar nichts?
-
Dann kommen wir der Sache schon näher. Wie groß ist deine Partition "K" mit den Magic Files? nimm mal eine Partition <100MB und schieb das dann da drauf. Wie ich deine CF eingerichtet habe, habe ich schon bewusst 4 Partitionen am Anfang mit jeweils <100MB Partitionen für die einzelnen Gegebenheiten eingerichtet.
Daran liegt es wohl doch nicht - ich habe das Bootdrive für EmuTOS ("L:" - 40MB) noch nicht eingerichtet und folglich leer! Dorthin die Rootfiles für Magic kopiert und ... Desktop erscheint trotzdem nicht!
Ich habe oben in Pascals Antwort noch eine Stelle hervorgehoben. Kann es vielleicht sein, dass Magic nicht damit klarkommt, wenn seine Bootdateien irgendwo weit hinten auf der SD-Karte sind? (Laufwerk K: oder L: sind ja wohl weit hinten.)
@Burkhard Mankel : Kommt denn überhaupt eine (Fehler-)Meldung oder gar nichts?
Genau darauf wollte ich ja raus @czietz. deswegen habe ich ihm die CF damals so Partitioniert, dass am Anfang 3 primäre Partitionen vorhanden sind, der Rest die erweiterte mit den logischen Partitionen. Wenn ich die Magic Files auf den logischen Partitionen habe, sehe ich auch keine Fehlermeldung und der Desktop ladet nicht. Das Burkhard jetzt keine Fehlermeldung mehr hat, deutet drauf hin, dass der deinen gepatchten Treiber genommen hat, aber trotzdem die Files für den Magic Desktop nicht geladen werden.
*klugscheißmodusan*
noch ein kleiner Auszug aus elektronik-kompendium:
Erweiterte Partition
Muss eine Festplatte in mehr als 4 Partitionen unterteilt werden, dann kann eine zusätzliche erweiterte Partition pro physikalisches Laufwerk eingerichtet werden. Die erweiterte Partition ist nicht bootfähig. Sie kann allerdings in kleinere logische Partitionen unterteilt werden.
*klugscheißmodusaus*
nicht böse nehmen, Burkhard ;)
-
Dann halt als kleiner Test mal die MagiC Files auf C:\ legen ...
-
Kann es vielleicht sein, dass Magic nicht damit klarkommt, wenn seine Bootdateien irgendwo weit hinten auf der SD-Karte sind? (Laufwerk K: oder L: sind ja wohl weit hinten.)
Naja - wenn das natürlich der Fall wäre? Dann wird es Zeit, was anderes zu überlegen:
Da ich gerne meine Partitionszuordnungen "D:" bis "H:" beibehalten würde - mit 40MB hat die Partiton 1 (also was offiziell "C:" ist) für das, was MagiC und TOS benötigen für den Start benötigen! Ich kann mir jetzt auch kein Problem vorstellen, was bestehen könnte, wenn sich MagiC un TOS 2.(0)6 die erste Partition als Bootdrive teilen - ich teste das mal, aber erst morgen!
Burkhard Mankel : Kommt denn überhaupt eine (Fehler-)Meldung oder gar nichts?
Nein - kein Fehler! Beim Booten unter MagiC sieht man erst den Bildschirm mit der Animation und dann wird der Bildschirmgelöscht und es kommen nacheinander die Infos für den Treiber und TOS und dann die vorhandenen Partitionen, unter denen das Bootdrive gewählt werden kann. Beim ungepatchten Treiber kam dann nach Wahl des Laufwerks der Fehler, das irgendwas dur "Bernutzerprogramm zerstört" sei, das bleibt jetzt aber aus und das bild bleibt einfach stehen!
Dann halt als kleiner Test mal die MagiC Files auf C:\ legen ...
die Idee habe ich jetzt auch und wenn's funzt, lasse ich "C:" als gemeinsame Bootp. für mein HauptTOS (2.(0)6) und MagiC!
-
*klugscheißmodusan*
noch ein kleiner Auszug aus elektronik-kompendium:
Erweiterte Partition
Muss eine Festplatte in mehr als 4 Partitionen unterteilt werden, dann kann eine zusätzliche erweiterte Partition pro physikalisches Laufwerk eingerichtet werden. Die erweiterte Partition ist nicht bootfähig. Sie kann allerdings in kleinere logische Partitionen unterteilt werden.
*klugscheißmodusaus*
nicht böse nehmen, Burkhard ;)
DOCH ;)
Spaß beiseite - wie kann ich Dir was böse nehmen, nachdem ich Dir erstmal viel zu verdanken habe! Außerdem denke ich, ich bin Dir noch was schuldig geblieben! Sende mir mal per PN Deine neue Bankverbindung - oder ist es tatsächlich bei der geblieben, die Du in Deiner Saaländischen Zeit hattest?
Ich dachte immer, Atari organisiert die Partitionstabelle anders und das mit physikalischen und logischen Partitionen gilt nut für PC-Systeme, weil die Unterscheidung bei Atari-Treiberinstallern nie mit ausgeführt wird!
-
*klugscheißmodusan*
noch ein kleiner Auszug aus elektronik-kompendium:
Erweiterte Partition
Muss eine Festplatte in mehr als 4 Partitionen unterteilt werden, dann kann eine zusätzliche erweiterte Partition pro physikalisches Laufwerk eingerichtet werden. Die erweiterte Partition ist nicht bootfähig. Sie kann allerdings in kleinere logische Partitionen unterteilt werden.
*klugscheißmodusaus*
nicht böse nehmen, Burkhard ;)
DOCH ;)
Spaß beiseite - wie kann ich Dir was böse nehmen, nachdem ich Dir erstmal viel zu verdanken habe! Außerdem denke ich, ich bin Dir noch was schuldig geblieben! Sende mir mal per PN Deine neue Bankverbindung - oder ist es tatsächlich bei der geblieben, die Du in Deiner Saaländischen Zeit hattest?
Ich dachte immer, Atari organisiert die Partitionstabelle anders und das mit physikalischen und logischen Partitionen gilt nut für PC-Systeme, weil die Unterscheidung bei Atari-Treiberinstallern nie mit ausgeführt wird!
Bin zwar zum Saarländer zum Hessen zum Pfälzer geworden, aber Saarländisch bleibt alles beim alten bei mir. Also die Bankverbindung ist immer noch gleichgeblieben.
-
Ich dachte immer, Atari organisiert die Partitionstabelle anders und das mit physikalischen und logischen Partitionen gilt nut für PC-Systeme, weil die Unterscheidung bei Atari-Treiberinstallern nie mit ausgeführt wird!
Auch die Atari-Partitionstabelle im Rootsektor bietet nur Platz für 4 Partitionen, möchtest Du mehr, kommen auch beim Atari erweiterte Partitionen (Typ "XGM") ins Spiel.
Und wenn Du Deine SD-Karte PC-kompatibel partitioniert hast (um z.B. mit Windows Daten auszutauschen), dann hast Du sowieso wieder primäre und erweitere Partitionen nach MS-DOS-Schema darauf.
-
Auch die Atari-Partitionstabelle im Rootsektor bietet nur Platz für 4 Partitionen, möchtest Du mehr, kommen auch beim Atari erweiterte Partitionen (Typ "XGM") ins Spiel.
Und wenn Du Deine SD-Karte PC-kompatibel partitioniert hast (um z.B. mit Windows Daten auszutauschen), dann hast Du sowieso wieder primäre und erweitere Partitionen nach MS-DOS-Schema darauf.
Tja - habe ich mittlerweile auch schon vermutet, da meine CF-Karte tatsächlich auf DOS kompatibel eingerichtet ist!
Bleibt nur eine komplette Neueinrichtung, da auch "C:" als gemeinsames Bootlaufwerk für TOS 2.(0)6 und MagiC nicht in Frage kommt. Das TOS startet korrekt, aber bei MagiC gibbet 2 Bomben bei der Startphase!
Da TOS 1.(0)4 aber scheinbar mit "J:" als Bootpartition zurechtkommt, teste ich das vorher noch mal mit "L:" als Boot für TOS 2.(0)6!
-
Eine Boot-Platte sollte man nie und nimmer TOS/DOS kompatibel einrichten.
-
Was soll das nun wieder? mit dem "Twisted Cable" wird sie doch DOS kompatibel!
Und TOS 2.(0)6 kommt doch augenscheinlich gut damit klar!
-
Ich sehe auch keinen Grund, warum Du Deine CF-Karte nicht DOS-kompatibel partitionieren solltest. IDE, ge"twist"etes Kabel, pperas Treiber, damit läuft das bei mir einwandfrei. Zu beachten sind natürlich die -- je nach GEMDOS -- beschränkten Partitionsgrößen für das Bootlaufwerk. (Wenn dann vom Bootlaufwerk erst einmal BIGDOS geladen ist, dürfen die übrigen Partitionen auch größer sein.)
-
Ich habe das mit dem DOS/TOS-kompatiblen Partitionsschema mit meinem Falcon und HDDRIVER 9.0x auf einer CF ausprobiert und für nicht gut befunden. Ihr wisst ja, meine Boot-CF sitzt unter der Floppy, so dass ich einfasch eine andere reinstopfen kann und dann experimentieren kann, ohne meine eigentliche CF in Gefahr zu bringen.
Es macht keinen Sinn, die Bootplatte/CF PC-Kompatibel zu machen. Der PC kann eh nur die erste Partition auf einer CF sehen (getestet mit USB-Cardreader und PCMCIA-CF-Karte) , und die kann wegen TOS-Limits nur 512/1GB groß werden, das lohnt nicht. Besser ist es, eine weitere CF zu haben bis 2 GB TOS/DOS-Formatierte Partition mit HDDRIVER, oder FAT32 und noch größer mit MiNT. Das ist dann perfekt für den Datenaustausch. Und der PC kann nicht auf der Boot-Partition des ST rumpfuschen, der legt da mitunter Recycled-Ordner an, die aus ST-Sicht "kaputt" sind, überall fliegen plötzlich "DESKTOP.INI" Dateien rum, usw.
-
Jepp bei einem Falcon macht das Sinn. Beim St ist das pperasche Konzept schon vorzüglich. Ansonsten kann man das Interface auch auf alte Atari Weise (ahdi, huschi) nutzen und auch ein normales ide Kabel nehmen und sogar 2 Platten am Strang betreiben. Bei der nächsten Geschichte werde ich aber noch leistungstreiber für längere Kabel mit Bedenken, obwohl ich schon 60cm Kabel auch so ohne Probleme nutzen könnte.
-
Und der PC kann nicht auf der Boot-Partition des ST rumpfuschen, der legt da mitunter Recycled-Ordner an, die aus ST-Sicht "kaputt" sind, überall fliegen plötzlich "DESKTOP.INI" Dateien rum, usw.
Habe ich bisher nur mit osx das Problem gehabt. Der legt dann Spotlight Mist usw. an, was man mit HiM wieder los wird. Ansonsten Linux starten, Medium einstecken und alle Partitionen werden angezeigt. Grundsätzlich funktioniert auch sehr gut das partitionieren mit gparted.
-
Du hast recht, der Mac ist da noch schlimmer. Aber Seuche ist beides, wenns auf TOS-Laufwerken rumpfuscht. Deswegen besser das ST-Boot-Laufwerk nicht dem PC (oder Mac) zum Fressen geben.
-
Der PC kann eh nur die erste Partition auf einer CF sehen (getestet mit USB-Cardreader und PCMCIA-CF-Karte) , und die kann wegen TOS-Limits nur 512/1GB groß werden, das lohnt nicht.
Versuchs mal mit Ubuntu oder einem andere Linux! Laut Pperas Anleitung soger zwingend notwendig, weil man damit nicht nur die Karte in mehrere Laufwerke aufteilen kann, sondern auch in diese hineinschauen und Daten hin und herschieben kann!
Ich wundere mich nur, warum der Treiber auch die Wahl der höheren Partitionen zuläßt, wenn es nur sinnvoll ist, die ersten 4 als solche zu nutzen (eigentlich nur 3, denn wenn die Verwaltung der Laufwerke bei Atari entsprechend der DOS/Windows ist, können nur 4 physikalische Laufwerke pro Datenträger verwaltet werden, die ersten Drei sind dann primär physikalisch einzurichten und das Vierte für weitere logische - wenn man (wie ich) mehr als vier Laufwerke haben will! Ich habe es auch durch: es lassen sich keine zwei physikalischen Laufwerke mit mehreren logischen Laufwerken einrichten - vielleicht schafft es Linux, aber das habe ich nie probiert!
Naja - Neueinrichtung mache ich nun auf einer 2. CF, die muß aber erst noch beschafft werden!
-
Die Linux-Seuche kommt mir nicht auf meine PCs.
Und ich kann problemlos auf meinen Atarisauch von f g h in k l m n ... Booten, wenn ich die Taste bei der Plattentreibermeldung drücke. Mit ICD und hddriver getestet und genutzt. Nur magic habe ich nicht.
-
Die Linux-Seuche kommt mir nicht auf meine PCs.
Ist halt Deine Sache - ich möchte Ubuntu nicht mehr missen! Mikrosoft Systeme kosten viel und sind auf meinen etwas älteren bis ganz alten Rechnern, die aber doch schon 64bit fähig sind, doch sehr schwerfällig, weil sie wohl im Hintergrund sehr viel speichern! Windows nutze ich für einige Aufgaben, für die ich unter Ubuntu nicht die passenden Alternativen finde! Aber allgemein scheint Ubuntu schneller zu arbeiten! Ich habe beide Systeme (Win 7 und Ubuntu) auf meinem PC!
Und ich kann problemlos auf meinen Atarisauch von f g h in k l m n ... Booten, wenn ich die Taste bei der Plattentreibermeldung drücke. Mit ICD und hddriver getestet und genutzt. Nur magic habe ich nicht.
Mit dem Unterschied, daß - wenn man von "F:" oder "H:" bootet - trotzdem sie als Partition "F:" bzw "H:"! Mit Pperas Treiber werden sie aber zu "C:"! Meineswissens werden ACCs immer auf C gesucht oder gar garnicht geladen! Deshalb ist der Treiber für ein MehrTOS Atari-System mAn. eine glückliche Sache, wenn man zB. für die unterschidlichen TOSse unterschiedliche ACC-Anwendungen haben möchte! Ganz zu schweigen von der Desktop-Sicherung, die nach eigenen Erfahrungen auch immer auf "C:" abgelegt werden - selbst wenn ich bei einem Atari mit Festplatte ven Diskette gebootet habe!
-
Ob man wie bei HDdriver, CBHD oder vielen anderen eine beliebige F16-Part. zum Boot-LW erklären kann oder ob man wie PPera immer nur von c: bootet und dafür ummäppt, das scheint auf den ersten Blick gleichwertig zu sein.
Welchen Irrtum PPera da begeht, das merkt man erst, wenn man Links einsetzt :( ! Die sind bei mir inzwischen unentbehrlich (ab MiNT_1.15.5 oder MAGX_5.xx).
Übrigens kann man mit MAGX_6.21 auch von F32-Parts. booten (mit einem kleinen Trick).
Mit TOS geht booten nur bis p: und nur von F16.
-
Mich haben meine Windows 10 Lizenzen 30 Euro in Form von Win 8.0 Updates gekostet. Win 10 soll die letzte Version sein, kann ich also theoretisch lebenslang nutzen ohne nochmal dafür zu bezahlen. Win 10 soll ewig mit Updates versorgt werden. Wenn das mal kein Deal ist.
Wenn Pera f zu c macht, dann dürfte magic durcheinander kommen. Denn du magic auf f installiert, folglich steht in den den configs von magic f drin. Du bootest aber in dem du aus f c machst. Dann findet magic seine Dateien auf f aber nicht mehr weil das jetzt c ist.
Edit: ipad-autokorrekturen entfernt. las sich als wäre ich auf speed.
-
Also - ich für meinen Teil sehe da überhaupt kein Probrlem! Links verwende ich gar nicht (mir ist auch gar nicht bekannt, wie das geht) und falls sowas doch im Hintergrund von MagiC automatisch passiert: bei der Arbeit damit hat es sein Drive "C:" und wenn ich unter einem anderen TOS arbeite, ist es sowieso inaktiv! Und wenn ich dann wieder unter MagiC arbeite, mappe ich das betreffende Laufwerk zu "C:" und Magic hat die Laufwerktabelle wie eh und je!
Das es mit einem logischen Laufwerk nicht klappt, erkläre ich mir so: MagiC arbeitet vermutlich ähnlich PC Systemen und kann folglich nicht mit logischen Partitionen als Boot umgehen! TOS hat alles im ROM, was zum Start benötigt wird und benötigt nur einige Tools, um irgendwelche Bugs zu beheben, daher funktioniert es wohl auch, wenn eine logische Partition zur Boot wird!
Mal 'ne andere Frage: Weiß jemand, wie sich diese CF ...:
(http://i.ebayimg.com/images/g/M5gAAOSwpLNYAfBe/s-l1600.jpg)
... bei Atari verhält - funktioniert die im ST? Der ist ja recht mimosenhaft bei Verwendung einer CF!
-
Ich kenne Magic nicht. Aber nehmen wir mal ein anderes Beispiel, Metados... Metados braucht eine Config.sys, in der die Pfade zu den DOS und BOS Treibern drin stehen. Etwa so:
*BOS,c:\METADOS\ICDCDROM.BOS, D:5
*DOS, C:\metados\ISO9660F.DOS, O:D
Jetzt nehmen wir mal an, du bootest deinen ST so, dass C: C: (erste Partition) ist und F: F: (5. Partition).
Jetzt installierst du Metados auf F: und du bekommst solch eine Config.sys:
*BOS,F:\METADOS\ICDCDROM.BOS, D:5
*DOS, F:\metados\ISO9660F.DOS, O:D
Solange du C: aus ersten Partition startest, klappt das. Jetzt nimmst du den c:\auto Ordner und verschebst ihn nach F:
Dann Reset, und du drückst in Peras Treiber F. Damit wird aus F: C: und aus C: D:, wird E:, E: wird F:
C:\Auto wird abgearbeitet und startet Metados und liest die Config.sys und sucht DOS und BOS Datei auf F: (vormals E) und findet seinen Krempel nicht.
Das dürfte momentan die Situation sein, die du mit Magic hast.
Die Compactflash kannst du ausprobieren, mit SanDisk ist man eigentlich immer auf der sicheren Seite. Garantieren werde ich aber für nichts.
-
Ich habe auch einige SanDisk Karten und viele andere und mit der MonSTer keinerlei Probleme ...
-
Ich kenne Magic nicht. Aber nehmen wir mal ein anderes Beispiel, Metados... Metados braucht eine Config.sys, in der die Pfade zu den DOS und BOS Treibern drin stehen. Etwa so:
*BOS,c:\METADOS\ICDCDROM.BOS, D:5
*DOS, C:\metados\ISO9660F.DOS, O:D
Jetzt nehmen wir mal an, du bootest deinen ST so, dass C: C: (erste Partition) ist und F: F: (5. Partition).
Jetzt installierst du Metados auf F: und du bekommst solch eine Config.sys:
*BOS,F:\METADOS\ICDCDROM.BOS, D:5
*DOS, F:\metados\ISO9660F.DOS, O:D
Solange du C: aus ersten Partition startest, klappt das. Jetzt nimmst du den c:\auto Ordner und verschebst ihn nach F:
Dann Reset, und du drückst in Peras Treiber F. Damit wird aus F: C: und aus C: D:, wird E:, E: wird F:
C:\Auto wird abgearbeitet und startet Metados und liest die Config.sys und sucht DOS und BOS Datei auf F: (vormals E) und findet seinen Krempel nicht.
Das dürfte momentan die Situation sein, die du mit Magic hast.
Auch nicht richtig Durchdacht von Dir! Bei MagiC hatte ich immer Probleme bei Abfrage des CD ROM. Da es bei mir in der Nachlade Version auch nie richtig arbeiten zu wollen schien, habe ich es eher Stiefmütterlich behandelt und nur gelegentlich benutzt um mich irgendwie hineinzufinden und meine Möglichkeiten danmit auszuloten. Das mit CD ROM war eher nebensächlich! Meineswissens beinhaltet es aber auch eine eigene Laufwerkverwaltung und MetaDOS wird hier mW gar nicht geladen, da MagiC den Ordner "AUTO" behandelt wie jeden anderen und nicht als Ordner für automatisch zu startende Programme (jedenfalls ist das meinen Erkenntnissen zufolge bei der nachlade Version so)! Wenn MagiC überhaupt mit einem CD ROM umgehen kann, dann nur mit einer eigenen Verwaltung. Oder es gibt einen Ordner, aus dem MetaDOS geladen werden kann! Ich weiß aber nicht, wie der benannt werden muß!
Jede Partition, die als Bootpartition eines der anderen TOSse da ist, erhält seinen eigenen AUTO Ordner mit dem zugehörigen MetaDOS, für das eine eigene CONFIG.SYS erstellt werden kann, die dann die Daten der entsprechenden Laufwerkzuordnung enthält. Es wird also auch hier wieder korrekt arbeiten!
Aber ich danke Dir trotzdem für diesen Beitrag, denn diese Notwendigkeit habe ich noch gar nicht in Erwägung gezogen und hätte mir einfach das unter TOS 2.(0)6 erzeugte CONFIG.SYS einfach in die anderen AUTO-Ordner übernommen!
Aber es könnte auch so klappen, denn die bei mir befinden sich die benötigten Treiber direkt mit im AUTO Ordner und die Partitionen werden gegeneinander ausgetauscht und verschieben sich nicht - wie Du meinst - nach oben, also: aus "C:" wird "F:" und aus "F:" wird "C:"!
Ich habe auch einige SanDisk Karten und viele andere und mit der MonSTer keinerlei Probleme ...
Ich habe ein Angebot zu dieser bei eBay (http://www.ebay.de/itm/272424020261?_trksid=p2060353.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT) entdeckt, von dem auch das Bild stammt! Mehr als 10€ (mit Versandspesen maximal 12€) kann ich für den kommenden Monat nicht einplanen! Falls mir aber das Teil aus der Hand gereizt wird, was wäre mit mit einer solchen CF (http://www.ebay.de/itm/Speicherkarte-Compact-Flash-CF-Karte-4-GB-8-GB-16-GB-32-GB-fur-Digital-Kamera-/322291664419?var=&hash=item4b0a148623:m:m09A3ZKi8ucMp-9gdjSiyUQ) (max. 8GB, aber eher die 4GB)? Kann die auch jemand empfehlen?
-
Das mit MetaDOS ist nur ein Beispiel. Es geht nicht um CD-ROM-Probleme b ei Magic. Es geht darum, dass Magic Konfigurationsdateien verwendet, in denen reingeschreben wurde, wo es seine Systedateien findet. Und diese Pfade sind eben an ganz bestimmte Laufwerksbuchstaben gebunden. Wenn etwas so installiert wurde, dass es seine Systemdateien auf F: finden soll, und dann plötzlich F: zu C: umbenannt wurde, dann geht das eben nicht mehr.
[spoiler]
Interessanterweise ist dieses Thema auf dem Amiga einfacher zu lösen, in dem man die Software in einen Ordner "Softwarename:", also z.B. "Magic:", installieren würde, nachdem man diesen Ordner mit dem Assign-Befehl verknüft hätte: assign magic: dh3:software/magic (Um genau zu sein, "Magic:" ist sogar gleichberechtigt mit Laufwerksnamen wie DF0:, DH3:, usw. Wenn man jetzt Magic: wo anders haben wollte, müsste man es nur von dh3:software/magic woanders hin verschieben, z.B. nach dh5:/system/magic und dann einfach nur in der s:startup-sequence den assign-Befehl anpassen, fertig ist der Lack. Wie ich finde, eine sehr elegante Sache, die ich leider außer unter Amiga-OS in keinem anderen OS so elegant gelöst gesehen habe. AM nächsten kommt dem die Sache mit den Symlinks unter unixoiden Betriebssystemen (u.a. Linux), wo sowas mit "ln -s ziel quellpfad" machbar ist. (Unter Windows gibts das auch, nutzt aber außer MIcrosoft (z.B. c:\benutzer nach c:\users) selbst kaum einer)[/spoiler]
-
Interessanter Weise gDlieGZ!
Warum willst Du es nicht kapieren? also dann Schritt für Schritt:
MagiC kann ich nicht unter TOS konfigurieren, sondern nur unter MagiC!
Dh.: Erst einmal muß ich MagiC im Grundpaket starten. Da es aber nicht startet ohne die am Anfang auf ROOT benötigten Dateien, muß ich die erstmal unter TOS auf die entsprechente Partition kopieren - nach neuesten Kenntnissen muß das wohl "D:" werden! Ich kopiere also auf diese Partition das, was von Pera Putnik, dem wir die ROM Version verdanken, als benötigt empfohlenen Dateien auf "D:"! RESET! Bei der Auswahl drücke ich <D> und MagiC startet, weil "D:" jetzt zu "C:" wurde, zum ersten Mal und kann es einrichten. Wenn ich dann zukünftig mit MagiC arbeiten will, muß ich folglich auch wieder <D> drücken und MagiC findet seine Laufwerktabelle wie sie bei der Einrichtung vorhanden war - und alles ist gut!
Übrigens: Wenn Du Dich nicht mit MagiC befassen willst solltest Du Dich am Besten auch aus Diskussionen darüber heraushalten (x: edit) anstatt anderen Leuten die Zornesröte ins Gesicht zu holen!
edit: oder gar anzetteln !!!
-
Noch etwas - die hier beschriebenen Problematiken treffen eher zu, wenn Du mit den Treibern wie SCSI-Tools oder HDDriver mehrere Partitionen als Bootlaufwerk nutzt! Ich habe das mal testweise (unter Verrwendung von SCSI-Tools) für mich durchexerziert:
Wenn ich mir zB "F:" als eine andere Bootpartition einrichte und dort eine andere ACC Verwaltung habe als auf "C:", wurden dabei trotzdem die ACCs von "C:" geladen, zuvor im Bootselektor aber die auf "F:" zum (De)selektieren angezeigt! Auch die Desktop Speicherung wurde auf "C:" abgelegt, gesucht aber auif "F:"! Das sieht nach größerem Durcheinander und Humbug für mich aus!
-
Das liegt dann aber an SCSI-Tools. Mit ICD oder HDDRIVER holt er sich die ACCs immer vom gewählten Bootlaufwerk.
-
Wenn ich bei mir mit HDDriver D:\ zum booten auswähle werden alle Sachen ausser dem Autoordner von C:\ geladen ...
-
Das liegt dann aber an SCSI-Tools ...
... oder am User selbst - ich kann nämlich eigene Fehler damals nicht ausschließen!
Wie dem auch sei! ist Schnee von Gestern!
Ich habe mir danach halt den FF nicht mehr erlaubt und meine Systeme immer so gestalltet, daß "C:" einzig Boot bleibt!
Jedenfalls bleibt auch bei dem jetzigen Treiber "C:" einziges Bootdrive (auch wenn es nicht mehrr die erste Partition des Datenträgers ist) und - abgesehen von der Patition, die jetzt zu "C:" wurde und eben die erste Partition - bleibt auch die Laufwerkverwaltung erhalten!Wenn ich bei mir mit HDDriver D:\ zum booten auswähle werden alle Sachen ausser dem Autoordner von C:\ geladen ...
Also hab ich doch recht und damals wohl doch keinen Fehler gemacht!
-
da MagiC den Ordner "AUTO" behandelt wie jeden anderen und nicht als Ordner für automatisch zu startende Programme
Natürlich ist der AUTO-Ordner auch unter MagiC dafür da, Programme automatisch zu starten, bspw. NVDI, Overscan …
-
Natürlich ist der AUTO-Ordner auch unter MagiC dafür da, Programme automatisch zu starten, bspw. NVDI, Overscan …
Und warum arbeitet es (zumindest die Nachlade Version) diesen dann nicht ab?
Ich habe es jedenfalls auf meinem Mega STE gehabt, daß ich nach dem MagiC Startbildschirm keine Anzeige vom STARTUP.PRG mehr erhielt und auch MetaDOS nicht mehr im System zu sein schien!
-
Im MagiC-Handbuch werden auf S. 7 einige Aspekte genannt, die Probleme bereiten können. (Sinnigerweise heißt das Kapitel „Tuning für Experten“.)
Genannt werden:
- Bei älteren Mega ST der Blitter, da er den DMA-Chip blockieren kann.
- Ein nicht speziell auf MagiC angepasster Festplattentreiber.
- Zudem die Verwendung von IDE-Festplatten, die beim Falcon schon Probleme bereitet haben.
- Auf bestimmte Cache-Programme sollte verzichtet werden.
- Ebenso auf nicht reentrante GDOS-Versionen.
Empfohlen werden der HDDRIVER und NVDI sowie die Installation des Programms FLOCK_OK.PRG im Ordner GEMSYS/MAGIC/START.
Vielleicht hilft einer der Tipps weiter.
-
Nachtrag:
Das Handbuch von MagiC ist online unter:
https://www.dsd.net/files/dl.php?File=Magic.pdf (https://www.dsd.net/files/dl.php?File=Magic.pdf)
-
Im MagiC-Handbuch werden auf S. 7 einige Aspekte genannt, die Probleme bereiten können. (Sinnigerweise heißt das Kapitel „Tuning für Experten“.)
Also - das Handbuch würde mich gerne mal interessieren! Meine MagiC Versionen habe ich als eine 5er Version durch SW-Tausch und die 6.1 Version durch einen gefundenen Download im Netz kostenlos erhalten können! Aber nehmt das bitte jetzt nicht zum Anlaß, mich auf irgendwelche Copyright-Verletzungen hinzuweisen! Auch das Upgrade zur v6.2 ist anscheinend bei ASH kostenlos - man erhält Dateien, mit denen man aus einer v6.1 eine v6.2 machen können soll, hat aber bei meiner v6.1 nicht funktioniert!
Gibt es vielleicht zum Handbuch einen kostenlosen Download-Link?
(edit: der Nachtrag mit dem Download-Link war völlig untergegangen - habe es gerade gazogen!)
Genannt werden:
- Bei älteren Mega ST der Blitter, da er den DMA-Chip blockieren kann.
Ausgehend davon, daß mein Mega ST4 eine schmale Auswurftaste hat, gehe ich schon davon aus, daß er aus einer der jüngeren Serien stammt!
- Ein nicht speziell auf MagiC angepasster Festplattentreiber.
??? ??? ???
- Zudem die Verwendung von IDE-Festplatten, die beim Falcon schon Probleme bereitet haben.
Im späteren betrieb vielleicht, aber warum sollte sich MagiC nicht genau so von IDE starten lassen wie von ACSI/SCSI Anlagen?
- Auf bestimmte Cache-Programme sollte verzichtet werden.
- Ebenso auf nicht reentrante GDOS-Versionen.
Hier fehlen mir die Worte und Gedanken für eine Anmerkung
Empfohlen werden der HDDRIVER und NVDI sowie die Installation des Programms FLOCK_OK.PRG im Ordner GEMSYS/MAGIC/START.
Vielleicht hilft einer der Tipps weiter.
Warum sollte es mit HDDriver besser funzen als mit SCSI-Tools als Festplattendriver? Wenn die Entwickler von Letzterem sich mit der Weiterenwicklung befaßt hätten, wäre es wohl auch heute dem HDDriver ziemlich ebenbürtig!
Eigentlich sehe ich bei em gesamten Beitrag keinen Grund, warum ein vorhandener Auto-Ordner nicht korrekt ausgelesen werden kann!
-
Also - das Handbuch würde mich gerne mal interessieren!
Dann vielleicht doch den Nachtrag lesen:
Nachtrag:
Das Handbuch von MagiC ist online unter:
https://www.dsd.net/files/dl.php?File=Magic.pdf (https://www.dsd.net/files/dl.php?File=Magic.pdf)
-
Ja - wie in meinem edit schon bemerkt! Der Nachtrag war irgendwie untergegangen - besten Dank dafür!
-
Also - ich habe gerade mal das Handbuch von MagiC überflogen! Dadurch wurde mir folgendes bekannt:
- AUTO-Ordner:
MagiC sucht im Ordner AUTO erst einmal nach einer Datei "AUTOEXEC.BAT" und arbeitet dann die darin aufgelisteten Programme ab. Da ich das bislang nicht wußte und eine solche Datei entweder gar nicht vorhanden oder die falschen Einträge hatte, wurde der Ordner bei mir auch gar nicht abgearbeitet!
- CD-ROM
Hierüber ist nur was in Bezug auf MagiCMAC zu lesen, daß ein eigener Treiber vorhanden sei und das Laufwerk fest auf D stellt. Ich vermute mal, daß am Atari das MetaDOS geladen werden muß und dann auch die Laufwerk- und Treiberdaten der entsprechenden CONFIG.SYS angewendet werden!
Alles Andere muß ich mir erst noch erlesen!
Die Argumente von @ste1040fan im Posting #219 beziehen sich wohl doch nicht auf meine bislang beschriebenen Probleme und können dewshalb erstmal unbeachtet bleiben - Trotzdem nochmals:
(http://www.deutschlandangeln.de/images/smilies/herz.gif)lichstes (http://www.smiley-paradies.de/smileys/schild/schild_0015.gif) an ihn
-
Die Sache mit dem CD Rom bezieht sich ausschliesslich auf MagiCMac ...
-
Natürlich ist der AUTO-Ordner auch unter MagiC dafür da, Programme automatisch zu starten, bspw. NVDI, Overscan …
Und warum arbeitet es (zumindest die Nachlade Version) diesen dann nicht ab?
Ich habe es jedenfalls auf meinem Mega STE gehabt, daß ich nach dem MagiC Startbildschirm keine Anzeige vom STARTUP.PRG mehr erhielt und auch MetaDOS nicht mehr im System zu sein schien!
Liste doch bitte mal den Inhalt deines AUTO-Ordners, in der physikalischen Reihenfolge, also nicht alphabetisch. Es kann ja sein, dass die genannten Programme *vor* MAGXBOOT.PRG liegen und du deswegen die Ausgabe nicht siehst. Eigentlich sollte MAGXBOOT.PRG vorne in der Reihenfolge liegen, bspw. nach dem Bootselektor (TUBS, XBoot …)
Was ist außerdem "STARTUP.PRG"?
-
Liste doch bitte mal den Inhalt deines AUTO-Ordners, in der physikalischen Reihenfolge, also nicht alphabetisch. Es kann ja sein, dass die genannten Programme *vor* MAGXBOOT.PRG liegen und du deswegen die Ausgabe nicht siehst. Eigentlich sollte MAGXBOOT.PRG vorne in der Reihenfolge liegen, bspw. nach dem Bootselektor (TUBS, XBoot …)
Was ist außerdem "STARTUP.PRG"?
Ließ bitte mal mein Posting #224, da habe ich bereits geäußert, daß ich mittlerweile Einblick in das Handbuch nahm und auch Erkenntnis habe, warum die Abarbeitung von AUTO bei meiner Installation nicht funktioniert hat!
STARTUP.PRG ist mein Bootloader! Der ist über viele PD-Serien veröffentlicht worden!
-
Edit.: Beitrag selbst gelöscht.
´Tschuldigung, manchmal steh´ ich auf der Leitung... ;)
-
Ist doch egal, woher - Hauptsache ist, ich habe das Handbuch!
-
Ließ bitte mal mein Posting #224, da habe ich bereits geäußert, daß ich mittlerweile Einblick in das Handbuch nahm und auch Erkenntnis habe, warum die Abarbeitung von AUTO bei meiner Installation nicht funktioniert hat!
Ja, nur ist dein Rückschluss falsch. MagiC arbeitet einen AUTO-Ordner auch ohne vorhandene autoexec.bat ab, dann halt in physikalischer Reihenfolge. Der Sinn einer autoexec.bat ist der, dass man leicht(er) die Reihenfolge des Starts modifizieren kann, ohne einen Bootselektor wie TUBS, XBoot … heranziehen zu müssen, indem man im Texteditor die Zeilenreihenfolgen in der Datei tauscht. Aber notwendig ist die Datei nicht.
STARTUP.PRG ist mein Bootloader! Der ist über viele PD-Serien veröffentlicht worden!
Was meinst du mit Bootloader? Sowas wie TUBS oder XBoot, mit dem die ACCs und AUTO-Ordner-Programme zur Bootzeit an- und ausknipsen kann?
Ein Bootloader wäre für mich eher das, was im ROM oder in den ersten Bootsektoren einer Platte steht, oder vielleicht noch sowas wie MAGXBOOT.PRG
-
Ja, nur ist dein Rückschluss falsch. MagiC arbeitet einen AUTO-Ordner auch ohne vorhandene autoexec.bat ab, dann halt in physikalischer Reihenfolge. Der Sinn einer autoexec.bat ist der, dass man leicht(er) die Reihenfolge des Starts modifizieren kann, ohne einen Bootselektor wie TUBS, XBoot … heranziehen zu müssen, indem man im Texteditor die Zeilenreihenfolgen in der Datei tauscht. Aber notwendig ist die Datei nicht.
Das wirft für mich wieder die Frage auf, warum der AUTO Ordner nach dem Reset duch den MagiC Starter nicht wieder abgearbeitet wurde - unter TOS wird er abgearbeitet, egal, ob mit Warm- oder Kaltstart-Reset! Aber ja, aus einem Irrtum und falschen Informationen heraus hatte ich den Starter am physikalischen Ende des AUTO Ordners platziert
Was meinst du mit Bootloader? Sowas wie TUBS oder XBoot, mit dem die ACCs und AUTO-Ordner-Programme zur Bootzeit an- und ausknipsen kann?
Für solche Programme war Atariseitig schon ziemlich am Anfang der Begriff "Bootloader" in der Fachpresse aufgeführt!
Ein Bootloader wäre für mich eher das, was im ROM oder in den ersten Bootsektoren einer Platte steht, oder vielleicht noch sowas wie MAGXBOOT.PRG
Meinst Do sowas wie ein Master Boot Sektor einer Start-HDD eines PC?
MAGXBOOT.PRG ist nach meinem Begriff ein "Starter"!
-
Nein, ein Bootloader ist was ganz anderes. Autostart-Menü trifft es besser.
-
So - neue CF Karte ist gestern eingetroffen und wurde heute gleich erstmal mit GPartEd unter Ubuntu vorbereitet. Ich hoffe, sie läßt sich auch so jetzt im Atari einsetzen (1. Partition = "C:", 2. Partition = "D:" usw.)! Ich habe auch gleich am PC die Dateien für MagiC Boot auf die 2. Partition kopiert in der Hoffnung, daß MagiC damit jetzt anständig startet.
Jetzt habe ich noch eine Frage: Es hatte ja w.o. schonmal Andeutungen gegeben, daß mit BigDOS mehr als 14 Partitionen verwaltet werden können, die unter TOS direkt ansprechbar sind. Bedeutet das, daß ich auf alle Partitionen auch unter TOS Zugriff habe oder benötige ich dazu ein weiteres Programm? Wenn ich beide Karten am System habe um die alten Daten auf die neue zu bekommen, hätte ich nämlich Partitionskennungen bis "W:" nötig! (alte CF "C:" bis "L:", neue Karte "C:" bis "M:")
-
Lese doch einfach die Anleitung durch ...
Big-DOS ist ein Dateisystem nach DIN EN 29293 = ISO 9293:1987. Es ersetzt das
GEMDOS des TOS (nicht KAOS und nicht ASH-MagiC!).
˘ GEMDOS- / ISO-9293:1987- / MS-DOS-Dateisystem
˘ 32 Laufwerke: A..Z1..6 oder A..Z[\]^_`
˘ Bis 65518 Cluster.
˘ 1 bis 64 Sektoren pro Cluster.
˘ Mehr als 65535 Sektoren und damit beliebige MS-DOS-Partitionen mîglich. Also
auch solche mit mehr als 32 MByte.
˘ 1 oder 2 FAT.
˘ Die erlaubten Zeichen werden - fÅr jedes Laufwerk getrennt einstellbar -
fÅr GEMDOS, d-Zeichen nach ISO 9293 bzw. ISO 9660 oder MS-DOS beschrÑnkt.
Damit weiû man schon vorher, ob MS-DOS oder ein beschrÑnktes
CD-Brenner-Programm alles lesen kann. Mit setter.ttp aus dem HSModem-Paket
oder dem setter.prg von Markus Kohm kann dies in Big-DOS gespeichert werden.
˘ Bei MS-DOS-Bootsektoren wird der Diskname auch dort hineingeschrieben.
˘ LÑuft mit und ohne MiNT.
˘ Wenn mîglich, wird beim ôffnen von Dateien Åber XHDI der Auswurf von
Wechselmedien gesperrt. (HDDRIVER, hdpSTACK, HuSHI)
˘ FÅr TOS 1.04 und 1.06 wird kein POOLFIX3.PRG, PFIX_CB.PRG oder POOLFX92.PRG
benîtigt.
˘ FÅr TOS 4 wird F030HFIX.PRG nicht benîtigt.
˘ 94 Standard-Handles fÅr Dateien statt 75. Mit WINX und ohne MiNT lassen sich
in CAT bis zu 31 Gruppen îffnen.
˘ Cookies ØDATEÆ und ØTIMEÆ wie bei DTCOOKIE und LED-Panel.
˘ Die Namen der geladenen Accessories werden ausgegeben.
˘ Alle GEMDOS-Funktionen des TOS einschlieûlich Srealloc().
Srealloc() schreibt z. Z. Informationen auf den Bildschirm.
˘ FÅr Uralt-Programme, wie sie bei ØAlcyon CÆ dabei sind, wird Cconws() von
CP/M-68K nach GEMDOS konvertiert.
˘ Programmabbruch mit Control-C ergibt wie bei KAOS und ASH-MagiC EBREAK (-68)
statt EINVFN (-32).
˘ Mxalloc() ignoriert die Speicherschutz-Bits.
˘ FÅr Maddalt() ist Speicher unterhalb 16$ 40 0000 ST-RAM.
˘ Sync() schreibt alle Puffer.
˘ Eigene Dcntl() wie in dateisys.txt und FUTIME und KER_DOSLIMITS. Mit
Dcntl(FUTIME, ...) lÑût sich (z. B. von Backup-Programmen) auch das Datum von
Verzeichnissen Ñndern.
˘ Mit Fattrib() lÑût sich bei Disknamen ein von MS-DOS fÑlschlich gesetztes
Archiv-Bit lîschen und bei Verzeichnissen das Versteckt- oder System-Bit
Ñndern. Versteckte Ordner werden z. B. vom DESKTOP, Gemini oder Selectric nur
dann gezeigt, wenn versteckte Dateien gewÅnscht werden.
˘ Dlock() ergibt momentan bei offenen Dateien EACCDN (-36), sonst EINVFN (-32).
˘ Dpathconf()
˘ Sysconf()
˘ Fxattr() liefert als ØInodeÆ den Startcluster oder bei leeren Dateien den
Startcluster des Verzeichnisses + Byte-Position im Verzeichnis * 2^11.
˘ Groû-/Kleinschreibung der Namen kann fÅr beliebige Laufwerke beibehalten
werden. (--> Setter oder dosmode.tos) Das eignet sich gut zum Testen eigener
Programme. Dpathconf(..., DP_TRUNC) kann so konfiguriert werden, daû es
DP_AUTOTRUNC statt DP_DOSTRUNC zurÅckgibt. Das ist fÅr Gemini sinnvoll.
Da MiNT Dpathconf() selber Åbernimmt, funktioniert dies nicht mit MiNT.
-
Besten Dank für die schnelle Antwort! Dann werde ich es also mal probieren - aber heute werde ich dazu nicht mehr kommen, muß gleich erst einmal weg!
-
Vor ein paar Tagen wollte ich mir jetzt endlich die neue Karte in meinen Mega ST4+ einsetzen und zur Nutzung einrichten, aber ich bekomme von den Partitionen keine Fenster geöffnet! Beim Installieren des Treiber klappt das (scheinbar) erst einmal noch - ich hatte die 8GB Karte alleine in dem Masterschacht und den Treiber installiert - korrekt und die Laufwerke lassen sich auch erkennen, aber im Desktop nicht öffnen. Ich habe peinlich genau beim Einrichten unter GPartEd darauf geachtet, daß die Laufwerke als FAT32 Laufwerke eingerichtet wurden, aber vielleicht doch was übersehen!
-
FAT32 geht nicht und ist falsch, FAT16 muss es sein ...
FAT32 geht nur unter MagiC und MiNT und das auch nur sehr langsam auf einem 68000 System und nicht zum booten.
-
Aua! Sollte ich mich da tatsächlich vertan haben? Leider ist an meinem PC scheinbar das NT ausgefallen! Zwar habe ich es schon getauscht, aber Testlauf konnte noch nicht geregelt werden! Dann kann ich das hoffentlich korrigieren!
-
Du hast doch Magx im ROM in der Kiste? Geht damit auch kein Boot?
-
Tja - auch MagiC im ROM benötigt Dateien auf Datenträger - und die können auch hier nicht gelesen werden! Ich bekomme nämlich eine Fehlerangabe, daß irgendwelche Videodateien (ich vermute mal bestimmter Bildschirmtreiber) fehlen! Aber die Problematik ist ja schon erkannt und sollte behoben werden können, sobald der PC wieder Einsatzfähig ist!
-
Dann bootet MAGX also von F32,
es fehlt offenbar nur D:\GEMSYS\ mit den Treibern bzw. ein D:\ASSIGN.SYS, dessen Pfad auf C:\GEMSYS\ (sic!) zeigt.
-
Dann bootet MAGX also von F32, ...
Ich glaube, das ist eine leicht verkehrte Ansichtsweise - gebootet wird doch aus dem ROM; und die Daten von F32 können nicht eingelesen werden!
... es fehlt offenbar nur D:\GEMSYS\ mit den Treibern bzw. ein D:\ASSIGN.SYS, dessen Pfad auf C:\GEMSYS\ (sic!) zeigt.
Alles was die ROMversion benötigt, sollte vorhanden sein (hatte ich zumindest beim Einrichten der CF schon vorsorglich auf die Karte in entsprechende Partition kopiert)
Leider bekomme ich meinen PC erst einmal nicht richtig betriebsbereit und kann das vorerst nicht reparieren!
edit: Ich habe doch noch 'n intakten Cardreader gefunden und damit die Partitionen der CF auf FAT16 umstellen können! Ich werde sie heute nachmittag noch mal testen!
-
-^^- Du machst es einem wirklich schwer, Dir zu helfen. Im Cyberspace ist ´wissen´ angesagt, und nicht ´glauben´! Wenn Du etwas nicht weißt, dann überprüfe bitte die Fakten anstatt zu schwadronieren "sollte vorhanden sein". Ibs. genügt es nicht, ´alles´ zu kopieren, sondern auch der Inhalt muß stimmig sein. Pack also das D:\assign.sys in einen Editor und schau nach!
MAGX_6.xx hat die Treiber für F32 schon an Bord, also kann man davon auch booten. Jedoch darf man wg. eines Bugs damit nur lesen, nicht schreiben! Auch nicht mit einem BootSelektor! Am besten sofort schreibschützen!
Im übrigen hatte ich Dir ja schon mal in einem anderen Thread erklärt, wie man 4GB sinnvoll partitioniert.
-
MAGX_6.xx hat die Treiber für F32 schon an Bord, also kann man davon auch booten. Jedoch darf man wg. eines Bugs damit nur lesen, nicht schreiben! Auch nicht mit einem BootSelektor! Am besten sofort schreibschützen!
Was ist das denn für ein Fehler? Ich habe die 6.20 im Einsatz und nutze eine Partition mit FAT32 und kann bis jetzt keine Fehler sehen.
-
-^^- Meine Erfahrung war:
Immer, wenn ich mir eine frisch unter MiNT eingerichtete & befüllte F32 (~1,8 GB) unter MAGX_6.2 auch nur angeschaut habe ohne Schreibschutz (mit dem Menue-Punkt "Informationen..."), dann war sie direkt anschließend nach Rückkehr zu MiNT kaputt!
Da ich im Begriff bin zu verreisen, müssen wir leider eine ausführliche Diskussion darüber in den Januar verschieben, sorry. Ich werde dann mal einen neuen Thread eröffnen.
Edit:
Fortsetzung der Diskussion bitte dort:
http://forum.atari-home.de/index.php?topic=13354.0
Im hiesigen Thread ist das ja OT!
-
Immer, wenn ich mir eine frisch unter MiNT eingerichtete & befüllte F32 (~1,8 GB) unter MAGX_6.2 auch nur angeschaut habe ohne Schreibschutz (mit dem Menue-Punkt "Informationen..."), dann war sie direkt anschließend nach Rückkehr zu MiNT kaputt!
MagiC hat da einen bekannten Fehler, daß der Zähler des freien Platzes nicht richtig gesetzt wird, aber das ist mehr kosmetischer Natur. Ich betreibe sowohl meinen Milan als auch meine Falcons mit MagiC und großen Platten, die ich nur mit F32 nutzen kann, und habe dort keine besonderen Probleme mit Datenverlusten. Jedenfals nicht auf dem Milan und dem CT2A Falcon, die CT63 Kiste ist ein anderes Thema.
MfG
Ektus.
-
Nach einiger Zeit, wo ich teilweise ob gesundheitliicher und andererseits aber auch anderer privaten Probleme hier nicht weiterkam, möchte ich jetzt, nachdem ich schon einige Zeit wieder aktiv im Forum unterwes sein kann, doch weitermachen - und fange mit einer kleinen Zwischenbilanz an:
- Nach anfänglichen Schwierigkeiten konnte ich auf einer 4GB SanDisk meine Wunsch-Partitionierung einrichten, um zumindest unter TOS Betriebssystemen arbeiten zu können.
- Booten unter TOSsen klappt problemlos, auch das nachträgliche Wiedereinbinden eines ACSI Gerätes durch HUSHI.PRG.
- Da ich eine Nutzbarkeit von MagiC im ROM bislang nicht erreichen konnte, habe ich mich zum Kauf einer 8GB Karte entschieden, hier die physikalisch erste Partition für MagiC einzurichten. Leider arbeitete der ST bislang nicht mit dieser Karte. Weil ich das Gefühl habe, beim erstellen der Partitionen einen Fehler gemacht zu haben, wollte ich das jetzt einmal wiederholen, aber ich bekam aktuell kein Linux auf meinem momentanen PC gestartet.
- Wer HUSHI.PRG nicht mehr verfügbar hat, wohl aber HUSHI.SYS (zB. durch SCSITOOL installierte Treiberdatei), kann diese umbenennen und verwenden - mir sind keinerlei Störungen feststellbar gewesen!
Wenn ich jetzt ein brauchbares LINUX finde, gehts hier endgültig weiter ...
-
Im Moment schlage ich mich damit herum, einen passenden Ubuntu Stick zu kreieren, und das dann auf dem PC zu installiere, aber leider will mir das am momentanen System nicht recht gelingen. Ich benötige aber ein LINUX, um hier weiterzukommen, nämlich eine CF Karte zu formatieren und einzurichten ...
Wenn ich das Prob beseitigt habe, kann ich weitermachen, aber um das zu regeln, habe ich eine Diskussion unter "Non Atari - Stoftware" (https://forum.atari-home.de/index.php/topic,15360.msg242843.html#msg242843) begonnen!
-
Wozu brauchst du dazu Linux ? Geht auch mit den Windows command line Tools wie diskpart
-
Wozu brauchst du dazu Linux ? Geht auch mit den Windows command line Tools wie diskpart
Ich arbeite lieber Mausophil statt Befehlsorientiert! Mit Befehlen und deren Parameter habe ich irgendwie immer Probleme!
-
Da ist aber Linux auch das Falsche, definitiv ;)
-
es gibt noch Knoppix. Eine komplette Linux Distribution bootfähig von CD. Hab die noch hier. Allerdings eine uralte Variante. Müsste man schauen ob es was neueres gibt. Jedenfalls musst du auf dem PC überhaupt nichts installieren und hast glaube ein vollwertiges Linux geladen.
-
Kann nicht verstehen wo das Problem liegt Ubuntu Live CD/DVD zu benutzen.
Wenn du einen Datenträger einrichten willst vielleicht die -> https://gparted.org/livecd.php
-
Da ist aber Linux auch das Falsche, definitiv ;)
Auch bei Linux geht das Meiste mit der Maus - vor allem auch die Größenwahl der Partitionen, die man auf einer CF Karte installieren will!
-
Kann nicht verstehen wo das Problem liegt Ubuntu Live CD/DVD zu benutzen.
Wenn du einen Datenträger einrichten willst vielleicht die -> https://gparted.org/livecd.php
Das Problem liegt darin, daß man Ubuntu auf Stick mit einer geissen Persistenz - also anpaßbar - installieren kann, auf CD/DVD ist nachträglich nichts änderbar!
Ich starte Ubuntu auf persistenten Sticks immer so, wie ich es zuletzt verließ!
-
Ich habe jetzt erfolgreich eine 8GB CF vorbereiten können und für die erste Eirichtung pfofissorisch mit meinem StartUp, BigDOS und HuSHi im Autoordner des für TOS 2.(0)6 vorgesehenen Bootlaufwerks kopiert. Heute habe ich mit meiner schon eingerichtete 4GB Karte die Daten kopieren wollen, bekomme sie aber irgendwie auf der Slave-Seite meines Adapters nicht gelesen. Darum habe ich die ursprünglich am M-STE eingerichtete Platte mit der Elektronik eines externen SCSI Gehäuses an den ASCI gehängt und bin nun die Daten am rüberziehen. Dabei habe ich festgestellt, daß ich im TOS Desktop "nur" Laufwerke bis "P:" angezeigt bekomme, obwohl BigDOS - angeblich - weitere Laufwerke verfügbar macht. Das reicht natürlich nicht, um die kompletten Daten zu kopieren, denn es sind nur 3 Partitionen von insgesamt 6, 7 oder 8 Partitionen, die ich auf der Platte installiert habe. Wie kann ich mir auch die zusätzlich im System verfügbar gemachten Laufwerkssymbole unter TOS zur Anzeige bringen?
-
So - da das Problem hier gelöst (https://forum.atari-home.de/index.php/topic,15523.msg245090.html#msg245090) wurde, kann es jetzt weitergehen. Zusammengefaßt lag es am gewählten ACSI Initialisierer - Statt HUSHI.PRG aus dem SCSI-Tools ist CBHD.PRG (CBHD 5.02) anzuwenden. Beim weiteren Kopieren der Daten von den HDD-Partitionen ist mir aufgefallen: es können keine Dateinamen mit kleingeschriebenen Umlauten und diversen Sonderzeichen erzeugt werden und solche Dateien werden folglich nicht kopiert! Sehr problematisch, weil gerade viele Spiele solche Dateien aufweisen - zB. in den OXYD Dateinamen steckt oft de "TM" Zeichen ...
Kennt jemand einen Patch, der das beheben kann? Ansonstem hilft wohl nur ein Diskmonitor!
-
Ich habe auch noch ein SCSI Gehäuse mit einem CD-RW von Philips, daß ich über das LINK Kabel erfolgreich am Mega STE als Drive "O:" am Laufen hatte. Reicht es eigentlich, die Zeile mit dem DOS Ttreiber das "Z" anstelle "O" festzulegen oder könnte ich mit dieser CONFIG.SYS für MetaDOS wider auf maximal 16 (... -c 16, ...) Laufwerke festgelegt sein, so daß ich mit CD-Tools eine komplett neue C.S erzeugen sollte?
; CD-Tool BEGIN
; Note that everything up to `; CD-Tool END' will be erased by
; CD-Tool's configuration tool!
;
; created by CD-Tool 2.14, Sat Feb 15 15:01:24 2014
;
; devices
;
; ACSI 1: `PHILIPS CDD3600 CD-R/RW' -> A
;
; BOS drivers
;
*BOS, C:\auto\hs-cdrom.bos, A:1
;
; DOS drivers
;
; *DOS, C:\auto\hs-iso.dos -c16, O:A
*DOS, C:\auto\hs-iso.dos -c16, Z:A
;
; CD-Tool END
-
Wie oben geschrieben, auch MetaDOS erweitert die Anzahl der Laufwerksbuchstaben, kannst also auch (bis) Z: nehmen.
-
Bei der Suche nach CF und SD Adaptern bin ich auch auf folgende Bilder gestoßen:
(https://www.addonics.com/products/diagrams/AEUDMD4_diagram_lrg.jpg)
(https://images-na.ssl-images-amazon.com/images/I/41SY94HFASL._AC_.jpg)
(http://img0101o.psstatic.com/157043473_addonics-aeidedmd4b-ide-digidrive-3-5-flashcard-reader-.jpg)
Ich finde sowas durchaus als brauchbare Alternative zu einer Slave-CF; hätte man doch die freie Auswahl der Kartenart! Leider sind solche IDE Cardreader heute nicht mehr erhältlich - würde gerne mal probieren, ob die am Atari überhaupt einsatzfähig sind!
-
Gestern war meine neue GOTEK im Briefkasten. Ich habe gleich mal zu einem Schraubenzieher gegriffen, erst mit Handy ein Foto von außen gemacht und ihr "in den Bauch geschaut" - und natürlich noch ein Foto von der Platine gemacht. Sie kam ganz ohne Treiberdisk und ich finde das zwar OK, aber auch verwunderlich, weil sie wohl ohne Tasten auskommt:
(https://forum.atari-home.de/gallery/4117_28_10_19_11_37_44.png)
(https://forum.atari-home.de/gallery/4117_28_10_19_11_39_22.png)
Sobald ich einen kleinen zeitlichen Freiraum finde, werde ich darangehen und sie flashen, testen und halt dann auch einbauen, wenn die CF Adapter da sind. Für eine Umschaltung habe ich an (https://www.reichelt.de/tastenschalter-4x-um-gruen-sa-400-gn-p15631.html?&trstct=pol_3) 2 Drucktaster (https://www.reichelt.de/tastenschalter-4x-um-orange-sa-400-or-p15632.html?&trstct=pol_4) (sind zwar etwas teurer, aber passender für frontseitigem Einbau ...) gedacht, die ich mit dem Rotari Selektor rechtsseitig von der Floppy plane, die Verlangerung des USB und die OLED links über dem Tüpenschild. Bei der Bearbeitung des Gehäusedeckel kann mir hoffentlich Jerry helfen ...
Den Platz zwischen Typenschild und Floppy behalte ich mir vor für den Fall, daß mir noch so'n Teil wie aus dem letzten Post in die Hände fällt und das an Atari funktioniert. Über einen Verbindungen an der Atari Elektrik habe ich mir auch Gedanken gemacht:
-
Was ist das denn für ein abgespecktes Gotek? Hab ich so noch nie gesehen, ohne Tasten und vor allem ohne Display bzw. 7-Segment Anzeige.
Wie willst du da ein bestimmtes Disk-Image auswählen?
Oder hast du für's Display schon was geplant?
Da müssen noch oben links und unten rechts (der Sechserblock) Pins eingelötet werden, wenn man Display und Rotary-Selector steckbar machen will.
Die beiden fehlenden vor/zurück-Tasten würde ich auch einlöten, trotz Rotary. Bei vielleicht mehreren hundert Images, kann man durch gleichzeitiges drücken der beiden Taster direkt wieder zu Image 0 zurückkehren und muss nicht endlos am Rotary rumrühren.
Aber das weißt du sicher alles. ;)
-
Was ist das denn für ein abgespecktes Gotek? Hab ich so noch nie gesehen, ohne Tasten und vor allem ohne Display bzw. 7-Segment Anzeige.
Wie willst du da ein bestimmtes Disk-Image auswählen?
Oder hast du für's Display schon was geplant?
Da müssen noch oben links und unten rechts (der Sechserblock) Pins eingelötet werden, wenn man Display und Rotary-Selector steckbar machen will.
Die beiden fehlenden vor/zurück-Tasten würde ich auch einlöten, trotz Rotary. Bei vielleicht mehreren hundert Images, kann man durch gleichzeitiges drücken der beiden Taster direkt wieder zu Image 0 zurückkehren und muss nicht endlos am Rotary rumrühren.
Aber das weißt du sicher alles. ;)
Da hast Du nicht unrecht - die Tasten wären schon sinnvoll gewesen - alleine zum Update der Firmware - falls es so geht wie bei der HxC Firmware!
Das mit dem Rotary funzt bei mir jetzt auch (https://www.youtube.com/watch?v=EDillIz1C78&feature=youtu.be) ...
Allerdings streubt sich mein System mit dem Flashen der neuen Platine mit der empfohlenen SW von . Ich habe mir eine Anleitung in Deutsch (per GOOGLE Translate - angehängtes PDF) gebastelt, aber es klappt irgendwie nicht ...
Bild 2 (3. Anhang) zeigt die Fehlermeldung. Vielleicht könnt Ihr mir raten, wie ich noch vorgehen kann?
-
Von dem Gotek gibt es zwei Versionen, die eine Version benötigt einen Programmieradapter und die andere Version kann mit einem USB Kabel direkt Programmiert werden.
-
Von dem Gotek gibt es zwei Versionen, die eine Version benötigt einen Programmieradapter und die andere Version kann mit einem USB Kabel direkt Programmiert werden.
Definitiv hast Du hier was falsch verstanden! Die GOTEK - und mit der befasse ich (und @neogain) mich schon länger (https://www.tonmann.com/2014/08/16/gotek-floppy-emulator-sfr1m44-u100-at-inside-the-atari-st/)als hier Kenntnis vermittelt wurde, daß Franco del Nero seine darauf angepaßte HxC Firmware anbietet - basiert auf einer Grundschaltung, ...
(https://cortexamigafloppydrive.files.wordpress.com/2014/02/gotek_usb_floppy_emulator_schematic_resized1.jpg)
... die natürlich auch immer wieder diversen Revisionen (an den ganz neuen Platinen ist zB. der Programmerport 5+4 polig) unterliegen kann - aber immer mit dem gleichen Microcontroller, dem CORTEX STM32. Über dem Programmer Port ist daher aber auf jeden Fall jede GOTEK mit dem geeigneten Mittel umprogrammierbar und nicht, wie aus Deiner Aussage hervorgeht: die eine Version so und die Andere so!
Bei FlashFloppy wird zum Flashen der GOTEK über den Programmerport auf die Seite Cortex Amiga Floppy Emulator (https://cortexamigafloppydrive.wordpress.com/), von der ich auch ab dem Bereich OK I HAVE THE EMULATOR, HOW TO « TRANSFORM » IT ?
übersetzt und für meine PDF neu formatiert habe. FlashFloppy hat aber für das Einrichten (Flashen) eine weitere Möglichkeit veröffentlicht (ob auch selbst entwickelt oder nur aus besonderen Kenntnissen heraus, weiß ich nicht) nämlich die per Kabel direkt am USB Port. Das kann ich aber auf keiner andern Page erfassen, wo es um das Flashen einer GOTEK geht.
So - nach dieser kleinen - von @tuxie erzwungenen - OfTopic Exkursion komme ich mal wieder zu meinem Projekt zurück mit einem Nachtrag zu meinem Post #261 (zu meinem Flash Problem eröffne ich einen neuen Thread bzw. behandle das in einem vorhandenen Thread von mir wo es um die GOTEK geht ...):
Ich habe hier einen Schaltungsteil der Floppy-Ausgangsschematik dargestellt. in der ich 4 Umschalter symbolisiert hinzufügte. Damit hierzu keine unnötigen Fragen aufkommen, eine kleine Erläuterung: die untereinander gezeichneten Schalter stellen je einen 2 Wege Umschalter dar, also 2 Schalter 2xUm (oder, wenn auf den Pull Up verzichtet werden kann, reicht hier 1xUm). Mit diesem Schalter schalte ich das DS1 Select entweder auf den internen Shugart oder an den externen Port (wie es serienmäßig war). Damit kann ich eine externe Floppy weiter nutzen, aber eben nur als 3. Floppy im "Dual-Floppy-Betrieb" (zB. für eine 5,25"). Mit dem 2. Schalter schalte ich das DS0 am Shugart auf Pin 10 oder 12, wodurch eine auf DS0 (oder DS1 in der anderen Stellung) gejumperte Floppy betriebsbereit wird und der Einbau einer S1 gejumperten GOTEK als Zweitlaufwerk ist möglich. Wird nun DS0 an der Leitung 12 algelegt, ist man in der Lage, von jedem gewählten Diskimage auch zu booten.
Nun zu meiner Frage hierzu: Ist ein Pull Up überhaupt nötig; oder nur, wenn kein Laufwerk angedockt wird; oder schadet es gar einem angedockten Laufwerk, wenn sein DS Signal über lange Zeit über 1k auf 5Volt gezogen ist?
-
Du ich hab schon mehrere geflashed und du brauchst bei der einen Version ein Programmieradapter und bei der anderen genügt ein USB Kabel!
Zitat aus dem Exxos Forum:
The model I bought is marked SFRC922C on the PCB, and according to the eBay listing was a 1.44Mb device. This shouldn't matter, since we are reflashing it anyway. I previously had a gotek that came with a donated STFM, which had the HxC firmware installed & is marked SFRC922.
I've done the process on both drives and everything works absolutely fine I'm pleased to say. Obviously, this is an 'At your own risk' post, because it is possible to brick your Gotek, so be sure you want to do this before pressing on.
You'll need the following items to do this little project:
1. A Gotek drive. Kinda obvious really!
2. A PL2303HX USB To RS232 TTL Auto Converter Adapter Module (search for this on eBay). There may be issues with Win10 drivers due to variances in these USB devices, if so, use the older 3.2 drivers I've attached. I wasted hours because of driver issues, hopefully you won't!
3. STM flashing software, which I've attached to this post.
4. FlashFloppy hex file, which you can download from here: https://github.com/keirf/FlashFloppy, and I've also attached to this post, but you shold always check for the latest version on GitHub.
https://www.exxoshost.co.uk/forum/viewtopic.php?f=12&t=593
Anleitung NUR USB Variante
http://www.binarydevotion.com/?p=228
Per Seriell
https://github.com/keirf/FlashFloppy/wiki/Firmware-Programming
Ich hatte beide Versionen schon in der Hand!
-
Du ich hab schon mehrere geflashed und ... und bei der anderen genügt ein USB Kabel!
...
Das heißt aber nicht, das sie nicht auch mit dem TTL Adapter über den Flashing Port zu flashen wären - aber genau diese Äußerung habe ich aus Deiner Aussage interpretiert!
-
Aber laß uns das bitte nit hier weiter erörtern, sondern besser in dem passenden Thread (sobald er freigegeben wurde), an dessen Eingangspost ich gerade sitze!