Chris_Johnsen@mindlink.UUCP (Chris Johnsen) (03/04/91)
The following messages were shared in an email environment between Charlie
Gibbs and myself over the last couple of days. We decided that it would be a
good idea to share these thoughts with the readership of
comp.sys.amiga.emulations. The messages speak for themselves for the most
part.
------------ Included text of messages ------------
Sun Mar 3 6:40:53 1991 From: Chris Johnsen [547] Subject : Emulators
Hello Charlie! Long time no talk to you eh? I haven't seen you for quite some
time. I was particularly fond of those after-PaNorAmA meetings at Wendy's a
few years ago. I trust you recall me from back then.
I have been following the comp.sys.amiga.emulations newsgroup on Usenet for
quite awhile now and was quite interested in the IBeM program that is being
posted about recently. In one of the near Alpha/Theta states that, being a
programmer, such as yourself, one recognizes as some kind of "source"; I had
an idea. Since there are not many "new" ideas spawned I wanted to get some
feedback from a person with the expertise you possess. The reasons I thought
of you for this private consultation are: 1) you've written an emulator -
SimCPM 2) you've written an assembler - A68K 3) you have a broad knowledge of
the computing field beyond lowly PC's and 4) you're such a nice guy!
I was musing about how an emulator would work. I must confess I have no
concrete knowledge of this. It has been said that "Not knowing how to do a job
'right' frees you to discover new and better ways of accomplishing the desired
result". Freeman Patterson (a Canadian photographer), in his book Photography
and the Art of Seeing, called this "thinking sideways". I believe I've
thought of a way of writing an emulator that would run at least as fast on the
Amiga as it would on the source machine.
My questions for you are:
Would you be interested in being a mentor to me in developing further this idea
or in fact ascertaining whether my concept has any validity?
I'm reticent to spill this on the net until I'm somewhat confident that it is
indeed practicable. I have thought about the possible legal considerations of
producing an emulator. There are potential commercial possibilities that one
could consider also.
Would you please give me just a quick, superficial rundown of the basic
algorithms used in developing an emulator?
I have assumed that you would read in the object module of say an IBM
executable, read it by opcode or routine, decipher the intent and then call a
library of glue routines to do the job that the program would have on an IBM
or clone. I have no idea how the interrupt structure would be handled but know
that you have done it with SimCPM.
I don't want to waste your time, but I would appreciate this information. I
would like to get your feedback on these questions to see if you are interested
in further discussion with me on this matter. If you are not interested or
don't have the time I'll certainly understand. I realize I'm asking you for
more information than I'm sharing but an idea is a tiny property and I'd like
to at least savor this for a while before I decide what to do with it. That is
the sole reason I have not gone public with it yet.
If you are indeed interested, after you tell me on the highest level how an
emulator functions, I'll be able to describe this idea on some kind of
comprehensible basis. I'm looking forward to your response! Thanks Charlie.
csj
Sun Mar 3 23:12:32 1991 From: Charlie Gibbs [218] Subject : Emulators
Indeed I am somewhat short of time these days, but I wouldn't mind kicking
the odd idea around without getting too wrapped up in it. I do understand your
idea of "thinking sideways" and enjoy being able to do it myself from time to
time. A similar way I've heard it described is that even though it's been
proven that bumblebees can't fly, they don't realize this and so do it anyway.
Or to put it another way, I like to write programs that are too stupid to know
what they're doing, so they can do anything.
Your ideas on emulation are basically in line with what's considered the
standard way of doing things. A machine instruction is analyzed as to just
what it's supposed to do, and appropriate code then carries out the operation.
The guts of SimCPM appeared in Dr. Dobb's journal as an emulator that was meant
to run under CP/M-68K. This made the job a bit easier for the original author,
since the CP/M-68K system calls were quite similar to the CP/M calls that he
was emulating. I had to replace this portion of code with appropriate AmigaDOS
routines. In addition, I extended the code to handle the full Z-80 instruction
set, since the original code could only handle the 8080 subset.
Since emulating another processor in software is quite a CPU-intensive
process (several machine instructions have to be executed to emulate a single
machine instruction on the target machine) I tried to optimize SimCPM for speed
at the expense of memory and redundant code. The overhead of a single
subroutine call, plus any extraction and interpretation of arguments, would
require several times as much time as a hand-picked set of instructions
dedicated to a single opcode.
For system calls there's easy out - as soon as I recognize what the
emulated program is trying to do (e.g. read a block from a disk file), I call
the corresponding AmigaDOS routine, so I/O can proceed pretty well at native
speeds. Therefore, even though CPU-bound programs might run 10% as fast as
they would on the target machine, I/O bound programs might get up to 50% of
speed.
Interrupts were easy - since most CP/M systems don't use hardware
interrupts, except possibly for a very few hardware-dependent programs, I
simply didn't worry about them. Software interrupts (the RST instruction) were
a snap on the other hand, since they're basically a special-purpose subroutine
call.
The Intel 8080 is fairly easy to emulate because the opcode is uniquely
determined by the first byte of the instruction. Some instructions might have
register numbers encoded in a few bits of that first byte, but I just treat
them as special cases. To decode the byte, I just multiply its value by 4
(shift left 2 bits) and use the result as an index into a table of 256 pointers
to the actual emulation routines. Since there are 64 possible MOV instructions
(well, 63 because one of the bit combinations is actually HLT) I actually have
63 MOV emulations, one for each combination of registers. This means that I
don't have to do any register decoding, since each routine consists of a
dedicated 68000 MOVE instruction, followed by a jump back to the main emulation
loop. Lots of almost-redundant code, but it's about as fast as it can get.
This is getting kind of long-winded. I'd be interested in hearing any
ideas you may have; although I wouldn't have time to get into the programming
of such stuff, I'm willing to act as a sounding board. Talk to you soon... CJG
Sun Mar 3 23:18:48 1991 From: Charlie Gibbs [218] Subject : Emulators
Another approach I've heard of is to "compile" the code to be emulated
into native machine code. This would involve a front-end program which would
read the target machine's program and analyze the instructions. For instance,
if the "compiler" detects an instruction that does a move between two of the
emulated machine's registers, it would simply generate a move instruction in
the emulating machine's code. It could generate either a translated assembly
language source file or a machine-language file ready to load into the
emulating machine. This would require the "compilation" process to be run once
on the program to be emulated, and you'd then run the output of this
"compiler." There are special tricks to consider here, such as resolving
addresses - you couldn't just copy the memory addresses across because the
emulated routines would likely be a different size. It might be easier to
generate a label (e.g. Axxxx where xxxx is the hex address in question) in an
assembly source file and let the emulating machine's assembler sort it all out.
I've never actually seen this process in action, but it's another
possibility. --CJG
Mon Mar 4 12:38:31 1991 From: Chris Johnsen [547] Subject : Emulators
Thanks a lot for your effort in explaining SimCPM to me man. As you describe
it, it would seem that I had intuitively understood the basic concepts. I
would think that interrupts would be the hardest part to get down to reliable
operation. What I had in mind, while thinking about this, in general terms,
was an emulator that was non-specific as to the machine, therefore I was
attempting to contemplate it handling say IBM, Mac, (hey it may even be
possible to deal with Amiga emulation!) and Atari ST on the Amiga and
imagining what the various architectures would require. All this on a very
abstract level.
Your second message hit the nail on the head! I got bogged down at about the
level you describe in your first message. Lots of details to be sought and
worked out. Gee, I'm really not even available to code another program just
yet anyway. I was giving the whole concept a rest when, what I thought of,
kind of sideways (lazy minds tend to look for an easier way around an
obstacle, sometimes unconsciously, even though this can lead to harder, though
more elegant solutions to problems), was to read the opcodes from the "source
executable" of the emulated machine, producing an assembly listing of the
program. This I imagine would be a two pass process, sort of like a C
compiler, followed by an assembler's two passes, and finished off with a
linker.
I thought that, if the compiler was "intelligent" enough, the output, though
likely larger, would be much faster than the common "interpreter type
emulator". I had never heard of such an idea and since there are none out
there, wanted to discuss this with you. I have developed the idea no further
than this in essence.
I did think of a few other considerations however. If one could, indeed,
compile an executable image of say Lotus 123 from the IBM into a program which,
on a base Amiga, could run at half speed, or on a A2500 or A3000 at twice the
speed, it would be a viable alternative, besides being a neat toy. However,
the standalone program generated would likely infringe on the copyright of
Lotus because the Amiga executable would actually be Lotus 123. Take
WordPerfect for instance. The latest version available is 4.1 or just a
micro-point higher, no problem, get hold of the IBM version 5.1, I believe it
is, and compile it and you have something some other people are wailing for. Of
course the rebuttal (I can hear you thinking?) is that, if a person owns
WordPerfect he has an inalienable right to run it. Run it on an IBM. Run it on
a clone. Run it through an Amiga compiler. You know, if it's for personal
use, etc.
As to the increase in size of the "compiled emulation" program, I have a couple
of ideas. First, the executable, though larger, would be standalone, except
for any support libraries. This doesn't mean that this "form" of emulator,
more like a "translator of executables", would be any less efficient than the
"interpreter type". Perhaps more memory efficient in a couple of possible
ways. Since the interpretation section of the program is in the compiler, and
the source executable is not required at runtime, memory usage may well be less
with a "compiled emulation". The second concept is to use link libraries which
would bind only the emulation routines required to the final program. Possibly
a combination of bound-at-link-time modules of less frequently used routines
and a shared library of essential routines all programs would need. A solely
link library approach would leave this concept open to claims that pirates
could produce "warez" that need no extra code or setup to work. Of course,
pirates appear to be capable of ripping anything off anyway!
This "compiled emulation" would, given sufficient memory and CPU
speed/efficiency, allow the running of multiple programs. Both emulated
programs and standard Amiga programs. Through the use of a shared library more
than one emulating program could be run without the overhead of multiple
"emulation interpreters" resident in memory.
The compiler could generate C statements so that you could take advantage of
the advancements in technology in the compiler, assembler and linker, without
having to deal, directly, with those parts of the system. I know this would
make the compiler operation more unwieldy. More operations, therefore it
would take longer, but theoretically the source is bugless, so you would
expect the output of this "emulation compiler" to either succeed or fail.
You'd run the emulator on the program only once. The beauty of producing
assembler (C would be better here), is that if it didn't work first time, a
programmer type could patch it up in source and get it running. I'm really
intrigued by this idea. Where did you hear about it, do you remember?
My knee-jerk reaction initially was to file the idea, but then I got to
wondering why no one had done it. There were many emulators out there for
various source machines. Why were none of them compilers? Another idea I had
was to contact the dude in Oz (or is he a Kiwi?) that wrote IBeM. He already
has the emulation working except for the parallel and serial ports. It would
appear that he reads the IBM object code, deciphers it and runs a routine, or
simply does a MOVE using an opcode lookup table, as you suggest; an
interpreter. If he instead simply wrote out an instruction in ASCII to do the
call or move instead, using a shared library of his emulation routines, he'd
basically have it. The end user would also have to have an assembler or C
compiler, however. This type of approach has got to produce faster emulation,
if it is possible. I believe it to be.
Anyway, that's what I had in mind Charlie. I really do appreciate your
feedback on this. Care to comment on any directions you think could be
followed? Do you know anyone with enough venture capital to fund the further
development of this concept? ;-) Do you think I should approach the author of
IBeM (cute name) directly? Or, should this private discussion we've been
having be moved to Usenet? Thanks again Charlie! I appreciate you man.
csj
Mon Mar 4 15:36:53 1991 From: Charlie Gibbs [218] Subject : Emulators
I can't remember where I first heard of the idea. The converted code
won't necessarily be smaller than the original, depending on the relative sizes
of corresponding machine instructions on both machines. However, if you could
make the compiler really smart it might be able to recognize certain sequences
of instructions and replace them by sequences designed to accomplish the same
thing more efficiently. For instance, since the 8080 doesn't have a multiply
instruction it needs to fake it with a bunch of adds and shifts. A smart
compiler, if it could recognize such a routine, could replace it with a single
68000 multiply instruction and see huge savings.
I'd stay away from calling subroutines; the overhead could kill you.
The copyright issue could be a sticky one, although I can't see any
problems if you run the converter on your own copy of the emulated software and
don't try to sell the result. It would no doubt be classified as a "derivative
work".
Perhaps it might be interesting to throw this discussion out to Usenet. It
won't be a trivial job, which is probably why we haven't seen it done
elsewhere. Remember that a straight machine-code emulation duplicates all the
register fiddling that is required by the target machine's architecture (and
the 80x86 family needs a LOT of register fiddling). This code is replaced by
the 680x0's own internal fiddling if you're re-compiling source code. One way
of looking at it is to decompile the original machine code, then recompile it
for the new machine.
Interesting stuff... CJG
------------ End of included text of messages. -----------
Both Charlie Gibbs and myself frequent this newsgroup and look forward to any
additions to this discussion with which others may respond. Sorry that the
posting is so long but I felt there was little enough chaff contained in the
messages to warrant including all of them.
csj
The hard way is usually the disguised easy way, you take your choice. Usenet:
a542@mindlink.UUCP Phone: (604)853-5426 FAX: (604)854-8104Charlie_Gibbs@mindlink.UUCP (Charlie Gibbs) (03/06/91)
In article <1991Mar6.010141.5905@mintaka.lcs.mit.edu>
rjc@pogo.ai.mit.edu (Ray Cromwell) describes a 6502 emulator that
looks a lot like my SimCPM. You're right that it would be better
to use MOVE from SR instead of GetCC() to get the flags. Before
anybody unholsters their flame throwers, I would hasten to point
out that normally I wouldn't think of doing such a dastardly thing,
but in this case it's too much of a performance hit to do otherwise.
We have to keep that loop as tight as possible if we're going to
get any speed at all.
As in your example, SimCPM's individual instruction emulation
routines fetch the flags so that I can use custom-tailored conversion
routines for more speed. One trick I use is to use the entire flag
byte as an index into a 256-byte table form which I pull the
translated flag values, again trading memory for speed.
This makes for lots of places where I need to get the flags.
What I've done in SimCPM is to define a macro that generates either
MOVE from SR or MOVE from CCR depending on the setting of an
assembly-time switch. The result is two versions of SimCPM - one
runs only on the 68000, while the other runs only on 68010 and
higher processors. I can't think of any other way to do it that
doesn't itself involve a prohibitive amount of overhead or lots of
self-modifying code.
Charlie_Gibbs@mindlink.UUCP
"I'm cursed with hair from HELL!" -- Night Courtpepers@enme1.ucalgary.ca (Brad Pepers) (03/06/91)
I have heard this idea discussed a fair bit in research and technical papers. I think it often gets down to the problem of self-modifying code. I can write code to 'calculate' an instruction (create a valid instruction in some hard to decipher way) and then store it in my code space. Now believe me I never do this but I believe many IBM programs do. But I'm not sure - maybe a significant portion of them don't? Brad Pepers (pepers@enme.ucalgary.ca or pepers@cpsc.ucalgary.ca)
rjc@pogo.ai.mit.edu (Ray Cromwell) (03/06/91)
Very interesting article. I myself have been tempted several times
to try and write an emulator. Since I programmed 6502 assembly on the
C64 for 4 years, and I know 68000 on the Amiga, I was tempted to
try to beat the speed of the other emulators. Then I realized
the sheer magnitude of the project. Emulating the instruction set is
easy. In fact, I am quite confident I can make a 6502 emulator run
faster on the Amiga then the C64. The hard part is the hardware.
Most C64 programs discard the oS entirely and bang on the hardware.
Further more, most of them use polling loops, like polling the
raster beam register and using precisely cycle timed delays. Moreover,
the VIC chip contains several glitches that allow programmers to
use tricks to remove the borders, vertically scroll the screen to
ANY raster location, horizontally shift the screen, vertically and
horizonally interlace the screen, stretch pixels (double, triple,
quaduple) length vertically. This is virtually IMPOSSIBLE to
detect, unless the emulator is artifically inteligent. And, any
program that has a fastloader won't work. This is because fastloaders
usually transfer data over the serial clock line, and data line. This
doubles bandwidth, unforunately it requires PERFECT timing, so perfect
in fact that it won't work on PAL computers, and vice versa.
Sprites are another problem, since Amiga sprites are only 16 pixels wide, and
C64 sprites can have their width and heigth doubled, and they rely
on a chunky pixel format. Text is another problem since the
C64 has a builtin Text mode.
The Mac is the easiest computer to emulate because it's not a computer
at all. The Macintosh computer does not exist, it's nothing more
than a ROM chip.
A few days ago, I was impressed. I downloaded a demo from ab20 called
C64Music.zap. This demo emulates 6502 at 100% (in fact, it emulates it
at perfect timing because the music is exactly the same speed.) This
demo emulates the SID chip PERFECTLY, and I mean perfect. These guys
should join together with the maker of A64.
I can't speak for other 6502 emulators, but if I wrote one, the fastest
method looks like table lookup, with careful optimization to make
sure things are long word aligned. For instance, I might do something like
pc6502 equr a5
accum equr d5
xindex equr d6
yindex equr d7
stack equr a4 ; 6502 stack, which is base address + $0100 on the C64
stat equr d4 ;status register
[allocmem the 6502's address space, load in an
executable and set the pc to it's start]
lea jumptbl(pc),a2
sub.l d0,d0
loop move.b (pc6502)+,d0
lsl.l #2,d0
move.l (a2,d0),a3
jmp (a3)
then every instruction would be emulated (even undoc's) and put into
the jumptbl. The code for 'LDA address' might look like:
lda sub.l d0,d0
move.b (pc6502)+,d0
lsl.l #8,d0
or.b (pc6502)+,d0
add.l addresspace,d0 ;this code inverts the 6502 little-endian
; and then add's the base address of the
; memory that was alloc's for it
move.l d0,a3
move.b (a3),accum
jsr GetCC() ? ;It might be better to use move SR, providing you
; check the machine you were running on and did
; and did a move ccr otherwise
; status reg is now in d0
and #mask,d0 ; mask off everything but the Z bit
bne whatever
whatever bclr #1,stat
jmp loop
bset #1,stat
jmp loop
(note: this code can be optimized, its off the tip of my tongue, and
probably bugged since I haven't coded in asm in awhile)
From my quick calculations, the jump table dispatcher incurs about a 3-4
microsecond delay in the fetch of each instruction. This is equivelent
to about 4 cycles on a 6502 @1.02mhz. If you had infinite amounts of ram,
the object code loader could 'inline' the code for each instruction
and get rid of this delay, I beleive this is probably how the C64Music
demo does it, since music players on the C64 were only about 1k of code.
The Lda routine itself looks like about 2.2 times slower than a true 6502
delay which 4 cycles. However a 25mhz 68030 would run more than
twice as fast.
Theoretically speaking, an IBM emulator running on an Amiga3000
should be running at atleast 5mhz 80286 speed. Consider SoftPC on
the NeXT which runs at 12mhz UNDER UNIX. 68040's are about 2-3 times
faster then 68030's, so SoftPC on the Amy should run at about 5mhz.
Maybe we all should trying something like 'NetIBM'. What I mean, is
like Nethack, we should all participate in coding an IBM emulator.
Each person might post a small code segment (in assembler), the rest
of us can compete optimize it. I remember having a contest with
some trying to optimize the 'size' of a binary to decimal print
routine, the final result was the code was reduced 300% in size.
(we kept passing the optimized source back and forth, each shedding
a few bytes.)
Regardless of what happens. Let's keep the discussion up, it's interesting
and educational.
JKT100@psuvm.psu.edu (JKT) (03/06/91)
...hating to throw a monkeywrench in a thoroughly wonderful and thought
provoking discussion, but....
I love the idea of a pre-compiler for emulators and I too thought (and
maybe still do think) it possible, but consider this BIG problem:
What if you have a modular program that swaps parts of itself in
and out AND does direct jumps to different portions of the swapped
code? How on earth is your compiler going to know what to put in
the place of that direct jump??
Kurt
--
-----------------------------------------------------------------------
|| Kurt Tappe (215) 363-9485 || With. Without. And who'll ||
|| 184 W. Valley Hill Rd. || deny it's what the fighting's ||
|| Malvern, PA 19355-2214 || all about? - Pink Floyd ||
|| jkt100@psuvm.psu.edu --------------------------------------||
|| jkt100@psuvm.bitnet jkt100%psuvm.bitnet@psuvax1 QLink: KurtTappe ||
-----------------------------------------------------------------------jonabbey@cs.utexas.edu (Jonathan David Abbey) (03/06/91)
The primary problem I see with a compile-type scheme is that self modifying code would go out the window. It would likely not be possible to determine in advance whether or not the code would self-modify, and it would certainly be impossible to determine in advance what the result of such activity would be. Because of this, you would need to have your run time code be able to jump in to an interpreted mode to handle the self modification, then recompile the effected code. Doable, perhaps, but not pretty and not at all simple. The other problem is that for something on the order of an MS-DOS emulator, you would need to be able to support the entire environment effectively. What if your Wordperfect 5.1 implemented on-line help as a TSR or some MS-DOS strangeness? Does MS-DOS support an overlay system? How about chaining? I truthfully don't know whether such a thing could be built. Given how many times I've been pleasantly surprised by apotheosistic programmers, I wouldn't be surprised if it were possible. But I suspect that an out-right compiler isn't in the cards. An interpreter that can do advance analysis on certain code segments and jump out to compiled segments would seem to be actually feasible, but I still am having dark visions of self-modifying code. -- ------------------------------------------------------------------------------- Jonathan David Abbey \"I am stronger than the passing time" -Frost the university of texas at austin \ jonabbey@cs.utexas.edu "Does any of this computer science/math?/psychology? \ (512) 472-2052 make sense?" -Me
ifarqhar@sunb.mqcc.mq.oz.au (Ian Farquhar) (03/06/91)
In article <1991Mar6.010141.5905@mintaka.lcs.mit.edu> rjc@pogo.ai.mit.edu (Ray Cromwell) writes: > The Mac is the easiest computer to emulate because it's not a computer >at all. The Macintosh computer does not exist, it's nothing more >than a ROM chip. The best description of a Mac I've ever read! :-) > I can't speak for other 6502 emulators, but if I wrote one, the fastest >method looks like table lookup, with careful optimization to make >sure things are long word aligned. For instance, I might do something like How about this? Write code for every one of the 256 possible opcodes, and make sure that it follows these important considerations: 1) The code is responsible for updating all registers, the 6502PC, and also for checking special functions if a hardware location is called. 2) It should be 256 bytes per opcode or less. 3) It should jump back to STLP (see below) when done. 4) It should intelligently introduce timing delays (very hard) 5) Something else I've forgotten. Take each piece of code, and distribute it in a 64K memory area, so that the code for opcode N starts at base + (n << 8). There may be a lot of wasted space, but on any reasonable Amiga, this space can be sacrificed for speed IMO. ; Base reg of instruction code in A0. 6502PC in A1. STLP MOVE.B (A1), lcna ; lcn is the upper byte of the ; dsp displacement below JMP dsp (A0) Excuse my poor 68K code. I think this will work, but it has been three years since I even looked at assembler on the 68000. Before anyone screams about this code failing on a 68030, remember that the modification made above is only needed until the JMP. After that, we do not need to see it again. If I read the info on the 68030 cache properly, this should be okay. At worst, the instruction cache can be disabled. This should be considerably faster than any table driven system. On any system with multi-byte opcodes (eg. the 8088), this system can be easily extended, and minor modifications can be made to emulate most modern CPU with reasonable speed. Now a suggestion for dealing with hardware locations (harder on memory mapped systems than on things like Intel and Zilog chips which have I/O instructions.) This is another memory-expensive solution, BTW. For every location, have two flags, one for read and one for write. If the opcode handlers write to the location, they can check the write flag and if it is set, call a handler which determines which location is being modified, and pass control to a routine to do it. Now for the VERY memory expensive solution. Have one 16 bit displacements per memory location (ie. for 1M of simulated RAM you must have 3M of real RAM.) This location contains the displacement from a base register to a routine which handles that memory location. If this word is non-zero, an instruction that reads or write to it calls this routine. You could even have two displacements, one for read and one for write, but this would only be practical for systems that have small amounts of simulated memory (eg. C64). At a rough estimate, for a C64 emulator (IMO the hardest of all emulators.) Simulated Memory 64K Read Displacements 128K Write Displacements 128K Opcode handlers 64K Memory Location Handlrs 28K (?) Rest 100K (??) ---- 512K So, for an average 1M Amiga, this is quite possible. As for the project, why not start with something much simpler? An Atari 2600 emulator. The hardware is quite simple to simulate, though the timing will have to be *very* precise. This would be a good starting point. Opinions, anyone? -- Ian Farquhar Phone : + 61 2 805-9400 Office of Computing Services Fax : + 61 2 805-7433 Macquarie University NSW 2109 Also : + 61 2 805-7420 Australia EMail : ifarqhar@suna.mqcc.mq.oz.au
lron@uunet.uu.net (Dwight Hubbard) (03/06/91)
In article <4992@mindlink.UUCP>, Chris Johnsen writes: > Another approach I've heard of is to "compile" the code to be emulated > into native machine code. This would involve a front-end program which would > read the target machine's program and analyze the instructions. For instance, > if the "compiler" detects an instruction that does a move between two of the > emulated machine's registers, it would simply generate a move instruction in > the emulating machine's code. It could generate either a translated assembly > language source file or a machine-language file ready to load into the > emulating machine. This would require the "compilation" process to be run once > on the program to be emulated, and you'd then run the output of this > "compiler." There are special tricks to consider here, such as resolving > addresses - you couldn't just copy the memory addresses across because the > emulated routines would likely be a different size. It might be easier to > generate a label (e.g. Axxxx where xxxx is the hex address in question) in an > assembly source file and let the emulating machine's assembler sort it all out. I think I read about a company that had something like this for Unix about a year ago but I don't remeber all that much. Handling interupts looks like it would be harder with this approach. > Your second message hit the nail on the head! I got bogged down at about the > level you describe in your first message. Lots of details to be sought and > worked out. Gee, I'm really not even available to code another program just > yet anyway. I was giving the whole concept a rest when, what I thought of, > kind of sideways (lazy minds tend to look for an easier way around an > obstacle, sometimes unconsciously, even though this can lead to harder, though > more elegant solutions to problems), was to read the opcodes from the "source > executable" of the emulated machine, producing an assembly listing of the > program. This I imagine would be a two pass process, sort of like a C > compiler, followed by an assembler's two passes, and finished off with a > linker. Basic concept sounds good, kinda sounds like the DSM program except it would convert another machines machine code to 68000 assembly... > I thought that, if the compiler was "intelligent" enough, the output, though > likely larger, would be much faster than the common "interpreter type > emulator". I had never heard of such an idea and since there are none out > there, wanted to discuss this with you. I have developed the idea no further > than this in essence. It sounds like it would be faster. > I did think of a few other considerations however. If one could, indeed, > compile an executable image of say Lotus 123 from the IBM into a program which, > on a base Amiga, could run at half speed, or on a A2500 or A3000 at twice the > speed, it would be a viable alternative, besides being a neat toy. However, > the standalone program generated would likely infringe on the copyright of > Lotus because the Amiga executable would actually be Lotus 123. Take > WordPerfect for instance. The latest version available is 4.1 or just a > micro-point higher, no problem, get hold of the IBM version 5.1, I believe it > is, and compile it and you have something some other people are wailing for. Of > course the rebuttal (I can hear you thinking?) is that, if a person owns > WordPerfect he has an inalienable right to run it. Run it on an IBM. Run it on > a clone. Run it through an Amiga compiler. You know, if it's for personal > use, etc. Well, the output of the program would most likely fall under the copyright of the original as a derivitave work, however the program to convert wouldn't be illegal as it modifies the original program much like many disk copiers will modify a program to remove manual protection and such. > The compiler could generate C statements so that you could take advantage of > the advancements in technology in the compiler, assembler and linker, without > having to deal, directly, with those parts of the system. I know this would > make the compiler operation more unwieldy. More operations, therefore it > would take longer, but theoretically the source is bugless, so you would > expect the output of this "emulation compiler" to either succeed or fail. > You'd run the emulator on the program only once. The beauty of producing > assembler (C would be better here), is that if it didn't work first time, a > programmer type could patch it up in source and get it running. I'm really > intrigued by this idea. Where did you hear about it, do you remember? I like the idea as well, although I think 'C' is pretty much out. > My knee-jerk reaction initially was to file the idea, but then I got to > wondering why no one had done it. There were many emulators out there for > various source machines. Why were none of them compilers? Another idea I had > was to contact the dude in Oz (or is he a Kiwi?) that wrote IBeM. He already > has the emulation working except for the parallel and serial ports. It would > appear that he reads the IBM object code, deciphers it and runs a routine, or > simply does a MOVE using an opcode lookup table, as you suggest; an > interpreter. If he instead simply wrote out an instruction in ASCII to do the > call or move instead, using a shared library of his emulation routines, he'd > basically have it. The end user would also have to have an assembler or C > compiler, however. This type of approach has got to produce faster emulation, > if it is possible. I believe it to be. Hmm, I think it might take a little more work at least initially but imagine what could be done if the software were to recognize standard Windows 3.0 calls as well as the normal bios calls and map them to Intuition calls instead... Gee, maybe we could get Ami Professional or Word to run. > I can't remember where I first heard of the idea. The converted code > won't necessarily be smaller than the original, depending on the relative sizes > of corresponding machine instructions on both machines. However, if you could > make the compiler really smart it might be able to recognize certain sequences > of instructions and replace them by sequences designed to accomplish the same > thing more efficiently. For instance, since the 8080 doesn't have a multiply > instruction it needs to fake it with a bunch of adds and shifts. A smart > compiler, if it could recognize such a routine, could replace it with a single > 68000 multiply instruction and see huge savings. Hmm, I'm sure there are many more optimizations that can be had as well. The big thing is to generate inline code to keep speed up instead of using subroutines. > I'd stay away from calling subroutines; the overhead could kill you. Looks like I was one comment to high. > The copyright issue could be a sticky one, although I can't see any > problems if you run the converter on your own copy of the emulated software and > don't try to sell the result. It would no doubt be classified as a "derivative > work". > > Perhaps it might be interesting to throw this discussion out to Usenet. It > won't be a trivial job, which is probably why we haven't seen it done > elsewhere. Remember that a straight machine-code emulation duplicates all the > register fiddling that is required by the target machine's architecture (and > the 80x86 family needs a LOT of register fiddling). This code is replaced by > the 680x0's own internal fiddling if you're re-compiling source code. One way > of looking at it is to decompile the original machine code, then recompile it > for the new machine. The big problem is going to be emulating the hardware, like using the Graphics.library text routine to print a character if someone goes and changes b000 0000(mono) b800 0000 (color) when the system is in text mode, not to mention recoginzing when to display text and when to display graphics. Emulating the chips other than the CPU is going to be the problem unless all you want to run is stuff that just makes bios calls (the mac would probably be easier, but then I don't know that much about the Mac so I could be wrong) All and all it sounds like a good idea, if I wasn't so busy I would even be interested in getting things started. Maybe in a month or so. ---------------------------------------------------------------------- -Dwight Hubbard USENET : easy!lron@uunet.uu.net - -Kaneohe, Hawaii CFR : 31:910/101 (Dwight Hubbard) - ----------------------------------------------------------------------
ifarqhar@sunb.mqcc.mq.oz.au (Ian Farquhar) (03/06/91)
An idea about code compilation, rather than interpretation. If you assume that a program does not employ self-modifying code, this may not be nearly as had as it first appears (I am not saying that it is trivial, just not too bad.) This assumption can be made if the program runs out of ROM, and also in 99% of non-ROM cases. The problems of compiling code for one CPU into that for another are fairly easy, but a major problem occurs when table-driven code is employed (common.) What I am suggesting is this. It is reasonably elegant, and quite simple to perform: Store the loaded memory image of the original program as well as the compiled code. For every instruction in this image, a pointer to the compiled code is generated indicating where the corresponding code actually is. As the program executes, the working store is this memory image, and if a piece of data is read, it can be dealt with normally. However, if a program attempt to jump, branch or call a location using data loaded (as would happen with a table), then the corresponding location can be determined and the correct code called. This has a high memory overhead (3-5 times original image size *plus* compiled code). I am sure that there is a more memory-effective way of doing this by identifying such tables during the compile, but it seems a difficult problem. Has anyone got any better solutions? BTW, an idea for semi-compiled code. Have two branches for every location, and simulate the machine that way. Reading an opcode calls the appropriate opcode handler, writing it calls a reevaluation routine that changes the pointers for the two locations. System and special locations are handled similarly. This may actually be a quite reasonable solution, as inelegant as it first sounds. -- Ian Farquhar Phone : + 61 2 805-9400 Office of Computing Services Fax : + 61 2 805-7433 Macquarie University NSW 2109 Also : + 61 2 805-7420 Australia EMail : ifarqhar@suna.mqcc.mq.oz.au
pashdown@javelin.es.com (Pete Ashdown) (03/07/91)
This is slightly off the beaten path, but I thought I would add it to the
discussion of "emu-compiled" emulations.
A pirate in Germany has managed to do this for the C64. I haven't seen it,
I was told about it by a friend who had it. He stated that the game ran at
full speed with sound and clean graphics, on an Amiga 500! However, he
told me that it seemed extremely stupid to him to be playing a C64 game on
his Amiga 500, so he deleted it. However, the programmer left an address
for 'requests' of other conversions to do. Somehow, I think the conversion
process isn't completely simple and requires a bit of hand hacking to finish.
Also, I don't remember what the game was, or whether it was PD or not. I
personally would prefer a 'emu-compiler' for C64 emulation. There are a
number of games that I would like to play from the C64, but IMHO, booting up
the emulator and mucking around the the C64 OS is a pain in the buttocks.
With a 'emu-compiler' all I would need to do is run the game from the Amiga
and apparently, I wouldn't need an accellerator to enjoy it.
--
"This special edition of The Gulf War will continue after these messages."
-ABC
Pete Ashdown pashdown@javelin.sim.es.com ...uunet!javelin.sim.es.com!pashdowndclemans@mentorg.com (Dave Clemans @ APD x1292) (03/07/91)
On the "compiled" approach to emulation: There definitely has been previous work in this area. The system I've heard of was an internal tool that was used experimentally to port some games from the Intel world to the 68K world. To use it, you basically had to develop enough information to get a clean disassembly of the Intel code; i.e., so that you "knew" where all the code and data was in the source object file. That then was used to drive the tool that produced the "compiled" 68K file. After that was done you had to go over the output for correctness, system dependencies, etc.; it was not intended as a turn key system. ... As a side issue, to bring over some of the bigger DOS packages you'll have to worry about more than just converting a single file. You have to find and convert all of their code overlay files.... dgc
stevek@amiglynx.UUCP (Steve K) (03/07/91)
The idea of a "translator compiler" is very interesting. I could have sworn I saw some talk about a IBM->Atari ST translator that exists on FidoNET. But why is everyone talking about IBM? Why not Macintosh programs? Though I am not anyting close to a professional programmer, I'd imagine programs that run off different computers with the same processor would share some op-codes, right? Even if that is not true, they do both have similar GUIs, windows, gadgets, and menu bars, ect. which shold make the translation easier and more like the original. I sincerly hope someone will pick up and persue these ideas, it would be very benificial for me and others - I'd love to run a nice pascal compiler like Turbo Pascal, and an excellent ANSI editor like TheDraw! - Steve Krulewitz - Fair Lawn, NJ -
rjc@geech.ai.mit.edu (Ray Cromwell) (03/07/91)
I got an idea. How about combining both methods? (compile and interpret) First compile the executable with flow analysis into 68k code. Any instruction that tries to touch a hardware register will become a trap instruction(or use an MMU to trap it) to emulate the hardware. Where does the interpreter come in? Any code that tries to self modify or do a change of state (table lookup, indirect jumps, etc) with be interpreted. Sounds hard? You bet. The easier solution of all is to throw faster CPUs at the problem. Now for another question: Why doesn't AMAX multitask? It should be EASY to run multiple copies of the Mac ROM as a task (since its a rom, its mostly pure code, except each task would need to alter where the ROM things the system memory is.) For things like the Atari emulator, or another 68000 emulator, the compile technique should work great! Just recompile the parts of the code that bang on the hardware, or use an MMU to trap them. The whole compilation process is made easier when the machine your trying to emulate has an object code format that contains seperate data and code chunks, and perhaps some relocation data. Further more, if the machine has rules against self modifying code, and a device independent OS it becomes trivial. Could someone run SI or dhrystone on IBeM and tell me how it performs? Itis said that SoftPC on a Mac @25mhz 68030 runs at 6mhz AT speed. Does anyone know if IBM code uses self modifying code, or jump tables? What kind of code does their compilers produce? And, does the IBM has a special object code format that seperates code and data? The compilation technique could work well, but the compiler would have to be VERY smart in its flow analysis of detecting code/data, jump tables, self modifying code, PC counter and stack manipulation, etc. I'll clairfy my thoughts tommorow, it's going on 4:30am here, and I need to get some well deserved sleep. :-)
drysdale@cbmvax.commodore.com (Scott Drysdale) (03/08/91)
In article <stevek.3380@amiglynx.UUCP> stevek@amiglynx.UUCP (Steve K) writes: >The idea of a "translator compiler" is very interesting. I could have sworn I >saw some talk about a IBM->Atari ST translator that exists on FidoNET. But >why is everyone talking about IBM? Why not Macintosh programs? Though I am IBM to Atari ST ports should be relatively simple. the ST essentially runs CP/M 68K with several extensions, much like ms-dos. so low level calls will pretty much translate directly, and you only have to worry about access to hardware. >- Steve Krulewitz - Fair Lawn, NJ - --Scotty -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Scott Drysdale Software Engineer Commodore Amiga Inc. UUCP {allegra|burdvax|rutgers|ihnp4}!cbmvax!drysdale PHONE - yes. "Have you hugged your hog today?" =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Radagast@cup.portal.com (sullivan - segall) (03/08/91)
Even without self-modifying code, it can be very difficult to
separate code from data. I will often use functions that
have inline data (eg:
call Print
db "Hello World!",0
mov ax,4c00h
int 21h
or:
call Case
db 2
dw OFFSET default_sub
db 'A'
dw OFFSET case_a_sub
db 'B'
dw OFFSET case_b_sub
jmp loop
)
This sort of problem is impossible to resolve without an interpreter
running at the same time as the cross-compiler. By following the path
of the program, you might possibly find most of the code and data
segments, but it is quite easy to write a branch which will only be
taken one out of a million times. If the compiler assumes that the
conditional branch may or may not be taken in the future (ie: ignoring
the current processor state) it might very well find itself modifying
data rather than code. The branch may have been written conditionally
to take advantage of the relative addressing inherent in those
branches so that the code is relocatable on the fly. I think
you'd stand a better chance with a resourcer, and a cross compiler
allowing you to control the intermediate code, and correct any
obvious flaws, than with a one step process.
-klsifarqhar@sunb.mqcc.mq.oz.au (Ian Farquhar) (03/08/91)
In article <1991Mar6.212548.9641@mentorg.com> dclemans@mentorg.com (Dave Clemans @ APD x1292) writes: >To use it, you basically had to develop enough information to >get a clean disassembly of the Intel code; i.e., so that you "knew" >where all the code and data was in the source object file. >That then was used to drive the tool that produced the "compiled" >68K file. After that was done you had to go over the output >for correctness, system dependencies, etc.; it was not intended >as a turn key system. Well, on a 6502, it is practically impossible to truly decide what is code and what is data. Let's imagine that you are (as I have done), writing a 6502 disassembler. For every byte you store a status thst says DATA, OPCODE, ARGUMENT, and also non-exclusive flags (eg. BRANCHENTERSHERE, BRANCHISNOTHERE.) Initially, all bytes are set to DATA, and BRANCHISNOTHERE. Write a recursive procedure that starts at the program entry point, and goes through the code. For every byte read as an opcode, tag it as an OPCODE, and the bytes following as ARGUMENT. If you get to a branch instruction, recursively call the new branch point, and continue processing that until you hit a byte that has already been processed (ie. not tagged DATA.) You should continue until the whole procedure exits, then run the same thing on the RESET, INT and NMI vectors. Calls are treated the same way as branches, except that the routine exits to a higher level invocation when it hits a RET or RTI. Now, you should have all the data tagged as either program (OPCODE and ARGUMENT), or DATA. Right? Wrong. Why? Because the 6502 has no branch always instruction, and your program may continue past what appears to be a conditional branch, into data, and screw everything up completely. I experimented with using a two pass approach to this problem. First, the program was scanned sequentially, treating every byte as an opcode, and tagging every point referenced by some branch, call, jump or vector. Then, when a branch was found during the second recursive pass, the program would backtrack and examine every last opcode till it hit a branch in point (after which no assumptions could be made), to see if the flags were left in a deterministic state. At this point I lost interest in the whole idea. Anyway, on the 6502 and anything without a BRA or equivalent, the problem of automatically determining what is data and what is code is extremely difficult. However, on the 68K, this approach is probably quite profitable. Why? Because there is enough correspondence between the 6502 and 68K instructions sets (both having the same ancestor, the 6800) to mean that the compilation process is reasonably simple. Simulating the hardware is still a problem, and I'll have to give that one some thought... I still tend to favor the idea that I presented in a previous article, carrying around a compiled image (of code only), and uncompiled data with labels to the compiled code and handlers for the I/O locations. -- Ian Farquhar Phone : + 61 2 805-9400 Office of Computing Services Fax : + 61 2 805-7433 Macquarie University NSW 2109 Also : + 61 2 805-7420 Australia EMail : ifarqhar@suna.mqcc.mq.oz.au
rjc@pogo.ai.mit.edu (Ray Cromwell) (03/09/91)
Besides inline data, don't forget this old trick
lda choice
asl
tax
lda jumptable+1,x
pha
lda jumptable,x
pha
php
rti
Or what about this
entrypoint1 lda #data1
.byte 2c
entrypoint2 lda #data2
.byte 2c
entrypoint3 lda #data3
.byte 2c
etc,etc
2c is the 6502 instruction 'bit'. The operand to bit is a SHORT
pointing to an address. LDA # is 2 bytes long, so entering at
any point causes the following instructions to do nothing.
How are compilers supposed to be smart enough to recognize such
clever optimizations and translate them to their 68000 equivelent?
The 6502 could only address 64k, space savers like this were used all
the time. Then of course, there weren't any rules of how to call
the OS, so most 6502 programs would JUMP directly into rom at different
addresses depending on how much of the function they wanted to use.
I think compilers would do a much better job on 16bit micro's where
C is used. I don't know a single C compiler that generates self modifying
code, or 'do-nothing' instructions between opcodes to save
bytes whenentering functions.lron@easy.hiam.com (Dwight Hubbard) (03/09/91)
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) - ----------------------------------------------------------------------
cg@ami-cg.UUCP (Chris Gray) (03/09/91)
In article <1312@macuni.mqcc.mq.oz> ifarqhar@sunb.mqcc.mq.oz.au (Ian Farquhar) writes: [Discussion of using a recursive approach to run through all branches and calls to tag bytes as being code/data.] >However, on the 68K, this approach is probably quite profitable. Why? >Because there is enough correspondence between the 6502 and 68K >instructions sets (both having the same ancestor, the 6800) to mean that >the compilation process is reasonably simple. My Amiga disassembler, Dis (which is available somewhere or other; I believe I sent it out last year some time) does this. The thing it has troubles with are things like function variables. In writing disk-resident libraries, a lot of that is done, so it doesn't work too well on such things. It has special code to handle case/switch statements generated by several compilers, but an assembler program doing a branch table will usually mess it up. I don't think there is much hope of an automated translater. Perhaps some kind of interactive one, so that the user can aid in identifying what is code and what is data. -- Chris Gray alberta!ami-cg!cg or cg%ami-cg@scapa.cs.UAlberta.CA
finkel@TAURUS.BITNET (03/10/91)
as someone who wrote a 8085 emulator/disassembler/monitor for the C64 I would like to contribute my on thoughts on the subject. I have toyed the idea of writing an IBM PC program translator that would take an IBM program and 'translate' it to run on the amiga, but after careful examination of the idea I decided to drop it for a few reasons: 1. There is no way to find out at compile time which memory references are accessing special RAM areas such as the text/graphics video screen. 2. self modifying code breaks such schemes easily 3. code/data seperation can be tough. for example, it's very hard to detect if memory block contains code ( translate it) , data ( don't touch it) or worse - near or far pointers. (2) is rare, but (1) and (3) are common, so I guess many programs will break. even commercial systems claiming the ability to 'compile' PC binaries into UNIX programs such as XDOS (anyone heard of them lately??) aren't automatic. Instead, I decided to try concentating on the 'usual' type of emulators such as IBeM and Transofrmer. What caught my attention is that a large portion of the time an emulator is spending while emulating an instruction is to check whether a memory read/write accesses video memory. every address being written to memory must be checked whether it lies in the $BXXXXX range, and if it does, it should be written to the screen. What I really wanted to do if I had an MMU based machine is to write an emulator that will use the MMU to track such memory accesses. The emulator's memory will be referenced without translation, but every address in the range where the video memory is located will be caught by the MMU and special code will be run to handle it. This would speed things up. Udi
finkel@TAURUS.BITNET (03/10/91)
One important fact I forgot to mention is that an IBM emulator running on a 68020 or a 68030 based machines can safely use 16 bit arithmetic operation on memory operands on located on byte boundary addresses, unlike the 68000 which requires word and longword operands to be word aligned. since the 8088 instruction set allows word operands to be stored on byte alignment, emulating these instructions on a 68000 requires splitting the memory access to two seperate byte memory accesses or one longword memory access followed by a shift operand. Udi
ecarroll@maths.tcd.ie (Eddy Carroll) (03/10/91)
In article <4992@mindlink.UUCP> Chris_Johnsen@mindlink.UUCP (Chris Johnsen) writes: > > [ Interesting discussion about a new sort of PC emulator ] My final year project for college last year tackled exactly this problem, i.e. given a PC executable file, produce an Amiga executable file which will perform the same function. The end result worked, in a limited sort of way; it was fairly easy for it to be misled by any program of reasonable size. There are a few tricky problems that must be handled if you want to achieve a good degree of success: o Given the instruction MOV reg,VAL do you treat VAL as a constant value or as an offset to an address in one of the PC's segments? The 8086 uses the same opcode for both cases, and it is far from easy to work out which meaning to use. It's important to get it right because in the translated program, all the constant values should remain the same but address offsets will be different. o How do you handle jump tables? Most compilers implement switch/case statements with jump tables, but it is not always clear what the bounds of such tables are. o On the PC, byte values can be pushed onto the stack as byte values. On the 68000, you can only push word values. You can see why this might be a problem if you consider a function accessing a parameter at an offset of 8 from the stack pointer. If the preceding parameters were four words, then this is okay. If they were two words and four bytes however, then the offset on the 68000 needs to be 12 to access the same data. o Given that most major PC programs access the PC's video RAM directly for speed reasons, such accesses must be mapped to act equivalently on the Amiga. The problem is that the usual method for doing this is to set a segment register to point to the video RAM and then to access the RAM through this. The same register is likely used for for all sorts of other data access elsewhere in the program. Of course, there are other problems too. The main thing I discovered during the course of the project was that it's a lot harder to do translation than it might first seem. My program performs the translation in two passes. The first pass traces out all possible paths through the PC code, building up a symbol table and separating code from data as it goes. The second pass then walks sequentially through the code, producing 68K assembly source code for each line. Certain instructions generate macros instead of opcodes, which are later expanded to calls to library functions. The resulting source is fed into Charlie's A68K and then linked with a library that sets up a PC-like environment (custom screen, ibm.font etc.) and handles the INT calls. The result is a standalone executable file. If anyone else has a shot at it, I'd be interested in seeing how it turns out. Perhaps a more practical route to take is to produce a translator that can take reasonably well written PC source code (say, C or assembly) and automatically convert it to Amiga source code. If such a tool existed and worked well, it might encourage more companies to port their products to the Amiga. In the meantime, back to IBem. -- Eddy Carroll ----* Genuine MUD Wizard | "You haven't lived until ADSPnet: cbmuk!cbmuka!quartz!ecarroll | you've died in MUD!" Internet: ecarroll@maths.tcd.ie | -- Richard Bartle
ifarqhar@sunb.mqcc.mq.oz.au (Ian Farquhar) (03/10/91)
In article <2406@taurus.BITNET> finkel%math.tau.ac.il@CUNYVM.CUNY.EDU (Udi Finkelstein) writes: >as someone who wrote a 8085 emulator/disassembler/monitor for the C64 >I would like to contribute my on thoughts on the subject. A 8085 toolkit on a C64? The mind boggles. Why?! :-) >2. self modifying code breaks such schemes easily I have yet to see a piece of self-modifying code on an IBM PC, and it will cause problems on the many 386DX and 486 systems that have instruction caches without write-through. >What I really wanted to do if I had an MMU based machine is to write an >emulator that will use the MMU to track such memory accesses. The emulator's >memory will be referenced without translation, but every address in the range >where the video memory is located will be caught by the MMU and special code >will be run to handle it. This would speed things up. Check my article on using lots of memory to very quickly tag this occurence on non-PMMU systems, by vectoring every location to a handler. -- Ian Farquhar Phone : + 61 2 805-9400 Office of Computing Services Fax : + 61 2 805-7433 Macquarie University NSW 2109 Also : + 61 2 805-7420 Australia EMail : ifarqhar@suna.mqcc.mq.oz.au
wilker@descartes.math.purdue.edu (Clarence Wilkerson) (03/11/91)
On the subject of self modifying code, I can think of one place on the 80X8Y where it's tempting: INT X where X is a byte code for the interrupt number. Since there is no other mechanism to call a software interrupt, and any C-library for the PC supports calls like Intr( number, args), I suspect that self-modifying code is used. On the other hand, a case statement with 256 cases could be used .....
Chris_Johnsen@mindlink.UUCP (Chris Johnsen) (03/11/91)
What is the status of your program that translates or compiles executable IBM
binaries into 68000 assembly code? It sounded from your article that you were
not interested in pursuing this any further. If so, that's too bad. I've been
reading the postings on this subject and, as yet have not been moved to doubt
the viability of some form of translator/compiler. Would you be willing, for
the betterment of humanity, and for those inquiring minds that just want to
know, to release your program as a basis for further research in this quest?
I know that there are those that are more interested in compiler/translators
for various platform source executables other than the IBM, but you would help
any wishing to work in tangental directions with your source as well. By
inspecting your work closely others could greatly speed any development they
are entertaining.
For instance, Ray Cromwell (rjc@pogo.ai.mit.edu) writes:
Maybe we all should trying something like 'NetIBM'. What I mean, is like
Nethack, we should all participate in coding an IBM emulator. Each person might
post a small code segment (in assembler), the rest of us can compete optimize
it. I remember having a contest with some trying to optimize the 'size' of a
binary to decimal print routine, the final result was the code was reduced 300%
in size. (we kept passing the optimized source back and forth, each shedding a
few bytes.)
Please give this some thought. I, for one would be very interested in looking
over what you have thus far accomplished. Thanks for considering this idea.
A glass half filled with water is full; half with water, half with air.
Usenet: a542@mindlink.UUCP Phone: (604)853-5426 FAX: (604)854-8104daveh@cbmvax.commodore.com (Dave Haynie) (03/12/91)
In article <1991Mar7.093149.18707@mintaka.lcs.mit.edu> rjc@geech.ai.mit.edu (Ray Cromwell) writes: > Why doesn't AMAX multitask? It should be EASY to run multiple copies >of the Mac ROM as a task (since its a rom, its mostly pure code, except >each task would need to alter where the ROM things the system memory is.) Without massive patching of the Mac ROM, I don't think so. The same reason you don't have more sophisticated multitasking on the Mac itself. You can't run multiple copies of the same Mac ROM code, since the code is not reentrant like Amiga code. Without some clever MMU tricks, I don't think you could easily relocate things such that several different copies of the ROM code could coexist. At least, you would expect Apple to have considered any of the more mundane tricks available on any 680x0 system. Apple does seem to have] decent technical folks, I doubt they missed any easy tricks... Via MMU, you could certainly get further. Multifinder didn't do that, since it would have required an MMU based system for any multitasking. I'm surprised Apple didn't work out anything like that for their MacOS-under-UNIX, though. >Does anyone know if IBM code uses self modifying code, or >jump tables? Self modifying code and other uglies are very prevalent in MS-DOS code. That's the main reason Intel went for a unified code/data cache for the 80486. Separate I and D caches with internal Harvard architecture (like the '030 and '040) can yield a much faster system, all else being equal. But that extra performance would not have been worth tossing out what was apparently a large portion of the MS-DOS programs out there. MS-DOS programs, more and more often, think they're the operating system. Every program is responsible for managing differences between CPUs, managing memory (beyond the 8088 model), graphics, etc. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "What works for me might work for you" -Jimmy Buffett
rjc@geech.ai.mit.edu (Ray Cromwell) (03/12/91)
In article <19749@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >In article <1991Mar7.093149.18707@mintaka.lcs.mit.edu> rjc@geech.ai.mit.edu (Ray Cromwell) writes: > >> Why doesn't AMAX multitask? It should be EASY to run multiple copies >>of the Mac ROM as a task (since its a rom, its mostly pure code, except >>each task would need to alter where the ROM things the system memory is.) > >Without massive patching of the Mac ROM, I don't think so. The same reason >you don't have more sophisticated multitasking on the Mac itself. You can't >run multiple copies of the same Mac ROM code, since the code is not reentrant >like Amiga code. Without some clever MMU tricks, I don't think you could >easily relocate things such that several different copies of the ROM code >could coexist. At least, you would expect Apple to have considered any of >the more mundane tricks available on any 680x0 system. Apple does seem to have] >decent technical folks, I doubt they missed any easy tricks... > >Via MMU, you could certainly get further. Multifinder didn't do that, since >it would have required an MMU based system for any multitasking. I'm surprised >Apple didn't work out anything like that for their MacOS-under-UNIX, though. Well it's not a heavy loss if you can't make the Mac ROM resident, but why does AMAX have to take over the Amiga's operating system? The only thing that would make it really diffcult to run MacOS under AmigaDOS is if Mac code fiddles with absolute memory locations or the OS implements function calls as traps/interupts. I also wonder why readysoft used a special disformat for Mac disks instead of reading Amiga disks.
Radagast@cup.portal.com (sullivan - segall) (03/12/91)
Subject: mail failed, returning to sender Reference: <m0jFzQc-0000p8C@nova.unix.portal.com> |------------------------- Message log follows: -------------------------| |------------------------- Failed addresses follow: ---------------------| <amish.s.dave@midway.uchicago.edu> ... transport smtp: 550 <amish.s.dave@midwa y.uchicago.edu>... User unknown |------------------------- Message text follows: ------------------------| >Organization: University of Chicago >Cc: > >I have been reading this thread with a lot of interest - but have a few >questions regarding the separation of code and data. > >I don't quite understand why this is _absolutely_necessary. I thought that >this discussion started with the idea of simplifying things by using lots of >memory. Thus, my conception of the compiler/emulator goes something like: > >You keep the original .exe file, and maybe even an entire 640K memory map >in memory. The compiler generates 680x0 equivalent code for every instruction, >with every memory read or write referring to the contents of the ORIGINAL >map. If we agree not to worry about self-modifying code, the 680x0 code never >really has to be modified. It will contain a considerable amount of junk >corresponding to data, but then this stuff would never get executed in the >original, and so won't get executed here either. The problem here is that the compiler can easily get out of synch with the program. Suppose my source looks like: Call Print db "Hello World",LF,0 Call CheckErr Now if the object code is treated as all executable, there is no guarantee that the instruction pointer of the cross compiler will ever stop on the first byt of the "Call" instruction. If the address for CheckErr happens to correspond to some real opcode, the IP could stay out of synch for quite some time. If the next statement had been an RET instruction, you might miss and start executing completely irrelevant code. Of course when you execute the code, and find that the return address isn't among any of the symbolic addresses available, you might realize that something has gone awry, but by then it is too late to fix it. More importantly though what you gain in speed by compiling the code, is completely lost in searching for address translations in the executable. Unless you are willing to spend 4 megs memory just to translate addresses for each byte in the source code, every return address popped from the stack, every indexed jump, every vectored jump will have to be translated into the equivalent location in 68000 code. > >Of course, there would still need to be code to handle whether, say, video >ram was written to, or whatnot. I guess you could just add this code to >the code that replaces any instructions that write to memory. > >I'd appreciate being further enlightened on the mechanics of emulators... > >Amish (asd2@ellis.uchicago.edu) Video writes are relatively easy. At least in that case you know that the address contains data, and not executable (same goes for reads). Other problems also arise. Suppose I want to move a segment register to a normal register. In 68k code, the move first requires that the address register be shifted right four bits. (Intel segment registers lack the lower four bits, so moves are always shifted automatically when relocated from \@ a segment register to a data register.) The question the comes, what do you do if you aren't sure whether the source data is from a segment register or a data register. Suppose you push a segment register on the stack, and pop a data register. Obviously segment registers have to be shifted whenever they are moved to anything (other than another segment register.) Unfortunately in the Intel command set it is impossible to move data between segment registers, so moves through other registers or the stack are performed constantly. But if you keep the segment register right shifted normally, you then have to left shift every time the register is dereferenced. Which is worse? Okay, so you've solved all of these problems... Well there is at least one more reason to seperate code from data (and this is what most people will refer to.) You've translated the code because Intel code won't run on a Motorola chip. Unfortunately the same is true of Intel Data. xDIntel always stores the most significant byte of any operand first. Motorola always stores the least significant byte of any operand first. So if you really want to translate a program, the data should be translated as well. Next the question comes, how do you really know the size of any data. If a data location is referred to as a word then the contents of the first and second bytes should be swapped. If it is referred to as both word and byte, the data should be swapped and the byte reference should be changed to the other byte. But now how do you handle indexed or calculated references. You may not be able to find any references to the data point, and so be unable to determine its contents. But if you convert all of the data references, you are right back where you started, not executing 68k code. Instead each reference is interpreted and loaded or written a single byte at a time. r -Sullivan_-_Segall (a.k.a. Radagast) _______________________________________________________________ /V\ E-Credibility: (n -- ME) The unguaranteed likelyhood that ' the electronic mail you are reading is genuine rather than someone's made up crap. _______________________________________________________________ Mail to: ...sun!portal!cup.portal.com!radagast or radagast@cup.portal.com
JKT100@psuvm.psu.edu (JKT) (03/12/91)
>>> Why doesn't AMAX multitask? It should be EASY to run multiple copies >>>of the Mac ROM as a task (since its a rom, its mostly pure code...) Well, it's pure code that is not prepared to share ANY memory locations with other tasks... >>Without massive patching of the Mac ROM, I don't think so. The same reason >>you don't have more sophisticated multitasking on the Mac itself. You can't >>run multiple copies of the same Mac ROM code, since the code is not reentrant >>like Amiga code. Without some clever MMU tricks, I don't think you could >>easily relocate things such that several different copies of the ROM code >>could coexist. At least one person has posted here to c.s.a.? saying he's tried and nearly gotten working a Mac emulator that multitasked with AmigaDOS. Problem is, he sacrificed a LOT of compatibility and speed to do it. ie. What he ended up with wasn't very viable. >>Apple does seem to have decent technical folks, I doubt they missed >>any easy tricks... > >Well it's not a heavy loss if you can't make the Mac ROM resident, but >why does AMAX have to take over the Amiga's operating system? The only >thing that would make it really diffcult to run MacOS under >AmigaDOS is if Mac code fiddles with absolute memory locations or the >OS implements function calls as traps/interupts. Mac OS code does a LOT of stuff that would be considered illegal in Amiga code. But can you blame it? It was designed under the assumption that it owned the machine; and on any real Mac it does. It *is* the operating system, after all! ;-) >I also wonder why readysoft used a special disformat for Mac disks >instead of reading Amiga disks. ReadySoft did a lot of things that may seem strange, but they did them in the name of speed and compatibility. With the disks, you have to understand that the Mac uses a mighty strange disk format. Mac drives are even variable speed. ReadySoft created a special disk format for compatiblity with disk I/O routines that expected a Mac floppy. And I congratulate ReadySoft on their achievement. I have been able to sector-edit A-Max format floppies and run Norton Utilities on them, all without ANY problem. Kudos!! Kurt -- ----------------------------------------------------------------------- || Kurt Tappe (215) 363-9485 || With. Without. And who'll || || 184 W. Valley Hill Rd. || deny it's what the fighting's || || Malvern, PA 19355-2214 || all about? - Pink Floyd || || jkt100@psuvm.psu.edu --------------------------------------|| || jkt100@psuvm.bitnet jkt100%psuvm.bitnet@psuvax1 QLink: KurtTappe || -----------------------------------------------------------------------
daveh@cbmvax.commodore.com (Dave Haynie) (03/13/91)
In article <1991Mar12.011418.24768@mintaka.lcs.mit.edu> rjc@geech.ai.mit.edu (Ray Cromwell) writes: >In article <19749@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>In article <1991Mar7.093149.18707@mintaka.lcs.mit.edu> rjc@geech.ai.mit.edu (Ray Cromwell) writes: >>> Why doesn't AMAX multitask? >>Without massive patching of the Mac ROM, I don't think so. > Well it's not a heavy loss if you can't make the Mac ROM resident, but >why does AMAX have to take over the Amiga's operating system? The only >thing that would make it really diffcult to run MacOS under >AmigaDOS is if Mac code fiddles with absolute memory locations or the >OS implements function calls as traps/interupts. Well, the Mac OS fiddles with absolute memory locations, and the OS implements function calls as line-A exceptions. Apparently, all the absolute locations are in low memory and get swapped as part of the process context when you run Multifinder. >I also wonder why readysoft used a special disformat for Mac disks >instead of reading Amiga disks. No doubt this was to make Mac software work on Amiga disks. The Mac isn't as nice about filesystem independence as the Amiga is, so you can't really provide a loadable Mac filesystem kind of thing that maps Mac filespace into Amiga filespace adequately. So ReadySoft essentially just built a new device driver, which uses Amiga-readable formats, but Mac filesystem organization. This is apparently why Mac's don't generally talk to MS-DOS disks via an alternate filesystem like CrossDOS or MSH, but instead use a user program for the conversion, along the lines of the old PC Utilities. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "What works for me might work for you" -Jimmy Buffett
eachus@aries.mitre.org (Robert I. Eachus) (03/13/91)
A couple of shortcuts which may make things a lot easier (if
anyone really wants to do another 8088 emulator, going for speed at
the cost of memory. (Why not! I have 9 Meg. :-)
First allocate emulated code memory as a 4*640K (or smaller)
array of FAST memory, keeping the original Intel image in another 640K
array. Write a call to the emulator/translator (ET) routine on every
8 byte boundary (corresponding to every 16-bit boundary in the Intel
image) in the emulation memory padded with NOPs if needed. When an
Intel instruction is to be executed, branch to the location (relative
to the base of the array) times four.
If this results in a call to the ET routine it will look at the
stack to get the right address, then look at the the Intel image to
figure out what to do. For instructions which can be translated into
a four word 68K sequence (possibly including NOPs and or branches)
write the code over the call, otherwise put in a branch or call to an
out of line routine. Keep data in the Intel image, doing byte swaps
when loading where necessary. (Rememeber, do this right and the SWABs
will be no cost in most cases.) Stores should automatically overwrite
the corresponding emulator location with a call to ET. (Remember to
map the overwrites for byte writes to the correct word.)
With a strategy like this (and unfortunately, both data and
instruction caches off), I think you could get a 25MHz 68030 well
above XT speed if you do a good job of coding the ROM emulation...
Robert I. Eachus
"The liberty of the press is not confined to newspapers and periodicals.
It necessarily embraces pamphlets and leaflets....The press in its
historical connotation comprehends every sort of publication which
affords a vehicle of information and opinion."
--Lowell v. City of Griffin, 303 U.S. 444, 452 (1938)
--
Robert I. Eachus
"As far as Saddam Hussein being a great military strategist, he
is neither a strategist, nor is he schooled in the operational arts,
nor is he a tactician, nor is he a general, nor is he as a
soldier...
Other than that he's a great military man. I want you to know that."
-- Gen. H. Norman Schwarzkopf, Saudia Arabia, Feb. 27, 1991 jcav@quads.uchicago.edu (john cavallino) (03/13/91)
In article <19792@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>I also wonder why readysoft used a special disformat for Mac disks >>instead of reading Amiga disks. > >No doubt this was to make Mac software work on Amiga disks. The Mac isn't >as nice about filesystem independence as the Amiga is, so you can't really >provide a loadable Mac filesystem kind of thing that maps Mac filespace >into Amiga filespace adequately. So ReadySoft essentially just built a new >device driver, which uses Amiga-readable formats, but Mac filesystem >organization. > >This is apparently why Mac's don't generally talk to MS-DOS disks via an >alternate filesystem like CrossDOS or MSH, but instead use a user program for >the conversion, along the lines of the old PC Utilities. Actually, the Macintosh OS has always supported installable external filesystems. Apple's AppleShare network fileserver client software is such a beast. So is Dayna's DOS Mounter, which, contrary to the above statement, lets MS-DOS disk volumes appear like any others on the Finder desktop and within application programs (although I believe it requires the 1.44mb Superdrive to be present). The "user programs" (such as Apple File Exchange) of which you speak tend to be intended more for supporting the conversion between different file formats (MS-DOS WordPerfect 5.1<->Mac MS Word 4.0, etc.), as opposed to different filesystems, although they do that also. -- John Cavallino | EMail: jcav@midway.uchicago.edu University of Chicago Hospitals | USMail: 5841 S. Maryland Ave, Box 145 Office of Facilities Management | Chicago, IL 60637 "Opinions, my boy. Just opinions" | Telephone: 312-702-6900
khl@doc.ic.ac.uk (Kang Ho Lee) (03/14/91)
In article <19792@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >This is apparently why Mac's don't generally talk to MS-DOS disks via an >alternate filesystem like CrossDOS or MSH, but instead use a user program for >the conversion, along the lines of the old PC Utilities. I think it's possible to get something equivalent for the Mac. One of them is called DOSMounter. Apparently, it will even map PC file extension to Mac applications, eg PC Microsoft-word file to Mac MSWord... >Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy > "What works for me might work for you" -Jimmy Buffett -- Kang Ho LEE email : khl@doc.ic.ac.uk Department of Computing address: 180 Queens Gate Imperial College London SW7 2BZ, UK
daveh@cbmvax.commodore.com (Dave Haynie) (03/15/91)
In article <45551@ut-emx.uucp> awessels@ccwf.cc.utexas.edu (Allen Wessels) writes: >In article <19792@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>This is apparently why Mac's don't generally talk to MS-DOS disks via an >>alternate filesystem like CrossDOS or MSH, but instead use a user program for >>the conversion, along the lines of the old PC Utilities. >Well, I don't really know what a "filesystem" is, Well, that's exactly what a filesystem is. In the normal AmigaOS or UNIX usage, the filesystem is the program that determines the logical format of files, directories, etc. out on the disk. In most cases, underneath the filesystem is a device driver, which knows about the specific piece of hardware you have your files mounted on. >but there are a couple of programs (INITs) that let you mount DOS disks >directly to the desktop. I guess my mistake was asking about these things in Mac groups, rather than here in an Amiga group. I'm actually after something like this for the Mac I use in the lab. This Mac is an integral part of a logic analyzer setup we have here. And it can dump nice, detailed timing results to disk. The problem is that I currently have no reasonable way to get data into and out of this Mac, other than via floppy. Everything in engineering speaks Ethernet, even a few of the PCs, but I haven't convinced anyone to spring for a Mac Ethernet card, and wouldn't really no where to begin looking for one. But a standard filesystem of some kind, something that can be read by the Mac and the Amiga, would be one solution. Something like CrossDOS or MSH for the Mac would be perfect. >(By the way, Dave, I'm really impressed with the support you provide here.) Well, someone's got to support these things. C= doesn't manage the level of marketing that Apple does, so I figure a little extra on the technical side, at least when I have time, is a good idea. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "What works for me might work for you" -Jimmy Buffett
JKT100@psuvm.psu.edu (JKT) (03/15/91)
In article <10924@dog.ee.lbl.gov>, jnmoyne@lbl.gov (Jean-Noel MOYNE) says: >> >> >>> Why doesn't AMAX multitask? >> >Just guess why it takes so much to Apple to get system 7.0 (multitasking) >out. As for A/UX it works the sameway the multifinder works, and since it >runs only on machines with a MMU.... Unless Apple has one helluva trick up its sleeve and is working on multitasking that it is not shipping in its Beta versions of 7.0, the common assumption that 7.0 will multitask is appearing to be false. Our company is a registered Apple developer, and as such we get all the 7.0 Beta CD's from Apple. We've seen 7.0 to date, and to Apple's credit, it looks quite nice. It is to Apple's previous OS's what AmiDOS 2.0 is to 1.3. But the 7.0 we've seen simply has Multifinder built-in; it is still TASK-SWITCHING like the current Mac OS. It is cleaner, smoother, easier to use, less noticable task-switching, but it is still not multitasking in the sense that Amiga owners are used to. Kurt -- ----------------------------------------------------------------------- || Kurt Tappe (215) 363-9485 || With. Without. And who'll || || 184 W. Valley Hill Rd. || deny it's what the fighting's || || Malvern, PA 19355-2214 || all about? - Pink Floyd || || jkt100@psuvm.psu.edu --------------------------------------|| || jkt100@psuvm.bitnet jkt100%psuvm.bitnet@psuvax1 QLink: KurtTappe || -----------------------------------------------------------------------
awessels@ccwf.cc.utexas.edu (Allen Wessels) (03/16/91)
In article <19886@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >of this Mac, other than via floppy. Everything in engineering speaks Ethernet, >even a few of the PCs, but I haven't convinced anyone to spring for a Mac >Ethernet card, and wouldn't really no where to begin looking for one. But a Try MacAvenue at 1-800-395-6221 for Ethernet cards (I don't know which Mac model you have.) They are a mail-order firm and are a subsidiary of CompuAdd, so they might know a little more about Mac-PC connectivity than most. >standard filesystem of some kind, something that can be read by the Mac and >the Amiga, would be one solution. Something like CrossDOS or MSH for the Mac >would be perfect. MacWarehouse at 1-800-255-6227 has DOSMount for $55, and Access PC for $65. Both programs will mount DOS disks on SuperDrive (1.44 meg floppy) equipped Macs.
billy@phoenix.pub.uu.oz.au (Jeff Coleman) (03/17/91)
In <stevek.3380@amiglynx.UUCP> stevek@amiglynx.UUCP (Steve K) writes: >why is everyone talking about IBM? Why not Macintosh programs? Though I am >not anyting close to a professional programmer, I'd imagine programs that run >off different computers with the same processor would share some op-codes, >right? Even if that is not true, they do both have similar GUIs, windows, >gadgets, and menu bars, ect. which shold make the translation easier and more >like the original. I sincerly hope someone will pick up and persue these >ideas, it would be very benificial for me and others - I'd love to run a nice >pascal compiler like Turbo Pascal, and an excellent ANSI editor like TheDraw! >- Steve Krulewitz - Fair Lawn, NJ - granted that the mac and amy both run on 68k bases wouldn't there be a major problem with the fact that the mac rom contains a lot of the definitions for gui's etc and therefore even if u could re-engineer the code u would still need to support the calls to the rom..which i IMAGINE is why readysoft have to use the roms for their amax package. jeff. <-----------------------------------------------------------------------------> Jeff Coleman billy@phoenix.pub.uu.oz.au ..!uunet!munnari.oz!phoenix.pub.uu.oz.au!billy <----------------------------------------------------------------------------->
BAXTER_A@wehi.dn.mu.oz (04/01/91)
> >>I also wonder why readysoft used a special disformat for Mac disks >>instead of reading Amiga disks. > > ReadySoft did a lot of things that may seem strange, but they did > them in the name of speed and compatibility. With the disks, you > have to understand that the Mac uses a mighty strange disk format. > Mac drives are even variable speed. ReadySoft created a special > disk format for compatiblity with disk I/O routines that expected > a Mac floppy. And I congratulate ReadySoft on their achievement. > I have been able to sector-edit A-Max format floppies and run > Norton Utilities on them, all without ANY problem. Kudos!! > > Kurt I't isn't really a special format. It's just ignoring the format. The AMiga drive does its best with the signals it gets. It can't change speeds, so it doesn't. No smart file system, no tricky program, just nice quick, clean, BODGE! Regards Alan