SNES native 3D performance ST-NICC no SFX demo

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
User avatar
Bregalad
Posts: 7951
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: SNES native 3D performance ST-NICC no SFX demo

Post by Bregalad » Mon Aug 24, 2020 9:17 am

Oziphantom wrote:
Mon Aug 24, 2020 1:20 am
which of cause gets problems because Chrono Trigger and Final Fantasy 6 are "NTSC Exclusives" but could actually work on a PAL machine 100% fine, they just couldn't be bothered. But what it means is "NTSC Region Exclusive"
Bad exemple, FInal Fantasy 6 actually can randomly freeze when played unpatched on a PAL console, most notably when opening the menu if my memory is right. But there's a patch making it run fine.

Chrono Trigger works perfect on a PAL console.

On the top of that, you have to add games that explicitly refuses to boot if they detect a PPU from the wrong region. This security can be there or absent regardless of whether the game runs well or not on a console from the wrong region. For example Donkey Kong Country refuses to run on the wrong region, but it would work just fine. Here in PAL lands we have unofficials adaptors that allows us to play a NTSC game on a PAL console by using the CIC from the PAL game, and some of the adaptors also makes the SNES game belive it runs on a NTSC console, but this breaks some PAL games.
This is very confusing to explain.
Brazil uses 60Hz video. Labelling it "PAL" is pedantically true but misleading.
You also have to know that most of the world did not get official releases in their respective countries and either had to import from richer countries or to use clones.
I'm fairly sure there is no SECAM SNES it's just a PAL one.
Indeed the French gaming material are just PAL consoles and games. Some games had an horrendoulsly bad French translation (*). If anything the video signal was modified at a latter stage, or perhaps there was modified PAL consoles. In call cases, just like PAL-M, it is irrelevant for software. As such, I agree using "50Hz" and "60Hz" makes more sense than talking about NTSC and PAL.

(*) It makes me laugh when the American public complains how retro games were poorly translated from Japanese to English, because what we got was much, much worse.
Useless, lumbering half-wits don't scare us.

Oziphantom
Posts: 913
Joined: Tue Feb 07, 2017 2:03 am

Re: SNES native 3D performance ST-NICC no SFX demo

Post by Oziphantom » Mon Aug 24, 2020 9:43 am

Bregalad wrote:
Mon Aug 24, 2020 9:17 am
Oziphantom wrote:
Mon Aug 24, 2020 1:20 am
which of cause gets problems because Chrono Trigger and Final Fantasy 6 are "NTSC Exclusives" but could actually work on a PAL machine 100% fine, they just couldn't be bothered. But what it means is "NTSC Region Exclusive"
Bad exemple, FInal Fantasy 6 actually can randomly freeze when played unpatched on a PAL console, most notably when opening the menu if my memory is right. But there's a patch making it run fine.

Chrono Trigger works perfect on a PAL console.
Interesting, seems to be a music end error. The slower clock vs the music clock stuffs it up?
My intention was more, the game will work ported to PAL just fine, even having things move slower wouldn't even be an issue, as it would in say a fast action game.
Bregalad wrote:
Mon Aug 24, 2020 9:17 am
On the top of that, you have to add games that explicitly refuses to boot if they detect a PPU from the wrong region. This security can be there or absent regardless of whether the game runs well or not on a console from the wrong region. For example Donkey Kong Country refuses to run on the wrong region, but it would work just fine. Here in PAL lands we have unofficials adaptors that allows us to play a NTSC game on a PAL console by using the CIC from the PAL game, and some of the adaptors also makes the SNES game belive it runs on a NTSC console, but this breaks some PAL games.
This is very confusing to explain.
Action Replay to the rescue!. Region locking and copy protection where issues. I think DKC2 failed to run if you had the AR3 in ( pal copy on a pal machine) due to some "don't copy that floppy" style check. There was an AR code to get around it though :D

lidnariq
Posts: 9659
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: SNES native 3D performance ST-NICC no SFX demo

Post by lidnariq » Mon Aug 24, 2020 1:00 pm

Oziphantom wrote:
Mon Aug 24, 2020 1:22 am
running NTSC at 50fps won't make it work the same as PAL, in that you won't get the PAL demo working on it. FPS is not the issue, Clocks per Frame and VBlank timings are the issue. Which PAL and NTSC mandate.
Why would "NTSC at 50Hz" not work the same as PAL? For most 3rd generation and newer consoles, clocks per scanline¹ is independent of SDTV System... and so, why would the vertical timings not be a function of the field rate?

Argentina (PAL-N) is technically PAL at 50Hz, but it uses a much lower colorburst frequency, such that the UMC famiclone for it uses a standard NTSC NES clone CPU and a special PPU that uses almost the same 21.5MHz clock that the NTSC NES does.

¹There are a number of important consoles I can think where CPU clocks per scanline is tied to the TV system: C64 and the NES - but as time went on it seemed that there was concerted engineering effort to produce a single design that would work almost-the-same in multiple SDTV systems. Other than the unavoidable change of frame rate and the corresponding need for 50 extra scanlines per field.

93143
Posts: 1225
Joined: Fri Jul 04, 2014 9:31 pm

Re: SNES native 3D performance ST-NICC no SFX demo

Post by 93143 » Mon Aug 24, 2020 1:43 pm

Oziphantom wrote:
Mon Aug 24, 2020 1:20 am
The Clock Speed is higher so in a benchmark the SNES NTSC will win when you measure things in how many seconds it takes to do X. Although the SPC 700 has the same clock on both, which means the access windows to and from it are different, it may be that one can get more data into the SPC700 over the other giving potential for different effects more sample data for music.
The clock speed on a PAL SNES is more than 99% of the clock speed on an NTSC SNES. I doubt it makes a material difference...

...except for one factor. The frame time outside VBlank is similar, but the frame rate is lower. If you're heavily exploiting that extra VBlank time, and you're streaming audio data, you need about 6/5 as much streaming time per frame to do the same job, which could crowd out other stuff and hurt performance (but compared to what? Using the extra VBlank likely means what you're doing can't be done on NTSC anyway).

If you're using HDMA audio streaming, PAL has a lower achievable data rate than NTSC regardless of VBlank considerations, because HDMA doesn't run during VBlank, and therefore there are fewer scanlines per second available for HDMA on a PAL SNES. Obviously there are ways around this, but they're messy.

Oziphantom
Posts: 913
Joined: Tue Feb 07, 2017 2:03 am

Re: SNES native 3D performance ST-NICC no SFX demo

Post by Oziphantom » Mon Aug 24, 2020 11:15 pm

lidnariq wrote:
Mon Aug 24, 2020 1:00 pm
Oziphantom wrote:
Mon Aug 24, 2020 1:22 am
running NTSC at 50fps won't make it work the same as PAL, in that you won't get the PAL demo working on it. FPS is not the issue, Clocks per Frame and VBlank timings are the issue. Which PAL and NTSC mandate.
Why would "NTSC at 50Hz" not work the same as PAL? For most 3rd generation and newer consoles, clocks per scanline¹ is independent of SDTV System... and so, why would the vertical timings not be a function of the field rate?

Argentina (PAL-N) is technically PAL at 50Hz, but it uses a much lower colorburst frequency, such that the UMC famiclone for it uses a standard NTSC NES clone CPU and a special PPU that uses almost the same 21.5MHz clock that the NTSC NES does.

¹There are a number of important consoles I can think where CPU clocks per scanline is tied to the TV system: C64 and the NES - but as time went on it seemed that there was concerted engineering effort to produce a single design that would work almost-the-same in multiple SDTV systems. Other than the unavoidable change of frame rate and the corresponding need for 50 extra scanlines per field.
Well how are you slowing down NTSC to 50hz. Does the PPU understand it has more lines, push out a 60hz frame and then hold VBlank for longer, because its internal timings are able to handle counting more lines that it should. I.e it outputs a PAL frame with NTSC colour encoding. Or are you running the normal clocks, then stalling them to halt the next frame until 50hz has happened?

As the cost of game development went up, PAL became a "necessary part of the strategy" rather than "market we can milk some more money out of it we want" so they actually though about us when making things. As the GPUs are their own processors with microcode and multiple bus speeds having it change a clock here and there doesn't really matter any more as things are not sync'd to the external CPU so much.

Oziphantom
Posts: 913
Joined: Tue Feb 07, 2017 2:03 am

Re: SNES native 3D performance ST-NICC no SFX demo

Post by Oziphantom » Mon Aug 24, 2020 11:33 pm

93143 wrote:
Mon Aug 24, 2020 1:43 pm
Oziphantom wrote:
Mon Aug 24, 2020 1:20 am
The Clock Speed is higher so in a benchmark the SNES NTSC will win when you measure things in how many seconds it takes to do X. Although the SPC 700 has the same clock on both, which means the access windows to and from it are different, it may be that one can get more data into the SPC700 over the other giving potential for different effects more sample data for music.
The clock speed on a PAL SNES is more than 99% of the clock speed on an NTSC SNES. I doubt it makes a material difference...

...except for one factor. The frame time outside VBlank is similar, but the frame rate is lower. If you're heavily exploiting that extra VBlank time, and you're streaming audio data, you need about 6/5 as much streaming time per frame to do the same job, which could crowd out other stuff and hurt performance (but compared to what? Using the extra VBlank likely means what you're doing can't be done on NTSC anyway).

If you're using HDMA audio streaming, PAL has a lower achievable data rate than NTSC regardless of VBlank considerations, because HDMA doesn't run during VBlank, and therefore there are fewer scanlines per second available for HDMA on a PAL SNES. Obviously there are ways around this, but they're messy.
Well in Demos Every clock counts. For example the C64 PAL is 63 clocks per line, NTSC is 64 clocks per line. Sounds neither here nor there, 2 clocks on a line, what are you going to do? an extra NOP? Well those extra 2 clocks means you can in some cases get 8 sprites while PAL can only get 7 sprites set up. The PAL clock is 0.985Mhz and the NTSC clock is 1.023Mhz but an extra sprite is a big deal.
Now the 1541/c/ii disk drive runs at 1.00mhz if you are in PAL or NTSC it doesn't change it just 1mhz. So you have PAL loaders and NTSC loaders that as they "run the clocks" need to adjust their timings for the blind reads, so some games won't even load on a PAL let along run because the loader wants NTSC, and vise versa. I imagine this probably does effect max transfer speeds, but that is a Krill question.

lidnariq
Posts: 9659
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: SNES native 3D performance ST-NICC no SFX demo

Post by lidnariq » Tue Aug 25, 2020 12:09 am

Oziphantom wrote:
Mon Aug 24, 2020 11:15 pm
Well how are you slowing down NTSC to 50hz. Does the PPU understand it has more lines, push out a 60hz frame and then hold VBlank for longer, because its internal timings are able to handle counting more lines that it should. I.e it outputs a PAL frame with NTSC colour encoding. Or are you running the normal clocks, then stalling them to halt the next frame until 50hz has happened?
Ok, I see what you mean. I don't know if any consoles supported being entirely paused for the extra 3ms between a system M field and a system B field. The closest I can think of is the Hong Kong Famicom, which has a special IC that pauses only the PPU right after the visible field (and before NMI) for those extra 50 scanlines.

I was thinking of what happens if you took a US SNES (or Megadrive) and made it run at 50Hz by strapping the relevant two pins on the PPUs high (or the one solder jumper for the Megadrive low): you get system B video timing (ish), but the modulator still converts the RGB output to NTSC3.6.

93143
Posts: 1225
Joined: Fri Jul 04, 2014 9:31 pm

Re: SNES native 3D performance ST-NICC no SFX demo

Post by 93143 » Tue Aug 25, 2020 2:18 am

Oziphantom wrote:
Mon Aug 24, 2020 11:33 pm
The PAL clock is 0.985Mhz and the NTSC clock is 1.023Mhz [...] Now the 1541/c/ii disk drive runs at 1.00mhz if you are in PAL or NTSC it doesn't change it just 1mhz. So you have PAL loaders and NTSC loaders that as they "run the clocks" need to adjust their timings for the blind reads, so some games won't even load on a PAL let along run because the loader wants NTSC, and vise versa.
Sounds a bit like the sync problem with audio streaming on SNES. If you want decent bandwidth, it seems to be helpful to avoid using high-granularity double-handshake methods and just use cycle-counted code to stay in sync over large bursts. However, there's a problem: not only is the nominal clock ratio slightly different from NTSC to PAL (~65.0 vs. ~65.6 SPC700 cycles per scanline), but since the APU uses a ceramic oscillator, the frequency (a) isn't consistent between consoles, and (b) drifts. This makes a robust, universal high-data-rate streaming scheme a fairly interesting problem.

User avatar
TmEE
Posts: 760
Joined: Wed Feb 13, 2008 9:10 am
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
Contact:

Re: SNES native 3D performance ST-NICC no SFX demo

Post by TmEE » Tue Aug 25, 2020 10:32 pm

Oziphantom wrote:
Mon Aug 24, 2020 1:22 am
running NTSC at 50fps won't make it work the same as PAL, in that you won't get the PAL demo working on it. FPS is not the issue, Clocks per Frame and VBlank timings are the issue. Which PAL and NTSC mandate.
I primarly meant things on video standard level, most hardware outputs RGB which is neither PAL or NTSC, and is then transcoded to some video format according to the region it sold in, and you can simply switch them between 50 and 60Hz without software being able to tell that it had happened, thus only 50 or 60Hz matters.

TI VDPs, C64 and NES are two major exceptions here of course, being hardwired for particular framerate and output format and timing differences that can be seen by software between the PAL and NTSC parts. Stuff like MD, SMS, SNES and all later things have easy 50/60 change with identical relative timings per line and some others simply have fully programmable video timings like Amstrad CPC and most PC video hardware where you may or may not keep the timings consistent. But even then, I view that 50/60 is the more imporntant aspect, even on the hardwired hardware mentioned and that video standard (all the PAL and NTSC flavors and perhaps even SECAM) is only a side effect.

Of course one can introduce a reference that will allow to compare things against and reveal the difference since absolute timings are different afterall, even though relative timings within the system remain same in most hardware. In SNES you have the SPC clock on most hardware versions (in later single chip ones all is derived from same clock) and the C64 floppy drive example or whatever you put in your custom cartridge etc.

Oziphantom
Posts: 913
Joined: Tue Feb 07, 2017 2:03 am

Re: SNES native 3D performance ST-NICC no SFX demo

Post by Oziphantom » Tue Aug 25, 2020 10:57 pm

In the C64 case its more Commodore made, because it was the 80s it was easier and cheaper to just make different models, so you have
6567 - NTSC
6569 - PAL B
6572 - PAL N
6573 - PAL M
version of the chips. While in the 90s fab process was smaller and it was easier and cheaper to make 1 chip. So the SNES PPUs put PAL and NTSC timing information in 1 chip. Hence you can easily change them. On a C64 you just swap the VIC and cut or solder a jumper.

However like the VICII, are the PPUs the clock masters. So if you switch the PPU to "50hz", does this also modify the clock speeds to be PAL or does the PPU run "50hz" timings, for vblank, hblank, active display etc off the NTSC Master clock? Or does it drop to PAL Master Clock.

Oziphantom
Posts: 913
Joined: Tue Feb 07, 2017 2:03 am

Re: SNES native 3D performance ST-NICC no SFX demo

Post by Oziphantom » Tue Aug 25, 2020 11:14 pm

93143 wrote:
Tue Aug 25, 2020 2:18 am
Oziphantom wrote:
Mon Aug 24, 2020 11:33 pm
The PAL clock is 0.985Mhz and the NTSC clock is 1.023Mhz [...] Now the 1541/c/ii disk drive runs at 1.00mhz if you are in PAL or NTSC it doesn't change it just 1mhz. So you have PAL loaders and NTSC loaders that as they "run the clocks" need to adjust their timings for the blind reads, so some games won't even load on a PAL let along run because the loader wants NTSC, and vise versa.
Sounds a bit like the sync problem with audio streaming on SNES. If you want decent bandwidth, it seems to be helpful to avoid using high-granularity double-handshake methods and just use cycle-counted code to stay in sync over large bursts. However, there's a problem: not only is the nominal clock ratio slightly different from NTSC to PAL (~65.0 vs. ~65.6 SPC700 cycles per scanline), but since the APU uses a ceramic oscillator, the frequency (a) isn't consistent between consoles, and (b) drifts. This makes a robust, universal high-data-rate streaming scheme a fairly interesting problem.
I think we are looking at the SPU the wrong way. Its a 1 mhz 6502 with 16bit instructions, mul and div and a 32bit bidirectional bus. Given on a C64 we typically spend about 20 raster lines playing music then the music engine would "wait for next frame", having a look at the SPC drivers seems they basically do the same thing. In some demos we also use the 1541's 6502 which is 1mhz and has 2K of RAM to do some maths for us, and that is on the other side of a slow serial connection :D

User avatar
TmEE
Posts: 760
Joined: Wed Feb 13, 2008 9:10 am
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
Contact:

Re: SNES native 3D performance ST-NICC no SFX demo

Post by TmEE » Wed Aug 26, 2020 11:55 pm

Oziphantom wrote:
Tue Aug 25, 2020 10:57 pm
However like the VICII, are the PPUs the clock masters. So if you switch the PPU to "50hz", does this also modify the clock speeds to be PAL or does the PPU run "50hz" timings, for vblank, hblank, active display etc off the NTSC Master clock? Or does it drop to PAL Master Clock.
In typical hardware you have a master clock where everything is divided down from, for example in case of MD and SMS the two main clocks are 3.579545*15=53.693175Mhz (NTSC native hardware) and 4.433619*12=53.203426MHz (PAL native hardware). The master clock is always divided down with same dividers, leaving all cycles per line, per pixel and etc. same and only thing that changes is lines per frame, depending on 50/60Hz selection signal on the video chip (there's actually one signal which divider is changed by 50/60 selection, which is color subcarrier output to the video transcoder chip to turn RGB into PAL or NTSC video signal, /12 in 50Hz and /15 in 60Hz). 68K and YM are always MCLK / 7, Z80 and PSG always have MCLK / 15, and there's always 3420 MCLK cycles per line (put per pixel changes with chosen resolution). Most other hardware works in same sort of way also, using single master clock to derive all the needed clocks from and in general there's no other clock domain so it isn't normally possible to actually determine if you are on PAL or NTSC hardware since you cannot determine the absolute clock, and relative timings are same in both cases.

turboxray
Posts: 104
Joined: Thu Oct 31, 2019 12:56 am

Re: SNES native 3D performance ST-NICC no SFX demo

Post by turboxray » Thu Aug 27, 2020 5:05 pm

TmEE wrote:
Wed Aug 26, 2020 11:55 pm
Oziphantom wrote:
Tue Aug 25, 2020 10:57 pm
However like the VICII, are the PPUs the clock masters. So if you switch the PPU to "50hz", does this also modify the clock speeds to be PAL or does the PPU run "50hz" timings, for vblank, hblank, active display etc off the NTSC Master clock? Or does it drop to PAL Master Clock.
In typical hardware you have a master clock where everything is divided down from, for example in case of MD and SMS the two main clocks are 3.579545*15=53.693175Mhz (NTSC native hardware) and 4.433619*12=53.203426MHz (PAL native hardware). The master clock is always divided down with same dividers, leaving all cycles per line, per pixel and etc. same and only thing that changes is lines per frame, depending on 50/60Hz selection signal on the video chip (there's actually one signal which divider is changed by 50/60 selection, which is color subcarrier output to the video transcoder chip to turn RGB into PAL or NTSC video signal, /12 in 50Hz and /15 in 60Hz). 68K and YM are always MCLK / 7, Z80 and PSG always have MCLK / 15, and there's always 3420 MCLK cycles per line (put per pixel changes with chosen resolution). Most other hardware works in same sort of way also, using single master clock to derive all the needed clocks from and in general there's no other clock domain so it isn't normally possible to actually determine if you are on PAL or NTSC hardware since you cannot determine the absolute clock, and relative timings are same in both cases.
The official unreleased TurboGrafx PAL is hacky trash. I don't remember all the details because it's been over 10 years, but there's a z80 mcu whose whole job is to keep the frame intact from a slowed down NTSC VDC intra-frame, making a PAL frame out of it. It's really dumb because the VDC is capable of driving a 512 visible scanline display - it's that flexible. It really didn't need that much work, just a slightly different reg setup for the internal timings.

Post Reply