As usual when you post it ,i will test it on the megaflash to see how is heard

Assuming the the site is correct/correctly understood,
IMHO you could also modify the SECOND technique in order to
update the samples only when the SCC is accessing to samples 16-31

It would become a sort of mix between the two option, i.e. you wait till
SCC is in the 0-15 region and than you update 32 samples

Do you like this?

by the way, ARTRAG: if information on Wikipedia is incorrect, please fix it. That's the idea of a Wiki, after all. I guess you guys have learned enough to correct all mistakes now...

Guillian: how much CPU time does your demo have left?

The sound quality is pretty good, there is much less noise than dvik's demo. But it does sound less sharp, but that's probably due to the 15.75kHz.

Note that it works fine on my real MSX, but unfortunately not in openMSX (I don't hear anything). I hope we can find the cause... If you have any ideas, please post.

It works on openmsx, just tryed!
try emulating msx2,
(BTW in OPEN it does not sounds better than dvick's
demo, both are noisy)

Guillian's code polls VDP status registers
for Horizontal retrace.

Wiki updated

ARTRAG: it seems we found a regression in the current openMSX SVN version. I'm trying to pinpoint it as we speak. Thanks for this info!

So ARTRAG, do you think its safe to access the SCC while the SCC is playing samples 16-31 or when its playing samples 0-15?

No idea, I did as Guillian said and tried to interpret the Japanenglish resulting
BTW
I've understood that 0-15 samples can be safely accessed, and I think that those
are the samples that the SCC program pointed by Guillian used.
So if you write 32 bytes in the tables while SCC is in 0-15 it should be safe.

I'll try that. It was a bit confusing whether it was safe to access all SCC registers while SCC is in 0-15 or if only registers 0-15 were safe. I'll do some tests but I wanted to start with something likely.

I'm sure that accessing to sample 0-15 works always, even if SCC is playing them (look at Guillian/Hyroyuki's code in the rom).
My guess is that when SCC is playing samples 0-15, you can access to ANY byte of the wavtable.
As the address lines interested are different (priority is decided on that basis),
if SCC is not accessing to the second half of the samples, Z80 can access them for sure without
affecting the sound.

This would be a big improvement wrt Guillian/Hyroyuki's code that limits itself to use only 16 samples out of 32.

Quote:

Gullian, if you are Manuel, I didn't received my SCC megaflash jet ... how long post takes usually ?

Well, I sent it 6 days ago. It should take 7-10 days or so.

What I undestand from Hiroyuki's doc is that channels 4 and 5 produce noise if they are accessed/modified when the wave pointer is at 15th-16th byte of wave ram. So when the MSX and SCC try to read those bytes at the same time, it seems the MSX data bus has priority so it is sent to the DAC and not the wave data.

That would explain the noise I hear on the real scc. I'm trying to modify the replayer to avoid reading while these samples are played.

You mean only the two sole bytes at 15th-16th positions ?
This is GREAT! !!
If it is really as you say, the current code needs only to include a delay of one or two samples
in cases when SCC in accessing positions 15th and 16th, and than update all the "used" samples.

[EDIT]
Probably I'm wrong, if even reading CH4 when it is at position 15-16 gives noise, we are in trouble.

exactly what I'm hoping for too. The problem with that other replayer is that its very hard to time the reseting correctly. If its possible to just avoid access while some samples are being played it would sound as good on a real scc as the current implementation does in emus.

Quote:

Quote: Gullian, if you are Manuel, I didn't receive my SCC megaflash jet ... how long post takes usually ? Well, I sent it 6 days ago. It should take 7-10 days or so. What I undestand from Hiroyuki's doc is that channels 4 and 5 produce noise if they are accessed/modified when the wave pointer is at 15th-16th byte of wave ram. So when the MSX and SCC try to read those bytes at the same time, it seems the MSX data bus has priority so it is sent to the DAC and not the wave data.

Does the site say that the problem arises specifically while reading ch4&5 at positions 15-16?