News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - slidelljohn

Pages: 1 ... 8 9 10 11 12 [13] 14 15 16
This looks really good! Since there is extra screen do you plan on moving the energy bar up any or are you going to leave it in the same spot?

Yes I definitely agree to keep it as close to the original as possible but it still needs to work correctly.

If you want to see it just load the 1st part of the graphics in game set bit 0x80 at $86:F4CE (0x60 + 0x80 = 0xE0) and
it will only load the 1st part. That 0x80 is a bit flag to tell it to load another set of graphics or not to load another set. Look at the data below. The 0xE1 will make it not load any more into vram. After it checks the bit flag it will subtract 0x80 from it.
0xE1 - 0x80 = 0x61.

$86:F4CD 0E 60  //Used to store vram to $C800-$C8DF
$86:F4CF 08 E1  //Used to store vram to $CA00-CA7F

The 1st byte $86:F4CD 0E is how many bytes to dma into vram. The formula is 0x0E x 0x10 = 0xE0. The 0xE0 is the
amount of bytes to transfer. The 2nd byte $86:F4CE 60 is for
where in vram to store the graphics. (0x60 + 0x04) x 2 = 0xC8
Which would be vram location $C800. The 0x04 comes from the data in the event that loads the sub tank.

That image of the tiles in the event editor is not correct.
The last 4 8x8 tiles need to be moved under the 1st 4 8x8 tiles
to complete the 16x16 tiles. Load up the mega man x rom and look at its vram for the sub tank and you will see how it is supposed to look.

I don't think the editor is loading this data:

$86:F4CD 0E 60  //Used to store vram to $C800-$C8DF
$86:F4CF 08 E1  //Used to store vram to $CA00-CA7F
These are all v1.1 of mmx rom.

Can you post a image of the tiles that it is using to assemble
the sub tank? If it's the same image that shows up in the event editor than that's 100% the problem. The graphics do get split up and put in 2 different locations. The last 4 8x8 tiles are supposed to be under the 1st 4 8x8 tiles. Those last 4 8x8 tiles make up the bottom of the 16x16 tiles that get loaded to the screen. If they are not placed there the bottom of the 16x16 tiles will be empty.

The sub tanks do only have 5 tiles. 2 16x16 and 3 8x8.
Do you know if it's loading the data at $86:F4CD and $86:F4CF?

$86:F4CD 0E 60  //Used to store vram to $C800-$C8DF
$86:F4CF 08 E1  //Used to store vram to $CA00-CA7F
These are all v1.1 of mmx rom.

Thanks justin3009, this looks like it will be helpful. Two lines of significance:
Code: [Select]
$00/B22A BD 23 86    LDA $8623,x[$08:8A70]   A:0174 X:044D Y:0000 P:envMxdIzc ;This loads the heart-tank value of 36Graphics number is well-known. You can see that in the event editor window + compression/decompression programs spit out all the addresses and sizes of each graphic in a txt file. I don't get why the accumulator value doesn't reflect that though. A:0174. Why is it not A:036, or A:054 (decimal)?

That is because the accumulator gets updated on the next line, not the line with the LDA. Look at $00/B22D and it should have the 36 in the accumulator.

The image showing the messed up graphics for the energy tank looks like it's loading the tile data correctly. It looks like the graphics that are supposed to be in vram are messed up.
If you look at where the energy tanks graphics are stored in vram they are stored at $C800-$C8DF and at $CA00-$CA7F. The graphics that are supposed to be at $CA00 don't look like they got stored there. Maybe that part of the graphics isn't getting stored in the right location or not at all.  They might be getting stored after the 1st set of graphics at $C8E0 like how they are stored when the are decompressed which would be incorrect for loading the tiles to the screen.

Newcomer's Board / Re: MegaMan X Help Translate READY.
« on: August 12, 2017, 08:41:17 pm »
Your welcome! And never give up. Where there is a will there is a way. Can you post post a picture of your results?

You should consider downloading vsnes and giegers snes debugger. Those 2 programs will help you with your translations. Vsnes is really helpful in finding your tiles that you will need to edit and giegers snes debugger will help with tracing the snes code. That's what I used you help you.

If you need any other help just let us know.

Newcomer's Board / Re: MegaMan X Help Translate READY.
« on: August 11, 2017, 03:16:23 pm »
Sorry. :huh:
Someone can help me? :'(
I need change part down of "D" for down "E"
the game repeats the high part of D turned

now it looks just like that, Need fix "T".

Help me please.  :banghead:

Rom addresses for the D in ready in mmx v1.1 rom
$8D:FCD1 top of D, the value is 0x05
$8D:FCB5 bottom of D, the value is 0x05

Open up a hex editor and change the value at
$8D:FCB5 to 0x02. 0x02 is the bottom of E.
You may need lunar address to convert the rom
address to pc address. Hope that helps with your
project. :thumbsup:

Can anyone explain to me how to compile the source for
Bsnes-plus in QT? I'm used to using the .pro files not the make files. If I can figure out how to compile the source code I'm going to add a ram viewer to the vram viewer plus I'm going to change the trace files to look more like how they look in giegers debugger. The ram viewer will help a lot with my decompression projects.

ROM Hacking Discussion / Re: Wip projects for mmx and 7th saga
« on: August 10, 2017, 08:49:13 pm »
@mrrichard999, @azoreseuropa
Thanks! Next time I get a chance I'll try to post some pictures.

Here is another patch that I have been sitting on for a
little over a year. It's for the 7th saga and all graphics are decompressed. You can now edit all of 7th saga's graphics
in your favorite tile editor without dealing with the compression. Towns and dungeons also load slightly faster.
Check it out and let me know if there are any bugs.

The next 2 patches I'm going to work on are:
1. Mega man x v1.1 no more passwords only sram.
2. Not sure how hard this is gonna be but I will have active battles in 7th saga like final fantasy 3 snes. Probably going to remove mode 7 from inside of battles to get it set up how I want it to look. Lol this one is gonna be fun!

Something else that I'm considering doing is adding sa-1 chip to mega man x but I'm not sure if I'm going to add that or just start hacking the psx version of mega man x3. I already wrote
a graphics decompressor/compressor for the psx version of
mega man x3 I just don't know how to edits sprites yet for the psx.

ROM Hacking Discussion / Wip projects for the 7th saga (Snes)
« on: August 08, 2017, 03:58:40 pm »
Here is a file including 5 projects that I have been working on
for mega man x v1.1 and the 7th saga.

1. There is a video for my mega man x competition cart.
2. I have a patch for all graphics decompressed in mega man
    x v1.1.
3. Another patch for mega man x v1.1 that allows for 128kb
    vram. The 128kb vram patch only works for higan v100
    and up.
4. A mega man x level editor that is in very early stages. Right
    now it only views bg1 tiles. This editor wont be finished for
    a long time and it will only work with my reconstructed
    project for mmx. You must have a 4k screen to view
5. A 7th saga editor. Doesn't edit anything just yet but you can
   view sprites for 7th saga and elnard. It also has a early
   stage paint system you just cant save anything yet.

I haven't posted much in the past few years but I have still been working on some things. I still get asked about my work and new patches so I decided to post these for everybody. These are still being worked on just at a slow pace.

Updated 1-3-18:
I have decided to change this wip page from mmx and 7th saga to just a wip page for 7th saga. I still plan to work on mmx and create new things for it. I changed it because I didn't want to clutter up this page with 2 different games.

News Submissions / Re: Site: RHDN 3.0 Site Refresh Launched!
« on: June 24, 2017, 09:41:23 pm »
And if you're on a cell phone... Why do you want to browse hacks on the cell phone? Do you have roms and a patcher on mobile?
Well because of my current situation over the past 4 years all I have is my cell phone to get online. And no, I don't. Hopefully soon when I buy my house I'll get my desktop back online. So right now all I have is my cell phone and it would be nice to be able to access the desktop version from my phone till I get my desktop back online. Most other websites have the option to choose the desktop version from your phone but I can't seem to be able to access the desktop version of the new site from my phone. Is the new site set up to use the desktop version from a cell phone?

News Submissions / Re: Site: RHDN 3.0 Site Refresh Launched!
« on: June 24, 2017, 05:03:18 am »
Is it possible to view the desktop version from my iPhone?
Hopefully I'm not stuck using the mobile version from my iPhone. There should be a option to choose the desktop version.

Nice work Justin!

Have you thought about using sprites to make the
border for the text box? There should be enough
unused sprites to make the border so you can get
4bit colors instead of 2bit.

Another thing to consider doing is a transparent
window. Not sure if you ever played with color math
but it is fairly easy to use.

The scene map in RAM (composed of tile maps) starts at 7E:2800 and I think the next valid thing in RAM is at 7E:F000 (background scene map).

$60 scenes:
$60 scenes * $40 blocks per scene * $4 tile maps per block * $2 bytes per tile map =  $C000 bytes

$FF scenes * $40 blocks per scene * $4 tile maps per block * $2 bytes per tile map =  $1FE00 bytes
($100 might be possible, but I'm assuming that a value of $0 actually means $0 unique scenes in the code right now and would need to be changed to represent $100)

It looks like the code copies all the scene data to RAM at the start of the level and leaves it there.  So without changing the way it's stored it would use almost all of 128KB of WRAM for $FF scenes.  Some ideas:

1) Store the tilemaps as blocks in WRAM and get 4x savings.  Not sure how much it will slow down the in-level scene management code to have to read the block to get the tile. It should just be an extra 1-2 LDs with some address arithmetic.
2) Dynamically load the scene mapping data and have the level designer setup events to identify which scenes are active at different parts of the level.  I don't like this idea.
3) Some other form of compression.

I prefer (1) if we want to increase the limit.  (2) seems like too much extra work for the level designer to worry about.  They already have to manage VRAM.  And (3) would require compression that supports random access and the editor checking that the scene definitions would actually fit in the allocated WRAM space.

I have been slowly working on a few mmx1 projects
for awhile now and one of them is redesigning the rom
so it can play like super metroid. I have two ways that
I came up with for adding more scenes.

1) I have completely removed the graphics
compression in the rom freeing up all ram located
between 7F:0000-7F:7FFF. So now there is 25% of
the roms ram I can use for whatever I want like extra
scenes, weapons and items. My code is already about
95% complete just a couple small things left to do.

2)I will place doors in the level like in super metroid so
when you walk through them it will load new areas so
scene data will be changed in the new areas.

Expanding the number of unique scenes seemed like an important part of designing larger and more detailed levels.  It ended up being $60 for a weird reason - the code runs out of space in RAM with larger values and starts overwriting other things.  I originally tried to add $FF total but it ended up wrapping around in RAM and overwriting all sorts of important things like the controller input and sound related stuff.

How many more bytes of ram do you need to go from $60 scenes to $FF scenes?

Not sure if you have all of mmx1 sprites loading
correctly yet but x3 looks like they are loaded the
same way. There are values stored between
7f:8000-7f:83ff that the the sprite asm algorithm
uses. The data stored there comes from the 6 bytes
that are the sprite, vram location, and palette...
I'm not 100% sure but I think the sprite data is
loaded that way to prevent people from easily adding
new enemies to the rom. They did a couple things
in mmx1 that I know of to prevent easily expanding it.

This shows you where the priority bit is.

I'm curious do you have vsnes? If not you should get
it because it will help you out a lot with building your
sprites and setting the bits for priority, color palette,
flipping. If you don't have vsnes I can show you how
to use it if you can't figure it out.

Also if the first and second tile in oam ram have the
same priority bit set the first tile will have priority over
the second tile. You could try drawing the last tile for
each sprite first and the first tile last and that will
probably solve your priority issue.

Glad to see this is being worked on again. I have a lot of the level data figured out and documented for v1.1 ROM. Here is a little bit of code that might help you out with the sprites graphics and color palettes. I have a bunch of documents i can send you that would save you a lot of time if you are interested in them just pm me your email and next time i get a chance I will send them to you.

/*part of level data of 1st level when you start a new game*/
$85:8302                  02      type of event                02 = graphics and color palettes
$85:8303-$85:8304 80 01 X location
$85:8305                 15      ???
$85:8306                  11     graphics and color palettes  stored at 7e:1d20
$85:8307-$85:8308 C0 81 Y location                   

/*where level data for graphics and color palettes for enemies, cars... are stored in ram*/
7e:1d10-7e:1d15                                //??? maybe here too not sure
7e:1d20-7e:1d25 80 01 15 11 16 FA             

/*step 1 of asm code for loading new vram for enemies, cars, .....*/
$83/FE0C E2 30       SEP #$30                 
$83/FE0E A5 0B       LDA $0B    [$00:1D23]       //$7e:1d23
$83/FE10 29 0F       AND #$0F               
$83/FE12 8D 08 1F    STA $1F08  [$86:1F08]    //$7e:1F08 graphics palette pointer

/*step 2 of asm code for loading new vram for enemies, cars, .....*/
$80/B09D AD 08 1F    LDA $1F08  [$86:1F08]   
$80/B0A0 29 FF 00    AND #$00FF               
$80/B0A3 0A             ASL A                   
$80/B0A4 85 00        STA $00    [$00:0000]   
$80/B0A6 AD 7A 1F    LDA $1F7A  [$86:1F7A]     //$7e:1F7a current level
$80/B0A9 29 FF 00    AND #$00FF
$80/B0AC 0A             ASL A                   
$80/B0AD AA             TAX                     
$80/B0AE BD EE AC    LDA $ACEE,x[$86:ACEE]     //$86:ACEE start of data for each level
$80/B0B1 18            CLC                     
$80/B0B2 65 00       ADC $00    [$00:0000]   
$80/B0B4 AA            TAX                     
$80/B0B5 BD EE AC    LDA $ACEE,x[$86:AD36]     //pointer to graphics and color palettes
$80/B0B8 AA             TAX                     
$80/B0B9 E2 20        SEP #$20                 
$80/B0BB BD EE AC    LDA $ACEE,x[$86:B647]     //graphics and color palettes
$80/B0BE C9 FF         CMP #$FF                A:0939 X:0959 Y:0000 D:0000 DB:86

/*data to load for graphics and color palettes for enemies, cars... (1st set 1st level)*/
39 C0 14 9C 00 50
3A C0 17
9E 00 60
3B C0 1B C0 00 70
1F 00 10 3E 00 40 FF //FF = end of data to load
 |         |   |
 |         |    --------color palette
 |          -----------location in vram to store graphics
  -------------------graphics (1F = spiky)

Newcomer's Board / Playstation 1 hacking
« on: January 26, 2014, 11:16:28 pm »
I was gonna see if someone knows some good tools and documents that I can use for playstation 1 hacking. I did some searching but I'm having a hard getting started I already know snes programming and c++ so I should be able to pick it up pretty fast. I want to try and hack mega man x3 on the playstation 1 because the Super Nintendo is not powerfull enough to properly run any mega man x game without glitching plus I just need a more powerfull system for what I want to do to the mega man x series. If I can just edit a few bytes in a hex editor and save it to a disk to play on my modded playstation 1 that would be a huge step forward. Any help getting started would be much appreciated.

Pages: 1 ... 8 9 10 11 12 [13] 14 15 16