Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!fernwood!uupsi!sunic!dkuug!diku!terra
From: terra@diku.dk (Morten Welinder)
Newsgroups: comp.sys.ibm.pc.hardware
Subject: Re: C64 emulation.
Message-ID: <1991May1.094306.10084@odin.diku.dk>
Date: 1 May 91 09:43:06 GMT
References: <1991Apr21.041312.1@watt.ccs.tuns.ca> <22498@yunexus.YorkU.CA>
Sender: terra@rimfaxe.diku.dk
Organization: Department of Computer Science, U of Copenhagen
Lines: 34

rreiner@yunexus.YorkU.CA (Richard Reiner) writes:

>macdonaldk@watt.ccs.tuns.ca writes:

>>re: emulation of a C64 on an IBM-PC.

>>My guess is that sprite and collision detection cannot be efficiently emulated
>>through software, which is the only way possible with an IBM PC.

>On the other hand, the C64 can do 36 dhrystones/sec (according to the
>machine rankings included with the dhrystone benchmark source), while
>a cached 386-33 does a best-case 13500 dhrystones/sec (according to my
>own measurements: dhrystone 2.0 compiled with MS C 5.1, generating
>286-specific instructions, using the register option).  Thus a 386-33
>is 375 times as fast as a C64.

>I think this means that a cached 386-33 can emulate the video features
>of a C64 at full speed.  At least.  But why would you want to?

You are surely well aware that a factor 375 tells you, that you are meassuring
something way from "performance". Please don't flame me for this statement;
Arguments over the true nature of performance are irrelevant here.

Some communiation experiments using a 386SX at 20MHz shows, that the c64 has to be
slowed with a factor 3 (t-h-r-e-e) in order for the pc to keep up.

This factor was found using hand-optimized machine code on both machines. The pc had
to do significantly more due to the protocol used.

These results suggest that the relative performance without arithmetic is
somewhere near 1:10 (c64:pc)

Morten Welinder
terra@rimfaxe.diku.dk