It is currently Mon Feb 18, 2019 10:08 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 63 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Sun Feb 03, 2019 11:20 pm 
Offline

Joined: Mon Jul 18, 2011 10:04 pm
Posts: 45
That's cool. I have my functional template up now. I'm still have questionable PRG-RAM, but that is another battle for later.
Image

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.


Top
 Profile  
 
PostPosted: Mon Feb 04, 2019 12:36 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 812
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.


Top
 Profile  
 
PostPosted: Mon Feb 04, 2019 1:47 am 
Offline

Joined: Mon Jul 18, 2011 10:04 pm
Posts: 45
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 :P
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.


Top
 Profile  
 
PostPosted: Mon Feb 04, 2019 5:57 pm 
Offline

Joined: Mon Jul 18, 2011 10:04 pm
Posts: 45
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?


Top
 Profile  
 
PostPosted: Mon Feb 04, 2019 6:15 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8139
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Mon Feb 04, 2019 6:58 pm 
Offline

Joined: Mon Jul 18, 2011 10:04 pm
Posts: 45
So MMC1 can't do 512K either?


Top
 Profile  
 
PostPosted: Mon Feb 04, 2019 7:09 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8139
Location: Seattle
MMC1 can do 512K if you're willing to deal with the hack.

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


Top
 Profile  
 
PostPosted: Mon Feb 04, 2019 7:11 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3864
Location: A world gone mad
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. :-)


Top
 Profile  
 
PostPosted: Mon Feb 04, 2019 7:13 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8139
Location: Seattle
koitsu wrote:
but at boot-time the hard-wired half is always the first half.
Should be random, not bottom half.


Top
 Profile  
 
PostPosted: Mon Feb 04, 2019 7:17 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3864
Location: A world gone mad
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.


Top
 Profile  
 
PostPosted: Mon Feb 04, 2019 7:39 pm 
Offline

Joined: Mon Jul 18, 2011 10:04 pm
Posts: 45
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...


Top
 Profile  
 
PostPosted: Mon Feb 04, 2019 8:54 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 812
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.


Top
 Profile  
 
PostPosted: Mon Feb 04, 2019 9:07 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11166
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Mon Feb 04, 2019 10:10 pm 
Offline

Joined: Mon Jul 18, 2011 10:04 pm
Posts: 45
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.


Top
 Profile  
 
PostPosted: Mon Feb 04, 2019 10:21 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8139
Location: Seattle
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.

Quote:
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 63 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


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

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group