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

Pages: [1] 2 3 4 5 6 ... 20
Newcomer's Board / Re: Where did Atari 2600 hacks go?
« on: November 18, 2017, 06:31:26 am »
If other sites have 2600 hacks to download, please submit them to RHND. That is how this works. They don't appear here unless you submit them.

Maybe, but if he remembers there being a bunch on RHDN which are no longer there, that's a cause for concern. Where did they go?

I tried changing the $88 (Up+A) value to just $20, but I couldn't get it to respond.
Try it for yourself though, perhaps I was doing something wrong back then and you might have better luck than I had. :)

Isn't it Up+A on controller 2? Maybe you were trying the wrong controller. Just a thought. You'd have to change the register (or wherever it's kept in RAM.

Programming / Re: How were early 8 and 16-bit games programmed?
« on: November 10, 2017, 03:09:09 am »
It's hard to imagine today, people grinding things out in hard ASM to make a game for Sega or Nintendo, but I guess it makes more sense, seeing as most probably went to top universities back in the day

It's really not as difficult as you make it sound. Look again at the ZX Spectrum: the Oliver Twins were making top selling games while they were still at school. I think Matthew Smith made Manic Miner and Jet Set Willy when he was around 16. Most programmers for the 8-bit computers were young, and did their own graphics and sound, too. Look at homebrew games. Sure, a lot of them are simple, but you don't need to be a university grad to do it.

Script Help and Language Discussion / Re: Ye Olde English.
« on: November 09, 2017, 01:56:26 pm »
Well, Wikipedia is always a good starting point:

Early Modern doesn't have too many big grammatical differences, but here are the main ones:

- it marks the point when the second person pronoun 'thou' fell out of use (in standard English: some English dialects still use it though);
- the alternate conjugation of third person tenses disappeared;
- 'ye' and 'you' becomes simply 'you'.

So second person (thou) adds '(e)st' (thou workest), third person singular (he/she/it) adds either 's' or '(e)th' (he works/worketh), third person plural (they) adds '(e)th' (they worketh). Also, the other second person pronoun (you) is 'ye' in its subject form, but 'you' in object form.

Examples from the King James Bible:
"My God, my God, why hast thou forsaken me? why art thou so far from helping me, and from the words of my roaring?" (Psalm 22:1)
"Our fathers trusted in thee: they trusted, and thou didst deliver them." (Psalm 22:4, note the past simple still adds 'st')
"For he hath not despised nor abhorred the affliction of the afflicted; neither hath he hid his face from him; but when he cried unto him, he heard." (Psalm 22:24)
"But of the fruit of the tree which is in the midst of the garden, God hath said, Ye shall not eat of it, neither shall ye touch it, lest ye die." (Genesis 3:3)
"And I will take you to me for a people, and I will be to you a God: and ye shall know that I am the Lord your God, which bringeth you out from under the burdens of the Egyptians."
(Exodus 6:7)

There's a bit of vocabulary difference, of course, but grammatically there's not much more to it than those points. Get them sorted and you'll be okay.

Script Help and Language Discussion / Re: Ye Olde English.
« on: November 09, 2017, 07:05:14 am »
First, you're looking for Middle English, not Old English;  Old English is nearly incomprehensible and is not what Frog uses.

Actually, there are five types: Old English, Middle English, Early Modern English, Modern English and Ye Olde English, the latter being a bastardisation of the language by people trying to make something sound old without knowing how it properly works. :D But anyway, when people say "ye olde" aren't they usually referring to EME, ie Shakespeare? Sorry to say I'm not familiar with Chrono Trigger, but Dragon Warrior uses a very EME style in its translation.

Personal Projects / Re: Nintendo Vs - NES Hardware Hacks
« on: November 07, 2017, 05:11:43 pm »
For Vs. Super Sky Kid, go to offset 7BBF and change the value 29 to A9.
For Vs. RBI Baseball, go to offset F1E9 and change the value 29 to A9.

Uh, didn't I already go through this in my Game Genie thread (which led to this thread)?

EDIT: I misunderstood what you were saying there: I though you were doing free play codes for some reason. Yes, the Super Sky Kid change works a treat (I didn't test RBI Baseball but I'll have a look sometime). That makes things a lot easier - some of these games have been a bitch to change because the colours are all over the place in the ROM.

By the way, sorry if anybody was looking forward to more hacks of Vs games (both of you :D ) but real life has got me distracted.

By which I mean I just got a Wii. :D Yes, I know I'm ten years too late: I'm a retro gamer.

I want a 16 bit game ported to another 16 bit console despite all of them being emulated easily on devices, portable ones no less, which have been around for over a decade and it is not like we are in a universe where technology goes backwards in capabilities or price. Why? Do you really think it is a good use of resources?

But that's what the Hack Ideas thread is all about: people with no clue about programming say "I want someone to do this incredibly niche thing for me that only I am interested in". :) I must say it's rare that someone mentions something that would actually be useful or interesting and would appeal to a wide audience.

Is it possible to do a port (of sorts) of Golden Axe to the SNES?
How troublesome would it be?

Um, you'd have to make it. Just like any other game. Doesn't really matter if it's a port or a totally original game (though you could import the graphics of course). The SNES has a totally different system to either the Genesis or the arcade original, so you'd need a few programmers to do it practically from scratch.

If systems share CPUs then it's a lot easier - not EASY but easier. Porting NES to TG16, porting MSX to Master System... but the SNES is a different beast.

Programming / Re: How were early 8 and 16-bit games programmed?
« on: November 05, 2017, 06:00:39 am »
Nice to see someone who knows what they're talking about in this thread. :)

Memory was quite tight. I don't think most people today have any clue at all about that. It was very tight.

I have to quote a well-known song here:
"Hey hey 16k, what does that get you today? You need more than that for a letter". So you tell me why nobody coded games in C, when every single byte mattered.

And what about the Atari 2600? In some games you can see black lines on the side of the screen: that's actual game code, appearing on the screen because there's not enough room for it to fit in regular memory. Now THAT'S tight.

Programming today is so easy: look at all the Steam Greenlight/Early Access games which use existing engines, existing assets, almost everything has already been done for them - and there's no point in optimising because everyone has gigabytes of RAM and hard drive space, with 3GHz processors.

Anyway, I think the OP has got a definitive answer to his initial query by now. :D

Programming / Re: How were early 8 and 16-bit games programmed?
« on: November 02, 2017, 07:37:22 pm »
Of course they were written in assembly, why wouldn't they be?

Take the ZX Spectrum as a good example: people were making new games all the time in their bedrooms, and if you browse old Speccy magazines, you'll see countless adverts for them, most of which say "fully written in machine code" as a selling point - since the only alternative was BASIC, which is very slow and primitive.

Perhaps parts were done in another language. My dad was telling me about his programming days (not games but business software) and said they usually didn't write directly in assembly, instead using C or something like that, but they still had to get into the assembly to tweak it. After all, 8-bit computers and consoles are primitive by today's standards, and you need to get every instruction working right for two reasons: speed and storage capacity.

Look at the NES: without memory management controllers (which didn't appear until around 3 years after the Famicom debuted) you get 8KB for graphics and 32KB for everything else. If you're writing the whole thing in a high level language, it may be doing instructions that are totally redundant and wasting space in your valuable storage. Not only that, but these instructions take time. If you want a fast-moving action game, you really need to fine tune the code.

Also, having worked on a good few NES games myself for hacking purposes, I can say that although you may think games look similar, under the hood it's a different story. Sure, if you take, say, Mahjong and Gomoku Narabe Renju, which immediately look very similar because they were clearly made at the same time by the same team, you can see similarities. But SMB3 and Mega Man 2? I doubt that they look similar in the code. There's a reason people talk about 'game engines': you spend time crafting an engine and then you can make several games with it, rather than reinventing the wheel every time, like you said (hey, they made six Mega Man games on the NES: that's a great example of having a good engine and just rehashing it to death).

But having delved into 6502 assembly, I don't see it as impossible to code a game that way: it's a really simple language. I could never get started on high level languages, while 6502 assembly now seems very accessible to me. It doesn't take 100 hours to compress graphics: that's what computers are for! :D

As FAST6191 says, assembly is a bit easier to work with than pure bytes because you can use definitions of things that you need, usually addresses. So instead of making a branch instruction and having to literally count the bytes until the next instruction (which will change if you change your code) you just write to branch to the PlayerShootingHisWeapon routine or whatever and the compiler takes care of it. In fact, take a browse through the reverse-engineered SMB disassembly to see what I mean.

Newcomer's Board / Re: Help with Tile Layer Pro
« on: October 30, 2017, 03:57:47 am »
Step 1: don't bother with Tile Layer Pro, use Tile Molester or something else.

Step 2: of course you'll see random coloured pixels if you're looking at game code rather than graphics. The game has everything in there, so to find the graphics you need to go looking for them. If they're uncompressed then you'll just need to make sure you're in the right format (looks like it's 4 bits per pixel for this).

It's helpful to get acquainted with 6502 assembly when doing hacking like this for the NES. I'd use FCEUX: Bizhawk is fine but not as specialised and easy to use.

Look at the name table for a tile, find that location in PPU memory then right-click to do a write breakpoint to see when that location is written to. When the title screen is written, the debugger will pop up to show the instruction writing to that address, usually STA (store contents of the Accumulator). If you're lucky, it'll say directly above it where that came from in the ROM (if it's an address above $8000) and you can find it in the RAM then right-click "go here in ROM".

If it comes from somewhere under $8000, it's probably gone from ROM to RAM to the PPU, which means you need to investigate further.

ROM Hacking Discussion / Re: Nintendo Vs - Game Genie Free Play Codes
« on: October 27, 2017, 02:15:18 pm »
The cheat code OXZEXN (Doesn't decrease credits) for Vs. Mighty Bomb Jack prevents you from finishing the first bonus round. The score counter is counting forever. With only the cheat VTLEOZ (Adds 1 credit at title screen) active, the game is working on my Analogue Nt mini.

I didn't do much play testing on these codes so I didn't know that the bonus rounds were affected. I've stopped updating this thread because I've started doing proper ROM hacks of the games especially to hack the palettes, and if I can figure out how to change the coin mechanism then I'll do that:

Not sure about any of the other ones you've marked as non-working.  There's probably a good chance that they didn't work since they're not on my list.  It was made 10 or so years ago, so my memory is a bit foggy on that. :)

I wrote non working because the ROMs don't work in FCEUX, so i can't hack them. I tried Balloon Fight in MAME and it works, but the NES file in GoodNES seems broken. Again, check my project thread for updates.

Newcomer's Board / Re: Japanese ROM scripting help
« on: October 27, 2017, 03:10:38 am »
What I have to figure out now is how to keep the translated text inside of the text boxes correctly. I edited some text to English but it broke through the text boxes, even with line break controls. Are there any documents dealing with things like this, figuring out where text box tiles are in the code and keeping text within its confines?

Remember that there is NO set way of programming anything, every game is different. Changing text is generally easy without any knowledge of assembly, but if you want to change text boxes, you're going to need it. You can check out my translation of Aighina's Prophecy where I expanded the text window: it was quite a bit of work, and I needed to learn 6502 assembly to do it. You need to see what the game is doing and change it. So let's say there's an instruction that says "draw the background tile for the text window eight times" and you'd change it to ten times, and so on. But it takes more than changing one byte, and you need to play test it to make sure you don't break anything else.

You also need to see how the game handles text. Some, like Dragon Warrior on the NES, are beautiful: they take the text from the ROM and recompose it with line breaks, and can run on as far as you want. That's because the guys localising it programmed that routine in, but sadly Japanese games don't normally bother with that. With Oide Rascal for example, I provided all the kana, but there are control codes that tell the CPU what to do, so you need to experiment with that.

ROM Hacking Discussion / Re: Biohazard NES?
« on: October 25, 2017, 07:16:31 pm »
It's not a hack, it's an original game, albeit based on a PS1 game.

I've recently been cataloguing Waixing's games, and this is as well-programmed as any of them. :D In fact, it's very easy to get the game to crash as soon as Jill starts running to the next room. You can get beyond that, if you're lucky. If I ever get round to translating one of Waixing's games, I'd probably start with this because it's such an oddity.

Newcomer's Board / Re: Japanese ROM scripting help
« on: October 25, 2017, 07:09:34 pm »
I feel like such an idiot... :D

I spent hours banging my head against the wall trying to understand where Oide Rascal was getting its text from, when I forgot the golden rule about relative searching: try it with spaces between letters.

Get Relativeful Search:

I looked at the graphics in Tile Molester and saw how the kana were laid out, and used that to find the first three letters of the intro ("do u bu"). I searched for "do" as the 41st letter, clicked 'skip value', then "u" as the 6th, skip letter, same for "bu". Search... several matches found. I change the second one... success. :)

Basically, the text uses two bytes per character: one selects the graphics bank to load from, the other selects the byte in that bank. So $82C7 is "do", then $82A4 for "u" and so on. Katakana is on $83, punctuation is on $81, which you can see when you load it in Tile Molester. I actually made the table file for you (it's in Romaji because I'm tired and can't be bothered pasting in my Shift JIS characters :D ):

Code: [Select]

Just copy-paste that into a .tbl file and load it into WindHex32 EX (my editor of choice for such things), and you'll find the intro text at $AA054.

I could be wrong (it wouldn't be the first time!), but that sounds like a sign that an emulator is using a checksum to recognize that ROM in order to overcome a bad header (or maybe a bad dump). Changing anything in the ROM means the emulator doesn't recognize it anymore, doesn't compensate for the error in the header, and is probably using the wrong mapper as a result.

That's one possibility, or the other is that he's made an error in his edits somehow. The NES is generally quite easy to find text and replace, but I haven't looked at that game.

Anyway, I hope I've been of help to you! :)

Newcomer's Board / Re: Japanese ROM scripting help
« on: October 25, 2017, 04:09:48 pm »
GB games might print a text window directly in VRAM (as opposed to loading the entire font) due to that the original GB has less VRAM than the NES. The GB (which also affects backwards-compatible GBC games) has 8KB while the NES PPU has 10KB (typically, it can be 12KB with "four-screen mirroring" which requires extra RAM on the cart): an 8KB CHR-ROM/CHR-RAM bank on the cart as well as the 2KB internal VRAM for the nametable.

It sure looks like it:

32KB for the program ROM, same as the NES; 6KB for the pattern table, compared to the NES's 8KB, so the sprites get only 2KB (maybe they figured it'll be okay given the lower screen resolution?); 2KB for the name tables (looks like there are two, and they cover a much wider area than the viewable window, presumably making four-way scrolling a breeze - at least that's an advantage over the NES); and 24KB for the rest.

So the GB has twice as much internal RAM as the NES, but a little less VRAM. I thought it would have memory limitations given that both graphics and program need to be accessed over the Z80's 16-bit bus, but since so much of the NES's range is wasted on mirroring, it doesn't seem like a problem. In fact, the fact that VRAM can be accessed directly rather than through a register is probably a bonus, allowing for more flexibility.

Nevertheless, I still can't find the text for this game. :D

Newcomer's Board / Re: Japanese ROM scripting help
« on: October 25, 2017, 05:39:23 am »
Filler gave you a good outline of the process, so let's look at how it applies to you.

Looking at a gameplay video on YouTube it looks like it uses just kana, which makes things easier. Basically, 8- and 16-bit consoles use one byte per character to save space, which limits you to 256 different characters. Obviously that's not enough for proper Japanese script that needs lots of kanji, and that would require two bytes (giving a total of 65,536, more than enough for every character imaginable). 32-bit and onwards systems generally use more accepted standards like Unicode or Shift JIS.

Anyway, the GBC is an 8-bit  machine, but a very late one, so it can use huge cartridges compared to when the GB first came out. I translated the first Detective Conan, and it was clear that despite the amount of text, compression was unnecessary due to the huge ROM size. This game probably does the same.

However, I did a relative search using the kana order I found in the ROM, as well as using the typical kana order, and I found nothing. It's surprising, but you may need to use a different route to finding the text. On a NES it's easy because of how the system works, but GB is a bit trickier and I don't have experience with it.

It seems that unlike the NES, graphics are loaded into memory individually, then put into place in a different part of memory. The question is how they get into memory in the first place. I'm still figuring this out myself, hopefully I'll find something...

Programming / Re: Where did you learn assembly from?
« on: October 24, 2017, 04:02:13 am »
Assembly by itself is such incredibly basic math that I don't think it's hard to grasp.

Exactly the revelation I discovered myself. I'd been conditioned to assume that BASIC was easy, C was medium and machine code/assembly was hard. Not at all. :)

Personal Projects / Re: Nintendo Vs - NES Hardware Hacks
« on: October 24, 2017, 02:44:59 am »
There are two Vs. Golf Men versions. The Japan version (included in GoodNES) uses the RC2C03B PPU/palette and the other one (non-Japanese, included in the MAME romset) uses the same PPU/palette as the Ladie's version (RP2C04-0002).

Well that would certainly explain it. I noticed this one was Japanese. The Ladies one appears to be English though.

Did you also see my post the other thread of yours? For some games it might be possible to fix the palette via a few Game Genie codes that alter the DIP switch settings.

Yes I saw, but I'm pretty certain the ones I've done so far can't be done that way. The only one i know of is Super Xevious.

EDIT: Golf's ready! :)

I've tested both the men's and women's versions and everything seems to be working, although the men's was easier since I don't need to mess with the palette as already mentioned. You start the game with Start but a weird thing seems to happen on the men's version: in a two player game, both players press player 2's Start button to continue, whereas the women's one has you press whichever button is logical. Don't know why. Also the Japanese on the men's version is just sprites that are removed on the women's version, so I ignored them.

Remember, nothing I've posted in this thread is final, I can change anything. I might change all the black colours from $2F to $0F since the latter is considered the "canonical black" for NES games, while on the Vs System it was used for a different colour so they switched to $2F for black (or whatever is the equivalent on that PPU). I may figure out how to change the coin mechanism to the Select button, but frankly I think free play is easier to use on a NES, even though you stupidly lose the title screen when you do (bad design).

Keep your feedback coming, guys, especially checking them on the real hardware - and with two players! I take care in making sure the inputs are correct! :)

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