BGMODE or parameter changes during scanline

[tepples]

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

[93143]

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

[psycopathicteen]

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

[Bregalad]

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.

[93143]

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?

[Sik]

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.

[Near]

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.

[Sik]

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)

[tepples]

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.

[Near]

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)

That is incorrect.

[psycopathicteen]

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

[93143]

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.

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.

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.

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.

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

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

[93143]

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.

modeswitch_brightness.png (4.44 KiB) Viewed 3478 times

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:

modeswitch_higan094.png (4.7 KiB) Viewed 3478 times

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

[Augustus Blackheart]

Hopefully this is just an artifact of how the dot-based renderer was coded, and a real SNES will do a better job.

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/august ... c/atx2.zip
http://www.morganleahrecords.com/august ... kit.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.)

[93143]

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.