nesdev.org

Posted: **Mon Sep 24, 2012 1:48 pm**

Denine wrote:My logo "Red moon games" is taking a lot of space

It doesn't matter, because you can just overwrite these kinds of graphics between screens.

Text too, is not really needed

Text will use what? Half of the 64 tiles we have? I think it's OK to have text as long as it's not during the actual game.

Well, Inversion have over 30 levels.

Inversion is not a scrolling game, and each screen IS a level. In a scrolling game, a single level would be 30 screens. Also, 32KB is indeed the same amount of PRG-ROM as NROM, but since you don't have CHR-ROM anymore you have effectively less memory than NROM.

I might convert Inversion if there's any compo for this chip programming.

If there was a compo, I would of course obey the 32KB limit.

Posted: **Mon Sep 24, 2012 2:01 pm**

tokumaru wrote:It doesn't matter, because you can just overwrite these kinds of graphics between screens.

It does matter, because we have 64 tiles. Logo uses 87.
Also have no CHR ROM. So it'll take some space of PRG.
Currently, I wanted to insert one more song but, have no more empty space. So I'm trying too come up with better compression scheme.

Text will use what? Half of the 64 tiles we have? I think it's OK to have text as long as it's not during the actual game.

Point taken. That's true.

Inversion is not a scrolling game, and each screen IS a level. In a scrolling game, a single level would be 30 screens. Also, 32KB is indeed the same amount of PRG-ROM as NROM, but since you don't have CHR-ROM anymore you have effectively less memory than NROM.

That's true.
But I belive you just said "platformer" not "scrolling platformer", right?

On side note: I think a 30 screen level( only one way, not 4 way) is really long. Of course, it depends on how fast character moves etc. but still.

If there was a compo, I would of course obey the 32KB limit.

Hmh, So I'll better use Famitone instead of Famitracker.(Famitracker uses considerably more space)

Posted: **Mon Sep 24, 2012 2:31 pm**

Denine wrote:It does matter, because we have 64 tiles. Logo uses 87.

I see. You can just reduce the tile count instead of completely removing these screens. This kind of presentation will help the game look "normal". =)

But I belive you just said "platformer" not "scrolling platformer", right?

You are right. But yeah, I'd like to see what kind of scrolling platformer could exist under these limitations.

On side note: I think a 30 screen level( only one way, not 4 way) is really long. Of course, it depends on how fast character moves etc. but still.

Yes. It also depends on the kind of obstacles you have... some games have obstacles/puzzles that slow the player down quite a bit, so if you have a lot of those you can have smaller levels.

Posted: **Mon Sep 24, 2012 2:52 pm**

Could anything really be a single chip cartridge, since you also need the CIC?

Posted: **Mon Sep 24, 2012 3:18 pm**

Dwedit wrote:Could anything really be a single chip cartridge, since you also need the CIC?

It is one reason why I think they should all be made 60-pins (there are other reasons too, including audio), and include the CIC in the 60-to-72 adapter, instead of on the cartridge.

It could have its own mapper number, it could have a UNIF name, or both or neither; but regardless, this is simple (same as an idea I had once too actually) and intend once I write a few things of DotFami then I intend to describe the mapper using that as well (just since it is a simple test of some software and documentation I am writing). Which pin will you connect CIRAM A10 to? Is it PA13?

OK here is a DotFami mapper code:

Code: Select all

06 06 00 00 00
   12 38 ; CIRAM A10 to PA13
   10 1F ; enable CIRAM
01 00 00 00 ; PRG ROM
32 05 00 00 00
   7E 2C ; chip select
   00 2B 01 2A 02 29 03 28 04 27 05 26 06 25 07 24 ; data
   08 0D 09 0C 0A 0B 0B 0A 0C 09 0D 08 0E 07 0F 06 ; address
   10 05 11 04 12 03 11 02 12 21 13 22 14 23 ; address

Just writing a possible code for DotFami:

ines218.hs:

Code: Select all

module Main (main) where {
  import Language.FamicomHDL;

  mapper :: Mapper ();
  mapper = do {
    r <- romchip 0;
    rs <- parameter 0;
    connectPRGaddress r (rs + 14);
    connectPRGdata r;
    connect prgce (chipEnable r);
    pa <- parameter 1;
    connect (cartridgePin pa) cirama10;
    tieLow ciramce;
  };

  main :: IO ();
  main = compile "ines218.cart" mapper;
}

ines218.map:

Code: Select all

export ();
parameter 0 = (romsize 0) >> 15;
switch(flags & 0x9) {
  0x0 { parameter 1 = 54; };
  0x1 { parameter 1 = 53; };
  0x8 { parameter 1 = 55; };
  0x9 { parameter 1 = 56; };
};
use "ines218.cart";

Once more of DotFami specification is written and FamicomHDL is made, then we could include these on the iNES mapper articles and create a category for it (perhaps [[Category:DotFami mappers]]).

Posted: **Mon Sep 24, 2012 4:13 pm**

Whew, looks as if the thing is kinda inviting for a competition.

Bregalad wrote:I was going to allow vertical and horizontal mirroring as usual exept the second nametable would be hardwired as blank - the internal chip disabled, and pull-down resistors to ensure the lines are at GND. This would allow to use one namtable normally + one blank nametable, and to have 64 tiles plus a blank tile.

Oh yes, neat idea. A little bit less low-level... but using resistors as "extra memory" is still pretty much in the low level category.
Hmmm, with some restrictions you might also get the same effect by software:
Blank the name table entries when they get scrolled offscreen (eventually with Port 2001h.Bit3=1, downside would be that you don't have a fullscreen picture).
Or, assign one BG palette as all-black (or whatever backdrop color you want), and set the color attributes in the 2nd name table to that palette number (downside would be that you could use only 3 BG palettes and only 60 tiles).

tokumaru wrote:I wouldn't mind adding a 74161 in order to have access to a few more pages of ROM

I was hoping to get the CPU/APU to toggle the "/IRQ" pin as extra address line (for two 32K banks), but after testing, it seems that the pin is input-only; it doesn't go low even when the APU is generating an IRQ.
Another idea would be trying to use an unused PPU address line as extra CPU address line, A12 for example. I haven't tested that, but it might be possible to control the PPU address lines when video is disabled, so one could maybe relocate PRG-ROM to WRAM during that time.
Well, and otherwise one could stay with the 32K limit, which is a lot of memory for an 8bit system. Or add some mapping, it'd blow the simple "single-chip" design, but it'd be still "single-memory-chip" - and might allow to get some really impressive graphics & sounds.

Is it okay if I assign a mapper number to the board? And (re-)define the "Four Screen" bit in the iNES header as "One Screen" bit for that mapper (as described above)?
(For now without recursing possible extensions like pull-down resistors or exceeding the 32K limit. If they get ever implemented they could share the same mapper number, as far as they don't conflict with the old 32K definition, or use another new mapper number - or stay with NROM or AOROM when exact emulation of the hardware limits isn't important).

Some potentionally free mapper numbers can be found here http://kevtris.org/Projects/console/mappers/index.html but after googling for nes "mapper xxx" (xxx=number), it turned out that most of them are used for this or that stuff. One number (maybe the last in the 8bit space) that seems to be still free is "218" so I guess I could use that one, right?

Btw. for the NES 2.0 mapper numbers 256..4095, I think the http://wiki.nesdev.com/w/index.php/NES_2.0 page should contain some guidelines on how to use/invent new numbers. Like something saying that "any newly invented numbers MUST be defined in the http://wiki.nesdev.com/w/index.php/Cate ... ES_Mappers category".

Posted: **Mon Sep 24, 2012 4:29 pm**

Which pin will you connect CIRAM A10 to? Is it PA13?

The PCB could be jumpered to either PA10, PA11, PA12, or PA13 (see above for details).
And the MagicNES game, yes, it's using PPU A13.

Could anything really be a single chip cartridge, since you also need the CIC?

Well, yes, I know, then it'd be two chips. On the other hand, the CIC isn't "directly" part of the mapper. On a Famicom it'd work without CIC, same on a modded NES (which every NES user should have). And finally one could use that CIC-stunning circuits - don't know if newer consoles are protected against that trick, but at least that trick did exist & work with the older NES consoles - that could be implemented via transistors & capacitors without needing a second chip.

Posted: **Mon Sep 24, 2012 4:34 pm**

I was under the impression that CIC stun circuits such as those of Camerica and Color Dreams carts required a spare latch bit to generate the pulses.

Posted: **Mon Sep 24, 2012 4:43 pm**

I'd say don't redefine the "four screen" bit. It is already clearly defined, and any existing emulator that sees the "four screen" bit will provide 4 Screen VRAM.

Posted: **Mon Sep 24, 2012 5:33 pm**

tepples wrote:I was under the impression that CIC stun circuits such as those of Camerica and Color Dreams carts required a spare latch bit to generate the pulses.

That would be the cost-down trick if you do have a spare latch (and enough CPU time to pulse it; which might need only a few CPU clocks per frame, I don't know how fast they are pulsing it). Otherwise it should be super-simple to make a transistor circuit that generates the pulses.

Dwedit wrote:I'd say don't redefine the "four screen" bit. It is already clearly defined, and any existing emulator that sees the "four screen" bit will provide 4 Screen VRAM.

Would be no problem. If the emulator does support the mapper then it can interprete the header bit accordingly. And if it does't support the mapper then it won't work anyways, no matter if it sees the bit has one-screen or four-screen flag.

The other options would be assigning separate mapper number for each configuration, but I think that'd be some overkill.

Or, to allocate a new one-screen flag in the NES 2.0 header, like in bitX of byte 0Yh or so. But then the name table mapping would be controlled by 3 separate bits scattered all across the header (byte 6.bit0, byte 6.bit3, byte 0Yh.bitX). That'd be kinda messy, too. I think doing that would make sense only if more mappers need one-screen BLK0 and BLK1 mappings - which might be actually be the case (as UNIF is explicitly supporting that configuration). Are there any cartridges that are using that feature?

Posted: **Mon Sep 24, 2012 6:31 pm**

nocash wrote:The other options would be assigning separate mapper number for each configuration, but I think that'd be some overkill.

Use submapper numbers if it help? (For mapper numbers 256 and more, it is not need submapper 0 for the compatibility mode, so you can use submapper 0 for your own use.) Or use the DotFami mapper codes (I have posted it above and believe it to be correct) (it is one reason why I make up DotFami). Or, even do both.

Use 60-pins cartridge that way you don't need CIC on the cartridge, you can use CIC only on 60-to-72 adapter, so you only need one CIC instead of more than one. At least, it is my suggestion (maybe you don't like it).

Posted: **Mon Sep 24, 2012 7:24 pm**

What Super Mario Bros 3 might look like if it had a 64 tile limit:

Also, you can animate CHR tiles easily. You can also mask off the first 8/16 lines of the screen by uploading more tiles into VRAM.

Posted: **Mon Sep 24, 2012 10:43 pm**

Shiru wrote:I think it would be great configuration for a coding compo.

My first thought when I saw this. Also lots of lols at the connector.

Posted: **Tue Sep 25, 2012 5:13 am**

Using extra logic for more PRG-ROM is possible, but then it's not single chip any longer, and if you go that far why not add a CHR-ROM that will be able to store some non-CHR extra data, too.

I like the idea of using a free CHR pin as an extra address line but it would probably be a little crazy to control. During rendering it could be controlled easily with the $2000 register, but during VBlank...

@Tokumaru : I have nothing against platformers, it's just the way you said it sounded like "game = (scrolling) platformer" for you. A platformer is quite needing in tiles as you need at least several tiles for the main character and several enemies and power ups. Other game genres can be done with less tiles.

Also of course it's not possible to look as good as Kirby's adventure, but I meant it's possible to look good enough so that it's not too obvious the game uses a single chip.
If people's reaction will be "hey this looks good thinking this game is the only sinlge NES/FC game that uses a single chip", then I'll have failed. However if their rections is "it looks fairly standard" then I'll be delighted.

And another trick to bypass the 64 tiles limitation would be re-writing tiles midframe. Of course it becomes a tradeoff between the extra blanking scanlines in the middle of the screen and the # of tiles being rewritten. Something like 4 more tiles could be a life saver in several situations. However I didn't plan to use that in my game.

Posted: **Tue Sep 25, 2012 6:26 am**

Bregalad wrote:Using extra logic for more PRG-ROM is possible, but then it's not single chip any longer, and if you go that far why not add a CHR-ROM that will be able to store some non-CHR extra data, too.

I like the idea of using a free CHR pin as an extra address line but it would probably be a little crazy to control. During rendering it could be controlled easily with the $2000 register, but during VBlank...

Now that I have given some more thought to this, expanding this mapper in any way that requires more components would make little sense, because the whole novelty here is the simplicity. If you're gonna add more chips you might just as well use a more conventional mapper. It would be interesting if something could be worked out using the CHR pins though.

it's just the way you said it sounded like "game = (scrolling) platformer" for you.

It's my favorite game style, so it's only natural that it's the first one I think about. =) I do enjoy other kinds of games though, I just can't play RPGs.

A platformer is quite needing in tiles as you need at least several tiles for the main character and several enemies and power ups. Other game genres can be done with less tiles.

Yeah, you'd have to keep power up and enemy kinds to a minimum, and make them symmetric whenever possible to take advantage of sprite flipping. Scrolling platformers might not be the most fitting for this mapper, but I believe that a decent one is perfectly possible.

"hey this looks good thinking this game is the only sinlge NES/FC game that uses a single chip"

Most people don't know what having a single chip in the cart means... XD

And another trick to bypass the 64 tiles limitation would be re-writing tiles midframe.

Another option, that doesn't require messing with the rendering process, is blanking one entire background palette (so you only get 3 for the game) and using that palette for a few scanlines at the top and bottom of the screen. Every 8 scanlines buys you 2 tiles, so if you reduce the vertical resolution to 192 (like in many other platforms) you get 12 extra tiles. Vertical scrolling becomes pretty much impossible though.

nesdev.org

Single Chip Cartridge

Re: Single Chip Cartridge

Re: Single Chip Cartridge

Re: Single Chip Cartridge

Re: Single Chip Cartridge

Re: Single Chip Cartridge

Re: Single Chip Cartridge

Re: Single Chip Cartridge

Re: Single Chip Cartridge

Re: Single Chip Cartridge

Re: Single Chip Cartridge

Re: Single Chip Cartridge

Re: Single Chip Cartridge

Re: Single Chip Cartridge

Re: Single Chip Cartridge

Re: Single Chip Cartridge