PAL red/green color moire, not in NTSC

Disk drives, Monitors, SuperCPU etc.
rmzalbar
Member
Member
Posts: 257
Joined: Wed May 08, 2019 9:06 am
Contact:

Re: PAL red/green color moire, not in NTSC

Post by rmzalbar »

It's silicone based, with some kind of ceramic thermal transfer material in it (i.e. aluminum oxide.)

I've finished cleaning the motherboard, the keyboard, and retrobriting of the case. The keys are taking longer to get all the yellow out so they are still in solution, they are about 90% done. I also retrobrited a 1571 case while waiting for that (which didn't take long at all.) I'll probably have the C64G back together tonight, and a full interior cleaning on the 1571 as well.


Smooth operator
rmzalbar
Member
Member
Posts: 257
Joined: Wed May 08, 2019 9:06 am
Contact:

Re: PAL red/green color moire, not in NTSC

Post by rmzalbar »

Drat.. now that I've started to really use it, the C64G has some issues. Crashing, strange behavior in some games, intermittent black screen boot failures, Warp Speed cart doesn't work. Nothing is socketed and it's the only 64C motherboard I have anyway, so no place to swap parts with. Diagnostic cart of course always shows OK. Has a broken power jack too.
Smooth operator
banman
Member
Member
Posts: 421
Joined: Sat Jun 15, 2019 12:21 am
Contact:

Re: PAL red/green color moire, not in NTSC

Post by banman »

Hi rmzalbar,

Do you have any before and after shots of your restoration?


That is very bad luck about your C64G crashing. Is it random or on certain types of activities?

Could it be a VSP bug. I was just reading about it the other day.

I think it's one that affects the newer boards? I think it has something to do with a different type of memory from the older C64 boards.


http://www.linusakesson.net/scene/safevsp/index.php
rmzalbar
Member
Member
Posts: 257
Joined: Wed May 08, 2019 9:06 am
Contact:

Re: PAL red/green color moire, not in NTSC

Post by rmzalbar »

Could be - one of the games it struggles with is Super Mario Bros, which is VSP, but not everything uses it. I actually have an SRAM module to substitute the DRAM with if that's the issue. VSP lab is one of the things I will be testing with shortly. I don't think that explains the Warp Speed cart failure, though. I'm going to replace the power jack before I do anything else, it's a glitch source. I'll take some pictures of the after on the 1571 and the 64G, though I didn't take any before pictures.
Smooth operator
rmzalbar
Member
Member
Posts: 257
Joined: Wed May 08, 2019 9:06 am
Contact:

Re: PAL red/green color moire, not in NTSC

Post by rmzalbar »

Geez, this is getting weird. VSP test is OK, ran it for 10 minutes. New development: SID went silent about an hour ago. Oh no. Well, whew.. turns out the 12V fuse had gone open. I check for shorts across the AC.. nope.. pull out SID and measure current across fuse socket: 1.9 amps! (fuse is 1.5 amps.) So something is wrong in 9V-land, even with SID removed. Where else does 9VDC/VAC go? Rectifier..Audio amp..SID..CIA..PLA(WHY PLA though??)..cassette..user port..a bunch of capacitors, diodes and transistors. Damn.. damnit. Roll up the sleeves, I guess.
Smooth operator
rmzalbar
Member
Member
Posts: 257
Joined: Wed May 08, 2019 9:06 am
Contact:

Re: PAL red/green color moire, not in NTSC

Post by rmzalbar »

All right...okay. I'm getting a handle one step at a time.

First problem. Control logic problems in some games: seems to have been caused by ESD SOT-6 diodes I added to the control ports. I must have overcooked one of them, allowing current to leak between pins. I removed them entirely as the 64C seems to have ESD suppression devices already (really, EMF devices, but they will still help.)

Second problem: Hello, grey dot bug! I've never met you in person before, so I apologize for not recognizing you right away. Confirmed, replicated with x64sc emulator. Blecch, it's an ugly bug. Had been chalking that up to a bad chip. Can scratch that off now.

Third problem: SMB crashing sometimes. Well, system passes the VSP test, so I don't know. Still open (haven't replicated since fixing controller ports.)

Fourth problem: Warp Speed 1.0 cartridge crashes after loading anything (get PRESS RECORD & PLAY ON TAPE as soon as disk load is done, followed by crashing out of the cartridge ROM to a 'restore' screen. Warp Speed works from EasyFlash emulation on 1541U2+ though..) Not sure if compatibility bug with C64C, bad CIA, or PLA or what. May try to replicate with x64sc..

Fifth problem: Blown 9VAC fuse. Yeah... I don't know. It works when I jump it and nothing gets hot nor drags any of the AC-sourced voltage rails down. Couldn't find any low-resistance areas anywhere between the rails or to ground. I don't think my DMM is accurately estimating the draw either as it refuses to pass any current across the fuse holder (it's apparently not a metered buss bar.) I may just replace the fuse and see. SID sounds just fine.
Smooth operator
rmzalbar
Member
Member
Posts: 257
Joined: Wed May 08, 2019 9:06 am
Contact:

Re: PAL red/green color moire, not in NTSC

Post by rmzalbar »

Problem 1: Removed bad ESD diodes, OK now. Solved.
Problem 2: Grey dot, normal. Solved.
Problem 3: NOT VSP SAFE, confirmed with extended VSP lab testing. Solved.
Problem 5: Replaced blown fuse and it didn't blow again. Solved.

Problem 4 remains: Fails with most fastloaders, corrupt data. Even with software fastloaders (can't boot fast hack'em.) Normal DOS disk operations seem fine. No idea here. Waveforms on both side of the inverters are sharp and clean. I guess I'll have to desolder and swap CIAs.
Smooth operator
rmzalbar
Member
Member
Posts: 257
Joined: Wed May 08, 2019 9:06 am
Contact:

Re: PAL red/green color moire, not in NTSC

Post by rmzalbar »

Investigated a claim that the "grey dot bug" is caused by chip select becoming active a little before data line is ready, and could be stopped simply by putting a capacitor to the /CS line of VIC-II.

I tried this.. putting 27R in the signal path and testing various capacitors in the nF range. I found that I was able to create enough RC delay to reduce the width of the dot by half, but by that time the signal was a very shallow shark fin with ground level becoming compromised (active-low), and any additional capacitance made it invalid and stopped the VIC-II from getting select. So RC is not enough, I have partially debunked that. A real delay circuit would need to be used.
Smooth operator
banman
Member
Member
Posts: 421
Joined: Sat Jun 15, 2019 12:21 am
Contact:

Re: PAL red/green color moire, not in NTSC

Post by banman »

Hi rmzalbar,


Gee you've done well to work out the bugs so far.


I had to do a quick google search for that grey dot bug, interesting....

Any more luck with the capacitor trick?

Do you have any shots of the ESD device you installed. I am interested in seeing this. I assume that it is for protection of one of the CIA chips?

On the cartridge crashing... Could it be that some of the logic chips on your C64 mainboard are say CMOS .

I think 74LSxxx means TTL internal circuitry, 74HTCxxx stands for CMOS technology that is TTL compatible and 74HCxxx CMOS technology with CMOS input and output levels(please excuse me if any of this is wrong)..

Do any of the chips have the HC markings..maybe these are causing some incompatible signalling when used with the problematic cartridges...

Just a thought, I think eslapion would have a much better way of explaining how this might come about (he helped me out heaps with making sense of something that used a TTL and CMOS chips...).
rmzalbar
Member
Member
Posts: 257
Joined: Wed May 08, 2019 9:06 am
Contact:

Re: PAL red/green color moire, not in NTSC

Post by rmzalbar »

Well..

The logic chips are all either standard TTL or LS versions.

The fastloaders I've tried are a physical Cinemaware Warp Speed cartridge that, after any load operation finishes, puts PRESS RECORD & PLAY ON TAPE on the screen. Real strange. Pressing run/stop crashes out of the cart environment to a blue screen ready prompt. Jiffydos functions fine. My other fastloaders are various carts provided by the 1541 Ultimate II+ - some work, some don't and only load corrupted data. Fast Hack'Em uses a software fastloader they label "FASTBOOT V2 ENABLED". However, as soon as it kicks in, corruption begins to appear. If I power cycle and keep retrying, I can get it to load and even copy a disk. Unknown why power cycling changes things.

All of these fastloaders work without a REMOVED my NTSC and PAL rev B breadbins. I read that Fastboot V2 loads into a specific area of high memory. No information on how Warp Speed works. Wonder if I have dodgy RAM? Was going to replace it anyways to cure VSP.

The grey dots bug can also by dodged by power cycling. It happens perhaps 1 in 3 power cycles. Something gets set randomly at power on time. Maybe the phase relationship between the dotclock and the color clock?

Using a capacitor to delay /CS is a dead end. I would need to make a real delay circuit. I can continue experiments in a simple way just by inserting 74-series logic gates into the signal path, as they have specified propagation delays in the nanoseconds range. It would be neat to make a 'grey dot bug fixer board' to fit under VIC, but I don't know if there's room for something like that in the C64C case.

The ESD protectors I use are these:
http://www.amibay.com/showthread.php?10 ... ector-v1-1

I have been using them without problem, but I made a mistake on assembly and overheated the chips beyond specification with hot air. I couldn't identify the parts, didn't have spec sheet, but learned later that 250° is the limit for most SOT-6 diode/transistors so I went way past thermal specification. Should have used preheat for a much smaller thermal bump, I used more heat for longer due to very cold substrate in 10°C ambient, but *really* I should have just used the iron. I was practicing my technique.. and learned something.

I did use the iron to assemble the rest and had no problems with those.
Smooth operator
Post Reply Previous topicNext topic

Who is online

Users browsing this forum: No registered users and 4 guests