Mail Archives: geda-help/2018/12/23/12:14:58
On Sun, 23 Dec 2018, richard lucassen (mailinglists AT lucassen DOT org) [via geda-help AT delorie DOT com] wrote:
>On Sun, 23 Dec 2018 17:15:14 +0100 (CET)
>gedah AT igor2 DOT repo DOT hu wrote:
>
>
>> >Uhhh, the latest version of OrCad I used was 3.20, IIRC the DOS-6.22
>> >version of 1989, I have never seen a better SDT than that version of
>> >82kB (!) in size (ex libs). I was already wondering if I could import
>> >Calay formatted netlists into pcb-rnd, but I didn't see the
>> >option :-(
>>
>> Netlist is cheap to implement. If you supply example files and
>> testing, that can happen in a few days.
>
>Even if it's 30 years old?
Yup. The cost of netlist import code is very low, so I can hardly resist
implementing import for any old format.
>
>> >It was 20 years ago that I used IRC. I'll try to install it. What IRC
>> >program do you advise? I use non systemd Debian testing.
>>
>> Im a console junkie so I prefer text based ones. I use ircII, but
>> irssi is popular too.
>>
>> Server: repo.hu
>> port: 6667
>> channel: #pcb-rnd
>>
>> there's no registration, ssl, cloaks or anything, just plain old IRC.
>
>I joined through the irc.debian.org server.
Sorry, that's the wrong server. Please use server repo.hu.
>I was already having the idea to pipe the netlist trough sed in order
>to get a gschem lookalike netlist, but I didn't try it until now. I have
>to look up in the docs which netlist formats OrCad can produce. Here
>is such a 30 year old Calay output format (which was needed by Layo1):
>
>/N00001 C3(2) R5(1) C2(1);
>/N00002 C2(2) Q3(2) R7(1);
>/N00003 C5(2) Q7(2) R8(1);
>/N00004 Q3(1) Q4(2);
>/N00005 Q7(1) Q8(2);
>/N00006 Q4(1) R5(2) R2(1) C4(1);
>/N00007 Q8(1) R10(2) R4(1) C1(1);
>
>[-- 8< -- snip -- 8< --]
>
>/N00085 Z6(1) C3(1) R12(1) R71(1) C13(1) C30(1) C35(1);
>/N00086 Z4(1) Q36(1) R60(1);
>/N00087 Z3(1) Q27(1) R39(1);
>/+15 Q6(3) Q5(3) Q2(3) Q1(3) Z7(1) C45(1) Q7(3) Q8(3),
> Q9(3) Q3(3) Q4(3) Q13(3) Q12(3) Q18(3) Q11(3),
> Q10(3) Q16(3) Q17(3) Q14(3) Q15(3) Q22(3) Q21(3),
> Q27(3) Q20(3) Q19(3) Q25(3) Q26(3) Q23(3) Q24(3),
> Q31(3) Q30(3) Q36(3) Q29(3) Q28(3) Q34(3) Q35(3),
> Q32(3) Q33(3);
>/GND C11(2) C8(2) Z2(2) R71(2) Z3(2) Z4(2) Z6(2) C45(2),
> Z9(1) C46(1) Z5(2) P1(3) R9(2) R6(2) Z1(2),
> P2(3) C22(2) C19(2) R30(2) R27(2) P3(3) C26(2),
> C27(2) R44(2) R45(2) R42(2) R43(2) P4(3) C44(2),
> C41(2) R66(2) R63(2);
>/-15 R3(2) R1(2) C46(2) Z8(1) R19(2) R4(2) R2(2) R24(2),
> R21(2) R20(2) R23(2) R22(2) R39(2) R36(2) R35(2),
> R38(2) R37(2) R60(2) R57(2) R56(2) R59(2) R58(2);
>
>And the component file:
>
>value component shape ? ? ?
>
>+15 Z7 EILAND08 1600 4736 1
>-15 Z8 EILAND08 2112 4736 1
>100N C1 CMKT03-2 2176 2880 1
>10K R5 XR-04 1152 2432 0
>10K R6 XR-04 448 2432 0
>10K R7 XR-04 1024 2688 0
>10K R8 XR-04 512 2048 0
>10K R9 XR-04 512 2240 0
>10K R10 XR-04 1984 2240 1
>
>[-- 8< -- snip -- 8< --]
>
>I will have to find out what the 3 values on the right mean.
>
Cool! these two files would make up a full sch import flow. They look
simple enough. If the shape column is the footprint name, we probably
won't need to know the last 3 values.
- Raw text -