Weird PPU writes

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Fiskbit
Posts: 890
Joined: Sat Nov 18, 2017 9:15 pm

Weird PPU writes

Post by Fiskbit »

I came across the following PPU write sequence a while back in The Legend of Zelda:

Code: Select all

  Bank7_E4C4: A9 3F         LDA #$3F
  Bank7_E4C6: 8D 0620       STA PPU_ADDRESS
  Bank7_E4C9: A9 00         LDA #$00
  Bank7_E4CB: 8D 0620       STA PPU_ADDRESS
  Bank7_E4CE: 8D 0620       STA PPU_ADDRESS
  Bank7_E4D1: 8D 0620       STA PPU_ADDRESS
It does this during every vblank after the function that handles PPU writes. It's also done after each series of writes in that PPU write function if the writes started in the $3F page:

Code: Select all

  Bank6_A0DA: C9 3F         CMP #$3F
  Bank6_A0DC: D0 0C         BNE $A0EA
  Bank6_A0DE: 8D 0620       STA PPU_ADDRESS
  Bank6_A0E1: 8E 0620       STX PPU_ADDRESS  ; X == 0
  Bank6_A0E4: 8E 0620       STX PPU_ADDRESS
  Bank6_A0E7: 8E 0620       STX PPU_ADDRESS
I can't find any reason why it needs to be writing to this 4 times, nor have I found any mention of this on nesdev. I wondered if this was unique to Zelda, but found the same pattern in SMB1, SMB3, Ninja Gaiden 3, Battle City, Mega Man 1, and TMNT1, which covers a pretty wide range of companies (Nintendo, Tecmo, Namco, Capcom, Konami) and years (1985-1991). Available disassemblies for SMB1, SMB3, and Mega Man 1 have comments indicating they have no idea what this code is for, so I'm clearly not the only one confused by this.

Can anyone shed some light on this code?
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Weird PPU writes

Post by tepples »

Any write of $3F $00 $00 $00 to $2006 is cargo-cult programming. The inexperienced coders who worked on NROM and FDS games may have internalized an incorrect model of PPU operation such that palette access ($3F00-$3FFF) and ordinary video memory access ($0000-$3EFF) have separate pointers inside the PPU.

Correct behavior: When the video memory address is $3F00-$3FFF and rendering is off, the backdrop is replaced with the color at the palette index corresponding to bits 4-0 of the video memory address. Changing the video memory address to $0000-$3EFF restores typical behavior of using palette index 0 (as if the VRAM address is $3F00). This write sequence changes the video memory address to $3F00 (uselessly) then $0000.

What they thought: The palette memory address and video memory address are separate. When rendering is off, the backdrop is replaced with the color at the palette memory address. Writes to $2006 starting with $3F set the palette memory address, and writes to $2006 starting with $00-$3E set the video memory address. This write sequence changes the palette memory address to $3F00 and the video memory address to $0000.

Or did very early (square button) Famicom PPUs actually have two separate addresses? Most western reverse engineering has focused on the more common revisions E and G of the NES chipset, not the earliest one that Nintendo recalled. If the palette on square button Famicoms worked differently, this write sequence could be a workaround for the misbehavior, just as Super NES games have to work around the bug in the HDMA controller of S-CPU revision 1.
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: Weird PPU writes

Post by Memblers »

This exact thing is mentioned in a (not publicly available AFAIK) excerpt from a Nintendo doc, dated from 1993. It doesn't say why, it just one sentence saying to do that when you write the palette. Then it shows the sequence from that first code block. I can at least say it doesn't seem to be a problem on 2C02G or 2C03 (Playchoice).
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Weird PPU writes

Post by Bregalad »

What they thought: The palette memory address and video memory address are separate. When rendering is off, the backdrop is replaced with the color at the palette memory address. Writes to $2006 starting with $3F set the palette memory address, and writes to $2006 starting with $00-$3E set the video memory address. This write sequence changes the palette memory address to $3F00 and the video memory address to $0000.
Dou you have any evidence they thought that ? Or is it pure speculaiton on your side ?
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Weird PPU writes

Post by tepples »

It's my best guess based on the hardware's behavior.
User avatar
za909
Posts: 248
Joined: Fri Jan 24, 2014 9:05 am
Location: Mijn hart woont al in Nederland

Re: Weird PPU writes

Post by za909 »

Misinterpreted documentation would make sense, there are similar cases for the APU, like in Ikari Warriors II, which plays RAW via $4011 but still sets up and starts the DPCM unit like during normal 1-bit delta playback. Or take some Capcom games that write $30 to $400C and then also a $07 to $4015, as if you had to make doubly sure to silence the noise channel.
User avatar
Anders_A
Posts: 88
Joined: Mon Nov 27, 2006 11:56 pm
Location: Sollentuna, Sweden

Re: Weird PPU writes

Post by Anders_A »

tepples wrote:Any write of $3F $00 $00 $00 to $2006 is cargo-cult programming.
memblers wrote:This exact thing is mentioned in a (not publicly available AFAIK) excerpt from a Nintendo doc, dated from 1993. It doesn't say why, it just one sentence saying to do that when you write the palette. Then it shows the sequence from that first code block
I wouldn't call trusting documentation from the creators of the hardware a "cargo cult". I bet most of them didn't really care if it was needed, but just put it there because nintento told them to and then forgot all about it. It's not like it's a costly operation in any way.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Weird PPU writes

Post by tepples »

To comply with the docs as I understand they are written, a generic video memory update buffer framework would have to check whether each string of writes to video memory is a palette update and write 3F 00 00 00 to $2006 afterward if so. This test costs valuable vblank cycles, as does the cost. For example, in Popslide, it'd add 11 cycles to each packet and 17 cycles to each palette write packet.

Code: Select all

; When writing the address to $2006
  STA packet_dsthi

; Before checking for the end of a packet
  LDA packet_dsthi
  CMP #$3F
  BNE was_not_palette
    STA $2006
    LDA #0
    STA $2006
    STA $2006
    STA $2006
  was_not_palette:
Or does it mean write 3F 00 00 00 at the end if at least one update during this vblank was a palette update, the way a program has to write the scroll at the end anyway? Without access to this document, I couldn't be sure.

It might be useful to count licensed games that do write 3F 00 00 00 vs. games that don't in order to estimate how important this practice was to Lot Check.
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Weird PPU writes

Post by Bregalad »

While it's false that having $2006 left pointing to the palette causes any problems, it's still true that palettes aren't buffered like other $2007 read/writes are.

The funny thing is that, even if the colour pointed to by the last palette write was to be used as background colour (this is not the case), then in most cases, the whole palette is written, so it'd point to $3f20, a mirror of $3f00. Even if only the BG palette is rewritten, $3f10 is still a mirror of $3f00. Only leaving the pointer at $3f01-$3f0f or $3f11-$3f1f would cause a problem, and those case would be very marginal.

So even if the take hypothesis that the last palette writen to is used as a BG colour was true, this "routine" would still be useless.

If the developers really tought they could use any colour as a background colour, they would eventually try this feature, and figure out that it doesn't work, isn't it ? If they did so and didn't change their code, then yes it's indeed cargo cult. If they just never tried anything else, we can't really call this cargo cult.
It might be useful to count licensed games that do write 3F 00 00 00 vs. games that don't in order to estimate how important this practoce was to Lot Check.
I'd be very interested in such a statistic.
Xkeeper
Posts: 92
Joined: Fri Feb 29, 2008 10:35 am

Re: Weird PPU writes

Post by Xkeeper »

hey thread! fancy seeing you here

i bumbled across another game that does this (TMNT 1) and got curious once i heard about the mystery. i did a simple scan for this sequence of bytes:

A9 3F
8D 06 20
A9 00
8D 06 20
8D 06 20
8D 06 20

I compiled the list here (note that the bytes in the header are wrong, i made an error copying them the first time)

https://pastebin.com/4BSfBm70



interestingly, a ton of games do this! even unlicensed ones!


from what i can tell, based entirely on wikipedia nonsense, "urban champion" and "excitebike" are the first games on the list to have it. clu clu land did not come up in the search but it might have it.

weird
Xkeeper
Posts: 92
Joined: Fri Feb 29, 2008 10:35 am

Re: Weird PPU writes

Post by Xkeeper »

I expanded the search a little bit. 1450 of 2650 ROMs matched a test where the first two bytes could be different; 1350 matched the exact thing.
https://mini.xkeeper.net/etc/weird-pals.txt

Nintendo also came up with a different way of doing it later on:

Code: Select all

Other games may have different methods that aren't caught by this test,
for example "Wario no Mori (Japan).nes"

	0F:CC73: A0 3F     LDY #$3F
	0F:CC75: A9 00     LDA #$00
	0F:CC77: 8C 06 20  STY PPUADDR = #$00
	0F:CC7A: 8D 06 20  STA PPUADDR = #$00
	0F:CC7D: 8D 06 20  STA PPUADDR = #$00
	0F:CC80: 8D 06 20  STA PPUADDR = #$00
here's a FCEUX lua script that will monitor writes and pop the debugger when it detects the game has written 3F 00 00 00:

Code: Select all


stage = 0
stages	= {nil, nil, nil, nil}

function dumpRegs()
	return string.format("PC=%04x A=%02x X=%02x Y=%02x ic=%10d", memory.getregister("pc"), memory.getregister("a"), memory.getregister("x"), memory.getregister("y"), debugger.getinstructionscount())
end

function resetPPU()
	stage = 0
end

function trackChanges(addr, size, value)

	if stage == 0 and value == 0x3F then
		stage = 1
		stages[1]	= dumpRegs()
	elseif stage > 0 and value == 0x00 then
		if (stage == 1 or stage == 2) then
			stage = stage + 1
			stages[stage]	= dumpRegs()
		elseif (stage == 3) then
			stages[4]	= dumpRegs()
			print(string.format("-----------\r\n%s\r\n%s\r\n%s\r\n%s\r\n", stages[1], stages[2], stages[3], stages[4]))

			debugger.hitbreakpoint()
			stage = 0
		end
	else
		stage = 0
	end

end

memory.registerwrite(0x2002, resetPPU)
memory.registerwrite(0x2007, resetPPU)
memory.registerwrite(0x2006, trackChanges)
interestingly, some games are not consistent about when and where they do this -- "batman returns (usa)" for example does write it, but not always


f-1 race
Image

bugs bunny birthday bash
Image

some games do not do it at all that i can tell, like batman (nes), so it doesn't seem like it was required for lotcheck (or they just didn't care)
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Weird PPU writes

Post by rainwarrior »

I'd be very surprised if lot check actually involved looking at source code.

I'd just assume some early example provided by Nintendo did it, and everyone copied it, and some unlicensed games probably copied it from stuff they disassembled to figure out how it works.

As code it works just fine. Unless you know ahead of time that it's actually redundant, it doesn't really stand out as something that would need experimentation/optimization?

It just looks funny to us now, with perfect hindsight.
Fiskbit
Posts: 890
Joined: Sat Nov 18, 2017 9:15 pm

Re: Weird PPU writes

Post by Fiskbit »

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
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: Weird PPU writes

Post by calima »

I can't read that, having to scroll left and right every line of the quote... Gonna have to copypaste to somewhere else.
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Weird PPU writes

Post by rainwarrior »

At least this gives a test case of Xevious for the supposed palette bug. (With the $3F00 write removed?)

I definitely believe that there was a bug, and that this change made it go away. Was it diagnosed correctly? I feel like there's more than enough commercial games that don't do the redundant write sequence that we'd have proper examples by now. (Though maybe very few games don't write palettes 16 at a time?)

DMC IRQ was a lot more rare, though. That seems slightly more possible, but still I think there's a good chance of misdiagnosis.
Post Reply