Newbie advice on making a simple dev cart.

[tepples]

That or put a known-working, tested-on-an-actual-PowerPak homebrew game on there.

[R-T-B]

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.

[tepples]

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.

[R-T-B]

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

[tepples]

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: Select all

  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

[R-T-B]

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?

[Jarhmander]

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.

[R-T-B]

Beautiful, thanks. Your guys patience seems infinite, and I appreciate it. I'll post my first program when I finish it, promise.

[R-T-B]

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.

[R-T-B]

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?

[tepples]

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

[Bregalad]

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.

[R-T-B]

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.