Messages

1

Mega Tokyo SCI Archive / Re:QfG1 remake's EGA640.DRV

« on: September 21, 2002, 11:29:33 AM »

Sorry for jumping into this thread so late. I haven't been ignoring you folks, I just tend to read sound stuff more often since that's my particular area of expertise with SCI.

Creating a new graphics driver is certainly possible, and as people pointed out, I did it by disassembling Sierra's sound drivers and creating a new one in assembly.

I haven't looked too closely at graphics drivers, but the general scheme for all of Sierra's drivers is a little something like this:

Code: [Select]

; The driver is in some file on disk. The interpreter
; loads it into memory at the start of a segment.
; Whenever it needs to use the driver, it does a far
; call to the start of that segment. The first instruction
; in the driver, at the start of a segment, is a jmp to a
; driver interface function.

jmp DriverInterface

; Next, some identifying information
db 0             ; unknown purpose, possibly here for alignment
dd 0x876543210   ; identifies this file as a Sierra driver
db 0             ; identifies this as a display driver

db 7, 'namedrv'       ; pascal style string with the driver name
db 11, 'description'   ; pascal style string with driver description

; This is traditionally the driver data space.
; Remember that driver data lives in the code segment,
; so if you have a variable foo, reference it with cs:foo
; and not ds:foo.

; Next, a jump table to driver subfunctions. You'll have to
; figure out what each subfunction does by disassembling
; a Sierra driver.
dw Func0
dw Func2
dw Func4
; etc

; The DriverInterface function saves registers and uses
; the jump table to call the correct function. Register bp
; contains the subfunction number.

DriverInterface:
   pushf
   ; save registers except ax and cx, which return values
   call near word [cs:ExportTable+bp]
   ; restore saved registers (don't touch ax and cx)
   popf
   retf

; Implementation comes down here.

Func0:
   ; implement Func0
   retf

Func2:
   ; implement Func2
   retf

Func4:
   ; implement Func4
   retf


2

Mega Tokyo SCI Archive / Re:Sound Blaster support

« on: September 18, 2002, 04:36:06 PM »

I think it is fairly common for SCI games to have SoundBlaster and Adlib sound problems on faster computers. Trying to get old games to run on new computers with newer hardware and operating systems just makes the problem worse.

Swapping out your sound card and enabling the onboard audio sounds like more work than it's worth, to me. First, get VDMSound or something similar if you're running Windows NT or Windows 2000. I'm not clear on whether or not it's necessary for Windows XP, but it's worth a shot.

If the operating system isn't the problem, make sure the sound card settings are set to something SCI can use. The SB driver from KQ1 SCI01 requires DMA 1 and I/O port 220h. The IRQ can be 3 or 7. QFG2 can also use IRQ 2 or 5. I don't know about SCI1 games.

If computer speed is the only problem, there's some chance that using onboard audio instead of the sound card will work. It would require that the onboard audio use shorter delays than the card. I don't know how likely that is.

edit - whoops, I meant KQ1 SCI01, not KQ1 SCI1.1

3

Mega Tokyo SCI Archive / Re:Sound Blaster support

« on: September 16, 2002, 10:46:34 PM »

Emulating hardware in drivers for the original Sierra interpreters isn't a very feasible thing to do. The main problem is that the drivers must be 16 bit DOS code. There isn't a direct way to use Windows API functions or anything else.

The best option is to follow FreeSCI development. It would be much easier to integrate with existing emulation libraries and could be compiled to run natively on more modern platforms.

4

Mega Tokyo SCI Archive / Re:Sound Blaster support

« on: September 15, 2002, 07:10:50 PM »

I'm not sure what would happen if the SB initialization code were skipped. It's advisable to keep it in there, though, because besides detecting the hardware it will also put the card in an initialized state.

There are a couple of things that might be going on. First, your hardware might be too fast. The driver has to introduce delays so the hardware has time to work. For simple delay routines, faster computers will cause shorter delays, which means that the hardware won't have enough time to do what it needs to.

Also, the driver may be hard coded to use different settings than your hardware uses. For example, one Sierra driver that I looked at uses DMA channel 1. If the SB uses some other channel, the driver will fail.

Do you know how the VDMSound SB is configured? Can you change those settings? If you send me a driver, I'd be happy to see what I can do with it.

5

Mega Tokyo SCI Archive / Re:Sound

« on: September 07, 2002, 02:25:45 PM »

Are you using gm.drv or mpumidi.drv? For imported MIDI files, the correct driver would be mpumidi.drv. It's available at http://www4.ncsu.edu/~rniyenga/sci/mpumidi.zip.

The names are a little confusing. The gm.drv driver is for playing MT-32 tracks on a GM device. I called it that long before even thinking about how to deal with actual GM tracks.

6

Mega Tokyo SCI Archive / Re:Soundbox

« on: September 01, 2002, 06:42:57 PM »

I write pages by hand. The original idea had been to play around with CSS while still using standard HTML that would render in non-CSS browsers. I probably did something to break browsers that don't support all the CSS features I'm using.

7

Mega Tokyo SCI Archive / Re:Soundbox

« on: August 30, 2002, 11:54:51 PM »

Oops. Sorry for the problems. A statically linked binary is now up at http://www4.ncsu.edu/~rniyenga/sci/soundbox-static.zip.

The blank pages are bad news. I'll be sure to change them as soon as I can get the time together. What browser and platform are you folks running?

8

Mega Tokyo SCI Archive / Soundbox

« on: August 30, 2002, 03:08:46 PM »

The re-write of Soundbox for editing SCI0 sound resources is now available from http://www4.ncsu.edu/~rniyenga/sci/soundbox.html. It is functionally similar to the previous version with known bugs squashed. It was also written in VSNET as opposed to VS6, which may affect distribution. Please let me know if you have any problems running it.

Soundbox includes Rickard Lind's MT-32 to GM patch mapping code, taken from FreeSCI.

Soundbox is released under the GNU GPL. Source code and a VSNET project are available from the same page as the binary package.

9

Mega Tokyo SCI Archive / Re:Sound in SCI Studio VGA

« on: August 16, 2002, 09:08:17 PM »

Sorry for the delay. With the approaching end of summer (in my hemisphere, anyway), I've been lax about working on projects. Best guess for a release is last week of August.

10

Mega Tokyo SCI Archive / Re:sound editor

« on: July 21, 2002, 08:28:39 PM »

wxWindows does look stable and solid. I can use it for the user interface if you plan on migrating, or if that would be easier for you to integrate.

My personal favorite GUI toolkit to program for is Swing. Once I got my head around its layout managers and event model, I found it simple and easy to work with. Java's garbage collection made it especially nice. Sadly, the actual GUIs produced by Swing never quite satisfied me.

11

Mega Tokyo SCI Archive / Re:sound editor

« on: July 21, 2002, 12:20:07 AM »

Brian, if you want source for the current editor you're welcome to it (just mail me or whatever), although I hope to rewrite it keeping in mind some of the lessons learned. Build one to throw away, more or less. Regardless, the current editor may be freely distributed. I don't think it says so in the program, but it's public domain.

Considering future integration with SCI Studio: I happen to use MSVC++, and as I recall Brian uses C++ Builder. I can probably keep data structures and functionality fairly portable (any special requests?) but the UI will have to be more or less re-written.

12

Mega Tokyo SCI Archive / Sound Editor

« on: July 12, 2002, 01:58:55 PM »

(Note: The board seems to chop off URLS at tildes. Clicking on the links won't work, you'll have to type or copy/paste the full address.)

The editor is available at http://www4.ncsu.edu/~rniyenga/sci/soundbox.zip. It is untested and unpolished, but should do for the moment. I plan on cleaning it up then releasing it under the Lesser GPL, but for now consider it public domain.

To play imported MIDI files in Sierra's DOS interpreter, use the driver at http://www4.ncsu.edu/~rniyenga/sci/mpumidi.zip.

The quick instructions:

Have an SMF file to import. It must be format 0 or format 1. Leave channel 15 blank (channel 16 if you count starting from 1 instead of 0). Don't rely on sysex messages. They will be stripped during import. For best results, keep the original MIDI file as simple as possible.

Use File -> Import MIDI to convert from SMF to SCI0 sound resource.

Use File -> Save As to save the resource to disk.

Be careful with large files. Sound resources should be under 64k.

It isn't necessary to use any other parts of the editor. If you're interested, though, the SCI0 sound resource specificaiton explains editable features of sound resources.

13

Mega Tokyo SCI Archive / Sound in SCI0 games

« on: July 11, 2002, 05:50:36 PM »

The first cut at a new sound resource editor is done. I plan on releasing it tomorrow. That's a little premature, but there's been enough interest about music that I want to get it out as quickly as possible.

Note that the sound editor I'm writing is not and probably never will be a composition tool. It converts SMF to SCI0 sound and manages things like cues and the loop point, but it won't let you actually write music.

I also plan on releasing a new sound driver to play resources converted from GM tracks. In short, it will use play flag 0x80 and simply dump the events as-are to the MPU. This will affect FreeSCI and any other programs which hope to play music from new SCI0 games, so if anyone wants to discuss this plan then feel free to bring it up.

14

Mega Tokyo SCI Archive / Re:how to insert midi in my game?

« on: July 08, 2002, 08:10:08 PM »

The old converter will not necessarily work for any given MIDI file. More than that, I believe it only flags channels for Adlib playback.

As I recall, (though I don't want to speak for him in this) Brain mentioned that he intends to include a sound editor with SCI Studio sometime in the future. I'd be happy to put together a more capable conversion program in the meantime, though.

15

Mega Tokyo SCI Archive / Re:To Ravi

« on: June 30, 2002, 03:36:51 PM »

The driver doesn't crash on KQ4, but it doesn't quite play the sounds correctly, either. The first 16 bytes of MIDI data get skipped. This is the same thing that happens with the Card, but with another twist. After skipping the first 16 bytes, the driver starts reading data in such a way that it belieives it's in running status mode. The problem is that it doesn't have a previous status to repeat, leading to the crash. For KQ4, it is lucky enough to read a full status byte for the first sound. Running status mode isn't invoked and the driver continues as normal, if a trifle odd sounding.

Incidentally, I put up a new SCI0 GM driver to avoid the crash, but it isn't really worth downloading if you already have the old driver. The newer version doesn't fix the real problem, it just gets rid of the most visible symptom. The Card doesn't crash now, but it skips the first song and gets stuck on the second -- probably waiting for a cue that never comes.

If you could send me a sound resource or two from each of your 0.000.3xx games, I'd be very grateful. Thanks a bunch.