Libraries for Western Design Center 6500 series ICs.

[McNeight]

• Includes symbols for CPU ICs:

IC Datasheet	DIP	PLCC	QFN
W65C02
W65C816

• Includes symbols for Interface ICs:

IC Datasheet	DIP	PLCC	QFN
W65C21
W65C22
W65C51

• Includes symbols for MCU ICs:

IC Datasheet	PLCC	QFN
W65C134
W65C265

• Passes all tests from KLC helper scripts.

---

All contributions to the kicad library must follow the KiCad library convention

Thanks for creating a pull request to contribute to the KiCad libraries! To speed up integration of your PR, please check the following items:

• Provide a URL to a datasheet for the symbol(s) you are contributing
• Provide a screenshot of the symbol(s) from the symbol editor with the pin types visible
• Ensure that the associated footprints match the official footprint library
  • A new fitting footprint must be submitted if the library does not yet contain one.
• If there are matching footprint PRs, provide link(s) as appropriate
• Check the output of the Travis automated check scripts - fix any errors as required
• Give a reason behind any intentional library convention rule violation.

---

Be patient, we maintainers are volunteers with limited time and need to check your contribution against the datasheet. You can speed up the process by providing all the necessary information (see above). And you can speed up the process even more by providing additional info like the screenshot of the symbol editor pin table (or for high pin counts converted to csv) sorted in the same way as the pin table in the datasheet and a direct link to the datasheet page that contains the pin table.

[CLAassistant]

All committers have signed the CLA.

[ghost]

Hi,

please add screenshots and provide links to datasheets. Without them a review is really hard.

Related: #2780

[McNeight]

Hi there.

I included links to the datasheets within each of the new symbols. If I am supposed to include the same links within the merge request to make the reviewers' job easier, then the merge request instructions should probably be updated to reflect that.

The datasheets used were:

• CPU
  -- http://www.westerndesigncenter.com/wdc/documentation/w65c02s.pdf
  -- http://www.westerndesigncenter.com/wdc/documentation/w65c816s.pdf
• Interface
  -- http://www.westerndesigncenter.com/wdc/documentation/w65c21.pdf
  -- http://www.westerndesigncenter.com/wdc/documentation/w65c22.pdf
  -- http://www.westerndesigncenter.com/wdc/documentation/w65c51n.pdf
• MPU
  -- https://www.westerndesigncenter.com/wdc/documentation/w65c134s.pdf
  -- https://www.westerndesigncenter.com/wdc/documentation/w65c265s.pdf

Here is a PDF of all of the symbols across the three libraries:
6500 Series.pdf

-Neil

[na-g]

Accepting this would obviate the need for my PR, #2780, which only adds the w65c816s.

[McNeight]

Accepting this would obviate the need for my PR, #2780, which only adds the w65c816s.

Then please double check the work done in this PR and make sure that the symbols are correct. I don't claim to always be correct, and I don't claim that my layout is the only way it should be done.

I've based the symbol designs themselves on example schematics from WDC. For example the W65C02 symbol is based on the schematic for the W65C02DB Developer Board.

[na-g]

@McNeight I think given the feedback I received on #2780, the address pins on the MPUs/MCUs should be OUTPUT.

[na-g]

For the W65C816, W65C02, W65C134, and W65C51N, I can't find text in the datasheets indicating that a decoupling capacitor is needed on each VSS pin, so the VSS pins should be stacked as per https://kicad-pcb.org/libraries/klc/S4.3/ . Full disclaimer, I am not a reviewer and I don't have any designs in the tree. I think the image of the proposed symbols that the reviewers want is supposed to show the pin types. @cp-aquila, or @myfreescalewebpage could you verify that the info in this message is correct?

[myfreescalewebpage]

I think the image of the proposed symbols that the reviewers want is supposed to show the pin types. @cp-aquila, or @myfreescalewebpage could you verify that the info in this message is correct?

Yes but not only:

• The image indicate the complexity of the pull request. Which is very nice to have when you are a reviewer because if you know you have 10 minutes free to make a small review then you will check for a simple symbol to review.
• The image is clearly helpful when the design is to be reworded a lot. For example pin length, general position of pins, etc. In this case I indicate I have just checked globally the pull request but it is not a full review, and I make a first set of comments. I do not open the symbol on KiCad. When it looks better I check with KiCad at this time.
• Depending the langage on your machine, the pin type is translated and personally I'm able to check when this is English of French, but that's all.
• And finally the image is nice to have to document the pull request.

Anyway I never ask absolutely for the image, but for the above reasons I clearly start the review of symbols with an image, description of the modifications, datasheet link etc as requested in the template.

When the symbol is reviewed I never ask to update the image too. But sometimes it can be nice and helpful.

[McNeight]

@myfreescalewebpage I have since included a PDF of all of the symbols in a single schematic at https://github.com/KiCad/kicad-symbols/files/5087759/6500.Series.pdf

Is this sufficient, or should the images be screen captures from within the Symbol Editor? If they should be individual images from within Symbol Editor, then perhaps the documentation should be updated to reflect this?

[ghost]

Did you rebase this branch? Or why are there 129 commits?
Whatever you did, it is not optimal because:

• TravisCI will now check all those commits and its output will be full of warnings/errors of unrelated parts
• Looking at the diff in the github web-frontend also shows unrelated changes.

[McNeight]

@cp-aquila Based on the suggestion from @myfreescalewebpage I did rebase against master to remove the changes I'd performed on sym-lib-table.

Since this pull request has a near zero chance of being merged into master before everything moves to GitLab anyway, I'm going to just close this pull request and recreate it at GitLab some other time.

-Neil

[myfreescalewebpage]

ok @McNeight

[na-g]

@McNeight, thanks for all the work you put into this. I wish it could have been merged. I hope that after the transition to GitLab, things can progress more quickly. With the Ben Eater videos, and such it seems that there is renewed interest, and this will be valuable to a number of hobbyists, myself included, and the 6502 community.