6502 illegal opcodes questions
in [Commodore]
|
Prev: what happened CBM=VGA
Next: 1581 Drive Kits on eBay
From: John Selck on 19 May 2006 10:07 Am 17.05.2006, 17:31 Uhr, schrieb <heuser.marcus(a)freenet.de>: >> Huh? They did move forward. 6510 -> 8500 -> 8502. > > And what exactly were the differences between these chips? 8502 allows 2 MHz and afaik also has some extra pins for zeropage addressing mode and stack detection. 8500 is ofcourse basically a 6510 :) >> And also, I don't think it's any kind of problem for Commodore to use >> customized CPUs since they owned MOS, the owners and producers >> of 6502 tech back then :) > > And, yes, MOS made all the funky custom chips - but the 6502-core chips > were AFAIK the most advanced CPUs designed/modified/produced by them. The VIC or SID are about 3 times bigger than the 6502. But ofcourse the 6502 is ingenious :) the only bad thing about it is, that they wasted transistor space for something like BCD mode. I would have preferred some small extra commands like ADD without carry or TXY.
From: Rainer Buchty on 19 May 2006 10:36 In article <qh1wuqmoqz.fsf(a)ruckus.brouhaha.com>, Eric Smith <eric(a)brouhaha.com> writes: |> buchty(a)atbode100.lrr.in.tum.de (Rainer Buchty) writes: |> > There are quite some "it wouldn't work otherwise" examples, though, |> > which require those undocumented opcodes to meet strict timing. |> |> Such as? IIRC the S-JiffyDOS patch uses illegal opcodes to speed up GCR decoding. (Jochen, are you reading here and can comment?) And I'm sure quite some demos contain illegal opcodes to either make effects possible at all or get the max out of the raster timing. Rainer
From: heuser.marcus on 19 May 2006 10:37 > The VIC or SID are about 3 times bigger than the 6502. But ofcourse the > 6502 is ingenious :) That's why I wrote "advanced CPUs" ;-) > the only bad thing about it is, that they wasted transistor space for > something like BCD mode. I would have preferred some small extra > commands like ADD without carry or TXY. I guess, all of us have some wishes for design changes and I agree with your propositions (though I would've called it TYX - sounds better). Additionally I would've dumped the indexed-indirect addressing mode and simply made an indirect-indexed-mode with the X register. IMHO this would've been infinitely more useful. For a long time I wished for a block move instruction but I've already seen too many cases of non-contiguous blocks. A block fill on the other hand... bye Marcus
From: John Selck on 19 May 2006 14:45 Am 19.05.2006, 16:37 Uhr, schrieb <heuser.marcus(a)freenet.de>: > I guess, all of us have some wishes for design changes and I agree with > your propositions (though I would've called it TYX - sounds better). You could need both, TXY and TYX. Also PHX/PLX/PHY/PLY would have been nice and propably would have been possible with only few extra transistors. > For a long time I wished for a block move instruction but I've already > seen too many cases of non-contiguous blocks. A block fill on the other > hand... And then we would have ended up like the Z80: That a copy loop is faster than the actual block copy instruction :D Anyway, you don't need block fill since you can use block copy for filling too, just write the fill-byte to the start address and then start copying to bufferstart+1, it will do the same. Anyway, things could have been better but at the same time they could have been way worse. We're actually pretty lucky with the existing implementations of the 6502 and also VIC + SID.
From: Eric Smith on 19 May 2006 16:34
"John Selck" <gpjiweg(a)t-online.de> writes: > And then we would have ended up like the Z80: That a copy loop is faster > than the actual block copy instruction :D Can you cite an example? The block move instructions on the Z80 are actually fairly efficient. They use three memory cycles to move a byte, vs. the theoretical minimum of two. Doing a block copy via a software loop is going to require at least five memory cycles per byte moved, and probably more. |