House of Truth ROM and minimapper

A place where you can keep others updated about your NES-related projects through screenshots, videos or information in general.

Moderator: Moderators

User avatar
jekuthiel
Posts: 10
Joined: Fri Nov 13, 2020 9:47 am

Re: House of Truth ROM and minimapper

Post by jekuthiel »

pubby wrote: Thu Feb 10, 2022 12:25 pmI'm confused by this. Most homebrew fans don't care about the underlying chip hardware
Quite right.
nor do they care about what arbitrary restrictions you've set.
They aren't arbitrary.
What are you gaining by not using a co-processor at this point?
Legitimacy and honor. It's dishonorable to me to put a computer inside of or attached to another computer and call it a video game running on the host computer. No one who has any idea what's going on thinks that a Game Boy game playing via the Super Game Boy is an "SNES" game, and that's even weaker of a case because the ~LR35902 CPU in the Super Game Boy is nowhere near as powerful as the SNES's 5A22 CPU.

Also, it would greatly increase the complexity of both the hardware engineering and the software engineering to have to deal with two different CPUs whose interface is something semi-custom and limited by whatever bus shenanigans we could dream up. The reason that something like the Super FX was invented is that it was fundamentally more capable of generating 3D graphics than the SNES by itself was, and the economics of the day justified it.

What we're doing is, at its core, memory mapping. It is not fundamentally different than what MMC1, MMC2, MMC3, MMC5, FME-7, and the other classical memory mappers did. We don't want to do more than what they did. We just want to do it better with the benefit of hindsight and all the wonderful modern tooling and documentation that is now available.
There's lots of justification, but I'm wondering who it's targeted at.
This is a reasonable question. It's targeted both at semi-technical people that are curious about what the memory mapper development part of the project is about, and at the fully technical people who might be willing to entertain the reasoning that led us to where we are.
Non-technical people will love the game regardless
Hopefully!
and hardware people can see it as a really cool accomplishment
Hopefully! However, the bulk of the work on this project is on the software engineering side, not the hardware engineering side. We've had to invent a lot of novel things in code in order to make this elaborate of a game possible on the NES. No amount of hardware support could've helped us grapple with the incredibly limited and obtuse sprite subsystem of the 2C02, for instance.
but I don't think you'll convince programmers - there'll always be an asterisk around the project with them.
Well, that's unfortunate. But I think if asterisks are being laid down in such a gatekeeping fashion, they should also put around The Legend of Zelda, Metroid, Super Mario Bros. 3, and basically every other good game in the NES game library as well.

I cannot hammer home enough that MXM-0's circuit complexity has been kept at or below MMC5's for the entire project, and it's going to stay that way. This is a very real constraint and it's almost entirely the ultimate justification that is needed for the prevention of those asterisks you speak of.

-jekuthiel
User avatar
jekuthiel
Posts: 10
Joined: Fri Nov 13, 2020 9:47 am

Re: House of Truth ROM and minimapper

Post by jekuthiel »

aquasnake wrote: Sat Feb 19, 2022 6:26 amI am very interested in this MXM mapper project, and I am also engaged in the same hardware design work. I guess your extended attribute mode is based on mmc5,and is enhanced to 8x1
In principle, yes. In implementation, no. The timing method is quite different but the fundamental mechanism is similar.
Theoretically, this will require an additional 8K cxram as attribute table, but I guess the real hardware will occupy 128KiB
Our 8x1 attributes require 1,920 bytes per nametable, although our current implementation is more wasteful than that. We'll probably clean it up sometime between now and Production.
I designed 8x2 mode before, but the problem is that the color is quite satisfying even under 8x8 attributes.
Well, this is a statement of taste / aesthetics. The artists on the Former Dawn project have, to me, proven beyond a shadow of a doubt that 8x1 attributes are just as superior to 8x8 attributes as you'd expect -- 8 times better. We've produced images that are simply impossible without that 8X increase in color density. But it all comes down to what you're willing to do on a project. If you're not willing to spend money and time on the specialized labor required to get beautiful artwork out of the 8x1 attributes, then there is no point in having them. The same thing is true for any technical enhancement that a memory mapper provides. (Extra ROM space comes to mind as a general example.)
The enhancement of attribute table requires a high increase in hardware cost.
Whether or not that's true depends on your starting point. It wasn't for us because we were already committing to a "high" hardware cost by going with INL's new board/cartridge base design. If you're comparing something humble like mapper 30 to something advanced like INLDP-ROM, yes. But comparisons within a chosen cartridge type are what make more sense to me.
It feels like another Paprium to release such a homebrew game with a hardware carrier equivalent to everdrive N8 level
But it isn't. I won't give specific numbers, but the marginal production cost of 1 of our cartridges will be a small fraction of the retail cost of an EverDrive N8 Pro.
To achieve the extended addressing of 768m PROM + 1m CROM at the same time, and support ext_attr mode, the pin fan-out of CPLD/FPGA has exceeded 100, and the closest choice is the chip with 144 pins. The upper cost limit is N8, and the reasonable and competitive price should be set below 1/2 N8
Agreed, and it is indeed below that.
(cracking this mapper and updating FPGA firmware will appear at a certain time). This will pose a great challenge to hardware design, whether it is self-development or outsourcing customization.
Indeed. And it's something we were willing to do.

Everyone else in the community will be welcome to benefit from the fruits of our labor once we release everything under permissive open-source licenses. We have no intention of hoarding this all to ourselves, despite the many attempts from various people to persuade us to do so.

-jekuthiel
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: House of Truth ROM and minimapper

Post by calima »

jekuthiel wrote: Wed Feb 23, 2022 3:18 pm Can you explain, even in rough terms, what constitutes "going too far" in your view?
Any kind of large hw expansion that would not be needed on another platform. At that point it's forcing a round peg to a square hole for very little practical reason.
Also, you should be aware of the fact that the people in the SNESdev Discord server told me that general 8x1 attributes on the SNES are impossible.
I have experience on various platforms. 8x1 attrs are not needed, most art will fit with only minor edits. You'll have 12+bg colors worst case, that's plenty to fit into the 8 15+bg SNES palettes.
I cannot hammer home enough that MXM-0's circuit complexity has been kept at or below MMC5's for the entire project, and it's going to stay that way. This is a very real constraint and it's almost entirely the ultimate justification that is needed for the prevention of those asterisks you speak of.
The MMC5 is also pointless, for the exact same reason that any project targeting it would be better targeted at the SNES. MMC5 was (is) too late, too expensive, *and* harder to program than SNES.
User avatar
pubby
Posts: 583
Joined: Thu Mar 31, 2016 11:15 am

Re: House of Truth ROM and minimapper

Post by pubby »

But I think if asterisks are being laid down in such a gatekeeping fashion, they should also put around The Legend of Zelda, Metroid, Super Mario Bros. 3, and basically every other good game in the NES game library as well.
I figured you were the one putting the asterisks down, as the article is about what constitutes a legitimate NES game or not. I know you're trying to define what your game is, but your argument also implies what other games aren't. For example, it's asserting that your game is more "NES" than Super Russian Roulette. I don't like that.

There's a very obvious set of mappers made of 80s / 90s technology: all the ones used in licensed games. Anything beyond that is subjective. As you said yourself, you have the benefit of hindsight, modern tooling, and modern documentation. I'm sure can openers could have been invented with the can, yet it took almost a century to create them.

To be clear, this game looks sweet and I'm very supportive of all other aspects, but I don't agree with your categorization. I would rather see it marketed as a cool NES game that's pushing limits, rather than hearing you talk about how what you're doing is legitimate.
User avatar
gauauu
Posts: 779
Joined: Sat Jan 09, 2016 9:21 pm
Location: Central Illinois, USA
Contact:

Re: House of Truth ROM and minimapper

Post by gauauu »

jekuthiel wrote: Wed Feb 23, 2022 3:48 pm They aren't arbitrary.
They feel quite arbitrary to me. I'm a big supporter of people making whatever they want to make. And on the flip side, people can be uninterested in whatever games or tech they want to be uninterested in, and we all have to be ok with that.

But your rules about what's acceptable in your mapper and what isn't do feel quite arbitrary. You don't allow co-processors (which were introduced all the way back in the Atari 2600 with David Crane's DPC chip for Pitfall 2), but you do allow a huge amount of ROM, using an imaginary CD-ROM peripheral that didn't exist as justification. That's fine, you explained why you made that choice, I fully believe that you should use whatever limitations and technology you want. But even after reading your explanation, the criteria of "CD-ROM quantity of data is ok but a co-processor isn't" comes across as completely arbitrary.

Now arbitrary choices aren't necessarily bad; we all make arbitrary choices about what we're doing or what tech we're interested in using. I respect that you chose a line and are sticking with it. But I think it's a losing battle if you want to convince anyone that your criteria are objectively more legitimate than other potential criteria.
User avatar
jekuthiel
Posts: 10
Joined: Fri Nov 13, 2020 9:47 am

Re: House of Truth ROM and minimapper

Post by jekuthiel »

calima wrote: Thu Feb 24, 2022 2:11 amAny kind of large hw expansion that would not be needed on another platform. At that point it's forcing a round peg to a square hole for very little practical reason.
The word "large" is hazy to me. Is Kirby's Adventure "large" at 19 times the ROM size of Super Mario Bros.? That's MMC3, not MMC5, and MMC3 games form a large chunk of the classical NES game library. I assume you're not going to attempt to exclude MMC3 from consideration.
I have experience on various platforms. 8x1 attrs are not needed, most art will fit with only minor edits. You'll have 12+bg colors worst case, that's plenty to fit into the 8 15+bg SNES palettes.
No, the worst case is actually more than that because of our color enhancement techniques (which don't require mapper support). If it weren't for that, you'd be quite right that we could easily put the graphics (outside of FMV) for the game on the SNES instead. But I don't understand the push to do that. We want to make an NES game, not an SNES game, and you seem to be trying to tell us we shouldn't want to do that.

The same sentiment could be expressed about any of the graphical tricks that companies employed on the NES. Raster effects? They're all easier on the SNES because of HDMA, which the NES lacks. "Big" ROM size? Always easier on the SNES because of the increased address space of the 65816; every classical NES game could've just been dropped onto the SNES with no mapper at all. Audio expansions? Pretty much all of them can be beaten easily by the SPC700. Parallax scrolling? It's always "fake" on the NES because there's no hardware support for it, and looks terrible compared to what the very first games on the SNES easily accomplished. How about sprite limitations? Obviously any NES game that tried to use more than 8 sprites on a scanline (which was almost every game you'd care to play) should've been made for the SNES because any NES game, designed as it was, could've been dropped on the SNES with no sprite flicker given its extra OAM. Need I go on?

The SNES is clearly a better machine than the NES in almost every way. So why keep nesdev.com alive? Why isn't the entire site just archived and people pointed to the SNES instead?
The MMC5 is also pointless, for the exact same reason that any project targeting it would be better targeted at the SNES. MMC5 was (is) too late, too expensive, *and* harder to program than SNES.
MMC5 came out halfway through the NES's lifetime for the North American market, so "too late" seems a little hard to argue. "Too expensive" is easier to argue, but ultimately doesn't make sense to me since there were many commercially successful MMC5 games in Japan and Castlevania III was one of the best games for the NES. It sold about 850,000 copies. Was it "too expensive"?

It is very clear that design-wise, MMC5 is bloated and hard to use. So no disagreement there. That's why we're making MXM-0 comparatively simple and easy to use.
User avatar
jekuthiel
Posts: 10
Joined: Fri Nov 13, 2020 9:47 am

Re: House of Truth ROM and minimapper

Post by jekuthiel »

pubby wrote: Fri Feb 25, 2022 1:19 amI figured you were the one putting the asterisks down, as the article is about what constitutes a legitimate NES game or not. I know you're trying to define what your game is, but your argument also implies what other games aren't. For example, it's asserting that your game is more "NES" than Super Russian Roulette. I don't like that.
What in the world led you to that conclusion?? There is nothing about Super Russian Roulette or mapper 413 (the one it uses) that makes it "less NES" than Former Dawn or MXM-0.

There is no existing NES game or memory mapper for the NES that I eschew as "not NES". I even include NESmaker games as "real NES games", as much as I dislike NESmaker.

So no, there's no gatekeeping from my end in any practical terms. My blog post was intended to explain the theoretical boundaries and explain why we reached the design that we did...not cast aspersions on anyone else's NES game development.
There's a very obvious set of mappers made of 80s / 90s technology: all the ones used in licensed games. Anything beyond that is subjective. As you said yourself, you have the benefit of hindsight, modern tooling, and modern documentation. I'm sure can openers could have been invented with the can, yet it took almost a century to create them.
I do not agree that "anything beyond that is subjective". It's not subjective that 8x1 attributes could've been accomplished with a discrete logic mapper in the late 80s. It's objective, and we could construct such a thing with off-the-shelf parts if we felt like pausing Former Dawn development in order to earn petty Internet points.

Your analogy to the can and can opener is very interesting -- so would you apply the same reasoning to the contents of those cans? I view Micro Mages as very anachronistic in terms of its game design and aesthetic choices. There's no way that a game like that could've come out in 1983 just because the console hardware was available to play it. They employed tons of lessons learned over the decades in order to construct its memory layout. The game mechanics, enemy types, boss fights, etc were all informed by games that came out far later than 1983.

But none of that has to do with a memory mapper, since they didn't use one. Therefore, Morphcat seems to get a pass from everyone in the nesdev community, which I find very interesting and inconsistent with the general philosophy that is almost universally espoused about cartridge hardware.
To be clear, this game looks sweet and I'm very supportive of all other aspects, but I don't agree with your categorization. I would rather see it marketed as a cool NES game that's pushing limits, rather than hearing you talk about how what you're doing is legitimate.
Thank you!

Well, believe me, I have no intention of breathing a word about legitimacy in any of our marketing materials or crowdfunding campaign(s). The blog post I wrote was for technical or semi-technical people who are curious. It's definitely not something that has any value in getting the game in front of more eyeballs, let alone generating sales.

Honestly, I've been tempted for a long time to market the game as just another indie game for the PC and then casually mention that it's also available for the NES on a physical cartridge. I feel like emphasizing the platform too much is a bad idea because it might limit the potential market.
User avatar
jekuthiel
Posts: 10
Joined: Fri Nov 13, 2020 9:47 am

Re: House of Truth ROM and minimapper

Post by jekuthiel »

gauauu wrote: Fri Feb 25, 2022 10:32 amThey feel quite arbitrary to me.
That's unfortunate, because it means that I failed to accomplish what I wanted to accomplish in that blog post. But I doubt there's anything more I could do to succeed at this point.
I'm a big supporter of people making whatever they want to make. And on the flip side, people can be uninterested in whatever games or tech they want to be uninterested in, and we all have to be ok with that.
I agree, mostly. The "mostly" comes down to the fact that it's impossible to imagine someone convincing me that running a raspberry pi inside an NES cartridge is anything other than a fun tech project that was called a joke by the guy who came up with the idea.
But your rules about what's acceptable in your mapper and what isn't do feel quite arbitrary. You don't allow co-processors (which were introduced all the way back in the Atari 2600 with David Crane's DPC chip for Pitfall 2)
Actually, I didn't really say that we don't allow co-processors on the cartridge. It is quite arguable that every memory mapper for the NES (or any console, for that matter) is technically, properly classed as a "co-processor". I'm not pretending that MXM-0/1 is any different.

What I wrote and tried to make clear is that we're not allowing general purpose co-processors. Basically, no CPUs or GPUs. I admit that my phrasing might need improving, but that has always been the sentiment I've tried to express. I've looked into David Crane's DPC and from what I can tell, it wasn't either one of those things. It seems like it was a souped-up memory mapper with a tiny amount of what's essentially expansion audio.

Speaking of all that, here's the segment of his GDC 2011 talk where he talks about the DPC and its role in Pitfall II's development:

https://youtu.be/MBT1OK6VAIU?t=2328

And here's the part where he said "I cheated":

https://www.youtube.com/watch?v=MBT1OK6VAIU&t=2412s

I don't think David Crane lost any sleep over his decision to "cheat" in the development of a video game that went platinum. If I had been in his shoes, I might not either. What sucks about doing this kind of stuff in the modern era is that self-appointed gatekeeping nerds will come out of the woodwork to accuse you of cheating, and not in a lighthearted way. My decision to avoid rampant co-processing on the cartridge was made in part to avoid criticism, and via a cruel twist of fate, it seems to have backfired on me.

If you read my post carefully, you will get the sense that I don't think that including a period-correct co-processor on an NES cartridge would necessarily make it not-an-NES-game. I said that it's a controversy that is best avoided. Given that we didn't need to do it anyway to achieve what we've achieved, I can thank my lucky stars.
but you do allow a huge amount of ROM, using an imaginary CD-ROM peripheral that didn't exist as justification.
As I've explained elsewhere, Former Dawn could probably be squeezed into a ROM size available via period-plausible mask ROMs using MXM-0 instead of MXM-1 LARPing as a CD-ROM drive. I just figured: well, if we're going to go that far, we might as well throw in some FMV as well, since it is also period-correct to do so. I almost regret that decision, but my regret is tempered by the fact that I just think full frame rate, full screen FMV on the NES is really cool, unique, and novel.
That's fine, you explained why you made that choice, I fully believe that you should use whatever limitations and technology you want. But even after reading your explanation, the criteria of "CD-ROM quantity of data is ok but a co-processor isn't" comes across as completely arbitrary.
With all due respect (which is a lot, given who you are), I think you need to re-familiarize yourself with what the word "arbitrary" means. Let's play the dictionary game.

https://www.merriam-webster.com/dictionary/arbitrary

You're welcome to point to any of those definitions and then explain to me how what we're doing counts as "arbitrary".

People who make arbitrary decisions do not write a dozen pages carefully trying to explain the logic and philosophy behind those decisions. You can state that you don't agree with my premises or that my reasoning is flawed somehow, and that's absolutely fine. That's what is supposed to happen in a philosophical debate. But simply telling your opponent that his conclusions are "arbitrary" does not prove anything.

Now arbitrary choices aren't necessarily bad; we all make arbitrary choices about what we're doing or what tech we're interested in using. I respect that you chose a line and are sticking with it. But I think it's a losing battle if you want to convince anyone that your criteria are objectively more legitimate than other potential criteria.
Yes -- many decisions on the Former Dawn project have been arbitrarily made. But they pertain to the characters, sizes of levels, colors used, etc. Not to the technology.

If it's a losing battle, it's only because people are stubborn and have egos at stake.
User avatar
2fadfe
Posts: 17
Joined: Thu Feb 24, 2022 7:55 pm
Location: Earth

Re: House of Truth ROM and minimapper

Post by 2fadfe »

I'm excited for this game and the hardware, but are you just going to be recreating the game from scratch or are you going to have the other releases in striped down emulators or in a NES VM, if that's possible?
Known as Duncan Idaho #0087 on the Discord Server.
User avatar
jekuthiel
Posts: 10
Joined: Fri Nov 13, 2020 9:47 am

Re: House of Truth ROM and minimapper

Post by jekuthiel »

2fadfe wrote: Fri Feb 25, 2022 5:34 pm I'm excited for this game and the hardware, but are you just going to be recreating the game from scratch or are you going to have the other releases in striped down emulators or in a NES VM, if that's possible?
Glad to hear it. =)

Nintendo Co. Ltd. is not generally friendly to emulators being put on the Switch market. So in the case of the Switch, I think what we'll probably do is partially port and partially emulate it. Basically convert enough of the 6502 ASM code to C/C++ that it couldn't possibly run another game, but then run the rest of it in a custom partially implemented emulator to avoid a total rewrite.

This will also help convert it to widescreen, which most people are going to demand on the PC and Switch versions.

In the interests of expediency, we may just wrap it with a headless emulator for the Steam version and accept the lack of widescreen at first. We'll let our customers inform us as to whether or not that's acceptable.
User avatar
2fadfe
Posts: 17
Joined: Thu Feb 24, 2022 7:55 pm
Location: Earth

Re: House of Truth ROM and minimapper

Post by 2fadfe »

If it's not too much to ask, would the FOSS'ed version of your MXM0/1 mapper have versions in VHDL and C/C++, so eventually MiSTer and FCEUX, for example, would support it?

And would development using this mapper be difficult for say a somewhat noob to NES development like me? I think it would be interesting if I had enough expertise to modify this hack https://www.romhacking.net/hacks/1657/ to make further general enhancement (maybe FMV as well).
Known as Duncan Idaho #0087 on the Discord Server.
User avatar
jekuthiel
Posts: 10
Joined: Fri Nov 13, 2020 9:47 am

Re: House of Truth ROM and minimapper

Post by jekuthiel »

2fadfe wrote: Fri Feb 25, 2022 7:56 pmIf it's not too much to ask, would the FOSS'ed version of your MXM0/1 mapper have versions in VHDL and C/C++, so eventually MiSTer and FCEUX, for example, would support it?
We've developed it for the EverDrive N8 Pro in Verilog, since that's the language that krikzz uses for his framework and also the language that INL uses for their mapper implementations. We have no plans to use VHDL for anything, but I imagine that it shouldn't be too hard to get MXM-0/1 working on MiSTer. We also have MXM-0 implemented in a private fork of Mesen, so there shouldn't be any problem getting the publicly available Mesen(-X?) to support it eventually. Since it's open source, I imagine that if people wanted to get it working in FCEUX, it wouldn't be that hard either.
And would development using this mapper be difficult for say a somewhat noob to NES development like me? I think it would be interesting if I had enough expertise to modify this hack https://www.romhacking.net/hacks/1657/ to make further general enhancement (maybe FMV as well).
Well, I think that using MXM-0 would be easier than some mappers and harder than others, mostly because it's among the most powerful of them. We did intentionally design it to be as easy to use as possible given what it does.

It would be pretty amusing to see an FF7-on-NES hack that incorporated FMV to do the same thing that Square did where the transitions between FMV and the normal game engine were seamless. Would probably have to be done in greyscale, though, unless some sprite overlay wizardry is done between now and then. (It's been planned for over a year now -- always seems a few months away.)
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: House of Truth ROM and minimapper

Post by aquasnake »

jekuthiel wrote: Wed Feb 23, 2022 4:03 pm
Our 8x1 attributes require 1,920 bytes per nametable, although our current implementation is more wasteful than that. We'll probably clean it up sometime between now and Production.
960(NT)+64(ATTR): 8x8x4, without CHR bank when rendering

960(NT)+960(ATTR): 8x8, with CHR bank

960(NT)+960(ATTR): 8x2, without CHR bank when rendering

960(NT)+1920(ATTR): 8x1, without CHR bank when rendering
User avatar
jekuthiel
Posts: 10
Joined: Fri Nov 13, 2020 9:47 am

Re: House of Truth ROM and minimapper

Post by jekuthiel »

aquasnake wrote: Sat Feb 26, 2022 8:13 pm 960(NT)+64(ATTR): 8x8x4, without CHR bank when rendering

960(NT)+960(ATTR): 8x8, with CHR bank

960(NT)+960(ATTR): 8x2, without CHR bank when rendering

960(NT)+1920(ATTR): 8x1, without CHR bank when rendering
It's difficult to talk about this stuff using the standard nesdev terminology. When I said "attributes" I meant only the palette choices. What's really going on is that we have extended nametable data (which includes the CHR bank indices you're referring to) and extended attribute data. Altogether, the 8x1 mode in MXM-0 has a fundamental data requirement of 38 bits per tile, not including the graphics data itself. 16 bits of that are for the palettes (8 strips which use 2 bits apiece) and 22 bits to specify the tile index and CHR bank index(8+14).

So using labeling similar to yours, 1 screen's worth is:

2640(NT + ENT)+1920(EATTR)

...which is 4560 bytes.

Given that a full screen of unique tiles takes 15360 bytes for the graphics, 960 bytes for the nametable, and 64 bytes for the attributes -- our 8x1 system bumps the all-in data requirement from 16384 bytes to 18896 bytes, which is only a 23% increase over the stock NES graphics system's data requirement. All considered, it's pretty good bang for buck. This is why it's important to keep distinguishing between tiles and their attributes. MXM-0 does not support 1 pixel tall "tiles" as some people like to think. The tiles are still 8x8.

Now as I said, our current implementation is not this efficient in ROM/RAM. (It could be made to be at the expense of some extra mapper complexity; everything is a trade-off.) However, if and when we do clean it up, we will probably adjust the bit layout to fill out to the nearest byte, and the number of possible CHR banks will likely change as a consequence.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: House of Truth ROM and minimapper

Post by tepples »

At the end of 2021, I ended up realizing it's less useful to think in term of "cheating" and more useful to define a "conventional mapper". I defined this concept in a message sent to the Discord server as follows:
  1. Bank number registers and circuitry to write to them
  2. Multiplexer selected by upper address lines of CPU and PPU to route bank numbers to upper address lines and chip enables of memories
  3. Programmable interval timer to divide CPU cycles or PPU upper address lines to form an IRQ signal
calima wrote: Thu Feb 24, 2022 2:11 am
jekuthiel wrote: Wed Feb 23, 2022 3:18 pmI cannot hammer home enough that MXM-0's circuit complexity has been kept at or below MMC5's for the entire project, and it's going to stay that way. This is a very real constraint and it's almost entirely the ultimate justification that is needed for the prevention of those asterisks you speak of.
The MMC5 is also pointless, for the exact same reason that any project targeting it would be better targeted at the SNES. MMC5 was (is) too late, too expensive, *and* harder to program than SNES.
Super NES also creates an expectation among players that a game will have more than about 53 palette colors, parallax scrolling, and a full wavetable/sampled soundtrack.
Post Reply