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:

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.

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.

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

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.

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

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?

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...)

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.

Who is online

Users browsing this forum: No registered users and 4 guests

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