I have an NES with a CopyNES installed I've been using to dump roms, mostly for use in emulators. Recently, I decided it would be fun to get into the development scene and I started programing some simple programs in my emulator using NBASIC. I would like to try running these on a real NES, with something more permanent than a powerpak lite. My programs are simple and I have a whole bunch of Original Mario Bros donor carts laying around (3 total). Is there anyway I could convert these to makeshift dev carts? I'm totally new to this, but I know a guy who can do the soldering if I just had a simple guide for this cart. I know the hardware on it is limited, but I honestly don't really care. Is it possible?
Thanks in advance for your patience, I am totally new to the hardware side of things.
Sure if you have a copynes it's real easy. I could give you detailed instructions......but you could just download the copynes program + files from kevtris's site (he originally made it)......a txt file describes how to make an nrom dev cart
(his site is
www.kevtris.org )
Thanks a bundle my friend, just what I needed!
I found a guide to get a ram cart built, but I want something more permanent, perhaps EPROM based. Would these parts serve fine for that purpose if I just substituted them in in the RAm cart guide, or am I oversimplfing things? Some of thing pins don't seem to match up so I'd like to check first.
http://www.futurlec.com/Memory/27C128-120.shtml
256kbit RAM and EPROMs pinouts are almost the same, only the WR pin doesn't exists on ROMs, and the P pin doesn't exist on RAM (both should be put to VCC anyways).
My concern was the guide I read seemed to refer to pin 27 as the VCC connector, and the schematic I linked refers to the VCC as pin 28. Also, there seem to be a few other things that just don't sound right to me. If anyone could kindly confirm/deny that the above chip could be made to work, I'd be most thankful. Otherwise, advice on where to obtain an appropriate chip is also welcome.
Thanks again guys.
It could be made to work. Pin 28 is VCC, but pin 27 is P (or /WE for RAM) which is only used by the EPROM programmer so it should be put to VCC on the cart too.
Yes. I hope I'm not sounding redundant, but I'm going to clarify one last thing.
This sentence in the NROM ram cart guide concerns me:
Quote:
You will now have to solder a small piece of wire on the bottom of the board across pins 26 and 27 of the 8K RAM chip. This will connect +CE to VCC.
If you look at the scematic, pin 26 is A13, not the Chip Enable (it's pin 20 according to the schematic). Pin 27 is P, not the VCC. Why are we soldering them together? Am I just missing something huge here? Probably, but I don't want to order these parts and just ruin a cart either.
On 8kb (64kbit) SRAMs (6264 compatible) pin 26 is positive CE. Since the RAM is 8kb the higher Adress is A12. The shematic you linked is a 16kb (128kbit) EPROM, which does have an A13 at pin 26 instead. You don't want to tie it to VCC unless you want to restrict yourself to 8kb.
For NROM carts normally no rewiring is needed. It's only needed if you rewire a NROM-128 to a NROM-256 or the other way arround. It looks like you're looking for NROM-128 because of the 16kb (128 kbit) EPROM.
Bregalad wrote:
On 8kb (64kbit) SRAMs (6264 compatible) pin 26 is positive CE. Since the RAM is 8kb the higher Adress is A12. The shematic you linked is a 16kb (128kbit) EPROM, which does have an A13 at pin 26 instead. You don't want to tie it to VCC unless you want to restrict yourself to 8kb.
For NROM carts normally no rewiring is needed. It's only needed if you rewire a NROM-128 to a NROM-256 or the other way arround. It looks like you're looking for NROM-128 because of the 16kb (128 kbit) EPROM.
Thanks for all your help, I think I am starting to understand. I need to get an 8KB EPROM chip for the CHR memory, and then a 16KB EPROM chip for the PRG memory, just like the original board. That should make no rewiring neccesary. However, the guide calls for a "32KB SRAM chip." Should I sub in a 32KB EPROM Chip, or is that unnecasary and a 16KB EPROM chip like the one above will do just fine? I want the pinouts to remain the same as in the guide so when I give it to my buddy to solder, he can follow it easily. I understand the electronics pretty well, just can't wield the soldering iron worth anything.
EDIT: Here's the other 8KB chip I was looking at. It lists pin 26 as "NC" or "Not Connected." Is it just me or is that not right?
http://www.futurlec.com/Memory/27C64-200.shtml
It's right NC means the pin is unused.
You can get both 16kb and 32kb EPROM and solder them without ANY rewiting to get a 16kb PRG cart, just if you get 32kb remember to programm your data in the SECOND half of the ROM (since A13 will be put to VCC by the board).
If you want to transform your board into NROM-256 to use all 32kb of PRG, you'll have to bend up pin 27 and wire it to actual A14 on the cart connector so you can use all of 32kb.
I think I understand most everything now, but just one thing is still bothering me.
Shouldn't pin 26 be CE thought rather than "not connected"?
It's a positive CE for RAM and unused for 8kb ROMs.
So there is no positive chip enable on an 8kb rom? Or is pin 20 on that schematic the positive chip enable?
(I'm pretty sure this is my last question, thanks for your patience)
One note....are you using eproms? Cause you cant program those using copynes (iirc) since they need a special voltage to be programmed.
Jeroen wrote:
One note....are you using eproms? Cause you cant program those using copynes (iirc) since they need a special voltage to be programmed.
Could someone confirm/deny this? I may either have to cancel an order, or order an EPROM programmer (I think that latter). Any advice either way? What should I be using if not EPROMs? Would non-volatile SRAM work? Flash? and also, what's a good programmer?
R-T-B wrote:
Jeroen wrote:
One note....are you using eproms? Cause you cant program those using copynes (iirc) since they need a special voltage to be programmed.
Could someone confirm/deny this? I may either have to cancel an order, or order an EPROM programmer (I think that latter). Any advice either way? What should I be using if not EPROMs? Would non-volatile SRAM work? Flash? and also, what's a good programmer?
Correct, you cant use a copynes to program them, I would just cancel
As I thought, it's too late to cancel the EPROM order, so I ordered a simple programmer. Should work fine. I already have the UV Light eraser so it isn't SO bad. I need a programmer anyways.
Ok, I installed a ZIF Socket for each rom chip and cut a hole in the cart. When I program my EPROMs however (and they are verifying and all that, I'm using Willem PCB5.0), all I get is a grey screen. Any idea why? I'm socketing the roms directly with no pin modifications, and using the 16kb and 8kb roms I listed above in the links. What's the deal? I thought I could wire these directly.
Feel free to call me a dumbass, I'm hardly good at this, lol.
Are you inserting the roms properly? Did you set the jumpers correctly? It could be that your nbasic programs are just not compatible with a real nes.....(nbasic really isnt that good of a programmer platform)
I find that hard to believe... See, all it does is scroll a line of text. Seems like it should do something...
And yeah, I'm looking into learning ASM for the 6502. Shouldn't be that hard. This is just a test.
The roms are inserted correctly. with pin one oriented properly like the original chips. These are EPROMs, I imagine they should be pin for pin compatable, no?
They should be.....that's weird...check for cold joints.
Got out my multimeter and working on that. Reburning the roms too for good measure with a full 10 minute erasure and blank test.
Uv eraser right? (I thought you said they were uv eproms) Also....can you post the program here? We could check to.
Yep, UV light eraser. I'll post the program if this doesn't work, know in 15 minutes. It's really simple.
It works now. I had the mirroring set wrong for the board.
I'm going to post the program now. I thought I had it working, but behavior in an emulator and on my devcart are drasticly different. It works fine in an emulator, but just draws a whole bunch of jibberish on a real NES. Try it and you'll see what I mean. It might just be that I used nbasic, but the program seems so simple I don't see how it couldn't work (It literally scrolls a line of text based on an example from Bob Rost's site). The archive attatched contains ines binaries, .asm source, and nbasic source versions. Could someone please point out the obvious to me, as I'm sure it probably is very simple and I am just missing it.
Thanks again all.
http://21gunsoftware.com:8080/PRG.zip
I tried your program in Nintendulator, Nestopia and FCEUX.. seemed pretty glitchy in all of them. Try to make it work in those emus correctly before trying it on devcart.
Couple of things that are obviously wrong:
- You have to wait for couple of frames at the start of the program to let the PPU "warm up" (there should be an example in the NesDev wiki). Also it is good practice to do a bunch of other init stuff, like disabling interrupts etc if you dont need them.
- Your vwait routine seems broken/strange, what is all that counter stuff inside the loop?
- You shouldn't even be using polling for checking for vblank, as you will miss vblanks every now and then with this method. Instead detect vblank using the NMI IRQ.
- All your vectors point to "start", don't do that... instead have those vectors point to an RTS instruction.. again good practice.
There are other oddities/problems too but I'm too tired to list them all...
Oh man, I forgot entirely about those counters... Haha, thought I had pulled them out. They were meant to slow the scroll speed. Don't worry, I'll start with ripping those out. I'll also get those emulators and see if I can't get more consistent results.
Actually, I was unaware of the wiki here and mostly working by reverse engineering Bob Rosts works. Thanks for the great pointer to that resource.
Thanks a bunch. Just wanted reassurance it wasn't a hardware problem, and it doesn't look to be one. After some reading, I immediately see several things wrong.
If you want to verify it's not a hardware problem your best bet it is to try it with a program you know does work, any commercial game ROM will do (as long as it uses the same mapper of course).
That or put a known-working, tested-on-an-actual-PowerPak homebrew game on there.
The original mario bros roms work, so it isn't hardware...
Still, it's odd. It behaves like I want in Nintendulator, but not in Nestopia. In Nestopia, it acts like it does loaded in my dev cart. However, on the PowerPak CF card, it acts like it does in Nintendulator, just like I want.
That can't be normal, can it? I mean I know my source code is a soupy nbasic mess, but should the powerpak act just the same as my devcart if it can run Mario Bros?
Very strange... but whatever, I'm going to try to code a different example in asm for the 6052.
If you see differences between a multicart (like the PowerPak) and a single-game cart running the same ROM on the same NES, the multicart's menu is probably initializing the hardware for you. Two things that the PowerPak does but you may or may not be doing include 1. setting the RAM locations your program uses to a known state, and 2. waiting for the PPU to stabilize.
That's it then.
I'm starting to write the program in assembler. Pretty sure that with that and some good coding practices, I can get it to work. Baby steps to be sure... But hey, it's a good summer project.
I'm familiar with most Higher level langauges, but not assembly. Well let you know how it goes. Using this guide at the moment:
http://patater.com/gbaguy/nesasm.htm
R-T-B wrote:
I'm familiar with most Higher level langauges, but not assembly.
C, for example, guarantees that your program's statically allocated variables will be filled with zero or NULL values before main() starts. To simulate this in 6502 assembly:
Code:
lda #0
tax
@clear_ram:
sta $00,x
sta $0100,x
sta $0200,x
sta $0300,x
sta $0400,x
sta $0500,x
sta $0600,x
sta $0700,x
inx
bne @clear_ram
Quote:
lda #0
tax
@clear_ram:
sta $00,x
sta $0100,x
sta $0200,x
sta $0300,x
sta $0400,x
sta $0500,x
sta $0600,x
sta $0700,x
inx
bne @clear_ram
Thanks for that code snippet. Using my now rudimentary assembly skills, I mostly understand it. You are simply incrementing the x register and storing 0 throughout the memory banks using the 0 stored in the acumulator. One question though (and I probably should know this, but it isn't coming to me), what's the "tax" command do?
TAX: Transfer Accumulator into X
Here is a list of the documented 6502 opcodes, with descriptions. Now the 6502 instruction set should not be mystery to you.
Beautiful, thanks. Your guys patience seems infinite, and I appreciate it. I'll post my first program when I finish it, promise.
If anyone is curious as to my progress and wants to offer tips/tricks (basically tell me what I'm doing inefficinently), here's my latest product. I can move a (dumb) sprite!
Yet to test it on a real NES, but my guess is it will work.
http://21gunsoftware.com:8080/PRG2.ZIP
It's a lot of cut and paste work, but I understand it pretty well so that shouldn't matter in the long run.
Just another newb question, I recently began assembly of a Reproboard and was wondering what the differences between U*ROM and A*ROM is mapper wise? Which would be better for development? Is it simply the bank size? If so, why the extra mapper chip for U*ROM on the Reproboard?
The extra chip in U*ROM implements the fixed bank. A fixed bank is useful for subroutines that need to read data from more than one bank, or for code or data that a background process needs. (On the NES, the background process is either DPCM sample playback or an interrupt handler.)
Roughly:
- B*ROM is U*ROM without the fixed bank
- A*ROM is B*ROM with one-screen mirroring
There is two big differences between U*ROM (mapper 2) and A*ROM (mapper 7).
The first is that U*ROM have switchable banks at $8000-$bfff, and a fixed bank at $c000-$ffff, while A*ROM will switch the whole 32k $8000-$ffff at once.
The second is that U*ROM have either horizontal or vertical mirroring (but only once per cart, it can't be changed by software) while A*ROM have one-screen mirroring.
Note that if you want to banswitch like A*ROM, but have a "traditionnal" mirroring type instead of A*ROM one-screen mirroring, you can use B*ROM (mapper 34 I guess) which only Deadly Towers used. Is is techincally possible to have A*ROM style 1-screen mirroring and U*ROM style bankswitching, but no Nintendo card did that, you'd as well use the MMC1 to do that.
There is not one better than the other, it all depends on your personal preferences, and maybe how your game is going to scroll for the mirroring.
The game I'm writing only has 32kb PRG so no banskwiching, so I can't give you much advice on it.
As far as I can tell, the main advantage of A*ROM style bankswtiching is that banks are very large, so you can have more data in them at once, for example you can place all maps of the game plus the code that deals with maps in one banks, all music of the game plus code that deals with music in another, etc...
Bankswitching will be a little tricky however because it switch ALL programm space at once, you may consider reading
this to give you ideas.
U*ROM bankswitching is usefull if you want some subroutines to be always accessible quickly witout doing any bankswitching, typically interrupt routines, or a routine that does things close to hardware such as loading the palette, mapping sprites to RAM, etc... You put them in the fixed bank ($c000-$ffff) and they are always there. Also you only need to have one time your interrupt vectors and interrupt routines in ROM which simplifies things a lot.
The main drawback is that the fixed bank is limited to 16k so you'd want to cleverly thing of what to put in the fixed bank and what not, but also swappable banks are smaller, so there is a chance that you won't be able to place for example all maps of the game + code dealing with maps in 16k, you'll either have to split the maps in 2 banks and have the code dealing with maps in the fixed bank, or have it it one of the 2 banks, and doing very frequent bankswitching when dealing with a map which is in another bank (this is CPU intensive).
Hope that helps you to see the 16k/16k bankswtiching VS whole 32k debate. As a side note, GB/GBC games using MMCs all gets a U*ROM style bankswitching so if you're going to develop for those systems as well and want to learn less programming techniques this could be a element to consider.
Thanks for the info. I'm thinking I'll just stick with what is simple and go with U*ROM. Should be simpler to implement bankswitching from.