nesdev.org

That's cool. I have my functional template up now. I'm still have questionable PRG-RAM, but that is another battle for later.


Now to study the PPU so I know what exactly I'm doing...

If worst comes to worst, I at least have an MMC1 setup I can revert to more sane numbers and do something a little less ambitious if the Z machine thing turns into a mess. Better yet find some other 6502 game to port. I'll look around.

I would be surprised if I have had added support for banked MMC1 RAM in no$nes (in everynes.htm it's still marked as reportedly existing, but unknown it works).
PS. Congrats on the first text output.

I know, the worst thing would be I'll be stuck with 8K.
Well, I mean the *worst* thing I can do is break your emulator with a non-standard mapping configuration and then submit a bug report
There are other 6502 ideas rolling around though.
For now I'm keen on streamlining the text display, Who knows, if Z machine is too complicated, I can revert to an old school text adventure with a graphic on the top and text on the bottom, and parser with less verbosity. I'll have to use CHR-RAM then.

With the template figured out I can go anywhere with this.

Hmmm
It would seem that assigning more that 8K of ram is problematic for emulators, so I think I'll scale back a bit
I made it a 512K ROM with 8K save ram
Sadly, it only opens in no$NES
All the other emulators I'm trying are attempting to load bank 00 and 0F (That has nothing) I thought emulators loaded the last bank and the first bank so it should be loading 00 and 1F.
Is there some kind of compatibility thing I'm running into?

MMC1 cannot load 16K banks from disjoint 256K sections simultaneously. The MMC1 was only designed to give you 256K PRG originally, and a dirty hack was employed to increase this amount to 512K.

If no$nes lets you do that, even gives you it by default, that's a bug.

So MMC1 can't do 512K either?

MMC1 can do 512K if you're willing to deal with the hack.

That hack involves selecting between two 256K halves at run time.

MMC1 supports 512KB but in a hack-ish way. It's not guaranteed to work on every emulator. It's up to you to decide if it's worth it.

Even if you do get it working -- which is possible -- you have to design your code to work off of the 256KB limit. That is to say: the final hard-wired PRG-ROM bank will be the last 16KB bank of the first 256KB half. At run-time, you can "swap" between which 256KB "half" you want to use -- but at boot-time the hard-wired half is always the first half.

In short: MMC1 was never designed "from the ground up" to support >256KB. MMC3 (mapper 4) can provide that, or other mappers like UNROM-512 (though you will not get PRG-RAM support on that mapper). In other words: you're going to have to work with these design quirks, you can't fight it.

https://wiki.nesdev.com/w/index.php/MMC1 has the details. The 512KB "quirk" (for switching 256KB halves) is under https://wiki.nesdev.com/w/index.php/MMC ... Mapper_001

Otherwise, MMC3 has 512KB support natively, and does support PRG-RAM (8KB).

Large-ish PRG-ROM is generally not a common thing; console mappers etc. were really not designed for it. 256KB was considered quite large for the time. Please step back and think about the era/time frame of the system you're working on. :-)

koitsu wrote:but at boot-time the hard-wired half is always the first half.

Should be random, not bottom half.

lidnariq wrote:

koitsu wrote:but at boot-time the hard-wired half is always the first half.

Should be random, not bottom half.

Oh, I didn't realise the internal state of the bit in the mapper would essentially be random. Yikes.

In that case, the solution is obvious: ensure in your ROM that the upper 16KB PRG-ROM bank (of the first and last 256KB halves) are identical, i.e. 16KB PRG-ROM bank $0F and $1F need to be the same. ld65 should make this easy, and the classic copy /b prg00.bin+prg01.bin+... method should be fine too.

Right-o 256K + 8k SRAM it is
I'm going to reevaluate my project then as that's too small to fit the Z machine I want. Good news is that I fought so far to get a working template, might as well do something with it
I'm looking up some really old 6502 game books and see if something catches my fancy

==EDIT==
OH! *THATS* how they crammed FF1 and FF2 on the same cart... OK...

Why do you want to give up here? Now that you have your header/template working, you could as well change it to MMC5, which should be easiest and most straight forward for large memory.

For MMC1, if you want your code in "last bank", you would have to store the code in "both last banks" (of each of the 256K-halves), that's making it a bit more difficult to merge code + game data, but it isn't impossible to do.

But when chosing between MMC1 and MMC5, I really think that MMC5 would be better for ease and speed and compatibility.

nocash wrote:But when chosing between MMC1 and MMC5, I really think that MMC5 would be better for ease and speed and compatibility.

It's not better for distribution, though... But I guess that depending on the subset of MMC5 features you actually need, you might be able to find someone who can publish your game.

Well, I'm new to NES development, and learning new and partially documented mappers are tricky. MMC1 is really straightforward So it's always better to scale back and not biting off too much. Anyways, limitations spur creativity, and I've been in little boxes before. I'm building up a little kernel and getting an NMI loop going. I'm not out of ideas. For fun I was wondering if I could do some "race the beam" kind of things with the NES, but that is going to require real hardware. On the Atari 2600 you could count cycles and alter the scan line while it's drawing on the phosphor. Looks like on the NES you are not even allowed to monkey with the beam during HSYNC. (or even detect it for that matter) I was contemplating if you could update the nametables during HSYNC and have it spit out a different pattern for that line. If you can update the nameable on each line, you can have a full screen bitmap. Like I said, I wouldn't even know how to detect when the beam is in HSYNC so I can play with the PPU while it's off.

I'm occupying myself with a psudo NES "Text mode" anyway. Still leaning on text adventure game. But Z machine is too strong (I wanted to run v8 games) Actually, having the compiler stuck in "PETSCII" mode gave me some ideas.

halkun wrote:Looks like on the NES you are not even allowed to monkey with the beam during HSYNC.

Some things are off limits, but some things are still available. For example, color emphasis, the monochrome bit, and bankswitching registers are all possible and have contemporary examples.

if you could update the nametables during HSYNC and have it spit out a different pattern for that line.

The contents of the nametables, no, but you can adjust the exact location out of all possible available nametables.