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

Pages: [1] 2 3 4 5 6 ... 35
1
ROM Hacking Discussion / Re: Handling possible text compression
« on: September 21, 2018, 03:56:14 am »
Wow, Alchemic, that confirms what I saw: that it's pretty messed up. :D I got as far as noticing that each individual word is assembled letter-by-letter in SRAM before being passed off to the PPU, but it would've taken me time to get to the level of detail you've acquired. That has to be the most convoluted text handling scheme I've ever seen in a game.

I had a look so I can see what you're talking about there. It's still messing with my brain, so I think I'll leave it for now. :)

2
ROM Hacking Discussion / Re: Handling possible text compression
« on: September 20, 2018, 06:00:12 pm »
Well, you were right: DW2 uses a rather tricky compression method which I don't fully understand yet. I'm still looking at it, and it's not like what I've seen before. I'd say it's a bit like dictionary compression, except not... I'll continue until I've figured it out, but it's weird.

3
ROM Hacking Discussion / Re: Handling possible text compression
« on: September 20, 2018, 10:43:22 am »
I went into FCEUX Nametable Viewer and checked the hex code of the letters showing up in dialogue text. The hex code for the letters in dialogue was exactly the same as the code for the letters in monster, item and spell names--with all of the latter showing up in a hex editor when I load up table data. Would this indicate compression or could another factor be causing this?

I don't think simply looking at the nametable would indicate compression per se. The way I would do it is the more advanced method of debugging the game to see how the text gets from the ROM to the screen, and compression will become apparent then. A simpler way is the old fashioned relative search technique locating where the text is, and discovering the compression then.

I'll have a look later, anyway. I've already hacked this game to double experience and gold, so that's why I'm familiar with it.

4
Programming / Re: Converting SNES and NES addresses to PC address
« on: September 20, 2018, 02:11:18 am »
I know I should probably say nothing because I feel I'm not contributing to the thread, but...

Is there a great need for a tool to convert addresses? I use OpenOffice Calc to put all my addresses in a column, then use a simple formula to convert them all. Combined with a little program my dad made to list every address where a particular byte is found, plus Textpad, and everything is pretty straightforward. Sure, I haven't done much work on the SNES so perhaps there's some tricky stuff with the HiROM LoROM business, but I don't recall anything too taxing.

Also, the terminology confuses me: "PC addresses"? In this context I think of Program Counter, how does an address connect with a Wintel computer? I would think ROM address or file address is more appropriate.

Again, apologies if it looks like I'm just being negative in the thread. I just had some questions on my mind. :)

5
ROM Hacking Discussion / Re: Handling possible text compression
« on: September 20, 2018, 02:00:55 am »
I second the idea of a dedicated thread for all this: no need to make lots of new threads. :)

As for the text compression question, if I can find the time I can have a look myself. I know for a fact that Dragon Warrior doesn't have compression but I can't remember about DW2. I'd be a bit surprised if it did because neither it nor the first game have an overwhelming amount of text.

Maybe later today I'll be able to spend five minutes checking the text to see how it's stored in the ROM. Compression does happen in text heavy games - my efforts translating Time Stranger from 1986 found a neat dictionary compression scheme - but again, I'd be a little surprised were that the case here.

6
ROM Hacking Discussion / Re: Need help obtaining NES RAM addresses
« on: September 17, 2018, 03:59:59 pm »
I just reread your original post and KingMike's reply: the original pointer you found was the correct one. "70 BC" refers to $BC70 because as KM said, the 6502 in the NES is little endian and reads the smaller byte first. So just change the pointer at $684E to whatever you've changed it to, bearing in mind what we've already told you.

I wouldn't bother with a pointer calculator since it's really not difficult to figure out anyway. Once you get the hang of using the debugger in FCEUX and understanding the assembly, the addresses will be obvious. :)

If you're still trying to figure things out, might I suggest watching my YouTube tutorial? (cheap plug I know... :) )
https://youtu.be/vuL0CZrxSYo

7
ROM Hacking Discussion / Re: Need help obtaining NES RAM addresses
« on: September 17, 2018, 08:02:29 am »
Thankfully FCEUX lets you find a CPU address and say "go here in the ROM", so it's clear which address it is. But yes, you just have to understand how the NES works.

The CPU address space is how the CPU accesses data. On the NES, it can access 64KB, and the upper half of that is dedicated to the ROM ($8000 onwards). 32KB isn't much to play with so mappers exist that reroute the CPU to different parts of the ROM. Think of it like a TV: you can only have one channel on TV at one time, so you change channels. Some mappers do just that, but some can increase the granularity - like having multiple channels on-screen at once.

So the ROM address rarely coincides with the CPU address, but at least you know the last three digits will be the same (after removing the $10 for the header).

8
Programming / Re: How to learn Assembly?
« on: September 14, 2018, 04:51:12 am »
Assembly is easy.  It's programming fundamentals that are hard.

But if you're hacking ROMs, you don't normally need to learn everything about programming, just how assembly works and how to fiddle with existing code to make it do what you want.

Just start with something simple and work your way from there. Like use a cheat finder to find the RAM address for where Sonic's lives are stored, then set a breakpoint to see which instruction takes a life away when you die, and learn how the instructions work. I really don't think you need to read a whole book on assembly before getting stuck in.

9
ROM Hacking Discussion / Re: Double Byte Text inserting / 16bit S-JIS
« on: September 09, 2018, 04:17:04 pm »
I ask other people nicely to do it for me. :)

8)

Anyway, I really don't see why 8-bit and 16-bit text should be any different. Can't you just make a table file with two bytes per character? As FAST suggested, you might be able to convert 8 to 16 if you can write a little routine. A very helpful guy showed me a simple routine to do it on the PC-98.

As for inserting text, my preferred method is a combination of Pointer Tables (the program, dull name I know), making my own IPS files, a regular hex editor, and maybe a bit of WindHex 32 EX. It's an odd combo but works for me.

10
ROM Hacking Discussion / Re: Question about graphical pointers
« on: September 09, 2018, 04:03:37 pm »
There's a reason we call it "reverse engineering": you start with what you can see and work backwards.

So once you've learnt how to use the fceux debugger and 6502 assembly (hah ;) ) you then read the nesdev wiki to realise how the NES specifically works. Then when you see the sprite that you want to change, you look in the RAM and see where it's stored, and use the debugger to see where that data came from in the first place.

It's not difficult per se, once you get the hang of it. It can take time, but if you're the kind of person who wants to hack, then it's all part of the fun. :)

11
Okay, I'll throw my hat in.

MAME has a built in debugger, and a nice one at that, so hacking games is no big deal. Sure, there are CRC checks but they can be ignored.

If you know what you're doing, you could probably change the questions to whatever you want, rather than being no longer than the existing ones as mentioned.

The problem I see is that you're the one person who really wants to see this happen, but if you spend hours putting new questions into the game, you'll play it and... you'll know all the answers, because you put them there. That kind of ruins the fun.

So, could you change the questions? Sure, but you'll know all the answers, so it's not really worth it. :)

12
ROM Hacking Discussion / Re: SMB1: Changing the text colour
« on: September 07, 2018, 04:06:43 am »
Tell me!

Calm down.

It's perfectly possible: at some point in the game code, there's an instruction telling the PPU which palette to use for each part of the screen, you just need to find that code and change it.

Two possible drawbacks: the palette you want isn't already there and changing a palette may have effects elsewhere; and the code may simply be "make this whole block the same palette", rather than "here's a list of palette choices for every single tile". Without having a look myself, I can't say which it is.

13
Personal Projects / Re: F-Zero Final v0.2 Coming Soon!
« on: September 07, 2018, 03:58:03 am »
As I am not allowed to post video links here

Who told you that? :huh: There's nothing in the rules disallowing YouTube links - hell, there's even a thread dedicated to that exact thing.

Anyway, good job on the hack. I might even feature it on my channel when it's finished. :)

14
This crap just appeared:

http://www.nintendolife.com/news/2018/08/illegal_game_sharing_site_mocks_nintendos_recent_legal_actions_with_trolling_video

they fell for a publicity stunt in the same article (bravo ROM site I have never heard of before by the way).

I agree, I'd never heard of that site before, but thanks Nintendo Life for letting me know about a place where I can download new games for nothing, good job. Admittedly they're PC games rather than Nintendo ones, but still.

I wasn't going to contribute to the thread again until I saw that, but since I'm here I'll throw in my two cents (more than what my opinion on the matter is worth, anyhow). I prefer to look at facts rather than emotions or opinions, and the fact is that Nintendo still makes money off of their old games via the Virtual Console, and they're apparently planning on launching a new subscription service where you can play any old games you want for a monthly fee - the Netflix of gaming, if you will. So if a site is offering for people to play their games through the browser, for free, and making money from banner ads to boot, it would be bad business sense for Nintendo to NOT take them down.

It's worth pointing out that the other ROM download sites that I won't mention were not approached by Nintendo, but got spooked by the actions being taken against certain ones. They probably could have gone on regardless. Still, anyone worried about game preservation should rest easy: you know there's a community out there in the shadows that are archiving all of this for the future of mankind. Chill out. 8)

15
Gaming Discussion / Re: Nintendo FDS Question
« on: August 06, 2018, 06:19:56 pm »
I read somewhere that the FDS is a NIGHTMARE to hack and translate games for.

Not at all, it's just like the NES. Only difference is the storage medium, which can actually be better than ROM if you know what you're doing. You can usually add extra data to a file on an FDS disk, whereas in a ROM you're stuck with whatever empty space you can find in there. You may have noticed that I translated a few of the easier ones. :)

I guess there just aren't enough interesting games to catch people's attention. If I had more time on my hands, I'd certainly have another go.

16
Gaming Discussion / Re: Psyklaxia: my new YouTube channel!
« on: August 05, 2018, 10:48:45 am »
For the few of you who are interested, here's an update on my channel:
https://youtu.be/gi8ge9IY7JY

17
My idea: Mortal Kombat Trilogy for SNES, with Khameleon, Chameleon, Cyber Smoke, Human Smoke, MK1/2/3 ninja costumes as options depending on the button you press when selecting the character.  Includes Ermac, Rain, Noob Saibot, Jade, Tanya, Tremor, Skarlet, Frost, Triborg, and Ruby, along with the regular characters.  Costumes are selectable via the button you press on the character.

I'd stick with Ultimate Mortal Kombat Trilogy. Sure, it's not the SNES, but it's hard to beat. Here's my review:
https://youtu.be/DfoH9AJ0oLI

18
ROM Hacking Discussion / Re: Sega Game Gear ROM Hack
« on: August 03, 2018, 09:01:44 am »
Okay, let's take this idea seriously for a minute.

First off, if you want to play TMNT on Game Boy, play it on Game Boy. Nobody but you would really care if it's on Game Gear at this point. So if you really want to devote yourself to this project, be my guest. :)

Now, assuming you DO want to do it. Let's compare the two systems.

The Game Gear is almost identical to the Master System, aside from a lower resolution and substantially more colours. It uses a Z80 CPU and has 8KB RAM. The Game Boy has a custom CPU that is very similar to the Z80, and also has 8KB RAM.

Therefore, a lot of the main code can be ported over directly without much change, since the languages the CPUs use are almost the same. There will be no problem with RAM usage, and both systems have an identical resolution of 160x144, so the graphics will port over perfectly. Of course the sound hardware is rather different, but you could adapt the tunes somehow (it's the least of your worries).

So, is it impossible? Not at all: in fact, it's remarkable how similar the two systems actually are. But it would still take a lot of work - the underlying code may be copied over, but the code regarding graphics and sound would need extensive rewriting. For someone with experience in Z80 assembly, this would be a fun challenge, but if you're more interested in the result than the process, you'd be better off not bothering. In fact, that sentence could apply to all ROM hacking. :)

Now, the second idea.

they would have to be completely redrawn and colored in.

Coloured in, yes, redrawn, no. As I said, the resolution on both systems is the same, so unless the sprites are the wrong size, you won't need to redraw them. But yeah, importing the graphics would be orders of magnitude easier than porting the game.

19
Help Wanted Ads / Re: Need a mapper hack
« on: August 02, 2018, 02:12:24 pm »
There's over 10,000 differences between the Japanese ROM and that mapper hack.

Not true. The differences are:

- a different header to reflect the new mapper
- a $200 byte section that goes into PRG-RAM which provides the back switching routines for the new mapper
- every instruction which switches the bank is replaced by a JSR to the aforementioned PRG-RAM bank switching routines

That's it. The reason you saw 10,000 changes in a simple file compare is likely because of the inserted PRG-RAM section at the beginning which offset the rest of it, but as far as the NES is concerned, it doesn't care.

So, actually, using the mapper hack would be trivial, and would definitely work on the Everdrive. Only problem is how to arrange the script to benefit from the bank switching.

20
Help Wanted Ads / Re: Need a mapper hack
« on: August 02, 2018, 05:55:34 am »
Your use of passive voice suggests it wasn't you that messed this up. :D

Here's the specs for the VRC1 used in this game:
https://wiki.nesdev.com/w/index.php/INES_Mapper_075
and the much more common MMC1 used in the prototype:
https://wiki.nesdev.com/w/index.php/INES_Mapper_001

One thing to notice is that the VRC1 has a maximum PRG size of 128KB, so maybe that's what went wrong. The MMC1 can go up to half a meg. The CHR works the same in both. A key difference is the granularity of the banks: although VRC1 can only do 128KB in total, the banks are 8KB rather than 16KB, so the game may use them differently than an MMC1 game. Then again, as you said the prototype used MMC1, perhaps it didn't take advantage of the granularity and therefore a switch would be easy.

The big problem is how the two mappers switch banks. The VRC1 works like most other mappers: just write the number of the bank you want to the address you want to put it, and bam, done. The MMC1 works quite differently, as the NESdev page shows. However, having that prototype will be very useful, as someone can compare the original with the prototype and see how the internal processes differ. I could have a look to see how it works, but I can't promise anything. :)

Anyone else with experience of the MMC1 might want to chime in here. On second thoughts, using the UNROM mapper instead might be a better choice, since it seems to work quite similarly to the VRC1, but has double the PRG capacity:
https://wiki.nesdev.com/w/index.php/INES_Mapper_002
If the bank switching works the same, it could be a very simple swap. But the problem in any mapper hack is how to tell the game to switch banks: like, how does the game know that THIS bit of dialogue is in a particular bank? That can be a challenge.

EDIT: the GoodNES set includes a mapper hack: Jajamaru Ninpou Chou (J) [hM04].nes. It changes the mapper to MMC3. Perhaps adapting the translation to that would be easiest?

EDIT2: Crikey, Taro's Quest is remarkably different to the original. Maybe it won't be so helpful to compare...

Pages: [1] 2 3 4 5 6 ... 35