GreenPAK mapper golf

[Myask]

And the LUTs are transposed from how the NES would find useful. (i.e. you can't just say "this byte specifies what CHR bank is present from $0000-$03FF"; instead you have to say "here's the value for CHR A10 for each of the eight CHR banks").

[…]

Next time: a fast I²C interface, hopefully. (I'm not done yet)

The transposition means that the important question is…how fast? Or do you not have to rewrite the whole table each go? (Obviously you have to rewrite at least one entry on each table, for a write to change bank N.)

So 2-4 of these can get you MMC3-class mappers, mm?

[lidnariq]

How fast?
The I²C interface poses an overhead of two bytes per different starting address you're writing to.
There are four 2LUTs, taking two adjacent bytes. Updating just that would take four I²C byte times.
The 3LUTs are in three separate blocks of size 5, 6, and 7... but assuming the 32KB CHR-RAM situation, that's seven I²C byte times.

The GreenPAK supports a 400kHz I²C bus, so that's a minimum of 5cy per bit time. The design that I think will work will let you sustain a bit every 6cy, so that should be 32 KiB VRC2 CHR update in 378cy ... or just about 3.5 scanlines.

Silego's been changing the price a bit, so it's hard to say what the actual cost would be. They provide really hefty volume discounts, but NES retrodev is anything but. They used to be selling the specific GP5 (SLG46533V) I'm using here for 65¢/@100, but right now they're 50¢/@100.

The calculus of using these programmable parts vs a CPLD is thus wibbly. An Altera MAX V (specifically 5M40ZE64C5N) and two linear voltage regulators (e.g. 2V and 4V) should cost about 90¢+2×19¢=$1.28 in qty 100 ... but might be too minimalist? I can't figure out what the size limits are on its LC RAMs, since "RAM with one read port and one write port" is basically all that a NES mapper is.

[Myask]

So raster-effect bankswitches aren't gonna be done that way, then.

[lidnariq]

I suppose the flip side to the "now you can have the GreenPAK automatically change banks at scanline N" is "now you have to to get CHR bankswitching raster effects"

[Myask]

Well, I always felt that Oeka-kids-style banking was underused…

But it sounds like you still have to do any serial reprogramming during blank, or suffer glitches. Depends how a LUT acts while it's being rewritten, I suppose.

Or you just end up having to graycode your banks so you're only switching one table's bits at any given scanline, if you can rewrite it while it's in use without it misbehaving…

[lidnariq]

Or you just end up having to graycode your banks so you're only switching one table's bits at any given scanline, if you can rewrite it while it's in use without it misbehaving…

The GP5 datasheet says that the contents of each byte are loaded into the LUTs at the start of the I²C ACK bit. So ... well, that's goofy, but maybe tenable.

[Myask]

wasn't sure if there was a shifter that then got latched to the LUT†; that makes things more likely to be doable that way.

†in retrospect, not sure how else it would have been done.

[FrankenGraphics]

Silego's been changing the price a bit, so it's hard to say what the actual cost would be. They provide really hefty volume discounts, but NES retrodev is anything but. They used to be selling the specific GP5 (SLG46533V) I'm using here for 65¢/@100, but right now they're 50¢/@100.

Just a thought experiment on that note:
I saw they go for 30 cents/unit if ordered pre-programmed at a staggering minimum of 3000 units. Having them pre-programmed rather than manually programming them one-by-one (even at a low quantity of 100) would be time saving. But with a minimum order like that, i can't see how any individual self-publisher could make the numbers work. I think they'd need to either be a group buy (with quite a number of group buyers) agreeing on a particular setup (like we sometimes do in the synth diy community), or be bought in by a pcb provider (retrostage or infinite nes lives comes to mind) to work with a pcb design (who provides it? open/closed?), again in precise communication with what retrodev publishers and the community may need and agree upon.

[Memblers]

Ah, I was hoping you'd talk about it's I²C. That's what I wondered about too when the GreePAK5 came out, but I haven't looked into how to bit-bang it, so I'm very curious to see how that would look on the NES hardware and software-wise. I thought it would involve reading back as well as writing (for full-blown I²C) , but maybe not? I like that mapper. Maybe you could also connect CPUA14 directly to flashROM's A18, and use those 4 mapper bits for a 32kB/512kB mode. 16kB/256kB mode would still work, I think.

One thing I noticed when the price changed on the GreenPAKs, seems that they stopped offering factory programming for quantities other than a full reel (3000 pieces). So using multiple parts in one design is a lot less attractive.. It's a tricky thing to balance anyways, it's easy to get I/O limited and you'd likely have to include the same signals on multiple parts, there are diminishing returns. I've toyed around with a GreenPAK+CPLD design and that's quite a pair. But using them together doesn't really help the I/O limit situation either.

Not having tested my mapper design is kinda driving me nuts, heheh. I have to rearrange my work area so I can get my PC, NES, and TV all together. I do know for sure though that I want to make a new mapper to follow up on my GTROM board, and it almost certainly will involve a GreenPAK. I don't mind buying a full reel of them, would take a while to use 3,000 but it's worth it. Though of course I'd start out with a decent hand-built batch first. GTROM was pretty much a drop-in replacement for UNROM that everyone already uses, a new one however could be fairly exotic.

[lidnariq]

Yeah, I think a write-only interface would be practical... although it would technically have to be able to handle the ACKs.

I'm having trouble figuring out how to get the FSM into the GreenPAK, but I'm reasonably confident it should be doable. So I'll just describe the programming interface I came up with, and maybe someone else will have an idea for implementation... The problem is that I need a variety of automated events scheduled 700 and 1400ns after M2 rise, but I haven't yet figured out how to "schedule" different possible actions. Maybe using one of the GP4 FSMs? But there might be more than eight total states...

This interface is only valid for working with devices that support the 400kHz timebase. Purely-100kHz devices require really slow high and low times (4.5µs/half bit or so).

Code: Select all

Mask: $F800
  Read: $6000 [D... ....]  read SDA
    - immediately floats SDA & SCL
    --- I /think/ this should work out, because SDA should float fast enough
        to get out of the way for the slave device to fail to assert SDA
    - buffers SDA onto CPU D7 during M2
    - 700ns later drive SCL low (must be >600ns per 400kHz I²C spec;
      must be >560ns to avoid DMC glitches)
    - reading a byte could be an unrolled loop of CPX $6000 / ROL A

  Write: $6000 - no effect (allow use of RMW instructions)

  Read: $6800 - no effect (allow use of RMW instructions)

  Write: $6800 [D... ....]  write SDA
    - immediately latch CPU D7, drive latch onto SDA, and drive SCL low (SCL should already be low)
    - 700ns later let SCL float (protect against RMW double writes)
    - 700ns later drive SCL low
    - (?? 700ns later let SDA float ??)
    - writing a byte could be an unrolled loop of STA $6800 / ROL A

  Access: $7000 - I²C start
    - immediately float SDA & SCL
    - 700ns later drive SDA low
    - 700ns later drive SCL low
    - (?? 700ns later let SDA float ??)

  Access: $7800 - I²C stop
    - immediately drive SDA & SCL low (SCL should already be low)
    - 700ns later float SCL
    - 700ns later float SDA

[Memblers]

I don't know if this helpful in this case or just a fun trick, but it should be possible to free up the cart memory area by mapping readable bits into PPU space at $2000-$3FFF. You only have to exclude $2004-$2007 (and its mirrors), and the data bits that $2002 uses.

[tepples]

I'm not sure how well that'd work, seeing as how the PPU has its own data latch that's connected to the main data bus when reading a nominally write-only register. (See "Riding the open bus".)

[lidnariq]

Haven't thought anymore about how to do the self timing, but randomly inspired by homebrew using the action 53 mapper, I present: an Action 53 subset for not multicarts.

Retains BNROM/ANROM/UNROM/m180 mode and mirroring control. Ran out of I/O for anything more.

a53subset.gp5.zip

(3.82 KiB) Downloaded 77 times

No bus conflict prevention, no CHR banking, no outer bank, no gap for PRG RAM (register is present at $7000-$7FFF also)