Falcon error: T4 Video Counter in Memory Controller

[Badwolf]

So I'd nearly wrapped up by series on salvaging a Falcon motherboard (viewtopic.php?t=7907), but I still had a niggly IDE problem.

Basically, with no IDE device (or cable) present, most of the time I'll get a nonsense device detected on the port.

Still 2025-09-03 134622_1.24.1.jpg

The exact characters returned can change but that macron (0xff) is often the second character of the pair.

Now, with most of the IDE bus simply being the data bus (behind a 56 ohm resistor) and IDE actually being able to work for the most part when it's attached, that suggests perhaps a problem with the control lines rather than the data component. Perhaps the interrupt? 0xff would make sense if a data transfer is being requested with nothign attached as that's the 'resting' data on an undriven bus.

But I don't know much about how the IDE system works. Is there anything obvious that jumps out to those more au fait than me?

So, anyway, I carried on testing and investigating and spotted this on the diagnostic cart.

Screenshot 2025-09-08 at 21.59.34.png

Not every time, but perhaps a good 50%. It doesn't seem to have any obvious ill effects, but perhaps that's just the way I've been using the machine.

The Falcon Service Guide explains this as:

Video Counter Error. The COMBO (sic) IC is not generating the correct addresses for the display. This will result in a broken-up display in some or all display modes.

But FF8201 is the video address high byte -- so I'm not quite sure what it's showing me with the 001280 and 0013C0 output.

The 'Some or all' display modes is interesting too -- clearly not all, so perhaps I need to hunt around for some failing modes to make more sense of things. I did observe some colour corruption to the bottom quarter or so of Bad Mood's screen when testing the DSP, but I don't know if that's connected.

badmood_loading.png

My immediate thoughts are that I can't see any other direct connection between IDE and the video counter other than COMBEL. Which is a worry. I did have to reflow SDMA so perhaps that's the obvious next step with COMBEL around the IDE control pins, but this video counter worries me. I don't know how the logic around that works. What's it counting?

Anyway finally to the point: ideas and suggestions welcome in case I'm overlooking an utterly obvious issue given these two symptoms.

Thanks,

BW

PS When I searched for that error, it popped up a topic on this forum from Acsi -- from whom I bought this board. So I've maybe got things back to where we came in! viewtopic.php?p=37635#p37635

[dml]

The machine had an Afterburner fitted then removed?

From what I remember, there were a few wires (maybe 5?) to GALs and pin 17 of the CPU lifted (potentially also on a switch) to take the 030 out of operation. No other changes. I can have a look in my machine to see exactly where the wires went...

As for the video corruption - can't tell from a static image but if the corrupt area is flickering/moving then it does maybe suggest a video addressing issue of some kind. If it is static, it could just be faulty data reading over IDE>

[dml]

Code: Select all

Video Counter Error. The COMBO (sic) IC is not generating the correct addresses for the display. This will result in a broken-up display in some or all display modes.

The video counter is the CPU's register access to the Combel's current video address. The base address for the screen is set by the CPU and the counter register counts up from there as the display is scanned out. So it's a 'live' copy of the screen address during refresh. It can be used to sync to a scanline for example.

The error seems to suggest the counter is not counting forwards properly - maybe hopping backwards or a stuck bit. The display corruption (if that is correlated with the error) maybe suggests the low byte is misbehaving at the end of certain scanlines (?), but not clear exactly what is happening - looks weird.

Not sure if that would have to be inside the Combel itself or just an address trace between 2 of the 3 ICs involved (CPU, Combel, VIDEL).

Interesting to know if that corruption is flickering/jumping around like noise, or if it is fixed/static, and if it changes if you reload the same screen.

[Badwolf]

The machine had an Afterburner fitted then removed?

From what I remember, there were a few wires (maybe 5?) to GALs and pin 17 of the CPU lifted (potentially also on a switch) to take the 030 out of operation. No other changes. I can have a look in my machine to see exactly where the wires went...

If it's the same one. The information I had previously was that it had (what I presumed to be) a bus accelerator fitted, but perhaps wires were crossed.

There was certainly plenty of evidence of tapped GALs and a couple of rewired oscillators.

As for the video corruption - can't tell from a static image but if the corrupt area is flickering/moving then it does maybe suggest a video addressing issue of some kind. If it is static, it could just be faulty data reading over IDE>

It was static. I just went back through my recordings and didn't capture it again -- perhaps it was a one off. That particular launch of BM froze later on so a bad load or some other data fault is quite possible. That was all from SCSI rather than IDE, though, but I wouldn't rule out that being connected.

Code: Select all

Video Counter Error. The COMBO (sic) IC is not generating the correct addresses for the display. This will result in a broken-up display in some or all display modes.

The video counter is the CPU's register access to the Combel's current video address. The base address for the screen is set by the CPU and the counter register counts up from there as the display is scanned out. So it's a 'live' copy of the screen address during refresh. It can be used to sync to a scanline for example.

Mmm. Thanks. That's what I took it to mean. I'm not sure if it's the originator of the count (like the MMU does for Shifter in the ST) or if it's counting display reads from VSYNC with Videl driving the change, though. Also I had the DFB1X in accelerated mode when I spotted that. Perhaps I should make sure it's not an artefact of the accelerator before worrying too much about it. I'll clamp DFB1X to motherboard speed while diagnosing from now on.

The error seems to suggest the counter is not counting forwards properly - maybe hopping backwards or a stuck bit. The display corruption (if that is correlated with the error) maybe suggests the low byte is misbehaving at the end of certain scanlines (?), but not clear exactly what is happening - looks weird.

Not sure if that would have to be inside the Combel itself or just an address trace between 2 of the 3 ICs involved (CPU, Combel, VIDEL).

Mmm. I was wondering if those numbers quoted were expected and actual counter read or something like that. If so, that'd make the discrepancy not far down the screen in most modes. Perhaps if it's only counting rather than generating it'll have marginal impact -- ie. only programs that use the counter to time things going to screen?

I may have to knock up a program that draws vertical lines based on the screen mode and that count and see if they go wiggly.


Thanks!

BW

[dml]

It was static. I just went back through my recordings and didn't capture it again -- perhaps it was a one off. That particular launch of BM froze later on so a bad load or some other data fault is quite possible. That was all from SCSI rather than IDE, though, but I wouldn't rule out that being connected.

I guess it could have been a SCSI transfer fault then. Something for another day :)

[Badwolf]

It was static. I just went back through my recordings and didn't capture it again -- perhaps it was a one off. That particular launch of BM froze later on so a bad load or some other data fault is quite possible. That was all from SCSI rather than IDE, though, but I wouldn't rule out that being connected.

I guess it could have been a SCSI transfer fault then. Something for another day :)

Sorry, I was extending that message when you replied. Bit more information there now.

I spent most of last night looking into the apparent IDE issue and found no smoking gun. I even removed U26 which combines IDE and DMA interrupts based on it having had some work done (and being surprised by that DSP supporting chip with the solder dag earlier). Interestingly the only effect of that was the keyboard stopped working.

That's not a suprise as it does the ACIA interrupts too, but interesting that both the IDE and SCSI for the most part don't seem to need the interrupt to get to desktop.

I had another thought that perhaps the check for IDE being missing was just to look for 0xffff on responses and, seemingly, whilst one byte in the device description string being shown is 0xFF, the other isn't. Perhaps it's as simple as a pull-up not pulling up on the data bus. That could have implications for other things -- loading from SCSI too, perhaps?

I did actually do a pull-up check on the databus in my first video. All 4.7k IIRC. But I've seen this to be an intermittent, so perhaps there's a bad joint somewhere. Or perhaps something's being a bit naughty on the bus.

Next steps are to check that out again and then perhaps I'll try to dig out my old IDE44<--->IDE40 adapter and get the logic analyser on that header.

Cheers!

BW

[mikro]

Video Counter Error. The COMBO (sic) IC is not generating the correct addresses for the display. This will result in a broken-up display in some or all display modes.

But FF8201 is the video address high byte -- so I'm not quite sure what it's showing me with the 001280 and 0013C0 output.

It's showing you a difference between the expected video line start and the actual one. In this case it's 0x140 = 320 bytes, so depending on the resolution (16c vs 256c) it may imply one or two raster lines difference.

If you want to put it in test, run e.g. https://demozoo.org/productions/205747, there's a pretty Timer-B / HBL demanding plasma in both RGB and VGA.

My guess would be that this isn't an issue with counting but more like with timing, i.e. that the interrupt takes a bit longer (or shorter) than it should.

[Badwolf]

It's showing you a difference between the expected video line start and the actual one. In this case it's 0x140 = 320 bytes, so depending on the resolution (16c vs 256c) it may imply one or two raster lines difference.

If you want to put it in test, run e.g. https://demozoo.org/productions/205747, there's a pretty Timer-B / HBL demanding plasma in both RGB and VGA.

Ooo, ideal. Thanks for that.

I think the diag cart runs in ST MED so one line off, perhaps.

My guess would be that this isn't an issue with counting but more like with timing, i.e. that the interrupt takes a bit longer (or shorter) than it should.

Aha, so perhaps that's where the accelerator gets in the way. I'll see if I can reproduce it at 16MHz mode.

Thanks,

BW

[Badwolf]

Well that excalated quickly.

From running BadMood and a full-blown MiNT installation I now have a Falcon which stops executing code after about 700ms. The video never initialises.

What started out as an odd IDE error, then that T4 Video Counter timing fault seemed to expand and expand. At one point the diagnostic cartridge was running so slowly each charcter on the screen was taking a second to appear.

Here's a little bit of a snip of it running, with a new failure, at slow, but not quite that slow, speed:





Oh well. So much for the triumphant part three conclusion video. Out comes the harness...

IMG_9288sm.jpeg

BW

[exxos]

IIRC running slowly is when the CPU doesn't see DTACK and it times out to complete the cycle with GLUE logic, whatever the Falcon version is.

But if your having odd video corruption as well, maybe a couple lines iffy somewhere ? Maybe resolder the videl, cpu, combel ?