It is currently Thu Dec 13, 2018 4:00 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 98 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next
Author Message
PostPosted: Fri Sep 28, 2012 9:53 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7604
Location: Chexbres, VD, Switzerland
Bregalad wrote:
Quote:
Uh, couldn't you have sent that objection before I released the specs? Well, and, now... what now?

I could not guess you were going to do it, and some people has already objected to the idea of a new mapper before I (if you follow the thread's order).

After all I don't really care, this won't change the face of humanity, BUT, I think free mappers are too precious to be wasted on something that can easily be implemented using existing mappers, and that iNES flags shouldn't be reassigned to new uses like this.

If someone will do something crazy like I and tokumaru were talking about (using more than 32kb on a single chip cart) then definitely a new mapper will be neccesarly. But for a 16k or 32k mapper, mappers 0 or 7 will do the trick very fine, as long as authors are careful not to rely on mirroring (that is, restrict to the usage of tiles 0-63, and don't display the unused nametable if mapper 0 is chosen).

Quote:
I'm beginning to understand why MMC6 never got its own mapper...

In fact the MMC6 is just the MMC3 and some extra features in a single chip, right ?


Top
 Profile  
 
PostPosted: Fri Sep 28, 2012 10:40 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20867
Location: NE Indiana, USA (NTSC)
MMC6 is just MMC3 with a particular method of PRG RAM enabling. It can be distinguished from MMC3 in NES 2.0 based on PRG RAM size. Likewise, the only difference between NROM and the PA10/PA11 variant of this poor man's OneBus is 1. the CHR holes are unpopulated and 2. CIRAM /CE is grounded. That's why I favor making the PA10/PA11 variant a variant of #0 distinguished by NES 2.0's CHR RAM size field being 0.


Top
 Profile  
 
PostPosted: Fri Sep 28, 2012 11:15 am 
Offline
User avatar

Joined: Mon Sep 27, 2004 2:13 pm
Posts: 1668
tepples wrote:
NROM and the PA10/PA11 variant of this poor man's OneBus is 1. the CHR holes are unpopulated and 2. CIRAM /CE is grounded. That's why I favor making the PA10/PA11 variant a variant of #0 distinguished by NES 2.0's CHR RAM size field being 0.

3. VRAM A10 is connected to PA13. (Unless you *want* two screens and don't mind continuously relocating your tiles to offscreen parts of the nametable, that would be hardcore.)


Top
 Profile  
 
PostPosted: Fri Sep 28, 2012 11:39 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11011
Location: Rio de Janeiro - Brazil
How about using BNROM for the horizontal/vertical mirroring variants and AxROM for the single screen variants? iNES 2.0 submapper codes would indicate that the ROM actually belongs in this single chip cart, but emulators not aware of this cart or even iNES 2.0 would still run the games (as long as the programmer didn't abuse the mirroring, in which case an emulator aware of the single chip cart would have to be used). This is the cleanest solution I can think of.

EDIT: Well, there's still the problem that the iNES header doesn't allow the selection of which name table to use with single screen mirroring on AxROM, since this is controlled by the mapper. Would repurposing the H/V bit (which would only work on emulators aware of the single chip cart, to be compatible with AxROM the game would have to perform a mapper write to select a name table) be as frowned upon as repurposing the 4-screen bit like nocash suggested?


Top
 Profile  
 
PostPosted: Fri Sep 28, 2012 1:28 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 732
Quote:
I could not guess you were going to do it, and some people has already objected to the idea of a new mapper before I (if you follow the thread's order).
After all I don't really care, this won't change the face of humanity, BUT, I think free mappers are too precious...

Glad that you don't see it too critical! I somehow thought I was asking for opinions... maybe I haven't made my questions and suggestions clear enough.

I think mapper 218 was in fact that LAST completley unused number in the 8bit space. But there are still 3840 free numbers in the NES 2.0 format, which is predicted to be enough until "next ice age". Nothing to be worried about for now.

Quote:
How about using BNROM for the horizontal/vertical mirroring variants...
EDIT: Well, there's still the problem that the iNES header doesn't allow the selection

What? BNROM, like mapper 34, as also shared for NINA-001?
Why not assigning it as 110-in-1 multicart apper, and indicating the special hardware variant by using .pdf as filename extension? ;-)
Yes (on the EDIT) that's the problem with AOROM.

Quote:
Would repurposing the H/V bit ... be as frowned upon as repurposing the 4-screen bit like nocash suggested?

I would guess, yes. :-)


Top
 Profile  
 
PostPosted: Fri Sep 28, 2012 2:12 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11011
Location: Rio de Janeiro - Brazil
nocash wrote:
What? BNROM, like mapper 34, as also shared for NINA-001?

I have no idea how NINA-001 got assigned the same mapper number. The NINA can be detected by the presence of CHR-ROM, which the single chip cart doesn't have, so this is not a problem.

Quote:
Why not assigning it as 110-in-1 multicart apper, and indicating the special hardware variant by using .pdf as filename extension? ;-)

... My suggestion was an attempt to use the simplest mappers (both BxROM and AxROM use a single discrete logic chip for a mapper) that are supersets of the different configurations that are possible on the single chip cart in order to make it as compatible as possible. It wasn't just a crazy random suggestion to avoid taking the last unused iNES mapper number.

Quote:
Quote:
Would repurposing the H/V bit ... be as frowned upon as repurposing the 4-screen bit like nocash suggested?

I would guess, yes. :-)

Though so.


Top
 Profile  
 
PostPosted: Fri Sep 28, 2012 2:36 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7014
Location: Canada
Now that I realize you were proposing that people don't "abuse" the CHR mirroring, Bregalad, I understand more clearly why you are suggesting mappers 0/7.

I was thinking that the CHR mirroring was actually an important part of this (not "abuse"), especially for people who would want to do some limited scrolling, or something like that, and that kind of thing would require a new mapper that properly supports it.

Another suggestion: if using mapper 7 to get single screen mirroring, you should write $8000-FFFF once to set the screen, in case someone wants to run it on an actual AxROM.


Top
 Profile  
 
PostPosted: Fri Sep 28, 2012 2:42 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7604
Location: Chexbres, VD, Switzerland
Why ?
On actual AxROM, the screen will be selected randomly and be kept while the system is powered on - a non-issue really.

In fact mapper 7 is probably the best, but 0 makes more sense for the circuits I was going to make where the chip would be disabled when A10 or A11 is high, pull-down resistors taking over the CHR data lines, effectively having a nametable automatically filled with tile #0, and having some automatic blank tiles.

All emus I've ever tried default nametables blanked with tile #0 and default unused tiles of CHR-RAM with blank tiles (which is never the case on real hardware), but any ways this would make my game compatible with the vast majority of emulators wile using mapper 0.

If I encounter issues I could just remove the resistors and deal with one-screen mirroring and only 64 tiles, with mapper 7, still 100% compatible with current emus.


Top
 Profile  
 
PostPosted: Fri Sep 28, 2012 3:14 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11011
Location: Rio de Janeiro - Brazil
rainwarrior wrote:
Now that I realize you were proposing that people don't "abuse" the CHR mirroring

By "not abusing the mirroring" I meant people should still use $0xxx/$1xxx for patterns and $2xxx for name tables, even though the single chip cart makes the tables accessible through mirrors (i.e. the name tables are also visible at $0000-$1FFF, and patterns also at $2000-$2FFF). In fact, patterns and name tables are mixed together, and only the NT mirroring and tile indexes used make a difference over what the VRAM is used for.

Quote:
I was thinking that the CHR mirroring was actually an important part of this

It's important in the sense that it introduces a number of limitations that don't exist in traditional configurations, but I don't really see any advantage in abusing the mirroring.

Quote:
if using mapper 7 to get single screen mirroring, you should write $8000-FFFF once to set the screen, in case someone wants to run it on an actual AxROM.

Yeah, I said that a couple of times. The ROM write would be harmless on the single chip cart, but would make sure that the correct name table was selected in AxROM.


Top
 Profile  
 
PostPosted: Fri Sep 28, 2012 3:18 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7604
Location: Chexbres, VD, Switzerland
Quote:
By "not abusing the mirroring" I meant people should still use $0xxx/$1xxx for patterns and $2xxx for name tables, even though the single chip cart makes the tables accessible through mirrors (i.e. the name tables are also visible at $0000-$1FFF, and patterns also at $2000-$2FFF). In fact, patterns and name tables are mixed together, and only the NT mirroring and tile indexes used make a difference over what the VRAM is used for.

Well this would be weird. Unless we want to do something like what you described (blanking portions of the screen for extra tiles), I think A13 should be wired to CIRAMA10, and then name tables and patterns are not merged. At least that's how I've always imagined the single chip cartridge.


Top
 Profile  
 
PostPosted: Fri Sep 28, 2012 3:25 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11011
Location: Rio de Janeiro - Brazil
Bregalad wrote:
I think A13 should be wired to CIRAMA10, and then name tables and patterns are not merged.

They will always be merged. Accessing $0000 will be the same as accessing $2000 no matter what you do. In practice, you could do all your VRAM updating (except for palettes) using $0000-$07FF, half of it being for patterns and the other half for a name table. If you do that, however, games won't work with mappers 0 or 7, or any other mapper really (except the newly created 218).


Top
 Profile  
 
PostPosted: Fri Sep 28, 2012 9:27 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 732
Quote:
I think A13 should be wired to CIRAMA10, and then name tables and patterns are not merged. At least that's how I've always imagined the single chip cartridge.

Yes, would be most likely case. I tried to make it flexible enough to work with different games, hence to options for using A10, A11, A12, or A13, with their advantages as described at the begin of this thread.

Quote:
you could do all your VRAM updating (except for palettes) using $0000-$07FF

Yup, for A10. Or elsewhere when using A11-A13. Of course it would be a bit weird to make a program that does actually rely on that mapping - more commonly one would access the name table at 2000h, as usually.
Still, for testing/developing games, it'd be nice if the emulator reproduce the exact mirroring. Not sooo much for intentionally using uncommon mirrors, but for seeing problems when accidently smashing something by writes to mirrors.

When making single-chip games, my focus on the mapper number would be to indicate that - hey - this thing works without memory mapping hardware and without CHR ROM/RAM! Declaring it as AOROM with CHR-RAM and mapping hardware would be somehow masquerading the programming efforts needing for squeezing into NT memory.

Allowing the game to run on older emulators would be nice, too. You could just release a second version of the game that works as normal NROM or AOROM or some other widely supported mapper type.


Top
 Profile  
 
PostPosted: Fri Sep 28, 2012 10:07 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 1024
tepples wrote:
That's why I favor making the PA10/PA11 variant a variant of #0 distinguished by NES 2.0's CHR RAM size field being 0.
This much I agree too; it does make a lot of sense! The problem is making it with PA12 and PA13 (I think iNES is the only format having this problem!!). Some possible solutions are:
  • Use submapper 1 for PA12/PA13.
  • Add an extra mirroring bit to iNES format to specify PA12/PA13 instead of PA10/PA11.
  • Ignore it and just make the game work with other mappers as well as the single-chip.
  • Make a multiple versions of the game, some working on any emulator and other require to use this special cartridge (or an emulator which emulates it).
  • Use UNIF and/or DotFami format instead of iNES. With UNIF, you should be able to add additional values to the mirroring chunk to specify these kind of things.
  • A combination of these.
Each one has its own advantages and disadvantages.

_________________
.


Top
 Profile  
 
PostPosted: Sat Sep 29, 2012 12:04 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11011
Location: Rio de Janeiro - Brazil
I was thinking some more about the 4 mirroring modes, and came to the conclusion that connecting A13 to CIRAM A10 isn't so versatile, because it doesn't allow parts of the name table to be used for patterns. When accessing $0000-$1FFF (A13 low) the lower 1KB is always selected, meaning that only this part of the memory can be used for patterns. Accessing $2000-$2FFF (A13 high) is the only way to access the upper 1KB, which is always used as a name table.

By connecting A12 to CIRAM A10 however, you can actually use $0000-$0FFF for patterns in the lower 1KB (which is also where the name table will be), and $1000-$1FFF for patterns in the upper 1KB. So if you set the background to fetch tiles from $1xxx and use 8x16 sprites, you can use a few extra tiles from $0xxx for sprites.

A11 and A10 are more restrictive in terms of scrolling (you'd scroll into the patterns if you scrolled both vertically and horizontally), but they're more versatile in terms of tile usage. Even if you use 8x8 sprites, you can still easily access patterns anywhere in the 2KB of RAM available, and these tiles can be used for sprites and backgrounds.

After considering all this, I'd probably use horizontal mirroring (A11) or single screen A (A12) in a project that used this mapper, in order to have the possibility of trading name table bytes for extra patterns, while still being able to scroll horizontally.

Anyway, my point is that although A13 provides the cleanest configuration (with complete separation of patterns and name tables), this configuration happens to be the one that doesn't offer the possibility of reallocating resources, so I'm not sure it would be the "most common case", as it says in the OP.


Top
 Profile  
 
PostPosted: Sat Sep 29, 2012 2:35 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7604
Location: Chexbres, VD, Switzerland
Quote:
They will always be merged. Accessing $0000 will be the same as accessing $2000 no matter what you do.

Not at all. Just think again. I map PPU A10 to CIRAM A13, which means there is 1k of RAM visible (and mirrored multiple times) at $0000-$1fff, and another 1k of RAM visible (and mirrored multiple times) at $2000-$3fff

Quote:
Anyway, my point is that although A13 provides the cleanest configuration (with complete separation of patterns and name tables), this configuration happens to be the one that doesn't offer the possibility of reallocating resources, so I'm not sure it would be the "most common case", as it says in the OP.

If you want to use the entiere screen, which is of course what I want to do in the game I was developing, that's pretty much the good way to go.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 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:  
Powered by phpBB® Forum Software © phpBB Group