AtariX => MagicOnLinux

[AndreasKromke]

WTF!
Im S/W-Bildschirmtreiber sind sabotierende Assemblerbefehle drin:

        subq.w    #1,d0             ;1 Plane ?
        bne.s     vt_set_b_exit

Wenn man die entfernt, funktioniert im VT52-Emulator (also ohne VT52.PRG) die Umschaltung der Vorder-/Hintergrundfarben.

Grund: Hier ist d0 undefiniert, und die Anzahl der Farbebenen ist immer Eins. Nun hat d0 aber immer den Wert 8, und damit wird das Umschalten der Farben sabotiert.

Auch lustig: In S/W gibt es ja nur vier Modi: Schwarz auf Weiß, Weiß auf Schwarz (also invertiert), alles weiß oder alles schwarz. Für den ersten Modus gibt es eine schnelle Funktion. Die könnte auch invertieren, was aber hier nicht genutzt wird. Die anderen drei Modi verwenden eine langsame Funktion, die überflüssigerweise 1,2,4 und 8 Farbenen unterstützt, also auch vier, 16 und 256 Farben.

Das wirkt alles etwas wild zusammenkopiert.

[KarlMüller]

Was sagt "xcode-select -p"?

/Library/Developer/CommandLineTools

OK, das ist denke ich der Grund warum das nicht funktioniert.

Führe mal bitte

Code: [Auswählen]

sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
aus (anschließend nochmal mit xcode-select -p verifizieren das der Pfad geändert wurde) und versuche dann nochmal "cmake -G Xcode .."

Hat ein paar Tage gedauert. Das hat jetzt funktioniert. Musste erst noch die Xcode App installieren. Da muss man wohl wissen, dass alle Programme, wie z.B. GarageBand.App, aktuell sein müüsen, sonst kann man Xcode nicht installieren. Ist ja logisch. 

Muss jetzt mir das mit dem root_fs noch anschauen. Aber erstmal Danke!

[goetz @ 3rz]

Script 4 und Edison 1.0 haben unter 32k Farben einen schwarzen Hintergrund in offenen Fenstern – das ist weg, wenn ich auf 256 Farben (oder weniger) wechsle.

[AndreasKromke]

Signum 4 4.40 (25.05.98), englische oder amerikanische Version.
Aber Signum 4 ist ja nicht Script 4. 

[AndreasKromke]

Ich habe nur Script 1 und 2. Ja, die haben das gleiche Probem.

Für Edison finde ich nur Demo-Versionen. Allein die Anleitung sieht schon gruselig aus, mehr Schreibfehler als alles andere...

...
   Schließen
      Sließt das aktuelle Fenster.

   alles gross

   Programmnamen Suchen..

      Wenn noch keine JOB-Datei im Speicher ist wird hier ein Prototyp

      Läd die in der Datei ED_IT.INF, oder eine unter *.INF gesicherte

[AndreasKromke]

Es ist bedauerlich, daß keiner der mir bekannten Resource-Editoren die pixelgenaue Plazierung von Objekten vollständig unterstützt. Der Autor von INTRFACE hat damals immerhin eine halbherzige Lösung eingebaut, die schon einmal hilfreich war. Dieses AES-Feature war ursprünglich undokumentiert, und ich weiß nicht, ob das inzwischen offengelegt wurde. Technisch: Die oberen 8 Bit von x/y/w/h sind vorzeichenbehaftet (!!!) und in Pixel-Einheiten, die unteren sind in Zeichen-Einheiten. INTRFACE kann (und will, meine Diskussionen damals waren fruchtlos ..) nur positive Pixel-"offsets" von Null bis 7 oder 15 unterstützen, möglich wären -128 bis +127.

Ärgerlich ist auch, daß ich z.B. mit INTRFACE zwar von einem Objekt zum nächsten Geschwist gehen kann, aber dort dann die Plazierung nicht ändern kann (x/y/w/h) und nicht einmal (!) das "hidden"-Flag ändern kann. Mist. Dadurch kann ich in Magxdesk keine Tabs bearbeiten.

Was z.B. zu neueren GUI-Systemen völlig fehlt, ist ein Fenster mit einer Baum-Ansicht, wo man jedes Objekt einzeln auswählen und dann jedes (!) Attribut ändern kann. Die Hierarchie der Objekte wäre dann auch sichtbar.

Was bleibt? Die RSC-Datei als C-Quelltext exportieren und dann selber basteln. Bit-Fieselei. Oder zur Laufzeit am geladenen Baum herumfummeln, wie es, wie ich gerade sehe, CHGRES tut.

[Thorsten Otto]

Es ist bedauerlich, daß keiner der mir bekannten Resource-Editoren die pixelgenaue Plazierung von Objekten vollständig unterstützt.

Meinst du sowas? ORCS kann sowas selbstverständlich.

Wenn man X-Raster und/oder Y-Raster im Menü deaktiviert, kann man Objekte auch pixelweise verschieben.

Hidden-Flag geht selbstverständlich auch: rechts-klick auf das Parent-Objekt, dann "Objekte hervorholen".

[AndreasKromke]

Es ist bedauerlich, daß keiner der mir bekannten Resource-Editoren die pixelgenaue Plazierung von Objekten vollständig unterstützt.

Meinst du sowas? ORCS kann sowas selbstverständlich.

Wenn man X-Raster und/oder Y-Raster im Menü deaktiviert, kann man Objekte auch pixelweise verschieben.

Hidden-Flag geht selbstverständlich auch: rechts-klick auf das Parent-Objekt, dann "Objekte hervorholen".

Ich möchte getrennt Zeichen- und Pixelposition eintragen. Das geht in INTRFACE z.B. mit y="3/6". Dann liegt das Objekt normalerweise bei 54 (3 * 16 + 6) und in "ST mid" auf 30 (3 * 8 + 6). Das habe ich damals massenhaft gebraucht. Was in INTRFACE nicht geht, ist z.B. h=3/-1. Ich möchte dabei eine Höhe von drei Zeichen haben, aber einen Pixel weniger. Das sind normalerweise 47 und in "ST mid" 23. Was INTRFACE auch nicht kann, ist h=3/16, also drei Zeichen plus 16 Pixel, stattdessen macht es 4/0 draus. Überflüssigerweise.

Wenn ich Registerkarten basteln muß, wie z.B. an den Einstellungen von Magxdesk, dann habe ich z.B. vier IBOXen  an derselben Position, von denen immer genau eine nicht "hidden" ist. Ich muß im Editor nun genau diese eine sichtbar machen, damit ich sie ändern kann. In INTRFACE kann man sich mit "nächstes" durchhangeln und jedes ach so seltene Attribut ändern, nur nicht das eine: hidden. Das geht über verbergen/aufdecken, aber das geht in meinem Fall nicht. Ich habe damals, glaube ich, einen Hex-Editor genommen und die Binärdatei geändert. Quälerei.

[Thorsten Otto]

Was in INTRFACE nicht geht, ist z.B. h=3/-1.

Wenn du mir erklärst wie man das unterscheiden soll kann ich das einbauen. Ich frage mich nur wie das gehen soll. Wenn du in ST-High solche Koordinaten eingibst, kommt da halt 47 raus. Ob die 47 dann ursprünglich 3/-1 oder 2/+15 war, kann der Editor nicht unterscheiden.

Wenn ich Registerkarten basteln muß, wie z.B. an den Einstellungen von Magxdesk, dann habe ich z.B. vier IBOXen  an derselben Position, von denen immer genau eine nicht "hidden" ist.

Ja, hab auch einige wenige Programme wo sowas genutzt wird. Ist ein bisschen umständlich dort mit dem Hidden-Attribut zu arbeiten, geht aber. Das kann man im Editor auch kaum besser machen, weil es keine Konvention gibt wie Register-Karten verwaltet werden, dann hängt halt davon ab was das Programm später damit macht.

Das geht über verbergen/aufdecken, aber das geht in meinem Fall nicht.

Warum nicht? Im Zweifelsfall alle aufdecken, dann wieder alle (bis auf eins) verstecken. Hat bei mir noch immer funktioniert. Was auch helfen kann ist, die I-Boxen in denen solche "Registerkarten" üblicherweise liegen, unterschiedlich gross zu machen, dann ist der Rand von hintenliegenden Boxen immer noch erreichbar.

[AndreasKromke]

Wenn du mir erklärst wie man das unterscheiden soll kann ich das einbauen. Ich frage mich nur wie das gehen soll. Wenn du in ST-High solche Koordinaten eingibst, kommt da halt 47 raus. Ob die 47 dann ursprünglich 3/-1 oder 2/+15 war, kann der Editor nicht unterscheiden.

Doch, kann er. Theoretisch. In der RSC-Datei steht dann entweder 0xff03 oder 0x0f02. Jedenfalls, solange man sie nicht per rsrc_load() geladen hat. Sonst ist halt Essig. .

[Thorsten Otto]

Ja, aber nach dem laden stehen da nur noch die angepassten Koordinaten. Inbesondere wenn rsrc_load benutzt wurde, kann der Editor nicht wissen was da vorher in der Datei gestanden hat.

[AndreasKromke]

Ja, aber nach dem laden stehen da nur noch die angepassten Koordinaten. Inbesondere wenn rsrc_load benutzt wurde, kann der Editor nicht wissen was da vorher in der Datei gestanden hat.

Genau das hatte ich gemeint. Nach dem Laden.

PS: Wenn ich sechzig Jahre jünger wäre, dann würde ich mir ein menschenlesbares Zwischenformat für RSC-Dateien ausdenken, vielleicht xml-basiert, und einen RSC-Editor schreiben, der .rsc in .xml wandeln kann und umgekehrt. Ich würde dann, wie ich es Android oder Matlab kenne, auch eine Baumstruktur einblenden, bei der man sehen kann, welches Objekt welches als Elt und Geschwist hat, und dann könnte man alle Eigenschaften jedes Objeks ändern oder auch ein Objekt im Baum umsortieren. Wenn irgendwas schiefläuft, könnte man dann immer noch die xml-Datei anschauen und damit weiterarbeiten. Außerdem müßte eine RSC-Datei multilingual sein, zumindest die xml-Variante, aus der man dann vielleicht unterschiedliche RSC-Dateien erzeugen kann.

Aber das lohnt alles nicht mehr.

[Thorsten Otto]

Genau das hatte ich gemeint. Nach dem Laden.

Ehm ja, dann versteh ich das Problem nicht. Woher soll der Editor jetzt wissen wie er die Koordinaten wieder abspeichern soll? Natürlich benutzt ORCS nicht rsrc_load() sondern eigene Routinen, aber das Resultat ist das gleiche: nach dem Laden wird nur noch mit Pixel-Werten gearbeitet. Erst beim speichern wird das wieder zurück gerechnet.

PS: Wenn ich sechzig Jahre jünger wäre, dann würde ich mir ein menschenlesbares Zwischenformat für RSC-Dateien ausdenken, vielleicht xml-basiert,

Eigentlich kann ORCS sowas schon Sieht für chgres dann z.B. so aus

Code: [Auswählen]

<?xml version="1.0" encoding="utf-8" ?>
<!-- created by ORCS 2.18 -->

<rscfile name="CHGRES.RSC" generator="ORCS" version="2.18">
  <tree index="0" name="MAIN_DIALOG" type="dialog">
    <object type="G_BOX" index="0" name="">
      <x>0</x>
      <y>0</y>
      <width>40</width>
      <height>18</height>
      <flags>1024</flags>
      <state>16</state>
      <type>28948</type>
      <exttype>113</exttype>
      <box>
        <character>9216</character>
        <framesize>2</framesize>
        <framecolor>1</framecolor>
        <textcolor>1</textcolor>
        <opaque>0</opaque>
        <fillpattern>0</fillpattern>
        <fillcolor>0</fillcolor>
      </box>
      <child>
        <object type="G_CICON" index="1" name="CHGRES_ICON">
          <x>34</x>
          <y>0</y>
          <width>8192</width>
          <height>8192</height>
          <flags>0</flags>
          <state>0</state>
          <type>33</type>
          <exttype>0</exttype>
          <ciconblk>
            <character>9216</character>
            <datacolor>1</datacolor>
            <maskcolor>0</maskcolor>
            <x>0</x>
            <y>0</y>
            <width>32</width>
            <height>32</height>
            <xchar>0</xchar>
            <ychar>0</ychar>
            <xtext>13</xtext>
            <ytext>13</ytext>
            <wtext>6</wtext>
            <htext>8</htext>
            <text></text>
            <data>
<![CDATA[
00000000000000001ffffff0200000082fffffe8280000282801002828038028
2807c028280100282801002828810228298103282bffffa82981032828810228
28010028280100282807c0282803802828010028280000282fffffe820000008
200000081ff01ff0001ff00003ffff8007ffffc0000000000000000000000000
]]>
            </data>
            <mask>
<![CDATA[
000000003ffffff87ffffffc7ffffffc7ffffffc7ffffffc7ffffffc7ffffffc
7ffffffc7ffffffc7ffffffc7ffffffc7ffffffc7ffffffc7ffffffc7ffffffc
7ffffffc7ffffffc7ffffffc7ffffffc7ffffffc7ffffffc7ffffffc7ffffffc
7ffffffc7ffffffc3ffffff80fffffe00fffffe00fffffe00000000000000000
]]>
            </mask>
            <cicon planes="4">
              <colordata>
<![CDATA[
000000003ffffffc7ffffffe7ffffffe7000000e7000000e700ff00e700ff00e
700ff00e700ff00e7000ff0e7000ff0e7000ff0e7000ff0e70f0f00e70f0f00e
70f0f00e70f0f00e7000ff0e7000ff0e7000ff0e7000ff0e7000000e7000000e
7ffffffe7ffffffe7ffffffe3feff7fc001ff8000000000003ffffc000000000
000000003ffffffc7ffffffe7ffffffe7000000e7000000e700f0f0e700f0f0e
700f0f0e700f0f0e700ff00e700ff00e700ff00e700ff00e70f00f0e70f00f0e
70f00f0e70f00f0e700ff00e700ff00e700ff00e700ff00e7000000e7000000e
7ffffffe7ffffffe7ffffffe3feff7fc001ff8000000000003ffffc000000000
000000003ffffffc7ffffffe7ffffffe7000000e7000000e700f000e700f000e
700f000e700f000e70ff0f0e70ff0f0e70ff0f0e70ff0f0e70f0000e70f0000e
70f0000e70f0000e70ff0f0e70ff0f0e70ff0f0e70ff0f0e7000000e7000000e
7ffffffe7ffffe7e7ffffe7e3feff7fc001ff8000000000003ffffc000000000
000000003ffffffc400000025ffffffa5000000a5000000a500f000a500f000a
500f000a500f000a5000000a5000000a5000000a5000000a500fff0a500fff0a
500fff0a500fff0a50ffff0a50ffff0a50ffff0a50ffff0a5000000a5000000a
5ffffffa40000002400000023ff00ffc0010080001ffff8003ffffc000000000
]]>
              </colordata>
              <colormask>
<![CDATA[
7ffffffeffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffffff7ffffffe07ffffe007ffffe007ffffe0
]]>
              </colormask>
            </cicon>
          </ciconblk>
        </object>
        <object type="G_STRING" index="2" name="">
          <x>2</x>
          <y>2</y>
          <width>8</width>
          <height>1</height>
          <flags>0</flags>
          <state>0</state>
          <type>28</type>
          <exttype>0</exttype>
          <string>
            <text>Colours:</text>
          </string>
        </object>
        <object type="G_BUTTON" index="3" name="CHGRES_COLORS">
          <x>11</x>
          <y>2</y>
          <width>9</width>
          <height>1</height>
          <flags>576</flags>
          <state>32</state>
          <type>26</type>
          <exttype>0</exttype>
          <string>
            <text>012345678</text>
          </string>
        </object>
... usw.
    </object>
  </tree>
  <freestring index="0" name="FS_CHANGE_RES" type="string">
    <text> Select Resolution </text>
  </freestring>
  <freestring index="1" name="FS_VIRTUAL" type="string">
    <text>virtual</text>
  </freestring>
  <freestring index="2" name="FS_LOW" type="string">
    <text>Low</text>
  </freestring>
  <freestring index="3" name="FS_MED" type="string">
    <text>Medium</text>
  </freestring>
  <freestring index="4" name="FS_HIGH" type="string">
    <text>High</text>
  </freestring>
</rscfile>



Außerdem müßte eine RSC-Datei multilingual sein

Hatte ich mal überlegt, aber dann wieder aufgegeben. RSM kann sowas, aber meiner Meinung nach ist das Format Schrott. MagiC macht solche Ambitionen auch zunichte, weil die Position der Shortcuts in ob_state kodiert wird. Damit ändern sich dann nicht nur die Texte, sondern auch ob_state je nach Sprache.

[AndreasKromke]

Ich bin beeindruckt.

[AndreasKromke]

Dank Thorstens Dekompilations-Genie habe ich die ET4k-Version von CHGRES an den Emulator angepaßt, wobei ich außer der GUI alles rausgeworfen habe. Die RSC-Dateien muß ich noch von Überflüssigem befreien, aber die nicht verwendeten Elemente stören erstmal nicht.

Was leider derzeit nicht funktionieren kann, ist der Auflösungswechsel durch Neustart allein des AES: Man sieht dann nur, daß der Bildschirm einmal neu aufgebaut wird. Immerhin stürzt erstaunlicherweise nichts dabei ab. Aber es gibt einen Trick: Über Ctrl-Cmd-Alt-Del kann man einen Atari-Warmstart auslösen, und dann startet (hoffentlich) der Emulator fast ganz von vorn und mit der neuen Einstellung. Es wäre natürlich nett, wenn das Emulator-Fenster dabei nicht geschlossen und neu geöffnet würde, aber das benötigt noch einige Umbauten. Immerhin kann man so einigermaßen flott z.B. nach "ST high" wechseln, ohne neue Kommandozeile oder Änderungen an der config-Datei.

Die Einstellungen von CHGRES sind übrigens nicht persistent; sie wirken also nur einmal für den nächsten Warmstart. Und die Bildschirmgrößen sind noch fest, die habe ich mir so ausgedacht.