Forums

The SN76489AN datasheet mentions that it can only accept writes every 32 cycles - meaning the same clock cycles as the CPU - and there was a post recently mentioning that the chip's READY pin was attached to the Z80's /WAIT in an SG-1000 to enforce this. This suggests that writing to the PSG on that system will slow the CPU. Has anyone confirmed this? You can test it in software by writing to the PSG and then counting how many writes you achieve between two frame interrupts.

It also occurred to me that Master System games very often write to the PSG much faster than this limit. This means that one of these must be true:

* The Sega VDP PSG does not need this 32 cycle window. The original chip divides the clock by 8 on entry, maybe the Sega PSG instead scales the counters so it can operate at 3.5MHz internally?
* It's buffered - seems unlikely
* It is also halting the CPU, meaning any code cycle counting around PSG writes needs to be adjusted accordingly

The same loop counting test could check if the last one is true. I'm hoping it's the first one.

I suspect that only 4 cycles are needed (32/8) - thus making that fast enough for any OUTx opcode...

The original chip does it in 4 internal cycles, so if the Sega version can do it in 4 external cycles that would make it a non issue. Is there any connection from the VDP chip to /WAIT?

Maxim wrote

Is there any connection from the VDP chip to /WAIT?

Not on the schematic; it's not as detailed as a real circuit diagram but the Z80 is in the lower left and WAIT appears to be connected only to the cartridge port.

I can confirm on the SC-3000 that the Z80 is paused via /WAIT when you write to the PSG. This should hold true for any system with a discrete SN76489A.

In fact that could be one way to determine if you are running on a SG-1000 / SC-3000 / early SG-1000 II console vs the later SG-1000 II with the integrated chipset / Mark 3 / SMS.

If I had to guess, I think the issue is that the SN76489A samples the control bus synchronously, once every 32 cycles, looking for a valid combination of CE# and WE# and then loading the data bus content into the internal registers accordingly. The application software can't know when this happens (especially if the CPU and PSG are clocked at different speeds), so instead the PSG inserts wait states for 32 cycles via READY. This ensures that the control bus and data bus present valid data for a minimum of 32 cycles, and within that interval the sampling is guaranteed to happen once.

When Sega reworked the PSG to be integrated into their hardware it seems likely they changed the interface to alleviate this delay, probably making it an asynchronous interface so data can be changed at any time and the PSG will pick up the changes when it can get to it. I guess the question is exactly how fast does that happen, we'd need to write to the PSG faster than the SMS can to find that upper limit. Or maybe there is no limit and data written updates the internal state immediately.

It could be interesting to play sampled audio on the Genesis, using the 68000 to write to the PSG more rapidly than the Z80 could. Or System E where the Z80 is running at 5.36 MHz instead of 3.58 MHz.

I can envision a situation where an overclocked Z80 in an otherwise standard SMS system wouldn't work consistently at any speed as the VDP and Z80 clocks would drift in and out of phase and the window where the buffered data is sampled wouldn't sync up with the write cycle. This is exactly what the READY output on the SN76489A solves and allows complete independence between how the PSG and host CPU are clocked. Sega's improvements may have re-introduced that issue but it's not a problem because the Z80 and VDP clocks are always derived from the same source and won't drift.

Author	Message
Maxim Site Admin Joined: 19 Oct 1999 Posts: 14741 Location: London	SN76489/Sega PSG and CPU waits Posted: Wed Oct 24, 2018 8:21 am
	The SN76489AN datasheet mentions that it can only accept writes every 32 cycles - meaning the same clock cycles as the CPU - and there was a post recently mentioning that the chip's READY pin was attached to the Z80's /WAIT in an SG-1000 to enforce this. This suggests that writing to the PSG on that system will slow the CPU. Has anyone confirmed this? You can test it in software by writing to the PSG and then counting how many writes you achieve between two frame interrupts. It also occurred to me that Master System games very often write to the PSG much faster than this limit. This means that one of these must be true: * The Sega VDP PSG does not need this 32 cycle window. The original chip divides the clock by 8 on entry, maybe the Sega PSG instead scales the counters so it can operate at 3.5MHz internally? * It's buffered - seems unlikely * It is also halting the CPU, meaning any code cycle counting around PSG writes needs to be adjusted accordingly The same loop counting test could check if the last one is true. I'm hoping it's the first one.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Wed Oct 24, 2018 10:04 am
	I suspect that only 4 cycles are needed (32/8) - thus making that fast enough for any OUTx opcode...

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14741 Location: London	Posted: Wed Oct 24, 2018 12:28 pm
	The original chip does it in 4 internal cycles, so if the Sega version can do it in 4 external cycles that would make it a non issue. Is there any connection from the VDP chip to /WAIT?

TomHarte Joined: 24 Sep 2018 Posts: 66	Posted: Wed Oct 24, 2018 3:38 pm
TomHarte Joined: 24 Sep 2018 Posts: 66	Maxim wrote Is there any connection from the VDP chip to /WAIT? Not on the schematic; it's not as detailed as a real circuit diagram but the Z80 is in the lower left and WAIT appears to be connected only to the cartridge port.

Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Posted: Sun Nov 11, 2018 5:06 am
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	I can confirm on the SC-3000 that the Z80 is paused via /WAIT when you write to the PSG. This should hold true for any system with a discrete SN76489A. In fact that could be one way to determine if you are running on a SG-1000 / SC-3000 / early SG-1000 II console vs the later SG-1000 II with the integrated chipset / Mark 3 / SMS. If I had to guess, I think the issue is that the SN76489A samples the control bus synchronously, once every 32 cycles, looking for a valid combination of CE# and WE# and then loading the data bus content into the internal registers accordingly. The application software can't know when this happens (especially if the CPU and PSG are clocked at different speeds), so instead the PSG inserts wait states for 32 cycles via READY. This ensures that the control bus and data bus present valid data for a minimum of 32 cycles, and within that interval the sampling is guaranteed to happen once. When Sega reworked the PSG to be integrated into their hardware it seems likely they changed the interface to alleviate this delay, probably making it an asynchronous interface so data can be changed at any time and the PSG will pick up the changes when it can get to it. I guess the question is exactly how fast does that happen, we'd need to write to the PSG faster than the SMS can to find that upper limit. Or maybe there is no limit and data written updates the internal state immediately. It could be interesting to play sampled audio on the Genesis, using the 68000 to write to the PSG more rapidly than the Z80 could. Or System E where the Z80 is running at 5.36 MHz instead of 3.58 MHz. I can envision a situation where an overclocked Z80 in an otherwise standard SMS system wouldn't work consistently at any speed as the VDP and Z80 clocks would drift in and out of phase and the window where the buffered data is sampled wouldn't sync up with the write cycle. This is exactly what the READY output on the SN76489A solves and allows complete independence between how the PSG and host CPU are clocked. Sega's improvements may have re-introduced that issue but it's not a problem because the Z80 and VDP clocks are always derived from the same source and won't drift.

Forums

View topic - SN76489/Sega PSG and CPU waits