When running Chris Covell's demo "Sayoonara!" on most recent emulators I see there are glitches in it. Some background areas are in gray where it should supposedly be black. What this originates in is the handling of $2001.3 and $2001.4. I'm still unsure of what the PPU exactly does when they're manipulated during midframe (beside from stoping the data fetching when both are cleared).
If I remember correctly some of you tested this demo on the real hardware, do any of you remember if those glitches were there as well?
I get the grey patches in my emu as well (as least I think they're the same ones you're talking about... my emu shows it very similar to how Nintendulator does).
Oddly enough... it doesn't play any sound in my emu... o_O
Actually, those spots are SUPPOSED to be gray - older emulators would display them in black instead.
Quite strange that "buggy" situations mean the "accurate"...
I looked at the sound problem... I can't understand how emus are playing sound for the demo.
It seems to write 0 to $4015 -- then write to each channel's length reg ($4003,4007,400B,400F) -- then write $0F to $4015.
It never writes to the length reg for any channels unless it writes $00 to $4015 first. I'm under the impression that this method will NOT work.. since the length counter is always zero unless the channel's $4015 bit has been flipped on. (ie: writing to the length reg will not reload the length counter unless the channel's $4015 bit is on)
How does this demo operate on the real system? Anyone know?
Hi, Chris C here...
About the grey parts -- those are supposed to be there. Sayoonara changes the palette two different times mid-screen, once after the gold lightsource logo, and again after the "sayoonara" logo. Since writing to the palette mid-screen causes the PPU to display the contents of the palette registers, I set the greyscale bit on, as well as all 3 emphasis bits. This changes the colours to various levels of grey (and the 3 emphasis bits will darken the grey) so the palette writing is less noticeable on the real hardware.
About what the music code does, I can't say since it's just ripped code.
And I did test this on real NES hardware using my devcart (I also did most of the testing on my DrPCJr). It worked OK, but Kevin H. tried it on his CopyNES and said there was some sprite glitching... I don't remember any, but this was a long time ago anyway...
Bye for now
Did the music play at all? I disassembled a short segment of code around the only two occurrences of $15 $40 (i.e. $4015), and it seemed that it would always leave the length counters at zero, resulting in silence.
I just tried Ferrari Grand Prix Challenge (the game the music was ripped from?) in my emu and the music played fine... but I get complete silence in Sayoonara!.
Maybe the writing to $4015 with channel bits off only clears the length counter and doesn't prevent it from reloading? All the docs say it does though.
*shrugs*
According to the NESdev wikki, RAM is mosty set to $ff on init. Sayoonara's sound will play on my emulator if I set RAM to $00 on init, but if I set it to $ff it will not.
AAhhh... yeah that explains it. I wipe system memory with $FF on startup (This seems right to me, since using $FF solves a quirk in Final Fantasy related to random encounters).
In my very simple NES emulator, if I set memory to $ff then Super Mario Bros. always starts on the negative world (it works if I clear it all to 0). Is this a well-known issue?
For me, clearing RAM to FFh doesn't affect SMB adversely.
I already had noticed this SMB side-effect on RAM $FF filling, but I didn't try again on my newst emu though...
blargg wrote:
In my very simple NES emulator, if I set memory to $ff then Super Mario Bros. always starts on the negative world (it works if I clear it all to 0). Is this a well-known issue?
It's a bad ROM. Here:
http://nesdev.com/cgi-bin/wwwthreads/showpost.pl?Board=nesdev&Number=1669&page=5&view=collapsed&mode=threaded&sb=5#Post1669
Have you guys tried "Cybernoid - The Fighting Machine"? It just recently got brought to my attention. Looks like the graphics get screwed when you flush with $FF and work when you flush with $00.
I suspect the actual dump is bad.
http://nesdev.com/Scrollde38.zip doesn't work at all when RAM is initialised at 0 instead of 0xff
Apologies for the topickick
Rise from your grave, topic. Hello old hap, you're wrong, you switched values. Anyway, I tried Minna no Taabou no Nakayoshi Daisakusen (J), and it doesn't work when RAM is set at 0x0. (I quite like that game, it's a remake of an MSX game I enjoyed when I was a kid).
To make it a bit clear:
RAM at 0x0:
- Minna no Taabou no Nakayoshi Daisakusen (J): won't work
- Final Fantasy: problem with random encounters (?)
RAM at 0xff (as confirmed by blargg):
- Cybernoid - The Fighting Machine (U): messed up graphics
- SMB1 (bad dump!): start at minus world
- Sayoonara: no music
- Scrollde38: won't work
- pputime2 (
http://tripoint.org/kevtris/mappers/incoming/ ): block moves to the right
*edit*: added pputime2
Which emulator are you using for such tests?
I collected most from this thread, and use my emulator to test things (except for Sayoonara: no sound yet :p ).
As for other emulators: I think Disch's emu flushes RAM with 0xff, and Quietust's Nintendulator flushes it with 0x0, judging from the behaviour between the two when testing the above list.
I'm not sure what Disch meant with the Final Fantasy problem.
You wouldn't notice the encounter bug unless you're a real FF1 geek like me. The games' random encounters are not random in all -- in fact it steps through a huge list which dictates which battle to fight -- making all your battles predictable as clockwork.
This FAQ here has it listed:
http://www.gamefaqs.com/console/nes/game/522595.html (select the "Character Lists" FAQ by 'Patbuns17' in the bottom section)
Search for "_Random Encounter List_" (no quotes, but keep the underscores) to jump to the section which contains it.
Every time you hard reset (or repower the actual NES), you start over in the encounter list. This can be abused by saving in town and hard resetting to make the next fight in the sea a pack of Kyzokus (they give lots of money). However on emulators, the game will start on the second entry in the table rather than the first entry in the table. I speculated that this was because it uses unprepped RAM for the counter, which is FF on the real system and 00 on emulators (which would be why emulators start one step in the table). After changing the way my emu flushes RAM this was confirmed, as the battle list started at the same point as on the NES.
But isn't it very likely that that FAQ was made using an emulator ? Or do you remember the Kyzokus cheat on the real NES ?
pputime2 and Sayoonara have been tested on a real NES, and that contradicts blarrg's test result.
I was a regular at the FF1 gamefaqs board around the time of that FAQ's devlopment. The encounter list was mapped out on both the real system and on emulators (NNNesterJ or FCEU probably, I can't recall) -- they were identical except for the starting point on powerup. I believe the list in that FAQ is taken from the actual system, and not from an emulator. Though I can't say with 100% certainty.
Disch wrote:
On every single HTML page of GameFAQs is the following request:
Feel free to link to this page, but not directly to the FAQs..
You're seeing this error message because it appears that you're linking from an external site directly to one of the text files stored at GameFAQs. GameFAQs is not a free public file server. Bandwidth costs money, and when sites link directly to files stored on the site, it becomes both a financial and resource drain. We've tried asking, but some sites simply don't care, so now we've implemented a technical solution.
Your browser is reporting that you linked to a GameFAQs-hosted FAQ from
http://nesdev.com/bbs/viewtopic.php?t=223&start=15.
There are four possible reasons you are seeing this message:
- You came from a direct link to a FAQ on GameFAQs from another site, and your link was properly blocked. See the paragraph above for why.
- Your web browser is passing improper URL data in the Referrer header. Your web browser may be over-compensating for a mistake you made in the address bar, and passing this information unintentionally. To fix this, just click the "Home" link on the left and surf normally.
- Your web browser is passing forged URL data in the Referrer header. Some browsers can be configured to hide referrer information, but instead of passing a blank header, it passes a forged one. To fix this, change your browser's security settings. If you are using Opera and having problems, try viewing this page for some pointers.
- You are behind a firewall or proxy server, and it is passing forged URL data in the Referrer header. If you are using one of these services, you or your network administrator may need to change the configuration.
The correct link is
http://www.gamefaqs.com/console/nes/game/522595.html
In the struggle to make the puzzle pieces fit together, this setup will at least make the commercial games and pputime2 work properly:
void Cpu::Ram::Reset()
{
std::memset( mem + 0x000, 0xFF, 0x3F0 );
std::memset( mem + 0x3F0, 0x00, 0x010 );
std::memset( mem + 0x400, 0xFF, 0x1F0 );
std::memset( mem + 0x5F0, 0x00, 0x010 );
std::memset( mem + 0x600, 0xFF, 0x200 );
mem[0x08] = 0xF7;
mem[0x09] = 0xEF;
mem[0x0A] = 0xDF;
mem[0x0F] = 0xBF;
}
Keep in mind that Kevin Horton's "pputime2" demo was tested on CopyNES, which initializes all memory to zero.
Ah, that's good to know. Does CopyNES do anything else significant ? (eg. disabling frame IRQs). Or even better, is its internal ROM (file) freely available to the public ? If not, perhaps Kevin Horton would be willing to release it ?
hap wrote:
Rise from your grave, topic. Hello old hap, you're wrong, you switched values. Anyway, I tried Minna no Taabou no Nakayoshi Daisakusen (J), and it doesn't work when RAM is set at 0x0. (I quite like that game, it's a remake of an MSX game I enjoyed when I was a kid).
Sorry, I'm going out of the topic, but this game seems to have the same sound code that FF3, it really sound the same. How surprising ! Has it be designed by Square or something ? Else, was it somme "licence-free" sound code that could be used from a library or something (?) for all NES developpers ? I also noted that SD gundam 3 and 4, that wasn't be made by Square at all also have the same sound code.