I am willing to contribute a few of those but, unfortunately, I couldn’t find a datasheet with official footprints. Does anyone have more info on these?
Thanks.
One does not necessarily need a suggested footprint to make one. The dimensioned drawing of the part should suffice. Ideally such a drawing should include the tolerances of the part. See Tutorial: How to make a footprint in KiCad 5.1.x (From scratch)? (section Through hole parts)
The thing however is that neither the documents on digikey nor the one linked by @ZASto list tolerances. And they only list suggested PCB layouts for 2.54mm grid parts.
I’m not really surprised about this.
Those have never been used much, and the last 20 year or so anything “high density” is SMT stuff.
However, it’s very easy in KiCad to make your own footprint. There are even a bunch of wizards in KiCad to make footprints.
The only problem is with the library management, which has a few pitfalls.
Before you can create your own footprint, you must create an (empty) library in a writable location.
(KiCad’s default libraries are not writable for users).
You must also add your library to the library search list in PcbNew.
Creating the footprint it’self is trivial with the wizard:
Starting from page 18(140) in my linked document are dimensional drawings for 1.778mm spacing sockets.
I think that tolerances for DIP packages are not much of relevance
Yes, the footprint is indeed for a legacy part: the C64c Super PLA but old MC68000 CPUs are also available in that package. I am slowly creating a “KiCad Retro Library” containing all the components from old 8-bit computers that I can’t find in the standard libs.
The datasheet posted by @ZASto says that the pin diameter for these SPDIP sockets is 0.5mm, i.e. 0.1mm smaller that the 2.54mm spaced ones. I’ll keep that in consideration.
@Rene_Poschl, @paulvdh, your suggestions saved me a lot of time! I wasn’t aware of the wizard!
The tolerance of the lead will go into how one determines the required hole diameter (max size + 0.2mm) without tolerances one needs to guess here. Which is disappointing to say the least.
Are you considering publicly releasing your library? If so, might I humbly suggest that you consider making your library either exactly or closely conform to the standards that the KiCad libraries are held to (at least the new parts, there are some older libraries that don’t conform but the volunteer teem that manage the library haven’t had time to get to with their other priorities), referred to as the KLC (KiCad Library Convention). You can access the KLC here:
If you do follow the KLC then your library will “fit in” with the supplied libraries.
(Granted, for my own personal use I do deviate from KLC on some details. Square pin 1 on ALL footprints and pin numbers on ALL symbols is my biggest deviation, and I’ve created my own parallel libraries for my commonly used parts where I “fix” the “issues”. But, then, I’m not publicly releasing my parallel libraries…)
Yes, sure!
The library will end up on GitHub once I am done replicating the first schematic, the C64C (250469 rev.A.)
I was aware of the KLC and my plan is to validate the library with the helper scripts before release.
However, I am still not sure if it makes sense to strictly follow the naming convention defined in the guidelines; that part might diverge a bit.