Recent content by dougg3

Thanks for that kind offer @Callan! I’d say let’s hold off for now, but I will definitely take you up on it later. I found a small bug yesterday and I want to make a version 4 (maybe with some additional tests) before I ask for a bunch of re-tests.

I was super curious if your prototype's EASC chip would behave any differently, but honestly I think it's the same. I'm guessing that it's occasionally normal for that second interrupt to happen. Thanks again for testing that! I'm trying to document Apple Sound Chip behavior on every 68k Mac...

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.

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.

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

Ha! It’ll be its own operating system by the time I’m done with it. :D

@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...

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...

@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...

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...

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?

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!)

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!

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...

@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? https://github.com/dougg3/ASCTester/tree/se30_testing It prints out info at the bottom about interrupt status values and...