VOGONS


Reply 1620 of 3172, by 640K!enough

User metadata
Rank Oldbie
Rank
Oldbie

So far, my efforts to test Mega-Em have been nothing short of exercises in frustration. I have tried just about every reasonable combination of options for EMM386, and even several versions of DOS and EMM386. Eventually, it still results in the message complaining of the inability to enlarge the server's page directory.

The only thing resembling an answer that I have found was on a German forum, via Google Translate, so I hope I got the gist of the conclusion. If there's any truth to that, then it seems that Mega-Em won't work with more than 64MiB of memory. If true, it's unclear whether this is due to a limitation of Mega-Em or EMM386. Has anyone been able to disprove this? If someone has Mega-Em working, does adding memory beyond 64MiB break it?

Reply 1622 of 3172, by 640K!enough

User metadata
Rank Oldbie
Rank
Oldbie
Phreeze wrote:

can you link the german forum? Many german speakers here 😉

Sure, there was the German discussion, and another seemingly related Russian discussion that I didn't even try with Google Translate.

I have a few other ideas to try, but unfortunately, no x86 system with 64 MiB or less of memory, nor any DIMMs less than 128 MiB, so trying a reduced-memory configuration isn't possible at the moment.

Reply 1623 of 3172, by Rawit

User metadata
Rank Oldbie
Rank
Oldbie

If you have a system with 64 MB memory or more then EMM386 in combination with HIMEM 3.x have a bug that prevents MEGAEM from loading. MEGAEM reports something like "Can not expand server pages". It is not a MEGAEM issue and can be fixed by either using an alternative memory manager like QEMM386 or an older HIMEM 2.x that only supports 16 MB XMS. I have not tested if other third party drivers like HIMEMX work too.

From: http://www.retronn.de/imports/gus_config_guide.html

Limiting with HIMEMX seems to working according to the Russian forum.

YouTube

Reply 1624 of 3172, by 640K!enough

User metadata
Rank Oldbie
Rank
Oldbie
Rawit wrote:

If you have a system with 64 MB memory or more then EMM386 in combination with HIMEM 3.x have a bug that prevents MEGAEM from loading. MEGAEM reports something like "Can not expand server pages". It is not a MEGAEM issue and can be fixed by either using an alternative memory manager like QEMM386 or an older HIMEM 2.x that only supports 16 MB XMS. I have not tested if other third party drivers like HIMEMX work too.

From: http://www.retronn.de/imports/gus_config_guide.html

Limiting with HIMEMX seems to working according to the Russian forum.

That's interesting; I'll have to try that. Still, the German page seems to indicate that QEMM386 (which I don't have) didn't work either.

I did manage to get it to load, but have more testing to do. I think there was an incompatibility with the ROM bank I had installed. I will have more information to share shortly.

Reply 1625 of 3172, by 640K!enough

User metadata
Rank Oldbie
Rank
Oldbie

I have a little more information to share regarding Mega-Em. The good news is that it should be possible to get it running on most configurations, even with the common Microsoft HIMEM.SYS version 3.x, though it's not necessarily ideal. Although still somewhat finicky, Mega-Em is not nearly as picky about the EMM386 configuration as it may at first appear. In my testing, the key seemed to be reducing the amount of extended memory visible as XMS via HIMEM.SYS. By default, under MS-DOS 6.x, this is about 64 MiB. Under these conditions, no combination of arguments to EMM386 seems to work.

There may be other ways of consuming extended memory before HIMEM.SYS loads, so that there is less available, but I didn't test that approach. The method that worked turned out to be relatively simple, and doesn't require finding old versions of HIMEM.SYS or other memory managers: set the BIOS setting usually labelled something like "OS Select for DRAM > 64MB" to OS2. This has the effect of "lying" to DOS, and getting HIMEM.SYS to report a total of about 16 MiB of XMS. With this, many common configurations of EMM386 will end up working with Mega-Em.

With Mega-Em finally loaded, it was time to try testing it. I have to admit that results seemed to vary. Even with the official AMD/Eye & I ROM, MIDI playback using General MIDI emulation seemed to be generally inferior to the results obtained via the included PLAY.EXE or under Windows 3.1. Whether this is normal behaviour isn't yet clear. FM emulation via Mega-Em is actually significantly worse than the results obtained using IWSBOS, and this just using some of the oldest FM-enabled software on the PC: the Ad Lib JukeBox.

Quite a number of pages ago, the question was asked whether we could use a custom ROM with Mega-Em, in particular to provide UltraMID functionality. So far, I can only give a tentative maybe (it's better than "no", isn't it? 🤣 ). I have only been able to get semi-sane playback with Mega-Em so far. To begin with, Mega-Em does not appear to require or make use of the SBOS chunk in ROM. When loading, it appears to scan the ROM and pick out the necessary instrument information. Playback sounds somewhat normal, but with a hint of the sort of sound you can still experience in shock__'s earliest recordings with the test ROMs of the time. My current working theory is that when it scans the ROM, it uses the addresses and other instrument parameters, but ignores the referenced DATA chunks that tell it which ROM bank actually contains the data. So, instruments that are actually in the first bank play mostly normally; those in other banks give that familiar sound. This seems to suggest that having a single-bank 4 MiB ROM would give the result being sought.

Actually testing that theory will take a while. I don't know of any 4 MiB, 5V flash ICs in either a SOP-44 or TSOP-48 package, which is what would be required to test that now. If anyone knows of such a part, please enlighten me; bonus points if it's reasonably priced. Failing that, we will likely have to wait for the single-board ROM daughterboard prototype on ARGUS, which I planned to start designing right after someone successfully tests the current carrier-board-plus-ROM-module design. So far, nobody has all of the pieces of that puzzle.

EDIT: I stand corrected; I should be able to stuff an 8-bit version of GSFULL4M, possibly even with SBOS chunk, into a single 2 MiB bank for testing. I will try that over the next few days.
EDIT 2: I already generated the ROM image, but the SBOS chunk wouldn't fit. I will program the module, test and report back when I can.

Reply 1626 of 3172, by Tiido

User metadata
Rank l33t
Rank
l33t

AM29F032D is a 32Mbit (8bit wide) and 5V, in TSOP40 and SOP44

T-04YBSC, a new YMF71x based sound card & Official VOGONS thread about it
Newly made 4MB 60ns 30pin SIMMs ~
mida sa loed ? nagunii aru ei saa 😜

Reply 1627 of 3172, by 640K!enough

User metadata
Rank Oldbie
Rank
Oldbie
Tiido wrote:

AM29F032D is a 32Mbit (8bit wide) and 5V, in TSOP40 and SOP44

I should have been more specific; we need a word-mode (16-bit) part that roughly matches the pin-out of the 29F800.

Reply 1628 of 3172, by shock__

User metadata
Rank Oldbie
Rank
Oldbie

You could always go with 2 8bit ROMs and split the image into high- and low-bytes before hand ... not that it's exactly intuitive (common practice on Atari ST and Amiga computers tho).
Also I suppose that's what the GUS PnP prototype ("defiant") did: https://pp.vk.me/c4153/u5039199/95209756/x_e6bd06c7.jpg

Current Project: new GUS PnP compatible soundcard

[Z?]

Reply 1630 of 3172, by d0pefish

User metadata
Rank Newbie
Rank
Newbie

Prototype #18 is alive, so I thought I'd post about my initial experience with it! 😀

The machine is the one in this thread, an Am5x86-based 486 on an ASUS GX4 motherboard.
It runs Windows 95 and a custom DOS configuration.

Soldering:

  • Assembly was straightforward, silkscreen is nice and clear.
  • Jumper settings diagrams on the card are excellent and very clear, I got the right settings first-time (at least for my RAM config - though I have no doubts about how to set up my IW78C21M1 chip when it arrives).
  • I noticed R41 and R616-R619 are supposed to be unpopulated but couldn't see any explanation why - is this just a temporary thing for the prototype that will go away in the next version?
  • The explanations in the schematics for (not) populating R620 made sense, and I've chosen not to use the -5V feature.
  • I thought I'd risk trying 6.3mm diameter (with 2.5mm lead spacing) capacitors as there was more variety available than 6.0mm in a low height, and I could then use one of my preferred brands (Nichicon or Panasonic). They went in just fine, but in the areas where there are a few in close proximity (eg. C717 etc), they were touching each other and needed some careful pushing to get them to sit flat. It'd be cool if the footprint could be widened to 6.3mm, maybe? 😀

rCuh1eYl.jpg

Extra assembly

  • I'm not sure what the intended bracket for the card should be, but a bracket borrowed from a VIBRA-16 (CT2800) I had lying around fits - sort-of. It was pretty tight, as the 3.5mm jacks rub against the rightmost parts of their cutouts, and the D-SUB also rubs against the left edge of its cutout.
  • The standoffs on the D-SUB work just fine to hold it in place.
  • Obviously there is a spare hole, and the extra mounting 'ear' near the top of the bracket cannot be attached to the card, but none of these cause any problems or get in the way of installation or anything. 😀
  • EDIT: I found a Pine PT-2633 (Crystal CS4614A based card) in my box of spares and the bracket fits better. There's still an additional hole, but there's no mounting "ear". I guess it would be a good idea to nail down a list of verified donor cards for brackets.

CT2800 bracket:
9dMmnZol.jpg

PT-2633 bracket:
8T3cMKSl.jpg
i7e9KZql.jpg

Usage/installation
I'm still waiting on my EEPROMs for MIDI, but the rest of the card seems to be fully functional.
I've successfully tested it with XTC-Play, Inertia Player, FastTracker II, and Turrican II so far - sounds excellent! 😁

This is my first Gravis Ultrasound card, and I'm using it alongside an AWE32, so I expected problems, but things are actually going very smoothly.
The instructions were clear and worked just fine.

To start with I removed my AWE32, Music Quest MIDI card and network card from the machine, added the ARGUS and ran PNPMAP.EXE, which worked just fine.
Then I installed the DOS drivers from GUS-pnp.rar.

My 16MB SIMM was successfully detected and tested by the Setup program, and it shows up in XTC-Play too.

I had to edit my AUTOEXEC.BAT/IW.INI to get it to co-exist with my AWE32 by disabling some of the unneeded functionality, but that's a configuration thing specific to my system. As a standalone card it was painless.

The last thing I've tried is to install the Windows 95 drivers, and so far it's working great, I am able to play MP3s on it in Winamp. Nice! 😀

Next steps

  • Enjoy testing lots of scene demos - very excited to do this as it's my first ever Gravis!
  • Test joystick functionality (I have a Gravis PC GamePad and an analog stick).
  • Install wavetable ROM and test internal MIDI functionality.
  • Test external MIDI functionality.
  • Test in a Pentium II machine.

Extra info
Here's a shared project/basket for ordering from Mouser. It contains everything you need for one card except DRAMs (I am using SIMM only) and EEPROM: https://www.mouser.com/ProjectManager/Project … ssID=78405ec88f.
I successfully built my card with this exact list of parts. You can add multiples of the project to your basket and adjust quantities to save money if you want (especially the resistors).
I didn't bother populating X3 or the 'magic smoke escape hatches' yet, so this basket excludes those.
As mentioned above the basket contains 6.3mm diameter capacitors, which fit fine in the 6.0mm footprints, but they are 'snug'.

Thankyou very much to shock__ for allowing me to help by building/testing this prototype, I'm really enjoying the card so far! 😁

Last edited by d0pefish on 2018-02-11, 21:14. Edited 3 times in total.

US1wUaR.pngg
💾 Download | 📚 Documentation | Support

Reply 1631 of 3172, by 640K!enough

User metadata
Rank Oldbie
Rank
Oldbie

For now, the least expensive and most convenient approach is to program and test the 2 MiB ROM image that I have already generated. I think I'll have time for that later tonight. Based on those results, we'll be able to decide how to proceed.

I've never seen that prototype before, but it looks like an interesting design. Doing a high/low split or even selecting one of two 2 MiB ICs based on RA21 could be made to work (bonus: I already have the chips), but would require more "glue" to generate the select signals. I'd rather leave that for later.

Phreeze wrote:

the german forum guy said that it works with less than 64MB of RAM. Who's using that much anyway in a gravis system 😉 how much do you use ?

I only have one machine with ISA slots left, and let's just say it has a few times the 64 MiB limit. It's useful for this too, but the machine isn't strictly dedicated to DOS/InterWave tasks.

Reply 1632 of 3172, by 640K!enough

User metadata
Rank Oldbie
Rank
Oldbie

With initial testing complete, I can say that Mega-Em worked well enough with the custom 2 MiB ROM to validate the theory. The sound produced via General MIDI emulation is quite acceptable, even with a custom ROM, as long as the instrument set used is fully contained within the first ROM bank. That seems to place a strict 4 MiB limit on banks that can be used with Mega-Em.

There seem to be more limitations inherent in the design of Mega-Em. For instance, it only uses the standard drum kit, regardless of what is present in the ROM. The percussion also seems to sound a little odd compared to software with native support. These symptoms are present even when the standard production ROM is in place, so I am inclined to believe that it is related to a bug in, or shortcoming of, Mega-Em.

I haven't yet tried using it with software requiring UltraMID functionality, since I don't know which software makes use of it; I will have to check the lists. If I have any such software, I will try that during my next testing session.

Reply 1633 of 3172, by Rawit

User metadata
Rank Oldbie
Rank
Oldbie
640K!enough wrote:

Quite a number of pages ago, the question was asked whether we could use a custom ROM with Mega-Em, in particular to provide UltraMID functionality.

Mega-Em 3.06 loads samples from RAM instead of ROM on a PnP if I'm not mistaken. Don't know if that is helpful with understanding Mega-Em's behaviour.

YouTube

Reply 1634 of 3172, by mateusz.viste

User metadata
Rank Member
Rank
Member

Hi all, I'm wondering about adding GUS support to DOSMid. I understand that the GUS doesn't present a MPU interface and needs to be programmed directly (unless used with the MEGA-EM thing which most people are complaining about). Any chance someone here would have some documentation about how the GUS is working / how it expects to be handled MIDI-wise?

http://mateusz.viste.fr | gopher://gopher.viste.fr

Reply 1635 of 3172, by keropi

User metadata
Rank l33t++
Rank
l33t++

Is it possible to test an Argus without any RAM or ROM installed with some tracker playing mods? Or do I need at least some ram installed?
I will finish my card tomorrow and although I have programmed 29F800s I want to wait for the original part from UT.
The simm socket is well out of the way but if I can avoid soldering it until the IW78C21M1 arrives then I'd like to wait 😀

🎵 🎧 PCMIDI MPU , OrpheusII , Action Rewind , Megacard and 🎶GoldLib soundcard website

Reply 1636 of 3172, by shock__

User metadata
Rank Oldbie
Rank
Oldbie

I don't think so.
The soundblaster emulation should work without any ram (as seen on various IW cards without RAM) ... but then again megaem/iwsbos requires the rom to load.

Current Project: new GUS PnP compatible soundcard

[Z?]

Reply 1637 of 3172, by shock__

User metadata
Rank Oldbie
Rank
Oldbie
mateusz.viste wrote:

Hi all, I'm wondering about adding GUS support to DOSMid. I understand that the GUS doesn't present a MPU interface and needs to be programmed directly (unless used with the MEGA-EM thing which most people are complaining about). Any chance someone here would have some documentation about how the GUS is working / how it expects to be handled MIDI-wise?

I guess your best bet would be the "InterWave Programmer's Guide" from the SDK - https://files.scene.org/view/mirrors/hornet/c … cs/iw_sdk20.zip

Current Project: new GUS PnP compatible soundcard

[Z?]

Reply 1638 of 3172, by mateusz.viste

User metadata
Rank Member
Rank
Member
shock__ wrote:

I guess your best bet would be the "InterWave Programmer's Guide" from the SDK - https://files.scene.org/view/mirrors/hornet/c … cs/iw_sdk20.zip

There is a wealth of information inside, thanks for the link! I will see if I can easily add support to DOSMid. Don't have any GUS hardware to test, but I noticed DOSBox got some GUS emulation, so that should be enough I guess. Will post here when/if I get this done, so perhaps one of the GUS-clone owners could see if it works on this modern clone.

http://mateusz.viste.fr | gopher://gopher.viste.fr

Reply 1639 of 3172, by cyclone3d

User metadata
Rank l33t++
Rank
l33t++

Getting ready to order parts, but will have to find another source besides mouser for the:
81-GRM219R61H225KE5D capacitors
660-RK73H2ATTD3900F resistors

as they are backordered - The capacitors until July and the resistors until May.

Or maybe I can find good substitutes on Mouser.

As for the opamps, is there a reason I have to use those specific ones, or are those just the cheapest on Mouser that will work?
What about socketed opamps so we could change them out if we want to?

Yamaha modified setupds and drivers
Yamaha XG repository
YMF7x4 Guide
Aopen AW744L II SB-LINK