High color bitmap on the SNES

[Near]

> The first few colours of the line are preloaded during HBlank, so as to buffer enough colours to get through the DRAM refresh.

Ooooooooooooooh you sneaky, sneaky bastard! :P

That's brilliant, seriously. Double congratulations, you not only broke higan, you've completely stumped and outsmarted me too :D

> Being lazy, I'm still using bsnes v072 a fair bit (it can open an SFC file on double-click, and it has blargg's NTSC filter)

blargg's filter's not coming back, but I'm sure I'll have something in place for direct-launch SFC eventually. Still working on icarus.

As for your test ROM, it might not require very significant changes to pass this one test. But I think as we move around and toggle other effects, it'll break again very easily. It's definitely a fun test and would be nice to run correctly, but I'm thinking that it'd probably be a better use of time to start working on timing out as much as we can through clever OAM/CGRAM accesses. I don't think we're ever going to find someone amazing at both writing SNES test ROMs and using a logic analyzer to trace out what the PPU chips are fetching and when, so I really don't know how we're going to get perfected VRAM access timings (or if it's even important, given it's untestable through emulation.)

> or impressing people with raw colour counts

It's easy to hit all 32768 colors on one screen already. And in fact, it's possible to go beyond 15-bit color, as the INIDISP luminance is an analog effect (which actually makes it really hard to say just how many colors the SNES can really produce. No telling how many colors are matches to other colors at different luminance levels.)

The best usage of this trick is probably to annoy emulator authors :D

[tepples]

The best usage of this trick is probably to annoy emulator authors

Such as to make screens where a picture of a character appears on the real thing but a skull and crossbones appear on emulators.

[Khaz]

Such as to make screens where a picture of a character appears on the real thing but a skull and crossbones appear on emulators.

Are you guys seriously talking about inventing new DRM for a 26 year old console?

... Can I put it in my game? >.>

[tokumaru]

Are you guys seriously talking about inventing new DRM for a 26 year old console?

Either that or giving an incentive for people to make their emulators more accurate.

[93143]

Okay, apparently the palette ordering in pcx2snes has nothing to do with the order in which the colours appear in the image. It seems to be in ascending numerical order or something...

Anyway, I seem to have fixed it. The input data format is now sane: 15-bit BGR values left-to-right, row by row top-to-bottom, 64x224. 28 KB exactly. Unless I'm much mistaken, 64x239 should work without any changes other than switching the display height and extending the input data.

Please excuse the name change; I was using a different name entirely in testing so I didn't realize until just now that my Super Everdrive won't load a file with exactly 8 letters in the name... and anyway it's more correct now...

dmacolour.7z

(108 KiB) Downloaded 159 times

That's brilliant, seriously. Double congratulations, you not only broke higan, you've completely stumped and outsmarted me too

Careful, my head's gonna pop...

A 2bpp layer blended onto this layer to enhance luminance detail would provide the equivalent of 4:1:1 video, with brightness coming mostly from the 2bpp layer and color coming from the 15bpp layer.

I wonder if that might actually produce a half-decent-looking video mode. To be able to use colour math, I'd have to use the timed-code version with a shifting offset pattern, which I haven't written yet so I'm not sure it works... and even at 2bpp, there's not enough bandwidth for the whole screen, so either each frame would have to be optimized to fit (potentially very lossy) or else the video would have to run at a lower frame rate or screen size (which kinda defeats the purpose of the technique)... Even 1-bit luminance would eat 7 KB per frame, or 8 with multiple subpalettes (which seems like a good idea) or a bit more if you want to overwrite the actual subpalettes each frame... but 208 lines at 30fps should work without compressing the 2bpp layer, and 216 lines looks like it should work at 60fps 50fps on PAL...

I don't see why the RGB layer couldn't supply peak brightness information, with the subpaletted 2bpp layer just providing deltas via subtraction. Kinda like BRR...

[tokumaru]

60fps on PAL...

Huh?

You probably mean that 1 hardware frame = 1 video frame, which would be 50fps on PAL, right? Personally, I think that video at 30/25fps using the techniques you're describing would look amazing on the SNES, no need to shoot for 60/50fps.

[Near]

With the improperly spelled test ROM, I get this pattern:

(Hcounter in decimal) (CGRAM addr[actual write location])=(value written)
Where actual write location = override of CGRAM write address based on palette fetch from PPU itself

Code: Select all

0024 0003[0002]=21
0032 0004[0003]=04
0040 0005[0004]=21
0048 0006[0005]=04
0056 0007[0006]=22
0064 0008[0007]=04
0072 0009[0008]=42
0080 000a[0009]=04
[[Hstart]]
0088 000b[0002]=42 <- will write 4204 (takes the last write before Hstart for the low byte latch)
0096 000c[0004]=08
0104 000d[0004]=21
0112 000e[0006]=04
0120 000f[0006]=21
0128 0010[0008]=04
0136 0011[0008]=21
0144 0012[000a]=08
0152 0013[000a]=41

0160 0014[0002]=08  0168 0015[0002]=42
0176 0016[0004]=08  0184 0017[0004]=65
0192 0018[0006]=0c  0200 0019[0006]=63
0208 001a[0008]=0c  0216 001b[0008]=63
0224 001c[000a]=10  0232 001d[000a]=62

0240 001e[0002]=0c  0248 001f[0002]=a4
0256 0020[0004]=18  0264 0021[0004]=83
0272 0022[0006]=10  0280 0023[0006]=29
0288 0024[0008]=19  0296 0025[0008]=6b
0304 0026[000a]=25  0312 0027[000a]=ad

0320 0028[0002]=29  0328 0029[0002]=84
0336 002a[0004]=0c  0344 002b[0004]=28
0352 002c[0006]=19  0360 002d[0006]=6d
0368 002e[0008]=5f  0376 002f[0008]=ef
0384 0030[000a]=73  0392 0031[000a]=08

0400 0032[0002]=57  0408 0033[0002]=62
0416 0034[0004]=21  0424 0035[0004]=44
0432 0036[0006]=36  0440 0037[0006]=64
0448 0038[0008]=3e  0456 0039[0008]=48
0464 003a[000a]=29  0472 003b[000a]=cf

0480 003c[0002]=41  0488 003d[0002]=ae
0496 003e[0004]=39  0504 003f[0004]=4b
0512 0040[0006]=29  0520 0041[0006]=af
0528 0042[0006]=35  0536 0043[0006]=54
[[DRAM refresh]] <- skips 0008,0009 [color# 4]
0584 0044[000a]=4e  0592 0045[000a]=50

0600 0046[0002]=63  0608 0047[0002]=f1
0616 0048[0004]=7b  0624 0049[0004]=ab
0632 004a[0006]=52  0640 004b[0006]=26
0648 004c[0008]=25  0656 004d[0008]=27
0664 004e[000a]=3a  0672 004f[000a]=27

0680 0050[0002]=3a  0688 0051[0002]=4c
0696 0052[0004]=46  0704 0053[0004]=d3
0712 0054[0006]=5e  0720 0055[0006]=14
0728 0056[0008]=67  0736 0057[0008]=57
0744 0058[000a]=6f  0752 0059[000a]=98

0760 005a[0002]=7b  0768 005b[0002]=55
0776 005c[0004]=77  0784 005d[0004]=d0
0792 005e[0006]=6a  0800 005f[0006]=cf
0808 0060[0008]=66  0816 0061[0008]=94
0824 0062[000a]=5a  0832 0063[000a]=56

0840 0064[0002]=18  0848 0065[0002]=56
0856 0066[0004]=14  0864 0067[0004]=54
0872 0068[0006]=14  0880 0069[0006]=70
0888 006a[0008]=18  0896 006b[0008]=54
0904 006c[000a]=14  0912 006d[000a]=79

0920 006e[0002]=4e  0928 006f[0002]=d0
0936 0070[0004]=3d  0944 0071[0004]=77
0952 0072[0006]=42  0960 0073[0006]=12
0968 0074[0008]=42  0976 0075[0008]=8c
0984 0076[000a]=35  0992 0077[000a]=55

1000 0078[0002]=52
1008 0079[0002]=54
1016 007a[0004]=4a
1024 007b[0004]=6f
1032 007c[0006]=3a
1040 007d[0006]=ca
1048 007e[0008]=29
1056 007f[0008]=6c
... kind of goes haywire here
1064 0080[0002]=46
1072 0081[0002]=ab
1080 0082[0002]=2d
[[Hend]]

The data doesn't look good at all.

Sometimes it starts at Hcounter=20, sometimes at Hcounter=24.

But it's starting way before the screen is supposed to be rendering.

Screen rendering is, as far as I know, around Hclock 88 - 1095. I based that off actual writes to CGRAM during active display and seeing when the write address was overridden. So that's where the timings in the MMIO write come from.

My main PPU render loop sleeps 28 clocks, then processes seven 'negative pixels' (to handle when you have Hscroll&7!=0 on tiledata) which is another 28 clocks. That totals 56 clocks.

The minimum value that runs your test correctly is 54. And 54+28=82. The highest value that works is 60, which of course 60+28=88.

This gives us much nicer data:

Code: Select all

0024 0003[0002]=21  0032 0004[0003]=04
0040 0005[0004]=21  0048 0006[0005]=04
0056 0007[0006]=22  0064 0008[0007]=04
0072 0009[0008]=42  0080 000a[0009]=04
[[Hbegin]]
0088 000b[000a]=42  0096 000c[000a]=08

0104 000d[0002]=21  0112 000e[0002]=04
0120 000f[0004]=21  0128 0010[0004]=04
0136 0011[0006]=21  0144 0012[0006]=08
0152 0013[0008]=41  0160 0014[0008]=08
0168 0015[000a]=42  0176 0016[000a]=08

0184 0017[0002]=65  0192 0018[0002]=0c
0200 0019[0004]=63  0208 001a[0004]=0c
0216 001b[0006]=63  0224 001c[0006]=10
0232 001d[0008]=62  0240 001e[0008]=0c
0248 001f[000a]=a4  0256 0020[000a]=18

0264 0021[0002]=83  0272 0022[0002]=10
0280 0023[0004]=29  0288 0024[0004]=19
0296 0025[0006]=6b  0304 0026[0006]=25
0312 0027[0008]=ad  0320 0028[0008]=29
0328 0029[000a]=84  0336 002a[000a]=0c

0344 002b[0002]=28  0352 002c[0002]=19
0360 002d[0004]=6d  0368 002e[0004]=5f
0376 002f[0006]=ef  0384 0030[0006]=73
0392 0031[0008]=08  0400 0032[0008]=57
0408 0033[000a]=62  0416 0034[000a]=21

0424 0035[0002]=44  0432 0036[0002]=36
0440 0037[0004]=64  0448 0038[0004]=3e
0456 0039[0006]=48  0464 003a[0006]=29
0472 003b[0008]=cf  0480 003c[0008]=41
0488 003d[000a]=ae  0496 003e[000a]=39

0504 003f[0002]=4b  0512 0040[0002]=29
0520 0041[0004]=af  0528 0042[0004]=35
0536 0043[0006]=54  0584 0044[0006]=4e  <- DRAM refresh in the middle
0592 0045[0008]=50  0600 0046[0008]=63
0608 0047[000a]=f1  0616 0048[000a]=7b

0624 0049[0002]=ab  0632 004a[0002]=52
0640 004b[0004]=26  0648 004c[0004]=25
0656 004d[0006]=27  0664 004e[0006]=3a
0672 004f[0008]=27  0680 0050[0008]=3a
0688 0051[000a]=4c  0696 0052[000a]=46

0704 0053[0002]=d3  0712 0054[0002]=5e
0720 0055[0004]=14  0728 0056[0004]=67
0736 0057[0006]=57  0744 0058[0006]=6f
0752 0059[0008]=98  0760 005a[0008]=7b
0768 005b[000a]=55  0776 005c[000a]=77

0784 005d[0002]=d0  0792 005e[0002]=6a
0800 005f[0004]=cf  0808 0060[0004]=66
0816 0061[0006]=94  0824 0062[0006]=5a
0832 0063[0008]=56  0840 0064[0008]=18
0848 0065[000a]=56  0856 0066[000a]=14

0864 0067[0002]=54  0872 0068[0002]=14
0880 0069[0004]=70  0888 006a[0004]=18
0896 006b[0006]=54  0904 006c[0006]=14
0912 006d[0008]=79  0920 006e[0008]=4e
0928 006f[000a]=d0  0936 0070[000a]=3d

0944 0071[0002]=77  0952 0072[0002]=42
0960 0073[0004]=12  0968 0074[0004]=42
0976 0075[0006]=8c  0984 0076[0006]=35
0992 0077[0008]=55  1000 0078[0008]=52
1008 0079[000a]=54  1016 007a[000a]=4a

1024 007b[0002]=6f  1032 007c[0002]=3a
1040 007d[0004]=ca  1048 007e[0004]=29
1056 007f[0006]=6c  1064 0080[0006]=46
1072 0081[0008]=ab  1080 0082[0008]=2d
[[Hend]]

But any value above 44 will break Air Strike Patrol's "Good Luck" rotating text (the very last tile will start to flicker.) ASP of course uses BG3HOFS writes. So most likely, the HOFS caching is happening at the wrong time. And I'm pretty sure even lower numbers were needed to square away some glitchiness in other games (probably Super Mario World's water level.)

So basically, we're stuck in a whack-a-mole situation here. We're not ever going to perfectly emulate the PPU by futzing numbers until tests pass. We have to be able to time this stuff out properly. And I don't believe it's possible to do it through software and screenshots.

But, for the time being, enjoy this screenshot:

[Sik]

Such as to make screens where a picture of a character appears on the real thing but a skull and crossbones appear on emulators.

OK probably Fusion wasn't the best for this (due to the display off gap being visible with it) but oh well.

Are you guys seriously talking about inventing new DRM for a 26 year old console?

Custom hardware on the cartridge would be much easier for that. Especially with the social pressure for emulator authors to not add emulation for it (because somehow it's OK to copy licensed games but not homebrew).

[Near]

Custom hardware on the cartridge would be much easier for that. Especially with the social pressure for emulator authors to not add emulation for it (because somehow it's OK to copy licensed games but not homebrew).

We've always had a huge double standard there. I've pointed out how hypocritical it was in the past.

Reproductions of game carts are fine, but of fan translations / ROM hacks are a sin.
Distributing commercially copyrighted ROMs is fine, but distributing pre-patched ROM hacks is very wrong.
Emulating commercial games and Chinese bootlegs is fine, but emulating Watermelon stuff is sacrilege.
We have to respect copyright unless it's our scene violating it, then it's okay.

Luckily, my own stance is not to emulate anything but commercial hardware (and my own stuff, heh), so I don't have to be faced with the dilemma of Project-N coprocessor emulation (assuming it ever comes out :P) I mean, I still wouldn't do it anyway out of personal respect to d4s, but yeah. There's an ethical quandary about doling out special favors like that. Choosing not to emulate anything unofficial is a wonderful way to avoid it entirely.

If history's any indication though, they can probably expect someone else to release an unofficial SNES emulator build that supports it; like they did for Pier Solar and MESS/HazeMD. Maybe they'll anticipate that and make the chip use some really nasty tricks like crypto.

[tepples]

We've always had a huge double standard there. I've pointed out how hypocritical it was in the past.

Reproductions of game carts are fine, but of fan translations / ROM hacks are a sin.
Distributing commercially copyrighted ROMs is fine, but distributing pre-patched ROM hacks is very wrong.

Is this likewise hypocritical? For Sale: Star Fox 2 ROM and CIC chips

[Near]

Whether you're okay with that is based on several factors:
* whether it's the translated ROM or not (I don't personally care)
* whether you're for or against people destroying retail carts (I am very much against it)
* whether you're for or against the original copyright owner's rights to the game (I don't care at all since they won't sell it)

These factors will vary from person to person. But in my own case, I'm against it because it's destroying real SuperFX carts.

The word hypocritical would be whether you engage in any of the above, but are against this guy's work. Or whether he's against something despite what he's selling.

[tepples]

* whether you're for or against the original copyright owner's rights to the game (I don't care at all since they won't sell it)

Whether the game's copyright owner can get nesdev.com shut down.

[getafixx]

Whether the game's copyright owner can get nesdev.com shut down.

Might as well throw every other fan site in there too, then... It's all small beans IMO.

[tomaitheous]

Such as to make screens where a picture of a character appears on the real thing but a skull and crossbones appear on emulators.

OK probably Fusion wasn't the best for this (due to the display off gap being visible with it) but oh well.

How many colors are you updating per line in that part of the demo?

[Sik]

15 colors per line. If I recall correctly kabuto told me he could get 23 in before getting serious artifacts, so there's some time left for sprite processing (hence the spinning text - the "YOUR EMULATOR SUXX" message appears if too many sprites get rendered, as only about 30 can be processed with the remaining time).

Distributing commercially copyrighted ROMs is fine, but distributing pre-patched ROM hacks is very wrong.

Reminds me of a variant: somehow standalone patches are OK, despite requiring the copyrighted ROM to work anyway. Even worse, the patches are made from a modified ROM, meaning that even the standalone patches are derivative works (and hence illegal). Ugh. And those patches usually include stuff that would be infringement anyway (e.g. artwork from existing characters).

But maybe this is just me being grumpy about having to find an IPS patcher that doesn't crash every time you attempt to use it.