Jump to content
hyuma

Trying to fix Colecovision PAL rev. D

Recommended Posts

ChildOfCv said:
 

I tested the clock with oscilloscope and it's says around 3.58-3.6mhz. I also bought the Z80 from local shop and it doesn't seems fake because i cleaned with IPA to test if label was painted... 

 

 

 

 

 

 

Edited by hyuma

Share this post


Link to post
Share on other sites

It doesn't have the look a fake one:

 

 

6cca642cce655b7ab873e115ab027236.jpg

Inviato dal mio CLT-L09 utilizzando Tapatalk

Edited by hyuma

Share this post


Link to post
Share on other sites
21 hours ago, hyuma said:

I tested the clock with oscilloscope and it's says around 3.58-3.6mhz. I also bought the Z80 from local shop and it doesn't seems fake because i cleaned with IPA to test if label was painted... 

Unfortunately, I can't think of a reason for the Z80 to self-reset... other than unclean power or a pulse on the reset pin.  And the pattern is way too regular to be from either external cause.  Whether it's real or fake, I still have a feeling that the processor is not working as it should.

Share this post


Link to post
Share on other sites

hey @ChildOfCv as I'm really, really stubborn, I made another sampling (the 11th!!!!) and now i made some changes on logic analyzer and now i'm not using the "auto restart sampling" function. In this sampling reset line is channel 8 (pin 26) and pin 15 of U5 is channel 9.

https://ufile.io/lijg6tcw

 

Check now the reset only happens at 0.5746397.

 

Tell me what you think now ;)

 

 

Edited by hyuma

Share this post


Link to post
Share on other sites

I still see the same repetition of values that indicate the processor is resetting.  Only the values are different.  The sequence is now 53, 61, 119, 71, *reset*, 53, 61, *reset for 300ms*, rinse, repeat.

 

This is weird though because there is no good pattern to the difference in values.

 

You have all the chips socketed now, right?  The sockets (and even replacement chips) may be "new old stock" which means they've sat on a shelf for decades.  Any original chips you are still using could also have a layer of oxidation.  Did you use contact cleaner before plugging in the chips?

 

Anyway, it's possible that there is something interfering with the bus.  Try removing the SRAM, VDP, and controller input chips and repeating this experiment.  Let's see if it gets further than the first 4 bytes.

Share this post


Link to post
Share on other sites
16 hours ago, ChildOfCv said:

I still see the same repetition of values that indicate the processor is resetting.  Only the values are different.  The sequence is now 53, 61, 119, 71, *reset*, 53, 61, *reset for 300ms*, rinse, repeat.

 

This is weird though because there is no good pattern to the difference in values.

 

You have all the chips socketed now, right?  The sockets (and even replacement chips) may be "new old stock" which means they've sat on a shelf for decades.  Any original chips you are still using could also have a layer of oxidation.  Did you use contact cleaner before plugging in the chips?

 

Anyway, it's possible that there is something interfering with the bus.  Try removing the SRAM, VDP, and controller input chips and repeating this experiment.  Let's see if it gets further than the first 4 bytes.

Socket are clean, like I cleaned also pins of ICs with IPA and deoxit...

This is sampling wihtout VDP, reset is channel 8:

 

https://ufile.io/kbgmeph6

 

 

Edited by hyuma

Share this post


Link to post
Share on other sites

This time the reads go 49, 57, 115, 67, reset, 49, 57.  It doesn't reset again, but it just starts reading 0's and 4's.  But then I realized that without the VDP, the CPU's NMI line (U1 pin 17) needs to be jumpered to +5V to keep it from floating.  Could you do that and try again?

Share this post


Link to post
Share on other sites
This time the reads go 49, 57, 115, 67, reset, 49, 57.  It doesn't reset again, but it just starts reading 0's and 4's.  But then I realized that without the VDP, the CPU's NMI line (U1 pin 17) needs to be jumpered to +5V to keep it from floating.  Could you do that and try again?
What I have to do? Sorry I didn't understood

Inviato dal mio CLT-L09 utilizzando Tapatalk

Share this post


Link to post
Share on other sites
39 minutes ago, hyuma said:

What I have to do? Sorry I didn't understood

Inviato dal mio CLT-L09 utilizzando Tapatalk
 

Find a temporary but secure way to connect U1 pin 17 to +5V

Share this post


Link to post
Share on other sites

HOUSTON, WE GOT SOMETHING!!

 

http://imgur.com/a/ldTDWMd

 

http://imgur.com/a/J2DzH3G

 

I found a little broken trace between Sram and BIOS and this is the situation now! OMG THERE IS LIFE!! I tested all DRAM and they're ok, I'm using this composite mod I made...[mention=66741]ChildOfCv[/mention] aebc75e7ad279fac401bb6ce7ad3571e.jpg

 

Inviato dal mio CLT-L09 utilizzando Tapatalk

 

 

 

 

Share this post


Link to post
Share on other sites

Cool!

When you were taking the readings that got the correct values, were you reading it from the BIOS chip then?  And the subsequent ones were at the CPU?  Anyway, now the results make sense:

>>> bin(49),bin(0x31)
('0b110001', '0b110001')
>>> bin(57),bin(0xb9)
('0b111001', '0b10111001')
>>> bin(115),bin(0x73)
('0b1110011', '0b1110011')
>>> bin(67),bin(0xc3)
('0b1000011', '0b11000011')

D7 is always 0.

 

 

Looks like you still have to replace a video RAM chip or two though (or fix traces), looking at the videos.

 

And just wondering, why did R140 need to be modified?

Edited by ChildOfCv

Share this post


Link to post
Share on other sites
Cool!

 

When you were taking the readings that got the correct values, were you reading it from the BIOS chip then?  And the subsequent ones were at the CPU?  Anyway, now the results make sense:

>>> bin(49),bin(0x31)('0b110001', '0b110001')>>> bin(57),bin(0xb9)('0b111001', '0b10111001')>>> bin(115),bin(0x73)('0b1110011', '0b1110011')>>> bin(67),bin(0xc3)('0b1000011', '0b11000011')

D7 is always 0.

 

 

Looks like you still have to replace a video RAM chip or two though (or fix traces), looking at the videos.

 

And just wondering, why did R140 need to be modified?

 

When I was reading with logic analyzer I always put the probe on the data lines of Z80, I never used the data lines of BIOS.. Today i got new VDP but the old one is ok, there is the same issue with new one. The DRAM are 8 4164 but I tested with arduino code and they are good.. I have to check traces but they seems cleaned and ok.. Also this is where I get info for the mod

 

https://gamesx.com/wiki/doku.php?id=av:cbs_coleco

 

Inviato dal mio CLT-L09 utilizzando Tapatalk

 

 

 

Share this post


Link to post
Share on other sites

Continuity between z80, Sram and BIOS is perfect, then I checked the continuity between vdp and DRAM by following the scheme in picture is good too..1d33a77f0cbb15a43010917323ff29ee.jpg

Inviato dal mio CLT-L09 utilizzando Tapatalk

Share this post


Link to post
Share on other sites

That sound good.  But it doesn't mention the data returns on pin 14, or the individual connections to pin 2.  Also, pin 8 must be +5V and pin 16 must connect to ground.  Pin 9 can be connected either to +5 or to ground, but must be connected to something.

 

As for pins 2 and 14, you need:

DRAM     2       14
U10      7       29
U11      3       25
U12      8       30
U13      4       26
U14      9       31
U15      5       27
U16     10       32
U17      6       28

 

Oh, and since you found a broken trace, make sure the Z80 to VDP has good continuity too.

Edited by ChildOfCv

Share this post


Link to post
Share on other sites




 
As for pins 2 and 14, you need:
DRAM     2       14U10      7       29U11      3       25U12      8       30U13      4       26U14      9       31U15      5       27U16     10       32U17      6       28

 
Oh, and since you found a broken trace, make sure the Z80 to VDP has good continuity too.



What's the scheme means? And yes z80, bios, Sram and vdp have good continuity between them, I checked all combinations possible



Inviato dal mio CLT-L09 utilizzando Tapatalk

Share this post


Link to post
Share on other sites
6 hours ago, hyuma said:

When I was reading with logic analyzer I always put the probe on the data lines of Z80, I never used the data lines of BIOS

Then it's weird that you once got all the right values... but it was still resetting according to that pattern.

 

BTW, I finally noticed the pattern in your second recording for the wrong values, D2 was always 1.  Maybe that probe was misplaced, or maybe it means there are intermittent connections.

Share this post


Link to post
Share on other sites
2 minutes ago, hyuma said:


 

 


What's the scheme means? And yes z80, bios, Sram and vdp have good continuity between them, I checked all combinations possible



Inviato dal mio CLT-L09 utilizzando Tapatalk
 

 

Pins 2 and 14 of each DRAM.  Go down the list of 2's to check continuity with the VDP pin.  Same with the list of 14's  For example, pin 2 of U10 to VDP pin 7

Edited by ChildOfCv

Share this post


Link to post
Share on other sites

DRAM 2 14

U10 pin 7 vdp 29
U11 pin 3 vdp 25
U12 pin 8 vdp 30
U13 pin 4 vdp 26
U14 pin 9 vdp 31
U15 pin 5 vdp 27
U16 pin 10 vdp 32
U17 pin 6 vdp 28

Like this?

Inviato dal mio CLT-L09 utilizzando Tapatalk

Share this post


Link to post
Share on other sites

Ok so, the 2s and 14s pin have all continuity with VDP with no problem, also VDP have good continuity with Z80 too and voltages on RAM +5v pin8 is present, pin 1 have 0v and pin9 around +5v too

Inviato dal mio CLT-L09 utilizzando Tapatalk

Share this post


Link to post
Share on other sites
3 hours ago, hyuma said:

Ok so, the 2s and 14s pin have all continuity with VDP with no problem, also VDP have good continuity with Z80 too and voltages on RAM +5v pin8 is present, pin 1 have 0v and pin9 around +5v too

Inviato dal mio CLT-L09 utilizzando Tapatalk
 

What is the exact part number of the 4164s?

 

Anyway, if it turns out to be one or more of the DRAM chips, you can find this out by removing them one at a time to see how it affects the image.

Edited by ChildOfCv

Share this post


Link to post
Share on other sites
What is the exact part number of the 4164s?
 
Anyway, if it turns out to be one or more of the DRAM chips, you can find this out by removing them one at a time to see how it affects the image.
TMS416415NL, but I'm 100% sure that ram are good because I have tested with arduino

Inviato dal mio CLT-L09 utilizzando Tapatalk

Share this post


Link to post
Share on other sites

So, 150ns memory should be in spec.

 

The Arduino program, as I recall, does not check dynamic retention times.  It only checks immediate readback.  So it's not an authority on whether the memory is good or not.  At best, it can tell you if the memory definitely is NOT good.  For a true test, it would need to write data, wait for the maximum refresh time of 4ms, then try to read it back.

 

Anyway, the random dots you see means that some memory data is not fixed.  If the VDP is good, the connections are good, and the memory is good, this obviously cannot happen, as it can only be one of those 3 things.  So like I say, try pulling one chip and temporarily hooking pin 14 to ground, to see if the randomness stops or at least improves.  If so, then that chip is suspect.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...