I have just bought the Apple Core disk after seeing this video. Your bug would not affect me, as I am emulating only a 6502, and I had tested my emulation using Klaus functional test, but the idea of running the tests from within the Apple emulator was to cool to resist. Thanks for sharing.
At 4:55 you say “[BIT] compares all of the bits in the memory location with the accumulator; if _any_ of the bits match then it clears the [Z flag]”. Not quite. BIT compares the _set_ bits only. If unset bits match, those don’t count. See the phrasing shown in the book at 4:27: “What this means is that if any bits *set* in the Accumulator happen to match any *set* in the value specified, the Z-flag will be cleared.” (Emphasis mine.) It’s a subtle difference; your code in Apple2TS is correct by doing a bitwise AND but it’s easy to be imprecise while talking about this.
Excellent point. I had to re-do that section like 15 times, because I kept saying it either backwards or imprecisely. And as you point out, I still didn't say it quite right. Thanks for pointing this out!
You're absolutely right. I misspoke - I meant to say BBR and BBS - branch on bit reset/set (which actually seem way more useful than this BIT immediate mode - too bad they aren't on all 65c02's).
@@codebythepound800 true, we could certainly implement them. It's interesting because right now they are implemented as undocumented NOPs with a cycle count of 1, whereas BBR/BBS are 3-byte instructions with a cycle count of 5. Assuming real software wasn't trying to use them as NOPs, it would be fun to implement them and write some test programs.
Very cool. I have a number of Apple IIs and IIes, will have to run against them. I'm especially interested in the app to identify installed hardware. Thanks!
It would be interesting to set a trap in the emulator on BIT# to see if any software ever used it. BIT is already obscure, BIT# only sets Z, is 65C02 only so introduces incompatibility with 6502, Z is very often already set as desired (eg in loops INX, BNE to repeat loop), and if Z needs to be reset CMP# can do so. So you have to need to fix Z and don't want to set N and C with CMP#. What use case was important enough to add it to 65C02?
Great question - I wonder if it was just for completeness. Western Design was already adding other BIT addressing modes. Maybe it was easy to add, and they weren't sure of the use cases so they just added it. Like you said, BIT itself is already obscure, yet they had that in the original 6502. It was probably hard to predict what programmers might find useful. Suppose that's true even today :-) I've been thinking of adding a "stop on instruction" breakpoint - maybe this would be a good excuse.
It's hard to create a perfect instruction set, but BIT# was a 65C02 instruction, so they had lots of feedback from people writing programs. Other 65C02 instructions are straightforwardly useful, such as BRA (you don't have to guaranteed Z or C status, or pay time and space for to explicitly set C as well as destroy the old C), PHX/PLX meant you didn't have to use another instruction and cycles and destroy A with a TXA/PHA or PLA/TAX, and the same story for STZ. But who asked for BIT#? Maybe the same guys who needed to flip bits with TSB/TRB and the Rockwell RMB/SMB? It would be interesting to instrument the emulator to make an instruction use census for various programs, counting both the static appearance of the instruction and the dynamic execution.
Great video Chris.. i'm glad the software is useful !
Thanks Dan! And thanks to you and Marc for creating these software programs.
we're not in kansas anymore...
this is the next best thing :)
Thanks!
I have just bought the Apple Core disk after seeing this video. Your bug would not affect me, as I am emulating only a 6502, and I had tested my emulation using Klaus functional test, but the idea of running the tests from within the Apple emulator was to cool to resist. Thanks for sharing.
Awesome, hope you had 100% success!
At 4:55 you say “[BIT] compares all of the bits in the memory location with the accumulator; if _any_ of the bits match then it clears the [Z flag]”. Not quite. BIT compares the _set_ bits only. If unset bits match, those don’t count. See the phrasing shown in the book at 4:27: “What this means is that if any bits *set* in the Accumulator happen to match any *set* in the value specified, the Z-flag will be cleared.” (Emphasis mine.) It’s a subtle difference; your code in Apple2TS is correct by doing a bitwise AND but it’s easy to be imprecise while talking about this.
Excellent point. I had to re-do that section like 15 times, because I kept saying it either backwards or imprecisely. And as you point out, I still didn't say it quite right. Thanks for pointing this out!
Excellent video and software!! Thanks for sharing
Thanks Rudy!
Im pretty sure tsb and trb are available on all 65c02 variants. The other specialized bit instructions werent though.
You're absolutely right. I misspoke - I meant to say BBR and BBS - branch on bit reset/set (which actually seem way more useful than this BIT immediate mode - too bad they aren't on all 65c02's).
We could always add them. :)
I have wondered why they didnt at least let the immediate form manipulate the overflow flag too.
@@codebythepound800 true, we could certainly implement them. It's interesting because right now they are implemented as undocumented NOPs with a cycle count of 1, whereas BBR/BBS are 3-byte instructions with a cycle count of 5. Assuming real software wasn't trying to use them as NOPs, it would be fun to implement them and write some test programs.
Very cool. I have a number of Apple IIs and IIes, will have to run against them. I'm especially interested in the app to identify installed hardware. Thanks!
Yes, that other Identify app is very cool. Definitely worth the €5.
It would be interesting to set a trap in the emulator on BIT# to see if any software ever used it. BIT is already obscure, BIT# only sets Z, is 65C02 only so introduces incompatibility with 6502, Z is very often already set as desired (eg in loops INX, BNE to repeat loop), and if Z needs to be reset CMP# can do so. So you have to need to fix Z and don't want to set N and C with CMP#. What use case was important enough to add it to 65C02?
Great question - I wonder if it was just for completeness. Western Design was already adding other BIT addressing modes. Maybe it was easy to add, and they weren't sure of the use cases so they just added it. Like you said, BIT itself is already obscure, yet they had that in the original 6502. It was probably hard to predict what programmers might find useful. Suppose that's true even today :-) I've been thinking of adding a "stop on instruction" breakpoint - maybe this would be a good excuse.
It's hard to create a perfect instruction set, but BIT# was a 65C02 instruction, so they had lots of feedback from people writing programs. Other 65C02 instructions are straightforwardly useful, such as BRA (you don't have to guaranteed Z or C status, or pay time and space for to explicitly set C as well as destroy the old C), PHX/PLX meant you didn't have to use another instruction and cycles and destroy A with a TXA/PHA or PLA/TAX, and the same story for STZ. But who asked for BIT#? Maybe the same guys who needed to flip bits with TSB/TRB and the Rockwell RMB/SMB?
It would be interesting to instrument the emulator to make an instruction use census for various programs, counting both the static appearance of the instruction and the dynamic execution.