68K30L, Falcon und Suska-III-T2

[guest2205]

So der Vorzeichenbug wurde von Wolfgang gefixt aber jetzt wird es richtig kompliziert! Ich sage nur Interrupt! Der Validator hat jetzt einen Fall gefunden der im Amiga auch praxisrelevant ist. Wird beim Atari ST bestimmt auch so sein.
Über IPL wird ein Interrupt ausgelöst. Genau in dem Augenblick in dem die Interruptstatemaschine gestartet wird, wird der Interrupt an den IPL-Eingängen gelöscht - genau nach dem letzten Zyklus des Befehls vor dem Interrupt. Der IPL-Status im Auslösemoment des Interrupts wird nicht gespeichert und somit wird der Interruptvector von $000060 und nicht von der zum Interrupt passenden Adresse geholt. => Absturz!!!

Viele Grüße
TobiFlex

[guest2205]

So es geht fleißig weiter:
Opcode: 0x486f  PEA
Der auf den Stack geschriebene Wert ist genau um 2 zu klein.

Opcode: 0xc5c1 MULS D1,D2 ist erstmal nur suspekt. Kann die Validatordiagramme noch nicht richtig deuten. Es scheint fast so als würde eine Interruptanmeldung über IPL die Multiplikation aus dem Tritt bringen. Bitte Simulieren!

Viele Grüße
TobiFlex

[wfoerster]

Ok,
ich habe Punkt für Punkt durchgesehen.
Interrupts:
genau in dem Moment, in dem ein Intterrupt in Verarbeitung geht wird er in EXCEPTION_Q gespeichert. Das passiert im Prozess STORE_CURRENT_EXCEPTION. Ich habe beim Entwurf des Interrupt-Handlers auf diesen Punkt geachtet. Vielleicht ist er aber noch nicht ganz korrekt umgesetzt. In emutos und in TOS1.00, welche beide die Interrupts intensiv verwenden, funktioniert alles prima. Ich hatte seinerzeit Fehler drin, was sich in einer springenden Maus, in nicht restaurierten Menüs, in Abstürzen usw. wiederspiegelte. Das passiert aber mit der aktuellen Version unter emutos und TOS1.00 nicht mehr. Daher weiss ich nicht genau, ob der Absturz nicht eine Folge eines anderen Fehlers ist. Vielleicht kannst Du, Tobias, sagen ob so etwas möglich wäre. Also kurz zusammengefasst, Sobald ein Interrupt ausgelöst wird und in Verarbeitung geht, wird der Interrupt Vektor quellen-konsistent verwendet.

Zu den Spezialfällen:
ich habe mittlerweile zu den folgenden Fällen die gleiche Meinung wie Tobias. Diese Spezialfälle waren bisher nicht korrekt, sind aber nun richtiggestellt:
ADDA -(Ax), Ax: es wird zum undekrementierten Wert also Ax addiert.
CMPA -(Ax), Ax: es wird mit dem undekrementierten Wert von Ax verglichen.
SUBA -(Ax), Ax:  es wird vom undekrementierten Wert also Ax subtrahiert.
MOVE Ax, -(Ax): es wird der undekrementierte Wert, also Ax nach Ax-2 geschrieben.

Opcode: 0xc5c1 MULS D1,D2:
die Multiplikation dauert lange. Daher wird in dem Systemzustandsautomat im Zustand WAIT_OPERATION auf das Ergebnis gewartet und dann nach FETCH_BIW_1 verzweigt. Erst in FETCH_BIW_1 werden Interrupts, registriert. Die Interrupt-Zustandssteuerung wartet also bis nach FETCH_BIW_1 und dann nach IDLE verzweigt wird. Das steuernde Signal ist CTRL_RDY. Ich kann mir daher nicht vorstellen, dass da was schief geht. Ich würde vorschlagen das mit PEA erst zu richten und dann nochmal zu sehen, ob's nicht weitergeht.

PEA:
das ist vermutlich falsch. Ich werde es richten und Tobias ein Update schicken.

Spezialfälle:
ich habe vor ein Dokument zu verfassen, in dem alle Spezialfälle wie beispielsweise oben beschrieben zusammengestellt sind. Es gibt, wie ich gesehen habe, nicht nur bei uns Diskussionen über diese Dinge. Der Prozessor hat meiner Meinung nach etwa 10 bis 20 von diesen. Ferner ist das Prefetch-Verhalten des Prozessors ein Thema, um auch self-modifying Code lauffähig zu bekommen. Auch hier müsste man eventuell etwas machen.

Viele Grüße

Wolfgang

[guest2205]

Opcode: 0xc5c1 MULS D1,D2:

Scheint in Ordnung zu sein - sah bloß komisch aus weil nach der langen Multiplikation gleich noch der Amigachipsatz auf den Bus zugriff.

PEA:

Das ist aus meiner Sicht auch im Augenblick der entscheidene Bug.

Interrupts:

Da läuft im Augenblick auf jeden Fall nochwas schief. Manchmal wird der Vector auch von $0000300 geholt.
Aber richte erstmal PEA.

Viele Grüße
TobiFlex

[wfoerster]

Ich habe PEA untersucht und kann nichts entdecken. Es ist nun aber gemäß OPCODE 0x486f so, dass der Stack an der Operation beteiligt ist. Also könnte auch der Stack aus irgendeinem Grund verrutscht sein. Ich habe noch einen Bug in der CHK Operation gefunden (ich habe die auch immer LONG behandelt). Vielleicht hilft das weiter. Ich schicke demnächst ein Update durch. Falls es Deiner Meinung nach CHK nicht sein kann (weil zum Beispiel gar nicht verwendet), müsste ich noch etwas aus der Vorgeschichte zu PEA wissen. Ein Hexdump wäre geschickt, ein Disassembly perfekt.
Kannst Du den Stack sehen? Das würde natürlich auch weiterhelfen.

Viele Grüße

Wolfgang

[guest2205]

Noch einfacher zeigt sich der PEA-Bug mit OPCODE 0X4857 PEA (A7). Wenn A7=0X00001000 ist muß 0X00001000 nach 0X00000FFC geschrieben werden. Es wird aber 0X00000FFE nach 0X00000FFC geschrieben.
Also ist PEA nur falsch wenn der Stack mit in die Berechnung einfließt.

Viele Grüße
TobiFlex

[wfoerster]

Hallo Tobias,
alles wieder im Lot. Ich habe den PEA gefixt. Das mit dem CHK geht noch nicht. Es gibt aber ein erfreuliches Ergebnis. Mit dem berichtigen PEA bootet TOS 1.62 nun bis zum Desktop und es sieht auch grau aus, wie es sein soll. Die Menüs können bedient werden und es stürzt auch nicht mehr ab. Einzig die Schrift der Menüeinträge ist nach wie vor falsch und nicht zu erkennen. Ich bleibe an dem CHK dran. Wenn ich den CHK einhänge, dann bekomme ich beim Booten zwei Bomben. Vielleicht ein Folgefehler. Wenn Du den CHK ausprobieren möchtest: ich habe den falschen CHK in der ALU eingerückt und aktiviert, so dass er läuft wie bisher. Die berichtigten Zeilen sind ebenfalls in der ALU eingerückt aber auskommentiert...

Viele Grüße

Wolfgang

[guest2205]

Bugreport WF68K00:
MOVEM (An)+,Reglist macht Murks. Wenn n=7 ist - sprich der SP benutzt wird ist alles OK. Aber wenn n=0 ist wirds falsch. Und ich nehme an bei n=1-6 wirds auch nicht besser. Beispielcode:
move.l #$200,A0
movem.l (A0)+,d0

A0 müßte jetzt den Wert $204 haben. Aber auf wundersame Weise steht jetzt $20C in A0.
Mit movem.w sind es nur 4 zuviel.

DIVS:
move.l #$1000000,d3
divs #$200,d3

D3 wird $8000 - also negativ. Die positiven Werte gehen aber blos von $0000 bis $7FFF. Es tritt also ein Overflow auf, der nicht erkannt wird. Wenn dagegen nur der Divisor oder der Divident negativ ist würde das Ergebnis im Wertebereich liegen und keinen Overflow auslösen da das Ergebnis negativ ist.
Viele Grüße
TobiFlex
 

[wfoerster]

Hallo Tobias,
kannst Du mir bitte mitteilen, ob die Version von gestern gar nicht geht oder der DIVS jetzt komplett daneben liegt oder hast Du die letzten Bugs mit dieser Version herausgefunden?


Viele Grüße

Wolfgang

[guest2205]

Die letze version ging garnicht. Die Bugs hab ich mit der vorletzen Version gefunden.
Viele Grüße
TobiFlex

[guest2205]

Bugreport WF68K00:
Opcode 4CDF FEFE movem.l (a7)+,D1-D7/A1-A7
liest nur 13 Werte vom Stack - es müssen aber 14 Werte gelesen werden.
Viele Grüße
TobiFlex

[guest2205]

Bugreport WF68K00:
Opcode d201 ADD.B D1,D1
Zeroflag fehlerhaft. Bei ADD.W D1,D1 sicher auch.
Es ist der gleiche Effekt wie beim Vorzeichen.
Bei 0X80+0X80 wird das Zeroflag nicht gesetzt.
Viele Grüße
TobiFlex

[wfoerster]

Hallo Tobias,
movem.l (a7)+,D1-D7/A1-A7 ist ein Sonderfall. Gemäß Programmer's Manual von Motorola wird der Stack A7 im Postincrement Adressmodus nicht mit dem vom Bus gelesenen Wert überschrieben. Daher habe ich diesen Buszyklus unterdrückt, da er sinnlos ist. Auszug aus der Originaldoku (s. letzter Satz).

If the effective address is specified by the postincrement mode, only a memory-to-reg-
ister operation is allowed. The registers are loaded starting at the specified address;
the address is incremented by the operand length (2 or 4) following each transfer. The
order of loading is the same as that of control mode addressing. When the instruction
has completed, the incremented address register contains the address of the last oper-
and loaded plus the operand length. If the addressing register is also loaded from
memory, the memory value is ignored and the register is written with the postincre-
mented effective address.


Bis später

Wolfgang

[wfoerster]

Hi Tobias,
ADD.B Dx,Dy ist gefixt.
ADD.W Dx,Dy ist gefixt.

Danke!
Update schicke ich später.

Bis dann

Wolfgang

[wfoerster]

Hallo zusammen,
Tobias hat ein wunderbares Händchen in Bugs finden. Ich leider nicht so in Bugs beseitigen. Momentan habe ich meine CPU vermurxt. Kann also etwas dauern, bis es hier weitergeht. An dieser Stelle möchte ich nochmal die hervorragende Arbeit von Tobias herausstellen. Ohne ihn wäre es mir kaum Möglich, das Projekt in dieser Intensität voranzutreiben.

Bis dann

Wolfgang

[tuxie]

Also ich muß sagen ihr seit alle Spitze die daran Arbeiten. Man sieht ja es geht mit großen Schritten vorran.

[guest2205]

Hallo Wolfgang,
also mit der Version vom 26.08. hast du mir eine echte Nuss geschickt, die ich nicht knacken kann. Der Validator stoppt und zeigt Fehler an aber ich komme nicht dahinter wodurch sie ausgelöst werden.
Die Indizien sprechen dafür, daß es was mit DIVU zu tuen hat. Kann es sein, daß ein DIVU das nächste auftretende DIVU beeinflusst - also daß irgendwas vor oder nach einer Division nicht resetet wird?
Viele Grüße
TobiFlex

[wfoerster]

Hallo Tobias,
ich bin jetzt glaube ich wieder auf der Spur. Es handelte sich bei DIVS und DIVU um einen zweifachen Laufzeitfehler. Das war nicht trivial und ich musste in einigen Modulen Änderungen vornehmen. Ich mache, um sicherzugehen, noch einige Tests. Wenn alles klappt, dann schicke ich Dir heute Nacht noch ein Update. Momentan habe ich mein TOS1.62 Desktop wieder und die Simulation hat auch gut funktioniert. Ich hatte nur noch eine Kleinigkeit übersehen und teste daher jetzt nochmals ausführlich. Ich hoffe, dass Dein Validator jetzt wieder was finden kann. Bei mir fehlt jetzt immer noch die Schrift in den Menüs.

Viele Grüße

Wolfgang

[guest2205]

Hallo Wolfgang,
leider bin ich erst heute zum Testen gekommen. In der Tat laufen jetzt ein paar Demos mit weniger Fehlern. Glückwunsch. Der Validator stopt jetzt immer bei dem schon beschriebenen Interruptbug. Kümmere dich mal bitte auch darum.
Viele Grüße
TobiFlex

[guest2205]

Bugreport WF68K00:
Opcode 4CB3 0007 0000 MOVEM.W (00,A3,D0),D0-D2
Der erste Wert wird von der richtigen Adresse gelesen. Die folgenden Leseadressen passen nicht mehr. Vermutlich weil sich D0 verändert hat.

Hab grad noch
Opcode 4CB3 0007 1000 MOVEM.W (00,A3,D1),D0-D2
ausprobiert und da sind die ersten beiden Adressen richtig. D1 wird ja etwas später als D0 verändert.
Viele Grüße
TobiFlex