It is currently Mon Jul 23, 2018 5:12 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 31 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Wed Jun 20, 2018 10:07 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10616
Location: Rio de Janeiro - Brazil
So, I'm working on something that requires me to alternate between 2 side-by-side name tables every 8 scanlines (8 scanlines of name table A, 8 scanlines of name table B, then back to A, and so on). Can anyone think of a way to do this that doesn't involve using the MMC3 (or other complex mappers with IRQ functionality) or wasting nearly 100% of the CPU power on timed code?

In an ideal world, DMC IRQs would be enough to time this, but somehow I doubt I could get something stable enough out of that. On the other hand, there is the fact that the window for writing to $2000 is huge, since horizontal scroll changes are buffered until the end of the scanline, so the timing doesn't have to be particularly precise, just enough for the write to happen anywhere in the correct scanlines.

I might end up going with the MMC3, as that'd bring other advantages besides the scanline counter, but I though I'd ask here first to see if anyone could think of something I didn't consider. Thanks.


Top
 Profile  
 
PostPosted: Wed Jun 20, 2018 10:18 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7329
Location: Seattle
Is this to get 16x8 attribute zones? If so, you could interleave the data such that you only had to change after every 16 scanlines.


Top
 Profile  
 
PostPosted: Wed Jun 20, 2018 10:30 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10616
Location: Rio de Janeiro - Brazil
lidnariq wrote:
Is this to get 16x8 attribute zones?

Nope, it's to draw software pixels that are 4 pixels tall, using tiles that are 8 pixels tall.

Quote:
If so, you could interleave the data such that you only had to change after every 16 scanlines

I'm using the same principle, but on tiles rather than on attributes, so I can change nametables every 8 scanlines instead of 4. :wink:


Top
 Profile  
 
PostPosted: Wed Jun 20, 2018 11:42 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7443
Location: Chexbres, VD, Switzerland
tokumaru wrote:
Can anyone think of a way to do this that doesn't involve using the MMC3 (or other complex mappers with IRQ functionality) or wasting nearly 100% of the CPU power on timed code?

The obvious answer is using another mapper with scanline IRQs, such as any VRC mapper, MMC5, FME-7 or develop your game for the Famicom Disk System. I think that's not what you wanted to hear though.

DMC IRQs aren't precise enough for that, and you don't want to waste most of the CPU's time so the only way to go is developing a new hardware mapper capable of this automatically. By re-routing some adress line to CHR-A10 it should be doable easily, but will be havily non-standard and not emulatable.


Top
 Profile  
 
PostPosted: Thu Jun 21, 2018 12:57 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6431
Location: Canada
VRC IRQs are cycle based, rather than true scanline timings, so they might not be quite as good for chaining repeated splits like this.

A restricted subset of MMC3 probably isn't too bad to build these days.

A simple mapper that makes it easy could be great, too. Maybe something like the Punch Out mapper where reading byte 4 of a specific tile you place at the end of the line will trigger a split automatically. New mappers don't seem as big a problem to me as they used to, there's quite a few good actively developed emulators these days that might keep up.


Top
 Profile  
 
PostPosted: Thu Jun 21, 2018 4:06 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1658
Location: Gothenburg, Sweden
Yeah, for comparison, GTROM was let loose 2015(?), and by may 2017, mesen had full support. fceux r3293 has support for the most important features, and likewise, so does powerpak.
This is because GTROM has become a very popular homebrew mapper.

A mapper that is simple enough to be about as cheap as nrom, unrom, gtrom etc, yet passively interleaves rows from two nametables, would nicely fill a role for any homebrew that seeks a slanted topdown perspective (popular with adventure games, rpgs, action puzzles) or an isometric view.

The example below could be a probably have more liberally constructed maps, including the z axis, better shadow effects, and so on.
Attachment:
File comment: doodle i made some time ago for the "maybe sometime" pile of ideas.
filtered.bmp
filtered.bmp [ 847.55 KiB | Viewed 934 times ]
.

I'm not well-read on the cartridge port side, but am i right to believe all it'd take is cutting and jumpwiring some traces? alternatively from a design perspective, inculde a three-point jumper/solder bridge to be able to reroute the behaviour.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Thu Jun 21, 2018 7:44 am 
Offline
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 416
Location: Central Illinois, USA
rainwarrior wrote:
New mappers don't seem as big a problem to me as they used to, there's quite a few good actively developed emulators these days that might keep up.


FrankenGraphics wrote:
Yeah, for comparison, GTROM was let loose 2015(?), and by may 2017, mesen had full support. fceux r3293 has support for the most important features, and likewise, so does powerpak.
This is because GTROM has become a very popular homebrew mapper.


It really all depends on whether you want emulator support primarily for development/test, vs if you plan to release a rom that you want the majority of people to be able to use. The average joe (who possibly plays emulated games on their phone or raspberry pi) won't have access to an emulator that supports GTROM or other new mappers for quite a while, I imagine.

That's not an issue if you primarily plan to release on cartridge-only, or if you don't care to target the larger rom-consuming community. But if you do, then using a new mapper will still limit your audience for quite a while. (and that's not even considering folks who have clones like the Retron 5, who may miss out when you use a custom mapper)


(I'm not trying to argue that a new mapper is a bad idea, heck, I'm using GTROM in the game I'm making. Just that there are potential downsides even IF you can find some emulator support)

_________________
My games: http://www.bitethechili.com


Top
 Profile  
 
PostPosted: Thu Jun 21, 2018 7:59 am 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 350
Location: Poland
For testing or playing under emulator - use MMC3
For doing physical cartridges - use 4020 counter and count 8 * 8 rising edges of PPU A12


Top
 Profile  
 
PostPosted: Thu Jun 21, 2018 8:18 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1658
Location: Gothenburg, Sweden
good points gauauu, it then becomes a question of how you'd intend to spread the software. Unless it's a proof of concept for a small crowd.

-an mmc3 type of thing is available for everybody as a freely shared ROM.

-a cartridge release on a typical homebrew Kickstarter scale of 200-500 units (upper figure is rare) would benefit financially from having a cheaper mapper than an mmc3. Even if physical mmc3 games are doable like this, you need to reach a higher threshold to break even.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Thu Jun 21, 2018 10:23 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7329
Location: Seattle
FrankenGraphics wrote:
A mapper that is simple enough to be about as cheap as nrom, unrom, gtrom etc, yet passively interleaves rows from two nametables, would nicely fill a role for any homebrew that seeks a slanted topdown perspective (popular with adventure games, rpgs, action puzzles) or an isometric view.
[...]
I'm not well-read on the cartridge port side, but am i right to believe all it'd take is cutting and jumpwiring some traces? alternatively from a design perspective, inculde a three-point jumper/solder bridge to be able to reroute the behaviour.
Yes, one could easily add cartridge hardware—in fact, just a 74'161—to automatically interleave namatables every 4 rows.

Specifically: latch PPU A2..0 on reads from pattern tables (i.e. 74'161.CK ← PPU/RD and 74'161.LE ← PPUA13). Because of how the PPU's fetch cadence works, the first fetch will have bogus results—that nametable fetch follows a sprite pattern fetch instead of a background pattern fetch—but that can be concealed with the "mask left 8 pixels" control.

The complicated part is if you ever want to turn it off.


Top
 Profile  
 
PostPosted: Thu Jun 21, 2018 11:06 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10616
Location: Rio de Janeiro - Brazil
lidnariq, I'm in no way qualified to validate your idea, but it'd be great if it could really be this simple. Would CHR-RAM or 4-screen mirroring interfere with that in any way? I can live without being able to turn it off.


Top
 Profile  
 
PostPosted: Thu Jun 21, 2018 11:30 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10616
Location: Rio de Janeiro - Brazil
lidnariq wrote:
Specifically: latch PPU A2..0 on reads from pattern tables (i.e. 74'161.CK ← PPU/RD and 74'161.LE ← PPUA13).

OK, I'm trying to make sense of if this: why do I need to latch PPU A2..0, and what do I do with them?

Now that I think of it, couldn't I latch just A2 (the bit that selects the top or bottom 4 rows of a tile) on pattern table reads, and use that as the lower name table selection bit? I'm not very good with hardware, so sorry if I'm way off, but my thinking is that whenever the top half of a tile is read, the left name table will be selected, and whenever the bottom half of a tile is read, the right name table will be selected. Does that make any sense?


Top
 Profile  
 
PostPosted: Thu Jun 21, 2018 11:34 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7329
Location: Seattle
Didn't you want automatic nametable switching? How are you thinking 4-screen would interact with that?

CHR-RAM wouldn't interfere.

This is approximately the same idea as mapper 96, or the initial drafts of what HardWareMan did for his InviteNES flashcart. (Unfortunately, his images expired from whatever host they're on)

tokumaru wrote:
couldn't I latch just A2 (the bit that selects the top or bottom 4 rows of a tile) on pattern table reads, and use that as the lower name table selection bit?
No, that's exactly correct. I don't know if there's a cheaper way to get "latch one bit when signal is low and another signal rises" than just a single 74'161, though.


Top
 Profile  
 
PostPosted: Thu Jun 21, 2018 12:00 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10616
Location: Rio de Janeiro - Brazil
lidnariq wrote:
Didn't you want automatic nametable switching? How are you thinking 4-screen would interact with that?

I don't know... I still want to have control over which pair of name tables to use with the automatic switching (i.e. the top 2 or the bottom 2), so I imagine I'd need another latch for that, right?

What I'm not sure is how I'd use the 2 name table selection bits to control the VRAM chip in the cartridge... They'd have to be used only on name table reads, so that'd be when A13 is high, right?

Quote:
CHR-RAM wouldn't interfere.

OK.

Quote:
This is approximately the same idea as mapper 96, or the initial drafts of what HardWareMan did for his InviteNES flashcart.

Oh, I didn't get much of that back then, but I see it now.

Quote:
No, that's exactly correct. I don't know if there's a cheaper way to get "latch one bit when signal is low and another signal rises" than just a single 74'161, though.

Awesome. I guess this is still all a bit too experimental for my taste, though... It's mainly the lack of support for this in emulators and Flash carts that bothers me. I could build a socketed cartridge for development, but that'd be far from ideal.

EDIT: Wait, I don't need to latch the vertical name table selection bit, A11 can go through unmodified, but I do have to decide whether to drive the horizontal bit with the latched value (reads when A13 is high) or let A10 just go through (all other cases). Would that make 2 sets of 2 name tables possible?


Top
 Profile  
 
PostPosted: Thu Jun 21, 2018 12:27 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7329
Location: Seattle
tokumaru wrote:
lidnariq wrote:
Didn't you want automatic nametable switching? How are you thinking 4-screen would interact with that?
I don't know... I still want to have control over which pair of name tables to use with the automatic switching (i.e. the top 2 or the bottom 2), so I imagine I'd need another latch for that, right?

What I'm not sure is how I'd use the 2 name table selection bits to control the VRAM chip in the cartridge... They'd have to be used only on name table reads, so that'd be when A13 is high, right?
Think about it like this...

A nametable is 1K of memory. The PPU natively provides two controls (PPU A10 and A11) to address 4 nametables (but only pre-provides enough memory for 2). But you can keep on adding more address lines as long as you have enough memory for it.

For example:
"Horizontal mirroring" connects PPUA11 to CIRAMA10.
AOROM connects an output from the latch to CIRAMA10.
GTROM connects PPUA10, PPUA11, and an output from the latch (via extra hardware) to CHRRAMA10, CHRRAMA11, and CHRRAMA14.

All of these are ways to allocate some number of chunks of 1K of memory to the region seen by the PPU.

So there's a bunch of options, depending on just how much RAM you're talking about. If you wanted something like GTROM, but instead of having two planes of 4 nametables controlled by the CPU latch, you could instead just connect the output of the PPU address latch to the same extra hardware and end up with a single 64x120 "stout tile" display, corresponding to 512x480 pixels.

Alternatively, you could also get away with just using the 2K of RAM inside the NES; then you'd have a single 32x60 "stout tile" display, corresponding to 256x240 pixels.

Quote:
It's mainly the lack of support for this in emulators
Looking quickly at Mesen's source (especially OekaKids and MMC2), I bet adding support would be really easy.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 31 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group