All MSX has PCM sound

Page 2/3
1 | | 3

By DarkSchneider

Paladin (880)

DarkSchneider's picture

20-05-2018, 21:41

SCC/MSX-Audio/OPL4 are discarded.

The problem I think is more the sync than the real CPU usage it would take really. It uses 100% because usually the technique used is the polling, not good if you can have different CPU speeds (like on MSX).

But, even using a proper sync method is problematic. For 8KHz are 8000/60 = 133 ops per interrupt, then for a good sync we should set 1 interrupt every 2 lines, and send 1 data (this gives 128 data sent, the others could be sent at the last one or distribute). But this is not very viable. As we distance more the interrupts, every 4 lines and send 2 datas, 8 lines 4 datas, 16 lines 8 datas...we free CPU an resources in general, but probably we get more audio jitter.

We have that the most correct sync method, that would be set 1 interrupt every few lines to send data, it can take much CPU. But the polling method on MSX should be avoided even for the case we want max sync dedicating the whole CPU to play the sample.

By ARTRAG

Enlighted (6277)

ARTRAG's picture

20-05-2018, 21:45

Keyclick is quite dull for most practical use when you can use the psg.
Moreover the balancement between psg and keyclick is not fixed, so you cannot safely mix them

By Grauw

Ascended (8508)

Grauw's picture

20-05-2018, 21:54

On MSX2 you could poll HR and play a 15 kHz sample.

IMO interrupt driven isn’t practically feasible or useful, I think 1 interrupt every 2 lines is quite optimistic, an ISR is not without overhead, and if you do manage to make it fit then the CPU will barely get any time outside of the ISR. Plus there are gaps, of the 262 lines @ 60 Hz you can only set interrupts on 244 of them, and 255 out of 313 @ 50 Hz. Due to this, the maximum interrupt driven timer you can get is only 300 Hz (I use this in VGMPlay).

However don’t discard timing with the CPU so quickly. You can calibrate the sample player to be CPU speed-independent by playing a short silent sample (e.g. 1/60 seconds) with different wait periods. Measure how long it takes, and then use a binary search pattern to increase or decrease the wait period until you’ve reached the exact time period it should take.

By DarkSchneider

Paladin (880)

DarkSchneider's picture

21-05-2018, 08:50

ARTRAG wrote:

Keyclick is quite dull for most practical use when you can use the psg.
Moreover the balancement between psg and keyclick is not fixed, so you cannot safely mix them

It seems so. Due you have to stop everything, the PSG can play samples up to 4-bit with the same small and simple code. And it allows to select the pitch.

@Grauw the problem is that you can't say to the user "hey adjust the audio to your clock". I have seen on a turboR PCM handling routine to use the port E6 (could be?) for system clock. But I can't find anything similar for MSX2. So the sync continues to be a problem.

By DarkSchneider

Paladin (880)

DarkSchneider's picture

21-05-2018, 12:34

Also, are you absolutely sure that the data needs to be polled? Turrican II on Atari ST uses digital sound on start screen and the action is not stopped, so it is supposed it puts data in periods and not continuosly.

https://youtu.be/dmI2XZ0PBzQ

Edit: OK the Atari ST has timers for triggering interrupts:
http://s390174849.online.de/ray.tscc.de/samples.htm
Looks so handy...

By Grauw

Ascended (8508)

Grauw's picture

21-05-2018, 13:49

DarkSchneider wrote:

@Grauw the problem is that you can't say to the user "hey adjust the audio to your clock".

Why would you need to prompt the user? Just run the calibration once at the start of your game (or w/e), it will only take 16 iterations to calibrate a 16-bit wait counter, if the period of the calibration sample is 1/60s that means just 0.5s.

DarkSchneider wrote:

I have seen on a turboR PCM handling routine to use the port E6 (could be?) for system clock.

The PCM controller itself also has its own (simpler) clock for that. Neither of them fire interrupts tho.

DarkSchneider wrote:

But I can't find anything similar for MSX2. So the sync continues to be a problem.

If you poll HR, it’s quite similar to the turboR… But not available on MSX1.

By DarkSchneider

Paladin (880)

DarkSchneider's picture

21-05-2018, 14:39

Grauw wrote:

Why would you need to prompt the user? Just run the calibration once at the start of your game (or w/e), it will only take 16 iterations to calibrate a 16-bit wait counter, if the period of the calibration sample is 1/60s that means just 0.5s.

But not all MSX CPUs have the same IPC, so that calibration could not be precise. On R800 you could get into problems, and don't want to put specific turboR code.

Grauw wrote:

If you poll HR, it’s quite similar to the turboR… But not available on MSX1.

HR? What is that? Not interested on MSX1 so if is something like a high-precision timer is fine to me.

By Grauw

Ascended (8508)

Grauw's picture

21-05-2018, 14:45

DarkSchneider wrote:

But not all MSX CPUs have the same IPC, so that calibration could not be precise. On R800 you could get into problems, and don't want to put specific turboR code.

IPC, what’s that?

I don’t see the problem. The whole point is that you use the same code, just binary search on the wait period. Start right after VBLANK. Play with a wait of 8000H. Does it complete after the next VBLANK? Subtract 4000H, play with a wait of 4000H, repeat. Does it complete before the next VBLANK? Add 2000H, play with a wait of 6000H. Repeat halving the step size each time until it’s reached 1.

DarkSchneider wrote:

HR? What is that? Not interested on MSX1 so if is something like a high-precision timer is fine to me.

VDP horizontal retrace flag, see V9938 application manual. Useful in line interrupts as well for sync.

By DarkSchneider

Paladin (880)

DarkSchneider's picture

21-05-2018, 15:15

IPC = instructions per clock. On R800 is higher than the Z80.

As HR is a more fixed method because is based on a fixed rate I think is better. But is triggered even on borders? or only for lines 0-212 (when drawing)?

It is more a design concept. Imagine a future MSX implementation with a CPU fast enough that even a full 16-bit counter is not slow enough. Because that I prefer to use solutions based on more tangible timming.

By Grauw

Ascended (8508)

Grauw's picture

21-05-2018, 15:47

Instructions per clock doesn’t matter at all for the autocalibration. The whole point of it is that it’s CPU speed independent. Since you think this matters, maybe you’re missing some vital detail about the concept of this suggestion? For being CPU-independent, I think this suggestion is quite future-proof (otherwise why bother with calibration at all).

If you want to imagine a future where a 16-bit counter isn’t enough then make a 32-bit counter. It’s not any slower to make a wait loop with that if you build it as two nested 16-bit loops or four nested 8-bit loops. However I think a 16-bit counter will have plenty of room to spare when playing samples at thousands of Hz, on an R800 I expect it to loop only a few hundred times orso at the most, so the CPU would need to be hundreds times faster to run out of 16-bit counter space.

Btw tbh I don’t think it makes sense to imagine such a hypothetical future where the CPU is many times faster than MSX CPUs are now. That’s not an MSX and I don’t care to develop for it. Then I might as well make games for Android, and reach many more people. In such a hypothetical future system, surely the display resolution will increase as well and then HR won’t be useful as a timing mechanism anymore either. If you start thinking too much that way then you can’t do anything.

HR is for sure also triggered during the borders. Not 100% sure it’s also triggered during sync, but I do think so. I plan to poll HR across the sync in my game project sometime soon, so I’ll post about it when I know for sure.

Page 2/3
1 | | 3