Reply 1960 of 3174, by 640K!enough
I think that makes perfect sense. Is what used to be JP4 now a full-sized 0805 resistor?
I think that makes perfect sense. Is what used to be JP4 now a full-sized 0805 resistor?
yup 😀 JP4 has become R12, JP5 is now R13x - all are full sized 0805 resistors.
Current Project: new GUS PnP compatible soundcard
[Z?]
Can you add some Hole on the upper side of the Board,
it would be useful to screw daughterboard to the ARGUS Card.
i'm making a version of sergeys opl2 isa card for the ISA Header, and it would be nice to screw them togehter 😀
also i'm still very satisfied with the ARGUS Card, i run it as default sound device in my K6-2 and encountered no problems or combatiblity issues yet.
Except for resource allocation but this is fault of the pnp bios. disabling pnp solved this problem.
https://www.retrokits.de - blog, retro projects, hdd clicker, diy soundcards etc
https://www.retroianer.de - german retro computer board
Asking all beta testers ... has anyone of you put in sockets for the SOJ DRAMs (U0/U1) or has the intention to do so in the future? I'll likely remove that feature due to some routing changes.
Also in a brief moment of insanity to distract myself from routing, I gave this behemoth a go ... it works 😀
https://i.imgur.com/mADokIn.jpg
Current Project: new GUS PnP compatible soundcard
[Z?]
I have not installed soj sockets because I doubt I can solder them good with my current equipment...
wrote:Asking all beta testers ... has anyone of you put in sockets for the SOJ DRAMs (U0/U1) or has the intention to do so in the future? I'll likely remove that feature due to some routing changes.
I have installed a couple of SOJ DRAM ICs, but never got to trying the sockets. I didn't have the budget to order several different designs for testing, and just decided to skip it. The SOJ footprints are convenient, but I don't really think I would need to use sockets for that purpose. If you decided to remove the option for SOJ DRAM altogether, I wouldn't miss it that much.
Have you had a chance to consider the amplifier situation? The Philips part many of us used has been discontinued, along with a number of other similar parts. There are suitable, pin-compatible replacements, for now (or at least there were the last time I checked). Would it be worth the trouble to accommodate a different pin-out, or do you expect that we'll be able to find suitable parts long enough for our needs?
SOJ sockets are gone then. I did attempt to fit some twice but actually failed. SOJ footprints will still remain tho.
About the amplifier situation - I'll look into that.
Current Project: new GUS PnP compatible soundcard
[Z?]
Current changelog:
Transition Prototype 02 -> RC 01
! uncrammed C717, C718, C721, C725
+ added C14 (100nF) to CFILT according to datasheet
! added support for non-PnP mode (3 way pads for R11)
+ added support for straight 72pin SIMM connects (additional drills)
! cleaned up RA20/RA21 configuration (JP4 -> R12, JP5 -> R13A, R13B, R13C)
! integrated X3 into the footprint of U31 (as U31EX)
- removed X3
! renamed X1 and X2 to ISA8 and ISA16 to make their purpose clearer
! renamed JPx to Jx
! renamed gameport/audio connectors to X0-X3
! changed silkscreen explainations to reflect the new naming scheme
- removed support for SOJ sockets for U0/U1
Likely gonna pause for a few days.
Things that will not be implemented:
- socketed op-amps (area too crammed), I'll likely add an alternative output amp tho
- additional audio in (there are already 2 line ins P45 and MPC)
- change thermal reliefs (sorry, eagle sucks in that regard and don't wanna touch up manually)
- headers for line in, line out, mic (mic is useless, line in is already there [P45], line out wouldn't make too much sense [go over line in instead])
- additional drills (you can repurpose the voltage regulator holes ... also 62 + pins should give a good fit)
In the meanwhile ... any recommendations for the alternative amplifier? NE5532 any good?
Current Project: new GUS PnP compatible soundcard
[Z?]
wrote:Asking all beta testers ... has anyone of you put in sockets for the SOJ DRAMs (U0/U1) or has the intention to do so in the future? I'll likely remove that feature due to some routing changes.
Also in a brief moment of insanity to distract myself from routing, I gave this behemoth a go ... it works 😀
https://i.imgur.com/mADokIn.jpg
No Socket either here.
I decided to test the custom-EEPROM method of disabling Plug-and-Play support. On my system, it didn't work at all. Yes, Plug-and-Play support was disabled, but everything else failed too, from IWINIT hanging/crashing to PNPMAP refusing to re-write the EEPROM. It's as good as having a paperweight, so that's not recommended.
I'm fairly confident that it is related to a software problem, and that producing a corrected IWINIT and company would get things working, but I doubt it's worth the effort. I'll just make other arrangements to erase the EEPROM, or replace it the next time I order parts, and write it using PNPMAP.
It is also worth mentioning that, on my system, the non-PnP behaviour was quite different from what shock__ reported. IWINIT, PLAY.EXE and other common tools worked as expected, in every ROM and RAM configuration tested, including none.
Has anyone tested the card on a 386 or earlier so far?
wrote:I decided to test the custom-EEPROM method of disabling Plug-and-Play support. On my system, it didn't work at all. Yes, Plug-and-Play support was disabled, but everything else failed too, from IWINIT hanging/crashing to PNPMAP refusing to re-write the EEPROM. It's as good as having a paperweight, so that's not recommended.
Is that the equivalent of closing JP9 on the original GUS Pnp boards?
JP9 on the GUS PnP probably is some remainder from the Defiant prototype. One pin goes to VCC, the other goes to GND via a 10K resistor ... odd stuff there.
Current Project: new GUS PnP compatible soundcard
[Z?]
wrote:Is that the equivalent of closing JP9 on the original GUS Pnp boards?
It is somewhat similar, but there are significant behavioural differences between the two methods, so I would not say it is equivalent. For instance, on my machine, closing JP9 on the GUS PnP v1.0 still allows IWINIT and PLAY.EXE to work as expected, and all functionality is available under Windows (SETUP.EXE won't run, however). With this, I haven't found a way to get anything running, even when combined with JP9.
It is probably an implementation issue with the standard software, but I don't have the hardware I would need to properly investigate the issues. There are also other things waiting for my attention at the moment. I might have a look at some point, hopefully before the final design is ready.
wrote:wrote:Is that the equivalent of closing JP9 on the original GUS Pnp boards?
It is somewhat similar, but there are significant behavioural differences between the two methods, so I would not say it is equivalent. For instance, on my machine, closing JP9 on the GUS PnP v1.0 still allows IWINIT and PLAY.EXE to work as expected, and all functionality is available under Windows (SETUP.EXE won't run, however). With this, I haven't found a way to get anything running, even when combined with JP9.
It is probably an implementation issue with the standard software, but I don't have the hardware I would need to properly investigate the issues. There are also other things waiting for my attention at the moment. I might have a look at some point, hopefully before the final design is ready.
I tried closing it recently when my original card refused to work, and that only made it worse. The card with the jumper open would allow for EEPROM writes to configure ressources, but would lose them on a reboot and no longer initialize. With the jumper closed, nothing would detect the card; not the EEPROM tools, not IWINIT.
I vaguely recall that at some early point in the (DOS) drivers, Gravis removed compatibility with the non-PnP mode using JP9 and basically required users to remove the jumper.
I'll see if I still have the old drivers somewhere.
I use the card on old boards, such as 386. However I can not grasp from your description where there should be a problem?
The only difference is, that the BIOS on a e.g. 386 can not initialize the cards resources by itself. But for initialization you call iwinit anyway, on the 386 as well as on a system with ISA-PnP capable BIOS.
Retronn.de - Vintage Hardware Gallery, Drivers, Guides, Videos. Now with file search
Youtube Channel
FTP Server - Driver Archive and more
DVI2PCIe alignment and 2D image quality measurement tool
It turns out that I overlooked one detail during my testing. When the card is configured to act as a non-PnP device, no resources are reserved for it before the OS loads. My IW.INI depended on the usually-assigned resources, but with the InterWave in non-PnP mode, those resources were re-assigned. When IWINIT finally ran, it created an IRQ conflict, resulting in a crash.
I haven't finished testing, but it seems like both the jumper and custom EEPROM methods of disabling the InterWave's PnP support work. The only drawback to the EEPROM method is that PNPMAP won't run to re-write the EEPROM (should the need to re-enable PnP support arise); this means different software would need to be used for that purpose, or the EEPROM removed and written in a dedicated programmer.
On Plug-and-Play systems, some software won't run with PnP support disabled on the card. In particular, this applies to software that includes code to detect and initialise an InterWave board even if IWINIT hasn't yet done its job. Particular examples are the DOS-based SETUP.EXE and PNPMAP. Software that depends on IWINIT and other initialisation tools to prepare the card for use, such as PLAY.EXE, older GUS software and games, should work fine.
Ok, but what is the difference to setting in BIOS "PnP OS = Yes" ? (Which is btw. default)
It leaves non crucial PnP devices uninitialized and leaves resource initialization to the OS.
From what I get you describe exactly the difference between calling IWINIT w/o and with the '-legacy' switch.
Retronn.de - Vintage Hardware Gallery, Drivers, Guides, Videos. Now with file search
Youtube Channel
FTP Server - Driver Archive and more
DVI2PCIe alignment and 2D image quality measurement tool
wrote:Ok, but what is the difference to setting in BIOS "PnP OS = Yes" ? (Which is btw. default)
It leaves non crucial PnP devices uninitialized and leaves resource initialization to the OS.
The main difference is that using one of the methods described to disable PnP support at the IC level prevents normal PnP initialisation from working at all. One then must treat it like a legacy ISA device, using IWINIT or OS-level drivers to assign resources. Any attempt at PnP enumeration will fail, whether at the BIOS, PnP OS or init tool level. The EEPROM is also inaccessible via the usual means.
One side-effect of this is that software that tries to locate the card on its own, without the help of IWINIT, will fail on a PnP-compliant system, if it doesn't also support legacy initialisation mode. That is the case for SETUP.EXE and PNPMAP, for instance. I don't yet know if either of those will run on a non-PnP system, like a 386, without a PnP configuration manager loaded. IWINIT should work on such a machine with no CM.
wrote:From what I get you describe exactly the difference between calling IWINIT w/o and with the '-legacy' switch.
Many DOS installations try to use legacy mode by default, but there have been reports of strange behaviour from at least two here, and the non-PnP mode could be one more tool available in such cases.
Using the legacy option still allows PnP enumeration, which may pose a problem on buggy BIOS implementations. This outright prevents that, leaving no choice but pure legacy initialisation, if the card is to work at all.
EDIT: From keropi's thread, it looks like some versions of SETUP.EXE (and surely PNPMAP) need the CM on older machines, too. Disabling PnP support in hardware would prevent them from running on any machine. If one were using the CM just for the GUS/ARGUS, it shouldn't be required, except for running those tools (or similar applications). GUS and native InterWave software and games should run fine with no CM loaded.
wrote:In the meanwhile ... any recommendations for the alternative amplifier? NE5532 any good?
That amplifier should be more than enough.
Those who will can have different ones (socketed?), but in these places it does not matter so much TL072/NE5532/NJM4580 give the similar result.
Current project: DOS ISA soundcard with 24bit/96Khz digital I/O, SB16 compatible switchable.
newly made SB-clone ...with 24bit and AES/EBU... join in development!
wrote:SOJ sockets are gone then. I did attempt to fit some twice but actually failed. SOJ footprints will still remain tho.
About the amplifier situation - I'll look into that.
For the amp, maybe go for op-amp and a pushpull output stage ?
it seems many of the analog amps are discontinued now, even some lm386 parts becoming unavaible now..
i don't need any SOJ sockets, i'm happy with the PS/2 Slot 😀
https://www.retrokits.de - blog, retro projects, hdd clicker, diy soundcards etc
https://www.retroianer.de - german retro computer board