I've been talking with the webmaster of http://www.vgwiz.com/, and they are willing to design and make some NES cartridge boards for us! Provided there is a demand for them, of course.

We'll all need to participate in the design (we can do that here), so we can get a good and flexible design. As much as I'd want to, I don't think we can really go overboard too much with 4MByte ROMs and such. (Or maybe we can, if someone here knows how to organize the bankswitch logic effeciently!)

You don't need any hardware knowledge to help out with this design process, just answer at least one of these questions:

1. Do you want to put your program on some NES cartridges? The higher the quantity, the cheaper they could be to make for all of us.

2. What kind of ROM size limit would you be comfortable working with? 128K, 256K, or as big as we can reasonably go? (that limit I do not know yet)

3. How about using CHR-RAM instead of CHR-ROM? Bankswitching CHR-ROM would seem to complicate things, because then you have 2 ROMs which need to be bankswitched seperately. There can be cases where this is still worthwhile, though. (like mid-frame CHR switching, a very useful trick).

We need to come up with a design that's flexable, but still effecient (which could make them cheaper to buy). Let's get something figured out.

Well, I am definitely in. The specs for the board I am working on are finalized:

512KB PRG EEPROM
512KB CHR EEPROM
-or-
512KB CHR SRAM
32KB BRAM (EEPROM)

Support for (potentially) all mappers, and you will be able to write custom mappers.

the overall status is:

Hardware design: 75%
---PRG EEPROM: 100%
---CHR EEPROM/SRAM: 100%
---BRAM: 50%
---uC: 25% (awaiting code)
---CPLD (Mapper): 25% (awaiting code)
Microcontroller software: 5%
---Structure: 20%
---ATA/ATAPI code: 0%
---JTAG code: 0%
---LCD interface: 5%
Mapper software: 0%

I maxed out the ROMs and so forth because it was free, and not much harder to lay down extra traces for (going from 32K ROM to 512K ROM adds only 4 address pins). It makes the mapper more complex, but it's just software, so it's not like it's going to be hard to modify. I will upload the Protel stuff soon (really!) so everyone can get a better idea of what I'm doing.

-Regards, Matt

"Never give a gun to ducks." -Ancient Chinese proverb

"I should have been a plumber." -Albert Einstein

My two cents (my hardware knowledge is *extremely* rusty so I may be completely insane here, but hey)...

If the goal is to, effectively, create a new sort of memory control, I'd recommend bankswitchable RAM and ROM on both PRG and CHR sides, for maximum flexibility. Switching could be controlled with writes to memory-mapped I/O on-cart, if the bus permits this (I don't know much about what kinds of writes are permissible to the $8000-$FFFF range). If it *is* possible to intercept and interpret arbitrary writes to memory ranges on-chip, I'd recommend reserving locations $8000-$800F (or some other power of 2) as communications ports. A simple latch system might be able to handle the bankswitching if the full PRG and CHR data is really on one large chip each.

Here's what I'm thinking, from what I've heard so far.

For the mapper logic, it would be nice to be able to swap smaller pieces of ROM. Say, two 8KB sections (or probably one 16KB section, if that's easier) at $C000-$FFFF. I know that would cover the CPU vectors, but it would be worth the minor trouble to be able to bankswitch the DPCM sample area.

Ideally, the board would support up to 512KB PRG-ROM, while still being usuable with smaller ROMs. The CHR-RAM would be either 16KB or 32KB, bankswitched in 8KB blocks (or 4KB, if that can be done easily).

Having an IRQ counter would be very good. If it can be done at a low cost.

Anyone have any ideas or suggestions?

Can you give a more general overview of your idea?

I'm guessing that:
You want to put that all on the cartridge. (as opposed to a "cart + separate progger" design) Use a CPLD to act as a flexible mapper ... and use a microcontroller to interface with a PC (and aid in programming the EEPROM and CPLD)?

What is the "LCD interface"? I hope you don't mean a liquid crystal display ... that is making things more complicated/expensive than is necessary.
I don't know what you mean by "ATA/ATAPI code" either.

Another question:
For the CPLD to work as a mapper, it needs to be able to have "power on reset" defaults. I'm new to CPLD's and was curious how you accomplish this. (I can read/write registers, do state logic, and logic tables ... but can't figure out how to set what the "power on" state is.)

Last question:
I know a lot about the SNES, but have never worked with the NES. So this question is of pure ignorance, but didn't some of the later mappers do more than just "memory maps"? (like extra hardware functions for the games to use)
If not, I'd be surprised because the later SNES cartridges did it all the time. If they really did nothing besides "memory maps" then we really could support everything! That would be amazing.

If the resultant product is as flexible as your ideas sound... consider me in.
Oh, where do you usually go to get your PCB's made? (I like Advanced Circuits myself... the $33 special is awesome!)

>You want to put that all on the cartridge.

It'll be a tight fit, but it should work.

>(as opposed to a "cart + separate >progger" design) Use a CPLD to act as a >flexible mapper ... and use a
>microcontroller to interface with a PC (and aid in programming the EEPROM and >CPLD)?

That's the general idea, but it will not interface with a PC (directly). It will read iNES images from a CompactFlash card or MicroDrive. The uCs only job will be to program the CPLD and EEPROMs.

>What is the "LCD interface"? I hope you don't mean a liquid crystal >display ... that is making things more complicated/expensive than is >necessary.

Just a little 1x16 alphanumeric unit, no graphics, no backlight.

>I don't know what you mean by "ATA/ATAPI code" either.

Well, it won't be *TRUE* APAPI, but CF 1.4 PC Card Memory Mode is pretty close.

>I know a lot about the SNES, but have never worked with the NES. So this >question is of pure ignorance, but didn't some of the later mappers do more >than just "memory maps"? (like extra hardware functions for the games to use)

I know the MMC5 did some timing and other misc functions, but there was nothing of any complexity, and most mappers just mapped and nothing more. I think there are some oddball japanese carts that had sound chips and such, but these will not be supported.

>For the CPLD to work as a mapper, it needs to be able to have "power on ?>reset" defaults. I'm new to CPLD's and was curious how you accomplish this.
>(I can read/write registers, do state logic, and logic tables ... but can't >figure out how to set what the "power on" state is.)

Every NES mapper that I know of was either a simple ASIC or a few 74LS devices, none of them had any real processing power, so it shouldn't be too hard. This cartridge will be packing 16 MIPS, after all.

>If the resultant product is as flexible as your ideas sound...

That's the nice thing about ideas, eh?

>consider me in.

Well, we'd be glad to have you. I am doing hardware, Memblers is doing the mapper, and loopy is writing the code for the uC. What are you good at?

>Oh, where do you usually go to get your PCB's made? (I like Advanced Circuits >myself... the $33 special is awesome!)

Agreed!

-Regards, Matt - fropmaster@earthlink.net

"Never trust any statistic you didn't fake yourself." -Winston Churchill

"I should have been a plumber." -Albert Einstein

I would be interested in the final thing if its cheap enough, but i can't help with design unfortunately my hardware knowledge does't extend to actual design of boards (electrical bit and bobs etc), but i would like to suggest that the memory size perhaps does't need to be bigger than the largest home made game (i'm not sure of this size)(not some hacked game), though if it would make much difference 40kbyte would probably be ok for must uses.

I have no real technical knowledge of the nes... just a yearning to learn it... but damn, if these get finished, and produced, and are cheap enough I'd be more than interested in buying a couple.

Afterall... my main goal right now, is to make something simple and burn it to a modified cart [with eprom], and test... but, if these carts get designed, it would seem they'd make things far simpler.

As Far as size is concerned... Chris Covell says the largest commercial game is 1Mb, so why not shoot for something that or less [the hardware mentioned in another reply seems to stick to this idea as well]? That's all I can really comment on, because I _do_ know the difference in things size-wise ;)

--gesis

I may be sexually inadequate, but I have a bigger Harddrive!

yes yes yes! i'd be very interested in getting my hands on a number of devcarts
if this happens. i'll leave the hardware design to those that actually know it,
i'm just a lowly NES musician ;]

to answer your questions:

1. yes, right now i have a very uh ... basic "devcart" ... basically just super
mario bros. with the PRG rom ripped out and a socket/eprom installed in its
place. i'm (going to be) using this for running my NES tunes on the actual
hardware instead of an emulator, but its certainly not the best solution. i'd
definitely like a more robust devcart that would be able to deal with some more
serious projects/demos as i anticipate getting to this down the road a bit.

2. Again, at the moment rom size limit is not a big deal. i'm using 32K eproms
at the moment. however, i'd definitely say the bigger the better, while keeping
the cost/value balance in mind.

3. I can't really comment on this as i've not done any graphics programming as
of yet. i'm confident that the wealth of knowledgable individuals on this board
will make the right decision! ;]

in short, i really hope this happens and if (WHEN!) it does i will absolutely be
placing an order for a good amount of these, no matter what the cost (within
reason!) ;D


../love_alwayz/nullsleep
../www.8bitpeoples.com
../www.nullsleep.com

I would be very interested in these. I currently have built a large number of EPROM carts by hacking up existing games, NROM, CNROM, UNROM, T*ROM, S*ROM, etc. These are what I currently use. However, I don't have an eprom eraser, and it's a hassle to burn these chips all the time.

I would love devcarts. The idea of using a new, non Nintendo mapper is great, becuase Nintendo won't be able to bother us as much about piracy like with GBA devcarts (yeah, N still cares about the NES & piracy even though they don't sell it anymore).

CHR Ram would be good also. The top 16K of the PRG can stay put, no need to worry about that. As for size, I want at least 128K, I probably wouldn't use more than 512K, but chips are so cheap, would it really cost much more at all for even 4MByte?

Lastly, would it be possible to add more NES Ram to the board? The 2K from $0000-$0800 is really limiting!

The most important thing I want is for it to be flash. I want it to have a plug in the top or something that connects to a PC. My vision is that you could, say, transfer the program from the PC to the cart while it's still in the NES, then turn on the NES, test it, turn off the NES, click "Transfer" on the PC again with a new program, turn on the NES, play, etc. So, the only steps would be to click a transfer button on the PC, then turn on the NES and you're ready. No need to even take out the cart.

I want it to allow me to quickly and easily test out my programs. If it used flash cards or something instead of a PC, I'd need to plug the flash card into the PC, transfer to it, take it out, connect it to the cart, transfer it to the cart, etc. If I had to do that, I may as well just mod my EPROM cart's sockets for EEPROMS since it would take the same effort to test my code.

>That's the general idea, but it will not interface with a PC (directly). It
>will read iNES images from a CompactFlash card or MicroDrive. The uCs only job
>will be to program the CPLD and EEPROMs.

Okay, that sounds good, but I'm misunderstanding something.
When is this 'EEPROM/CPLD programming' taken place? Everytime the cartridge receives power from the Nintendo after insertion?
If so, this means the Nintendo is looking for its reset vectors, code, etc while you're programming the EEPROM. By the time the programming is done ... the Nintendo will be in an unknown state and will not be able to run the code correctly.

BTW, what microcontroller have you selected?

Oh, and with the current design ... everything can be programmed except the uC. Will pre-programmed chips be sold with the boards?

>Just a little 1x16 alphanumeric unit, no graphics, no backlight.

What are you planning to use it for?

>>I don't know what you mean by "ATA/ATAPI code" either.
>
>Well, it won't be *TRUE* APAPI, but CF 1.4 PC Card Memory Mode is pretty close.

Compact flash cards can be accessed like 2 separate flash chips. So the interface code shouldn't be anything more than ... set address, enable chip, enable read, wait 300 ns, get byte, disable read, disable chip.

>>For the CPLD to work as a mapper, it needs to be able to have "power on ?
>>reset" defaults. I'm new to CPLD's and was curious how you accomplish this.
>
>Every NES mapper that I know of was either a simple ASIC or a few 74LS
>devices, none of them had any real processing power, so it shouldn't be too
>hard. This cartridge will be packing 16 MIPS, after all.

You misunderstood my question, but that's okay.

I want to know how to program a CPLD such that it has a known "power on start-up state". For instance, let's say I want to make a simple mapper. By writing to a particular address, the mapper will change what data bank is mapped into the code region. The problem is I want to REQUIRE that the mapper defaults to mapping data bank 0 into the code region after power up. So, how do I set power on defaults like this?

>Well, we'd be glad to have you. I am doing hardware, Memblers is doing the
>mapper, and loopy is writing the code for the uC. What are you good at?

I'm kinda in the middle of some projects for the SNES. I can supply whatever knowledge I have that may be useful and some money ... but not much time.
What would you like me to help with?

=========================================

I know you're probably well on your way to making this device ... but I have been meaning to make a versatile SNES flash cartridge for some time now and I have some ideas that you might like to use. Please read though this, I think you might like it.

I just checked ... the NES is a 2 MHz system. That means the 300 ns flash in a CompactFlash cartridge is fast enough for the system to run directly off of.

So, I suggest designing the cartridge like this.
Contents:
CPLD
NVRAM or SRAM + battery + nvram controller (such as Dallas Semiconductor: DS1210)
50 pin CompactFlash connector
security chip (from old NES cartridge)
some DIP switches
a couple 74'xx logic chips

and that is it.

Here's how I'd envision the design working:
A CompactFlash cartridge has 2 flash chips in it (that can be accessed completely separate from each other, simultaneously). We can use one for the PRG ROM and one for the CHR ROM. The SRAM chip will be large enough that the CPLD can map it so that its usable for both battery backup and CHR RAM.

A normal CompactFlash programmer can be used to program the flash from the PC.
The CompactFlash is inserted into the cartridge and the cartridge is inserted into the NES.

The DIP switches control whether the CPLD maps the PRG portion of the cartridge or whether it is forced to the first bank. The DIP switches also enable the 74'xx chips to "map" the CPLD's JTAG pins to the data pins when the cart is read/written at a certain address.

This means a "bootstrap" program can be put on the FlashCartridge which allows programming of the CPLD (even on the first time, so we don't have to ship pre-programmed parts). This bootstrap program can be used to select which "game" on the FlashCartridge you want to play (many many NES games can fit on one FlashCartrige).

After programming of the CPLD, you remove the cartridge ... flip the DIP switches to normal position ... and now you can play the game!

Woohoo!

It is also possible to program the flash in the CompactFlash from a NES program if the cartridge is designed such that the inverse of the PRG /RD is sent to the Flash /WR.

What does this allow?
It allows you to copy the backup RAM to FLASH from your bootstrap program.

=========================

So, how I imagine it:
flip DIP switches to "choose game" position ... put in cartrige
on NES you see: choice of "choose Game", "save RAM to FLASH", "restore RAM from FLASH"

after letting the program copy the RAM, program the CPLD, or whatever you want...

remove the cartridge... flip switches to "play game" position

put in cartridge... play game!


You can fit a whole library of games on the cartridge. The design has less parts and is completely configurable/reprogrammable by the user (no preprogrammed parts needed). I really like the idea ... what do you think?

>As for size, I want at least 128K, I probably wouldn't use more than 512K, but
>chips are so cheap, would it really cost much more at all for even 4MByte?

Check out my last post (scroll to the bottom to get to my design suggestions) ... you can have much more than 4MBytes! :)

>Lastly, would it be possible to add more NES Ram to the board? The 2K from
>$0000-$0800 is really limiting!

Why not? With a CPLD mapper ... you can map stuff basically anywhere, and still support the normal mappers as well.

>I want it to have a plug in the top or something that connects to a PC.

That would mean your PC is right next to the NES. So how much work could it possibly be to remove a cartridge, program cartridge, reinsert?

Regardless, the PC would still have to program something on the cartridge ... and that's what takes the most time anyway.

You've brought up some interesting points.

Keep in mind though, we have 2 seperate NES cartridge design projects here that are being confused somewhat. One is the universal cartridge started by Betaman, the other is a simpler one for http://www.vgwiz.com/ to be used to do small-scale publishing of a new NES game.

For the universal cart:
I've not considered the CPLD's initial state. I was thinking you'd put the cartridge in and turn it on, and the stuff would get programmed. Then resetting the console would run it.

I don't mind having to run around a bit to test my program. Hell, with the SNES program I'm working on I have to use 4 floppy disks or burn a CD-RW to be able to test it. Writing a little CF card seems like nothing in comparison to that. But, the best way to test your program if you don't want to have to move anything (other than the power and reset buttons of the NES) is to use an EPROM emulator. I've wanted one of those, but they're expensive to buy (with a good memory size) and not very easy for a beginner to build.

For the vgwiz cart:
I'm not sure if it would have the extra 8KB WRAM. Hopefully having the connection for it on the board wouldn't drive the cost up very much. Ideally, the extra RAM (or NVRAM) would be optional.

> I want it to allow me to quickly and easily test out my programs. If it used
> flash cards or something instead of a PC, I'd need to plug the flash card into
> the PC, transfer to it, take it out, connect it to the cart, transfer it to
> the cart, etc. If I had to do that, I may as well just mod my EPROM cart's
> sockets for EEPROMS since it would take the same effort to test my code.

Have you considered buying or building an EPROM emulator? This schematic satisfies those needs, it even has a RESET and a /RESET line so the dumping procedure will even reset the NES for you after download.

http://www.devrs.com/e/files/ee4096.gif <-- 512kb version

http://www.devrs.com/e/files/ee256.gif <-- 32kb version

I've successfully built the 32kb version on a lab-deck, and used it for lots of hardware intense coding. The 512kb which I built on a nice compact PCB I never got working though... :(

// Michel Iwaniec (bananmos_uv@hotmail.com)

>Keep in mind though, we have 2 seperate NES cartridge design projects here
>that are being confused somewhat.

Oh, I wasn't aware of that.
Thanks for pointing that out.

>For the universal cart:
>I've not considered the CPLD's initial state. I was thinking you'd put the
>cartridge in and turn it on, and the stuff would get programmed. Then
>resetting the console would run it.

Even after the CPLD's programmed ... how do you make it so that it has a "reset state"? So that when you start the game it begins at "bank 0" or whatever the default should be. I'm don't doubt that it's possible. It's just that I don't know how to program a CPLD to have "power on defaults" and am curious how to do it.

So, with your idea, the cartridge gets power from the NES, and copies everything? I assume that the microcontroller will need to control the address lines and data lines so that it can program both EEPROMs. You can't have the uC controlling these lines while the NES is operating unless you "buffer" them all through logic chips (or the CPLD). That is a LOT of lines to buffer and a big waste.

On a side note, I looked up the cartridge connector for the NES ... I don't see any /RESET pin or anything. How are you supposed to protect the battery backed up RAM from unwanted writes if you can't even tell when the writes are unwanted?
Did they use some weird trick to get around this?

BTW, what is "pin 38 - M2"?

================

If you don't like the "DIP switches" on my idea (for the 'universal cart'), I may be able to do away with them ... I'd have to think about it. I think building a universal cart sounds great, but the current design is overly complicated (and therefore unneccesarily expensive and large in size).

>Even after the CPLD's programmed ... how do you make it so that it has a
>"reset state"? So that when you start the game it begins at "bank 0" or
>whatever the default should be. I'm don't doubt that it's possible. It's
>just that I don't know how to program a CPLD to have "power on defaults"
>and am curious how to do it.

AFAIK, most mappers (if not all) don't have a "reset state", they need to be initialized after being powered on.

>AFAIK, most mappers (if not all) don't have a "reset state", they need to be
>initialized after being powered on.

So that means the section of the ROM that contains the RESET vector and initilaization code can never be "swapped out" by the mapper?
I see ... that makes things much easier.

I'm sorry if some of my questions sounds ignorant ... it's because I don't know anything specific about the NES. I've only done work with the SNES.

But, with other projects I'm working on ... it would be nice to know how to set the "power on" state of a CPLD. I have a feeling its possible (or that there's a good trick for doing it). I guess it's off topic now, but if anyone knows ... please pass any info my way. Thanks.

>On a side note, I looked up the cartridge connector for the NES ... I don't see any /RESET pin or anything. How are you supposed to protect the battery backed up RAM from unwanted writes if you can't even tell when the writes are unwanted? Did they use some weird trick to get around this?

Well, an unused address line on a mapper would usually be connected to an extra chip enable line on the RAM. This was done not so much to disable illegal writes to the RAM area, but to circumvent RAM corruption during power on/downs. During this time, the logic states of address & control lines become unstable. A "pull-down" resistor tied to this chip select line would basically make sure that the RAM stays disabled when there's not enough power for the output of the MMC to drive the signal properly. But in case this trick didn't work, Nintendo told us to hold in reset while powering down. Another bit of evidence would be in the Uncharted Waters cart (ETROM). They're using 2- 8K RAM chips, instead of a 16K one. At first, I thought Nintendo was mad (or that it was cheaper for them to use 2 8Ker's than a single 16K). But then I realized why they did it. The 8K RAM chips have an active high chip select line on it (in addition to one gated with it that activates when low), which is why they used it. During power down (and because of the common ground situation between the NES & the battery-backed RAM), it's easier to force a logic line low than it is to force it high, which is why the noninverted chip select line is always used to disable the RAM during power down.


>BTW, what is "pin 38 - M2"?

It stands for "phi 2", and represents the NES's raw 1.79 MHz CPU clock signal (I have no idea why Kevin abbreviated it "M2"). The duty cycle is 62.5%, and is used as the 6502's bus enable line (active when 1). The use of this signal is required to allow the 6502 address lines (& the deocders) time to set up the next valid address before the address line data can be considered stable.

----------------------

Finally, for those of you designing the dev carts- why don't you borrow a page from an idea which Michel Iwaniec and I discussed recently on a previous thread here, and use the "multi port" RAM/ROM emulation idea. Design your dev board with an extra 28 pin (or so) connector on the back, which connects (via ribbon cable, for example) to some other microcomputer system you use to upload your NES code to the cart with in real time (i.e., NO removal of the cart requred, all you might need to do is hold in reset during the upload phase). I mean basically, if you can't afford an eprom emulator, and you're half decent with digital electronics (and don't mind actually building somthing, even if it's on a breadboard), *this* is the way to go.

When I was reverse engineering the NES's sound channels, I set up a dev cart with an authentic 1K byte dual port static ram, where the other port was tied into my PC's ISA bus. I wrote a program out of Pascal/Assembler to VERY easially upload short bits of code I wanted to run on the NES in literally fractions of a second. I do remember having to hold in the reset button during the upload (which is understandable), but this was but a slight nussiance. The project made it possible for me to write a pascal program which interacted with the NES's 6502 in real time. In 1 line of pascal code, I could make a write out to an NES port, even step through the HLL program, and never have to touch any 6502 code after the initial load was done. It was a dream.

Now, of course, you guys want to design real NES applications, and that's fine. Personally, if I had to do what you guys were, I'd use the multiport emulation idea for researce & development of my NES app projects, since REAL dual port RAM is small, expensive & rare. At any rate, anyone serious enough about doing *real* NES app dev should be serious enough to put themselves together a test rig which ensures that 99% of the time is spent on the design & programming of the app, and 1% of the time is spent on the technicalities which prevent you from running your code on the little grey box.

I originally thought that the multi-port emulation idea's most valuable quality was to allow for a super-mapper design, allowing memory allocation between the PPU & CPU to be dynamic & unified (even allowing for speedy background DMA xfers for free), but using the idea so that your favorite microcomputer system (with all your programming software on it) can have real-time access to the cart's RAM while the NES is running, is just as good.



- BT

Just a quick post today...

I think we're pretty much on the same page, the way the cart will load the games is before it is inserted. The LCD is so you can browse the images on the CF. Running the NES off of the CF is not practical, since there are 2 independent buses, there would need to be some sort of data/address latching and an internal clock, at a minimum, plus the uC would have to translate the address info into CF commands, and then discard the high byte (additional buffering of the data bus and extra latency). The design will use SRAMs for PRG and CHR ROM/RAM (the EEPROMs had to go, space constraints). The cart will have some sort of internal power (either 2 AAAs or 2 N cells, don't know which yet, but I'm leaning towards 2 AAA NiMH cells), so programming will occur before insertion (actually, there will be an interlock, to prevent the NES 5v line from blowing the chips away while programming). When you insert the cart and power the NES, the game will run as it normally would, so there doesn't need to be any NES code written.

As far as the mapper, the uC has the capability to throw commands at it after programming is complete, so any initial state can be set.

Anyway, more details later, pressed for time now.

-Regards, Matt

"I should have been a plumber." -Albert Einstein

>Running the NES off of the CF is not practical, since there are 2 independent buses ...

You are correct about one thing .. a CF doesn't have two address busses. However, I still believe it to be simplier to put another CF connector on the cartridge then to put a uC, an LCD, and all the stuff required to prevent damage by inserting the cartridge before programming is over.

>... plus the uC would have to translate the address
>info into CF commands, and then discard the high byte (additional buffering of
>the data bus and extra latency)

My design idea didn't have a uC on it. And there are no complicated "commands" for readig a CF ... only for writing it. The high byte does not need to be discarded, both "data buses" can be connected together since each internal flash chip can be selected separately. The entire memory space of the CF is accessible this way.


>The LCD is so you can browse the images on the CF.

So you need buttons on the cart as well to let you select which one you want ... I still think you're making this much much more complicated that it needs to be.

Your design also has increased power needs. I only need a battery for SRAM backup. You need one to power everything.

For people who want to keep making changes to their code and testing their program on the NES ... the CPLD doesn't need to be reprogrammed. Therefore, my method will require no reprogramming on the cartridge. Only a quick program of the CF using the widely available pc USB -> CF programmers.

Also, as stated, my design needs no preprogrammed parts. Therefore if a "bug" in code is found ... all users can upgrade.

Does your design allow the uC to be reprogrammed? If not, will you be shipping preprogrammed parts to people ... and what is the best way to handle "upgrades"?

>Design your dev board with an extra 28 pin (or so) connector on the back,
>which connects (via ribbon cable, for example) to some other microcomputer
>system you use to upload your NES code to the cart with in real time (i.e., NO
>removal of the cart requred, all you might need to do is hold in reset during
>the upload phase).

Hmmm... directly connect to another computer, that is another way to simplify things. Programming of the CPLD would be simplified (done directly from the PC). The only problem is that I liked the fact that both other ideas could store MANY games on a CF and you could select which one you want to play ... the direct connect method wouldn't allow this.

So, if you went over a friend's house you couldn't take all your home-made games to show off (and a few comercial ones if you feel like it).

One allows quicker code developement ... one allows for a more versatile "storage" cart. I don't know, I like both.

However, right now I'm thinking I spend way more time programming than final testing (although that final testing is so annoying that it SEEMS like its longer). So I'm leaning towards the more advanced storage idea (could hold many hacks on it at once!).

I'm still not sure. I'll have to think about it for a bit.

>It stands for "phi 2", and represents the NES's raw 1.79 MHz CPU clock signal
>(I have no idea why Kevin abbreviated it "M2"). The duty cycle is 62.5%, and
>is used as the 6502's bus enable line (active when 1). The use of this signal
>is required to allow the 6502 address lines (& the deocders) time to set up
>the next valid address before the address line data can be considered stable.

So you're saying, the time I have to decode the address and respond with data is:
(1/1.79MHz)*0.625 = 349 ns

Correct?

Thanks, its nice to know what limits the designs need to stay under.

To be clear:

During read cycles, you have just about the entire CPU clock cycle (1/1.79M sec) for your memory device to decode the address, and present valid data onto the data bus (in other words, the only data on the bus that counts is the data there the instant phi 2 goes inactive (at the end of the CPU cycle)).

During write cycles, you have the first 37.5% of the CPU cycle (1/1.79M *0.375 sec) for your address decoders (descrete logic & your memory device) to decode the address properly. The next half of the cycle is when the write is to be engaged (i.e., your memory's write line is activated). At the end of the cycle, the memory device is to latch the data on the bus (store it).

So basically, memory devices being read never really need to use phi 2; they can drive data on the bus for the entire cycle (since it's only what's on the bus at the end of the cycle that matters, anyway). It's only during write cycles when phi 2 must be used (to divide address decode time, and latch time into 2 different time frames).

Since enabling the bus for the entire clock cycle during reads would have required extra circuitry for the CPU's enabling logic, they just used phi 2 as a general enable for both read & write cycles. For faster MPU data buses however, it is better if data is always present on the bus, rather than leave it float half the time (as in the NES's case)).

- BT

>During write cycles, you have the first 37.5% of the CPU cycle (1/1.79M *0.375
>sec) for your address decoders (descrete logic & your memory device) to decode
>the address properly. The next half of the cycle is when the write is to be
>engaged (i.e., your memory's write line is activated). At the end of the
>cycle, the memory device is to latch the data on the bus (store it).

Your post doesn't quite say this, but I assume it's what you mean:
For Writing: The address lines are correct during the full cycle, but the data lines are just floating until the second half of the cycle (when the data to be written is put on the lines). The data is expected to be latched at the end of the cycle.

Correct? If I'm still misunderstanding ... please correct me.

According to the cart connector document:

#50 - PRG /CE (/A15 & /M2)
So it looks like the cartridge will only be told that its being accessed during the second half of the cycle anyway. Correct?

#14 - PRG R/W
Does this mean READ high, WRITE low? Since usually ROM is just there, I think it would make more sense to have those reversed. Can you set me straight on this one?

Thanks for taking time to answer my questions.

>Correct? If I'm still misunderstanding ... please correct me.

You've got it.

As for your other questions, please see a recent post I made, which should answer your questions (it's in the "NES hardware development" thread):

"http://nesdev.parodius.com/cgi-bin/wwwthreads/showpost.pl?Board=nesdev&Number=780&page=0&view=collapsed&mode=threaded&sb=5#Post780"


- BT