mudanhonnyaku on the NESdev Discord server recently brought up an
interesting Twitter conversation with someone who appears to have been a Famicom developer in the 80's. Based on the details in the thread, I believe it to be genuine. There are a couple interesting things mentioned, including information about this peculiar PPU address write pattern. Via DeepL:
Pandora wrote:As mentioned above, the NES had a collection of notes for developers to make the game work properly even on some difficult-to-operate consoles. Many of them are of the "what the heck is this spell" kind of content.
For example, when you rewrite the color palette, you should first set $0000 and then $3F00. Or else, you should always write 16 bytes at a time in a row. By doing that, it will work fine on the early NES.
What happens if you don't, for example, Xevious. On some consoles, the color of some characters starts to turn completely white while playing. The above instructions are probably a countermeasure to this symptom.
Indeed, there are two revisions of Xevious, with the first writing to just $3F15 to update a color and the second instead writing $3F10-3F1F. I attempted to reproduce the described issue on an RP2C02A PPU using Xevious rev 0 on an Everdrive N8 Pro, but had no luck despite many resets and leaving the console on for some time. I also used N-K's
palette glitch test ROM to ensure I was testing on an alignment that is known to have palette glitches, but still had no luck.
So, it's not clear to me at all what hardware is required to trigger this glitch, but we at least now know the likely purpose of these writes. It sounds to me like palette corruption occurs under some circumstance based on the value of v, much like we see with the palette bug found by N-K and Vectrex28. But, while that bug appears to occur on all PPU revisions, this one is apparently limited to some specific revision or hardware configuration. Setting v to $3F00 and then $0000 (or having a value of v pointing into palette RAM where the low nybble is 0) is presumably a safe sequence that will bypass any negative effects of the bug. I had guessed that the glitch may occur only on rev A or earlier perhaps as a result of writes to $2001 in vblank, because writes to $2001 during rendering unconditionally disable rendering briefly before the written value takes effect. My guess was that it still had some similar effect even during vblank and was triggering the known palette glitch. However, since I can't even reproduce this on A, I haven't found anything to support this guess.
One interesting note is that rendering can end with v pointing into palette RAM (as seen in the post-render NTSC border in Metal Storm), which could presumably be a trigger for this bug. If we can find affected hardware to justify doing this in modern software, workarounds may require writing address $3F00 to $2006 early in every NMI for any game that can encounter this condition.
I have included a DeepL translation below of the whole thread. Also of interest is a claim that the DMC IRQ does not work on some hardware revision. This is perplexing to me, as it seems to work fine in my testing on the letterless RP2A03. This perhaps warrants its own thread.
Code: Select all
Jemini. @jeminilog
The creator of Monster Panic for PC-8001 (who knew about that?), programmer of Lunaball for FC, ZANAC, Gunhead for PCE, Super Arrester, Power Strike 2 for MS, etc... I've only seen the old ones, but not the new one... What about this one? I dug up this icon from my HDD from my compilation days, but who drew it?
Pandora @kopandacco
My hobby is tinkering with PC junk. I also RT pornographic tweets, so please be careful if you follow me. I used to draw pictures, but I'm not very good at it. So this cute icon is made by Nooooooooooootos (twitter.com/noooooooooootos). Thanks!
Pandora @kopandacco
It's been a while since I've talked about game consoles from the past. It came up the other day when we were talking. I mean sorry if I wrote about it before.
2014-04-16 17:45:21
Pandora @kopandacco
The NES was a vector that if you touched it in a way other than the basic hardware operation method and could do something interesting with it, it would guarantee the same operation on subsequent versions of the machine, without saying as little as possible that such usage was not guaranteed.
2014-04-16 17:45:28
Pandora @kopandacco
Not that Nintendo is a supreme company or anything, but this policy was very fruitful. The original hardware specs didn't allow for vertical two-part scrolling (setting different vertical scrolling at the top and bottom of the screen), but by the end of the game, it was common practice.
2014-04-16 17:45:34
Pandora @kopandacco
To explain lightly, the NES has a behavior that is not in the specs, that when you set the address to read/write to VRAM, for some reason the screen scroll value (display offset value) is affected by it and changes. This behavior is more like a bug.
2014-04-16 17:45:42
Pandora @kopandacco
However, the register for vertical scrolling is invalid even if you touch it during the display period (why they made the spec that way is a mystery), but the scrolling change in the address setting is valid during the display period. So use that.
2014-04-16 17:45:50
Pandora @kopandacco
Unlike the original scroll setting, there are some limitations, such as it can only be set to a half position, or only in 8-dot increments. So some software just uses it to cut the window at the bottom of the screen.
2014-04-16 17:46:04
Pandora @kopandacco
Like Garforce, Fantasy Gene, and Gardic Gaiden. Also, Devil World is the one I use for scrolling. That one only moves vertically in 8 dot units. I think the original Zelda uses this too.
2014-04-16 17:46:15
Pandora @kopandacco
However, the NES's ability to "specify scroll values by addressing" has another property: if the screen is being displayed, the raster after the point at which the address is written will be the content of the display corresponding to that address.
2014-04-16 17:46:25
Pandora @kopandacco
In other words, even if the same address is written, the vertical scroll position effectively changes depending on the raster in which it was written. So if we control the position where the address is set itself, we can apparently change the scroll from the middle of the screen completely. Godzilla and this.
2014-04-16 17:46:33
Pandora @kopandacco
But even the NES, with all its interesting features, has holes, or rather many holes. One of them is that there is no function to interrupt at any position on the screen. There is no scanning line interrupt or timer interrupt. It's hard to cut a window without this.
2014-04-16 17:46:43
Pandora @kopandacco
There is no way to know the scanning lines themselves, so perhaps, but what was used was BG-OBJ collision detection. This is a specific status change when the OBJ (sprite in other companies) and the BG (background) overlap. It is determined on a per scan line basis.
2014-04-16 17:46:52
Pandora @kopandacco
Put the OBJ at the position where you want to cut the window and the CPU will monitor the status closely. If a collision occurs, the status will change and all you have to do is set the aforementioned scrolling settings
2014-04-16 17:47:01
Pandora @kopandacco
But "only" the CPU can't do much else while you have it do this. If you let it do it, it can't react, so the window will be out of alignment. If it's a game with plenty of processing time, you can just let it monitor when the main processing is done.
2014-04-16 17:47:10
Pandora @kopandacco
Fantasy Zone shifts the window position when the processing is down, so maybe that's what they're doing. Note that MMC3 and disk systems have timer interrupts, so the window can be cut off naturally without doing too much weirdness.
2014-04-16 17:47:20
Pandora @kopandacco
Well Gardic Gaiden, I didn't want to use the CPU too much just for scanning line monitoring, so I came up with a plan: let's use the DMA exit interrupt.
2014-04-16 17:47:34
Pandora @kopandacco
The NES is loaded with a sampling sound source. I didn't want to use it at all at the time because of its many limitations, but this sound source was capable of generating an interrupt at the end of data playback.
2014-04-16 17:47:45
Pandora @kopandacco
Then if you make short silent data and have it play at a lower rate, you should also be able to generate an interrupt near the point in the screen where you want to cut the window. Then you can have it do the scanning line monitoring as normal. This should cut down on wasted time!
2014-04-16 17:47:53
Pandora @kopandacco
It actually looked like it worked... but after release, some NES (just the Twin NES?) I'm not sure why, but I'm getting severe processing crashes on some NESs (Twin NES only?). I'm not sure why, but the DMA exit interrupt doesn't happen on some units, sir.
2014-04-16 17:48:01
Pandora @kopandacco
It seems that no one had thought to use the DMA exit interrupt before then and it was not included in the operation check at the time of shipment. In other words, it is unknown how many units in the world do not generate DMA exit interrupts.
2014-04-16 17:48:10
Pandora @kopandacco
The Gardic Gaijin has a feature that dynamically follows how long it waits after an interrupt, and if no DMA interrupt is generated, the worst setting is automatically chosen. In other words, CPU power is being wasted by waiting for a long time. Ahhhh.
2014-04-16 17:48:19
Pandora @kopandacco
I'd rather have a game that doesn't work than a game that still doesn't work. After that, they added a sentence "Do not use DMA exit interrupt (summary)" to the NES developer's note. Yay.
2014-04-16 17:48:26
Pandora @kopandacco
As mentioned above, the NES had a collection of notes for developers to make the game work properly even on some difficult-to-operate consoles. Many of them are of the "what the heck is this spell" kind of content.
2014-04-16 17:48:35
Pandora @kopandacco
For example, when you rewrite the color palette, you should first set $0000 and then $3F00. Or else, you should always write 16 bytes at a time in a row. By doing that, it will work fine on the early NES.
2014-04-16 17:48:46
Pandora @kopandacco
What happens if you don't, for example, Xevious. On some consoles, the color of some characters starts to turn completely white while playing. The above instructions are probably a countermeasure to this symptom.
2014-04-16 17:48:53
Pandora @kopandacco
And one of them said "If you are using DMA, there is a possibility of noise in the key input". Specifically, noise in the controller's readings, which can lead to unwanted operations.
2014-04-16 17:49:00
Pandora @kopandacco
The countermeasure is to read it twice and consider it normal if the readings are the same. It's really just instantaneous noise.
2014-04-16 17:49:12
Pandora @kopandacco
But first, the premise of the NES is that the palette is specified in units of 2*2 characters. And since the palette designation is 2 bits, 4 2*2 characters are controlled by 1 byte. (That would be 4*4 characters.)
2014-04-16 17:49:20
Pandora @kopandacco
But the game doesn't only rewrite 4*4 characters each. Often you want to rewrite at least in 2*2, the lowest unit of color designation. Well, that was back then.
2014-04-16 17:49:33
Pandora @kopandacco
Also, the NES internal screen isn't 32*32 or 32*28, it's the rare 32*30. if you're using 4 each vertically, you'll have 2 extra. Vertical scrolling games, even if they are mapped with 4*4, have to be controlled with 2*2 internally or they will break down.
2014-04-16 17:49:43
Pandora @kopandacco
Well, if you want to rewrite only 2*2, you can't involve up to 12 other characters. That's why ZANAC made a copy of the palette specification in memory, read the values from it, partially rewrote them, and wrote them back to the copy while writing them to VRAM.
2014-04-16 17:49:50
Pandora @kopandacco
In Gardic Gaiden, I took it one step further and read the necessary information from VRAM, did a partial rewrite and wrote it back. This way you don't need to bother copying it into memory.
2014-04-16 17:49:57
Pandora @kopandacco
However, for some reason, the actual device is sometimes garbled. It doesn't happen on my development equipment (DICE-6502). I've come to the conclusion that if you use DMA, the VRAM read values are also sometimes garbled, because the DICE-6502 is not a genuine development device, so it doesn't have DMA functionality.
2014-04-16 17:50:05
Pandora @kopandacco
I added the ability to read and confirm twice and it no longer boggles. I've reported this to Nintendo, but I don't think they added a note to the end saying "if you use DMA, VRAM reads will also be corrupted."...no one else wanted to read VRAM?
2014-04-16 17:50:13
Pandora @kopandacco
It's been a long time, so I'll leave it at that. Dotto harai.
2014-04-16 17:50:27
Pandora @kopandacco
MMC was a pseudo-scan interrupt, not a timer interrupt. Oh well.
2014-04-16 17:53:58
Sorge Ichizo @zolge1
I'm looking up the NES regulations now. I'm numb to the color and sound on the edge. I'm amazed they made this setting in 83. It's as detailed as looking at a survival kit and I don't think any other manufacturer did something like this. The hardware that did the usual messy stuff here, all the wrinkles went to the software.
2014-07-24 22:06:16
Pandora @kopandacco.
@zolge1 Work is ・・・・! A little more RAM... somehow... (but even less for SG1000), cries my heart out as a developer back then. I agree vehemently that the NES has unbelievably high specs for that era (not much more than even the Mark 3).
2014-07-24 22:34:14
Sorge Ichizo @zolge1
If you ask me how PCM drums sounded on the NES, I still have the impression that even though it wasn't that rare, it still didn't sound like that. I don't know if it ate up processing or memory, or if the NES was becoming obsolete by the time it was solidified as a technique. Bass and okehi are much rarer.
2014-08-19 19:47:03
Pandora @kopandacco.
@zolge1 It sounds like they were gunning for the NES Wars. I was listening to that one and thought "Huh? Isn't 4 notes not enough?" I checked and found it was PCM. I heard that the official NES development equipment (for music) at that time included data for PCM, but we were a small company and didn't have any official equipment.
2014-08-19 20:12:20
Sorge Ichizo @zolge1
Oh, valuable information from someone who rang in real life! Come to think of it, the gunnucks were ringing all over the place. But yeah, it may be that the drum tone data was not so ready and widespread even if you wanted to ring it.
2014-08-19 20:35:34
Pandora @kopandacco.
@zolge1 Yes, it's rather special data, so it may have been a struggle in some cases.
2014-08-19 20:36:32
Sorge Ichizo @zolge1.
@kopandacco Very informative. By the way, was it not a burden in terms of capacity and processing?
2014-08-19 20:39:06
Pandora @kopandacco.
@zolge1 It's a special format, even though it's 1-bit, and it doesn't rattle like MSX's Raydoc or X1's Thunderforce. And I didn't feel any load in processing speed.
2014-08-19 20:49:07
Sorge Ichizo @zolge1.
@kopandacco Thank you for your very valuable talk. I think this is information that many people wanted to hear.
2014-08-19 20:55:49
Naoki Horii @hor11
@zolge1 @kopandacco Sorry to interrupt. I was exactly what I was listening to. Thank you!
2014-08-19 20:56:20