PSG samples

Rookie (30)

02-11-2021, 22:06

Hello,
I have decided to reduce the player as much as possible.
The original one was reading chunks of 16 bytes from the card reader and then played them back at
the correct timing.
Now I have created two cycles of a sawtooth shape at 1378 Hz (1025/8=1378)
Then the player reads 16 bytes of that WAVE (the full data) into its buffer and then plays that buffer
sending data to the YM2149
Well, the result is much better than the other versions. I can hear perfectly the 1378 Hz despite there is some
white noise, maybe due to the just 1 channel playback
On the positive side, at the end of a 'song', the sound mutes perfectly, so this makes me think that the noise
I am hearing right now could be due to the 4-bit downscaled sound ...
It is time to play these two cycles but using 3 channels ... will let you know how this goes
regards

By pser

Rookie (30)

02-11-2021, 22:30

no good luck :-(
using the three tables to have better data conversion gives as a result a greater noise level
The 1378Hz sound is audible and better defined but noise has raised too.
Probably the intermediate changes are creating spikes while switching from a state to the next.
It seems to be complicated to avoid them ... in my setup :-(
Thanks a lot to all of you for your hints/advices
cheers!

By Grauw

Ascended (10717)

02-11-2021, 23:17

That could be the case indeed. When I look at the Motorola 6809 code, because of fewer internal registers it seems more difficult to space the I/O as closely together as on the Z80, where it gave decent results, not perfect but an improvement at least. Although I’m very unfamiliar with the 6809 CPU’s instructions and timing.

I think the best quality solution is ARTRAG’s that I linked to before (quote “crystal clean”), but it has practical limitations in the sense that you need to preprocess the wave data. Fine for a game, but not so great for a generic wave player. Unless there is some clever delta calculation that is relatively precise but doesn’t require excessive CPU cycles or memory for large tables.

By pser

Rookie (30)

03-11-2021, 09:00

Hi all,
I finally saw the light or got some inspiration ...
As I am using two external modules, say the card reader and the MSX chips add-on, I was using a special
multi-pack module with four slots that allows the programs to switch from one to any other.
This has not had any effect on the YM2413 playing, but I suspected that the continuous switching could
be affecting and so creating noise on the YM2149.
In fact I read the card every 16 bytes, so working with 11025Hz samples I am switching 689 times per second
back and forth from one slot to the other, meaning 1378 switches per second ...
Fortunately, we have a 'second' solution with a strange name "Oojamaflip" that allows to share the expansion
port by two modules, so there is no needto switch slots.
The first try has been the RAM wave I had created with just 16 bytes. The result while playing has been a very
clean sound with absolutely no noise at all, and it was using the three channels!
Then I have tried the older version that played the data from the card using the three channels too and, remember,
I said that it is an old version, it starts the song with some white noise that is very soon hidden (almost) by the music level that is very high compared to what I did hear before with the multi-port module.
So the idea works well despite our module could 'need' some extra filtering in the positive rail to get rid of the
noise created by the continuous slots changing.
This encourages me to make further tests to try to minimize that noise, maybe even learning the ARTRAG approach
that Grauw told me to use, despite this could imply a WAVE pre-work. Java will come to help!
So, thanks a bunch to all of you, my friends. It is a pleasure to talk to you and I am really fortunate to have
the chance to ask and get advices from you!!
cheers!

By pser

Rookie (30)

03-11-2021, 14:59

Hello,
as the 6809 is a subset of the much better Hitachi 6309 that adds two more registers (at 1 extra cycle cost) and a lot of new opcodes, I have tried to read the three bytes on different registers and then send to the YM2149 R# and value as fast as possible.
The result has been quite a lot worse than 'normal' version
It seems that YM2149 is happier if there is a small delay after modifying one register and before you send next R#
so I will forget about this kind of optinizations and will try to learn about ARTRAGs approach you had commented ...
regards

By pser

Rookie (30)

03-11-2021, 17:02

Hi,
final note ...
6809/6309 accept to work at 1,8MHz (double speed) despite this implies losing the 6847screen, not that important
when we are working withV9958 ... I was using this feature just for reading from the card.
Once set this double speed, the playing gets much better. The noise is greatly reduced, probably because the times
between data writes, those that create spikes, have been halved ...
cheers!

By pser

Rookie (30)

03-11-2021, 19:40

and ...
when using the extra registers of the 6309 to read the three bytes and then send thtese values as fast as possible
to the YM2149 ... results in a greater noise level :-(
I would have hoped the contrary, but you never can tell ...
After reading the Viterbi filter articles and the hell of work that could be related to implement that I think that
I wil keep experimenting with other features of these MSX chips, maybe in the future ...
regards

By jltursan

Prophet (2619)

03-11-2021, 20:00

The YM is losing data for sure, too fast writes are too much for its timings

By pser

Rookie (30)

03-11-2021, 20:18

jltursan wrote:

The YM is losing data for sure, too fast writes are too much for its timings

I agree, José Luis.
I have tried to add more cycles between YM writes but it doesn't make any change.
All in all, I think that current program version is a very nice proof of concept of playing WAV files on YM2149
It is a pity the number of cycles needed to feed the three channels. That way I cannot even try to work with
WAVEs sampled at 14000 Hz
11025Hz seems to be the limit in my setup (and I am using double speed!)
cheers!