[HLE BIOS] Final Fantasy 8 hangs before starting a battle

[gameblabla]

What title says. As soon as you encounter a monster to battle, the game hangs.
Someone had opened a bug report on Codeplex and someone posted a very interesting comment. Sadly, said patches are now lost

I don't know if the pal version of ff7 and ff9 work but i know the US-NTSC versions work with the hle-bios as i have beaten both of them. Final Fantasy 9 has some issues with some fmvs and sound issues with the dfsound plugin. As far as Final Fantasy 8 - there is an issue with the game not being able to save and hangs when you get into a battle. My guess is that it may need a bios patch.

1.patch_missing_cop0r13_in_exception_handler:
In newer Kernel version, the exception handler reads cop0r13/cause to r2, examines the Excode value in r2, and if the exception was caused by an interrupt, and if the next opcode (at EPC) is a GTE/COP2 command, then it does increment EPC by 4. The GTE commands are executed even if an interrupt occurs simultaneously, so, without adjusting EPC, the command would be executed twice. With some commands that'd just waste some clock cycles, with other commands it may cause data to be written twice to the GTE FIFOs, or may re-use the result from the 1st command execution as input to the 2nd execution.
The old "CEX-1000 KT-3" Kernel version did examine r2, but it "forgot" to previously load cop0r13 to r2, so it did randomly examine a garbage value. The patch inserts the missing opcode, used in elo2 at 80033740h, and in Pandemonium II at 8007F3FCh:

2.early_card_irq_patch:
Because of a hardware glitch the card IRQ cannot be acknowledged while the external IRQ signal is still LOW, making it neccessary to insert a delay that waits until the signal gets HIGH before acknowledging the IRQ. The original BIOS is so inefficient that it takes hundreds of clock cycles between the interrupt request and the IRQ acknowledge, so, normally, it doesn't require an additional delay. However, the central mistake in the IRQ handler is that it doesn't memorize which IRQ has originally triggered the interrupt. For example, it may get triggered by a timer IRQ, but a newer card IRQ may occur during IRQ handling, in that case, the card IRQ may get processed and acknowledged without the required delay. Used in Metal Gear Solid at 8009AA5Ch, and in alone1 at 800AE2F8h:

3.patch_uninstall_early_card_irq_handler:
Used to uninstall the "early_card_irq_vector" (the BIOS installs that vector from inside of B(4Ah) InitCard(pad_enable), and, without patches, the BIOS doesn't allow to uninstall it thereafter). Used in Breath of Fire III (SLES-01304) at 8017E790, and also in Ace Combat 2 (SLUS-00404) at 801D23F4:

4.patch_card_info_step4:
The "card_info" function sends an incomplete read command to the card; in order to receive status information. After receiving the last byte, the function does accidently send a further byte to the card, so the card responds by another byte (and another IRQ7), which is not processed nor acknowledged by the BIOS. This patch kills the opcode that sends the extra byte.

[gameblabla]

Well turns out said patches actually from nocash and never applied to PCSX4ALL, which is a bummer.
The root cause is still unknown then.
TODO : Catch BIOS calls before a battle starts. (so we can get an idea as to why it crashes)

[gameblabla]

There's nothing in the bios calls that can help us... the game mostly use bzero & memcpy.
Our implementation of either is correct so not sure what's wrong...