Hi,

Maybe it is usefull for some of you to have some technical details:

For bass, treble, spatial stereo and pseudo stereo a TDA8425 is used together with a PCA9564D I2C controller (I/O &H24-&H26). A second TDA8425 can be used to combine the standard MSX audio output with the output of the MP3 player, so bass, treble, spatial and pseudo stereo can be selected independently.

Indeed it is a 'rotating FIFO', at this moment the size is 2048 bytes. An interrupt will be generated when the FIFO level is below 256 bytes. Some time ago i did a check with the interrupts, it was possible to edit in WBass and go to basic while a 192kbps MP3 is playing, but any access to HDD crashes the MSX. I don't know how to open more than one file on the MSX system (?), sorry, i am a hardware guy. I am not sure if a 320kbps MP3 in basic is possible. You can also poll bit 7 of I/O address &H23 (=need data). So after this bit is set or the interrupt is generated, you can send 2048-256 bytes (7* OTIR). It might be possible to increase the buffersize, because i implemented 'shadow memory' which should contain data of the VS1011 memory... But it seems not possible to read memory of the VS1011, i -thought- it would be possible to read register 6 from the VS1011, it isn't. This remaining part of AtMega RAM could be used for audio data as well, but checking the limits of the buffer will be more complex and the interrupt routine of the AtMega must be very short otherwise a R800 might be too fast and the AtMega will lose bytes.

While playing a 320kbps MP3 from a CF card (IDE interface), it is not possible to send 640 bytes to &H98 of the VDP. I think it is because of the delay of the VDP. The Z80 can execute longer divide loops instead, but not loops containing OUT (&H98).

For adding extra flash storage on the cartridge, i am affraid we will have to start over again. The concept of the player is ready and debugged... There are no I/O pins left on the AtMega, but maybe there is a possibility to add SD/MMC because it has a serial bus. I am working on a bootloader for the AtMega right now, it should be possible to update the main software later on.

About emulating, bit 4 of &H23(read) is a busy flag, when changing from audio to register (command) data, the AtMega sets this flag and keeps this bit high while sending the register buffer (max 256 bytes) to the VS1011. The MSX should poll this bit before writing to I/O &H23 again. For writing to the dataport, no waits are needed. The cart does not generate a hardware WAIT signal, using this status bit the programmer can be more efficient and let the MSX do other things in the mean time.

Writing to &H21 will reset the AtMega, the VS1011 and the I2C chip.
&H22(wr) = audio / register data
&H22(rd) = shadow memory of VS1011 registers (polled by AtMega so it is available for the MSX immediately)
&H23(wr) = Bit 3-0 = Register select
&H23(wr) = Bit 4 = *
&H23(wr) = Bit 5 = 1=Don't auto increment the register number, normally it is incremented after 2 data bytes
&H23(wr) = Bit 6 = 1=Data is register, will be stored in AtMega first
0=Data is audio data
&H23(wr) = Bit 7 = 1=Send stored register data to VS1011
&H23(rd) = Bit 3-0 = Register select, data read on &H22 is the content of this register
&H23(rd) = Bit 4 = Busy
&H23(rd) = Bit 5 = *
&H23(rd) = Bit 6 = *
&H23(rd) = Bit 7 = Need audio data (interrupt requested)

&H24 to &H27 are the PDA9564D directly, the exact meaning of these registers can be found in the PCA9564D datasheet as well.

If you want i can send a short example program, later on i will put all details on www.pa4den.nl to make it downloadable for everyone.

Grz, Dennis

Well, I was only thinking about converting existing AVIs, MPEGs whatever, not creating new own movies The Dragon's Lair movie is a conversion, too, isn't it? But if I understand you correctly, Dragon's Lair is a very special kind of movie and you won't have this quality with other movies?
Hm, maybe Screen5 showing a smaller frame would be an alternative. But sorry, it starts to become offtopic now

I was indeed talking about new movies for gaming purposes. -btw, don't mind any offtopicness, welcome to MRC-

Thanx a lot for the information!

Dragon's Lair was animated by Don Bluth. Don Bluth, once a disney animator, also made the movies Titan A.E. (2000) and Anastasia (1997).

Quote:

Quote: so that means you need a HD or Cf card in your msx in order to store mp3s ? I guessed the msx would send a signal to the cart, and have an output of some kind.. or the msx'es one Yes, you need a HD of CF for storing the MP3's. Maybe Obsonet will give you MP3 radio, but i think it's speed is to slow for it. But i am not sure.

Well, a small note about this: Matra is involved in Dumas. Dumas will contain Obsonet. It will not use any Z80-time, because Dumas has its own co-processor and moreover: Matra could look into combining this MP3-player with Dumas/Obsonet.

@Dennis: Would it be possible to do the "need audio data" signal/interrupt more early? Originally I was planning to check the status every 1/50s seconds, but this wouldn't be enough when playing a 128kbps MP3. 512bytes would be better in this case.

Quote:

Well, a small note about this: Matra is involved in Dumas. Dumas will contain Obsonet. It will not use any Z80-time, because Dumas has its own co-processor and moreover: Matra could look into combining this MP3-player with Dumas/Obsonet.

If Obsonet is able to "load" data from the internet as fast as the Sunrise IDE or whatever from HD/CF it would be totally ok. I am not sure, if it makes sense to "combine" mass storage or network devices with the MP3 card, as it would require a lot of different combinations (MP3 with IDE, MP3 with Sd, MP3 with Ethernet etc etc...) The MSX should be fast enough to handle the transfer by itself and still has CPU power left.

Prodatron, let's not forget that Dumas isn't only Ethernet. It will also have some memory on it. I could imagine that some dedicated space could be implemented as a buffer for the MP3 device. As far as I have read in this thread, it's up to the coder to place MP3 data in the buffer. Well, I guess it can be done all-at-once, with some large buffer. Then, the MP3 processor would only receive an instruction to repeat the music data once it has played it all.

@Prodatron, giving an interrupt earlier won't be a problem. The only disadvantage is, the MSX will have to send smaller data packages (6*256) more frequent. I will try to make the buffersize 10 or 11*256 bytes, i have to test it on the Turbo-R...

@DD: You are right, that would decrease the performance a little bit. But I hoped, that it won't be necessary to install an additional interrupt handler but to use the VDP 50/60Hz interrupt to send data to the MP3 card if required. I think sending 1,5KB at once (only every 4-5 vblanc for a 128kbps MP3) is still fine and not too small. Of course a bigger buffer would be always better.

@D-Tail: But the memory coming with Dumas is usual mapper-memory, isn't it? So it's not a difference to the MSX internal memory.
If I would implement a MP3 player, I would do it like this:
- reserving a buffer of let's say 16KB in the normal MSX memory
- load the first 8KB of the MP3 from HD into the first part of the buffer
- start sending the data of the first part to the MP3 card and load the second 8KB parallel
- wait until the first part has been sended
- now it will be just swapped. The second part is sent and the first part of the buffer can be filled with the next MP3 data
- etc etc.
I hope this won't generate any glitches, otherwise the size of the temporary buffer has to be increased.

Prodatron: I can imagine that a separate design can be made, so as to implement extra (dedicated) memory for this chip. It's then just a matter of transferring the MP3 data to the device at the beginning, and let the thing whistle its tune. The current approach of the Dumas memory is, indeed, mapper-based.

About your approach, which sounds to me a lot like a bound, wrapped buffer, I'm afraid it's too CPU-intensive. 128kbps = 16kBps, so every second you would load some 16K from HDD. Now, that isn't too big of a load, but since interrupts have to be disabled when doing disk I/O (that's the proper way, isn't it?), I'm afraid the eventual program will display hickups. Unless, the 16K reading sessions can be spread out so as to reduce the time that I/O has to be switched off. As if that isn't enough, the 16kB loaded data must be transferred to the device using outs, so I do doubt that the eventual program would be able to do something useful.

There's light at the end of the tunnel: as I am about a total ASM-noob, I just might be wrong

I do hope that it delivers its sound just right, we'll have to see if that plan comes together

D-tail: Interrupts don't need to be disabled and they are only disabled if you disable them

It sounds like Prodatrons suggestion is a memory mapped buffer so you could use cpir instead of outir. Sortof like ADVRAM. This would speed things up and you'd only need to have that page mapped into Z80 memory when the copying is done.
It will also make it easier and a bit more flexible when it comes to switching the buffer. The hardware would most likely automatically switch buffer when the other buffer is done, generate an interrupt and/or set a status bit.
In fact the hw could swap buffers automatically so the only data you can write is the buffer currently not being played. Could also make each buffer a bit smaller than 8kB so you could have memory mapped status and command regs.

But I must say I like the current design too. Being able to use shorter buffers would be nice. I would even like to be able to fill the buffer on every vint to even out the outs to the cart.
One important thing is that it would be good if the interrupts can be disabled but still have the status bits telling whether more data is needed. If you're using vint you don't want to have the other interrupt fired.

@D-Tail: At least in SymbOS interrupts are only disabled while reading one single 512byte sector, as the IDE rom has to be mapped during this process in the visible memory (and normally there could be different program code, so I have to disable the INTs to prevent executing it). Between every sector they are enabled for a short time, so that every VDP irq can be handled without big delays. That means, that I don't see any problems here. And yes, I think the MSX is fast enough to handle this: 1.) Transfer data from HD to ram, 2.) transfer data from ram to the MP3 card, 3.) goto 1. As I wrote before I made some calculations and came to the result, that there should be still 75% CPU time left! That's quite cool and gives you the possibilities to do some other sensefull jobs.