Renamed 'SPDIF' -> 'ESP'
Otherwise I take it that things should work out?

90° rotation won't happen - just checked the dimensions of those IDC-pinheaders, even when rearranging stuff those would still collide with the SIMM slot and overlap the credits.

Are new funders/donaters able to contribute and get in on this to help the project move along? Am I reading the state of things correctly?

stacker139 wrote:

1 / There are two functions of IWUTIL.EXE that can read (IwaveRegPeek) and write (IwaveRegPoke) a value in a register. IWUTIL.exe is a compilation of IWUTIL.C program (included in the pnpddk).

IWUTIL.C cannot be used in the way that you think it can; it only contains functions to allow access to some aspects of the InterWave, and will not compile into an executable programme.

It would certainly be possible to create a utility that allows access to those two functions from the command line, though I'm not sure it will provide the result you're hoping for.

shock__ wrote:

TS482 is an active replacement type for MS6308/TDA1308 (according to http://www.allxref.com/philips/tda1308.htm)
https://www.mouser.de/Search/Refine?Keyword=TS482I

Any betatesters up for verifying?

It is worth noting, for anyone planning to test this as a replacement part, that only the TS482IDT will fit in the existing footprint.

If I may ask, what is the planned approach going forward? I have seen mention of committing to a final run sooner or opting for another prototype run in hopes of getting S/PDIF support implemented, but there doesn't seem to have been enough discussion on the subject to establish a consensus. So, to be clear about the matter:

1. What do we prefer: final cards sooner, or more prototyping to potentially get S/PDIF support (which may still not be viable)?
2. If we want S/PDIF support, how much more will it cost, and who is willing to pay?

Alternatively, is jumping to production with the serial header there, but potentially unused, not a possibility?

EDIT: These are, presumably, still questions for those who contributed previously, unless something has changed.

EDIT 2: To answer my own questions, I have no use for S/PDIF support, nor any way to test it. Furthermore, I have no budget for either option at the moment, so I will let the rest of you discuss and decide.

I'm absolutely for getting S/PDIF support. If we can skip another prototype and go straight into production - better (I won't care for an unused serial header if something goes wrong). If another prototype is a must for confirming the header before the production run, I'm fine with that too.

Regarding additional donations - I'm willing to donate once again for the sake of this feature.

Another prototype run would be $60 - 10 boards, made in China. Donors will get a prototype board.
Personally I don't care about SPDIF either. Never used it, probably never will in a vintage setting.

My prefered approach would be "final evaluation prototype, then production, SPDIF as a potentially useless header"

Since I only came across this late last year: happy to jump in with $60 for a prototype and doing some testing in a bunch of machines and environments afterwards.

Sorry to sow trouble in the production process of ARGUS. But if you allow me here are my arguments:

1/ A card with an available ESP (Externally serial port) header will multiply the chances that the S/PDIF function or other features using the external serial port will be released. Because, to my knowledge, only the owners of the Compaq Ultrasound 32 Pro (STB) card can experiment with this feature.

2/ Is it necessary to make a new series of protoptype? Do we need to test new tracing on the PCB?
On the other hand, it seems important to me to check the wiring and the components present between the pins 41, 54, 60 and 61 of Am78c201akc and the connector P3 of the Compaq Ultrasound 32 Pro (STB) card. Do you know a possessor of this card? Can it visually and electrically check (with an ohmeter) the tracks and components between Am78c201akc and the P3 connector?
The answer to these questions will remove doubt. I also trust the people who designed the Compaq Ultrasound 32 Pro (STB) card.

3/ Adding the ESP header will put the ARGUS card almost at the same level as the Compaq Ultrasound 32 Pro (STB) card. Except the "Sound fader control" and "PCM Codec for Modem" functions.

For SPDIF you'd need an extra chip such as DIT4096 or DIT4192, the ESP is just i2s like (the timing diagram isn't completely clear to me) link and only if specifically enabled in software. It also has limited use since you can only have it output raw data of the WSS codec or digitized data from analog path. Latter is the most useful thing but at that point you might aswell do it externally with modern parts...
I personally would only add 4 test points, whoever wants to experiment can solder up a dongle to them with the required support hardware.

This is what I said months ago. It is a questionable feature, at best. The option that offers the most complete support for sound sources still passes through the on-chip analogue stage. What is the point, exactly?

Furthermore, the registers may be modified by software during initialisation, and sound from all on-chip modules may not be present in the signal. Depending on sample rates used and/or timing, this may be difficult. It seems like more trouble than it's worth.

As far as I know, we are not considering adding the necessary chips to the card; just a footprint for the headers. All needed parts will need a daughterboard or module with the necessary circuitry, which one of the interested parties will have to design.

In case anyone of the _previous donors_ wants to join the "release candidate" prototype run, the deadline is March 23rd (which is when I'll order the PCBs if the money comes together), currently there are 6 slots remaining. Minimum donation is $10 for a bare PCB + InterWave presoldered.
PM for details.

If we return to the subject of the ROM headers for a moment, I would suggest that anyone who is interested plan on using 50-pin, 2-row headers. There are two primary reasons for this. Firstly, the single-row, 25-pin headers seem to be relatively unavailable in 1.27mm-pitch, surface-mount form. Secondly, and more importantly, the double-row version will offer superior strength during mating and de-mating, since there are more solder joints supporting the receptacles. They are still somewhat expensive via Digi-Key, at about $5.50 CAD each, but at least we have more parts/manufacturers from which to choose, rather than just a couple of Samtec parts.

It is worth pointing out that I haven't completed the design of the revised ROM module for the release candidate design, so there are no modules available for testing at this time. Hopefully, I will have something we can test before the details are settled for the final run, but I can't make any promises. If nothing else, those building their cards can always fall back on the original, old-stock masked ROMs, which seems to be what the vast majority of those who built the Rev 2 prototype chose, anyhow.

Let's not forget the option to use 29F800 EEPROMs (as ROMs) 😉

Also strongly supporting the dual row header approach (afterall it's what Matrox did in the 90s already: http://www.vgamuseum.info/images/vlask/matrox … stique220fb.jpg)

Totally on it 😀, great project! Needs support so it can keep going 😀

2 slots left (1 pending).
"Release Candidate" run therefore will happen.

am I in time? sent a pm

@shock__: If you need another slot filled, I am happy to join.

I sent payment last night, so I should be in as well. Was I the "pending" one?

cyclone: Nah, you're one of the 8 on the definite list 😀