MP3 player for MSX

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

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.

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.

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 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)!

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.