Forums

Hello,

I continue the development of my SMS emulator. It runs now some games that does not require any exotic features : Alex kidd in Miracle World, Sonic 1, etc. Any undeveloped features : codemaster mappers / sprite overflow and collision flags / others than VPD mode 4 / etc.

An important limitation is the "frame based" video and sound timing. The emulator processes quickly all that it is needeed for each frame at 50 or 60 Hz. On the video "side", I only record if an horizontal scrolling is done on a specific frame that allows the display to achieve scanline scrolling. But it seems that others action are done between scanline. For example Space Harrier seems to set some colors during display (the color of the sky of the 1st level is green while it is supposed to be blue...).
A simple solution is to "scanline base" produce the display in the video buffer and should be done quite easily.

On the sound side, the 50 or 60Hz seems to be fully sufficient to produce sounds and music except samples. I use SDL and the sample callback is done around 85Hz, that is more than the 50/60Hz.
What about samples ? Thez are logically not played at all. If I use a "scanline based" timing, the loop refresh rate will be 60*262 or 50*131 that is around 15.7 KHz.
Will it be sufficient for sample playing ?

Thanks !

you mean 50×313

by the way, why not aiming for cycle accuracy? If it runs on modern computers it's not overkilling...

Line need rendering is fine so long as you capture the line settings at the right point, in reality they are read at an exact cycle position in the 228 for each line. It will sound pretty terrible for audio, best is to capture the clock timing at the point of each PSG write and then emulate enough audio samples to reach that time, before applying the write to the PSG, then catch up any remaining time at the end of the frame. Emulating at a higher frequency and downsampling would be most accurate, but more work.

Author	Message
cgyed.cgyed Joined: 10 Feb 2020 Posts: 6	Emulator timing and samples Posted: Wed Sep 16, 2020 9:08 am
cgyed.cgyed Joined: 10 Feb 2020 Posts: 6	Hello, I continue the development of my SMS emulator. It runs now some games that does not require any exotic features : Alex kidd in Miracle World, Sonic 1, etc. Any undeveloped features : codemaster mappers / sprite overflow and collision flags / others than VPD mode 4 / etc. An important limitation is the "frame based" video and sound timing. The emulator processes quickly all that it is needeed for each frame at 50 or 60 Hz. On the video "side", I only record if an horizontal scrolling is done on a specific frame that allows the display to achieve scanline scrolling. But it seems that others action are done between scanline. For example Space Harrier seems to set some colors during display (the color of the sky of the 1st level is green while it is supposed to be blue...). A simple solution is to "scanline base" produce the display in the video buffer and should be done quite easily. On the sound side, the 50 or 60Hz seems to be fully sufficient to produce sounds and music except samples. I use SDL and the sample callback is done around 85Hz, that is more than the 50/60Hz. What about samples ? Thez are logically not played at all. If I use a "scanline based" timing, the loop refresh rate will be 60262 or 50131 that is around 15.7 KHz. Will it be sufficient for sample playing ? Thanks !

sverx Joined: 05 Sep 2013 Posts: 3811 Location: Stockholm, Sweden	Posted: Wed Sep 16, 2020 9:28 am
	you mean 50×313 by the way, why not aiming for cycle accuracy? If it runs on modern computers it's not overkilling...

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14732 Location: London	Posted: Wed Sep 16, 2020 1:03 pm
	Line need rendering is fine so long as you capture the line settings at the right point, in reality they are read at an exact cycle position in the 228 for each line. It will sound pretty terrible for audio, best is to capture the clock timing at the point of each PSG write and then emulate enough audio samples to reach that time, before applying the write to the PSG, then catch up any remaining time at the end of the frame. Emulating at a higher frequency and downsampling would be most accurate, but more work.

Forums

View topic - Emulator timing and samples