Quote:

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.

Don't know, if we understood each other correctly? Of course I don't want to change the design of the MP3 card at all (only have the IRQ/"buffer nearly full" signal a little bit earlier). I just described, how I would realize the player.

If you want to output the data in the most optimal way, you have to OUTIR the sectors directly from the mapped Sunrise IDE "rom" to the card. But I can't do that in SymbOS, so I need this inbetween-buffer. In MSX-DOS it's the same, if you don't want to write an own driver for each mass storage device.

Quote:

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.

I completely agree! You should be able to keep the buffer shorter, if you only transfer 3x256 bytes in one VINT or so. But as I said it's important to have the signal more early to be able to use the VINT without having glitches.

Hi, the interrupt can be given when there are only 512 bytes left, but if you want to use the VDP interrupt you can also poll bit 7 of I/O register &H23. At this moment, this bit is set when there are only 512 bytes in the buffer and will be reset when there are at least 768 bytes.

So when you are in the interrupt service routine and bit 7 is set, you can send up to 6*256 bytes. 3*256 bytes will be fine for lower bitrates but there is no synchronisation. Maybe it is a good idea that the AtMega resets bit 7 when the buffer is filled with 5*256 or 6*256 bytes? In this case you can make a better estimation of the remaining bytes of the buffer...

Hi Daniel, yes, I will use bit7 of #23. I think Dvik just would like to have no additional IRQ from the card at all. For me this wouldn't be a big problem, as I just ignore any interrupts, if they aren't coming from the VDP.

Regarding the moment, when bit7 should be reset: Your suggestion can be interesting for special implementations, but for me it's not too important. As I know, that the buffer always has >=1,5KB free (if you stay with the size of 2KB), I will always send 6*256 bytes and then wait for bit7=1 again.

> but there is no synchronisation

What do you exactly mean with this?

Btw, thank you very much for sending the signal now earlier (512bytes)!

Okay, i see about the unwanted IRQ... Now mine is also giving unused IRQ's, the MSX BIOS does ignore it too, there is only a call to &HFD9A. I can add a flag in the AtMega, a command to mask interrupts is noproblem.

With synchonisation i meant, when sending 3*256 bytes every VDP interrupt you assume the bitrate is exactly this (3*256)*50Hz*8bits. Maybe i did not understand his plans but i think it is tricky to expect this bitrate will be exactly 192 or 128kbps for a few minutes. The MP3 cartridge also has its own clock, does not use the MSX clock.

Cool, such a switch IRQ on/off command would make it perfect. Ok, got it with the synchonisation. I would always use bit7, as I think without sync you will always run into problems.

Quote:

I can add a flag in the AtMega, a command to mask interrupts is noproblem.

This was actually what I wanted. I think interrupts can be useful too, depending on the sw.

About synchronization, it would be good if bit7 in #23 is set more than 1/50 second before the buffer is empty. That way it would not be any problem using vint. So @ 192kbps the flag must be set at least 491 bytes earlier. With other overhead I think 512 bytes earlier is enough, but I think it means that the mp3 buffer need to be serviced first in the ISR (which is no problem, just something to keep in mind). @128kbps its no problems at all.

About clearing the flag, I suggest clearing it on read. I guess it could be useful to have the bit set always when the buffer is close to empty ( < 512 bytes), but then its harder to use the interrupts.

I was expecting this for a looong time. I'm not interested in it.... Of course I am!!! I'll buy the first possible unit of it!!!

I think that this device would be very nice if you could read back the decoded data in order to make oscilloscope display for MP3 player or to make MP3 to WAV converter. Unfortunately I don't know how hard this is to implement.

From developer point of view it would be nice to have just 2 I/O ports (L&R) from where you could read realtime PCM data send by MP3 decoder to DA converter.

Sorry if I missed the previous discussion, but where are the MP3 files stored? In the MSX (hard)disk or in a separate memory? In any case, is the file fully loaded and/or buffered in the MP3 replayer device or has the MSX to handle the data transmission?

pitpan: see the top of page 4 of this thread.

Understood. Thanks for pointing it out, Manuel.

The decoding is done in the VS1011, all inside the chip. It is possible to upload a small program to the VS1011 and i think there are 4 16 bit registers which can be used as a feedback from the internal program to the outside world. All registers can be read through I/O &H22, i made a (quick and dirty) example program which reads and 'decodes' register 8 and 9. Here you can also see the actual bitrate of the current package, the layer, MP3 version, stereo/joint stereo etc.

There is an example program available from VLSI for the VS1011 to insert a loudness filter. I was thinking of a small spectrum analyser, but i have to study this strange language first and i don't know the data path inside... Now i am busy with hardware... I spent some time searching on the internet for this, this is needed to start with it:

http://www.vlsi.fi/software/vskit/vskit.shtml
http://www.vlsi.fi/vs1011/software/software.shtml

The data buffer is increased to 14*256 bytes now. It is no problem to send smaller parts ofcourse, if you only want to send 3*256 bytes you won't see the difference. In my test program this buffersize is better with 320kbps MP3's, after 12*OTIR the MSX has more time to access the VDP.

You're welcome. With rapidly growing threads it's sometimes hard to follow.