61

Programming / Re: 6 bit text encoding

« on: September 03, 2020, 09:18:13 pm »

 

62

Newcomer's Board / Re: I have MSCOMCTL.OCX but...

« on: September 03, 2020, 08:13:42 pm »

Did you try this?
https://thegeekpage.com/mscomctl-ocx/

63

Programming / Re: How to: Command line tool

« on: September 03, 2020, 11:57:14 am »

Awesome!

64

Programming / Re: How to: Command line tool

« on: September 03, 2020, 11:27:30 am »

@GuyPerfect
I did say:

Not the best way to do it

There are many ways to use the command prompt. You can even have a bat file.
Sometimes for people that never use a command prompt they forget how it works
and how to set the path and sometimes its easier to just add the cmd file to
your folder that your tool is in so you don't have to type the path that the
tool is in. Just open cmd and your there.

@EmRoKtheVerdant
Did you try this? I dont have the game to test.

65

Help Wanted Ads / Re: Sutte Hakkun Level Editor (searching a competent programmer)

« on: September 02, 2020, 11:56:45 pm »

Can you explain the compression format and show the assembly for it?

I seen your translation(nice work) and you posted 4 pictures for it:
1. 2.
3. 4.

In the 3rd picture what is up with the letter m for them and from? It doesn’t look right.

66

Programming / Re: Understanding Sprite Assembly, Decoding C++

« on: September 02, 2020, 11:38:40 pm »

This link is useful for snes registers
https://wiki.superfamicom.org/registers

This link is useful for snes assembly but I mostly learned
from looking at and editing code to see how it works.
https://wiki.superfamicom.org/65816-reference

I’ll try to have something posted by tomorrow showing how
I found the data and how it works. I’ll also upload a tool to unpack some of the mmx v1.1 files.

67

Programming / Re: How to: Command line tool

« on: September 02, 2020, 11:12:43 pm »

I copy cmd from system 32 folder in windows and put it in the same directory as the tool then open cmd from there. Not the best way to do it but it works sometimes when you can’t get the path right. What tool is it?

68

Help Wanted Ads / Re: [Technical] Forcing CONTRA III (SNES) to completely SKIP top-view levels

« on: August 30, 2020, 06:35:10 pm »

You’re welcome! 
Did it work?

It is super simple

Yes, it is simple. It doesn’t seem so hard to do when you see
how it’s done. Hopefully you will take the necessary steps to
skip the next one on your own. Anything you can’t figure out
just ask the right questions on what you’re trying to figure out and I’m sure someone will help you. You probably didn’t get the help you were looking for because when you asked:

Is there someone capable to help me with this hack?

It was more like:
Is there someone capable to do this hack for me?

Also stuff like this isn’t what the help wanted ads section is for.
This should probably be in the romhacking discussion page.

69

Help Wanted Ads / Re: [Technical] Forcing CONTRA III (SNES) to completely SKIP top-view levels

« on: August 29, 2020, 08:50:52 pm »

Here is a patch for it:
http://www.mediafire.com/file/hrsy2b7qplm88ae/file

Code: [Select]

step #1

Disassembly: original code
$00/B6FF 22 9F B9 00 JSL $00B99F[$00:B99F]

Disassembly: modified code
$00/B6FF 22 00 FF 01 JSL $01FF00[$01:FF00]

Disassembly: new code
$01/FF00 C9 02 00    CMP #$0002             
$01/FF03 D0 01       BNE $01    [$FF06]     
$01/FF05 1A          INC A                   
$01/FF06 22 9F B9 00 JSL $00B99F[$00:B99F]   
$01/FF0A 6B          RTL                     


Code: [Select]

step #2

Disassembly: original code
$00/B79E E6 86       INC $86    [$00:0086]   
$00/B7A0 A5 86       LDA $86    [$00:0086]

Disassembly: modified code
$00/B79E 22 10 FF 01 JSL $01FF10[$01:FF10]   

Disassembly: new code
$01/FF10 E6 86       INC $86    [$00:0086]   
$01/FF12 A5 86       LDA $86    [$00:0086]   
$01/FF14 C9 02 00    CMP #$0002             
$01/FF17 F0 F7       BEQ $F7    [$FF10]     
$01/FF19 6B          RTL                     

This is how I added the modifications and saved it:

Download this:
https://dl.smwcentral.net/11501/SNES9Xdebugger.zip

original code


modified code


Anytime you want to save the modified code just hit the save rom
button in the hex editor that is included in the debugger. You can
do it my friend!

70

Help Wanted Ads / Re: [Technical] Forcing CONTRA III (SNES) to completely SKIP top-view levels

« on: August 29, 2020, 08:11:14 am »

To skip level #2 try this custom code.

At 00/b6ff

Put this
22 00 ff 01

At
01/ff00

Put this
c9 02 00 d0 01 1a 22 9f b9 00 6b

At
00/b79e

Put this
22 10 ff 01

At
01/ff10

Put this
E6 86 a5 86 c9 02 00 f0 f7 6b

71

Programming / Re: Understanding Sprite Assembly, Decoding C++

« on: August 28, 2020, 09:15:08 pm »

@bosn
I'm not sure if you were talking to me or pianohombre but I have found most of my notes
for the mmx v1.1 data structure for the sprites that I will hopefully have posted within
a few days so everyone will have access to it.

The problem is trying to find what values control what. I'm not even sure which variable controls the starting point for the graphics table in the editor (you need an address obviously which is like searching for a needle in a haystack.) But that's not all that's required. Several variables control graphics disassembly and assembly. It may use the same compression algorithm as MMX1-3, but I'm not sure. So I may have to use like an exception clause for RNF to run a separate function/class that handles this game's compression, assembly, etc. I have the addresses for the graphics pointer table I was able to find by a disassembly program, but I think there's like an offset value or something (another unknown that has be included in the function).

I found the majority of my notes for how the data works which I will post soon but from what
you have said it seems like your biggest problem is understanding how the snes hardware works.
If you understand the hardware you should(or seems like you should) be able to find out how
the data works. I would like to show you how to figure out how the data works instead of just
showing you how the data works.

To be able to figure out and understand the sprite data own your own you really need to know how the snes:

1: cgram registers work
2: oamram registers work
3: vram registers work
4: 65c816 assembly language works

Knowing how these snes registers work will give you the ability to trace the assembly code
backwards to the location of the data. If you know these 4 things the data wont be like
"searching for a needle in a haystack" it would be more like hunting your prey.

If there is any of the 4 things listed above that you don't fully understand just let me know which ones
and I'll walk you through each one in search of the mmx data that you need to understand to accomplish your
goals with the mmx editor.

As far as the c++ I'm probably not going to be much help with that part but I can do a little bit.
I mostly use QT for my c++ and I do have some stuff written for mmx to view the levels and sprite
data but nothing I have available yet to edit the levels and data. It will probable be awhile before
I'll be ready to finish my QT c++ programs for mmx but it is something that I would like to finish
eventually.

72

Programming / Re: Understanding Sprite Assembly, Decoding C++

« on: August 17, 2020, 05:14:18 pm »

I would like to help you accomplish your goals with this editor or a new mmx editor from scratch. I’m not sure when I will be able to put the information together for you to understand how the graphics for the sprites work but I will get that to you as soon as I’m able to.

73

Personal Projects / Re: slidelljohn (a.k.a.[J]) snes projects page

« on: October 22, 2019, 07:21:48 am »

So this is a Super SNES-ROM-ROM upgrade?

Um...yea

@slidelljohn
why is underground stage 3 so slow? And why do the stars still stay on BG using 30 sprites? is it possible to remove?

I’m sure there are more than a few things causing the slowdown on stage 3. The stars are both on a background layer and on the sprite layer. The stars that are on the sprite
layer uses 25% of the games sprites which I do not like but
it is how the game was made. And yes, you can turn the stars off on the sprite layer by changing one byte in the object data but that 25% of sprites will still be reserved for stars in oam-ram. If I make a new gradius game I will probably completely remove the stars that are sprites so there can be more enemies and bullets on screen.

74

Newcomer's Board / Re: Starting Snes Rom Hacking

« on: October 22, 2019, 06:45:43 am »

Your welcome, and thanks! I have a lot left to do
with gradius but I also have projects for 7th saga
and mega man x.

The vsnes tool will help you find what you are
looking for and you should play around with it.
For the sprites you need to look for the oam
ram. Open vsnes and a savestate that has a
sprite that you are looking for like maybe your
ship. After you open your savestate in vsnes
open the hex viewer in vsnes and scroll to oam
ram. The oam ram is the data for your sprites.
The link for the sprites that I posted shows you
that each sprite uses 4 bytes in oam ram. In the
scene viewer if you show the sprites you can see
them change if you change the bytes in the oam
hex viewer. Usually if you look at the oam ram
in the hex viewer you can find the same bytes
in the wram hex viewer. If you can find the oam
data in wram then you can trace your code back
to find out how that data got there for that particular
sprite. You can also do this with cg-ram which is for
your color palettes. Play around with this for awhile
and see what you can find. As you find stuff keep
notes for it in a rom map and a ram map. The more
stuff you document the more you will understand.

Here is a test for you. Try to find your ships color palette
in the rom.

Step #1 find ship color palette in cg-ram
Step #2 find cg-ram in wram
Step #3 trace code back to find out how it got in wram

When you go to trace the code for finding the color palette
make sure that you do not use trace once when you
trace the code. When you go to trace the code start the
trace just before the data for the color palette gets loaded
into wram then stop tracing after you see it appear in wram.

75

Newcomer's Board / Re: Starting Snes Rom Hacking

« on: October 15, 2019, 02:10:45 am »

Good tools for snes hacking:
geigers snes debugger
vsnes for viewing geigers snes debugger savestates
bsnes plus snes debugger
lunar ips
lunar address
lunar expand
Tile Molester

Good reference material for snes hacking:
https://wiki.superfamicom.org/65816-reference
https://wiki.superfamicom.org/registers
https://wiki.superfamicom.org/memory-mapping
https://wiki.superfamicom.org/sprites
https://wiki.superfamicom.org/backgrounds

I know that you mentioned Gokujou Parodius on one of your other post so
I created a trace file of some of its code for you to look at.
http://www.mediafire.com/file/mjyp26xqzmd5jvm/Gokujou_Parodius_%2528J%25290000.log/file

This file was created using geigers debugger. In the debug console
I had trace once checked then I checked CPU under logging and then
I pressed the run button to run the game. I let the game trace code
until I started the 1st level then I unchecked CPU under loggin to stop
the trace. Checking the CPU under logging is what starts tracing the
code that the cpu is executing. Having the trace once checked will make
the trace file only document a section of code once. If it was not
checked then it could trace the same code multiple times. I only
sometimes use the trace once feature when tracing the cpu code. These
trace files get created in the same location as your rom that you
loaded into geigers debugger.

In the trace once file that I posted I put a few comments showing what
a few of the lines of codes are for on the 1st 2 sections of code.

When you start a game you start with 2 lives. Your lives value is in
ram at $7E:00A4 and in rom at $81:D72B

I put comments at lines:
$80/C642
$80/C645
$80/8782
$80/8785

Search for these in the trace file that I posted so you can see how the rom
value for your lives gets loaded from rom and stored to ram. If you want to
start with 4 lives instead of 2 click the show hex button in geigers snes
debug console and under viewing select rom then scroll down to 81:D72B
and change 02 to 04 and then hit save rom. Now you have saved your rom and
every time you play you will start with 4 lives. Just be sure to make a copy of
your rom file before you save it so you have a backup of the original file.

Remember google is your friend and a lot of questions that you might have
could be found by using a search engine or by reading the many documents that
are on romhacking.net.

Happy hacking and good luck on your journey into snes hacking.

76

Personal Projects / Re: slidelljohn (a.k.a.[J]) snes projects page

« on: October 14, 2019, 08:04:23 pm »

That’s great MMR!

I’ll I see if I can help get you some good information to help you get you started later tonight or sometime after midnight.

77

Personal Projects / Re: slidelljohn (a.k.a.[J]) snes projects page

« on: October 14, 2019, 05:17:35 pm »

I don’t know what a sprite count code is but there is a limit of 128 sprites and the sprites data is stored in oam ram. I’m not sure what asar is but it sounds like it’s a compiler. I never used a snes compiler before but I should.

@slidelljohn

Is it possible to put more code on the same line as the original code using asar? or have to expand the rom?

It’s possible to write new code without expanding the rom but it just depends on what code you are writing and if there is free space in the rom that you are using.

It’s seems like you are wanting to learn but you have a lot to learn and it would be best to start a page in the newcomers section so you can get a variety of help from the whole community. If you start a page I can help you figure some things out. It’s really not hard to learn snes rom hacking as long as you put the time into learning it.

78

Personal Projects / Re: slidelljohn (a.k.a.[J]) snes projects page

« on: October 14, 2019, 03:24:06 pm »

Yes, I think you do have the bits correct.

“what if they want to play using their original cartridges”

You only need the unused ppu pin for 128kb of vram but I
had to use one of the unused cpu i/o pins with 128kb of vram ppu pin to get original unmodified games like yoshi’s island to work. It seems like it would be good to have 2 128kb settings and 2 256kb settings. For me and what I wanted out of the extra vram it doesn’t really matter to me if no original games work because I want to modify games to use the extra vram. I only made the modchip like that so other people can still play original game carts with it if they wanted to but I guess no matter what we will still probably run into issues with original games. I can put switches on the modchip to fix some games but that means you still need to open the console to flip the switch. I guess whenever you run your test try using yoshi’s island and see what you think the best option would be.

79

Personal Projects / Re: slidelljohn (a.k.a.[J]) snes projects page

« on: October 14, 2019, 04:33:55 am »

@Revenant
“am I correct in understanding that writing all zeroes to $4201 will select the second 128kb VRAM bank?”

No, I do not think that is correct. I think if bit 0 and 1 are not set for $4201 it will activate the second set but give me a day or two and I’ll get you the exact details for how it works but I’ll try to get it to you tomorrow night when I have time to look at my docs. I also think I have a working 256kb mmx patch somewhere that kept the menu graphics on the second 128kb set. I do have a snes console with the mod installed that I can ship to you for free for researching how it works on real hardware. If you would like to have the console just pm me a address to send it to and I’ll ship it priority mail and you can get it this week.

You are probably having problems with the multitap because $4201 is for the joypads and you are zeroing out all of the bits. 2 bits are used for the controllers and the other 6 are not used for anything. There are 8 pins on the cpu for each bit for the joypad I/O ports $4201. The last 2 pins I think bit 7 and 8 are connected to the controls and the other 6 are not connected to anything on the motherboard. When you do your testing I think you need to have 128kb vram activated when you activate 256kb. So try only using those 2 bits/I/O ports.

I’m not sure if qwertymodo has done any reasearch on the modchip but he does have one of my consoles that I gave him with the modchip and he may have done some research that could possibly help.

Thanks for adding the support to bsnes plus I really appreciate it and I’m sure the snes rom hacking community will appreciate it too once we start to get things going with the extra vram.

Also I think I should mention some games will have problems with the modchip but they will only need a minor patch to get them to work correctly. I think rushing beat shura was one of them. In the beginning of that rushing beat game it sets and unsets the bits constantly at $4201 causing vram data to get stored on the different sets of vram but I patched it and it worked correctly afterwards. Yoshi’s island doesn’t work correctly using just the extra unused ppu pin for 128kb of vram but it shouldn’t cause any problems when using it with the unused cpu I/O pin. When I create the next mod chip it will have switches on it to turn the extra vram on or off so original games will still work if needed.

Is the vram viewer capable of displaying both 128kb sets of vram at the same time? If not, can you make it to where it does so I can run a few test?

Can you try patching the stuff for the multitap that writes to the unused bits at $4201 so it only writes to the used bits and see if that fixes most of the multitap stuff?

It might be a good idea to have two ways to enable 128kb of vram. One having only the unused ppu pin used and the other with having both the ppu and the cpu pin used. My next version of the mod chip will probably have a switch for this.


@MMR
I’ll try to help you get started. It will probably be a good idea to start a how to snes rom hack page on the new comers section so multiple people can help you get started. I use giegers snes debugger for most of my snes hacking and vsnes for displaying the Geiger’s save state data. I also use bsnes plus for snes hacking. I currently do not use a compiler so I do not know which one is best but I should use one.

80

Personal Projects / Re: slidelljohn (a.k.a.[J]) snes projects page

« on: October 09, 2019, 02:47:55 pm »

Thanks MMR! The patch is getting better thanks to the
optimizations that Aaendi has been doing. I should use my words more carefully so no one gets confused when I say almost equal to or slightly faster than the sa-1 patch. The sa-1 is about 3 times faster than the fastrom so the game definitely isn’t running the code nowhere near as fast as the sa-1. The code is being optimized to use less code that is more efficient than how the original programmers written the code therefore making it appear almost as fast or possibly in the near future slightly faster. Adding new features and more enemies on the screen the sa-1 chip would be the way to go due to the 3x speed over fastrom but there is still a limit to how many enemies/sprites that can be on the screen and per line. If you would like to do optimizations in the parodius game you should look into creating a disassembly file of all of the code in that game. The fastrom patch that I made was created using my disassembled code that I uploaded to romhacking.net. You should look at that file to give you a example of how you could create a file like that for your parodius game. I do plan on creating documents of the before and after of the optimizations that I have worked on so others can use the documents as a example to create optimizations for other games.