kidkratos, I'm sorry. I don't know the answers to your questions. I was hoping someone more knowledgeable would pipe up. We'll cross our fingers.

Beau, the way I would probably code your problem is like this:

1.) Check to see if your block is overlapping the key sprites in any location. If so, set a zero page variable flag to 1.
2.) Have a subroutine constantly checking to see if that variable is 1. If so, move that sprite(s) in exactly the same way your controller is moving your block.

When sprites need to be moved off screen, you can just move them to #$FF in either the x or y position. Just keep in mind that if you have too many sprites moved to #$FF on the same scanline, you're going to run into problems!

As always, my email address is always open to you, friend.

Kevin, thanks for the response and no worries.

I'm assuming that the support just isn't there yet for nesasm. I'm guessing it's just a matter of time before someone adds it, maybe I will if/when I have some time... for now, I'm just using ca65 / nintendulator which has the symbol debugging I was looking for.

Thanks Kevin! The whole check variable thing was very helpful, I had not thought of doing things that way. Be on the lookout for another email this evening.

In looking through some examples of games I have noticed that with the switch to more banks there is often also the inclusion of more "reset vectors" sections in the code at the end of some of the banks, but not others. Does anybody have any idea as to where or why to place them different places? Thanks.

Oh, and in case "reset vectors" is not the right name, what I am talking about is this business:

.org $FFFA ;first of the three vectors starts here
.dw NMI ;when an NMI happens (once per frame if enabled) the
;processor will jump to the label NMI:
.dw RESET ;when the processor first turns on or is reset, it will jump
;to the label RESET:
.dw 0 ;external interrupt IRQ is not used in this tutorial

I think that is because they switch the PRG banks with the interrupt vectors in them, and they are always needed. How else would you get to your NMIs and your IRQs?

Depends on the mapper!

Some mappers like UNROM switch only the first 16KB of PRG ($8000-BFFF) and keep the last 16KB ($C000-FFFF) as a fixed bank.  In those cases the vectors are only needed in the last 16KB of PRG.

Some mappers like AOROM switch all 32KB ($8000-FFFF) at once.  In those cases the vectors need to be in every 32KB of PRG because you don't know what bank will be active when NMI/IRQ/reset happens.  Hitting the reset button does not change the active bank for almost all mappers, so vectors must be available in any bank that could possibly be swapped in.

Well that certainly makes sense, I was not expecting such a clear solution  Thanks!

So I managed to fool around with some code and get NESASM to spit out a file that my NES emulator can run, which was super exciting.

So, eventually I might actually get a game together, and I might want to put it on a cart, even a repro one.

1) Is this possible using the code I write for NESASM and/or the file NESASM produces?

2) If so, how do I actually get my game from my computer to the cart?

1.) Yes.

2.) PowerPak. (Or bug a person who makes reproductions. If you are deadset on doing it yourself, you'll need someone more knowledgeable than me!)

Hey guys,

I'm starting to make repros of particular roms for snes. I'm looking to complete dragon quest 1,2,3,5,6 as well as chrono trigger crimson echoes, terranigma and others ! From what research I have conducted I realize most these games will esquire different EPROMs 32,36,40,44 pin chips. Can someone point me in the direction of a cheap programmer that will do most of these chips with minimal of adapters being purchased. Also If someone could point me in the direction of the software needed to remove the headers,checksum, pan out a file to a larger size or anything else anyone may know about putting roms on existing carts.

Thanks in advance for any responses

Hey,

I have a question regarding preparing files to be burnt to eproms. must the header always be removed? if not how do you know what cases to remove the header? what is the point, is it just to make the ROM a specific size? Next I was wondering about checksum. Does it always have to pass in order to have a working file burnt to a EPROM ? cause I noticed when I apply certain patches to certain roms the checksum then fails but the emulator will still play it quite fine. Would this be the case if put into a real SNES ? Also what would someone with experience suggest to use to modify and correct checksums ?

Thanks for your help

I think you are a bit confused about what this thread is for. 

It is about programming homebrew games for the NES, not making reproductions.  There are lots of good resources out there, try searching around.

I can only assume that you're working with the SNES, and referring to the SMC header.  That header itself is not part of the ROM space and is not actually used by any emulator (that I know of).  From what I know, emulators tend to rely on parts of the registration data inside the ROM at address space $00:$FFB0-$FFDF in order to figure out how the ROM is mapped to memory, and if any add-on chips need to be emulated.  So yes, any headers like the SMC one need to be removed.

As for the checksum, an SNES emulator may check it and the complement check to make sure the ROM contents are not corrupted as a courtesy, but this is not required in order for the ROM itself to run as long as the ROM contents are not corrupted.  The SNES itself doesn't do anything with the checksum.

Here's my question:

How do ya make repros?

This isn't exactly programming-related, but I just opened up an Ogre Battle snes cartridge and saw 3 of the big chips on the right side...is that normal? I don't recall seeing games with 3 of the large chips, even on the big boards for games with save batteries.

edit: got antsy, made a thread: http://www.nintendoage.com/forum/...

OK so I am trying to make my sprite duck. I really need help, cant sleep until i figure this out, what am i doing wrong here. I am also JSR'ing to LookForDuck in my playing engine. When I press down, nothing is happening.

LookForDuck:
LDA DownHeld
CMP #$01
BNE .End
LDA $0301
CMP #$1B
BCC .Left
LDA #$01
STA PlayerisDucking
RTS
.Left:
LDA #$02
STA PlayerisDucking
.End:
RTS

Ducking:
LDA PlayerisDucking
CMP #$00
BEQ .End
CMP #$01
BEQ .Left
CMP #$02
BEQ .Right
.End:
RTS
.Left:
LDA DownHeld
CMP #$01
BEQ .ResetL
LDA #$09
STA $0301
LDA #$0A
STA $0305
LDA #$19
STA $0309
LDA #$1A
STA $030D
RTS
.ResetL:
JSR ResetSpritesLeft
LDA #$00
STA PlayerisDucking
RTS
.Right:
LDA DownHeld
CMP #$01
BEQ .ResetR
LDA #$29
STA $0301
LDA #$2A
STA $0305
LDA #$39
STA $0309
LDA #$3A
STA $030D
RTS
.ResetR:
JSR ResetSpritesRight
LDA #$00
STA PlayerisDucking
RTS

EDIT: I ended up figuring this out guys, here is the corrected code, also had to JSR to Ducking in game engine.

One question that has been eluding me for a while has been the practical difference between CHR RAM and CHR ROM. I have read through the NESDEV material on the subject, and also several threads, but no one seems to be too interested in breaking down the differences in practical terms, i.e. how they actually affect game design and for which types of games each is best suited. Instead the material seems to focus more on the exceptions to the rule and fancy technical effects (which are interesting, but way down the line for me). I understand that one's choice can be made for them through the choice of a mapper, but in the case of the MMC1 both options exist (looking at INL's flashable options). So, for those who have done some programming, what has your experience been? What influenced your decision, and what benefits/limitations came with your choice? Also, if you have any recommendations for someone looking to do an overhead adventure game with a lot of tile data, I would be curious to know your thoughts on this as well

Lastly, when choosing a flashable board for testing purposes, is it all right to have too high of specs? Would the best bet for development be to get the largest board possible, or will this cause complications? The answer may be obvious, but I thought that I would check before purchasing (assuming that I can make a decision on the CHR RAM/ROM issue).

Thanks for any and all help!

CHR-RAM can be written to as well as read from, whereas CHR-ROM is read only and all you can do is swap it out, usually in 4kb sized banks (I believe there are smaller and larger configurations of chunks that can be swapped out, as well).

I like CHR-RAM for my games because it allows maximum deduplication of graphics data. Say you have some background graphics for a given area or level, and then you proceed to a new area or level and most of the graphics are the same but a couple of tiles are different. With CHR-ROM, unless the bank swapping granularity of your mapper is sufficiently high this will force you to duplicate a lot of your graphics just so you can show those couple of new tiles. With CHR-RAM, you can simply keep all these chunks of background data separate, and load them in different combinations based on what area or level you are loading up. The same thing applies for sprites, in fact this application is probably much more commonly used for sprites than for background data.

For most existing mappers, typically CHR-ROM was used for background animation because of the bank swapping capability. But with new mappers being developed by bunnyboy and others, we can now bankswitch with CHR-RAM, which essentially gives us the best of both worlds. To me, I cannot at the moment envision any real benefits of CHR-ROM over CHR-RAM. I think CHR-RAM is probably the best option for homebrew game development. I have more experience with it though so I'll let others comment on any details I may have left out.

^^ Made good points. However, I'd say that from an actual build mode, assuming it's your first couple games (which are typically NROM or some other simple mapper), you should probably stick with CHR-ROM. It takes a pretty substantial homebrew game to use all of the tiles in an NROM or CNROM cart even if you're trying. AND the doner carts are much easier to find and cheaper.

But if you're going out and making a big platformer or porno or something, CHR-RAM is the way to go. There's no exact answer to your question, it depends on the game.

Plus, new PCB's have RAM, AND 32KB of it standard. It's so flexible for the programmer, and easy to get carts made using. It's great.

To all that replied, here and privately, thanks for your input. I had initially decided on using CHR ROM, due to many of the games that I enjoy using that format, but it now appears that CHR RAM does indeed seem to be the way to go. I made the move to MMC1 a while back after running out of room with NROM and not being able to plan ahead for battery saves with UNROM. My plan is to use INL's boards rather than relying on donors (mostly due to my lack of skills with that process; impressive stash of carts/boards though MRN), so that has influenced my decisions as well. I would like this to be an open question, however, so if you have thoughts I am still interested in hearing them. Just wanted to say thanks for those who have taken the time to respond so far!

I'm a bit new to NES programming, so after doing some research when some programming veteran brought up the term "hardcoded OAM", I discovered my sprite data was hardcoded (my sprite is 16x16 pixels). I was wondering how I could make it non-hardcoded (hopefully this all makes sense to you). I was told to draw all the other sprites around the main sprite I use for movement, collisions, updates, etc. but I am not sure how todo that. Here is my sprite drawing routine:

PlayingSP: ; These are the sprites during the game
;vert tile attr horiz
.db $B0, $00, $00, $20
.db $B0, $01, $00, $28
.db $B8, $02, $00, $20
.db $B8, $03, $00, $28
.db $37, $37, $37, $37 ;end    <- Ignore this.

http://nintendoage.com/forum/messageview.cfm?catid=22&th...

Just to clarify, that isn't a drawing routine.  That's just the sprite data.  The actual drawing routine (since I'm guessing that's the code from my lessons that you're using) will be at a subroutine called "LoadSprites".

Okay, I think I have incorporated everything within the link above.  I haven't run into any problems, so I think I got it working.  That brings me to my next question:  I'm trying to make my 16x16 sprite flip when I press left (these sprites are oriented to the right).  I know how to make the graphics for individual sprites flip, but what I was wondering was how to swap the places of the vertical 8x16 sprites (they appear vertically fragmented) so that it looks like a proper flip.


Oh, thanks for clarifying that.  (I'm still trying to wrap my head around how everything in the code works, mostly the stuff I haven't learnt much about, but it's gradually becoming clearer to me.)