BGMODE or parameter changes during scanline

I know this has been discussed before, but I can't find any reference to a conclusion.

Was it tested? Does anyone know if you can change BG modes mid-scanline?

If not, is it possible to change scroll parameters (and matrix parameters, if in mode 7) in order to fake it?

I don't have a flash cart, and probably won't any time soon, so I can't test it myself, but this and a couple of other questions have been driving me nuts...

Well, it's obvious you can, but what effect it will have is a mystery.

I can test things for you on my Super Power Pak and PAL SNES if there's a need to, but I can only do so if you give me a ROM. I know few things about the 65816 and SNES hardware, really so I can't code a demo myself.

I believe there are commercial games which do switch modes mid-scanline. But right now it's late and my brain can't remember which of them which do it...

Summoning byuu! :)

Thanks for the offer. I may take you up on it once I'm halfway competent at this myself...


That would honestly surprise me. The way it's been talked about in the past makes it sound like an edge case among edge cases. Scroll positions, maybe, but modes?

Granted, the information I have is patchy and stale - I'm very new to the SNES programming scene...

Yeah, I'm thinking modes -- as in part of the screen is operating in MODE 1 and another part is operating in MODE 3. I just wish I could remember which games did this.

Hmm, now that I'm thinking about it, and this is just me pondering (I haven't taken the time to investigate), but possibly Super Mario World uses it during boss battles (main background/playfield is MODE 7 but the score/life/coin bar is probably some other mode?) or Contra 3 (2nd stage, entire screen rotates as the player moves around, same during the boss battle, while there's a status bar at the top). I suppose the status bars in question could be done with sprites though. Just dumping thoughts as I go here...

I think many of the mode 7 racing games (like F-Zero and Super Mario Kart) use another mode for the horizon area, but not changing during the scanline.

SNES modes affect the entire screen, so I don't know how someone would accomplish that without either HDMA (writing to $2105 at a specific scanline, hence changing mode), or through $4209/420a (letting you pick a scanline in the register and when the raster gun hits that scanline, the code at the NMI vector is called, and NMI would change $2105).

Yeah, I was thinking rewrite the mode in a vcount interrupt handler.

I thought of using a H-Blank IRQ to change the BG Mode as a possibility under the condition that the GUI actually covered up the background in the process. I could also in theory do this for a port that I am considering, using Mode 7 to simplify the pixel drawing process (I am going to use this to zoom in a display that would normally be very small), but using a different BG mode for displaying something else.

Mid-frame, yeah, all the time. Mid-scanline, nah, some games toggle BG layers on and off in the middle of a scanline, more of a timing issue usually caused by using IRQs instead of HDMA. ASP also messes with BGSCROLL mid-scanline to surprisingly good effect. And of course ASP also does INIDISP (display brightness) mid-scanline, to less successful effect due to the impreciseness of IRQs to cycle positions.

You can definitely write to BGMODE in the middle of a scanline, but I don't know what the consequences will be, as I am too afraid to try it. A lot of registers are cached at various times during the scanline. If BGMODE isn't one of them (and it wouldn't surprise me if it weren't), then you'd probably get what looks like gibberish for the rest of the scanline.

Emulating the PPUs perfectly would require perfectly capturing when each variable was read, and mastering the state machine that manipulates those values during rendering. Could easily sink another 5+ years of full-time research into that and likely not even come close to nailing down the extreme edge cases.

The practical use, if you could actually pull this off ... would be to have the left-hand side of the screen be one mode (say a text display that wouldn't work with sprites for some made-up reason) and the right-hand side be another mode (probably mode 7.) Ostensibly with black filler pixels between the two sides of the screen. Not all that useful. Sprites are pretty versatile. Maybe doing hires text/art on one side, and mode7 on the other, would be sufficiently unique ...

Hey thanks byuu. Your reply actually made me realise a big mistake on my part:

The subject in question was with regards to mid-scanline mode changes (as in changing $2105 outside of HBlank), and I even said "there are commercial games which do switch modes mid-scanline".

But what I said is false/inaccurate -- what I was thinking of (as my subsequent replies implied) were games that tweaked $2105 at the end of a scanline / during HBlank (I even have a SNES music pack demo that does that (and boy does it make emulators angry, but I haven't tried bsnes/higan, I imagine that probably gets it right)).

No, I don't know of any games that do mid-scanline mode changes, just ones doing it during HBlank.

I guess I wasted a bit of everyone's time. Sorry folks. I should have paid closer attention/read more slowly.

Thanks for the response. Unless another heavy gun like nocash has been messing with this, I guess it's safe to assume no one knows.

Though the fact that scroll parameters can be changed is encouraging - if the matrix can be changed too, it might be possible to fake a mode change, though I imagine you'd have to mask some garble with sprites (or turn the BG off) because it would take a while to hit up all those registers even with DMA...


I do have a scenario in mind. It's a port, so I don't have much design freedom, and the result is that I am so overloaded with sprites that I'm not sure I can reliably stay under the scanline limit (or the global limit for that matter) even if this trick works perfectly. Nerfing the game is an absolute last resort; gameplay fidelity comes ahead of visual fidelity - but I'd still like as much visual fidelity as possible...


I kinda figured that might be what you meant, especially after seeing the subsequent conversation. And you did mention you were tired...

Pehaps you should post a screenshot of what you're wanting to do, so we can help you.

I doubt any emu support midscanline mode change, so if the hardware supports that, your ROM will probably be hardware-only (until BSNES starts to support this).

Perhaps I should, now that I've mentioned the idea. And I appreciate your willingness to help. But I have a possibly irrational desire to keep this as far under my hat as I can for as long as I can. Part of it is that I'd really rather not look like I'm promising something I can't actually pull off, or that will take so long as to be effectively the same thing (ever heard of the Nearly Upright?)...

I will say this: It's a bullet hell game. The score/lives/etc. are on a textured overlay next to the playfield. There are way too many independently-moving bullets for the SNES to have a hope of handling them as sprites, so I plan to blit them with the Super FX chip. The trouble I'm referring to with sprites happens when the playfield is in Mode 7, because I don't have a background layer to blit to. This means that in the general case the whole playfield is covered in a layer of tiled sprites, which doesn't include the player, the player's bullets or any enemies or powerups unless I can jam them into the palette I'm using for the enemy bullets. I could rearrange the screen to get the HUD out of the playfield's scanline range, but I'd really rather not...

...

Fool's errand? Maybe. I haven't seen anything yet that looks like an obvious showstopper, but every part of this game seems to be pushing the system in some way; I had to trim the title screen vertically a bit because I ran out of VRAM and DMA bandwidth at the same time...

This is why I like the project; it's marginal. People have actually said that it's impossible, no way no how, and I disagree. But it's also why I'm asking questions now - I want to establish what's possible before I start.


I'm cool with that, as long as I can get my hands on a dev cart with the hardware I need (GSU2, MSU1, maxed-out Game Pak ROM/RAM as well as a full load of backup RAM and a bunch of extra ROM the GSU doesn't know about, which according to the manual is something you can do)... I'm hoping the sd2snes ends up being that dev cart; it's easily the most promising option I'm aware of...

Besides, if I can show something useful working on hardware, at least in the context of a finished game, I'm sure higan will support it before too long...

Perhaps the hardware you need is a Game Boy Advance, which has a 4x overdraw for sprites and the ability to rewrite OAM mid-frame.

Do you have a screenshot of a comparable game in the same genre? Or should I just say "perfect cherry blossom" and leave it at that?

I have an idea of how to add hi-res mode. Use Mode-0 with psuedo-hi-res with BG0 and BG2 on main-screen, and BG1 and BG3 on sub-screen. BG2 and BG3 would have a "dot-interlaced" action screen and the HUB background, whereas BG0 and BG1 will be used for the HUB font. I don't know if the FX-chip is fast enough to calculate the most convenient set of color palettes for each tile though.

Oh, so you mean there's going to be more than 128 bullets on screen at the same time ?!
Even if that's the case, how's the CPU going to handle them ?

If you require the Super-FX chip I definitely can't test it, as the Super Power Pak only supports no chip or the DSP-1. I don't know how much the DSP-1 helps at rendering stuff on the screen, but I don't think it does help at all.

You can't have mode 7 and another BG, period. However, you could simulate mode-7 effets without using mdoe 7 at all. Especially if you have a Super-FX chip.

I would imagine that even if this worked, if mode 7 was on the right side of the screen (or just anywhere that's not the leftmost side) it's very likely that the deformation computations would be completely wrong since they weren't started at the left side of the screen. Or does the hardware compute it regardless of which mode is currently being displayed?

I would imagine this could screw up other modes as well in similar ways (e.g. tiles not being fetched correctly at the transition area, scrolling being broken, etc. - depends on how the hardware implements this).

It depends on how big the "mode-7" layer is, if it is scaling, rotation or both, and if it's a full 360 degree rotation, or just tilting. If it's small sprites, it could pre-rotate sprite frames in wram while the game is running, so it can smoothly rotate several sprites by the time they appear onscreen. Same for scaling, but both at the same time would eat up a lot of wram. If it is a larger object, that is 128x128 or 256x256, it can be smoothly tilted back and forth using MODE-2 offset-per-tile mode, and HDMA line-scrolling. You can use tilting to transition between large rotation steps, to make a full 360 degree.

I can't help but think that the simplest is to make 2 bullet in a single sprite. Then it'll be complicated to draw them of course, but at least you'll use only sprites.
With 8x8 sprites, you can have 64 sprites for showing 2 bullets in the same tile with all possibilities, assuming they're just a 1-pixel dot.

I have another idea. Use a 2bpp layer for bullet sprites, and have software sprites using 2 palettes, and use the 8 hardware palettes as gradients from one palette to the other, to create a glowing effect, when two sprites of different palettes are in the same tile.

Yeah, but as far as I know nobody's ever said it was impossible to do this on the Game Boy Advance.

This isn't some brilliant and original concept I'm trying to realize and should pick the appropriate platform for. It's specifically an attempt to cram an existing game onto the SNES (which has a much specialer place in my heart than the GBA, not to mention better sound). If I'm allowed to switch platforms, there's no point; I might as well go play the original.

I already know I won't be able to get it pixel-perfect. And I also know that a nerfed version is possible - worst case, I have to abandon both scaled/rotated backgrounds and 100% faithful bullet patterns. The question is how close I can get.


That's close enough, though I'm dubious about the GSU2 being able to handle that game. Same general idea.

That was a really good guess... was it that obvious?

The attached pics (from Perfect Cherry Blossom, because why not) show a case similar to what I'm worried about - a ton of bullets on screen, a line of enemies pouring in from the side (each side, in this case), and a lot of shots from the player (way more than I'll need to deal with) as well as some powerups (using the term loosely here), all on top of a scaling and rotating background. Don't worry about the snowflakes and cherry petals; the game I'm thinking of doesn't do that sort of thing.

It would be a major challenge to fit all the moving objects into one 4bpp palette and still have them look halfway decent, especially with multiple different-coloured bullets present... but doing just the enemies might be feasible in spots, if I'm really stingy with the colours. The problem with doing the sidebar in sprites is that with a Mode 7 playfield I'd have almost no capability to have anything in it that wasn't part of either the blitted surface or the Mode 7 BG itself. Even if I were to use a constant colour for the overlay, which could be done with windowing, the HUD data would eat into the available sprite tile count.





It's not. I'm hoping to have enough horsepower left over on the GSU2 to run the bullet engine and do collision checks. That way the S-CPU only has to run the rest of the game, which isn't especially demanding.


The final game would require a GSU, but a test ROM addressing the thread topic would not.

I'm not going to ask you to become a remotely-operated dev kit for a game. Among other issues, the logistics of that would be ridiculous. I'm hoping the sd2snes supports what I need by the time this project enters full-scale development (by which point I should have the spare cash to buy one); if not, I may have to take apart a copy of Doom or something...


If the Super FX were tasked with rendering the background too, the only way to get 30fps with this size of playfield would be to use 2bpp for both layers, which would look awful, and even then I doubt you'd have enough power to scale and rotate an entire layer that fast. For the same colour depth Mode 7 + sprites gives you (8bpp + 4bpp), the ceiling drops to 10fps.

Just blitting the bullets at 30fps takes up the bulk of the power available even at 21MHz. I'm still not sure it's even possible, but the way the GSU handles pixel plotting is rather nice and I may have a trick up my sleeve...


Possible, and I'm (kinda) prepared to be disappointed in this. But as Bregalad once said, "we're not going to re-invent the SNES PPU and this should be tested."


I suppose I could look into that; it seems you've been doing some good work in that area...

There are parts where a large background consisting of almost entirely unique tiles (it pretty much fills up Mode 7's memory map) is scaled to fill the playfield and doing 360° rotation. There are also parts where the background is doing F-Zero-style perspective (or maybe even Pilotwings-style), though with fewer unique tiles. There's even a part where I was considering abusing HDMA to make Mode 7 look like polygon graphics with a minimum of CPU rendering involved...

I think that with tricks like those you describe, the sections with intricate rotating backgrounds would take too much memory unless they were redrawn to use vastly fewer tiles. DMA is pegged in the general case because of the bullet layer, so everything has to fit in VRAM.


That might work for an original game, but unfortunately these bullets are not just 1-pixel dots. (I'd have no doubt about being able to draw them with the GSU if they were...) Scaled to SNES resolution, they range from 4x4 to 32x32, with the bulk of them being 8x8. Also, your method limits you to 256 bullets onscreen if nothing else is happening and each one is next to at least one other, which is still too few.

Plus it doesn't do lasers. Did I mention there were lasers?


...buh?

Okay, I think I get it.

I'm a bit dubious; I think that there are bullets in this game that would suffer quite a bit with a colour limit that tight, especially some of the big ones that span multiple tiles. And while this scheme looks like it would enable 60fps without the drastic NESification of a monolithic 2bpp layer, I'm not sure the GSU could keep up... But it's something to keep in mind.

Hah, sounds like either Layer Section or Radiant Silvergun.

Anyway, doesn't the SNES have a windowing parameter that lets you set the right side of the screen to all black / BG off / whatever? Then you'd use sprites for the score only in that area.

The idea of splitting the screen or otherwise updating registers or video chip state mid-line has been used successfully on other systems. On the C64, where it's fairly easy for a seasoned programmer to target a specific cycle on a given line, I've seen it used to have one half of the screen (usually the left) in hires character mode and the other half in the software FLI mode (which also adds a requirement of changing the screen base address on each line and triggering a new badline to force the VIC-II to re-fetch said address. There are also "raster splits" which are more simple, and only consist of targeting specific cycles on each successive line. Also, the "direct color" technique on the Mega Drive is done, if I understand it correctly, by syncing to the beam using the FIFO and then using DMA to repeatedly stuff the desired backdrop color value into CRAM, which necessarily involves changing said values many times mid-line. I also know it's possible to update some registers on the MD successfully mid-line, such as the backdrop register itself, allowing the use of any of the 64 color slots arbitrarily at any position that one can construct cycle-exact code to target (which is different from the resolution possible with the DMA technique, as DMA can't target the VDP's registers, and thus you're limited to writing such data with the 68k). All such techniques obviously require either syncing to the beam (which C64 coders call getting a "stable raster"), or using sprites to mask the split (which may not be possible, depending on how the hardware switches modes, which is why splitting the screen between H32 and H40 on the MD is not useful, even when not done mid-line). If it's possible to reuse a given sprite slot after it's already been displayed on the screen, it may be possible to limit the sprite overhead for such masking to one or possibly two sprites (depending on whether there is any required delay on such reuse).

Exploration of such techniques can be useful in terms of demoscene effects, in some cases. The majority of the major C64 demoscene is based around finding such useful edge cases and documenting them, and then making cool shit with them.

You might as well keep the sprite layer 16 colors, if you need f-zero style background and your fine with 30fps sprite movement.

EDIT: If you trim the frame to 184, and have a 152x176 gameplay screen, you can pull off 256 colors at 30fps.

Yes it does. Two sets of L/R coordinates that can be changed between scanlines and applied to different layers individually; hence all the big translucent coloured shapes and Looney Tunes screen transitions in SNES games... But the score has enough digits that without using a narrow font and rendering it down, I'd only save maybe four tiles that way, leaving six or seven total. I need more than that just for the player's shots. There are other sidebar elements that take a lot of tiles too, unless I sacrifice visual authenticity for low tile count. I'd prefer to have all that be background if possible; I need all the breathing room I can get...


Great minds etc.... The trouble is that last I checked, no one knew if rewriting OAM outside VBlank was possible on the SNES. The system certainly goes out of its way to make it difficult...

But if it works, I wouldn't say no to saving close to 50 sprite slots on a pair of 8-pixel masking columns... and if bullets could be cloned this way, it might be possible to get 60fps with multiple 4bpp bullet palettes, only blitting when the scanline limit is exceeded (though it might be computationally intensive to schedule all this in real time, besides which exceeding the scanline limit is easier than I'd hoped). This was going to be the topic of another question thread, actually...


I think that's the path of least resistance.

Though now that I think about it, there is at least one spot where a boss fires nothing but a huge number of small, fast, identical bullets that would look fine in 2bpp and might be easier to dodge at 60fps... It's on a Mode 7 candidate background, though, and it might be too fiddly to try to DMA the first two bitplanes of a sprite layer by themselves...

Regarding 30fps, maybe I should try to engineer a way to play the original at 30fps and see what happens. I imagine it should look and play fine, but experimentum solum certificat in talibus... Even then, that doesn't tell me what it's like having the background and player's sprite stay at 60fps (should be a plus), or the effect of the coarser resolution (should be a minus)...


I come up a bit short, even without any OAM access:

(262-184)*(1364-40)/8 = 12909
152*176*30/60 = 13376

Either way, the idea seems sound, but for this application the playfield is getting a bit small (not to mention a bit squashed; I'm trying to preserve screen aspect ratio). I don't think it's worth the loss of real estate for 8bpp, and I don't want to drop the frame rate below 30 (except maybe in special cases) if I can possibly avoid it...

Also, if I'm understanding the Super FX right (another topic that was going to be the subject of a question thread), 8bpp takes twice as long to blit as 4bpp. Of course, that only matters if I can code the renderer efficiently enough that the transfer between the secondary pixel cache and the GSU's work RAM is the bottleneck...

How will the sprite VRAM work? There is only 16kB of VRAM for sprites, and you would need to do some double buffering. Somewhere in the frame, there must be a page switch.

Wait, what?

See, that's the kind of thing it's easy to miss when you're trying to teach yourself something like this in a big hurry without any real pressure to use the knowledge right away... yeah, maybe I shoulda paid more attention in OAM class; this one's pretty basic...

Still, it seems that a 144x192x4bpp bullet layer fits in 16 KB with 2.5 KB left over, and which sprite table is being used is set per sprite, not per frame. Paging should be easy enough if you can write to OBSEL between frames, which you can... I'm not seeing the issue here.

152x200 fits too, but it doesn't leave nearly as much headroom in terms of either sprite memory or VBlank time...

What am I missing?

Yeah, you should be able to alternate between a 16K table at $4000 (main at $4000-$4FFF and alt at $5000-$5FFF) and a 16K table at $6000 (main at $6000-$6FFF and alt at $7000-$7FFF). But what tile ordering does the GSU expect? And what does the title screen of Yoshi's Island do?

Or (it seems to me) you could use three 8 KB tables at the cost of some OAM reshuffling. Fill the unused table first, then fill one of the ones you just got through using and use it again. I suppose this would glitch if the frame rate dropped...

The GSU in sprite mode has a 256x256-dot OBJ plane composed of four 128x128 sprite tables. I think you can PLOT across table boundaries, which would require some care to handle properly. It also has three monolithic BG modes: 256x128, 256x160, and 256x192, which it can plot to in 2bpp, 4bpp, or 8bpp. I presume one could DMA the results out of game pak RAM in any order one chose...

I have no idea what Yoshi's Island's title screen does, but I don't see anything that couldn't be accomplished with HDMA...

...who designed this chip? What are the S-CPU bus access enable flags doing in between the size selector bits in the Screen Mode register?

What is the VRAM increment flag doing in between the nametable select and pattern table select flags on the NES PPU? Sometimes you have to squeeze bits wherever there's room in address space.

I'm not really complaining; it just seemed like a really odd place to put them... Perhaps it implies feature creep during the design phase...?

Well, whatever. I'm certainly no chip designer. If it works, it works...

...

Maybe I should start learning how to use interrupts so I can code a test ROM instead of dragging my own thread off topic...

I'm guessing 128x192 of it would be stored normally, and the 16x192 left would be stored as a bunch of 8x8 patterns.

My idea of using a single sprite for 2 bullets would also work for bullets up to 8x8, using 64 different 16x16 sprites. If priority between bullets matters you'd have to use 128 of them (which starts eating a lot of VRAM).
But yeah, it's limited to 256 sprites and they should be close to eachother by pairs for this to work.


Otherwise, the only thing I see is simulate a BG layer with large sprites and have the GSU or whathever chip draw to this "BG" layer while the background is done with mode 7. Then you're limited in colours for all the sprites. I think you can do this with 8x7 = 56 sprites of size 32x32, then you're limited to 16 colours in a 32x32 pixel area. Pehaps it's managable if you use 16 colours for the playfield, and then customize the sprite arrangement for the side status bar.$

Nevertheless, the effect of a BGMODE write during scanline still has to be tested.

Okay, I'm about to try to code a test ROM.

Are there any tricky bits or gotchas I have to watch out for? Any way to get a 'maybe' out of this test? Or is it really as simple as loading VRAM and the relevant registers with the data for both modes and setting up an H-IRQ to write to $2105?

If I can make it change, say, the screen brightness in the middle of a scanline (should work in higan accuracy), and if I can change the screen mode successfully during blanking periods, is there anything else I have to worry about or can I just retarget the IRQ code?

May want to release the source code of the test ROM so others can mess with it easily in case the test is not correct or there's something else to be tested.

Otherwise, no idea. Should be as simple as making the change at the correct point on screen.

The really obvious one is your HIRQ will not trigger at an exact cycle point each scanline. The net effect is the exact position of change will waver seemingly randomly based on the instructions executing around it, so you'll have a zig-zag pattern on the screen, which will also likely change every frame.

You also won't be able to write to the 40-cycle (10-pixel) area around DRAM refresh, which is somewhere around the middle of the screen.

I would imagine that writing to the registers shouldn't be affected by the DRAM refresh restriction (since they aren't in DRAM, right?). Is that correct? (not like I expect it to work properly anyway, but that's the whole point of the test)

Perhaps the memory controller needs to monopolize the address bus while doing the refresh cycle. I wouldn't be surprised if the circuitry for DRAM refresh resembled the DMC circuitry in the NES.

That is incorrect.

Is the 65816 going to run the game logic, or is it just going to sit there?

Game logic, per the current plan. The bullet engine, collisions, and rendering are going to be plenty intensive by themselves, and I don't want to have to nerf the bullet patterns to fit extra logic into the GSU program (or skimp on the extra logic and end up with a less accurate port) if the CPU could have handled it. The precise division of labour is of course TBD, but I don't think the bullet engine needs to be all that tightly coupled to the game engine...

Besides, I'm already dubious about fitting all the graphics and music into 16 Mbits, so it's probable that I'll need a chunk of what the manual calls CPU ROM - ROM that's not behind the GSU and can't be accessed by it. And if I need that extra ROM anyway, why not put code in it?

I think it's more elegant to have both processors doing what they do best as far as possible. Still, I'm probably way too new at this to say for sure yet.


That sounds like a good plan, once I've got something worth posting. Right now I feel like I should do a bit more investigating myself - I've had a bit of trouble with other people's DMA macros...

I did manage to get an IRQ to change the brightness at a point on each scanline. So once I get DMA working properly (or just give up and poke all the data in manually), I should be good to go.


Yeah, I got a bit of a scrolling, flickering crenellation effect one pixel wide. I guess WAI isn't as unpredictable as actual game code...

Regardless, if this were to actually work I would happily accept the necessity of masking any such seam with sprites. As long as, y'know, it doesn't glitch out the OBJ layer...


I had been worried about this. But I recently took another look at the game, and it seems that the big high-colour bullets tend to occur in fairly strictly colour-themed barrages. I think it should be okay.

Okay, I managed to get the data for both modes into VRAM at the same time without having to manually transfer all of it. Anyone who cares to can investigate why the DMA for the Mode 7 data doesn't work - I've tried writing out the method myself, and I still get nothing, or at most an array of pink dots in no$sns (higan gives me nothing regardless).

Whatever. This works.

Here's a screenshot using brightness as a proxy for screen mode, so as to enable testing in higan. The top half is mode 1, two layers, and the bottom half is mode 7. All three backgrounds use a single tile.


Altering the IRQ to target $2105 instead of $2100, and removing the mid-screen mode change during HBlank, produces a primitive test of mid-scanline mode switching behaviour. It kinda works in higan (which is unexpected, and renders the above exercise slightly pointless), but not well enough to be useful:


Yeah, the right-hand side of that keeps jiggling back and forth. Going from Mode 1 to Mode 7 does the same thing. With real game code messing up the IRQ timing, it would probably be worse. And resetting $210D and $210F to zero doesn't help... it kinda looks as though it's using the mode switch as a horizontal baseline, instead of the actual beginning of the scanline...

Hopefully this is just an artifact of how the dot-based renderer was coded, and a real SNES will do a better job. If not, I may have to try messing with scroll registers and matrix registers, and see how well that works in Mode 7...

...I wonder if I could try to use the H-position register as a scroll reference during the interrupt... okay, no, I will find out what the behaviour really is before trying to fix it...

On real hardware from right to left 9 1's are perfectly still. The next three 1's are chaos, similar to Pan's horiz demo (sprites are used to cover the mess in the center.) Higan was the only emulator that displayed even that much correctly.



Below are the original horiz source code and the sneskit development environment with the snesmod2 example that uses horiz. All you should have to do is run make.

http://www.morganleahrecords.com/augustus/blackheart/src/atx2.zip
http://www.morganleahrecords.com/augustus/blackheart/src/sneskit.tar.xz

(edited: updated sneskit archive with win32 binaries for ca65 and ld65 and snes_rules_win32 which should replace snes_rules for anybody running windows.)

What.

You mean this was tried twenty years ago by a first-generation SNES demoscener?

And it works? (I assume that's what you mean by "perfectly still"...)

I guess that's the takeaway - it works. And from your description, it seems to work well enough to enable what I want to do. If it's only a few tiles worth of garbage, I can easily cover that with a column of 32x32s.

...

Reading that old code is kinda surreal, even for a n00b like me. For one thing, I've never seen anyone deliberately add a Super Magicom header before - I imagine if you're working with an actual Super Magicom you kinda need it...

This is pretty badass. Thanks.

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.

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.

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/augustus/blackheart/tmp/mtest.mp4
http://www.morganleahrecords.com/augustus/blackheart/tmp/horiz.mp4



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.

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.

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.

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...

> 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.

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.

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...


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.


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?

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*

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).

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.



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...

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+:



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.

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.

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.

I tend to use VirtualDub as much as possible, but when it comes to deinterlacing I really prefer that the hardware capture device do it natively. To date I have yet to see a software deinterlacer do even a remotely decent job, and it's all because they're working with "post-rendered" results (dunno what else to call it). Things work a hell of a lot better if the actual hardware handling the video signal is what handles the deinterlacing correctly -- that Firewire/DV capture box I have actually does a great job deinterlacing (I used it do save a lot of old VHS recordings that look quite nice), but the last time I used that was like 8-9 years ago, and my PC now doesn't have Firewire nor do I have room for an expansion card, hence new product.

The device I bought claims to do up to 60fps in a multitude of modes, but I always take those claims with a grain of salt (meaning some jackass at the company probably tested HDMI 1080p @ 60fps, was able to do it, and thus said "say we support it, ship it" but probably didn't test anything else). That's what I mean by "it's always a crap shoot". I guess I'll be finding out soon enough. If the product turns out to be crap I can always return it and try this instead.


I remember seeing some (free) Japanese software that supposedly worked wonderfully but also cannot remember it's name. Just remember if you recommend anything, please ensure it works on Windows XP. (The product I was going to buy, which was recommended to me by literally 4 different people, doesn't support XP, which is why I bought what I did).

Are you talking about OBS (Open Broadcaster Software)? https://obsproject.com/

I had the same symptoms with it, most deinterlacing options caused it to crash (seemed to be ones implemented with shaders).

I think the worry is that some capture devices won't sync to 240p at all. I have a DVD recorder that records NES fine but records Super NES in black and white. Another device records GameCube fine (because it's 480i) but says "recording failed" for NES.

As for "having the capture card do the deinterlacing", that depends on how you define deinterlacing. A lot of people use it to mean "inverse telecine", or reconstructing 24 film frames from the 60 fields implied by 30 captured frames. That's not the same thing as extracting 60 low-definition, high-motion frames from 30. I'm inclined to just trust VirtualDub to pull out odd or even lines.

Nah, not OBS (I've posted on their forum anyway asking why XP isn't supported, and there's basically no justification -- and the author actually admits that, stating "Yes it's fully possible, but I just chose not to bother". There's like one specific UI-related feature that uses Vista+ features that that has nothing to do with the actual capturing).

What I'm talking about is some Japanese video capturing software (not SCFH DSF by the way :-) ), it's like VirtualDub but without any editing capability, it just interacts with DirectShow and WDM devices both and lets you adjust all sorts of really low-level stuff. It's just a little standalone app, very small, and bare-bones. I'll ask my friends to see if they remember.


Correct -- you hit the nail on the head.

And what I feared was true.

First and foremost, nothing can seem to "connect" to the capture driver itself; VirtualDub fails with a vague message, and Skype (just as a test) also fails.

Using the native software that comes with the thing, something called VivaStation, I'm able to get video and audio (makes you wonder what the hell is going on at the driver level that causes this thing to require custom software to interface with it), but the live overlay results (i.e. native screenshots aren't possible) are very badly interlaced -- until you do an actual video capture, then the preview becomes non-interlaced (sometimes, but not always).

Regardless if you're capturing or not, the responsiveness (between pressing a button on the controller and seeing something change on-screen) is nearly 3 full seconds.

It seems to support VMR7 and VMR9, and the resulting capture files are something called m2ts, which is some kind of BluRay MPEG-2 stream, which VirtualDub cannot read. Crap I found on the web indicates Windows Media Player can load m2ts, but not on Windows XP. So I'm not sure what VMR7 and VMR9 have anything to do with m2ts, which is MPEG-2. Very confusing.

On the bright side, VLC 2.1.5 can play it, but man I hate that software. You also have to adjust specific settings in VLC to get it to look right, specifically Video / Deinterlace / Automatic, then set Video / Deinterlace Mode / Discard. Otherwise the video either flashes between a frame and a black frame, or the brightness is too dim.

It also randomly seems to "get lost" with its video syncing, in the sense that sometimes at the bottom of the video there's just a flashing colour, preceded by a darker thick line. *shakes head*

So when I talk about these things being extremely wonky/sensitive/ridiculous, regardless of cost, this is what I'm talking about. I've included a screenshot but it doesn't do it justice even remotely. Edit: I've added a couple screenshots from within VLC of Super Metroid (with the above settings applied).

@byuu -- if you can work with the above (m2ts files and use VLC), I can capture something for you. I'm just worried about the quality because we're talking about something that's very timing-sensitive and any kind of garbage or anomalies make analysis even harder. I'm really not thrilled that I can't capture with VirtualDub, because that'd make frame-by-frame analysis a hell of a lot easier.

And now it looks like my SWC DX is also broken somehow. The first time I plugged it in, some device (pretty sure the SWC) made a noise that sounded like electrical interference or something very bad happening power-wise, so I shut the SNES off. Now no matter what I do I can't get the thing to give a picture with the SWC DX plugged in, so I have a feeling my copier is fried. (I'd better go harass Front Far East! Hahahaha...)

I'll have to take it apart and see if I can figure out if something is blown and/or replace it. Otherwise I guess I need to get myself some kind of SD card for the SNES, or maybe one of those SNES PowerPaks. *grumbles*

Edit: Oh foo. I forgot the damn thing uses its own AC power supply, although I don't remember it requiring one to function... so maybe some part of it is just busted. Else I'll go figure out what voltage and polarity that has. And once I opened it up, it looks like the CMOS battery is... well, let's just say it probably needs to be replaced, I see what looks like corrosion on one of the leads.

Edit #2: Well all the repair techniques I know of for these things (I've had to deal with 4 or 5 during my life), including an AC adapter (12V, centre-pin-negative (per docs I found)) don't work, so it's just "another dead SWC DX". I'll have to pick up an SD2SNES (thought about Super Everdrive but I figure this is one of those one-time purchases that should last me a long time, so I'm happy to shell out the extra cash). Sorry about all the delays -- just goes to show how long ago I used all this stuff. :-) I'll use the opportunity to also pick up a different capture device too, hopefully something that works with VirtualDub directly.

P.S. -- If anyone wants the SWC DX I'll be happy to send it to 'em, if they want to try to repair it.

My reply was to tokumaru, not to you.

*waves hands randomly* Details details... ;)

Well, thanks for trying anyway. Appreciated all the same.

I guess it doesn't have to be perfect, I just need a longer capture of the wave effect. A cell phone capture would probably be fine, so long as you convert it to something mplayer can open (I know Android stores videos in some stupid ass phone format by default.)

Have you tried the FFMpeg Plugins? VirtualDub becames capable of opening a crapload of different formats once you install these.

@byuu -- No problem. When my SD2SNES gets here I'll be able to get you something either way (regardless of which capture device I use). I'm blocked until then. I'm just glad my S-Video cable still works. :-)

@tokumaru -- No, because I've never understood ffmpeg and how exactly those filters fit into how DirectShow works. Rephrased: I have deep concerns over things that "tie in" to DirectShow via some system-wide installation vs. using something like MPC-HC (which is what I prefer to use to play video files) which includes its own ffmpeg stuff. But right now the major problems I have are with the fact that I no longer have a working copier (working on that, re: SD2SNES in the mail) and capture devices being dicks. :-) I'll figure something out either way, I just don't want to give byuu some crappy results where he can't get a clear frame-by-frame. I really prefer capturing in a raw or lossless compression format, especially for short clips (~3-4 minutes tops), followed by doing lossless compression using XviD or another codec that does a better job (MPEG often makes a mess of things), as long as it's compatible with software (ex. mplayer that byuu uses).

Hum... This looks suspiciously familiar, but I can't say for sure. I'll have to check on my computer that has the capture card, which I haven't turned on in months. Thanks for the link.


I have good news for you: this is not a system-wide installation, it's just some files you unpack to VirtualDub's plugins folder. Then every time you open VirtualDub it will find the plugins and load them automatically.

I was under the impression that VirtualDub already came installed with the ffmpeg plug-ins by default (unless that changed recently). It is true though that ffmpeg isn't used by default when encoding (you need to select the format explicitly, but that's trivial). Not sure how it goes around decoding.

New capture device came in today. Yay -- it works in VirtualDub! (once I figured out what to pick in some of the menus -- I may have to go back with the older device and try some of the same, because there were settings I didn't even know existed).

I had to set the device into "Game Mode" which removes lag of some sort (the device buffers 3-4 full seconds for whatever reason by default, but Game Mode turns that off). Capture results were interlaced (sigh), but I had VirtualDub do the deinterlacing and the results turned out pretty good. Problems I can detect:

• It occasionally drops frames (not in VirtualDub but the actual encoder), although it may be the 29.97fps vs. 30.00fps situation. Hard for me to tell. It's noticeable during panning parts (there is always a little bit of stutter, but then big jumps at times, and those concern me).
• Brightness is significantly off (too dark) compared to emulators/actual on-TV results -- I can adjust this post-processing if needed (I imagine we might need it to see subtle glitching during the MODE change).
• Audio frequency gradually becomes off -- not video/audio sync, but the actual frequency of playback sounds like it gradually gets faster/higher-pitched (especially noticeable in the first 15-20 seconds or so). This is not the first time I've seen VirtualDub do this (though there it started dropping audio and video frames with the frequency decreasing). This only happens during the actual recording and not when simply using VirtualDub to preview the input. That gives me a lot of ideas of things to adjust. (Edit: Ah yes, it's Capture / Timing / Sync audio to video by resampling the audio to a faster or slower rate option -- this explains it)
• If the deinterlacing isn't good, I have *lots* of deinterlacing options in VirtualDub to try.

I'm not too worried about the audio issue (for this thread, because it's not relevant), but I do worry about it long-term if I plan on using this to record video game play (which would be incredibly useful, to be honest, as I'd love to do some actual Famicom recordings). The only thing I'll change is really jacking up the XviD quality (like doubling it), or possibly using a different (lossless with compression) codec.

It's seriously been 15 years since I've played Super Metroid yet I was able to notice those issues immediately, especially the audio playback ramping up. Guess I have good eyes and ears. ;-)

Sorry about the video recordings being from two separate demos/self-plays -- it would have been better had I reset the console each time.

• VirtualDub-recorded clip from Super Metroid (demo/self-play) (16.7MBytes)
• Video: Xvid 720x480 29.97fps 2073kbps [V: mpeg4 advanced simple profile, yuv420p, 720x480, 2073 kb/s]
• Audio: MP3 48000Hz stereo 112kbps [A: mp3, 48000 Hz, stereo, 112 kb/s]
• I was sure to use CBR MP3, not VBR (VBR can sometimes cause audio-video desync over time)

Then I moved on to using the native software ("WinTV v7"), which has craploads of options (including device-level features, really low-level stuff, pretty neat). The most idiotic thing is that changing any of the options -- including things like "Video Recording Path", requires you to reboot! What the hell! So moronic. But I figured what the hell, right? Might as well see which one works best for us.

• WinTV V7-recorded clip from Super Metroid (demo/self-play) (62.7MBytes)
• Video: MPEG2 Video 720x480 (4:3) 29.97fps [V: mpeg2 main, yuv420p, 720x480]
• Audio: MPEG Audio 48000Hz stereo 128kbps [A: mp2, 48000 Hz, stereo, 128 kb/s]

I don't like the results of this. I really prefer the VirtualDub results. (I will admit the in-app preview looked good though). But at least the audio doesn't increase in frequency ;-)

These can both be played in MPC-HC, and probably mplayer.

Let me know when you have these so I can delete them from DropBox.

@byuu, is this sufficient quality, particularly the VirtualDub recording? There's lots I can adjust of course. I just wanna make sure you can see what you need.

Sure, that looks to be of sufficient quality to ascertain the offset-per-tile effect. Thanks!

Great! When my SD2SNES arrives I'll record stuff and put it up here. Thanks for reviewing stuff + putting up with my delays. (Edit: It's been shipped, so I imagine it'll be here within a week or two. The way Retrogate does their package tracking is bizarre as hell though -- through some third-party site in Ukraine despite them being in Germany. Very weird)

I figured out how to alleviate the audio frequency ramping problem too -- just had to check a couple boxes in VirtualDub (specifically Capture / Timing / Automatically disable resync when integrated audio/video capture is detected). Since the Happauge capture device is doing both audio and video capturing, they're actually always in sync. I figured this out by reading the manual a bit, but also by looking at Capture / Timing graph when doing a test video capture. Now things look great and with very few frame drops (76 for a 1:30 video. 90 seconds * 29.97 fps = 2697.3 frames, 76 / 2697.3 = 0.282 0.0282 frames dropped (0.0282 * 100 = 2.82%), totally acceptable).

I had a bunch else to say about audio stuff (like how apparently some models of SNES units output a high pitch noise (like mine -- I have the original SNES, not a SNES Jr.), but I realised it's not really relevant since we're focused on the video aspect.

Edit: Me doing math wrong (was done right in GNU bc, but I don't tend to copy-paste very much, I type things manually, forgot a zero. :-) Thanks Sik!)

I think you forgot a 0 there (0.0282, or 2.82%).

But yeah, so the problem was just bad settings in the end? Go figure. This is probably the most annoying part of video recording, there are just too many settings that can go wrong =P

While we're waiting...

Is there a preferred method of extending VBlank while the IRQ is otherwise occupied?

I was thinking of using a couple of HDMA channels; one to toggle the display and one to hijack the interrupt (which would probably have to be in RAM). This would allow the mode change interrupt code to be as lean as possible, which I imagine is very important for something that runs ~200 times per frame. But if there's a less hacky way to do the same thing, great.

You can't trigger NMI manually, can you? I gather it doesn't trigger on force blank...

There's no way I know of to trigger NMI through software -- it's tied to a pin on the CPU, connected to a particular device (PPU VBlank in this case, or some latch chip that connects to that (I'm talking out my ass here, I don't do EE)). The NMI itself is induced by the hardware it's tied to, e.g. the PPU.

You are correct that forced blank will not trigger NMI.

About my SD2SNES: still waiting. Estimated delivery time from Germany is 15-20 days, and for whatever reason (intentionally) the product goes through cities in Ukraine before going to the US. I can read some Cyrillic, but right now it looks like in Ukraine still on its way here. Last update was on 2014/08/09 and it was originally shipped on 08/05. So another week or so...

On the NES, if the NMI hasn't been acknowledged (BIT $2002), disabling and reenabling NMI (LDA #$00 STA $2000 LDA #$80 STA $2000) before vertical blanking has finished will cause an immediate falling edge on /NMI. Does the same thing work on the Super NES?

I don't know what "falling edge" means. This is again more hardware talk and doesn't really shed any light on what actually happens at a software level (read: does the CPU notice hardware NMI and thus run code at NMI vector or not?). What is it going to take for folks to actually comprehend this point? :P

Likewise, descriptions like the below ("forced high", "output low", "output high", etc.) are a little more helpful but not by much. The below seems to imply that "NMI output low" means "NMI is firing / code at NMI vector will be executed". Whether or not that's "falling edge" is unknown to me.

A forced blank is accomplished by setting bit 7 of $2100 to 1. It essentially "turns the screen off" (meaning you get a black screen, or black for whatever duration you set it + unset it), but the electron gun and video synchronisation stuff keep working during this time.

Some of the below is irrelevant to the discussion topic. The important stuff is at the top.



There is also this, but it says nothing about NMI:



And then this:

The 6502 treats NMI differently from IRQ, and I assume that the 65816 behaves the same way.

• /IRQ is level sensitive. If /IRQ is held low, the CPU will repeatedly call the IRQ vector every time CLI (or PHP with bit 2 clear) is executed.
• /NMI is edge sensitive. A transition from high to low causes a flip-flop to get set in the CPU, and the CPU will call the NMI vector only once and not call it again until the signal goes high and low again.

So let me state it from a purely software perspective: On the NES, changing the PPU's NMI enable bit from off to on during vblank causes an immediate call to the NMI vector if the NMI for that frame hasn't already been acknowledged.

> You can't trigger NMI manually, can you?

Sure you can.

Push P and your return address onto the stack, and then JML to your NMI vector routine =)

> I can read some Cyrillic, but right now it looks like in Ukraine still on its way here.

Hopefully it's not being transported on a Malaysia Airlines cargo plane :/

AFAIK, Krikzz, the guy responsible for the Everdrives, lives in Ukraine. For some reason the guy who created the SD2SNES has Krikzz manufacture it. Anyway, I've found retrogate's shipping methods to be pretty reliable, fast and cheap, more so than from any other country I've bought products from (and I never had to pay import taxes for any of my Everdrives or SD2SNES), and the tracking page has an English language option.

I've found it to be all of those things but fast. But still, the items were in stock and I did receive them.

Well, yeah, it sounds silly when you put it like that...

I guess what I was hoping for with that question was something I could poke with HDMA, since as far as I'm aware it's the only thing left that auto-triggers on a timer (the IRQ is busy with the mode change and needs to be lean, and the NMI fires too late). Like tepples' method, but more flexible. It would be even better if there were a way to freely move the NMI trigger point itself...

I suppose I'm not doing too badly as it stands, though. It seems to me that I could even get away with just using one HDMA channel instead of two, by simply writing a branch into the IRQ code before the last scanline and letting the resulting pseudo-NMI handle the screen blanking. If the IRQ code ends up having to be in ROM for some reason, I could just have it check a memory location, and have the HDMA write to that location - but that's, what, at least two extra instructions every scanline? Still faster than checking OPVCT...

Since I have almost no experience at SNES coding, I was trying to find out if there's a standard procedure or something that people follow in this situation. If there isn't, that's okay; I'm sure there's a way to make it work.

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.

How narrow do you think I can get the garbage area? Or should we wait for better video?

I don't know if running the game logic in VBlank is a good idea in this case. Even with a 144x192 playfield, after accounting for all the stuff that needs to happen via DMA, plus related maneuvering, I figure I'd be lucky to have 20 scanlines of actual compute time left before the mode change loop had to restart. Anything that didn't fit would have to be offloaded onto the GSU, which is already pretty busy.

On the other hand, if I understand correctly, running non-timed game code during active display could produce a variance in the position of the mode switch of up to W*(N-1) pixels, where W is the number of pixels per cycle and N is the number of cycles taken by the longest instruction that could conceivably be executing when the interrupt fires. If this is the case, it seems to me that minimizing the width of the sprite mask would require this section of the code to be written exclusively with instructions of four cycles or less, which could be very restrictive... or I could use FastROM in the CPU-only area, which should allow at least five cycles per instruction, maybe six... unless the interrupt timing itself has jitter, as implied by the use of "~" in the timing docs, which would have to be added to the variance...

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

...or I could give up and run most of the game on the GSU, and hope it can handle it...


I'm not sure I get this. To me, using that much mission-critical cycle-timed code in the middle of an active game environment seems more extreme than changing a register in an IRQ, especially if the timed loop eats most of the available CPU power without doing any actual computing...

I mean, the IRQ works; it's just a question of how much extra glitch masking it forces me to do. Am I missing something?

Here's some video;

http://www.morganleahrecords.com/augustus/blackheart/tmp/mtest.mp4
http://www.morganleahrecords.com/augustus/blackheart/tmp/mtest-reverse.mp4
http://www.morganleahrecords.com/augustus/blackheart/tmp/mtest-scroll.mp4

...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...

Also, something funny is going on with the timing; it doesn't look quite the same as in higan v094. It looks like there's more jitter on the real system, and the garbage starts sooner.

But it looks like the scroll changes work more or less as expected, except that they seem to be widening the garbage area... Maybe zeroing the scroll, rather than bumping it positive, would have a different effect...

It strikes me that a lot of cases may have to be tested for confidence in describing the behaviour. Then again, I haven't spent a decade writing an obsessively accurate emulator for this system, so maybe it's more clear what's going on to someone who has...

...

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

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).

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

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.

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'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...


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...

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.

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

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.

> 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.

Forgot to comment on this (whoops)


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

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)

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.


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?


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...


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.


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...


...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?

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.

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?

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.


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


That depends on what you consider "personal data".

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/augustus/blackheart/tmp/horiz_nospr.mp4

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

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:

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.


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

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/augustus/blackheart/rom/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

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....


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'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:




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...


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...

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.

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?

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.

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...?


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.

> ...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)

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.

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).

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...


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...


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?

> 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.

"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."


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.


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?

> It works on a Super NES, which is what matters.

You would think that, but experience shows me otherwise.

We found a bug that caused Der Langrisser to freeze in ZSNES, especially when you hit the fast forward key. We reported it to them in 1998, pagefault said he'd fix it soon, and it's still broken in 2015. It also apparently happens periodically in Snes9X v1.43 and earlier.

When we released the game, we warned people about the emulator bugs, and recommended real hardware or bsnes.

On the first day of release, we had two people accuse us of making the fan translation "bsnes-only", even though the original Japanese game had the same issue.

TL;DR: people are really, really stupid.

> This is a wake-up call to nocash and the 9x team to get their behinds in gear.

I think the 9x team is pretty much dead. They're all still around, but we're over four years out from the last release now, with no signs of project life.

I do know of one other emulator that has pixel-based PPU timing, but it's not public. Also have not heard anything on that in over a year, so it may be dormant/dead, not sure.

> Perhaps that's why it's 5 slow cycles, not 4: to let the previous cycle finish.

It certainly could be.

(H)DMA has a really bizarre and complex clock sync system for its DMAs (it first syncs the CPU clock tick count to a multiple of 8, then does the DMA, then syncs it back to a multiple of the last CPU cycle's clock count, then resumes.) But that causes a variable length of extra clock cycles, which DRAM refresh doesn't exhibit, so that's not what DRAM refresh is doing.

> 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?

It doesn't for me.

Indeed. Thank you!


Heh. Yeah, probably. Assuming I actually pull this off in the first place...

I figure it's a SNES game, not a ZSNES game, so if ZSNES can't handle it that's not my problem. I could probably make it ZSNES-compatible, or at least Snes9X-compatible (ZSNES can fail awfully hard on even mildly creative uses of the hardware), but I'd have to sacrifice a lot of visual authenticity and I don't want to do that.

I'm not especially bothered about broad compatibility - the original game exists, after all. This project is more about pushing the limits of the Super NES. I am glad you've somewhat resumed bsnes development, though; there are no strong indications of the SD2SNES gaining GSU support any time soon, and for a while there I was faced with the distinct possibility that I was developing a game that would only fully work on a custom Super FX devcart. I mean, I'll have to build one eventually anyway, but still...


Hm.


Hmm.

Well, it's not like I actually need to know this at the moment. If I get really curious there's always the bsnes source code...

Does the 1CHIP behave like the Jr.? In #nesdev, fys and ikari_01 said it did.

I can't say for sure.

I also didn't do really extensive testing. I just know that the SNES deck I was using next to the SNES Jr rendered raster effects quite differently. Was as if the INIDISP brightness reg changes had much less effect and the colors were a lot brighter on the SNES Jr. And some other differences like that.

But I don't recall which of my SNES decks I was using at the same to go and check on it now.

Testing this would have to be done by someone else, or to wait a really long time until I'm back up and running again.