Falcon clock patch V4 series

[Steve]

I just also thought: on your motherboard, have you tried contact-cleaning / de-oxit'ing the expansion connector? Other thoughts on your friends Falcon vs your falcon ... it could be degraded capacitors. I would be sure to replace the main 4700uf cap since it's very important. Another thought is heat-related, as the DSP heats up, perhaps it could have a loose leg which needs re-soldering. I've also seen people with faulty DSP S-RAM chips which needed replacing..

I guess, there are a million factors to take into consideration with your Falcon vs your friends Falcon...

[Swissfalcon]

It is not just the accelerator itself which is important here, it is how it interacts with the entire system. Completely different motherboard is a completely different set of tolerances placed upon the accelerator. While it is an indication that the accelerator might be okay, it does not mean it could necessarily run exactly the same speed in a different Falcon.

It would be like driving a car up a hill and comparing it to the same car driving down the hill. One person can say the car goes very fast, the other person can say the car goes very slow. Even though it is the exact same car ! This is due to "external factors".

I agree. To me, the goal with the second motherboard was to roll out the the CT60e as possible cause, and to check if Falcamp can run stable. But I understand that maybe it won't be possible on my mobo even with the most perfect signal.

but on the other hand, Mxplayer, that use the CPU only to decode, run stable without the patch and not anymore with the patch. To me, it's a very good proof that the stability is now worst.

You also said earlier.

Ok. I tried Falcamp under TOS 404 (with local MP3) too, in 030 mode ok, in 060 mode crash too,

So please confirm that you can play Falcamp in 030 mode (remove the CT60) try Falcamp and joy demo to see if its stable.

I confirm that falcam play stable in 030 mode and joy demo too (I launched it 50 times, yes, I did that). But it was with the CT60e de-activated, not removed, because I don't have the original power supply here with me. I can take it back from my storage place, but it isn't recapped. I will do it anyway (will measure the voltage before) just to be able to measure the clock signal on the expansion bus without the CT60e, to see if there is a difference.

I don't think it has been mentioned the power supply you are using either. But indeed trying to debug multiple things at once isn't going to work. So removing the CT60 and doing all tests should be the first step. Of course, your original Falcon power supply should also be recapped to be stable.

Micro ATX power supply. This one run my falcon stable since November 2023 (and I use my Falcon a lot). With the CT60e de-activated, my falcon is in fact stable, yes, this is confirmed by the long run joy demo (my kids can't ear the song anymore, they wanted to kill me), and by letting Falcamp running MP3 locally in a row.

The instability is only when the CT60e is activated.

I also patched a better 4700uF low ESR on my falcon motherboard as the original is likely bad these days.

good to know

Also when you measure the SDMA clock (across the 47pF) please put minimum and maximum voltage reading on your scope!

Also verify all the soldering is good on the V4, in particular where it rests on top of the GAL chip as this gives the board power.

ok, I will do that.

I tried the 68R. Signal is now a lot better. But I cannot really say made any difference to my machine as it was working fine before anyway.

This is a good info. With my measurement, we will see if my signal looks like yours. In this case, I can try to add a 68R too.

I also tried with and without the 47pF and there was really not that much difference.

ok, good to know to, this we can discard then.

Currently I have had Falcamp running on the CT60e for a hour on loop without problem. Its running over 90Mhz. I will let it run for a little longer. I only have the PSU fan blowing on the 060 at the moment, so its probably getting pretty hot by now anyway.

but it crashed yesterday after 30 minutes. If you can now run it for some hours, won't it tell us that the system is more stable because you added the 68R?
I'm curious to see if you can have it longer. Mine is still playing as I'm away to work. I will do the measurement between this evening and tomorrow, have to borrow the oscilloscope first (and come back from work).

Thanks!

[exxos]

I confirm that falcam play stable in 030 mode and joy demo too (I launched it 50 times, yes, I did that). But it was with the CT60e de-activated, not removed, because I don't have the original power supply here with me. I can take it back from my storage place, but it isn't recapped. I will do it anyway (will measure the voltage before) just to be able to measure the clock signal on the expansion bus without the CT60e, to see if there is a difference.

If the setup worked fine with 030 mode then that should be a good enough test.

Micro ATX power supply.

Should be good.

The instability is only when the CT60e is activated.

Other than adding the 68R, I don't really have any ideas why the CT60e would misbehave, I can't replicate that here. As others have said, trying the stock speed of 66MHz would be a step to try.

If problems are specific to the CT60e, I cannot help much with that as I did not design the hardware and I would not be able to troubleshoot those problems . Though with the 68R, the clock to the expansion board is as good as it's going to get. But if it was a bad clock, the original Atari patch would have surely failed because the clock signals are a lot worse anyway.

Currently I have had Falcamp running on the CT60e for a hour on loop without problem. Its running over 90Mhz. I will let it run for a little longer. I only have the PSU fan blowing on the 060 at the moment, so its probably getting pretty hot by now anyway.

but it crashed yesterday after 30 minutes. If you can now run it for some hours, won't it tell us that the system is more stable because you added the 68R?

The ground connection of my scope came off and touched the motherboard which could have been the cause of the crash. But also I had no fan on the CPU which I think pretty much anyone will say is a bad idea in particular when going over 90MHz. Though as the crash happened exactly when the scope probe disconnected it is reasonable to assume that was the cause of the crash.

Indeed yes the 68R might have been a factor, but I cannot conclusively say what was the cause of that crash.

I'm curious to see if you can have it longer.

I just updated my post as it is been running for a hour and a half now. I will leave it running for another hour. But again I don't really have a proper fan on the CPU, just the airflow from the power supply.. So any crash which may happen from now on could literally just be thermal. If something was unstable, the machine would very likely crash within the first couple of minutes.

IMG_2439.JPG

[Swissfalcon]

I just also thought: on your motherboard, have you tried contact-cleaning / de-oxit'ing the expansion connector? Other thoughts on your friends Falcon vs your falcon ... it could be degraded capacitors. I would be sure to replace the main 4700uf cap since it's very important. Another thought is heat-related, as the DSP heats up, perhaps it could have a loose leg which needs re-soldering. I've also seen people with faulty DSP S-RAM chips which needed replacing..

I guess, there are a million factors to take into consideration with your Falcon vs your friends Falcon...

yes, they are tons of possibilities. I think it's maybe good to first investigate the clock signal on the expansion bus. I the signal isn't good, like Exxos measured yesterday, it's a good path to investigate. I would say that if falcamp play well for some time (one or 2 hours?) on Exxos's Falcon with the 68R fitted additionally, then it's a good clue that his stability increased too. It will be worth that I try to add the 68R too an see if it help.
Step by step :-)

[Swissfalcon]

Other than adding the 68R, I don't really have any ideas why the CT60e would misbehave, I can't replicate that here. As others have said, trying the stock speed of 66MHz would be a step to try.

ok. Yes, I will do that. If the machine is stable at 66 MHz (or 77Mhz, like Steve), then it can explain why not everyone is having this instability with the V4. I assume that not so many people are running the V4 + CT60e at 100 MHz currently (if any).

Currently I have had Falcamp running on the CT60e for a hour on loop without problem. Its running over 90Mhz. I will let it run for a little longer. I only have the PSU fan blowing on the 060 at the moment, so its probably getting pretty hot by now anyway.

That's a good information. I will totally test the 68R too, but after measurement.

The ground connection of my scope broke a modern touch the motherboard which could have been the cause of the crash. But also I had no fan on the CPU which I think pretty much anyone will say is a bad idea in particular when going over 90MHz.

Indeed yes the 68R might have been a factor but I cannot conclusively say what was the cause of that crash. But also don't forget I could run the DFB1X all day on the V4 clock patch.

if you run now for a couple of hours now with the 68R, maybe it's worth to remove it and redo the test without, to see if it crash?

I just updated my post as it is been running for a hour and a half now. I will leave it running for another hour. But again I don't really have a proper fan on the CPU, just the airflow from the power supply.. So any crash which may happen from now on could literally just be thermal. If something was unstable, the machine would very likely crash within the first couple of minutes.

yes, can good be. In my opinion, if it run correctly 2 and half hour, it's stable.

[exxos]

Another thought is heat-related, as the DSP heats up, perhaps it could have a loose leg which needs re-soldering. I've also seen people with faulty DSP S-RAM chips which needed replacing..

I do remember a lot of people having SRAM chips failing. I'm not really sure of the cause was ever identified..

The top two SRAM chips measure 40c in temperature, the bottom on measures 33c :shrug:

The DSP measure 40c currently.

I think you would be worthwhile placing a very small heatsink on each of those chips. I'm going to stick a small heatsink on my DSP now in fact.

[exxos]

if you run now for a couple of hours now with the 68R, maybe it's worth to remove it and redo the test without, to see if it crash?

Yes that is a good idea. It's got to run about 10 more minutes for a total of two hour run time. So then I will remove the 68R and try again.

[exxos]

The DSP was 40c after running for a couple of hours.

I added a small heatsink and now it is running at 38c.. so meh, whatever.. 2c cooler I guess.

IMG_2440.JPG

[exxos]

It's been running about an hour and half now, without the 68R (with CT60e). No crashes. So it has run 3x as long as it did before and the machine was already warmed up when I started this test. Of course it may have some effect on your machine, but other than that, I don't really know what it could be.

Considering that Joy works now with the V4, then it would indicate the bus is now stable, maybe that in itself is inherently started showing up some fault on the CT60 itself or some other problem. But as others have said, you can only really try 66Mhz to see if its stable then. If not, then I don't know, I am out of ideas. Other than some bad connection or thermal problem, I'm not really of any other potential faults relating to the CT60.

EDIT:

I guess if all else fails, you could try the V3 patch as it has the adjustable SDMA delay. But if that worked, then that would mean there would be inherently some timing problems with the CT60, and likely a SDMA delay should be done as standard. But, It should not really be that sensitive anyway.

[Swissfalcon]

ok, thanks for testing!

I will do the following:
- measure the clock signal on the bus with the CT60e
- measure the clock signal on the bus without the CT60e (what implies the use of the old power supply)
- try at 66 Mhz to see if it’s stable
- add a 68R on the clock patch as you did to see if it’s stable.

and I will report. Can take some times, I first have to find a 68R somewhere

If the 68R solution fail, I will then let mount the V3 clock patch.