macdonaldk@watt.ccs.tuns.ca (04/21/91)
re: emulation of a C64 on an IBM-PC. To explain why an IBM cannot emulate a C64, it would be good to identify features unique to the C64: The C64 supports three voice sound with 16 volume levels. Filtering, modulation and ADSR volume shaping are also supported. The C64 also supports eight sprites, which are small 21x24 pixel bit planes which may be placed anywhere on the screen. Collision detection with other sprites and background is supported. The IBM PC supports sound clicks and thus cannot emulate the C64's sound capabilities. My guess is that sprite and collision detection cannot be efficiently emulated through software, which is the only way possible with an IBM PC. The C64 was designed for arcade games; the PC wasn't!
rreiner@yunexus.YorkU.CA (Richard Reiner) (04/22/91)
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? //richard
c60b-1eq@e260-1e.berkeley.edu (Noam Mendelson) (04/22/91)
In article <22498@yunexus.YorkU.CA> rreiner@yunexus.YorkU.CA (Richard Reiner) writes: >>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 know this is a bit off the track but that statement is simply wrong. Comparing a 386-33 to a C64 using dhrystones is ridiculous, considering the difference between the processor capabilities. Besides, in my experience a C64 managed only 6 dhrystones/sec :-) -- +==========================================================================+ | Noam Mendelson ..!ucbvax!web!c60b-1eq | "I haven't lost my mind, | | c60b-1eq@web.Berkeley.EDU | it's backed up on tape | | University of California at Berkeley | somewhere." |
jerry@polygen.uucp (Jerry Shekhel) (04/26/91)
<1991Apr21.041312.1@watt.ccs.tuns.ca> macdonaldk@watt.ccs.tuns.ca writes: > >The C64 supports three voice sound with 16 volume levels. Filtering, >modulation and ADSR volume shaping are also supported. > OK, so forget sound, at least on PC's without sound cards. > >The C64 also supports eight sprites, which are small 21x24 pixel bit planes >which may be placed anywhere on the screen. Collision detection with other >sprites and background is supported. > Ah, but this CAN be done! The C64's hardware detects access to certain memory locations and performs special functions based on that. Well, the 386 has debug registers that can be used for this purpose. Consider the DOS-in-a-window that Microsoft Windows provides. It traps writes to the video area and draws in a window what the graphics card would display on the full screen. A full-speed C64 emulator might require a 386 and be a sophisticated piece of software, but it is possible, IMHO. > >The C64 was designed for arcade games; the PC wasn't! > Tell that to the makers of Wing Commander :-) -- +-------------------+----------------------+---------------------------------+ | JERRY J. SHEKHEL | POLYGEN CORPORATION | When I was young, I had to walk | | Drummers do it... | Waltham, MA USA | to school and back every day -- | | ... In rhythm! | (617) 890-2175 | 20 miles, uphill both ways. | +-------------------+----------------------+---------------------------------+ | ...! [ princeton mit-eddie bu sunne ] !polygen!jerry | | jerry@polygen.com | +----------------------------------------------------------------------------+
rreiner@yunexus.YorkU.CA (Richard Reiner) (04/28/91)
c60b-1eq@e260-1e.berkeley.edu (Noam Mendelson) writes: >In article <22498@yunexus.YorkU.CA> rreiner@yunexus.YorkU.CA (Richard Reiner) writes: >>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 know this is a bit off the track but that statement is simply wrong. >Comparing a 386-33 to a C64 using dhrystones is ridiculous, considering >the difference between the processor capabilities. The Dhrystone benchmark is *intended* for the comparison of different processors, and even processors of different architectures. The introduction of the documentation packaged with the Dhrystone 2.1 source reads, in part, it gives a first performance indication which is more meaningful than MIPS numbers which, in their literal meaning (million instructions per second), cannot be used across different instruction sets (e.g. RISC vs. CISC). Now, the comparison of an i386 to a 6502 in integer and logic performance alone (i.e. in what Dhrystone measures) may be ridiculous, since this omits the more sophisticated capabilities of the i386 (memory management, etc), but my statement about the relative performance of the two processors is not wrong: it does *not* constitute a misuse of the benchmark, and *does* give a perfectly reasonable estimate of how much faster an i386 can be expected to perform logic and integer ops. There are so many benchmarks around that extreme care must be exercised in interpreting them correctly. Careless statements, like the one above claiming that my comparison is "wrong," only contribute to the confusion. //richard
c60b-1eq@e260-1g.berkeley.edu (Noam Mendelson) (04/30/91)
In article <22590@yunexus.YorkU.CA> rreiner@yunexus.YorkU.CA (Richard Reiner) writes: >c60b-1eq@e260-1e.berkeley.edu (Noam Mendelson) writes: >>Comparing a 386-33 to a C64 using dhrystones is ridiculous, considering >>the difference between the processor capabilities. >Now, the comparison of an i386 to a 6502 in integer and logic >performance alone (i.e. in what Dhrystone measures) may be ridiculous, >since this omits the more sophisticated capabilities of the i386 >(memory management, etc), but my statement about the relative >performance of the two processors is not wrong: You have it reversed; the Dhrystone includes the more sophisticated capabilities of the i386 unintentionally. If a cache is present, the benchmark will be skewed considerably. Not to mention that the 386 has more registers than the 6502 (register variables will tend to dramatically improve the results of the benchmark). Also, an average 386 machine will have much faster on-board memory, thereby reducing the delay when instructions must be fetched from memory. >There are so many benchmarks around that extreme care must be >exercised in interpreting them correctly. Careless statements, like >the one above claiming that my comparison is "wrong," only contribute >to the confusion. Agreed. Extreme care must be exercised in interpreting them. In most cases additional tests using other benchmarks are very helpful and tend to clear up the confusion caused by assertions based on insufficient data. -- +==========================================================================+ | Noam Mendelson ..!ucbvax!web!c60b-1eq | "I haven't lost my mind, | | c60b-1eq@web.Berkeley.EDU | it's backed up on tape | | University of California at Berkeley | somewhere." |
terra@diku.dk (Morten Welinder) (05/01/91)
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
rreiner@yunexus.YorkU.CA (Richard Reiner) (05/02/91)
c60b-1eq@e260-1g.berkeley.edu (Noam Mendelson) writes: >You have it reversed; the Dhrystone includes the more sophisticated >capabilities of the i386 unintentionally. If a cache is present, >the benchmark will be skewed considerably. No, this is not skew, it is data. If the 386 resides on a system board with cache or burst-mode support or whatever, this all contributes to that system's ability to emulate the c64 system rapidly. If you recall, the original question was whether a "PC," meaning a system with an Intel *86 processor, could emulate the video features of the c64 at a reasonable speed. Again, the Dhyrstone is intended as a measure of *system* performance (including compiler capabilities), so use of it to compare the performance of a system incorporating a 386, cache, and whatever else, to another system, in this case the c64, is perfectly legitimate, nd the numbers it yields, while by no means the final word, are not "skewed" by the very system capabilities they measure. R.