atari-home.de - Foren

Hardware => Hardware (High-End) => Thema gestartet von: Nervengift am Sa 26.09.2015, 00:22:30

Titel: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am Sa 26.09.2015, 00:22:30
Nachdem ich's getan habe, hier mal eine kleine Beschreibung von mir zum Projekt. 8) Vielleicht ist's ja für den einen oder anderen interessant.

1. Das Gehäuse:

Im Grunde der wichtigste Parameter bei dem Vorhaben. Wenn man sich möglichst wenig Arbeit machen möchte, dann sollte man ein Gehäuse wählen, das entsprechende Bohrungen für ein Baby AT Board hat. Ein weiterer nicht ganz unwichtiger Faktor ist, dass heutige ATX-Gehäuse oft Frontblenden haben für zusätzliche USB-Anschlüsse oder Audioanschlüsse. Eine solche Frontblende sollte am besten einfach entfernbar sein und das Fehlern der Blende sollte nicht weiter auffallen. Ein weiterer Punkt, der nicht ganz unwichtig sein könnte, ist die Anzahl der Aussparungen für Steckkarten. Da kann schon einiges zusammen kommen. Vor allem auch wenn man die seriellen Schnittstellen und die parallele sowie die PS/2-Schnittstelle noch über diese Aussparungen nach draußen führen möchte.

Ich habe relativ lange nach einem entsprechenden Gehäuse Ausschau gehalten und habe im Grunde nur eines gefunden, welches meinen Anforderungen genügte:

http://www.lian-li.com/en/dt_portfolio/pc-6/ (http://www.lian-li.com/en/dt_portfolio/pc-6/)

https://www.caseking.de/lian-li-pc-6b-midi-tower-schwarz-geli-504.html (https://www.caseking.de/lian-li-pc-6b-midi-tower-schwarz-geli-504.html)

Eigentlich hatte ich ein Gehäuse in silber gesucht, weil schwarz nicht so meine Farbe ist, aber in silber hatte ich nichts passendes gefunden und da der Milan ein eher dunkler Vogel ist, dachte ich letzten Endes, dass das passt.

2. Der P8/P9-Adapter und das ATX-Netzteil:

Dieser Adapter wird benötigt, um ein (Baby) AT-Board an einem ATX-Netzteil anzuschließen:

http://www.amazon.de/InLine%C2%AE-Adapter-AT-Mainboard-Schalter-26641S/dp/B000VFBC2E/ref=sr_1_fkmr1_1?ie=UTF8&qid=1436614604&sr=8-1-fkmr1&keywords=atx+at+netzteil+adapter (http://www.amazon.de/InLine%C2%AE-Adapter-AT-Mainboard-Schalter-26641S/dp/B000VFBC2E/ref=sr_1_fkmr1_1?ie=UTF8&qid=1436614604&sr=8-1-fkmr1&keywords=atx+at+netzteil+adapter)

Bei ebay wird man auch sehr gut fündig, was diesen Adapter angeht. Man sollte nur aufpassen, dass man sich einen Adapter zulegt, der zwei Kabel (vorzugsweise mit Hülsen) hat, die man mit einem Ein/-Ausschalter verbinden kann. Legt man sich einen Adapter ohne diese beiden entsprechenden Kabel zu, kann man den Milan nur direkt über den Wippschalter des ATX-Netzteils an- und ausschalten:

http://www.amazon.de/InLine-Stromadapter-intern-ATX-NT-AT-Mainboard/dp/B000KKKGG8/ref=sr_1_1?ie=UTF8&qid=1442861763&sr=8-1&keywords=P8+p9+adapter (http://www.amazon.de/InLine-Stromadapter-intern-ATX-NT-AT-Mainboard/dp/B000KKKGG8/ref=sr_1_1?ie=UTF8&qid=1442861763&sr=8-1&keywords=P8+p9+adapter)

Als Netzteil sollte sich im Grunde jedes handelsübliche ATX-Netzteil eignen. Ich hatte mich für folgendes Netzteil entschieden:

https://www.caseking.de/be-quiet-pure-power-l8-netzteil-80-plus-bronze-350-watt-nebe-118.html (https://www.caseking.de/be-quiet-pure-power-l8-netzteil-80-plus-bronze-350-watt-nebe-118.html)

3. Der Ein-/Ausschalter:

Der stellt im Grunde die erste große Hürde dar und wenn man Pech hat, ist Bastelei angesagt.

Heutige ATX-Netzteile werden über das ATX-Mainboard per Taster ein- und ausgeschaltet. (Baby) AT Boards kannten dieses Verfahren noch nicht und die Netzteile wurden direkt über einen Schalter ein- und ausgeschaltet, der direkt mit dem AT-Netzteil verbunden war. Hat man sich jetzt den P8/P9 Adapter gekauft, den man mit einem Schalter verbinden kann, dann ist fast alles in Butter. Es fehlt nur noch der passende Schalter. Hier kommt's jetzt wieder aufs Gehäuse an. Wie groß ist die Aussparung am Gehäuse für den Schalter? Wie lang darf der Schalter sein, damit nichts weiter stört? Wenn man diese Parameter alle berücksichtigt hat, kann man sich an die Beschaffung des Schalters machen. Im Internet findet man sog. Vandalismusschalter, die für diesen Einsatzzweck sehr gut geeignet sind. Sie gibt es in den unterschiedlichsten Größen und Varianten, so dass man gut etwas passendes finden sollte:

https://www.caseking.de/lamptron-vandalismustaster-schalter-16mm-blackline-blue-molt-038.html (https://www.caseking.de/lamptron-vandalismustaster-schalter-16mm-blackline-blue-molt-038.html)

Jenen Schalter habe ich verwendet, obwohl mein Gehäuse eine 20 mm Öffnung aufweist. Wieso und warum wird später mit den Bildern erklärt.

Im Grunde tut es aber auch ein Wippschalter von z. B. Conrad oder Reichelt für knappe 2 €. Das mag dann aber nicht so gut aussehen.

Einige mögen sich jetzt auch fragen, warum verwendet der nicht das Teil, welches im Gehäuse schon drinsteckte? Im Grunde keine schlechte Idee, aber das ist bei einem ATX-Gehäuse heute kein Schalter sondern ein Taster. Der Taster schließt den Kontakt nur so lange wie er gedrückt wird. Wie bei einer Klingel eben. Wollte man jetzt ein AT-Board damit ein- und ausschalten, müsste man den Taster die ganze Zeit gedrückt halten, damit der Stromkreis geschlossen bleibt.

4. Die ATX-Blende mit Aussparung für die DIN-Tasterturanschlussbuchse:

Das Thema hatten wir schon. Infolgedessen verweise ich mal auf folgenden Thread:

http://forum.atari-home.de/index.php?topic=12151.0 (http://forum.atari-home.de/index.php?topic=12151.0)

5. Sonstiges Zubehör und nicht ganz trivaler Kleinkram:

Gehäuselüfter: Der Milan ist bei weitem keine solche Heizkachel wie es manche Gamer PCs heutzutage sind. ;D Insofern bin ich immer für möglichst leise zu haben. Ich habe mich für die „Silent Wings 2“ entschieden, die ich auch schon in meinem Hackintosh verarbeitet hatte:
 
https://www.caseking.de/be-quiet-luefter-silent-wings-2-120mm-lubq-027.html (https://www.caseking.de/be-quiet-luefter-silent-wings-2-120mm-lubq-027.html)

Die Lüfter werden mit entsprechenden 12 V/7 V/5 V Adapter ausgeliefert, so dass man sie rein gar nicht mehr hört, wenn man sie mit 5 V betreibt. Ich habe mich für 7 V entschieden. Dann sind sie auch noch sehr leise und fördern etwas mehr Luft. Man solte sich nur nicht die PMW Ausführung kaufen, denn die lässt sich nicht wirklich gut mit dem Milanboard betreiben. :D

SATA <--> IDE-Adapter: Möchte man eine SSD in dem Milan verbauen anstatt einer alten HDD, was durchaus sinnvoll ist, dann sollte man sich einen solchen Adapter besorgen:

http://www.amazon.de/MANHATTAN-158282-SATA-Drive-Konverter/dp/B002LBVUFK/ref=sr_1_63?ie=UTF8&qid=1405264059&sr=8-63&keywords=sata+auf+ide#productDetails (http://www.amazon.de/MANHATTAN-158282-SATA-Drive-Konverter/dp/B002LBVUFK/ref=sr_1_63?ie=UTF8&qid=1405264059&sr=8-63&keywords=sata+auf+ide#productDetails)

Mit diesem Adapter hatte ich schon sehr gute Erfahrungen in meinem PowerMac G4 MDD/FW800 gemacht. Auch im Milan läuft der sehr zuverlässig ohne irgendwelche Probleme zu machen. Sicherlich kann man sich auch eine IDE-SSD beschaffen, aber die Preise dafür sind meistens dann doch so hoch, dass eine kleine SSD und der Adapter günstiger kommen:

Ansonsten fallen mir noch solche nützlichen Dinge ein wie eine IDE-Verlängerung oder auch ein DIN <--> PS/2 Adapter zum Anschließen einer PS/2 Tastertur. Auch ein Adapter von USB auf PS/2 für eine optische Maus ist sinnvoll. Läuft super am PS/2-Anschluss des Milan. Ein solcher CF-Cardreader ist auch noch eine nette Sache, um unkompliziert Daten auszutauschen oder auch mal um auf die Schnelle andere Systeme zu testen:

http://www.amazon.de/StarTech-com-Adapter%C2%A0-Kartenleser-5%C2%A0Zoll%C2%A0-Single/dp/B000T9QQP0/ref=sr_1_1?ie=UTF8&qid=1443219415&sr=8-1&keywords=startech.com+cf+ide (http://www.amazon.de/StarTech-com-Adapter%C2%A0-Kartenleser-5%C2%A0Zoll%C2%A0-Single/dp/B000T9QQP0/ref=sr_1_1?ie=UTF8&qid=1443219415&sr=8-1&keywords=startech.com+cf+ide)

Abschließend kann ich sagen, dass der Umbau an sich eine recht einfache Sache ist, wenn nicht die ATX-Blende mit DIN-Aussparung wäre und der Schalter. Aber beide Probleme sind durchaus lösbar.

Ich möchte mich auch noch bei allen bedanken, die mir beim Umbau mit Rat und Tat zur Seite gestanden haben. Meinem Onkel, der mir die Adapterringe für den Schalter gedreht hat. pcx für die Lötarbeiten am Vandalismusschalter und nicht zuletzt gilt mein Dank auch joska aus dem atari-forum.com. Ohne dessen Hilfe hätte ich den Milan so schnell bestimmt nicht wieder flügge bekommen. Ich denke, er ist dahingehend schon ein echter Experte. Auch noch vielen Dank an alle aus diesem Forum, die mir weitergeholfen haben wenn es z. B. um easymint ging oder andere Softwareproblemchen.

Ein paar Bilder vom Umbau mit der entsprechenden Beschreibung gibt's auch noch gleich. Ich muss die noch etwas anpassen fürs Forum. ;D
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am Sa 26.09.2015, 00:40:42
Und schon geht's weiter mit den ersten Bildern. 8) Fange ich mal mit dem Ein-/Ausschalter an. In meinem Falle war das eine nicht so einfache Sache, weil der Taster in einer Fassung direkt unter der 20 mm Aussparung im Deckel des ATX-Gehäuses befestigt war und durch diese Fassung passte leider kein 20 mm Vandalismusschalter durch. Die waren alle zu dick. :o Auch ein entsprechender Wippschalter von Conrad passte nicht und ich hätte diese Fassung entsprechend bearbeiten müssen. Aber ein 16 mm Vandalismusschalter passte! 8) Ein Glück habe ich in der Verwandtschaft jemanden, der mir entsprechende Adapterringe drehen konnte, so dass ich den Schalter letzten Endes in mein Gehäuse gut einbauen konnte wie man auf den folgenden Bildern sieht.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am Sa 26.09.2015, 00:51:32
Als nächstes ein kleiner Blick auf den P8/P9-Adapter für das ATX-Netzteil und wie jener mit dem Schalter verbunden wird. Sicherlich hätte ich das professioneller machen können als mit den Lüsterklemmen. Aber so hat es zumindest den Vorteil, dass ich diese Verbindungen im Falle eines Falles leicht wieder lösen kann.

Ganz nebenbei gefragt, habe ich die seriellen Schnittstellen richtig angeschlossen? Ich habe das analog zu den IDE-Anschlüssen und zum Floppyanschluss gemacht. Leider ist Pin 1 bei den COM-Ports nicht markiert auf der Milanplatine. ??? Da bin ich dann wieder zu schusselig zu. ::)
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am Sa 26.09.2015, 01:02:31
Ein kleiner Blick auf die Anschlüsse für die Festplatten- und Power-LED (Jumperzeile JC) sowie für den internen Lautsprecher und den Reset-Taster (Jumperzeile JD). Die Pinbelegung kann hier nachgelesen werden:

http://der-ingo.de/de/milanhelp/hardware.html (http://der-ingo.de/de/milanhelp/hardware.html)
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am Sa 26.09.2015, 01:10:00
Mal ein kurzer Blick auf das komplette Innenleben. Zum CPU-Kühler und dessen Befestigung gibt's noch ein wenig was zu sagen. Aber dazu später mehr. Erstmal den Rest der Bilder abarbeiten. :D Und ich weiß, warum ich Flachbandkabel rein gar nicht mehr mag.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am Sa 26.09.2015, 01:28:42
Und die letzten Bilder für heute: Alles zusammengebaut. :D Ich denke, dass ich die Sache mit den entfernten Frontpanel ganz gut gelöst habe, so dass es auch im Grunde sehr unauffällig ist.

Ich hoffe, ich habe jetzt niemanden erschlagen mit diesem Thread. Vielleicht hilft es ja dem einen oder anderen oder ich konnte ein paar Anregungen geben. Mir hat diese Aktion zumindest großen Spaß gemacht, auch wenn ich manchmal fast verzweifelt wäre. Hatte ich das eine Problem gelöst, tat sich ein anderes promt auf. Ich hatte auch fast sechs Wochen gebraucht, bis ich das Gehäuse endgültig zusammen hatte. Manche Dinge bekommt man eben auch nicht mehr um die Ecke.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: neogain am Sa 26.09.2015, 12:28:47
Sieht gut aus, der Vogel im neuen Käfig :) Ist das Mainboard von den Ausmaßen her ein mATX?
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Lukas Frank am Sa 26.09.2015, 12:40:44
Das sollte es sein ...

(http://www.maedicke.de/atari/galerie/clones/image/milan.jpg)
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: 1ST1 am Sa 26.09.2015, 14:30:28
Ein toller Umbau!
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: LuckyOldMan am Sa 26.09.2015, 17:25:18
@Nervengift:

Mit sowas kann man Niemanden erschlagen, denn das bereichert und gibt Lust auf mehr. :)

Es gibt für mich nur einen kleinen Kritikpunkt: die Lüsterklemme beim Kabelübergang. Plastiklüsterklemmen sind ein Quell von Kontaktproblermen und da empfehle ich die Lötung + Schrumpfschlauch.

Gruß
LOM
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am Sa 26.09.2015, 17:53:00
Erstmal vielen Dank für die lobende Worte. 8) Hat mich sehr gefreut.

Zitat
st das Mainboard von den Ausmaßen her ein mATX?

Beim Milanboard handelt es sich um ein Baby AT-Board, wenn ich mich nicht total irre. Laut dieser Seite hier, ist das Baby AT-Board sogar etwas kleiner als ein mATX-Board:

http://www.elektronik-kompendium.de/sites/com/0403291.htm (http://www.elektronik-kompendium.de/sites/com/0403291.htm)

Baby-AT: 21,77 x 15,24 cm; microATX: 24,4 x 24,4 cm

Ich hatte mir auch ein paar microATX-Gehäuse angeschaut, aber ich bin aufgrund der Anzahl der Erweiterungskarten, die ich habe (Grafikkarte, Netzwerkkarte, Soundkarte und eventuell TV-Karte sowie SCSI-Karte) sehr schnell zu dem Schluss gekommen, dass ein microATX-Gehäuse nicht ausreicht, weil die Anzahl der Aussparungen für die Steckkarten zu gering ausfiel. Gut wäre es noch, wenn man eine ATX-Blende bekäme, mit einer DIN-Aussparung und mit Aussparungen für einen PS/2-, LPT- und zwei COM-Anschlüssen, dann müsste man diese nicht über die Erweiterungskartenaussparungen nach draußen führen. In diesem Falle könnte sogar ein microATX-Gehäuse reichen.

Zitat
Es gibt für mich nur einen kleinen Kritikpunkt: die Lüsterklemme beim Kabelübergang. Plastiklüsterklemmen sind ein Quell von Kontaktproblermen und da empfehle ich die Lötung + Schrumpfschlauch.

Ich muss ganz ehrlich sagen, da bin ich in dem Moment gar nicht drauf gekommen. Vielen Dank für den Tipp.

Und ein Bild von der nackten Platine nach dem CPU-Tausch habe ich auch noch. Den 68LC040 hatte ich rausgeschmissen und gegen einen vollwertigen 68040 getauscht, weil die LC-CPU ohne FPU im Grunde nur Probleme verursachte.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: KarlMüller am Sa 26.09.2015, 19:01:53
Ich hoffe, ich habe jetzt niemanden erschlagen mit diesem Thread. Vielleicht hilft es ja dem einen oder anderen oder ich konnte ein paar Anregungen geben.
Danke dafür!

Eigentlich suche ich noch für meinen ein neues Netzteil oder Lüfter. Der vorhanden macht mir zuviel Lärm.

Was mir bei Deinem Gehäuse noch auffällt, ist das Du dir mit den Buchsen für Drucker und seriellen Schnittstellen die Steckplätze belegst. Der obere scheint garnicht nutztbar zu sein.

So als prinzipeller Gedanke sollte man berücksichtigen das auch mal die Pufferbatterie gewechselt werden muss.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am So 27.09.2015, 00:49:29
Zitat
Was mir bei Deinem Gehäuse noch auffällt, ist das Du dir mit den Buchsen für Drucker und seriellen Schnittstellen die Steckplätze belegst. Der obere scheint garnicht nutztbar zu sein.

Das ließ sich nicht anders machen, weil ich leider keine ATX-Blende mit den entsprechenden Aussparungen habe. Das ist zur Zeit nicht so schlimm, weil ich die beiden oberen PCI-Steckplätze zur Zeit nicht brauche. Aber es sind alle ISA- und PCI-Steckplätze in dem Gehäuse nutzbar, wenn man die Kabel für die besagten Schnittstellen auf andere Art und Weise nach draußen führt.

Zitat
So als prinzipeller Gedanke sollte man berücksichtigen das auch mal die Pufferbatterie gewechselt werden muss.

Da kommt man auch noch ran. Man muss eben nur die entsprechenden Steckkarten etc., die stören, kurz rausnehmen. Ich muss aber auch ehrlich gestehen, ich weiß nicht wirklich was die Pufferbatterie im Milan macht. Die VRAM-Einstellungen werden fest im EPROM gespeichert. Ein wahrer Fortschritt im Vergleich zum Falcon.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: KarlMüller am So 27.09.2015, 08:31:36
ich weiß nicht wirklich was die Pufferbatterie im Milan macht.
Für die Uhr.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am So 27.09.2015, 12:07:39
Zitat
Für die Uhr.

Ah. Ok. Hätte man sich auch denken können, dass sie zumindest dafür gut ist. ;) Bei easymint wird die Uhrzeit mit dem Internet synchronisiert. Dann fällt das nicht so auf ob die Batterie leer ist oder nicht. Ich werde das aber auch mal testen und den Raubvogel vom Internet und vom Stromnetz trennen und mal sehen ob er die Uhrzeit dann vergisst.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Mathias am So 27.09.2015, 12:24:41
Sehr schöne Beschreibung! Fast schon ein Artikel. Und macht wirklich Lust selber zu basteln. Ich mußte grade wieder an den 060er denken, der noch immer nicht in meinem Hades ist, ... ;)
Den CF/IDE-Adapter gleich mit schöner Blende finde ich auch sehr inspirierend! Ich hatte mal vor den Hades für Debian m68k rechnen zu lassen, weil ich eh fast alles mit der Biene mache. Dafür wäre so ein Adapter perfekt, Karte mit MiNT wenn ich was tun will, wenn grade "Leerlauf" wäre Karte mit Linux rein und einmal neustarten, ...

Was ich nur noch nicht gecheckt habe, wie hast Du 'rausgefunden daß das Gehäuse die Bohrungen für ein Baby-AT-Board hat?
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am So 27.09.2015, 19:05:54
Zitat
Sehr schöne Beschreibung! Fast schon ein Artikel. Und macht wirklich Lust selber zu basteln.

Danke für das Lob. ;D Wenn die ST-Computer will kann sie gerne einen vollwertigen draus machen. :D

Zitat
Was ich nur noch nicht gecheckt habe, wie hast Du 'rausgefunden daß das Gehäuse die Bohrungen für ein Baby-AT-Board hat?

Gar nicht! Laut Hersteller passen nur ATX-, Micro-ATX- und Mini-ITX-Boards in das Gehäuse, da ich aber nichts besseres gefunden hatte, habe ich dann in einem meiner Wahnanfälle einfach das Gehäuse bestellt. Als ich das dann hatte, ging mir die Zwicke. Ich hatte aber noch ein altes ATX-Desktopgehäuse, das entsprechende Bohrungen hatte, die auch markiert waren. Das Milanboard war noch nicht da und das neue Gehäuse aber. Dann hatte ich nachgemessen und ein Glück, das sah gut aus mit den Abständen der Bohrungen. Leider habe ich mir die Abstände nicht notiert. Sonst hätte ich die Maße auch gepostet.

Zitat
Den CF/IDE-Adapter gleich mit schöner Blende finde ich auch sehr inspirierend! Ich hatte mal vor den Hades für Debian m68k rechnen zu lassen, weil ich eh fast alles mit der Biene mache. Dafür wäre so ein Adapter perfekt, Karte mit MiNT wenn ich was tun will, wenn grade "Leerlauf" wäre Karte mit Linux rein und einmal neustarten, ...

Den Adapter hatte ich auch erst gar nicht eingeplant. Aber mich trieb dann genau derselbe Gedanke um wie Dich und nicht auch zuletzt, um auf einfache Weise Backups machen zu können. Und ein Schacht war noch frei. Also warum den nicht auch noch nutzen. Inzwischen ist wohl eher ein optisches Laufwerk verzichtbar, denke ich.

Zitat
Ich mußte grade wieder an den 060er denken, der noch immer nicht in meinem Hades ist, ... ;)

Betreibst Du Deinen Hades auch mit einem 68040? Mit einem 68060 soll man immerhin MP3s im Hintergrund abspielen können und das Surfen im Internet soll nicht ganz so zäh sein wie auf einem 68040er. Ich bin echt gespannt wie sich die Biene im Internet schlägt und ob man dann von angenehmer Arbeitsgeschwindigkeit sprechen kann. :P
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Mathias am So 27.09.2015, 20:58:15
Mutig, mutig, das Gehäuse einfach zu bestellen ;) Aber super daß dann Alles gepasst hat!

Und ja, in meinem Hades steckt der 040er. Aber betreiben wäre derzeit zu viel gesagt, eher Staubfänger unterm Tisch spielen oder so, ...

Und ich fürchte mich schon vorm Surfen mit dem 060er, weil das geht am CF definitiv um Einiges schneller (wenn auch nicht optimal). Die einfachen Seiten sind ja die letzten Jahre auch nicht mehr geworden, abseits von firebee.org natürlich. ;) Leider alles nur mehr Stangenware statt Webdesign, irgendein Fertigsystem und optimiert wird eh nichts mehr, ... Vielleicht sollte ich vor dem Umbau eine Woche "ernsthaft surfen mit 040er" einlegen um nachher nicht frustriert zu sein ;)
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am So 27.09.2015, 22:17:49
Zitat
Vielleicht sollte ich vor dem Umbau eine Woche "ernsthaft surfen mit 040er" einlegen um nachher nicht frustriert zu sein ;)

 :D Auch eine Art und Weise sich selbst zu bestrafen. Ganz einfache Seiten aus damaliger Zeit gehen tatsächlich echt gut und flott, aber an heutige Webseiten sollte man sich lieber erst gar nicht ranwagen. Es ist schon echt krass wie sich das seit Ende der 90er Jahre entwickelt hat. Das Internet braucht inzwischen echt Rechenpower.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: dbsys am Mo 28.09.2015, 16:09:41
Sehr gute Arbeit!

Und auch der Bericht ist erste Sahne.

Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am Fr 23.10.2015, 23:23:26
Nachdem ich über die Bucht auch ein entsprechendes ATX I/O Shield mit einer Aussparung für den DIN-Tasterturanschluss bekommen hatte, habe ich mein selbstgebasteltes I/O-Shield mal gegen das maschinell gefertigte ausgetauscht. ;)

Infolgedessen reiche ich Fotos von der Rückseite des Gehäuses nach. Die fehlten bislang ja noch. :)

Insgesamt bin ich mit meinem Umbau soweit zufrieden. Ich hätte es mir zwar etwas einfacher vorgestellt, aber es ist durchaus eine Sache, die im Grunde fast jeder bewerkstelligen kann, denke ich.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am Fr 23.10.2015, 23:43:18
Wie man auf meinen Bildern auch erkennen kann, habe ich die seriellen Schnittstellen und die parallele Schnittstelle über entsprechende Slotbelche nach außen geführt. Dadurch habe ich mir aber die beiden oberen PCI-Steckplätze blockiert, was erstmal nicht so schlimm ist, weil ich dieselben nicht unbedingt brauche. Ich habe aber noch eine TV-Karte für den Milan und wollte dieselbe auch noch installieren. Also habe ich mir für die beiden seriellen COM-Ports ein Slotblech mit längeren Kabeln besorgt (40 cm), so dass ich jenes unterhalb der Soundkarte nach außen führen kann. Dann ist zwar ein ISA-Steckplatz blockiert, aber damit kann man wesentlich besser leben als mit einem blockierten PCI-Steckplatz. :D

http://www.amazon.de/gp/product/B008635ANK?psc=1redirect=trueref_=oh_aui_detailpage_o07_s00 (http://www.amazon.de/gp/product/B008635ANK?psc=1redirect=trueref_=oh_aui_detailpage_o07_s00)

Wichtig ist, darauf zu achten, dass man sich Kabel mit einem Anschluss für 10 Pins kauft. Kabel mit 9 Pins passen nicht auf die beiden COM-Ports des Milan-Boards, da die Ports 10 Pins haben. Ansonsten drückt man Pins platt, was nicht unbedingt so schön ist.

Ich habe dann nur bemerkt, als ich die TV-Karte einbauen wollte, dass dieselbe nicht mehr in Ordnung ist und sich ein Kondensator von der Karte gelöst hat. :'( Infolgedessen habe ich den kleinen Umbau für den Einbau der TV-Karte erstmal auf Eis gelegt. Vielleicht lasse ich die Karte reparieren, aber das steht nicht ganz oben auf meiner Prioritätenliste.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am So 15.11.2015, 02:50:02
Dank Arthurs ausgezeichneter Lökünste ist die TV-Karte wieder am Leben! 8) Vielen Dank nochmal an Arthur, dass er sich der Karte angenommen hatte.

Ich habe die Karte eingebaut und damit nochmal ein wenig das Innenleben des Milans modifiziert. Die seriellen Schnittstellen sind jetzt komplett nach unten gerutscht, was ich allerdings nicht weiter tragisch finde, da ich diese wohl eh nur zu Testzwecken im Einsatz haben werde. Dafür habe ich jetzt aber auch den dritten COM-Port mit nach draußen geführt, der zuvor noch nicht mit einem externen Anschluss versehen war. Ich weiß zwar nicht ob die Orientierung der seriellen Anschlusskabel auf der Milanplatine richtig ist oder ob ich's spiegelverkehrt gemacht habe, aber Versuch macht ja klug. Somit präsentiert sich auch die Rückseite des Gehäuse etwas anders und ich habe tatsächlich nahezu alle Aussparungen jetzt in Benutzung.

Die gemTV-Software an sich ist eher gewöhnungsbedürftig. Das hatte etwas gedauert bis ich da durchgeblickt hatte. Immerhin konnte ich die Karte erfolgreich in Betrieb nehmen. Ich habe tatsächlich ein Fernsehbild! 8) Um den Ton muss ich mich allerdings nochmal kümmern. Den hatte ich noch nicht mit angeschlossen. Aber leider läuft gemTV 0.27 nicht unter MiNT 1.19.x, was bei easymint 1.90 mit dabei ist. Infolgedessen bin ich erfolgreich aufs Milan Single TOS 4.08 (letzte Version von 2006) ausgewichen.

Ich denke, dass ich damit die Hardwarebastelei am Milan abschließen kann. Weitere Erweiterungen plane ich zur Zeit nicht. Getestet werden müssen noch die seriellen Schnittstellen und die parallele Schnittstelle. Danach soll das Hauptaugenmerk auf jeden Fall auf der Software liegen. Neben easymint 1.90 möchte ich auch Magic Milan nutzen. Ich bin gespannt welches OS die bessere Softwarekompatiblität aufweist. Aber das wird dann ein eigener Thread werden. :D
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: 1ST1 am So 15.11.2015, 11:27:08
Tolle Kiste, ein richtig moderner ATARI. Schade dass es davon nicht mehr gibt.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am So 15.11.2015, 16:03:06
Zitat
Tolle Kiste, ein richtig moderner ATARI. Schade dass es davon nicht mehr gibt.

Vielen Dank! Ich finde die Idee hinter dem Milanboard auch echt nicht schlecht. Alles handelsübliche Komponenten, die wichtigsten Schnittstellen onboard. Alles andere lässt sich über Steckkarten erweitern. Austauschbarkeit und Erweiterbarkeit ist auch sehr gut. Ich finde das sehr schade, dass es solche Boards in Sachen Atari heute nicht mehr gibt. Die Firebee mag echt gut und vor allem auch schnell sein, aber mit dem Formfaktor habe ich eben so meine Probleme. Aber so hat eben alles seine Vor- und Nachteile. ;)
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am Mi 20.07.2016, 02:48:04
Bei der Orientierung der Flachbandkabel für die seriellen Schnittstellen und den parallelen Port war ich mir ja nicht sicher. Auf der Milan-Hauptplatine ist Pin 1 jeweils nicht gekennzeichnet für diese Schnittstellen. Leider hatte ich auch nie ein Handbuch, welches mir Auskunft geben könnte. Jetzt habe ich aber das Milan Benutzerhandbuch im Netz gefunden:

http://christophe.bray.free.fr/informatique/milan/Guide_milan.pdf (http://christophe.bray.free.fr/informatique/milan/Guide_milan.pdf)

In dem Handbuch ist der Pin 1 der jeweiligen Schnittstellen in einer Abbildung der Hauptplatine markiert. Ein paar Kabel musste ich tatsächlich drehen, weil ich sie falsch draufgesetzt hatte. :o

Hier auch noch ein paar nützliche ergänzende Informationen zum Benutzerhandbuch:

http://christophe.bray.free.fr/informatique/milan/DOC_Milan.pdf (http://christophe.bray.free.fr/informatique/milan/DOC_Milan.pdf)

Anbei die entsprechende Abbildung mit der Markierung der Pins.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am So 11.09.2016, 12:50:54
Für die TOS-Plattform kamen auch einige CD-ROMs heraus. Einige wie die Whiteline Serie sind inzwischen frei verfügbar. Ich hatte noch eine 60 GB IDE-Festplatte aus meinem Power Mac G4 MDD FW 800 übrig und dachte mir, Du hast noch einen IDE-Anschluss im Milan frei also schließe die Platte an den Anschluss an und nutze sie als CD ROM-Archiv. Das Unterfangen war allerdings nicht so einfach, da die Orientierung der Anschlüsse (vor allem des IDE <--> SATA Adapters, der an der SSD hängt) nur ein Anschluss der Festplatte über ein IDE-Verlängerungskabel zuließ. Ich hatte mir eine 20 cm Verlängerung bestellt, wobei sich herausstellte, dass dieselbe noch zu kurz war. Also habe ich noch zusätzlich eine 10 cm Verlängerung benutzt, die ich noch im Schrank hatte. Sieht auf den Bildern auch etwas verwickelt aus, aber es funktioniert bislang fehlerfrei. Insgesamt muss ich sagen, gefallen mir die SATA-Kabel besser. Sie nehmen weniger Platz weg und die Handhabung ist einfach besser als mit den Flachbandkabeln.

Auch nicht ohne war die Einbindung der Paltte ins System. Ich hatte sie zuerst mit HDDriver (9.07) eingerichtet mit einer FAT32-Partition für TOS und ohne Windowskompatiblitätsoption. Das hatte auch auch geklappt. Nur das Draufschaufeln der Daten war etwas schwierig mit dieser Lösung. Kopiert man auf dem Milan unter MiNT etwas mehr als 1 GB gibt's out of memory Fehler. Mit dieser Einrichtung erkennt nur mein Mac die Platte nicht. Es gibt in HDDriver die Option die Platte Windows kompatibel einzurichten, was aber lt. Hilfedialog wohl zu Preformanceverlusten führt und für OS X nicht unbedingt funktioniert. Wie dem auch sei, ich nutze eine SD-Karte mit dem Milan, die ich mal unter OS X auf FAT32 formatiert hatte und die wird von HDDriver ohne Probleme erkannt und man kann mit arbeiten. Also dachte ich mir, ich gehe diesen Weg. Also hatte ich die Platte an meinen G5 formatiert auf FAT32 mit Master Boot Record als Partitionsschema. Dann gab's aber eine Fehlermeldung auf dem Milan von XaAES beim Zugriff auf die Platte, dass etwas mit dem Bootparameterblock der Platte nicht stimme. Zwar klappte das Lesen und Schreiben, aber Fehlermeldungen an sich sind immer nervig finde ich. Bei der SD-Karte habe ich diese Fehlermeldung nicht. Also habe ich mir die nochmal genauer angeguckt. Die verwendet das GUID-Partitionsschema. Also habe ich die Platte auch so eingerichtet und siehe da keine Fehlermeldungen mehr. Lesen und Schreiben klappt am Milan. Befüllt habe ich dann die Platte am G5. Ich hätte nie gedacht, dass ich das mal sagen würde, aber ich fürchte, die Platte ist zu klein für mein Vorhaben. :o Aber Vorteil der Einrichtung ist, ich kann sie auch am Mac anschließen und alle Daten umkopieren auf eine größere Platte.

Die verwendete Seagate Barracuda ATA V (ST360015A) ist auch sehr leise und werkelt kaum hörbar im Milan. Allerdings scheint sie auch extra gedämmt zu sein. Ich weiß nicht ob die Dämmung an der Unterseite standardmäßig so war oder ob diese dem Einbau in Apples G4-Gehäuse geschuldet war (siehe Bilder).

Auch interessant: Magic Milan 6.1 scheint mit FAT32 ein paar Probleme zu haben. Irgendwie zeigt Magic mir für alle meine FAT32 Partitionen abweichende Werte zu MiNT an. Manchmal auch total "schwachsinnig". Lt. Magic sind auf der Platte nur noch ca. 2 GB frei. MiNT sagt was anderes, was sich mit dem Mac deckt.   
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: tuxie am So 11.09.2016, 20:13:24
Zum kopieren empfehle ich dir Kobold der dateikopierer, geht super..
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am So 11.09.2016, 22:21:51
Kommt der gleiche Fehler bei raus. Genauso beim KK Commander ist nach ca. 1 GB Schluss und die Programme verabschieden sich mit einem "out of memory" Fehler. Der Thing Desktop zeigt dasselbe Verhalten. Unter Teradesk habe ich's noch nicht ausprobiert. Keine Ahnung wo da der Hund begraben liegt. Vielleicht ist's auch nur eine Einstellung. Dabei spielt es auch keine Rolle ob die Platte oder SD-Karte mit HDDriver für TOS auf FAT32 formatiert wurde oder unter OS X. Dieses Verhalten bleibt so. Was ich noch nicht probiert habe, ist eine so große Menge an Daten übers Netzwerk zu kopieren. Wäre insofern interessant ob sich dieses Verhalten dann auch so zeigt.

Die Einrichtung mit HDDriver hätte ich auch so gelassen, aber ich wollte auch gerne das TOSEC-Archiv auf die Platte packen und das sind 12 GB. Das wäre etwas sehr umständlich gewesen es in 1 GB Schritten rüberzukopieren. Das wollte ich dann mit dem Mac vorab auf die Platte schieben.

Falls aber jemand Ideen hat wieso und warum es zu den out of memory Fehlern kommt und wie man dieselben umgehen kann, bin durchaus gewillt da nochmal weiter nachzuforschen. ;D

Bislang hatte ich auch noch nicht den Write Back Cache für die FAT32- und BGM-Volumes eingeschaltet, weil ich viele Programme teste und Angst hatte, dass mir dann ein Absturz schneller die Dateisysteme zerlegt. Vielleicht kann ich den Cache mal für die Seagate Baracuda einschalten und gucken was passiert.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: tuxie am So 11.09.2016, 23:17:08
Ist leider sehr lange her wo ich einen Milan hatte, aber mir war so al muss man irgendeinen Treiber laden, der das Memory Management übernimmt. Bin mir aber nicht ganz sicher
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am Mo 12.09.2016, 08:34:26
Zitat
Ist leider sehr lange her wo ich einen Milan hatte, aber mir war so al muss man irgendeinen Treiber laden, der das Memory Management übernimmt. Bin mir aber nicht ganz sicher

Davon hatte ich noch nichts gelesen aber die Quellenlage ist in Sachen Milan auch eher spärlich. Ich weiß auch nicht ob das ein Problem an/mit MiNT ist, aber vielleicht könnten dazu noch was unsere MiNT-Cracks @HelmutK oder @maanke was sagen oder eine Idee haben?
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: ari.tao am Mo 12.09.2016, 11:15:21
Auf den Bug in MAGX_6.21 bzgl. FAT32 hatte ich schon mal kurz hingewiesen:
http://forum.atari-home.de/index.php?topic=12796.msg207837#msg207837
(Absatz 2)
Aus meinen Notizen:
 10.05.14:
 Auf dem 4G-Plättle meldet MAGX für die NewFAT-Part. J extremen Inhalt,
  zB. daß diese 1,8G-Part. noch 1,48 Milliarden k frei hat, obwohl sie mit
  1,44G gefüllt ist, die in mehr als 429 Millionen Dateien stecken! (Da habe
  ich wohl, aus Versehen (& ohne Internet!), einen kleinen Teil des Bestands
  des NSA.US angezapft ;-)

 18.04.10:
 8ung: Bei großen (F32-?) Part. kann MAGX nicht richtig zählen: Partitions-
 =====  Füllung & Frei-Anzeige spinnen (unabh. vom Desktop; unter NAES2 ok).
        Hat das etwas zu tun mit dem für TOS in \TOS\PATX*\Newbies\hideVFAT\
        geschilderten Problem?

 Tja, und dann muß leider noch festgehalten werden, daß MAGX kein MIX kann
 (es fehlt ein Treiber) & mit F32 Probleme hat; die sollten lt. Doku eigtl.
 behoben sein, aber: 400MB freier Platz werden plötzlich nicht mehr erkannt!
 Das passiert regelmäßig zB. auch, wenn man mit SINF nachgeschaut hat, was
 noch frei ist (offenbar wird aus Zeit-Optimierungsgrnden irgendwas falsch
 auf die Partition geschrieben). Deshalb:

 8UNG: Unter MAGX _immer_ Schreibschutz im HDDRIVER einschalten für F32er!
 =====  (Lesen ok) 
Ich rate hierzu: Die F32-Partition neu initialisieren und dann _schreibend_ nur noch unter MiNT darauf zugreifen! Die Part. unter MAGX mit Schreibschutz versehen! Hat man einmal unter MAGX schreibend (dazu gehört in diesem Fall auch die Inhalts-Abfrage!) zugegriffen, ist die Part. nmE. auch für MiNT verdorben! Lesen auf der schreibgeschützten Part. ist aber ok (im ´GEMDOS-Mode´).
Unter MiNT+NAES2+THING gibt´s nmE. keine Probs, auch nicht mit richtig großen Parts. (32GB).
-------
Ein weiterer MAGX-Bug in diesem Zusammenhang:
  10.06.16:
 Nun endlich nen Hinweis zur Ursache beim Verzählen auf F16 (sic!) gefunden:
  Im 'Atari Hard Disk Filesystems Reference Guide' auf S.13 sagt DrCoolZic
  (Jean Louis-Guerin), das sei eine Folge davon, das TOS mit LFN (langen
  File-Namen) nicht umgehen kann! Gilt dies auch für F32 unter MAGX ?
  (-> 18.04.10) Es wird ausdrücklich gewarnt, daß TOS bei Schreibzugriffen
  auf LFN das betroffene Directory kaputt macht! Deshalb:
 8UNG: LFN schon auf'm PC kürzen, _vor_ dem Kopieren auf eine TOS-Partition!
 =====  Anscheinend ist die Kürzungs-Automatik in MAGX_6.20 unzuverlässig?
        Oder gar nicht vorhanden, iGgs. zu MiNT_1.15.9 ?
        Entsprechend vorsichtig MAGX\MAGIC\UTIL\VFATCONF.PRG anwenden!
   Oder kommt MAGX etwa mit der PartitionsGröße > 1GB nicht klar?
    Mit der 1GB SD-Card für den Austausch mit dem Labtop keine Probs!
   Neuerdings sieht das Symptom nur noch 'halb so schlimm' aus: 'gesamt' und
    Inhalt scheinen zu stimmen, nur bei 'belegt' & 'frei' streikt MAGX. 
Es gibt einen ganzen Sack voll weiterer Bugs & Macken in MAGX, das müßten wir mal in einem extra Thread behandeln... (aber bitte nicht vor Mitte Okt.)
Wenn doch jmd. ASH dazu bewegen könnte, die Quellen freizugeben - dann könnte sich mal ein versierter C-ler an die Arbeit machen! >:(

PS: Nachdem ich es vom Zeitungsjungen bis zum Senator gebracht hatte, bin ich nun auf meine alten Tage auch noch ein Kammerjäger & Flickschuster geworden... >:D
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am Mo 12.09.2016, 12:22:47
Zitat
Ich rate hierzu: Die F32-Partition neu initialisieren und dann _schreibend_ nur noch unter MiNT darauf zugreifen! Die Part. unter MAGX mit Schreibschutz versehen! Hat man einmal unter MAGX schreibend (dazu gehört in diesem Fall auch die Inhalts-Abfrage!) zugegriffen, ist die Part. nmE. auch für MiNT verdorben! Lesen auf der schreibgeschützten Part. ist aber ok (im ´GEMDOS-Mode´).
Unter MiNT+NAES2+THING gibt´s nmE. keine Probs, auch nicht mit richtig großen Parts. (32GB).

Und wieder etwas essentielles dazugelernt. Das hieße möglicherweise, dass ich die Probleme, die ich jetzt unter MiNT habe von dem Zugriff mit MagiC herrühren könnte? MagiC ist auch nicht mein Hauptsystem auf dem Milan. Ich hatte MagiC 6.1 mit dem Milan dazubekommen und es ausprobiert. Soweit macht das einen ganz brauchbaren Eindruck auf mich (nur das Netzwerk zickt ohne Ende), aber irgendwie arbeite ich doch lieber mit MiNT. Kann man das auch so hinbekommen, dass die F32-Partitionen automatisch für MagiC schreibgeschützt sind und für MiNT ein Schreib- und Lesezugriff möglich ist. Ich möchte ungern im HDDriver das jedes Mal neu einstellen müssen.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: ari.tao am Mo 12.09.2016, 12:50:16
Zitat
  Das hieße möglicherweise, dass ich die Probleme, die ich jetzt unter MiNT habe von dem Zugriff mit MagiC herrühren könnte? 
Imho ja (ohne Gewähr).
Zitat
Soweit macht das einen ganz brauchbaren Eindruck auf mich   
Trotz gewisser Macken arbeite ich immer noch gern damit, ibs. mit MAGXDESK (der ist imho _ergonomisch_ bis heute unübertroffen! Sehr schade, daß der nicht mehr weiterentwickelt & gepflegt wurde!
Zitat
  Kann man das auch so hinbekommen, dass die F32-Partitionen automatisch für MagiC schreibgeschützt sind und für MiNT ein Schreib- und Lesezugriff möglich ist. Ich möchte ungern im HDDriver das jedes Mal neu einstellen müssen. 
Ich habe mir nicht anders zu helfen gewußt, als für die KennBuchstaben, die möglicherweise auf F32er Parts. zu liegen kommen, unter HDDRIVER den Schreibschutz einzuschalten. Wenn ich dann unter MiNT doch schreiben will, wird der Schreibschutz sehr schnell mit dem  dem HDDRIVER beiliegenden CPX aufgehoben. (In xCONTROL installieren; falls Du aber kein xCONTROL.ACC im System haben willst, kannst Du auch *.CP? auf zCONTROL ´anmelden´.)
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am Do 15.09.2016, 20:42:09
Zitat
ch habe mir nicht anders zu helfen gewußt, als für die KennBuchstaben, die möglicherweise auf F32er Parts. zu liegen kommen, unter HDDRIVER den Schreibschutz einzuschalten. Wenn ich dann unter MiNT doch schreiben will, wird der Schreibschutz sehr schnell mit dem  dem HDDRIVER beiliegenden CPX aufgehoben. (In xCONTROL installieren; falls Du aber kein xCONTRO.ACC im System haben willst, kannst Du auch *.CP? auf zCONTROL ´anmelden´.)

Ich nutze COPS. :) Aber jetzt habe ich für das HDDriver CPX auch eine Verwendung. ;D

Eine Erkenntnis des Abends gibt's noch: Es ist weniger eine Frage der Größe als der Menge. Ich wollte etwas auf die Platte kopieren, was nur ca. 600 MB hatte, aber ich bekam wieder die "out of memory"-Meldung. Von der Größe her sollte das eigentlich klappen. Dabei handelte es sich auch um ein CD-Archiv, was ich allerdings mal inter über mein Netzwerk zwischen zwei Macs hin- und hergeschoben hatte. Dabei legt der Mac zu jeder Datei eine zusätzliche Datei an, die nur wenige KB groß ist. Aber infolgedessen steigt natürlich die Anzhal der Dateien, die kopiert werden sollen, auf das Doppelte an. Insofern denke ich, dass man nur eine bestimmte Anzahl von Dateien kopieren kann und dann ist Schluss?

Was F32 und Magic angeht: Ich will nochmal einen kleinen fiesen Test machen. Ich hoffe, ich komme morgen mal dazu. ;D
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: 1ST1 am Do 15.09.2016, 20:47:10
Also auf dem Falcon und TT habe ich das noch nicht beoabchtet. Folgende Ideen:
- Statt über den Desktop zu kopieren, Kobold 3.5 verwenden (ist eh schneller und besser)
- Funktionieren die WinX-Patches auch im Zusammenhang mit dem Milan-TOS? Nicht, dass du das Environement-Problem von TOS 3.06 / 4.04 bei hohen Auflösungen und vielen (großen) Partitionen hast... Ich habe deswegen bei mir ROMRAMPRG und WINX.PRG mit passend angepasster WINX.INF im Auto-Ordner liegen, auf allen TTs und Falcons.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am Do 15.09.2016, 20:57:20
Zitat
- Statt über den Desktop zu kopieren, Kobold 3.5 verwenden (ist eh schneller und besser)

Gleiches Problem. Gibt auch einen "out of memory"-Fehler. Ebenso beim KK-Commander usw..

Zitat
- Funktionieren die WinX-Patches auch im Zusammenhang mit dem Milan-TOS? Nicht, dass du das Environement-Problem von TOS 3.06 / 4.04 bei hohen Auflösungen und vielen (großen) Partitionen hast... Ich habe deswegen bei mir ROMRAMPRG und WINX.PRG mit passend angepasster WINX.INF im Auto-Ordner liegen, auf allen TTs und Falcons.

WinX sagt mir jetzt leider gar nichts. Ich nutze im Grunde nur MiNT (easymint mit MiNT 1.19). Bislang tritt der Fehler auch nur unter MiNT auf. Unterm Single TOS habe ich noch nicht so viele Daten kopiert. MagiC zeigt ein ähnliches Verhalten bei sehr vielen Dateien. Es wird irgendwann nur ganz langsam beim Kopieren und bricht dann auch irgendwann ab mit einer Fehlermeldung, aber unter Magic habe ich da auch noch nicht so viel probiert.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: 1ST1 am Do 15.09.2016, 21:22:15
Da bekommst du WinX. https://sites.google.com/site/stessential/home/all-software/ -> Nach Winx suchen. Runterladen. Entpacken. Lesen. Ausprobieren. (Du brauchst ROMRAM, GEMRAM, oder ähnliches, denn WinX patcht direkt im TOS, das dazu im RAM liegen muss.)
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: ari.tao am Fr 16.09.2016, 08:36:24
_^^_ Gemeint ist, daß evtl- der ShellBuffer überläuft (wenn zuviele Fenster geöffnet werden). Den kann man mit dem SHBUF.PRG aus WINX hochsetzen. Ich habe ihn bei mir bereits auf 16kB setzen müssen (weil (NEW)DESK(TOP).?NF wg. so vieler Icon-Zuweisungen so fett wurde).
-------
Ich vermute eher, daß ein anderes Problem vorliegt, daß nämlich Deine Kopier-Prge. sich sämtlichen Speicher unter den Nagel reißen, so daß nix mehr übrig bleibt für´s System. Darauf hin deutet der Umstand, daß es immer die gleiche Meldung ist, auch wenn das Kopier-Prg. wechselt. Abhilfe: Speicher-Anforderung begrenzen oder den gesamten Speicher _etwas_ fragmentieren (zB. per RAMBO.ACC).
Das Problem tritt nur bei neueren BSen auf, die älteren haben sowieso den Speicher (unfreiwillig & heftig) fragmentiert.
------
COPS ist leider sehr eigenwillig, wenn es um Anordnung/Reihenfolge der CPXe geht.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: 1ST1 am Fr 16.09.2016, 14:08:08
Wenn das auch mit Kobold passiert, bin ich etwas ratlos. Denn Kobold hat sein eigenes Speichermanagement. Kobold 3.5 gibt nach dem Kopieren den ganzen Speicher auch wieder frei, während bei älteren Versionen manuell vorreserviert werden muss, und das dort eingestellte Minimum auch behalten wird, selbst wenn man das ACC geschlossen hat und es nicht benutzt.

Ich könnte mir vorstellen, dass das Problem von wo ganz anders her kommt, vielleicht ein Problem in MiNT?

Wenn ich so viel Dateien kopiere/Verschiebe, dann immer mit Kobold. Kam auch schon beim Füttern meines Falcons vor, dass ich 1 GB am Stück von der zweiten SD auf eine Partiton der immerdrin-CF verschoben habe, ging bisher immer problemlos, aber ohne MiNT, was ich erst noch installieren will.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am Fr 16.09.2016, 22:08:08
Zitat
Ich vermute eher, daß ein anderes Problem vorliegt, daß nämlich Deine Kopier-Prge. sich sämtlichen Speicher unter den Nagel reißen, so daß nix mehr übrig bleibt für´s System. Darauf hin deutet der Umstand, daß es immer die gleiche Meldung ist, auch wenn das Kopier-Prg. wechselt. Abhilfe: Speicher-Anforderung begrenzen oder den gesamten Speicher _etwas_ fragmentieren (zB. per RAMBO.ACC).

@ari.tao: "RAMBO.ACC" sagt mir jetzt rein gar nichts. :-[ Anbei mal zwei Screenshots bzw. des Infodialoges, den mir Thing! über den KK Commander und Kobold rausgibt, was die RAM-Nutzung anbelangt. Keine Ahnung ob man über diesen Dialog was drehen könnte. Unter Teradesk schaue ich auch nochmal was der mir so sagt.

Zitat
- Funktionieren die WinX-Patches auch im Zusammenhang mit dem Milan-TOS? Nicht, dass du das Environement-Problem von TOS 3.06 / 4.04 bei hohen Auflösungen und vielen (großen) Partitionen hast... Ich habe deswegen bei mir ROMRAMPRG und WINX.PRG mit passend angepasster WINX.INF im Auto-Ordner liegen, auf allen TTs und Falcons.

@1ST1: Nutzt Du WINX auch unter MiNT? Lt. SpareMiNT Wiki ist das wohl keine so gute Idee:

http://wiki.sparemint.org/index.php/User_manual#Tips_.26_tricks (http://wiki.sparemint.org/index.php/User_manual#Tips_.26_tricks)

Zitat
Unlike TOS, FreeMiNT doesn't require patch programs at all. FreeMiNT replaces TOS, and bugs are fixed in FreeMiNT itself. All such patch programs (like serial port enhancers, cookie jar extenders, hard disk caches etc) must be avoided when running FreeMiNT.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: 1ST1 am Fr 16.09.2016, 23:23:02
Nein, unter MiNT würde ich es per XBOOT ausschalten. Habe ich aber immer noch nicht installiert.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: HelmutK am Fr 16.09.2016, 23:43:23
Zitat
Ist leider sehr lange her wo ich einen Milan hatte, aber mir war so al muss man irgendeinen Treiber laden, der das Memory Management übernimmt. Bin mir aber nicht ganz sicher

Davon hatte ich noch nichts gelesen aber die Quellenlage ist in Sachen Milan auch eher spärlich. Ich weiß auch nicht ob das ein Problem an/mit MiNT ist, aber vielleicht könnten dazu noch was unsere MiNT-Cracks @HelmutK oder @maanke was sagen oder eine Idee haben?

Wahrscheinlich verwechselt er das mit dem tool für den Hades?
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: ari.tao am Sa 17.09.2016, 10:52:33
WINX ist zB. hier an der Arbeit:
http://forum.atari-home.de/index.php?action=gallery;sa=view;pic=376
-------
RamBO im Anhang. Use it on your own risk!
-------
Zitat
Ich könnte mir vorstellen, dass das Problem von wo ganz anders her kommt, vielleicht ein Problem in MiNT? 
Auch ich könnte mir das vorstellen. Ich könnte mir aber auch vorstellen, daß es bloß ein Problem des Desktops, ibs. von THING ist (auch, was dessen Einbindung des KOBOLDs angeht). Zum Thema ´kopieren´ Im Anhang ein weiterer Text aus meinen Notizen (die ersten drei Zeilen könnt ihr ignorieren, sie betreffen nur mein System).
-------
Das SpareMiNT-Zitat bezieht sich nicht auf Patxes/Änderungen/Zusätze der AES (wie WinX sie macht), sondern nur auf GEMDOS-  & BIOS-Patxes! Auch VDI-Patxes (ie. NVDI) sind damit nicht gemeint!

PS: Die vielen Macken von THING müßten wir auch mal diskutieren - aber bitte nicht vor Mitte Okt.!
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am Mi 21.09.2016, 20:39:00
So ... etwas Zeit zum Testen hatte ich jetzt nochmal. Kobold kopiert zwar tatsächlich munter, aber bricht ohne Fehlermeldung dann einfach nach einer bestimmten Anzahl von Dateien ab. In Kobold selbst war der GEMDOS-Modus für die entsprechenden Laufwerke aktiviert. Inzwischen habe ich ihn deaktiviert. Ein Test folgt noch. Ich habe auch mal einen kleinen Screenshot von den Einstellungen der Speicherzuteilung des Kobolds gemacht. Vielleicht kann oder sollte ich da auch noch was dran drehen?

Rambo stüzt leider ab unter MiNT 1.19. Die Absturzmeldung habe ich auch mal beigefügt. Zun WINX bin ich leider noch nicht gekommen. Damit setze ich mich auch nochmal auseinander, wenn ich demnächst mal ein paar freie Stunden mehr habe.

Erstmal vielen Dank für eure Hilfe und Mühe, die ihr euch macht! 8)
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: ari.tao am Fr 21.10.2016, 02:21:14
Hi, bin wieder da.
Mit der Fehlermeldung bzgl. RAMBO kann ich nicht viel anfangen. Trace Trap wird von RAMBO nicht benutzt. Vermutlich wird der Trace-Mode von einer Debug-Version von XaAES oder MiNT gesetzt? Trace mode abschalten! (ie. debug aus).
Ich hatte jüngst (bevor ich hier ´reingeschaut habe) selbst Anlaß, Rambo iZhg. mit MiNT 1.18-0 & 1-19-cur zu überarbeiten. Im Anhang die neue Version, die bei mir läuft.
Ein kleiner Test-Bericht bzgl. MiNT 1-18-0 (und vielleicht 1-19-cur) folgt noch anderswo.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am Fr 21.10.2016, 18:25:25
Zitat
Trace mode abschalten! (ie. debug aus).

Wie geht das? Sorry ... vom Programmieren habe ich null Ahnung. :-\

Zitat
Ich hatte jüngst (bevor ich hier ´reingeschaut habe) selbst Anlaß, Rambo iZhg. mit MiNT 1.18-0 & 1-19-cur zu überarbeiten. Im Anhang die neue Version, die bei mir läuft.
Ein kleiner Test-Bericht bzgl. MiNT 1-18-0 (und vielleicht 1-19-cur) folgt noch anderswo.

Die Version, die Du angehängt hast, läuft auf jeden Fall auch unter MiNT 1.19. Reicht es, einfach RAMBO2.ACC beim Booten zu laden oder muss man noch etwas einstellen? Ich wüßte nur nicht was oder wie? Sorry wenn ich manchmal eine Blindbunke bin.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: ari.tao am So 23.10.2016, 23:57:22
Eine Blindbunke? hihi, hoho, was ist das?!
-------
Nein; Rambo einfach nur bei den anderen ACCs mitladen und dann vergessen - jedenfalls so lange, bis sich irgendein Prg. über zu wenig Speicher beschwert; falls dieser Fall eintritt, dann ´Unfrag´ benutzen.
-------
Zitat
Zitat
Trace mode abschalten! (ie. debug aus).
Wie geht das? Sorry ... vom Programmieren habe ich null Ahnung. :-\
Mußt Du auch nicht. Bloß den normalen MiNT-Kernal in Dein AUTO\ kopieren (anstatt des Debug-Kernals).
Aber wenn´s jetzt auch so läuft, mußt Du vielleicht gar nix machen?
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am Mo 24.10.2016, 08:33:01
Zitat
Nein; Rambo einfach nur bei den anderen ACCs mitladen und dann vergessen - jedenfalls so lange, bis sich irgendein Prg. über zu wenig Speicher beschwert; falls dieser Fall eintritt, dann ´Unfrag´ benutzen.

Danke für die kurze Anleitung. Jetzt weiß ich auch damit umzugehen. ;)

Zitat
Eine Blindbunke? hihi, hoho, was ist das?!

"Blindfisch" wäre wohl ein äquivalenter Begriff. :D

Zitat
Bloß den normalen MiNT-Kernal in Dein AUTO\ kopieren (anstatt des Debug-Kernals).

Ich nutze den normalen Kernel aus dem MiNT-Paket (Trunk-Build). Keine Ahnung wie ich überhaupt an den Debug-Kernel käme.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: ari.tao am Di 25.10.2016, 02:29:01
Tja, dann weiß ich wirklich nicht, woher der Trace Trap stammte. Vielleicht weiß es einer unserer MiNTzer?
Rambo ist so konstruiert, daß während der kritischen Phase der Speicher-Allozierung (im MiNT.MOD beschrieben) kein Task-Wechsel stattfinden können sollte.

Edit: Sorry, Dreckfuhler; lies RAMBO.MOD anstatt MiNT.MOD !
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: mfro am Di 25.10.2016, 08:06:42
Tja, dann weiß ich wirklich nicht, woher der Trace Trap stammte. Vielleicht weiß es einer unserer MiNTzer?

Ich würde im ersten Anlauf mal annehmen, daß das Programm mit den langen Stackframes des 040ers nicht umgehen kann und deswegen das SR falsch setzt.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: ari.tao am Mi 26.10.2016, 23:23:34
^^--
@mfro :
1) Was hat der TraceTrap mit den LongStackframes zu tun?
2) Wie unterscheiden sich die LongdStackframes des 68040 von denen des 68030?
    Was muß man ändern/beachten? (Ich habe leider keinen 68040 oder ~60)
-------
@Nervengift : Ist die Meldung mit der neuen Version verschwunden? Funzt das Teil?
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: mfro am Do 27.10.2016, 07:10:48
^^--
@mfro :
1) Was hat der TraceTrap mit den LongStackframes zu tun?
2) Wie unterscheiden sich die LongdStackframes des 68040 von denen des 68030?
    Was muß man ändern/beachten? (Ich habe leider keinen 68040 oder ~60)

Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: Nervengift am Do 27.10.2016, 08:57:35
Ja. Funzt. Steht alles in  Antwort #46 drin in diesem Thread. ;D Also zumindest Rambo an sich funzt. Tests, was die out of memory Fehler angeht, mache ich hoffentlich dann am Wochenende.
Titel: Re: Milan040: Baby AT <--> ATX Umbau
Beitrag von: ari.tao am Do 27.10.2016, 09:34:33
^^-- Danke für Info.
-------
@mfro :
Als ich meine Libs an den 68030 angepaßt habe (das war vor vielen Jahren, und seither hatte ich nie ein derartiges Symptom), habe ich natürlich auch die LongStackframes berücksichtigen müssen. Eine Änderung bei späteren Prozessoren ist mir diesbezüglich nicht bekannt. Allerdings habe ich niemals ´getraced´; deshalb danke für den Tipp, falls das Symptom nochmals auftaucht, weiß ich, wo ich mal hinschauen könnte.
Die neue Version von Rambo hat nur noch _eine_ DoppelKlammer SuperAn, PrioHoch - PrioRunter, SuperAus; bei der früheren Version war das mislungen, gemerkt habe ich das erst kürzlich (obwohl Rambo bei mir schon viele Jahre Dienst tut), darum die neue Version.