snipe3687 wrote on 2025-01-15, 13:47:

Hello everyone, I'm hoping someone can help me here. I've been working on a project that combine's Rasteri's WeeCee with Eivind […]
Show full quote

Hello everyone,
I'm hoping someone can help me here. I've been working on a project that combine's Rasteri's WeeCee with Eivind Bohler's TinyLlama 3 which has been very successful except for 1 part. I cannot get pgusinit to see the picogus on the bus for some reason. If anyone is familiar with the SOM304RD-VI it essentially offers the entire ISA bus on it's pin header so I am treating the PicoGus like it's plugged into an ISA slot. this differs a little bit from the TinyLlama v3 since that one uses the PCIRST signal which is active low and inverts it where as I used RSTDRV off the ISA bus which is active high which is essentially what the original PicoGus does. other than that, I didn't change any of the logic. I used a very similar schematic to make a PC/104 version of the PicoGus and that works so I guess what I really need is a second set of eyes on it.
I was able to succesfully drop the firmware on it and everything and the activity light comes on after I do that so that tells me the RP2040 is responding at least. it just seems like the ISA bus isn't making connection to the SOM.
and before anyone asks, I've been able to use other PicoGus devices with this SOM so I know it's compatible.

Thank you for taking the time to check this out! if I can get this working, I think the project will be complete! 😀

I did find one issue while reviewing this again and that was the AEN Masking circuit was using 3.3V instead of 5V.
I tombstoned the resistor on the pad connected to DACK1 removing the other end from the 3.3V supply and attached 5V from one of the VREGs but unfortunately, this didn't solve the issue.
This is actually the second board I've spun as the first one was using the incorrect signal for RSTDRV. I don't see anything else on any of the schematics I've looked at that I could be missing. I suppose maybe the traces could be too small, but I would be surprised since it's such a short distance. they are 0.127mm. could that possibly be an issue though? I normally like to stay around 0.18mm or 0.2mm for ISA traces but I have had success using 0.127mm for other projects.

ughh, I really don't know what else to check so any advice would be very much appreciated!

Shreddoc wrote on 2023-04-21, 07:13:

And in today's Titles-You'll-Never-See category!............. "Top 10 SBOS Moments". 🤣

@pc-sound-legacy, I dare you! 😀

Better late than never! I put this together last year because I like some of these sbos tunes!

https://youtu.be/JboCNzrYQvs?si=6L3VcMoW1AO2PmSR

vsharun wrote on 2024-12-27, 20:11:

Hayko wrote on 2024-12-26, 12:03:

I have been testing dune2 but i dont get the "speaking sounds" to work. What im doing wrong? 😀
picogus + S2 midi.

I would like to add something more: not only XMS should be available to dune 2 and enabled via setup program, XMS available also should be limited to 16M, once you provide more - dune2 executable may/will crash.
My main setup for Dune 2 is PicoGUS in SB 2.0 mode + WP32 McCake in MT-32 mode.

Some testing..

I've been trying to set my PicoGUS 2.0 up as part of a DOS/Win3.11 focused build using one of my Socket 7 boards, but seem to be hitting a lot of incompatibilities ...

First board was a Packard Bell IN5598 SiS based microATX board with onboard ESS AudioDrive 1869F, with EDO RAM and a Cyrix MII. PgusInit recognises and initialises the board, but it's been impossible to get any GUS game or demo working - the Ultrasound MidiDemo, for example, just gives error messages about "No response from DMA channel". I noticed the PicoGUS compatibility list mentions random crashes with the SiS 530/5595 - might the 5598 be even worse?

The other board I tried is an IBM OEM/Acer V72MA with an Ali Aladdin V chipset and onboard ESS Solo-1 PCI sound card onboard. The PicoGUS works nicely alone on this board, but the ESS Solo always seems to default to channel 240, which the PicoGUS seems to need. I've been able to force the ESS-Solo to channel 220 by setting a SET BLASTER before initialising essolo.com, but then it seems to delete that value from autoexec or dosstart.bat after it runs!

I also tried changing the ULTRASND value for channel to 220 (to leave 240 for the ESS Solo) , but then PgusInit doesn't recognise the values as valid ...

Is there a way to successfully force the PicoGUS to a channel other than 240? (or to keep the ESS Solo using a channel other than 240?)

The only other board I have that I could try is a Siemens OEM 440ZX based Slot 1 board. But that doesn't have any onboard sound, and only one ISA slot. So I'd have to pair the PicoGUS with a PCI sound card - I do have a Yamaha YMF724. Is that going to be the best option? Or would the Yamaha PCI sound card also likely lead to clashes?

It seems like you can change from 240 to 220 simply by changing your ultrasnd variable, whereas irq and dma require jumpers on the card to be changed in conjunction with changing or aligning with the variable.
https://github.com/polpo/picogus/wiki/Configu … ng-your-PicoGUS

justin1985 wrote on 2025-01-26, 21:42:

So I'd have to pair the PicoGUS with a PCI sound card

You don't have to pair the PicoGUS with any other card.

Shreddoc wrote on 2025-01-27, 06:20:

justin1985 wrote on 2025-01-26, 21:42:

So I'd have to pair the PicoGUS with a PCI sound card

You don't have to pair the PicoGUS with any other card.

But I thought the PicoGUS doesn't really serve as a Windows soundcard, and the SB emulation isn't as full as something like an ESS card?

I'd like the flexibility to run some things in Windows, and have full SB compatibility as well - even if I am focusing on DOS with this build.

I had the impression that most people do pair their PicoGUS with another sound card?

dukeofurl wrote on 2025-01-26, 23:43:

It seems like you can change from 240 to 220 simply by changing your ultrasnd variable, whereas irq and dma require jumpers on the card to be changed in conjunction with changing or aligning with the variable.
https://github.com/polpo/picogus/wiki/Configu … ng-your-PicoGUS

I'd seen that too, but if I change the value in the ULTRASND variable to 220 rather than 240, PiGusInit gives an error about a "missing or deformed variable"!

Could you maybe give us a little more information about your AUTOEXEC.BAT perhaps? And how the jumpers on your card are setup? It seems odd that the ULTRASND variable is rejected if you only changed the port address.

justin1985 wrote on 2025-01-27, 08:15:

But I thought the PicoGUS doesn't really serve as a Windows soundcard, and the SB emulation isn't as full as something like an ESS card?
I'd like the flexibility to run some things in Windows, and have full SB compatibility as well - even if I am focusing on DOS with this build.
I had the impression that most people do pair their PicoGUS with another sound card?

PicoGUS has decent SB 2.0 compatibility and can be switched on the fly from one mode to another.
I ended up using this card primarily as a SB2.0 + MPU-401 intelligent mode with wavetable WP32 in MT32/GM mode depending on a title.
The only practical way of GUS mode I ended up with - demoscene and trackers, coz in gaming GUS sound/music will take significant toll from (already low) FPS in FPS (frames per second in first person shooter) and has issues from chipset to chipset which original GUS also has or prone to.

digistorm wrote on 2025-01-27, 09:16:

Could you maybe give us a little more information about your AUTOEXEC.BAT perhaps? And how the jumpers on your card are setup? It seems odd that the ULTRASND variable is rejected if you only changed the port address.

Jumpers are set to IRQ7 and DMA3, on the basis that the ESS Solo defaults to IRQ5 and DMA1 . Autoexec is pretty minimal at the moment, with just the Win98 defaults followed by Ultrasound variables, PgusInit, and Set Blaster and Essolo.com (in that order). The ULTRASND variable is accepted by PgusInit when it is set to 240, but literally changing the single digit to 220 makes it reject it. Is 240 maybe the only valid value?

I read around some old threads here about the ESS Solo and managed to find that changing the DOS emulation resource values in Windows device manager actually writes them to a hex essolo.ini file, so changing it to address 220 there seems to have made it stick. I also had to find and use Essvol.exe to re-enable the line-in volume (which I was using to pass through the PicoGUS) . So it does now seem to be working on the ALi Aladdin based IBM Aptiva!

vsharun wrote on 2025-01-27, 10:27:

PicoGUS has decent SB 2.0 compatibility and can be switched on the fly from one mode to another.
I ended up using this card primarily as a SB2.0 + MPU-401 intelligent mode with wavetable WP32 in MT32/GM mode depending on a title.
The only practical way of GUS mode I ended up with - demoscene and trackers, coz in gaming GUS sound/music will take significant toll from (already low) FPS in FPS (frames per second in first person shooter) and has issues from chipset to chipset which original GUS also has or prone to.

I see what you mean about this being a realistic option, although I have noticed some games having very stuttery digital sound from the PicoGUS in SB mode, when they work perfectly with the ESS chip (e.g. Discworld). The best experience with Discworld seems to be Midi via GUS but digital audio set to SB Pro via the ESS. So ideally I'd like to keep that flexibility!

I would have preferred to be able to use it on the SiS 5598 based system though - am I just going to have to give up on that? There didn't seem to be any conflicts in terms of resources I could see via Windows device manager, but it seemed significant that the MidiDemo from the Ultrasound folder (which does work on the ALi system) reported that DMA error on the SiS one .... Other games and things attempting to use the PicoGUS on the SiS system just crash, even Doom.

I thought gus, including emulated gus on picogus, offloads the CPU a bit because Gus's are designed to do mixing on the card in hardware rather than via the computers CPU. So I would have thought the fps would be a little better on gaming compared to using a sound blaster.

dukeofurl wrote on 2025-01-27, 13:23:

I thought gus, including emulated gus on picogus, offloads the CPU a bit because Gus's are designed to do mixing on the card in hardware rather than via the computers CPU. So I would have thought the fps would be a little better on gaming compared to using a sound blaster.

There were very few games that actually made the effort to do that, rather than just use the existing (software mixing) code they already had to support other sound cards.

dukeofurl wrote on 2025-01-27, 13:23:

I thought gus, including emulated gus on picogus, offloads the CPU a bit because Gus's are designed to do mixing on the card in hardware rather than via the computers CPU. So I would have thought the fps would be a little better on gaming compared to using a sound blaster.

In very theory. IRL situation differs from driver to driver.

justin1985 wrote on 2025-01-27, 08:15:

But I thought the PicoGUS doesn't really serve as a Windows soundcard, and the SB emulation isn't as full as something like an E […]
Show full quote

Shreddoc wrote on 2025-01-27, 06:20:

justin1985 wrote on 2025-01-26, 21:42:

So I'd have to pair the PicoGUS with a PCI sound card

You don't have to pair the PicoGUS with any other card.

But I thought the PicoGUS doesn't really serve as a Windows soundcard, and the SB emulation isn't as full as something like an ESS card?

I'd like the flexibility to run some things in Windows, and have full SB compatibility as well - even if I am focusing on DOS with this build.

I had the impression that most people do pair their PicoGUS with another sound card?

Oh sure, some people do. There's nothing wrong with it. It's just that, as you're discovering, multi-soundcard multi-OS setups come with many extra complications. Especially from the 1990s, when the computing environment was changing so fast and had many competing standards.

ESS SOLO-1 drivers tend to alter autoexec.bat every boot to Windows. So, make autoexec.bat read-only, problem solved. 😀

dj_pirtu wrote on 2025-02-01, 06:16:

ESS SOLO-1 drivers tend to alter autoexec.bat every boot to Windows. So, make autoexec.bat read-only, problem solved. 😀

Great idea, thanks!

In the end though I ended up putting the IBM system with the onboard ESS Solo aside, and started using the PicoGUS in a Slot1 board (440ZX) alongside a Yamaha YMF724 PCI. That worked smoothly first try, and also the Yamaha has much cleaner output 😀

also if your bios lets you reserve the irq/dma for isa use usually these mb's have a section dedicated to reserve them from the pnp os

Got my picogus today from Joe's Computer Museum, set my ultradir and ultrasnd variables, and when using pgusinit 2.2 on my old computer (a pocket 386) I get an error "card using protocol 255, needs 3. Please run latest firmware and pgusinit.exe". Running earlier versions of pgusinit simply say the card can't be found.

I went to update the card firmware by connecting the picogus to my modern computer with a usb-b cable and holding the BOOTSEL button down, like the instructions say. I tried to move the .uf2 files from the v 2.2 archive onto the "RPI-RP2" drive several times, however every time I tried to do this, the file manager would exit as soon as the status bar indicated the files were copied over... and when I subsequently checked the RPI-RP2 drive again, none of the .uf2 files showed up there.

Just in case things are supposed to be like that when updating the firmware, I tried the picogus connected to the old computer again and launched pgusinit 2.2 and it still gave the same error. Any ideas what this error means or what I might be doing wrong?

dukeofurl wrote on 2025-02-14, 04:36:

I went to update the card firmware by connecting the picogus to my modern computer with a usb-b cable and holding the BOOTSEL button down, like the instructions say. I tried to move the .uf2 files from the v 2.2 archive onto the "RPI-RP2" drive several times, however every time I tried to do this, the file manager would exit as soon as the status bar indicated the files were copied over... and when I subsequently checked the RPI-RP2 drive again, none of the .uf2 files showed up there.

This is normal for uploading Pico firmware. As soon as the firmware file finish copying (uploading) the device will reset hence the file manager closes. At this point the Pico should be running the firmware you have uploaded.

Ah that's good to know that I probably updated the firmware appropriately then. Confused why I'm still getting the error though with the pgusinit that was distributed with that firmware. Just tried some different IRQ and DMA jumpers on the card and matching them in the ultrasnd variable but that didn't help.