Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!waikato.ac.nz!canterbury!cosc.canterbury.ac.nz!tomlin Newsgroups: comp.sys.amiga.emulations Subject: Re: re : Transformer - IBeM for 68000s RSN ! Message-ID: <1991Apr30.162842.544@csc.canterbury.ac.nz> From: tomlin@cosc.canterbury.ac.nz (M. Tomlinson) Date: 30 Apr 91 16:28:40 +1200 Sender: tomlinson@elec.canterbury.ac.nz References: <1991Apr29.103748.520@csc.canterbury.ac.nz> <15380@life.ai.mit.edu> Distribution: world Organization: Computer Science,University of Canterbury,New Zealand Nntp-Posting-Host: betelgeux.elec.canterbury.ac.nz Lines: 25 In article <15380@life.ai.mit.edu> psteffn@pogo.gnu.ai.mit.edu (Paul Steffen) writes: > >Wouldn't it be possible to do some exception handling so that you could >emulate the extra '20/'30 opcodes on a '00? It seems feasible >to me but I haven't seen anyone do it yet. Perhaps this should > >go to the 68k newsgroup. Unfortunately this can't be done. The new instructions can be done this way by trapping the illegal instruction vector. But the new addressing modes can't always be trapped. For example move.w 0(a6,d3.w*2),d0 is not valid under the 68000 (because of the *2) but is valid on 020's/030's. I had a program that used this instruction and it did not cause any trap or guru when it encountered this instruction. The same was true for a lea $10000(a3),a2 instruction (offset too large for 68000's) and still no trap! Another problem is reading words/longs at odd addresses. Most 68020 code doesn't do this, but this too would be tricky to do on the 68000. (This does sound like the right group for this - its emulation of 68020 processors on the Amiga!). - Mark Tomlinson