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

0 Mitglieder und 1 Gast betrachten dieses Thema.

Online Nervengift

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

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.
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 #41 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.
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 HelmutK

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

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #43 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.!
« Letzte Änderung: Sa 17.09.2016, 23:28:32 von ari.tao »
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Online Nervengift

  • Benutzer
  • Beiträge: 1.533
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #44 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)
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 #45 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.
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Online Nervengift

  • Benutzer
  • Beiträge: 1.533
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #46 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.
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 #47 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?
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Online Nervengift

  • Benutzer
  • Beiträge: 1.533
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #48 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.
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 #49 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 !
« Letzte Änderung: Mi 26.10.2016, 23:27:00 von ari.tao »
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline mfro

  • Benutzer
  • Beiträge: 1.640
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #50 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.
And remember: Beethoven wrote his first symphony in C

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #51 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?
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline mfro

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

  • eingentlich nix. Wenn man allerdings (in einem Traphandler oder einer Interrupt-Routine) an den Stackframes rumfummelt ohne ihren Aufbau zu berücksichtigen, kann man dabei problemlos das Statusregister und dabei das Trace-Bit erwischen. Beim RTE landet das dann wieder in der CPU und plötzlich ist der Trace Trap da. Woher ich das weiß? ...
  • ich auch nicht.
And remember: Beethoven wrote his first symphony in C

Online Nervengift

  • Benutzer
  • Beiträge: 1.533
Re: Milan040: Baby AT <--> ATX Umbau
« Antwort #53 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.
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 #54 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.
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.