BGMODE or parameter changes during scanline

[koitsu]

I don't know why you disabled sprites (or how you did that on the hardware; or maybe you just modified the demo source?), but your subsequent line states clearly that with sprites enabled the black dots (like in my video) are visible for you too, which means this is not an issue specific to my SNES or my setup. This is all mainly in response to this:

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.

[Augustus Blackheart]

I don't know why you disabled sprites (or how you did that on the hardware; or maybe you just modified the demo source?), but your subsequent line states clearly that with sprites enabled the black dots (like in my video) are visible for you too, which means this is not an issue specific to my SNES or my setup.

I just used a hexeditor to change the value being written to REG_TM. When I'm not working on other projects I plan on trying various modifications to the source to see if I can get anything useful or interesting to happen.

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.

My SNES darkens in the middle of the screen. A lot.

[Augustus Blackheart]

Here's a modified version of Pan's horizontal split demo.

Press left or right to decrease where the horizontal split happens. Press up or down to move the sprites left or right. Press select to toggle the sprite layer. Press A to toggle vertical plasma and b to toggle horizontal plasma. Press Y or X to decrease or increase the raster split. Press L to change the background color. Press R to reset to defaults. (Some of the toggles will mess up the timing for the scroll text).

This demo shows that the black flecks (blue flecks in this demo) are where mode 2 is bleeding through the sprite layer.

If nobody beats me to it I'll get a video posted soon.

http://www.morganleahrecords.com/august ... /horiz.sfc

Another interesting thing, now that I've changed the sprites, is that the 40 pixels of junk is part of the sprite layer. If you move the horizontal split close to the right edge of the screen it will settle down and you can clearly see a copy of the sprite layer.

edit: updated to add ability to increase or decrease sprite xpos, change background color, raster split

[93143]

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.

Sure, that works. I've PMed you.

I'm not actually all that worried about trustworthiness - you do look like a reliable character, as much as an online presence can. It's mostly a formality, since you can never be too careful on the internet etc....

It's hard for me to tell if your mtest_* stuff has the same behaviour as Pan's demo, re: black specks.

I don't think it does. The specks seem to show up on the sprite layer when it's used to mask the garbage in the BG layers that results from the mode switch; I wanted to see what the background layers did, so I didn't use a sprite mask. That flickering black area in my test is uncensored.

There are only three tiles in my tests - the colourful Mode 7 tile (which is zoomed in 2x), the partly-transparent Mode 1 numeral tile (BG1), and the blue textured Mode 1 backdrop tile (BG2). All three tiles are mapped to every entry in their respective tilemaps (which is really easy since they're all tile #0). Anything else that shows up on the screen is garbage - I suspect that area is mostly black in my case because the VRAM is mostly empty...

I sincerely do not think the SNES initialisation code is what's responsible for the "speck" problem.

I'm with you there. I think the specks would show up regardless. But the speck pattern has been observed to change between runs, and I thought that might be related to initialization. After what tepples said about the NES, though, I'm not so sure that's the explanation - it could be unavoidable hardware behaviour:

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.

Here's a modified version of Pan's horizontal split demo.

Cool. I know the results I'm getting from higan aren't exactly correct (and my laptop is too slow to run it at full speed, so the music crackles), but I can still see most of what you're talking about.

I think I'll still enhance my test code, simply because I need to learn how to do all this. But apparently there's no rush...

This demo shows that the black flecks (blue flecks in this demo) are where mode 2 is bleeding through the sprite layer.

Okay, so there may actually be a way to jigger this so the flecks are fairly unobtrusive. I mean, they're already fairly unobtrusive compared with the mess underneath the sprite mask, but if they could be made to appear in a similar colour to the sprite mask itself, they'd be almost invisible...

[Augustus Blackheart]

This demo shows that the black flecks (blue flecks in this demo) are where mode 2 is bleeding through the sprite layer.

Not really mode 2 or mode 7 bleeding through exactly, but at the point where mode 2 and 7 intersect those flecks show up and they are whatever the background color is. I'm not seeing the flecks changing color when the mode 7 logo goes under those spots.

[93143]

Given the extremeness of raster effects, I would recommend writing a very specialized, static loop for the active display area. No IRQs, no checking counters. Each line consumes exactly 1324 cycles. Then run your NMI routine (doesn't even have to be a real NMI since you know you're in Vblank now) to do your game logic, then sync up to V=0,H=0 and start the next frame.

That will require some learning on your part in how to calculate exact cycle times and penalties. But set an IRQ for V=261,H=~330 or so and then use WAI. Have that bail out so that you're now within 6 clocks of V=0,H=0. You can actually sync perfectly to V=0,H=0 but it's complicated, so you'll have to learn that on your own.

A cycle-timed game engine (or part of it) could be the best of both worlds.

Okay, so I tried the static loop thing over the weekend, and it doesn't seem to work properly if I use mostly fast cycles (the mode switch point drifts by an average of no less than one master cycle per scanline). Using mostly slow cycles, if I'm careful with the position of the fast cycles (ie: where I put the nopes in relation to the time-delay loop) I can nail it and get a wobbly equilibrium.

That's right, wobbly. The position of the switch is different on every scanline except the first, and changes every frame. This is with the first scanline perfectly synchronized and rock solid every frame (at least in higan where I can actually see the blasted thing), using an interrupt designed to exit at a constant dot position given an entry point anywhere in a particular eight-pixel range.

The interaction with the DRAM refresh and/or the HDMA seems to be really finicky. I suspect I won't be drawing any text boxes with the brightness register, and I may well end up just using an H-interrupt for the mode switch.

...

Though there was a tantalizing scenario I ran across where some frames had a ~1-dot offset per scanline, resulting in a diagonal seam, but other frames were perfectly synchronized with no wobble (after a slight offset between the second and third scanlines)... maybe it is possible to figure this out, and maybe even write game logic around the timing events... I'd have to have separate game engines for launch model and later-model decks, though, because IIRC they changed how the DRAM refresh works... and this is starting to sound like a recipe for never getting the game done...

...

Also, I added a column of sprites to mask the garbage. For some reason I don't see any artifacting; those infamous flecks don't show up even when I set colour #0 to bright green and the constant colour to bright red and change the mode switch to target Mode 2 instead of Mode 1... Maybe I should change the colour of the sprite mask; it's kinda dark on a real CRT... It would be great if the flecks didn't show up in the final game, but why wouldn't they when they do in the Anthrox cracktro?

[Near]

A little late, but I did finally merge the BGMODE updates into v094r39.

The masking you added makes mtest2 work fine without flicker now.

> The position of the switch is different on every scanline except the first, and changes every frame.

DRAM refresh occurs at a fixed time on CPU revision 1 decks; but most are CPU revision 2, where it shifts by 8 clocks every scanline. However, it's always 40-clocks long and doesn't interfere with the timing of other opcodes other than stalling you for 40 clocks. It's only a serious issue if you are trying to change your drawing effects around that area of the screen, which is effectively impossible.

Really, I think Anthrox already did split-screen the best it's going to get: mode 7 rotozoom + offset-per-tile plasma at the same time and on the same line. Not remotely useful for an actual game, but fun to go, "oh that's neat" for a few seconds and move on.

[93143]

Awesome! I've just recently gotten a functional mockup of the gameplay screen running on real hardware; it'll be nice to see it work in higan.

...how does it handle colour math? My mockup puts BG2 on the subscreen and maths it with BG1, and in higan v094 it doesn't show up. Or is that just due to BG2's position not being tracked properly? I'd post my code, but it's using near-final graphics and would thus blow the cover off the identity of the game I'm porting. Maybe I should come up with a version with placeholder graphics and post that.

...

Again, for some reason, the artifacting evident in the Anthrox demo (the "flecks") doesn't seem to be happening in my code. Maybe it's just too dark for me to see it...?

However, it's always 40-clocks long and doesn't interfere with the timing of other opcodes other than stalling you for 40 clocks.

Does it stall the CPU for 40 clocks or hog the bus for 40 clocks? It seems like a crucial difference in this case, since the CPU can be going into an internal operation when the refresh starts.

Not that I'm using pure timed code any more - my current method is mostly an IRQ chain based off a simple trampoline in shadow RAM, with only a little timed code to line up the position of the register writes to within 8 dots regardless of what was going on when the IRQ fired.

[Near]

> ...how does it handle colour math?

Color math should be emulated correctly, especially thanks to AWJ's improvements.

This may or may not fix mid-scanline PPU register changes involving it, I don't know. You can send me your demo via PM and I'll send you a screenshot that way if you want. Otherwise, wait for v095 I suppose.

> the artifacting evident in the Anthrox demo (the "flecks") doesn't seem to be happening in my code

I don't know what that refers to.

> Does it stall the CPU for 40 clocks or hog the bus for 40 clocks?

It stalls the CPU. It absolutely has to. The bus is writing to DRAM during this time (I really don't know exactly what it's doing, I presume it's a pattern of {read, read+write, read+write, read+write, write} on a 17-bit counter; but who knows)

[Joe]

(I really don't know exactly what it's doing, I presume it's a pattern of {read, read+write, read+write, read+write, write} on a 17-bit counter; but who knows)

DRAM usually has three access cycles: read, write, and refresh. All three will refresh the contents for the entire row, but refresh cycles are the fastest way to do that.

If the memory controller isn't capable of refresh cycles for some reason, it can use read cycles to refresh the DRAM instead.

[tepples]

Why doesn't it just refresh the RAM on "IO" (internal operation) cycles, which I understand to be cycles when the 65816 is pulling neither /RD nor /WR low, and insert a refresh pause only if there hasn't been an IO in a while? Was that logic too hard for N to implement compared to stealing 5 slow cycles every line?

[AWJ]

Why doesn't it just refresh the RAM on "IO" (internal operation) cycles, which I understand to be cycles when the 65816 is pulling neither /RD nor /WR low, and insert a refresh pause only if there hasn't been an IO in a while? Was that logic too hard for N to implement compared to stealing 5 slow cycles every line?

The 128KiB DRAM seems to have been added fairly late in development--probably after Sega revealed the Megadrive's specs. Early promotional materials describe the SNES as having just 8 KiB of work RAM (the same as the PC Engine).

[93143]

You can send me your demo via PM and I'll send you a screenshot that way if you want.

What the heck; I haven't exactly been keeping it a secret from people I know personally. I just don't want it to be public yet (way premature, you know?)...

And hey - if it doesn't work, we've found a bug in higan...

the artifacting evident in the Anthrox demo (the "flecks") doesn't seem to be happening in my code

I don't know what that refers to.

On real hardware, the Anthrox demo shows a pattern of black flecks, single-pixel or smaller, in a vertical stripe on the sprite mask. The pattern varies between frames in a regular sequence and can change when the system is reset. This effect is presumably related in some way to the mid-scanline PPU manipulation.

I take back what I said above; there does seem to be something similar happening in my test, but it looks pretty sparse, and because my sprite mask is so much darker it's almost invisible. I had to turn my TV's brightness to maximum to see it, and I'm still not 100% sure it's not just an analogue video artifact...

However, since I lazily started the H-IRQ one line early due to having to start HDMA early and not wanting to bother working out the timing on a fourth H/V-IRQ, there is a bit of somewhat more visible artifacting on the last line of the upper border above the sprite mask. It's still not terrible - a barely visible flicker under normal viewing conditions - but I suspect that extra IRQ is worth the effort...

Does it stall the CPU for 40 clocks or hog the bus for 40 clocks?

It stalls the CPU. It absolutely has to. The bus is writing to DRAM during this time

I know normal processing uses the bus heavily, and that the bus can't handle refresh and normal processing at the same time. I'm wondering about the exact timing of the stall - does the CPU pause instantly, or does it pause the moment it tries to access the bus? I had some trouble with my cycle-counted loop not taking quite the same amount of time every scanline, with the variance changing each frame despite my dot alignment code apparently working perfectly (the first scanline never moves), and I was wondering if CPU internal operations coinciding with the start of the DRAM refresh might be the reason. I figured you would know this, since higan and my real SNES seem to show the same timing behaviour.

...

One other thing bugs me, and that's my use of HDMA to manipulate CGRAM. In fullsnes, nocash claims that CGRAM writes during HBlank sometimes work and sometimes don't. But I've been using HDMA for this for a while now, including one very busy test in Mode 3 using all eight channels just for CGRAM while displaying nearly every sprite (though BG2 was unused) and doing intensive calculations involving instructions as long as 6 cycles. I've never seen the technique not work perfectly. Should I be worried?

[Near]

> And hey - if it doesn't work, we've found a bug in higan...

It does work. Quite a striking difference from v094, too :D

You're gonna get so much crap from people claiming you made the game "bsnes only", though :P

> does the CPU pause instantly

Instantly. One thing I'm not sure on is if it happens between cycle edges or absolutely immediately. My presumption is between cycle edges, because otherwise you'd be stalling out a cycle in the middle of its own read, which could have been to DRAM.

Haven't come up with a surefire way to verify this, though. Anything you can observe through software will give the same results either way.

> nocash claims that CGRAM writes during HBlank sometimes work and sometimes don't

I've never once seen a CGRAM write fail. It's just that the PPU can override the address when it is fetching its own pixels, so your writes won't go where you expect them to.

However, I'm not saying nocash is wrong. It's possible my test just so happened to always write when it was possible. It seems reasonable that there'd be bus conflicts in reading and writing at the same time, but I haven't observed that myself.

Either way, given what you're doing, verify on hardware no matter what and you should be fine.

[tepples]

You're gonna get so much crap from people claiming you made the game "bsnes only", though

"It works on a Super NES, which is what matters. This is a wake-up call to nocash and the 9x team to get their behinds in gear. Until then, if it's not bsnes, it's just bs."

Instantly. One thing I'm not sure on is if it happens between cycle edges or absolutely immediately. My presumption is between cycle edges, because otherwise you'd be stalling out a cycle in the middle of its own read, which could have been to DRAM.

Perhaps that's why it's 5 slow cycles, not 4: to let the previous cycle finish. You might need a logic analyzer to verify this though.

Haven't come up with a surefire way to verify this, though. Anything you can observe through software will give the same results either way.

Might NES timing details (the 513/514 cycle OAM DMA thing and the DMC DMA waiting a few cycles for an interrupt's triple-write to finish) inspire something?