Famicom/Dendy SRAM cartrige
Moderator: Moderators
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
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?
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
- HardWareMan
- Posts: 209
- Joined: Mon Jan 01, 2007 11:12 am
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.
- HardWareMan
- Posts: 209
- Joined: Mon Jan 01, 2007 11:12 am
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.
Re: Famicom/Dendy SRAM cartrige
Any reason you didn't go all the way and have an attribute for every 8x1slice?
Re: Famicom/Dendy SRAM cartrige
Wait, how is a grayscale video supposed to demonstrate that feature? (Also, why u no use YouTube?)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.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
- HardWareMan
- Posts: 209
- Joined: Mon Jan 01, 2007 11:12 am
Re: Famicom/Dendy SRAM cartrige
You're right. I must go this way. Besides, that can be done easier than 8x8.lidnariq wrote:Any reason you didn't go all the way and have an attribute for every 8x1slice?
This video shows a render of solid 512x480 picture windowed by 256x240 (PAL). I ain't gonna upload to youtube this one.thefox wrote:Wait, how is a grayscale video supposed to demonstrate that feature? (Also, why u no use YouTube?)
Re: Famicom/Dendy SRAM cartrige
Someone should youtube it as I can't access the site.
- HardWareMan
- Posts: 209
- Joined: Mon Jan 01, 2007 11:12 am
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.
I'll work further on this.
I'll work further on this.
- HardWareMan
- Posts: 209
- Joined: Mon Jan 01, 2007 11:12 am
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).
Re: Famicom/Dendy SRAM cartrige
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.HardWareMan wrote:It's very hard to extract full address when PUU fetch attribute byte, so for now achieved only 8x8 individual attribute.
Alternatively, timed code in the CPU would allow 16x1 attribute zones: 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.
- HardWareMan
- Posts: 209
- Joined: Mon Jan 01, 2007 11:12 am
Re: Famicom/Dendy SRAM cartrige
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.lidnariq wrote: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.HardWareMan wrote:It's very hard to extract full address when PUU fetch attribute byte, so for now achieved only 8x8 individual attribute.
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.
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
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
- HardWareMan
- Posts: 209
- Joined: Mon Jan 01, 2007 11:12 am
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.
Almost got it: ***
Logic analyzer says:
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...
Moderator edit: recovered images from webarchive
***Almost got it: ***
Logic analyzer says:
Code: Select all
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
Moderator edit: recovered images from webarchive
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