[ShadowOne333]

It isn't maybe sprite 0?

Yeah I did think of that.
I had Zelda 2 Redux flashbacks with Trax telling me kittens would die if I touched that sprite lol

I only tried blanking out the tile, I will try just adding any kind of sprite there to see if it doesn't freeze the game on screen change.

EDIT: Upon some more tests, I can tell that the bomb icon does something very interesting.
Not the bomb icon itself, since I can select another tile in its place, but tile $61 (and $60) specifically from the PPU.
If I leave it blank, the game doesn't change screens, but if I even add just a 4 pixels "dot", it works.
I noticed that said sprites (tile IDs $60 and $61), get called on screen transition for both the key and bomb icon as background sprites behind the icons themselves.
You can try this out by tile editing tile $60, add whatever in there, and change screen, you will see the tile appear behind the key icon until the screen stops moving/scrolling.

So yeah, interesting stuff indeed.
However, this won't help with what I wanted to do lol (which was to free up space for a possible burnable tree sprite which I even did lol)
(Don't pay attention to the blue color, that's the default game palette but can be changed)


But oh well, at least I'm happy with how things are right now

[SpringSonic9187]

Yeah I did think of that.
I had Zelda 2 Redux flashbacks with Trax telling me kittens would die if I touched that sprite lol

I only tried blanking out the tile, I will try just adding any kind of sprite there to see if it doesn't freeze the game on screen change.

EDIT: Upon some more tests, I can tell that the bomb icon does something very interesting.
Not the bomb icon itself, since I can select another tile in its place, but tile $61 (and $60) specifically from the PPU.
If I leave it blank, the game doesn't change screens, but if I even add just a 4 pixels "dot", it works.
I noticed that said sprites (tile IDs $60 and $61), get called on screen transition for both the key and bomb icon as background sprites behind the icons themselves.
You can try this out by tile editing tile $60, add whatever in there, and change screen, you will see the tile appear behind the key icon until the screen stops moving/scrolling.

So yeah, interesting stuff indeed.
However, this won't help with what I wanted to do lol (which was to free up space for a possible burnable tree sprite which I even did lol)
(Don't pay attention to the blue color, that's the default game palette but can be changed)


But oh well, at least I'm happy with how things are right now

Woah, separate graphics for burnable trees?

Looks like I'm never gonna use a overworld map image as a burnable tree fiding tool again.

[ShadowOne333]

I've been trying to dive into the MMC3/MMC5 hacks for Zelda 1, but I am kinda confused with all of it. Could someone help me understand the doubts I have?


• I see there are MMC3 and MMC5 conversions for Zelda 1. Which one is better or recommended of the two for the purpose I'm trying to make? Which is animated tiles in the Overworld.
• For the MMC5 hacks, I noticed there's actually TWO of them made by the same person, RetroRain. I tried contacting him for clarification on what is the difference between the two, but he doesn't seem to be online here as much. Anyone knows the difference between the MMC5 conversion and Optimum?
• If there's a hack that modifies the first 0x10 bytes of the ROM (which I think is the header part), how would I go about modifying said bytes through xkas? If I use bank 0; org $8000 it starts modifying after 0x00010 I believe, but not before that.

If anyone knows an answer to any of these questions, please let me know!
It'd be really helpful for the remaining stuff.

[bogaabogaa]

That should be located at 0x16C96 in the ROM.
...

Also, one REALLY odd stuff I found out today.
If you change the tile for the bombs in the HUD to a blank, the game refuses to change screens at all.

Around 0x16c96 is a table that will get drawn to RAM $302 on some point. The table contains PPU offsets and counters for the length of tiles to draw. You might have mistaken something for a tile value, what does something else. This table in RAM will get updated with current counts of heart, ruby and bombs in RAM before it will be written to the PPU pattern table. Oddly enough the ruby,arrow,key and bomb are in a other table with a different format and will get drawn at the screen when you spawn.

Here the description for the Table you mentioned:

Spoiler:

/exa 20B608 2424242424242424 20D608 2424242424242424 206C03210024 20AC03210024 20CC03210024 FF
/des uuppss nnnnnnnnnnnnnnnn uuppss nnnnnnnnnnnnnnnn uuppssnnnnnn uuppssnnnnnn uuppssnnnnnn ff   
/des        HeartRowTop             HeartRowbot      ruby         key          bomb          (add two digit entery 208c022100)
/ uu PPU page number high
/ pp PPU page number low
/ ss Leangth of data transphered
/ nn Symbols for nambetable
/ ff End of Table

So to change the bomb it should be at PRG $1bf37. This is true for redux what is a patchwork master-peace ;P (AND YES THAT ONE CRASHES WHEN VALUE $24 lol sry... This would take some debugging)
The bomb is a sprite after the first screen transition. Before it is a heart. This is one way to hide a Sprite 

The table you described is one I moved and expanded. I added a lot of space so in theory you could add all kind of things there. I did not have a idea for it so far.   

May 16, 2020, 11:25:24 pm - (Auto Merged - Double Posts are not allowed before 7 days.)

I've been trying to dive into the MMC3/MMC5 hacks for Zelda 1, but I am kinda confused with all of it. Could someone help me understand the doubts I have?

1 MMC3 and MMC5 do both support CHR bank swapping so they are both good for that. The MMC5 does have a bunch more features. Like more freedom on how to arrange CHR banks. Best thing you look it up at NESDEV. MMC3 might be more compatible with older devices since MMC5 was hard to add on some emulators or power packs. But when hacking it is nice to have a extra 1k PPU sprite window or toy around with music or 8x8 tribute table.

2 Retrorain is awesome to share a hack like this since it might be hard to get into that. Still he added only basic support. You still have to add CHR ROM and hijack GFX loading tables to add proper CHR bank assignment. The patch does not have that much things in it. He will probably expand the space to make it possible. Put the basic MMC5 setup at the Vector bank and drop to the old vector to reset form where the game runs normal. There will be a new bank-swap routine and hijacks of the old once. Might be a challenge to get it all working.

3 When you tell Xkas that it has a header just add a db. Here a example:

Spoiler:

//-------------------------------------------------------------------------------
// iNES Header
//-------------------------------------------------------------------------------
           db $4e,$45,$53,$1A       // Header (NES $1A)
           db 16                   // 12 x 16k PRG banks
           db 00                  // 0 x 8k CHR banks
           db %01010001            // Mirroring: Vertical
                           // SRAM: Not used
                           // 512k Trainer: Not used
                           // 4 Screen VRAM: Not used
                           // Mapper: 5
           db %00000000            // RomType: NES
           db $00,$00,$00,$00     // iNES Tail
           db $00,$00,$00,$00   
//-------------------------------------------------------------------------------
// ROM Start
//-------------------------------------------------------------------------------
bank 0;
   org $8000

                 

You could add the header to the MainASM. Or just make sure to add it in the first file that will get processed.
[/list]

[ActionGamer]

Hey man, I just wanted to say I'm loving this Zelda 1 Redux hack so far. I'm actually make a Zelda 1 hack using this hack as a base.

Here you can look at a preview here: http://www.romhacking.net/forum/index.php?topic=30678.0

[ShadowOne333]

@bogaabogaa Oh I see.
So the table I posted was indeed made by you when you did the Arrows and Rupee hacks.
Glad to know

It really helped to make the rearrangements I wanted to make really easy, thanks for that

As for the MMC3/MMC5 stuff, oooofff.
It really seems like a lot more than I can chew.

I'm still indecisive in between MMC3 or MMC5, since basically all I want to do is just add animation frames for water/cascade tiles, and perhaps be able to separate the tilesets from Overworld and Dungeons to possibly adding burnable trees, but I am mostly interested in the animation for Water tiles, the other I can live without.

I tried disassembling Optimum's MMC5 conversion, and this is what I did:
https://pastebin.com/S0esDdUz

It still needs the rewrite of the first line to accommodate your Header explanation, but everything else should work I think. All that's needed is extracting the graphics from the ROM into a file called "mmc5gfx.bin".


But aside from that, I have no clue as to how to complete the hack for bankswitching lol.
Or if I should instead focus on making the MMC3 conversion for better compatibility.

I don't think going full-on MMC5 is necessary, since I just want water/cascade animation tbh.
What do you think, should I use MMC3 instead for better compatibility, or continue with MMC5?

--------------------------------------------------------------------------------------------------

@ActionGamer nice dude!
Hope your hack goes well.
I'd just not going full-in with the Redux features yet until Redux sees a proper release, since things are still in beta and might be prone for bugs/glitches.
I still have to fix some stuff to make it 100% bug-proof.

[Trax]

MMC5 is overkill. MMC3 is probably reasonable, but still not a trivial task. Do it only if you really think it's within the scope of the hack.

[bogaabogaa]

If you think the MMC3 might be easier to work with. I don't think this is true in therms of hacking. Sure it is a different topic when it comes to reproduction. I guess you need donation bord for both mapper. Would be interesting to hear about that.

Here is the MMC3 mapper layout for CHR RAM.

;MMC3 CHR Config
;
; The chr is divided like this (but it can be
; inverted to switch which side gets 2 and which
; side gets 4 banks).
;

Code: [Select]

;   8kb Nes ppu-chr-ram     MMC3 mapper                     
;MMC3 CHR Config
;
; The chr is divided like this (but it can be
; inverted to switch which side gets 2 and which
; side gets 4 banks).
;
;
;   8kb Nes ppu-chr-ram     MMC3 mapper
; ______________________  ______________________
; | 0  $0000-$FFFF     |  | 2 Mapper Bank      |
; |                    |  |____________________|
; |                    |  | 3 Mapper Bank      |
; |____________________|  |____________________|
; | 1  $1000-$1fff     |  | 4 Mapper Bank      |
; |                    |  |____________________|
; |                    |  | 5 Mapper Bank      |
; |____________________|  |____________________|
;
;  8kb Nes ppu-chr-ram     MMC3 mapper
; ______________________ ______________________
; | 2 $0000-$07FF      | | 0  Mapper Bank     | 
; |____________________| | $1000-$2000        |
; | 3 $0800-$0FFF      | |                    |
; |____________________| |____________________|
; | 4 $1000-$17FF      | | 1  Mapper Bank     |
; |____________________| | $2000-$4000        |
; | 5 $1800-$1FFF      | |                    |
; |____________________| |____________________|
In case of the MMC5 you can choose the 4 bank layout for both sides Sprites and Tiles. For the Sprite you have a extra 8kb window to map. 4 banks to animate sprites or tiles if you choose the smallest bank for CHR. This will make it easier to animate individual banks for tiles or sprites without wasting unwanted CHR space. So far I feel like the MMC5 gives you more freedom. I know this will not make it easier to decide. I personally like more freedom.


Adding CHR is also not that complicated. There is a pointer table in the ROM where it usually does load tiles to the PPU. I would use that table and dump the CHR RAM in the same order. You can just write the pointer and dump one after the other then pasting them in a CHR.bin you can add it to the end of the ROM. When hijacking this routine to load the pointer with LDA $1234,x it is easy to have the right bank in that table. Instead of loading you write to the mapper register to switch banks.

[ShadowOne333]

Hard to tell tbh, I'm still torn as to what road to go to hopefully achieve animated water tiles.
I'll attempt disassembling the MMC3 conversion alongside the MMC5/Optimum too.
Once both conversions are disassembled, we can see which one to go for the animated tiles lol.

The MMC5 one is already disassembled, I'll just need to make the proper header for it, and I'll start the MMC3 one today.

------------------------------------------------------------------------------------

Aside from that, I added some slight changes to the repo during the weekend.

1) I fixed the Recoloured Dungeons patch, since some people reported that after coming back from stairs, the dungeon goes back to the default colour scheme. This has been fixed, and I also went ahead did two more things to this patch:

   * Made it so that the sprite palette now matches the dungeon colour instead of using the original's palette (this affected certain things as movable objects like the blocks to make stairs appear, and certain enemies like the Gels/Zols, they now match the dungeon colour like in the original Zelda 1).
   * Changed the palette for the Dark Rooms, so they also match the palette of the recoloured dungeon now.

If we really want to be picky with this patch, then there's still the fade-in/fade-out effects which still use the original dungeons, but to be honest those go by so quickly that they're not that noticeable, so right now I won't bother with those.


2) I made a new optional patch. This one is rather small and quick to do. The new patch disabled the low health beep sound as requested by some people, and to make it in-line with the Zelda 2 Redux optional patch of the same vein.

------------------------------------------------------------------------------------

Okay so I think I'm done with the MMC3 conversion disassembly?
Or so I think lol

Here's the disassembly for MMC3:
https://pastebin.com/kPsFGCgf

And for reference, here's the MMC5 (Optimum) one I posted previously:
https://pastebin.com/S0esDdUz

I have only one question, and that's the header part.
I think I understand the parts of it, but I am confused by the 4th and 5th bytes.
@bogaabogaa in the code you posted for the iNES header, you had those two bytes without "$" in them, does that mean those values are in decimal?

Here's what I have for the 3 headers (the first line in the MMC conversions are the offset and Hex values changed):

Code: (Original Zelda 1 Header) [Select]

db $4E,$45,$53,$1A // Header (NES $1A)
db 08 // 8 x 16k PRG banks
db 00 // 0 x 8k CHR banks
db %00010010 // Mirroring: Vertical
// SRAM: Not used
// 512k Trainer: Not used
// 4 Screen VRAM: Not used
// Mapper: 1
db %00000000 // RomType: NES
db $00,$00,$00,$00 // iNES Tail
db $00,$00,$00,$00


Code: (MMC3 Conversion) [Select]

// 0x00006 - 42
db $4E,$45,$53,$1A // Header (NES $1A)
db 08 // 8 x 16k PRG banks
db 00 // 0 x 8k CHR banks
db %01000010 // Mirroring: Vertical
// SRAM: Not used
// 512k Trainer: Not used
// 4 Screen VRAM: Not used
// Mapper: 4...?
db %00000000 // RomType: NES
db $00,$00,$00,$00 // iNES Tail
db $00,$00,$00,$00


Code: (MMC5 (Optimum) Conversion) [Select]

// 0x00004 - 40 80 52
db $4E,$45,$53,$1A // Header (NES $1A)
db 64 // 64 x 16k PRG banks
db 128 // 128 x 8k CHR banks
db %01010010 // Mirroring: Vertical
// SRAM: Not used
// 512k Trainer: Not used
// 4 Screen VRAM: Not used
// Mapper: 5
db %00000000 // RomType: NES
db $00,$00,$00,$00 // iNES Tail
db $00,$00,$00,$00


For anyone adept enough, please check those header values and let me know if they're correct.
Also, let me know if the disassemblies seem good enough or not.
I already have the MMC3 one ready, and the MMC5 is only lacking the proper header info, and that's it.
Apart from that, I have zero clue as to how to implement this to properly make bankswitching and make the tiles change lol

Also, I noticed that both MMC conversions seem to modify code at the end of bank 7, around the 1FFXX section of the ROM.
IIRC, some code from Redux already uses that section too, so it seems like there will be some code collision in there, unless there's a way to still make both codes work (Redux & MMC) alongside each other.

[bogaabogaa]

Yes numbers in any assembly file I know off are in decimal till they have a prefix like $ff. Some debugger use 0x12af as a prefix. In ASM6 you can write write "hex 1a 2b .." sadly this is missing for xkas assembly patcher. I like to write numbers as binary to see what bit needs to be flipped. This is done with %00001111 what would be the same as $0f in hex. It will also help if you have to solve logic for "or" "and" bitwise operation. In the beginning you might look up a true table for the operations but after a while in just is obvious.

Instead of me explaining the header look it up here.
https://wiki.nesdev.com/w/index.php/INES

Use Mesen and open the debugger window. Below tools you will find INES Header Editor. There you can make changes and see how it updates the header.

I did see you used 64 PRG Banks for MMC5 header. That would give you 1MB ($40 x $4000 byte in hex) also you don't have CHR Space yet. This you would add to the header when you add the graphic banks to the end of the room. This task will give you a idea how to go about to extending a ROM.
Different mappers have different registers to change banks. This is why you have to hijack the old and hack in a new routine for bank swapping. They are located at the vector bank (last bank) since that one is always present. At CPU offset $fffa you will find the NMI pointer. $fffc is reset pointer and $fffe is BKR/IRQ. This is called the vector table and true for any nes ROM I believe. 

I just did add CHR to the MMC5 for CV1 and Jackal. Jackal is still buggy with CHR. I can add CHR for you if you don't trust yourself to do it. Will hit you up on discord about it.

[ShadowOne333]

Sorry for the late reply.
Thanks for the info, Bogaa.
I now understand iNES headers a bit better, and I have now properly implemented the original header of Zelda 1 with code in the source code

I have just pushed a fix for the Old Man text, since his text was broken due to some overflow that went into the text point table, and it turns out it modified the exact pointer for the Old Man.

Also, aside from that, there hasn't been much work lately into Redux that could interest most users.
There's currently a lot of work and back and forth talk involving converting the game to MMC3 or MMC5, so we can have more graphics and animated tiles, but there is nothing yet to show in that regard.

I've also been absent due to work stuff and other tihngs, that's why things got somewhat slow.
I'll try to get back to this now, but I don't think there might be much to show until the conversion gets settled and we have a PoC of animation ready.

Still though, if you guys find anything weird, bugs or glitches, please let me know here!

[ifightdragons]

Very much looking forward to release, whenever that may be!

[ActionGamer]

Is there any update about how the projects going?

[ShadowOne333]

Is there any update about how the projects going?

Well most of the points have already been done.
The only remaining things are:

• Implementation of a Copy/Erase file system like in subsequent Zeldas, where D-Pad Up and Down control the cursor in the File Selection and pressing A brings up the Name screen (Example: ALttP)
• Add water animation (possibly by converting the ROM to another mapper like MMC5?)
• Diagonal sword swing

What I'm currently working on is the MMC3/MMC5 conversion, to hopefully achieve tile animation for water or other stuff.
However, I'm not sure how well it'd play with the current code already done for Redux.
Also, this is something entirely new to me, and I'm trying to figure the whole mapper conversion thing, trying to wrap my head around it, so nothing has come out of that yet.

[pleasejust]

just a thought... wouldn't it be easier to try to decompile zelda so you can see what the code is doing? Mario 1 was decompiled. Even Mario 64 was. Is it a different process for different games?

[ShadowOne333]

just a thought... wouldn't it be easier to try to decompile zelda so you can see what the code is doing? Mario 1 was decompiled. Even Mario 64 was. Is it a different process for different games?

While not really decompilations, Trax did some disassemblies of both Zelda 1 and Zelda 2 some time ago, they're available online. Nevertheless, I think disassemblies are the proper code in which NES and SNES games were made back then, given the whole 6502 and how popular assembly was back then in computers.
The people involved in both Z1 and Z2 Redux projects have been using that as a base to work upon.

So we are way ahead of ya
We are also using that as base for the source code we've been developing for both Redux projects too.

[bogaabogaa]

I think some could use a better understanding of code and what you could do with a proprietary code used to build Zelda from scratch. It does not always make much sense to reverse engineer a whole file if you just like to do some mods for it. The code is not yours so you might get in trouble with it after creating it and yes I am aware that there are a lot of disassembled and documented games for retro consoles on Git. It is not legal even when you find it shared in practice and it is nice this things are not shutdown. Sure I understand that you think it might help to understand the game better. Here I like to say if you write down the code with the data tables in a single document you might end up with around 30 000 line page when you have a 8 bank NES file like Zelda. Even when you invest the time documenting this it would not be the best way to work with a source to just do some mods. What it would be good for is moving large portions of code to other banks and things.. Let me make some examples what you can use the things for your mentioned.

SMB1 Dissasembly:
A full documented assembly source code of a Nes game with one bank of code. The Ram symbols are figured out and named. The code is easy to understand thanks to documentation and the game can be compiled to the original game.
 - You could use this to learn every part of the game you like and I guess it will take time to find parts that can be documented better.
 - You can modified the code and move things around. You can build something different out of it.
 - Even with just one bank this is a large document written in assembly code. The code is edited as text.
 - A source like this takes month or years to generate and is great learning material.

Pure DisASM file without additional Ram symbols:
A full source that can be compiled and run on the Nes.
 - The code can be browsed but to make sense out of it you might need to consult the debugger a lot to get a idea how to name things.
 - This can be used to work out a better source code or to just move blocks of code to get more space for things you have in mind.
 - I like to add if you have more then one bank of code and use DisASM to generate the source there is a view hours of manual editing to make it work.
 - A source like this can be generated in a afternoon.

Mario 64 Source:
This was reverse engineered to C code not just assembly. Could probably be used to make ports to other platforms too. Back in the day they did not build the game with optimization flag (may be buggy around that time). So just building it with that did fix slowdowns. I have no experience with this project so I should be quiet..

Using a injection patcher/ASM patcher:

 - Small files of your code that is fully yours and you can do with it what you like.
 - When documented well what ever the patch is doing can be understand quick and used to patch a game or write a similar patch yourself.
 - Really depends what your going for. But for example speeding up some enemies could be done in a hour without any prior knowledge of the game.

I think this project is set well with some disassembly and the Xkas ejection patcher. A great way to share patches or learn about the game.

[darthvaderx]

Zelda II two players, would this be a good option for the project?

http://www.romhacking.net/hacks/5243/

[ifightdragons]

Zelda II two players, would this be a good option for the project?

http://www.romhacking.net/hacks/5243/

That's for Zelda II, though. This is the Zelda I thread.

Anyway, while that hack is a neat little proof of concept, that's all it really is. The bug testing for a full-featured version of such a game would open up such a Pandora's Box...

I honestly think it might be time to let ShadowOne finish his Zelda hacks, without adding even more to the top of the pile, which will inevitably ensure that the release gets pushed further back.

[darthvaderx]

That's for Zelda II, though. This is the Zelda I thread.

Anyway, while that hack is a neat little proof of concept, that's all it really is. The bug testing for a full-featured version of such a game would open up such a Pandora's Box...

I honestly think it might be time to let ShadowOne finish his Zelda hacks, without adding even more to the top of the pile, which will inevitably ensure that the release gets pushed further back.

Ok.