This problem probably has nothing to do with VBlank length (read: amount of time), because you're actually drawing the title screen "mostly correctly". It's not entirely gobbledegook.
This problem does not appear to be mirroring related, otherwise you'd likely see nothing.
This problem really looks to be in how you're rendering data (I suspect this), or maybe a strange endian problem.
Balloon Fight is a CHR-ROM game, with 16KB PRG and 8KB CHR-ROM. That means the graphics are not "drawn" by 6502 code -- they are pre-done in CHR, and that CHR bank ends up in the pattern table (PPU RAM $0000-1FFF). If you're getting those wrong, then something much deeper is incorrect.
Try something logical, like: using a known working emulator with a good debugger and helper tools (read: Mesen, FCEUX), dump PPU RAM to disk while at the title screen, then have your emulator do the same at the same point. Now compare files and see if you can figure out why yours is wrong.
Another possible clue -- but not definitive, for the reasons I'm about to state -- is in the fact your palette is completely wrong. "A 1-PLAYER GAME, B 2-PLAYER GAME" etc. is supposed to be white. The "A" in "A 1-PLAYER GAME" is located (nametable-wise) in PPU RAM at $2248, and is supposed to be tile $0A in PPU RAM (address $10A0, i.e. upper half of the pattern table). This area of the screen should be using the attribute bytes from PPU RAM $23E2. Colour index #1 is what should be used for white (i.e. NES colour $30), taken from palette entry #0 (i.e. $3F00-3F03). If you haven't implemented palette lookups etc. then the colours being wrong is OK/acceptable/understood.
The complexity with threads like this is that your emulator is your code and nobody here understands it but you and only you. "Test ROMs" are not going to magically guarantee that those passing magically means you'll have a working NES emulator (I'm not sure why people think that either, but I digress). Lots of people here doing emulators have done things like run CPU instruction test ROMs and have them pass, but only to find things are completely wrong with where/how they were storing data (i.e. the ROM would pass fine, but things would functionally be incorrect).
One thing emulator authors
do find universally helpful is to generate a log syntactically similar to
http://www.qmtpro.com/~nes/misc/nestest.log -- which is from Nintendulator, known to be accurate, running the nestest ROM -- and then compare the log from their emulator to that log. This usually turns up several mistakes, the #1 problem being in
adc/sbc emulation (if that turns out to be the case,
see this post and the reference material within it).
When you find the problem,
please be sure to post in this thread with a follow-up explaining the root cause. This tends to help other new emulator authors.