| Click here to select a new forum. |
| Would someone with a Quadra 700/900/950 be willing to test a program for me? |
Posted by: dougg3 on 2026-01-20 21:09:31
Is that not the new one I'm running? Did you update the code with a new one?
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!) |
Posted by: Callan on 2026-01-20 21:29:37
Nope... I read the your description and somehow missed the start of the paragraph (sigh). Here are a couple with the new one. I've run it over 15 times now and the fifo is staying the same. |
Posted by: dougg3 on 2026-01-20 21:38:40
Nope... I read the your description and somehow missed the start of the paragraph (sigh). Here are a couple with the new one. I've run it over 15 times now and the fifo is staying the same.
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? |
Posted by: Callan on 2026-01-20 21:53:58
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) |
Posted by: dougg3 on 2026-01-20 22:01:52
Original version 3 (non se/30 specific) reports (multiple runs)
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! |
Posted by: dougg3 on 2026-01-21 15:32:38
@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! |
Posted by: Callan on 2026-01-21 19:50:05
Here are 4 tests with the new app (se/30 ver 3). |
Posted by: dougg3 on 2026-01-21 21:52:13
Here are 4 tests with the new app (se/30 ver 3).
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. |
Posted by: Arbee on 2026-01-22 08:14:02
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. |
Posted by: dougg3 on 2026-01-23 15:40:51
@Callan Tired of my requests yet? 🙂 I made one more improvement to the SE/30 testing branch, forcing the FIFO writes to A and B to be back-to-back. I'm curious if this eliminates (or at least minimizes) the extra IRQs. Same test link again: https://github.com/dougg3/ASCTester/tree/se30_testing
If this works, I'll probably switch the tester to use this new approach on everything with the next revision. I had to write assembly code to force the FIFO B write to be *immediately* after the FIFO A write. |
Posted by: adespoton on 2026-01-23 16:30:56
@Callan Tired of my requests yet? 🙂 I made one more improvement to the SE/30 testing branch, forcing the FIFO writes to A and B to be back-to-back. I'm curious if this eliminates (or at least minimizes) the extra IRQs. Same test link again: https://github.com/dougg3/ASCTester/tree/se30_testing
If this works, I'll probably switch the tester to use this new approach on everything with the next revision. I had to write assembly code to force the FIFO B write to be *immediately* after the FIFO A write. Doug, by the time you're done here, your application will be the only thing people will ever need to run a hardware test (assuming they can boot to Finder)! Move over Tech Tool! |
Posted by: dougg3 on 2026-01-23 18:04:38
Doug, by the time you're done here, your application will be the only thing people will ever need to run a hardware test (assuming they can boot to Finder)! Move over Tech Tool!
Ha! It’ll be its own operating system by the time I’m done with it. 😀 |
Posted by: dschnur on 2026-01-23 18:52:05
I have a prototype Quadra 700 and a release version. If you'd like, I can run it on both systems. |
Posted by: dschnur on 2026-01-23 19:59:53
Here's one from a Prototype Quadra 700: |
Posted by: dougg3 on 2026-01-23 20:25:17
Here's one from a Prototype Quadra 700: Thank you! Out of curiosity, would you mind running this version on it too? Your test showed one small peculiarity I’m interested in. https://github.com/dougg3/ASCTester/tree/se30_testing |
Posted by: Callan on 2026-01-23 21:18:51
Naw! Any time you need a test, I'm down to help.
Any reason to turn a Mac on is a good reason. 😁
Asc version 6 (se/30 version). 4 runs. |
Posted by: dougg3 on 2026-01-23 21:27:50
Naw! Any time you need a test, I'm down to help.
Any reason to turn a Mac on is a good reason. 😁
Asc version 6 (se/30 version). 4 runs.
Awesome, thank you! And I agree! With the quicker write to FIFO B, your SE/30 responds just like my IIci, so everything is making sense. |
Posted by: dschnur on 2026-01-24 06:06:26
Here's the second one (Prototype Quadra 700) |
Posted by: dougg3 on 2026-01-24 08:24:15
Here's the second one (Prototype Quadra 700)
Thanks! I appreciate it! Interestingly enough, the weird anomaly I noticed on your first test didn't happen during this test. The extra unknown IRQ in the first test was probably a "FIFO A half empty" IRQ firing without FIFO B showing up as half empty. |
Posted by: dschnur on 2026-01-24 08:42:51
Thanks! I appreciate it! Interestingly enough, the weird anomaly I noticed on your first test didn't happen during this test. The extra unknown IRQ in the first test was probably a "FIFO A half empty" IRQ firing without FIFO B showing up as half empty. Interesting. This is a prototype and has some programmable logic on it that's probably a different from the final release. |
| < 4 > |