• Please review our updated Terms and Rules here

Build your own PDP 8I, Part 3..

Hi All;

Dave, Thanks for Your patience, with me.. I have been really hoping to Hear from You and what You thought on the whole thing..
"" By all means 'play' with signals to see what the effect is - but because something starts to work I wouldn't make the change 'permanent' until you identify the theory behind why it is working now and wasn't before. ""

I have not nor was I about to make the change permanent.. Which is why, I did the change on the BreadBoard and NOT on the System itself..
"" until you identify the theory behind why it is working now and wasn't before. ""
Which is why I need to carefully read and copy what you had to say in the last couple of postings..
"" It only works by accident - not by design! ""

"" If you have 20 faults in your wiring you can end up going down quite a few "dead ends". As I have said before (sorry to keep labouring the point) your debugging needs to be 100% methodical so that you fix 1 bug, then the next, then the next and so on. It's a painful process - but the only one. If you introduce what you think (in error) is a bug fix - you have just created yourself a new bug for the future instead of fixing one now. ""
Which is Why I posted about it not working correctly.. I knew I didn't understand enough about what was going on and what was happening or not happening..

"" However, if you put binary '000' (an AND instruction) into IR<0..2>; the OPG1 instruction will still be executed! This is clearly incorrect! ""
I will try this and let You know the result..

"" If you put '111' in IR<0..2> (a 7xxx instruction) do you see L5 pin 9 (/7 output) go low during the EXECUTE phase of your instruction? If not, do any of the other outputs from L5 go low (especially pin 5 - /JMS)? I have a reason for asking this - as I got the sense of my MUX gate input wrong (L6 pin 1) when I did my LOGISIM implementation.

L5 pin 12 (D input) should be low and L5 pins 15, 14 and 13 should follow IR<0..2>. When you are loading values into the IR - do you correctly see IR<0..2> appearing at L5 inputs A, B and C. If not - you need to find out why not. ""

I will try this and let You know the result, of this as well..

Right now I have an old Radio on the Table, so it will be awhile before I try anything..

THANK YOU Marty
 
Sorry - now I have re-read my last post again it sounded like I was being a bit 'off'.

I have just had a long, tiring day at work which (unintentionally) came through in my post for which I apologise.

I suspect your problems are around L5 somewhere - so let's see if we can get that working next.

Dave
 
Under 'normal' circumstances, L8 pin 6 (Q output) should be '1' thus enabling IR<0..2> to be passed through the 'switch' (L6) to the A, B and C inputs of L5 (7442).

L8 pin 6 is set to a '1' by the application of a '0' to the /PReset input of L8 on pin 5 (CONTP.L).

H13 pin 10 (Q output) should be a '0'. If a 'manual' command is entered from the front-panel buttons (e.g. LDIR) - H13 Q output will go to a '1' for the duration of one EXECUTE cycle and will then be forced back to '0' again by CP7.L.

As a result, L5 should always decode the instruction placed into IR<0..2> on its outputs (an active LOW output signal for the instruction that is decoded).

If H13 pin 10 goes to a '1' - all the instruction decode outputs from L5 will go inactive (high).

If L8 pin 6 goes to a '0' - binary '100' (4) will be 'forced' into L5 by the action of switch L6 and will be decoded as a 'JMS' instruction by L5 (i.e. this is the way interrupts are processed by forcing L8 pin 6 to a '0' by the introduction of state output A0 into the /K input (pin 3) of L8 (possibly coincident with CP7.H into the J input - but this is supposition on my part for now until I go and check).

Hopefully this little description will help unravel the next bug? I am also learning a lot by trying to explain the function of the circuit.

Dave
 
Last edited:
Hi All;

I put the Radio on hold for today..

"" Sorry - now I have re-read my last post again it sounded like I was being a bit 'off'.

I have just had a long, tiring day at work which (unintentionally) came through in my post for which I apologise. ""

No need for an apologise.. I didn't see any reason for an apology..

I have the System back here on the table..
I have tried both '0000 and '7000, on the Instruction Register..
And it seems to decode, both alright at the end of the CPx cycles..
"" L5 pin 12 (D input) should be low and L5 pins 15, 14 and 13 should follow IR<0..2>. ""
Yes, it does..
But, at CP4, in both of them it does decode pin 5 going Low..

I have put back the 7402, and it does the same thing..
"" If you put '111' in IR<0..2> (a 7xxx instruction) do you see L5 pin 9 (/7 output) go low during the EXECUTE phase of your instruction? ""
I am not sure whether it's the EXECUTE phase, but on the 7442, pin 12 goes Low (Bar Q or /EXECUTE) for the proper pin to show Low..
But, it does decode properly..

I see that You Posted another helpful posting..
I need to check it out..

I am going to put the 7442 on the BreadBoard, with the Led's on it to help me decipher what is happening, like I did the 74109..

"" Hopefully this little description will help unravel the next bug? I am also learning a lot by trying to explain the function of the circuit. ""
Me, too..
I just finished copying the Information from posting #119, and #120 and #123.. Great stuff..
"" your debugging needs to be 100% methodical so that you fix 1 bug, then the next, then the next and so on. ""
My biggest problem is Identifying what is the Next Bug and not creating another future bug that will need fixing..

THANK YOU Marty
 
Last edited:
"But, at CP4, in both of them it does decode pin 5 going Low.." - this seems not right. The only thing that should happen at CP4 is an OPG1 RAR in response to IR8 being set. If a JMS is being decoded here - then something is incorrect. Try and chase back what is going on - and follow CP4 to see if it goes to somewhere it shouldn't.

The decoded output from L5 should be valid all the way through the EXECUTE cycle. Monitor the output from pin 6 of L9. This signal should be a '1' during the EXECUTE phase of the instruction. If the output(s) from L5 change whilst L9 pin 6 is a '1' - then we have to find out why.

A little 'trick' may be to remove the F1 signal from the input of the gate E11 with the output pin 11 on the schematic containing the IR(L) signal (with flip-flop G6) - LD14. This gate doesn't have it's input pins numbered on my schematic. Tie the unused input to E11 (that you have just removed F1 from) to '1' to prevent it from floating and causing us trouble whilst debugging. This 'hack' will prevent IR from being loaded during the FETCH cycle at time F1. The only way to load IR is now from the panel (which is exactly what we want). Deposit your instruction to test directly into the IR. Any bugs present within the FETCH cycle will not now overwrite our instruction in IR and we can check out L5 in isolation. Don't forget to write this 'hack' on a red 'stick-it' note so we don't forget to re-instate F1 when we have finished debugging the logic around L5!

Dave
 
Hi All;

Dave, Thank You for Your information..
Officially, I have CP4.L going to the following places, L11, pin 5, where it starts.. K3, pin 12, (for the Halt Instruction) where it was changed from CP5.H and K12 pin 5.. (RAR).. The Halt instruction was changed, per Your Schematic, but I will check it for sure and make sure I copied/read correctly..
Yes, Your Schematic or at least the copy I have shows it going to CP4.L, since there is no CP4.H
I will also, check the wiring on the Board to make sure of what I have actually wired..

Looking at the Lab Manual, The Halt instruction, should be connected to CP3, and OPG2, and IR10..
So, can I change it to CP3.H ??
I have changed it to CP3.H, and It makes NO difference, at CP4, L5 pin 5 goes Low..
On L5, pin 15 is Low, pin 14 is Low, pin 13 is High and pin 12 is Low..
Dis-avow the above two sentences, except for the changing of the signal to K3.12..

I just Realized I have been Looking at the WRONG IC, I have been Looking at L11 and Not at L5..

But, I think I did find a possible Mistake with CP4, so not all is Bad..

So, NOW, I can truely Report on what is happening with L5, During any of the CP cycles, pin 12 of L5 is High, thereby disabling any of the commands from L5..

THANK YOU Marty
 
Last edited:
Yep - there's obviously an inconsistency there between the schematics and the table in the Lab Handbook!

I would have said the HALT logic should have CP3.L (and not CP3.H). By the schematics having it wired to CP4.L - it only delays it to the next clock pulse (i.e. it will still work irrespective of whether CP3 or CP4 is used). Use whichever you wish - just make sure you document them for posterity!

So I am still intrigued as to why the decoder IC (L5) decodes for /JMS during CP4... We need to identify why. Does L6 pin 1 go to '0' by any chance simultaneously?

Dave
 
Hi All;

Dave, Thank You for your Help..

SEE, my posting #126 above, as we were most likely posting about at the same time..
For my Mistake !!!!
I will change CP3 from High to CP3 Low, The reason for my putting it at High was before it was at CP5.H..
So, I am unsure which to change it to CP3.L or CP3.H ????

"" Does L6 pin 1 go to '0' by any chance simultaneously? ""
NO..

Can I re-attach the F1 Signal now ?? Or should I leave it, for further Debugging ??

THANK YOU Marty
 
Last edited:
Yep - looks like we crossed over with posting there.

I'll guarantee it should be CP3.L.

OK - so we were looking at the wrong IC - so let's forget everything about that and start again.

So, during the EXECUTE phase L5 pin 12 is a '1' - not good news.

This should come from H13 pin 10 - so I assume this is a '1' as well?

If so - why? Let's double check the wiring to H13.

J input (H13 pin 14) should be '0'.

/K input (H13 pin 13) should be CP7.L.

/CLR input (H13 pin 15) should be '1'.

Clock input (H13 pin 12) should be clocking away...

What is the state of H13 pin 11? If it is a '0' then this will be PREsetting H13 pin 10 and will account for the problem.

When a manual command (e.g. something from the front panel) is being processed - SWONMANP briefly pulses LOW and sets H13 pin 10 to a '1' - thus inhibiting decoding of the 'normal' instructions during the EXECUTE phase - and processing the desired 'manual' command.

CP7.L should clear the H13 flip-flop pin 10 after the manual command has been processed in readiness for the next 'real' instruction.

I would still leave our F1 signal disconnected for now. We will be 'forcing' instructions into IR next and we will want to see what happens without anything overwriting IR for us.

Dave
 
Last edited:
Hi All;

Dave, Thank You for being so forgiving..

I have Put B5, (H13), on the BreadBoard, with the high side on Led's..
I also, will be copying What You have Written.. And going through it one line at a time..
I have it on the Led's and it's initial state is..
pin 9 High,
pin 10 Low,
pin 11 High,
pin 12 clocking away,
pin 13 High,
pin 14 Low,
pin 15 High..
After pressing IR(L), then CP0 has
pin 9 Low,
pin 10 High,
pin 11 Low,
pin 13 High..
At CP1 it has
pin 9 Low,
pin 10 High,
pin 11 High,
pin 13 High..
At CP7 it has
pin 9 Low,
pin 10 High,
pin 11 High,
pin 13 Low..
After CP7
pin 9 High,
pin 10 Low,
pin 11 High,
pin 13 High..
Does this Help ??
Also, L5 (B7) pin 12 follows what H13 (B5) pin 10 is doing..

Dave, on a side note, I am starting to copy into another NoteBook, Your Schematic for Your MicroCoded 8I..
I have copied everything in basic form, with only the I/O and the MicroSequencer to go..
Monday, I will copy the MicroSequencer and then the I/O and then anything else that need to be expanded..
Dave, I am truely amazed at what You have done, and figured out How to do it !! Especially, the CCMUXes and the MicroSequencer..
How did You ever figure it out ??
I have a few questions -- What are the connections to the IntenFF, as I am not sure ??
Also in the microSequencer the memory with it, Is that Rom or Ram ??
And also what size is the Memory for the main prom in the Microprogram ??

THANK YOU Marty
 
Last edited:
Marty,

Thanks for your extremely well documented post.

And yes it helps a lot - but for a different reason. What you described is absolutely 'signal perfect' for the working of H13 pin 10... This (unfortunately) contradicts what is said in post #126 for the state of L5 pin 12 (= H13 pin 10).

My only conclusion, therefore, is that sometimes things work and at other times things don't work (or work differently) which (if memory serves me correctly) is where we were with the previous wire-wrapped board. At times like this I tend to write a list down of what could possibly be wrong - and work my way through the list one item at a time (not necessarily in the order of the list I hasten to add). So, here goes:

1) Power supply problems. Usually the cause of many issues. What type of power supply do you have (is it regulated or not for instance) and can it supply the necessary current for your board under all circumstances without the Voltage dipping? A mentee of mine had a problem a while ago where everything seemed to work with a piece of equipment he was developing - except that sometimes it would go haywire. We eventually worked out that there was an occasion where the current that the equipment drew was too much for the power supply unit and the voltage dipped momentarily - causing his equipment to fail. A more 'beefier' power supply unit solved the problem.

2) How is the current from the power supply to the board - and the power rails on the board themselves - distributed? Are there some excessive volt drops somewhere? You should be able to determine this by measuring the voltages on the power pins of the ICs furthest away from the power supply source (that is at the end of the longest pieces of wire). I usually arrange my power rails in a 'grid' to minimise the voltage drops as far as I can.

3) Decoupling capacitors. Have you added these or not yet? Sometimes you can get away without them - other times not. My preference is to use one decoupling capacitor per IC package on a 'production' card - but on a 'home-brew' card perhaps two (or more) per row or column of IC's on the power grid. It depends on how 'lucky' you feel. I use 0.1 uF ceramic discs (or whatever is the modern version) in conjunction with a few 4.7 uF tantalums interspersed here and there. Make sure the voltage rating of the tantalums are at least twice (preferably 3 or 4 times) the rail voltage they are across. Don't forget that tantalum capacitors are polarised.

4) Faulty ICs. Where did you get them, do you 'trust' the supplier? Have you tested them?

5) Faulty IC sockets. A few years ago I built a DSKY (DiSplay and KeYboard) for my Apollo Guidance Computer that I was constructing. It had a couple of 40 pin Maxim IC's that I used for multiplexing the LEDs. I used wire-wrapping construction. I noticed that one of the ICs was 'playing up' occasionally. I tracked it down to a bad contact between one of the IC pins and the socket. I wasn't going to remove the IC socket and re-do the wire-wrapping - so I under up soldering the bad IC pin to the socket. Nasty - but it has worked ever since.

6) Non debounced switches. I noticed when I did my LOGISIM implementation - and ran everything at a slow clock speed - that strange things happened occasionally when I used the simulated front panel. I tracked this down to me just 'poking' the button too fast with the result that the signal had gone away before all of the Clock Pulses (CPx) had been processed for that manual instruction. This caused odd things to happen. For example, a DEPOSIT request may have occurred correctly during CP0 but the address doesn't get incremented during CP6 if the DEPOSIT signal has gone away from the pushbutton. This was 'me' poking the pushbutton too fast - but I suspect a similar thing could happen if the contact was to bounce. The panel PCB itself seems to use two inverters from a 7404 as a cross-coupled flip-flop. Cheap - but effective.

7) Input pins to ICs left floating. There are two issues here. One is where we have a floating input to a gate that is used. The other is where there are floating inputs to gates that are not used. A floating input to a gate that is used is a 'no-no'. The floating input should be tied to 0V directly or pulled high via a 10 kOhm resistor. The difference is that tying a pin to 0V could result in a 10-fold increase increase in the current flowing into/from the input pin. You need to identify whether to pull the input high or low depending upon the function of the input pin. Pulling it the wrong way may cause the gate/chip to not work as intended. Notice that I also said pull the pin high via a 10 kOhm resistor and not connect the pin to +5V. With 74xx series devices you should NEVER tie an input directly to +5V - only via a resistor. It may work for a while - but the input pin has a lower tolerance to over voltage and damage to the input/gate can occur over time. Other families of logic devices (e.g. 74LSxx) can have inputs directly tied to the +5V rail (but I wouldn't do this myself). You can use one pull-up resistor for up to (say) 5 input pins to save on adding resistors. Again, this is not a "hard and fast limit" but a bit fluid. You should be able to check visually if a pin is not wired up of course. I developed a little test probe on breadboard a while ago to check for floating input pins (but it has been replaced no by a commercial logic probe now). If you want I can described what I did in a separate post so you can build one if this would be useful. Floating inputs on unused gates will generally not cause a 'logical' problem - but will increase power supply noise and power dissipation (especially if you haven't installed decoupling capacitors). Again, you should pull high all unused inputs of all unused gates via 10 kOhm (shared) resistors.

8) Pins not wired correctly. This was where we were with our debugging up until today. A wiring fault should manifest itself as a 'logical' fault (i.e. it should occur when the right circumstances are present). This is what we have been assuming - but we now appear to be seeing 'random' faults with how the PDP-8 is working. I don't like these sorts of problems... These can occur for the reasons given above or (possibly) due to the random power-up state of the J/K or D-type flip-flops. Do you always depress CLEAR after you power-up the PDP? If not - you should. Assuming all of the combinatorial logic (e.g. the NAND/NOR/ALU/MUXs and decoders) are wired up right - they should produce an output that is a function of the function of the IC device and it's inputs (i.e. a NAND gate should always function as a NAND gate assuming none of the above issues apply). Problems can occur, however, where 'state-based' logic (e.g. counters and flip-flops) are present and it is not defined what should happen on power-up. This is where I would like to go back to and follow the logic through once again from the inputs to the counters and flip-flops to see that everything is initialised properly.

So, going all the way back to schematic LD8 :-

i) Can you confirm that CLR.L is always high until you press the CLEAR button whereupon CLR.L goes low.

ii) Can you confirm that CONT.L is always high until you press the CONTINUE button whereupon CONT.L goes low.

iii) Can you confirm that CLRP.L is high, CLRP.H is low, CONTP.L is high with no buttons depressed.

iv) Can you confirm that CLRP.L pulses LOW for one clock cycle when the CLEAR button is depressed.

v) Can you confirm that CLRP.H pulses HIGH for one clock cycle when the CLEAR button is depressed.

vi) Can you confirm that CONTP.L pulses LOW for one clock cycle when the CONTINUE button is depressed.

vii) Can you confirm that the above behaviour is consistent when tried a number of times.

I will work on the next logical progression to see what happens to the flip-flops when we press CLEAR and then CONTINUE.

Sorry for the lengthy post - but I thought I would get a lot of my thoughts down on one go for you to "mull" over.

I figured most of the microcoding stuff out by myself (but used the internet to draw on some good ideas). Microcoding is just something I have been interested in for years - but never had a project to try out my ideas on (until you came along with your excellent book find).

I have just seen that you added a couple of questions to your last post...

There are two inputs to INTENFF and one output (although it looks like one input and two outputs as I have drawn it). INTENFF is a set/reset flip-flop. Set by SET_INTENFF and reset by CLEAR_INTENFF. The output is Q_INTENFF. The D and CLK inputs are pulled high and low respectively to prevent operation of the D part of this flip-flop (I even have to tie 'unused' inputs in the simulation - otherwise it complains at me whereas 'real' hardware just behaves erratically as discussed above).

The micro sequencer is ROM (although the LD30 in the book had RAM so that it could be changed easily by the students). My micro sequencer uses 128 Words of 32 data bits. In reality I would probably round it up to 256 Words of 32 data bits to allow for expansion of the instruction set in the future!!!!!

Dave
 
daver2 said:
Marty,

Thanks for your extremely well documented post.
.....
The micro sequencer is ROM (although the LD30 in the book had RAM so that it could be changed easily by the students). My micro sequencer uses 128 Words of 32 data bits. In reality I would probably round it up to 256 Words of 32 data bits to allow for expansion of the instruction set in the future!!!!!

Dave
Click to expand...

And thank *you* for your thoughtful and extensive discourse! (I just get to be the peanut gallery while Marty galley-slaves away at the oar ...)

Can you share the design & ROM contents for your sequencer?

-----
paul
 
Hi All;

Dave, Thank You for Your intense Posting..
Tomorrow, I will post most of the Answers..
For now, On the Power Supply, It is a Dell PC Power Supply Unit, with 5 volt 22 Amp rating, that has other voltages as well, but none of them are used..
Remember, when I re-started this board that I posted both pictures and description of my Power wiring..
Almost all Ic's have both Vertical and Horizontal wires going to each of them.. I used the Cap pins for the Horizontal wires and the IC's for the vertical wires..
Tomorrow, I will measure the voltages for You and report back.. As, well as all of the other questions that I can answer..

And Paul, Thank You for Your encouraging words..

THANK YOU Marty
 
Last edited:
"A floating input to a gate that is used is a 'no-no'. "

It is easy to assume that because you didn't wire anything to a pin that there is nothing on it. You would be wrong. There is always leakage and crosstalk, especially in a circuit that operates well into the RF range. Consider for a moment that each and every bit of those 600' of 30 ga. wire you used is an antenna. The problem is that you have no idea of or control over what might in fact be on that pin, or what effect it might be having on your circuit when it is running. And that's why its important to wire it in such a way that YOU are in control of that pin, and not leave it up to "The Flying Fickle Finger of Fate".
 
I have been going through all the flip-flops and counters to see how they 'should' power-up and sort themselves out - and have identified an anomaly. I will post the correct sequence tomorrow as it is getting late in the UK and I don't want to write something that I screw up whilst I am too tired!

The anomaly is the RUN input to K8 pin 12. The RUN flip-flop is the second half of L9 which requires a CLRP.L pulse to initialise the state to "not running" but (and here is the rub) a clear pulse can't be produced because it is running! It appears that the CLRP and CONTP pulses can only be produced if the machine is not running.

If the machine happens to power up in running mode - you don't appear to be able to stop it! There is the possibility (however) of using single step to initially stop it and then issuing a CLEAR.

I will think about this a bit more during work tomorrow.

Dave
 
daver2 said:
My microcoded LD30 was posted back in post #106.
Click to expand...

Thank you for the pointer; I missed that completely. My job has run-me-over in the past 2 weeks and I've been pretty worthless about following much of anything not job-related :-<.

Both you and Marty are amazing, in your own ways :->. Thank you both for continuing to pursue this so diligently.

I wonder if anyone has ever cross-checked any of this control logic against the 8/I maintenance prints?

And if not, would doing so be beneficial?
 
"If the machine happens to power up in running mode - you don't appear to be able to stop it! There is the possibility (however) of using single step to initially stop it and then issuing a CLEAR."

It would be desirable for the machine to power up into a known initial state. Perhaps the addition of a "System Reset" switch or button that forces the various state control hardware into the desired configuration should be added.
 
Hi All;

Dave, and Everyone, Thank You for the encouraging postings..

I will probably make this into multiple postings..

"" And yes it helps a lot - but for a different reason. What you described is absolutely 'signal perfect' for the working of H13 pin 10... This (unfortunately) contradicts what is said in post #126 for the state of L5 pin 12 (= H13 pin 10). ""

"" My only conclusion, therefore, is that sometimes things work and at other times things don't work (or work differently) which (if memory serves me correctly) is where we were with the previous wire-wrapped board. At times like this I tend to write a list down of what could possibly be wrong - and work my way through the list one item at a time (not necessarily in the order of the list I hasten to add). So, here goes: ""

I am not sure that even in posting #126, that I had stated the true L5.. I by that time had know about my confusion, and I may have still been confused, when stating the status of L5..

So, I have tried putting an Led, via a wire (my traveling status Led) on pin 12 of my IC clip..
On B3 (L11), it shows during CP time, pin 12 Is Low..
On B7 (L5), it shows during CP time, pin 12 is High..
Before and after CP time it is a Low..
And It is doing exactly as I stated in posting #130..
And, so far it has always repeated doing the same thing on each of the two Ic's..
I am going to go back and check my documented postings..

So, it may not be as Bad as we had thought..

But, I think It would and it is a good idea to go thru what You posted in posting #131..

THANK YOU Marty
 
Last edited:
Hi All;

Dave, I found in reference to Your posting #131..

Numbers 1 and 2 Power Supply Issues..
I just did a measurement, and it is alot different than I expected..
At the power Supply wires, where they are connected to a set of Alligator Jumpers, the voltage is 5.02,
where the alligator clips to the Board is 4.76..
On the corners of the Board it is the following::
Top Right of the IC array 4.70,
Top Left on the IC array 4.65,
Bottom Right of the IC array 4.68, and
Bottom Left on the IC array 4.64..
So, this definately need some work and improvement,
I am very surprised that from Right to Left on a Row that there is such a voltage drop, now .4 or .5 volts isn't much but when I am in the 4.60's it might make some difference on the IC response..
And these voltages are when it is on but not running..
So the First improvement, is to take care of the voltage Drop on the Alligator clips, and then see where things stand..
The Alligator clips are just clipped onto wires..
The Alligator wire is alot thinner than I had previously thought..
So, they need to have the alligator ends clipped on the Power Supply End, and attached..
I found one of my Jumper wires, was not conducting as it should, I found this out when It quit working, and I substituted another jumper for it, and the voltage increased..
I now have at the four corners 4.81, with more wire-wrap wires added between the place where the jumpers connect and the far reaches of the Board.. Next, I will solder one end of the Jumpers to an extended wire off of the Power Supply, as what is there from the Power Supply is a little too short, and could cause a short If I try and put an alligator clip straight on and put too much tension on the wire causing it to twist and then short to the other pin..

It looks like I will need to wait, until I can go and get some Heavier wire and new alligator clips for the final wiring..
But, for Now 4.81 is better than 4.61-65..

THANK YOU Marty
 
Last edited:
You must log in or register to reply here.
Back
Top