MP3 player for MSX

Página 8/51
1 | 2 | 3 | 4 | 5 | 6 | 7 | | 9 | 10 | 11 | 12 | 13

Por [D-Tail]

Ascended (8258)

imagem de [D-Tail]

28-02-2007, 21:18

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 Face

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

Por msd

Paragon (1471)

imagem de msd

28-02-2007, 21:21

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

Por dvik

Prophet (2200)

imagem de dvik

28-02-2007, 21:36

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.

Por Prodatron

Paragon (1808)

imagem de Prodatron

28-02-2007, 23:10

@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.

Por Prodatron

Paragon (1808)

imagem de Prodatron

28-02-2007, 23:21

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.

Por DD

Expert (88)

imagem de DD

01-03-2007, 17:42

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...

Por Prodatron

Paragon (1808)

imagem de Prodatron

02-03-2007, 16:25

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

Por DD

Expert (88)

imagem de DD

02-03-2007, 17:21

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.

Por Prodatron

Paragon (1808)

imagem de Prodatron

02-03-2007, 17:29

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.

Por dvik

Prophet (2200)

imagem de dvik

02-03-2007, 17:40

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.

Página 8/51
1 | 2 | 3 | 4 | 5 | 6 | 7 | | 9 | 10 | 11 | 12 | 13