What should write-only registers return when read? ($200x)

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

User avatar
blargg
Posts: 3717
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

Yeah, they seem stable on my system. They behave like normal open bus, reflecting the last read, which is $40 if you use LDA $4016 or LDA $4017.
User avatar
cpow
NESICIDE developer
Posts: 1097
Joined: Mon Oct 13, 2008 7:55 pm
Location: Minneapolis, MN
Contact:

Post by cpow »

blargg wrote:I think at least one demo relies on some of this behavior. Here you go, a test ROM for this "decay register" behavior:

ppu_open_bus.zip
Image

Any idea what that demo is that relies on this? :D
User avatar
blargg
Posts: 3717
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

I thought it was the one by Memblers that requires that you "agree" that emulators will never be as good as the real thing before it continues, but I recently found that that demo says the same thing on hardware as well. :)
User avatar
cpow
NESICIDE developer
Posts: 1097
Joined: Mon Oct 13, 2008 7:55 pm
Location: Minneapolis, MN
Contact:

Post by cpow »

blargg wrote:I thought it was the one by Memblers that requires that you "agree" that emulators will never be as good as the real thing before it continues, but I recently found that that demo says the same thing on hardware as well. :)
Of course I agree that emulators will never be as good as the real thing. I mean...sure...I pass that test but not by any means because my emulator is a clone of the real HW/SW of the NES [which would make it a clone and not an emulation! :lol: ]. I just took a rough approximation approach and count PPU frames until 600msec have 'roughly' elapsed and then change any 1 that was set to 1 more than 600msec ago to a 0. I could have counted PPU cycles to get closer to exactly 600msec, but that would be overkill. Now, had your analysis included a temperature/delay relation curve [which I suppose i could have derived from your mountain of provided data but i'm a bit mathematically lazy], *that* might require PPU-cycle granular emulation of the decay. I can see it now... menu option for "NES temperature", selections include "just turned it on", "beat the first boss", "damn, when am i ever going to beat this stupid game?!".

I've seen 'frustration' expressed on these forums that 'so-and-sos' emulator is not mentioned in the echelon of the "accurate" [Nintendulator, Nestopia]. I'll admit I'd sure like to be up there too someday, but I take a different approach...I don't care if nobody uses my emulator [critical 'it sucks monkey butt' feedback is useful too, though :shock: if it includes a reason or two] but I sure am having fun trying to meet the challenges that you and others that put together test ROMs provide in terms of trying to increase the accuracy. Hopefully along the way I gain some knowledge and help others do the same. Isn't that what emulation is all about?

:D

26 more test ROM challenges ahead...
User avatar
Memblers
Site Admin
Posts: 3901
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers »

I don't remember exactly what was going on, but I think that emulator test part of the demo (I coded it before I had my ROM emulator) might require CHR-ROM to be used (and I probably released it using CHR-RAM, heh). But regardless, when running everything on NES I use CHR-RAM, so I may just never know. :P
Post Reply