6502 illegal opcodes questions
in [Commodore]
|
Prev: what happened CBM=VGA
Next: 1581 Drive Kits on eBay
From: John Selck on 18 May 2006 02:27 Michael J. Mahon wrote: > It would actually be fun to see the real logic diagram of the > 6502. ;-) > > All of the "internals" documentation I've found is very abstract > with no detail where it would be most interesting. Some hungarian maniacs have reverse engineered the 6502: http://impulzus.sch.bme.hu/6502/6502/ Sadly the site is in hungarian language, but atleast the logic diagrams speak for themselves.
From: Michael J. Mahon on 18 May 2006 03:39 John Selck wrote: > Michael J. Mahon wrote: > >> John Selck wrote: >> >>> Huh? They did move forward. 6510 -> 8500 -> 8502. 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 these new processors preserved the undefined opcode behavior? >> >> If so, they are almost certainly *not* new processor designs. > > > Same opcodes but faster clockspeed. Also, CBM switched from NMOS to HMOS. So this was an algorithmic rework of the original design for a new process, not a new logical design. >>> 3) Slow-as-hell 8 Bit platforms don't have a proper abstraction layer >>> for any of their hardware, no matter if sound, graphics, timers, >>> ports or CPU. >> >> >> Nonsense. The "abstraction" we are discussing is the published >> documentation for the processor/system. What it documents is the >> abstraction that future implementations will preserve. What it >> doesn't document will generally not be preserved. > > > What about the bugs in the decimal mode? They were fixed on later > processor designs, this also renders the CPUs incompatible for some > programs. Processor bugs (or "errata") are cases where the implementation does not behave as the documentation says that it should. The decimal bugs in the original 6502 were not part of its documentation, and therefore should not be depended upon. (Of course, in the presence of the bug, code cannot depend on the documented *correct* behavior either; it must be written to "work around" the bug without depending on undocumented behavior.) Errata are always a special case. The designers always hope that code that runs correctly on the original, buggy processor will still run correctly on a fixed processor. In other words, they hope that no one has written code that *depends* on buggy behavior. To summarize, code written to the specifications of a processor will work correctly on all implementations, *except* where an implementation is faulty. Code written to work around a fault can still be written to the specifications, but avoiding the faulty case(s). On the other hand, code written to *require* faulty behavior to run does not conform to the specification, and may not run correctly on a later implementation of the processor. Compatibility is always with the specification--not with undocumented and possibly faulty behavior exhibited by a particular implementation. Such a specification describes the abstraction known as the processor "instruction set architecture" (ISA). -michael Music synthesis for 8-bit Apple II's! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it is seriously underused."
From: Michael J. Mahon on 18 May 2006 04:08 John Selck wrote: > Michael J. Mahon wrote: > >> It would actually be fun to see the real logic diagram of the >> 6502. ;-) > > > > > All of the "internals" documentation I've found is very abstract > > with no detail where it would be most interesting. > > Some hungarian maniacs have reverse engineered the 6502: > > http://impulzus.sch.bme.hu/6502/6502/ > > Sadly the site is in hungarian language, but atleast the logic diagrams > speak for themselves. What do you know! The decoding *is* done with a PLA after all! -michael Music synthesis for 8-bit Apple II's! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it is seriously underused."
From: Michael J. Mahon on 18 May 2006 04:22 John Selck wrote: > Michael J. Mahon wrote: > >> True, but the decoding in the 6502 is handled by a kind of PLA, so >> it would likely not be very expensive (in real estate) to trap or >> NOP the invalid combinations. > > > The 6502 is a design to have as few transistors as possible. The whole > CPU only has a few thousand of them. Handling the illegals would have > increased this small amount a lot. Actually, neither of us has the data on how much would have been required. I argued that if the decoding is regular--as in PLA-- then the cost might have been relatively modest. From looking at the Hungarian reverse engineering of the 6502, it appears that I was right about the PLA decoder. A PLA is used to derive control signals from the op register. >> Admittedly, though, the microprocessor design culture at that time >> was not oriented toward "protecting" undefined space, as they all >> have been in the years since. > > > It's not about culture, it's about being able to do more with just a few > transistors. What CPU would you buy? The one which can do less has NOPs > instead of illegals, or the one which can do more? The difference would be in die size, and therefore cost. And just "getting it done" with absolute minimal die size *is* a design culture. (One that is no longer current in commercial microprocessors.) Moore's "Law" has provided a great deal of freedom in design cultures. ;-) > Removing illegals is ok if you only waste 1000 transistors of 1000000, > but if it's 1000 transistors of 6000, then it's a whole different matter. I admit that I don't have a quantitative estimate of the number of transistors (PLA terms) required to protect at least most of the unused opcode space, but I suspect it would not be more than a few hundred (out of about 3700 in the 6502). Since the decoding is done with a regular (rectangular) PLA, the real issue is not the number of transistors, but the number of rows and columns required to make a "complete" decoder. This would add slightly to the chip dimensions. Adding terms to the PLA within the existing matrix would not add to chip size. Any quantitative estimate would need to be based on the actual 6502 implementation. -michael Music synthesis for 8-bit Apple II's! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it is seriously underused."
From: Spiro Trikaliotis on 18 May 2006 05:56
Hello, aiiadict(a)gmail.com <aiiadict(a)gmail.com> schrieb: >>It would actually be fun to see the real logic diagram of the 6502. >>;-) > > I'd love to see it. According to http://www.ncsu.edu/wcae/WCAE1/hanson.pdf (see also http://www.ncsu.edu/wcae/WCAE1/), there must exist a blueprint at the University of Mississippi, Department of Electrical Engineering. So, perhaps, there might be a source of a possible logic diagram available, if someone could get in touch with that University? Regards, Spiro. -- Spiro R. Trikaliotis http://cbm4win.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ |