I wouldn't get picogus for its gravis part, because its big hassle 😀.
I think gus emulation puts raspery too near to the edge. Games like panzer general, x-com or transport tycoon doesn't work.
I think picogus killer feature is its intelligent mode 401, and all other modes.
I just love the card I've build 5, 1.2 cards for my xt/286 machines.

LSS10999 wrote on 2025-06-04, 02:34:

A question, as I'm struggling to figure out what might be wrong with my 2nd PicoGUS v1.2 assembly. […]
Show full quote

A question, as I'm struggling to figure out what might be wrong with my 2nd PicoGUS v1.2 assembly.

For some reasons, that card works without any issue in SB mode, but when in GUS mode, it could not detect any valid RAM.
- GUSDRAM reports all banks BAD. ULTRAMID would refuse to load citing no memory available, and if I try launching ULTRAMID a second time, the system would freeze or, if JEMM loaded, keep generating exception messages.

I inspected the soldering with a magnifier but could not find anything problematic. I suspected the PSRAM chip may be faulty so I replaced it with another one, but no difference.

I wonder what might be causing the issue, as from the schematic it's just some GPIOs used by Pico for SPI connecting to the PSRAM... I'm using v2.2.0 firmware, and I don't have a spare Pico at the moment...

UPDATE: Got myself another Pico and no avail. Same issue. The card still can only work in SB mode. GUS is no-go. When running pgusinit without any argument it simply says the card is not responding to GUS commands on port 240. I wonder if something's wrong with that particular PCB, as my first build worked correctly in GUS mode.

An update on my other PicoGUS assembly. My second assembly was actually fine (no possible soldering issue), after testing this on a board with proper ISA (AIMB-865 in my case). GUS mode works fine and the RAM is properly detected.

The actual problem was that the card cannot be properly initialized in GUS mode on my board that I'm testing dISAppointment (LPC-ISA adapter) with, ASUS P8B75-M.

I've updated the quoted post and will be leaving a message on dISAppointment thread about this discovery...

NeoG_ wrote on 2025-06-28, 08:40:

Now for level 2 of "the offset experience"

Terminal Velocity (V1.2 retail CD) in GUS mode randomly switches between aligned and offset. In this case I couldn't replicate it in DOSBox and it remained aligned the whole time. I confirmed the offset with an audio capture.

So, the reason this was bugging me a bit is because in Terminal Velocity the SB Pro driver is limited to 11Khz Stereo even though the card and compatibles can do 22Khz stereo which would approximately match the GUS driver quality.

It actually seems like there is a bug in the game's menu code which incorrectly limits the mixing rate for SB Pro cards or compatibles and if you edit VOX.INI in the game directory directly you can force 22Khz Stereo on the SB Pro driver by manually changing the mixSpeed and stereoFlag values to 22050 and 1 respectively. It sticks as long as you don't try to change the frequency or stereo mode option in the sound menu.

On a side note, the PicoGUS also saved my bacon when updating the BIOS on my 3DFX card. Initially it was the wrong size BIOS for my card, the flash failed with an erased BIOS so the system was not going to boot again after being power cycled. I couldn't remove the SD2IDE card while the system was on and I was out of floppy disks and writable CDs leaving me stranded with no way to get the correct BIOS file onto the system without rebooting.

Then I had an idea, the PicoGUS supports hot plugging USB drives and the CDMKE driver was already loaded into memory. I used another computer to compile the necessary files into an ISO disc image and put it on a USB drive. I stuck it into the back of the PicoGUS and mounted the disc image, allowing me to successfully complete the flashing process. Thanks PicoGUS!

When working with the CD drive emulation in batch files or scripts that change mode, the PicoGUS may not be ready to load an image by the time the next batch command runs after a mode change. It may vary by the amount of images on the USB and the speed of the USB drive. So if you are automating CD image loading and mode changes a pause is required to ensure it works. I have a MOUNT.BAT file that sets the PicoGUS to USB mode, waits for a set amount of seconds and then issues the cdloadname command. This may not be necessary if the mode change waits for USB enumeration before continuing in future firmware versions (maybe with something like a /odeready switch to not change the default behaviour).

Set "/T:1,2" to amount of seconds to wait as the second parameter. E.g. "/T:1,5" for 5 seconds or "/T:1,3" for 3 seconds.

1@ECHO OFF
2PGUSINIT /mode %1
3ECHO Waiting for USB ready...
4CHOICE /C:1 /T:1,2 > NUL
5PGUSINIT /cdloadname %2

Usage:

MOUNT [mode] [imagename]

Example: MOUNT sb "game.iso"
Example: MOUNT usb "software.iso"

Works in MS-DOS 6.0 or higher. For earlier versions CHOICE can be replaced with your selection of third party pause or sleep executables.

Might be worth asking the devs for a switch that doesn't return until the command has succeeded/failed and reports an errorlevel

Eg
picogus /cdmode /batch
If %errorlevel%==1 echo CD mode failed
If %errorlevel%==0 echo CD mode success
Etc

I want o build my own PicoGUS 1.2 and I have a few questions (hopefully someone with experience can answer):
1) What's the difference between 1.2 and 2.0? For once I can't find a wavetable header in 1.2 which is a biggie for me
2) Is 1.2 buggy in any way?
3) Why add an ISA bus connector with male headers in 1.2?
4) Do you recommend building the DAC or buying the DAC module?
I just need to determine whether going through the trouble of building 1.2 is worth it.
Thanks!

gerpux wrote on 2025-07-16, 01:08:

I just need to determine whether going through the trouble of building 1.2 is worth it.
Thanks!

If the wavetable header and built in USB host port (mouse, joystick and optical drive emulation) are useful to you I'd say just buy the 2.0 card. The ISA headers on the 1.2 card are a holdover from development used for debugging.

I've built lots of 1.2's and 2.0's. Broadly listing the points relevant to a user :

gerpux wrote on 2025-07-16, 01:08:

I want o build my own PicoGUS 1.2 and I have a few questions (hopefully someone with experience can answer):
1) What's the difference between 1.2 and 2.0? For once I can't find a wavetable header in 1.2 which is a biggie for me

2.0 has a wavetable header. 1.2 does not, and one can NOT be easily added.
2.0 has a USB A port. 1.2 does not, but one CAN be manually added (OTG cable plugged into Pico).
1.2 has the option of wireless networking, if a Pico W is used. 2.0 does not.

gerpux wrote on 2025-07-16, 01:08:

2) Is 1.2 buggy in any way?

No, the 1.2 does not have unique bugs. It performs just like the 2.0.

gerpux wrote on 2025-07-16, 01:08:

3) Why add an ISA bus connector with male headers in 1.2?

For a regular user, do not populate. It is only for testing and development purposes.

gerpux wrote on 2025-07-16, 01:08:

4) Do you recommend building the DAC or buying the DAC module?

There is no perfect choice.
Building the DAC is more reliable. Because you will avoid quality-control issues found in some DAC modules (usually just poor soldering).
Buying the DAC module is easier, and usually works perfectly fine.

Note that the DAC area of the 1.2 is the most technically challenging section to solder by hand, if you choose to build it yourself, because of the tightly spaced 0805 parts clustered around a TSSOP. Easy if experienced, and do-able by many. But if not experienced, then take note.

For general example, this is one of my v1.2 hand builds :

So I notice that there is a USB mode that does MPU-401 and CD-ROM emulation, I was wondering if its also doing MPU-401 with intelligent mode as well, or is that just in the MPU mode only?

JuddSandage wrote on 2025-07-16, 06:27:

So I notice that there is a USB mode that does MPU-401 and CD-ROM emulation, I was wondering if its also doing MPU-401 with intelligent mode as well, or is that just in the MPU mode only?

There are three levels of MPU-401 games;

- UART Mode
- Intelligent mode
- Intelligent mode with interrupts

All modes on the PicoGUS that support MPU-401 will work with the first 2, MPU mode is required for the third type. You can see the game that need MPU mode here marked with a (1)

https://github.com/bjt42/softmpu/wiki/Compati … gent-Mode-Games

As per this post from Ian there is nothing technically stopping MPU mode with ODE so it will likely show up in a future firmware update;

Re: PicoGUS: ISA sound card emulator with Raspberry Pi Pico (Gravis Ultrasound, AdLib, MPU-401, Tandy, CMS)

Ah OK, outside of A10 tank killer, I have not heard of any of those games, and probably won't play them, so I'm good for now.

Shreddoc wrote on 2025-07-16, 04:34:

2.0 has a wavetable header. 1.2 does not, and one can NOT be easily added.

Can you elaborate on why this is not easy?
Thanks Shreddoc for the detailed and to the point answer (very useful)!

gerpux wrote on 2025-07-16, 23:13:

Shreddoc wrote on 2025-07-16, 04:34:

2.0 has a wavetable header. 1.2 does not, and one can NOT be easily added.

Can you elaborate on why this is not easy?
Thanks Shreddoc for the detailed and to the point answer (very useful)!

You are quite welcome!

It would not be easy because none of the related physical circuitry for a wavetable header exists on the 1.2. This includes the header itself, and also the mixer circuitry which mixes the wavetable's output with the sound card's other audio streams and outputs it through the 3.5mm jack.

So, unlike with the USB, you cannot simply connect an external cable or solder on a header.

It's not impossible (afaik), but would probably be a very manual job of point-soldering to different places on the card, and physically cobbling together some kind of interface. Or alternatively, redesigning the card to include it from scratch. I can't say offhand whether the v1.2 card has other impediments to that, e.g. free GPIO, firmware behaviour differences, etc - it may!

So in summary, it would potentially be a lot of work.

Shreddoc wrote on 2025-07-16, 23:26:

It would not be easy because none of the related physical circuitry for a wavetable header exists on the 1.2. This includes the header itself, and also the mixer circuitry which mixes the wavetable's output with the sound card's other audio streams and outputs it through the 3.5mm jack.

Got it! Thanks again 😀

Shreddoc wrote on 2025-07-16, 23:26:

You are quite welcome! […]
Show full quote

gerpux wrote on 2025-07-16, 23:13:

Shreddoc wrote on 2025-07-16, 04:34:

2.0 has a wavetable header. 1.2 does not, and one can NOT be easily added.

Can you elaborate on why this is not easy?
Thanks Shreddoc for the detailed and to the point answer (very useful)!

You are quite welcome!

It would not be easy because none of the related physical circuitry for a wavetable header exists on the 1.2. This includes the header itself, and also the mixer circuitry which mixes the wavetable's output with the sound card's other audio streams and outputs it through the 3.5mm jack.

So, unlike with the USB, you cannot simply connect an external cable or solder on a header.

It's not impossible (afaik), but would probably be a very manual job of point-soldering to different places on the card, and physically cobbling together some kind of interface. Or alternatively, redesigning the card to include it from scratch. I can't say offhand whether the v1.2 card has other impediments to that, e.g. free GPIO, firmware behaviour differences, etc - it may!

So in summary, it would potentially be a lot of work.

I mean, it could potentially be an addition for a 1.3 card, but I'm not sure there is any effort to further develop the 1.x PCBs. I would personally appreciate it. I have enough components to build another 1.x but I'm holding off because the 1.2 is not really that big a change over 1.1 I currently have (I never suffered the reset bug on my desktop PCs personally).

appiah4 wrote on 2025-07-17, 11:10:

Shreddoc wrote on 2025-07-16, 23:26:

You are quite welcome! […]
Show full quote

gerpux wrote on 2025-07-16, 23:13:

Can you elaborate on why this is not easy?
Thanks Shreddoc for the detailed and to the point answer (very useful)!

You are quite welcome!

It would not be easy because none of the related physical circuitry for a wavetable header exists on the 1.2. This includes the header itself, and also the mixer circuitry which mixes the wavetable's output with the sound card's other audio streams and outputs it through the 3.5mm jack.

So, unlike with the USB, you cannot simply connect an external cable or solder on a header.

It's not impossible (afaik), but would probably be a very manual job of point-soldering to different places on the card, and physically cobbling together some kind of interface. Or alternatively, redesigning the card to include it from scratch. I can't say offhand whether the v1.2 card has other impediments to that, e.g. free GPIO, firmware behaviour differences, etc - it may!

So in summary, it would potentially be a lot of work.

I mean, it could potentially be an addition for a 1.3 card, but I'm not sure there is any effort to further develop the 1.x PCBs. I would personally appreciate it. I have enough components to build another 1.x but I'm holding off because the 1.2 is not really that big a change over 1.1 I currently have (I never suffered the reset bug on my desktop PCs personally).

If the 1.1 works well for you, then you're getting the same quality of experience as any PicoGUS owner.

Whether-or-not there are any further official 1.x cards in the future (I have no idea if Yes or No), the PicoGUS hardware is currently open source under CERN OHL V2 (Permissive), so it's really in the world's hands as to what additions or improvements are made to the v1.x line.

Don't get me wrong, I'm not complaining. I love my Picogus 1.1 😀

Does anyone know how much power this card draws? This is an interesting anectode, but if I add this card to my Cx5x86 PC in addition to my MK8330+PCMIDI+McCake something strange happens.. The McCake starts acting flaky. Sometimes it never fires up properly at boot, or starts to reset intermittently. It almost feels like there is not enough juice on the ISA Bus to power all four of them at the same time, so I had to remove the PicoGUS to make the system behave. I have a NOS 200W AT PSU in the system.

I'm having trouble with CD-ROM emulation (and also my YMF719 general soundcard) when going from Win95 to "Reboot into MS-DOS mode" in an SiS based IBM Aptiva 2134 Pentium 133.

With the PicoGUS in USB mode, if I have both the CDMKE and normal CD drivers in Config.sys, and both MSCDEX and UniSound in Autoexec.bat, everything plays nice - I can access both the physical IDE CD-ROM and the PicoGUS emulated one from the command prompt, and UniSound correctly finds the YMF card.

If I remove MSCDEX and UniSound from Autoexec (to DosStart.bat), then the Yamaha card works fine in Win95, and so does the emulated CD-ROM (using the provided Creative driver).

But if I reboot using "Restart in MS-DOS Mode" (or via a PIF file set to run in MS-DOS mode), MSCDEX will ONLY see the physical IDE CD-ROM, not the emulated CDMKE one. The MSCDEX command in DosStart.bat was literally copied and pasted from Autoexec.bat.

Also, if I reboot with Control-Alt-Delete, and return to the DOS prompt via F8 (and run DOSSTART), neither the CDMKE emulated drive, nor the YMF card via UniSound are detected. I have to do a cold boot to get the YMF card to be detected again, even in the BIOS Plug and Play list!

Is this an inevitable behaviour? (work around via a DOS boot menu to give pure DOS or pure Win95 modes?) Or a sign of a conflict that could be resolved?

I did also try running the PicoGUS in SB mode as the only sound card in the system, and it did work in Win95 with the built-in SoundBlaster drivers, but the low sample rates were really obvious and sounded bad - is that inevitable, or could better drivers from Creative for the SB2.0 improve that?

justin1985 wrote on Yesterday, 11:35:

I'm having trouble with CD-ROM emulation (and also my YMF719 general soundcard) when going from Win95 to "Reboot into MS-DOS mode" in an SiS based IBM Aptiva 2134 Pentium 133.

Post your CONFIG.SYS and AUTOEXEC.BAT that is saved to the restart in MS-DOS mode PIF file (I assume you are using Phil's easy MS-DOS mode shortcut?)

Also remove the /Q option from CDMKE.SYS to see if the card is not responding for some reason

I am using 3 sound cards (including the PicoGUS), 1 physical and 1 virtual CDROM and nothing stops working when I use a reboot to MS-DOS mode shortcut. The difference is I am not using the PicoGUS virtual drive in Windows98, I am using Alcohol 120% RE instead.

NeoG_ wrote on Yesterday, 12:18:

Post your CONFIG.SYS and AUTOEXEC.BAT

My (main) Config.sys was (most of this is just how the IBM restore image created them):

1BUFFERS=20
2FILES=40
3DEVICE=C:\WINDOWS\HIMEM.SYS /TESTMEM:OFF
4DEVICE=C:\WINDOWS\EMM386.EXE NOEMS I=E000-EFFF X=F000-FEFF
5DOS=HIGH,UMB
6DEVICEHIGH=C:\WINDOWS\COMMAND\IBMIDECD.SYS /D:IBMCD001
7DEVICE=C:\PICOGUS\CDMKE.SYS /P:250 /Q /D:MKECD2

And my DOSSTART.BAT was:

1C:\PICOGUS\PGUSINIT /MODE USB
2LH MSCDEX /D:IBMCD001 /L:G /D:MKECD2 /L:H
3MOUSE
4C:\YMF719\UNISOUND /VL80

I hadn't quite described things correctly above - on a fresh boot to command prompt via F8, the CDMKE driver from config.sys was reporting no drive (perhaps a timing issue with the PicoGUS not having initialised yet?), but Unisound was working for the YMF719. After a reboot, again direct to command prompt via F8, CDMKE was working, but the YMF wasn't detected in DOS, or again via Windows, until a fresh boot. So very much seemed like it was either/or - PicoGIS or YMF. [EDIT - this is my remaining issue - CDMKE not detecting the drive from a cold boot into DOS via F8]

NeoG_ wrote on Yesterday, 12:18:

Post your CONFIG.SYS and AUTOEXEC.BAT that is saved to the restart in MS-DOS mode PIF file (I assume you are using Phil's easy MS-DOS mode shortcut?)

So I just tried creating Phil's style PIF file instead of using the Windows built-in Restart in DOS mode shutdown option, and moved the CDMKE driver into the Config.sys part of the setup for that. I also moved Pgusinit and Unisound from Dosstart.bat into the PIF file options. This *does* now work - both emulated CDMKE and YMF available in DOS!

BUT, if I go back to Windows 95 by typing "exit" (i.e. reboot) or "win", I'm left with the YMF card totally undetected again - until a fresh cold boot! Problem with the YMF card itself perhaps? Or do I need to uninitialise the YMF card? Also wondering if the IBM power suspend etc commands might be messing something up? [EDIT - I tried running UNISOUND /D before returning to Windows, and it does actually work now! Is there any way to automate that though? Commands run when ending a DOS session started via PIF, rather than when starting?]