nesdev.org

actually i opened up a ds flash cart, it contains a controller which is enclosed under a gloptop, but interestingly there is also a flash chip, most probably holding the firmware to boot up, which could be used to also store and play snes games, yet this requires either a special board or good wirin...

...

But this would be pretty costly, providing an extra cpu to every single cart. "Goddammit, damn dammit, damn damn" -- Fox McCloud, Star Fox At least by the Super NES era, the cost of including a CPU on a cart had dropped to the point where the Super FX and SA-1 coprocessors were cost-effec...

Wide Boy, RetroVision, and Super Game Boy implement exactly that technique, and with modern ARM CPUs, it might just be workable. Still, it's probably overkill as copy protection. This was something i also considered, having an extra cpu do some or all the work and passing some neccessary data to th...

That's a curious request coming from someone who was JUST NOW considering using music and art from existing games! Yeah, as i said, i had the idea for some cameo appearances which of course would have needed those licensed graphics and sprites, but i dropped it in favor of not wanting to go through...

Ok, well, it seems like it might not be worth going through the hassle and stress of getting some copyrighted material into my work. Another question: Is there a way of securing rom data from being pirated? I know i could implement a new custom mapper of which only i know how it operates. But for so...

good to know, that copyrighted material actually must not be used. So my ideas of cameos in the game will be dropped....

Now, if i changed my mind and were to release it as free homebrew, is there also any issues using copyrighted material?

I am in process of programming my own homebrew game, which I might want to release as a cartridge and sell it (much like sivak did with his Battlekid games on Retrousb). What do I have to consider? Any issues with patents when I for example use graphics or music from other (licensed) commercial game...

Search tokumaru threads he goes in depth about the subject within five seconds of his explanation i was aware how to implement it. He's got the clearest writing on the subject, as a matter of fact he explains all subjects the clearest i've ever seen.Kasumi is a notable second they both go into deep...

thank you for your tips, i very appreciate them. these will improve my programs heavily (as i now see that i have them coded in very untidy and inefficent way )

Okay, figured it out. Here's a ROM (Let me know if you want it removed, it's here to prove I'm not nuts), as well as the changes. If the changes I listed don't give you this result, tell me and I will find out what I forgot. main:;checks for collision bit $2002 bpl main lda $0204;vert pos of metasp...

That is to say, add these writes to $2005 slightly before main ldx #$00 ldy #$00 lda #$1E sta $2001 ;------------------------------------------- ;------------------------------------------- lda #$00 sta $2005 sta $2005 main:;checks for collision but changing scroll register right before main routin...

thanks for the suggestion, but changing scroll register right before main routine did not change anything (i actually turned off scrolling way before in the code).
here is a picture to show what i actually mean, maybe this was not really clear:

Here is the code for anyone whose device is not able to display asm files properly. Just tell me where explanation is needed and i will explain, as i did not really comment on all the code. ;-------------------------------------------- ; constants ;-------------------------------------------- PRG_CO...

sadly, it is not the falling velocity, which causes the problem (it is 1pixel/frame). i think i will probably rewrite the collision detection to what you described, because this sounds most convenient to implement. nevertheless, i would like to know what was wrong with my way of handling detection o...