calhoun@cis.ohio-state.edu (robert r calhoun) (03/30/89)
Being an engineering senior at OSU, my brother has been picking my brain. He wanted me to rig a Seagate compatible hard drive expansion for his C64, This has taken some time and effort, but finally paid off. While I was researching the 6502, I came across a 65C02 which is a CMOS 4MHZ version of the 6502. I noticed also that there is a 65C802. From what I know, this appears to be an Advanced CMOS 8MHZ processor. He now wants me to rearrange his C64 to use the fastest 65??02 I can find. If the 65C802 is truly an 8MHZ processor I calculate that he will need 100ns memory chips. I don't recall seeing 64k 100ns chips so I guess I'll have to make it accept 256's. (whether or not to have it access all of that I haven't decided.) With this idea, I would like to know if there is a faster C64 video chip so that I won't have to continuously write a copy of video ram to the old 150ns RAM. The wait states would be too harsh to consider. Anyone who has tried any of these, I would greatly appreciate learning from your experiences and mistakes.
daveh@cbmvax.UUCP (Dave Haynie) (03/31/89)
in article <41063@tut.cis.ohio-state.edu>, calhoun@cis.ohio-state.edu (robert r calhoun) says: > While I was researching the 6502, I came across a 65C02 which is a > CMOS 4MHZ version of the 6502. I noticed also that there is a 65C802. > From what I know, this appears to be an Advanced CMOS 8MHZ processor. Sounds like you've been reading GTE databooks. One caution -- don't believe everything you read. While these databooks often show the timing for parts in a wide variety of speeds, that doesn't necessarily mean that such parts are actually available. Last time I looked, GTE listed 65C02s up to 4MHz and 65C802s and 65C816s up to 8MHz, though they only had 4MHz versions of the latter, and no real yield on the former at 4MHz (they probably have the 4MHz 65C02s by now...). > He now wants me to rearrange his C64 to use the fastest 65??02 I can > find. If the 65C802 is truly an 8MHZ processor I calculate that he > will need 100ns memory chips. I don't recall seeing 64k 100ns chips > so I guess I'll have to make it accept 256's. Someone currently sells a little accelerator for the C64 that plugs into the cartridge port and runs up to 4MHz (check the C64 magazines). You can't run at 8MHz using dynamic RAM; 100ns is just the RAS access time. A minimum cycle time for such a part is 180ns. Also consider that, even though the cycle time of an 8MHz part (which you probably can't get anyway) is 125ns, you can only use a fraction of that time for your memory access. There's a wait for addresses to be valid (probably around 1/4 or so of the cycle), and a setup time for data to be valid before the processor clocks it in. Not to mention any external logic needed to multiplex the address lines from the CPU to the DRAM and for decoding. The 4MHz C64 add-ons use static RAM, probably 100ns parts. Note also that since the C64 uses a 6510, which has an on-chip I/O port, you'll have to come up with some way of emulating that port. > With this idea, I would like to know if there is > a faster C64 video chip so that I won't have to continuously write > a copy of video ram to the old 150ns RAM. The wait states would be > too harsh to consider. Anyone who has tried any of these, I would > greatly appreciate learning from your experiences and mistakes. There are no faster VIC chips. You'll have to come up with some clever scheme to make this work correctly. I'm not exactly sure what the folks who make these accelerators do, but there are options. One option would be to make like an Apple II GS. Whenever your fast CPU writes to memory, you slow down to 1.02MHz and write to both normal C64 memory and your fast static RAM. Same thing happens for read or write of I/O devices. For straight memory reads, you can read full speed from your static RAM. Needless to say, this isn't a one-afternoon project. Such an accelerator is going to require some clever hardware design. Once it's done, you'll no doubt learn about "software timing loops" when a good portion of the C64 programs you have don't run properly. Folks are selling these accelerators for more that the cost of a C64; much of that selling price is the cleverness you're buying. -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
A-N-Onymouse@cup.portal.com (John - DeBert) (04/01/89)
In article <6460@cbmvax.UUCP> daveh@cbmvax.UUCP writes: >in article <41063@tut.cis.ohio-state.edu>, calhoun@cis.ohio-state.edu (robert r calhoun) says: > >> While I was researching the 6502, I came across a 65C02 which is a >> CMOS 4MHZ version of the 6502. I noticed also that there is a 65C802. >> From what I know, this appears to be an Advanced CMOS 8MHZ processor. There are some books out about programming the 65C802/65C816. > >Sounds like you've been reading GTE databooks. One caution -- don't believe >everything you read. While these databooks often show the timing for parts >in a wide variety of speeds, that doesn't necessarily mean that such parts >are actually available. Last time I looked, GTE listed 65C02s up to 4MHz and >65C802s and 65C816s up to 8MHz, though they only had 4MHz versions of the >latter, and no real yield on the former at 4MHz (they probably have the >4MHz 65C02s by now...). Hmm. I have before me a copy of a data sheet for the WD65C816/65C802 that specifies a version of the device with an 8MHz clock. It's >NOT< a preliminary data sheet. > >> He now wants me to rearrange his C64 to use the fastest 65??02 I can >> find. If the 65C802 is truly an 8MHZ processor I calculate that he >> will need 100ns memory chips. I don't recall seeing 64k 100ns chips >> so I guess I'll have to make it accept 256's. > >Someone currently sells a little accelerator for the C64 that plugs into >the cartridge port and runs up to 4MHz (check the C64 magazines). You can't >run at 8MHz using dynamic RAM; 100ns is just the RAS access time. A minimum >cycle time for such a part is 180ns. Also consider that, even though the >cycle time of an 8MHz part (which you probably can't get anyway) is 125ns, >you can only use a fraction of that time for your memory access. There's >a wait for addresses to be valid (probably around 1/4 or so of the cycle), >and a setup time for data to be valid before the processor clocks it in. Not >to mention any external logic needed to multiplex the address lines from the >CPU to the DRAM and for decoding. The 4MHz C64 add-ons use static RAM, >probably 100ns parts. Note also that since the C64 uses a 6510, which has >an on-chip I/O port, you'll have to come up with some way of emulating that >port. 8MHz is too fast for DRAM? Shhh! Don't tell my HP! It has DRAM and an 8MHz clock. Plus a faster one for the alphagraphics display. :) Seriously, one wonders how one may get DRAM to work with those so-called turbo clones with clocks of at least 8MHz. Also, I have seen 70ns DRAMS advertised from time to time. > >> With this idea, I would like to know if there is >> a faster C64 video chip so that I won't have to continuously write >> a copy of video ram to the old 150ns RAM. The wait states would be >> too harsh to consider. Anyone who has tried any of these, I would >> greatly appreciate learning from your experiences and mistakes. > >There are no faster VIC chips. You'll have to come up with some clever >scheme to make this work correctly. I'm not exactly sure what the folks >who make these accelerators do, but there are options. One option would >be to make like an Apple II GS. Whenever your fast CPU writes to memory, >you slow down to 1.02MHz and write to both normal C64 memory and your fast >static RAM. Same thing happens for read or write of I/O devices. For >straight memory reads, you can read full speed from your static RAM. > >Needless to say, this isn't a one-afternoon project. Such an accelerator >is going to require some clever hardware design. Once it's done, you'll >no doubt learn about "software timing loops" when a good portion of the >C64 programs you have don't run properly. Folks are selling these accelerators >for more that the cost of a C64; much of that selling price is the cleverness >you're buying. I doubt that it would be worth the trouble and expense to modify the C64 for "turbo speed" using the 65C802. There would need to be drastic changes in bus timing and how interrupts were handled. After you're done with the mods, you'll probably never be able to put the thing back in a C64 case. Even if you just wanted to do a straight replacement of the 6510, there's still the problem of how to implement the i/o port but that's not really too hard. Ah, well. Now that we've knocked your idea and all, perhaps you'll prove us all wrong? :) >-- >Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy > Amiga -- It's not just a job, it's an obsession J. DeBert A-N-Onymouse@cup.portal.com also: ...!sun!amdahl!dlb!netcom!onymouse CI$: 75530,347 GEnie: A.N.Onymouse Telex: 6502636614 paper snail -oops, I mean mail: Box 51754 Pacific Grove, CA 93950-6754
elg@killer.Dallas.TX.US (Eric Green) (04/02/89)
in article <16510@cup.portal.com>, A-N-Onymouse@cup.portal.com (John - DeBert) says: $ In article <6460@cbmvax.UUCP> daveh@cbmvax.UUCP writes: $>can't run at 8MHz using dynamic RAM; 100ns is just the RAS access $> time. A minimum $>cycle time for such a part is 180ns. Also consider that, even though the $>cycle time of an 8MHz part (which you probably can't get anyway) is 125ns, $>you can only use a fraction of that time for your memory access. $>CPU to the DRAM and for decoding. The 4MHz C64 add-ons use static RAM, $>probably 100ns parts. Note also that since the C64 uses a 6510, which has $ 8MHz is too fast for DRAM? Shhh! Don't tell my HP! It has DRAM and an 8MHz $ clock. Plus a faster one for the alphagraphics display. :) $ Seriously, one wonders how one may get DRAM to work with those so-called $ turbo clones with clocks of at least 8MHz. $ Also, I have seen 70ns DRAMS advertised from time to time. The 8080sux emulates the bus cycles of it's 8080 ancestory, which is identical to the bus cycle of the Z-80 which we previously discussed. An 8080sux takes 4 clock cycles to read a byte from the bus. The 6502, 65c02, etc. take 1 clock cycle. Thus a 8 mhz 6502 would be the equivalent of a 32mhz 8086-based machine. Considering that 80x6-based machines are having trouble getting RAM fast enough to run at 25mhz (they're going to static caches, interleaved DRAM, etc.), you begin to see the memory problems of an 8mhz 6502 (although because it can only address 64K of RAM, using fast SRAM is certainly a good option). -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 | | \X/ Amiga. The homestation for the blessed of us. |
cs3b3aj@maccs.McMaster.CA (Stephen M. Dunn) (04/03/89)
In article <7734@killer.Dallas.TX.US> elg@killer.Dallas.TX.US (Eric Green) writes: >in article <16510@cup.portal.com>, A-N-Onymouse@cup.portal.com (John - DeBert) says: >$ 8MHz is too fast for DRAM? Shhh! Don't tell my HP! It has DRAM and an 8MHz >$ clock. Plus a faster one for the alphagraphics display. :) >$ Seriously, one wonders how one may get DRAM to work with those so-called >$ turbo clones with clocks of at least 8MHz. >$ Also, I have seen 70ns DRAMS advertised from time to time. That's how they get DRAM to work with turbo clones - they use faster DRAMS (or at least, that's part of it). I'm writing this on an AT-clone running at 12 MHz, one wait state, but I could get it down to zero wait states with readily available 80 ns memory. As for the really fast 386 machines, they use caches to achieve better performance (and some of them are huge - I've seen machines with 64K SRAM caches!); that's mentioned later on in the article. I believe the intent of whoever said 8 MHz is too fast for DRAM was that the chips in the 64 were too slow, not that DRAM as a whole is too slow. > >The 8080sux emulates the bus cycles of it's 8080 ancestory, which is >identical to the bus cycle of the Z-80 which we previously discussed. Just to make sure nobody gets the idea that the 8080 was based on the Z-80, it's the other way round. >An 8080sux takes 4 clock cycles to read a byte from the bus. The 6502, >65c02, etc. take 1 clock cycle. Thus a 8 mhz 6502 would be the >equivalent of a 32mhz 8086-based machine. Considering that 80x6-based The problem with your argument is that you assume that everything on an 8086 takes four times as long as on a 6502. I'd like to see you get a 6502 to do a 16-bit signed integer division in under 50 clock cycles (which would be four times faster than an 8086), or do based indexed addressing on a pitiful CPU with two 8-bit index registers. You're quite right about how dreadfully slow 8086 memory accesses are; however, make sure that you don't get everybody out there in NetLand thinking that they should sell their XT clones and buy a 64. By the way, part of the reason why 8086 memory accesses are so slow is the fact that the data and address buses are multiplexed, so you need extra time to access the data; also, I'm sure that the time required to add in the segment register slows it down by a cycle or so. >machines are having trouble getting RAM fast enough to run at 25mhz >(they're going to static caches, interleaved DRAM, etc.), you begin to >see the memory problems of an 8mhz 6502 (although because it can only >address 64K of RAM, using fast SRAM is certainly a good option). One of the major problems with most DRAM is that its address bus is multi- plexed and, without some nifty hardware (which is sometimes incorporated into the DRAM chip) to determine if the current memory access is in the same page of DRAM as the previous one, this generally adds something like 50% to the time it would take were the address bus not multiplexed. (Do you get the feeling I'm not a great fan of multiplexing buses to save space and waste time? ;-) But back to the 6502 family; it's a seriously flawed processor (not that the 8086 family doesn't have flaws - it does too, of course). Unlike many other 8-bit processors (Z-80, 8080, 8085), it is incapable of doing anything with 16-bit quantities unless you write your own code to do it. Its stack is limited to 256 bytes. If you want to do math, you can't use your other two registers - they're stricly for indexing or temporary storage; one operand comes from the accumulator, and the other has to be fetched from memory. And it forces you to waste some of your memory space for I/O. Of course, it does have some nice features. It has more addressing modes than your average 8-bit micro; it can perform decimal arithmetic; it is optimized for quick access to one page of memory, and it has short branch instructions. One thing we have to watch out for here is comparing apples (with a small a) to oranges - the 6502 and 8080 families were designed in the early seventies, and they're 8-bit chips, whereas the 8086 family came out in the late seventies and are 16 bits (or more). The 6502 and the 8086 aren't really comparable (as my example a couple of pages ago, on 16-bit integer division, was meant to show). Regards, -- ====================================================================== ! Stephen M. Dunn, cs3b3aj@maccs.McMaster.CA ! DISCLAIMER: ! ! I always wanted to be a lumberjack! - M.P. ! I'm only an undergrad ! ======================================================================
leblanc@eecg.toronto.edu (Marcel LeBlanc) (04/03/89)
In article <2310@maccs.McMaster.CA> cs3b3aj@maccs.UUCP (Stephen M. Dunn) writes: >In article <7734@killer.Dallas.TX.US> elg@killer.Dallas.TX.US (Eric Green) writes: >>in article <16510@cup.portal.com>, A-N-Onymouse@cup.portal.com (John - DeBert) says: >>$ 8MHz is too fast for DRAM? Shhh! Don't tell my HP! It has DRAM and an 8MHz >>$ clock. Plus a faster one for the alphagraphics display. :) >>$ Seriously, one wonders how one may get DRAM to work with those so-called >>$ turbo clones with clocks of at least 8MHz. >>$ Also, I have seen 70ns DRAMS advertised from time to time. ... >>An 8080sux takes 4 clock cycles to read a byte from the bus. The 6502, >>65c02, etc. take 1 clock cycle. Thus a 8 mhz 6502 would be the >>equivalent of a 32mhz 8086-based machine. Considering that 80x6-based > >The problem with your argument is that you assume that everything on an >8086 takes four times as long as on a 6502. I'd like to see you get a >6502 to do a 16-bit signed integer division in under 50 clock cycles Since Eric was talking about memory access, there's nothing wrong with his argument. An 8088/86 takes 3 clock cycles per memory access, NO MATTER WHAT INSTRUCTION is being executed! The same is true of the Z80 and 8080. Eric stated 4 clocks/access because these processors need an extra cycle to decode the instruction on a fetch. The 6502 takes only 1 clock/access. This is why Dave Haynie was saying that cheap DRAMs wouldn't be enough for an 8MHz 6502. An 8MHz XT on the other hand is much slower, so you can use almost any speed DRAM. >(which would be four times faster than an 8086), or do based indexed >addressing on a pitiful CPU with two 8-bit index registers. You're quite >right about how dreadfully slow 8086 memory accesses are; however, make >sure that you don't get everybody out there in NetLand thinking that they >should sell their XT clones and buy a 64. Standard clones (today) are faster than the original 4.77MHz that were common when the C64 was younger. When I bought my C128 (ages ago), I tried running a simple benchmark on it, then compared with the results on a clone that I had borrowed from work. To make the test "fair", I tested floating point addition, since neither machine had floating point hardware. I used a simple "FOR" loop in BASIC (you would really have to compare the two BASIC interpreters if you wanted to publish 'facts'). As expected, the 2MHz C128 was 40% FASTER than the 4.77MHz clone. If you just compare clock speeds, then you might believe that a 33MHz 80386 is faster than a 10MHz R2000, 88000, or SPARC (?). If I was just interested in speed, I would use any of these at 10MHz before a 33MHz 80386. Marcel A. LeBlanc | University of Toronto -- Toronto, Canada leblanc@eecg.toronto.edu | also: LMS Technologies Ltd, Fredericton, NB, Canada ------------------------------------------------------------------------------- UUCP: uunet!utai!eecg!leblanc BITNET: leblanc@eecg.utoronto (may work) ARPA: leblanc%eecg.toronto.edu@relay.cs.net CDNNET: <...>.toronto.cdn
bah@tippy.uucp (04/03/89)
3.
cs3b3aj@maccs.McMaster.CA (Stephen M. Dunn) (04/04/89)
In article <89Apr2.223029edt.2745@godzilla.eecg.toronto.edu> leblanc@eecg.toronto.edu (Marcel LeBlanc) writes: >>>65c02, etc. take 1 clock cycle. Thus a 8 mhz 6502 would be the >>>equivalent of a 32mhz 8086-based machine. Considering that 80x6-based >>The problem with your argument is that you assume that everything on an >>8086 takes four times as long as on a 6502. I'd like to see you get a >>6502 to do a 16-bit signed integer division in under 50 clock cycles >Since Eric was talking about memory access, there's nothing wrong with his >argument. An 8088/86 takes 3 clock cycles per memory access, NO MATTER WHAT >INSTRUCTION is being executed! The same is true of the Z80 and 8080. Eric >stated 4 clocks/access because these processors need an extra cycle to >decode the instruction on a fetch. The 6502 takes only 1 clock/access. >This is why Dave Haynie was saying that cheap DRAMs wouldn't be enough for >an 8MHz 6502. An 8MHz XT on the other hand is much slower, so you can use >almost any speed DRAM. No dispute there ... the point I was trying to make is that we're trying to compare apples to oranges. Memory accesses may be (much!) slower on an 8086 or 8088, but beyond that, you can't really compare them to the 65xx since one is so much older than the other. >>addressing on a pitiful CPU with two 8-bit index registers. You're quite >>right about how dreadfully slow 8086 memory accesses are; however, make >>sure that you don't get everybody out there in NetLand thinking that they >>should sell their XT clones and buy a 64. >Standard clones (today) are faster than the original 4.77MHz that were >common when the C64 was younger. When I bought my C128 (ages ago), I >tried running a simple benchmark on it, then compared with the results on a >clone that I had borrowed from work. To make the test "fair", I tested >floating point addition, since neither machine had floating point hardware. >I used a simple "FOR" loop in BASIC (you would really have to compare the >two BASIC interpreters if you wanted to publish 'facts'). As expected, the >2MHz C128 was 40% FASTER than the 4.77MHz clone. I don't have a C128 to play around with, but I do have a 64 (with a broken 1541) back home, and I did a C benchmark on it. The code I used was taken from BYTE (don't ask me which issue), and it included four tests: fibonacci, a floating test, the Savage benchmark, and the standard sieve of Eratosthenes. On the Fibonacci, the 64 died (not enough stack, so it hung). On the Sieve, the 64 had 16.2% of the performance of a real IBM PC. On the floating test, it had 64.3% performance, and the Savage said that the 64 had 70.3% of the performance. (I suspect, though, that the C compiler on the 64 used the ROM BASIC floating point routines, which are single-precision, whereas the PC compiler used the double precision that good C compilers are supposed to use. Now, of course I realize that this is a comparison of the two compilers as well as the hardware, but it shows just how much slower the 64 is. One neat thing, though, which shows that the 8086 family has some inefficiencies, is that when you adjust the figures to take into account the difference in clock speeds, the 64 had 75.6% of the performance of an XT (based on the sieve). Anyway, I'm going to stick with my AT clone. The 64 was nice while its disk drive lasted, but it just can't hope to compare with machines using much more recent technology. Besides, there's such a great variety of software for the PC family, and I'm just continuing on here because our news posting program requires me to half more than half new text. f i l l e r That should about do it. Regards, -- ====================================================================== ! Stephen M. Dunn, cs3b3aj@maccs.McMaster.CA ! DISCLAIMER: ! ! I always wanted to be a lumberjack! - M.P. ! I'm only an undergrad ! ======================================================================
daveh@cbmvax.UUCP (Dave Haynie) (04/05/89)
in article <16510@cup.portal.com>, A-N-Onymouse@cup.portal.com (John - DeBert) says: > In article <6460@cbmvax.UUCP> daveh@cbmvax.UUCP writes: >>Sounds like you've been reading GTE databooks. One caution -- don't believe >>everything you read. While these databooks often show the timing for parts >>in a wide variety of speeds, that doesn't necessarily mean that such parts >>are actually available. Last time I looked, GTE listed 65C02s up to 4MHz and >>65C802s and 65C816s up to 8MHz, though they only had 4MHz versions of the >>latter, and no real yield on the former at 4MHz (they probably have the >>4MHz 65C02s by now...). > Hmm. I have before me a copy of a data sheet for the WD65C816/65C802 that > specifies a version of the device with an 8MHz clock. It's >NOT< a preliminary > data sheet. The Western Design data sheets are just as misleading. You really have to consider what a data sheet is. You seem to think that it's a description of what a particular part does. In reality, all a data sheet for any part tells you is that, given a particular part, what's the worst that you can expect from it. It's a specification, just as it says. If Western Design or GTE were to make an 8MHz 65C816, it would have to meet that specification. Just because they've produced a specification is absolutely no indication that such a part exists or ever will exist. I had the specification sheets on 65C816s, going all the way up to 8MHz, back when the fastest part they could make was a 500kHz version. > 8MHz is too fast for DRAM? Shhh! Don't tell my HP! It has DRAM and an 8MHz > clock. Plus a faster one for the alphagraphics display. :) > Seriously, one wonders how one may get DRAM to work with those so-called > turbo clones with clocks of at least 8MHz. If you don't understand the difference, I hope you're not going to be designing any PC clones or 6502 systems in the near future. The clock speed given had absolutely no standard relation to bus speed (bus speed directly relates to the possible memory speeds you can deal with). The 8086 family runs one memory cycle in 4 CPU clocks, the 6502 family runs one memory cycle in 1 CPU clock. So your 8MHz 8086 machine is, from the point of view of the memory you have to support, roughly equivalent to a 2MHz 6502 family machine, like the C128. Obviously, the C128 works just fine with moderate speed DRAM, as do most PClones. > Also, I have seen 70ns DRAMS advertised from time to time. Yes, you can get 70ns DRAMs, though they're around 5x-10x the price of 120ns DRAMs. A 70ns DRAM gives you something on the order of a 110-120ns cycle time, which is still too slow for an 8MHz 6502 family processor. Part of the problem here is the 6502 design itself. The memory cycle time of a 6502 family part at 8MHz is 125ns. The problem is that, unlike modern CPUs such as the 680x0 family processors, the 6502 doesn't give you much help in closely matching a memory system to the CPU. The 680x0 parts give you a strobe when addresses are valid and a strobe when data is valid, and both address and data come out really fast. The 6502 just gives you a fixed time from the falling edge of PHI0 to when addresses or data are valid, things like that. So you can't design a circuit that's nearly as tight as a 680x0 circuit, even if address/data events were as fast for the same bus cycle time (which they aren't). > I doubt that it would be worth the trouble and expense to modify the C64 > for "turbo speed" using the 65C802. There would need to be drastic changes > in bus timing and how interrupts were handled. Well, for turbo speed, you really can't modify the C64 bus timing, you just build a separate 6502 computer with fast memory that knows when to slow down and access the C64 resources. The 65816 accelerator thing I mentioned. I still doen't recall the manufacturer, though I saw it last at the Philly World of Commodore, running BASIC at 4MHz, though I believe they've modified the ROMs to drop down in speed when accessing disk and any other time critical things. And most video games will die or at least malfunction with a faster system. Nothing changes with interrupts themselves, though any routines driven by interrupt code, like raster interrupts for screen splits or reusable sprites almost always depend on processor wait loops, which of course are directly based on the speed of the 6502. Fred's certainly seen most of what can go wrong from back in the C128 days. >After you're done with the mods, you'll probably never be able to put the > thing back in a C64 case. Even if you just wanted to do a straight > replacement of the 6510, there's still the problem of how to implement > the i/o port but that's not really too hard. The commercially available units typically plug into the expansion port, and to do much of anything, new code is required. All in all, though, I agree; it would be more trouble than it's worth to try and build such an accelerator, unless that just sounds like a fun hobby. If you want a faster C64, I'd recommend buying one of the commercially available units. > Ah, well. Now that we've knocked your idea and all, perhaps you'll prove us > all wrong? :) Maybe he will. After all, someone had to design the ones that are already out there. >>Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" > J. DeBert -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
ross@watcsc.uucp (Ross Ridge) (04/05/89)
In article <2325@maccs.McMaster.CA> cs3b3aj@maccs.UUCP (Stephen M. Dunn) writes: >I don't have a C128 to play around with, but I do have a 64 (with a broken >1541) back home, and I did a C benchmark on it. The code I used was taken >from BYTE (don't ask me which issue), and it included four tests: fibonacci, >a floating test, the Savage benchmark, and the standard sieve of Eratosthenes. >On the Fibonacci, the 64 died (not enough stack, so it hung). On the Sieve, >the 64 had 16.2% of the performance of a real IBM PC. On the floating >test, it had 64.3% performance, and the Savage said that the 64 had 70.3% of >the performance. (I suspect, though, that the C compiler on the 64 used the >ROM BASIC floating point routines, which are single-precision, whereas the >PC compiler used the double precision that good C compilers are supposed to >use. C Power uses the ROM's 5 byte floating point routines, but most good C compiliers will use single-precision (4 byte) artithmitic if it can get away with it. >Now, of course I realize that this is a comparison of the two compilers as >well as the hardware, but it shows just how much slower the 64 is. No, not really, C compilers for the 64 are really bad compared to C compiliers for other systems. I believe Abacus's C compiler is a P code interpreter, and C Power C, doesn't do any significant optimizations (not even constant folding). This really isn't a fair comparison because no "serious" delopement for the 64 is done using C. A fair comparison would be assembly language verses assembly language. Or even 6502 assembly verses, IBM PC C language since most PC software being written now is done in C. >Anyway, I'm going to stick with my AT clone. The 64 was nice while its >disk drive lasted, but it just can't hope to compare with machines using >much more recent technology. 1981? Recent technology, hardly... Well I don't use my 64 because of its great speed, but nor would I use an IBM PC (or even AT) for that reason either. I use my 64 because it has great games, there are not many games available for the PC that are not available for my 64, and CGA graphics are blech. Gimme '386 machine with VGA (or better), and good selection of games, and then I'd think of using machine capable of running operating systems written by MicroSoft. >Besides, there's such a great variety of software for the PC family, and >I'm just continuing on here because our news posting program requires me >to half more than half new text. Well then delete some of the old irrelevent text. -- l/ // [oo] !watmath!watcsc!ross [OO] -()- -()- db The Dreaded Commodore 64 User //
cs3b3aj@maccs.McMaster.CA (Stephen M. Dunn) (04/05/89)
In article <1989Apr4.221550.19284@watcsc.uucp> ross@watcsc.UUCP (Ross Ridge) writes: >>Anyway, I'm going to stick with my AT clone. The 64 was nice while its >>disk drive lasted, but it just can't hope to compare with machines using >>much more recent technology. >1981? Recent technology, hardly... And when, pray tell, did the 6502 come out? And is it not true that just about the only difference between a 6502 and a 6510 is the 6-bit (I think it's 6) parallel port on-chip? Not a high-tech feature that significantly alters the recentness (is that a word) of the design. >I use my 64 because it has >great games, there are not many games available for the PC that are not >available for my 64, and CGA graphics are blech. Gimme '386 machine with >VGA (or better), and good selection of games, and then I'd think of using >machine capable of running operating systems written by MicroSoft. And do you use BASIC on your 64? Who do you think Commodore cloned that software from? In fact, if you go back to the BASIC on the original PET (which the 64's BASIC grew out of), the ROM even has the string MICROSOFT embedded in it. I don't know if they wrote the OS for the PET, though, and the 64 OS is quite likely Commodore's, but they're not perfect, either. Proof? The code running the 1541. The save and replace function (@) is buggy, and I've run across a couple of other bugs that I can't remember the specifics of. Nothing but agreement on your CGA comments - it's a lousy display card. It I was going to have a colour display, I'd certainly go for at least an EGA (which beats the $%&@ out of the 64 in almost every respect). But I'm quite happy with my Herc clone - 720 x 350 resolution. Yes, the 64 has some great games on it (although the Amiga is even better for games), but if you're doing something more serious, I don't see how anyone could be happy programming the 64 for too long. Try doing a small business accounting package (including AR, AP, GL, etc.) on a 64. It can be done, yes, but you run into several problems: - slow compilation (unless you do it in interpreted BASIC, in which case you get slow execution) - mega-slow disk drive unless you buy an IEEE adapter - small memory to work with - 40-column screen (I've seen software to make it do 80, but the print is nearly illegible) Anyway, if you're happy with your 64, by all means keep using it. It's just that the machine's limitations get frustrating faster than those of the PC family (in my opinion, anyway). Regards, -- ====================================================================== ! Stephen M. Dunn, cs3b3aj@maccs.McMaster.CA ! DISCLAIMER: ! ! This space left unintentionally blank - vi ! I'm only an undergrad ! ======================================================================
daveh@cbmvax.UUCP (Dave Haynie) (04/07/89)
in article <2310@maccs.McMaster.CA>, cs3b3aj@maccs.McMaster.CA (Stephen M. Dunn) says: > Summary: 6502 Family has some _serious_ design problems >>An 8080sux takes 4 clock cycles to read a byte from the bus. The 6502, >>65c02, etc. take 1 clock cycle. Thus a 8 mhz 6502 would be the >>equivalent of a 32mhz 8086-based machine. Considering that 80x6-based > The problem with your argument is that you assume that everything on an > 8086 takes four times as long as on a 6502. There really isn't much of a problem with this argument. Look again, we were talking about memory system requirements, nothing else. From the point of view of the memory system, this isn't far off. However, I have no doubt that a 32MHz 8086 machine (assuming one could build such a critter) would easily outpace an 8MHz 6502 type machine. Because of the fact that memory access isn't everything -- what can be accomplished in single instructions, and how much can be done without touching main memory (eg, via registers or cache) also have to get factored into this. > But back to the 6502 family; it's a seriously flawed processor ... It wasn't all that bad for it's time. It was much easier to design a 6502 system than an 8080A or Z-80 system, and for most of the things a micro computer had to do back then, it was faster than 8080 or Z-80 systems that were available at the time (the early Apple II and PETs were noticably faster than my first micro, the Z-80 based Exidy Sorcerer) for the same marketplace (Z-80 business systems were built than outpaced most 6502 and even many of the later 8088 systems, but they weren't cheap). You might also want to re-read the stuff I deleted. Virtually every complaint about the 6502 vs. the 8088 can be applied to the argument of 80x86 vs 680x0. I just found that kind of interesting. > One thing we have to watch out for here is comparing apples (with a small a) > to oranges - the 6502 and 8080 families were designed in the early seventies, > and they're 8-bit chips, whereas the 8086 family came out in the late > seventies and are 16 bits (or more). The 6502 and the 8086 aren't really > comparable (as my example a couple of pages ago, on 16-bit integer > division, was meant to show). The 8086 and 8088, internally, are pretty much 8 bit chips that can at times manipulate 16 bit data. Much in the same way that a 68000 in mostly 16 bits internally, but does 32 bit operations (as I recall, there are 3 sixteen bit ALUs in the 68000, two of which team up to do a 32 bit operation). > ! Stephen M. Dunn, cs3b3aj@maccs.McMaster.CA ! DISCLAIMER: ! -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
mac@harris.cis.ksu.edu (Myron A. Calhoun) (04/07/89)
In article <2348@maccs.McMaster.CA> cs3b3aj@maccs.UUCP (Stephen M. Dunn) writes: >And when, pray tell, did the 6502 come out? And is it not true that just I had several KIM-1 single-board 6502-based computers by 1975, so the 650x (there were eventually a LOT of versions) obviously came out before then. >about the only difference between a 6502 and a 6510 is the 6-bit (I think >it's 6) parallel port on-chip? Not a high-tech feature that significantly True. The instruction set was essentially (and maybe exactly) the same. [several lines deleted] >Proof? The code running the 1541. The save and replace function (@) is >buggy..... Not really--it was just that, based on a not-too-good explanation in the manual, most users used a short-hand way of issuing the save-and-replace function which had a problem. I (vaguely) recall that when one issued the command correctly, it worked correctly. I am (or at least I consider myself to be:-) an "expert" on 6502 programming, but I am/was NOT an expert on Commodore C-64's and/or VIC-20's; even though I own/owned about a dozen of them altogether. But I have a college-age son whom I do consider to be quite knowledgeable about C= stuff. -- Myron A. Calhoun, PhD EE, W0PBV, (913) 532-6350 (work), 539-4448 (home). INTERNET: mac@ksuvax1.cis.ksu.edu BITNET: mac@ksuvax1.bitnet UUCP: ...{rutgers, texbell}!ksuvax1!harry!mac
elg@killer.Dallas.TX.US (Eric Green) (04/08/89)
in article <2310@maccs.McMaster.CA>, cs3b3aj@maccs.McMaster.CA (Stephen M. Dunn) says: > In article <7734@killer.Dallas.TX.US> elg@killer.Dallas.TX.US (Eric Green) writes: >>The 8080sux emulates the bus cycles of it's 8080 ancestory, which is >>identical to the bus cycle of the Z-80 which we previously discussed. > Just to make sure nobody gets the idea that the 8080 was based on the Z-80, > it's the other way round. Which is exactly what I said, in any event. We were previously talking about the 4mhz Z-80 in the C-128, and someone wondered why it wasn't twice as fast as the 2mhz 8502. A detailed description of its 4-cycle bus cycle was posted, which is what I'm referring to above. >>An 8080sux takes 4 clock cycles to read a byte from the bus. The 6502, >>65c02, etc. take 1 clock cycle. Thus a 8 mhz 6502 would be the >>equivalent of a 32mhz 8086-based machine. Considering that 80x6-based > The problem with your argument is that you assume that everything on an > 8086 takes four times as long as on a 6502. I'd like to see you get I can see where you got confused, but I was talking solely about the memory speed requirements -- not CPU power. If you read my previous notes about the Z-80, I noted that its ability to hold 16-bit quantities in registers and a real 16-bit stack pointer made Z-80 "C" and Pascal compilers produce much smaller and faster code than 6502 equivalent. And of course the 8086 adds better memory addressing, instructions for multiply and divide, and many other advantages (it makes a dandy successor for the Z-80, though I doubt the 8086 designers were thinking of the Z-80 at the time). I have programmed extensively in 6502 assembly language, enough such that I will never use a 6502 in any imbedded applications -- it's not worth it, when you can buy 6809s cheap as sand. Using 6502s in a systems application is, of course, absolutely brain-dead in today's world where 68000s are as cheap as sand. But the C-64 was never intended to be a system -- it was intended to be a cartridge-based game machine. -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 | | \X/ Amiga. The homestation for the blessed of us. |
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (04/08/89)
> From: mac@harris.cis.ksu.edu (Myron A. Calhoun) > Message-ID: <1581@deimos.cis.ksu.edu> > >about the only difference between a 6502 and a 6510 is the 6-bit (I think > >it's 6) parallel port on-chip? Not a high-tech feature that significantly > > True. The instruction set was essentially (and maybe exactly) the same. To the point where undocumented op codes that worked on the 6502 (regardless of the manufacturer!) work on the 6510 (and probably the 8502 as well). The 65C02 and the 65816, on the other hand, have reassigned those op codes to new instructions, so programs that depend on undocumented op codes (PaperClip) don't work on these CPUs. -- Geoffrey Welsh - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!izot Internet: izot@f171.n221.z1.FIDONET.ORG