Forums

[Admin note: this thread is missing several messages from the start.]

<center><img src="http://www.zyx.com/chrisc/smsdemo.jpg"></center>

Quote

> This is disconcerting. You didn't notice the double "SMS Power"? Can anyone test this demo on a system that is known to have a 315-5124 VDP?

I tested it last night, on 3 systems:

On my MegaDrive w/ adaptor, it looks nice, but with a thin vertical black line and some flickering going down from the right side of the "W" in POWER, as mentioned before. And the colour bars are 1 pixel higher to the right of that glitch.

On my Japanese, SMS, yes the "SMS Power" logo is duplicated at the bottom of the screen. There is also the flickering. Finally, the sine-wave sprites are all glitched, with a few glitchy ones in the centre, and a bunch of them on the right edge of the screen.

On my Game Gear w/ SMS adaptor, it looks nice, but with the same flickering/glitching situated at the left side of the "W" in Power. No black line, though.

Pooh, I'll just take a picture of the three. Sorry, no video captures... It's interesting that the timing of the glitch is slightly different between the MD/SMS and GG systems.

Quote

> > I only emulate what is necessary for Ys, but even adding this
> > line in MEKA.NAM didn't worked to reproduce the bug:
> > F6CA6BFD36AE4CA8,smspower7.sms,VDP=315-5124

> This is disconcerting. You didn't notice the double "SMS Power"? Can anyone test this demo on a system that is known to have a 315-5124 VDP?

Sorry, my mistake. I managed not to notice the double SMS Power logo. It is there on a 315-5124 VDP.

or I guess you'd call it an 'intro'.

I'd hoped to get this released when it was still March 27th, but I am forever pushing deadlines and it is no different for my SMS shenanigans.

D/L here

Thank you and.. good night (Zzzzz)

(Best viewed in Meka, it should be okay in other emulators but some older emulators don't support palette raster effects. I know they can be switched on in BrSMS with the -palraster flag, not sure about the others)

...I didn't write anything! Ah well. I am doing SMS stuff today for the first time in months, even though it is mainly trying to locate the roms I lost in a hard disk crash. Maybe people can help me with that later...

Quote

> I'd hoped to get this released when it was still March 27th, but I am forever pushing deadlines and it is no different for my SMS shenanigans.

Somewhere in the world it was still the 27th. Add in some nonsense about folding of time and space and you're set.

Quote

> Thank you and.. good night (Zzzzz)

And now... the Real SMS Test!

(No screenshots - my capture card is out because it's slower than my new motherboard's built-in RAM-stealing graphics, for shame.)

It runs, but with a glitch. Here's a diagram:

Where I've drawn a garish magenta line, there's some kind of glitch which I presume is due to some timing issue. On this line:

- the tile text has a "hole" which is somewhat transparent, but also with some noisy flashing pixels
- the bars suddenly become 1 pixel higher
- the sprite text seems to just become black

I'm guessing there's some timing issue with the H-interrupt; possibly it fires "early" (pixel 170ish instead of 256) to give code time to do its stuff (handle interrupt, do something like write to HScroll register) before the next line begins, giving on-interrupt-line-number effects. Maybe this is worth some discussion on the dev forum.

Maxim

smspower7.png (2.54 KB)

Attaching screenshot

Quote

> I'm guessing there's some timing issue with the H-interrupt; possibly it fires "early" (pixel 170ish instead of 256) to give code time to do its stuff (handle interrupt, do something like write to HScroll register) before the next line begins, giving on-interrupt-line-number effects. Maybe this is worth some discussion on the dev forum.

Could be -- I would imagine the hscroll updates are latched and only updated once per line, just as vblank is only updated once per frame, but palette changes could be immediate. Interesting that it would cause a blackout in the background.

Another possibility is that my hblank routine is too long instead off too short -- it loads a table pointer and does a look up before writing to the palette, so maybe it would work better if I set it up so it writes right away and uses the rest of the interrupt to set up the next write. Perhaps updating the palette mid-line can be detrimental.

I should look at another game that does raster palette effects (Space Harrier or one of the Sonic games come to mind) and see if it does anything special in the way of delays or port reads.

but not now...

Quote

> > I'd hoped to get this released when it was still March 27th, but I am forever pushing deadlines and it is no different for my SMS shenanigans.

> Somewhere in the world it was still the 27th. Add in some nonsense about folding of time and space and you're set.

I was thinking about changing date and time of his post and files. But then, WLADX was evil and wrote a definitive date of March 28th into the ROM.

Quote

> > Thank you and.. good night (Zzzzz)
> And now... the Real SMS Test!

[...]

Quote

> It runs, but with a glitch. Here's a diagram:
>

> Where I've drawn a garish magenta line, there's some kind of glitch which I presume is due to some timing issue. On this line:

> - the tile text has a "hole" which is somewhat transparent, but also with some noisy flashing pixels
> - the bars suddenly become 1 pixel higher
> - the sprite text seems to just become black

> I'm guessing there's some timing issue with the H-interrupt; possibly it fires "early" (pixel 170ish instead of 256) to give code time to do its stuff (handle interrupt, do something like write to HScroll register) before the next line begins, giving on-interrupt-line-number effects. Maybe this is worth some discussion on the dev forum.

I think this is due to palette change. The VDP has problem accessing video data when palette's being accessed. If you look at any SMS games changing palette, you usually can notice small glitchs and flashing pixels somewhere. It's often at the very top or bottom. I don't know about the exact behavior of the VDP in this case.
So based on this theory, Nicolas' code would change the palette on each line at around pixel 170.

I also tested the demo now. On SMS2 it behaves as you describe. On both PAL and NTSC SMS1 (I suppose the early VDP model) the sinus text is completely messed. Part of the sinus are shown but tiles are incorrect. I'm unsure about the exact reason.
Maybe MesaDX would emulate VDP differences better?
I only emulate what is necessary for Ys, but even adding this line in MEKA.NAM didn't worked to reproduce the bug:
F6CA6BFD36AE4CA8,smspower7.sms,VDP=315-5124

On a GG it looks less noticeable that on a SMS2 VDP, but then, who can notice details on a GG screen?

Quote

> I should look at another game that does raster palette effects (Space Harrier or one of the Sonic games come to mind) and see if it does anything special in the way of delays or port reads.

Just had a look at Space Harrier, and noticed that the hblank handler (That switches the screen color at line 126)

ld a,$07
dec a
jr nz,-3

so it looks like a delay loop. After that, it sets the CRAM address and writes the new background color without anything in between port writes. Then it does another delay look, except with 9 and an initial accumulator value instead of 7.

I'll see if I can time out exactly my routine needs to do vs. what Space Harrier does and adjust the hblank handler to match.

I used to wonder why palette raster effects weren't used very often on the SMS. I had originally supposed that it was because the SMS's generous palette made it let necessary as with other consoles, but now I think it was avoided because it's a pain in the ass.

Quote

> I think this is due to palette change. The VDP has problem accessing video data when palette's being accessed. If you look at any SMS games changing palette, you usually can notice small glitchs and flashing pixels somewhere. It's often at the very top or bottom. I don't know about the exact behavior of the VDP in this case.

The color RAM is single ported, so it can only be accessed by one source (CPU or VDP) at any time.
During the display period, the VDP repeatedly reads CRAM to get the color value of the current pixel to display.
If the CPU writes to CRAM during this time, it has higher priority than the VDP, and the data read by the VDP for the current pixel is the same data the CPU wrote.
So each flickering pixel will be the color of whatever data the CPU sent at that point in time.

Technically, this happens at any point in the display, even when the screen is off or in the border/overscan area.
That's because the VDP is still reading CRAM to get the border color.

If you want to emulate this, the only catch I know of is that it seems that the flicker may be offset by a few pixels to the right.
On the real hardware, there may be a very brief delay between an 'out' instruction and when the data is actually written to CRAM (and therefore shown on the screen)
But it's a 1-2 pixel difference, hardly important.

One of the Dizzy games and Gunstar Heroes (GG) are good examples of this, they have a lot of palette flicker to look at.

My Homepage

Quote

> I also tested the demo now. On SMS2 it behaves as you describe. On both PAL and NTSC SMS1 (I suppose the early VDP model) the sinus text is completely messed. Part of the sinus are shown but tiles are incorrect. I'm unsure about the exact reason.

Damn. I really need to get a dev cart of my own.

At the top of the vblank I just dump a new sprite table into vram with OTIR. Rather than set up a vertical blank interrupt, I just poll bit 7 of $bf to see if it's vblank time yet. Do you think maybe that fires early on the SMS1, and the sprite table doesn't get updated correctly because I'd be sending data to vram too quickly during the display area?

Quote

> I also tested the demo now. On SMS2 it behaves as you
> describe. On both PAL and NTSC SMS1 (I suppose the early VDP
> model) the sinus text is completely messed. Part of the sinus
> are shown but tiles are incorrect. I'm unsure about the exact
> reason.
> Maybe MesaDX would emulate VDP differences better?

I noticed two things when running the demo under MesaDX:

First, the demo initially uses a video mode that is unsupported in MesaDX. The mode (as described in Charles MacDonald's VDP doc) is:



M4 M3 M2 M1     SMS VDP                 SMS 2 / GG VDP


-- -- -- --     ----------              ---------------------


1  0  0  1     Invalid text mode       Invalid text mode

The VDP register values determining the mode are:
VREG[$00] = $04
VREG[$01] = $F0

This mode is unsupported in MesaDX and causes the emulator to shutdown. The code that sets this mode is a OTIR instruction at address $0072. I compiled a hacked version of MesaDX to ignore the illegal video mode since the demo quickly switches over to the standard "Mode 4" mode. This led to the second thing I noticed.

The second thing is that the demo ignores the "Japanese Ys VDP quirk". The demo does not set bit 0 of VREG 2, so tiles near the top of the screen are mirrored near the bottom. In the demo this results in the "SMS Power" text being shown twice: once near the top and once near the bottom of the screen. MesaDX currently only emulates a 315-5124 VDP which has this quirk. I suspect (and hope) that so far the demo has only been tested on real systems without a 315-5124 (SMS1) VDP since no one else has reported the double "SMS Power", otherwise I have some work to do correct my understanding of the 315-5124 VDP and fix MesaDX's 315-5124 VDP emulation.

I have not noticed any other (timing-related) glitches, but this is probably because MesaDX does not accurately emulate all the timing-related VDP issues. (Mostly because, not all of the timing issues are well understood yet.)

Quote

> I only emulate what is necessary for Ys, but even adding this
> line in MEKA.NAM didn't worked to reproduce the bug:
> F6CA6BFD36AE4CA8,smspower7.sms,VDP=315-5124

This is disconcerting. You didn't notice the double "SMS Power"? Can anyone test this demo on a system that is known to have a 315-5124 VDP?

--
Eric R. Quinn

Author	Message
ccovell Joined: 26 Dec 2004 Posts: 374 Location: Japan	Re: Oh, the shame... Posted: Fri Aug 17, 2001 8:02 am
ccovell Joined: 26 Dec 2004 Posts: 374 Location: Japan	[Admin note: this thread is missing several messages from the start.] <center><img src="http://www.zyx.com/chrisc/smsdemo.jpg"></center> Quote > This is disconcerting. You didn't notice the double "SMS Power"? Can anyone test this demo on a system that is known to have a 315-5124 VDP? I tested it last night, on 3 systems: On my MegaDrive w/ adaptor, it looks nice, but with a thin vertical black line and some flickering going down from the right side of the "W" in POWER, as mentioned before. And the colour bars are 1 pixel higher to the right of that glitch. On my Japanese, SMS, yes the "SMS Power" logo is duplicated at the bottom of the screen. There is also the flickering. Finally, the sine-wave sprites are all glitched, with a few glitchy ones in the centre, and a bunch of them on the right edge of the screen. On my Game Gear w/ SMS adaptor, it looks nice, but with the same flickering/glitching situated at the left side of the "W" in Power. No black line, though. Pooh, I'll just take a picture of the three. Sorry, no video captures... It's interesting that the timing of the glitch is slightly different between the MD/SMS and GG systems.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8648 Location: Paris, France	Sorry Posted: Fri Aug 17, 2001 8:07 am
	Quote > > I only emulate what is necessary for Ys, but even adding this > > line in MEKA.NAM didn't worked to reproduce the bug: > > F6CA6BFD36AE4CA8,smspower7.sms,VDP=315-5124 > This is disconcerting. You didn't notice the double "SMS Power"? Can anyone test this demo on a system that is known to have a 315-5124 VDP? Sorry, my mistake. I managed not to notice the double SMS Power logo. It is there on a 315-5124 VDP.

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	SMS Power 7th Anniversary Demo released! Posted: Sun Mar 28, 2004 8:20 am
	or I guess you'd call it an 'intro'. I'd hoped to get this released when it was still March 27th, but I am forever pushing deadlines and it is no different for my SMS shenanigans. D/L here Thank you and.. good night (Zzzzz) (Best viewed in Meka, it should be okay in other emulators but some older emulators don't support palette raster effects. I know they can be switched on in BrSMS with the -palraster flag, not sure about the others)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14728 Location: London	Oh, the shame... Posted: Sun Mar 28, 2004 10:37 am Last edited by Maxim on Sun Mar 15, 2015 11:01 am; edited 2 times in total
	...I didn't write anything! Ah well. I am doing SMS stuff today for the first time in months, even though it is mainly trying to locate the roms I lost in a hard disk crash. Maybe people can help me with that later... Quote > I'd hoped to get this released when it was still March 27th, but I am forever pushing deadlines and it is no different for my SMS shenanigans. Somewhere in the world it was still the 27th. Add in some nonsense about folding of time and space and you're set. Quote > Thank you and.. good night (Zzzzz) And now... the Real SMS Test! (No screenshots - my capture card is out because it's slower than my new motherboard's built-in RAM-stealing graphics, for shame.) It runs, but with a glitch. Here's a diagram: Where I've drawn a garish magenta line, there's some kind of glitch which I presume is due to some timing issue. On this line: - the tile text has a "hole" which is somewhat transparent, but also with some noisy flashing pixels - the bars suddenly become 1 pixel higher - the sprite text seems to just become black I'm guessing there's some timing issue with the H-interrupt; possibly it fires "early" (pixel 170ish instead of 256) to give code time to do its stuff (handle interrupt, do something like write to HScroll register) before the next line begins, giving on-interrupt-line-number effects. Maybe this is worth some discussion on the dev forum. Maxim smspower7.png (2.54 KB) Attaching screenshot

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Re: Oh, the shame... Posted: Sun Mar 28, 2004 11:08 am
	Quote > I'm guessing there's some timing issue with the H-interrupt; possibly it fires "early" (pixel 170ish instead of 256) to give code time to do its stuff (handle interrupt, do something like write to HScroll register) before the next line begins, giving on-interrupt-line-number effects. Maybe this is worth some discussion on the dev forum. Could be -- I would imagine the hscroll updates are latched and only updated once per line, just as vblank is only updated once per frame, but palette changes could be immediate. Interesting that it would cause a blackout in the background. Another possibility is that my hblank routine is too long instead off too short -- it loads a table pointer and does a look up before writing to the palette, so maybe it would work better if I set it up so it writes right away and uses the rest of the interrupt to set up the next write. Perhaps updating the palette mid-line can be detrimental. I should look at another game that does raster palette effects (Space Harrier or one of the Sonic games come to mind) and see if it does anything special in the way of delays or port reads. but not now...

Bock Site Admin Joined: 08 Jul 2001 Posts: 8648 Location: Paris, France	Re: Oh, the shame... Posted: Sun Mar 28, 2004 11:16 am
	Quote > > I'd hoped to get this released when it was still March 27th, but I am forever pushing deadlines and it is no different for my SMS shenanigans. > Somewhere in the world it was still the 27th. Add in some nonsense about folding of time and space and you're set. I was thinking about changing date and time of his post and files. But then, WLADX was evil and wrote a definitive date of March 28th into the ROM. Quote > > Thank you and.. good night (Zzzzz) > And now... the Real SMS Test! [...] Quote > It runs, but with a glitch. Here's a diagram: > > Where I've drawn a garish magenta line, there's some kind of glitch which I presume is due to some timing issue. On this line: > - the tile text has a "hole" which is somewhat transparent, but also with some noisy flashing pixels > - the bars suddenly become 1 pixel higher > - the sprite text seems to just become black > I'm guessing there's some timing issue with the H-interrupt; possibly it fires "early" (pixel 170ish instead of 256) to give code time to do its stuff (handle interrupt, do something like write to HScroll register) before the next line begins, giving on-interrupt-line-number effects. Maybe this is worth some discussion on the dev forum. I think this is due to palette change. The VDP has problem accessing video data when palette's being accessed. If you look at any SMS games changing palette, you usually can notice small glitchs and flashing pixels somewhere. It's often at the very top or bottom. I don't know about the exact behavior of the VDP in this case. So based on this theory, Nicolas' code would change the palette on each line at around pixel 170. I also tested the demo now. On SMS2 it behaves as you describe. On both PAL and NTSC SMS1 (I suppose the early VDP model) the sinus text is completely messed. Part of the sinus are shown but tiles are incorrect. I'm unsure about the exact reason. Maybe MesaDX would emulate VDP differences better? I only emulate what is necessary for Ys, but even adding this line in MEKA.NAM didn't worked to reproduce the bug: F6CA6BFD36AE4CA8,smspower7.sms,VDP=315-5124 On a GG it looks less noticeable that on a SMS2 VDP, but then, who can notice details on a GG screen?

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Space Harrier analysis Posted: Sun Mar 28, 2004 11:31 am
	Quote > I should look at another game that does raster palette effects (Space Harrier or one of the Sonic games come to mind) and see if it does anything special in the way of delays or port reads. Just had a look at Space Harrier, and noticed that the hblank handler (That switches the screen color at line 126) ld a,$07 dec a jr nz,-3 so it looks like a delay loop. After that, it sets the CRAM address and writes the new background color without anything in between port writes. Then it does another delay look, except with 9 and an initial accumulator value instead of 7. I'll see if I can time out exactly my routine needs to do vs. what Space Harrier does and adjust the hblank handler to match. I used to wonder why palette raster effects weren't used very often on the SMS. I had originally supposed that it was because the SMS's generous palette made it let necessary as with other consoles, but now I think it was avoided because it's a pain in the ass.

Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Palette flicker Posted: Sun Mar 28, 2004 3:51 pm
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Quote > I think this is due to palette change. The VDP has problem accessing video data when palette's being accessed. If you look at any SMS games changing palette, you usually can notice small glitchs and flashing pixels somewhere. It's often at the very top or bottom. I don't know about the exact behavior of the VDP in this case. The color RAM is single ported, so it can only be accessed by one source (CPU or VDP) at any time. During the display period, the VDP repeatedly reads CRAM to get the color value of the current pixel to display. If the CPU writes to CRAM during this time, it has higher priority than the VDP, and the data read by the VDP for the current pixel is the same data the CPU wrote. So each flickering pixel will be the color of whatever data the CPU sent at that point in time. Technically, this happens at any point in the display, even when the screen is off or in the border/overscan area. That's because the VDP is still reading CRAM to get the border color. If you want to emulate this, the only catch I know of is that it seems that the flicker may be offset by a few pixels to the right. On the real hardware, there may be a very brief delay between an 'out' instruction and when the data is actually written to CRAM (and therefore shown on the screen) But it's a 1-2 pixel difference, hardly important. One of the Dizzy games and Gunstar Heroes (GG) are good examples of this, they have a lot of palette flicker to look at. My Homepage

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	dog gone Posted: Sun Mar 28, 2004 8:47 pm
	Quote > I also tested the demo now. On SMS2 it behaves as you describe. On both PAL and NTSC SMS1 (I suppose the early VDP model) the sinus text is completely messed. Part of the sinus are shown but tiles are incorrect. I'm unsure about the exact reason. Damn. I really need to get a dev cart of my own. At the top of the vblank I just dump a new sprite table into vram with OTIR. Rather than set up a vertical blank interrupt, I just poll bit 7 of $bf to see if it's vblank time yet. Do you think maybe that fires early on the SMS1, and the sprite table doesn't get updated correctly because I'd be sending data to vram too quickly during the display area?

Eric R. Quinn Joined: 18 Sep 1999 Posts: 498 Location: Portland, Oregon USA	Re: Oh, the shame... Posted: Mon Mar 29, 2004 3:23 am
	Quote > I also tested the demo now. On SMS2 it behaves as you > describe. On both PAL and NTSC SMS1 (I suppose the early VDP > model) the sinus text is completely messed. Part of the sinus > are shown but tiles are incorrect. I'm unsure about the exact > reason. > Maybe MesaDX would emulate VDP differences better? I noticed two things when running the demo under MesaDX: First, the demo initially uses a video mode that is unsupported in MesaDX. The mode (as described in Charles MacDonald's VDP doc) is: M4 M3 M2 M1 SMS VDP SMS 2 / GG VDP -- -- -- -- ---------- --------------------- 1 0 0 1 Invalid text mode Invalid text mode The VDP register values determining the mode are: VREG[$00] = $04 VREG[$01] = $F0 This mode is unsupported in MesaDX and causes the emulator to shutdown. The code that sets this mode is a OTIR instruction at address $0072. I compiled a hacked version of MesaDX to ignore the illegal video mode since the demo quickly switches over to the standard "Mode 4" mode. This led to the second thing I noticed. The second thing is that the demo ignores the "Japanese Ys VDP quirk". The demo does not set bit 0 of VREG 2, so tiles near the top of the screen are mirrored near the bottom. In the demo this results in the "SMS Power" text being shown twice: once near the top and once near the bottom of the screen. MesaDX currently only emulates a 315-5124 VDP which has this quirk. I suspect (and hope) that so far the demo has only been tested on real systems without a 315-5124 (SMS1) VDP since no one else has reported the double "SMS Power", otherwise I have some work to do correct my understanding of the 315-5124 VDP and fix MesaDX's 315-5124 VDP emulation. I have not noticed any other (timing-related) glitches, but this is probably because MesaDX does not accurately emulate all the timing-related VDP issues. (Mostly because, not all of the timing issues are well understood yet.) Quote > I only emulate what is necessary for Ys, but even adding this > line in MEKA.NAM didn't worked to reproduce the bug: > F6CA6BFD36AE4CA8,smspower7.sms,VDP=315-5124 This is disconcerting. You didn't notice the double "SMS Power"? Can anyone test this demo on a system that is known to have a 315-5124 VDP? -- Eric R. Quinn

Forums

View topic - SMS Power 7th Anniversary Demo released!