nesdev.org

Posted: **Tue Sep 25, 2012 8:11 am**

zzo38 wrote: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.)

That would be working, too. Had the same idea last night. It wouldn't be much better/worse than using the 4-screen bit as 1-screen bit - emulators will need to interprete special header bits either way. I was thinking of the submapper bits as a last resort to be used only if something did went wrong. In so far, I would prefer to keep them reserved for such purposes.
Oh, and submapper 0 - that will be still needed to be reserved as "default" value. I am pretty sure that things will go wrong in future. The NES 2.0 format doesn't prevent people from assigning the same mapper number to different boards.

zzo38 wrote: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.

DotFami, like here http://wiki.nesdev.com/w/index.php/User:Zzo38/DotFami ?
Looks powerful.
And also pretty complicated, at first glance at least.

zzo38 wrote: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).

Yes, would have some advantages. If it's really useful would depend on how many people have such adaptors. To me... cutting the CIC pin the console would seem easier than finding/buying a female 72pin connector with nonstandard 2.5mm pitch. And "just-want-to-plug-and-play" users would probably prefer multiregion CIC clones without cutting pins & without using adaptors.

Posted: **Tue Sep 25, 2012 11:51 am**

nocash wrote:
zzo38 wrote: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.)
That would be working, too. Had the same idea last night. It wouldn't be much better/worse than using the 4-screen bit as 1-screen bit - emulators will need to interprete special header bits either way. I was thinking of the submapper bits as a last resort to be used only if something did went wrong. In so far, I would prefer to keep them reserved for such purposes.
Oh, and submapper 0 - that will be still needed to be reserved as "default" value. I am pretty sure that things will go wrong in future. The NES 2.0 format doesn't prevent people from assigning the same mapper number to different boards.

You are correct it still does not prevent that (UNIF and DotFami do not have these problems). But I was thinking make a universal standard "ines.map" file (the format of this file is described in DotFami) to decode iNES headers (including NES 2.0) to select DotFami .cart files and values of external parameters. It is meant for DotFami-compliant emulators, but even emulators which do not use DotFami could use this ines.map for decoding the headers so that any new mapper numbers will be assigned here, including the decoding logic for the header, so it work. It was suggested that you must put it on the wiki under the iNES mappers category with a title "iNES Mapper ___"; so the corresponding part of the "ines.map" file (as well as the DotFami mapper codes, perhaps a Haskell program to compile the .cart (after a while I intend to make a Haskell library for doing this) (literate Haskell can be easily embedded into MediaWiki and most other formats)) can be included within the same article.

nocash wrote:
zzo38 wrote: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.
DotFami, like here http://wiki.nesdev.com/w/index.php/User:Zzo38/DotFami ?
Looks powerful.
And also pretty complicated, at first glance at least.

Also incomplete. It is more complicated than other formats but also more precise, and I do try to make it simplified instead of being even more complicated than it is. There are some reasons I make it; one reason is for custom mappers, although it has other purposes too.

nocash wrote:
zzo38 wrote: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).
Yes, would have some advantages. If it's really useful would depend on how many people have such adaptors. To me... cutting the CIC pin the console would seem easier than finding/buying a female 72pin connector with nonstandard 2.5mm pitch. And "just-want-to-plug-and-play" users would probably prefer multiregion CIC clones without cutting pins & without using adaptors.

But then you still need adapter to play on 60-pins Famicom, so you need adapter either way. At least to me (and what I will do if I ever make the cartridges) is to make 60-pins cartridges (which might also use audio), and a 60-to-72 adapter with a CIC key (in NTSC-only mode by default but switchable to all-region), and a 72-to-60 adapter with CIC lock in NTSC-only mode (but can be turned off entirely by a switch). Also any hardware meant to play NES/Famicom games would be 60-pins (if I manufactured these, I would also manufacture the adapters so you can buy them together if you want to). (Of course, you need not follow my advice; you can do what you want, but I make this advice since I think is good idea.)

Posted: **Tue Sep 25, 2012 12:00 pm**

@Tokumaru : Don't worry the game I was planning to make for a single chip cartridge is not an RPG (but not a platformer either).
And I hope someday I'd do a RPG that even you like, although apparently I do less and less nesdev so unfortunatly I begin to start doubting this will ever happen.

The idea to sacrifice part of a nametable for more tiles is interesting. You say it would prevent vertical scrolling, but it is also possible to sacrify vertical borders for more tiles and sactify horizonal scrolling, or to sacrifice all 4 borders and sacrifice any scrolling. But with the additional cost of a palette (wich is 25% of your BG palettes) this is probably a very high price to pay for more tiles.
Also it'd be harder to emulate correctly, because it would mean the same RAM is mapped to both nametable and pattern tables. With the 1k / 1k approach (CIRAMA10 being wired to PPUA13) it's really an easier approach and is closer to what we're used to.

Also I don't think using any CHR line for extra PRG bankswitching is possible in a meaningful way.
A0-A9 and A13 changes all the time during rendering.
A12 has somewhat unpredictable behaviour during sprites fetching, and is always low during name table fetches.
A10 and A11 are selectable if you don't use scrolling at all and if all tiles are from the same area of pattern tables, but their behaviour is probably not predictable during VBlank, especially if you're updating VRAM (which of course you want to do).

I think with today's technology it's very possible to put a mask ROM + a custom clone of a CIC on the same chip, in fact it's even probably possible to put an entiere NROM cartridge, PRG-ROM, CHR-ROM and CIC on the same chip, but at least several thousands carts should be produced for it being made for a reasonable price per unit.

Posted: **Tue Sep 25, 2012 12:12 pm**

Yes, would have some advantages. If it's really useful would depend on how many people have such adaptors. To me... cutting the CIC pin the console would seem easier than finding/buying a female 72pin connector with nonstandard 2.5mm pitch. And "just-want-to-plug-and-play" users would probably prefer multiregion CIC clones without cutting pins & without using adaptors.
But then you still need adapter to play on 60-pins Famicom, so you need adapter either way. At least to me (and what I will do if I ever make the cartridges) is to make 60-pins cartridges (which might also use audio), and a 60-to-72 adapter with a CIC key (in NTSC-only mode by default but switchable to all-region), and a 72-to-60 adapter with CIC lock in NTSC-only mode (but can be turned off entirely by a switch). Also any hardware meant to play NES/Famicom games would be 60-pins (if I manufactured these, I would also manufacture the adapters so you can buy them together if you want to). (Of course, you need not follow my advice; you can do what you want, but I make this advice since I think is good idea.)

You can always make your own 60 pin version if you'd like. The discussion here is irrelevant to 72 vs 60 pin.

You might argue my point and say hey 60 pin has sound! Well 72 pin has ~10 pins you could use for sound if you pleased. And I'm really interested in hearing what super awesome sound capabilities you can add without any chips... That's like saying you could add better graphics to this board if you used CHR ROM.

I think with today's technology it's very possible to put a mask ROM + a custom clone of a CIC on the same chip, in fact it's even probably possible to put an entiere NROM cartridge, PRG-ROM, CHR-ROM and CIC on the same chip, but at least several thousands carts should be produced for it being made for a reasonable price per unit.

What would be the point to fabricate a CIC and mask rom in one? So you could spend thousands of dollars to be able to merely say there is only one chip? You can pay me thousands of dollars to bypass your CIC, and then you can say the same thing... In reality though if you ignore the need for level shifting which Hardwareman claims is unnecessary, you could just use a CPLD/fpga that has non volatile memory. Then you could have CIC, ROM, Dual ported ram, a full 8910 synth, MMC5, a spare 6502 coprocessor, and the kitchen sink in one chip for less than $20 a part. And still not have to pay fabrication start up costs...

Posted: **Tue Sep 25, 2012 12:23 pm**

Just a random thought. Isn't an ATMega MCU fast enough and has enough pins to emulate a ROM for NES, i.e. put requested data from internal ROM on data bus pins as fast as needed? It probably can also act as CIC.

ATMega64 could be enough for this application (32K for PRG, 32K for AVR code), and its price is under $10, which is a bit less than thousands.

Posted: **Tue Sep 25, 2012 1:39 pm**

Bregalad wrote:And I hope someday I'd do a RPG that even you like

Yours was an action RPG though, right? I kind like those. What I can't stand about RPGs is the battle system (I find fighting through menus incredibly boring), and all the useless fighting you have to do in order to level up.

but it is also possible to sacrify vertical borders for more tiles and sactify horizonal scrolling

That wouldn't work, because you wouldn't get 16 contiguous bytes. You only get contiguous bytes if you hide horizontal areas (each row of tiles gives you 32 contiguous bytes, enough for 2 tiles), so it's only possible to sacrifice vertical scrolling.

this is probably a very high price to pay for more tiles.

You could still gain some tiles if you mask the top and bottom of the screen by disabling rendering, the idea of sacrificing a palette was just to avoid messing with the rendering.

Also it'd be harder to emulate correctly, because it would mean the same RAM is mapped to both nametable and pattern tables. With the 1k / 1k approach (CIRAMA10 being wired to PPUA13) it's really an easier approach and is closer to what we're used to.

Yeah, if you use mapper 7 the memory won't actually be shared between the name and pattern tables, you'll have to be careful so that things don't overlap when running on the actual 1-chip cart.

A10 and A11 are selectable if you don't use scrolling at all
If you chose only one type of scroll to sacrifice (either vertical or horizontal) you could still use 1 bit for bank selection, right?

but their behaviour is probably not predictable during VBlank, especially if you're updating VRAM (which of course you want to do).

Since you only have 2KB or VRAM, that's all you be using, so you could access $0000-$07FF (A11 = 0) or $0800-$0FFF (A11 = 1) to select one of two 32KB PRG banks. For this you'd have to sacrifice vertical mirroring, right?

Posted: **Wed Sep 26, 2012 3:09 pm**

Yours was an action RPG though, right? I kind like those.

Yes, but the RPG elements are pretty much limited to what is in Mega Man X : You get new weapons from bosses and your lifebar can increase.
Yet nobody consider Mega Man X an RPG...

What I can't stand about RPGs is the battle system [...] and all the useless fighting you have to do in order to level up.

There is infinite possibilities for various battle systems, though menus and without menus.
Tales of Phantasia and Star Ocean for instance doesn't use menus, yet their battle systems are probably worse than any RPGs that uses menu in my opinion.

As for levelling up I 100% agree with you : I hate RPGs which requires level grinding. Unfortunately lots of NES ones does, but then I just recommand people to use a cheat code to save your time.
Well designed RPGs shouldn't require the player to waste time in the sole purpose of rising his level, (unless he fled from too many random battles of course), requiring hours of level up is a flaw in design.

Since you only have 2KB or VRAM, that's all you be using, so you could access $0000-$07FF (A11 = 0) or $0800-$0FFF (A11 = 1) to select one of two 32KB PRG banks. For this you'd have to sacrifice vertical mirroring, right?

In fact both A10 and A11 could be used, for a total of four 32KB PRG banks :
- Use tiles $00 to $3f (patterns $0000-$03ff) and nametable 0 ($2000-$23ff) : Bank 0
- Use tiles $40 to $4f (patterns $0400-$07ff) and nametable 1 ($2400-$27ff) : Bank 1
and so on.
(nb : the tiles and nametable are the same, mirrored, memory. You'd just need to address the correct mirrored version of the tiles for the sake of bankswitching)

The problems are :
- Scrolling is impossible unless you want your banks to switch "randomly"
- Bankswitching requires you not only to change the $2000 register, but also to update the entiere name table, therefore forced blanking is the only option.
- The address lines might not be stable outside of rendering, for example if the VBlank code rewrites the palette, there is no way to predict what will happen on the address lines. Even if it does nothing, I'm not sure they'll remain in the state they were in the frame.
This could be solved if all the VBlank code and all the code that uses forced blanking is duplicated in all banks.

However, that's a small price to pay for a single chip 64kb or 128kb cartridge !

Posted: **Wed Sep 26, 2012 3:46 pm**

Bregalad wrote:As for levelling up I 100% agree with you : I hate RPGs which requires level grinding. Unfortunately lots of NES ones does

If I recall correctly, it was an anti-rental measure.

Posted: **Wed Sep 26, 2012 5:14 pm**

Bregalad wrote:Scrolling is impossible unless you want your banks to switch "randomly"

That's what I was debating... If you want to select PRG bank 0, you can use the name tables at $2000-$27FF (A11 is always 0), and if you want to select PRG bank 1 you use $2800-$2FFF (A11 is always 1). Of course that you'd have to use matching tile indexes, 0-127 for bank 0 and 128-255 for bank 1. Changing the bank during rendering would indeed be impossible (like you said, you'd have to rewrite the name tables), but maybe you could use one bank during rendering (containing game code and data) and another one during VBlank (containing graphics and other things that can be accessed while rendering is off). Because of pattern table mirroring, you can write the tiles to one address and have the PPU read them from another, so that would be OK.

I'm not sure the address lines would be stable enough for that though... Maybe it's better we forget about this and accept this mapper for the simplicity it has. Bankswitching is sounding too complicated.

Posted: **Wed Sep 26, 2012 6:44 pm**

I'm confused about the goal to squeeze more memory into this setup with the CHR address line discussion. This setup is nice because it's simple and has a small amount of ROM, so why would you try to overly complicate things for more ROM.

Shiru wrote:Just a random thought. Isn't an ATMega MCU fast enough and has enough pins to emulate a ROM for NES, i.e. put requested data from internal ROM on data bus pins as fast as needed? It probably can also act as CIC.

ATMega64 could be enough for this application (32K for PRG, 32K for AVR code), and its price is under $10, which is a bit less than thousands.

A MCU isn't going to be fast enough for random access demanded from a ROM. You'd only have a few cycles to decode 16 inputs, retreive the data, and output to the pins. Definetly not enough time... For fun i once emulated a '161 on a UNROM board with an avr and it did work. I timed it out and i think there was less than a cycle's worth of slack for an overly simple operation and I wasn't retrieving data for the NES. I did NOT have enough time to implement the logic for the '32 in addition to the '161. You could use an AVR to feed a commanded stream of data and store it in onboard SRAM and perform all your code from there though. Not sure how well you'd be able to handle reset/interupts very well either. 2KB is pretty badly limited, you'd probably start sacrificing CIRAM for CPU use which would be a mess. The single chip 32KB starts looking pretty good at that point.

Posted: **Wed Sep 26, 2012 7:26 pm**

infiniteneslives wrote:I'm confused about the goal to squeeze more memory into this setup with the CHR address line discussion. This setup is nice because it's simple and has a small amount of ROM, so why would you try to overly complicate things for more ROM.

You are probably right. The goal here is to simplify things, so if you need more than 32Kb of PRG you should probably not be using this mapper.

Posted: **Wed Sep 26, 2012 7:57 pm**

infiniteneslives wrote:A MCU isn't going to be fast enough for random access demanded from a ROM.

I thought this way: AVR runs at 16-20 MHz, NES at 1.79 MHz. So we have 8-11 AVR cycles per 6502 cycle. Here is a primitive program that gets state of address lines connected to two ports, reads a byte from program memory, and puts it into third port.

Code: Select all

loop:
 in ZL,PORTA  ;1
 in ZH,PORTB  ;1
 lpm r0,Z        ;3
 out PORTC,r0 ;1
 rjmp loop      ;2=8t

Takes 8 cycles. Not sure if 6502 or NES hardware needs access to ROM every cycle, if it is, then it probably won't work.

Posted: **Wed Sep 26, 2012 8:00 pm**

PICS can run at like, what...40MHZ? And then they have single cycle execution for everything but branches AFAIK. Probably the better chip to go with, whatever you're discussing.

ETA: Nevermind, seems like you are talking about a equivalent instruct set chip. Carry on like I never posted this.

Posted: **Wed Sep 26, 2012 10:24 pm**

Shiru wrote:
infiniteneslives wrote:A MCU isn't going to be fast enough for random access demanded from a ROM.
I thought this way: AVR runs at 16-20 MHz, NES at 1.79 MHz. So we have 8-11 AVR cycles per 6502 cycle. Here is a primitive program that gets state of address lines connected to two ports, reads a byte from program memory, and puts it into third port.
Code: Select all
loop:
 in ZL,PORTA  ;1
 in ZH,PORTB  ;1
 lpm r0,Z        ;3
 out PORTC,r0 ;1
 rjmp loop      ;2=8t
Takes 8 cycles. Not sure if 6502 or NES hardware needs access to ROM every cycle, if it is, then it probably won't work.

Few issues here first you have to know when to do this by polling ( CP, BNE 1 + 2 = 3 cycles) or or trigger off interupt (upto 4cycles) so you lose 3-4 cycles there. Let's make it easier and say you're running off the NTSC 21Mhz clk (slight over clock non-issue) this should help for worst case alignment timing. So for argument's sake we'll say 12 AVR cycles per 6502 cycle. The only way you know when the NES is accessing PRG ROM is /CE which is inverted M2 when A15 is high. M2 is only high (active) for 2/3 of the cycle. So that cuts your alloted time from 12 to 8 cycles. So from the time PRG /CE goes low you have 8 cycles to get data on the bus, assuming no setup time requirement and you're perfectly aligned with the NES. So you need 3-4 cycles to start and 6 cycles to retrieve data and put it on the bus. That's 9-10 cycles, time's up...

EDIT: oh and you forgot one very important time consuming item. You need to change the direction of your data bus register as well so you can go from tristate to output to prevent bus conflicts... 40 mhz is starting to sound even less feasible now too.

Most instructions executed from ROM read from ROM 2-3 CPU cycles in a row, (opcode, low order byte, high order byte) So you've got to do this sequence back to back. Additionally you've got even more problems if you try to sense R/W operations as you'll spend even more time looping or responding to two interupts.

Perhaps something is possible with the pic. I always thought their 40Mhz mcu's didn't have one cycle execution, according to 3gen that's not the case though. As a matter of preference I'll never touch anything besides AVR if I have a choice in the matter. Don't forget Xmega's run at 32Mhz as well.

In any event even if you somehow managed to pull it all off with overclocking or something you're still consuming ALL your time acting as a ROM, and only 32-64KB at that! Sorry but nocash still beats you... Forget about also acting as a CIC which also requires time sensitive operations and most likely cycle counting to achieve that. Toss in a few interupts for ROM and you'll miss CIC requirements... Save some time for sound, IRQs, etc? doubtful you can do it well if at all with ANY mcu.

Programmable logic is the only way to go if you want to do anything substantial with minimum (single) parts being your driving goal. The <$20 Mach XO2 cpld/fpga I suggested is the big dog, the powerful more modest one is $6-7 and could beat the pants off the MMC5 if you wanted to. But really trying to do things with ONLY one part is a silly goal aside from what nocash has built which is simple, capable, and dirt cheap.

Posted: **Thu Sep 27, 2012 12:33 am**

See the Atari 2600 Harmony cartridge, it's just a 70 MHz ARM7TMDI (<70 MIPs). The NES is 50% faster than the 2600, but still it shows that it's very feasible; the 2600 doesn't even give you a clock or *any* control signal to synchronize with. Selecting a MCU with a slave parallel port will help.

Also worth noting is that the typical PIC at 40 MHz is actually 10 MIPs, some of the newer 16/32-bits are 1:1 and achieve 80+ MIPs.

STM32F205RC - $6.67 for a quantity of 100 at Digikey, this could do it. A large benefit of a MCU over a ROM here is that you can reprogram it in-system with a cheap TTL serial adapter. Kinda handy if this is intended for compos...

Somewhat comically I think a true NES flash cart emulating real mappers could possibly be developed with two fast MCU. If not today, in a few years.

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