nesdev.com
http://forums.nesdev.com/

Famicom/Dendy SRAM cartrige
http://forums.nesdev.com/viewtopic.php?f=9&t=8781
Page 9 of 10

Author:  infiniteneslives [ Sat Feb 23, 2013 10:42 am ]
Post subject:  Re: Famicom/Dendy SRAM cartrige

So you're actually able to 'single step' through something like the MMC3 scanline counter properly? Freezing the counter is one thing but syncing it back up properly including proper filtering and such would be quite a feat. Not only that but you've got to actually fire irqs at the pre-freeze rate to keep things stable while freezing. Wowzers, are you actually doing all that?

Author:  HardWareMan [ Sat Feb 23, 2013 12:09 pm ]
Post subject:  Re: Famicom/Dendy SRAM cartrige

Well, we make 2 types of mappers: one simple and stable just for playing and other one with savestate abilities and other that kind stuff for debug. Debug mappers will be evolved simultaneously with debugger to achieve maximum possible adequate behavior in single step mode without any extra requirement from NES/FC side. That's our goal.

Author:  HardWareMan [ Fri Jun 07, 2013 12:56 pm ]
Post subject:  Re: Famicom/Dendy SRAM cartrige

OK, using some techniques of interpretation of PPU signals we got extended capabilities, that pushes limits. Now we have private attribute for every single tile (8x8) instead of block 2x2 of tiles. Some demonstration. Now I can say: we will do GUI menu, that can contain game thumbnails. Stay tuned.

Author:  TmEE [ Fri Jun 07, 2013 12:58 pm ]
Post subject:  Re: Famicom/Dendy SRAM cartrige

This is very very awesome !

Author:  lidnariq [ Fri Jun 07, 2013 1:35 pm ]
Post subject:  Re: Famicom/Dendy SRAM cartrige

Any reason you didn't go all the way and have an attribute for every 8x1slice?

Author:  thefox [ Fri Jun 07, 2013 1:58 pm ]
Post subject:  Re: Famicom/Dendy SRAM cartrige

HardWareMan wrote:
OK, using some techniques of interpretation of PPU signals we got extended capabilities, that pushes limits. Now we have private attribute for every single tile (8x8) instead of block 2x2 of tiles. Some demonstration. Now I can say: we will do GUI menu, that can contain game thumbnails. Stay tuned.

Wait, how is a grayscale video supposed to demonstrate that feature? (Also, why u no use YouTube?)

Author:  HardWareMan [ Fri Jun 07, 2013 9:03 pm ]
Post subject:  Re: Famicom/Dendy SRAM cartrige

lidnariq wrote:
Any reason you didn't go all the way and have an attribute for every 8x1slice?

You're right. I must go this way. Besides, that can be done easier than 8x8.
thefox wrote:
Wait, how is a grayscale video supposed to demonstrate that feature? (Also, why u no use YouTube?)

This video shows a render of solid 512x480 picture windowed by 256x240 (PAL). I ain't gonna upload to youtube this one.

Author:  3gengames [ Fri Jun 07, 2013 9:10 pm ]
Post subject:  Re: Famicom/Dendy SRAM cartrige

Someone should youtube it as I can't access the site.

Author:  HardWareMan [ Wed Jun 12, 2013 8:13 am ]
Post subject:  Re: Famicom/Dendy SRAM cartrige

It's very hard to extract full address when PUU fetch attribute byte, so for now achieved only 8x8 individual attribute.
Image
I'll work further on this.

Author:  HardWareMan [ Fri Jun 14, 2013 12:40 pm ]
Post subject:  Re: Famicom/Dendy SRAM cartrige

Here test with color. Attributes are random for test purpose. And it compatible with worst clones with internal 2KB VRAM that can't be switched off (with less color resolution).

Author:  lidnariq [ Fri Jun 14, 2013 4:03 pm ]
Post subject:  Re: Famicom/Dendy SRAM cartrige

HardWareMan wrote:
It's very hard to extract full address when PUU fetch attribute byte, so for now achieved only 8x8 individual attribute.

A very simple heuristic would be to latch the bottom 3 bits of the PPU address during pattern fetch, and use that as the fine Y scroll. The leftmost 8 pixels will be wrong (and depend on what sprites are on the following scanline), but the other 248 should work correctly.

Alternatively, timed code in the CPU would allow 16x1 attribute zones:
Attachment:
File comment: Uses N163 ROM nametables and timed code. Uses ≈50% CPU time during rendering (but busywaits)
display.nes.zip [13.63 KiB]
Downloaded 140 times
Attachment:
display.nes.png
display.nes.png [ 46.02 KiB | Viewed 32055 times ]


I think more careful timing should allow switching attribute tables every 16 pixels, which could be offset from the PPU's native 16 pixel wide segments to achieve a new attribute every 8 pixels.

Author:  HardWareMan [ Fri Jun 14, 2013 11:04 pm ]
Post subject:  Re: Famicom/Dendy SRAM cartrige

lidnariq wrote:
HardWareMan wrote:
It's very hard to extract full address when PUU fetch attribute byte, so for now achieved only 8x8 individual attribute.

A very simple heuristic would be to latch the bottom 3 bits of the PPU address during pattern fetch, and use that as the fine Y scroll. The leftmost 8 pixels will be wrong (and depend on what sprites are on the following scanline), but the other 248 should work correctly.

Thinking the same thing. I can detect render end (no PRD cycle in couple M2 cycles) and reset fine tune counter. Need more testing and analyzing.

I've just think about: we can use sprite prefetch mechanism to recover scanline number, right? With IRQ, fired at every 8 scanlines for set new sprite coordinates and VBlank for reset sprite position.

Author:  tepples [ Sat Jun 15, 2013 4:54 am ]
Post subject:  Re: Famicom/Dendy SRAM cartrige

You could try an MMC5-like fetch follower:
3 /RD falls in a row with PA13 high: Set X counter (6 bits) to 2
PA13 rise: Add 1 to X counter
Counter in (34...41): Fetch sprite patterns instead of BG patterns
PA13 rise while counter >= 41: Set X counter to 0
/RD fall with PA13 low and X counter = 0: Set Y counter (3 bits) to PA2-0

Author:  HardWareMan [ Sat Jun 15, 2013 6:50 am ]
Post subject:  Re: Famicom/Dendy SRAM cartrige

I know about MMC5. But doing some researches with logic analyzer I figured out that NTSC and PAL PPUs have some difference in render cycle. NTSC one has strange double-ALE cycles without PWR/PRD asserting.
Image

***

Almost got it:
Image

***

Logic analyzer says:
Code:
Previous scanline
201E - 23C7 - xxx0 - xxx8
201F - 23C7 - xxx0 - xxx8
HBlank
2400 - 27C0 - 0000 - 0008
2401 - 27C0 - 0010 - 0018
2402/2002 - 2000 - 1000 - 1008 < Address glitch
2000 - 2000 - 1FF1 - 1FF9
2000 - 2000 - 1FF6 - 1FFE
2000 - 2000 - 1FF6 - 1FFE
2000 - 2000 - 1FF6 - 1FFE
2000 - 2000 - 1FF6 - 1FFE
2000 - 2000 - 1FF6 - 1FFE
2000 - 2000 - 1FF6 - 1FFE
Next scanline
2000 - 23C0 - xxx1 - xxx9
2001 - 23C0 - xxx1 - xxx9
....
201E - 23C7 - xxx7 - xxxF
201F - 23C7 - xxx7 - xxxF
HBlank
2400 - 27C0 - 0000 - 0008
2401 - 27C0 - 0010 - 0018
2402/2002 - 2000 - 1000 - 1008 < Address glitch
2020 - 2020 - 1FF1 - 1FF9
2020 - 2020 - 1FF6 - 1FFE
2020 - 2020 - 1FF6 - 1FFE
2020 - 2020 - 1FF6 - 1FFE
2020 - 2020 - 1FF6 - 1FFE
2020 - 2020 - 1FF6 - 1FFE
2020 - 2020 - 1FF6 - 1FFE
Next scanline
2020 - 23C0 - xxx0 - xxx8
2021 - 23C0 - xxx0 - xxx8

Every column of table is normal PPU nRD based access to VRAM. In HBlank we have double access with start address of nametable. Maybe, this can be used somehow...

Author:  lidnariq [ Wed Jun 19, 2013 8:17 pm ]
Post subject:  Re: Famicom/Dendy SRAM cartrige

I was rereading some old threads and wanted to point out that Visual2C02 showed this: viewtopic.php?p=102081#p102081

Page 9 of 10 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/