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

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 - Nightcrawler

Pages: 1 2 3 4 [5] 6 7 8 9 10 ... 51
Newcomer's Board / Re: Branching in Disassembled Code
« on: September 02, 2015, 06:16:06 pm »
Please, please, just use a disassembler and save yourself a ton of pain...

Right. Or better yet, use a debugger and step through the specific code in question so you can start to learn exactly what each instruction is doing.

ROM Hacking Discussion / Re: Lufia-Patches by Artemis
« on: September 01, 2015, 06:14:36 pm »
According to the readme
One recommendation by RHDN to check CRCs on Windows is to install HashTab. Then you can right-click on the file and click Properties and get the hashes on the menu.

I think the preferred and definitive source for this site should be ROM Hasher. The output can be copied and pasted right to RHDN submission forms meeting all guidelines. :)

Programming / Re: Getting Started on a VWF?
« on: August 09, 2015, 11:20:07 am »
There are a number of ways a VWF renderer can be 'glued' into the game. The best approach will vary depending on how you did your rendering, and what the game engine was already doing.

In general though, if you're doing dialog, and you're doing letter by letter display, then I'd probably suggest one of the following:

1.) Map a large region of RAM for rendering that can contain an entire dialog line or even full text window. Then, the tilemap doesn't change much. It's mapped once to the full line or window. It will reflect the letter by letter rendering in VRAM automatically that way. You don't have to do anything to tilemap during rendering.

2.) If you don't have the RAM to do that, you can write the tilemap each character iteration, advancing the index only when the tilespace is full. If you're doing 8x8 for example, you'd write the current tile, and second potential spillover tile to the tilemap each time. It would write the same two indexes until your tile was full, then it would increment to the next index and write the two tiles there.

You can do any variation of the above as well. You can write to the tilemap only when the tile is full, only after x number of tiles are done etc. There are lots of ways to handle it. I usually pick what I think is the easiest way to massage into the game with the least amount of code.

Newcomer's Board / Re: Spc Jukebox/player on real hardware/flashcart
« on: August 06, 2015, 05:41:03 pm »
This do not answer my question, I understand resetting the console is the only way to get out of SPC playing, but HOW is it done (in hardware). The 65816 can soft reset itself, but it also resets the SPC.

It can do this because the reset line is one of the cart pins. ;)

the flash cart resets it when you back out of playing the spc. Heck the newest firmware on the flashcart has in game reset using button combinations on the controller.

That's a bit trickier and less reliable. It does this via a global NMI hook, which can introduce glitches and problems in games where NMI timing is already tight. There is the ability to turn it off temporarily, but I would like to see as a full system option.

Newcomer's Board / Re: Spc Jukebox/player on real hardware/flashcart
« on: August 05, 2015, 08:18:21 pm »
This is hardly believable. The only way this can be technically achieved is by cloning the SPC chip in the cartridge and use the expansion sound pin. Perhaps that's what they did.

No, it is certainly believable. I have an SD2SNES. I can tell you approximately how it works. SPC files are basically savestates and contain the entire music engine for a given song, right? So, what they do is simply load in the state of the DSP, and the full SPC memory contents, and start execution. Presto! You're now playing back your given SPC file. Now, this method is of course only valid to play a single song. So, any time you stop playing, there is a quick screen flicker. I assume the system is being reset during this time. Since the SNES retains all of it's memory during reset, it recovers near instantly ready to load the next song in the list.

I imagine the PowerPak must do something similar.

Programming / Re: Getting Started on a VWF?
« on: August 02, 2015, 12:05:59 pm »
Congrats! Perseverance pays off in ROM hacking. Add another skill to your bag. :)

Programming / Re: 65xx Assembler Alpha release: Schasm
« on: July 22, 2015, 06:41:09 pm »
I use Notepad++ which allows you to set up syntax highlighting -- but it doesn't have auto complete.

Yes it does. Settings -> Preferences -> Auto-Completion

Also related to Notepad++ and SNES IDEs, I have used this setup a few times before. It's not your ideal SNES IDE, but pretty cool nonetheless.

Programming / Re: 65xx Assembler Alpha release: Schasm
« on: July 20, 2015, 08:09:11 pm »
I have reviewed the documentation in detail and... I like it! It seems like a very capable assembler with some reasonable and consistent syntax. You get bonus points for good documentation too! It seems you have most things covered.

1. Does #IncBin and #IncSrc handle relative paths?
2. When declaring variables like 'SomeVar = $001800', are you required to always use long addresses?
3. Is there a way to output the pc or embed it into debug message like #Warn/#Error? I have to do this often to get the breakpoint I need to use to debug various specific areas and lines of code. I didn't see a way to do this.
4. Can expressions be used in variable declarations? Something like 'Foo = (5+2) - 1 * 7 ;my secret constant for sprite animation.'? What about a variable within a variable declaration? I'm getting at equivalent functionality for defines in xkas/bass. You can do some interesting things with them being able to define almost anything. Not all of that power is needed, but it is a frame of reference when evaluating abilities of schasm.

I know you probably choose #Byte,#Word,#Long,#Dword for consistency with all directives and ease of parsing, but what do think about also supporting traditional db (define byte), dw (define word), etc. type syntax many assemblers do?

1. #Var is a nice addition. It is annoying to add variables in the middle of your list, change your mind about a variable length throwing addresses of everything else off, and what not.

2. Interesting approach to #Org with the independence between platform address and file offset. That's great for more difficult mappings as long as it is not a burden for simple mappings. I see it is optional, but I'm not sure I understand how optional with the explanation given. If you have a no header, traditional hirom mapped ROM, and all your code is in the linearly mapped region for example, you wouldn't really have much need to declare file offsets more than once at the beginning. All other instances of #Org in the project probably wouldn't need it (nor would I want to have to declare it all the time). Is that allowed here? When can you omit the file offset on #Org exactly?

3. It's dangerous to make assumptions that some things will never be used. Either I saw, or I read about (damn old age, I can't remember!) a game that used brk to call a decompression subroutine, for example! Few would expect that usage, but yet it was done. Perhaps that was not the smartest thing to do, but I'm sure there are other cases where something was used unconventionally and it was actually very clever. I guess my point never assume something would never be used and use as an excuse not to put it in! You'll need another excuse! :laugh:

Small mistakes observed:
1. In both readme.txt and directives.txt your passage says 'changes how the compiler assembles its code.' Technically it's an assembler rather than a compiler.
2. typo in readme.txt -  'jmp Label       ; legal, Label is vidible here'

Programming / Re: 65xx Assembler Alpha release: Schasm
« on: July 19, 2015, 01:00:22 pm »
It's explicitly given by the user.

I don't need much for DP awareness.  Just a way to specifiy what direct page is and have the assembler take advantage of it.  Many assemblers don't even do that much -- if you want to use DP you have to actually specify the size of each individual instruction.  Like in xkas, you have to use the '.b' mnemonic suffix (lda.b) or it will always use absolute mode.  I didn't see anything in Asar's notes which changed that -- though maybe I missed it.

Oh, right. I forgot xkas didn't actually support direct page in the assume command. Then, I think asar removed it entirely in favor of auto 24-bit to 16-bit optimizations, but apparently leaving direct page optimization out in the cold. So, supporting it at all would indeed be an improvement! ;D

Yes.  You specify a range of banks for data to be mirrored across.

I was going to respond by mentioning that the WRAM mirroring is a fixed scheme on the SNES, but I see in your documentation that you you already map it by default and allow additional mirroring via that directive. Nice! :)

It looks like you're off to a great start so far. I will read through what you have a little more closely when I have some more time and see if I have any other useful comments to muster. I know it's early in the game, but it would be great to support SPC700, and a few other SNES co-processers in the future. asar does SPC700 and includes SuperFX for example.

Programming / Re: 65xx Assembler Alpha release: Schasm
« on: July 18, 2015, 09:35:45 am »
Asar is interesting, but it still doesn't have the mirroring acknowledgement or the awareness to shrink to directpage when appropriate which are two things I REALLY wanted.  It does have some other interesting ideas that I might steal, though  ;D

How do you intend to do any better than the aforementioned assemblers on direct page awareness? You will always have the inherent problems that you don't know the starting values (unless explicitly given by the user), it can be changed in code outside the assembler between functions, and you can't handle it being changed by stack pulls, or if the value is a result of a calculation, table grab, etc.

For mirroring, have you accounted for the fact that WRAM is not mirrored in all banks?

Programming / Re: 65xx Assembler Alpha release: Schasm
« on: July 16, 2015, 05:58:36 pm »
I suggest you also take a look at Asar. It's a fixed and extended version of the old xkas lineage. It's not well known in these circles, so I thought I'd throw it out there.

Programming / Re: Getting Started on a VWF?
« on: July 11, 2015, 01:19:21 pm »
Speaking of Tales of Phantasia. Didn't already do this there? You had an 8x8 VWF there for the menus, right? To do that you had to draw tiles dynamically to RAM. It's the exact same concept here.

Yes, it looks like your problem is coming from the FMVs. No patching format is going to be able to do anything about that. Since you hard coded it, you've changed nearly every frame of the video. The resulting full video will be vastly different resulting in a huge chunk of marked different data (especially if compression is involved). The reason your custom patcher is 2 megabytes is because you already know the new data ahead of time and are storing a video editing procedure to apply it. The patcher needs to reverse engineer that with only strict binary difference rules. It will never come up with the same results.

In any event, if you absolutely need hard coded subs, it probably would be more appropriate to include a utility to apply the subs to the videos.

I would say it is about the same as the background analogy. It would be convenient to be able to disable channels in the emulator, however you can live without it. When I have had a need to disable a specific audio channel, I have usually done so temporarily in software and rebuilt.

If I were in your shoes and trying to streamline and simplify the code as such, I'd probably omit it. I don't think the added complexities are worthwhile for the feature even though I do think the feature itself would be a nice convenience.

So as to purify the situation once and for all [future entries], what do you think of the following format:

This utility was designed for the site and it's output format is the desired standard output. Please either use this utility or follow the rules it employs.

See all the backing discussion on the discussed rules for certain platforms below. The term hash as applied to ROMs of various platforms can be ambiguous.,16846.msg246949.html#msg246949

Most advanced hacking is done with hardware documentation, a debugger to reverse engineer with, and a cross assembler to assemble new code into the ROM.

If you know of translations that aren't here and should be, by all means add them for benefit of all! :)

If for some reason the license or readme file of the project may not allow for distribution here, you can still add the entry page. You would simply use the 'No File' checkbox and note distribution is not allowed per readme/license in the description in that case.

Programming / Re: Sailor Moon SuperS - Fuwa Fuwa Panic APU Question
« on: May 01, 2015, 09:08:04 pm »
It's not weird, I don't think. The way the APU works is you have your sample that was recorded at some sampling rate, and then the VxPITCHL/VxPITCHH registers scale the original pitch up or down for playback. So, in order to come up effective scaling value for those registers, you have to know the original sample rate. The same value in those registers will play different samples at different rates since it scales proportionately to what the original was recorded at. That's also why when you rip samples, you don't know what the original sampling rate was without some trial and error guesswork.

Anomie's SPC700 Doc
Anomie's S-DSP Doc
SNES Programming Wiki
SNES Development Wiki

Personal Projects / Re: Fischmare - General Purpose Rom Editor
« on: April 16, 2015, 06:31:09 pm »
That seems like quite a bit of programming to accomplish viewing or editing some tiles. I think that might put it out of reach for most for anything you don't supply out of the box. I think it is simpler to use the aforementioned tools in this thread that do the same. I think the concept of blindly extracting portions of data from a ROM and then defining attributes on how to parse and view that data is interesting and good. However it seems a little overcomplicated for what it is. I'd be curious what other people's opinions are.

Personal Projects / Re: Fischmare - General Purpose Rom Editor
« on: April 15, 2015, 07:42:42 pm »
Congrats! :beer: I know all too well how much effort goes into making some of these constructs that result in very little to the untrained eye on the surface! It's hard to really appreciate the 'under the hood changes' from the end user position.

What did you end up doing for the tile definitions?

Pages: 1 2 3 4 [5] 6 7 8 9 10 ... 51