28 thoughts on “Reverse Engineering the MOS 6502 CPU [announcement]

  1. viscid

    Thank you for the interesting talk at CCC and therefor for pushing the limits further… I guess there are a lot of useful informations for the C64-demoscene. I just wonder when someone starts to rebuild a 6502 on a large scale hardware with real transistors. Maybe on 2 or 3 squaremetre of PCB ;)

    Reply
  2. Stephen

    Would an all transistor 6502 be able to work (could the timings be correct with discrete transistors)?

    Can’t wait to check out this presentation.

    Reply
  3. Paul

    Forgive me for being stupid but I’m nervously checking the linked page for a few days now but can’t find the presentation, or stream, or anything.

    Help! :-)

    Reply
  4. Paul

    Thanks guys (for the upload, and for the presentation). Great stuff and brings back many memories of my childhood.

    Happy New Year!

    Reply
  5. Russ Cox

    Very cool stuff. Two small things.

    1. The 6502 designer’s name was Chuck Peddle not Peedle.
    (Same mistake is in the SIGGRAPH slides on visual6502.org but I can’t find any contact information on that site.)

    2. Is the perfect6502 code available?

    Thanks.

    Reply
  6. Jim Brain

    It would be nice to get additional clarity on the BRK bug. Specifically, since the IRQ/NMI/RESET lines are added to the Random control logic portion (to force the correct PC, for example), they also prevent PC from being incremented before stack push (they have to). So, the fact that 0 was forced into the opcode doesn;t seem to matter, as the random control logic should prevent PC+1 in these cases, and thus the RTI would fetch the BRK again. Obviously, since the bug is present, either there is more to the story.

    Reply
  7. Pingback: Reverse Engineering the MOS 6502 CPU [video] « pagetable.com

  8. Adrian Glaubitz

    Hi Michael,

    I watched your talk on the 6502 on Youtube yesterday and I was really amazed. That was an incredibly insightful view on the inner workings of how CPUs work. I have been doing a lot of 6502 assembly on my old C64 as well and your talk really shed a lot of light onto the whole how and why. Congratulations!

    Looking forward to what’s coming on this topic. The idea about a complete C64 simulated in software is just crazy but incredibly fascinating. I hope to see that in some years ;).

    PS: I really liked the part with the “perfect6502″ and the delay when the ROM BASIC was actually determining the amount of free memory, you could really see the C64 doing something ;). Do you actually know how this works? I mean, how does the ROM BASIC calculate the free BASIC bytes? Is there some bitmap for the pages that is looked up?

    Adrian

    Reply
  9. Michael Steil

    @Adrian: RAM check, as MagerValp says, walks through RAM, testing every byte with 0×55 and 0xAA until it hits memory that doesn’t read back the right value – which is when it hits ROM at 0xA000.

    But the reason for the delay before printing “38911″ is actually different, and my statement in the talk wasn’t entirely accurate: It is KERNAL that does the RAM check, and when BASIC is running, it only asks KERNAL, and in my simulation I just pass it the value of 0xA000. What really takes a long time there is converting the result of “0xA000 – 0×0801″ into a decimal number. To do that, it uses the software floating point library included with BASIC. It converts a 16 bit integer into floating point and then prints it. And that takes forever. A couple of manual divides by 10 would have been much faster, but in Microsoft BASIC for 6502, it’s rarely about speed, and most of the time it’s about size.

    Reply
  10. Adrian Glaubitz

    Hi,

    MagerValp and Michael, thanks clarifying things.

    The way the KERNAL determines the usable memory sounds a bit brute force though. I was just thinking of some data/vectors in the RAM that get arbitrarily overwritten. But yeah, how else would it work except for writing and reading back all bytes.

    Is there a specific reason why $55/$AA were chosen?

    Thanks,

    Adrian

    Reply
  11. Ken Dyke

    Michael,

    Thanks for the excellent presentation. Do you have a URL to that much-improved internal block diagram that shows the various internal 6502 busses? I’m another one of those in the “implemented a 6502 in an FGPA” crazy people and found this all to be very fascinating….

    Reply
  12. Adrian Glaubitz

    @tlr:

    Yes, I saw the “ROL” in the assembly code and that was my thought, too. I love tricks like these, so beautiful code =).

    Adrian

    Reply
  13. Mark

    Is there someone/-where to get more detailed information about the optical verctorization of the chip (besides visual6502.org). I would like to know if it would be possible to analyze other chips with more than 2 metal layers, e.g. technologies in 0.35um. My goal is to extract only parts of the chip and generate the schmatic of a certain block.

    -Mark

    Reply
  14. Jibaro

    Hello,

    > Yes, I saw the “ROL” in the assembly code and that was my thought, too.
    > I love tricks like these, so beautiful code =).

    I love the C64, too, but this particular ROL at $FD79 should have been
    an ASL instead! Since the previous BNE will not jump (unless we found
    an error), the C flag will always be set, and the ROL will produce $AB
    (not $AA as intended). If you have a byte where the LSB is stuck into
    a steady one, this RAM test will never discover it.

    Sometimes you can spot this $AB on the screen as a “+” char in reverse
    (not a reverse “*” which would correspond to $AA) when you press RESET
    or do a SYS64738.

    Jibaro

    Reply
  15. Jeff Dutky

    Is there some way to view the video of the talk? YouTube now (in Jan 2014) says that the video is “private”. I would really like to see the presentation.

    Thanks.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>