NOVA VME + blitter = DMA audio bugs?

[mrbombermillzy]

A version for TT/ET4000/M32 may open up the no. of people who can test.

At least we can be 100% certain that there won't be any Blitter-induced audio artifacts on the TT. (The TT doesn't have a Blitter.)

Good point!

I take it the M32 version also uses ST/e blitter or did you manage to get the M32 BTBLT operational?

Otherwise, sorry. I have TT, Mega ST, ET4000 and Mach32 but NOT ISA adapter for the Mega ST. Therefore need an 030 version with software/CPU 'block transfers'.

[fenarinarsa]

I take it the M32 version also uses ST/e blitter or did you manage to get the M32 BTBLT operational?

Otherwise, sorry. I have TT, Mega ST, ET4000 and Mach32 but NOT ISA adapter for the Mega ST. Therefore need an 030 version with software/CPU 'block transfers'.

The M32 test binaries are provided with both versions, blitter and software.

The M32 bitblt wouldn't help unless I rewrite the effect to transfer the whole font into the video memory card (like a texture) then do M32 bitblt calls. No more transfers between ST/TT-RAM and the video RAM in this case
I'm not there yet, but the advantage of this intro is that it's a simple enough effect to be a good test case.

[Idek Tramielski]

Same observation with the Mach32:
Blitter version shows clicking noises.
Software version shows noises at 8MHz and 16MHz-cacheoff. 16MHz-cacheon is pretty (but not totally) quiet. It clicks maybe 5-6 times during one loop.

[fenarinarsa]

Same observation with the Mach32:
Blitter version shows clicking noises.
Software version shows noises at 8MHz and 16MHz-cacheoff. 16MHz-cacheon is pretty (but not totally) quiet. It clicks maybe 5-6 times during one loop.

Thanks for the feedback. That's really unfortunate, I also have clicks in software mode. Not always, but they're here.

BTW which RAMDAC does your Mach32 have? It seems the colors are wrong with Bt481.

[czietz]

BTW which RAMDAC does your Mach32 have? It seems the colors are wrong with Bt481.

Mine has a ATI68875.

[Idek Tramielski]

BTW which RAMDAC does your Mach32 have? It seems the colors are wrong with Bt481.

Mine also has the ATI68875. The BT481 is not very common and afair limits the Mach32's abilities.
I made a special version for Frank some time ago that supports the BT481 partially.
But I guess its only a TT version. I will look if I can figure out what I changed back then.

[Idek Tramielski]

I don't know if I will be able to release the demo for 320x240, last time I tried to create this mode with VMG.PRG (Mach32), it wouldn't allow me to create low resolutions.

The reason for this is the different way the ET4000 and the Mach32 work. The "Low res." button in VMG actually sets the timing sequencer of the VGA register of a ET4000 card. The Mach32 does not use the VGA register for anything above 2 (maybe 16) colors. Maybe I can find another way to divide the frequency by two.

[fenarinarsa]

It looks like the BT481 works in 6-bits component colors. I think there's a register that specify the number of bits per component, I may need to check it.

And for the low res on M32, I checked the extended registers and all the information I could find in libvga.config and svgalib but you're the specialist here -_-

Some other news about the audio clicks, I'm working on another project (not on VGA card) that uses the blitter and DMA loading and I heard the same audio clicks on my Mega STE. I went back on my STE and no audio issue... So indeed, it may not be related to VME at all. I still need to try swapping chipsets but I'm waiting for a PLCC extractor to do that, so it's going to be after Christmas.

[Idek Tramielski]

And for the low res on M32, I checked the extended registers and all the information I could find in libvga.config and svgalib but you're the specialist here -_-

I wish I were....whenever I add another DAC to the code, it is more like pulling teeth.

Some other news about the audio clicks, I'm working on another project (not on VGA card) that uses the blitter and DMA loading and I heard the same audio clicks on my Mega STE. I went back on my STE and no audio issue... So indeed, it may not be related to VME at all. I still need to try swapping chipsets but I'm waiting for a PLCC extractor to do that, so it's going to be after Christmas.

I used two small screwdrivers since my PLCC extraction tool did not work on the chip (too small-works well for the 68k or Blitter size chips). I am looking forward to your tests since the C300588 didn't help with my setup.

[fenarinarsa]

At last i could do the test today!

My MSTE has a C301712 and I swapped it with the C300588 from one of my STE - actually my own original STE.

And it works! No more PCM audio cracks when using the blitter!

So it's definitively the previously-known audio hardware issue.

shifter.jpg

shifter2.jpg

[viking272]

My MSTE has a C301712 and I swapped it with the C300588 from one of my STE - actually my own original STE.

And it works! No more PCM audio cracks when using the blitter!
So it's definitively the previously-known audio hardware issue.

I swapped my C301712 with a C300588 in my CA400677 board. Clicking noises are still there, maybe a little less, but still present.
Full demo still crashes.

Idek suggests with those two chip swaps the clicking noise is there and the demo crashes, but fenarinarsa, you said it works perfectly now?

[stormy]

At last i could do the test today!

My MSTE has a C301712 and I swapped it with the C300588 from one of my STE - actually my own original STE.

And it works! No more PCM audio cracks when using the blitter!

So it's definitively the previously-known audio hardware issue.



shifter.jpg
shifter2.jpg

We were just talking on Exxos forum about how the 'newer' GST shifter C301712 makes the 16/32mhz clocks 10ns out-of-phase: https://www.exxoshost.co.uk/forum/viewt ... =30#p77931

[metalages]

I am currently working on various effects on STe (not MSTe) while DMA audio is looping (50khz stereo) and audio cracks happen more or less depending on the activity of the code / blitter (I have not found specific patterns yet)

[fenarinarsa]

The last test: it actually doesn't work correctly on STE with the C301712.

I did a small test program and audio cracks still appear.
https://github.com/fenarinarsa/ste_dmatest/releases/

So yes, in my case the C301712 is the definitive culprit.

[metalages]

My STe is from 1989 not modified

[czietz]

I ran your DMATEST.PRG on my 1040STE (fresh out of storage) with C301712 shifter and I heard the audio "pops". After running the machine for a while I don't get them anymore. So, for me, it's not (only?) related to the shifter but (also?) to temperature. I shall try freeze spray next time I have the STE open.

[ijor]

Interesting. Please let me see if I understand correctly:

1) The sound issue also happens on a bare STE (not just on a MSTE with NOVA).
2) The DMA sound is configured as a dummy buffer loop (not reloaded or changed by the CPU in anyway).
3) The sound issue seems to be related to CPU and/or Blitter activity (besides possibly other things)

Correct?

[ijor]

We were just talking on Exxos forum about how the 'newer' GST shifter C301712 makes the 16/32mhz clocks 10ns out-of-phase: https://www.exxoshost.co.uk/forum/viewt ... =30#p77931

Interesting. But why this would be relevant to DMA audio issues?

[Cyprian]

Interesting. But why this would be relevant to DMA audio issues?

the MMU 'sends' the audio data to the GST Shifter, which passes them to the DAC : https://info-coach.fr/atari/hardware/STE-HW.php#shifter

[fenarinarsa]

Interesting. Please let me see if I understand correctly:

1) The sound issue also happens on a bare STE (not just on a MSTE with NOVA).
2) The DMA sound is configured as a dummy buffer loop (not reloaded or changed by the CPU in anyway).
3) The sound issue seems to be related to CPU and/or Blitter activity (besides possibly other things)

Correct?

Correct.

[czietz]

I can now present to you the first measurement (inside my 1040STE) of the audio crackle with fenarinarsa's test program:



I measured at U500, one of the flip-flops that latch the sound data for the DAC. The yellow trace is the load/clock signal; with every rising edge, new data is loaded into the flip-flops. The light blue trace is one of the data bits going to the DAC. As the DMATEST programs plays a buffer consisting of only zeros, it should stay low all the time. Whenever one of the flip-flop outputs (=DAC inputs) goes high erroneously, you hear a crackle or pop in the audio output.

Now, why does the data bits go high? The purple trace is the input to the flip-flop. The STE Shifter is known to suffer from ground bounce - I have shown this in earlier investigations already. And this is precisely what happens here! The "spike" in the input coincides with the rising edge of the load signal. As you can see, it does not reach proper "high" level. This is why the crackling sounds random, the spike does not cause the output of the flip-flop to go high every time.

Fortunately, this means this should be fixable. Let me think about a solution...

[metalages]

whaou impressive
thanks for the investigation

[ijor]

We were just talking on Exxos forum about how the 'newer' GST shifter C301712 makes the 16/32mhz clocks 10ns out-of-phase: https://www.exxoshost.co.uk/forum/viewt ... =30#p77931

Interesting. But why this would be relevant to DMA audio issues?

the MMU 'sends' the audio data to the GST Shifter, which passes them to the DAC : https://info-coach.fr/atari/hardware/STE-HW.php#shifter

MMU does setup the transfers from RAM to shifter. So? This still doesn't explain why that would be relevant.

[metalages]

Seems in my case, it is more related to blitter activity than CPU,
and in particular when I use OP = (source XOR destination) HOP = source generating a lot of resulting 0xFFFF values

[stormy]

We were just talking on Exxos forum about how the 'newer' GST shifter C301712 makes the 16/32mhz clocks 10ns out-of-phase: https://www.exxoshost.co.uk/forum/viewt ... =30#p77931

Interesting. But why this would be relevant to DMA audio issues?

the MMU 'sends' the audio data to the GST Shifter, which passes them to the DAC : https://info-coach.fr/atari/hardware/STE-HW.php#shifter

MMU does setup the transfers from RAM to shifter. So? This still doesn't explain why that would be relevant.

Well don't you think the clocks being out of sync would be relevant? If not, why not?