[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: R65C02 PI
In article <502orp$e24@pith.uoregon.edu>,
Neil Parker <nparker@cie-2.uoregon.edu> wrote:
>In article <500k7k$mf9@nnrp1.news.primenet.com> johnlb@primenet.com (John
>Bowling) writes:
>>In article <4vv3gg$an7@europa.frii.com>,
>>Randy Shackelford <shack@deimos.frii.com> wrote:
>>>All the old games which I have tried with the exception of One on One work
>>>on a //c and IIgs for that matter.
>>
>>Europe Ablaze, Think Tank, and Evelyn Wood Speed Reading don't work on the
>>gs. I haven't bothered to look into why, but it has to be related to
>>either use of jumps into RAM or Dos/ProDOS which are undocumented, or use
>>of 6502 undocumented opcodes.
>
>Actually, there is at least one more reason why non-GS software can fail on
>a GS: absolute,X and absolute,Y addressing. This is probably a once-in-a-
>lifetime pitfall, but I have a program that fell into it.
>
>Machine-language programmers might want to take note of this.
>
>A few years ago I inherited a copy of MicroMotion Forth-79 from a former
>Apple II user. It worked just fine on an Apple IIe, but I couldn't get it
>to boot on my IIGS. For a long time I couldn't figure out why--it makes
>only minimal use of the ROMs, and only through published entry points, and
>it doesn't seem to use any undocumented 6502 opcodes.
>
>Finally a few months ago I found the cause of the problem. There are
>several places in its machine code where it uses instructions like this:
>
> LDA $FFFF,X
> ORA $FFFE,X
>
>The intent here was for the indexing to wrap around to zero page, and
>access the zero-page memory location one or two bytes before the location
>pointed to by the X register. This works just fine on the 6502 and 65C02,
>but on the 65816, it indexes into bank 1 and picks up the wrong data.
>
>I doubt the programmer who wrote that code had any idea it was happening.
>The original assembler source code probably looked something like this:
>
> LABEL EQU 0
> LDA LABEL-1,X
> ORA LABEL-2,X
>
>Since countless nearby references to "LABEL+1,X", "LABEL+2,X", etc., all
>assemble to zero-page,X addressing, it's not immediately obvious that this
>is any different. But even the dumbest 8-bit assembler knows that
>0 - 1 = $FFFF, which has a non-zero high byte, so it dutifully assembles
>absolute,X addressing.
>
>Had zero-page,X addressing been used for those instructions, there wouldn't
>have been any problem, since zero-page,X addressing wraps within zero page
>on the 65816 as long as the direct page register is page-aligned (as it
>almost always is in emulation mode). It would have been a couple of cycles
>faster too.
>
>Moral: If you're storing data in a table on page zero, check the output of
>your assembler carefully. You may be generating GS-incompatible code
>without even realizing it.
>
>
>I was able to get MicroMotion Forth-79 to work on my IIGS by hunting down
>all the $FFFF,X and $FFFE,X references, and replacing them like this:
>
> LDA $FF,X
> NOP
> ORA $FE,X
> NOP
>
> - Neil Parker
>
>P.S. Is there anybody out there besides me who actually owns a copy of
>MicroMotion Forth-79, and can't get to work on your GS? If so, send
>e-mail, and I'll send you the patch info.
>--
>Neil Parker, nparker@{cie-2,cie}.uoregon.edu, http://cie-2.uoregon.edu/~nparker
>
> "Evolution is vastly overrated." -- Ambassador Delenn, _Babylon_5_
>
Yah, that's wonderful... but MM Forth-79 was pretty limited. A much better
system is MAF (Mad Apple Forth) written by David Douthitt. It can read
the old Forth-79 disks (with a little patching... fairly obvious stuff.
I believe that there is a certain number of blocks of crap before the
actual blocks on the disk start...), and run the code with a little
touching up. Also, MAF adds support for block-files on your hard drive,
and (one of these days?) MAF 2.0 will add 16 bit support to speed things
up.
--
- Rev. SPQR 1WSW team member and proud of it
geek code: finger wbaguhn@nox.nyx.net - http://www.nyx.net/~wbaguhn/home.html
Flavour of the day: apple juice