Autor Thema: Milan040: Baby AT <--> ATX Umbau  (Gelesen 21635 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Offline Nervengift

  • Benutzer
  • Beiträge: 1.516
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #20 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.
« Letzte Änderung: Sa 24.10.2015, 11:36:06 von Nervengift »
520 ST(M) (TOS 1.02), Falcon030 (16 MHz, 16 MB RAM, CF-Karte, MiNT & MyAES), Milan040 (25 MHz, 48 MB RAM, EasyMiNT 1.90), Firebee (2nd Edition), PowerMac G5 Late 2005 (2 x 2,3 GHz, Mac OS 10.5), iMac 4K Late 2015 (intel Core i7 4 x 3,3 GHz, Mac OS 10.11.6), IBM XT SFD (640 KB RAM, DR DOS 6.0), Compaq LTE 5300 (Pentium/133 MHz, DR-DOS 7.03), AT-PC (Cyrix 6x86L/200 MHz, Windows 98 SE/MS-DOS 6.22 & Windows 3.11)

Offline Nervengift

  • Benutzer
  • Beiträge: 1.516
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #21 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

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.
520 ST(M) (TOS 1.02), Falcon030 (16 MHz, 16 MB RAM, CF-Karte, MiNT & MyAES), Milan040 (25 MHz, 48 MB RAM, EasyMiNT 1.90), Firebee (2nd Edition), PowerMac G5 Late 2005 (2 x 2,3 GHz, Mac OS 10.5), iMac 4K Late 2015 (intel Core i7 4 x 3,3 GHz, Mac OS 10.11.6), IBM XT SFD (640 KB RAM, DR DOS 6.0), Compaq LTE 5300 (Pentium/133 MHz, DR-DOS 7.03), AT-PC (Cyrix 6x86L/200 MHz, Windows 98 SE/MS-DOS 6.22 & Windows 3.11)

Offline Nervengift

  • Benutzer
  • Beiträge: 1.516
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #22 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
520 ST(M) (TOS 1.02), Falcon030 (16 MHz, 16 MB RAM, CF-Karte, MiNT & MyAES), Milan040 (25 MHz, 48 MB RAM, EasyMiNT 1.90), Firebee (2nd Edition), PowerMac G5 Late 2005 (2 x 2,3 GHz, Mac OS 10.5), iMac 4K Late 2015 (intel Core i7 4 x 3,3 GHz, Mac OS 10.11.6), IBM XT SFD (640 KB RAM, DR DOS 6.0), Compaq LTE 5300 (Pentium/133 MHz, DR-DOS 7.03), AT-PC (Cyrix 6x86L/200 MHz, Windows 98 SE/MS-DOS 6.22 & Windows 3.11)

Offline 1ST1

  • Benutzer
  • Beiträge: 8.661
  • Gesperrter User
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #23 am: So 15.11.2015, 11:27:08 »
Tolle Kiste, ein richtig moderner ATARI. Schade dass es davon nicht mehr gibt.
Ausgeloggter Mitleser, der hier NIE mehr aktiv wird. Am besten, meine Inhalte komplett löschen. Dabei berufe ich mich auf mein Urheberrecht, die DSGVO und auf die Rechte, die mir unter Impressunm&Datenschutz zugestanden werden. Tschö!

Offline Nervengift

  • Benutzer
  • Beiträge: 1.516
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #24 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. ;)
520 ST(M) (TOS 1.02), Falcon030 (16 MHz, 16 MB RAM, CF-Karte, MiNT & MyAES), Milan040 (25 MHz, 48 MB RAM, EasyMiNT 1.90), Firebee (2nd Edition), PowerMac G5 Late 2005 (2 x 2,3 GHz, Mac OS 10.5), iMac 4K Late 2015 (intel Core i7 4 x 3,3 GHz, Mac OS 10.11.6), IBM XT SFD (640 KB RAM, DR DOS 6.0), Compaq LTE 5300 (Pentium/133 MHz, DR-DOS 7.03), AT-PC (Cyrix 6x86L/200 MHz, Windows 98 SE/MS-DOS 6.22 & Windows 3.11)

Offline Nervengift

  • Benutzer
  • Beiträge: 1.516
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #25 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

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

Anbei die entsprechende Abbildung mit der Markierung der Pins.
« Letzte Änderung: Mi 20.07.2016, 02:56:40 von Nervengift »
520 ST(M) (TOS 1.02), Falcon030 (16 MHz, 16 MB RAM, CF-Karte, MiNT & MyAES), Milan040 (25 MHz, 48 MB RAM, EasyMiNT 1.90), Firebee (2nd Edition), PowerMac G5 Late 2005 (2 x 2,3 GHz, Mac OS 10.5), iMac 4K Late 2015 (intel Core i7 4 x 3,3 GHz, Mac OS 10.11.6), IBM XT SFD (640 KB RAM, DR DOS 6.0), Compaq LTE 5300 (Pentium/133 MHz, DR-DOS 7.03), AT-PC (Cyrix 6x86L/200 MHz, Windows 98 SE/MS-DOS 6.22 & Windows 3.11)

Offline Nervengift

  • Benutzer
  • Beiträge: 1.516
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #26 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.   
520 ST(M) (TOS 1.02), Falcon030 (16 MHz, 16 MB RAM, CF-Karte, MiNT & MyAES), Milan040 (25 MHz, 48 MB RAM, EasyMiNT 1.90), Firebee (2nd Edition), PowerMac G5 Late 2005 (2 x 2,3 GHz, Mac OS 10.5), iMac 4K Late 2015 (intel Core i7 4 x 3,3 GHz, Mac OS 10.11.6), IBM XT SFD (640 KB RAM, DR DOS 6.0), Compaq LTE 5300 (Pentium/133 MHz, DR-DOS 7.03), AT-PC (Cyrix 6x86L/200 MHz, Windows 98 SE/MS-DOS 6.22 & Windows 3.11)

Offline tuxie

  • Benutzer
  • Beiträge: 6.830
  • Falcon! Milan! Schuetzt die Raubvoegel!
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #27 am: So 11.09.2016, 20:13:24 »
Zum kopieren empfehle ich dir Kobold der dateikopierer, geht super..
Tschau Ingo

Offline Nervengift

  • Benutzer
  • Beiträge: 1.516
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #28 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.
520 ST(M) (TOS 1.02), Falcon030 (16 MHz, 16 MB RAM, CF-Karte, MiNT & MyAES), Milan040 (25 MHz, 48 MB RAM, EasyMiNT 1.90), Firebee (2nd Edition), PowerMac G5 Late 2005 (2 x 2,3 GHz, Mac OS 10.5), iMac 4K Late 2015 (intel Core i7 4 x 3,3 GHz, Mac OS 10.11.6), IBM XT SFD (640 KB RAM, DR DOS 6.0), Compaq LTE 5300 (Pentium/133 MHz, DR-DOS 7.03), AT-PC (Cyrix 6x86L/200 MHz, Windows 98 SE/MS-DOS 6.22 & Windows 3.11)

Offline tuxie

  • Benutzer
  • Beiträge: 6.830
  • Falcon! Milan! Schuetzt die Raubvoegel!
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #29 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
Tschau Ingo

Offline Nervengift

  • Benutzer
  • Beiträge: 1.516
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #30 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?
520 ST(M) (TOS 1.02), Falcon030 (16 MHz, 16 MB RAM, CF-Karte, MiNT & MyAES), Milan040 (25 MHz, 48 MB RAM, EasyMiNT 1.90), Firebee (2nd Edition), PowerMac G5 Late 2005 (2 x 2,3 GHz, Mac OS 10.5), iMac 4K Late 2015 (intel Core i7 4 x 3,3 GHz, Mac OS 10.11.6), IBM XT SFD (640 KB RAM, DR DOS 6.0), Compaq LTE 5300 (Pentium/133 MHz, DR-DOS 7.03), AT-PC (Cyrix 6x86L/200 MHz, Windows 98 SE/MS-DOS 6.22 & Windows 3.11)

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #31 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
« Letzte Änderung: Mo 12.09.2016, 11:27:06 von ari.tao »
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline Nervengift

  • Benutzer
  • Beiträge: 1.516
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #32 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.
520 ST(M) (TOS 1.02), Falcon030 (16 MHz, 16 MB RAM, CF-Karte, MiNT & MyAES), Milan040 (25 MHz, 48 MB RAM, EasyMiNT 1.90), Firebee (2nd Edition), PowerMac G5 Late 2005 (2 x 2,3 GHz, Mac OS 10.5), iMac 4K Late 2015 (intel Core i7 4 x 3,3 GHz, Mac OS 10.11.6), IBM XT SFD (640 KB RAM, DR DOS 6.0), Compaq LTE 5300 (Pentium/133 MHz, DR-DOS 7.03), AT-PC (Cyrix 6x86L/200 MHz, Windows 98 SE/MS-DOS 6.22 & Windows 3.11)

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #33 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´.)
« Letzte Änderung: Fr 16.09.2016, 08:46:21 von ari.tao »
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline Nervengift

  • Benutzer
  • Beiträge: 1.516
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #34 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
520 ST(M) (TOS 1.02), Falcon030 (16 MHz, 16 MB RAM, CF-Karte, MiNT & MyAES), Milan040 (25 MHz, 48 MB RAM, EasyMiNT 1.90), Firebee (2nd Edition), PowerMac G5 Late 2005 (2 x 2,3 GHz, Mac OS 10.5), iMac 4K Late 2015 (intel Core i7 4 x 3,3 GHz, Mac OS 10.11.6), IBM XT SFD (640 KB RAM, DR DOS 6.0), Compaq LTE 5300 (Pentium/133 MHz, DR-DOS 7.03), AT-PC (Cyrix 6x86L/200 MHz, Windows 98 SE/MS-DOS 6.22 & Windows 3.11)

Offline 1ST1

  • Benutzer
  • Beiträge: 8.661
  • Gesperrter User
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #35 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.
Ausgeloggter Mitleser, der hier NIE mehr aktiv wird. Am besten, meine Inhalte komplett löschen. Dabei berufe ich mich auf mein Urheberrecht, die DSGVO und auf die Rechte, die mir unter Impressunm&Datenschutz zugestanden werden. Tschö!

Offline Nervengift

  • Benutzer
  • Beiträge: 1.516
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #36 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.
520 ST(M) (TOS 1.02), Falcon030 (16 MHz, 16 MB RAM, CF-Karte, MiNT & MyAES), Milan040 (25 MHz, 48 MB RAM, EasyMiNT 1.90), Firebee (2nd Edition), PowerMac G5 Late 2005 (2 x 2,3 GHz, Mac OS 10.5), iMac 4K Late 2015 (intel Core i7 4 x 3,3 GHz, Mac OS 10.11.6), IBM XT SFD (640 KB RAM, DR DOS 6.0), Compaq LTE 5300 (Pentium/133 MHz, DR-DOS 7.03), AT-PC (Cyrix 6x86L/200 MHz, Windows 98 SE/MS-DOS 6.22 & Windows 3.11)

Offline 1ST1

  • Benutzer
  • Beiträge: 8.661
  • Gesperrter User
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #37 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.)
Ausgeloggter Mitleser, der hier NIE mehr aktiv wird. Am besten, meine Inhalte komplett löschen. Dabei berufe ich mich auf mein Urheberrecht, die DSGVO und auf die Rechte, die mir unter Impressunm&Datenschutz zugestanden werden. Tschö!

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #38 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.
« Letzte Änderung: Fr 16.09.2016, 08:53:01 von ari.tao »
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline 1ST1

  • Benutzer
  • Beiträge: 8.661
  • Gesperrter User
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #39 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.
Ausgeloggter Mitleser, der hier NIE mehr aktiv wird. Am besten, meine Inhalte komplett löschen. Dabei berufe ich mich auf mein Urheberrecht, die DSGVO und auf die Rechte, die mir unter Impressunm&Datenschutz zugestanden werden. Tschö!