Path: utzoo!mnetor!tmsoft!torsqnt!hybrid!scifi!bywater!uunet!easy!lron
From: lron@easy.hiam.com (Dwight Hubbard)
Newsgroups: comp.sys.amiga.emulations
Subject: Re: Emulator Mechanics (sorry long post)
Message-ID: <18cc3625.ARN0ee0@easy.hiam.com>
Date: 9 Mar 91 04:39:49 GMT
References: <10775@dog.ee.lbl.gov>
Reply-To: lron@easy.hiam.com
Followup-To: comp.sys.amiga.emulations
Distribution: na
Organization: You must be talking about someone else.
Lines: 63
Expires:
Keywords:

In article <10775@dog.ee.lbl.gov>, Jean-Noel MOYNE writes:

> In article <39935@cup.portal.com> Radagast@cup.portal.com (sullivan -
> segall) writes:
>           I agree with you, but there are some practical assumptions you
> can make. First, you want to define you goals, I mean what do you want
> this program for ? The goal here is to be able to run software we don't
> have on the Amiga, and at a decent speed. If you want to be realistic, you
> should make a few concessions, like don't expect games to run like that.
> What you want on the Aniga is these 'pro' programs, like lotus or dBase.
> So you assume that these programs are written quite cleanly, using legal
> calls, that they are written in C or another high-level language.

A good start would be just to get programs that use bios and dos for I/O
to run first, I'm sure there will be unexpected problems just doing that.

>           Knowing the way a 8088 accesses data, you can try to see
> modifications in the data pointer register (is it DX ... don't remember),
> and then if it's a code generated by a compiler, you're sure that you
> won't have data in the middle of the code, you can assume that data will
> be in nice well separated chunks, etc ...

On the 8088 the DS register is going to be pointing to the data segment,
but the ES register can be used as well.  Assuming the program is not
using self modifying code it should be possible to recersivly follow
the program code and make the assumtion that anything that is not executed
anywere in the flow of the program is data.  You will need to change all
references to data to labels as well.  Something like this is done for the
program DSM which will produce an Assembly language listing of an AmigaDos
application that can be put back through an assembler and run.  I forsee
a problem with the manner in which the processors access the data though,
I.E. high byte/low byte instead of low byte/high byte.

>          Separating data is a much more real problem than self-modifying
> code ! First self-modifying code is not that usual, you do it only when
> you're looking for extreme speed. Then it's not a good thing to do, and
> programmers of big applications know it. If you want your program to run
> on one of these fancy fast 386 with cache, you'd bettre not write such
> code. And finally, self-modifying code is only when you write in asm. A C
> program will not be self-modifying (unless the programmer is mad (-:). So
> don't worry about self-modifying code, maybe games won't run ... but tell
> me: WHO WANTS TO RUN PC GAMES WHEN HE HAS AN AMIGA ?!??!!??!?!???!?
> (adventure and role-playing games are most of the time written in C or
> Pascal, since speed is not a issue).

Good points.

>           Running an interpretor at the same time you run the translator
> is one solution, but there must be a better one. I think the first think
> to do would be to start by writing a Ms/Dos assembler for the Amiga: given
> an ms/dos asm source code, generate the equivalent source code for
> AmigaDOS (in C or ASM, whatever). Then you can allways test the thing by
> using a ms/dos re-sourcer on the PC side to generate 8088 source code from
> existing applications.

I think it would be easier to do a Mac to Amiga sourcer than one to go from
MS-Dos to AmigaDos, since the byte ordering will be the same and of course
if the program accidently converts some code to data there will still be a
chance for it to run (the data should assemble back to the correct op codes)
----------------------------------------------------------------------
-Dwight Hubbard             USENET  : easy!lron@uunet.uu.net         -
-Kaneohe, Hawaii            CFR     : 31:910/101 (Dwight Hubbard)    -
----------------------------------------------------------------------