Live data from Hacker News

The 6502 CPU's overflow flag explained at the silicon level

arcfn.com

31–34 of 34 posts

Re: The 6502 CPU's overflow flag explained at the silicon level

#32
post #23

Earlier quoted context omitted.

This is working data, so you'd keep it in a register if possible. Sadly that just happens not to be possible on the 6502 :)

Two bytes can be kept in the X and Y registers. Immediate load and add instructions only use two cycles. CLC ; 2 ADC #b1 STA&70 ; 0 2 3 = 5 LDA #a2 ADC #b2 TAY ; 2 2 2 = 6 LDA #a3 ADC #b3 TAX ; 2 2 2 = 6 LDA #a4 ADC #b4 ; 2 2 = 4 ; total 23 cycles

If you're adding constants, you might as well load each byte of the result directly, when you need it. (I can't tell where the LSB is coming from in this code - perhaps it isn't a constant? - this example doesn't resemble any code I've ever had to write.)

Perhaps the code is intended to be modified at runtime, but then you'd then still want one of the operands loaded from memory, I think (otherwise why not just precalculate the results?), and I've generally found the (fairly substantial) fixed expense not to be worth it anyway.

Anyway, overall I think you're being a bit unfair to the x86 with this comparison.

Re: The 6502 CPU's overflow flag explained at the silicon level

#33
post #24
post #10

Earlier quoted context omitted.

Almost 38 years, even... If you're interested in the story around MOS and the 6502, the early parts of "Commodore: A Company on the Edge" by Brian Bagnall covers it quite a bit including parts about the manual layout work that Bill Mensch did. Here's an article about it too: http://research.swtch.com/6502 Not only did they route / layout by hand-drawing, and then cut the Rubylith photomask by hand (it's not a drawing…

I'm glad to see the 6502 getting so much attention on HN. I like the article title Unwind used here, so I've changed the article's original title to match. (Note to self: try to come up with better titles.) I've seen that story before that the 6502 worked perfectly the first time, but I think there's some mythologizing going on. The ROR instruction was totally broken on the first release of the 6502 and wasn't fixed…

I suspect that the "worked perfectly the first time" basically implies (whether that is accurate or not) "they only had to create one mask before their tests passed", not that it was entirely bug free. Possibly that the mask faithfully replicated the design, but that the revision of the design they first manufactured still had bugs.

In any case, the main thing is that a lot of MOS' early success came from saving a tremendous amount of money being able to get to market quickly and cheaply compared to the competition thanks to actually having guys like Mensch and Peddle coupled with superior process (though that did not last all that long).

Re: The 6502 CPU's overflow flag explained at the silicon level

#34
post #24

Earlier quoted context omitted.

I'm glad to see the 6502 getting so much attention on HN. I like the article title Unwind used here, so I've changed the article's original title to match. (Note to self: try to come up with better titles.) I've seen that story before that the 6502 worked perfectly the first time, but I think there's some mythologizing going on. The ROR instruction was totally broken on the first release of the 6502 and wasn't fixed…

You might also want to check out someone building a computer based off a 6502, very fun to see someone going through the steps to design and build something out of older hardware. http://quinndunki.com/blondihacks/?p=680

Part of the appeal to me of this hardware is that it is so simple that even without much electronics experience you can get away with a lot more trial and error while learning.

I did all kinds of crazy things with my C64 and got away with it without breaking stuff, like powering it off batteries (the C64 takes multiple different voltages in, but you can get away with just one - don't remember if it was 5v or 9v - just that some things like the user port and realtime clock won't work) and attaching leds and relays to the user port without a clue what I was doing, replacing the IO chips (CIA) with a different version from my 1541 disk drive when one of the ones in the C64 broke (standard troubleshooting: If the CIA chips were hot right after turning the machine on, they had short-circuited - they were the source of breakage on C64's and Amiga's...), and at a later point with one from my Amiga (they're all pin compatible, but some functionality is different, e.g. the Amiga version has a 32 bit timer instead of the realtime clock nobody used...), or replacing the 6510 in my C64 with a 6502 from a 1541 just to see what would happen (the 6510 has 8 general purpose IO lines, mapped to the tape drive IO and I think bank switching - I believe the machine will still start but...)

On my Amiga I at one point made a pause switch by soldering stuff straight onto a pin on the CPU...

Post reply on HN