Quellen von Magic, Magxdesk, u.a. auf gitlab ...

[Thorsten Otto]

Hm, IF/ELSE seh ich da keine. Find die Idee aber schon ganz sinnvoll, allerdings müsste man das wohl dann konfigurierbar machen irgendwie (gibt mit Sicherheit sonst wieder welche denen das nicht passt).

[ama]

Wenn ich mich hier kurz laienhaft einmischen darf. Vielleicht versteh ich auch nur nicht um was es genau geht.

Wenn man ICFS installiert hat, kann man doch mit dem ICFS.CPX die Einstellungen für die iconifzierten Fenster machen. Also die Fenster, von rechts nach links ablegen lassen und auch die Position etc. einstellen.

[KarlMüller]

Hm, IF/ELSE seh ich da keine.

Code: [Auswählen]

IF 0
  Original
ELSE
   Neue
ENDIFEs sind zwar nur ein paar Zeilen die ich geändert habe, aber zur Übersichtlichkeit.

Find die Idee aber schon ganz sinnvoll, allerdings müsste man das wohl dann konfigurierbar machen irgendwie (gibt mit Sicherheit sonst wieder welche denen das nicht passt).

Klar, ich frage mich nur was an zusätzlichen Speicher kostet. Beim Milan mag das keine Rolle spielen. Aber wie sieht es beim ST aus.

Was mich auch wundert, wenn ich es richtig  gesehen habe, kann ich wenn  MagiC auf einen ST läuft alle XBIOS Funktionen vom TT oder Falcon aufrufen. Gehört das nicht beschränkt, also xbios_tab je nach Maschine verkürzt. Wobei bei den TT Funktionen wird die Maschine abgefragt, beim DSP nicht.

Wenn man ICFS installiert hat, kann man doch mit dem ICFS.CPX die Einstellungen für die iconifzierten Fenster machen.

Klar geht das und hatte ich auch so, aber wenn ich jetzt die Möglichkeit habe das ins BS zu verschieben, warum ein zusätzliches Programm starten. Beschleunigt etwas den Bootprozess und es hängt kein weiteres Programm im GEM-Trap. Zumal zumindest bei mir das Programm auch irgendeine Ausgabe macht wo durch T-Con bei jedem Start sich öffnet.

Wie geschrieben ist halt was spezielles von mir. Wollte nur den Quellcode teilen falls jemand sich das auch wünscht.
 

[Thorsten Otto]

Code: [Auswählen]

IF 0
  Original
ELSE
   Neue
ENDIF

Also endweder bin ich blind oder.... in der angehängten Datei seh ich da nix. Habs aber jetzt selber eingebaut.

Klar, ich frage mich nur was an zusätzlichen Speicher kostet.

Speicher weniger, ein bisschen zusätzlicher Code halt. Aber ich hatte auch nicht an ICFS gedacht, wems nicht passt kann das sich das ja darüber einstellen.

Was mich auch wundert, wenn ich es richtig  gesehen habe, kann ich wenn  MagiC auf einen ST läuft alle XBIOS Funktionen vom TT oder Falcon aufrufen. Gehört das nicht beschränkt, also xbios_tab je nach Maschine verkürzt. Wobei bei den TT Funktionen wird die Maschine abgefragt, beim DSP nicht.

Hm, ja, eigentlich schon. Bzw. müsste man mal genau checken ob da irgendwelche Katastrophen passieren, wenn man Funktionen aufruft für die die entsprechende Hardware garnicht vorhanden ist. Aber vermutlich war das schon immer so, wüsste nicht daß es für ST abgespeckte Versionen gegeben hat.

[gh-baden]

So fühlt sich das dann aktuell bei mir an ^^

https://youtu.be/u9kvFbmaGZk

Da muss man sich anschnallen, und zwar doppelt: a) noch keinen solchen TT gesehen, erhöhte Schwuppdizität! – worauf beziehen sich die 54 MHz?, und b) du darfst bitte nicht so viel schwenken und zoomen mit der Kamera, ich werd da reisekrank :-) Lieber feste Schnitte …

[1ST1]

Prozesortakt. Dieser TT ist overclocked bis zum Anschlag.

[KarlMüller]

Also endweder bin ich blind oder.... in der angehängten Datei seh ich da nix. Habs aber jetzt selber eingebaut.

So hatte ich es gemeint hatte. Bei nächsten wird es besser beschrieben.

MagicMac/kernel/aes/aesmain.s

Code: [Auswählen]

dsp_xgrf_stepcalc:
 cmpi.w   #5,4(a1)                 ; contrl[2] (Laenge intout) == 5 ?
 beq.b    dsp_appl_getinfo
 cmpi.w   #1,4(a1)                 ; contrl[2] (Laenge intout) == 1 ? --> appl_getinfo_str
 beq.b    dsp_appl_getinfo
 pea      10(a4)
 pea      8(a4)
 pea      6(a4)
Der AES Opcode 130 ist dreimal belegt. Einmal durch xgrf_stepcalc von GEM/3, dann durch appl_getinfo zum dritten gibt es appl_getinfo_str. Beim letzterem ist control[2] = 1 statt fünf und control[3] = 4 statt null, denn hier werden Zeichenketten zurück geliefert. Das wurde irgendwann bei XaAES eingeführt. Deswegen die zusätzliche Abfrage.

[Thorsten Otto]

Das wurde irgendwann bei XaAES eingeführt. Deswegen die zusätzliche Abfrage.

Sollte eigentlich unnötig sein, da man das Vorhandensein sowieso vorher ermitteln muss (also appl_getinfo(96), mit dem normalen interface). Kann aber auch nicht schaden.

PS.: noch ein Bitte: bei neuem Code nach Möglichkeit englische Kommentare benutzen, da wir nun nicht mehr die einzigen sind die das lesen

[tuxie]

So fühlt sich das dann aktuell bei mir an ^^

https://youtu.be/u9kvFbmaGZk

Da muss man sich anschnallen, und zwar doppelt: a) noch keinen solchen TT gesehen, erhöhte Schwuppdizität! – worauf beziehen sich die 54 MHz?, und b) du darfst bitte nicht so viel schwenken und zoomen mit der Kamera, ich werd da reisekrank :-) Lieber feste Schnitte …

@gh-baden
Das war nur quick und dirty aufgenommen mitm Handy nix geschnitten ^^
Und jep 18Mhz Bus und 54MHz CPU und das Stabil (jetzt) man beachte den Vergleich zum Milan

[KarlMüller]

Wenn es geht jetzt hier keine Dinge über einen beschleunigten TT austauschen. Dazu was eigenes auf machen.
Danke!

Sollte eigentlich unnötig sein, da man das Vorhandensein sowieso vorher ermitteln muss (also appl_getinfo(96), mit dem normalen interface).

Echt? Kannte ich so nicht. Aber im Vorgriff auf die Erweiterung von appl_getinfo ist es so oder so nötig.

bei neuem Code nach Möglichkeit englische Kommentare benutzen, da wir nun nicht mehr die einzigen sind die das lesen

Ich versuch es. Wobei es gemein ist, ich muss mich ja auch ständig durch irgendwelche englische Texte quälen.

Ich habe mich schon immer gefragt warum MagiC in der Version 6 die Menüzeile nicht grau dastellt trotz das man in der INF beim Parameter _FLG das siebte Bit gesetzt hat. Jetzt weiss ich das dies nur funktionierte wenn man einen unproportionalen Zeichensatz nutzen würde. Also geändert:

MagicMac/kernel/aes/aesmen.s in der Funktion menu_on

Code: [Auswählen]

* Menue neu eingeschaltet. Auf mich umschalten

 move.l   a4,menu_app              ; Eigner des Menues umsetzen
 move.l   a4,a0
 bsr      set_desktop              ; und Hintergrund mit umschalten
mon__ismine:
 move.l   a5,menutree              ; Menuebaum merken

* Set menu background color

 btst     #7,look_flags+1          ; 3D look for menu
 beq.b    mon_co_end
mon_col_loop:
 move.w ob_type(a5),d1
 and.w #$ff,d1
 cmp.w #$14,d1                  ; G_BOX ?
 bne.s mon_col_box
 andi.w   #-$0010,$e(a5)
 ori.w #$0008,$0e(a5)
 andi.w   #-$0071,$e(a5)
 ori.w    #$0070,$e(a5)
 bra.s mon_col_box1
mon_col_box:
 ori.w    #$0400,ob_flags(a5)
mon_col_box1:
 moveq    #$20,d1
 movea.l  a5,a4
 lea      $0018(a5),a5
 and.w    $0008(a4),d1
 beq.s    mon_col_loop
 move.l   menutree,a5
mon_co_end:

* Proportional-Systemfont: Menuetitel neu ausrichten

 tst.w    finfo_big+fontmono
 bne      mon_fontmono
 move.w   2*24+ob_head(a5),d0      ; erster Menuetitel
 move.w   2*24+ob_x(a5),d7         ; abs. Pos. des ersten Titels
 bmi      mon_fontmono             ; keine Menuetitel
 move.w   ob_tail(a5),d1           ; rechter Teil (Menues)
 mulu     #24,d1
 move.w   ob_head(a5,d1.l),d1      ; erstes Menue
 moveq    #0,d5                    ; Pos. des ersten Titels
mon_title_loop:
 mulu     #24,d0
 lea      0(a5,d0.l),a4            ; a4 = OBJECT *
 move.w   d5,ob_x(a4)              ; x-Pos fuer Menuetitel
 mulu     #24,d1
 lea      0(a5,d1.l),a6
 move.w   d5,ob_x(a6)              ; Position auch fuer Menue
 add.w    d7,ob_x(a6)
 move.l   a4,a0                    ; OBJECT *
 jsr      stw_title                ; Breite setzen
 add.w    ob_width(a4),d5          ; Breite addieren
 move.w   ob_next(a6),d1           ; naechtes Menue
 move.w   ob_next(a4),d0           ; naechter Titel
 cmpi.w   #2,d0                    ; ist der Parent ?
 bne.b    mon_title_loop           ; nein
 move.w   d5,2*24+ob_width(a5)     ; Breite des Parent setzen

Der Bereich ab "* Set menu background color" bis "* Proportional-Systemfont: Menuetitel neu ausrichten" ist neu. Danach sind zwei Stellen entfallen, die etwa so aussehen.

Code: [Auswählen]

btst     #7,look_flags+1
 beq.b    mon_2d1
 ori.w    #FL3DBAK,24+ob_flags(a5) ; Objekt 1: Menueleiste
mon_2d1:
Und wieder ist ein Programm MENU3D aus dem Startordner entfallen. Wenn das so weitergeht dann ist der bald leer.

[Thorsten Otto]

Ehm, das ist mir ehrlich gesagt zu unübersichtlich Benutzt du git, oder hast du sonst irgend ne Möglichkeit ein diff vorher/nachher zu machen? Wenn nicht, lieber die geänderte Datei komplett anhängen, solange ich die nicht selber an den gleichen Stellen geändert hab ist das einfacher.

[KarlMüller]

Ehm, das ist mir ehrlich gesagt zu unübersichtlich

Naja, in dem Fall wäre es ein einfaches rein kopieren.

Anbei ein diff. Musste ich mit dem Apfel erstellen. Mit der Mupfel kommen immer Leerzeilen zwischen den einzelnen Zeilen.

[Thorsten Otto]

Naja, in dem Fall wäre es ein einfaches rein kopieren.

Danke, war trotzdem einfacher so. Habs jetzt erstmal so eingebaut, aber ein paar Fragen bleiben noch offen: wenn ich das richtig sehen, wurde vorher nur bei allen Menütiteln FL3DBAK gesetzt, die neue Routine macht das jetzt bei allen Objekten. Passt das trotzdem? Ausserdem: gab es womöglich einen Grund warum das nur bei nicht-proportionalen Zeichensätzen gemacht wurde? In objc_sysvar(MX_MENUCOL) ist nämlich die gleiche Abfrage drin.

[KarlMüller]

wenn ich das richtig sehen, wurde vorher nur bei allen Menütiteln FL3DBAK gesetzt, die neue Routine macht das jetzt bei allen Objekten. Passt das trotzdem?

Die Routine hat auch bei den Boxen das  FL3DBAK gesetzt. Fand ich nicht gut. Nun wird nur die Farbe verändert.

gab es womöglich einen Grund warum das nur bei nicht-proportionalen Zeichensätzen gemacht wurde?

Es ist nur bei proportionalen Zeichensätze aktiv gewesen. Ich kenne keinen Grund, kann mir aktuell auch keinen vorstellen und finde auch keinen Hinweis in der Doku warum.

In objc_sysvar(MX_MENUCOL) ist nämlich die gleiche Abfrage drin.

Stimmt das hatte ich gesehen, aber vergessen zu ändern.

[Ektus]

Ich versuche gerade, das frisch kompilierte MagiC auf meinem CT63+CTPCUI Falcon zu starten. Dort läuft ja ein modifizierter MaiC-Boooter, der diverse Sachen in der MAGIC.RAM patched, Dabei kommt eine Fehlermeldung:

WARNING ! A part is not patched ! (19/20)

Der Rechner kommt damit nicht bis zum Desktop, sondern hängt nach den Ausgaben von HDDRIVER.


Frohe Weihnachten!

Ektus.

[Thorsten Otto]

Müsste ich mir mal anschauen was der genau macht, vermutlich findet er durch die Änderungen irgendwelche Stellen nicht. Je nachdem wie kompliziert das ist, könnte man evtl. auch den Kernel ändern daß man keinen speziellen Booter für CT60 mehr braucht.

Wenn ich das richtig verstanden habe, patch der im wesentlich

• 030 pmmu Befehle durch nops. Ist IMHO unnötig, weil an allen Stellen wo die benutzt werden ein exception Handler für illegal opcodes verwendet wird. Müsste man aber mal testen.
  
• Patcht die Stelle wo MagiC versucht den CPU-Typ festzustellen (könnte die sein die nicht gefunden wird, weil sie sich geändert hat). Grund für den Patch ist hier daß MagiC die '060 speziellen Vektoren für unsupported integer instruction etc. überschreibt und nicht wiederherstellt, und damit ein evtl schon installiertes 060 FPSP aushebelt. Das müsste man sicher ändern.
  Alternativ könnte man das schon vorhandene FPSP60 ähnlich wie bei der Hades-Version mit in den Kernel packen, allerdings ist das relativ gross, und wird ja bei "normalen" Maschinen nicht gebraucht.
  

Weisst du zufällig ob da noch andere Sachen gemacht werden?

[Ektus]

Ich weiß leider nicht genau, was da alles gepatched wird. Es sind jedenfalls 21 Einträge. Ausgaben beim Systemstart (vom Bildschirm abgetippt):

Code: [Auswählen]

Patch vectors 3
Patch cache 2
Patch vectors 1
Patch vectors 2
Patch CTPCI
Patch PMMU 030 tree
Patch cache 1
Patch DSP
Patch floppy
Patch cache 3
Patch PSG printer
Patch movep 1
Patch movep 2
Patch movep 1
Patch cache 2
Patch reset 1
Patch cache 2
Patch reset 2
Patch CPU type
Patch FPU cookie
Patch context FPU

Diese Änderungen sind zusätzlich zum vorher schon gepatchten Magic.ram und werden bei jedem Systemstart ausgeführt.

MfG
Ektus.

[Thorsten Otto]

Ok, danke, muss ich wohl doch mal in den Quellcode schauen. Einiges kann man vermutlich im Kernel schon ändern, z.B. die movep die vermutlich nur aus Performance-Gründen geändert werden um sie nicht emulieren zu müssen. Auch die CPU/FPU  Cookies sollten eigentlich nach den letzten Änderungen schon stimmen. Der Rest ist mir noch ein Rätsel, hoffe mal ich finde da Kommentare im Source

[Petari]

Ich habe geseht diese WEBpage auf Gitlab einige Monaten früher. Erste Gedanke war: wunderbar ! 
Und dann ... nur kleine Teilen von ... Aber es ist was geht heute überall - irreführend Titeln, ziehen Achtung auf jede Preis.
Warum firmen, leute wer arbeitete auf es nicht einfach macht alles öffentlich ? Kein Geld von diese 20-30 Jahr alt OS-en überhaupt.
Tatsachlich Ich habe meine Teorie warum ist so ...

[Thorsten Otto]

Vlt. solltest du nochmal nachschauen. AK hat mittlerweile alles öffentlich gemacht, was von ihm ist. Nicht veröffentlicht sind lediglich NVDI (weil das von Behne&Behne ist), und MagicPC (von Franz Schmerbeck). Der Rest ist komplett vorhanden, und es lassen sich daraus die Magic-Kernel sowohl für MagicMac als auch Atari/Milan/Hades bauen.

Tatsachlich Ich habe meine Teorie warum ist so ...

Schön für dich.