Mapper 30, but with more PRG ROM?

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

Post Reply
User avatar
poorstudenthobbyist
Posts: 233
Joined: Fri Jun 24, 2016 4:20 pm

Mapper 30, but with more PRG ROM?

Post by poorstudenthobbyist » Sat Feb 13, 2021 8:54 pm

I'm helping someone out with a game they're making, and they'd like to have a board with more ROM space on it than Mapper 30's 512KB. Has anyone done a modification to Mapper 30 to expand the space available? They need to keep the same amount of CHR available as well as the dynamic mirroring control.

A very simple (maybe stupid) method that I thought of was using a 74'161 to cycle between more 512KB banks, that has its clock triggered by the original PRG_A18 output (CPU_A14 ORed with D4). The Q1 and Q2 outputs go to a 74'139 decoder, to cycle between the four Y outputs of the '139, that go to the /CE pins on the four ROMs (eventually replacing this with a single ROM chip, but for now separate 39SF040 flash chips).

This makes it a bit clunky to cycle between ROM chips, but the person I'm working with says so far it doesn't seem like it'd be an issue.

Having not much experience in NES programming, are there any other hidden issues this architecture could pose? (Or any cardinal sins I'm committing?)
Attachments
mapper30_extra.PNG
Check out my website for NES, SNES, and Genesis tutorials here. And visit my store for some custom tools and boards for making games here.

You can also follow me on Twitter for infrequent updates and bad jokes!

lidnariq
Posts: 10463
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Mapper 30, but with more PRG ROM?

Post by lidnariq » Sat Feb 13, 2021 10:00 pm

poorstudenthobbyist wrote:
Sat Feb 13, 2021 8:54 pm
I'm helping someone out with a game they're making, and they'd like to have a board with more ROM space on it than Mapper 30's 512KB.
The 512KB design limit ultimately comes from the price increase from the 512KB SST39SF040 to larger ROMs. Micron had discontinued their M29F parts about six years ago, and only Macronix provided 1MB 5V NOR flash and that at a mediocre price. So larger ROMs required 3V translation and that added enough cost that it just didn't make sense to stick with a discrete logic design. (Once you have need 3V regulator and translation you should use both cheaper 3V flash and 3V programmable logic)

Recently, Alliance has done a special buy of Micron 5V flash - I assume they had to agree to a very large number of each SKU - and are currently (re)selling 1MB 5V NOR flash for an ok price ($1.90/@102; compare Macronix 1MB $2.38/@100 or SST 512KB $1.46/@100)
Has anyone done a modification to Mapper 30 to expand the space available?
Not that I know of.
They need to keep the same amount of CHR available as well as the dynamic mirroring control.
The cost of the discrete logic here is already pretty firmly at the upper bound of what's economically a good choice; it'd be better to design something with similar capability but a different ABI. Especially since all 8 bits of a byte are already spoken for here, so you'd have to add at the very least an extra latch, and possibly also an extra OR gate if compatibility with INL's 4sc configuration is desired.
Having not much experience in NES programming, are there any other hidden issues this architecture could pose? (Or any cardinal sins I'm committing?)
Design something on the spectrum between "programmer's ease" and "lowest BOM cost". But don't bodge in something vaguely upwards compatible: it's ugly, increases the cost, and isn't easier to program.

User avatar
poorstudenthobbyist
Posts: 233
Joined: Fri Jun 24, 2016 4:20 pm

Re: Mapper 30, but with more PRG ROM?

Post by poorstudenthobbyist » Sat Feb 13, 2021 11:59 pm

lidnariq wrote:
Sat Feb 13, 2021 10:00 pm
The 512KB design limit ultimately comes from the price increase from the 512KB SST39SF040 to larger ROMs. Micron had discontinued their M29F parts about six years ago, and only Macronix provided 1MB 5V NOR flash and that at a mediocre price. So larger ROMs required 3V translation and that added enough cost to a discrete logic mapper that it just didn't make sense to stick with a discrete logic design. (Once you have a 3V regulator and translation you should use cheaper 3V flash and 3V programmable logic)

Recently, Alliance has done a special buy of Micron 5V flash - I assume they had to agree a very large number of each SKU - and are currently (re)selling 1MB 5V NOR flash for an ok price ($1.90/@102; compare Macronix 1MB $2.38/@100 or SST 512KB $1.46/@100)
The SF040s was just for ease of programming for development, I was thinking about going to fewer chips later on - removing the need for the '139 and just connecting the '161 outputs to the ROM instead. But thanks for that information. I suppose the market for 5V parallel memory isn't too big hah.
The cost of the discrete logic here is already pretty firmly at the upper bound of what's economically a good choice; it'd be better to design something with similar capability but a different ABI. Especially since all 8 bits of a byte are already spoken for here, so you'd have to add at the very least an extra latch, and possibly also an extra OR gate if compatibility with INL's 4sc configuration is desired.
I don't know the scale of the project, or what their exact plans are, but I suppose it should be a conversation. I don't know how important INL compatibility is.

The problem I'm running into is figuring out how control more addresses without interdependent signals. Which is why I added the '161, serially controlled by the previous PRG_A18 line. It'd be cool if there was another line available for the '139 controlling the PRG /OE, to connect to the B data input there, to flip between a lower 512KB and upper 512KB bank using the Y1 and Y3 outputs instead of just the Y1.

Is it possible to do something similar to the existing strategy, just with the CHR data pins? Or perhaps ORing A13 and three data pins out of another flip flop? There are three unused OR gates, so if feasible this would really only include adding another '377 (or two '74s, if somehow cheaper) to quadruple the ROM space (one for PRG A13, then the other two for A19 and A20).
Design something on the spectrum between "programmer's ease" and "lowest BOM cost". But don't bodge in something vaguely upwards compatible: it's ugly, increases the cost, and isn't easier to program.
Definitely! I knew this wasn't the best solution, but I was having trouble envisioning something else.
Check out my website for NES, SNES, and Genesis tutorials here. And visit my store for some custom tools and boards for making games here.

You can also follow me on Twitter for infrequent updates and bad jokes!

calima
Posts: 1335
Joined: Tue Oct 06, 2015 10:16 am

Re: Mapper 30, but with more PRG ROM?

Post by calima » Sun Feb 14, 2021 12:41 am

If they're using mapper 30, it means nesmaker, which means they aren't going to be manually programming and expect it to be nesmaker compatible.

lidnariq
Posts: 10463
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Mapper 30, but with more PRG ROM?

Post by lidnariq » Sun Feb 14, 2021 1:08 am

poorstudenthobbyist wrote:
Sat Feb 13, 2021 11:59 pm
The SF040s was just for ease of programming for development, I was thinking about going to fewer chips later on - removing the need for the '139 and just connecting the '161 outputs to the ROM instead. But thanks for that information. I suppose the market for 5V parallel memory isn't too big hah.
Yeah, it started pining for the fjords about the same time that cheap ARM SOCs took over the world.
The problem I'm running into is figuring out how control more addresses without interdependent signals. Which is why I added the '161, serially controlled by the previous PRG_A18 line. It'd be cool if there was another line available for the '139 controlling the PRG /OE, to connect to the B data input there, to flip between a lower 512KB and upper 512KB bank using the Y1 and Y3 outputs instead of just the Y1.
By far the simplest option to describe, for use in a flashing-enabled board that doesn't need a bus conflict prevention table, is to use some of the address lines as part of the bankswitching register. You can use all of A0-A13 with the existing definition.

One other huge gotcha is that parts made by manufacturers other than SST don't have the 4K erase sectors, so it's incompatible in a bunch of different subtle ways. Micron's parts mostly use 64K erase sectors (albeit plus one 32K and one 16K and two 8K sectors).
Definitely! I knew this wasn't the best solution, but I was having trouble envisioning something else.
Quickly thinking through options...

I'd seriously consider some kind of programmable logic such as a GreenPak, a LC4032, an ATF1502, or maybe a 16V8. Programmable logic really is the right choice as you try to go past four 74xx parts, and of those I mentioned, only the LC4032 needs an extra voltage regulator.

By moving the bankswitching register out from overlapping with flash, you don't need to generate the modified /FLASHWE signal. And as zzo38 likes to point out, you don't need to avoid colliding with the mirrors of PPU and NES-internal RAM, so you only need /ROMSEL, re-shaped-M2, and one of A11 or A12).

Switching to 32K PRG bankswitching might be a harder sell, but it also solves the complexity nicely, because then you don't need the two 74'32s and can reallocate one of them for more (albeit now unneeded) latches.

User avatar
poorstudenthobbyist
Posts: 233
Joined: Fri Jun 24, 2016 4:20 pm

Re: Mapper 30, but with more PRG ROM?

Post by poorstudenthobbyist » Sun Feb 14, 2021 11:22 am

calima wrote:
Sun Feb 14, 2021 12:41 am
If they're using mapper 30, it means nesmaker, which means they aren't going to be manually programming and expect it to be nesmaker compatible.
Nah he's not using NES Maker. You can still make a Mapper 30 compatible game without it, though I'm not sure how exactly he's going about making the game.
lidnariq wrote:
Sun Feb 14, 2021 1:08 am
One other huge gotcha is that parts made by manufacturers other than SST don't have the 4K erase sectors, so it's incompatible in a bunch of different subtle ways. Micron's parts mostly use 64K erase sectors (albeit plus one 32K and one 16K and two 8K sectors).
I should clarify, that at least for right now, he's interested in getting the game on a board. He says he's fine with just programming the chips individually and then putting them on-board. He was using Mapper 30 as a base to start off, but the project became larger than it could handle natively, and (after talking with him today) he's not concerned about INL or NES Maker compatibility, at least for now. I just wanted to get some opinions about the mechanisms/possible pitfalls of mapper design, as I have not designed one myself before hah.
Quickly thinking through options...

I'd seriously consider some kind of programmable logic such as a GreenPak, a LC4032, an ATF1502, or maybe a 16V8. Programmable logic really is the right choice as you try to go past four 74xx parts, and of those I mentioned, only the LC4032 needs an extra voltage regulator.

By moving the bankswitching register out from overlapping with flash, you don't need to generate the modified /FLASHWE signal. And as zzo38 likes to point out, you don't need to avoid colliding with the mirrors of PPU and NES-internal RAM, so you only need /ROMSEL, re-shaped-M2, and one of A11 or A12).
I'll look into these logic chips, thanks. I knew they existed, but never really considered them before. I can always replace all of the 74 logic parts with one of these in the future, as I have no experience with them right now haha.
By far the simplest option to describe, for use in a flashing-enabled board that doesn't need a bus conflict prevention table, is to use some of the address lines as part of the bankswitching register. You can use all of A0-A13 with the existing definition.
Ok, so ignoring the flashability of the board, would using the A13 line as well for bankswitching smaller banks be a viable option? Something like this?
mapper30_extra2.PNG
Check out my website for NES, SNES, and Genesis tutorials here. And visit my store for some custom tools and boards for making games here.

You can also follow me on Twitter for infrequent updates and bad jokes!

lidnariq
Posts: 10463
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Mapper 30, but with more PRG ROM?

Post by lidnariq » Sun Feb 14, 2021 12:28 pm

poorstudenthobbyist wrote:
Sun Feb 14, 2021 11:22 am
Ok, so ignoring the flashability of the board, would using the A13 line as well for bankswitching smaller banks be a viable option? Something like this?
[Two latches, one latching D0-D7, the other latching D0-D2 ("OR8-OR10"), both using the same clock enable and clock inputs
Eight OR gates, five making UNROM, the other three ORing OR8-OR10 with CPU A13 before going to the ROM]
Uh.... no, you basically can't get anything better than UNROM style banking without starting using a lot of external parts. There's two problems with what you've suggested:

1- You're latching the same signals at the same time, so OR8-OR10 can never not contain the same data as OR0-OR2. You have to use different inputs to the latch, or different clock enables at the latch, or use different clocks at the latch.
What I meant was "latch A0-A1 at the same time you latch D0-D7", but this can only possibly work if you don't need to use A0-A1 to access the bus conflict prevention table, which requires a board that is at least partially flash enabled (i.e. the ROM won't enable its data bus drivers when the CPU tries to write to the bankswitching register).

Alternatively, you could latch some of A8-A13, but then the programmer will need to have a bus conflict prevention table in every location that they ever want to write to to cause a bank switch.

Alternatively alternatively, you could remove the latches on D0-D7 and only latch A0-A13. The address bus has no bus conflicts, but you still want to make sure that you write the same value back that's stored in that address. (i.e. lda (zp),y then sta (zp),y)

2- The OR gates connecting to CPU_A13, even if their inputs weren't correlated, won't generate the banks you want. Quickly illustrating:
If OR8 is 1, then PRG_A13 is always high. If PRG_A13 is always high, then the 8KB banks would be two of the same, followed by a different two identical ones.

Other worked examples:
if the latches held 0 and 0, the banks would be [00 C1 1E FF]
if the latches held 0 and 1, the banks would be [01 C1 1F FF]
if the latches held 0 and 2, the banks would be [40 C1 5F FF]
if the latches held 0 and 7, the banks would be [C1 C1 FF FF]
if the latches held 1 and 0, the banks would be [02 C3 1E FF]

You really have to use an external multiplexer of some sort (e.g. 74'153 or 74'157) and then you quickly allocate so many parts that it doesn't make sense price-wise. Back in the day when the cost of programmable logic was higher, pirates often used 74LS670s to implement NES banking, but they're comparatively very expensive now.

User avatar
poorstudenthobbyist
Posts: 233
Joined: Fri Jun 24, 2016 4:20 pm

Re: Mapper 30, but with more PRG ROM?

Post by poorstudenthobbyist » Sun Feb 14, 2021 12:54 pm

Yeah after I posted that and started thinking more about it, I realized the issue with using D0-D2 like that. I don't think the bus conflict prevention is a great way to go about this. And adding multiplexers is equally clunky. And thank you for the insight.

I don't think the goal is to create a new backwards-compatible mapper type to replace/enhance Mapper 30 completely, but rather a UNROM-based board that meets his needs. I just wanted to make sure there aren't any hidden pitfalls that I'm going to find along the way, or if there was an existing method that might fit his needs already.

He seems fine with going forward with the original '161 idea, at least for now. He doesn't seem concerned with the programmatic complexity in that regard. Going forward, I can look into those programmable logic chips to cut down on the part count. This shouldn't really pose any problems, other than introducing extra cost and some complexity in paging between upper banks of data, right?
Check out my website for NES, SNES, and Genesis tutorials here. And visit my store for some custom tools and boards for making games here.

You can also follow me on Twitter for infrequent updates and bad jokes!

lidnariq
Posts: 10463
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Mapper 30, but with more PRG ROM?

Post by lidnariq » Sun Feb 14, 2021 1:33 pm

poorstudenthobbyist wrote:
Sun Feb 14, 2021 12:54 pm
I don't think the goal is to create a new backwards-compatible mapper type to replace/enhance Mapper 30 completely, but rather a UNROM-based board that meets his needs. I just wanted to make sure there aren't any hidden pitfalls that I'm going to find along the way, or if there was an existing method that might fit his needs already.
Fair enough.

I'd probably personally go for the "use the address bus" version of the design, but it's up to you.
[graduating this design to programmable logic] shouldn't really pose any problems, other than introducing extra cost and some complexity in paging between upper banks of data, right?
Yeah. The smaller cheaper CPLDs have many more I/O than total amount of state, so designs with hidden state (such as MMC3 and FME-7) waste resources, compared to just using more address lines to disambiguate various functions.

User avatar
poorstudenthobbyist
Posts: 233
Joined: Fri Jun 24, 2016 4:20 pm

Re: Mapper 30, but with more PRG ROM?

Post by poorstudenthobbyist » Sun Feb 14, 2021 5:38 pm

Thanks as always for the insight. Definitely gonna look into those CPLDs at some point, when time allows
Check out my website for NES, SNES, and Genesis tutorials here. And visit my store for some custom tools and boards for making games here.

You can also follow me on Twitter for infrequent updates and bad jokes!

Joe
Posts: 460
Joined: Mon Apr 01, 2013 11:17 pm

Re: Mapper 30, but with more PRG ROM?

Post by Joe » Sun Feb 14, 2021 7:53 pm

lidnariq wrote:
Sun Feb 14, 2021 1:08 am
maybe a 16V8.
Would it make sense to use a 16V8 mostly to drive chip selects and have one or two latches hold the mapper's state? Would it make sense to drive the ROM's upper address lines with a tristate-output latch and pull-up resistors to make the fixed bank?

From what I've seen, you can get a 16V8 for pretty close to the price of common 74-series logic, so even if you need two more chips to hold the mapper state and another to decode the ROM select you might be able to keep it within a reasonable budget.

User avatar
poorstudenthobbyist
Posts: 233
Joined: Fri Jun 24, 2016 4:20 pm

Re: Mapper 30, but with more PRG ROM?

Post by poorstudenthobbyist » Sun Feb 14, 2021 8:11 pm

lidnariq wrote:
Sun Feb 14, 2021 1:33 pm
I'd probably personally go for the "use the address bus" version of the design, but it's up to you.
Like this?
Theoretical 8MB PRG with 128KB CHR (use a 1008 series SRAM)
(This would also require another set of OR gates, but you could exclude A11-A13 for smaller space)
mapper30_extra3.PNG
Check out my website for NES, SNES, and Genesis tutorials here. And visit my store for some custom tools and boards for making games here.

You can also follow me on Twitter for infrequent updates and bad jokes!

lidnariq
Posts: 10463
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Mapper 30, but with more PRG ROM?

Post by lidnariq » Sun Feb 14, 2021 8:42 pm

Joe wrote:
Sun Feb 14, 2021 7:53 pm
Would it make sense to use a 16V8 mostly to drive chip selects and have one or two latches hold the mapper's state? Would it make sense to drive the ROM's upper address lines with a tristate-output latch and pull-up resistors to make the fixed bank?
Hm. The 16V8 only has 8 outputs, and those 8 outputs can't contain buried (hidden) state, so... for this situation I'd probably use two 6- or 8- bit latches (depending on what's cheaper) and use the 16V8 to implement the OR gates. If so, we need 6 outputs for the OR gates, 1 can be the latch clock, and ... hm. I don't like that.

Maybe a better plan is to borrow a page from Family Noraebang and have one latch and one external SIP resistor array to implement the UNROM-style banking. The 16V8 can then absorb the functionality of the 74'139 and the new latch.
From what I've seen, you can get a 16V8 for pretty close to the price of common 74-series logic, so even if you need two more chips to hold the mapper state and another to decode the ROM select you might be able to keep it within a reasonable budget.
Yeah, the only problems with 16V8s are power budget. They range from "thirsty" (45mA continuous) to "really thirsty" (130mA).

Also, I don't think any more are being made, but Rochester Electronics has a enormous pile of NOS ones (>500k) so I don't think that's really a concern.
poorstudenthobbyist wrote:
Sun Feb 14, 2021 8:11 pm
Like this?
[two 8-bit latches latching CPU A0-A13 on writes to CPU $8000-$FFFF
outputs feeding PRG A14-A22 and CHR A13-A16]
Yeah, that could work. I'd personally put the bank bits adjacent: it makes the programming a little cleaner.

I think I'd be tempted to avoid the 9th PRG bank bit just to avoid needing another OR gate.... well, that and low availability of 5V flash bigger than 2MB.

User avatar
poorstudenthobbyist
Posts: 233
Joined: Fri Jun 24, 2016 4:20 pm

Re: Mapper 30, but with more PRG ROM?

Post by poorstudenthobbyist » Sun Feb 14, 2021 8:52 pm

lidnariq wrote:
Sun Feb 14, 2021 8:42 pm
Yeah, that could work. I'd personally put the bank bits adjacent: it makes the programming a little cleaner.

I think I'd be tempted to avoid the 9th PRG bank bit just to avoid needing another OR gate.... well, that and low availability of 5V flash bigger than 2MB.
Yeah, just a quick sketch, it'd probably be neater to have one '377 for PRG and one for CHR. I'll pose this to the programmer, see if he likes it better. It does seem cleaner. I didn't even think of using the addresses instead of the data pins.
Check out my website for NES, SNES, and Genesis tutorials here. And visit my store for some custom tools and boards for making games here.

You can also follow me on Twitter for infrequent updates and bad jokes!

Joe
Posts: 460
Joined: Mon Apr 01, 2013 11:17 pm

Re: Mapper 30, but with more PRG ROM?

Post by Joe » Sun Feb 14, 2021 11:56 pm

lidnariq wrote:
Sun Feb 14, 2021 8:42 pm
Maybe a better plan is to borrow a page from Family Noraebang and have one latch and one external SIP resistor array to implement the UNROM-style banking.
Huh! Yeah, that's exactly what I was trying to describe. You'd need a separate latch for CHR banking and mirroring control and whatever else since the PRG bank latch would go high-impedance while executing out of the fixed bank.

If you can find a big enough 5V chip for the PRG-ROM, you can spare some logic to prevent bus conflicts.
lidnariq wrote:
Sun Feb 14, 2021 8:42 pm
Yeah, the only problems with 16V8s are power budget. They range from "thirsty" (45mA continuous) to "really thirsty" (130mA).

Also, I don't think any more are being made, but Rochester Electronics has a enormous pile of NOS ones (>500k) so I don't think that's really a concern.
Microchip (Atmel) says their ATF16V8BQL is still in production, and they claim 40mA at maximum. It's a bit more expensive, but maybe still reasonable?

Post Reply