keropi wrote:

The PnP repair wasn't anything spectacular: new capacitors, a VERY good cleaning, reflow of the F32 at U10 because it looked weird (still does!) and re-flash of the eeprom. After all these the card was revived

Is it just the picture, or is the ROM at a slight angle on its footprint? Is there a particular reason you removed the SIMM sockets, or was that how it arrived?

I've seen a number of these boards that have one or more of U9 through U13 looking rather worn; I wonder what the cause is.

Not everything is soldered perfectly aligned on the card, that's how it is made apparently - a little quick and sloppy and it's nothing unusual 🤣
The simm sockets were removed , I will solder a 72pin adapter at some point.

About the work ICs, maybe gravis used some lower-cosmetic grade ones to save up... it's not like in this card's case that U10 was hit with something and it became skewed - the pads would also rip but they are perfect. It's just how it was soldered apparently...

640K!enough wrote:

shock__ wrote:

Any input on that? I wouldn't mind adding a header or even a full implementation - but have to admit that I've never worked with SPDIF before, so some guidance might be required.

I have hardly ever used a S/PDIF-enabled device, much less designed anything involving one, but I question the feasibility of this endeavour. Looking through the datasheet and programmer's guide, it quickly becomes clear that it would be far more involved than setting a register once and connecting those signals to an appropriate encoder. The only way it seems even remotely feasible still involves going through the on-chip analogue stage before getting to the CODEC module. Otherwise, you seemingly won't have access to the full card's output. Furthermore, the serial output is unavailable when certain other FIFO modes are used, if I'm reading correctly, and would seemingly also require driver-level changes for Windows to manage that register setting. My vote would be to ask this person to provide some form of proof-of-concept implementation, or at least more concrete circuit and software design guidelines, before going ahead with unnecessary layout and routing work. I'm not claiming that it definitely can't be done, but it doesn't look like it would work as intended.

Thanks for the input - that is pretty much on par with my judgement.

I also haven't ever used spdif in my life yet... I don't see the appeal on old soundcards tbh, it's like asking an EGA card with HDMI output, old stuff are supposed to be fuzzy 🤣 🤣 🤣

There really isn't much point when dealing with most old cards. They're generally designed to mix several analog sources before outputting via a power amp stage or line output. Any SPDIF output would still have all the noise of the internal analog mixing.

Later generation cards with high levels of integration could conceptually use SPDIF (as CMI 8330 based cards, in fact, did), but it's not really an option most ASIC manufacturers pursued.

Shame, really. An ES1869 card with SPDIF I/O would be spiffy.

Having tried a few different combinations, I can say that the sound produced via Mega-Em is always lacking in some respects. The 2 MiB, 8-bit set was better in some ways, but had anomalies similar to the triangle in a number of other places (the triangle was broken in that bank as well). I still plan on tracking down a few other versions of Mega-Em to see if the results are at least a little less unappealing. As d0pefish has demonstrated, older versions can sound marginally less broken.

Is there anyone with a GF1-based card who would be willing to share their MEGAEM.CFG? Please mention which version of Mega-Em it's from, if you do post it.

Hi Guys
When the rest of the cards will be available for the people who made doantion earlier ?
I tried to search info about that but I couldn't find.

Thanks

Targeted production date for the regular series is june/july 2018 - unless something goes horribly wrong during betatesting.

640K!enough wrote:

Having tried a few different combinations, I can say that the sound produced via Mega-Em is always lacking in some respects. The 2 MiB, 8-bit set was better in some ways, but had anomalies similar to the triangle in a number of other places (the triangle was broken in that bank as well). I still plan on tracking down a few other versions of Mega-Em to see if the results are at least a little less unappealing. As d0pefish has demonstrated, older versions can sound marginally less broken.

Is there anyone with a GF1-based card who would be willing to share their MEGAEM.CFG? Please mention which version of Mega-Em it's from, if you do post it.

I have a GUS-MAX with Mega-EM 3.10 currently installed. Would that be good for you ?

I don't need the whole installation, just MEGAEM.CFG. I think I've found a source for almost all of the versions of Mega-Em that have InterWave support.

EDIT: Is there anyone who owns an external MIDI device who would be willing to try another experiment? The idea is to connect it to the PnP's MIDI/joystick port, configure Mega-Em to output through that port via MESETUP, and play a few MIDI files via MegaMID (or similar). Whether setting it for GUS MIDI port or MPU-401 will work better is left as an exercise for the reader. Whichever option is chosen, we don't want the GUS synthesizer to also be active. This is meant to tell us whether Mega-Em's MIDI interpreter or playback engine is broken (at least one definitely is). I will have to send two particular MIDI files to the willing participant.

640K!enough wrote:

I don't need the whole installation, just MEGAEM.CFG. I think I've found a source for almost all of the versions of Mega-Em that have InterWave support.

EDIT:: Is there anyone who owns an external MIDI device who would be willing to try another experiment? The idea is to connect it to the PnP's MIDI/joystick port, configure Mega-Em to output through that port via MESETUP, and play a few MIDI files via MegaMID (or similar). Whether setting it for GUS MIDI port or MPU-401 will work better is left as an exercise for the reader. Whichever option is chosen, we don't want the GUS synthesizer to also be active. This is meant to tell us whether Mega-Em's MIDI interpreter or playback engine is broken (at least one definitely is). I will have to send two particular MIDI files to the willing participant.

I do own a SC-88 and a MT-32. I have already used the MT-32 with the Argus to play SQ3.

Do you want my MegaEM 3.10 cfg file or not ?

Yes, the file would be helpful, in that case, configured for GUS synthesizer with no MIDI output. These are intended to be two separate tests.

For the curious, using the InterWave, Mega-Em eats notes under certain conditions and plays some other things very badly. That's why I'm trying to isolate where this undesirable behaviour comes from. The external MIDI test will hopefully shed some light on that.

640K!enough wrote:

Yes, the file would be helpful, in that case, configured for GUS synthesizer with no MIDI output. These are intended to be two separate tests.

For the curious, using the InterWave, Mega-Em eats notes under certain conditions and plays some other things very badly. That's why I'm trying to isolate where this undesirable behaviour comes from. The external MIDI test will hopefully shed some light on that.

Alright, tonight I will do this :
1. I will plug in my SC-88 pro to the Argus, set MIDI output to GUS MIDI Port and record 2 .MID files that 640!enough will provide.

@640K!enough

I am attaching 2 cfg files from versions 3.03b and 3.10 from my 3.73 GUS classic
None work for me, they complain about the "EMM incompatibility problem: Unable to expand servers Page Directory" so I have no idea if the CFGs are valid.
At least version 3.03b's setup builds a 1024kb bank on first load before it fails with the above error.
I have never messed with GUS midi playback other than what games load on startup. In my system there is a also an MPU at 330/irq2

No idea if it helps though 😀

edit:
oh the error is because I have 128MB of RAM installed in my 233mmx system

Ready to Record.

Synoptic wrote:

Ready to Record.

The test files are attached, but I will be removing them shortly.

640K!enough wrote:

Synoptic wrote:

Ready to Record.

The test files are attached, but I will be removing them shortly.

You can remove them

Recordings.

Synoptic wrote:

Recordings.

Thanks. Just to confirm, that was with the SC-88 connected to your ARGUS prototype, Mega-Em loaded to pass the data over the MIDI port, and Mega-Em treating the InterWave more like a GF1 (using your old MEGAEM.CFG from the Max, because in native InterWave mode, the ROM is required). If that's the case, the answer is that the problems seem to come from the playback engine built into Mega-Em. When playing through the on-board synthesizer, a few notes are eaten in ROBBEN2.MID, and the pitch bends are severely mangled in DIGILAND.MID.

All is good, except I did not understand I had to use the GF1 Megaem.CFG file.
I will record again.

[EDIT]
NEW RECORDINGS :
Mega-Em 3.11 with MEGAEM.CFG from the GF1 UltraSND installation files.
Using Roland SC-88 PRO
Using the ARGUS Joystick Port
MegaEM set to output through GUS MIDI PORT
When Loading MegaEM, it loaded the patch set in memory.