Dragon's Lair for MSX2 - introdemo

Just to say Congratulations!!! Terrific!!

I have an SCSI interface, and I can't load the Demo. Anyway to do it?


Regards,
Alex

Sorry Morg, I don't think, that I'm going to implement SCSI support. It would require too much work :-(

Once you come up with a 'final version', perhaps it would be possible to make a standard file-format for it? If you'd give me the specs it would be nice to have another video-format to support in ViewMSX. I had also been looking into slightly modifying/updating the EVA format, but the lack of hardware makes it a tad tedious. So, if you're going to do it; even better! If I may be so bold as to make a few suggestions: Try to include some file and frame headers, it shouldn't be too hard, and can make life at lot easier for file-type detection. Also (if you want ofcoz) try to make a replayer that can be easily used in games, with options such as preffered sound-chip, no mode-change, no cls, and maybe a variable DX/DY (iirc it uses HMMC, right?). It should be nice for people to be able to replay a small 'eva' file without actually having to code stuff themselves.

A pity you're not planning scsi support... would be nice to see. Is there possibly an emulator which supports IDE interface emulation?

I think, this "How did you do it" feeling is not gonna last whole day.

To Sonic_aka_T:

I already have a player that supports both of the "EVA formats" In this version HMMC was thrown to trashcan and direct VDP access was used instead, but you are right... EVA originally uses HMMC. File header is quite a hard to implement, when you play with direct sector access. This means, that whole data moves and sector reading routines need to be changed to different locations in the code.

I also don't see any point for making PC replayer, when there is no tools to convert data to this format. As I'm not a PC coder, there is no much I can do... This conversion was pretty much made by hand. Frames were converted with BMP2MSX and sample was edited with GoldWave. The thing was put together with really crappy and slow VBScript, that read the files 1 byte at a time as text file

If you really want to make a replayer, just take your EVA replayer routine switch to "Hi resolution mode" take the picture data and put first 6KB to address 0, next 6KB to #2000 use next bytes to initialize pallette and trow rest of the bytes away. That's all folks. No magic inside, magic is in the data. Sample timing has not been altered.

Ps. I have tested, that this works with OpenMSX (at least with MSX tR config)

Watching and listening full screen movie on my MSX right now in complete disbelief.....

Seems the same in blueMSX 2.5 beta : no sound in boosted MSX2, but I have sound on boosted Turbo-R (I don't have yet tried a non-boosted machine)

Here some blueMSX screenshots :

To use MSX-AUDIO in for example MSX tR, you have to use /A parameter. For full list of parameters, just write DEMO to commandline.

On turboR nor on MSX2 do I get any sound with the /a parameter...

the other parameters work very good (manuel, try /c !) .... the /m parameter is indeed experimental

Any tips on how to initialize MSX-Music correctly for playing samples is more than wellcome. I know it can be done... At the moment either I get really low volume or then there is some strange noice in the backround...

I just know this:

Procedure PcmPlay(SourceAddr,SampleLength,SampleFrequency:Integer;
                  Volume:Byte); {REM Volume 0..7}
  Var SampleRate :Integer;
      Temp       :Integer;
  Begin
    Temp := Trunc(SampleFrequency/1000);
    SampleRate := Trunc(3600/Temp);

    Inline(
           $F3/
           $3E/$18/$D3/$C0/$3E/$FF/$D3/$C1/$3E/$19/$D3/$C0/$3E/$08/$D3/$C1/
           $3E/$04/$D3/$C0/$3E/$08/$D3/$C1/$3E/$04/$D3/$C0/$3E/$80/$D3/$C1/
           $3E/$0D/$D3/$C0/$3a/SampleRate  /$D3/$C1/
           $3E/$0E/$D3/$C0/$3a/SampleRate+1/$D3/$C1/
           $3E/$08/$D3/$C0/$3E/$0C/$D3/$C1/
           $3E/$17/$D3/$C0/$3a/Volume     /$D3/$C1/
           $2a/SourceAddr/$ed/$4b/SampleLength/
           $3E/$16/$D3/$C0/$3E/$C0/$D3/$C1/$3E/$15/$D3/$C0/$7E/$D3/$C1/
           $23/$0B/$78/$B1/$28/$10/$DB/$C0/$CB/$67/$28/$FA/$3E/$04/$D3/$C0/
           $3E/$80/$D3/$C1/$18/$E3/$3E/$04/$D3/$C0/$3E/$78/$D3/$C1/$3E/$04/
           $D3/$C0/$3E/$80/$D3/$C1/$3E/$08/$D3/$C0/$3E/$00/$D3/$C1/
           $3E/$18/$D3/$C0/$3E/$FF/$D3/$C1/$3E/$19/$D3/$C0/$3E/$00/$D3/$C1/
           $FB
            );
   End;   { PcmPlay }

(code by Kari Lammassaari)

On my MSX2+... Great!!!
One request: can you make a DSK floppy image to use immediatly with openMSX?
Thank you.

And indeed, it's for MSX-AUDIO. But that's what you asked.

nyyyyriiiiiki.. do you use compression on each videoframe? Or is it just the raw 12304 bytes per frame?

nyyyyriiiiiki.. do you use compression on each videoframe? Or is it just the raw 12304 bytes per frame?
The video part of the frame is 12320 bytes of raw data. Sound data is about 1312 bytes / frame and the routine reads 15360 bytes / frame, so actually there is about 1728 bytes / frame, that are currently not in use!´

From this it is possible to calculate, that there is currently MUCH to improve, but as I said before there are no more frames in original Dragon's Lair, so I did not find it usefull to start modifying those 8 already optimized disk / sample play routines at this point. When you ZIP the file the size difference is not much...

By the way (also to mars2000you): the openMSX Teams welcomes programmers who are interested in GUI development. Send us a mail. Also Windows developers are still welcome, as we get about 0 response.

The harddisk image is now online :

http://www.msxblue.com/Dragontest.zip

To use it in openMSX, the unzipped file (Dragontest.dsk) must be placed in a special directory (see the user's manual).
You also need to edit the hardwareconfig.xml file in share/extensions/ide as following :
- name of the file : Dragontest.dsk (in stead of ide.dsk)
- size of the file : 16 (in stead of 100)

Extremely cool ! Never thought I'd see that kind of video on a MSX2. BTW, I only get sound when I use TR emulation. Nothing no with MSX2, be it with Audio or fmpac.

Kuddos !

Considering that just the number of OUTI's a z80 can do a second gives you an upper limit of 16FPS. I think 15 fps will be a bit much when loading and sound is included.

It looks impressive though! And I think prodatron will want to have a word with you about low level disk drivers

A pity you're not planning scsi support... would be nice to see. Is there possibly an emulator which supports IDE interface emulation?
The next version of blueMSX will most likely have IDE support as well.

NYYRIKKI: No MSX1 version? . Nah, just jokin' , awesome work!. Well done, NYYRIKKI!

Thank you for all these good reactions, it is great to see, that you like this demo!

BiFi: Thank you for this code. The only MSX-Audio I've ever had was Phillips Music-Module, so my knowledge was not accurate. I'll fix this to next version.

iamweasel2: If I would use CD for audio playing, I would need to put the data some other device. Although CD-drives are quite advanced today, you can't play music and read data at the same time AFAIK. CD data troughput is high, but seek times are slow.

Edwin: These low level disk routines are not made by me, but ofcource I'll help Prodatron in all possible ways I can. It seems, that direct I/O to IDE is not very difficult... If you look at EVA sources and documentation in Sunrise www-page, you should be able to make your own routines in no time.

I think the OPL4 is damaged... I connected it to PC sound input and it went dead... I think this is relatively common problem... I hear something with really low volume and the sound is broken.

NYYRIKKI: Yes, the game would need to be in HD and the songs would be played by the CD, and the z80 would be free to work with the video only. About the delay, it is possible to make your code wait until CD is ready (I know it sucks, but that's how things are). I know it is not the perfect solution, but if you want to get the best result possible, you could try using CD. I believe it can make the MSX version of Dragon's Lair even better than already is.

Why my IDE+RS232 is crashed!!!!!

But only wathing the screenshots, reactions and readme I can say... this is absolutelly AMAZING!!! TOTALLY GREAT!

NYYRIKKI: I just watched your demo... It's amazing I like it very much! Samples are of crystal clear quality and the video is superb! Thanks man!

http://koti.mbnet.fi/asukkaat/dragon/dragonupdate.zip

Nyyrikki has just uploaded an update ... I guess that MSX-AUDIO must work now

@NYYRIKKI

few questions

what is the format of the original video?
what is the frame size?
how many colors it has ?

apart bmp2msx, what processing have you done?

Very impressive. This is one of the coolest thing I've ever seen on an MSX2.

@ARTRAG

I think that the quality of the video could be improved a bit by looking at several frames, similar to the PSG sample player. But at 12 fps I wonder how much can be done to improve the quality, but I'm sure it can be improved a bit at least.

When it comes to audio, the biggest problem is that its not that much CPU left for the audio. Assuming that each video frame requires the whole screen to be updated (12320 bytes), its only 44200 CPU cycles per second for audio which isn't enough for a 8kHz PSG sample player.

So to get enough CPU cycles for decent PSG audio, the video frames needs to be rendered, so that not the entire screen is updated each frame. This is most likely not too hard, but certanly not trivial.
I updated the waves demo to use the new PSG sample player and with 8kHz audio, about 50% of the CPU is free for other things.


@NYYRIKKI, What frequency does you audio replayer have?

Original sample is 44KHz 16bit stereo, ogg encoded @ about 120kbps. The MPEG framerate is 30fps, but as I said, all animation frames are included in the MSX version.

I think, that PCM could use PSG in theory... There is still 1.7KB empty data in each frame, that is now just sent to unused I/O port... maybe that could be used to make the sample play less CPU intensive. Now the sample plays @ about 15KHz

Hey, that's nice... Thank you!

Actually, this demo is SC2/4. So not quite the same as you might think. Especially considering the amount of data.