How to investigate failing Blitter access while CT60 active?

[mikro]

To avoid going off topic in viewtopic.php?f=29&t=7224, I have created this one for some brainstorming.

To reiterate, I have a Falcon which refuses to work reliably with CT63 r2022 by Centuriotech and it applies only to this specific CT63. I have tried two other CT60s (original CT60 and CT63 by R. Czuba) and they don't show any issues. Also, putting the problematic CT63 into another Falcon shows no issues.

So clearly, something is fishy about this particular combination of motherboard and CT63. If I boot into 030 mode, even with this CT63, all is good, too.

The problem can be demonstrated by *any* Blitter access, it freezes the machine. For example:

- drawing Atari logo upon boot (only in CT60TOS 1.03; 1.05 draws the logo using software routines so it doesn't freeze)

- running the "Short Blit" in diagnostic cartridge (thankfully CT60TOS 1.05 still contains the diagnostic cartridge inside!) but also the video test (which presumably uses the Blitter, too) ... the "Short Blit" test even shows me "EB Access Error" a few times and only then freezes (!)

- XBoot (uses VDI and therefore Blitter)

- booting into desktop and accessing any menu (again, uses VDI and therefore Blitter)

Initially, I could get rid of this behaviour when I booted the Falcon after letting it "cool off" for a while. Then it booted and if I avoided any Blitter access (i.e. using CT60TOS 1.05, NVDI, skipping XBoot or running it after NVDI, not running any Blitter-intensive software, ...) I could use machine normally in 060 mode.

For a while I thought that installing the V2 clockpatch fixed the problem (previously there was no clockpatch) but it didn't last long (to this day I have no clue how could such behaviour change overnight...) and currently the problem is always there, even if I let the Falcon switched off the whole night, it always freezes on the Atari logo (in CT60TOS 1.03 of course).

As I have tried literally everything concerning the configuration of this Falcon and/or CT63, I guess it is a good time to start some serious investigation. As mentioned in the other thread, I can even measure some things on the scope but I lack some good starting point.

I have re-read @Badwolf's advice in the non-booting Falcon thread however I'm not sure I can apply any of it here as everything is running as long as you don't touch the Blitter part in Combel.

So any hint on where to begin with, what to check... I guess it will involve checking some signals between the CPU and Combel but my knowledge about the order and meaning is fairly insufficient. Thankfully I can always compare the reading between 030 and 060 modes but I need to know where to look first.

[mikro]

One thing I had in mind was to create a custom CT60 TOS image which would have the first instruction accessing the Blitter and then just stop (or enter a loop with flashing screen so I would see whether the machine froze or not).

That way I could hook on some signals immediately after reset but still, no clue what should I check.

[Steve]

One thing I had in mind was to create a custom CT60 TOS image which would have the first instruction accessing the Blitter and then just stop (or enter a loop with flashing screen so I would see whether the machine froze or not).

That way I could hook on some signals immediately after reset but still, no clue what should I check.

Was it Rustnut? Who was experimenting with over clocking their Falcon bus. He disabled blitter in TOS because the blitter would crash if the bus was overclocked. This is why the phantom and nemesis had programs that would enable it once TOS was booted. Apparently the Atari logo would actually use blitter, which is why bus boosting can't be done 'by default' and had to be enabled later.

I dunno if that info helps you.

[Cyprian]

Was it Bikerbob ? Who was experimenting with over clocking their Falcon bus. He disabled blitter in TOS because the blitter would crash if the bus was overclocked. This is why the phantom and nemesis had programs that would enable it once TOS was booted. Apparently the Atari logo would actually use blitter, which is why bus boosting can't be done 'by default' and had to be enabled later.

I dunno if that info helps you.

from my experience, the BLiTTER was completely stable with overclocked bus to 20MHz ( and 40MHz 030 in my case ) and was unstable wit 24/50MHz bus (48/50MHz CPU)

[Steve]

Was it Bikerbob ? Who was experimenting with over clocking their Falcon bus. He disabled blitter in TOS because the blitter would crash if the bus was overclocked. This is why the phantom and nemesis had programs that would enable it once TOS was booted. Apparently the Atari logo would actually use blitter, which is why bus boosting can't be done 'by default' and had to be enabled later.

I dunno if that info helps you.

from my experience, the BLiTTER was completely stable with overclocked bus to 20MHz ( and 40MHz 030 in my case ) and was unstable wit 24/50MHz bus (48/50MHz CPU)

Yes mine too .. but what I'm trying to say is that the blitter can't be overclocked on the initial atari logo screen. This is why bus overclocking can't be done permanently, and has to be done by software once TOS is loaded.

Rustnut got around it by patching TOS to not enable blitter at boot ... why this is the case, I cannot remember.

I might be getting confused ... but it's something I read about during Rustnut's trials.

[ijor]

Deleted. Wrong post.

[mikro]

I think it was @Rustynutt and IIRC, he just halved the Blitter clock (from 16 MHz to 8 MHz).

However you can't disable the Blitter. There's a lot of bad info over the forums, you simply can't. The only thing you can do is:

- disable Blitter usage in VDI (TOS 1.x / 2.x)
- disable Blitter usage in VDI via using NVDI (TOS 4.x)

Btw in my Phantom'ed Falcon I had no issues with Blitter running at 25 MHz.

Anyway, this is what I tried as well, i.e. booting with the Blitter at 8 MHz, didn't help. Did I mention that I had tried literally everything?

So I really need some clues as of how to starting debugging.

[Steve]

@mikro I think all you can do is experiment with all different flavors of clock patches... How many have you tried?

Also perhaps make sure the 4700uf capacitor on the motherboard is good.

[mikro]

While it is surely the quickest test, I would like to inspect this properly and not just try random things. Because so far nothing supports the theory that it has something to do with clock patch (well, except the fact that it worked for a while with the V2...). I wouldn't be surprised if some passive component went off spec a bit or that I accidentally did something to the motherboard when soldering the V2 and it got 'corrected' and now it isn't anymore but that is also just a speculation.

The 4700 capacitor has been replaced, yes.

So that is why I have opened this thread, to avoid just random things and get advice about more systematic approach.

[Badwolf]

So I really need some clues as of how to starting debugging.

I think the first thing I would start with is the bus arbitration signals.

Now, I may be mixing up the ST and Falcon here (this is all off the top of my head, I caution), but IIRC the blitter is a 'proper' bus master. It drives the address and data lines just like the CPU does. The floppy and SCSI OTOH still goes through bus arbitration but I think the address lines are isolated.

Why would that matter? Well the only absolutely outlandish theory I can come up with for what may be going on is that perhaps something is flakey with the BGACK connection between the expansion connector on that Falcon and that particular CT60. Who knows -- bit of grime at just the wrong places on both sides?

Anyway, BR will stop the CPU from initiating any further bus accesses after the one it issues BG on, but (again, IIRC) only assertion of BGK by the peripheral will actually send all the buses high-Z on the CPU.

Perhaps that bus isolation during floppy access is why you don't see a problem there, but you do with the blitter..?

I told you it was outlandish.

Anyway, make sure BR and BGACK are being seen by the CPU (however that works on an 060), and that BG is being seen on the motherboard (that one is complicated as it's on the expansion connector in three different guises, but you're interested in it at COMBEL, I'd imagine).

Which reminds me -- I have to do some jiggery pokery with bus arbitration on DFB1 as there is another top-dog bus master sat there just under the board (ie. the onboard 030). I imagine CT60 has to do something similar. Perhaps it's as simple as a failing CPLD which can just about drive enough current for one board but not another somehow?

BW