Would someone with a Quadra 700/900/950 be willing to test a program for me?

[dougg3]

This second one is moving the mouse around the entire time that the test is running.

Thank you @jmacz! This confirms exactly what I expected to see, and shows MAME is acting just like hardware with the 950. No worries about re-testing that anymore @Callan! Thanks!

Quadra AVs don't have an ASC or EASC so that's expected.

I should probably add a check to only run these tests if the AddrMapFlags contain both VIA2 and ASC, to prevent crashes on incompatible hardware.

So...looking through these results in general, and making a few educated guesses, it seems like:

• Original ASC interrupts on FIFO full and FIFO half empty, no repeats. Clears register $804 on read.
• No other variants clear $804 on read, as far as I can tell.
• EASC interrupts on FIFO half empty, only if $F09 or $F29 is 0 for the respective channel. Doesn't repeatedly fire.
  • The Q700 looks like it repeats (same with Q950 when mouse is moving) but it's due to special code in the OS and/or ROM.
• Version $Ex interrupts on FIFO half empty, and repeats forever
• Versions $BB and $BC have varying behavior on different machines. They both interrupt on FIFO half empty if $F29 is 0. On some machines the IRQ floods forever, on some machines it doesn't.
• Variants with the $F29 register will fire an IRQ immediately if $F29 changes to 0 and the condition is active. (I'm assuming EASC does the same thing with $F09 for channel A)

 

[Callan]

Thank you @jmacz! This confirms exactly what I expected to see, and shows MAME is acting just like hardware with the 950. No worries about re-testing that anymore @Callan! Thanks!

Your welcome. If you need anything else tested lmk.

 

[dougg3]

I just uploaded version 3 with a few new tests and improvements. I definitely won't ask everyone to re-test everything because I don't expect we'll learn much on most models.

@Callan, @cgp, or @jmacz, would you be so kind as to re-test the Quadra 700 with the latest version? It should say something at the bottom about how it temporarily disabled the ASC VBL task, and the results should now be similar to the 950 without mouse movement. It works that way in MAME now anyway. Thank you!

 

[jmacz]

Quadra 700

 

[dougg3]

Thank you @jmacz! This confirms my suspicions, and the Quadra 700's hardware is now being tested "properly". My VBL disable hack works on hardware, woohoo! I really appreciate your fast test on that!

 

[jmacz]

Thank you @jmacz! This confirms my suspicions, and the Quadra 700's hardware is now being tested "properly". My VBL disable hack works on hardware, woohoo! I really appreciate your fast test on that!

No problem!

 

[Arbee]

I'd love to see results from a II, IIx, IIcx, or SE/30 too, just to get data on the original ASC + discrete VIA2 combination. (Those 4 machines are identical for this testing, so I only need one of them).

 

[Callan]

se/30 test. It has a bmow rom in it. Not sure if that will skewe the result. If so I can get you one with an original rom lmk.

 

[cgp]

My Q700 is the same as @jmacz except for the Stereo FIFO Tests ending (1108 1108) not (1103 1103) - different system sound config??

 

[dougg3]

se/30 test. It has a bmow rom in it. Not sure if that will skewe the result. If so I can get you one with an original rom lmk.

Thanks! That result is interesting. I'm not sure how to explain the 2 "other" IRQs at the bottom. Maybe bits in FIFO A were set instead and they fired not quite at the same time. (That test is only looking at the FIFO B IRQ bits). I'll have to think about how to decipher that further. Might have to get my SE/30 or IIx into working order.

I don't think the ROM will skew the results at all.

My Q700 is the same as @jmacz except for the Stereo FIFO Tests ending (1108 1108) not (1103 1103) - different system sound config??

Perfect, thanks. Those numbers are for informational purposes only and will vary a bit even on different runs of the same machine. It's the number of audio samples that were written to the chip before it said it was full. Makes sense, it should always be more than 1024 because I think that's approximately the size of the FIFO, and the FIFO is emptying itself as I'm filling it.

 

[Callan]

Thanks! That result is interesting. I'm not sure how to explain the 2 "other" IRQs at the bottom.

Leave it to me to throw a wrench in the works again. It seems to be my forte´.

 

[dougg3]

Leave it to me to throw a wrench in the works again. It seems to be my forte´.

Haha! Well, you have provided very valuable information both times this has happened, so I'm grateful!

 

[Arbee]

Thanks again Callan! Wrenches are good, it makes sure we understand what's actually happening. That actually does line up with what I'm seeing in MAME where I got IIci perfect when spamming the Sound control panel, but SE/30 and friends are two IRQs short. Like Doug I don't have an explanation for why that's happening yet though.

 

[dougg3]

@Callan (anybody else with an SE/30, II, IIx, or IIcx is welcome to try too!) can you please try running this test branch of the program on one of those older machines?

GitHub - dougg3/ASCTester at se30_testing

Tester program for the classic Mac ASC chip. Contribute to dougg3/ASCTester development by creating an account on GitHub.

github.com

It prints out info at the bottom about interrupt status values and timing. My IIci's output typically looks something like this:

2 IRQs (start time = 239540243):
$0A at t = 239540987
$05 at t = 239563997

...which makes sense. $0A means both FIFOs are full, then $05 means both FIFOs are half empty. But sometimes (less often) it has 3 IRQs, in which case it looks like the ASC is firing the half empty IRQ immediately when I re-enable interrupts, and then behaving normally:

3 IRQs (start time = 453200387):
$05 at t = 453200331
$0A at t = 453201124
$05 at t = 453224130

One guess for that discrepancy is maybe as I'm initially filling the buffer up, right when I'm at half full but still going upward, the ASC happens to pull a sample out, which drops it below half full again and re-arms the IRQ. (Just a guess though!)

The SE/30 behavior depicted was different. I'm curious to see what we get for output on the machines listed above. Maybe run the test a few times to see if it's consistently the same number of interrupts. Thanks!

 

[Callan]

Here is the new code ran on the same se/30.
Ran it multiple times. Attached 3 of the instances.

 

[dougg3]

Here is the new code ran on the same se/30.
Ran it multiple times. Attached 3 of the instances.

Thanks @Callan! That's very helpful. What in the world...the behavior changed. I pushed one more change to the same link as last time. When you get a chance, will you please try it out?

There was never an interrupt that showed channel B's FIFO full. I think this explains why channel A saw thousands of "FIFO full" interrupts, because I keep writing samples for a while, either until FIFO B says it's full, or a counter gets too big. I think what happened here is the counter got too big. So that means I was constantly writing new samples to the FIFO while it was already full. This caused repeated "FIFO A full" interrupts. That all makes sense.

But...why wasn't FIFO B's full bit ever set? It should have been. Wouldn't the ASC latch that state until the next read? Is this evidence that maybe it doesn't, at least in certain conditions?

My change did end up calling Microseconds() as the first thing in the IRQ handler, which is a bit naughty. Instead of that, I probably should be acknowledging the IRQ and reading the ASC's status register immediately before anything else. I'm also not sure how valid it is to call Microseconds() from an IRQ handler, but I'm getting hacky here just to understand what's going on. My new commit reorders that.

Interestingly, I got this result the first time I ran this latest version on my IIci:

(1 1), (1 1), (0 0), (1 1), 1
3 IRQs (start time = 119265903):
$02 at t = 119266646
$0A at t = 119266710
$05 at t = 119289704

I guess this makes sense. There's a time period between when I write a sample to FIFO A and when I write the same sample to FIFO B. If the interrupt fires at that exact moment, it's plausible that only FIFO A would show as full. Almost immediately afterward, I got the expected "A and B both full" IRQ.

I retried a couple more times and could not reproduce that initial $02 IRQ, so it's fairly rare at least on the IIci.

 

[Callan]

Update. I ran it again and i got a different fifo result (machine had sat off for a while). Restarted and it's back to 1000 on the fifo again.

 

[Callan]

Yeah... I was looking for a way to duplicate it, but it seems random. Ran the test 3 times and got 1000 on fifo. Ran it one more time and got 1010.

 

[dougg3]

Very weird! I’m curious to see if it changes with that tweaked version I just posted. The FIFO B full IRQ is never firing for some reason!

 

[Callan]

Very weird! I’m curious to see if it changes with that tweaked version I just posted. The FIFO B full IRQ is never firing for some reason!

Is that not the new one I'm running? Did you update the code with a new one?