atari-home.de - Foren
Software => Alternative Betriebssysteme => Thema gestartet von: ST-Oldie am Sa 08.07.2017, 16:38:39
-
Hallo,
ich hab mal für den Workshop auf der Retrolution versucht, EasyMiNT auf dem emulierten TT zu installieren um mögliche Probleme oder Fallstricke zu erkennen. Dabei bin ich über einige Dinge gestolpert, die mich veranlassen, das Easy im Namen als Anmaßung zu sehen. Und hab an die Experten hier ein paar Fragen.
Ich hab mit EasyMiNT 1.6 angefangen, Hatari als Version 2.0.0 und TOS 3.06
Das erste Problem war das Partitionieren und der Festplattentreiber. Im README.TXT vom EasyMiNT steht, es geht hdddriver oder cbhd (nur scsi) und man benötigt eine LNX oder RAW Partition.
Hatari kann wohl noch nicht das SCSI Interface des TT emulieren, also mußte es eine emulierte ACSI Platte sein. Gibt es eigentlich eine Möglichkeit, auch mit Installationstool von cbhd eine raw oder lnx Partition anzulegen ohne SED und etwas Wissen zu nutzen? Ich hab dann das Tool vom hddriver genutzt, da geht das ganz einfach. Für cbhd muß es eine RAW Partition sein wie hier im Parallelthread schon beschrieben, LNX geht nicht. Dann konnte ich cbhd (5.02) installieren und der Installer von EasyMiNT war zufrieden und hat die RAW Partition gesehen. Allerdings hat dann nach dem ersten Installdurchlauf MiNT eine Fehlermeldung ausgegeben, daß kein XHDI Plattentreiber gefunden wurde. Heißt der obige Satz aus dem README tatsächlich, daß die XHDI Schnittstelle im cbhd nur für SCSI Platten zur Verfügung steht? Oder hat sich an der XHDI Spezifikation etwas geändert und cbhd ist zu alt? Hat irgend jemand es geschafft, das auch mit freien Tools einzurichten? Oder zumindest einen freien Plattentreiber zu benutzen? Ich kann ja schlecht auf dem Image, das ich im Workshop verteile, meinen kommerziellen hddriver installieren.
Die Pakete für XAAES und TeraDesk scheinen schlampig im EasyMiNT Paket integriert zu sein. Die Pakete, die beiliegen, heißem XAAES.ZIP und TERADESK.ZIP. Allerdings erwartet der Installer Pakete mit der Namenskonvention XAAESxxx.ZIP bzw. TDESKx_y.ZIP die damit ihre Versionsnummer im Namen tragen. Gut, es war für mich kein Problem, die Dateien umzubenennen. Aber solch ein Stolperstein für unbedarftere Anwender muß nicht sein.
Danach erfolgte der Reboot. Ich hatte zwar irgendwo im README gelesen, daß die Installation in 2 Stufen erfolgt. Und mir war klar, daß für den Zugriff auf die ext2 Partition schon MiNT mit dem Dateisstemtreiber laufen muß. Aber es wäre schön, wenn der Ablauf deutlicher beschrieben ist. Daß ich nach dem Booten erneut den Installer aufrufen muß, war mir nur durch das README allein nicht so klar. Das könnte einen unbedarften Anwender möglicherweise vor Probleme stellen.
Aber soweit bin ich nicht gekommen. Denn MiNT stürzt bei mir mit 2 Bomben ab. Es scheint zumindest nicht an den ladbaren Treibern zu liegen. Die hatte ich testweise deaktiviert. An AUTO-Orden Programmen ist nur XBOOT aktiv, keine ACCs (aber soweit war der Bootvorgang nicht gekommen). Hat schon mal jemand MiNT unter Hatari installiert und eine Idee? Möglicherweise eine Einstellung in Hatari für das emulierte System? Eigentlich enthält MiNT ja kaum hardwarenahe Routinen.
Tschüß
Michael
-
Da tust du EasyMiNT unrecht. Auf meinem Atari TT läuft der EasyMiNT Installer einwandfrei und ohne Fehler. Hatari ist halt kein Atari TT ...
Nimm EasyMiNT 1.90 -> http://atari.grossmaggul.de/download/em190.zip
-
Hallo Lukas,
Da tust du EasyMiNT unrecht. Auf meinem Atari TT läuft der EasyMiNT Installer einwandfrei und ohne Fehler. Hatari ist halt kein Atari TT ...
Naja, der Fehler mit den Dateinamen für XAAES und TeraDesk ist ja nun mal vorhanden und Tatsache. Wenn ich das durch umbenennen beheben, läuft auch der Installer. Belibt aber immer noch das Problem, welchen Festplattentreiber kann ich benutzen und auch mit dem Image weitergeben und der Absturz von MiNT.
Nimm EasyMiNT 1.90 -> http://atari.grossmaggul.de/download/em190.zip
Danke, das probier ich mal.
Tschüß
Michael
-
Ich habe mal EasyMiNT auf Hatari und einem 68000 System installiert. Partitioniert habe ich das ACSI Image mit HDDriver. Es gibt da natürlich einiige Klippen die man umschiffen muss ...
-
und der Absturz von MiNT.
Es würde helfen, die Debug-Ausgabe von Hatari dazu zu sehen. (Unter Windows musst Du sie mit der Kommandozeilenoption "-W" sichtbar machen.) Dort solltest Du beim Absturz mit zwei Bomben eine Zeile mit der Fehlermeldung sehen: Bus Error at address $....
Das gibt evtl. einen Hinweis auf in Hatari fehlende Hardware/Konfiguration.
-
Naja, der Fehler mit den Dateinamen für XAAES
Und wurde mit der 1.63 behoben.
-
Hi,
Naja, der Fehler mit den Dateinamen für XAAES
Und wurde mit der 1.63 behoben.
Tja, wenn es mal leichter wäre, eine offizielle download Quelle zu finden ...
Die Version 1.90 lief jetzt durch. Was rumzuumäkeln hab ich dennoch gefunden. Ich bevorzuge es, die erste Partition als GEM < 16 MB anzulegen (ist für AHDI, erster Teil des Workshops sogar nötig) aber EasyMiNT braucht mehr Platz auf der Bootpartition.
Tschüß
Michael
-
Hallo,
und der Absturz von MiNT.
Es würde helfen, die Debug-Ausgabe von Hatari dazu zu sehen. (Unter Windows musst Du sie mit der Kommandozeilenoption "-W" sichtbar machen.) Dort solltest Du beim Absturz mit zwei Bomben eine Zeile mit der Fehlermeldung sehen: Bus Error at address $....
Das gibt evtl. einen Hinweis auf in Hatari fehlende Hardware/Konfiguration.
Danke für den Tip. Da die MiNT Version aus EasyMiNT 1.90 sich auch mit 2 Bomben verabschiedet, werde ich das als nächstes testen.
Tschüß
Michael
-
Vor Hatari 2 lief die Atari TT Emulation nicht richtig. Wenn es nicht geht versuche mal ST mit 68030 + FPU, EmuTOS, 14MB ST Ram und TT Ram ...
-
Hallo,
Vor Hatari 2 lief die Atari TT Emulation nicht richtig. Wenn es nicht geht versuche mal ST mit 68030 + FPU, EmuTOS, 14MB ST Ram und TT Ram ...
Dann sollte es eigentlich funktionieren. Ich hab hatari 2.0.0
Ich hab den Log:
M68000 Bus Error reading at address $f00039 PC=$201a0.
Laut http://deunstg.free.fr/sct1/hardware.htm wäre es das IDE Data Output Register
----- 8>< ---------- 8>< ---------- 8>< ---------- 8>< ---------- 8>< ---------- 8>< -----
##############IDE Controller (Falcon, ST-Book, IDE cards) ###########
-------+-----+-----------------------------------------------------+----------
$F00000|long |Data Register |R/W
$F00005|byte |Error Register BIT 7 6 5 4 3 2 1 0|R
| |Bad block mark -----------------------' | | | | | | ||
| |Uncorrectable error --------------------' | | | | | ||
| |Media change -----------------------------' | | | | ||
| |ID-Field not found -------------------------' | | | ||
| |Media change requested -----------------------' | | ||
| |Command aborted --------------------------------' | ||
| |Track 0 not found --------------------------------' ||
| |DAM not found --------------------------------------'|
$F00009|byte |Sector Count Register |W
$F0000D|byte |Sector Number Register |W
$F00011|byte |Cylinder Low Register |W
$F00015|byte |Cylinder High Register |W
$F00019|byte |Drive Head Register |W
$F0001D|byte |Status Register |R
$F0001D|byte |Command Register |W
$F00039|byte |Alternate Status Register |R
$F00039|byte |Data Output Register |W
----- ><8 ---------- ><8 ---------- ><8 ---------- ><8 ---------- ><8 ---------- ><8 -----
Aber wer greift warum auf den Falcon IDE Port zu? Ich hab den hddriver so konfiguriert, daß er nur den ACSI Port bedient. Und MiNT sollte doch nicht direkt auf den IDE Port zugreifen? Da bin ich etwas ratlos.
Tschüß
Michael
-
Hallo
Vor Hatari 2 lief die Atari TT Emulation nicht richtig. Wenn es nicht geht versuche mal ST mit 68030 + FPU, EmuTOS, 14MB ST Ram und TT Ram ...
Das funktioniert. Damit bootet MiNT. Ich finde es zwar etwas unbefriedigend, daß der TT nicht funktioniert und ich quasi eine andere Maschine statt nur eine andere Platte mitbringen muß. Aber das reicht für den Workshop.
Leider bleibt noch das Problem mit dem Festplattentreiber.
Tschüß
Michael
-
Das Falcon-TOS sucht zuerst am IDE-Port nach einer bootfähigen Partition (also _bevor_ ein Plattentreiber gefunden wird), erst wenn da nichts gefunden wird, kommen SCSI und schließlich die Floppy dran.
Das TT-TOS sucht zuerst am SCSI-Port nach einer bootfähigen Partition (also _bevor_ ein Plattentreiber gefunden wird), erst wenn da nichts gefunden wird, kommen ACSI und schließlich die Floppy dran.
Anscheinend ist in Hatari nicht richtig berücksichtigt, daß weder am Falcon eine IDE-Platte hängen muß noch am TT eine SCSI-Platte (und wenn doch, dann müssen die auch nicht bootfähig sein).
Die zwei Bömbchen, die zu sehen waren, haben also weder mit MiNT noch mit dem HD-Treiber etwas zu tun.
-------
XHDI-fähige HD-Treiber gibt es afaik drei, nämlich CBHD, HDDRIVER und den von PPERA. Alle drei können sowohl SCSI als auch ACSI als auch IDE bedienen und sollten für den Workshop geeignet sein.
Von HDDRIVER gibt es eine (eingeschränkte) Demo-Version.
-------
Eine Installation von MiNT ist grundsätzlich stinkeinfach und kinderleicht. Warum das durch EasyMiNT & Co. so kompliziert gemacht wird, war mir immer schon rätselhaft.
Man kann nämlich völlig ohne besondere Datei-Systeme (ie. für LNX oder EXT) auskommen und braucht auch keine Unox-artige Ordnerstruktur.
Wie einfach MiNT installiert werden kann, hat exemplarisch Atari selber gezeigt, nämlich mit seinem MultiTOS. Daß dieses sich nicht hat durchsetzen können, das lag imho an dessen Bugs, ie. weil es nicht stabil war.
Erst mit NAES änderte sich das, aber da hatte uns Atari schon verlassen...
Für MiNT_1.19.cur empfehle ich den Helmut-Kernal.
-
Die MiNT/XaAES Installation ist recht einfach aber bei EasyMiNT geht es ja darum eine komplette SpareMiNT UNIX Umgebung mit zu Installieren und das ist wegen der RPM Pakete schon schön mit EasyMiNT ...
Unter OSX/macOS habe ich keine Probleme mit Hatari und HDDriver. Ich lege unter OSX/macOS ein leeres MSDOS Image mit Masterbootrecord an, benenne es in IMG um und trage es in Hatari ein als ACSI Image. Starte Hatari mit HDDriver als .ST Image in Laufwerk A:\ und partitioniere das MSDOS Image wie ich möchte ...
-
Ich finde es zwar etwas unbefriedigend, daß der TT nicht funktioniert
Alleine davon, etwas unbefriedigend zu finden, wird Open-Source-Software nicht besser. Also: Bitte Bug-Report an Hatari-Entwickler verfassen.
-
Hallo;
Alleine davon, etwas unbefriedigend zu finden, wird Open-Source-Software nicht besser. Also: Bitte Bug-Report an Hatari-Entwickler verfassen.
Naja, dazu mußte ich ja erst mal wissen, welcher Teil die Probleme macht, also ob es ein Fehler in Hatari, MiNt, ... ist, damit ich den Bugreport an der richtigen Stelle einkippen kann. Aber mit deiner Analyse kann ich das ja jetzt machen.
Tschüß
Michael
-
Hallo,
ich hab jetzt eine zwar nicht richtig tolle, aber gute Nachrichten. Die Tatsache, daß es mit cbhd nicht funktionierte, lag an der in EasyMiNT 1.6 verwendeten MiNT Version. Ich war stutzig geworden, weil da als XHDI Version mit hddriver auch nur Müll angezeigt wurde, obwohl es aber funktionierte. Ich hab also mit EasyMiNT 1.90, wo auch die XHDI Version von hddriver korrekt angezeigt wurde, einen neuen Test gemacht. Es ist etwas umständlich, da ich auch ein kommerzielles Tool mitbenutzen mußte. Aber ich hab zumindest für den Workshop ein Plattenimage nur mit freien Tools. Das Vorgehen bei mir ist wie folgt:
- Eine leere Datei als Plattenimage erzeugen. Für den Workshop hab ich eine 200 MB HD angelegt.
- als Maschine in Hatri einen ST mit 68030, genug Speicher, Extended Atari Screen und TOS 2.06 anlegen
- die virtuelle Festplatte mit hddriver formatieren und partitionieren. Die Partition für das ext2 Dateisystem als RAW anlegen. Da ich nur ein Basis System installiere, braucht man als Boot Partition ca. 25 MB, für EasyMiNT ca 45. Mit dem Tool von cbhd war es mir nicht möglich, nach anlegen der Bootpartition den restlichen Speicher auf weitere Partitionen zu verteilen.
- cbhd installieren. Mit einem Diskmonitor das SCSI Treiber Modul für TT laut FAQ deaktivieren. Ich hab gleich alle Treiber Module bis auf ACSI deaktiviert
- EasyMiNT auf die Platte kopieren. Dazu kann z.B. die Hatari Funktionalität "GEMDOs Drive" benutzt werden, die quais als "Tauschpartition" vom Atari und vom Host erreichbar ist.
- EasyMiNT installieren. Das lief dann mit der 1.90 tatsächlich sauber durch.
-
Naja, dazu mußte ich ja erst mal wissen, welcher Teil die Probleme macht, also ob es ein Fehler in Hatari, MiNt, ... ist, damit ich den Bugreport an der richtigen Stelle einkippen kann. Aber mit deiner Analyse kann ich das ja jetzt machen.
Wenn Du mir das Disk-Image und die Hatari-Konfigurationsdatei zur Verfügung stellst, mit der sich der Absturz reproduzieren lässt, gucke ich's mir gerne mit an und trage meine Analyse zu Deinem Bugreport bei. PM an mich, falls Du einen Server brauchst, um die Dateien hochzuladen...
-
Hallo,
Danke für deine Analyse. Aber ich hab da noch ein paar Fragen, weil ich das so gedanklich nicht nachvollziehen kann.
Das Falcon-TOS sucht zuerst am IDE-Port nach einer bootfähigen Partition (also _bevor_ ein Plattentreiber gefunden wird), erst wenn da nichts gefunden wird, kommen SCSI und schließlich die Floppy dran.
Das TT-TOS sucht zuerst am SCSI-Port nach einer bootfähigen Partition (also _bevor_ ein Plattentreiber gefunden wird), erst wenn da nichts gefunden wird, kommen ACSI und schließlich die Floppy dran.
Anscheinend ist in Hatari nicht richtig berücksichtigt, daß weder am Falcon eine IDE-Platte hängen muß noch am TT eine SCSI-Platte (und wenn doch, dann müssen die auch nicht bootfähig sein).
Die zwei Bömbchen, die zu sehen waren, haben also weder mit MiNT noch mit dem HD-Treiber etwas zu tun.
Was mich daran irritiert ist, daß ich aber auf dem emulierten TT ein TOS 3.06 einsetze. Das sollte doch gar nicht versuchen, auf den IDE Port des Falcons zuzugreifen? Der Versuch, zuerst auf den (in Hatari nicht vorhandenen) SCSI Port zuzugreifen scheint ja kein Problem zu sein. Denn der virtuelle TT bootet ja problemlos von dem ACSI Plattenimage. Der Absturz mit 2 Bomben kommt ja erst, wenn ich MiNT boote. Und da ist der Festplattentreiber ja schon geladen. Deshalb verstehe ich an deiner Erklärung noch nicht, wieso ein IDE Zugriff erfolgt.
XHDI-fähige HD-Treiber gibt es afaik drei, nämlich CBHD, HDDRIVER und den von PPERA. Alle drei können sowohl SCSI als auch ACSI als auch IDE bedienen und sollten für den Workshop geeignet sein.
Von HDDRIVER gibt es eine (eingeschränkte) Demo-Version.
Also hddriver ist nicht geeignet, da die Demo Version zu stark eingeschränkt ist. Ich kann aber meinen hddriver zum Einrichten verwenden, da ich da komfotabler eine RAW Partition anlegen kann. Der cbhd hat sich für EasyMiNT 1.90 als geeignet erwiesen, die Probleme mit EasyMiNT 1.6 lagen wohl an der verwendeten MiNT Version. Siehe dazu meinen anderen Post.
Eine Installation von MiNT ist grundsätzlich stinkeinfach und kinderleicht. Warum das durch EasyMiNT & Co. so kompliziert gemacht wird, war mir immer schon rätselhaft. ...
Der größte Teil der Probleme hab ich ja wohl durch die Verwendung von Hatari als Emulator, der MiNT Version in EasyMiNT 1.6 und mein Wunsch, natürlich keinen kommerziellen Festplattentreiber zu verwenden.
Ansonsten wurde ja schon darauf hingewiesen, daß das Ziel ist, auch eine SpareMiNT Umgebung einzurichten. Ich hab ja in der Vergangenheit auch schon alles durch. Ich hatte die Partition für die UNIX Tools sogar noch manuell eingerichtet, damals mit Minix Dateisystem. Da ich das aber auf realer Hardware gemacht hatte und eine Lizenz für hddriver hab, hatte ich diese Problem nicht. Und ich hatte sogar N.AES gekaut und installiert. Später dann per Bootmanager selektierbar, ob N-.AES, oAESis oder XAAES gebootet wird.
Ich denke mal, wenn ich das vorbereitete Plattenimage mit der passenden config mitnehme, dann läuft die EasyMiNT Installation durch und man hat zum einen einen Atari mit Multitasking und GEM und kann zum anderen zeigen, daß sich das System an UNIX bzw. Posix anlehnt.
Tschüß
Michael
-
Hallo,
Wenn Du mir das Disk-Image und die Hatari-Konfigurationsdatei zur Verfügung stellst, mit der sich der Absturz reproduzieren lässt, gucke ich's mir gerne mit an und trage meine Analyse zu Deinem Bugreport bei. PM an mich, falls Du einen Server brauchst, um die Dateien hochzuladen...
Danke für dein Angebot. Ich bau jetzt erst mal das zusammen, was ich für den Workshop mitnehme. Dann werde ich ich nochmals ein System entsprechend aufsetzen. Server zum Hochladen ist kein Problem, da hab ich was.
Danke und Tschüß
Michael
-
Mal nebenbei ... @ST-Oldie Du hast mal oAESis installiert und mit gearbeitet? Ich hatte mir das mal geladen und wollte damit auch mal einen Versuch wagen, aber ich hab's dann doch erstmal gelassen, weil es mir zum Ausprobieren doch etwas zu komplex erschien. Leider gab's im Netz nicht wirklich Informationen dazu. Mich würden mal Deine Erfahrungen mit oAESis interessieren. Mich reizt es immer noch, das mal auszuprobieren.
-
Anscheinend ist in Hatari nicht richtig berücksichtigt, daß weder am Falcon eine IDE-Platte hängen muß noch am TT eine SCSI-Platte (und wenn doch, dann müssen die auch nicht bootfähig sein).
Der Fehler kommt aber scheinbar nicht aus dem HATARI, sondern aus dem MiNT-Kernel? Schließlich wurde ja als Plattform in HATARI ein TT voreingestellt, und der hat ja im Original keinen IDE-Port. Und TOS 3.06 spricht auch dagegen, dass TOS irgendwas mit IDE tut.
Von HDDRIVER gibt es eine (eingeschränkte) Demo-Version.
Die Demo-Version schreibt offensichtlich keine Daten. Ich denke, das ist äußerst unpraktisch für eine MiNT-Installation durchzuführen.
-
Die zwei Bömbchen, die zu sehen waren, haben also weder mit MiNT noch mit dem HD-Treiber etwas zu tun.
... Der Absturz mit 2 Bomben kommt ja erst, wenn ich MiNT boote. Und da ist der Festplattentreiber ja schon geladen. Deshalb verstehe ich an deiner Erklärung noch nicht, wieso ein IDE Zugriff erfolgt.
Sorry, da bin ich mit meiner Aussage etwas zu weit gegangen. Sie gilt afaik nur bis HDDRIVER_8.45; danach nämlich verlangt er von MiNT eine Auskunfts-Funktion, die wohl bis heute nicht eingebaut ist (und bis einschl. MiNT_1.18 schon gar nicht, also auch nicht in EasyMiNT).
Versuche also mal eine ältere Version von HDDRIVER, oder ersetze ihn durch CBHD, _bevor_ Du das erste Mal MiNT bootest. Dann sollten imho keine zwei Bömbchen erscheinen.
Schon TOS_2.06 kann mit IDE umgehen, auch 3.06 - bloß booten kann afaik das TT-TOS ungepätscht nicht von IDE (obwohl das, falls mich meine Erinnerung nicht täuscht, mit 2.06 schon möglich ist!).
Wenn Du den Austausch von HDDRIVER gegen CBHD durch pätschen mit SED oä. erledigst, dann bleibt ja immer noch ein Stückchen Commerz erhalten. Also stattdessen die Boot-Fähigkeit durch das Inst.-Tool von CBHD vornehmen (und natürlich HDDRIVER.sys aus C:\ entfernen).
Auch die UNIX-Tools kann man ohne MINIX oder EXT2 einrichten. Nötig ist für deren einige (nicht alle) aber LFN (was man ohne UNOX sonst auch nicht unbedingt braucht).
PS: - als Maschine in Hatri einen ST mit 68030, genug Speicher, Extended Atari Screen und TOS 2.06 anlegen
Zum 68030 paßt das TOS_2.06 nicht mehr.
-
Zum 68030 paßt das TOS_2.06 nicht mehr.
Naja, dann versuche mal auf einem 030 aufgebohrten ST ein ungepatchtes TOS 3.06 laufen zu lassen....
Und, bist du sicher, dass im TT-TOS 3.06 irgendwelche IDE-Routinen drin sind, jenseits von einem Plattetreiber zu booten? (also genau das was du schreibst, dass es nicht da ist?) Alles darüber hinaus wäre doch Aufgabe des Plattentreibers...? Der Atari holt sich ja eigentlich so aus dem Sumpf, dass er aus dem Bootsektor einer Platte was lädt, was es ihm ermöglicht, den eigentlichen Plattentreiber von der Platte zu holen, und dieser Plattentreiber dann komplett übernimmt. Dieser Funktionsteil im TOS ist für die jeweiligen Platteninterfaces ist meines Wissens nach recht primitiv, einfach und kurz. Ich muss nochmal nachlesen, wie LF bzw. GAGA das TOS 3.06 gepatcht haben, damit Thunderstorm booten kann, das hat soweit ich mich aus dem Thread erinnern konnte, irgendwelche Nachteile, die mir ganrnicht schmeckten.
-
Hallo,
Wenn Du mir das Disk-Image und die Hatari-Konfigurationsdatei zur Verfügung stellst, mit der sich der Absturz reproduzieren lässt, gucke ich's mir gerne mit an und trage meine Analyse zu Deinem Bugreport bei. PM an mich, falls Du einen Server brauchst, um die Dateien hochzuladen...
Du kannst das Paket unter
https://drive.google.com/file/d/0B0_7fXzuvOiPM28zdkVHa05LazA/view?usp=sharing
runterladen.
Ich hab das Plattenimage für den Workshop neu erstellt und das dann in dem emulierten TT eingebunden. Die Crashes sind jetzt an anderen Adressen! Erscheinen aber zuverlässig.
Tschüß
Michael
Der Absturz kommt i
-
Anbei mal ein gefundenes hatari-mint-myaes ready-to-go System.
Einfach auspacken und unter hatari emulation HD-> gdos Pfad anpassen.
-
Hallo,
Sorry, da bin ich mit meiner Aussage etwas zu weit gegangen. Sie gilt afaik nur bis HDDRIVER_8.45; danach nämlich verlangt er von MiNT eine Auskunfts-Funktion, die wohl bis heute nicht eingebaut ist (und bis einschl. MiNT_1.18 schon gar nicht, also auch nicht in EasyMiNT).
Versuche also mal eine ältere Version von HDDRIVER, oder ersetze ihn durch CBHD, _bevor_ Du das erste Mal MiNT bootest. Dann sollten imho keine zwei Bömbchen erscheinen.
Das ist ja genau das, was ich gemacht habe. Ich hab doch einen Post von meinem Vorgehen in diesem Thread:
- Formatieren und Partitionieren mit hddriver
- cbhd installieren
Damit läuft ab der EasyMiNT Installation schon cbhd und natürlich auch wenn ich MiNT boote. Von der virtuellen Platte wurde immer nur mit cbhd gebootet, nie mit hddriver. Wenn es interessiert, kann ich ja noch mal einen Test mit hddriver und EasyMiNT 1.90 machen.
Ach ja, mein hddriver ist eine ältere Version, da ich die letzten Updaes nicht mitgemacht hatte.
Wenn Du den Austausch von HDDRIVER gegen CBHD durch pätschen mit SED oä. erledigst, dann bleibt ja immer noch ein Stückchen Commerz erhalten. Also stattdessen die Boot-Fähigkeit durch das Inst.-Tool von CBHD vornehmen (und natürlich HDDRIVER.sys aus C:\ entfernen).
Das hast du völlig falsch verstanden. Ich habe mit hddriver nur partitioniert. Nicht den hddriver installiert! Anschließend konnte ich mit dem CBHDCONF.APP aus dem cbhd Paket den cbhd auf der Platte installiern. Warum auch immer hat die Installation aber nur den Bootsektor geschrieben und ich mußte cbhd.sys von Hand auf c: kopieren. Die Platte hat nie den Bootsektor aus dem hddrive rPaket oder hddriver.sys gesehen.
Das Patchen war für cbhd.sys nötig, um das SCSI Modul für den TT zu deaktivieren, da der Timeout sehr lang ist. Das ist auch so im FAQ des cbhd beschrieben.
Auch die UNIX-Tools kann man ohne MINIX oder EXT2 einrichten. Nötig ist für deren einige (nicht alle) aber LFN (was man ohne UNOX sonst auch nicht unbedingt braucht).
Klar, der FAT Treiber in MiNT kann auch lange Dateinamen. Das ist (oder war) zumindest für die einzelnen Partitionen einstellbar. Aber das Installieren von MiNT ist eher de Abschluß, der zeigt wie die Entwicklung von TOS weiterging. Da ist die automatische Installation von EasyMiNT gut genug. Es würde den Zeitrahmen sprengen jetzt noch MiNT ausführlich zu erklären. Es ging ja erst mal um die klassischen Ataris für Leute, die damit noch keinen Kontakt hatten.
Zum 68030 paßt das TOS_2.06 nicht mehr.
Da ist Hatari aber andere Meinung! Ich hatte auch gedacht, wenn ich einen ST konfiguriere und als Prozessor einen 68030 nehme, muß ich auch TOs 3.xx verwenden. Aber Hatari erlaubt TOS 3.xx nur, wenn als System ein TT eingestellt ist. Deshalb mußte ich für diese Kombination ein anderes TOS einsetzen.
Tschüß
Michael
-
Das ist völlig konsequent von HATARI, TOS 3.06 nicht zuzulassen, wenn als Voreinstllung ein ST, mit egal welchem Prozessor, eingestellt ist. Denn im TT schlummern ein paar Chips, die ein ST nicht hat (zweiter MFP, TT-Shifter, SCSI-Controller, ...), die aber TOS 3.06 initilaisieren möchte und bei Nichtvorhandensein auf die Schnauze fällt. Genausowenig, wie man ein ungepatchtes TOS 4.04 auf einem (virtuellen) TT oder gar ST(E) loslassen wollte, auch das würde fatal auf die Schnauze fallen.
Das TOS 3.06 für die PAK68/3 ist recht heftig durchgepatcht, damit es hochkommt.
Vielleicht macht es Sinn, es in Hatari nochmal mit den TT-Voreinstellungen und der neuesten EasyMiNT-Version zu probieren?
-
Hi,
Das ist völlig konsequent von HATARI, TOS 3.06 nicht zuzulassen, ...
Das TOS 3.06 für die PAK68/3 ist recht heftig durchgepatcht, damit es hochkommt.
Ach das war es. Ich meinte noch mich zu erinern, auf der PAK/3 ein TOS 3.06 zu haben. Aber das es da einige Patches gab, da konnte ich nicht nicht mehr erinnern. Ist auch schon einige Jahre her und dann durch einen TT ersetzt worden.
Vielleicht macht es Sinn, es in Hatari nochmal mit den TT-Voreinstellungen und der neuesten EasyMiNT-Version zu probieren?
Welches ist denn die letzte EasyMiNT Version? Ich hab die letzten Tests (wo ich die Abstürze hab) mit der Version 1.90 gemacht. Und die enthält im readme die Info, daß die Entwicklung eingestellt wird. Das dürfte dann die letzte Version sein?
Tschüß
Michael
-
Das ist sie. Ältere würde ich nicht mehr verwenden.
-
Ich hab das Plattenimage für den Workshop neu erstellt und das dann in dem emulierten TT eingebunden. Die Crashes sind jetzt an anderen Adressen! Erscheinen aber zuverlässig.
OK, ich weiß nicht, was Du vorher mit IDE gesehen hattest. Jetzt zeigt eine kleine Session mit dem Hatari-Debugger aber, dass der Absturz beim (versuchten) Zugriff auf den SCC (zusätzliche serielle Schnittstelle im TT) kommt. Nach meinem Verständnis des Hatari-Quellcodes wird der SCC tatsächlich nicht emuliert. => Da hast Du was für Deinen Bugreport. Evtl. wäre es auf kurze Sicht besser, die Zugriffe auf den SCC in Hatari wenigstens ins Leere laufen zu lassen, statt mit einem Buserror zu reagieren.
Ich dachte erst, ich könnte das Problem beheben, indem ich einfach SCC.XDD in Deiner MiNT-Installation lösche/umbenenne. Leider greift aber auch der Kernel (via XBIOS-Funktionen Bconmap und Rsconf) schon auf den SCC zu, sodass es bereits dort zum Absturz kommt. Man müsste also entweder TOS patchen, den SCC nicht mehr anzusprechen oder bevorzugt das Problem in Hatari lösen.
-
Dachte ich mir doch das eine Atari TT Emulation mit Hatari immer nicht nicht läuft ...
-
Dachte ich mir doch das eine Atari TT Emulation mit Hatari immer nicht nicht läuft ...
Das ist eine zu verallgemeinernde Schlussfolgerung. Die -- immer noch als experimentell(!) bezeichnete -- TT-Emulation von Hatari läuft schon ziemlich gut und ich würde die harte Arbeit der Entwickler diesbezüglich nicht mit den Worten "läuft immer noch nicht" zusammenfassen. Nur sind es manchmal Kleinigkeiten, wie die hier die fehlende SCC-Unterstützung, die einem einen Strich durch die Rechnung machen.
-
Da ist Hatari aber andere Meinung!
Da hätte ich dann mit Hatari eine echte Meinungsverschiedenheit. Wie kann Hatari für einen ST einen 68030 zulassen? Die ´aufgebohrten´ STs benutzen doch einen 68020? Und der braucht dann ein angepaßtes TOS extra...
Wenn schon ST, dann lieber 68000 - sonst aber Falcon im Hatari.
-------
Ad 1ST1 : Weiß nicht, was Dir am Thunder nicht schmeckt. Ich jedenfalls sehe da kein Problem. Noch einmal ganz deutlich: Zwischen generellem Zugriff auf IDE und der Boot-Fähigkeit gibt es keine Implikation (ibs. keinen kausalen Zusammenhang). Man kann am TT von SCSI oder ACSI oder Floppy booten und trotzdem hinterher auf IDE zugreifen (mit dazu fähigem Treiber). Allerdings habe ich meinen Thunder noch nicht installiert (der muß warten bis zu kühleren Tagen im Herbst), sondern verlasse mich auf die Aussagen von @Gaga und @tuxie , daß IDE mit Thunder auch mit originalem TOS_3.06 funzt (aber eben nur mit gepätschtem auch bootet).
Zum 68030 paßt das TOS_2.06 nicht mehr.
Naja, dann versuche mal auf einem 030 aufgebohrten ST ein ungepatchtes TOS 3.06 laufen zu lassen....
Es würde mich wundern, wenn im HATARI auch _alles_ ´aufgebohrte´ läuft.
-------
@nebulus07 , bitte mal für Fußgänger: Die sechs Teile ´runterladen und aneinanderhängen (womit?), dann das ca. 7MB große 7z auspacken (womit?) und dann _was_? starten ?
-
@ari.tao, was anderes habe ich ja auch nicht behauptet. Von IDE booten und später nach dem Laden des Plattentreiber zugreifen sind zwei ganz unterschiedliche paar Schuhe! Wenn es anders wäre, bräauchte man ja garkeinen Plattentreiber, so wie im Amiga oder Archimedes - oder bei DOS-PCs. (da überall kommt die notwendige Software für den Betrieb der jeweiligen Platteninterfaces aus dem ROM der jeweiligen Erweiterung(s-Karte - und Windows 9x und später lassen wir mal aus der Betrachtung draußen!.)
-
Die ´aufgebohrten´ STs benutzen doch einen 68020? Und der braucht dann ein angepaßtes TOS extra...
Die aufgebohrten STs nutzen alles mögliche, auch 68020, aber auch 68030. Davon gab’s ja viele Varianten, Gadget-by-small, SST, Makro/CDE, PAK68/3 etc.pp.
Und die gab es mit gepatchtem TOS 3.06, KAOS-TOS, sogar ein gepatchtes 1.06 sah ich mal, IIRC.
-
Hallo,
OK, ich weiß nicht, was Du vorher mit IDE gesehen hattest.
das hatte ich mich nach dem letzten Test auch gefragt. Ich hatte ja schon gesagt, daß ich jetzt eine andere Adresse sehe.
Jetzt zeigt eine kleine Session mit dem Hatari-Debugger aber, dass der Absturz beim (versuchten) Zugriff auf den SCC (zusätzliche serielle Schnittstelle im TT) kommt. Nach meinem Verständnis des Hatari-Quellcodes wird der SCC tatsächlich nicht emuliert. => Da hast Du was für Deinen Bugreport. Evtl. wäre es auf kurze Sicht besser, die Zugriffe auf den SCC in Hatari wenigstens ins Leere laufen zu lassen, statt mit einem Buserror zu reagieren.
Danke :-) Das ging ja richtig schnell. Wie geht denn das mit dem hatari Debugger?
Ok, wenn die TT Emulation sowieso noch als experimentell beschrieben wird, ist das wohl noch weniger ein Bugreport sondern eher ein Vorschlag. Aber das kann ich ja mal machen.
Ich dachte erst, ich könnte das Problem beheben, indem ich einfach SCC.XDD in Deiner MiNT-Installation lösche/umbenenne.
Die XDDs zu deaktivieren hatte ich auch schon versucht.
Tschüß
Michael
-
Hallo,
Dachte ich mir doch das eine Atari TT Emulation mit Hatari immer nicht nicht läuft ...
Och, so schlecht läuft die auch nicht. Ich hab ja nur das Einrichten durchgespielt bis hin zur Installation einer Festplatte und nichts anspuchsvolles gestartet. Aber das hat funktioniert. Man sollte nur in den Festplattentreibern das Scannen des SCSI Bus des TTs deaktivieren. Da hängt dann der Plattentreiber.
Tschüß
Michael
-
@ari.tao
Einfach die .pdf von den 7zip dateien entfernen und dann auf die .001 klicken und entpacken!??
Ich benutze dafür das Programm PowerArchiver unter Windowwz..
Ich hätte auch gerne in einem großen Zip hochgeladen, ging aber nicht.
-
Danke :-) Das ging ja richtig schnell. Wie geht denn das mit dem hatari Debugger?
Der Hatari-Debugger ist ein derart mächtiges Tool, dass ich in einem Posting keine allgemeine Anleitung liefern kann. Aber für den konkreten Fall: Mit der Kommandozeilenoption "-D -W" gestartet, springt Hatari bei jeder Exception in den Debugger. Es ist normal, dass direkt beim Start von TOS ein paar Exceptions ausgelöst werden, hier kann man also am Debugger-Prompt ein paar mal "c" (für Continue) drücken.
Irgendwann kommt man aber an den Punkt, an dem Du sonst die zwei Bomben siehst. Dann steht im Debugger:
Bus error exception at 0xe0312a!
CPU=$e0312a, VBL=1704, FrameCycles=66976, HBL=32, LineCycles=1952, DSP=N/A
$00e0312a : 14bc 000c move.b #$c,(a2)
Es ist also ein Bus-Error beim Zugriff auf die Adresse aufgetreten, die in A2 steht. Eingabe von "r" (für Registers) liefert:
D0 0000000B D1 00000008 D2 0000000F D3 00000000
D4 21240001 D5 0000FFFF D6 0000FFFF D7 00000000
A0 000017A6 A1 00E031E4 A2 FFFF8C85 A3 FFFFFFFF
A4 FFFFFFFF A5 00000000 A6 00000A46 A7 01086D0E
USP 01086DAE ISP 01086D0E SFC 00000000 DFC 00000000
CACR 00003111 VBR 00000000 CAAR 00000000 MSP 00000000
Also ein Zugriff auf $FFFF8C85, das Kontrollregister des SCC, Kanal B. Außerdem zeigt die Codeadresse $00e0312a, dass der Absturz in TOS-Code passiert, dass also MiNT hier nicht direkt auf die Adresse zugreift.
Dank Thorsten Ottos Listing von TOS 3.06 kann man schnell herausfinden, dass $00e0312a in der Rsconf-Funktion für das Device 7 (SCC Kanal B) liegt. Ab hier wird's spekulativ, aber man kann im Freemint-Quellcode sehen, dass z.B. in xbios.c, Funktion init_bconmap für alle vorhandenen Devices Rsconf aufgerufen wird. Vermutlich ist das der Aufruf, der zum Absturz führt.
-
Hi,
Der Hatari-Debugger ist ein derart mächtiges Tool, dass ich in einem Posting keine allgemeine Anleitung liefern kann.
Klar ...
Aber für den konkreten Fall: Mit der Kommandozeilenoption "-D -W" gestartet, springt Hatari bei jeder Exception in den Debugger. Es ist normal, dass direkt beim Start von TOS ein paar Exceptions ausgelöst werden, hier kann man also am Debugger-Prompt ein paar mal "c" (für Continue) drücken.
Aber das ist schon mal hilfreich. Ich hate zwar mal gehört, daß Hatari einen Debugger hat. Aber mich bisher nicht weiter damit beschäftigt.
Irgendwann kommt man aber an den Punkt, an dem Du sonst die zwei Bomben siehst. Dann steht im Debugger:
Bus error exception at 0xe0312a!
CPU=$e0312a, VBL=1704, FrameCycles=66976, HBL=32, LineCycles=1952, DSP=N/A
$00e0312a : 14bc 000c move.b #$c,(a2)
Toll. Der Debugger scheint ja seht hilfreich zu sein. Die Ausgaben verstehe ich. Ich kann ja 68k Assembler. Bei meinem letzten Arbeitgeber hatte ich für einen 68360 programmiert. Und irgendwann auch eine gewisse Routine, den Assemblercode dem C Code zuzuordnen, wenn ich mal eine Software ohne Debuginfos debuggt hatte.
Also ein Zugriff auf $FFFF8C85, das Kontrollregister des SCC, Kanal B. Außerdem zeigt die Codeadresse $00e0312a, dass der Absturz in TOS-Code passiert, dass also MiNT hier nicht direkt auf die Adresse zugreift.
Dank Thorsten Ottos Listing von TOS 3.06 kann man schnell herausfinden, dass $00e0312a in der Rsconf-Funktion für das Device 7 (SCC Kanal B) liegt. Ab hier wird's spekulativ, aber man kann im Freemint-Quellcode sehen, dass z.B. in xbios.c, Funktion init_bconmap für alle vorhandenen Devices Rsconf aufgerufen wird. Vermutlich ist das der Aufruf, der zum Absturz führt.
Mir fällt dazu noch ein, daß MiNT auch seriell Debugausgaben machen kann. Wenn ich das disable, tritt der Absturz trotzdem auf. Möglicherweise ist das aber der Grund für den Zugriff auf den SCC. Dann wärst du mit deiner Spekulation richtig. Das TOS 3.06 Listing kenne ich nicht. Späteswtens da hätte ich passen müssen.
Vielen Dank und tschüß
Michael
-
Anbei mal ein gefundenes hatari-mint-myaes ready-to-go System.
Einfach auspacken und unter hatari emulation HD-> gdos Pfad anpassen.
@ari.tao
Einfach die .pdf von den 7zip dateien entfernen und dann auf die .001 klicken und entpacken!??
Ich benutze dafür das Programm PowerArchiver unter Windowwz..
Ich hätte auch gerne in einem großen Zip hochgeladen, ging aber nicht.
Hmmm, @nebulus07 , kann es sein, daß Du diesen Link hier
http://myaes.lutece.net/telechargement/myhatari.zip
aus dem engl. Forum
http://www.atari-forum.com/viewtopic.php?f=51&t=29989
schön vernebelt hast??
Gibt es Unterschiede?
-
Hallo,
OK, ich weiß nicht, was Du vorher mit IDE gesehen hattest. Jetzt zeigt eine kleine Session mit dem Hatari-Debugger aber, dass der Absturz beim (versuchten) Zugriff auf den SCC (zusätzliche serielle Schnittstelle im TT) kommt.
das hatte mir noch keine Ruhe gelassen
Also ein Zugriff auf $FFFF8C85, das Kontrollregister des SCC, Kanal B. Außerdem zeigt die Codeadresse $00e0312a, dass der Absturz in TOS-Code passiert, dass also MiNT hier nicht direkt auf die Adresse zugreift.
Wenn ich mir nochmals die stderr.txt der letzten Session mit dem Absturz ansehe und die Bus Errors suche, finde ich dort:
Bus error wput at 0041fffe
Bus error wput at ffd000e0
Bus error wput at 0181fffe
M68000 Bus Error reading at address $f00001 PC=$20b8c.
Nur nix mit deiner Adresse. Oder bin ich einem Irrtum aufgesessen und finde in der Datei gar nicht einen Log zum Absturz?
Tschüß
Michael
-
Anbei mal ein gefundenes hatari-mint-myaes ready-to-go System.
Einfach auspacken und unter hatari emulation HD-> gdos Pfad anpassen.
@ari.tao
Einfach die .pdf von den 7zip dateien entfernen und dann auf die .001 klicken und entpacken!??
Ich benutze dafür das Programm PowerArchiver unter Windowwz..
Ich hätte auch gerne in einem großen Zip hochgeladen, ging aber nicht.
Hmmm, @nebulus07 , kann es sein, daß Du diesen Link hier
http://myaes.lutece.net/telechargement/myhatari.zip
aus dem engl. Forum
http://www.atari-forum.com/viewtopic.php?f=51&t=29989
schön vernebelt hast??
Gibt es Unterschiede?
Genau, da hatte ich es auch her! Ich hatte den Link nicht mehr, sondern nur doch die Zip Datei und die konnte ich hier wegen dem 2MB Limit nicht hochladen, also musste ich es splitten...
-
Bus error wput at 0041fffe
Bus error wput at ffd000e0
Bus error wput at 0181fffe
M68000 Bus Error reading at address $f00001 PC=$20b8c.
Nur nix mit deiner Adresse. Oder bin ich einem Irrtum aufgesessen und finde in der Datei gar nicht einen Log zum Absturz?
Das oben sind die Bus-Errors direkt beim Start von TOS, über die Du hinwegsehen kannst. Es scheint, dass später im Bootprozess die Adressen von Bus-Errors nicht mehr im Log angezeigt werden. Ich habe keine Zeit, nachzusehen, wieso. Meine o.g. Analyse (bzgl. SCC) ist trotzdem korrekt, wie Du Dich mit dem Debugger überzeugen kannst.
-
Hi,
Das oben sind die Bus-Errors direkt beim Start von TOS, über die Du hinwegsehen kannst. Es scheint, dass später im Bootprozess die Adressen von Bus-Errors nicht mehr im Log angezeigt werden. Ich habe keine Zeit, nachzusehen, wieso. Meine o.g. Analyse (bzgl. SCC) ist trotzdem korrekt, wie Du Dich mit dem Debugger überzeugen kannst.
Nö, ist auch nicht nötig da nachzusehen. Ich vertraue da deiner Analyse. Ich war nur etwas irritiert, weil ich die Adresse deiner Analyse nicht gesehen hab. Aber das wäre dann auch eine Frage an die Hatari Entwickler.
Tschüß
Michael
-
Wie ist denn jetzt der Stand der Dinge? Sind die 2 Bömbchen auch mit EM190 immer noch da?
Ich habe mal Hatari mit dem oben verlinkten MyHatari-Drive auf meinem Labtop (Win_8.1) laufen lassen. Der enthält den MiNT-Kernal 1.19.0.alpha, bootet ohne Bömbchen. Dann habe ich den Kernal durch den Helmut-Kernal ersetzt. Dazu war es nötig, im MiNT.ini den Debuglevel auf 0 zu setzen (sonst kommt eine Sintflut an Meldungen, iGgs. zum vorherigen Kernal). Bootet auch ohne Bömbchen.
MyHatari ist im Anlauf etwas mickrig (grab0001), aber nach Änderung von ein paar Optionen (Key F12) dann doch ganz ansehnlich (grab0002).
Das geschah mit der Option ´Falcon´ - nach Änderung auf ´TT´ bleibt Hatari mitten im Boot hängen. Letzte Meldung (grab0003):
"Launching init: u:/c/gemsys/myaes/myaes68k.prg ..."
Ups, jetzt kann ich den Wechsel Falcon -> TT nicht mehr rückgängig mache - wo zum Kukkuk hat Hatari sein .cfg etc. abgelegt?
Ahh, jetzt doch noch gefunden: In Tao/AppData/Local/Hatari/
-
Der Unterschied ist in ari.taos Screenshots sofort sichtbar: EmuTOS. Ginge es @ST-Oldie nur darum, EasyMiNT auf Hatari zum Laufen zu bringen, wäre das evtl. ein Workaround. Hat dann natürlich den großen Nachteil, dass die Konfiguration nicht der echten Hardware (TT mit TOS 3.06) entspricht.
-
Das EmuTOS hatte ST-Oldie in #10 doch auch schon verwendet?
Vorteil dieser Lösung ist, daß überhaupt kein HD-Treiber extra sein muß (weil schon im Emu eingebaut). Nachteil: Es gibt nur den GEMDOS-Drive, ibs. kein Ext2.
Übrigens empfiehlt das Hatari-Manual als HD-Treiber den CECILE. Ist leider frz.
-
Wieso kein ext2 mit EmuTOS und MiNT ?
Das GEMDOS Drive geht nicht mehr aber das liegt am MiNT ...
-
Ugh, jetzt kommt der TeraDesk nicht mehr hoch, und ich weiß nicht, warum. Die MiNT-BootMeldungen fehlen auch.
Edit.: Alles wieder da. Der Haken an "Boot von HD" hat gefehlt.
-
Das GEMDOS Drive geht nicht mehr aber das liegt am MiNT ...
Kannst Du das bitte mal erläutern?
Der Drive aus MyHatari läuft ja als GEMDOS-Drive mit MiNT, siehe oben.
Ich habe aber inzwischen nach Anleitung des Hatari-Manuals einen GEMDOS-Drive mit Unterordnern C ... J erstellt und mußte feststellen, daß ohne MiNT alle funzen, aber mit MiNT funzt nur C - obwohl alle Icons da sind, -> ScreenShot. Woran genau liegt das?
Man kann natürlich im mint.cnf Aliasen setzen, die funzen auch, aber man kann davon natürlich nicht booten.
Was mir auch noch auffiel: Der FullScreen-Modus ist bei mir unbrauchbar: Der Cursor springt wild kreuz & quer bei geringster Berührung des TouchPads.
-
Und noch ein kleines Schrittchen weiter...
Die GEMDOS-UnterPartitionen lassen sich über u: benutzen.
Aber warum funzt
alias d: u:/d
nicht? Es ging doch
alias d: C:/unix
Bem.: Mit TeraDesk 4.06 werden auch die Fenster geöffnet.
-
Was ist denn D:\ ?
Wenn ext2 musst du natürlich auch den ext2 Dateisystem Treiber vom MiNT laden.
-
Hi,
Wie ist denn jetzt der Stand der Dinge? Sind die 2 Bömbchen auch mit EM190 immer noch da?
Wie czietz schon richtig bemerkt hatte, ging es um die Ähnlichkeit zum TT. Und die 2 Bömbchen kamen, weil MiNT auf die Hardware des TT zugreifen wollte. Das hat mit der EM190 nichts (direkt) zu tun. Nur mit dem MiNT.
Wie ich das zum Laufen bekommen hab, steht doch schon in einem anderen Post von mir:
- Als Maschine einen ST mit 68030 und TOS 2.XX, 14 MB ST RAM und TT RAM anlegen.
- das Harddisk Inage mit hddriver partitionieren, die für ext2 vorgesehene Partition als Typ RAW anlegen
- cbhd installieren. Das TT SCSI Modul per Diskmonitor/Hexedit wie in der FAQ von cbhd beschrieben deaktiviern. (am besten gleich alle außer ST ACSI)
- EM190 installiern
Und jetzt noch mal etwas zum Ziel und warum deshalb ein TT verwendet werden sollte und auch kein EmuTOS verwendet wurde:
Das Ziel des Workshops ist es nach einem Vorschlag des Initiator 1ST1, einen ST und einen TT stellvertretend für die 2 Generationen von Atari Computern einzurichten. Der Falcon bleibt damit außen vor. Damit werden die Einstellungen des Desktops mit speichern in der desktop.inf besprochen. Der AUTO Ordner mit Beispielen, was es dort an Programmen gibt wie z.B. TOS Patches, Erweiterungen wie MetaDOS, GDOS. Die Accessoires am Beispiel von Kontrollfeld und xcontrol mit Kurzem Überblick was es noch gibt wie z.B. ST-Guide. Und dann das Einrichten einer Festplatte mit AHDI. Also die alten Sachen von damals. Die meisten Dinge wollte ich dann mit dem TT in Verbindung mit der Platte machen. Diskjockey ist ja nicht so spannend und man muß das nicht zweimal für ST und TT durchkauen.
Und dann kommt als Abschluß der Übungen mit dem TT die Installation von EasyMiNT um zu zeigen, in welche Richtung sich TOS entwickelt hat. Das aber nicht so ins Detail, das wäre dann schon Stoff für einen weiterführenden Workshop. Deshalb hätte ich das gern mit dem TT gemacht. Da aber ein XHDI fähiger Festplattentreiber nötig ist und ein RAW/LNX Partiton vorhanden sein muß, hab ich das Plattenimage schon vorbereitet. Das Partitionieren mit zusätzlicher RAW Partition geht mit dem hddriver am komfortabelsten. Der cbhd wurde verwendet, weil der XHDI kann, nicht kommerziell ist und in dem readme von EM190 aufgeführt wird. Da MiNT auf dem unter Hatari emulierten TT abstürzt, hab ich auf Vorschlag von hier eine Maschine angelegt, die dem TT recht ähnlich ist. Ideal wäre es gewesen, wenn man auf den vorherigen Übungen hätte aufbauen können und den TT mit der eingerichteten Platte nehmen könnte. Weil es zuerst mit EM 1.6 nicht funktionierte, weil die XHDI Routinen in der dort verwendeten MiNT Version fehlerhaft sind, hab ich dann auf Vorschlag von hier die letzte Version EM190 verwendet.
Tschüß
Michael
-
Was mich daran irritiert ist, daß ich aber auf dem emulierten TT ein TOS 3.06 einsetze. Das sollte doch gar nicht versuchen, auf den IDE Port des Falcons zuzugreifen?
Doch, tut es. Auch TOS 3.06 sucht zuerst nach einer IDE Platte (warum auch immer, mir ist nicht bekannt daß es jemals offiziell TT mit IDE gegeben hätte)
-
Bei meinem Atari TT mit original TOS 3.06 und Thunder IDE Karte bootet der Rechner von der SCSI Platte legt aber das IDE Device an die erste Stelle also Laufwerk C:\. Ich musste extra die Reihenfolge in HDDriver umsortieren ...
-
Doch, tut es. Auch TOS 3.06 sucht zuerst nach einer IDE Platte
Tut es das? Jedenfalls bootet TOS 3.06 nicht von IDE, sondern probiert erst alle SCSI- und dann alle ACSI-IDs durch. IDE wird beim Bootvorgang ausgelassen. Deshalb bieten die Macher der Thunder-IDE-Karte ja gerade ein gepatchtes TOS 3.06 an.
Siehe Deinen eigenen kommentierten Code von TOS 3.06:
#if TOSVERSION < 0x300
moveq #16,d4 /* d4 = device (IDE0) */
#else
jsr scsirst
moveq.l #8,d4 /* d4 = device (SCSI0) */
-
csietz hat recht! (mal wieder..)
Das TOS 3.06 enthält die gleichen IDE-Routinen wie TOS 2.06, mit einem kleinen, aber wichtigen Unterschied: Beim Bootvorgang werden die IDE-Routinen nicht ausgeführt! Stattdessen führt der TT die SCSI-Routinen aus, die es im TOS 2.06 nicht gibt..
-
Mir mangelt es immer noch an einem brauchbaren Platten-Image. Habe mir darum das ACSI-Image von der HomePage von Hatari geangelt. Ist aber nur mickrige 80MB groß und wild in vier Parts. geteilt. Mit zwei Parts. 30MB + 50MB sollte sich lt. #15 immerhin EM190 installieren lassen - also HDDRIVER drauf angesetzt, um die Partitionierung zu ändern - aber der weigert sich: "Kann Verwaltungs-Informationen nicht schreiben". Was nun?
Wünschenswert wäre ein Image mit min. 4 x 255,9MB; wo bekooom?
PS: Das NVRAM habe ich auch noch nicht anpassen können (wie in der EmuTOS-Doku empfohlen). Alle meine drei NVRAM-Setter stürzen ab!
-
Siehe Deinen eigenen kommentierten Code von TOS 3.06:
#if TOSVERSION < 0x300
moveq #16,d4 /* d4 = device (IDE0) */
#else
jsr scsirst
moveq.l #8,d4 /* d4 = device (SCSI0) */
Ups, du hast natürlich recht. Nur 2.06 versucht das, aber nicht 3.06. Abgesehen davon, sind die Routinen für DMAread/write aber in beiden Versionen vorhanden. Allerdings wird ein Zugriff auf die IDE Register abgefangen, also selbst wenn Hatari einen bus-error meldet, sollte das Programm deshalb nicht abstürzen.
-
Hi,
Mir mangelt es immer noch an einem brauchbaren Platten-Image. ...
Wünschenswert wäre ein Image mit min. 4 x 255,9MB; wo bekooom?
Na das kannst du mittlerweile auf meinen Atari Seiten unter Einrichten von Hatari (http://www.mbernstein.de/atari/emu/hatari/konfig.htm) nachlesen.
Du mußt nur einfach eine leere Datei mit der gewünschten Größe anlegen. Unter Windows:
fsutil file createnew <dateiname> <Dateigröße in byte>Unter Linux:
dd if=/dev/zero of=hd.img bs=512 count=<anzahl 512 byte bl&oumml;cke>
Dann kannst du mit hddriver formatieren und anschließend partitioniern. Da du mit hddriver formatierst, sollte der Inhalt der virtuellen Platte egal sein.
Tschüß
Michael
-
Unter OSX/macOS geht das anlegen eines leeren Festplatten Image mit dem Festplattendienstprogramm. Einfach ein leeres MSDOS Image mit Masterrootrecord anlegen ...
-
Unter OSX/macOS geht das anlegen eines leeren Festplatten Image mit dem Festplattendienstprogramm. Einfach ein leeres MSDOS Image mit Masterrootrecord anlegen ...
Ja. Das stimmt, was die Sache komfortabeler macht. ;)
Ist die Frage ob man statt des Partitionierens des Images nicht auch mehrere Image anlegen könnte und diese als unterschiedliche Laufwerke einbindet? Das gäbe einem vielleicht noch mehr Flexiblität und man könnte schneller austauschen und rumprobieren? Andererseits kann man das auch mit mehreren partitionierten Images. Nur so nochmal als Idee.
-
Du kennst Hatari gar nicht, oder ?
Es geht nur ein ACSI Image und die IDE Images nur im Falcon Mode mit EmuTOS habe ich das noch nicht probiert. Die IDE Images sollten eigentlich bei allen TOS Versionen ermöglicht werden ...
-
Es geht nur ein ACSI Image und die IDE Images nur im Falcon Mode mit EmuTOS habe ich das noch nicht probiert. Die IDE Images sollten eigentlich bei allen TOS Versionen ermöglicht werden ...
Auch wenn nur eines geht, kann man sich dennoch unterschiedliche anlegen für unterschiedliche Zwecke und jene dann hin und wieder austauschen, um besser ausprobieren zu können. Das war meine Überlegung dahinter.
Aber Du hast schon Recht, ich kenne Hatari nicht wirklich. Ich mag Emulatoren nicht sonderlich. Ich hatte die Diskussion nur verfolgt und fand das Thema interessant. Und es war eine Idee, die mir beim Lesen des Threads kam.