6509 dissection: IDKFA

[ttlworks]

[ttlworks]

That's all for now, and I'm happy to have the 6509 off my desk.


Some background info:
While waiting for Frank to finish that 6525 polygonisation, I had some spare time at my hands.

Some time ago, I had helped a bit with the C74 project, it was about building a 6502 compatible TTL CPU.

I remembered that we had some problems with getting the interrupt response of the TTL CPU cycle exact to the NMOS 6502.

So I said to myself:
"Hey, I had that 6509 dissection, let's take a little look at the interrupt logic in the 6509 silicon."
"Dang, that part is not easy to understand, and it has odd connections to a lot of other places."
"Hmm... need to find out what the control logic does for making sense of the interrupt logic."
"Hmm... need to find out what the control logic actually controls for making sense of the control logic."
And from there, things had escallated pretty quick.

But hey: if/when somebody is out to try building a NMOS 6502 compatible TTL CPU again,
I think now we know what the NMOS 6502 interrupt logic is supposed to look like.

[GARTHWILSON]

Amazing work, truly a labor of love! My boss and I were just talking yesterday about all the valuable design information that gets lost or discarded by companies everywhere, even if the company is still in business but no one is left who knows anything about the project, and it's lost in an unidentified file cabinet somewhere inaccessible in a store room. It would have saved a lot of work if Commodore Semiconductor Group had just said, "We know we can't make money on this anymore, so we're releasing this information to the public." However, they're out of business now, and I doubt that the engineers who left and went to Western Design Center took copies of those files with them. Does it even exist in someone's basement or museum anymore, or did it get destroyed? I suppose we'll never know. Anyway, thanks for your service to the 65xx community!

[ttlworks]

Garth, thanks for the kind words.
I hope, that my dissection gives others a better chance of understanding what really goes on inside a NMOS 6502.

The nice thing about old chips from the 70s..80s is, that the design teams were small and that the amount of transistors on a chip wasn't too big.
So there is "supposed to be" a fair chance that a lone little hobbyist might be able to dissect them at some level.
For nowadays modern chips, it's different.

Anyhow, Frank has that crazy plan to go for the rest of the MOS chips, and I'm trying to stick with him.


When I was a kid, I was aware that there are just flipflops and logic gates in these chips, and a lot of them,
and that the "Magic" lies in how them flipflops and logic gates are wired together.
After 40+ years of wondering how they might be wired together, things seem to become a bit more clear now...

[Dr Jefyll]

Awesome job, Frank and Dieter!! And thanks for the startlingly extensive writeup, Dieter!

There's more here than I can take in at one sitting. But here are a few questions that come to mind so far.

In this post you mentioned that, "BRK has one more step than the rest of the instructions: T6." But isn't it true that the total number of cycles for BRK is the same as that for an interrupt?

BRK is listed as a 7 cycle instruction, and from my point of view it begins with the cycle during which the opcode is fetched. I assume this corresponds to the cycle during which an interrupt sequence begins (by fetching an opcode but discarding it and replacing it internally with $00). Can you clarify, please, regarding "one more step than the rest of the instructions."

Question 2: I'm interested in the topic of the predecode section. In this post you mention, "Signal '21.A' is low for instructions which take two cycles, and where the ALU operation could be done in parallel with the next instruction fetch." Since you use the word "and," it sounds as if two separate conditions need to be satisfied. But perhaps what you mean to say is, "Signal '21.A' is low for instructions which take two cycles. These will be instructions where the ALU operation could be done in parallel with the next instruction fetch."

Final question (for now, at least): what does IDKFA stand for?? I am familiar with IDK (I don't know), but this new variation puzzles me. Congrats again on a great job,

-- Jeff

[ttlworks]

Dr Jefyll wrote:

Awesome job, Frank and Dieter!! And thanks for the startlingly extensive writeup, Dieter!

Thanks, Jeff. It sure was a lot of work.

Quote:

There's more here than I can take in at one sitting. But here are a few questions that come to mind so far.

In this post you mentioned that, "BRK has one more step than the rest of the instructions: T6." But isn't it true that the total number of cycles for BRK is the same as that for an interrupt?

True.

Quote:

BRK is listed as a 7 cycle instruction, and from my point of view it begins with the cycle during which the opcode is fetched. I assume this corresponds to the cycle during which an interrupt sequence begins (by fetching an opcode but discarding it and replacing it internally with $00). Can you clarify, please, regarding "one more step than the rest of the instructions."

We have two sequencers, one generating T0#..T1#, the other generating T2#..T5#, and their outputs go into the PLA.

And we have that T6 flipflop, its output does not go into the PLA.
It goes into some logic gates inside the "random logic area", which also is fed by the PLA outputs.
T6 flipflop _only_ is set when a BRK instruction has finished state T5.
This is done in the PLA by product term "26:T5.INT" (I had not picked that name, them MOS engineers had labeled it like that), which is Visual6502 node 370.
When the interrupt logic kicks in, it forces the instruction register to $00 (that's BRK), and fakes a BRK sequence for the rest of the CPU.

That sequencer thing is a bit tricky: instruction fetch seems to happen during T1, and to me it looks like ALU data operation hypothetically might happen during T0.
But as I already had said: I don't have the ressources for digging any deeper into it. And the next chip already is waiting to be dissected.
Hey, you could write a nice set of technical articles.

Quote:

Question 2: I'm interested in the topic of the predecode section. In this post you mention, "Signal '21.A' is low for instructions which take two cycles, and where the ALU operation could be done in parallel with the next instruction fetch." Since you use the word "and," it sounds as if two separate conditions need to be satisfied. But perhaps what you mean to say is, "Signal '21.A' is low for instructions which take two cycles. These will be instructions where the ALU operation could be done in parallel with the next instruction fetch."

When I'm cutting a piece out of the silicon to be dissected, I give it a number, for instance "21) instruction register".
When spotting signals going into (or out of) that section, and I don't really know what they are good for, I initially give them temporary names like "21.A .. 21.Z".
When I'm (more or less) sure, what they are good for and what they actually do, they get real names like "T11".
Means that I don't know for sure what the signal '21.A' actually causes/does, but I noted/stated my observations.

Some people label a "black sheep" a 'black sheep' when spotting it somewhere far away in the landscape, and usually this might do.
Others label it 'a sheep which appears to be black on at least one side' until they know for sure, what is technically more correct.
It has to be done this way, because else the dissection would be heading for the wrong track at some point when basing everything on assumptions.

Quote:

Final question (for now, at least): what does IDKFA stand for??

When typing in that cheat code, it depends on the game:
In DOOM, it instantly gives you unlimited health, weapons and ammo.
In Mechwarrior2, it instantly punches the ejection seat (plus you) out of the cockpit, while a message is displayed: "This ain't DOOM, bub."

Edit:
Thinking of it... that's a nice analogy:
When making use of the things here in this thread, depending on some factors you might not be aware of
this either puts you into "god mode", or brings you into serious trouble, or isn't useful at all for solving your current technical problem.

Quote:

Congrats again on a great job

Again: thanks, Jeff.

[fhw72]

ttlworks wrote:

....
But as I already had said: I don't have the ressources for digging any deeper into it. And the next chip already is waiting to be dissected.

Whoever is curious enought might want to take a look under the hood:

viewtopic.php?f=1&t=5695&p=81833#p89327

Have fun!

[org]

Great job! Now I'm going to cross-check with my 6502 schematics
If I find anything I'll be sure to write.

[ttlworks]

Thanks for the kind words.

If there are errors in our schematics,
they will show up in different places,
so cross checking increases the chance to get correct results.

Also great job with releasing the "Breaking NES Book",
I think I know how much work is necessary for digging into the 6502 that deep.

If you find anything in my schematics (or in your schematics), I'm trying to help.

[org]

The first thing I want to point out right after starting the comparison is that I absolutely do not understand where NOR, NAND, OR and AND are on the schematics. They all look the same to me

Also (as we already discussed in PM) - your circuits are optimized by de Morgan rules (or "demorganized" as we call this operation among ourselves). We didn't optimize on purpose so that the restored circuits are "DIE-perfect" and can always be compared to transistors, without too much stress.

It should be noted, the schematics are very clean, for nothing you scare in the beginning that long to look at them is dangerous to health. I'm fine

Since circuits can be compared until retirement, I'll post here as I go and mark each case study so we can refer to it.

Case_ADDSB7:
It looks like the input value of flag C must be in inverse logic.

[BigEd]

In case it helps, you can look over the same location in the 6502 here:
http://visual6502.org/JSSim/expert.html ... &zoom=10.7

[ttlworks]

Ed, thanks for jumping in.

org wrote:

I absolutely do not understand where NOR, NAND, OR and AND are on the schematics. They all look the same to me

I'm using logic symbols in EU notation, you are using logic symbols in US notation.
//In the CAD software I'm using, EU notation is default.

I'm aware that de_morganized logic is less easy to verify against the original,
but I think it's helpful for spotting/identifying function blocks and flipflops in the original.

org wrote:

It should be noted, the schematics are very clean, for nothing you scare in the beginning that long to look at them is dangerous to health. I'm fine

Thanks.
Nevertheless: if anybody loses his immortal soul when "navigating to deep in the zone",
the warning label is supposed to keep them lawyers at bay.

[ttlworks]

Case_ADDSB7:

There is a three_input NOR gate at the output of your circuitry (and in the silicon), generating what I called signal '25.G'.
Output of said NOR gate goes 1 if the three inputs are 0,
means in your circuitry the temporary C flag feeding said NOR gate has to store the C Flag in inverted form.

There is a three_input AND gate at the output of my circuitry, generating signal '25.G'.
Output of said AND gate goes 1 if the three inputs are 1,
means in my circuitry the temporary C flag feeding said AND gate has to store the C Flag in non_inverted form.

Case_ADDSB7: to me, my circuitry looks correct.


//To be fair, I have to warn you that my "demorganizing level" was configurated to "ruthless" during that 6509 dissection.

[org]

Case BRK_T6:

It looks like the inverter for brk6_latch1 is missing.

EDIT: "BRK7" is simply the name of the signal, which was obtained historically in the process of reversing, without any meaningful designations. That is, it does not mean that BRK-sequence in the T7

[org]

I also attach a mapping of your decoder designations to an adapted version of D.Hanson with 130 decoder outputs, which we also use in our project.