Re: A89: Re: porting Z80 to 68k.....possible?? (yes, but not easy)


[Prev][Next][Index][Thread]

Re: A89: Re: porting Z80 to 68k.....possible?? (yes, but not easy)





> I have only 3 points to make:
> 
> 1) What about a routine like this to access data?
>    ld a,(level)
>    ld b,a
>    ld de,49 ;Size of a level
>    ld hl,levelSet+1-49 ;levelSet-48
> lvlAddLoop:
>    add hl,de
>    djnz lvlAddLoop
> 49 is a odd number... and this is a program that will eventually be on
> 83s

It depends on what's in the level data.  If it consists of only data,
there will be no problem.  After all, all data is accessed as bytes by
the Z80; there are no instructions to load a word from a variable
address.  If you store this address in a word load instruction by
self-modifying code, that will also still be OK since the word loads
are split to avoid this problem.

> 2) What about people who write self-modifying code like this:
>    .db $FE; cp n
> levelCountCheck .db 0

That wouldn't work under the current design.  If it's only used in a
few places, it's probably easier to just change the source code so it
will work under the converter.  However, if I see a lot of this I may
need to come up with a solution; this will be harder than the other
way, since it's harder to determine what is or isn't code.

This way of writing self-modifying code is, however, much less logical
than the one I mentioned.
 
> 3) What about actual data that is accessed by (label+1)?

That isn't a problem.  The self-modifying code conversion would only
be done when there is code at label+1.  Of course, as you mentioned
before, there are problems if the person enters code with .db
directives.


Follow-Ups: References: