Unless mca can operate in 8bit, I doubt it.
I'm pretty sure I read that 8bit already requires a lot of processing by the pico and there weren't enough gpio pins for 16bit isa.
Mca is listed as 16/32bit.
I suppose a crazy dedicated person could use multiple picos to build a truly abominable mca bridge, but I suspect the effort is beyond most people's dedication.

snipe3687 wrote on 2024-10-03, 12:23:

I'm relieved to hear that the schematic looks correct. The error message I'm getting is the dreaded "no PicoGus Detected!" whic […]
Show full quote

Caligula wrote on 2024-10-03, 09:29:

I compared it to the current git schematics of the chipdown version I could not find anything obvious. Also the PC104 seems to b […]
Show full quote

snipe3687 wrote on 2024-10-03, 01:58:

Hello everyone. I'm on kind of a PC104 kick lately. I built a backplane motherboard with a PC104 socket and since then I've been […]
Show full quote

Hello everyone. I'm on kind of a PC104 kick lately. I built a backplane motherboard with a PC104 socket and since then I've been building whatever I think could run on it into PC104 modules. this leads me to my actual question. I built a PC104 adaptation of the PicoGus. it looks great and I was able to drop the firmware on it however, it is not being detected by pgusinit. I had it assembled by JLC so I know the soldering is ok. Although I did opt to solder 3 of the chips myself since I already have them on-hand and they were a bit pricey through JLC but I went over them several times to make sure everything was solid and there are no bridges.
I also poked some of the address pins coming from the RP2040 with my oscilloscope and I see activity. so i'm wondering if I messed up when I copied over the schematic. I already found that I didn't attach IOW and IOR properly. this was due to the setting the label as active low on the bus side but not on the other end so KiCad didn't say anything about it not being connected. I bodged both of them and have continuity on both ends. I'm wondering if anyone would be willing to review my schematic and tell me if there's anything obvious (or not so obvious) that I messed up.

I've attached it here. I know it's a little messy, but I will clean it up once I'm sure everything is working properly!
And I will of course share the project files when it's done for the select few people who actually want something like this 😉

Thanks in advance!

I compared it to the current git schematics of the chipdown version I could not find anything obvious. Also the PC104 seems to be wired correctly. Best guess: some wireing/soldering/chip could be broken, another device is using the I/O ports 0x1D0..0x1D2.

Since you were able to flash the board, I would assume that the RP2040 is working kind of properly. What error message is pgusinit reporting exactly? If it is ERROR: no PicoGUS detected! then it already fails by writing out 0xCC and 0x00 to 0x1D0 or not reading properly 0xDD from 0x1D2. If you get a different error message it means that your board should work in principle, but something else is broken.

Maybe to narrow the issue a bit down (depending on what equipment you have to test):
- Do you have an logic analyzer that is fast enough for your bus? Even with a small number of pins you can still record some pins e.g. AD0..x, SA0..x, SD0..x, IOR, IOW and ADS(x should depend on the number of channels your LA has) to see if the adress and data toggling is working properly.
- Do you have ISA to PC104 adapters? Does your board work in a regular ISA slot or does a regular PicoGUS work in your PC104 machine?
- Do you have an Debug probe for the RP2040 (just use another RP2040 for that: https://mcuoneclipse.com/2022/09/17/picoprobe … as-debug-probe/ ) then you can compare what is RP2040 is sending/receiving compared to what pgusinit is doing.

I'm relieved to hear that the schematic looks correct.
The error message I'm getting is the dreaded "no PicoGus Detected!" which tells me something on the data or address bus is not working properly. I suppose it's possible that data on IOR and IOW is not flowing properly as those are the ones I had to bodge to the PC104 connector. I did verify that they are the correct pins a few times, but I've been known to make some pretty dumb mistakes in the past with these projects, so I'll verify that again later tonight as that's the only part of the bus I know for sure was not connected originally.
I do have ISA to PC104 adapters so I can test it out on one of those later. I did test one of my regular PicoGus in an ISA slot on the board, so I know that the system itself is working properly.
I have the debug probe for the RP2040 but when I connected it, it didn't show me anything in the terminal. Maybe I have some settings wrong for the serial connection.

I don't have a logic analyzer. is there any that are relatively inexpensive you would recommend? I do projects like this pretty regularly so it would probably be a good investment to have one.

I appreciate the quick response!

The PicoGUS does not write anything out by default. You have to uncomment some printf debug messages in handle_iow and handle_ior https://github.com/polpo/picogus/blob/main/sw … icogus.cpp#L437
It would also help to modify the pgusinit to print out the return value of inp(DATA_PORT_HIGH) https://github.com/polpo/picogus/blob/main/pg … pgusinit.c#L390 instead of just comparing it to 0xDD.

If the PicoGUS is reading something similar with just one or two bits flipped to what pgusinit is sending outp(0x1D0, 0xCC) outp(0x1D0, 0x00) or the return value on PC side is similar to 0xDD it might be possible that one of your pins is not soldered properly or a wire is somehow damaged.

Connecting a debugger to the PicoGUS https://www.circuitstate.com/tutorials/how-to … and-platformio/ is some additional effort at the beginning but saves a lot of time later when digging down software problems. That can help if the issue is on software side or at least visible within the software.

The general problem with "cheap" LAs is that they only move data via USB2.0 to the PC. So they are limited to 480MBit/s (minus some overhead). So there is a gap between cheap solutions for about 10Euros/Dollars like CY7C68013A or EZ-USB FX2 (together with sigrok https://sigrok.org/wiki/Downloads https://sigrok.org/wiki/Supported_hardware#Logic_analyzers) which offers 16 channels an up to 24MHz. That could be sufficient for ISA, if you can reduce your clock rate (for LA the sampling rate should be at least 4-6 times higher than the clock rate). But always with the risk, that you can't find the root cause due to the low sampling rate.
Better LAs with 16 or 32 channels and clock rates above 100MHz (which can be useful if you plan other projects anyway) start above 100Euro/Dollars. There are some other LAs out there that claim high sampling rates and high channel numbers, but you have to read the datasheets carefully. Some cheap logic analyzers can reach their high clock rates only with a low number channels (e.g. LA1010 from Kingst with 100MHz@3ch but only 16MHz@16ch).

It also makes sense to keep the logging as short as possible, so try to analyze the pigusinit start up messages (and expect some other stuff happening on the bus in the meantime, that has nothing to do with the picogus) and use IOR or IOW as a trigger signal.

myne wrote on 2024-10-04, 07:10:

Unless mca can operate in 8bit, I doubt it. I'm pretty sure I read that 8bit already requires a lot of processing by the pico an […]
Show full quote

Unless mca can operate in 8bit, I doubt it.
I'm pretty sure I read that 8bit already requires a lot of processing by the pico and there weren't enough gpio pins for 16bit isa.
Mca is listed as 16/32bit.
I suppose a crazy dedicated person could use multiple picos to build a truly abominable mca bridge, but I suspect the effort is beyond most people's dedication.

Nobody would be so crazy to recreate a MCA soundcard. Except: https://github.com/schlae/snark-barker-mca and he uses the word masochistic only once...

He relies on a Xilinx as an MCA interface chip, but when reading his documentation about MCA https://github.com/schlae/mca-tutorial - The 16bit MCA looks like a slightly extended 16bit ISA interface (except for the DMA). So with some work it might be even possible to use the current PicoGUS concept and a RP2350B (with extra GPIO pins) to implement it. And of course it would need a lot of time and some PCBs will get wasted.

Greetings,
I received my PicoGUS from Serdashop last week and it's working nicely in my PC Chips M560TG mainboard (socket 7 with P200MMX, 64MB).

In SB mode, Doom and Quake are working fine.
In GUS mode, Doom is working fine.

My goal was to rebuild a Windos 95 system to play Warcraft II on (mainboard is my original one). I bought a copy on fleabay since mine got lost somewhere in the past 30 years, this is the Battle.Net edition. This version seems to be using DirectX (v6 in this case, which is on the CD-Rom). I can't get sound working within Warcraft II though. I see it is listed as 'working' in GUS mode and that others have it working, so I was wondering if other Warcraft II players would have some tips. The 'setup.exe' doesn't offer me any configuration for the sound card and the docs only say that it uses anything that is supported by DirectX.

Any help greatly appreciated! Loving the PicoGUS, was amazed by the ease of use and the mousecom option to use a USB mouse 😁

LazySquid wrote on 2024-10-05, 09:42:

Greetings, I received my PicoGUS from Serdashop last week and it's working nicely in my PC Chips M560TG mainboard (socket 7 wit […]
Show full quote

Greetings,
I received my PicoGUS from Serdashop last week and it's working nicely in my PC Chips M560TG mainboard (socket 7 with P200MMX, 64MB).

In SB mode, Doom and Quake are working fine.
In GUS mode, Doom is working fine.

My goal was to rebuild a Windos 95 system to play Warcraft II on (mainboard is my original one). I bought a copy on fleabay since mine got lost somewhere in the past 30 years, this is the Battle.Net edition. This version seems to be using DirectX (v6 in this case, which is on the CD-Rom). I can't get sound working within Warcraft II though. I see it is listed as 'working' in GUS mode and that others have it working, so I was wondering if other Warcraft II players would have some tips. The 'setup.exe' doesn't offer me any configuration for the sound card and the docs only say that it uses anything that is supported by DirectX.

Any help greatly appreciated! Loving the PicoGUS, was amazed by the ease of use and the mousecom option to use a USB mouse 😁

If it is indeed Warcraft II Battle.net Edition (1999) and uses DirectX, then it's a Windows game. Like any Directx games, it uses Windows' APIs for hardware setup and you won't be able to "adjust" hardware selection through the game.

If you want the original GUS experience, it's all happening in DOS and you might have to get the 1995 release of Warcraft 2.

Thanks for pointing me in the right direction Linoleum, that's it by the looks of it.

dr.zeissler wrote on 2024-10-03, 06:36:

btw. ALIEN RAMPAGE refuses to use my real ULTRASOUND too...

Weird... maybe it`s just a red herring and does not really supports GUS from the start?!

Mastran wrote on 2024-10-05, 14:24:

dr.zeissler wrote on 2024-10-03, 06:36:

btw. ALIEN RAMPAGE refuses to use my real ULTRASOUND too...

Weird... maybe it`s just a red herring and does not really supports GUS from the start?!

It's possible.

But the broader reality of "game X doesn't work" reports is that, even without any PicoGUS in the equation, any given DOS game could be sensitive to a number of different factors. Hardware variables e.g. speed, chipset vagaries, CPU, amount and configuration of RAM, resource conflicts, and software variables e.g. operating system, environment variables, config & autoexec stuff, and a bunch of others. And that's without even considering the minor degradation faults that can start to creep into 30 year old systems, which can muddy the waters even further.

Which is all just to say : not getting sound in a particular game, in a particular configuration, can be merely the starting point for ongoing detailed investigation. Which often has to happen over time through the community, because (generally speaking) no one person has all the computers, configurations and time necessary to put games through the entire gauntlet of compatibility possibilities.

All this is also why a Compatibility List is more complicated than simply taking individual user reports of Thing X Doesn't Work and passing that on to the world as a universal truth.

A lot of games just had buggy GUS support, or undocumented requirements like requiring ULTRAMID to be resident before starting the game.

Any idea why my Pentium 100mhz does not want to boot into windows 98 after installing the picogus i just received from EU store (most probably new firmware in already), but w98 boots just fine in safe mode...driver issue? Sounds also work in dos games just fine when running them in safe mode.

I am really rusty with the old driver issues..

When in doubt:

DELTREE C:\WINDOWS
D:
INSTALL.EXE

Lol.
I'd try removing the device in safe mode and any drivers if possible

What I did initially:
- add picoGUS ISA
- remove sound blaster awe64 ISA
- remove PCI yamaha sound card

I did that..then booted up and Windows 98SE boot sequence stops at loading screen without errors, cannot ESC out to see if there are any..
Boots up just fine in safe mode, where I removed the original sound card drivers for SB awe 64.

Tried to switch jumpers on picoGUS to change DMA1 --> DMA3...I am clueless at this point what to do next

iikkak wrote on 2024-10-21, 17:24:

What I did initially: - add picoGUS ISA - remove sound blaster awe64 ISA - remove PCI yamaha sound card […]
Show full quote

What I did initially:
- add picoGUS ISA
- remove sound blaster awe64 ISA
- remove PCI yamaha sound card

I did that..then booted up and Windows 98SE boot sequence stops at loading screen without errors, cannot ESC out to see if there are any..
Boots up just fine in safe mode, where I removed the original sound card drivers for SB awe 64.

Tried to switch jumpers on picoGUS to change DMA1 --> DMA3...I am clueless at this point what to do next

From what I remember with my PicoGUS, it won't register as a Plug and Play device; you need to run PGUSINIT in your Autoexec.bat file before Windows starts to initialize it, then once Windows starts you'll need to Add New Hardware and choose a non-PNP device. You may need to choose a Gravis Ultrasound manually, if memory serves me.

MadMac_5 wrote on 2024-10-21, 18:02:

From what I remember with my PicoGUS, it won't register as a Plug and Play device; you need to run PGUSINIT in your Autoexec.bat file before Windows starts to initialize it, then once Windows starts you'll need to Add New Hardware and choose a non-PNP device. You may need to choose a Gravis Ultrasound manually, if memory serves me.

I did not manage to get my P100 vintage box to boot up, so gave up and decided to start to move my business to my P2 233Mhz box : ) There were absolutely no problems whatsoever regarding the windows bootup.

Now to get pigoGUS to register in Windows, so being able to play something out from Winamp, that will probably have to wait for firmware support!

Thanks for the help. It was really cool to be able to boot up OMF2097 with SB16 mode, listen to the title music and then boot up in GUS mode and compare the results head to head so fast. Crazy!

Hello all, need help. Picogus v2.0 chipdown(smd) version, soldered by myself. Flashed with latest firmware via USB, and then flashed via ISA in real DOS enviropment - flashes well.
The pgusinit tells me that the card is recognized with firmware 2.1.0, but no response from picogus from 240 port. Can't save the settings, can't set the port.

The only chip unsoldered is M62429 (volume controller), it is on the way by dealer, but i think it's not the problem of unreachable 240 port.

Solder shorts are impossible, i checked my solder work twice, and i have experience with smd soldering more than 10 years. But it may be overheated IC somewhere, or just broken IC from dealer.
Where must i dig to find the source of problem?

Ah. Settings are DMA3/IRQ7, and there is also SB16 CT2910 with standard 1+5 DMA/IRQ5 jumpers set. Can they live together?

esher wrote on 2024-10-27, 17:14:

Ah. Settings are DMA3/IRQ7, and there is also SB16 CT2910 with standard 1+5 DMA/IRQ5 jumpers set. Can they live together?

Not at the same port. Does PGUSINIT report the PicoGUS at port 240?

digistorm wrote on 2024-10-27, 21:26:

esher wrote on 2024-10-27, 17:14:

Ah. Settings are DMA3/IRQ7, and there is also SB16 CT2910 with standard 1+5 DMA/IRQ5 jumpers set. Can they live together?

Not at the same port. Does PGUSINIT report the PicoGUS at port 240?

No. Pgusinit tells "ERROR: Card not responding to GUS commands on port 240". However, i can enable/disable joystick port and MIDI port, reflash the firmware, but can't /save settings

PS. I can change modes too, /mode adlib cms tandy are changing but i cannot check the sound yet due to missing volume IC. It will arrive in a week, i hope.
Edit2: checking schematic, i CAN check the sound, as the volume IC controls only wavetable. Will check it later.

Edit3: pgusinit /mode sb works fine, Sound Blaster mode with DMA3/IRQ7 as well as /mode adlib.
With /mode tandy i cannot get any sounds (only Dune II tested).
SB16 is taken out from motherboard.

Edit4: well, it seems that there is faulty IC in ADDR/DATA MUX/DEMUX block. Waiting for replacement.

I just started actually testing a PicoGUS 1.2 that I built myself and noticed an issue. For some reasons I have to run pgusinit at least twice per boot in order to make it function properly.

While there were no errors during the first run of pgusinit (e.g. using GUS mode), trying to utilize the card in this state would lead to hangs. Those issues would go away once I run pgusinit a second time.

Not sure if this behavior is caused by the firmware (2.1.0), or my hardware, as I'm not using an official Pi Pico -- it's a WaveShare clone with larger flash space as well as using Type-C instead of micro-USB.

Apart from this particular issue the card is working okay, using IRQ7 and DMA3 as I've an AWE64 Gold on that system taking IRQ5 and DMA1/5.

EDIT: By the way... is there an available bracket design for PicoGUS 1.2 when not using the GY-PCM5102 module ("integrated DAC" method)? I used this one which was featured in the build guide, but it's not compatible when building the card using "integrated DAC" method, as the 3.5mm Line Out jack would be at a different position compared to when using GY-PCM5102, that I had to manually drill a hole to accommodate the difference.

LSS10999 wrote on 2024-10-29, 15:39:

EDIT: By the way... is there an available bracket design for PicoGUS 1.2 when not using the GY-PCM5102 module ("integrated DAC" method)? I used this one which was featured in the build guide, but it's not compatible when building the card using "integrated DAC" method, as the 3.5mm Line Out jack would be at a different position compared to when using GY-PCM5102, that I had to manually drill a hole to accommodate the difference.

Well, i'm not using the bracket at all,my plans is to route Picogus audio out to CD line in @SB16, and the MIDI port to custom bracket with mini DIN which Creative use in SB Audigy 2 ZS with 5.25" module.
Anyway, i recommend to build a custom bracket with 2xRCA stereo out, as i did to SB16 before. Just take one of the dummy bracket from the PC case and drill the holes for RCA.