A box? T-Shirts? This project is so awesome.

you can do it 😀

shock__ wrote:

To my knowledge the drivers in the SDK are outdated.
Since the target for the card is to remain compatible with the formerly distributed GUSPnP drivers there's no need for a custom built driver from the SDK ... having someone figure out how exactly the ROMMaker tool works would be awesome tho.

I haven't disappeared; I have still been going over the code, as free time allows. I wasn't planning on an updated driver, so much as being able to build the DOS tools, with any necessary modifications. That includes the ROMMaker.

I haven't gone over the ROMMaker code in as much detail as I would like, yet. However, I think I have enough information to put some test code together to shed some additional light on their use of "layers". As it currently affects us, this seems to be related only to the SBOS information and instrument maps that get embedded in the ROM. If my tests prove successful, I should be able to produce a down-sampled ROM file based on the 4 MiB FFF. If converting it to 8-bit produces something that will fit in the current 1MiB flash chip, is there someone with one of shock__'s prototype boards who would be willing to test it?

I suspect the resulting file will be a little too big; maybe closer to 2 MiB. I'll be back with an update as soon as I have time to do a little testing.

vittek wrote:

Just wanted to say congrats to everyone involved, shock__ especially. I cannot imagine the amount of work involved in something like this. Obviously a labor of love. I read through every page, all 57 of 'em. Just guessing an average of 20 posts per page that's over 1140 posts. I read through them in one day at the risk of getting in trouble at work hahaha. So awesome watching the progress from 2015 all the way till now, watching the board evolve from a longer one to a shorter one, love the logo and color choice. The audio recording was so cool I couldn't wait to get home to listen. My favorite was the 3d model video with both sides of the card it really helps visualize what going on in a layered PCB. Just goes to show what a talented person with a vision and some help can do. Very unique work of art. I had moved this past winter to a new town and just started a new job so I had no idea this was going on. I look for GUSes for sale from time to time as I never saw one growing up, it was just this legendary card used by the demoscene. I wrote shock__ a really passionate PM but I realize now, after the fact, I missed the deadline for both rounds of funding 😵 I definitely would have donated - this thread just didn't have much visibility or eluded me until yesterday. I totally respect that he cant keep accepting after the deadline, I just HAD to ask. Anyway, a major major accomplishment. I was thinking the logo is so awesome I am in Seattle and there's tons of printing presses here it would be cool to do T-Shirts for the release... If the group were to do kits it would be something really neat to have t shirts too, with the Logo on the front and the special thanks on the back... anyone interested?!

Definitely.
A nice t-shirt would be super cool.

640K!enough wrote:

shock__ wrote:

If converting it to 8-bit produces something that will fit in the current 1MiB flash chip, is there someone with one of shock__'s prototype boards who would be willing to test it?

I would be (I haven't handed out any prototypes and don't exactly plan to) 😀 I still have a few spare chips and don't mind reworking the prototype to fit another ROM. On the other hand, everyone with a GUS PnP should be able to do that (feel free to contact me if you need mod instructions - don't wanna post them publically and have people ruin their cards).
Props for keeping it up 😀

I got a little bit more work done with the software. The first thing I did was write a simple tool that can produce a valid sboslyrs.ini file given a ROM configuration file (as used by ROMMaker). It is important to notice that I said "valid"; the results won't necessarily sound good on the first try. With that file, a set of ROM files can be produced via ROMMaker.

I created a set of ROM files based on the 4 MiB bank, down-sampled to 8-bit. Unfortunately, the result was three (3) ROM files; two that were mostly a full 1 MiB, and a third with a little less than 20 KiB of remaining data. It could be possible to add a few more 1 MiB chips to the board for testing, but can it be done neatly, and is it an idea worth considering? I don't have access to an InterWave board at all (not even a pristine one that I don't want to mangle with a soldering iron), so I am a little limited in what I can do myself, unfortunately.

By my count, the full 4 MiB set contains 44 instruments with more than one layer (I counted by looking through the list, so that may not be exact). I don't think any instrument has more than three (3) layers, so an sboslyrs file with any numbers higher than 2 (layers are numbered from 0) in the second column is probably suspect.

There was some discussion of a 2 MiB "Pro Patches Lite" set. Is that already in the form of an FFF/DAT bank, or a set of traditional GUS .PAT files that we first have to turn into an FFF/DAT bank? Would anyone care to provide a link? I thought those sets were typically larger than 2 MiB. Also, if the .DAT is exactly 2 MiB, we would likely still end up with two (2) ROM files, if we are targeting 1 MiB flash chips, even after conversion to 8-bit.

Does any of this get us any further along than we were before?

As far as I understood, there is hardware possibility to put a 4Mb ROM chip instead of the 1Mb one without any major modifications into the design.
By far more problematic is the driver itself as it has to be somewhat modified in order to take the 4Mb ROM image.
The ROMMAKER that was compiled earlier (and posted here) actually produced one file (ready to flash, I suppose), I'm attaching both the tool and the resulting file. However nobody actually tested how it will behave when flashed.
If I had another InterWave card to donate, I would eagerly send it over to you for testing purposes. If anyone here could do that, I would be ready to compensate its cost partly - any volunteers?

hard1k wrote:

As far as I understood, there is hardware possibility to put a 4Mb ROM chip instead of the 1Mb one without any major modifications into the design.
By far more problematic is the driver itself as it has to be somewhat modified in order to take the 4Mb ROM image.

Yes, according to the Programmer's Guide, the InterWave IC can make direct use of ROM chips in capacities of 256 KiB, 512 KiB, 1 MiB, 2 MiB and 4MiB. Furthermore, the total ROM can be made up of 0, 1, 2, 3 or 4 banks. I'm not quite sure why, but they say that the ROMs must all be the same size. From that, you can calculate the possible ROM capacities. I would have expected the last bank to be able to have a lower-capacity chip to save a few cents, but obviously haven't tried.

I think shock__'s concern with higher-capacity ROMs is that they are almost universally in fine-pitch packages. Since, by my understanding, this is supposed to be an assemble-it-yourself project, the number of people who could successfully solder such chips would be significantly lower.

For the most part, I think that the modifications necessary for different ROM sizes should be relatively minimal, from a software standpoint.

hard1k wrote:

The ROMMAKER that was compiled earlier (and posted here) actually produced one file (ready to flash, I suppose), I'm attaching both the tool and the resulting file. However nobody actually tested how it will behave when flashed.

I was aware of the results obtained previously, but I suspect that the sboslyrs file used to generate those ROM files had a few problems. If my expectations are correct, it may sound fine under Windows, and maybe even in DOS with native InterWave or UltraSound support. The problems will likely arise when trying to use SBOS for MPU-401 emulation (General MIDI and MT-32 emulation). Since the instruments in the sines bank are all single-layer, AdLib (FM) emulation may partially work, as well, except where other MIDI instruments are selected.

hard1k wrote:

If I had another InterWave card to donate, I would eagerly send it over to you for testing purposes. If anyone here could do that, I would be ready to compensate its cost partly - any volunteers?

Given that some of these cards are selling above their original, brand-new prices these days, I don't expect anyone will want to part with theirs. We'll just have to wait for capable volunteers for testing, for the time being. The prices are much too high for my budget, at the moment.

If anyone has the time or inclination to test, I have attached a ROM file, along with the ROMMaker ROM configuration file and source FFF/DAT banks. The banks are exactly the 2 MiB files generated from the Pro Patches Lite (PPLT) 1.61 set (using the old Gravis GIPC tool). The ROM file contains the 8-bit version of that set, plus the sines bank.

It should be noted that the 2 MiB PPLT set excludes quite a number of instruments and all but the standard GM drum bank. I would be interested to hear the playback results, if this set works at all.

It may be necessary to generate a new SBOS .IWL file via bldlib.exe to get sane SBOS results.

EDIT One other comment: There were some reports of bugs in GIPC causing some instruments to play without reverb/chorus effects. If the results are good enough to be worth further consideration, we should be able to fix the FFF file and generate a new, corrected ROM.

EDIT 2: Removed the attachment and will post an updated ROM file later.

Just for some context, have a look at the typical footprint of a more modern flash chip. It's not impossible to solder by hand, but it's not the easiest thing to do for beginners, either.

Personally, I would prefer the option to have two or even three such footprints on the board, to allow for up to 12 MiB of flash. This would allow the inclusion of the full 4 MiB set, or the entire Pro Patches Lite set, including all drum banks, without having to compromise on sound quality.

A more modern chip might also make in-circuit flashing more feasible, though I'd have to look into that further to see what options are available, and whether it can still be done with the current AMD flash chip.

640K!enough wrote:

If anyone has the time or inclination to test, I have attached a ROM file, along with the ROMMaker ROM configuration file and so […]
Show full quote

If anyone has the time or inclination to test, I have attached a ROM file, along with the ROMMaker ROM configuration file and source FFF/DAT banks. The banks are exactly the 2 MiB files generated from the Pro Patches Lite (PPLT) 1.61 set (using the old Gravis GIPC tool). The ROM file contains the 8-bit version of that set, plus the sines bank.

It should be noted that the 2 MiB PPLT set excludes quite a number of instruments and all but the standard GM drum bank. I would be interested to hear the playback results, if this set works at all.

It may be necessary to generate a new SBOS .IWL file via bldlib.exe to get sane SBOS results.

EDIT One other comment: There were some reports of bugs in GIPC causing some instruments to play without reverb/chorus effects. If the results are good enough to be worth further consideration, we should be able to fix the FFF file and generate a new, corrected ROM.

I'll give that .rom file a spin later on this week (probably by tomorrow).

Just reworked Prototype #2
The good news: It works with Duke3D (which bugs out when it can't find a ROM chip), ROTT and Descent 2 (don't have much more MIDI games installed on my test machine currently)
The bad news: it sounds exactly the same as the default.fff set, the name gets detected wrong by iwinit as "2 series_name" (contrary to AMDGM_1_1_ [or very similar]) and it breaks the DMX_init in Doom2 (which then hangs there in limbo)

EDIT: Doom2 seems to have a problem with my current setup.
EDIT2: Doom2 works again ... turns out it was due to a recently done BIOS update on my machine.
EDIT3: DOS games sound just fine when using Ultrasound for Music/MIDI ... however, MegaEm sounds broken (not that it ever sounded even remotely acceptable) and SBOS bugs out because it can't find it's ROM data. Installing Windows 3.11 now because setting the default vendor in iw.ini appears to have no change to any of my test programs (neither does it on the ARGUS with the IW78C21M1 chip)

At least that tells us that we can produce usable ROMs. Now that we're sure of that, we can put some effort into tweaking the results.

I'm not quite sure where the 2 came from, but I intentionally used obvious values in the ROM configuration file to see how they were treated. If you wanted to see what happens, you could simply change the "series_name" entry in the IWSBOS.INI file I included, and re-generate the ROM file. Since the FFF and DAT files were generated from classic GUS .PAT files, there are no multi-layer instruments, and any sboslyrs.ini file that can be parsed should produce usable results.

I just double-checked, and the ROM file does have an SBOS chunk (the header begins at byte index 18664). The instrument maps and other data should be in place; it's likely just an incorrect reference somewhere that is causing SBOS to fail. Did you try generating a new set of .IWL files for SBOS? Did you use your compiled SBOS, or the original version that shipped with the old cards?

I am wondering if MegaEm "sounds broken" because of a problem with the ROM, or because so many instruments are missing from the set.

I used the version of SBOS that came with the official GUSPnP drivers.
Just redumped the ROM I soldered in place, that one checks out nicely.
I really wonder where the 2 comes from when detecting the ROM via iwinit -v9 ... did it maybe get compiled as a 2MB version or as 2 banks of 1MB?
Also, when using the Windows 3.11 drivers I'm getting "can't find directory for patch file" ("couldn't open patch file" when attempting to open the AMDGM_1_1_ or AMDGS_4_2_ sets [of which the later doesn't exist ... but I think it shows that it's kinda filename sensitive for the moment]) ... 4MB RAM set works fine.

EDIT: Apparently the drivers expect the first 3 characters of a ROM bank to be named "ROM" ... I'll hex edit the file tomorrow, reflash and check again. At least that's what I figured out via experimenting with iw.ini.
EDIT2: Calling the ROMSet via ROMseries_new at least givess me a "couldn't open patch file"

This is somewhat peculiar. All of the important files were included in the archive I uploaded. IWSBOS.INI is the ROM configuration file I used, and rom_size is set to 1048576. There were no splits; just a single ROM file generated. If you have a hex editor handy, can you post just the first 172 bytes of the original ROM?

I am not perfectly familiar with the Windows configuration files, as the last time I had any exposure to a real UltraSound card, the InterWave didn't even exist yet. I did notice certain references in the files in the SDK. Some of the files refer to %PATCHES%, expecting an environment variable to be set. The AMD* definitions seem like they should refer to a ROM set, however, so I'm not sure why it would look for files. Do you get the same behaviour with a real Gravis card?

Just some random findings going over the source again ...
also there used to be a switch that could be used with ROMMAKER to give a slightly more verbose output ... dunno if that was a command line parameter or a definition in the sourcecode.
First 172bytes of the original ROM checked against the one 640K!enough posted checks out correctly to me (that's basically just header stuff with a fixed length until 0x1FE)

This is hardcoded in ROMMAKER.C ... doesn't seem exactly correct to me.

1unsigned rom_size = 2;		/* size of rom chips in megabytes */

Also found this in PATCH.C

1#ifdef ROM_DEBUG
2    char diskbuff[1024];
3    int fp;
4    unsigned bytes_in;
5    unsigned long addr;
6
7    if (_dos_open("gm1_1_0.rom", O_RDONLY, &fp) != 0) {
8	printf("Can't open file to copy to DRAM\n");
9	return(IWU_PATCH_CANTOPEN);
10    }
11    addr = 8UL * 1024UL * 1024UL;
12    while (_dos_read(fp, diskbuff, 1024, &bytes_in) == 0 && bytes_in) {
13	iw_poke_block(diskbuff,addr,bytes_in,0);
14	addr += bytes_in;
15    }
16    _dos_close(fp);
17#endif

But to make things clear once again:
Long story short ... I don't see a point in adding support for additional ROM sizes as long as it's absolutely uncertain how/whether an alternative ROM file can be built and what changes would have to be made to the software. To put it perfectly clear I consider that request as useless as adding a second InterWave onto the board, as the driver supports more than 1 card in a system - allowing up to 64 channels of sound (which is even supported in cubic player I think) ... it's just that no one ever used that it seems (just like ALL ROMs I found on InterWave cards so far use exactly the same binary, info on the internet of cards with 4MB ROM turned out to be incorrect so far).
Currently the main priority is to remain compatible with old software. If anyone needs hardware to test his/her efforts, I have 2-3 InterWave cards I can split paths with if that helps (ARGUS does virtually nothing different than them except adding support for more RAM).

There is a certain amount of old cruft in the code, and some other general sloppiness. The global variable rom_size is set to 2 initially, then it even looks like the size can be set using a command-line argument. The only problem is that it is never used; the line that used to refer to it in WPATCH.C is commented, and the value is instead read, directly from the configuration file, into rh.rom_size, then copied into rom_bytes when they calculate the splits.

The ROM_DEBUG section appears to be used to copy the resulting file into on-board RAM at a specific location to allow debugging without having to flash the actual chip. How the rest of that works is not yet clear. It may have something to do with the FAKE_ROM option you mentioned previously, for SBOS use.

You had me doubting the values I used to generate the ROM, so I double-checked in more detail. The ROM size is encoded in the header (4 bytes, starting at byte 40), and the value is correct for a 1 MiB ROM. However, I did make a mistake with the series number, which should have been 0. I don't know if that has anything to do with the 2 that appeared or the other error messages, but will correct the configuration file.

Unless they were extra sloppy, you can't just hex-edit the file. There is a checksum at the end of the header (and likely in other places) that should be checked, and you would expect the software to complain if the value is wrong. I will fix the file and upload again shortly.

EDIT: Added the ROM_DEBUG section, and added the files. There are two copies of the ROM, one of which uses AMDGM_1_1_ for the series name. I also included replacement SBOS .IWL files.

I'll give that another spin

Also: elbrunzy had asked me to document the process of swapping ROMs on the prototype, which I did, so here are a few pictures for you (overall time needed was 20 minutes )
http://i.imgur.com/wVWDa3f.jpg

Steps from top to bottom:
deattach botch wire
unsolder chip + cleanup the pads using solderwick
apply solderpaste
set chip (note top left pin is lifted)
hot air away!
reattach botch wire, ram and add a nice sticker

Just reworked the Prototype with PPLT0.ROM
Good news: Neither Windows nor SBOS bug out any longer, appears like it works in that regard. IWINIT also detects it as "Found ROM Chip: 1 PPLT_1_1_" which seems more correct than previously.
Bad news: Sounds quite broken ... this is canyon.mid played back under windows https://drive.google.com/open?id=0B9WAZV_Pqo7 … cnMzNFBUZzg0MjA ... General MIDI via SBOS/MegaEM sounds similarly wrong.

Seems like we're getting there 😀

Using the rebuilt IWL files (and setting the the location to RAM in iw.ini) I'm getting quite decent results in DOS with SBOS actually
However ... it reports that the library version does not match the drivers. It should also be noted that the .iwl files are not required with the original ROM. Windows remains unaffected.

Recording utilizing the .iwl files (Duke3D Theme and Doom Level2 sound alright to me, rest has some stuff that sounds severely off, but not exactly broken anymore):
https://drive.google.com/open?id=0B9WAZV_Pqo7 … YUxNRUhkYTBTWms