nesdev.org

Release Candidate 0.5-rc2 is out now. Per usual I've updated the first post with the new distribution package which now also includes full sources to avoid confusion. The project page has also been updated with the new distribution and documentation for the new features. New Features The import stat...

Yea, ca65 is a beast. Glad you're up and running now.

I can get myself stuck in SMB a number of ways

Isn't that XyzxY in the US?

Also, this whole thread has been NES porn. I'm all hunched over my monitor at work trying not to let my co-workers see what I'm looking at

Funny how that works

Thank you everyone for your responses! I hope to be able to show you all something cool I'm working on in a month or two regarding this.

You could just prep 4K chunks for GB and SP patterns that contain your alternate tiles and bank them in based on level. That way you replace only what you need to.

ROM hacks don't have to be very practical after all

tepples wrote:Tool building has clearer requirements and needs less art.

Word.

Plus, once I'm done with the tool I'll be able to pump out games lightning fast!

No worries. NES development has a lot of woopses involved More experienced developers don't necessarily have fewer, they just get better at debugging them on their own. I think you're skill is coming along very quickly comparatively. Do you have any prior experience with assembly?

Well with MMC3 you could always use bankswapping to get more CHR space.

That's pretty cool that they had some sort of shared libraries back in the day. When I was working on my NES software projects (before falling into the tool building trap ) I used a similar, all-be-it more simplistic format for my PPU updates.

Before you get to object to object collision detection you really need to think about limiting the scope of collision detection. CPU cycles are at a premium on the NES, and you really can't afford to test every object against every other object every frame at 60 FPS. Instead you need to use object g...

Very cool! Was this at all connected to the recent discussion about converting SMB to use a mapper? When I get my new MMC3 dev board in I'm going to have to give this a go

Right, so parts that say "5V tolerant I/O" are designed for 5V logic, those that just don't melt when given 5V I/O signals are not. Got it.

The chip you have needs a 21-volt power supply during the programming process. This is common with very old UV EPROMs. My guess is the GAL G540 does not support this, as it is a USB-powered programmer (USB only provides 50 mA at 5V). Sorry about the confusion :( this is a pin-compatible chip that is...

Is there an easy way to tell if a LVTTL chip will be 5V tolerant? And what does 5V tolerant mean exactly? I've seen a lot of discussions about parts with maximum tolerances on their I/O pins specified at 4.6 volts being "5V tolerant" because of how the pins are connected to ground inside t...