This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Jump Physics

Jump Physics
by on (#69560)
Just wanted to get some input on my character physics model before I move on. There is no real collision detection yet, so it won't fall down the hole.

http://www.yibbleware.com/nes/cartlemmy-test-0.3.nes

by on (#69561)
There's something weird about the jump... It looks like at one point in the way up it gets an extra boost, and that doesn't look/feel very natural... Maybe this has to do with the way you implemented the variable jump height.

Other than that, the controls feel OK, better than a lot of commercial NES games (many of them didn't even have any sort of acceleration, inertia, etc). Once you implement platforms we can stand on it will be easier to judge the controls I guess.

by on (#69562)
Cool, thanks for the feedback! :)

by on (#69567)
Looks good. If it looks good, it is =D. I'm not sure I felt what tokumaru felt during jumping, if I move horizontally, the jump produces a nice arc.

*edit* found something. If you jump, then release and hold A again before landing, the dot will jump back into the air again. I think the standard way to resolve this it to keep a history of button presses, and check for a transition from released to pressed, rather than simply whether it is pressed or released. It looks like you may have this partially implemented, since the dot will stop jumping if you hold down A indefinitely. Not sure if that was what you were looking for---you may have had this refinement in mind already.

by on (#69571)
Gradualore wrote:
Looks good. If it looks good, it is =D. I'm not sure I felt what tokumaru felt during jumping, if I move horizontally, the jump produces a nice arc.

Cool, yeah I noticed the same thing about the arc. I think that, like tokumaru said, once the platforms are in place it will be easier to tell. I probably should've waited to post it until then.

Gradualore wrote:
*edit* found something. If you jump, then release and hold A again before landing, the dot will jump back into the air again. I think the standard way to resolve this it to keep a history of button presses, and check for a transition from released to pressed, rather than simply whether it is pressed or released. It looks like you may have this partially implemented, since the dot will stop jumping if you hold down A indefinitely. Not sure if that was what you were looking for---you may have had this refinement in mind already.

Hehe, yeah I just noticed that as well. I am just resetting the "don't allow another jump" flag in the wrong place (oops!).

I'm getting more nervous as the implementation of the slopes approaches

:shock:

by on (#69574)
Before you get too far into development, you might want to change mirroring to scroll horizontaly, unless you want to....scroll vertically?


So far looking nice, and yeah, the jump if more favoring of the Y height, and not letting you get vary far horizontally when you just so high. I think making it even would be great, but keeping it how it is could be your games "trademark" or something along those lines. Whatever it is, your doing great! Keep it up. :)

by on (#69576)
65024U wrote:
Before you get too far into development, you might want to change mirroring to scroll horizontaly, unless you want to....scroll vertically?

Yeah, I plan on letting it scroll up and down 2 screens vertically as well. I still have to work on the tile update so there's a little less artifacts at the right edge of the screen. As far as I understand there is not way to totally get rid of it (unless I use sprites to cover up the edge, but I don't want to waste my sprites on that.) For me the artifacts are worth having vertical and horizontal scroll.

65024U wrote:
So far looking nice, and yeah, the jump if more favoring of the Y height, and not letting you get vary far horizontally when you just so high. I think making it even would be great, but keeping it how it is could be your games "trademark" or something along those lines. Whatever it is, your doing great! Keep it up. :)

Are you saying perhaps I'm letting it jump too high? I was thinking the same thing. I was thinking maybe I would make it jump less high from a stand still and jump higher (like the way it is now) when running. I also want to implement wall jumping :)

by on (#69578)
For scrolling multiple ways, you might want to make some extra RAM on the cart and use One-screen mirroring.


And yeah. Not that the jump height seems too high, just for the X movement you get during the time is very small compared to it, so yeah....sorta too high I guess, but maybe making the X movement a tad more will make it more even. :)

by on (#69579)
65024U wrote:
For scrolling multiple ways, you might want to make some extra RAM on the cart and use One-screen mirroring.

One-screen mirroring? Hmm, I'm not familiar with that. I'll have to look it up.

65024U wrote:
And yeah. Not that the jump height seems too high, just for the X movement you get during the time is very small compared to it, so yeah....sorta too high I guess, but maybe making the X movement a tad more will make it more even. :)

Cool, did you try it with the b button down ?

by on (#69580)
cartlemmy wrote:
As far as I understand there is not way to totally get rid of it (unless I use sprites to cover up the edge, but I don't want to waste my sprites on that.) For me the artifacts are worth having vertical and horizontal scroll.

What mapper are you using? If you have IRQs, hiding the top and bottom 8 scanlines is very easy, and will get rid of all the glitches. If you don't have IRQs you can still blank scanlines, but that will require timed code and/or sprite 0 hits. Fact is it is indeed possible to completely get rid of scrolling artifacts, it's just not the simplest of the tasks. In my game I have a timed NMI routine and I blank the top 16 scanlines (and I also use the time for extra Vblank transfers).

65024U wrote:
For scrolling multiple ways, you might want to make some extra RAM on the cart and use One-screen mirroring.

If by extra RAM you mean 4-screen, then yeah, that would be the simplest (from the point of view of the software, I'm not sure how hard it is to modify a cart) way to get rid of scrolling artifacts. One-screen on the other hand would make things worse, because you'd have glitches both horizontally and vertically.

by on (#69583)
tokumaru wrote:
What mapper are you using?
I think it's mapper 3. I want to use the one that has the extra WRAM so I can compress my maps, but I haven't really got to that point yet.

tokumaru wrote:
If you have IRQs, hiding the top and bottom 8 scanlines is very easy, and will get rid of all the glitches.

Ah yes, that seems like an elegant way of handling things. Right now I'm at the "wow I can't believe I'm getting anything to work phase", so changing anything that I've already written seems a tad scary. But It's nice to see things in a new light, I think I'm finally starting to understand this NES Dev stuff. I might graduate from noob school by the end of the year even, lol.

Thanks to everyone for your help. This community is great!

by on (#69584)
cartlemmy wrote:
I think it's mapper 3. I want to use the one that has the extra WRAM so I can compress my maps, but I haven't really got to that point yet.

Mapper 3 (CNROM) doesn't have WRAM. Theoretically, you can add WRAM to any board you want (although this community can't seem to agree on the best way to do it, there have been some suggested circuits), but no official CNROM carts have it. Maybe you meant MMC3 (mapper 4)? Either way, WRAM isn't absolutely necessary for handling compressed maps, there are plenty of other options: on-the-fly decompression from ROM, partial decompression (only the part of the map that surrounds the player needs to be in RAM), and so on. But if you want to go with WRAM, that's a valid choice. It will make the cartridges more expensive though, in case you ever decide to manufacture them.

Quote:
But It's nice to see things in a new light, I think I'm finally starting to understand this NES Dev stuff.

I think you are doing well... most people here (me included) take years to show any results. It's usually because of lack of free time though, rather than lack of knowledge or potential.

by on (#69586)
tokumaru wrote:
Maybe you meant MMC3 (mapper 4)?

Ah yes, mmc3. That's it.

tokumaru wrote:
Either way, WRAM isn't absolutely necessary for handling compressed maps, there are plenty of other options: on-the-fly decompression from ROM, partial decompression (only the part of the map that surrounds the player needs to be in RAM), and so on. But if you want to go with WRAM, that's a valid choice. It will make the cartridges more expensive though, in case you ever decide to manufacture them.

good point. I'd like to have the option to reproduce the end product when the time comes, but I also really want to have destructable backgrounds. I guess I just need to weigh my options.

by on (#69588)
cartlemmy wrote:
Ah yes, mmc3. That's it.

That's another aspect to consider if you plan on making carts, since AFAIK there aren't MMC3 clones available for building new carts, meaning that for each copy of your game you are gonna have to destroy an original MMC3 game.

tokumaru wrote:
good point. I'd like to have the option to reproduce the end product when the time comes, but I also really want to have destructable backgrounds. I guess I just need to weigh my options.

If you want to be able to destroy the whole level, then yeah, you are going to need the extra RAM, but if it's something around 2000 blocks or less you can probably remember the states of those using just the regular RAM. You just have to create a way to associate the groups of destructible blocks to the bitmaps that represent their state.

In case it looks like it, I'm not trying to talk you out of using extra RAM, I'm just presenting some options you might not have considered, so that you can make an educated decision, or "weigh your options", like you just said.

by on (#69594)
tokumaru wrote:
Fact is it is indeed possible to completely get rid of scrolling artifacts, it's just not the simplest of the tasks.

And how hard is it with a status bar? Sonic doesn't use one, but SMB3 does.

cartlemmy wrote:
I also really want to have destructable backgrounds.

We had a discussion on those. Mapping destruction state to game objects is a tradeoff of memory vs. geometry restriction vs. code complexity. I came up with a compromise in which the engine restricts the map geometry to have only one destructible object per column of the map.

by on (#69596)
tokumaru wrote:
That's another aspect to consider if you plan on making carts, since AFAIK there aren't MMC3 clones available for building new carts, meaning that for each copy of your game you are gonna have to destroy an original MMC3 game.


If you partner with RetroZone it's pretty likely that a MMC3 clone can be put on a CPLD. Just because they don't sell it as parts doesn't mean that it can't be made. If you have a compelling enough game I would imagine the effort would be made to get your game cartridges built.

Now if you wanted something more fancy like MMC5, then you're back in that boat of destroying cartridges as no one has cloned the MMC5 and I doubt it will happen anytime soon.

by on (#69600)
Yeah, and since the best thing about MMC5, The extra sound, has been limited on US consoles, it seems like a waste anyway. And since 8x8 background blocks are nice, but hard to see anyway, it's kinda a waste, too.


And as for a destructible map, I was thinking of a clone on Miner Dig Deep on Xbox 360, how it could be done on NES with saving a huge map. You could fit a pretty large map ON NES in RAM if you use SXROM with 32K SRAM. You could also hack up the board with a couple wires to use a 1MB ROM for your program, 32K switchable SRAM and CHR-RAM for graphics. Heck, you can use a 512K ROM with 64MB SRAM if you hacked it in even more. I thought of this with MMC1, since scanline on MMC3 means nothing to me as I am not good enough to use it yet, so MMC1 is what I looked at this with. And thats pushing the MMC1 to it's limit. Now looking at SXROM right now it seems as if what I said isn't possible, but shouldn't it be possible if your used CHR-RAM in 8K mode?

EDIT:

Would this work for wiring MMC1 pins to make it 32K battery back WORKRAM, 1MBROM?

Code:
MMC1 PIN=====Chip Pin
PRG A14 =====Rom A14
PRG A15 =====Rom A15
PRG A16 =====Rom A16
PRG A17 =====Rom A17
CHR A12 =====Rom A18
CHR A13 =====Rom A19
CHR A14 =====Rom A20
CHR A15 =====WORK-RAM A14
CHR A16 =====WORK-RAM A15


I am not good at figuring out this electornics stuff yet, but it seems to make sense? :) I think this setup would be something you might want to look into. It needs a little re-wiring of boards, but it offers a TON of extra hardware, especially the 32K WRAM. :D

by on (#69602)
MottZilla wrote:
tokumaru wrote:
That's another aspect to consider if you plan on making carts, since AFAIK there aren't MMC3 clones available for building new carts, meaning that for each copy of your game you are gonna have to destroy an original MMC3 game.


If you partner with RetroZone it's pretty likely that a MMC3 clone can be put on a CPLD. Just because they don't sell it as parts doesn't mean that it can't be made. If you have a compelling enough game I would imagine the effort would be made to get your game cartridges built.


But it's true what they say, if you want something done right, you have to do it yourself. Maybe RetroZone could and will, but I wouldn't stake my project on it. On the PowerPak even with an FPGA, MMC3 doesn't work right..

I came up with a CPLD mapper design that is better than MMC1 (maybe between MMC1 and MMC3 in terms of flexibility - great features but no IRQ counter), and uses a CPLD with half the resources that the MMC1 ReproPak uses. It should be a bit cheaper. I'm sure the efficiency was helped by me not cloning an existing design. I still need to make a board for it though, just another one of my many projects.

by on (#69608)
tokumaru wrote:
...since AFAIK there aren't MMC3 clones available for building new carts, meaning that for each copy of your game you are gonna have to destroy an original MMC3 game.

No! Destroying old carts is against my belief system. :)

tokumaru wrote:
If you want to be able to destroy the whole level, then yeah, you are going to need the extra RAM, but if it's something around 2000 blocks or less you can probably remember the states of those using just the regular RAM. You just have to create a way to associate the groups of destructible blocks to the bitmaps that represent their state.

Yeah, I've considered doing something like this... Like a 1 bit-per destructible object (normal and destroyed state), but for what I want to do I might need more than two states.

tokumaru wrote:
...I'm just presenting some options you might not have considered, so that you can make an educated decision, or "weigh your options", like you just said.

Cool, yes I greatly appreciate the input.

tepples wrote:
And how hard is it with a status bar? Sonic doesn't use one, but SMB3 does.

I'm pretty sure I'm going to want a status bar. But from what I understand I can use a sprite 0 hit if I don't have scanline IRQs. Is that correct?

tepples wrote:
I came up with a compromise in which the engine restricts the map geometry to have only one destructible object per column of the map.

This seems like a really effective way of handling it, though again for what I want to do I might need more than one tile per row.

MottZilla wrote:
...If you have a compelling enough game I would imagine the effort would be made to get your game cartridges built.

This is good to know. I am going to do my best to use the least amount of resources as possible, but it is good to know that if I have no other option they might be able to work with me.

MottZilla wrote:
Now if you wanted something more fancy like MMC5...

Nah, as far as I can tell MMC3 will be plenty for what I'm planning. Out of curiosity what mapper, and how much RAM is Battle Kid?

65024U wrote:
Yeah, and since the best thing about MMC5, The extra sound, has been limited on US consoles, it seems like a waste anyway.

I actually wouldn't want that extra sound capability anyway, I want it to sound like the way I remember it as a young boy :)

Memblers wrote:
Maybe RetroZone could and will, but I wouldn't stake my project on it.

Point well taken, I'm going to try to keep this in mind along the way.

Memblers wrote:
On the PowerPak even with an FPGA, MMC3 doesn't work right...

Oh, how bad is it?

Thanks for all the great input everyone.

by on (#69609)
Battle kid is UNROM (mapper #2) with CHR RAM, and no PRG RAM. I think it's 256k in size, but I don't have a dump of that game.
Can't confirm the final version, but that's what it is in the demo.

by on (#69610)
I'll agree. I was wondering the same thing.....I thought it used MMC1 though.....hmmm. Interesting!

by on (#69611)
When deciding between UNROM/UOROM and MMC1 (SNROM), the big differences are that SNROM has switchable mirroring and SRAM. The MMC1's switchable mirroring is helpful for games that scroll one direction at a time (e.g. Mega Man 2, The Legend of Zelda), and the MMC1's one-screen mode makes status bars easier to make steady in a 4-way free-scrolling game at the cost of a few attribute artifacts on the right side. SRAM is helpful if your game has more than one chapter and you want to save more than 32 bits of state from one session to the next (e.g. any RPG). Battle Kid could use UOROM because it doesn't scroll and its state fits in 32 bits.

by on (#69619)
MottZilla wrote:
tokumaru wrote:
That's another aspect to consider if you plan on making carts, since AFAIK there aren't MMC3 clones available for building new carts, meaning that for each copy of your game you are gonna have to destroy an original MMC3 game.


If you partner with RetroZone it's pretty likely that a MMC3 clone can be put on a CPLD. Just because they don't sell it as parts doesn't mean that it can't be made. If you have a compelling enough game I would imagine the effort would be made to get your game cartridges built.


I happen to have a couple of pictures from a mmc3 retrozone board. I can't remember where I pulled them from, but the boards are dated September '09. I'm guessing they aren't far away from being sold.

by on (#69627)
cartlemmy wrote:
Memblers wrote:
On the PowerPak even with an FPGA, MMC3 doesn't work right...

Oh, how bad is it?


I've had issues with MMC3 games not saving WRAM (and yeah it was the iNES header). There could be other problems, but there also different versions, I've only tried the official mapper pack, so far.

IMHO, the MMC3's IRQ behavior is pretty complex for it being relatively crappy, compared to other possible IRQ methods.

If you do end up needing a custom board, I can make one maybe.

by on (#69634)
Personally I like FME7 and Konami VRC scanline IRQ counters. While they don't give you NTSC/PAL compatibility like some want to have, I think they are pretty simple yet effective scanline counters. Sure beats using Sprite Hit Zero.

by on (#69636)
cartlemmy wrote:
Yeah, I've considered doing something like this... Like a 1 bit-per destructible object (normal and destroyed state), but for what I want to do I might need more than two states.

I see... Well, if you need to move lots of blocks around instead of simply destroying them, they would need far too much RAM for their coordinates, so you're better off storing the whole map in the extra 8KB of RAM.

Quote:
I'm pretty sure I'm going to want a status bar. But from what I understand I can use a sprite 0 hit if I don't have scanline IRQs. Is that correct?

If you don't have IRQs, status bars are much easier to make when they are at the top of the screen, rather than the bottom. If it stays at the top, showing it is just a matter of detecting the end of VBlank (which can be done by waiting for the sprite hit flag to be cleared) and then waiting for a sprite hit to indicate the end of the status bar.

If the status bar is at the bottom however, guaranteeing a sprite hit can be hard when you also scroll vertically, because you can't be sure that a solid pixel in the sprite will hit a solid pixel in the background. Also, if by any chance your frame calculations take longer than usual (if there are too many objects on the screen for example), you might miss the sprite hit, which will cause the status bar to be drawn at the wrong place (or not at all) for a frame, so it will appear to be jumping.

So, if you are not using IRQs, I strongly suggest you place your status bar at the top, and use 1-screen mirroring, so that one name table can be dedicated to the gameplay while the other is dedicated to the status bar. Using 1-screen mirroring will allow you to make levels taller than 2 screens while using a status bar, something that's pretty much impossible with other kinds of mirroring.

You will have some scrolling glitches at the side(s) of the screen though, unless you mask them with sprites. I'm not aware of any way to have a status bar and glitch-free 8-way scrolling that doesn't involve one or more of the following: sprites, 4-screen mirroring, IRQs and MMC5.

Quote:
Out of curiosity what mapper, and how much RAM is Battle Kid?

AFAIK, mapper 2 with 256KB of PRG-ROM, CHR-RAM, no extra RAM. It's a simple mapper, but you can do a lot of cool things with CHR-RAM (although Battle Kid doesn't seem to). I'm using it for my Sonic-like game.

Quote:
Memblers wrote:
Maybe RetroZone could and will, but I wouldn't stake my project on it.

Point well taken, I'm going to try to keep this in mind along the way.

I'm with Memblers on this one... I'd rather design my game around hardware I know exists, rather than count on the possibility of my project generating a demand for new hardware.

Quote:
Memblers wrote:
On the PowerPak even with an FPGA, MMC3 doesn't work right...

Oh, how bad is it?

A lot of games seem to suffer from jittering status bars and saving issues.

by on (#69638)
MottZilla wrote:
Personally I like FME7 and Konami VRC scanline IRQ counters. While they don't give you NTSC/PAL compatibility like some want to have, I think they are pretty simple yet effective scanline counters.

I'm OK with this kind of scanline counter too. PAL compatibility is overrated, because it's not like scanline counting is the only thing in the way of region compatibility... You also have to change note tables, music tempo, delays, physics (nobody seems to go as far as changing the physics though)... So a couple of extra constants and/or tables is not such a big deal.

I also like the simple approach that Memblers and tepples have suggested in the past, of firing an IRQ when a certain tile is used. This is region independent and very flexible, as you can use sprites or the background to do it. This is kinda like a "sprite 0 hit done right" IMO, because it uses IRQs instead of register polling and doesn't have that solid pixel limitation. And it can be used multiple times in the same frame.

What I can't stand are the several limitations of the scanline counter of the MMC3. It forces you to give up on a feature I consider one of the best in the NES, which is being able to fetch sprite tiles from both pattern tables when using 8x16 sprites.

by on (#69652)
tokumaru wrote:
I'd rather design my game around hardware I know exists, rather than count on the possibility of my project generating a demand for new hardware.

Would that include or not include the availability of battery-backed SRAM on an SNROM-compatible board? Ultima Exodus conversions support it, and the ReproPak MMC1 theoretically supports it, but I'm not aware of any existing RetroZone products with a battery.

by on (#69659)
tepples wrote:
Would that include or not include the availability of battery-backed SRAM on an SNROM-compatible board? Ultima Exodus conversions support it, and the ReproPak MMC1 theoretically supports it, but I'm not aware of any existing RetroZone products with a battery.

Are you asking me? I don't like the MMC1 much, so I probably wouldn't use it, but if one wishes to publish their games through RetroZone I think it would be wise to contact them and make sure they can (and are willing to) manufacture the type of cart you need before investing your time into it.

by on (#69667)
It was more a reference to an IRC chat that I had with bunnyboy. He told me that he had never done a battery pak before.

by on (#69685)
Quote:
I also like the simple approach that Memblers and tepples have suggested in the past, of firing an IRQ when a certain tile is used. This is region independent and very flexible, as you can use sprites or the background to do it. This is kinda like a "sprite 0 hit done right" IMO, because it uses IRQs instead of register polling and doesn't have that solid pixel limitation. And it can be used multiple times in the same frame.

I third that it's a very good idea. If an automatic CHR switching system based on this worked well for Punch Out, Famicom Wars and Fire Emblem, something that would trigger an IRQ would be as good (as long as there is something to prevent triggering 8 IRQs in 8 consecutive scanlines...).

Quote:
I'm OK with this kind of scanline counter too. PAL compatibility is overrated, because it's not like scanline counting is the only thing in the way of region compatibility..

With a CPU cycle counter such as FME7's, N106's or FDS's there is no problem, you can just adjust the counter's value for PAL compatibility.

With VRC mappers however it becomes real crap, because the value is multiplied by 113.66666 automatically without having you being able to do anything with it. This made the counter terribly practical for NTSC (as you don't have to do any computations based on the # of lines you want to wait), and terribly impractical for PAL (you'd have to multiply the value by 15/16, round it down and wait the remaiding time by a timed loop).

Also I agree MMC3's way of generating IRQs is too complex as opposed to what it could be. This whole "delay between A12 raises" thing is complex and weird. It it was just A12 divided by 8 it would make more sense.

by on (#69692)
Unfortunately, the problem with the 'Sprite IRQ' is the larger amount of CHR address pins needed to check for the condition. If those inputs can also be re-used for something else, it would be a little more attractive, but I can't think of anything. The other methods only need a single input.

One way to prevent 8 IRQs in a row would be to check CHR data. In the game that means that you would have to 'hide' at least one visible pixel, which is a similar one of the annoyances with sprite #0 detect. I'm sure there's a better solution, perhaps using a counter.

With my first Squeedo prototype (I still have like 40 of those boards, heh), it was dead simple to get IRQs working using a PIC16 or PIC18. I was using a higher-end one ($4-$6), but it should just as well on cheapest ones (>$1). That's what I figured I would do if I needed just IRQ, by itself. I should consider putting that on my cheap CPLD board, as an option to develop later perhaps.

You can prescale CHR-A12 by 8 to get the scanline timer, or can also use a CPU cycle timer. No reason you can't use both at the same time, too (on the PIC at least, you'd need a way to check on NES). I expanded on that idea for example, by making the PIC also control the CHR banking. So at least for CHR stuff, the NES doesn't even have to be interrupted, if it told the PIC what to do beforehand. For the NES CPU, that's no latency, no overhead. Not that there's much overhead in CHR switching anyways, unless you're really getting crazy with it.
Re: Jump Physics
by on (#69695)
cartlemmy wrote:
Just wanted to get some input on my character physics model before I move on. There is no real collision detection yet, so it won't fall down the hole.

http://www.yibbleware.com/nes/cartlemmy-test-0.3.nes

I think it's a nice feeling to this! Something that would add a little more feeling to it, would be that the left-right movement don't stop emiditly when you release the left/right on the d-pad. Now it feels like "he" is falling straight down when you release left/right even if you "run" and jump... I'm not saying that it should move alot, but a bit before it stops.

Hope you understand what I mean...

by on (#69933)
Sorry to derail this thread a bit more, but I looked into the IRQ problem, and I think I now have the solution for a cheap single-chip solution (well, it must combine with my CPLD, but it's already there) for a PPU-based (tile $FF) IRQ, which could be accurate down to a single pixel (and can be transparent, I suppose). But all that accuracy is thrown out the window of course, if a CPU IRQ is generated (by latency of the current instruction executing).

I'll see if I can work that into controlling CHR banking at the same time, that would be nice. I'm removing i2c functionality to fit this in, so I guess I'll find out soon if there's room to work with that idea.

by on (#69935)
I think that putting a PIC or other micro-controller in a NES cart as a sort-of co-processor is intriguing.

How much circuitry (meaning... $$$ cost) would it take to be able to load a program into the controller from the NES at boot time (or any time)? Like using $5fff, $5ffe, similar to writing to PPUADDR and PPUDATA.

It would make adding support to emulators more difficult. I wonder what could be done with a general-purpose cart-based co-processor. I imagine that if it existed most people would use it for raster effects and bank switching tricks. But would there be any other uses?

by on (#69939)
clueless wrote:
I wonder what could be done with a general-purpose cart-based co-processor. I imagine that if it existed most people would use it for raster effects and bank switching tricks. But would there be any other uses?

Do "Super FX", "SA-1", and "Super Game Boy" give you any ideas?

by on (#69940)
I have never had a game with a SA-1 or Super-FX. I do own a super-game-boy though.

One thing that I can think of for the NES is generating a per-line IRQ, and then feeding unique interrupt vector addresses to the CPU. This saves CPU cycles by the CPU not having to look up a scan-line counter to determine what to do.
Re: Jump Physics
by on (#69944)
Kreese wrote:
Something that would add a little more feeling to it, would be that the left-right movement don't stop emiditly when you release the left/right on the d-pad. Now it feels like "he" is falling straight down when you release left/right even if you "run" and jump... I'm not saying that it should move alot, but a bit before it stops.

Hope you understand what I mean...


Yes, I do understand what you mean, and I totally agree. Thanks!

by on (#69949)
clueless wrote:
I think that putting a PIC or other micro-controller in a NES cart as a sort-of co-processor is intriguing.

How much circuitry (meaning... $$$ cost) would it take to be able to load a program into the controller from the NES at boot time (or any time)? Like using $5fff, $5ffe, similar to writing to PPUADDR and PPUDATA.

It would make adding support to emulators more difficult. I wonder what could be done with a general-purpose cart-based co-processor. I imagine that if it existed most people would use it for raster effects and bank switching tricks. But would there be any other uses?


The cost is mostly for the MCU itself. Cost is maybe ranging from $3.50 - $9 for PICs with a parallel port (easy for NES to read/write) + oscillator + 3.3V power (for the ones that need it). Here's the first board I made that can use various PIC16 or PIC18s - http://www.parodius.com/~memblers/nes/squeedo/pics/sqproto-side.jpg Other info is here: http://www.parodius.com/~memblers/nes/squeedo/ but it's all outdated stuff.

You could pretty much run the entire game in the coprocessor, if you wanted to. I'm using PIC32 in later designs, which is pretty decent to program in C (MIPS32 core.. relative of the N64's cpu :D).

With the PIC18F I was able to make 4 extra sound channels, wavetable synth with 8-bit volume for each channel. The NES gets the IRQ from it and writes the sound data to $4011. The newer version of the synth, that I've rewritten recently is much better though (but remains to be tested on hardware).

An MCU by itself probably won't be able to do any special IRQ vectoring, it would need some external logic probably. Pretty nifty idea though. For a later design I have a plan for an IRQ priority encoder with separate vectors. On the older board, what I did in my NES IRQ routine was read the (first) byte from the PIC, then use that as the index to the jump table. Plenty of overhead there, but there were a lot of different causes for an IRQ (UART, sound, scanline timer, CPU timer, math function results).

by on (#69950)
clueless wrote:
I wonder what could be done with a general-purpose cart-based co-processor. I imagine that if it existed most people would use it for raster effects and bank switching tricks. But would there be any other uses?


You could as Memblers suggested, run your actual game program on the coprocessor which would be much faster than the 1.79mhz 6502 type cpu. This would mean you would have alot more time to calculate game logic, meaning you could have even more complex game logic. This also means that the host CPU in the NES, similar to the SNES with SA-1, could just have the tasks of taking the update data for video updates and sending them to the PPU and other general tasks that it must do.

Perhaps your coprocessor could handle decompression as well. That was popular on SNES for graphics. Many games just used the large amount of RAM in the SNES and the main cpu, where as other games like Street Fighter Alpha 2 and Star Ocean had the SDD1 that could decompress graphics extremely fast.

With a coprocessor maybe you could do a 3D game sort of like Star Fox.

If you did put a coprocessor in a NES cartridge you'd probably want to carefully consider what you want to do before choosing what hardware to use. If you were to make a general purpose board for other developers to use, it might make the most sense to have the CPU be 65xx based so learning curve to use it would be minimal.

That really would be cool to put a fast 65xx type CPU in a cartridge as a coprocessor maybe along with some audio enhancement.

by on (#69952)
MottZilla wrote:
That really would be cool to put a fast 65xx type CPU in a cartridge as a coprocessor maybe along with some audio enhancement.


What I hoped to do was emulate the 6502. I've got the sound part covered (not complete yet). PIC32 natively runs 1 instruction per clock @ 80mhz, so I'm sure it could at least match the NES CPU's performance even with an unoptimized emulator. The audio stuff will load the CPU down, depending on the number of audio channels (and sample rate).

I looked into using real 65xx hardware, but really, there wasn't anything good for the price (especially with their MCUs). It looks like the 32-bit version might never be seen.

by on (#69959)
MottZilla wrote:
If you were to make a general purpose board for other developers to use, it might make the most sense to have the CPU be 65xx based so learning curve to use it would be minimal.

That or some sort of ARM on which one can easily use C++.[1] Imagine Super Game Boy... advance.


[1] But not necessarily the icky parts.