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 😉
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.)
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.
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: 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.
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 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….
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.
> 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.
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.
BBC Micro was my first computer, and they were nice enough to include an inline assembler in BBC Basic and I fell in love with the 6502. Great video. Thank you.
Aha! We knew you’d have something cool for CCC. 😀 Merry Christmas and thank you 😉
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 😉
@viscid: i-m working on it
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.
I couldn’t be there, but watched a stream and very much enjoyed it. Thank you!
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! 🙂
There are streams available from http://events.ccc.de/congress/2010/wiki/Documentation
I uploaded a mirror here (as the original site was quite slow and unreliable):
http://www.megaupload.com/?d=DUBJF3Z5
Hope that’s allowed!
Great presentation Michael – thanks very much!
Thanks for the upload Richie. I re-encoded it as an h.264 mp4 and cut it down to 52 minutes, download a copy here (183 MB):
http://galaga.hum.gu.se/tmp/Reverse_Engineering_the_MOS_6502_CPU.zip
Thanks guys (for the upload, and for the presentation). Great stuff and brings back many memories of my childhood.
Happy New Year!
Video of the presentation now on YouTube: http://www.youtube.com/watch?v=HW9AWBFH1sA (first of 6 parts)
I enjoyed the presentation even though I know little of the background.
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.
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.
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
C64 kernal ram check:
http://unusedino.de/ec64/technical/aay/c64/romfd50.htm
@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.
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
Adrian: “Is there a specific reason why $55/$AA were chosen?”
Yes, %01010101 / %10101010
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….
@Ken: we’re collecting our sources and results on our wiki:
http://visual6502.org/wiki/index.php?title=Main_Page#6502_additional_information
(our sources include Hanson’s block diagram)
@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
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
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
@Russ Cox the perfect6502 code is now available at
https://github.com/mist64/perfect6502
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.
I would love to watch the video, too.
BBC Micro was my first computer, and they were nice enough to include an inline assembler in BBC Basic and I fell in love with the 6502. Great video. Thank you.
Are the slides of this session downloadable ?
I found something here and there, but nothing about the part regarding the language 🙁
Thanks !
Julian