BGMODE or parameter changes during scanline

[Near]

Not that surprising that the '90s homebrew scene would do wild stuff like this.

It's a shame all they were capable of were shitty text scrollers and trainers. They could have made some awesome games if they were able to get past their leet-speak and put their skills to productive use.

Anyway ... is anyone willing to record a video of this being run on real hardware? I don't want to dig out my copier gear, and I don't understand AB's explanation of "left 9 1's", but I'd like to see how close I am.

No surprise I don't emulate it properly, though. It's ... really, really extreme to change the BGMODE mid-scanline, and there was zero chance in hell I was going to guess the right way to do it with no actual testing.

[koitsu]

Anyway ... is anyone willing to record a video of this being run on real hardware? I don't want to dig out my copier gear, and I don't understand AB's explanation of "left 9 1's", but I'd like to see how close I am.

I can get around to doing this during the coming week (my SNES, AV S-Video cable, SWC DX2, and USB floppy drive are all readily available. I just gotta find working floppies... :-) ).

I remember the demo in question, but it's been over 20 years since I've seen it. True nostalgia, ahhhh! I just hope it doesn't utilise any of the high-res stuff, because I don't think my USB-based capture device will work with that.

[Augustus Blackheart]

Anyway ... is anyone willing to record a video of this being run on real hardware? I don't want to dig out my copier gear, and I don't understand AB's explanation of "left 9 1's", but I'd like to see how close I am.

Here's a picture, the yellow stripe is the part of the screen that is messed up.



Here's some shaky cam video:

http://www.morganleahrecords.com/august ... /mtest.mp4
http://www.morganleahrecords.com/august ... /horiz.mp4

No surprise I don't emulate it properly, though. It's ... really, really extreme to change the BGMODE mid-scanline, and there was zero chance in hell I was going to guess the right way to do it with no actual testing.

Snes9x just shows the large logo on the left, the sprites and the scroll text; no plasma effect. ZSNES just shows the large logo very, very slowly moving. It is rather nice how much higan gets right.

[psycopathicteen]

This is great news! This means you can have huge rotating and scaling bosses, with a background behind it, by mid-screen mode changes, and using sprites to patch up the background.

[KungFuFurby]

Excellent. Now I can give in to temptation to have more than one zoom level per scanline...

I can see why there is chaos when the BGMODE is being changed mid-scanline. There's only four cycles per dot, and it looks like the effects are near-instantaneous or instantaneous once the register is written to.

I can see that type of graphcal chaos coming into some sort of use... maybe after blacking it out first. Kind of like some sort of weird rip in the fabric of time.

Edit: I got another lightbulb! This glitchy effect can also be masked if you have matching colors between both tiles where you intend on performing your mid-scanline magic.

[93143]

Hmm... It looks like my test program has about three tiles worth of garbage, but the Anthrox demo seems to have five.

I hope this has more to do with the HDMA "plasma" effect than the fact that the Mode 7 layer is actually doing something, or the fact that actual code is running in between BGMODE writes...

Also, it occurs to me that I may want to be able to change the scroll position on BG1 during the interrupt. I have to focus on work for a bit, but it doesn't seem like an especially difficult modification to make, so I will probably try it anyway...

[Near]

> I can get around to doing this during the coming week

Thank you! That'll definitely be helpful.

> Here's a picture, the yellow stripe is the part of the screen that is messed up.

Oh, those are indeed 1's. Didn't notice. Okay, your initial response makes sense now. But I was actually referring to the Anthrox demo, atx2. I was wondering how that is supposed to look on hardware. The text isn't really readable with higan. I can't imagine they'd release it if the text were unreadable.

EDIT: oh, horiz.mp4 is Anthrox. But ... there's no sprite border in the middle, and almost all of the text written on the right-hand side is gone. Are you using the same MODE7.SMC file? If not, where can I get the ROM you are running, or could you please do a video of the ROM I am using (the one pictured in your screenshot)?

> Snes9x just shows the large logo on the left, the sprites and the scroll text; no plasma effect. ZSNES just shows the large logo very, very slowly moving. It is rather nice how much higan gets right.

Nobody ever took me seriously on the importance of a dot-based PPU renderer. I figured we'd find some interesting new effects nobody had previously noticed if we tried it, so finding these are always a treat.

[Fun tangent: find the first release of VSMC. Ignore the racist pro-KKK demo ROM (no, I am unfortunately not joking about that), and look at the other one. The author tried to emulate a fade screen effect by having a tight loop that writes to INIDISP between 15 - 0, back to 15, repeat. But he thinks it changes the entire screen instantly, as that's how his emulator handles it. Only with higan do you see what the true effect of that brings: an absolutely chaotic screen effect where the brightness changes every few pixels, and the affected pixels changes every frame, resulting in an interference-like pattern that's quite fun.]

But aside from me timing out the OAM access patterns for the sake of Uniracers, two or three test ROM demonstrations of my own (eg writing text onscreen using only the display brightness register), and a few tweaks to fix games that exhibited problems, I haven't done much more than the basic timing mechanic.

Getting things exactly right will mean tracking down timings of when the SNES reads in and latches every single register bit. And I bet those timings change based on which settings are enabled. It's not going to be fun.

> I can see why there is chaos when the BGMODE is being changed mid-scanline. There's only four cycles per dot, and it looks like the effects are near-instantaneous or instantaneous once the register is written to.

The big concern is that there's a lot of caching involved. Mode 7, for instance, isn't actually multiplying every pixel, it's adding a step value each pixel; but re-multiplying each scanline. So if you switch the right-hand side of the screen to mode 7, you can imagine that initial computation will likely not have happened.

Messing with certain sprite registers and the big-guns display-disable-bit is known to break things for the rest of the scanline.

> or the fact that actual code is running in between BGMODE writes...

You really don't have time for this sort of thing. Even the fastest possible instruction is equivalent to three PPU pixels. On average it's more like six pixels per useful instruction.

And I need to again stress that there's a big gaping 10-pixel "hole" in the middle of the screen thanks to DRAM refresh. You'll never be able to do raster effects there, no matter what you do. And I also need to bring up that the SNES Jr radically changes the internals of the PPU rendering. A lot of the mid-scanline effect demos I make break in horrifying ways on it. The SNES Jr is more like an SNES clone than a minor process revision. So if you use these effects, you're limiting yourself to the original SNES units and higan (at least for now.) No Jrs/Minis, no clone consoles, no other emulators.

> Also, it occurs to me that I may want to be able to change the scroll position on BG1 during the interrupt.

Air Strike Patrol does that mid-scanline. It works pretty well.

[Augustus Blackheart]

Oh, those are indeed 1's. Didn't notice. Okay, your initial response makes sense now. But I was actually referring to the Anthrox demo, atx2. I was wondering how that is supposed to look on hardware. The text isn't really readable with higan. I can't imagine they'd release it if the text were unreadable.

EDIT: oh, horiz.mp4 is Anthrox. But ... there's no sprite border in the middle, and almost all of the text written on the right-hand side is gone. Are you using the same MODE7.SMC file? If not, where can I get the ROM you are running, or could you please do a video of the ROM I am using (the one pictured in your screenshot)?

Sorry, I should have been more clear there.

The rom I used for horiz.mp4 was the snesmod2 example from the sneskit archive. I turned the sprites off just so everyone could see what was happening under them.

The sprites do display correctly when enabled. The only thing that is wonky is the scrolltext. Both higan and snes9x are displaying it as it appears on the real hardware.

I have run the original horiz demo before and everything displays great. If nobody else gets around to it I'll post video of that specific rom when I can.

[93143]

> or the fact that actual code is running in between BGMODE writes...

You really don't have time for this sort of thing. Even the fastest possible instruction is equivalent to three PPU pixels. On average it's more like six pixels per useful instruction.

I don't mean trying to fit in code during the garbage area or anything. I just mean that the Anthrox demo seems to have graphical manipulation code going on during the rest of the screen, whereas my test code just sits there and waits for the interrupt. I figured that was why I almost managed to hit the same pixel every line...

And I need to again stress that there's a big gaping 10-pixel "hole" in the middle of the screen thanks to DRAM refresh. You'll never be able to do raster effects there, no matter what you do.

Now that you mention it, I wonder if that could be part of the reason for the extended garbage area in the Anthrox demo. A write that slipped past the start of the DRAM refresh would happen 10 pixels late, and combined with the larger timing variance due to interrupting nontrivial code, the resulting disturbance could easily be closer to five tiles wide instead of the roughly three my code seems to show.

Or not...

Fortunately, I don't have to do anything in the literal middle of the screen; the mode change in my test code is actually pretty much where I want it.

And I also need to bring up that the SNES Jr radically changes the internals of the PPU rendering. A lot of the mid-scanline effect demos I make break in horrifying ways on it. The SNES Jr is more like an SNES clone than a minor process revision. So if you use these effects, you're limiting yourself to the original SNES units and higan (at least for now.) No Jrs/Minis, no clone consoles, no other emulators.

I think I'm okay with this (hey, the Satellaview didn't work with the SFC Jr. either). But it's good to be aware of, especially since it looks like I'm not the only one considering using this technique...

I wonder what exactly a SNES Jr. does in this case?

[koitsu]

Getting a clear video capture is gonna take me a bit more work. I thought my capture device was USB but it's actually DV/Firewire (just goes to show how long ago it was that I last used it!). Will work on getting a working capture device this week.

Edit: Son of a bitch -- my SNES AC adapter is missing. *Not* happy. Have a pretty good idea where it went (ex-roommate likely stole it as part of his massive game console collection), so I've had to order another one and should be here Saturday. Capture device should be here later this week as well. *still ticked off about AC adapter*

[Sik]

How common is the SNES Jr. in the first place? It seems to be the SNES counterpart to the Mega Drive 3 (except that in Sega's case incompatibilities aren't anywhere as big since it's based on the old ASIC, most issues come from having some bugs fixed, not complete timing changes).

[93143]

Okay, apparently it is possible to speed-write to the scroll registers by splitting the values and doing two 16-bit writes to the first one. I could be misunderstanding what's going on, I suppose...

I was going to use DMA, but I can't get it to work without having to set up the registers all over again every scanline, which eats a huge chunk of the available CPU time... Surely this can't be impossible?

Also, the horizontal scroll change doesn't seem to work in higan in this case; the ones should be shunted right 4 pixels as well as up 4 pixels.

modeswitch_higan094_scroll.png

Also attached is the basic test reversed; with Mode 1 switching to Mode 7 partway through the scanline. It works exactly as well as the original in higan. I don't know if basic 2x scaling is enough to identify any matrix issues, though; maybe I should try something fancier...

...

Oh. Also, I think I just got the Mode 7 data to DMA properly. It was a question of memory mapping, no doubt; I had it at the very beginning of the bank, in HiROM mode, and it wasn't working, so I removed all the trailing zeros (since VRAM is initialized to zero in this code anyway) and just stuck it at HEADER_OFF SEMIFREE, which worked. The attached files do not reflect this change; they still load the Mode 7 tile manually.

Apparently I need to read up on this...

[Near]

Okay, mtest and atx2 revealed to me that the PPU::Background::run() tile counter needs to be run even in mode 7. That was the cause of the shaky video on the right-hand side.

atx2 further revealed something interesting ... BG2 in mode 7 non-extbg doesn't seem to be inactive. I sincerely doubt this is a special case, so it looks like the tile counter, X coordinate and probably mosaic computations run even if the BG doesn't actually render anything on screen.

Here's a rough patch for higan v094+:

Code: Select all

void PPU::Background::run(bool screen) {
  if(self.vcounter() == 0) return;
  bool hires = (self.regs.bgmode == 5 || self.regs.bgmode == 6);

  if(screen == Screen::Sub) {
    output.main.priority = 0;
    output.sub.priority = 0;
    if(hires == false) return;
  }

//if(regs.mode == Mode::Inactive) return;
//if(regs.mode == Mode::Mode7) return run_mode7();

  if(tile_counter-- == 0) {
    tile_counter = 7;
    get_tile();
  }

  if(regs.mode == Mode::Mode7) return run_mode7();

  uint8 palette = get_tile_color();
  if(x == 0) mosaic.hcounter = 1;
  if(x >= 0 && --mosaic.hcounter == 0) {
    mosaic.hcounter = regs.mosaic + 1;
    mosaic.priority = priority;
    mosaic.palette = palette ? palette_index + palette : 0;
    mosaic.tile = tile;
  }
  if(screen == Screen::Main) x++;
  if(mosaic.palette == 0) return;

  if(regs.mode == Mode::Inactive) return;
  if(hires == false || screen == Screen::Main) if(regs.main_enable) output.main = mosaic;
  if(hires == false || screen == Screen::Sub ) if(regs.sub_enable ) output.sub  = mosaic;
}

Result:





Still recovering a bit too soon from the mode switch compared to the video, most likely due to the exact cycle at which we start the PPU rendering being off just enough to grab one more tile.

Unfortunately the mtest.mp4 isn't long enough to see if offset-per-tile was being applied to the screen or not. Gonna have to wait for a longer video of that one running on real hardware.

[koitsu]

Got my new video capture device (crossing fingers it doesn't wig out with older consoles or interlaced stuff, sigh, always a crap shoot with these things), just waiting on the AC adapter which should be here tomorrow according to USPS.

[tokumaru]

Got my new video capture device (crossing fingers it doesn't wig out with older consoles or interlaced stuff, sigh, always a crap shoot with these things)

I'm pretty sure all cheap capture devices you can find nowadays will display/capture NES video as interlaced, at least with the bundled software. But you can use VirtualDub or some other tool to convert it back to 60Hz 240p after capturing.

There is a free (open source?) capture software though, that is able to display and capture the video correctly. I can't remember its name right now... I'll see if I can find it again, if I do I'll post the name here. Anyway, this program treated the video correctly, but it was far from perfect... It was pretty unstable, crashed a lot. While setting it up, 50% of the choices I made caused the program to close.