It is currently Tue Oct 23, 2018 1:13 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 43 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Mon Apr 09, 2018 4:51 pm 
Offline

Joined: Wed Mar 09, 2005 9:08 am
Posts: 418
8x8 attributes with no mmc5 have been discussed at some point, but not sure anyone's actually tried them out yet.

So after experimenting with my new pass-through hardware debugging board, I figured I'd post it here and ask if anyone would find this to be a useful enough feature to spend logic on - despite the very quirky memory layout.

I chose mapper30 as an experimental platform, mainly because I did an Everdrive/Powerpak implementation (actually more like a copy'n'paste job from the available UNROM implementations). But also because I wanted to have a think about the minimum number of TTL circuits would be needed to add it to a popular discrete-circuit board.

The logic is really simple (and has been suggested on the forum): Latch the lowest X/Y during nametable accesses, and apply this during the attribute table accesses. In the goal of keeping this as simple as possible, these two bits get directly used to as CHR_A14 and CHR_A13 on the 32kB CHR-RAM chip. This means:
1) The new attribute table has a bit of an awkward layout: 4 different 64bytes areas, all mapped to address 03C0-03FF, 07C0-07FF, 0BC0-0BFF and 0FC0-0FFF for each nametable, across all 8kB CHR-RAM pages.

2) You gain some, you lose some: Because these areas overlap with the CHR, there's going to be 16 tiles particular tiles in pattern table 0 of each 8kB CHR that you need to avoid using. (though this could probably be cut to 8 tiles if you take advantage of mirroring, or 4 if you do single-screen mirroring)

I haven't had time to make a test ROM, so I've tried it out with a Megaman ROM instead. Here's the colourful mess of attribute accesses it currently displays:
Attachment:
megaman_8x8attributes.jpg
megaman_8x8attributes.jpg [ 3.7 MiB | Viewed 2259 times ]


And here's the very simple Everdrive Verilog code:
Attachment:
map_30.v [3.84 KiB]
Downloaded 74 times


I originally tried to use an asynchronous latch that would latch the value whenever 'ppu_oe' was low and 'attribute_access' was high. But this resulted in glitchy attributes. Not sure if this is due to actual quirks of the PPU signals, or just some FPGA-specific limitation.

So instead I treated ppu_oe as a clock and latched the attribute fine coordinates on the falling edge. Seems kind of naughty as it is not a dedicated clock input - but it appears to work.

If sticking to discrete component, I think it'd take say a 7408 'AND' TTL circuit, a 7400 'NAND' TTL circuit, a TTL latch circuit, and maybe an OR circuit. So it'd roughly double the number of TTL circuits on a mapper30 board, which isn't great but also wouldn't break the bank. This is mostly guesstimates though - I'd like to sketch up and implement this stuff on actual TTL circuits at some point in the future just as another fun experiment - but feel free to beat me to it.

A few thoughts of mine:
1) Infiniteneslives 4-screen variant of mapper30 could be used to provide a configuration that doesn't overlap with CHR, because you've got 4kB spare CHR-RAM and would only need 1kB for 8x8 attributes for all 4 screens. This would probably make the logic circuits required slightly higher, as you'd have to multiplex signals. It also can't be prototyped on an Everdrive/Powerpak, because they both cannot address less than a 1kB page.

2) Likewise, the single-screen variant of mapper30 would probably be more useful if the attribute fetches were redirected to the other screen that's currently not selected. This could give you an attribute table that does not overlap with CHR-RAM, and could still leaves some room for a status bar. But the same notes about increased IC cost/incompatibility with Powerpak/Everdrive apply.

3) 8x1 attributes should be fairly simple to implement by latching the lowest 3 bits from the PPU's CHR-fetch, but again it means increased number of discrete ICs. Also not sure how useful 8x8 attributes would really be? You'd still have a pretty awkward memory layout, and would need to have a 2kB attribute table for a single screen - twice the memory of a vanilla nametable to update.

4) And obviously, this solution might be a better fit for a CPLD-based implementation of MMC3/FME-7 and similar more advanced mappers, where you've already ditched discrete mappers and stepped up the cost. I haven't tried prototyping any of these mappers in a CPLD, but would hope this feature could be added without breaking the macrocell budget.

Let me know your thoughts on what you think would be the most useful of these hypothetical configurations.


Top
 Profile  
 
PostPosted: Mon Apr 09, 2018 5:15 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20689
Location: NE Indiana, USA (NTSC)
By the time you have five or more 7400 series ICs, you can probably afford a CPLD anyway, as I understand it. And at that point, you can interpose even more of the PPU bus, producing a more GBC-like attribute layout with two banks switched into $2000-$2FFF and the attribute for each 8x8 pixel area stored "behind" that area.


Top
 Profile  
 
PostPosted: Mon Apr 09, 2018 5:20 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3569
Location: Indianapolis
Pretty cool to see it in action. This is almost exactly what I've planning to do on the next mapper I produce, trading some pattern tables for more attributes. :)


Top
 Profile  
 
PostPosted: Mon Apr 09, 2018 5:31 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7682
Location: Seattle
Previous time I thought about this, I wrote this.

I bet this awkward-memory-layout design would fit nicely in a greenpak.


Top
 Profile  
 
PostPosted: Mon Apr 09, 2018 6:54 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 2095
Location: WhereverIparkIt, USA
lidnariq wrote:
I bet this awkward-memory-layout design would fit nicely in a greenpak.
But there's really too few of i/o available (18 at best) to handle PRG banking and 8x8 attrs. Dual greenpaks (or greenpak + mapper30 discrete logic) gets awfully close to the cost of a 32 macrocell CPLD.

The i/o limitation is my biggest obstacle with the greenpak. Part of the problem is I'm always trying to design a board that can handle a broad number of mappers/configs though which is my own fault. If one were to come up with one design and stick with it, the greenpak could shine in abilities and cost though.

Quote:
this solution might be a better fit for a CPLD-based implementation of MMC3/FME-7 and similar more advanced mappers
While it would certainly fit in a MMC3/FME7 scale mapper it adds even more signals that a 3v CPLD would have to level shift which MMC3/FME7 can typically avoid. It could still get done within a 5v tolerant MMC1 scale mapper with a 32 macrocell CPLD. The only 5v tolerant CPLD still recommended for new designs (and will be for 5+ years I'm told) is the lattice ispMach LC4032V. As Tepples mentioned, doubling the number of IC's for mapper 30 already gets you comparable pricing to the LC4032V your at least sitting right at that price threshold. So unless your specific goal is to stick with discrete logic I'd recommend taking advantage of the flexibility programmable logic provides. All that said, Lattice's lever classic isn't user friendly by any stretch so I have a hard time recommending the LC4032V for that reason, but it gets the job done.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Mon Apr 09, 2018 7:07 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7682
Location: Seattle
infiniteneslives wrote:
But there's really too few of i/o available (18 at best) to handle PRG banking and 8x8 attrs. Dual greenpaks (or greenpak + mapper30 discrete logic) gets awfully close to the cost of a 32 macrocell CPLD.
Hm, quickly thinking this through:

inputs-
PPU A0, A5-A9, A13, /RD → 8
CPU D0, D1, /ROMSEL, R/W → 4
(CPU M2, A12) → 2

disable NES-internal NTRAM, just provide 4-screen always

outputs-
CHR A13, A14 → 2
W/R

total - 17 I/O

Yeah, the extra I/O for self-flashing does us in. Removing that saves three pins, which leaves space for two more data lines and two PRG banking lines... more-or-less exactly GNROM with CHR RAM.


Top
 Profile  
 
PostPosted: Mon Apr 09, 2018 7:36 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 2095
Location: WhereverIparkIt, USA
lidnariq wrote:
Yeah, the extra I/O for self-flashing does us in. Removing that saves three pins, which leaves space for two more data lines and two PRG banking lines... more-or-less exactly GNROM with CHR RAM.

Giving up flash saves is probably a worthy trade off if you're after 8x8 attrs. If you have the freedom to trim i/o for a custom mapper like you did the greenpak can really shine in with a highly customized specific mapper design like this. The challenge then becomes emulator support, and worthy software to make use of the hardware that makes one confident enough to purchase enough greenpaks to make them cost effective...

For me, the lack of flexibility due to i/o limits can effectively put the greenpak in the position where you may never be ready to buy the min 3k pcs. I did pick up one of their dev boards and a few samples to tinker around with recently though. Guessing I'll come up with something to put it to use for some day. They are coming out with new packages including the first non-qfn (tssop) package this summer, and a device with an LDO. So for now I'm hoping they keep moving things forward and 30-40 i/o count devices become available to fill the hole that's being created of small 5v tolerant CPLDs as Xilinx and Altera are exiting the market.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Mon Apr 09, 2018 11:00 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7548
Location: Chexbres, VD, Switzerland
Quote:
All that said, Lattice's lever classic isn't user friendly by any stretch so I have a hard time recommending the LC4032V for that reason, but it gets the job done.

I use this at work and I don't have any problem, is it worse than Xilinx or Altera tools which are also very user un-friendly ?


Top
 Profile  
 
PostPosted: Tue Apr 10, 2018 1:35 am 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3569
Location: Indianapolis
Bregalad wrote:
Quote:
All that said, Lattice's lever classic isn't user friendly by any stretch so I have a hard time recommending the LC4032V for that reason, but it gets the job done.

I use this at work and I don't have any problem, is it worse than Xilinx or Altera tools which are also very user un-friendly ?


For me, sometimes it crashes immediately when I launch it. So I'll just re-launch it and it will be fine, minor annoyance but I haven't had a problem with it otherwise.


Top
 Profile  
 
PostPosted: Tue Apr 10, 2018 2:48 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 813
Speaking for the software side, such a board would need to include battery RAM for saving, as pretty art without save support wouldn't be much of use.


Top
 Profile  
 
PostPosted: Tue Apr 10, 2018 8:14 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 2095
Location: WhereverIparkIt, USA
My responses to these questions got rather wordy and started to further depart from the original post on 8x8 attrs so I've decided to answer these questions in a separate thread.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Tue Apr 10, 2018 9:52 am 
Offline
User avatar

Joined: Wed Sep 07, 2005 9:55 am
Posts: 328
Location: Phoenix, AZ
I added it to the FME7, but sorted cheated and used a block ram instead. Nice to see it in a more affordable package.

I'd have to double check, but I'm pretty sure I had to latch bits on the rising edge for the PowerPak.


Top
 Profile  
 
PostPosted: Tue Apr 10, 2018 3:14 pm 
Offline

Joined: Wed Mar 09, 2005 9:08 am
Posts: 418
infiniteneslives wrote:
My responses to these questions got rather wordy and started to further depart from the original post on 8x8 attrs so I've decided to answer these questions in a separate thread.


Haha, thanks for that. But it wouldn't be nesdev.com without the wildly offtopic tangents... ;)

Anyway, the questions I hoped to get some feedback on would be what various trade-offs people think are useful to get those mythical 8x8 attributes in a homebrew game...

So, open questions:
* Do you even feel 8x8 attributes are worth the extra hassle, with the inconvenient memory layout and all?
* Which of the possible configurations would be your favorite? Conventional H/V mirroring trading away CHR tiles? One-screen mirroring leaving CHR alone? Or variants on the 4-screen configuration?
* How many extra $ would you be willing to spend on board replication to have 8x8 attributes in your game, before it starts to bite?


Top
 Profile  
 
PostPosted: Tue Apr 10, 2018 3:28 pm 
Offline

Joined: Wed Mar 09, 2005 9:08 am
Posts: 418
never-obsolete wrote:
I added it to the FME7, but sorted cheated and used a block ram instead.


Not a cheat at all! Block RAM opens up a lot of more possibilities... one interesting mapper design I've thought of is encoding N variants of the 16 bits needed for 8x1 attributes into a lookup table in block RAM, and have the attribute index in the screen reference that instead, in much the same way as the tile index references the CHR. This would allow changing attributes on an 8x1 granularity but without having to manage a 2kB per screen attribute table.

(Not sure how realisable that is with the Powerpak I/O signals though...)


Top
 Profile  
 
PostPosted: Tue Apr 10, 2018 3:45 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7682
Location: Seattle
Bananmos wrote:
* Which of the possible configurations would be your favorite? Conventional H/V mirroring trading away CHR tiles? One-screen mirroring leaving CHR alone? Or variants on the 4-screen configuration?
My hunch is that once one has 8x8 attributes, 1-screen layout becomes awfully reasonable. You get the benefits of run-time switchable nametables (like GTROM or AxROM) without really having to worry about attribute clash regardless of scrolling axis.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Yahoo [Bot] and 5 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