BGMODE or parameter changes during scanline

[Sik]

...okay, so it looks like Sik called it. Apparently you can change from Mode 7, but not to Mode 7, at least if the line doesn't start in Mode 7. Unless there's a bug in my code that doesn't trigger in higan...

Well, my guess was that the mode 7 deformation calculations would not be performed outside mode 7, so basically it'd attempt to start them the moment the switch happens (note how basically it just restarts the first line every time). I suppose you could still use it if you treated it the way Sega CD does deformation (where you have to explicitly specify every line, start position included), but even then you need to make sure the switch always happens in the same line (or at least the same spot where a mode switch gets accepted).

[Augustus Blackheart]

...call me paranoid, but can you confirm that you're using an original SNES, and not a SNES Jr.?

Original SNES; I haven't opened this one up. Not sure if this is helpful:

S/N: UN279446165
CPU: 2
PPU1:1
PPU2:3

That serial number is between two listed at SNES SN which indicate SNS-CPU-RGB-01

[koitsu]

SD2SNES arrived today, after a lot of problems with the local USPS (don't ask, I'm seriously in "Is Wayne Brady gonna have to choke a bitch?" mode). Really glad I got it -- makes me very very happy.

Thanks for getting decent captures up and going before me, Augustus, but I just wanted to follow through with my promise.

• mode7.XviD.avi -- MODE7.SMC (Pan of Anthrox demo) -- 720x480, deinterlaced, XviD quality 7500, no audio, 10.2MBytes
• mtest_scroll.XviD.avi -- mtest_scroll.smc -- 720x480, deinterlaced, XviD quality 7500, no audio, 19.8MBytes
• mtest_reverse.XviD.avi -- mtest_reverse.smc -- 720x480, deinterlaced, XviD quality 7500, no audio, 28.3MBytes

SNES used is an original (not SNES Jr.), CPU revision 2, PPU1 revision 1, PPU2 revision 3. I can invest in a SNES Jr. and see if there are any differences if needed.

One thing to note: the "black static" in Pan's demo tends to change its size and location (horizontally within the "ATX" logo) every time I power-cycle and run the demo. I can take a video demonstrating this if need be. I didn't try repeated power-cycles and runs of the mtest_* stuff, but I can do that if asked as well. I figure that info might be helpful not only for byuu, but for 93143 too.

[93143]

Thanks to both of you! If I had the hardware, or enough free cash to obtain it, I'd test this stuff myself, but I don't...

That "black static" is worrisome. Apparently even the sprite layer glitches briefly - but it's probably not very noticeable on an overlay as dark as the one I'm planning. As long as it stays black - I wonder if there's any way to change it?

Also, those black flecks look for all the world like half-height pixels - you said this was deinterlaced? What do they look like on a CRT?

...

I'm thinking I should work up a test that's much closer to what I've got planned. Rotation of the Mode 7 layer, or perhaps HDMA perspective, or both, and a sprite mask to cover the glitching, maybe toggled with the controller. Scroll the Mode 7 BG, maybe with the D-pad, and reset BG1 scroll to (0,0) during the interrupt. Maybe run some random math/logic during the screen so I can see what the effect is on the garbage area.

Filling the screen with timed code is probably still a bit beyond me right now, even though it looks like it may be the only way to completely obscure the existence of any glitching...

Either way, I don't have much time to do this sort of thing right away; I have to focus on work. I should have a bit more time in a couple of weeks.

I can invest in a SNES Jr. and see if there are any differences if needed.

I'd feel presumptuous asking you to spend even more money on this. But if byuu wants to know too, it might be a good idea. I'd rather not write a game that glitches on a SNES Jr. if I don't have to; then again, I should have money myself by the time the question becomes critical...

...I wonder if different PPU versions would behave differently even on a regular SNES? This isn't the sort of situation Nintendo would have been designing to, and I couldn't help but notice you're both using 2/1/3 units... I imagine it would work about the same, but I don't have any sort of feel for what the differences were really like...

I didn't try repeated power-cycles and runs of the mtest_* stuff, but I can do that if asked as well. I figure that info might be helpful not only for byuu, but for 93143 too.

If the width of the garbage area changes between runs, that's something I'd like to know, yeah. I can't imagine why it would, as long as everything is initialized properly - I'm still using Neviksti's code for that...

From my perspective, I'd be just as happy to wait until I can get a more complicated test going, so it's closer to what would happen in-game. Not sure what byuu would need in terms of getting enough data to accurately emulate this, or how accurate he even wants to get. It is a bit of an extreme use case, and reminds me of the trouble he had with partially-calculated multiplication results. I believe he only ended up accurately emulating that because Taz-Mania relied on it to work (and/or because blargg reverse-engineered it), and this looks even more complicated...

[koitsu]

Re: viewing on CRT: I don't have a CRT that supports S-Video, I'm sorry to say. My Dell 2407WFP supports S-Video, but that's an LCD, and obviously has to do some deinterlacing itself (plus I have no way to capture that video -- I don't like the idea of recording screens using cameras and that sort of thing, even if my crappy point-and-shoot camera can do 60fps recording). None of my neighbours have displays that support S-Video either (the one which might has an LCD), so really the only thing I can use is the capture device I bought, or my Dell monitor directly.

Re: black flecks: which video are you referring to (there are "black dots" in all of them in some manner of speaking ;-) )? I'm going to assume you're referring to Pan's demo -- if so, they're the same height as the "white/grey flecks" in mtest_scroll and mtest_reverse. My gut instinct is that these are probably the screen artefacts previously discussed when changing video modes mid-scanline.

Re: black flecks moving horizontally between power cycles: I doubt this has to do with your SNES init code -- as I said it happens on Pan's demo as well. It's probably just a timing thing combined with the mid-scanline $2105 adjustment.

Re: deinterlacing: The captured video is interlaced (rephrased: the capture device does not do deinterlacing itself), so during the post-processing phase (compressing the raw video capture with XviD), I use VirtualDub's deinterlacer filter. If you want original non-deinterlaced video (but still in XviD format), I can do another recording. Providing any original, uncompressed video however is probably not an option -- these tend to be hundreds of megabytes.

Re: SNES Jr: I figured finding one of these would not be that hard, but seems I'm mistaken -- eBay is filled with people selling classic/original SNES units as cheap as $20, while the SNES Jr/Mini tends to go for 3-4x that. *shakes head* So I suppose I could invest in one (it wouldn't break the bank), but like the NES top-loader they're overpriced for no legit reason I can think of and I'm inclined to say "not worth it".

Re: PPU revisions: most SNES units are what August and I both have. PPU revision changes aren't really well-documented, but the official developers manual, in the "Documented Problems" section, does mention one item affecting PPU1 revision 1. That's all I've ever seen mentioned myself. It's probably safe to focus on the "2/1/3" units, as those are what most people have. As for the SNES Jr/Mini, I have no idea if that's identical or not.

So here's my question for you: how exactly are you testing the code you're writing? Are you using emulators exclusively? Do *YOU* have a CRT and a SNES? ;-)

If so, maybe the more economical thing to do would be to send you my SNES + cables + controller + SD2SNES and let you actually test on real hardware. This is how back in the early 90s I did all of my own stuff (there were no emulators then) and how commercial companies did it as well (Nintendo's own devkits did nothing more than ran the code you gave them -- at least that's all the ones at EA did). I would be perfectly fine with loaning you my stuff if you'd like, assuming you can reimburse me for shipping costs, and of course promise to return my stuff when you're finished (and if you run off with my shit I'll be absolutely livid, trust me). But maybe that would work better for you, since all development involves is moving an SD card back and forth between the SD2SNES and a PC.

Otherwise if you have all the SNES hardware / hookups yourself but lack a way to run code on the console, I would be willing to donate some money to getting you a Super EverDrive not the v2 unit -- seems nobody has stock of those right now) as my way of saying "kudos to someone still developing stuff on the SNES!" It'd at least get you started and working on real hardware.

[lidnariq]

For whatever it's worth, I have a 1/1/1 SNES ... although no way to run tests on it (yet).

[tepples]

I have a PowerPak with Simba firmware and a launch Super NES!!!!1/1/1

But my DVD recorder doesn't like it very well. I wonder if its PPU2v1 is part of this. Reportedly the PPU2v1 puts out an even more nonstandard* signal than the more common PPU2v3, and the DVD recorder might be confusing the nonstandard qualities of its composite output with copy protection used on major studio movies.


* Grammar Nazis shut up.

[Near]

> Well, my guess was that the mode 7 deformation calculations would not be performed outside mode 7

Correct. So far I'm doing the actual multiplication on each pixel instead of adding a step per pixel and only multiplying once per scanline start. Just haven't gotten to adapting anomie's algorithm for single-stepping yet. It really is early days with dot-based rendering, if that wasn't obvious enough by now. So yeah, don't use mode 7 on the right side of a horizontal-split mode. Although you probably could make it work anyway if you timed things just right (eg let it run in mode7 for the initial multiplication.)

> mode7.XviD.avi -- MODE7.SMC (Pan of Anthrox demo) -- 720x480, deinterlaced, XviD quality 7500, no audio, 10.2MBytes

Thanks a bunch for making this! I feel bad being so lazy, given I have an sd2snes myself. Just ... don't want to dig out all my kit for SNES dev right now.

Good news is we are getting the offset-per-tile effect correct now under emulation. Hooray.

> the "black static" in Pan's demo tends to change its size and location (horizontally within the "ATX" logo) every time I power-cycle and run the demo

Looks to be right where DRAM refresh tends to hang around, too. I know that tends to darken the image for some people in the middle of the screen, but haven't seen anything like what you are getting.

> I can invest in a SNES Jr. and see if there are any differences if needed.

I haven't done extensive raster effects testing with an SNES Jr. But I did run my "write out text using only $2100 INIDISP brightness changes" demo, and Air Strike Patrol (before I knew about the BG3 text raster effect.)

Both had the same issue: the shadowing seemed to be seriously diluted. Where my letters were pitch black on a classic SNES, they were light gray on the SNES Jr, and their positions were shifted off somewhat. Not a brightness issue, I had 75ohm resistors on the RGB lines (modded it to output raw RGB. Real fun trying to solder onto that tiny S-ENC chip.)

I often say the SNES Jr is more like a console clone than a revision. May be a bit overly harsh compared to the reality, but I felt it was really shady the way they didn't bump the chip revision# s, yet changed a bunch of things (PPU raster stuff, SMP timer glitch fixes, etc.) I haven't done super extensive testing, but every time I do any kind of deep testing, I spot a new difference. There's probably a ton more we don't know about, even if that's conjecture for now.

It's also neutered: no underside expansion port, no fun cart ejection, no power LED, what I want to call maliciously disconnected multi-out lines, etc. It does have one amazing picture, though. Equal to the final full-size SNES revision, which is hard to find since sellers don't know/list motherboard revisions.

> I believe he only ended up accurately emulating that because Taz-Mania relied on it to work (and/or because blargg reverse-engineered it), and this looks even more complicated...

What you need to understand about my methodology is that I don't avoid things until they are required: I avoid doing things that I don't know of any software doing, and as a result of that I can't test at all. Because every time I write untested code paths, they have serious bugs.

It just turns out that having a real-world example of a given behavior gives us something to verify that we're at least more right than we were before.

"But you could write the tests!", yeah if I didn't already have hundreds of other things I needed to be doing. And I did that for a whole lot of behaviors that nothing ever relies on: like VIRQ off-by-one glitch on the first frame after power-on, IRQ I/O->read cycle penalty on 2-cycle instructions, DMA<>CPU sync, HDMA channel 7 short-circuit glitch, weird double-height sprite glitch, etc. (if you want details, read higan source, I don't recall them well enough offhand.)

If someone wrote a test ROM that relied on starting a multiplication during a division and reading out the half-multiplied, half-divided, clusterfuck bits ... I would not be emulating that. Not even if d4s used it for an emulator check screen :P

I already failed to figure out the regular MUL/DIV partial computation bits. Thankfully blargg cracked that algorithm for us.

> and this looks even more complicated...

If you really want to be "a dick", mess with the PPU multiplication registers (different from the CPU ones) while displaying mode 7 data. Obviously the PPU is going to be using that hardware during mode7 rendering. Who knows what will happen when you fuck with it yourself.

[Sik]

Forgot to comment on this (whoops)

But my DVD recorder doesn't like it very well. I wonder if its PPU2v1 is part of this. Reportedly the PPU2v1 puts out an even more nonstandard* signal than the more common PPU2v3, and the DVD recorder might be confusing the nonstandard qualities of its composite output with copy protection used on major studio movies.

As far as I know, copy protection is done by putting garbage dots inside vblank area, which results in naive recording hardware to get jammed (e.g. the autoadjusting recording hardware in VHS players). I know this actually happens to be a serious issue with Mega Drive games because CRAM dots often get mistaken to be copy protection by some devices =P

[tepples]

As far as I know, copy protection is done by putting garbage dots inside vblank area, which results in naive recording hardware to get jammed (e.g. the autoadjusting recording hardware in VHS players).

This is true of gain control copy protection. But there's also a later method called "four-line colorstripe" that most "video stabilizer" boxes can't remove, in which the horizontal positioning of the colorburst varies slightly throughout a frame. (Source, PDF)

[93143]

Re: black flecks: which video are you referring to (there are "black dots" in all of them in some manner of speaking )? I'm going to assume you're referring to Pan's demo -- if so, they're the same height as the "white/grey flecks" in mtest_scroll and mtest_reverse. My gut instinct is that these are probably the screen artefacts previously discussed when changing video modes mid-scanline.

Yeah, I meant Pan's demo. We kinda knew the BG layers filled with garbage for a bit while the PPU was getting its bearings in the new mode (you can see this plainly in my test, as well as the sprite-free version of the Anthrox demo Augustus posted earlier), but I at least didn't expect the sprite layer to show any artifacts.

Re: black flecks moving horizontally between power cycles: I doubt this has to do with your SNES init code -- as I said it happens on Pan's demo as well. It's probably just a timing thing combined with the mid-scanline $2105 adjustment.

I would expect a properly-initialized SNES to behave deterministically. Maybe I'm just a sucker...

But I wasn't referring to my code. I don't know if my code does that; I was referring to what you said you'd observed in the Anthrox demo, which I haven't checked to see if it initializes properly (it would take a while, at my level of expertise...).

...wait, are you saying it does happen with my code too?

If you want original non-deinterlaced video (but still in XviD format), I can do another recording.

No, that's fine. The apparent pixel size of the black flecks was just weirding me out/giving me vague hope that they wouldn't show up well on a CRT. It's probably a compression artifact or something - I don't know what else could possibly cause this - but they really do look half-height...

they're overpriced for no legit reason I can think of and I'm inclined to say "not worth it".

Yeah, I checked a bit myself, and it looked like the market price was north of $70, which informed my response. I'd tend to agree with you here.

So here's my question for you: how exactly are you testing the code you're writing? Are you using emulators exclusively? Do *YOU* have a CRT and a SNES?

Higan v094 accuracy core (when necessary; bsnes v072 compatibility core when not), yes (for testing, at least), and yes. I don't have a flash cart or any sort of copier, and I don't have any digital video capture hardware or even a decent camera, but I do have a working deck w/power supply and composite cable, two working controllers (oh wait - my little brother borrowed one), a real TV (not one of these newfangled Back To The Future jobs that can't handle real game consoles properly), and a bunch of games. I don't have an S-video cable, but they're dirt cheap and the TV does have the appropriate hookups, so maybe I should consider getting one...

I would be willing to donate some money to getting you a Super EverDrive not the v2 unit -- seems nobody has stock of those right now) as my way of saying "kudos to someone still developing stuff on the SNES!" It'd at least get you started and working on real hardware.

...wow. That's very generous of you, on top of all the procurement you've done already.

Getting started on real hardware would be great; I could fiddle around with stuff like this with low latency and without leaning on strangers I meet on the 'net every time I want to change something. I could also see what the graphics assets look like on a real TV; bsnes with blargg's NTSC filter is close, but not close enough, and I suspect that engaging byuu's gamma ramp too is giving me a bit of double-counting...

Speaking of latency, that would be another advantage - gameplay just isn't the same in an emulator, unless you're playing SimCity or something...

Speaking of strangers, how would you propose to execute such a donation without potentially compromising either of our personal data?

[koitsu]

I could send you some money via PayPal, enough to cover the costs of a Super Everdrive + S/H and you could get it yourself. Alternately I could buy one, test it/make sure it works, and then ship it to you, but that'd require me having your mailing address. The former is a lot less invasive, and just requires me to know your PayPal address (you can PM it to me). I'm sure we can work something out!

If you're worried about trustworthiness, there are lots of folks here who I'm sure can attest to the fact that I respect people's privacy -- ex. I just got some Famicom stuff from mikejmoffitt in the mail today, Zycrow and I shipped things back/forth a lot in this thread, I sent a non-working SWC DX off to Ramsis (per this thread) not too long ago, and I help admin the forum. There's also the data point that I ran Parodius for nearly 20 years, and we had to have contact info for all the folks who had accounts... :-)

As for the rest of the post:

- It's hard for me to tell if your mtest_* stuff has the same behaviour as Pan's demo, re: black specks. Possibly the white/grey "specks" in yours are effectively the same thing as the black specks in Pan's, I really don't know. Your mtest_* stuff tends to have some black areas where the mode transition takes place (shown in yellow here, and shown with black-grey lines here), while Pan's has a definitive (non-black) ATX logo (using sprites I believe), so it's easier to see the "specks".

- I'm going to try to rule out the "black specks" (in Pan's demo) being either specific to my capture device (anything is possible) by checking on an actual display. The only display I have that does S-Video input is my Dell 2407FWP monitor, and the hardware deinterlacing it does isn't the best in the world. But let's just say I wouldn't be surprised if it turned out to be some silliness with my capture device. I suppose alternately I could just use composite out and hook it up to my CRT directly + record that with my crappy point-and-shoot camera (which can do 60fps, oddly enough).

- I sincerely do not think the SNES initialisation code is what's responsible for the "speck" problem. My own opinion is that it's a direct result of changing MODE mid-scanline (while electron gun is drawing) -- my guess is that the PPU and related circuitry ends up reading gobbledegook from somewhere during the short period of time (not sure how long) it takes for the PPU to actually "fully" switch modes.

[koitsu]

Just a brief follow-up:

I hooked my SNES up to my Dell 2407WFP. It shows the "black specks" as well, which means it isn't my capture device. I recorded some videos using my crappy point-and-shoot camera in 60fps, recording the Dell monitor. Camera will only record up to 60 seconds, and I can't adjust focus or zoom once recording, sorry.

• MVI_2425.XviD.avi -- MODE7.SMC (Pan of Anthox demo) -- 320x240, XviD quality 7500, no audio, 25.4MBytes
• MVI_2426.XviD.avi -- MODE7.SMC (Pan of Anthox demo) -- 320x240, XviD quality 7500, no audio, 26.8MBytes

The 1st recording shows that the "black specks" basically shifting up and down a pixel (possibly half a pixel), in a column along the left side of the ATX logo. There's similar gobbledegook at the top of the logo. Near the end I hardware reset (not power-cycle) the SNES, and the pattern/rate at which the "specks" move changes.

The 2nd recording is after a full power-cycle (although I've gotten this to happen after a hardware reset as well, it just varies). The "black specks" are in two columns. Mid-way I power-cycle the console again, and get the same two-columns-of-specks issue, but the pattern/rate at which the "specks" move changes (shifting/jiggling up and down rapidly).

I may invest in another SNES just to rule out some hardware inside flaking out (I've had this unit since my childhood), but I don't see this kind of behaviour in any commercial carts, ditto with games loaded via the SD2SNES. Presently I'm of the firm opinion that this is just some kind of side-effect of mid-scanline MODE changing. Obviously more testing is needed, so the more folks who can test this out on actual hardware the better.

Augustus, is it possible to get a recording of you running MODE7.SMC on your setup?

[tepples]

I would expect a properly-initialized SNES to behave deterministically.

A properly-initialized NES can start in one of four relative alignments between the CPU and PPU. The Super NES may have more or fewer, given the phase of the DMA unit.

I don't have an S-video cable, but they're dirt cheap and the TV does have the appropriate hookups, so maybe I should consider getting one...

Yeah, for anything 480i, S-Video is going to be very nearly as good as component/RGB.

Speaking of strangers, how would you propose to execute such a donation without potentially compromising either of our personal data?

That depends on what you consider "personal data".

[Augustus Blackheart]

Augustus, is it possible to get a recording of you running MODE7.SMC on your setup?

This is a new video of the original anthrox demo with sprites disabled. It is hard to tell with the mess going on in the middle but the black specks do not appear to be visable when the sprite layer is disabled.

I don't have a video yet with sprites enabled but I can confirm that the black dots are visable.

http://www.morganleahrecords.com/august ... _nospr.mp4

edit: That file is kind of large at 36MBytes...