A question about Super Mario Bros 3 nes and Dragon warrior
Moderator: Moderators
A question about Super Mario Bros 3 nes and Dragon warrior
I open Mario bros 3 catridge and it have write ram????? it's possible???
i analyze header of dragon warrior 5 nes. My program say 64 kb
prg-rom and 0 kb chr???? where is saving graphics of dragon warrior?? how???
i analyze header of dragon warrior 5 nes. My program say 64 kb
prg-rom and 0 kb chr???? where is saving graphics of dragon warrior?? how???
Re: A question about Super Mario Bros 3 nes and Dragon warri
Certainly. There's more than a few games that have extra RAM but no battery (like Metroid, MC Kids, Spot are a few that come to mind). Mario 3 likely uses it for uncompressing it's levels.EL_CHILENO_LORD_NES wrote:I open Mario bros 3 catridge and it have write ram????? it's possible???
Usually that would mean it's using CHR-RAM instead of ROM, so graphics would be in PRG memory. I thought the first DW was 32kB PRG and 32kB CHR though. I've never seen a DW5 for NES (officially it was only on Super Famicom).i analyze header of dragon warrior 5 nes. My program say 64 kb
prg-rom and 0 kb chr???? where is saving graphics of dragon warrior?? how???
Re: A question about Super Mario Bros 3 nes and Dragon warri
Dragon Quest [1] (J) was 32KB PRG 32KB CHR (CNROM), and it didn't have particularly good graphics.Memblers wrote:I thought the first DW was 32kB PRG and 32kB CHR though.
Dragon Warrior [1] (U) was 64KB PRG 16KB CHR (MMC1), being somewhat improved over the Famicom version (one major improvement was having characters face the direction they were walking).
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
Re: A question about Super Mario Bros 3 nes and Dragon warri
Ok, i see... smb3 have zipped graphics.... i didnt know it... chr-ram is the same that it w-ram????? then chr-ram is zipped inside prg-rom????
Games with CHR-RAM have their graphics stored in PRG-ROM, compressed or not. To use them, they must be copied/uncompressed to CHR-RAM. With SMB3, only the level maps are compressed in ROM, not the graphics.
EDIT: Oh, Memblers already said the SMB3 part...
EDIT: Oh, Memblers already said the SMB3 part...
Last edited by tokumaru on Tue Jan 24, 2006 4:58 am, edited 1 time in total.
Re: A question...
Level map data = name-table???
VRAM is inside nes rom?????
VRAM is inside nes rom?????
Re: A question...
No. The level map has to eventually be rendered to the name tables so that the players can see anything, but they most definatelly are not the same thing.EL_CHILENO_LORD_NES wrote:Level map data = name-table???
Hum... if the cart has CHR-RAM, sort of. The console has RAM for 2 nametables, the palettes, this kind of stuff. However, some carts have CHR-RAM and even extra RAM for more name tables. Then I think you could say the cart (not the ROM) has VRAM... I'm not sure if it is actually correct to say this, though! =)VRAM is inside nes rom?????
Re: A question about Name tables
I am reading nes programming articles on internet....
it say about, pattern tables, name tables... I dont understand very much it.. but i understand any things...
but .. how actually know the game when there are collisions between sprites and any part of background or sprites collisions.. it is used with tables?? or is only prg-code????
it say about, pattern tables, name tables... I dont understand very much it.. but i understand any things...
but .. how actually know the game when there are collisions between sprites and any part of background or sprites collisions.. it is used with tables?? or is only prg-code????
Re: A question about Name tables
Sprite x Sprite -> "bounding box" concept, usually;EL_CHILENO_LORD_NES wrote:but .. how actually know the game when there are collisions between sprites and any part of background or sprites collisions.. it is used with tables?? or is only prg-code????
Sprite x Background -> checking specific player spots against the level map;
There is no hardware way of detecting collisions, it is all done in your program's logic. There is a whole topic (and it is big...) in this board about collisions started by Celius, maybe you should take a look at it: http://www.nesdev.com/bbs/viewtopic.php?t=352
The iNES format has a code for classes of boards (for example the code is 4 for most boards that have an MMC3 or MMC6). It also assumes that all MMC3 games have a WRAM. Newer file formats (which you usually don't come across on warez sites) can make finer distinctions between boards, but at this stage you don't need to worry about them.