From mint-bounce@lists.fishpool.fi Mon Aug 1 20:52:20 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: Re: [MiNT] Atari 030 patch for mmu030.S in current CVS From: Alan Hourihane To: "Konrad M. Kokoszkiewicz" Cc: MiNT In-Reply-To: <20050801192454.G3492@antyk.obta.uw.edu.pl> References: <1122902457.7645.13.camel@jetpack.demon.co.uk> <20050801192454.G3492@antyk.obta.uw.edu.pl> Content-Type: multipart/mixed; boundary="=-zb3KNzAUScxnnb51kRi1" Date: Mon, 01 Aug 2005 19:48:52 +0100 Message-Id: <1122922132.7645.43.camel@jetpack.demon.co.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: alanh@fairlite.demon.co.uk Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-1.0 tagged_above=-50.5 required=7.0 tests=BAYES_00 X-Spam-Level: --=-zb3KNzAUScxnnb51kRi1 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2005-08-01 at 19:31 +0200, Konrad M. Kokoszkiewicz wrote: > > I've found why FreeMiNT 1.16.x won't work on my TT, and below is a patch > > to fix it. > > > > It seems that a pop from the stack had crept into the mmu030.S file. > > This fix does not seem completely perfect at first glance. You rather have > to restore the pop you deleted, and move the push to the very begin of the > routine. Note that there are two branches to the label "normal_set", and > both have to be inside the scope of the push/pop operation. > > In other words, these lines in mmu030.S: > > set_mmu: > tst.l _offset_tt_ram > beq.s normal_set > movem.l d0-d2/a0-a2,-(sp) > > should look like this: > > set_mmu: > movem.l d0-d2/a0-a2,-(sp) > tst.l _offset_tt_ram > beq.s normal_set > > And this - and not deleting the pop - seems to fix the real bug we have in > this procedure. No, that's still not quite right either. Below is the right fix taking into account the second branch to "normal_set". Because "normal_set" loads "crp" from the stack, which becomes corrupt if we've already pushed it. We need to pop it before it reaches loading of crp. Attached is a better fix which should take care of the second call to "normal_set" as well. Alan. --=-zb3KNzAUScxnnb51kRi1 Content-Disposition: attachment; filename=mmu030.S.patch2 Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name=mmu030.S.patch2; charset=UTF-8 SW5kZXg6IHN5cy9hcmNoL21tdTAzMC5TDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL21pbnQvZnJl ZW1pbnQvc3lzL2FyY2gvbW11MDMwLlMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjcNCmRpZmYg LXUgLXIxLjcgbW11MDMwLlMNCi0tLSBzeXMvYXJjaC9tbXUwMzAuUwk3IE1heSAyMDA1IDA4OjU4 OjE2IC0wMDAwCTEuNw0KKysrIHN5cy9hcmNoL21tdTAzMC5TCTEgQXVnIDIwMDUgMTg6NDU6NDIg LTAwMDANCkBAIC0yNiw5ICsyNiw5IEBADQogCS5nbG9ibAlfc3lzX21fZnJlZQ0KIA0KIF9zZXRf bW11Og0KKwltb3ZlbS5sCWQwLWQyL2EwLWEyLC0oc3ApDQogCXRzdC5sCV9vZmZzZXRfdHRfcmFt DQogCWJlcS5zCW5vcm1hbF9zZXQNCi0JbW92ZW0ubAlkMC1kMi9hMC1hMiwtKHNwKQ0KIAltb3Zl LmwJI2VuZF9zZXRfbW11X2NhbGxlZF9zdF9yYW0gLSBzZXRfbW11X2NhbGxlZF9zdF9yYW0sZDEN CiAJY2xyLncJLShzcCkJCQkvLyBTVC1yYW0NCiAJbW92ZS5sCWQxLC0oc3ApDQpAQCAtNjYsMTMg KzY2LDEzIEBADQogCW1vdmVtLmwJKHNwKSssZDAtZDIvYTAtYTINCiAJcnRzDQogbm9ybWFsX3Nl dDoNCisJbW92ZW0ubAkoc3ApKyxkMC1kMi9hMC1hMg0KIAlwbW92ZQkobnVsbHRjKS5sLHRjCQkv LyB0dXJuIG9mZiBtbXUNCiAJZGMubAkweGYwMzkwODAwLG51bGx0YwkvLyBwbW92ZSBudWxsdGMs dHQwDQogCWRjLmwJMHhmMDM5MGMwMCxudWxsdGMJLy8gcG1vdmUgbnVsbHRjLHR0MQ0KIAlwbW92 ZQk0KHNwKSxjcnAJCS8vIGNhdXRpb246IGNycCBpcyA4IGJ5dGVzDQogCXBmbHVzaGENCiAJcG1v dmUJMHhjKHNwKSx0Yw0KLQltb3ZlbS5sCShzcCkrLGQwLWQyL2EwLWEyDQogCXJ0cw0KIA0KIHNl dF9tbXVfY2FsbGVkX3N0X3JhbToNCg== --=-zb3KNzAUScxnnb51kRi1--