Shreddoc wrote on 2024-01-08, 20:13:

This might be (my latest) dumb question, but does there exist large-scale testing of Picos being overclocked? […]
Show full quote

This might be (my latest) dumb question, but does there exist large-scale testing of Picos being overclocked?

E.g. 100+ random Picos, all overclocked and analysed, for statistical results?

I was just idly wondering if perhaps 1 out of 100, or whatever, might not like the overclock. This seems less likely, given that I understand the PicoGUS's overclock of the RP2040 is mild, and anecdotally, people say the RP2040 is usually capable of rather large overclocks - but just thought I'd ask the broad question, on the basis that in my experience of PC overclocking, whenever we experience weird behaviour, we always look first to the overclock, in case it is exacerbating something.

A test firmware without the overclock might be another angle from which to check that speculation, in troublesome instances.

Initially I clocked the RP2040 at 280MHz, but as of PicoGUS firmware 0.7.0, the overclock is to 400MHz, which isn't mild at all. I went ahead with that clock speed because I had great results with it in my testing of multi-hour "soak tests" where I'd just let the Doom demo loop run or have Cubic Player play through my mods directory continuously. Now that I'm selling PicoGUS 2.0 boards, I've been able to test them in large quantities so I have statistically significant data. I test each of the boards when I get them in my door by playing MIDI in MPU-401 mode, firmware flashing from DOS, and playing an S3M file in CapaMOD. My last batch had 200 units, and here are the results:

• 184 worked perfectly using firmware v1.0.1 at 400MHz.
• 1 did not respond to ISA bus events. Inspecting the board revealed bent pins and poor solder connections on one of the chips. Reflowing the solder on the pins fixed the issue.
• 13 wouldn't start up and/or reset reliably with firmware v1.0.1 at 400MHz, but only in GUS mode. Introducing 250ms of "dead time" after overclocking solved the issue with those boards.
• 2 wouldn't start/reset at 400MHz with the above fix. Clocking those boards down to 366MHz fixed the issue.

In a nutshell, 99% of the boards would run at 400MHz, but 100% were good at 366MHz.

Shortly I'll be releasing a new firmware that includes the "dead time" fix and I'm also strongly considering clocking down to 366MHz, pending testing with joystick support.

About weird behavior caused by overclocking – in my experience either the RP2040 works fine at a certain clock or it will not start. There's no zone where things act funny: it either works perfectly or it doesn't. And even at 400MHz the RP2040 gets barely warm to the touch. I could be wrong with this "either or" theory so I'll be DMing the 366MHz firmware to HandOfFate and Pickle who have recently commented reporting funny behavior so they can see if it fixes their issue.

Looking forward to trying it out, polpo!

Because my 486's chipset reportedly has issues with flashing the firmware I pulled another machine out of storage in anticipation of the updated firmware. This is a Pentium II with a Intel 440BX chipset and the card has the same symptoms as on the 486, so that should make testing easier.

We had problems with my friend's PicoGUS v2, only game where sound worked was Pinball Illusions, others were silent or crash. Port 240, IRQ 7 and DMA 3. SB AWE32 was 220, 5, L1, H5.
Really strange, why one game works and no other... But we sorted it out, friend had disabled all serial ports and printer port from bios and my guess was that one of the PCI cards took that IRQ 7 when it freed. So, we enabled printer port at IRQ 7 and PicoGUS works!

Machine in this case was ICL Fujitsu x451, Pentium 133, in Finland it's called "MikroMikko". Damn I love old PnP implementations.

My own PicoGUS works perfect, not one single problem! But if I have to make up one problem: in Windows 95 I use MOD4WIN for playing tracker-music and that uses GUS hardware straight, so no drivers needed. It detects PicoGUS as GUS PnP, not GF1 like everything else in DOS mode and that causes every song playing scrambled. And it can't be manually set to GF1-mode. But that's not a PicoGUS -problem, just bad code in MOD4WIN.

Interesting, I'm 99% sure I don't have an IRQ conflict in either machine (I also marked IRQ 5 as "already taken" in the PNP BIOS settings and I know the VGA card in the 486 is on IRQ 11) but I will double check later.

Did you happen to have a view of the LED on the card when the games were silent? Was the LED flashing?

edit: no IRQ conflicts

Problem statement: My GoTo DOS machine (SS7 MB with ATX power header only) has only 2 ISA slots. I'd like run my PAS16 with PicoGUS in order to have full (GUS, PAS, OPL3, SB) coverage. PAS16 needs -5V from ISA bus.
Old v1 PicoGUS PCB have empty ISA pinout holes. So I added pin header to PicoGUS in order to get access to -12V, -5V, GND for mini linear voltage regulator board (UA7905C) in order to provide -5V for ISA bus.
PicoGUS doesn't seem to use -12V and -5V pins so it should be safe.

PicoGus is capable to deliver many functions. Now we can add "voltage blaster" readiness to already extensive list 😉

dj_pirtu wrote on 2024-01-11, 06:44:

We had problems with my friend's PicoGUS v2, only game where sound worked was Pinball Illusions, others were silent or crash. Po […]
Show full quote

We had problems with my friend's PicoGUS v2, only game where sound worked was Pinball Illusions, others were silent or crash. Port 240, IRQ 7 and DMA 3. SB AWE32 was 220, 5, L1, H5.
Really strange, why one game works and no other... But we sorted it out, friend had disabled all serial ports and printer port from bios and my guess was that one of the PCI cards took that IRQ 7 when it freed. So, we enabled printer port at IRQ 7 and PicoGUS works!

Machine in this case was ICL Fujitsu x451, Pentium 133, in Finland it's called "MikroMikko". Damn I love old PnP implementations.

My own PicoGUS works perfect, not one single problem! But if I have to make up one problem: in Windows 95 I use MOD4WIN for playing tracker-music and that uses GUS hardware straight, so no drivers needed. It detects PicoGUS as GUS PnP, not GF1 like everything else in DOS mode and that causes every song playing scrambled. And it can't be manually set to GF1-mode. But that's not a PicoGUS -problem, just bad code in MOD4WIN.

Something I've learned is that the PicoGUS is very sensitive to IRQ conflicts. Often you could have your Sound Blaster and LPT both on IRQ 7 and things would work fine as long as you're not printing while playing games 😉. But the PicoGUS, probably because it is a 3.3v device, simply can't drive the IRQ line high if another device in the system is also on that line. In the next firmware release I'm going to increase the drive strength on the IRQ and DRQ lines (since they're just passed through a FET switch) to see if it can improve things on boards where there are "soft" conflicts.

Interesting that MOD4WIN detects the PicoGUS as a GUS PnP... I bet the fix for that would be pretty simple. I'll put that on my list of things to test. I always liked how that program supported the GUS directly.

vutt wrote on 2024-01-13, 16:54:

Problem statement: My GoTo DOS machine (SS7 MB with ATX power header only) has only 2 ISA slots. I'd like run my PAS16 with Pico […]
Show full quote

Problem statement: My GoTo DOS machine (SS7 MB with ATX power header only) has only 2 ISA slots. I'd like run my PAS16 with PicoGUS in order to have full (GUS, PAS, OPL3, SB) coverage. PAS16 needs -5V from ISA bus.
Old v1 PicoGUS PCB have empty ISA pinout holes. So I added pin header to PicoGUS in order to get access to -12V, -5V, GND for mini linear voltage regulator board (UA7905C) in order to provide -5V for ISA bus.
PicoGUS doesn't seem to use -12V and -5V pins so it should be safe.

PicoGus is capable to deliver many functions. Now we can add "voltage blaster" readiness to already extensive list 😉

I love it! I'm glad I kept that header on the board as it's been cool to see people do interesting things with it, like using it as a faux PC/104 connector or what you've done!

BTW, I wanted to share this... yyzkevin has gotten Sound Blaster DSP support working on the PicoGUS, mixed with the OPL2. So now PicoGUS will be able to emulate a Sound Blaster 2.0! If we ever get OPL3 optimized enough, Sound Blaster Pro would be possible, but we're not quite at that point yet.

I posted a quick video of the PicoGUS playing Doom using SB to my Mastodon: https://bitbang.social/@polpo/111757282612442191

polpo wrote on 2024-01-15, 01:18:

BTW, I wanted to share this... yyzkevin has gotten Sound Blaster DSP support working on the PicoGUS, mixed with the OPL2. So now PicoGUS will be able to emulate a Sound Blaster 2.0! If we ever get OPL3 optimized enough, Sound Blaster Pro would be possible, but we're not quite at that point yet.

I posted a quick video of the PicoGUS playing Doom using SB to my Mastodon: https://bitbang.social/@polpo/111757282612442191

This is awesome!!!

polpo wrote on 2024-01-15, 01:18:

BTW, I wanted to share this... yyzkevin has gotten Sound Blaster DSP support working on the PicoGUS, mixed with the OPL2. So now PicoGUS will be able to emulate a Sound Blaster 2.0! If we ever get OPL3 optimized enough, Sound Blaster Pro would be possible, but we're not quite at that point yet.

I posted a quick video of the PicoGUS playing Doom using SB to my Mastodon: https://bitbang.social/@polpo/111757282612442191

I'm guessing this is not a functionality that can coexist with GUS emulation, but a different firmware altogether?

appiah4 wrote on 2024-01-15, 07:19:

I'm guessing this is not a functionality that can coexist with GUS emulation, but a different firmware altogether?

reminder that rp2040 are $1, one could chain multiple rp chips on same board for almost no additional cost. Make first rp2040 the IO dispatch chip talking to additional RPs over some fast serial bus.

I have been testing the 366MHz firmware that polpo sent me and while most games seem to be more consistent, Doom and Dope (download link) are still troublesome.

Dope in particular has been difficult. Not only did I only get to work once (with the original firmware), in my latest test it also caused Doom to lose its sound again after running it. It's like something crashed or the volume was set to 0 but it somehow persists after a complete power down (power supply switched off)

Doom has been somewhat predictable though. I think that next time I start it in a few hours or so it'll have its sound back. I know this all doesn't make sense this is the only pattern I'm seeing.

Could any of you with a PicoGUS v2 (Tindie or otherwise) please run the Dope demo and Doom, to see if they both work (and keep working?)

Im also using the 366 test version but I haven’t seen anything doom engine related work.
I’m trying other pc’s but so far not getting different results either.

polpo wrote on 2024-01-09, 05:10:

Initially I clocked the RP2040 at 280MHz, but as of PicoGUS firmware 0.7.0, the overclock is to 400MHz, which isn't mild at all. […]
Show full quote

Shreddoc wrote on 2024-01-08, 20:13:

This might be (my latest) dumb question, but does there exist large-scale testing of Picos being overclocked? […]
Show full quote

This might be (my latest) dumb question, but does there exist large-scale testing of Picos being overclocked?

E.g. 100+ random Picos, all overclocked and analysed, for statistical results?

I was just idly wondering if perhaps 1 out of 100, or whatever, might not like the overclock. This seems less likely, given that I understand the PicoGUS's overclock of the RP2040 is mild, and anecdotally, people say the RP2040 is usually capable of rather large overclocks - but just thought I'd ask the broad question, on the basis that in my experience of PC overclocking, whenever we experience weird behaviour, we always look first to the overclock, in case it is exacerbating something.

A test firmware without the overclock might be another angle from which to check that speculation, in troublesome instances.

Initially I clocked the RP2040 at 280MHz, but as of PicoGUS firmware 0.7.0, the overclock is to 400MHz, which isn't mild at all. I went ahead with that clock speed because I had great results with it in my testing of multi-hour "soak tests" where I'd just let the Doom demo loop run or have Cubic Player play through my mods directory continuously. Now that I'm selling PicoGUS 2.0 boards, I've been able to test them in large quantities so I have statistically significant data. I test each of the boards when I get them in my door by playing MIDI in MPU-401 mode, firmware flashing from DOS, and playing an S3M file in CapaMOD. My last batch had 200 units, and here are the results:

• 184 worked perfectly using firmware v1.0.1 at 400MHz.
• 1 did not respond to ISA bus events. Inspecting the board revealed bent pins and poor solder connections on one of the chips. Reflowing the solder on the pins fixed the issue.
• 13 wouldn't start up and/or reset reliably with firmware v1.0.1 at 400MHz, but only in GUS mode. Introducing 250ms of "dead time" after overclocking solved the issue with those boards.
• 2 wouldn't start/reset at 400MHz with the above fix. Clocking those boards down to 366MHz fixed the issue.

In a nutshell, 99% of the boards would run at 400MHz, but 100% were good at 366MHz.

Shortly I'll be releasing a new firmware that includes the "dead time" fix and I'm also strongly considering clocking down to 366MHz, pending testing with joystick support.

About weird behavior caused by overclocking – in my experience either the RP2040 works fine at a certain clock or it will not start. There's no zone where things act funny: it either works perfectly or it doesn't. And even at 400MHz the RP2040 gets barely warm to the touch. I could be wrong with this "either or" theory so I'll be DMing the 366MHz firmware to HandOfFate and Pickle who have recently commented reporting funny behavior so they can see if it fixes their issue.

I'll preface this statement with the disclaimer, for the general reader, that this (discussion about overclocking-related error) is only broad speculation. Outliers happen everywhere, even with the best designs.

In that sense, even if the overclocking is found to negatively affect a small % of boards, the response may partly come down to the standard old business decision faced by hardware makers everywhere, that is, the commercial choice between:

* Option 1 : test longer, to weed out the few bads - which, as a result, adds significant (time) cost to every board
* Option 2 : don't test longer, accept that there'll be X% bads, and set aside a suitable number of replacements - which again, adds cost to every board, but perhaps less than option 1

And of course, an alternative technical solution - eg. your suggested milder overclock - may make that largely moot.

HandOfFate wrote on 2024-01-15, 12:03:

I have been testing the 366MHz firmware that polpo sent me and while most games seem to be more consistent, Doom and Dope (downl […]
Show full quote

I have been testing the 366MHz firmware that polpo sent me and while most games seem to be more consistent, Doom and Dope (download link) are still troublesome.

Dope in particular has been difficult. Not only did I only get to work once (with the original firmware), in my latest test it also caused Doom to lose its sound again after running it. It's like something crashed or the volume was set to 0 but it somehow persists after a complete power down (power supply switched off)

Doom has been somewhat predictable though. I think that next time I start it in a few hours or so it'll have its sound back. I know this all doesn't make sense this is the only pattern I'm seeing.

Could any of you with a PicoGUS v2 (Tindie or otherwise) please run the Dope demo and Doom, to see if they both work (and keep working?)

Ok, this is really interesting: I just mentioned this to someone who also has a SiS 85C496 chipset based system, and he has the exact same problems: silence in Dope and Doom with his PicoGUS. I really need to get my hands on one of those boards to see what this chipset does so differently. I sort of wonder if the fact that this chipset has an early implementation of PCI means there's there's something different with how it handles ISA IRQs, because the issues that you describe point directly to an IRQ issue.

I ran into a new problem tonight with MPU emulation. Went to play around with some MT32 games like SQ3, QFG1, and Monkey Island and found that the midi did not work for them. For the Sierra games the computer locks on the game start up. I see one small blip of input to my MT32 at the very beginning before it locks up. Monkey Island sometimes plays some music, but the patches are off and things play garbled. What is interesting is that the MT32 is getting the *** PicoGus *** display message when picogus initializes so it is capable of sending midi to the MT32. However, when I select a General Midi driver with the Sierra games and Warcraft II the midi works perfectly with my Sound Canvas. It only seems to be MT32 drivers having issues.

I have tried a few different things, like the delay sysex option as well as different IRQ's and memory options. Nothing seems to fix MT32. I will see if I can do some more debug and logging.

Delphius wrote on 2024-01-16, 02:39:

I ran into a new problem tonight with MPU emulation. Went to play around with some MT32 games like SQ3, QFG1, and Monkey Island and found that the midi did not work for them. For the Sierra games the computer locks on the game start up. I see one small blip of input to my MT32 at the very beginning before it locks up. Monkey Island sometimes plays some music, but the patches are off and things play garbled. What is interesting is that the MT32 is getting the *** PicoGus *** display message when picogus initializes so it is capable of sending midi to the MT32. However, when I select a General Midi driver with the Sierra games and Warcraft II the midi works perfectly with my Sound Canvas. It only seems to be MT32 drivers having issues.

I have tried a few different things, like the delay sysex option as well as different IRQ's and memory options. Nothing seems to fix MT32. I will see if I can do some more debug and logging.

That's a new one to me – what system (mobo chipset & CPU) are you using? I did notice this thead saying some Sierra games don't work in MT-32 mode on fast systems, maybe that's the issue you have? Tonight I tried SQ3 and QFG1 with MT-32 on several systems of varying speeds (Pentium 120 w/ 430FX, K6-2 533 w/ VIA MVP3, PII 450 w/ 440BX) and didn't have any issues, so I'm not entirely sure of that.

I've found that Monkey Island doesn't fully reset the MT-32 and it'll give you pretty bad sound unless you power cycle the MT-32 if anything else has played MIDI before.

polpo wrote on 2024-01-16, 06:48:

I've found that Monkey Island doesn't fully reset the MT-32 and it'll give you pretty bad sound unless you power cycle the MT-32 if anything else has played MIDI before.

This applies to Wing Commander also. Monkey Island after Wing Commander without MT-32 powerreset is quite funny experience. Monkey Island theme is lasergun-version 😁.

polpo wrote on 2024-01-16, 06:48:

Delphius wrote on 2024-01-16, 02:39:

I ran into a new problem tonight with MPU emulation. Went to play around with some MT32 games like SQ3, QFG1, and Monkey Island and found that the midi did not work for them. For the Sierra games the computer locks on the game start up. I see one small blip of input to my MT32 at the very beginning before it locks up. Monkey Island sometimes plays some music, but the patches are off and things play garbled. What is interesting is that the MT32 is getting the *** PicoGus *** display message when picogus initializes so it is capable of sending midi to the MT32. However, when I select a General Midi driver with the Sierra games and Warcraft II the midi works perfectly with my Sound Canvas. It only seems to be MT32 drivers having issues.

I have tried a few different things, like the delay sysex option as well as different IRQ's and memory options. Nothing seems to fix MT32. I will see if I can do some more debug and logging.

That's a new one to me – what system (mobo chipset & CPU) are you using? I did notice this thead saying some Sierra games don't work in MT-32 mode on fast systems, maybe that's the issue you have? Tonight I tried SQ3 and QFG1 with MT-32 on several systems of varying speeds (Pentium 120 w/ 430FX, K6-2 533 w/ VIA MVP3, PII 450 w/ 440BX) and didn't have any issues, so I'm not entirely sure of that.

I've found that Monkey Island doesn't fully reset the MT-32 and it'll give you pretty bad sound unless you power cycle the MT-32 if anything else has played MIDI before.

The current system is an AG430HX with 233mmx & 64MB. I am also very surprised about this and I am trying to think back to if I ever had MT32 working with PicoGus or not before. It seems this would have been one of the first things I would have checked. I turned the system cache off to see if that would help but it still gave the same problem. I will try to do a little more testing today as well as try putting my Orpheus in to see if it acts the same with MT32 games.

Just out of curiosity I went and tested my v2 board midi capabilities first time.
No issues whatsoever with Monkey I and SQ3 on my K6-II@280MHZ SS7 MB with SIS530 chipset. L1 and L2 caches enabled. However SIS530 might be unique because I also do not have any issues running speed sensitive games like Tyrian. I'm running it even on 112MHZ bus speed in order to boost integrated SIS graphics memory bandwidth...

However my testes were done on MT32-Pi

What does the process of switching modes look like? I see references to "when X firmware is loaded" in the wiki and on the git page.

Is switching modes, say from GUS to MPU ,as simple as running a command and then launching an app?