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

0 Mitglieder und 1 Gast betrachten dieses Thema.

Offline tuxie

  • Benutzer
  • Beiträge: 6.835
  • Falcon! Milan! Schuetzt die Raubvoegel!
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #80 am: Mo 03.12.2018, 14:24:12 »
Weiß nicht ob man die Themen eventuell einmal aufteilen sollte. Aber ich schreibe es jetzt erstmal hier rein.

Unser Thunder IDE Interface besitzt ja die SmartSwap Features was im Grunde nichts anderes macht als die reinen Daten Bytes zu swappen. HDDriver kommt damit klar und da man dort das Software Swappen ausschalten kann und nur Dos Kompatibel erstellen kann.

Wenn man jetzt Magic auf einen dieser Medien installiert dann startet der Kernel und nach dem Reset bleibt er hängen. Meine Vermutung ist das der Kernel quasi prüft um was für eine Partition es sich handelt. Jetzt ist es ja so das bei DOS Partitionen der Typ im hex Format abgelegt ist und bei TOS kompatiblen Partitionen eben BGM, GEM, F32 usw. drin steht. Jetzt wird hier natürlich die Erkennung schief laufen
Tschau Ingo

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #81 am: Mo 03.12.2018, 15:40:09 »
^^-- Antwort im neuen Thread "SmartBoot für MAGX" .
« Letzte Änderung: Mo 03.12.2018, 15:50:17 von ari.tao »
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline TheNameOfTheGame

  • Benutzer
  • Beiträge: 90
  • Almost Heaven, West Virginia
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #82 am: Mo 03.12.2018, 16:13:55 »
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?

Andreas könnte es haben?

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 1.315
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #83 am: Mo 03.12.2018, 16:37:52 »
Unser Thunder IDE Interface besitzt ja die SmartSwap Features was im Grunde nichts anderes macht als die reinen Daten Bytes zu swappen.

Wenn ich das richtig verstanden habe swapped das (im Gegensatz zu einem Twisted Cable) nur die Daten, aber nicht die Kommandos. Aber wann genau swapped er die Daten, erkennt er selbständig irgendwie ob das Medium an einem PC oder Falcon eingerichtet wurde? Wenn das quasi automatisch erfolgt, dürfte das für MagiC eigentlich keinen Unterschied bedeuten. In jedem Fall ist ein ByteSwap aber nur Sache des Treibers (ausser vlt. beim lesen des Rootsectors, da müsste ich mal schauen).

Zitat
Meine Vermutung ist das der Kernel quasi prüft um was für eine Partition es sich handelt. Jetzt ist es ja so das bei DOS Partitionen der Typ im hex Format abgelegt ist und bei TOS kompatiblen Partitionen eben BGM, GEM, F32 usw. drin steht. Jetzt wird hier natürlich die Erkennung schief laufen

Nicht direkt. Die Partitionskennung wird zunächst mal  nur vom Treiber geprüft. Magic versucht dann Getbpb() aufzurufen, wenn das fehlschägt wird die XHDI-Funktion XHInqDev2 aufgerufen. Dort wird dann geprüft, ob "F32" im Partition-Typ steht. Ansonsten werden diverse Daten im Bootsector auf Gültigkeit geprüft. Für andere Partitionen als FAT32 wird da aber nix weiter geprüft.

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 1.315
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #84 am: Mo 03.12.2018, 16:39:53 »
Andreas könnte es haben?

Möglich, aber dann hätte er es vermutlich dabei gepackt ^^ Anfrage ist aber natürlich schon unterwegs.

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 1.315
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #85 am: Mo 03.12.2018, 17:53:30 »
Und noch ein Update zum "Zählfehler": das ganze war eine Kombination von (mindestens) zwei Fehlern. Zum einen ein Fehler in einer 32*32->64 Multiplikation, die nur MagxDesk betraf. Der ist jetzt behoben, und beide Desktops zeigen jetzt die gleichen (unsinnigen) Werte an. Eigentlich recht harmlos, wenn auch unschön.

Der zweite dagegen ist nicht so harmlos: wie in dem anderen Thread beschrieben,  gibt es bei FAT32 einen Info-Sector, wo u.a. die Anzahl der freien Cluster und der nächste zu verwendende Cluster steht, damit man nicht jedesmal die ganze FAT abklappern muss (die bei FAT32 recht gross werden kann, zig MB sind da nicht selten). AK hat nur leider vergessen, daß diese Informationen alle im Intel-Format vorliegen. Dementsprechend liest/schreibt MagiC diese Werte im 68k-Format, auch werden dort keine Überprüfungen auf Gültigkeit gemacht. Resultat: wenn die Werte (korrekterweise) im Intel-Format vorliegen (z.B. weil die Partition von Mint beschrieben wurde), wird mit völlig sinnlosen Cluster-Nummer gearbeitet, die möglicherweise sogar ausserhalb der Partitions-Grenzen liegen. Wenn man Glück hat, fängt der HD-Treiber das ab, wenn man Pech hat macht der das nicht, oder die Werte liegen zwar ausserhalb der FAT, aber noch innerhalb der Partition, und die Daten werden dann irgendwo hingeschrieben, nur nicht da wo sie hingehören.

Heisst aber auch im Umkehrschluss: solange man *ausschliesslich* mit Magic auf FAT32 zugreift, dürfte nix gravierendes passieren (ausser da sind noch andere Bugs, natürlich). Kann das nochmal jemand bestätigen? Ich hab es im moment nur mit einer relativ kleinen Partition getestet.


Offline KarlMüller

  • Benutzer
  • Beiträge: 420
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #86 am: Mo 03.12.2018, 18:09:39 »
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?

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 1.315
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #87 am: Mo 03.12.2018, 19:18:58 »
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?

Offline KarlMüller

  • Benutzer
  • Beiträge: 420
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #88 am: Mo 03.12.2018, 20:01:25 »
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.

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 1.315
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #89 am: Mo 03.12.2018, 20:31:01 »
Doch hat er. Liegt ganz normal an den Adressen wie beim ST/TT.

Ah ok. Irritiert war ich, weil "gpip" schon definiert war als die Addresse für den ST-MFP. 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. Ansonsten lassen sich die Sourcen jetzt zumindest übersetzen. Ob sie auch funktionieren: kA ;)

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #90 am: Mo 03.12.2018, 20:38:19 »
Zu deiner RSC-Datei: statt sie in applicat.rsc einzubauen, hab ich sie jetzt in den RSC Ordner von magxdesk gepackt. Dann muss man sie nicht in 3 verschiedene sprach-abhängige Resourcen einbauen, und jeder kann sich selber aussuchen welche Icons er benutzen will. Ich hoffe das ist ok.
Nein, das ist nicht ok.
Ich verstehe gar nicht, was Du da wohin gepackt hast. In den Ordner GEMDESK\RSC\ gehören afaik nur Icon-Resourcen. Solche habe ich aber oben gar nicht angehängt. Falls Du die in APPLICAT.RSC eingebauten Icons herausgenommen und in eine extra Icon-Datei gepackt hast, so ist das auch nicht ok, denn dann hättest Du schlicht nicht verstanden, warum diese Icons just da sind, wo sie sind, nämlich in APPLICAT.RSC. Es ist allerdings etwas seltsam, wie MAGX bzw. sein APPLICAT seine Icons überall zusammensucht.
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #91 am: Di 04.12.2018, 02:16:13 »
Das jüngste APPLICAT (aus #76) steigt haargenau an der gleichen Stelle aus, ohne weitere Meldung. Ich habe mal meinen ErrorProzessor in´s System gehängt. Er berichtet folgenden last sigh:

 Post Mortem Global Error Context:

 Exception  2, is: Bus missing hardware

 D0 = 00000001     A0 = 0400F2A8
 D1 = 03FDD06A     A1 = 00000000
 D2 = 0400DC3C     A2 = 0401124C
 D3 = FFFF0003     A3 = 00000000
 D4 = 00000000     A4 = 03FDCB8C
 D5 = 00000000     A5 = 0401124E
 D6 = 00000000     A6 = 03FD9E8C
 D7 = 00000000     A7 = 012B26BA (= SSP)
 EID = 02FFFFFF   USP = 04011236

 SavedSuperStack:
 0300 03FD C602 B008 16EE 0729 3290 4E75 0000 0000 0401 123A 0000 00AC 226F
 ^-ps ^-AcAdr-^ ^-Op ^-SR----^ ^-PC----^

 PC = 32904E75, PC^[-9..+5]:  ----
 No valid M2 Error Dump
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #92 am: Di 04.12.2018, 04:19:58 »
Und noch ein Update zum "Zählfehler": das ganze war eine Kombination von (mindestens) zwei Fehlern. Zum einen ein Fehler in einer 32*32->64 Multiplikation, die nur MagxDesk betraf. Der ist jetzt behoben, und beide Desktops zeigen jetzt die gleichen (unsinnigen) Werte an. Eigentlich recht harmlos, wenn auch unschön.
Das bestätigt ja, was ich in #69 schrieb. Aber daß auch der Zählfehler für sich allein schon nicht harmlos ist, das hatte ich schon in "MAGX´ Macken" nachgewiesen. Wie auch immer: Sehr erfreulich, daß Du den jetzt beheben kannst und auch gleich noch die Ursache für das ebenfalls in "MAGX´ Macken" diskutierte FAT32-Problem gefunden hast! Danke!
Der zweite dagegen ist nicht so harmlos: wie in dem anderen Thread beschrieben,  gibt es bei FAT32 einen Info-Sector, wo u.a. die Anzahl der freien Cluster und der nächste zu verwendende Cluster steht, damit man nicht jedesmal die ganze FAT abklappern muss (die bei FAT32 recht gross werden kann, zig MB sind da nicht selten). AK hat nur leider vergessen, daß diese Informationen alle im Intel-Format vorliegen. Dementsprechend liest/schreibt MagiC diese Werte im 68k-Format, auch werden dort keine Überprüfungen auf Gültigkeit gemacht. Resultat: wenn die Werte (korrekterweise) im Intel-Format vorliegen (z.B. weil die Partition von Mint beschrieben wurde), wird mit völlig sinnlosen Cluster-Nummer gearbeitet, die möglicherweise sogar ausserhalb der Partitions-Grenzen liegen.
Das klingt für mich jetzt so, als ob eigtl. MAGX das richtig macht (da wir ja auf 68k-Maschinen arbeiten) und MiNT da schief liegt - aber bevor hier wieder der übliche Aufschrei kommt, MiNT habe immer Recht: Es ist letztlich egal, bloß muß dafür gesorgt werden, daß beide gleich vorgehen!!
Heisst aber auch im Umkehrschluss: solange man *ausschliesslich* mit Magic auf FAT32 zugreift, dürfte nix gravierendes passieren (ausser da sind noch andere Bugs, natürlich). Kann das nochmal jemand bestätigen? Ich hab es im moment nur mit einer relativ kleinen Partition getestet.
Das kann, wie schon dargelegt, imho nur mit einer Version getestet werden, in der der Zählfehler schon beseitigt ist (also mit Deiner).

Edit.: Da es ja nicht bloß darum geht, sowohl mit MAGX als auch mit MiNT auf die gleichen FAT32-Parts. problemlos zugreifen zu können, sondern auch die Austauschbarkeit mit gewöhnlichen (also für Windows eingerichteten) Medien zu berücksichtigen ist, plädiere ich natürlich in diesem Fall für das Intel-Format, also für die Anpassung von MAGX. Warum also noch etwas testen, was eh angepaßt werden muß...
« Letzte Änderung: Di 04.12.2018, 05:30:09 von ari.tao »
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #93 am: Di 04.12.2018, 04:59:31 »
... Der Exception-Vector dafür war aber an der Stelle noch gar nicht gesetzt, zeigte also immer noch auf die Routine die vom ROM installiert wurde... Schlimmer noch waren stattdessen sämtliche System-Variablen schon  gelöscht, sodaß diese Routine, und evtl auftretende MFP interrupts, dann irgendwann ins Nirwana sprangen.
Den MAGX-typischen ReBoot/DoppelBoot hast Du doch aber berücksichtigt?
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 1.315
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #94 am: Di 04.12.2018, 06:11:38 »
Nein, das ist nicht ok.

Na gut, dann nehm ich es halt wieder raus,

Zitat
Ich verstehe gar nicht, was Du da wohin gepackt hast. In den Ordner GEMDESK\RSC\ gehören afaik nur Icon-Resourcen.

Ja, das ist mir auch klar. Wenn da was anderes als ICONS drin ist, wird die auch gar nicht genommen.

Zitat
Falls Du die in APPLICAT.RSC eingebauten Icons herausgenommen und in eine extra Icon-Datei gepackt hast

Exakt.

Zitat
so ist das auch nicht ok, denn dann hättest Du schlicht nicht verstanden, warum diese Icons just da sind, wo sie sind, nämlich in APPLICAT.RSC.

Und ich habe dir oben erklärt, warum man die so nicht in APPLICAT.RSC einbauen kann.

Zitat
Es ist allerdings etwas seltsam, wie MAGX bzw. sein APPLICAT seine Icons überall zusammensucht.

Finde ich gar nicht mal so verkehrt. Bei vielen Icons kann man die halbwegs sinnvoill auf mehrere RSC-Datein verteilen und behält so vlt. einen besseren Überblick. Z.b ein Datei mit Laufwerks-Symbolen, eine mit Programm-Icons etc.

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 1.315
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #95 am: Di 04.12.2018, 07:15:15 »
Das jüngste APPLICAT (aus #76) steigt haargenau an der gleichen Stelle aus, ohne weitere Meldung.

Hm seltsam, auch kein Error -69 mehr?

Zitat
Post Mortem Global Error Context:

Auch seltsam. Sieht so aus als ob da jemand versucht an eine ROM-Addresse zu schreiben ($FDC602) In welcher Konfiguration testet du das?

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 1.315
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #96 am: Di 04.12.2018, 07:29:15 »
Aber daß auch der Zählfehler für sich allein schon nicht harmlos ist, das hatte ich schon in "MAGX´
Macken" nachgewiesen.

Bitte les nochmal was ich geschrieben habe. Es wurde dort lediglich ein falscher Wert berechnet und angezeigt. Das ist schon eher harmlos und kann auch nicht zu Datenverlusten führen.

Zitat
Das klingt für mich jetzt so, als ob eigtl. MAGX das richtig macht (da wir ja auf 68k-Maschinen arbeiten) und MiNT da schief liegt

Nein, sicher nicht, Die Werte dort liegen alle im Intel-Format vor, egal auf welcher Maschine. Wird ja auch an anderen Stellen richtig gemacht, nur halt bei diesen zwei Werten nicht.

Zitat
Das kann, wie schon dargelegt, imho nur mit einer Version getestet werden, in der der Zählfehler schon beseitigt ist (also mit Deiner).

Das könnte man auch jetzt schon testen (natürlich nur mit einer Partition die man entbehren kann, falls da irgendwas fatales passiert). Muss aber nicht sein, ist auch ziemlich zeitaufwendig. Das zu fixen dauert auch noch ein bisschen, würde das schon ganz gerne relativ ausgiebig testen bevor da jemand seine Partionen zerschiesst ;)

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #97 am: Di 04.12.2018, 12:18:44 »
Das jüngste APPLICAT (aus #76) steigt haargenau an der gleichen Stelle aus, ohne weitere Meldung.
Hm seltsam, auch kein Error -69 mehr?
Mit ´haargenau´ war gemeint: Total gleich wie in obigem ScreenSnap, auch #-69 !
Zitat
Post Mortem Global Error Context:
Auch seltsam. Sieht so aus als ob da jemand versucht an eine ROM-Addresse zu schreiben ($FDC602)
Ja klar, Dein APPLICAT. Sieht für mich so aus, als ob ein Subroutine-Sprung mißglückt (oder die Rückkehr daraus). Auf dem SuperStack liegt offenbar ein Stück Code genau da, wo eigtl. der ProgramCounter liegen sollte. Eine ROM-Adr.? So hoch? Kann wohl kaum sein. Was liegt denn da.
In welcher Konfiguration testet du das?
Völlig unverändert. Funzt absolut reibungslos mit dem Original seit Jahren.  Lediglich das neue Applicat eingewechselt (samt .RSC).

Edit.:
Habe den Test gerade noch mal wiederholt, aber auf dem Falcon anstatt dem TT: Gleiches Bild, bloß der last sigh ist leicht verändert:

 Post Mortem Global Error Context:

 Exception  2, is: Bus missing hardware

 D0 = 00000001     A0 = 00539F8C
 D1 = 00507D4E     A1 = 00000000
 D2 = 00538920     A2 = 0053BF30
 D3 = FFFF0003     A3 = 00000000
 D4 = 00000000     A4 = 00507870
 D5 = 00000000     A5 = 0053BF32
 D6 = 00000000     A6 = 00504B70
 D7 = 00000000     A7 = 001F939E (= SSP)
 EID = 02FFFFFF   USP = 0053BF1A

 SavedSuperStack:
 0300 0050 72E6 B008 360E 0329 3290 2252 0000 0000 0053 BF1E 0000 0049 226F
 ^-ps ^-AcAdr-^ ^-Op ^-SR----^ ^-PC----^

 PC = 00000000, PC^[-9..+5]:  ----
 No valid M2 Error Dump
« Letzte Änderung: Di 04.12.2018, 12:45:19 von ari.tao »
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 1.315
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #98 am: Di 04.12.2018, 13:14:59 »
Mit ´haargenau´ war gemeint: Total gleich wie in obigem ScreenSnap, auch #-69 !

Ok, hatte ich wohl missverstanden. Würde auch keinen Sinn machen, weil dann die Daten im Post-Mortem-Dump gar nicht gültig wären.

Zitat
Ja klar, Dein APPLICAT.

Naja direkt eher nicht. Vermutlich indirekt, weil vorher irgendwo der Stack zerschossen wurde.

Zitat
Eine ROM-Adr.? So hoch? Kann wohl kaum sein.

ROM bei ST geht von FC0000 -FF0000, wieso kann das nicht sein?

Zitat
Was liegt denn da.

kA. Wenn du mal meine Frage beantworten würdest, könnte ich das vlt. sogar sagen. Ist aber eigentlich unerheblich, interessanter wäre zu wissen wie er da hin kommt.

Zitat
Völlig unverändert.

Echt extrem hilfreich. Welche Maschine? Welches TOS im ROM? Welche MagiC Version? Wieviel Speicher? Was läuft da evtl. noch an residenten Programmen?

Zitat
0300 0050 72E6 B008 360E 0329 3290 2252 0000 0000 0053 BF1E 0000 0049 226F
 ^-ps ^-AcAdr-^ ^-Op ^-SR----^ ^-PC----^

kA was du da für ein Tool benutzt, aber die Angaben sind irgendwie unsinnig. Der Stackframe für Bus-Error sieht beim 68030 erheblich anders aus als beim 68000.

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 1.315
Re: Quellen von Magic, Magxdesk, u.a. auf gitlab ...
« Antwort #99 am: Di 04.12.2018, 13:27:37 »
Ok, nochmal genauer nachgeschaut. Hab mich da irgendwie von den Ausgaben des Tools verwirren lassen. Ausgehend davon daß beide Tests auf einem 68030 liefen (TT/Falcon), ist das einfach ein NULL-Pointer-Zugriff:


0300 0050 72E6 B008 360E 0329 3290 2252 0000 0000
               ^                        ^- Zugriff auf Addresse 0
               + Format 11 frame, Bus-Error


Hilft mir nur irgendwie auch nicht direkt weiter...