Looks pretty good! Haha, I think it's pronounced N.E.S.Dev. NES is an acronym and Dev is like the word development so yeah.....It's weird hearing it called that, but nobody else has every said it so I don't really know? 
Looks good, the random sprites up top are his head! XD Yeah but jumping and stuff looks great, I like the fast animation, you can make a FAST moving game if it at that speed, that'd be awesome to see. Nice job on it so far, and keep working on it! Looks really fun even there!
Looks good, the random sprites up top are his head! XD Yeah but jumping and stuff looks great, I like the fast animation, you can make a FAST moving game if it at that speed, that'd be awesome to see. Nice job on it so far, and keep working on it! Looks really fun even there!
65024U wrote:
Looks pretty good! Haha, I think it's pronounced N.E.S.Dev
Yes, I suppose that does make sense, though it is not the way I hear it in my head. When I open my mouth and pronounce things like MySQL, Linux, lib, gnu, etc... I often butcher it. So be prepared for me to do it more
Haha, will do man. 
NES alone is "N-E-S", but I tend to contract it in emulator names such as "Nesticle", "Nestopia", "RockNES" (Engrish for "Loch Ness"?), and that emulator named after the Norwegian word for "nearly". So "ness-dev" fits the pattern.
Saying it letter by letter in Portuguese sounds really weird, so I've always said it as a word. Most people wouldn't know what I'm talking about either way... The best way to refer to an NES here in Brazil is "Nintendinho" (little Nintendo), since it was actually released after (or alongside, I'm not really sure) the SNES, so the NES was basically the baby brother. Before that we only used clones.
I was surprised to know that you English speakers called it N-E-S. But I'm used to it now, and in the rare occasions that I need to talk about it in English out loud I do call it that. I have always said NESDev the way cartlemmy did though (although we cariocas use a very forced "s" that sounds more like "sh").
I was surprised to know that you English speakers called it N-E-S. But I'm used to it now, and in the rare occasions that I need to talk about it in English out loud I do call it that. I have always said NESDev the way cartlemmy did though (although we cariocas use a very forced "s" that sounds more like "sh").
Haha yeah, us diferent regions have weird thingsl ike that. Not that that is wrong or anything, just hearing it different is really strange Pretty cool, though! ^_^
Pretty cool, though! ^_^I find that I use the pronunciations interchangeably. Nessdev or enn ee ess dev....ness dev rolls off the tongue easier.
Fun video btw. What's the name of your little bearded guy?
Fun video btw. What's the name of your little bearded guy?
I've always pronounced it the same as the main character of Earthbound, or the Scottish lake monster. So I'd never use the word NES with an "an" in front of it.
Gradualore wrote:
Fun video btw. What's the name of your little bearded guy?
Not sure yet, something Japanese sounding probably. Not sure though.
I've been working on collision detection for my game, and thought I'd give a video update.
http://www.youtube.com/watch?v=5TRUHckytKM
http://www.youtube.com/watch?v=5TRUHckytKM
Coming along nice! Neaten up the slope detection and tweak the physics and that looks the start to a nice engine!
Interesting video blog. I'm gonna have to keep checking for updates. By the way, what IDE are you using for your coding?
67726e wrote:
Interesting video blog. I'm gonna have to keep checking for updates. By the way, what IDE are you using for your coding?
Thanks. I'm using Geany, then compiling with ASM6. ASM6 is running in WINE, as my OS is Ubuntu.
ASM6 is distributed as C source code, maybe you could build a Linux version with GCC.
Dwedit wrote:
ASM6 is distributed as C source code, maybe you could build a Linux version with GCC.
Ah! I might do just that, thanks. Command line stuff is normally pretty easy to move over.
EDIT:
http://www.yibbleware.com/nes/asm6-1.6-linux.zip
So what is the premise of your game you have in the works? Is it just a concept thing you are working on or is this a new homebrew game in the works?
67726e wrote:
So what is the premise of your game you have in the works? Is it just a concept thing you are working on or is this a new homebrew game in the works?
Nothing is entirely solidified yet, but right now I plan on it being a platformer with puzzle elements.
I don't know if anyone has ever done anything like what you've done with the videos. It's a cool thing to do and I hope you continue it.
Also I pronounce it like "ness-dev". Afterall I say "ness" not "N - E - S".
Also I pronounce it like "ness-dev". Afterall I say "ness" not "N - E - S".
Super cool!
Hope you keep videoing your progress.
Hope you keep videoing your progress.
Cartlemmy, I'm inspired by videos by you, metalslime and some others. It's making me want to make a similar series of videos about my own development process. It's interesting how different nesdevers come up with a lot of the same ideas (or are using some ideas that float around here on this site, etc.). I've made a lot of my own dev tools as you have, and have also considered polishing them up some day and releasing them...some day there's going to be an embarassment of riches in this community in the way of tools! Part of me thinks that anybody with similar ideas should pitch in to an existing project like NESICIDE, though, rather than each of us make our own tools available. We'll see...for now we have games to make!
Gradualore wrote:
...It's making me want to make a similar series of videos about my own development process. It's interesting how different nesdevers come up with a lot of the same ideas (or are using some ideas that float around here on this site, etc.).
I hope you do, I've watched your nomolos video many-a-times, and I've been itching to see your progress.
Gradualore wrote:
Part of me thinks that anybody with similar ideas should pitch in to an existing project like NESICIDE, though, rather than each of us make our own tools available. We'll see...for now we have games to make!
True, I have a nasty habit of re-inventing the wheel. Though I find I learn a lot more when I do so.
Cool project. I like the hero sprite. It's not too often that you see a character that's 3 sprites wide.
Your videos seem to skip from part 2 to part 4. Did you make a part 3?
Your videos seem to skip from part 2 to part 4. Did you make a part 3?
cartlemmy wrote:
Gradualore wrote:
...It's making me want to make a similar series of videos about my own development process. It's interesting how different nesdevers come up with a lot of the same ideas (or are using some ideas that float around here on this site, etc.).
I hope you do, I've watched your nomolos video many-a-times, and I've been itching to see your progress.
Gradualore wrote:
Part of me thinks that anybody with similar ideas should pitch in to an existing project like NESICIDE, though, rather than each of us make our own tools available. We'll see...for now we have games to make!
True, I have a nasty habit of re-inventing the wheel. Though I find I learn a lot more when I do so.
I recently spoke with a friend of mine who works in the pro game dev industry. It sounds like it is a fairly universal problem, that most game developers have to create some sort of custom tools. I guess the problem is there are just too many ways of doing everything. Even in NES development I think this is the case. I guess some tools are starting to come out which may standardize map editing, but even there there are lots of ways to do things like how you apply properties to your maps.
I agree, one does learn a lot by re-inventing the wheel. When I started nesdev, I didn't understand how graphics were put together at all, all I had was NES101 tutorial by michael martin. I knew there was YY-CHR, but I couldn't figure it out. So, I wrote my own graphics editor to learn...and it ended up evolving into a tool that I use every day for my game. It's very useful *for my game* but it is hard to say whether it'd be useful to others. Probably the best hope is for the community to eventually pitch in to something like NESICIDE and then there will be "*a* way" to make a game---but it probably still won't be quite as robust as doing everything yourself...that's just the nature of game development. If you want something unique, your own, you gotta do most things yourself.
MetalSlime wrote:
Your videos seem to skip from part 2 to part 4. Did you make a part 3?
Ah, I'm glad you caught that. I seemed to have mis-labeled.
Gradualore wrote:
...that's just the nature of game development. If you want something unique, your own, you gotta do most things yourself.
Yep. Though after having created all of my own custom tools I will have gained enough knowledge to help with projects such a NESICIDE, and hopefully I can.
This is really neat, seeing everything come together with demo videos and the creation of your engine. It's like battle kid's videos, but it's with making the actual engine, not more levels, which I like since we understand the technical level mostly here, we like to see what you add in order and stuff (I do) but this makes me want to start a blog like this. I will probably just do a text-file though since I don't have any video, but then it can show people what took longer to make, what gave me trouble, how I break my crap then fix it and stuff like that. Nomatter who's game, I think it's fun knowing what they went through when making it. Like Defender and their blowing of the ROM's when they put them in backwards! Haha but these blogs are cool, keep making them, they're a great idea IMO.
Haha but these blogs are cool, keep making them, they're a great idea IMO. cartlemmy wrote:
Yep. Though after having created all of my own custom tools I will have gained enough knowledge to help with projects such a NESICIDE, and hopefully I can.
It sure needs the help, it does. I've experienced the same stagnation, procrastination, and excitement working on NESICIDE as I read you guys do with game projects. Of course, the whole thing started because I was interested in creating a game. I guess the emotions of software development are universal to all types of software.
Join us on #nesicide on freenode.net, or post on forums.nesicide.com if at all interested.
I'm busier with work these days so not on quite as often as I'd like, but...still hoping to eventually "finish" this thing.NESICIDE wrote:
Join us on #nesicide on freenode.net, or post on forums.nesicide.com if at all interested. I'm busier with work these days so not on quite as often as I'd like, but...still hoping to eventually "finish" this thing.
I'm busier with work these days so not on quite as often as I'd like, but...still hoping to eventually "finish" this thing.Cool, I'll drop in soon.
Also, it's good to see this thread moved to "Homebrew Projects" before I even had chance to ask
MetalSlime wrote:
Cool project. I like the hero sprite. It's not too often that you see a character that's 3 sprites wide.
Back to the 3-sprite-wide hero: do you plan to have enemies to fight? You mentioned that your game was going to be a platformer with puzzle elements. Is your focus more on action or more on puzzles? Having a wide hero makes me think about sprite flicker issues. Especially if the hero has a ranged attack. I'm just curious to know how you plan to deal with the 8-sprite limit.
Not dogging the idea at all, btw. I love your hero sprite, and my favorite NES game has an enemy that's 9-sprites wide (=automatic flicker). Just want to hear your ideas.
(a little off topic...) What game has a 9-sprite wide hero? Just curious.
MetalSlime wrote:
Having a wide hero makes me think about sprite flicker issues.
I think that games with big hero characters are great, even if they flicker a bit more than the ones with tiny heroes. When you look at Batman Return of The Joker you can't deny that it looks awesome, and I at least will take the flickering that comes with it any day. Even sprites that aren't exactly big can use a lot of sprites some times... Mega Man, for example, has animation frames with 4 tiles across, plus the one with his face, which adds up to over half of the sprite limit. His shooting frame appears to be like that, add the 3 shots that can be on the screen at once and Mega Man alone is trying to use 8 sprites in those scanlines. These things happen, and they are not so bad, we as players are used to flickering.
In my game I try to stick to a limit of 4 tiles per scanline for all characters and objects, so that I can have at least two of them side by side without any flickering. With clever level design you can also prevent huge enemy reunions, specially if the game scrolls vertically as well, meaning you can spread detail vertically more than than you would if you only scrolled horizontally.
MetalSlime wrote:
Back to the 3-sprite-wide hero: do you plan to have enemies to fight?
Yes
MetalSlime wrote:
You mentioned that your game was going to be a platformer with puzzle elements. Is your focus more on action or more on puzzles?
A balance of the two, but I think the perception will be that the focus is on the action.
MetalSlime wrote:
Having a wide hero makes me think about sprite flicker issues. Especially if the hero has a ranged attack. I'm just curious to know how you plan to deal with the 8-sprite limit.
I actually plan on quite a few 1 sprite wide enemies (1x2, and 1x3), that could be used along two 2 sprite wide enemies and designing the levels in such a way that (in most cases) no more than three are on screen at once. I will set the hero's lower two sprites (at the back) to have a lower priority, because this area has the least non-transparent pixels.
It makes my head spin just thinking about it. Deep breaths, one step at a time.
clueless wrote:
(a little off topic...) What game has a 9-sprite wide hero? Just curious.
not hero, enemy. The game is "The Guardian Legend" (Grimgrin): http://www.youtube.com/watch?v=Hi5ECVCA8pE
Tokumaru wrote:
I think that games with big hero characters are great, even if they flicker a bit more than the ones with tiny heroes.
I agree. Flicker is acceptable as long as it isn't too ridiculous. As you said, vertical games can get away with larger sprites because most of the action (hence the player's eyes) will be "up" rather than to the side. Flicker is easy to ignore if you are focused on a different area of the screen.
cartlemmy wrote:
I actually plan on quite a few 1 sprite wide enemies (1x2, and 1x3), that could be used along two 2 sprite wide enemies and designing the levels in such a way that (in most cases) no more than three are on screen at once. I will set the hero's lower two sprites (at the back) to have a lower priority, because this area has the least non-transparent pixels.
It makes my head spin just thinking about it. Deep breaths, one step at a time.
It makes my head spin just thinking about it. Deep breaths, one step at a time.
no need to sweat it. It can be done, and flicker is acceptable if it doesn't make the playing experience annoying. I'll be paying attention to your monster and level design in your future updates. Not too critically, just curiously. I think your big hero is awesome. I never considered using a hero larger than 16 pixels horizontally, so it will be cool to see how you do it.
Quote:
Part 4 is up. Boring stuff about my pre-parser.
Boring? Pfft I love stuff like that. Then again I've already started work on a 6502 compiler that I'm writing for my IB Comp Sci final so....
Anyway how many tools have you written so far?
Cool, interesting video. Cute baby too, I need to develop one of those eventually. I've long since gotten used to coding 6502 by hand, so I'm not sure how much I'd personally benefit from a pre-parser, but it's still a neat idea. Wasn't nes-hla supposed to accomplish kind of what you're doing here? I dunno if anybody here uses that or not.
67726e wrote:
Anyway how many tools have you written so far?
Well, none of them are complete... but just the map editor/meta-tile parser, and this.
Gradualore wrote:
Wasn't nes-hla supposed to accomplish kind of what you're doing here?
I really don't know, I never looked into it. My goal was to actually code entirely in 6502 assembly, with some minor flow control parsing. I really don't want to abstract the code too much.
I'm still working on the project, but I wasn't really in the mood to make a video, so here's some screenshots and a link to a demo of my progress.
http://www.yibbleware.com/downloads/20110312-rtt.nes
http://www.yibbleware.com/downloads/20110312-rtt.nes
cartlemmy wrote:
When you see it...
Nice demo by the way. Very solid.
Nice job progressing! I see you made it only 2 tables high like SMB. Very cool. Is there going to be a status bar or just a main menu in the game? Or is it to be decided later?
Great job.
Great job.
joe1088 wrote:
Nice demo by the way. Very solid.
Thanks
3gengames wrote:
Is there going to be a status bar[?]
I'm still on the fence, I think the style of the game will probably require a status bar. But from what I understand there is some issue with putting a status bar at the bottom of a screen using sprite 0 hit (So I will need to use MMC3?). Or perhaps I just made that up in my crazy mind. But in either case I am only using the first 48 of 60 rows of tiles, so there is room in the nametable if need be.
The "issue" is that there needs to be an overlap between a solid sprite pixel and a solid background pixel somewhere in x=0 to 254 (or x=8 to 254 if using the clipping window). If your background is color 0, then there might not be any solid background pixels to guarantee an overlap unless you rewrite the map every frame to keep a solid tile under sprite 0. Another way to do it, as long as you aren't playing sampled drums, involves splitting the status bar between the top and bottom.
I noticed that after the music starts playing, if you leave at a specific point, you can hear some "static" noise. Is this accidental or intentional?
Very nice demo! Keep up the good work. You could use sprites to show some status info if other methods are troublesome.
tepples wrote:
...Another way to do it, as long as you aren't playing sampled drums, involves splitting the status bar between the top and bottom.
Hmmm, I am using sampled drums and to me sampled drums are more important than a status bar
And thanks for refreshing my memory to the reason that it is hard to put the sprite 0 activated status bar at the bottom.WJYkK wrote:
I noticed that after the music starts playing, if you leave at a specific point, you can hear some "static" noise. Is this accidental or intentional?
Haha, yeah. Well it is a bug, but one that I was too impatient to fix before I released this demo. I just left out the code that silences the noise channel. Also, in the actual release the music will play throughout the entire level.
thefox wrote:
Very nice demo! Keep up the good work. You could use sprites to show some status info if other methods are troublesome.
Thanks. Yes, I will certainly keep that in mind.
tepples wrote:
The "issue" is that there needs to be an overlap between a solid sprite pixel and a solid background pixel somewhere in x=0 to 254 (or x=8 to 254 if using the clipping window).
Not only that, but you also have to make sure all your frame calculations end before the sprite hit every single frame, or else the status bar will jump/flicker. In a platformer, with all the flow of enemies showing up and leaving/dying, I think it's pretty safe to assume that there will be an occasional CPU-intensive frame, and I'm sure you don't want the status bar to glitch up in that case.
Status bars at the bottom of the screen are only 100% safe with IRQs. Are you against placing the bar at the top of the screen? Those can be safely implemented without the aid of mappers or interrupts (well... technically the NMI is required, but you should be using NMIs anyway).
tokumaru wrote:
Are you against placing the bar at the top of the screen?
Not at all. Sounds like my only option if I'm ever to reproduce this thing on a real cart. Right? What mappers would a company like Retrozone be able to reproduce without costs being excessive?
cartlemmy wrote:
Not at all. Sounds like my only option if I'm ever to reproduce this thing on a real cart. Right?
I wouldn't want to rely on mapper IRQs while no NES cart publisher (is RetroZone is the only one?) has a mapper with that feature.
For a status bar at the top of the screen, here's what you have to do: after the usual graphical updates, set the scroll to display the status bar and prepare a sprite 0 hit for a location near the end of the status bar (which is easy, because the status bar doesn't move). Then wait for the sprite hit flag to be cleared (from the previous frame's hit) and then wait for it to be set again. You can do other tasks before these waits, as long as you're sure they'll finish before the sprite hit (the sound engine would be a good thing to run during this time, for example). Once the hit happens, you just have to set the scroll for the gameplay area using $2005/$2006 trickery (example code here).
This will work either in an NMI handler or in the main loop (in case you use NMIs just to set a flag indicating that VBlank started), but it's obviously better to use the NMI handler, because they deal with lag frames gracefully, without visual side effects.
BTW, I was peeking at your code and it seems you have an NMI handler, but for some reason you trash X by reading from a variable and comparing its value to $02, but soon after you save A to the stack. If you had a lag frame, trashing X like that would be very bad. You should probably use A to check that variable instead, after having backed it up to the stack (and obviously restore it before RTI'ing). Or better yet, if you can use bits 6 and 7 to represent the states you need, you can use the BIT instruction, which doesn't trash any registers, and use BPL/BMI and BVC/BVS to make decisions based on those bits.
Quote:
What mappers would a company like Retrozone be able to reproduce without costs being excessive?
I think they have basically two boards: one that can be configured for most discrete logic mappers (NROM, CNROM, UxROM, AxROM) and another for various MMC1 configurations. Those are your safe bets, but some people say that a good MMC3 game might just be the incentive RetroZone needs to develop an MMC3 clone and board. Personally, I wouldn't risk it.
tokumaru wrote:
but some people say that a good MMC3 game might just be the incentive RetroZone needs to develop an MMC3 clone and board. Personally, I wouldn't risk it.
I can think of one hedge. Develop two versions of your game, one for MMC1 and one for MMC3, with extra features in the MMC3 version. With good architecture, they should be able to share most of the source tree.
tokumaru wrote:
For a status bar at the top of the screen, here's what you have to do...
Cool thanks
tokumaru wrote:
BTW, I was peeking at your code and it seems you have an NMI handler, but for some reason you trash X by reading from a variable and comparing its value to $02, but soon after you save A to the stack. If you had a lag frame, trashing X like that would be very bad...
I created that NMI code when I first started with the 6502, so I'll have to give it a look. The odd thing is I just did a test yesterday to see what would happen if my engine had to drop a frame (I wanted to see if I had it set right so the sound engine didn't slow), and everything worked fine. It ran at half speed, and the music stayed constant.
tepples wrote:
I can think of one hedge. Develop two versions of your game, one for MMC1 and one for MMC3, with extra features in the MMC3 version. With good architecture, they should be able to share most of the source tree.
I really like this idea, and I think I'll do just that. Can I do chr rom bank switching in MMC1?
Here's a strange quirk with your game. Jump next to a wall while holding A. You fall faster than if you weren't holding A. I do know wall jumping exists which makes this being around a little stranger to me. Intentional or not?
Edit: As for your game working fine during a lag frame, if tokumaru's description is correct, it only worked because the NMI was called in the middle of a routine where the value of X wasn't expected to be something. If that happened in the middle of a loop that used X and X was changed by the NMI, bad things would (probably) happen.
Edit: As for your game working fine during a lag frame, if tokumaru's description is correct, it only worked because the NMI was called in the middle of a routine where the value of X wasn't expected to be something. If that happened in the middle of a loop that used X and X was changed by the NMI, bad things would (probably) happen.
tokumaru wrote:
Those are your safe bets, but some people say that a good MMC3 game might just be the incentive RetroZone needs to develop an MMC3 clone and board. Personally, I wouldn't risk it.
They have one its just not affordable when the profits need to be split.
cartlemmy wrote:
tepples wrote:
I can think of one hedge. Develop two versions of your game, one for MMC1 and one for MMC3, with extra features in the MMC3 version. With good architecture, they should be able to share most of the source tree.
I really like this idea, and I think I'll do just that. Can I do chr rom bank switching in MMC1?
Yes, but only 4 KiB at a time. Are you animating a lot of background tiles? There may be a workaround.
Kasumi wrote:
Here's a strange quirk with your game. Jump next to a wall while holding A. You fall faster than if you weren't holding A. I do know wall jumping exists which makes this being around a little stranger to me. Intentional or not?
Not intentional, and it is a result of the wall jump (well, actually the wall slide) code. Thanks for the heads up
Kasumi wrote:
As for your game working fine during a lag frame... ...was changed by the NMI, bad things would (probably) happen.
I will definitely review this. EDIT: I have fixed this.
ibeenew2 wrote:
They have one its just not affordable when the profits need to be split.
I will keep this in mind.
tepples wrote:
cartlemmy wrote:
Can I do chr rom bank switching in MMC1?
Yes, but only 4 KiB at a time. Are you animating a lot of background tiles? There may be a workaround.
So you have to switch all of the graphics at once with MMC1?
I'm not sure if I will want to animate any, I just though it would be a nice thing to have available if I needed an extra aesthetic touch.
(minor tangent) Whatever happened to that "Let's design a mapper that can fit in the same CPLD that RetroZone uses for the MMC1 but is more useful to us" project?
Demo looks really cool.
I don't know if anyone else has one, but I finished the Verilog for one, I'm 95% sure it will work as-is, but I haven't made the board layout yet. I used the smallest (36 macrocell) CPLD and one 74xx part to provide the inputs needed for the IRQ logic. I have some projects ready to use this board, so this will be moving along before too long.
IRQ operation has 2 modes. Both are PPU-based - based on sprite and/or background tile placement. One mode triggers an IRQ (acknowledge register clears it). The other mode will automatically bankswitch the CHR to your latched value (acknowledge register resets it to a 'fixed' bank). The only catch is that in the latter mode, the NES CPU must keep IRQs disabled. CHR page size is 2kB.
lidnariq wrote:
(minor tangent) Whatever happened to that "Let's design a mapper that can fit in the same CPLD that RetroZone uses for the MMC1 but is more useful to us" project?
I don't know if anyone else has one, but I finished the Verilog for one, I'm 95% sure it will work as-is, but I haven't made the board layout yet. I used the smallest (36 macrocell) CPLD and one 74xx part to provide the inputs needed for the IRQ logic. I have some projects ready to use this board, so this will be moving along before too long.
IRQ operation has 2 modes. Both are PPU-based - based on sprite and/or background tile placement. One mode triggers an IRQ (acknowledge register clears it). The other mode will automatically bankswitch the CHR to your latched value (acknowledge register resets it to a 'fixed' bank). The only catch is that in the latter mode, the NES CPU must keep IRQs disabled. CHR page size is 2kB.
This demo shows a lot of good potential. Well done!
tokumaru wrote:
"Nintendinho"
i LOVE this and am calling the nintendo this from now onPortuguese -inho corresponds to Spanish -iño, correct?
tepples wrote:
Portuguese -inho corresponds to Spanish -iño, correct?
I think the diminutive in spanish is -ito, no? As for the sound, "nh" in portuguese does indeed sound the same as "ñ" in spanish, but I don't think many english speakers know that, because they always get it wrong in movies and series.
it is -ito, yeah
edit: i love the sh and nh that portugese uses. i listen to a lot of MPB, so i picked up a bit of the pronunciation from that, but i am useless w/ portugese.
edit: i love the sh and nh that portugese uses. i listen to a lot of MPB, so i picked up a bit of the pronunciation from that, but i am useless w/ portugese.
ibeenew2 wrote:
tokumaru wrote:
Those are your safe bets, but some people say that a good MMC3 game might just be the incentive RetroZone needs to develop an MMC3 clone and board. Personally, I wouldn't risk it.
They have one its just not affordable when the profits need to be split.
SMB2j that retrozone sells has a MMC 3 board. And seriously, a game like this could be worth a lot. Seems like it could be a great platformer! Don't be scared to make an expensive game as long as it has great quality. The demo gives me really good hope for a great game. I wouldn't doubt buying a game like this for $50-60.
I am working on an MMC3 clone board too Keep up the good work!
Keep up the good work!Kreese wrote:
SMB2j that retrozone sells has a MMC 3 board.
I seem to remember someone saying it was actually a subset of the FDS, as the ROM is not the MMC3 hacked version. Does anyone know for sure?
Alls I know is what has been discussed previously, and what was said previously was that SMB2j on RetroZone uses a mapper that emulates the subset of FDS that SMB2j uses. I didn't bring up that point on this thread because I have absolutely no proof and no way to get any
Well... Here are the cart:
http://www.kreese.com/slask/smb2j.jpg
Would be great if Bunnyboy started selling those boards... I wonder how much they would cost.
http://www.kreese.com/slask/smb2j.jpg
Would be great if Bunnyboy started selling those boards... I wonder how much they would cost.
Kreese wrote:
http://www.kreese.com/slask/smb2j.jpg
Well, there's a big "MMC3" there, so I guess we have an answer.
tokumaru wrote:
Kreese wrote:
http://www.kreese.com/slask/smb2j.jpg
Well, there's a big "MMC3" there, so I guess we have an answer.
Neato!
Unless the Xilinx part is a CPLD that can be switched between FDS-subset and MMC3 by loading different fusemaps.
It's all speculation at this point, unless BunnyBoy lets the cat out of the bag. There must be something that makes this board not terribly marketable.
I think it is telling that the CPLD used has 144 macrocells. That one chip retails at $5.80 in single quantities at DigiKey.
I think it is telling that the CPLD used has 144 macrocells. That one chip retails at $5.80 in single quantities at DigiKey.