You will not be able to post if you are still using Microsoft email addresses such as Hotmail etc
See here for more information viewtopic.php?f=20&t=7296
Check if your IP is banned
viewtopic.php?t=7286
The server is under a massive attack which started yesterday morning.
Unfortunately I am not at home on weekends to keep a eye on it all.
So if we go down, I will not be able to fix it until Sunday night. Fingers crossed we stay up!
I have also had to block and ban anything with HTTP1.x protocol.
So make sure you are using HTTP2 otherwise you will get banned!
~exxos~

How to diagnose dead Videl?

Problems with your machine in general.
mikro
Posts: 698
Joined: Mon Aug 28, 2017 11:22 pm
Location: Kosice, Slovakia
Contact:

How to diagnose dead Videl?

Post by mikro »

Guys, I'm gonna need your experience in this because this is above my pay grade. :)

I have got a Falcon here, not unlike this one (rare my ass...):

I got it in a "rattling PSU" state. So I disassembled everything I could from that tower, used a PSU which I know it works and I got ... nothing. The only sign of life was the poor internal fan. Not even the infamous "out of sync", "going to sleep", not a single life sign on screen.

Since the Falcon had the Mighty Sonic 32 installed, I carefully removed it (thanks @Badwolf for the hint in viewtopic.php?p=80248#p80248 -- much easier than messing with the CPU legs!), just to avoid another possible source of failure (and the PCB CPU is much easier to diagnose...).

(Un)fortunately, that didn't change anything. I measured all the usual CPU stuff from the Service Guide (RESET, HALT, BERR etc), couldn't see anything suspicious. Combel's input and output clocks are OK, Videl's input +5V and input clocks are OK, too.

After power on, ROM CE (measured on TOS ROM's pin 3) goes from an initial activity to 0V and stay there unless I press the reset button (interestingly, I see a lot of activity while I'm holding the button but as soon as I release it, it quickly ends up in 0V). That is perhaps OK since the memory card it out.

So that perhaps mean that ROM is read but in my case, I get nothing on /ROM3 and /ROM4 (always high) and the guide is quick on recommending of replacing the Combo IC but this seems like a premature conclusion because what if the Videl is dead and is blocking any meaningful operation?

The Service Guide's sections for both halted and non-halted CPU do not give a clear answer what happens if the Videl is dead, is the unit expected to operate to at least execution of code from the cartridge?

I'm mentioning Videl so often because this one looks really dead. I checked its +5V, RESET and input clocks but I get nothing from DOTCK, HINT, VINT, DE ... The only suspicious thing is that VCS (chip select) is raised only upon power on. Pushing the reset button doesn't ever lead to active high (checked against a working Falcon, there it does go to active high). This pin is connected directly to the Combo IC so that could imply something wrong with it but: The COMBO IC is responsible for handling the interrupts generated by the VIDEL IC, and the loading of DRAM data into the video chip’s input buffer. COMBO receives the interrupt signals VINT for VSYNC and HINT for HSYNC. A request for video data to be loaded into the video RAM buffer within the VIDEL IC is generated to the COMBO IC by the VREQ signal, and DRAM data is loaded into the video chip’s input buffer via the VLD signal from the COMBO IC.

So if it doesn't receive anything from the Videl, how should Combo IC behave then?

Do you have any idea what to check next to either confirm or reject the idea of a dead Videl?
dml
Posts: 593
Joined: Wed Nov 15, 2017 10:11 pm

Re: How to diagnose dead Videl?

Post by dml »

Have you inspected the state of the pins on the ICs? Especially CPU, COMBEL, SDMA, VIDEL in that order. And then maybe MFP and DSP.

I have seen a few cases where the solder joints are dry and the legs lift but its completely invisible until you try to move them with a needle and a microscope. A good clue is dull grey pins. I have seen this more often with the CPU than the other chips but COMBEL has very fine pins. Have seen exactly the same with the MFP and it was difficult to find without knowing about that.

For this I use a makeshift tool - a winebottle cork as a handle with a long sewing needle shoved into it :)

There are some other ways to test this without microscope, just by pressing the pins down in groups of 3-5 at a time with a soft qtip, cocktail stick with a flattened end or similar - and pressing the RESET button repeatedly as you go round the ICs.

The MFP needs done differently since the legs curl under the chip. In this case you can try pressing the centre of the chip though.

Unfortunately this is such a common thing with old surface mounted ICs that you really need to rule this out before you start swapping things. You can do some diagnostics of course but don't discard chips as bad until you check they are really still soldered properly.
dml
Posts: 593
Joined: Wed Nov 15, 2017 10:11 pm

Re: How to diagnose dead Videl?

Post by dml »

As I understand it, the VIDEL has priority control over the RAM and must handshake with the COMBEL to coordinate on who gets access at any time. So the VIDEL could hold the COMBEL in a permanent freeze if it doesn't handshake properly.

All devices, including CPU, BLITTER (inside COMBEL) wanting access to the main shared data bus must access RAM through COMBEL, so they will be held also.

There are not many lines between VIDEL and COMBEL for this - I'm not sure exactly which ones but I'd guess it involves VLD:69/VREQ:47 and maybe others. However there is also an interface between VIDEL/COMBEL for reading/writing the VIDEL registers. That's separate and on the 16bit bus (PD0-PD15). This might also cause a similar problem but I'm less sure about it. I just know its an independent mechanism from the VIDEL RAM reading & handshaking.

I'm sure someone else on here can pinpoint exactly which lines do which things here.
dml
Posts: 593
Joined: Wed Nov 15, 2017 10:11 pm

Re: How to diagnose dead Videl?

Post by dml »

The COMBO IC is responsible for handling the interrupts generated by the VIDEL IC, and the loading of DRAM data into the video chip’s input buffer. COMBO receives the interrupt signals VINT for VSYNC and HINT for HSYNC. A request for video data to be loaded into the video RAM buffer within the VIDEL IC is generated to the COMBO IC by the VREQ signal, and DRAM data is loaded into the video chip’s input buffer via the VLD signal from the COMBO IC.
It's too late in the day for me to detangle that mess - :D but if you look at the schematic, you will see on the right side of the VIDEL there is a 32bit wide data bus which maps directly to the memory interface. It does not pass through COMBEL at all. It's the only device with that special bus.

There is a separate, 16bit data bus between the COMBEL and VIDEL which will primarily be for accessing HW registers and perhaps coordination.

There is also an address bus between the two, again for HW register loading. I don't think the COMBEL needs to provide video fetch addresses for any reason - the VIDEL's own registers will track that once set.

The rest is coordination signals & DAC outputs. It's the coordination signals that matter here.

(yes I suppose its possible the COMBEL is still in charge of when VIDEL does its loading - a bit strange but it could be the way they did things - but even if that's the case, a non-replying VIDEL will have the same effect)
User avatar
exxos
Site Admin
Site Admin
Posts: 26106
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: How to diagnose dead Videl?

Post by exxos »

I had a dead videl before viewtopic.php?t=80
mikro
Posts: 698
Joined: Mon Aug 28, 2017 11:22 pm
Location: Kosice, Slovakia
Contact:

Re: How to diagnose dead Videl?

Post by mikro »

@dml thanks, I'll try to push the pins as you described. I saw such cases in the past, too.

@exxos it's interesting that even despite the Videl being "dead", in your case it displayed something on screen.
ijor
Posts: 607
Joined: Fri Nov 30, 2018 8:45 pm

Re: How to diagnose dead Videl?

Post by ijor »

I'm not an expert on Falcon at all. And we haven't done any significant reverse engineer on the die images to be any useful for this purpose at all. However, I was looking at the schematics and the chip pinouts a couple of weeks ago, and I think I can reach some conclusions, although I'm not certain at all.

I don't think there is a data bus, excatly between COMBEL and VIDEL, if you mean this literally. The Falcon has a main 16-bit data bus that connects to most chips, including the CPU, VIDEL, COMBEL and others.

The 32-bit bus is the RAM data bus and connects only to VIDEL. But I suspect this work very similarly as in the STE. VIDEL is here just used as a replacement for the 4 TTL chips that were used in the original ST. The same that STE SHIFTER is used for this purpose. Only that here there is an additional mux between the lower and higher ram data bits.

For sure that COMBEL signals to VIDEL exactly when to latch video data. COMBEL is still the one that manages the RAM interface. If that means that COMBEL is in charge or not, it might be a matter of point of view.
dml wrote: Sat Jul 05, 2025 4:40 pm
It's too late in the day for me to detangle that mess - :D but if you look at the schematic, you will see on the right side of the VIDEL there is a 32bit wide data bus which maps directly to the memory interface. It does not pass through COMBEL at all. It's the only device with that special bus.

There is a separate, 16bit data bus between the COMBEL and VIDEL which will primarily be for accessing HW registers and perhaps coordination.

There is also an address bus between the two, again for HW register loading. I don't think the COMBEL needs to provide video fetch addresses for any reason - the VIDEL's own registers will track that once set.

The rest is coordination signals & DAC outputs. It's the coordination signals that matter here.

(yes I suppose its possible the COMBEL is still in charge of when VIDEL does its loading - a bit strange but it could be the way they did things - but even if that's the case, a non-replying VIDEL will have the same effect)
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com
dml
Posts: 593
Joined: Wed Nov 15, 2017 10:11 pm

Re: How to diagnose dead Videl?

Post by dml »

ijor wrote: Sat Jul 05, 2025 6:19 pm For sure that COMBEL signals to VIDEL exactly when to latch video data. COMBEL is still the one that manages the RAM interface. If that means that COMBEL is in charge or not, it might be a matter of point of view.
That does make the picture a bit clearer - it would also suggest the COMBEL can't be blocked by VIDEL and doesn't need acknowledgement about memory access. So e.g. removing the VIDEL would not affect COMBEL operation.

Which would point Mikro's problem back at the COMBEL or something else holding the bus.
mikro
Posts: 698
Joined: Mon Aug 28, 2017 11:22 pm
Location: Kosice, Slovakia
Contact:

Re: How to diagnose dead Videl?

Post by mikro »

Actually it seems that I missed one quite important thing previously -- the /RESET signal. While it reacts to the reset button and all but only now I have realised that it's stuck a in reset loop! So if I let it trigger on raising edge and release the button, I see more peaks every couple of microseconds! Not sure how could I have missed it but it surely may explain why Videl doesn't want to do anything -- it's constantly reset!

But oh dear, why and how...

EDIT: Actually, I perhaps need to take a few steps back. Those peaks are at 4V (which looks quite suspicious) plus they eventually disappear as I'm seeing stable +5V afterwards.
dml
Posts: 593
Joined: Wed Nov 15, 2017 10:11 pm

Re: How to diagnose dead Videl?

Post by dml »

mikro wrote: Sat Jul 05, 2025 6:48 pm Actually it seems that I missed one quite important thing previously -- the /RESET signal. While it reacts to the reset button and all but only now I have realised that it's stuck a in reset loop! So if I let it trigger on raising edge and release the button, I see more peaks every couple of microseconds! Not sure how could I have missed it but it surely may explain why Videl doesn't want to do anything -- it's constantly reset!

But oh dear, why and how...
That might not be such bad news! The reset signal is not something sent by most (any?) ICs, rather received by them. Just poke around the rest circuit and the inverters from that - make sure they all agree (or disagree) depending on the high or low condition. (I remember there is both a high and low version of reset sent around the board for different purposes).

It's possible a faulty chip can pull reset low but they are mostly isolated from each other. Look for signs of disagreement between different branches of the reset line, separated by buffers/inverters.

You are probably also aware by now that the reset circuit in Atari machines is a common failure point - timing capacitor dries out under the PSU, reset period shrinks, some chips come out of reset before time... black screen or whatever.


Reset signal XRESET and also XHALT is generated by U11, reset time controlled by C7. There is some interaction between the two but I forget the details since I last had to trace this. In any case I would begin there and check XRESET and XHALT both go high and both survive the trip to each IC.
Post Reply

Return to “HARDWARE ISSUES”