so are you talking about Interwaves GF1 vs a real GF1? Interwaves oscillator cant clock to the same hz as GF1 for legacy playback per channel count... as you said, speed issues..

BloodyCactus wrote:

so are you talking about Interwaves GF1 vs a real GF1? Interwaves oscillator cant clock to the same hz as GF1 for legacy playback per channel count... as you said, speed issues..

As far as I'm aware, this applies only to the InterWave's GF1-compatibility mode, when compared to actual GF1 output. Part of this was already mentioned in the linked thread. The goal here is to document the extent of the differences and find a way to compensate for them. I don't expect it to be that difficult, but it's something I feel should be thoroughly documented, even if the InterWave was discontinued over twenty years ago.

640K!enough wrote:

I suspect that the source of the problems is the slight differences in timing between the two chips, resulting in a playback rate (and therefore audible pitch) that is slightly different on the InterWave. That is to say that the same software will produce different sound when running on a system with an InterWave card, than if the very same system were to have a GF1-based card installed.

This is generally not true for a voice count 14 or less. The main loop of the IW synth work exactly the same as the GF1. It takes two successive samples from memory based on the voice position count, optionally performs a weighted average of them based on the fractional position value (and corresponding two's complement), applies attenuation sources from volume and panning positions, and accumulates across all active voices (active, not 32). The FSM takes a maximum number of cycles per voice based on worst case state transitions and DRAM wait states. Multiply that by the active voice count. Then take the result and divide it into the system clock frequency and you have your effective max sample generation rate. IW just has a faster system clock and can thus keep up with all 32 voices 44100 times a second.

On the IW, there may be slight differences in the fixed point step progression (speed) for voice counts greater than 14 for software that is not IW aware. That is, the IW has to compensate for the compensation programs do to account for the voice mixing frequency for SAVI > 14 on the GF1. When you write to the fstep register on IW with SAVI > 14, the logic performs a scaling of that factor based on the original GUS frequency tables so that at a IW progression of 44.1 KHz, the sample pacing is approximately correct. That calculation has rounding error and could account for slight audible differences. It's essentially whatever value the program wrote for FSTEP * 14 / SAVI = the new effective FSTEP while the original value is returned on read-back as written.

Additional artifacting may also occur due to the fact the GF1 is pushing samples at a true 19293 HZ to the DAC at SAVI=31 while the IW is pushing samples at a true 44100 HZ while adding an adjusted fixed-point sample increment (FSTEP) that is compensated for by the difference in frequency. EG. adding a smaller increment at a faster rate at insufficient resolution causing rounding errors to compound over time.

640K!enough wrote:

My current belief is that most of these problems are related exclusively to the InterWave's legacy GUS compatibility mode.

It's related to the fstep compensation outlined above. There are two parts to the GF1 and IW. What I like to call the 'core' and the 'synth'. The core is where the register file is maintained - including the dual port register RAM to the synth, things like Adlib timers, PIO and DMA DRAM access (LMC - or Local Memory Controller), and the SB/Adlib/MPU401 emulation hooks. The 'core' of the IW is a fairly pure superset with a compatibility mode for extended and dual function bits that is on be default after reset.

The synth of the IW is the same synth as the GF1 just clocked faster and with a few additional voice processing features (mostly the LFOs) outlined below. Both follow a simple mixing finite state machine to generate samples at a rate determined by the SAVI and system clock rate accessing local memory through a second higher priority port.

If you want a horrifically detailed dive in the inner workings of the IW, look-up US Patent # 6,058,066. Some yahoo at AMD decided to file all the gory design details as a patent. Lucky for us.

640K!enough wrote:

if you're aware of any of these differences, please share them in as much detail as possible.

From my understanding the IW generally added the following enhancements over the GF1:

1. Ability to address up to 24 bits of RAM or Flash (16 MB ea.) vs 20 bits for the GF1 (1 MB) of RAM only.
2. Additional DMA on-the-fly transforms such as 16-bit signed conversion and auto-interleaving
3. An enhanced LMC port which allows 16-bit PIO access with optional auto-increment
4. Additional mappable general purpose registers with interrupt triggers to better facilitate Adlib, Sound Blaster, and MPU-401 emulation
5. Full 44.1 KHz @ 32 voices - but this wasn't a functional change; only a qualitative one.
6. Built-in direct codec to replace the Crystal add-on daughter board for the GUS. Built into the GUS MAX as well. Eventually adopted as the Windows Sound System standard with some later port mapping adjustments.
7. Additional effect channel per voice
8. Volume and frequency LFOs per voice
9. Ability to play stereo samples per voice (LR offset regs)
10. More comprehensive mixer (later ICS)
11. ISA Plug-n-Play support (a curse - not a feature!)

Though as I've explained on VCForums, I don't believe any software made use of any of these features aside from the emulation and demo apps that shipped with the PnP cards.

I plan on demoing my IW Verilog core next month at VCF-MW. Look for videos of my talk to follow as well as some announcements later in the year on possible Kickstarter plans.

640K!enough wrote:

I have been working on a simple piece of DOS software to explore some of these issues. Unfortunately for me, this is where I reach a bit of an impasse. In order to complete this experiment and document the results properly, I would need an InterWave-based card (I have a couple of those), a GF1-based card (which I don't have) and an oscilloscope (which I also don't have). So, is there anyone who is sufficiently interested in this, and who has at least one type of GUS-like card and an oscilloscope, to be willing to collaborate briefly?

I would be happy to do any testing you want. I have at least 3 variations of IW cards, nearly all major versions of GUS (about 10 cards), and have built my own core using a MachXO2 at the moment while moving to an ECP5 next month. I do have lots of DSP past the IW core, but I can zero or by-pass most of it. The output noise floor is pretty clean as well even before any analog tuning (next ECP5 version).

I plan on doing some of the comparisons myself as I mature the code before next month. However other paying work has higher interrupt priority.

Though as I've explained on VCForums, I don't believe any software made use of any of these features aside from the emulation and demo apps that shipped with the PnP cards.

Cubic Player claimed to have support for 44.1KHz mixing of 32 channels and more than 1 MB of RAM .

See https://www.cubic.org/player/geocities/mixer.html (SSL certificate is expired).
or https://web.archive.org/web/20170720220719/ht … ties/mixer.html

darry wrote:

Cubic Player claimed to have support for 44.1KHz mixing of 32 channels and more than 1 MB of RAM .

As SFK pointed out, it would be an interesting test to compare a reference wave form to GF1, IW with GUS compatibility flag and without and all three with a 14 vs 32 voice count. The IW always outputs 44.1. Turning off the GUS compatibility flags shouldn't affect output quality much as it's still incrementing the position a smaller amount at a faster rate. Accumulated rounding error still vastly out-weighs the initial rounding error on the desired FSTEP.

I was more interested in the other advanced features like the freq/vol LFOs. A mod player could, theoretically, use them for vibrato and tremolo effects rather than actively adjusting the FSTEP and VSTEP every song 'tick'. I'm not aware of any players that did.

Using the extra RAM would be interesting if a player used a non-linear/polynomial resampling method to promote the samples to a higher rate before uploading. Should sound better than stock. Curious if CP did this - but I don't recall seeing it last time I took a look at their drivers over the years. But I might have been looking at vanilla GUS.

eeguru wrote:

Though as I've explained on VCForums, I don't believe any software made use of any of these features aside from the emulation and demo apps that shipped with the PnP cards.

As mentioned, Cubic Player can use the Interwave in Interwave and GF1 mode. Also the following software has Interwave support:
- XTC Player;
- Impulse Tracker (two drivers);
- Midas (demoscene audio driver);
- Miles Audio (might be ROM only);
- LucasArts iMuse (might be ROM only);

They also support GF1, so useful for comparison. FastTracker 2.09 has some Interwave support it seems but with issues (don't have an Interwave, so haven't tried). On Pouet I've read loops in Fasttracker don't play back correctly on an Interwave with complex songs. No info on the used version of FastTracker or mode used. FastTracker is speed sensitive in my experience; a 60hz display will cause it to slow down and cause gaps between patterns on a GF1. Not so in SB16 mode.

It isn't finished yet, but I thought I would share an initial test version of the software. It is relatively simple; it does a GUS reset, then generates and uploads a simple wave that is played continuously. It starts off with 14 active voices, so 44100 Hz sampling on all cards. To start with, it would be interesting to take measurements on both a GF1-based card and an InterWave-based card in that state, to see that we're getting the same result in both cases, with a description of what is being played.

The software also allows you to increase or decrease the number of active voices by pressing +/-. In its initial state, this uses the approximate sample rates provided by Gravis/Forte for the GF1, and adjusts the frequency control register as the number of active voices changes. It is inaudible (to me, at least), but there may be a momentary change in pitch between the setting of the number of active voices and the adjustment of the frequency control register. Because the numbers used are approximate, there is likely to still be some measurable shift in frequency when the number of active voices changes.

One can also disable/re-enable adjustment of the frequency control register by pressing f. This way, we can observe (and potentially measure) the differences between the various generations of cards as the pitch/frequency changes with number of active voices.

The software can be run by by specifying the GUS base I/O address (hexadecimal) as a command-line option. It doesn't do any detection or verification at this point, and simply trusts that there is a GUS-like card with at least 256 KiB of DRAM at the address given.

EDIT: Attachment deleted. A newer version, with support for native/"enhanced" mode on InterWave, will follow in the coming days.

As an additional experiment, I added a second sample rate table containing exact values for the various GF1 sample rates, rather than the approximate values that are commonly used. On my cheap speakers, there was absolutely no audible difference, despite the new values resulting in a fractional change in the frequency control register. It will be interesting to see if there is any measurable difference, or if the change is more accurately reflected on a GF1 card.

EDIT: I have repeatedly read about problems with "long loops" and tracker music that plays back incorrectly, but I haven't seen too many specific examples. I think one example I saw mentioned was Innuendo, which uses Karva.S3M, if I'm not mistaken. Is that among them? Are there others we can look at? Also, what do we mean when we say "long loops"; a large sample with loop points near the beginning/end, a sample that is left to loop for an extended period, or something else entirely?

In these discussions, for the sake of clarity, we should make a point of noting when particular functionality or behaviour applies to enhanced mode or compatibility mode. For instance, we have been referring to SAVI in a number of places, but SAVI only applies to compatibility mode. Changing SAVI in enhanced mode has no effect whatsoever, on audible or internal behaviour. I can set SAVI to DFh (32 voices) and still not get any sound out of the synthesiser module (the documentation says so, and I've tried it), and it will still not prevent the processing of any active voices (even "stopped" ones), and their data being summed into the output DACs.

eeguru wrote:

IW just has a faster system clock and can thus keep up with all 32 voices 44100 times a second.

Again, it may (selectively?) use the higher-rate crystal in compatibility mode, but the synthesiser module only needs the 16.9344 MHz crystal for enhanced-mode functionality at 32 voices/44.1 kHz, so not faster than the GF1's 19.7568 MHz part. The documentation specifically mentions that the additional crystal is only necessary for GUS compatibility and 48 kHz and similar sample rates on the CODEC module.

eeguru wrote:

Additional artifacting may also occur due to the fact the GF1 is pushing samples at a true 19293 HZ to the DAC at SAVI=31 while the IW is pushing samples at a true 44100 HZ

Are you sure about this? The documentation seems to imply that, in compatibility mode, the InterWave synthesiser does, in fact, produce output at rates other than 44.1 kHz. This is the reason that particular care must be taken in trying to use the serial transfer and/or external effect processing features. There are ways to verify this, given a logic analyser, but I am not so fortunate as to own one.

640K!enough wrote:

Are you sure about this? The documentation seems to imply that, in compatibility mode, the InterWave synthesiser does, in fact, produce output at rates other than 44.1 kHz. This is the reason that particular care must be taken in trying to use the serial transfer and/or external effect processing features. There are ways to verify this, given a logic analyser, but I am not so fortunate as to own one.

Not 100%. I'm slammed with RL work atm and haven't had time to get back to GUS work. I'm hoping to do that next week. It would be nice to get whatever your test program is doing in source form so I can drop it into a CLI I already have. Black-boxes usually frustrate me.

eeguru wrote:

It would be nice to get whatever your test program is doing in source form so I can drop it into a CLI I already have. Black-boxes usually frustrate me.

I was thinking about releasing the source code eventually, but not before I have time to add a few more options and make it a little neater. I also want to confirm that I'm actually getting the expected output from the card.

I'm not sure what you would plan to do with the code at this point. If you meant to build it for another environment, be aware that there are some calls that were specifically Borland/DOS-only, and it will not build anywhere else without modification.

I was thinking about the whole effort yesterday, and have a suspicion that this isn't quite the right approach. It is indeed useful for some things, but potentially not for exposing the differences between card generations. I'm not sure now if I want to partially re-work the code to accommodate the new ideas, produce a separate utility for the other cases, or some combination of both.

The version with InterWave detection/support is finally workable. Press ? for a help message explaining the other options. I still want to refine this a little more, and maybe add options for additional testing possibilities, but I think this is a reasonable first stab at it.

I managed to borrow a low-cost USB oscilloscope for a little while, and finally managed to get a few basic measurements. My main worry was that, despite appearing to put out some kind of tone, I had bungled something in the software that caused the output to be completely different from what I had intended. On an InterWave-based card, at least, that is not the case. I got a fairly perfect 150 Hz sine wave, which is exactly what I expected:

The result is the same in the InterWave's native/enhanced mode. As expected, I get a consistent ~150 Hz sine wave, whether I have 1 or 32 active voices. In GF1-compatibility mode, things get a little more interesting. When the frequency control register isn't updated as the voice count increases above 14, the frequency of the output starts to drop; this is also mostly expected. Whether I use the official Gravis/Forte sample rate table (all integer values) or the table I calculated based on exact GF1 timings, the output is within a few tenths of 1 Hz, though the frequency seems slightly more stable with the calculated table (might just be observer bias, as there isn't much of a difference in the resulting frequency control register values). When updating of the frequency control register is enabled, I get a fairly perfect 150 Hz wave only at 14 voices (compatibility mode). When SAVI is set to values other than CDh (14 voices), the frequency tends to gradually drop below 150 Hz.

I still don't think this tells the whole story yet. Firstly, it would be helpful to hear from someone with measurements from a GF1-based card, so that we can put together a table of frequency values versus number of active voices for comparison. Furthermore, I think things will break in a more obvious way with a wave that isn't so specifically chosen to have an even number of 16-bit samples per cycle at 44100 Hz. I will try that when time allows.

I also plan on taking a few of the same measurements from the Rev. 2 ARGUS prototype, just to see if there are any significant differences, and so that I can take a few additional measurements. I think it will be interesting to see if we can compensate for the difference between a real GF1 and the InterWave's GF1-compatibility mode just by revising the sample rate table, or whether there is some other inherent difference that makes getting the same output from the two chips almost impossible.

EDIT: Further investigation confirms that the InterWave does indeed operate at sample rates other than 44100 Hz in GF1-compatibility mode. More information will be shared when I have time to run the numbers.

EDIT 2: There seems to be a bug in the test software, such that it doesn't respect the 14-voice minimum when switching back to GF1-compatibility mode from enhanced mode (InterWave only). It won't really cause any trouble, and may even be a simple display error, but I'll fix it when I add the last sample rate table and a few other options.