atari-home.de - Foren
Software => Alternative Betriebssysteme => Thema gestartet von: KarlMüller am Di 04.12.2018, 19:34:13
-
Um das ganze mal zu entzerren.
Was bisher geschah:
Hades? Ich sehe das BIOS nicht. Ist es möglich?
Gerade mal getestet. Da scheint noch eine Datei für zu fehlen (hades.inc) scheinbar mit Definitionen für die Hardware-Addressen. Er meckert über solche Sachen wie pci_vga_reg, hlt (head load time) etc. Weiss jemand wo man da Ersatz für finden kann?
Hades? Ich sehe das BIOS nicht. Ist es möglich?
Gerade mal getestet. Da scheint noch eine Datei für zu fehlen (hades.inc) scheinbar mit Definitionen für die Hardware-Addressen. Er meckert über solche Sachen wie pci_vga_reg, hlt (head load time) etc. Weiss jemand wo man da Ersatz für finden kann?
;video auflîsung 2=st high 6=tt high
vidmo: equ 2
vidmo00: equ vidmo*$100
pci_vga_base: equ $80000000 ;screen ram beginn
isa_vga_base: equ $ff000000 ;screen ram beginn
pci_vga_reg: equ $b0000000 ;vga register
isa_vga_reg: equ $fff00000 ;vga register
pci_conf1: equ $a0010000 ;pci config
pci_conf2: equ $a0020000 ;pci config
pci_conf3: equ $a0040000 ;pci config
pci_conf4: equ $a0080000 ;pci config
mem_max: equ $40000000 ;memory maximum 1 GB
;hades hardwareregister
main_status: equ $fff00080
data_reg: equ $fff00082
ldor: equ $fff000c0
ldcr: equ $fff000e0
; Hardwareregister
dmahigh: equ $FFFF8608
dmamid: equ $FFFF860B
dmalow: equ $FFFF860D
gpip: equ $FFFFFA81 ; TTMFP: Interface Port Datenregister
; sonstige Variablen
defhdinf: equ $302 ; Default hdinf. byt 0 -> anzahl versuche byt 1 -> taktrate (hd default)
ed: equ 0 ; clockraten fÅr verschiedene format
hd: equ 2
dd: equ 3
hlt: equ 3 ;head load time in milisekunden (in 1ms schriten 1-128ms)
hut: equ 120 ;head unload time in ms (in 16ms schritten 8-120ms)
Noch etwas?
Noch etwas?
Ja, ein paar SCSI-Addressen noch, aber die standen noch als Kommentar irgendwo anders. Den Rest konnte ich mir grösstenteils zusammen reimen. Vielen Dank!
Was mich noch irritiert:
gpip: equ $FFFFFA81 ; TTMFP: Interface Port Datenregister
Hat der Hades den "normalen" MFP gar nicht?
Ja, ein paar SCSI-Addressen noch, aber die standen noch als Kommentar irgendwo anders.
Das liegt daran, weil die Routinen eins zu eins den Modifikationen des TOS 3.06 für den Hades entnommen sind.
Was mich noch irritiert:
gpip: equ $FFFFFA81 ; TTMFP: Interface Port Datenregister
Hat der Hades den "normalen" MFP gar nicht?
Doch hat er. Liegt ganz normal an den Adressen wie beim ST/TT.
-
Bleibt nur noch eine Ungereimtheit: im exception-handler wird der SP auf eine Addresse gesetzt die nirgendwo definiert ist. In der ST-Version wird das nicht gemacht. Da muss ich mir jetzt noch ein freies Plätzchen suchen.
Ich nehme an Du meinst in HAD_EXEC.S die Variable "startup_stk". Die ist
startup_stk: equ $5758
Allerdings macht das meiner Meinung keinen Sinn bei MagiC. Die Adresse stammt aus TOS 3.06
Auszug aus der BSS von TOS 3.06:
$00004b54: _msec
$00004b56: _prtbbval
$00004f58: _supstk 2*1024=$800
$00005758: _prtbflg
$0000575A: _prtbdmask
Wenn ich das richtig verstanden habe ist das der Supervisor Stack.
Könnte in MagiC dazu den Inhalt der Variable pgm_superst genutzt werden? Diese wird zumindest am Anfang des Bios definiert.
-
Ja genau, die meinte ich. Dort Addressen von TOS 3.06 zu nehmen macht logischerweise keinen Sinn, die internen Variablen von Magic sind natürlich ganz woanders.
Ob man den pgm_superstk nehmen kann bin ich nicht sicher, sieht mir so aus als ob der nach Ausführung der Auto-Ordner-Programm vom AES geerbt wird. Der liegt auch nicht am Anfang des BIOS, sondern wird per Mxalloc angefordert. Ich bin mir auch nicht ganz sicher warum das überhaupt gemacht wird, das wird weder in der "normalen" Version von MagiC, noch in TOS 3.06 gemacht. I.d.R. wird das Programm kurz danach sowieso beendet. Wenn du da mehr weisst, immer her damit ;) Mit Hades kenne ich mich kaum aus (gibt ja auch nicht viel offizielle Dokumentation dazu).
-
Ja genau, die meinte ich. ...
Wenn du da mehr weisst, immer her damit
Tut mir leid ich habe da auch nicht mehr und versuche auch nur aus dem wenig was zu finden.
Hier kann nur Andreas Kromke oder Fredi Aschwanden helfen. Andere alternative wäre ein vorhandenes MAGIC.RAM vom Hades.
Der Code von MagiC ist fast ein zu ein aus dem was ich als Patch kenne. In letztem fehlt die Möglichkeit per "Return" ins Programm zurück zukehren.
Der Sinn des ganzen könnte sein das der vorhanden Stack nicht überschrieben wird um korrekte Daten aus dem möglicherweise defekten Stack zu bekommen. Die exception Routine spring ja mal nach reg_aus oder string_out.
Wenn nur die Kaltstart Funktion vorhanden wäre, würde ich einfach in hades.inc der Variable startup_stk einen Speicherbereich zuordnen.
-
Andere alternative wäre ein vorhandenes MAGIC.RAM vom Hades.
Würde ich auch nehmen ;) Wenn ich davon ausgehe, daß da nur Kleinigkeiten anders als in dem veröffentlichten Source sind, sollten sich die Stellen eigentlich relativ schnell finden lassen.
In letztem fehlt die Möglichkeit per "Return" ins Programm zurück zukehren.
Das ist auch so eine Sache. IMHO macht es in den wenigsten Fällen Sinn zu versuchen das Programm fortzuführen. In den meisten Fällen würde der gleiche fehlerhafte Befehl nur gleich wieder ausgeführt werden, und dann gleich wieder krachen.
einfach in hades.inc der Variable startup_stk einen Speicherbereich zuordnen.
Ja, habe ich jetzt auch erstmal gemacht, damit es sich übersetzen lässt.
PS.:
Gabs eigentlich jemals ne 'offzielle' ROM-Version von Magic 6? Ich hab hier nur ein Tool gefunden das ein *.ram reloziert, scheint aber nur für ältere MagiX-Versionen zu funktionieren.
-
Ich habe 2 magic.ram-Dateien auf meinem Hades.
Im AUTO-Ordner befindet sich mhades.ram
Auf dem C-Drive-Root befindet sich magic.ram
Hier sind sie.
Edit: Auch magxboot.prg und magxbo32.prg aus dem AUTO-Ordner.
-
Danke für Dateien!
Im AUTO-Ordner befindet sich mhades.ram
Das ist ein verschlüsselte Version. Wahrscheinlich die 6.20. Kann/konnte man mal bei ASH downloaden.
Auf dem C-Drive-Root befindet sich magic.ram
Die passt. Thorsten wird es auch schon gesehen haben, die eigenartige Adresse ist dort auch drin.
Du kannst ja mal die Version testen, welche im anderen Thread im Archiv "mmilan.zip.pdf" drin ist.
-
Ja, danke, hatte auch schon festgestellt daß die eine Version verschlüsselt ist. Wäre auch seltsam, das Bootprogramm ist identisch zu der normalen Version, und das sucht nur nach magic.ram.
-
Ja, danke, hatte auch schon festgestellt daß die eine Version verschlüsselt ist. Wäre auch seltsam, das Bootprogramm ist identisch zu der normalen Version, und das sucht nur nach magic.ram.
Ah, mhades.ram ist nur ein Relikt. Es war schon da, als ich die Maschine kaufte.
-
Schon mal vorab ein paar sachen die mir in der Zwischenzeit aufgefallen sind:
- Das Bios-Datum der angehängten Datei ist vom 5.5.2001, die Sourcen hatten ursprünglich 11.09.2001. Ausser den unten genannten Sachen konnte ich aber keine Unterschiede feststellen.
- Die Version ist eine US-Version, und hat auch nicht das PAL-Flag im Header gesetzt. Das PAL-Flag wird (warum auch immer) in den veröffentlichten Sourcen immer gesetzt.
- Die Tastatur-Tabellen haben (im Gegensatz zu den Sourcen) auch Alt-Tabellen. Macht das überhaupt Sinn für eine US-Tastatur?
- Der _IDT Cookie wird entgegen des OS-Headers auf $112e wie bei der deutschen Version gesetzt. Kann es sein daß die Tastatur-Tabellen und der Header nachträglich gepatcht wurden?
- Einige Texte wie z.b. SYSTEM ÜBERSCHRIEBEN sind seltsamerweise trotzdem in deutsch
- Rogers MBSU Patch ist da offensichtlich drüber gelaufen (deaktiviert den Floppy-Test beim booten, und gaukelt dem System stattdessen 2 Floppies vor). In der übersetzten Version ist der jetzt nicht mehr drin, wenn man das möchte einfach nochmal drüber laufen lassen, funktioniert auch mit der neuen Version.
- Auch wenns keinen Sinn macht, verwendet er $5758 als Supervisor-Stack im Exception-Handler. Offensichtlich hat da jemand vergessen das anzupassen. $5758 ist für MagiC ungeeignet, weil es ausserhalb des vom System reservierten Bereichs liegt (oberhalb von _membot)
- Die XFS95 Routinen sind da seltsamerweise einkompiliert, werden aber scheinbar nicht angesprochen.
- Allgemein scheinen die Hades TOS Sourcen auf TOS 3.05 zu basieren. Ich hab jetzt noch nicht geprüft ob sich in den übernommenen Stellen bei 3.06 was geändert hat. Überhaupt scheint (vermutlich noch aus der Zeit von KAOS) ziemlich viel bei TOS "geklaut" zu sein.
-
So, nochmal aktualisierte Versionen für Hades und Milan. Die Hades-Version benutzt bei Exceptions jetzt den Stack der auch beim booten benutzt wird (ist eh nur relevant wenn Programme abstürzen). Beide Versionen sind komplette deutsch (inklusive Tastatur-Tabellen), wenn man andere braucht ist die einfachste Möglichkeit sie extern zu laden (siehe auch http://atari-forum.com/viewtopic.php?f=28&t=34608)
Ansonsten nicht viel geändert. Was ich noch gesehen habe, daß in der original-Hades-Version von TheNameOfTheGame offensichtlich ein Fehler in der Einbindung des FPSP060 war, die wohl dazu führen müsste daß der Versuch CAS/CAS2 zu emulieren fehlschlägt. Wer Lust hat kanns ja mal testen.
Im übrigen sind die Sourcen mit meinen Änderungen jetzt auch auf github (https://github.com/th-otto/MagicMac) verfügbar.
-
Danke Schön!
-
Ich habe die MAGIC.RAM auf meinem Milan 040 gegen diese Version (12.12.2018) ausgetauscht, der Rechner startet noch :-)
MagiC-Net läuft, Mailabruf mit MyMail und mit IN2CAT hat geklappt.
Dabei fällt mir noch eine Beschränkung von MagiC ein: Die Anzahl der möglichen Einträge in Laufwerk U: ist begrenzt. Kann der Wert erhöht oder dynamisiert werden? Im Moment muß ich einige Laufwerke aus U: löschen um Platz für die UNIX-artigen Wurzelverzeichnissse (BIN, ETC, HOME, OPT, USR und so weiter) zu schaffen.
Vielen Dank für die Weiterentwicklung meines Lieblings-Betriebssystems!
Mit freundlichen Grüßen
Ektus.
-
Dabei fällt mir noch eine Beschränkung von MagiC ein: Die Anzahl der möglichen Einträge in Laufwerk U: ist begrenzt. Kann der Wert erhöht oder dynamisiert werden?
Dynamisch natürlich schon möglich, nur ist mir der Aufwand zuhoch. Was vielleicht noch einfacher ging ist die Anzahl der Einträge in der magx.inf festzulegen.
Habe es mal probeweise von 64 auf 100 Einträge gesetzt.
-
Dynamisch dürfte nicht so einfach werden, wenn ich das richtig sehe ist die Speicherverwaltung zu dem Zeitpunkt noch nicht initialisiert. Den Wert zu erhöhen wie Karl es getan hat, oder auch aus der MAGX.INF zu lesen dürfte aber gehen.
Bist du in der Lage einfache Änderungen selber vorzunehmen, und dann den Kernel zu übersetzen? Nicht daß es sehr grosse Mühe machen würde, aber wenn wir hier nach jeder kleinen Änderung neue Versionen anhängen, führt das früher oder später sehr schnell zu Chaos.
-
Bist du in der Lage einfache Änderungen selber vorzunehmen, und dann den Kernel zu übersetzen? Nicht daß es sehr grosse Mühe machen würde, aber wenn wir hier nach jeder kleinen Änderung neue Versionen anhängen, führt das früher oder später sehr schnell zu Chaos.
Theoretisch schon, ein Pure-C müßte ich haben. Ich bräuchte aber eine komplette Entwicklungsumgebung, also MagiC-Sourcen, benötigte Bibliotheken und Konfigurationsdateien für Pure-C, am liebsten als Archiv zum einfach auspacken und loslegen. Oder gibt es Git für MagiC oder MiNT?
Jetzt am Wochenende und dann von Weinachten bis 07. Januar habe ich keinen Zugriff auf den Milan, nur den CT2A Falcon und den CT63 in Vollausstattung.
MfG
Ektus.
-
Es gibt Git für Mint: http://tho-otto.de/crossmint.php dort dann nach git-2.16 suchen. Die Binärpakete sollten funktionieren, hab sie aber nur kurz getestet. Könnte sein daß es Probleme mit SSL-Verbindungen gibt. Ob sie auch unter MagiC funktionieren kann ich nicht sagen, die sind halt mit der mintlib kompiliert. Vermutlich scheitert das an der fehlenden MintNET-Unterstützung in MagiC.
Ich habs bei mir so eingerichtet, daß ich die tools vom Host benutze, und die Sourcen in ein Verzeichnis auschecke an das ich vom Emulator aus dran komme.
Wenns mit git nicht klappt, einfach auf https://github.com/th-otto/MagicMac gehen, dort den Button "Clone or Download" anklicken, und dann als ZIP herunter laden. Nachteil ist halt daß du das beim nächsten mal wieder machen musst, wenn sich das Repo geändert hat.
Ein paar Dateien von Pure-C musst du dann noch in die Verzeichnisse kopieren (sollte in BUILDING.md erläutert sein), dann Projekt-Datei auswählen und loslegen.
-
Es gibt Git für Mint: http://tho-otto.de/crossmint.php dort dann nach git-2.16 suchen. Die Binärpakete sollten funktionieren, hab sie aber nur kurz getestet.
Auf meiner Firebee funzt git (in der ColdFire Version) problemlos.
-
Schon mal vorab ein paar sachen die mir in der Zwischenzeit aufgefallen sind:
- Das Bios-Datum der angehängten Datei ist vom 5.5.2001, die Sourcen hatten ursprünglich 11.09.2001. Ausser den unten genannten Sachen konnte ich aber keine Unterschiede feststellen.
- Die Version ist eine US-Version, und hat auch nicht das PAL-Flag im Header gesetzt. Das PAL-Flag wird (warum auch immer) in den veröffentlichten Sourcen immer gesetzt.
- Die Tastatur-Tabellen haben (im Gegensatz zu den Sourcen) auch Alt-Tabellen. Macht das überhaupt Sinn für eine US-Tastatur?
- Der _IDT Cookie wird entgegen des OS-Headers auf $112e wie bei der deutschen Version gesetzt. Kann es sein daß die Tastatur-Tabellen und der Header nachträglich gepatcht wurden?
Ja, ich habe die PAL-Flag und die Tastatur-Tabellen für US Version gepatcht, damit meine Tastatur funktioniert und 60Hz.
-
Es gibt Git für Mint: http://tho-otto.de/crossmint.php dort dann nach git-2.16 suchen. Die Binärpakete sollten funktionieren, hab sie aber nur kurz getestet.
Auf meiner Firebee funzt git (in der ColdFire Version) problemlos.
Bei mir läuft es noch nicht. Unter MiNT auf dem CT63 Rechner kommt bei git clone ein fatal: unable to access 'https://github.com/th-otto/MagicMac/': SSL certificate problem: unable to get local issuer certificateca-certificates habe ich schon geholt und in / ausgepackt, was fehlt noch?
MfG
Ektus.
-
Wenn ich mich recht erinnere, musste man da noch ein script laufen lassen, update-ca-certificates. Ich weiss nur gar nicht mehr genau wie ich das angestellt habe, weil es ein tool (trust) benutzt das zu einem anderen Paket gehört ;)
Ich meine, letztens endes habe ich dann ein anderes script genommen:
http://anduin.linuxfromscratch.org/BLFS/other/make-ca.sh-20170119
und
http://anduin.linuxfromscratch.org/BLFS/other/certdata.txt
Schätze ich muss das alte mal rausschmeissen ;)
-
Gerade noch was eingefallen: versuche mal in deinem HOME-Verzeichnis eine Datei .gitconfig anzulegen, und dort
[http]
sslVerify = true
einzutragen
-
Wenn ich mich recht erinnere, musste man da noch ein script laufen lassen, update-ca-certificates. Ich weiss nur gar nicht mehr genau wie ich das angestellt habe, weil es ein tool (trust) benutzt das zu einem anderen Paket gehört ;)
Stimmt, erst will es perl haben, und nachdem ich das installiert hatte scheitert es an trust.
Ich meine, letztens endes habe ich dann ein anderes script genommen:
http://anduin.linuxfromscratch.org/BLFS/other/make-ca.sh-20170119
und
http://anduin.linuxfromscratch.org/BLFS/other/certdata.txt
Schätze ich muss das alte mal rausschmeissen ;)
:)
das make-ca.sh schint jetzt zumindest zu laufen, braucht aber ganz schön lang. Einige Minuten ohne Ausgabe nach dem Start, dann 2 bis 3 Sekunden pro Zertifikat. Und das auf der CT63 mit 90MHz (oder so in dem dreh)...
Erst mal abwarten ;)
[edit]
Nach "install: creating directory '/etc/pki/anchors'" kam eine Fehlermeldung "rm: traversal failed: /tmp/tmp.BRvNMp2dET: Function not implemented"
Aber git clone läuft jetzt, ca. 160KiB/s. Und fertig :)
[/edit]
-
Aber git clone läuft jetzt, ca. 160KiB/s. Und fertig :)
Na also, das ist die Hauptsache.
P.S.: daß ich da ähnliches Geraffel machen mußte, um git ans Fliegen zu bekommen, wußte ich beim besten Willen nicht mehr - man wird alt ;)
-
P.S.: daß ich da ähnliches Geraffel machen mußte, um git ans Fliegen zu bekommen, wußte ich beim besten Willen nicht mehr - man wird alt ;)
:)
Die beiden Bibliotheken konnten gebaut werden, aber nach Auswahl des Projekts "ATARI.PRG" kommt eine Fehlermeldung "Error L:\MAGICMAC\KERNEL\BIOS\ATARI\MODULES\DSP.S 0: Label redefined: 1 Error(s)" und abbruch des Projekts mit Assembler error.
Ich hatte alle Dateien der obersten Ebene meines PureC-Verzeichnis in MAGICMAC\PC\ kopiert und dann pc.cfg gelöscht. Die bereits vorhandenen Libraries habe ich nicht überschrieben. Es sind keinerlei Compileroptionen gesetzt. Warning level ist 2.
Und nun? Kann mal einer seine funktionierende ps.cfg teilen?
MfG
Ektus.
-
nach Auswahl des Projekts "ATARI.PRG"
Ich hoffe du meinst atari.prj ;)
redefined: 1 Error(s)" und abbruch des Projekts mit Assembler error.
Welchen Assembler hast du, mas.ttp oder pasm.ttp? Ansonsten evtl. mal mit "Make all" probieren.
Kann mal einer seine funktionierende ps.cfg teilen?
Das wird nicht funktionieren, weil Pure-C da absolute Pfade drin speichert.
-
nach Auswahl des Projekts "ATARI.PRG"
Ich hoffe du meinst atari.prj ;)
Ja doch. Projekt. Blöder Vertipper...
redefined: 1 Error(s)" und abbruch des Projekts mit Assembler error.
Welchen Assembler hast du, mas.ttp oder pasm.ttp? Ansonsten evtl. mal mit "Make all" probieren.
Kann mal einer seine funktionierende ps.cfg teilen?
Das wird nicht funktionieren, weil Pure-C da absolute Pfade drin speichert.
Ich habe pasm.ttp mit 65860 Bytes vom 24.11.1992.
Ein gleichartiger Fehler mit "Label redefined" kommt bei den anderen Projekten auch, mit "XMENU" oder "ch_attenuation"
Außerdem sollte das PC.CFG heißen, und die absoluten Pfade würden nicht weiter stören, die kann man ändern. Wichtiger sind die ganzen Compilerflags. Okay, ein Screenshot des entsprechenden Dialogs täte es auch :-)
MfG
Ektus.
-
Ich habe pasm.ttp mit 65860 Bytes vom 24.11.1992.
Meine ist 66084 Bytes, vom 21.6.1993, also etwas neuer.
Wichtiger sind die ganzen Compilerflags. Okay, ein Screenshot des entsprechenden Dialogs täte es auch :-)
Normalerweise sollten die wichtigen Flags schon explizit in den Projekt-Dateien stehen, damit genau solche Dinge nicht passieren.
-
Okay, die Flags habe ich bei mir jetzt genauso gesetzt. Damit ließ sich wdialog compilieren (scheiterte vorher mit privileged instruction), aber die Kernel lassen sich immer noch nicht bauen, gleicher Fehler "Label redefined" wie vorher.
MfG
Ektus.
-
Ich habe noch einen anderen PASM gefunden mit 66084 Byte vom 14.04.1996 (aus Pure Pascal). Der meldet sich als PASM 68040 Assembler, Version Jun 21 1993. Bringt aber denselben Fehler.
Mit der PC.CFG aus der vorherigen Nachricht ändert sich auch nichts. Der einzige Pfad scheint der zum Projekt zu sein, die Einstellungen wurden übernommen.
-
Ein gleichartiger Fehler mit "Label redefined" kommt bei den anderen Projekten auch, mit "XMENU" oder "ch_attenuation"
Öffne die Datei bei der solche Fehler passieren mal mit QED. Dann schau mal mit dem Menüpunkt "Datei/Info..." nach welche Zeilenendung diese hat. Bei mir stand hier Apple, muss natürlich Atari sein. Also entsprechend Ändern und speichern.
Konkret war es hier die kernel/bios/atari/modules/dsp.s. Bei irgendeiner war mir das auch aufgefallen habe nur vergessen es mitzuteilen.
-
Ich habe noch einen anderen PASM gefunden mit 66084 Byte vom 14.04.1996 (aus Pure Pascal). Der meldet sich als PASM 68040 Assembler, Version Jun 21 1993. Bringt aber denselben Fehler.
Ja das müsste die gleiche Version sein. Datum der Datei kann sich schonmal ändern je nachdem wer das wann wo hochgeladen hat, aber beim starten meldet sich meiner mit dem gleichen Datum.
Dann schau mal mit dem Menüpunkt "Datei/Info..." nach welche Zeilenendung diese hat
Hm dachte die Sache mit den Zeilenenden wäre längst behoben. War sie aber scheinbar nicht. Git verhält sich da manchmal etwas eigensinnig.
find . -name "*.s" | xargs file | grep -v CRLF
zeigt bei mir im Arbeitsverzeichnis nichts an. Wenn ich aber ein leeres Verzeichnis anlege und es dort neu clone, werden diverse Dateien angezeigt, u.a. auch dsp.s . Muss man nicht verstehen. Hoffe mal ich konnte das jetzt beheben.
-
Dann schau mal mit dem Menüpunkt "Datei/Info..." nach welche Zeilenendung diese hat
Hm dachte die Sache mit den Zeilenenden wäre längst behoben. War sie aber scheinbar nicht. Git verhält sich da manchmal etwas eigensinnig.
find . -name "*.s" | xargs file | grep -v CRLF
zeigt bei mir im Arbeitsverzeichnis nichts an. Wenn ich aber ein leeres Verzeichnis anlege und es dort neu clone, werden diverse Dateien angezeigt, u.a. auch dsp.s . Muss man nicht verstehen. Hoffe mal ich konnte das jetzt beheben.
Scheint nicht so. Ich habe einen checkout gemacht. dsp.s hatte ich schon korrigiert, da meldet checkout jetzt M kernel/bios/atari/modules/dsp.s
Your branch is up to date with 'origin/master'.Bei neuem Checkout kommt die Meldung wieder, also stimmt da was nicht.
\kernel\aes\aesmen.s hatte bei mir noch unix-Zeilenenden, nachdem ich die mit QED auf Atari geändert habe, ließen sich alle Projekte in /kernel übersetzen. Git checkout meldet jetzt zwei Dateien mit vorangestelltem "M", aber tut nichts.
MfG
Ektus.
-
Bei neuem Checkout kommt die Meldung wieder, also stimmt da was nicht.
Welches Kommando genau meinst du? "git checkout" tut nicht das, was du vlt. von CVS gewöhnt bist: es verwirft deine Änderungen, und setzt die Datei auf die zuletzt eingecheckte Version zurück (aber nur, wenn du den entsprechenden Dateinamen angibst). Das musst du jetzt vermutlich auch erstmal machen, weil er sich sonst weigert deine lokalen Änderungen zu überschreiben, also
git checkout kernel/bios/atari/modules/dsp.s
(evtl mit weiteren Dateien die Du geändert hast; "git status" sagt dir welche geändert sind).
Was du danach brauchst, ist "git pull", um deine lokale Kopie auf den Stand von github zu bringen.
-
Bei neuem Checkout kommt die Meldung wieder, also stimmt da was nicht.
Welches Kommando genau meinst du? "git checkout" tut nicht das, was du vlt. von CVS gewöhnt bist: es verwirft deine Änderungen, und setzt die Datei auf die zuletzt eingecheckte Version zurück (aber nur, wenn du den entsprechenden Dateinamen angibst). Das musst du jetzt vermutlich auch erstmal machen, weil er sich sonst weigert deine lokalen Änderungen zu überschreiben, also
git checkout kernel/bios/atari/modules/dsp.s
(evtl mit weiteren Dateien die Du geändert hast; "git status" sagt dir welche geändert sind).
Was du danach brauchst, ist "git pull", um deine lokale Kopie auf den Stand von github zu bringen.
git checkout ohne weitere Parameter meldet die beiden Dateien aesmen.s und dsp.s.
git pull meckert, daß die beiden Dateien von merge überschrieben würden und verweigert den Dienst mit "Please commit your changes or stash them before you merge". Es wird genau gar nichts aktualisiert.
Ist das ein Krampf :(
Einzeln ausgecheckt kommt keine Meldung von checkout, und git pull meldet danach 33 geänderte Dateien mit 22113 insertions und 22112 deletions.
Gibt es da kein "force" oder meinetwegen interactive beim pull? So in der Art "Deine Datei ist geändert. Behalten, überschreiben oder zusammenführen?"
Kopfschüttelnd
Ektus.
-
Wenn du Kleinigkeiten an den Dateien geändert hättest, hättest du die einchecken können (mit "git add" und "git commit"), und dann erst pullen. Dann wäre beim pullen ein Merge-Commit erzeugt worden, und wenns da Konflikte gibt (weil die gleichen Stellen sowohl bei dir als auch im repo geändert wurden), kannst du die dann anschliessend beheben. Hätte nur in dem Fall nicht besonders gut funktioniert: dadurch daß sich die Zeilenenden geändert haben, ist aus Git Sicht praktisch die gesamte Datei geändert. Deswegen auch die 22000 deletions/insertions.