Sorry, it got buried in my long technical details. Yes, after you posted your first result today, I posted a new one with a small tweak to the logic that will hopefully make things work differently. (Unless you already saw that and the latest results are testing that version!)
Would someone with a Quadra 700/900/950 be willing to test a program for me?
- Thread starter dougg3
- Start date
Sorry, it got buried in my long technical details. Yes, after you posted your first result today, I posted a new one with a small tweak to the logic that will hopefully make things work differently. (Unless you already saw that and the latest results are testing that version!)
Thanks! Rats, I'm having a lot of trouble understanding why it's doing that. Is the original ASCTester v3 still looking the same each time with
(1 1) (1 1) (0 0) (2 2) 1 at the bottom?
Original version 3 (non se/30 specific) reports (multiple runs)
(1 1),(1,1),(0 0) (5 5), 1
(1 1),(1,1),(0 0) (2 2), 1
(1 1),(2,1),(0 0) (4 4), 1
(1 1),(1,1),(0 0) (2 2), 1
(1 1),(1,1),(0 0) (4 4), 1
(1 1),(1,1),(0 0) (3 3), 1
And another wrench...
(2 2),(1,1),(0 0) (1 1), 1
(Was moving the mouse while this last one tested)
(1 1),(1,1),(0 0) (5 5), 1
(1 1),(1,1),(0 0) (2 2), 1
(1 1),(2,1),(0 0) (4 4), 1
(1 1),(1,1),(0 0) (2 2), 1
(1 1),(1,1),(0 0) (4 4), 1
(1 1),(1,1),(0 0) (3 3), 1
And another wrench...
(2 2),(1,1),(0 0) (1 1), 1
(Was moving the mouse while this last one tested)
Thank you for being so kind and putting up with all my requests, and so quickly too! Those results seem fairly consistent at least, so that’s good. The only thing I can think of is maybe calling Microseconds() in the IRQ handler is not allowed and I’m breaking things by trying. Maybe I should just try Ticks for measuring the time and see what happens.
I’ll sleep on it and try to come up with another test idea!
@Callan I pushed a new test app here: https://github.com/dougg3/ASCTester/tree/se30_testing
Technical detail: The difference in this latest attempt is I'm timing the IRQs with Ticks instead of trying to get microseconds. Ticks only give 1/60th of a second resolution which is not ideal, but they're easier to read so I'm hoping this eliminates the weird flooding we're seeing when I try to print more details. Thanks!
Technical detail: The difference in this latest attempt is I'm timing the IRQs with Ticks instead of trying to get microseconds. Ticks only give 1/60th of a second resolution which is not ideal, but they're easier to read so I'm hoping this eliminates the weird flooding we're seeing when I try to print more details. Thanks!
Yay, thank you so much! That's more like what I was expecting to see based on your earlier SE/30 test results. Too bad the Ticks variable doesn't give us great timing info, but I think it's enough to provide a decent theory about what's happening.
After pondering some more, I think this is all starting to make sense. Technical stuff that @Arbee will possibly be interested in:
In the first result, the first IRQ was a "FIFO A and B both half empty" IRQ, even though clearly the FIFOs hadn't filled up yet. My guess/theory: the ASC probably happened to pull out a sample exactly when the FIFOs were just above half empty, causing the half empty condition to be latched into the register even though ASCTester was still filling it up. As soon as I enabled IRQs, it fired immediately due to that. I think it's the same situation I occasionally see on my IIci when there are 2 half-empty IRQs instead of 1.
That one example aside, in general, it looks like what's happening is FIFO A is marked as full first and the IRQ handler is running before FIFO B's sample has been written. This happens repeatedly, and eventually sample B somehow gets written quickly enough too, but it takes a few tries. Then it falls back to expected behavior (a single "half empty" IRQ after I'm done filling it), although I see that we get one more "FIFO A full" IRQ again first.
I think the tests yesterday were going bonkers because I made the ISR too complicated and CPU-intensive by calling Microseconds, and it took long enough that the ASC ate up another sample, so by the time the FIFO B sample was written that should have made it full as well, it wasn't full anymore. In other words my ISR ran for so long after filling FIFO A that it was impossible for FIFO B to ever be full.
The big question: why doesn't this ever happen on my IIci? It's the same ASC chip, right? Maybe it takes a tad bit longer for the IRQ to be signaled on the IIci, so my second sample has already been written before the handler runs? (VIA vs. pseudo-VIA?) Or maybe the IIci's faster CPU is able to write the corresponding FIFO B sample before the IRQ manages to fire. I wonder if I'm supposed to leave IRQs disabled while filling the FIFO or something. I'll have to see what Apple's driver does with the original ASC.
Either way, I think I'm starting to see why they took the "FIFO full" interrupt out of later ASC versions. It's broken (or at least flawed) in stereo mode, at least on the SE/30, because it fires before the B sample has been written. I'm trying to think about how to turn this into an actual test to run.
TBH though, the full interrupt is pointless anyway. It doesn't make sense to use from a software perspective. You wouldn't want to use an IRQ to determine when to stop filling it. You'd poll the status register directly when filling, and then use the half empty interrupt to know when to start filling again.
Last edited:
I'd generally expect the real VIA to be slower than the pseudo-VIA given it's more complex, so I'd lean towards the faster CPU in the IIci making the difference.
And yeah, I understand why FIFO full bit went away. It's not useful in any case, especially if you just leave the ASC enabled after a sample has completed.
And yeah, I understand why FIFO full bit went away. It's not useful in any case, especially if you just leave the ASC enabled after a sample has completed.
Similar threads
