Hello everybody, i have this problem with the nes and i expect some help if it isn't much of a trouble.
I'm developing this program that basically shows some words on screen and allows the user to move a cursor on them to "select" them (this changes from nametable 0 to 1 and write the selected word again, then it appears like everything else has been deleted) and with another click, the program deselect it. i tested it with the FCEUXD emulator and it worked fine, but i wanted to make it work in real hardware so i modified a NROM cartridge (i already tested it with some games and it works, so the cartridge isn't the problem) and load the program into the eproms.
the problem is that the words are written by parts, and sometimes not at all. i was thinking maybe somebody had some clues about what am i doing wrong that the emulator couldn't notice but the real NES does, and if you need everything (like the source) just reply.
Maybe you're writing to $2007 at the wrong time (outside of VBlank) ? Or maybe it's just the CHR bus which makes bad contact with the NES (happens to me all the time and I have to reset countless times to get proper graphics).
Save time by testing with Nintendulator or Nestopia first. I'm surprised you went straight to hardware without this step.
As i already said, i tested it in an emulator already and it didnt show any problem, so i dont think it's a $2007 timing problem, or maybe it is but it doesn't explain why it only shows in the nes and not in an emulator. I'm gonna try with more emulators for now.
edit: i proved the program with both, nintendulator and nestopia, with the first one it has no problem either but with nestopia it only shows the sprites, not the background or anything else.
Mmmmmm are you stripping the header? Also is the file padded? you know do you have na actual 32k rom and 8k chr file? or is it smaller then that?
i already tested everything related to hardware, ripped the .nes with cajoNES and load both the .pgr and .chr into the respectives eproms.
here is the .nes and the source of the program. about the .nes it´s already tested in FCEUXD and it works fine. Any idea would be appreciated.
source.zip
Just realised. Did you solder the correct mirroring jumper on the board? I believe they're marked kinda weird so people tend to think they have the correct setting but it turns out they got the wrong one. Try removing the blob of one of the pads and putting a blob on the other.
edit: it also seems to only load up if I select pal mode. Sure you're not using too many cycles?
edit2: Switching mirroring DOES seem to give an effect sorta like you describe. (or at least as I understand it)
it isn't the mirroring, i checked and the nrom is solded in vertical, the same that the program( using name table 0 and 1 to switch).
Also, what do you mean with "too many cicles", i dont quite understand why it only works in PAL mode either.
Ya but I recall reading the boards got it switched or something
aka vertical mirroring is selected by jumper h and vice versa.
edit: I meant too many cycles as in takes too long to run in the vblank.
edit: it DOES seem like you do ALOT of writes to the ppu in vblank. I think that might be your problem
i was also thinking that maybe that was the problem, so assuming the time of the vblank is too short for the routines, what can i do there, do you have any idea?
Also, i'm gonna check the mirroring, probably that's the problem..
euler271 wrote:
it isn't the mirroring, i checked and the nrom is solded in vertical, the same that the program( using name table 0 and 1 to switch)
Solder pads on boards correspond to how the nametables are
arranged, which is opposite of how they're
mirrored.
Quote:
Also, what do you mean with "too many cicles", i dont quite understand why it only works in PAL mode either.
There are over three times as many CPU cycles in an NTSC NES's vertical blanking than in a PAL NES's. NTSC has 20 lines of vblank at 341/3 cycles each for 2273 cycles; PAL has 70 lines at 341/3.2 cycles each for 7459 cycles. So if you're rewriting large portions of the nametables or uploading lots of tiles to CHR RAM, you'll have to heavily optimize your PPU code if you want to release outside Europe, Australia, and New Zealand. With no slick tricks other than partly unrolled loops to copy from a transfer buffer in RAM, you can squeeze in a sprite DMA and roughly 160 bytes of copies to VRAM. You can carve this buffer out of the stack if you want:
- $0100-$019F: VRAM transfer buffer
- $01A0-$01FF: stack
- $0200-$02FF: OAM transfer buffer
ok, so the routine is too large for a NTSC video mode and maybe is so large that even the rendering is not finished on time and that could explain the words being cut. Assuming that's the case, what can i do to make it fit, can i make this routine take more that one frame to "refresh" the nametable so that it can fit in NTSC mode? how?
When updates take too long to fit in VBlank even after you optimize the hell out of the code, you have 2 options:
1: Disable rendering. While rendering is disabled, you can write to the PPU as much as you want, and when you're done you can enable rendering again. Notice that the screen will be blank during the time you are copying the data, so this solution is good for when you want to change the whole screen, but sucks for animating a screen that is already being displayed, because the image would flicker with each update.
2: Break up the large update into smaller ones and do them across consecutive VBlanks. Most games do this as the camera scrolls, as they draw small portions of tiles (in the form of rows or columns) instead of rewriting the whole background. If the kind of animation you are making looks bad when done in parts, you can always write the new data to the hidden name table and display that once all data has been written.
I'm willing to help you work through optimizing it. How much of the screen are you trying to update in a single vertical blank? You can usually fit about five rows or columns into a single NTSC vblank.
If less than that, can you post some of the code that you're using on
Pastey?
OK, thanks for the support, i already made a link to the source some posts up.
As you can see in the .nes (by the way, the .nes is proved to be right with fceuxdsp, some bugs with Nintendulator and only the cursor works with Nestopia), the writing and changing of the nametables happen when the cursor is on the word and 'A' is pressed, then if 'A' is pressed again anywhere the word selected is 'erased' from NT1 and the NTs switch again to the original state, so i'd say that without the first writing of all the words, the refreshing only happen in 3 rows.
Didn't have time to do too much debuging, just did one test. I guess people already knew but If I disable the content inside the NMI, the screen is shown in nintendulator. So something is going on there. If I have more time I will do more testing.
Anyone has an idea about how to modify the NMI handler to make it work fine? I'm making some improvements on the source, maybe later i will upload it. if anyone has an idea or can debug the code a little, please share your ideas