Most likely the Creative Voice Editor, capable of playing .voc "voice" files.
http://vgmpf.com/Wiki/index.php/Creative_Voice_Editor
http://www.vgmpf.com/Wiki/index.php/Sound_Bla … r_Pro_%28DOS%29

I have the same memory as you do but I'm out of town right now; will add more info.

Well, I don't think it was Creative Voice Editor.

Attached is a "mock up" of what I recall the program looking like. Mostly I just remember that "oscilliscope" widget in the corner and being mesmerized by that.

Maybe this was part of some other application - but it just seems I came across it shortly after installing the Creative setup stuff.

This is what you're looking for sir:

https://www.youtube.com/watch?v=2a6I0FBo0O4

PSA turn your volume down below half before you click that, it's a tad overdriven

That's it.

Now to find what installer had this, to run it on my physical 5150. I thought there were other samples to choose - but anyhow, that's certainly it. 1991, nice! [ how could I have forgotten the MOD format! for shame ]

I've tried
Sound Blaster 2.0 CT1350B Installation Disks
Sound Blaster 2.0 Deluxe CT1350B Installation Disks

I had no idea about the name, I just remember it was part of one the Creative installers because my mother got home shortly after we finished the install and we were playing this (and WingCommander) and she said (to my father) "so how much did all this cost!?" (since it was obviously an upgrade to the typical speaker BEEP). I tried to cover for the old man and immediately said "aw mom, we just finally fixed the speakers! that's all" 😀 "Mmmmhmmm..."

Tetra Compositor... I misread it as Voyetra... wow.

This post has a download for the demo version:
Re: Tetra Music Compositor.

Here is a better video of a possibly older version compared to the the youtube link with a bit of explanation in the description:
https://steamcommunity.com/sharedfiles/ ... 162298090

Yeah, I think you're right - I recall some extra "offers" being included in the box. [ Voyetra, yeah I was wondering there 😀 ]

MODEDIT and ECHOING.MOD should do then, hopefully it can talk to my SB.

Scratch that - MODEDIT doesn't run on a 5150 (8088).

[ I always had a feeling this audio originated from the Amiga crowd ]

EDIT:

TDEMO failed (on stock 5150 @ 4.7) - it showed the GUI, but never executed any audio. (works in 86box; maybe I need to remove the extra RAM, just use 256KB mainboard?)
(is NST just a renamed MOD?)

GLX played the ECHO.MOD - but struggled greatly (as in playing it at 1/5th speed). [ I think my old PC-clone was one of the Tandy 1000's @ 8-10 mhz ]

voidstar wrote on 2021-08-13, 22:41:

Scratch that - MODEDIT doesn't run on a 5150 (8088). […]
Show full quote

Scratch that - MODEDIT doesn't run on a 5150 (8088).

[ I always had a feeling this audio originated from the Amiga crowd ]

EDIT:

TDEMO failed (on stock 5150 @ 4.7) - it showed the GUI, but never executed any audio. (works in 86box; maybe I need to remove the extra RAM, just use 256KB mainboard?)
(is NST just a renamed MOD?)

GLX played the ECHO.MOD - but struggled greatly (as in playing it at 1/5th speed). [ I think my old PC-clone was one of the Tandy 1000's @ 8-10 mhz ]

Sent you a PM.

Thank You! (I'm too new to reply in PM)

NOTES:
TETRA_XT.EXE is the same byte size, but (I think) it disables the "o-scope" spectrum analyzer - which then my little 4.77mhz 8088 is able to play AXEL_F.NST at a decent tempo (but then it locks up when playing nearly every other NST, not sure why that's inconsistent and I'm too lazy to disable the 3COM network stuff to see if that's causing the conflict - I use that to sync clock on startup and FTP in files).

I wonder, how does TDEMO.COM know my SB settings? ( don't think it uses the BLASTER env var ). But maybe this is why it is locking up on me? (my physical SB is at int 5, 220, dma 1).

All this makes me appreciate that 8088 Domination project even more - which on my 5150, that does slow down in a couple parts, but overall plays (and sounds) fine.

voidstar wrote on 2021-08-14, 06:15:

I wonder, how does TDEMO.COM know my SB settings? ( don't think it uses the BLASTER env var ). But maybe this is why it is locking up on me? (my physical SB is at int 5, 220, dma 1).

Auto-Probing for SB settings was common and easy in the DOS days.

One approach works like this: You send "reset card" output instructions pulses to the reset register 6 above the base address for every possible base address (210, 220, 230, 240 IIRC). If the card answers with the correct "initialization complete" answer, there most likely is a soundblaster at that base address. After that, you issue a "play silence" command (or, if you are Creative Labs and know your undocumented instructions, you issue a "generate IRQ" command). As "play silence" doesn't need any data, and just waits for some time, it causes the soundblaster card to generate an interrupt, even without setting up DMA. Finally, you send a "play data" command, which needs DMA, and enable one DMA channel (0,1,3) after the other, and you probe what DMA channel causes an interrupt to occur. "play data" waits for DMA data to arrive at the card, so when the matching DMA channel is disabled, it will not yet generate the soundblaster interrupt.

Your issue doesn't sound like it, but I observed several issues with automatically detecting sound cards:

Auto-probing schemes are known to (sometimes) disable all candidate interrupts after probing. I used to play older games from a network drive mapped using Novell Personal Netware. Some game disabled IRQ2 after finding my sound card on IRQ5. Too bad that IRQ2 was the network IRQ, which caused the network driver to hang on the next file the game tried to load. In this case, the offender was Supaplex.

Furthermore, many programs do not only probe for soundblaster cards, but also for GUS cards. This involves reading from "candidate base address + 100", so for candidate base 210, the program reads the value at port 310. A lot of NE2000 clones (I heard the original is more tolerant, defenitely modern clones are) lock the ISA bus if you access their base address + 10 without preparing the card for that access. As 300 is the default and de-facto standard base address for an NE2000 card, this is another cause for lock-ups of sound software on retro systems. In this case, the offenders were the OS/2 Warp 3.0 installer and th e module player WOW II.

Wow, thanks for the insight. I see TDEMO.COM is a ~16KB COM file - so it has to be running in real mode right? And it doesn't have to be doing BIOS calls, it could do it's own OUT instructions - except it is included with that EGA file and the NST sample, so probably using BIOS to access the file system? (maybe I'm running from a folder that is too nested?) Anyhow, I wasn't sure if COM files really can access environment variables - couldn't they technically be executed before command.com, which I thought command.com setup environment variables? (wasn't there something in config.sys to limit the size/amount of RAM allocated to those variables)? Maybe I'm remember all that wrong...

So, I removed everything from config.sys and autoexec.bat (not loading any SB drivers or network drivers) - TDEMO.COM is still locking up for me (on physical 4.77mhz 8088, 5150 -- I do have a VGA card, so TDEMO.COM does render the gray GUI scene, but it locks up I assume when starting to try the audio -- I have to ctrl-alt-delete out). [ I'm not sure if TDEMO can run on just a CGA card - but I suppose my next thing to try is to just remove all the cards {except SB} and run TDEMO from a floppy disk {i.e. with the NIC and XT-IDE removed}) ].

The only other thing is I'm using DR DOS 3.41 instead of MS-DOS. (bit of a story as to why: my stock 5150 was only 256KB RAM - all the installers of MS-DOS 4.0 or newer require 512KB {not to boot, but to execute the installer} -- I could have installed manually {SYS and all that}, except my floppy controller doesn't support high density, so I needed to find a version of DOS that would support >32MB partitions, had 720K install disks, and require under 256KB RAM -- DR DOS 3.41 met all that). But now I have my RAM board and technically 1MB RAM (but DR DOS 3.41 has no EMS/HIMEM, etc, so I just use 640KB). And I don't want to migrate to MSDOS622 since I want to be able to remove the RAM board and verify what programs still function with just 256KB RAM available.

voidstar wrote on 2021-08-14, 08:15:

Wow, thanks for the insight. I see TDEMO.COM is a ~16KB COM file - so it has to be running in real mode right?

Well, wrong. I can write a 1.6KB COM file that switches to protected mode, prints "Hello world" and switches back. A program being a "16KB COM file" doesn't tell you anything about the mode the code runs in. On the other hand, the 8088 in an PC/XT doesn't support anything except real mode (actually, that mode was intended to be called "real-address mode", but the name was shortened to "real mode" as soon as Intel introduced the different modes on the 286 processor. The other mode is called "protected virtual-address mode", by the way, usually shortened to "protected mode"). As that program runs (kind of) on your PC, it is very likely not doing any mode mode switches.

voidstar wrote on 2021-08-14, 08:15:

And it doesn't have to be doing BIOS calls, it could do it's own OUT instructions - except it is included with that EGA file and the NST sample, so probably using BIOS to access the file system? (maybe I'm running from a folder that is too nested?)

There is no BIOS support for the sound card, so programming the SoundBlaster needs to be done by using it's own OUT instructions. On the other hand, you don't want to reinvent floppy drive / hard disk drivers, and you also don't want to reimplement the FAT file system in a music player. The FAT filesystem is implemented in DOS, and DOS uses the BIOS to access the data on the floppy or hard disk. So TDEMO calls DOS to "open AXEL_F.NST", and DOS then calls the BIOS to read the sector that contains the current directory, so DOS knows where the file is stored. Later on, TDEMO will call DOS to "read bytes from the file" and DOS will call the BIOS to read the data sectors as indicated by the directory and FAT structures.

voidstar wrote on 2021-08-14, 08:15:

Anyhow, I wasn't sure if COM files really can access environment variables - couldn't they technically be executed before command.com, which I thought command.com setup environment variables? (wasn't there something in config.sys to limit the size/amount of RAM allocated to those variables)? Maybe I'm remember all that wrong...

What you write is at least partly right. There used to be no environment before COMMAND.COM was loaded, at least up to DOS 3.3. But those DOS versions also couldn't run COM files from CONFIG.SYS. "INSTALL=" is a DOS 5 invention, I think one of the features MS-DOS copied from DR DOS 5.0. You specify the size of the environment as parameter to COMMAND.COM using "/E", and usually that size is inherited to all child processes.

But COM files can access the environment without problems. The (segment) address of the current environment is stored at address 2E (if I remember correctly) in the COM file segment (the actual code/data from the file starts at 100). Possibly "INSTALL="ed COM files get an empty dummy environment here.

voidstar wrote on 2021-08-14, 08:15:

So, I removed everything from config.sys and autoexec.bat (not loading any SB drivers or network drivers) - TDEMO.COM is still locking up for me (on physical 4.77mhz 8088, 5150 -- I do have a VGA card, so TDEMO.COM does render the gray GUI scene, but it locks up I assume when starting to try the audio -- I have to ctrl-alt-delete out). [ I'm not sure if TDEMO can run on just a CGA card - but I suppose my next thing to try is to just remove all the cards {except SB} and run TDEMO from a floppy disk {i.e. with the NIC and XT-IDE removed}) ].

I see three possible reasons for the lockup. Possibly your version of TDEMO is using some 286 instructions, which can not be handled by an 8088 processor, your computer is just too slow to calculate the sound data fast enough and starts calculating new blocks interrupting the calculation of previous blocks and thus overflows the stack. A third possibility is that TDEMO requires the sound card to be on IRQ7, which was a common setting back in the PC/XT days with the hard drive at IRQ5.

mkarcher wrote on 2021-08-14, 12:19:

A third possibility is that TDEMO requires the sound card to be on IRQ7, which was a common setting back in the PC/XT days with the hard drive at IRQ5.

Super Good point ! Nearly all my 8bit controllers default is IRQ5 and cannot be shared for proper operation, making the sound card IRQ7 which can be shared with a rarely used LPT port. Was going thru that issue last week 😀

mkarcher wrote on 2021-08-14, 12:19:

I can write a 1.6KB COM file that switches to protected mode, prints "Hello world" and switches back. A program being a "16KB COM file" doesn't tell you anything about the mode the code runs in. On the other hand, the 8088 in an PC/XT doesn't support anything except real mode

Yeah, I meant a .COM that is runnable on an 8088 should be a "real mode" and limited to 64KB (single segment) memory allocation (hmm, including the code portion itself? so a 16KB real-mode COM can only allocate 48KB of dynamic buffer space? although it could use overlays to "pull in more code" and overwrite itself, I suppose).

I've now tried about 20 "mod players" and they are all locking up (on my 8088) eventually - so I assume they eventually hit a 186/286/386 instruction. They're all EXEs, except MP.COM (old ModPlayer) - which maybe that's locked up for the same reason as TDEMO?

I was pretty sure I ran that old TDEMO.COM long ago on my Tandy 1000SX that had an 8088 (at either 8mhz or 10mhz, can't recall) - but maybe I'm mistaken and we had upgraded the PC by then. According to here:
https://www.mobygames.com/game/dos/wing-commander/techinfo
Wing Commander would run on that old 8088 Tandy system.

Maybe it's the IRQ7 deal that you mentioned, I'll give that a shot.

voidstar wrote on 2021-08-14, 08:15:

You specify the size of the environment as parameter to COMMAND.COM using "/E"

I think I started with MSDOS around 3.30, skipped 4, then went thru 5 and 6. So I remember when they added that SHELL= option in config.sys.
http://qa-knowledge.blogspot.com/2012/04/comm … nd-comspec.html

But COM files can access the environment without problems. The (segment) address of the current environment is stored at address 2E (if I remember correctly) in the COM file segment (the actual code/data from the file starts at 100). Possibly "INSTALL="ed COM files get an empty dummy environment here.

I was hoping TDEMO.COM had some command line arguments. [ that's start at 0x100, or 256 byte offset ]

I ported my DestinyHunter game from the Commodore PET to a real-mode IBM PC game ( www.destinyhunter.org ), but I haven't finished adding audio to the PC version. I was just going to use PIT (speaker timing), but maybe some Adlib support might not be too hard.

I'm wondering: it seems it would be possible to write a little .COM utility to scan other .COM files and report if they are real-mode 5150 / 8088 compatible or not (just search for code portions and see if it is a valid 8088 instruction -- otherwise, report the invalid offset). Wonder if such a tool already exists?

BTW, not to distract from this thread too much -- but since we're talking about real-mode: I tried to run VC.COM (VisiCalc), and it loads OK, I can move the cursor/cell around, but I can't enter any actual data (the top right corner says "0M" so the program itself thinks there is 0 RAM available). Maybe it's just some incompatibility with the XT-IDE RAM expansion module - I tried getting a message to Dan Bricklin about it, but not sure I have the correct address.

voidstar wrote on 2021-08-14, 23:33:

I've now tried about 20 "mod players" and they are all locking up (on my 8088) eventually - so I assume they eventually hit a 186/286/386 instruction. They're all EXEs, except MP.COM (old ModPlayer) - which maybe that's locked up for the same reason as TDEMO?

At what rate are you trying to playback a .MOD on your XT ? GLX 2.12 works on XT's but you have to limit the playback to 11khz or 22Khz depending on what sound card iirc. Let me grab it...
The docs say up to 22Khz with Adlib and SB. If you haven't tried it is is here under Galaxy Music Player: http://www.dcee.net/Files/Music/Player/
Some info: GLX Player the only XT player ? Check Mod Master... and https://www.vcfed.org/forum/forum/collections … -modarchive-org
If it does no run on your system at 11Khz then you I think you have something else wrong...

Oh, yes, pardon - GLX does work, but it was painfully distorted rate (but I didn't try adjusting settings; I'll look into that again). The TetraCompositor demo also did work, but only for a single NST (AXEL.NST) -- it has two EXE's, where the xxx_XT.EXE disables the spectrum graph -- so that "XT" version had a reasonable playback. Thanks for the ModMaster notes, I'll give it a shot tonight.

Success, on both GLX and ModMaster 2.2 (if you have the ECHOING.MOD file).

GLX defaults to 22KHz (I only had a few moments when I tried it previously and hadn't read thru the doc file), so that doesn't quite work for the 8088 @ 4.77Mhz (it does play, but slow and distorted)

I used command: GLX /oSB /m13
( /m can be value 10 to 13 seemed ok to me, whereas values 14-22 were playable but had a bad distortion; interestingly values below 10 got interpreted as values over 20... i.e. /m8 became 25KHz and /m9 became 35KHz).

For ModMaster 2.3 (note: "2.3" and not the "2.2" version), I got a runtime error and dropped back to DOS prompt. [ this is better than just freezing up the system, since 2.3 is supposed to be for '386 or newer ]

ModMaster 2.2: with no command line options, it reports a "speed test" where the value I got was 905. After that, you can select a file - but note the program is also defaulting to 22khz. I had mouse driver loaded, and selected "Output" and used arrows to reduce that down to 13000 hz. [ I went as low as 7000 which still sounded ok, 14k to 16k also still sounded ok but starting to get distorted -- but I'd say not as distorted as GLX at those speeds {perhaps because GLX tries to show more graphic in the spectrum, so it is working more on that} ].

I'd still like to just run TDEMO.COM itself for the visual, but for now I'm a bit lazy to change my SB from IRQ5 to 7 to see if that is the issue -- it's not difficult, but it's just that I have the case and everything "buttoned up" (enclosed and screwed tight) and everything is working very nicely, I don't really want to risk any mishap to 40 year old equipment. Maybe we can disassemble TDEMO.COM and study it from that way instead (is it locked to 22khz? to IRQ 7? are there command line options? is it even 8088 compatible {one of those online disassemblers I think can answer that}?).

voidstar wrote on 2021-08-14, 23:33:

mkarcher wrote on 2021-08-14, 12:19:

I can write a 1.6KB COM file that switches to protected mode, prints "Hello world" and switches back. A program being a "16KB COM file" doesn't tell you anything about the mode the code runs in. On the other hand, the 8088 in an PC/XT doesn't support anything except real mode

Yeah, I meant a .COM that is runnable on an 8088 should be a "real mode" and limited to 64KB (single segment) memory allocation (hmm, including the code portion itself? so a 16KB real-mode COM can only allocate 48KB of dynamic buffer space? although it could use overlays to "pull in more code" and overwrite itself, I suppose).

Well you're kind of mixing up memory model (tiny, small, compact, medium, large) with executable format.
It's true that a COM has to be under 64K and starts up with DS=SS=ES=CS (tiny model) but doesn't mean it has to continue to maintain the seg registers that way if it can get additional segments allocated from DOS at runtime.