OpenMSX PSG de-emulation

صفحة 2/2
1 |

بواسطة redman

Expert (67)

صورة redman

11-11-2014, 15:55

Quote:

(Perhaps they don't really cared about that issue? / Too much trouble to 'fix' it?)

No, you don't have a choice realy. The driving of the PSG is usually linked to vblank interrupt. There is no good way of replayinng 60Hz music on 50Hz and vice versa.

بواسطة ren

Paragon (1928)

صورة ren

11-11-2014, 16:17

Quote:

No, you don't have a choice realy. The driving of the PSG is usually linked to vblank interrupt. There is no good way of replayinng 60Hz music on 50Hz and vice versa.

hmm.. If I'm not mistaken SHMUP! (and perhaps some other recent/'modern' MSX games as well?) has some detection routines and plays the music back at the same speed/rate/pitch, whether 50 or 60Hz. (right guys (or not)? ;))

بواسطة ren

Paragon (1928)

صورة ren

11-11-2014, 17:37

Quote:

hmm.. If I'm not mistaken SHMUP! (and perhaps some other recent/'modern' MSX games as well?) has some detection routines and plays the music back at the same speed/rate/pitch, whether 50 or 60Hz. (right guys (or not)? ;))

Hmm.. I just checked, it seems it doesn't have some magical PAL/NTSC detection/playback routine.. The sound speed/pitch difference only isn't as noticeable so much perhaps as with some other tunes/games?

edit: actually I am not really sure (again ;)), there is a (slight) difference in playback pitch/speed noticeable, but when I e.g. toggle_freq in openMSX, it is way too fast, or way too slow, depending if I booted 50 or 60Hz.
So it seems to do something different than e.g. a Konami rom :) (where you can just toggle_freq, and you get the difference in speed between PAL/NTSC).

The Bold demo also seems to be adaptive; try starting it with a 60Hz machine.
Funny thing is it the demo restarts itself (or it may crash) after a toggle_freq in openMSX.

بواسطة redman

Expert (67)

صورة redman

11-11-2014, 17:55

I'm think they use line interrupts to send commands to the psg. It means that they can have higher time resolution (that can influence frequency as well) and they can kindof compensate for fps speed. I'm just not sure if it works out perfectly. To do this perfectly i think you need to be able to set line interrupts for the vblank period. Not sure the vdp can do that.
Anyway, my project is not fast enough yet to handle that kind of data flow.

بواسطة Grauw

Ascended (10581)

صورة Grauw

11-11-2014, 19:22

What is done in some software is to call the music player twice every 5th interrupt at 50Hz (if the music was designed for 60Hz), or skip every 6th interrupt at 60Hz (if it was designed for 50Hz).

The approach using moving line interrupts is more accurate, but I don’t think that was done often. Also it only works if the music was designed for 50Hz. For Synthesix, I will probably do that though. Currently it automatically switches to 60Hz on boot.

بواسطة redman

Expert (67)

صورة redman

11-11-2014, 20:04

Quote:

What is done in some software is to call the music player twice every 5th interrupt at 50Hz (if the music was designed for 60Hz), or skip every 6th interrupt at 60Hz (if it was designed for 50Hz).

Aah,. ok,. not the nicest solution. Smile

Quote:

The approach using moving line interrupts is more accurate, but I don’t think that was done often.

I came across some of these. I think Utopia demo does it in the copper demo.
I think that for something like Synthesix you should comletely forget about interrupts and scan midi & drive PSG as fast and often as you can. Maybe use interrupts only for arpeggio's and such. But that's just my opinion Smile

بواسطة Grauw

Ascended (10581)

صورة Grauw

11-11-2014, 22:23

redman wrote:

I think that for something like Synthesix you should comletely forget about interrupts and scan midi & drive PSG as fast and often as you can. Maybe use interrupts only for arpeggio's and such. But that's just my opinion Smile

Mmh… maybe, but then the update frequency becomes irregular. I think that’d be audible. Additional complication is that you can wire triggered modules to run at control frequency by just feeding them a constant 127. Is handy for ADSRs etc. In editing mode I need some time for the UI as well so there a fixed update frequency is better.

But as I was thinking about adding a 100Hz control rate mode anyway, maybe I should also just make an unlimited setting in recording mode. Then people can decide on their own which they prefer, depending on the patch and machine speed (turboR Smile). I’ll just have to find a good way way to discourage people from using aforementioned constant trigger method.

Anyway a bit off topic hehe, sorry Smile.

بواسطة redman

Expert (67)

صورة redman

12-11-2014, 02:08

Quote:

Mmh… maybe, but then the update frequency becomes irregular. I think that’d be audible.

With something like midi you want to react as soon as possible and not wait untill the next interrupt to start the note. But then, if you generate an envelope or lfo or other internal control signal you want to have that in a regular stream.

Isn't there an interrupt for incomming midi? I mean, midi has a command speed of about 1kHz. That's much more than 50 or 60 Hz, right? How is it handled?

Quote:

In editing mode I need some time for the UI as well so there a fixed update frequency is better.

I can imagine two scenario's, both involving line interrupts.
It depends on if you get an interrupt from the midi in port or not.
If yes then handle that data immediately.
If no then bunch it together with the control generation.

The control signal generation could run on a line interrupt. If you divide the screen in, say, 8 parts, then you already have a rate of 400Hz, which is decent.
You'd get (i think?) about 9000 z80 cycles between line interrupts which seems pretty decent as well. Maybe you could even bump it up to 800 Hz by halving the line offset, which gets you close to midi command rate.
You may need to tune it to not get choked on incomming midi data. Actually, i think midi data is a concern all thoughout the path, whatever design you use. There is probably little buffering at the midi port so if you don't read it fast enough you risk losing data. So the faster you handle the midi data the better (up to about 3k midi bytes/s). How do you handle this problem, or, is this a problem at all?

Since this would all be running in the background on interrupts you can do your UI more or less the usual way as long as you don't make it too heavy.

Anyway, just theorizing Smile

Quote:

Anyway a bit off topic hehe, sorry Smile.

No problems here! Smile Not sure about the visitors, but... who cares Wink

بواسطة Grauw

Ascended (10581)

صورة Grauw

12-11-2014, 11:58

I replied in the Synthesix thread :).

صفحة 2/2
1 |