Forums

As I was researching a practical/solid way of detecting a SMS VDP connected to a MSX computer (Franky/PlaySoniq, for the vgmplay-msx project) I discovered a consistent register behavior on the SMS VDPs which can be useful for detecting the video frequency:

As you guys are aware of, the TMS9xxx VDPs (TMS9918/9928/9929/9118/9128/9129) have a function which allows it to synchronize with external video source for superimposing. The SMS VDP also have that feature, which is used on the SYSTEM E arcade board to make two SMS VDPs operate synchronized.

What I discovered is that when you have a single VDP you have no synchronization input for the extvideo mode. So the internal raster of the VDP will sit at a corner of screen without traversing. That makes the vertical counter stop at a fixed value, which is:

0xBA for 50Hz
0xD5 for 60Hz

By masking out the IRQ, setting extvideo on briefly, waiting a little while (for the counter to reach that value) and checking the vertical counter value you can tell what vertical frequency the VDP is set as.

Clearing extvideo makes the counter resume normal behavior.

This behavior was consistent on 315-5124 and 315-5246, I don't know if it works on newer chips. Also, I am assuming this doesn't work on the Game Gear.

Some more findings;

0xBA corresponds to the sync start line of PAL 256x192 (-70)
0xD5 corresponds to the sync start line of NTSC 256x192 (-43)

So before testing for this you also need to set a 256x192 mode.

Additionally, after setting EXTVID, the v-counter either changed immediately or after 20 µs. I didn’t see any intermediate values, but either way, you gotta wait a bit for it to determine that it’s lost sync and reset the counter.

That is an interesting way to check 50/60, very cool find !

Another option is to just count numbers throughout a frame, 50Hz will count higher compared to 60Hz.

What's the exact behaviour if EXTVID is on and there's no external video? Is it that the VDP halts before generating vertical sync, awaiting detection of an external sync, and resumes from where it is as soon as EXTVID is toggled back off?

If so then it should be possible to generate an interlaced array. Thinking extemporaneously, enable EXTVID for half a line, then disable it, then wait for the duration of vertical sync, then do the same for odd frames, and just enable it for an entire line then disable it and forget about it for evens.

TmEE wrote

That is an interesting way to check 50/60, very cool find !

Another option is to just count numbers throughout a frame, 50Hz will count higher compared to 60Hz.

We were looking for a consistent way of testing for the presence of a SMS VDP. The ports 88h/89h on MSX are used for an alternative V9938 VDP for a external MSX2 upgrade kit. (cartridge based) So an deterministic way of discerning the SMS VDP apart from a regular TMS9xxx or V9938 was necessary. What I was looking for with this was a way of using the presence of the SEGA VDP V counter as indicative of a Franky cartridge presence. Discovering that we can tell NTSC apart from PAL was actually a nice bonus on this.

TomHarte wrote

What's the exact behaviour if EXTVID is on and there's no external video? Is it that the VDP halts before generating vertical sync, awaiting detection of an external sync, and resumes from where it is as soon as EXTVID is toggled back off?

Going by what I observed from the v-counter, when the sync is lost (near immediately), it resets to the start of the vertical sync and stays there. I reckon it stays because this reset just happens continuously as long as no sync is detected.

Once EXTVID is disabled it resumes. I presume it resumes immediately from right there at the start of vertical sync and not at some other place.

Apparently, when on EXTVIDEO mode, the H-L pin (the pin which causes the H counter latch the raster position) becomes the sync input for the VDP. On the particular case of a MSX computer where the pin is left disconnected there is no chance of a mistake on the detection. That might be a different story on a actual Master System with a Light Phaser gun connected to. It would be interesting if we were to perform some testing with this later on.

Coming back to this, I'm trying to reproduce the " freeze vcounter " trick, but to no avail thus far :/

The reason I'm interested in this is that, according to the VDP decap core, the Y scroll value gets latched specifically on dot 488 of scanline 511.
If we can reset the vcounter to $1D5 at will, it would be possible to force reload the Y scroll value mid-screen.

The description of the H-L pin being related to CSYNC generation doesn't seem to make much sense to me, especially since the decap clearly shows that the CSYNC pad is both an input and an open-drain output.

I'm attaching the test ROM I've been trying to make work (excuse the weird extension, it really is a SMS ROM. Just rename it). What it does is:
- Poll vcounter and wait for scanline 100
- Enable external CSYNC
- Execute a few hundred nops
- Read and print the value from vcounter

What I expected is that it would be $1D5 plus however many scanlines have passed, but instead I consistently get 110, which is the same thing that happens on Emulicious.

vcount_force_load .bps (32 KB)

Trirosmos wrote

instead I consistently get 110

you mean it's stuck at 110? it's actually 'freezed'?

sverx wrote

Trirosmos wrote

instead I consistently get 110

you mean it's stuck at 110? it's actually 'freezed'?

No, I mean the vcounter keeps counting as normal.
I'm nop'ing for roughly 10 scanlines, so I always get 110.

Trirosmos wrote

sverx wrote

Trirosmos wrote

instead I consistently get 110

you mean it's stuck at 110? it's actually 'freezed'?

No, I mean the vcounter keeps counting as normal.
I'm nop'ing for roughly 10 scanlines, so I always get 110.

And it doesn't stop later when it reaches

Quote

0xBA for 50Hz
0xD5 for 60Hz

?

Trirosmos wrote

Coming back to this, I'm trying to reproduce the " freeze vcounter " trick, but to no avail thus far :/

The reason I'm interested in this is that, according to the VDP decap core, the Y scroll value gets latched specifically on dot 488 of scanline 511.
If we can reset the vcounter to $1D5 at will, it would be possible to force reload the Y scroll value mid-screen.

The description of the H-L pin being related to CSYNC generation doesn't seem to make much sense to me, especially since the decap clearly shows that the CSYNC pad is both an input and an open-drain output.

I'm attaching the test ROM I've been trying to make work (excuse the weird extension, it really is a SMS ROM. Just rename it). What it does is:
- Poll vcounter and wait for scanline 100
- Enable external CSYNC
- Execute a few hundred nops
- Read and print the value from vcounter

What I expected is that it would be $1D5 plus however many scanlines have passed, but instead I consistently get 110, which is the same thing that happens on Emulicious.

It may work if you disconnect the VDP pin 35 and leave it disconnected. When I got this to work it was on a MSX computer with a Franky cartridge, it's not exactly the same thing as a Master System. hehe

l_oliveira wrote

It may work if you disconnect the VDP pin 35 and leave it disconnected. When I got this to work it was on a MSX computer with a Franky cartridge, it's not exactly the same thing as a Master System. hehe

Ah, I see.
I believe the SMS VDP behavior in this regard is different from the TMS9918 at least, so it might also be different from the MSX VDP.

sverx wrote

Trirosmos wrote

sverx wrote

Trirosmos wrote

instead I consistently get 110

you mean it's stuck at 110? it's actually 'freezed'?

No, I mean the vcounter keeps counting as normal.
I'm nop'ing for roughly 10 scanlines, so I always get 110.

And it doesn't stop later when it reaches

Quote

0xBA for 50Hz
0xD5 for 60Hz
?

That's not how it works, supposedly.

From running simulations with the Nuked SMS VDP core, I discovered the following:
- Both the internal hcounter and vcounter are 9-bit wide, as you'd expect.
- hcounter counts from $00-$127, then gets reloaded with $1D2, counts until $1FF and wraps around to 0.
- When external CSYNC is disabled, i.e, when running the VDP normally, the vcounter gets reloaded when hcounter == 490. Usually, it gets reloaded with old_vcounter + 1, but after scanline $DA, it gets reloaded with $1D5, as was already known.
- When external CSYNC is enabled, the hcounter immediately (within two pixels, because of pipeline latency) gets loaded with 466 and then keeps counting normally. vcounter also gets incremented as normal once hcounter reaches 490. However, right after that, when hcounter reaches 504, vcounter gets reloaded with $1D5. From that point onwards, whenever hcounter reaches 350, it gets reloaded with 266, so it never reaches 488 again and vcounter is never incremented again, until you disable external CSYNC or the external CSYNC signal goes low.

What I'm not sure about is what the value of external CSYNC is on the SMS. The CSYNC output port is open drain, and the schematics show that there is an external pull up as required, which should mean that external CSYNC is high, usually, which... should mean this trick would work?

Just to be sure, I changed the ROM so that it:
- Waits for scanline 100.
- Enables external CSYNC.
- Waits for scanline $DA
- Waits for scanline counter to jump to $D5.
- Executes nops for approximately 10 scanlines.
- Reads and prints the scanline counter.
- Disables external CSYNC.

So, if it worked, I should be getting $D5 or 213 on the read out, meaning that the vcounter got frozen for around 10 scanlines. But instead I'm getting 223, meaning the counter was still incrementing during that time.

vcount_force_load_wait_for_D5.bps (32 KB)

It might sound weird to say this but Nuked SMS might not be a good test case for this because leaving the pin disconnected on the real chip is a physical thing you would need to be able to reproduce properly in a software model for emulation sake. I don't know if the floating pin assumes a certain voltage or changes state in a random way.

The NukedSMS is a emulator, it will reproduce only the logic states portion of the situation, not the physical world part of it. And on this state it is being put to work on a out of normal state configuration. I think you can safely ignore this "method" as it was long ago discarded as non practical.

You can't really count on the behavior of a pin that was left disconnected being something stable.

l_oliveira wrote

It might sound weird to say this but Nuked SMS might not be a good test case for this because leaving the pin disconnected on the real chip is a physical thing you would need to be able to reproduce properly in a software model for emulation sake. I don't know if the floating pin assumes a certain voltage or changes state in a random way.

The NukedSMS is a emulator, it will reproduce only the logic states portion of the situation, not the physical world part of it. And on this state it is being put to work on a out of normal state configuration. I think you can safely ignore this "method" as it was long ago discarded as non practical.

You can't really count on the behavior of a pin that was left disconnected being something stable.

But like I said, the H-L pin definitely has nothing to do with this and reading Nuked SMS confirms that it doesn't get anywhere near the CSYNC generation circuitry :)

The CSYNC pin just becomes an input when external CSYNC mode is activated. And, again, there's an external pull up and the output port on that pad is open drain, so.

Anyway, the method is not practical and has been proven to be dependent on how the chip is wired up. Thank you for confirming the real input is CSYNC then. You can test it with the VDP while it is not being the main output of the video, which was the case on the MSX while I was testing. Disconnect CSYNC and try. Of course if it is the main video source for you, this method cannot really be used.

In fact I had nothing connected to the SMS VDP video outputs while testing that because at the time I was trying to find a reliable method of testing if it was a SMS VDP as in the MSX the port assigned for the SMS VDP on the Franky design is the same as an alternative V9938 VDP, the test was check for the presence of the SMS H/V counters instead of checking for VRAM being present as it was being done before (the V9938 passes the VRAM check of course as it's backwards compatible with TMS9918). My goal was detecting a SMS VDP (Franky) to know if a SN76489 would be available or not.

Author	Message
l_oliveira Joined: 29 Jan 2014 Posts: 95 Location: Brasilia, Brazil	Practical way of detecting the video Hz on SMS Posted: Sun Jan 20, 2019 9:43 pm
	As I was researching a practical/solid way of detecting a SMS VDP connected to a MSX computer (Franky/PlaySoniq, for the vgmplay-msx project) I discovered a consistent register behavior on the SMS VDPs which can be useful for detecting the video frequency: As you guys are aware of, the TMS9xxx VDPs (TMS9918/9928/9929/9118/9128/9129) have a function which allows it to synchronize with external video source for superimposing. The SMS VDP also have that feature, which is used on the SYSTEM E arcade board to make two SMS VDPs operate synchronized. What I discovered is that when you have a single VDP you have no synchronization input for the extvideo mode. So the internal raster of the VDP will sit at a corner of screen without traversing. That makes the vertical counter stop at a fixed value, which is: 0xBA for 50Hz 0xD5 for 60Hz By masking out the IRQ, setting extvideo on briefly, waiting a little while (for the counter to reach that value) and checking the vertical counter value you can tell what vertical frequency the VDP is set as. Clearing extvideo makes the counter resume normal behavior. This behavior was consistent on 315-5124 and 315-5246, I don't know if it works on newer chips. Also, I am assuming this doesn't work on the Game Gear.

Grauw Joined: 24 Mar 2018 Posts: 6	Posted: Sun Jan 20, 2019 10:34 pm
Grauw Joined: 24 Mar 2018 Posts: 6	Some more findings; 0xBA corresponds to the sync start line of PAL 256x192 (-70) 0xD5 corresponds to the sync start line of NTSC 256x192 (-43) So before testing for this you also need to set a 256x192 mode. Additionally, after setting EXTVID, the v-counter either changed immediately or after 20 µs. I didn’t see any intermediate values, but either way, you gotta wait a bit for it to determine that it’s lost sync and reset the counter.

TmEE Joined: 31 Oct 2007 Posts: 853 Location: Estonia, Rapla city	Posted: Mon Jan 21, 2019 8:28 pm
	That is an interesting way to check 50/60, very cool find ! Another option is to just count numbers throughout a frame, 50Hz will count higher compared to 60Hz.

TomHarte Joined: 24 Sep 2018 Posts: 66	Posted: Tue Jan 22, 2019 2:35 am
TomHarte Joined: 24 Sep 2018 Posts: 66	What's the exact behaviour if EXTVID is on and there's no external video? Is it that the VDP halts before generating vertical sync, awaiting detection of an external sync, and resumes from where it is as soon as EXTVID is toggled back off? If so then it should be possible to generate an interlaced array. Thinking extemporaneously, enable EXTVID for half a line, then disable it, then wait for the duration of vertical sync, then do the same for odd frames, and just enable it for an entire line then disable it and forget about it for evens.

l_oliveira Joined: 29 Jan 2014 Posts: 95 Location: Brasilia, Brazil	Posted: Tue Jan 22, 2019 5:08 pm
	TmEE wrote That is an interesting way to check 50/60, very cool find ! Another option is to just count numbers throughout a frame, 50Hz will count higher compared to 60Hz. We were looking for a consistent way of testing for the presence of a SMS VDP. The ports 88h/89h on MSX are used for an alternative V9938 VDP for a external MSX2 upgrade kit. (cartridge based) So an deterministic way of discerning the SMS VDP apart from a regular TMS9xxx or V9938 was necessary. What I was looking for with this was a way of using the presence of the SEGA VDP V counter as indicative of a Franky cartridge presence. Discovering that we can tell NTSC apart from PAL was actually a nice bonus on this.

Grauw Joined: 24 Mar 2018 Posts: 6	Posted: Fri Jan 25, 2019 1:54 pm
Grauw Joined: 24 Mar 2018 Posts: 6	TomHarte wrote What's the exact behaviour if EXTVID is on and there's no external video? Is it that the VDP halts before generating vertical sync, awaiting detection of an external sync, and resumes from where it is as soon as EXTVID is toggled back off? Going by what I observed from the v-counter, when the sync is lost (near immediately), it resets to the start of the vertical sync and stays there. I reckon it stays because this reset just happens continuously as long as no sync is detected. Once EXTVID is disabled it resumes. I presume it resumes immediately from right there at the start of vertical sync and not at some other place.

l_oliveira Joined: 29 Jan 2014 Posts: 95 Location: Brasilia, Brazil	Posted: Fri Jan 25, 2019 3:34 pm
	Apparently, when on EXTVIDEO mode, the H-L pin (the pin which causes the H counter latch the raster position) becomes the sync input for the VDP. On the particular case of a MSX computer where the pin is left disconnected there is no chance of a mistake on the detection. That might be a different story on a actual Master System with a Light Phaser gun connected to. It would be interesting if we were to perform some testing with this later on.

Trirosmos Joined: 26 Apr 2022 Posts: 29 Location: Brinstar, Zebes	Posted: Mon Feb 26, 2024 1:52 pm
	Coming back to this, I'm trying to reproduce the " freeze vcounter " trick, but to no avail thus far :/ The reason I'm interested in this is that, according to the VDP decap core, the Y scroll value gets latched specifically on dot 488 of scanline 511. If we can reset the vcounter to $1D5 at will, it would be possible to force reload the Y scroll value mid-screen. The description of the H-L pin being related to CSYNC generation doesn't seem to make much sense to me, especially since the decap clearly shows that the CSYNC pad is both an input and an open-drain output. I'm attaching the test ROM I've been trying to make work (excuse the weird extension, it really is a SMS ROM. Just rename it). What it does is: - Poll vcounter and wait for scanline 100 - Enable external CSYNC - Execute a few hundred nops - Read and print the value from vcounter What I expected is that it would be $1D5 plus however many scanlines have passed, but instead I consistently get 110, which is the same thing that happens on Emulicious. vcount_force_load .bps (32 KB)

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Mon Feb 26, 2024 1:58 pm
	Trirosmos wrote instead I consistently get 110 you mean it's stuck at 110? it's actually 'freezed'?

Trirosmos Joined: 26 Apr 2022 Posts: 29 Location: Brinstar, Zebes	Posted: Mon Feb 26, 2024 2:48 pm
	sverx wrote Trirosmos wrote instead I consistently get 110 you mean it's stuck at 110? it's actually 'freezed'? No, I mean the vcounter keeps counting as normal. I'm nop'ing for roughly 10 scanlines, so I always get 110.

sverx Joined: 05 Sep 2013 Posts: 3827 Location: Stockholm, Sweden	Posted: Mon Feb 26, 2024 2:50 pm
	Trirosmos wrote sverx wrote Trirosmos wrote instead I consistently get 110 you mean it's stuck at 110? it's actually 'freezed'? No, I mean the vcounter keeps counting as normal. I'm nop'ing for roughly 10 scanlines, so I always get 110. And it doesn't stop later when it reaches Quote 0xBA for 50Hz 0xD5 for 60Hz ?

l_oliveira Joined: 29 Jan 2014 Posts: 95 Location: Brasilia, Brazil	Posted: Mon Feb 26, 2024 4:17 pm
	Trirosmos wrote Coming back to this, I'm trying to reproduce the " freeze vcounter " trick, but to no avail thus far :/ The reason I'm interested in this is that, according to the VDP decap core, the Y scroll value gets latched specifically on dot 488 of scanline 511. If we can reset the vcounter to $1D5 at will, it would be possible to force reload the Y scroll value mid-screen. The description of the H-L pin being related to CSYNC generation doesn't seem to make much sense to me, especially since the decap clearly shows that the CSYNC pad is both an input and an open-drain output. I'm attaching the test ROM I've been trying to make work (excuse the weird extension, it really is a SMS ROM. Just rename it). What it does is: - Poll vcounter and wait for scanline 100 - Enable external CSYNC - Execute a few hundred nops - Read and print the value from vcounter What I expected is that it would be $1D5 plus however many scanlines have passed, but instead I consistently get 110, which is the same thing that happens on Emulicious. It may work if you disconnect the VDP pin 35 and leave it disconnected. When I got this to work it was on a MSX computer with a Franky cartridge, it's not exactly the same thing as a Master System. hehe

Trirosmos Joined: 26 Apr 2022 Posts: 29 Location: Brinstar, Zebes	Posted: Mon Feb 26, 2024 4:54 pm
	l_oliveira wrote It may work if you disconnect the VDP pin 35 and leave it disconnected. When I got this to work it was on a MSX computer with a Franky cartridge, it's not exactly the same thing as a Master System. hehe Ah, I see. I believe the SMS VDP behavior in this regard is different from the TMS9918 at least, so it might also be different from the MSX VDP. sverx wrote Trirosmos wrote sverx wrote Trirosmos wrote instead I consistently get 110 you mean it's stuck at 110? it's actually 'freezed'? No, I mean the vcounter keeps counting as normal. I'm nop'ing for roughly 10 scanlines, so I always get 110. And it doesn't stop later when it reaches Quote 0xBA for 50Hz 0xD5 for 60Hz ? That's not how it works, supposedly. From running simulations with the Nuked SMS VDP core, I discovered the following: - Both the internal hcounter and vcounter are 9-bit wide, as you'd expect. - hcounter counts from $00-$127, then gets reloaded with $1D2, counts until $1FF and wraps around to 0. - When external CSYNC is disabled, i.e, when running the VDP normally, the vcounter gets reloaded when hcounter == 490. Usually, it gets reloaded with old_vcounter + 1, but after scanline $DA, it gets reloaded with $1D5, as was already known. - When external CSYNC is enabled, the hcounter immediately (within two pixels, because of pipeline latency) gets loaded with 466 and then keeps counting normally. vcounter also gets incremented as normal once hcounter reaches 490. However, right after that, when hcounter reaches 504, vcounter gets reloaded with $1D5. From that point onwards, whenever hcounter reaches 350, it gets reloaded with 266, so it never reaches 488 again and vcounter is never incremented again, until you disable external CSYNC or the external CSYNC signal goes low. What I'm not sure about is what the value of external CSYNC is on the SMS. The CSYNC output port is open drain, and the schematics show that there is an external pull up as required, which should mean that external CSYNC is high, usually, which... should mean this trick would work? Just to be sure, I changed the ROM so that it: - Waits for scanline 100. - Enables external CSYNC. - Waits for scanline $DA - Waits for scanline counter to jump to $D5. - Executes nops for approximately 10 scanlines. - Reads and prints the scanline counter. - Disables external CSYNC. So, if it worked, I should be getting $D5 or 213 on the read out, meaning that the vcounter got frozen for around 10 scanlines. But instead I'm getting 223, meaning the counter was still incrementing during that time. vcount_force_load_wait_for_D5.bps (32 KB)

l_oliveira Joined: 29 Jan 2014 Posts: 95 Location: Brasilia, Brazil	Posted: Mon Feb 26, 2024 5:38 pm
	It might sound weird to say this but Nuked SMS might not be a good test case for this because leaving the pin disconnected on the real chip is a physical thing you would need to be able to reproduce properly in a software model for emulation sake. I don't know if the floating pin assumes a certain voltage or changes state in a random way. The NukedSMS is a emulator, it will reproduce only the logic states portion of the situation, not the physical world part of it. And on this state it is being put to work on a out of normal state configuration. I think you can safely ignore this "method" as it was long ago discarded as non practical. You can't really count on the behavior of a pin that was left disconnected being something stable.

Trirosmos Joined: 26 Apr 2022 Posts: 29 Location: Brinstar, Zebes	Posted: Mon Feb 26, 2024 5:45 pm
	l_oliveira wrote It might sound weird to say this but Nuked SMS might not be a good test case for this because leaving the pin disconnected on the real chip is a physical thing you would need to be able to reproduce properly in a software model for emulation sake. I don't know if the floating pin assumes a certain voltage or changes state in a random way. The NukedSMS is a emulator, it will reproduce only the logic states portion of the situation, not the physical world part of it. And on this state it is being put to work on a out of normal state configuration. I think you can safely ignore this "method" as it was long ago discarded as non practical. You can't really count on the behavior of a pin that was left disconnected being something stable. But like I said, the H-L pin definitely has nothing to do with this and reading Nuked SMS confirms that it doesn't get anywhere near the CSYNC generation circuitry :) The CSYNC pin just becomes an input when external CSYNC mode is activated. And, again, there's an external pull up and the output port on that pad is open drain, so.

l_oliveira Joined: 29 Jan 2014 Posts: 95 Location: Brasilia, Brazil	Posted: Mon Feb 26, 2024 6:05 pm
	Anyway, the method is not practical and has been proven to be dependent on how the chip is wired up. Thank you for confirming the real input is CSYNC then. You can test it with the VDP while it is not being the main output of the video, which was the case on the MSX while I was testing. Disconnect CSYNC and try. Of course if it is the main video source for you, this method cannot really be used. In fact I had nothing connected to the SMS VDP video outputs while testing that because at the time I was trying to find a reliable method of testing if it was a SMS VDP as in the MSX the port assigned for the SMS VDP on the Franky design is the same as an alternative V9938 VDP, the test was check for the presence of the SMS H/V counters instead of checking for VRAM being present as it was being done before (the V9938 passes the VRAM check of course as it's backwards compatible with TMS9918). My goal was detecting a SMS VDP (Franky) to know if a SN76489 would be available or not.

Forums

View topic - Practical way of detecting the video Hz on SMS