Cool, that the buffer size has been increased to 3,5KB!
Because of this I wonder if there is any chance to make the "buffer is nearly empty"-signal configurable. Now you are generating it, when the buffer contains <512 bytes, which is fine for 128kbps MP3s (I am speaking about the VDP-irq-poll-methode). For 192kbps this is already very short, and for 256kbps it's not enough (higher bitrates are probably not useful, if you want to do something else with a normal MSX2). So as you now have a bigger buffer, maybe it could make sense to set the bit more early (768 or 1024), if the bps-rate is higher.
Only an idea, and I hope these discussions won't delay the project, as I can't wait for holding this great card in my hands Personally I think I will hardly play MP3s with a bitrate >128kbps on the MSX.

Is the size of the data buffer configurable or is it always 3.5kB? @128kbps, the buffer is around 200ms if I calculated correct. This is great in an mp3 player but maybe a bit too long if you want do do sound effects that are synchronized with video or user input.
On the other hand I'm not sure if mp3 is a good format for sound effects. In a game its probably better to have high quality background music in mp3 and do sound effects with another sound chip and then the delay doesn't matter.

Having a configurable 'buffer near empty' flag is not needed I think but could be good. But I guess it need to be set earlier than 512 bytes before buffer empty, so it can be used in bit rates > 192kbps. If its fixed I think 1024 bytes is a good number.

Is this VS1011 doable as not-so-heavy addition for the OCM?

Quote:

Is this VS1011 doable as not-so-heavy addition for the OCM?

You mean integrated in the FPGA, right?I think it may be a bit heavy. Not sure how many gates it would need but it sounds like there aren't too many free ones in the ocm.

Are there already any MP3-decoder-implementations for VHDL? I wonder how many LEs it would need.

With mp3 serving for music, you can drop FM-Pac, MSX-Audio, SCC and PSG at once (well, maybe a small simple soundgenerator for some sfx)

Btw, would it be terribly difficult/expensive if you'd include a few MB of memory and play the mp3 from there? That would free up the cpu and internal memory to do other things. Even having a single mp3 in memory is a big job for most MSX machines.

You don't need internal memory, if you "stream" it from hard disc. I don't like the idea of having memory on the MP3 card too much.
- big delays before playing an MP3
- additional costs
- nothing else than an "iPod" controlled by the MSX
If my calculations are not totally wrong, you will still have 75% CPU time and nearly the complete MSX memory available while playing 128kbps MP3s from HD/CF card.

Quote:

With mp3 serving for music, you can drop FM-Pac, MSX-Audio, SCC and PSG at once (well, maybe a small simple soundgenerator for some sfx)

Full ACK!

Quote:

Is the size of the data buffer configurable or is it always 3.5kB?

That doesn't matter. It's your choice how much bytes you load into the buffer after receiving the "nearly empty" signal. Regarding the reaction time and "realtime" sound-effects: The question is, if the MP3 card does nothing at the moment, and I start to fill the buffer: After what delay will the MP3 decoder throw out the decoded audio? I think that has nothing to do with the size of the buffer, has it?

What's with the iPod all the time? If you're referring to it being like a co-processor that takes overhead away from your MSX, then what about the V9938? What about the Moonsound? What about the G9k? What's so extremely not-done about having a co-processor working alongside the MSX in which co-processors are already daily practice? It's not an iPod, it's just a chip, just as the Moonsound has chips, just as the FM-Pacs, MSX-Audios, SCCs, G9k's have chips.

My point is, if you start using too much external CPU power (many times more than a Z80 and something that wasn't possible to do in the 80's, the system becomes quite ridiculous. Then its not the same as a V9938. G9k is imo as you know from other posts close to the limit to what can count as MSXing.

But it all depends on how you look at it. The russians have done quite remarkable improvements with the speccy, but those speeded up speccys with several MB ram is really not something retro. And for me MSX is retro. Its like old cars. Of course it could be fun to rebuild it, but calling a new BMW with an exhaust pipe from an old beetle retro doesn't make much sense.

A bit out of topic maybe....

A co-processor is not the problem. The only problem for me is having a completely separated hardware which is only sometimes controlled by our old 8bit machines via play/pause commands. For me that's not so exciting. But ok, the "ipod" issue was only the third argument against onboard MB-sized buffer-memory

Is the Moonsound ridiculous (it would've been space-age in the 80's!) ? Or is it only ridiculous with some decent SRAM (RAM was space-age in the 80's)? And what about SymbOS? Isn't it ridiculous to port "Windows9x" to an 8bit-system? (not so much concerning whether it can be done, but whether it should be done, from a retro point of view. A real retro-geek doesn't need a Win'esque GUI/OS, as he types "Run"cas:" all the way)

When is something ridiculous, and when is it not? And: whould you've said the same 12 years ago?

Is it ridiculous to plug a $900 videocard into a $300 PC just to play the latest games at 1600x1200? Should one say: "in such a cheap PC, there should only be a cheap videocard, otherwise get a faster PC" ?

One of the things that defined the MSX for me was that there were all kinda expansions one could gradually buy. Why not simply see an mp3-player -with its own RAM- as such an expansion?

offtopic it may be, but not less interesting

ok, esp. for you

- big delays before playing an MP3

define 'big' .. I think we could bear some..

- additional costs

like? I dunno what hardware costs and such, but what would, say, 8MB cost?