Hi guys, a question, i think is related to a old post of mine

theelf wrote on 2026-04-14, 08:49:

I tested in a pentium 200 and videos are slow too using picogus […]
Show full quote

NeoG_ wrote on 2026-04-14, 08:04:

theelf wrote on 2026-04-14, 07:30:

Hi thanks fo reply!!, im in DOS, using for playback, quickview pro […]
Show full quote

Hi thanks fo reply!!, im in DOS, using for playback, quickview pro

- Picogus is in USB mode
- Video is a Cinepack 12fps, 320x200 video, tried ADPCM 22khz mono audio or PCM 8bit 11khz, interleave every frame. Video is 40min long, 560mb, then 230-250kb sec
- Tried too msvideo 1 256colors, 12fps, same audio options and interleave, 640mb more or less 270kb sec
- Tried iso and cue/bin

Bot videos i burn in CD and test in a 4x IDE drive and play fine, from HDD too

Using Picogus CD give me stops every 2 or 3 seconds because frameskip

Hi! i get consistent 600kb sec transfer rates in speedsys, and i can confirm by copy a file in DOS is correct

The attachment IMG_20260414_092524.jpg is no longer available

In fact my IDE 4x drive is slower, because i think i use CDRW unit and the unit is old, read at 360-420kb sec, but anyways video play smooth from real CD

I dont have a IO recovery period option in bios

thanks!

I wonder if the MKE cdrom has naturally higher CPU overhead and its running out of CPU power to copy from ISA bus and decode at the same time

I tested in a pentium 200 and videos are slow too using picogus

Funny thing is that msvideo1 avi play smoth from HDD in a 286 25mhz

Maybe is ISA bus that saturate?

The only videos i can play smoth using picogus CD is msvideo1 optimized for CDrom playback at 150k

Im testing more cd emulation, and at least in my motherboard?¿ can someone help me to test, i think is very cpu consuming

Im testing game The DIG, this game need a DX/2 66, i have a DLC33, of course MUCH slower than minimum, but anyways, if i play from HDD or IDE CD, the game is a little slow, but playable. Using Picogus CD emulation, in USB or SB mode, is same, the game became unplayable, too slow

Any ideas? or is just picogus cd emulation that consume too high CPU?

thanks!!!!

Are you playing the game in DOS or Win9x? If it's in win9x, use the latest firmware version and swap to the microsoft MKE drivers instead of Creative. The Creative MKE driver blocks the CPU like crazy.

Also because the MKE interface doesn’t use IRQs or DMA it does burn a lot of CPU time polling and transferring data.

polpo wrote on 2026-05-16, 23:26:

Also because the MKE interface doesn’t use IRQs or DMA it does burn a lot of CPU time polling and transferring data.

The game calls for a 486DX2/66 and 2x speed CD-ROM under DOS, you would think that means it's fairly safe for an MKE drive

NeoG_ wrote on 2026-05-16, 23:01:

Are you playing the game in DOS or Win9x? If it's in win9x, use the latest firmware version and swap to the microsoft MKE drivers instead of Creative. The Creative MKE driver blocks the CPU like crazy.

Hi im using DOS thanks

polpo wrote on 2026-05-16, 23:26:

Also because the MKE interface doesn’t use IRQs or DMA it does burn a lot of CPU time polling and transferring data.

thanks, i had similar problem with my 1x mitsumi cdrom until change driver to one using dma

But you say the problem is interface no driver then? no solution with diferent driver or parametes?

thanks a lot

Hi everyone! Quick question as I plan to play some x-wing this weekend! I have my PicoGUS in USB mode and use a hub with my USB drive attached with my CD images. This all works fine. Then I also attached my Logitech Extreme 3D Pro joystick. I see on the PicoGUS wiki that "joysticks" are supported and maybe this is where i'm getting confused. I enabled joystick support (pgusinit /joy 1) but I see on the wiki that only xinput or sony gamepads are supported? So not strictly 'joysticks' but more gamepads? unless there are joysticks that also support xinput? I'm no expert hence why i'm asking here. I read that my joystick uses HID.

So any clarity on the matter would be much appreciated. All I wanna do is fly my x-wing!!!!! 🤣

stu_e_hughes wrote on 2026-06-04, 20:42:

Hi everyone! Quick question as I plan to play some x-wing this weekend! I have my PicoGUS in USB mode and use a hub with my USB drive attached with my CD images. This all works fine. Then I also attached my Logitech Extreme 3D Pro joystick. I see on the PicoGUS wiki that "joysticks" are supported and maybe this is where i'm getting confused. I enabled joystick support (pgusinit /joy 1) but I see on the wiki that only xinput or sony gamepads are supported? So not strictly 'joysticks' but more gamepads? unless there are joysticks that also support xinput? I'm no expert hence why i'm asking here. I read that my joystick uses HID.

So any clarity on the matter would be much appreciated. All I wanna do is fly my x-wing!!!!! 🤣

As far as I know, the PicoGUS's joystick support just doesn't work with DirectInput devices like your Extreme 3D Pro. One solution would be finding a PS4-compatible Thrustmaster T-Flight HOTAS or similar, and hope that the three buttons and axes that you need end up mapped in a way that you can fly with. If you can find an analog joystick like a Gravis Analog Pro for a good price (I see two on eBay right now for under $30 CAD), you could also use a cheap sound card like a SB PCI 128 with its DOS Sound Blaster emulation turned on, and make sure that you set X-Wing to use the PicoGUS for audio.

If it's X-Wing Collector's CD-ROM (1994), I'd recommend:

-Set the PicoGUS to GUS mode, on something like Port 240, IRQ 5, DMA 1/1, and disable the joystick
-Set the PCI 128 to Port 220, IRQ 7, DMA 3
-Set X-Wing to Gravis Ultrasound for audio, and enjoy!

If it's the original floppy release of X-Wing, this could get a bit more complicated since I don't remember if it had native GUS support or not. In that case, choosing the Port/IRQ/DMA values in its installer is a bit more tricky, I can't remember if it allowed for direct selection of the Sound Blaster settings although it did have SB Pro support but not SB16.

So, short answer; you'll need some more hardware, and some resource juggling, but it's possible!

The next release of PicoGUS should have a pretty big overhaul of joystick support, so Directinput joysticks should gain support. I'm currently pretty deep in PicoIDE and dayjob stuff so I don't have a definite timeline, but sooner rather than later!

polpo wrote on 2026-06-04, 22:06:

The next release of PicoGUS should have a pretty big overhaul of joystick support, so Directinput joysticks should gain support. I'm currently pretty deep in PicoIDE and dayjob stuff so I don't have a definite timeline, but sooner rather than later!

If you want someone to test out the DirectInput functionality, let me know! I have a trio of USB sticks (Microsoft Sidewinder Precision 2, Logitech Wingman Force 3D, Thrustmaster T.16000) and a desire to play various space combat/vehicle games in DOS.

Sharing this here as well: https://github.com/tgies/opl3-pico2-demo/

This is a demo for a version of Nuked-OPL3 that has exactly the same output as upstream Nuked-OPL3, but is heavily optimized for RP2350. It also has a dual-core rendering mode. With these, Nuked-OPL3 sustains realtime rendering on worst-case input at 294MHz for the single core version, or 180 MHz for the dual core version.

agovtman wrote on 2026-06-11, 01:11:

Sharing this here as well: https://github.com/tgies/opl3-pico2-demo/

This is a demo for a version of Nuked-OPL3 that has exactly the same output as upstream Nuked-OPL3, but is heavily optimized for RP2350. It also has a dual-core rendering mode. With these, Nuked-OPL3 sustains realtime rendering on worst-case input at 294MHz for the single core version, or 180 MHz for the dual core version.

I assume this takes advantage of the 2350's hardware FPU, doing it on the 2040 with integer only compute would be a significant challenge I think. Getting it from an unoptimised project that ran on desktop computers to an RP2350 is already great work.

NeoG_ wrote on 2026-06-11, 01:45:

I assume this takes advantage of the 2350's hardware FPU, doing it on the 2040 with integer only compute would be a significant challenge I think.

original yamaha OPL doesnt use any floating math and is a very simple algorithm consisting mainly of lookup tables and adding logs instead of multiplication

Hello to everyone, I've read the entire thread and I really want to congratulate this community, and especially polpo himself. I don't know for the development of this exceptional emulator for ISA 8-bit slots, but also for his perseverance and expertise in continually developing new features and improvements, putting himself to the test in this wonderful community of retro system enthusiasts! My most sincere compliments and appreciation, polpo!
I've recently started posting on this forum, even though I've been reading for a long time... and, if I may, I'd like to share some ideas for the possible hardware development of a new PicoGUS version:
1) It would be very nice and functional to have an analog audio input on a jack (with a related hardware/software mixer) to be able to use the PicoGUS exactly as if it were a GUS ACE, interfacing it as an input/output from other sound cards.
2) I don't know if it's possible or not, but I think it would be nice to consider making the next version of PicoGUS Plug&Play so as not to be tied to opening the case and physically removing the PicoGUS every time you need to change its IRQ and DMA.
3) In my opinion, it would also be interesting to develop either a version with and a version without wavetable... not everyone needs an onboard wavetable connector.
4) I also think it would be greatly appreciated by everyone to have a hardware development of PicoGUS that allows for an industrialized basic construction, but also a little customization, in the sense of having an industrialized basic PicoGUS that is able to accept standard Raspberry Pi Pico modules, so that, when they evolve, we could keep our basic PicoGUS and buy and change independently by removing and reinserting the updated standard Raspberry Pi Pico modules by hand (without a soldering iron).

I hope polpo to kindly consider these proposals of mine for the future...and I thank you sincerely!

Damiano.78 wrote on Today, 10:30:

Hello to everyone, I've read the entire thread and I really want to congratulate this community, and especially polpo himself. I […]
Show full quote

Hello to everyone, I've read the entire thread and I really want to congratulate this community, and especially polpo himself. I don't know for the development of this exceptional emulator for ISA 8-bit slots, but also for his perseverance and expertise in continually developing new features and improvements, putting himself to the test in this wonderful community of retro system enthusiasts! My most sincere compliments and appreciation, polpo!
I've recently started posting on this forum, even though I've been reading for a long time... and, if I may, I'd like to share some ideas for the possible hardware development of a new PicoGUS version:
1) It would be very nice and functional to have an analog audio input on a jack (with a related hardware/software mixer) to be able to use the PicoGUS exactly as if it were a GUS ACE, interfacing it as an input/output from other sound cards.
2) I don't know if it's possible or not, but I think it would be nice to consider making the next version of PicoGUS Plug&Play so as not to be tied to opening the case and physically removing the PicoGUS every time you need to change its IRQ and DMA.
3) In my opinion, it would also be interesting to develop either a version with and a version without wavetable... not everyone needs an onboard wavetable connector.
4) I also think it would be greatly appreciated by everyone to have a hardware development of PicoGUS that allows for an industrialized basic construction, but also a little customization, in the sense of having an industrialized basic PicoGUS that is able to accept standard Raspberry Pi Pico modules, so that, when they evolve, we could keep our basic PicoGUS and buy and change independently by removing and reinserting the updated standard Raspberry Pi Pico modules by hand (without a soldering iron).

I hope polpo to kindly consider these proposals of mine for the future...and I thank you sincerely!

Actually, the 1.2 revision of PicoGUS PCB will meet your demands 3) and 4). It accepts standard Raspberry Pi Pico (RP2040) but it does not have a wavetable connector due to limited amount of GPIO pins.

It seems Pico 2 (RP2350A) maintained a matching pinout compared to Pico (RP2040) but there will be differences on the software side. Sadly, as with PicoGUS 1.x there are no free GPIO pins for more extensions. PicoGUS 2.0 put the RP2040 directly on the PCB to be able to access GPIOs not exposed on the Pico module, and if you want more GPIO pins you'll need a design around RP2350B which is a larger variant of RP2350A used on Pico 2.