Author Topic: ReWriting the FF7 Engine  (Read 21313 times)

Cyberman

  • *
  • Posts: 1572
    • View Profile
ReWriting the FF7 Engine
« Reply #50 on: 2004-07-07 01:14:23 »
Quote from: halkun
Quote from: Cyberman

You wouldn't have a 'clean' listing of function calls commonly used in PS1 games would you?
I have a list of the bios function calls, I guess that would be a reasonable start.  Anyone 2 weeks before I can get the debugging system working then I can start mangling FF7 data again.


I've never played with Psy-Q... ever. I have no idea what kind of calls that lib makes to the metal. When I was making my doc, sony was very very very very direct in telling me that no libs were go into my psx doc.

I don't even have the bios calls... (I used to)

Hmmm.. I suppose if I will then need to use a derivation system to create C level function call listings.  IE when you find a call to a subroutine find out where it goes/does then give it a name and guessed parametric reference.  Should work.  I plan on storing this data in an XML database so I can compare it with other information.  I think I have the Yaroze function list.. and I think I have the PS1 bios list as well. Hmmm.

I should get to work on that soon.

Cyb

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
ReWriting the FF7 Engine
« Reply #51 on: 2004-07-07 05:44:15 »
You are assuming that there are standard calls that are commonly used, there isn't

Though it is true that many game companies use Psy-Q libs to make games ...LoadTIM(), playSEQ()... These are very often tweaked and stripped for the individual application. The PSX does not use shared libaries like DLLs, a PSX executable is a static COFF-type. I don't think you are going to find entry points very easily as they can be anywere, and custom within the executable.

The FF7 kernel is amazing because it manages threading and several sub programs, each with a scripting language, all without a Memory manager. (FF7's MMU is software(!)) This reqired many of the libs to be tweaked to run in such an environment.

However there is a strict programming rule that the PSX executable must use the BIOS fuctions. You can't talk directly to the metal. This is why PS1 games work on a PS2  even with a massivly different architecture. This is also why Virtual Game station ran so well. Connectix wrote thier own BIOS.

Also it's why Bleem was only 512K. It caught BIOS calls and made DirectX calls.

sfx1999

  • *
  • Posts: 1142
    • View Profile
ReWriting the FF7 Engine
« Reply #52 on: 2004-07-07 18:39:29 »
I thought Connectix was a JIT emulator.

Cyberman

  • *
  • Posts: 1572
    • View Profile
ReWriting the FF7 Engine
« Reply #53 on: 2004-07-07 18:42:42 »
Quote from: halkun
You are assuming that there are standard calls that are commonly used, there isn't

Though it is true that many game companies use Psy-Q libs to make games ...LoadTIM(), playSEQ()... These are very often tweaked and stripped for the individual application. The PSX does not use shared libaries like DLLs, a PSX executable is a static COFF-type. I don't think you are going to find entry points very easily as they can be anywere, and custom within the executable.

The FF7 kernel is amazing because it manages threading and several sub programs, each with a scripting language, all without a Memory manager. (FF7's MMU is software(!)) This reqired many of the libs to be tweaked to run in such an environment.

However there is a strict programming rule that the PSX executable must use the BIOS fuctions. You can't talk directly to the metal. This is why PS1 games work on a PS2  even with a massivly different architecture. This is also why Virtual Game station ran so well. Connectix wrote thier own BIOS.

Also it's why Bleem was only 512K. It caught BIOS calls and made DirectX calls.

That explains why I never saw a program use the TLB hardware in the PS1.. odd that.  I suppose if they had things would be much more difficult (LOL).

Well if they use the BIOS I can deal with the bios calls easily enough. That at least will give an idea of what they are doing at that level.

Cyb

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
ReWriting the FF7 Engine
« Reply #54 on: 2004-07-08 00:08:54 »
On top of which ^_^

Yaroze and and Psy-Q are totaly different beasts. Yaroze allows no access to the CD-ROM at all. Also the executible format is different It was an "ecoff" bin and not compatable with a PSX-EXE type coff file. The yaroze libs are massively different and made by Sony. Psy-Q was deveoped by Psygonsis.

You also can't boot a Yaroze ecoff from a cd-rom. The BIOS would halt the disk.

The TLB was used for caching purposes when needed. Because all the memory segemnts were hard wired togeather, depenending on what memory mirror you worte to, that would engaguge and disengauge the cache. That's really it.

PSX also doen't have a math co-prossesr either. The GTE is a fixed-point matrix trasformation engine. It also is horrably buggy and that's why the texture perpectives suck so badly. Many games relied on the buggy GTE and sony coudn't fix it later on.

Yare

  • *
  • Posts: 17
    • View Profile
ReWriting the FF7 Engine
« Reply #55 on: 2004-07-08 03:04:38 »
Quote
...we know that FF7pc was written in C++. Therefore, we must think within the limitations of that language when trying to reconstruct how FF7 can access and decode battle operations, etc, and that includes file I/O, and memory storage.

That leaves us with commands like ".read"; ".get"; and ".getline" for loading the battle animation data into memory, if I'm not mistaken...


C++ doesn't really have any limitations. Its not uncommon for most video games to have a lot of the operations that need to run very very fast (thousands of times per seconds, in some cases) written in ASM (assembly) blocks.

.read, .get, and .getline are not really effecient for the very specific and repetative purposes of a lot of the FF7 files. I would be more surprised if they didn't write thier own low-level file and memory IO functions than if they did.

They teach that in intermediate C++ classes. Its a fairly common practice as far as I can tell.

Remember that C++ and ASM pretty much go hand-in-hand, and you can write ASM directly into your C++ programs.

But then, Square programmers may also be a fairly lazy lot. So who knows?

And in case anyone is wondering, PSX games are programmed in a version of C++ as well -hooking into a propriatary Sony hardware API.[/b]

sfx1999

  • *
  • Posts: 1142
    • View Profile
ReWriting the FF7 Engine
« Reply #56 on: 2004-07-29 01:35:11 »
Hey isn't the decompression algorithm used in FF7 patented?

Qhimm

  • Founder
  • *
  • Posts: 1996
    • View Profile
    • Qhimm.com
ReWriting the FF7 Engine
« Reply #57 on: 2004-07-29 21:15:26 »
Maybe you're thinking of the much-disputed LZW patent? (read: "The GIF bitch")

Cyberman

  • *
  • Posts: 1572
    • View Profile
ReWriting the FF7 Engine
« Reply #58 on: 2004-07-30 04:50:52 »
Quote from: Qhimm
Maybe you're thinking of the much-disputed LZW patent? (read: "The GIF b*tch")


Which has expired, I wrote a compressor that used it as a college project lot of fun, but tottally useless :)
Unisys had the patent on it and decided to 'exercise' the patent, they got a rude awakening as people deleted the standard unix compress off there systems and used something else instead.  "Yes we are compliant .. we don't use your software at all or a variant we deleted it, you can come and look if you wish."

sfx1999
LSZ compression is used which is a very different animal.

Cyb