Autor Thema: Quellen von Magic, Magxdesk, u.a. auf gitlab ...  (Gelesen 205291 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Online Thorsten Otto

  • Benutzer
  • Beiträge: 1.315
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #120 am: Mi 12.12.2018, 16:44:37 »
Wenn man keine CFG-Datei nutzt bei der -B angwählt ist gehen die.  8)

Wer macht denn auch sowas ;) Könnte man natürlich explizit setzen, aber das müsste dann in alle Projekt-Dateien rein... sind ja nur 251...

Zitat
Im Milan Projektfile habe ich noch ein ".C[-2]" eingefügt. Erzeugt dann für C  68020 Code.

Ja, kann man machen. Für die Hades-Version wohl auch.

Zitat
In MAGCMACX.PRJ musste noch ein ".S[-S]" rein

Stimmt, fehlte generell bei allen Projekt-Dateien für Kernels. Behoben.

Wie lange dauert das übersetzen auf dem Milan so ca?

Offline KarlMüller

  • Benutzer
  • Beiträge: 420
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #121 am: Mi 12.12.2018, 21:19:33 »
Zitat
Im Milan Projektfile habe ich noch ein ".C[-2]" eingefügt. Erzeugt dann für C  68020 Code.
Ja, kann man machen. Für die Hades-Version wohl auch.
Yep, vom Prinzip her auch für den TT und Falcon. Vielleicht einfach eine zusätzliche Projektdatei atari020.prj.

Wie lange dauert das übersetzen auf dem Milan so ca?
70 Sekunden, auf eine Milan060 mit 25MHz. Kein Vergleich, ein komplett durchlauf von CAT benötigt fast 6 Minuten.

Offline Nervengift

  • Benutzer
  • Beiträge: 1.531
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #122 am: Do 13.12.2018, 08:26:06 »
Zitat
Im Milan Projektfile habe ich noch ein ".C[-2]" eingefügt. Erzeugt dann für C  68020 Code.
Ja, kann man machen. Für die Hades-Version wohl auch.
Yep, vom Prinzip her auch für den TT und Falcon. Vielleicht einfach eine zusätzliche Projektdatei atari020.prj.

Wie lange dauert das übersetzen auf dem Milan so ca?
70 Sekunden, auf eine Milan060 mit 25MHz. Kein Vergleich, ein komplett durchlauf von CAT benötigt fast 6 Minuten.

@KarlMüller Du meinst einen Milan060 mit 50 MHz oder einen Milan040 mit 25 MHz?
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)

Online Thorsten Otto

  • Benutzer
  • Beiträge: 1.315
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #123 am: Do 13.12.2018, 09:05:08 »
Yep, vom Prinzip her auch für den TT und Falcon. Vielleicht einfach eine zusätzliche Projektdatei atari020.prj.

Es gibt momentan keine spezielle Version für Falcon/TT, das ist die gleiche wie für ST. C-Code ist nur für File-Selector, Font-Selector etc. vorhanden, da wird man ein paar eingesparte Cycles nicht bemerken. Von daher möchte ich eigentlich vermeiden noch weitere Projekt-Dateien pflegen zu müssen, zumal da möglicherweise sowieso noch welche für verschiedene Sprachen dazu kommen.

Zitat
ein komplett durchlauf von CAT benötigt fast 6 Minuten.

Meinst du das Maustausch-Programm CAT? Wow, hätte nicht gedacht daß das noch jemand benutzt.

Offline tuxie

  • Benutzer
  • Beiträge: 6.834
  • Falcon! Milan! Schuetzt die Raubvoegel!
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #124 am: Do 13.12.2018, 10:56:25 »
Würde es sinn machen speziell für TT das Magic anzupassen ? Ich meine vielleicht ist da sogar noch Optimierungspotential wobei ich sagen muß ähm bei mir rennt es wiiiiieeeee irre.
Tschau Ingo

Online Thorsten Otto

  • Benutzer
  • Beiträge: 1.315
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #125 am: Do 13.12.2018, 11:48:11 »
Optimierungs-Potenzial wäre vlt. vorhanden, es gibt immer ein paar Sachen die sich mit '020 Code einfacher/schneller lösen lassen. Ob man das gross merkt wage ich aber zu bezweifeln, die meisten Geschwindigkeitsvorteile sind eigentlich in den VDI-Treibern zu erwarten, und da werden die meisten vermutlich die NVDI Treiber benutzen. Inwieweit die veröffentlichen Treiber-Sourcen der letzten NVDI-Version entsprechen kann ich nicht sagen, sie werden vermutlich ähnlich sein, aber nicht identisch. Da würde ich eher abwarten wollen, ob nicht auch NVDI demnächst freigegeben wird.

Offline tuxie

  • Benutzer
  • Beiträge: 6.834
  • Falcon! Milan! Schuetzt die Raubvoegel!
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #126 am: Do 13.12.2018, 12:12:31 »
Größtere Vorteil ist halt das Magic komplett im TT-Ram läuft.. da z.b. mein Rechner momentan einen Datendurchsatz auf dem TT-Ram von 25Mb/s hat spürt man das unheimlich. Werde mal ein Video machen und hochladen wie sich magic auf meinem TT anfühlt :) gut meiner ist nicht ganz so normal wie andere aber dennoch dank der Storm ist das echt Spürbar.
Tschau Ingo

Offline gh-baden

  • Benutzer
  • Beiträge: 2.052
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #127 am: Do 13.12.2018, 19:31:27 »
Optimierungs-Potenzial wäre vlt. vorhanden, es gibt immer ein paar Sachen die sich mit '020 Code einfacher/schneller lösen lassen. Ob man das gross merkt wage ich aber zu bezweifeln, die meisten Geschwindigkeitsvorteile sind eigentlich in den VDI-Treibern zu erwarten,[…]

Du sagst es. VDI übernimmt NVDI oder NovaVDI, die seriellen Schnittstellen wickelt man über HSMODA ab, BIOS/XBIOS wird keiner groß in moderner Software direkt aufrufen, GEMDOS dürfte bis auf die Speicherverwaltung größtenteils I/O-bound sein.

Daher sehe ich bei kurzem Nachdenken nur zwei Ecken, wo man optimieren kann mit 030-Code: Speicherblöcke löschen oder schieben, falls das irgendwo enthalten ist, gerade bei heutigen Speichergrößen (der wächst dank der Neuentwicklungen ja, und die CPU ist dieselbe wie ’89 :-), sowie im Scheduler, also tief im Kern.

Hm, bei den AES vielleicht auch? Aber wo da?

Und damit kommen wir auf die Diskussion, die kürzlich auf der EmuTOS-ML war: für sinnvolles „Beschleunigen“ müßte man erstmal untersuchen, wo denn nennenswert Zeit verbraten wird im OS, bevor man da Zeit reinhängt an Stellen, die zwar toll zu optimieren sind, aber selten aufgerufen werden oder eh nur 80ms laufen …
Wider dem Signaturspam!

Offline tuxie

  • Benutzer
  • Beiträge: 6.834
  • Falcon! Milan! Schuetzt die Raubvoegel!
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #128 am: Fr 14.12.2018, 07:28:08 »
Das Apollo Team und ich hatten uns Mitte des Jahres das für die Vampire Amiga von Vincent Riviere Entwickelten fVDI Treiber zur Hand genommen und diesen Optimiert, wir haben durch Optimieren der Blitting Routinen fast 300% Leistungszuwachs erzielen können. Ich glaube das man dort auch noch etwas Verfeinerung hin bekommt. Ansonsten Lesen-/Schreiben-/ Kopieren in und aus dem TT-Ram ... man kann diese Daten ganz gut mit Kronos Benchen, da wird der Speicher intensiv benutzt. Aber ich denke das Betrifft wirklich nur diejenigen die keine Grafikkarte habe.
Tschau Ingo

Offline KarlMüller

  • Benutzer
  • Beiträge: 420
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #129 am: Fr 14.12.2018, 09:29:40 »
Es gibt momentan keine spezielle Version für Falcon/TT, das ist die gleiche wie für ST. C-Code ist nur für File-Selector, Font-Selector etc. vorhanden, da wird man ein paar eingesparte Cycles nicht bemerken.
Ja, die einzige nicht AES Datei in C ist noch die vfat.c im DOS.

Zum Offtop Teil:
KarlMüller Du meinst einen Milan060 mit 50 MHz oder einen Milan040 mit 25 MHz?
Ungenau ausgedrückt ein Milan060 mit 25MHz Bustakt und 50MHz CPU Takt.

Meinst du das Maustausch-Programm CAT? Wow, hätte nicht gedacht daß das noch jemand benutzt.
Gut nutzen ist jetzt etwas übertrieben. Ich benötige es noch für die Archive der Mausgruppen. Hier rechariere ich öfteres mal in den Gruppen wie z.B. Maus.Computer.Atari.Programmieren.

Offline Ektus

  • Benutzer
  • Beiträge: 919
Off Topic: CAT
« Antwort #130 am: Fr 14.12.2018, 14:50:56 »

Zitat
ein komplett durchlauf von CAT benötigt fast 6 Minuten.

Meinst du das Maustausch-Programm CAT? Wow, hätte nicht gedacht daß das noch jemand benutzt.

Wieso nicht? Bei mir ist es nach wie vor täglich im Einsatz, Maustausch mit der letzten verbliebenen Maus (Berlin) und per In2CAT mit einem POP3-Postfach.

Offline KarlMüller

  • Benutzer
  • Beiträge: 420
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #131 am: So 16.12.2018, 09:51:44 »
Im Anhang hätte ich die Datei kernel/bios/milan/doc/mmilan.txt. Ich habe die Struktur MILAN_OS an den tatsächliche Zustand angepasst.

In MagicMac/kernel/aes/aesevt.s ist mir was auf gefallen:
* FPU retten
 tst.b    is_fpu                        ; LineF- FPU installiert ?
 beq.b    ad_no_fpu                     ; nein!
 fsave    -(sp)
     IF   MC68060
 tst.b    10(sp)
     ELSE
 tst.b    (sp)                          ; NULL/IDLE/BUSY- Flag
     ENDIF
 beq.b    ad_no_fpu                     ; NULL
 fmovem.x fp0-fp7,-(sp)                 ; Datenregister
 fmovem.l fpcr/fpsr/fpiar,-(sp)         ; Statusregister
 move.w   #-1,-(sp)                     ; Flag fuer "FPU komplett gesichert"
Es gibt das Symbol MC68060, welches in der Datei explizit gesetz werden muss. So funktioniert das auf dem 60860 nicht richtig. Ich frage mich ob es wirklich Sinn macht da ne spezielle Abfrage zumachen und nicht einfach gernerel die Register der FPU retten. Ob das zeitlich jetzt so ins Gewicht fällt.

Online Thorsten Otto

  • Benutzer
  • Beiträge: 1.315
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #132 am: So 16.12.2018, 11:50:58 »
Im Anhang hätte ich die Datei kernel/bios/milan/doc/mmilan.txt.

Danke dir, ist geändert. Scheint aber nur die Dokumentation zu betreffen, in milan.inc stand das schon so drin.

Zitat
In MagicMac/kernel/aes/aesevt.s ist mir was auf gefallen:

Huks, das ist natürlich ungeschickt. Muss ich mir mal genauer anschauen, wells auch '030 betrifft.

Zitat
Ich frage mich ob es wirklich Sinn macht da ne spezielle Abfrage zumachen und nicht einfach gernerel die Register der FPU retten. Ob das zeitlich jetzt so ins Gewicht fällt.

Ich frage mich eher ob das überhaupt notwendig ist, kann mich nicht erinnern daß TOS 3.06 das macht. Auch EmuTOS macht das nicht. Wobei die natürlich auch nur umschalten wenn die App gerade einen AES-Aufruf macht.

Online Thorsten Otto

  • Benutzer
  • Beiträge: 1.315
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #133 am: So 16.12.2018, 17:04:02 »
Den FPU-Check im AES hab ich  jetzt geändert. Den Test auf NULL-Frame kann man nicht so einfach rausnehmen wie ich feststellen musste, weil an ein paar anderen Stellen (z.B. wenn eine neue APP gestartet wird) dort lediglich ein NULL-Frame auf dem Stack erzeugt wird. Hoffe das passt für '060, konnte es leider nicht testen weil Aranym kein 060 emuliert, und Hatari beim Versuch abstürzt (könnte das an HDDRIVER liegen? Gibs da ne spezielle Version?)

Bei der Gelegenheit hab ich die CPU/FPU-Erkennung auch geändert, in der "normalen" Version hätte er 060 gar nicht erkannt.

Offline KarlMüller

  • Benutzer
  • Beiträge: 420
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #134 am: Mo 17.12.2018, 19:57:53 »
Im Anhang hätte ich die Datei kernel/bios/milan/doc/mmilan.txt.
Scheint aber nur die Dokumentation zu betreffen, in milan.inc stand das schon so drin.
Ja, dem ist so. Dort habe ich die Infos auch her.

Den FPU-Check im AES hab ich  jetzt geändert. Den Test auf NULL-Frame kann man nicht so einfach rausnehmen wie ich feststellen musste, weil an ein paar anderen Stellen (z.B. wenn eine neue APP gestartet wird) dort lediglich ein NULL-Frame auf dem Stack erzeugt wird. Hoffe das passt für '060,
Also hier funktioniert es. Allerdings hast Du die Variable 'cpu_typ' benutzt bevor sie gesetzt wird. Ich habe das ganze etwas umgestellt.
*
* CPU, Cookies und machine_type
*

 move.w   #8,stack_offset
 jsr      get_cpu_typ
 move.w   d0,cpu_typ
 move.w   #1,cpu020                     ; MATHS.S: 68020-Arithmetik moeglich
 jsr      get_fpu_typ
 cmp.w    #40,cpu_typ
 bcs.s    set_fpu
 bne.s    set_fpu_060
 moveq    #8,d0
 bra.s    set_fpu
set_fpu_060:
 moveq    #16,d0
set_fpu:
 move.b   d0,is_fpu

inst_cook:
 jsr      ivideo                        ; Videosystem initialisieren

 lea      cookies,a0
 move.l   a0,_p_cookies
 moveq    #NCOOKIES,d0
 jsr      icookies                      ; maschinenspez. Cookies

 ; Wegen eines Fehler im MilanTOS. Es setzt bei einem 060
 ; nicht den richtigen Wert.
 clr.l    d1
 move.b   is_fpu,d1
 swap     d1                            ; Wert
 move.l   #'_FPU',d0                    ; key
 bsr      putcookie

*
* "soft"-Cookies (_IDT und MagX)
*
'stack_offset' und 'cpu020' habe einfach auf feste Werte gesetzt. Ein Milan kann nur ein 040 oder 060 haben.
Das mit dem falschem Cookie _FPU ist mindestens bis zum MilanTOS Version vom 2003.09.03.

(könnte das an HDDRIVER liegen? Gibs da ne spezielle Version?)
Nein, könnte natürlich sein das da intern Rücksicht auf den Milan genommen wird.

Bei der Gelegenheit hab ich die CPU/FPU-Erkennung auch geändert, in der "normalen" Version hätte er 060 gar nicht erkannt.
Das ist gut für die Falcon ct60 Fraktion. ;-)

Ich habe noch die Datei MagicMac/kernel/bios/milan/doc/milan_hw.txt in einer neueren Version angehängt.

Online Thorsten Otto

  • Benutzer
  • Beiträge: 1.315
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #135 am: Di 18.12.2018, 01:12:38 »
Allerdings hast Du die Variable 'cpu_typ' benutzt bevor sie gesetzt wird. Ich habe das ganze etwas umgestellt.

Huch, na sowas. Ist gefixt, danke.

'stack_offset' und 'cpu020' habe einfach auf feste Werte gesetzt. Ein Milan kann nur ein 040 oder 060 haben.
Ich hab jetzt nur die Reihenfolge geändert und den Rest gelassen. Denke mal für die paar Byte lohnt es sich nicht, dort irgendwelche Annahmen zu machen.

Das mit dem falschem Cookie _FPU ist mindestens bis zum MilanTOS Version vom 2003.09.03.

Funktioniert das denn so in Zusammenarbeit mit Milan-TOS? Der cookiejar wird ja scheinbar komplett neu angelegt dort, ich sehe aber z.B. nicht daß dort ein _CPU cookie eingetragen wird. Auch ein paar andere wie _SND, _MCH und _VDO fehlen.

Offline KarlMüller

  • Benutzer
  • Beiträge: 420
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #136 am: Di 18.12.2018, 10:12:17 »
Ich hab jetzt nur die Reihenfolge geändert und den Rest gelassen. Denke mal für die paar Byte lohnt es sich nicht, dort irgendwelche Annahmen zu machen.
Das sind keine Annahmen. Der Milan kommt nur mit 040 oder 060 vor und die Funktion get_cpu liefert nur 40 oder 60. Deswegen macht es keinen Sinn 'stack_offset' erst auf sechs und dann immer auf acht zu setzen. Entsprechendes gilt für 'cpu020'.

Funktioniert das denn so in Zusammenarbeit mit Milan-TOS? Der cookiejar wird ja scheinbar komplett neu angelegt dort, ich sehe aber z.B. nicht daß dort ein _CPU cookie eingetragen wird. Auch ein paar andere wie _SND, _MCH und _VDO fehlen.
Das Anlegen der Cookies wird vom MilanTOS erledigt. Dort werden _CPU, _FPU, _VDO, _MCH, _MIL, _PCI, MNAM, _SND, _FDC, _FRB, _AKP, _IDT und EURO angelegt.  Im MagiC Quelltext ist das die Funktion 'icookies'. Mein Zusatz hängt direkt hintendran.

Offline tuxie

  • Benutzer
  • Beiträge: 6.834
  • Falcon! Milan! Schuetzt die Raubvoegel!
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #137 am: Di 18.12.2018, 11:51:38 »
So fühlt sich das dann aktuell bei mir an ^^

https://youtu.be/u9kvFbmaGZk
Tschau Ingo

Online Thorsten Otto

  • Benutzer
  • Beiträge: 1.315
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #138 am: Di 18.12.2018, 14:20:24 »
Nicht übel für so'n altes Schätzchen ;)

Offline KarlMüller

  • Benutzer
  • Beiträge: 420
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #139 am: Mi 19.12.2018, 10:29:34 »
Mal was praktische. Ich habe eine geänderte Version der Funktion find_icon_pos angehängt.

Auch wenn ich das Iconfiy nicht so oft nutze hatte mich von Anfang angestört das die Icons immer von links nach rechts aufgebaut werden, kommt von MultiTOS. Deswegen habe das Programm ICFS installiert. Nun habe ich mir oben genannte Funktion so umgeschrieben das sie von rechts nach links geht.

Ich weis das ist jetzt etwas spezielles, zumal ich den Abstand von unten noch um 16 Pixel erhöht habe, weil hier Appline läuft. Ich wollte jetzt das ganze nicht aufblähen und das konfigurierbar machen. Ist hier per IF/ELSE/ENDIF im Quellcode.