digistorm wrote on 2024-01-27, 19:43:

The demo's of Triton hang randomly in the way, that the playback routine seems to stall but the effects go on. If the demo code […]
Show full quote

Pickle wrote on 2024-01-27, 17:23:

ill try this demo on my 486 opti chipset, can you describe the problems?

The demo's of Triton hang randomly in the way, that the playback routine seems to stall but the effects go on. If the demo code doesn't wait for a cue from the module and it loads a new song, it is fine. If it does wait for a cue it will eventually crash.
The Gravis Ultrasound Advertisement of Triton hangs in the first part, quite quickly, but picks up with the second part (with a new song). The parameter /d 8 seemed to help.
Crystal Dream II hangs after 5 minutes, sometimes a bit earlier, but often around the torus effect. With the parameters /d 2 /a 32 I managed to finish and exit the demo 2 times, but not always. That was a lot of testing 😬
It is not entirely deterministic unfortunately, but with the default initialisation it pretty much hangs in the same spot (it seems).

But this may also all be a weird bug of the chipset instead of the PicoGUS. I just have no idea how to figure it out. All other demo's and games work fine. Only Verses and Caero need the /a 8 parameter, and this chipset seems to be the only one that needs it so far (haven't read about others having this issue). Still a very minor set of demo's that has problems with this chipset.

Thank you for the very detailed report! I've seen Triton demos reported to have issues but haven't been able to reproduce them myself. I just this past week got a 486 motherboard with the same chipset as you, so hopefully I'll also be able to also see this freeze!

While working on the SoundBlaster emulation, I did find a bug in my timer code that drives DMA and IRQs... I'm hoping that fixing it for SB will also fix some of the issues on GUS. Fingers crossed... 🤞

Whoops, I misremembered the chipset for the board I just got: it's an SiS 85C496/497, but I figured it was worth testing because it's of a similar vintage. I ran Crystal Dream II on loop (run "cd2 L") for 2 hours with no freezes or silent music on firmware v1.0.2. I also got out another 486 board with a SiS chipset, the SiS 85C460. It's been running Crystal Dream II for 2 hours also with no problems. So without this chipset I'm not entirely sure how to figure out the issue (unless I implement one of rasz_pl's awesome bus capture ideas). @digistorm I'll send you a test firmware with the timer bugfix, there's a small chance it may improve things for you...

I decided to also test Crystal Dream II with the CPU at stock settings (66 MHz, 33 MHz bus, 8.33 MHz ISA bus) but it stalls in exactly the same way and in the same spot. Just to rule out that the board didn't like 40 MHz for some reason although I thoroughly stress-tested it.

digistorm go into bios and play with ISA clock settings

rasz_pl wrote on 2024-01-28, 17:30:

digistorm go into bios and play with ISA clock settings

Well. I tried to give it a go, although it is a complete pain because it sometimes takes 5 minutes before the demo crashes 😉
I have a Cyrix DX2/66 running at 40 MHz FSB making a 80 MHz effective clock. During these tests I had the divider at ⅕ making the ISA bus run at 8 MHz. I also tested it at stock settings (33 MHz bus, ¼ divider for 8.33 MHz bus speed) and the result was more or less the same.
Then I lowered the bus speed more and more: ⅙ (6.66 MHz) ⅛ (5 MHz) and 7.159 MHz fixed speed. I also tested it with de-turbo which should reduce the system clock to ⅓ of whatever is set, making the ISA run at 2.66 MHz. And the result was: the lower I put the bus, the earlier it seemed on average to crash. So not really helping…

Out of spite (😉) I then set the bus to ¼ or 10 MHz clock speed, expecting to it not even initialising. But WHAT IN THE WORLD!?
At 10 MHz, which should not even work according to the Wiki, it finishes the whole demo without issue (at least once, I was too fed up to repeat the test 😉). Also a quick run of DOOM2 confirmed that it too ran with an ISA clock of 10 MHz. Maybe there is something really fishy going on with this motherboard, I don't know…

Here are some pictures, I really had the ISA bus running at 10 MHz…

Well, maybe this gives some info? Maybe not 😊

EDIT: Could it be this motherboard is too slow or the PicoGUS is sending some kind of signal too fast for this particular motherboard to notice it unless it's bus is overclocked? This was not what I was expecting…

Sounds like PicoGUS needs a diagnostic mode where it does nothing (so no sound) other than listening to ISA Bus to determine timings. Clock speed, wait states, are all transitions happening at valid times etc. Run 'pgusinit.exe -diagnose', then run some game for a while so ISA bus get exercised, exit and rerun 'pgusinit.exe -report' to see what PicoGus thinks about ISA Bus. Basically Atheatos https://migronelectronics.bigcartel.com/produ … ng-device-v1-01 but on steroids, and cheaper 😀
Much easier to implement than logging while emulating GUS. Can even do pure logging to SPI ram so users of problematic boards can upload dumps instead of Polpo hunting for obscure hardware.

@digistorm That's super interesting! Firmware v1.0.2 has faster assertion of IOCHRDY than previous firmwares, which means it probably actually can handle a 10MHz ISA clock. I haven't tested at that speed yet so the wiki still says 8.33MHz, but I want to see how fast it actually can go now. Now I need to think of why increasing the ISA bus speed would make the timer IRQ more reliable...

@rasz_pl that's a cool idea. I already want to add checking that IRQ and DMA work reliably to pgusinit to ensure people don't have conflicts and that their jumpers are set correctly... bus timing analysis would be another good thing to test.

What would you consider good test cases out of all those demo's and games to find out if it's stable? Or what could be used to stress test it, if that even makes a difference?

Its very hard to debug when you dont see what is happening, thats why Polpo needs same hardware so he can poke and prod at it, or an ISA logic analyzer to let him see peculiarities of the board making trouble. Without that its a lot of stabbing in the dark with random streaks of luck.

i ran the Crystal Dream II on my AMD 486 DX4 OPTI chipset on 1.0.2 firmware with multiple loops and no problems.

also its looking like my original board has a hardware fault as new one has had to issues and works with doom, warcraft 2 perfect now.
i took look under the microscope and R11 has cracks and some discoloration, so its pretty good guess that is the problem.

At $50, the PicoGUS sounds like quite a device, but as a longtime owner of a classic Gravis Ultrasound, I wonder how well the RPi core can approximate the GUS.

The PicoGUS would not have the >12 voice drop in frequency limitation obv and it's just playing samples and I doubt the GF1 put a lot of "nuance" onto a sample. But, if one has a PicoGUS, would the proper move be to frame the GUS and hang it on the wall and let the PicoGUS play the tunes?

The GF1 did linear interpolation in moving 8 bit samples out as 16-bit. Does the PicoGUS? Perhaps it does far better (better interpolation) -- I don't know.
I'm curious about the device.

bp

blakespot wrote on 2024-02-02, 05:48:

At $50, the PicoGUS sounds like quite a device, but as a longtime owner of a classic Gravis Ultrasound, I wonder how well the RP […]
Show full quote

At $50, the PicoGUS sounds like quite a device, but as a longtime owner of a classic Gravis Ultrasound, I wonder how well the RPi core can approximate the GUS.

The PicoGUS would not have the >12 voice drop in frequency limitation obv and it's just playing samples and I doubt the GF1 put a lot of "nuance" onto a sample. But, if one has a PicoGUS, would the proper move be to frame the GUS and hang it on the wall and let the PicoGUS play the tunes?

The GF1 did linear interpolation in moving 8 bit samples out as 16-bit. Does the PicoGUS? Perhaps it does far better (better interpolation) -- I don't know.
I'm curious about the device.

bp

I compare pretty constantly with my original Ultrasound that I've had since 1994 and while there are subtle differences, to my ear it's very close. If you want to get a good feel for what the PicoGUS's GUS emulation is like, fire up DOSBox-X (not mainline DOSBox or DOSBox-staging), enable GUS support and ensure "gus fixed render rate" is off. I originally based my GUS emulation code on DOSBox-X's. While I've changed things quite a bit from when I started, the core of GUS audio rendering hasn't changed much. PicoGUS does drop sampling rate above 14 voices just like the GF1, and there may be a slight difference because the PicoGUS drives its DAC at the GF1 rate instead of DOSBox's output needing to being resampled to whatever your computer's sound card is running at. Both DOSBox-X and PicoGUS's audio rendering code uses linear interpolation just like the GF1 does. 8-bit samples are converted to 16-bit before interpolation is performed.

There's the possibility of better quality, for example always rendering at 44.1kHz or using cubic spline interpolation (8bitbubsy outlined how to do it), but for now PicoGUS renders audio just like a real GUS not just for historical accuracy but because it's a lot easier on the microcontroller and bandwidth to the serial PSRAM I use for sample RAM.

blakespot wrote on 2024-02-02, 05:48:

At $50, the PicoGUS sounds like quite a device, but as a longtime owner of a classic Gravis Ultrasound, I wonder how well the RP […]
Show full quote

At $50, the PicoGUS sounds like quite a device, but as a longtime owner of a classic Gravis Ultrasound, I wonder how well the RPi core can approximate the GUS.

The PicoGUS would not have the >12 voice drop in frequency limitation obv and it's just playing samples and I doubt the GF1 put a lot of "nuance" onto a sample. But, if one has a PicoGUS, would the proper move be to frame the GUS and hang it on the wall and let the PicoGUS play the tunes?

The GF1 did linear interpolation in moving 8 bit samples out as 16-bit. Does the PicoGUS? Perhaps it does far better (better interpolation) -- I don't know.
I'm curious about the device.

bp

My limited take: While we can be certain that a great deal of comparison was done across the years of Ultrasound emulation development (from DOSBox to PicoGUS, etc), I'm not aware of any structured scientific comparison that exists, to compare the different options - e.g. the mdfourier gold standard - and even A-vs-B listener tests aren't easily-findable. The main reason being that rigorous sound comparison testing is quite an undertaking in itself. Accordingly, it's an area where structured comparison data is sparse, across all PC sound cards of all eras. If you are in possession of both the GF1 and PicoGUS cards, then you're in the rare position of being able to do such comparisons personally.

Shreddoc wrote on 2024-02-02, 06:35:

My limited take: While we can be certain that a great deal of comparison was done across the years of Ultrasound emulation development (from DOSBox to PicoGUS, etc), I'm not aware of any structured scientific comparison that exists, to compare the different options - e.g. the mdfourier gold standard - and even A-vs-B listener tests aren't easily-findable. The main reason being that rigorous sound comparison testing is quite an undertaking in itself. Accordingly, it's an area where structured comparison data is sparse, across all PC sound cards of all eras. If you are in possession of both the GF1 and PicoGUS cards, then you're in the rare position of being able to do such comparisons personally.

I did some MDFourier comparisons and it is a pretty overwhelming amount of data. I didn't post them because I wasn't happy with how I recorded them (I used an MOTU M2 audio interface, which has separately controllable L/R input volumes, and it's impossible to get the balance perfect, and I used Cubic Player to play the wav file, which introduced some clicks/pops in the audio). I need to re-record with Gravis's playfile.exe and use a different audio interface. In any case I'm not sure what I could do with the results anyway: I'm not an analog audio wizard and any sort of advanced digital audio processing is far out of the capabilities of the RP2040.

[/quote]My limited take: While we can be certain that a great deal of comparison was done across the years of Ultrasound emulation development (from DOSBox to PicoGUS, etc), I'm not aware of any structured scientific comparison that exists, to compare the different options - e.g. the mdfourier gold standard - and even A-vs-B listener tests aren't easily-findable. The main reason being that rigorous sound comparison testing is quite an undertaking in itself. Accordingly, it's an area where structured comparison data is sparse, across all PC sound cards of all eras. If you are in possession of both the GF1 and PicoGUS cards, then you're in the rare position of being able to do such comparisons personally.
[/quote]

I'd bet that if you did a blinded test comparing old sound cards to the emulated versions, most people wouldn't be able to tell the difference. Same thing goes for many emulated consoles or computers, at least those that are more popular. I think that CRTs are the one exception and that is unlikely to change because new CRTs aren't being made. I wish that more of the comparisons on YouTube were blinded because knowing what you are listening too will bias your judgement of whether or not you can hear a difference.

That being said, it's still fun playing with old hardware. It's just more fun for some reason.

polpo wrote on 2024-02-02, 07:06:

I did some MDFourier comparisons and it is a pretty overwhelming amount of data. I didn't post them because I wasn't happy with how I recorded them (I used an MOTU M2 audio interface, which has separately controllable L/R input volumes, and it's impossible to get the balance perfect, and I used Cubic Player to play the wav file, which introduced some clicks/pops in the audio). I need to re-record with Gravis's playfile.exe and use a different audio interface. In any case I'm not sure what I could do with the results anyway: I'm not an analog audio wizard and any sort of advanced digital audio processing is far out of the capabilities of the RP2040.

You'll need many more recordings from different original hardware if you want to really make use of MDFourier. The first step is trying to get high-quality recordings which is difficult if you crowd source as people will record will different hardware and methods. You then take all of those records and form a baseline of how a GUS is supposed to sound. You then use that baseline to compare to the emulator, PicoGUS, etc.

If you want to go down that path, you could always reach out to Artemio for guidance. MDFourier started on the MegaDrive/Genesis and for a long time there were emulators that sounded close enough, but doing the comparison there were many areas that needed improvement. It's an extremely large amount of work, but it generates a preserved copy of what xyz hardware is supposed to sound like. But then you get into things like we just created a perfect digital recreation of this card, but no real hardware sounded like that because of low-quality amps that introduced statics and pops.

polpo wrote on 2024-02-02, 07:06:

Shreddoc wrote on 2024-02-02, 06:35:

My limited take: While we can be certain that a great deal of comparison was done across the years of Ultrasound emulation development (from DOSBox to PicoGUS, etc), I'm not aware of any structured scientific comparison that exists, to compare the different options - e.g. the mdfourier gold standard - and even A-vs-B listener tests aren't easily-findable. The main reason being that rigorous sound comparison testing is quite an undertaking in itself. Accordingly, it's an area where structured comparison data is sparse, across all PC sound cards of all eras. If you are in possession of both the GF1 and PicoGUS cards, then you're in the rare position of being able to do such comparisons personally.

I did some MDFourier comparisons and it is a pretty overwhelming amount of data. I didn't post them because I wasn't happy with how I recorded them (I used an MOTU M2 audio interface, which has separately controllable L/R input volumes, and it's impossible to get the balance perfect, and I used Cubic Player to play the wav file, which introduced some clicks/pops in the audio). I need to re-record with Gravis's playfile.exe and use a different audio interface. In any case I'm not sure what I could do with the results anyway: I'm not an analog audio wizard and any sort of advanced digital audio processing is far out of the capabilities of the RP2040.

You're doing so much already, this kind of laborious granular testing is not something I'd expect of you personally. I see it as more of a community thing that will be attended to in time, whether that's a month, or 5 years.

And it's such a theoretical thing, for the most part. Regardless of the results, it wouldn't make a whit of difference to me loving and using the PicoGUS. As Ensign Nemo just noted, I doubt a blinded A-vs-B test would leave me any the wiser.

It's all merely (part of) the eventual answer to that inevitable scientific question - as asked by blakespot, above - "exactly how much like an original GUS/CMS/etc is the PicoGUS?". One day we'll have more data, but there's no hurry. Until then the answer, for me and I daresay virtually all of us, is "More Than Enough!". 😀

Hey Guys,
I've just finished a build of a v1.1 board yesterday. Unfortunately pgusinit reports 'card not responding to GUS command'. Gravis software report card not found. Pgusinit /f works with every file. Card initialises ok with Adlib fw, Monkey Island works fine with 'monkey a', but no sound. Same with CMS and Tandy.
I've learned from a YT video that, if I remember correctly, U2-U4 do address decoding. I was just wondering what the other ICs do and which can be connected to my issue. Basically where to start with troubleshooting? I have checked all solder joints on the SMD ICs, no neighbouring pins are in short. I have found two pins that are in short but those are a lot further apart, not sure if that's normal. Any info is appreciated 😀. Thank you!

_ar wrote on 2024-02-05, 07:36:

Hey Guys,
I've just finished a build of a v1.1 board yesterday. Unfortunately pgusinit reports 'card not responding to GUS command'. Gravis software report card not found. Pgusinit /f works with every file. Card initialises ok with Adlib fw, Monkey Island works fine with 'monkey a', but no sound. Same with CMS and Tandy.
I've learned from a YT video that, if I remember correctly, U2-U4 do address decoding. I was just wondering what the other ICs do and which can be connected to my issue. Basically where to start with troubleshooting? I have checked all solder joints on the SMD ICs, no neighbouring pins are in short. I have found two pins that are in short but those are a lot further apart, not sure if that's normal. Any info is appreciated 😀. Thank you!

Can you share some high res pictures of the front and back of the card?

mbarszcz wrote on 2024-02-05, 16:46:

_ar wrote on 2024-02-05, 07:36:

Hey Guys,
I've just finished a build of a v1.1 board yesterday. Unfortunately pgusinit reports 'card not responding to GUS command'. Gravis software report card not found. Pgusinit /f works with every file. Card initialises ok with Adlib fw, Monkey Island works fine with 'monkey a', but no sound. Same with CMS and Tandy.
I've learned from a YT video that, if I remember correctly, U2-U4 do address decoding. I was just wondering what the other ICs do and which can be connected to my issue. Basically where to start with troubleshooting? I have checked all solder joints on the SMD ICs, no neighbouring pins are in short. I have found two pins that are in short but those are a lot further apart, not sure if that's normal. Any info is appreciated 😀. Thank you!

Can you share some high res pictures of the front and back of the card?

Any particular area of interest or specific angle?

I have done some testing, these are the ICs that have shorts between their legs:

U2: 11-13, 10-11, 4-11, 4-10, 1-19

U6: 4-10, 2-11, 3-12

U8: 3-4, 3-7, 4-7

Are these normal?