Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!INGRES.BERKELEY.EDU!hatcher From: hatcher@INGRES.BERKELEY.EDU (Doug Merritt) Newsgroups: comp.sys.amiga Subject: Re: Some thoughts and questions about the Ranger Message-ID: <8703082031.AA05316@ingres.Berkeley.EDU> Date: Sun, 8-Mar-87 15:31:54 EST Article-I.D.: ingres.8703082031.AA05316 Posted: Sun Mar 8 15:31:54 1987 Date-Received: Mon, 9-Mar-87 04:07:20 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: University of California at Berkeley Lines: 44 In article <1513@cbmvax.cbmvax.cbm.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >>[6502 emulation] might be possible, however it is often a mistake to assume >>that the predecessor is so that you can emulate it in >>software in real time. The 6502 is still a fast microprocessor, In article <2725@well.UUCP> The Guy in the Cape writes: > Really? You think so? The fastest I've ever seen those things >commercially is 2 MHz. The C-64 runs at (slightly less than) 1 MHz. After >moving to the 68K, the very THOUGHT of going back to the 6502 makes me gag. 68000 versus 6502 wars is not the point here. George Robbins is telling the gospel truth; it is hard to do real time processor emulations, even if the processor in question is one you don't like. >>munching 8-bit data, and the VIC chip is a pretty tricky little gadget >It's tricky because of all the design barfs made on it. Granted, if Again, the fact that you don't like it does NOT make it easy to emulate in real time. The fact that your 68K clock speed is about 7-8 times that of the 6502 does not necessarily make the 68K run 7-8 times faster than the 6502. Almost certainly not, as a matter of fact. By comparison with the 68K, the 6502 is sort of a RISC processor. Its code density is better for the kinds of things it does well. Its code density is very poor on the things that 68000's do, but that's not the point in an emulation. The authors of Sargon claim that Sargon runs faster on 6502 than on 68000s. This may be biased, but I find it easy to believe. The problem is that everybody thinks that a high clock speed means a linear increase in speed. Very far from the truth. Read comp.arch for a while. People also think that more powerful instructions mean a faster processor. Sometimes true, but more often not (hence the idea of RISC). People further think that a machine with 32 bit pointers will run faster than one with 16 bit. Definitely the opposite of the truth, all else being equal; each indirection must fetch twice as much data before it can do the same operation. As George said, it might be possible. But don't blithely assume that it *has* to be possible; it might not be. There's a lot of confusion surrounding architectural and performance issues, so I'm probably inviting flames here. Fine, do it by email. I have a fair amount of professional experience with design and implementation of both instruction set architectures and compilers. So while I may be wrong, I am *very* sure of my opinions :-) Doug