NewRisingSun wrote:

How would you do volume changes as register writes if the PCM data itself is written as a volume change on channel 0?

Ah yes, you're right... I forgot that in the case of the SN76489, the samples ARE the volume.
Yes, you'd need a translation table in between, which is not there.

NewRisingSun wrote:

One way to support streams on 8088 would be to pre-process by expanding the VGM file with stream commands into the original simple register log upon loading. But then we're back to the huge memory requirements. It could be done piece-by-piece though --- expanding 10 seconds ahead at a time, or so.

The problem is that the 8088 can only handle interrupts at about ~8-10 kHz speeds at best (depending on how complicated you make the actual handler).
This would leave little or no CPU left to expand data ahead of time. Which brings us back to the original problem that the VGM preprocessing tried to solve: A VGM capture of a game on 8088 at 4.77 MHz requires a faster CPU to replay.

I think it's a lose-lose situation: Either you have a routine that is generic, but requires a faster CPU, or you have a routine that is custom-made to only play the Hubbard songs. It wouldn't be 'true' VGM, because you'd make various assumptions, such as only one sample channel, and samples always smaller than 64k etc.
You'd basically just reimplement Hubbard's routine. In which case you might as well rip out the actual code from the games, since it would be the most compact and efficient solution.

NewRisingSun wrote:

I didn't know that you took over SBVGM from OPLx.

I haven't taken over. I had made my own VGM replayer, which in my case was more of a proof-of-concept to get sample playback working in realtime on an 8088 at 4.77 MHz, because I want to build my own toolset for a music system similar to Rob Hubbard's (except I don't want to be limited by a VBL-loop, so mine can run entirely on the timer interrupt, while graphics effects can be shown in the foreground).
OPLx and I decided to 'compare notes', since his player had problems with sample replay on real hardware, and my player didn't implement VGM very thoroughly.
So I shared my preprocessor with him. He could marry that to his more accurate VGM interpreter, and we'd do the actual playback with the stream processor that I had made (it can also support OPL2, OPL3, SAA1099 and even MPU401 and IMFC, all at the same time in theory... we had a thought of also introducing a VGM format for PC speaker, since that is still missing from VGM).

You may be right about the lose-lose situation, with one exception: having just one simultaneous stream is not that far out an assumption; in fact, the overwhelming majority of VGM files that use the stream commands only have one simultaneous stream. That command was originally for the Sega Genesis' YM2612, which only has one PCM channel. In fact, the only kind of files that I have seen that use more than one simultaneous stream are Sega 32x VGMs, which are not supported by SBVGM at all. Multi-PCM chips such as the OPL4 don't count, as they have their own memory region and chip-specific sample playback commands.

Also, SBVGM v1.16 freezes on the Tandy 1000 at the display "Loading (VGM File Name)". v1.15 and v1.14 run well.

SBVGM does not work on ESS-SOLO1 PCI either.

NewRisingSun wrote:

Hi, OPLx!

It seems that SBVGM does not yet support VGM stream commands. They can be very useful for some songs; I have attached one of them. It's the title screen music from the 1989 Electronic Arts game "688 Attack Sub", played on the Tandy 1000. The game plays PCM samples by manipulating the volume register of one the SN76489's square wave channels. The "688 Attack Sub Title Screen (PCM as track data version)" would be compatible with SBVGM if it were not for the excessive memory usage --- all the PCM data is just included in the form of individual register writes --- making it impossible to play the file on a Tandy 1000, which does not have XMS memory. The "stream command version" saves space by including each PCM instrument only once, and by having the VGM player send the PCM data bytes to the chip at appropriate intervals. At 140 KB size, the file can easily fit into the Tandy 1000's memory.

Hello!

Sorry for the delayed response, I got pulled into some work that required more or less my full attention and basically have not had a chance to keep up. Strangely enough it seems that I was not getting message notifications for this thread; it may have been going into my spam folder. I think Scali mentioned about some of the work we had been doing and (at present) SBVGM can't handle the PCM streams to the SN76489 because how it is implemented and also because of how timing sensitive it is. There is a version of SBVGM (I suppose Scali and I ought to finish up the file stream spec) which writes out a the register values in a more efficient form for play back which ought to work on the Tandy 1000 using Scali's playback routines (I think).

NewRisingSun wrote:

Also, SBVGM v1.16 freezes on the Tandy 1000 at the display "Loading (VGM File Name)". v1.15 and v1.14 run well.

Hello again. Could you tell me which VGM files it freezes on? I may be able to fix it and at least test it under DOSBox (since I don't have a Tandy 1000 to test on). Thanks!

dr.zeissler wrote:

SBVGM does not work on ESS-SOLO1 PCI either.

Was there any error message or output? I don't own one of those to test with so it may likely be a bug when it attempts to auto-detect the sound hardware. There are options to force a particular setting if that might help.

I'll have to check that out again. I have changed the working machine, but use that same soundcard in it. I'll report later this week.

Thank you! 😀

http://www.flickr.com/photos/94839221@N05/set … 57687526598300/
Does this help, or do you need additional stuff?

Greetings
Doc

dr.zeissler wrote:

http://www.flickr.com/photos/94839221@N05/set … 57687526598300/ Does this help, or do you need additional stuff? […]
Show full quote

http://www.flickr.com/photos/94839221@N05/set … 57687526598300/
Does this help, or do you need additional stuff?

Greetings
Doc

Thanks a bunch, that's exactly what I needed! That particular file is for the SN76489 hardware which SBVGM does command data translation for to the optional C/MS (SAA1099) chips on the Sound Blaster 1.x/2.x series. While I am not familiar with the ESS-SOLO1, I am under the impression that it does not have support for the C/MS option. It's not possible to detect the C/MS chips on the Sound Blaster series so the -c option is necessary to force SBVGM to use the hardware. Looking at the output that SBVGM gives it's definitely not clear why the program fails to load; I will have to add that for the next version.

OPLx wrote:

While I am not familiar with the ESS-SOLO1, I am under the impression that it does have support for the C/MS option.

I skimmed through the datasheet and found no clues of C/MS support. It does say that it's compatible with SB Pro (Pro should not have C/MS?) and SBbase+0 to SBbase+3 ports are for ESFM synthesis.

OPLx wrote:

It's not possible to detect the C/MS chips on the Sound Blaster series

Actually, I believe it is.
This thread describes building a replica of the Game Blaster: www.vcfed.org/forum/showthread.php?4736 ... le-replica

One thing that is mentioned is that there are apparently latches on the Game Blaster between the ISA bus and the SAA1099 chips (a 'CT-1302' chip), which allows you to read back data that you have written. This is apparently used by various software to detect C/MS.

In this thread, a replica based on the earlier thread is discussed: http://www.vcfed.org/forum/showthread.php?598 … e-Blaster-clone
I have received the PCBs for it, and will be assembling it once I have all the parts. I should be able to write and test some autodetection code on it then.
DOSBox should also emulate this behaviour.

Jepael wrote:

OPLx wrote:

While I am not familiar with the ESS-SOLO1, I am under the impression that it does have support for the C/MS option.

I skimmed through the datasheet and found no clues of C/MS support. It does say that it's compatible with SB Pro (Pro should not have C/MS?) and SBbase+0 to SBbase+3 ports are for ESFM synthesis.

You are absolutely right! It doesn't support the C/MS option. My thoughts were moving faster than I was typing and completely skipped typing not. Thank you for pointing this out; I will go ahead and edit my response.

Scali wrote:

Actually, I believe it is. This thread describes building a replica of the Game Blaster: http://www.vcfed.org/forum/showthread.p […]
Show full quote

OPLx wrote:

It's not possible to detect the C/MS chips on the Sound Blaster series

Actually, I believe it is.
This thread describes building a replica of the Game Blaster: www.vcfed.org/forum/showthread.php?4736 ... le-replica

One thing that is mentioned is that there are apparently latches on the Game Blaster between the ISA bus and the SAA1099 chips (a 'CT-1302' chip), which allows you to read back data that you have written. This is apparently used by various software to detect C/MS.

In this thread, a replica based on the earlier thread is discussed: http://www.vcfed.org/forum/showthread.php?598 … e-Blaster-clone
I have received the PCBs for it, and will be assembling it once I have all the parts. I should be able to write and test some autodetection code on it then.
DOSBox should also emulate this behaviour.

Hi Scali! SBVGM uses that method to detect if a Game Blaster is present, but that method doesn't seem to work for Sound Blasters with the C/MS chips present. The SAA1099 has a DTACK pin, but I don't know if the Game Blaster or Sound Blaster 1.x/2.x series have this connected.

By the way, are those Game Blaster clones easy to come by pre-assembled?

I am pretty sure, that this ESS-SOLO1 PCI-Card is not compatible with CMS. I thought plain SB would do the job for the player,
or perhaps Adlib-Emulation (which is supported), but I think this is a dead end for me. Thx anyways. Greetings Doc

OPLx wrote:

Hi Scali! SBVGM uses that method to detect if a Game Blaster is present, but that method doesn't seem to work for Sound Blasters with the C/MS chips present.

Ah, perhaps that is a shortcoming in the SB design then.

OPLx wrote:

By the way, are those Game Blaster clones easy to come by pre-assembled?

Not as far as I know. The guy just made a prototype card, but the way things work, you generally have to order at least 10-15 PCBs at a time. So he had a few spare ones which he sold on.
I have two. So if I manage to put them together correctly, perhaps you can have one of mine.

Scali wrote:

OPLx wrote:

Hi Scali! SBVGM uses that method to detect if a Game Blaster is present, but that method doesn't seem to work for Sound Blasters with the C/MS chips present.

Ah, perhaps that is a shortcoming in the SB design then.

It seems so. I'm just guessing, but the SB 1.0 had the chips soldered on the board so it was assumed to just be there. But subsequent versions didn't include them.

Scali wrote:

OPLx wrote:

By the way, are those Game Blaster clones easy to come by pre-assembled?

Not as far as I know. The guy just made a prototype card, but the way things work, you generally have to order at least 10-15 PCBs at a time. So he had a few spare ones which he sold on.
I have two. So if I manage to put them together correctly, perhaps you can have one of mine.

Oh wow! Thanks! I will gladly pay you for it. I tried my hand at soldering a few times and was (generally) unsuccessful. I'm not confident enough to put together an ISA card, then end up damaging the motherboard I have. 😵

dr.zeissler wrote:

I am pretty sure, that this ESS-SOLO1 PCI-Card is not compatible with CMS. I thought plain SB would do the job for the player,
or perhaps Adlib-Emulation (which is supported), but I think this is a dead end for me. Thx anyways. Greetings Doc

You're welcome! The OPL3 has native support for square waves and the OPL2 to an extent can emulate square wave by setting up the operator data to approximate it. Unfortunately, but based on how the noise generator on the OPLx family works, it doesn't seem possible to natively simulate/emulate the SN76489 noise generator. As a result a lot of the songs just won't sound correct.

OPLx wrote:

Scali wrote:

OPLx wrote:

Hi Scali! SBVGM uses that method to detect if a Game Blaster is present, but that method doesn't seem to work for Sound Blasters with the C/MS chips present.

Ah, perhaps that is a shortcoming in the SB design then.

It seems so. I'm just guessing, but the SB 1.0 had the chips soldered on the board so it was assumed to just be there. But subsequent versions didn't include them.

Official Game Blaster detection routine appears to use only 2X6 and 2XA ports if the write and readback test pass, but on Sound Blaster those are the DSP reset port and DSP data read port, so no Game Blaster detection routine will work on a Sound Blaster.

However, reading CT-VOICE.DRV, it appears that if GameBlaster gate array detection fails, the SoundBlaster DSP detection is performed. Then a DSP command 0xC6 is run to return if CMS chips are present, but I have not seen it documented before.
Obviously valid only on early cards with CMS sockets/chips, if at all, as I don't see how the DSP would be able to detect if the sockets are empty or not.
Maybe the detection only works on the SB 2.0 as it had the PAL chip, maybe it is assumed that SB 1.X cards have them? But there are also rumours that if you try to access the CMS chips while the sockets are empty, it hangs the machine, as there is nothing to generate DTACK signal so ISA bus cycle is lengthened forever with IOCHRDY.
Later this was reused for generic playback command on SB16.