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

  1. 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 ;)

  2. 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.

  3. 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! :-)

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

    Happy New Year!

  5. 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.

  6. 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.

  7. 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

  8. @Adrian: RAM check, as MagerValp says, walks through RAM, testing every byte with 0x55 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 – 0x0801” 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.

  9. 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

  10. 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….

  11. @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

  12. 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

  13. 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

  14. 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.

Leave a Reply to Adrian Glaubitz Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.