UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio and TV Service Data

Go Back   UK Vintage Radio Repair and Restoration Discussion Forum > Specific Vintage Equipment > Vintage Computers

Notices

Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment.

Reply
 
Thread Tools
Old 27th Jul 2023, 9:05 pm   #381
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,751
Default Re: Commodore PET 4032/8050/3022

This web site I believe is the source of the table above - it has a slightly clearer set of headings.

http://www.6502.org/users/andre/petindex/crtc.html

Colin.
ScottishColin is offline   Reply With Quote
Old 27th Jul 2023, 9:34 pm   #382
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,420
Default Re: Commodore PET 4032/8050/3022

The system still is not able to run code placed in the UD7 position.

What I'm thinking so far is that it seems as though the Tynemouth board is writing (or trying to write) legitimate information to the CRTC but the CRTC is apparently ignoring it - or is it? Did you get around to scoping pins 39 and 40 of the CRTC as asked earlier?

If there is no activity on those pins, or if the activity is not what we expect, then either the CRTC has failed or it is not receiving valid set-up instructions via the unbuffered databus. We can see (from the 18 pairs of chip select pulses) that the Tynemouth board is trying to set it up, but we don't know if the correct numbers, the ones from that table, are flowing along the databus to the CRTC.

Along with this, the 'chirp', another function fully independent of the CRTC, is also not happening even when we are using internal RAM and ROM of the Tynemouth board. The 'chirp' depends on the correct functioning of two of the large ICs, UB15 pin 2 generates it and UB2 pin 9 enables it. The UB2 'enabling' feature can in theory be bypassed by 'listening' to UB15 pin 2 with an amplifier, as we tried earlier.

All of this, plus the fact that the system can't currently run code from mainboard ROMS, suggests that something is jamming the unbuffered databus and preventing the CPU from communicating with any of the devices on it, even though the observations we have made of the databus so far don't seem to have thrown up anything obviously 'bad'. If this is the case then the culprit may be any of the devices connected to the 8 data lines - any of the large ICs excluding UB16 which you have already changed, any of the ROMs excluding UD7 which has been swapped out, or the main databus buffers UB9 / UB10. Although the CPU communicates directly with all of the above devices directly and not through those buffers, a fault on one of the CPU-side gates of UB9 or UB10 could cause problems on the unbuffered data bus.

Let's do something positive: Remove the main databus buffers UB9 and UB10 in one piece, socket the UB9 and UB10 positions but leave them empty. Take the (new, known good) buffers out of the UD13 and UD14 sockets and place the buffers from the UB9 and UB10 positions in those sockets, fit your NOP tester and look for the expected squarewave waveforms on the buffered address bus (BA0-BA15), If all 16 squarewave waveforms are present that will rule out those buffers and we can put them back where they were, if not, then they will need to be replaced.

Why these ones first? Because these buffers generally are known to be quite fragile, and of all of the soldered-in ICs sitting on the unbuffered databus, they are the easiest and cheapest to remove and replace, (and we may get lucky).

Even if we do this and we find that the UB9 / UB10 buffers are indeed damaged there is still the possibility that one or more of the other devices sitting on the database is also damaged - remember how badly damaged the original UB16 was, whatever caused that may have damaged more than just that one IC.

If you are in the mood to socket UD6 as well, please do so and read its contents (as a 2532) and verify it against the matching file on zimmers. Same for the original UD7, which is already in a socket. (That one will need to be read as a 2716, I think). I know you wil be thinking that we don't need working ROMs while we are using the Tynemouth board but if we have one or more dead ones sitting on the unbuffered databus, that could prevent anything else from communicating over the bus.
SiriusHardware is online now   Reply With Quote
Old 27th Jul 2023, 9:47 pm   #383
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,751
Default Re: Commodore PET 4032/8050/3022

re pins 39 and 40 of UB13, I get no waveforms on either pin, and a reading of 1.88V on pin 40 and 0v on pin 39.

I'll get on with post 382 tomorrow.

Colin.
ScottishColin is offline   Reply With Quote
Old 27th Jul 2023, 9:56 pm   #384
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,751
Default Re: Commodore PET 4032/8050/3022

Oh - revised EPROM has been burnt.

Colin.
ScottishColin is offline   Reply With Quote
Old 27th Jul 2023, 10:07 pm   #385
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,420
Default Re: Commodore PET 4032/8050/3022

Has to be worth a try, boot with it in the UD7 socket and see if pin 39 / 40 of the CRTC start generating vdrive and hdrive signals. I think almost certainly not, but there is no harm in trying.

Which table did you plump for in the end?
SiriusHardware is online now   Reply With Quote
Old 27th Jul 2023, 11:06 pm   #386
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,420
Default Re: Commodore PET 4032/8050/3022

Looking through the file 'edit-4-40-n-50Hz.901498-01.bin' which is the matching file for your UD7 ROM (which is where the CRTC initialisation code is), I had a feeling that the setup values sent from the ROM to the CRTC would be held in a table there as well. I was right, but unfortunately doubly so. Have a look at the attached code from UD7. Here we see not one, but two CRTC setup tables, one underlined in red, the other underlined in green. Why two - no idea as yet, but you can safely say that one of those two tables is the correct initialisation table to insert into the Daver2 test code.

Looking through the disassembly I mentioned, there are also two CRTC initialisation tables in close proximity so obviously the system chooses to use one or the other on some grounds that I haven't worked out yet - maybe based on whether the machine has a business keyboard or a graphics keyboard. I'll look further into this tomorrow.
Attached Thumbnails
Click image for larger version

Name:	UD7_CRTC_Init_Tables.jpg
Views:	31
Size:	176.8 KB
ID:	282225  
SiriusHardware is online now   Reply With Quote
Old 28th Jul 2023, 12:36 am   #387
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,420
Default Re: Commodore PET 4032/8050/3022

Last bit of investigation before turning in:

I went to this page of CRTC initialisation values, same one we linked to earlier and scrolled down to the 'Pet Timing Examples' section near the bottom.

http://www.6502.org/users/andre/petindex/crtc.html

I took the columns for '4032 text' and '4032 graph', turned them horizontally and added the equivalent hex values. Note that the page of values given in the tables on that web page are only for registers 0-7 and 9. The values for registers 8 and registers 10-17 are not stated so for those I have entered 'xx' in the table.

Code:
		R0	R1	R2	R3	R4	R5	R6	R7	R8	R9	R10	R11	R12	R13	R14	R15	R16	R17

4032	Text	49=31	40=28	41=29	15=0F	39=27	00=00	25=19	32=20	xx	09=09	xx	xx	xx	xx	xx	xx	xx	xx

4032	Graph	49=31	40=28	41=29	15=0F	49=31	00=00	25=19	37=25	xx	07=07	xx	xx	xx	xx	xx	xx	xx	xx
Then, I removed the decimal versions of each value, kept the hex values and compared them with the two code tables from the UD7 ROM. Here's the '4032 text' table from the web page lined up against the first table from UD7.

Code:
4032 Text (Simplified, Hex values only) below
31 28 29 0F 27 00 19 20 xx 09 xx xx xx xx xx xx xx xx
31 28 29 0F 27 00 19 20 00 09 00 00 10 00 00 00 00 00
First CRTC initialisation table from UD7, above
Here is the '4032 graph' table from the web page lined up against the second table from UD7.

Code:
4032 Graph (Simplified, Hex values only) below
31 28 29 0F 31 00 19 25 xx 07 xx xx xx xx xx xx xx xx
31 28 29 0F 31 00 19 25 00 07 00 00 10 00 00 00 00 00
Second CRTC initialisation table from UD7, above.
Therefore, if your machine is a 'graphic' version 4032 then the correct hex values to place into the CRTC initialisation table at 0005-0016 in the Daver2 test code would be:

Code:
31 28 29 0F 31 00 19 25 00 07 00 00 10 00 00 00 00 00
...And it's goodnight from me.
SiriusHardware is online now   Reply With Quote
Old 28th Jul 2023, 8:51 am   #388
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,751
Default Re: Commodore PET 4032/8050/3022

Yep - they are the set that I used to overwrite what was in the .BIN - then (thanks for reminding me) I copied it twice into a 4K file and burnt that.

No change to pins 39/40 of the CRTC once it is installed - I get no waveforms on either pin, and a reading of 1.88V on pin 40 and 0v on pin 39.

Colin.

Quote:
Originally Posted by SiriusHardware View Post
Last bit of investigation before turning in:

I went to this page of CRTC initialisation values, same one we linked to earlier and scrolled down to the 'Pet Timing Examples' section near the bottom.

http://www.6502.org/users/andre/petindex/crtc.html

I took the columns for '4032 text' and '4032 graph', turned them horizontally and added the equivalent hex values. Note that the page of values given in the tables on that web page are only for registers 0-7 and 9. The values for registers 8 and registers 10-17 are not stated so for those I have entered 'xx' in the table.

Code:
		R0	R1	R2	R3	R4	R5	R6	R7	R8	R9	R10	R11	R12	R13	R14	R15	R16	R17

4032	Text	49=31	40=28	41=29	15=0F	39=27	00=00	25=19	32=20	xx	09=09	xx	xx	xx	xx	xx	xx	xx	xx

4032	Graph	49=31	40=28	41=29	15=0F	49=31	00=00	25=19	37=25	xx	07=07	xx	xx	xx	xx	xx	xx	xx	xx
Then, I removed the decimal versions of each value, kept the hex values and compared them with the two code tables from the UD7 ROM. Here's the '4032 text' table from the web page lined up against the first table from UD7.

Code:
4032 Text (Simplified, Hex values only) below
31 28 29 0F 27 00 19 20 xx 09 xx xx xx xx xx xx xx xx
31 28 29 0F 27 00 19 20 00 09 00 00 10 00 00 00 00 00
First CRTC initialisation table from UD7, above
Here is the '4032 graph' table from the web page lined up against the second table from UD7.

Code:
4032 Graph (Simplified, Hex values only) below
31 28 29 0F 31 00 19 25 xx 07 xx xx xx xx xx xx xx xx
31 28 29 0F 31 00 19 25 00 07 00 00 10 00 00 00 00 00
Second CRTC initialisation table from UD7, above.
Therefore, if your machine is a 'graphic' version 4032 then the correct hex values to place into the CRTC initialisation table at 0005-0016 in the Daver2 test code would be:

Code:
31 28 29 0F 31 00 19 25 00 07 00 00 10 00 00 00 00 00
...And it's goodnight from me.
ScottishColin is offline   Reply With Quote
Old 28th Jul 2023, 8:59 am   #389
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,420
Default Re: Commodore PET 4032/8050/3022

I didn't expect it to work at the moment but it is good to have that EPROM ready to go anyway.

UB9 and UB10, remove and check by temporarily putting them into the address buffer (UD13/UD14) sockets?
SiriusHardware is online now   Reply With Quote
Old 28th Jul 2023, 9:03 am   #390
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,751
Default Re: Commodore PET 4032/8050/3022

On it.

Colin.

Quote:
Originally Posted by SiriusHardware View Post
I didn't expect it to work at the moment but it is good to have that EPROM ready to go anyway.

UB9 and UB10, remove and check by temporarily putting them into the address buffer (UD13/UD14) sockets?
ScottishColin is offline   Reply With Quote
Old 28th Jul 2023, 9:33 am   #391
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,751
Default Re: Commodore PET 4032/8050/3022

UB9 and 10 out. UB9 didn't make it - one pin is off the chip. I have new ones though.

Off to put them into UD13 and 14.

Are the tests are the ones mentioned in post 190?

Colin.
ScottishColin is offline   Reply With Quote
Old 28th Jul 2023, 9:38 am   #392
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,420
Default Re: Commodore PET 4032/8050/3022

Indeed yes, you probably know the expected frequencies on the BA0-BA15 lines off by heart by now.

Pity about the IC pin - can you maybe re-pin it by putting it into a socket and then put the socket into either UD13 or UD14 position to test? Otherwise we'll never know whether that IC was dud.

The waveforms should look really solid and square - if any of them looks reduced-height or distorted, that's a reject.
SiriusHardware is online now   Reply With Quote
Old 28th Jul 2023, 2:00 pm   #393
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,751
Default Re: Commodore PET 4032/8050/3022

I used the NOP tester to get these results.

They all check out OK on the removed UB9 and UB10 pins. Do not ask how I managed to get readings from the one with a broken pin. It involves one of my wife's sewing pins and is not a thing of great beauty.

Colin.
ScottishColin is offline   Reply With Quote
Old 28th Jul 2023, 2:53 pm   #394
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,420
Default Re: Commodore PET 4032/8050/3022

OK, good news that the buffers were OK, but bad news in the sense that the problem looks to be somewhere else. A pity that pin went missing in action as we've damaged the IC for no reason, apart from a little bit more knowledge gained.

Let me think on't. We are very handicapped by the inability to remove most of the suspect devices from the databus.

Couple of ways to go, I think.

One is to progressively remove and socket all of the devices which are directly connected to the databus so that we can add / remove and replace them for diagnostic purposes the way you were able to on your other PET. I'm going to suggest the ROMs first as they are smaller, have fewer pins and although the Tynemouth board is reading from its own internal ROMs it is trying to commmunicate with other ICs over the unbuffered databus which the untested ROMs are also connected to, so a dead ROM squatting on the bus could cause problems. Plus, we can verify their contents as we go. You obviously don't want to lose any pins from those although I know you do have the means to replace them, it would be better not to damage the originals.

Or, you may prefer to remove and socket UB2 and UB15, the remaining large ICs (CRTC excepted), first on the grounds that you could test them in your other PET. If we suspect the CRTC then unfortunately substitution with a replacement is probably the only way to prove or disprove that.

Another approach is to attempt to get the hang of the analyser feature of your scope and actually see what is going on on the databus - for example we could capture the first few bytes read out from UD6 just after the machine comes out of reset. By looking at the UD6 ROM code we can actually see what the first few bytes fetched from UD6 should be and compare those with what is appearing on the databus. Or, we could intercept the setup values being sent to the CRTC, as we now know exactly what they should be.

The most daunting part of doing this (apart from having to learn yet another new thing) is making all the connections, especially the eight wires to the databus. If it helps, the unbuffered D0-D7 signals are available on all of the ROM sockets including the ones which don't have a ROM fitted, so you could use a conventional socket with 8 flying insulated wires soldered to its D0-D7 receptacles and plug it into one of the empty sockets to pick up D0-D7. You would then only need a few extra wires to pick up other signals specific to the area of interest. If you did go that way I would suggest using wires of the resistor colour code for D0 (black) through to D7 (violet) and that will make it easier to remember which wire is D0, D1, D2, etc.
SiriusHardware is online now   Reply With Quote
Old 28th Jul 2023, 3:28 pm   #395
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,420
Default Re: Commodore PET 4032/8050/3022

If you would prefer to use a connector made for the job, use a 24-way DIL IC header:

https://uk.farnell.com/harting/09-17...way/dp/1106723

These are actually made to be clamped onto the end of a piece of flat ribbon cable but you can leave the 'lid' off and just solder wires to the tags - however they aren't really designed to be soldered to and too much heat applied to the tags will probably melt the carrier and allow the legs to wander off course. To get around that, plug the header into an IC socket before attempting to solder wires to it. If the carrier does soften, the IC socket will hold the pins in the correct alignment until the carrier hardens again.

You could also put one on the end of an actual piece of flat ribbon cable and peel the individual cables apart at the other end so that they can be connected to the appropriate connections on the analyser input.
SiriusHardware is online now   Reply With Quote
Old 28th Jul 2023, 3:34 pm   #396
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,751
Default Re: Commodore PET 4032/8050/3022

I'll have a think re the options, especially the logic analyser. I'm not current clear how I actually connect the wiring back to the Hantek right now so I'll take a look.

What I know I can do with a reasonable amount of confidence is remove and socket the ROMs and the other larger ICs. If I removed all the ROMs, I assume that would stop anything sitting on the bus and might open things up for the Tynemouth board?

We're off up to Loch Tummel soon in the motorhome for the weekend so I won't have any progress to report until Sunday night at the earliest.

Colin.
ScottishColin is offline   Reply With Quote
Old 28th Jul 2023, 3:50 pm   #397
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,420
Default Re: Commodore PET 4032/8050/3022

Quote:
If I removed all the ROMs, I assume that would stop anything sitting on the bus and might open things up for the Tynemouth board?
That's the hope, although we both know that it'll end up being one of the large ICs after all if we go that route. If we could only get the system to run Daver's code that would checksum all of the soldered ROMs for us, but we have a chicken and egg situation here, maybe the system can't run daver2's code because of a fault on one of the ROMs.

Enjoy your trip away, I think you have earned it.
SiriusHardware is online now   Reply With Quote
Old 28th Jul 2023, 4:43 pm   #398
ScottishColin
Octode
 
Join Date: May 2012
Location: Perth, Scotland
Posts: 1,751
Default Re: Commodore PET 4032/8050/3022

I think you could do with a break too from this.....

Colin.

Quote:
Originally Posted by SiriusHardware View Post
Quote:
If I removed all the ROMs, I assume that would stop anything sitting on the bus and might open things up for the Tynemouth board?
That's the hope, although we both know that it'll end up being one of the large ICs after all if we go that route. If we could only get the system to run Daver's code that would checksum all of the soldered ROMs for us, but we have a chicken and egg situation here, maybe the system can't run daver2's code because of a fault on one of the ROMs.

Enjoy your trip away, I think you have earned it.
ScottishColin is offline   Reply With Quote
Old 29th Jul 2023, 1:43 am   #399
ortek_service
Octode
 
ortek_service's Avatar
 
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 1,354
Default Re: Commodore PET 4032/8050/3022

Quote:
Originally Posted by SiriusHardware View Post
>>
Let me think on't. We are very handicapped by the inability to remove most of the suspect devices from the databus.

Couple of ways to go, I think.

One is to progressively remove and socket all of the devices which are directly connected to the databus so that we can add / remove and replace them for diagnostic purposes the way you were able to on your other PET. I'm going to suggest the ROMs first as they are smaller, have fewer pins and although the Tynemouth board is reading from its own internal ROMs it is trying to commmunicate with other ICs over the unbuffered databus which the untested ROMs are also connected to, so a dead ROM squatting on the bus could cause problems. Plus, we can verify their contents as we go. You obviously don't want to lose any pins from those although I know you do have the means to replace them, it would be better not to damage the originals.

Or, you may prefer to remove and socket UB2 and UB15, the remaining large ICs (CRTC excepted), first on the grounds that you could test them in your other PET. If we suspect the CRTC then unfortunately substitution with a replacement is probably the only way to prove or disprove that.
>>
>>
Yes, I resorted to socketing all the larger IC's Z80(CPU+PIO+CTC) + AY-3-8910 Sound / PIO devices (there was already sockets for the MOS+Util (EP)ROM's, as well as the VIDC - The only ones socketed) in an Einstein last year, on which the diagnostic test EPROM I'd programmed crashed during RAM-test (after I'd already fixed the first failed system-clock 74LS divider IC problem, that had just resulted in nothing happening) - As it seemed the nINT line was getting stuck-low after a short while, and Z80 Interrupts have a chained system to complicate matters.
I already had replacements for all of these larger IC's (except sound IC, but could get them quite cheap, unlike the Texas VIDC I'd already tested in another Einstein). And difficult to fully-test them in-circuit, when the computer wasn't booting, so having them in sockets made things a bit easier to check.
I also did the same for the 74LS244 / 74LS245 address / dat buffers / islators (Einstein has the ability to map-out the Z80CPU and access one on its 'Pipe' Connector - Although they maybe coud have simply used the Z80 BUSREQ), then the DRAM (having previously usually done that first on 4116's in any dead Spectrum, as were very prone to failure with extra supply voltages that could easily go wrong).
But, typically, it wasn't any of these, but one of the 16pin 74LS157 address multiplexers, I'd socketed next (as only two of these).
- Although I did discover an odd issue with the original Z80 PIO, that caused the Diagnostic program to fail (and stop) before it got to that IC.

I don't usually bother socketing 74LS Logic IC's, that had originally been directly soldered-in (unless buffers going to 'outside-world' that could easily get damaged)- Only ones found to be faulty - as normally not too difficult to check in-circuit. But I still ended-up with about half of all IC's socketed -Finding 3 IC's that had actually failed.
Maybe a good uP Bus Tester, replacing the Z80 (It seems you can just clip the Polar B2000(A) one over a soldered-in one, and use BUSREQ to map it out) could have found the memory address-multiplexor corrupting the RAM issue . But finding the Z80 PIO problem may have required developing a specific check for its registers etc in the right locations in the memory-map
ortek_service is offline   Reply With Quote
Old 29th Jul 2023, 2:04 am   #400
ortek_service
Octode
 
ortek_service's Avatar
 
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 1,354
Default Re: Commodore PET 4032/8050/3022

Quote:
Originally Posted by SiriusHardware View Post
>>
Couple of ways to go, I think.
>>

Another approach is to attempt to get the hang of the analyser feature of your scope and actually see what is going on on the databus - for example we could capture the first few bytes read out from UD6 just after the machine comes out of reset. By looking at the UD6 ROM code we can actually see what the first few bytes fetched from UD6 should be and compare those with what is appearing on the databus. Or, we could intercept the setup values being sent to the CRTC, as we now know exactly what they should be.

The most daunting part of doing this (apart from having to learn yet another new thing) is making all the connections, especially the eight wires to the databus. If it helps, the unbuffered D0-D7 signals are available on all of the ROM sockets including the ones which don't have a ROM fitted, so you could use a conventional socket with 8 flying insulated wires soldered to its D0-D7 receptacles and plug it into one of the empty sockets to pick up D0-D7. You would then only need a few extra wires to pick up other signals specific to the area of interest. If you did go that way I would suggest using wires of the resistor colour code for D0 (black) through to D7 (violet) and that will make it easier to remember which wire is D0, D1, D2, etc.

Quote:
Originally Posted by SiriusHardware View Post
If you would prefer to use a connector made for the job, use a 24-way DIL IC header:

https://uk.farnell.com/harting/09-17...way/dp/1106723

These are actually made to be clamped onto the end of a piece of flat ribbon cable but you can leave the 'lid' off and just solder wires to the tags - however they aren't really designed to be soldered to and too much heat applied to the tags will probably melt the carrier and allow the legs to wander off course. To get around that, plug the header into an IC socket before attempting to solder wires to it. If the carrier does soften, the IC socket will hold the pins in the correct alignment until the carrier hardens again.

You could also put one on the end of an actual piece of flat ribbon cable and peel the individual cables apart at the other end so that they can be connected to the appropriate connections on the analyser input.
Well if Colin does have the 'Dupont' socket-to-socket rainbow-coloured ribbon cable leads and the IC-pin 'grabber' test-clips, that I'd previously mentioned in posts #355 / #356 (Pictures from these now attached) - as seemingly being supplied with the Hantek 6022BL (Although different coloured sets-of-8 clips between the pictures), then can just clip these onto one of the ROM's / the CPU etc.

Or maybe (for something easier to plug-in in one go) use either a proper IC test-clip (as mentioned by Graham, in post #336) / Use another standard (non turned-pin) IC socket, (so will plug into standard ones already in PCB) - probable a 'dual-wipe' exposed top-contacts and solder a 0.1" pitch Single-In-Line (SIL) 0.64mm Square-pins header strip to both columns of IC sockets top-contacts.

You can then just plug the rainbow-coloured ribbon cable lead's 'Dupont' sockets onto the required pins sticking up from this adaptor (or the IC clip-over test-clip).

BTW, If there's still any of the original white IC sockets fitted, then maybe there's some intermittent connections that could be cause of problems in getting consistent waveforms on the 'scope.
So it might be worth giving any of these IC-socket a good dose of contact cleaner etc. or changing these to a better type.
Attached Thumbnails
Click image for larger version

Name:	Hantek_6022BL_Product-Supplied-Parts__Amazon__61uXP7ST6sL._AC_SY355_.jpg
Views:	17
Size:	23.1 KB
ID:	282271   Click image for larger version

Name:	IC-pin_grabber-clips__Hantek_6022BL_Accessories__www.hantek.com__products__detail__153__20200611.jpg
Views:	19
Size:	52.5 KB
ID:	282272   Click image for larger version

Name:	Dupont_Rainbow-ribbon-cable_Leads__Hantek_6022BL_Accessories__www.hantek.com__products__detail__.jpg
Views:	15
Size:	41.1 KB
ID:	282273  

Last edited by ortek_service; 29th Jul 2023 at 2:19 am.
ortek_service is offline   Reply With Quote
Reply

Thread Tools



All times are GMT +1. The time now is 2:27 am.


All information and advice on this forum is subject to the WARNING AND DISCLAIMER located at https://www.vintage-radio.net/rules.html.
Failure to heed this warning may result in death or serious injury to yourself and/or others.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Copyright ©2002 - 2023, Paul Stenning.