Against my better judgement I have taken a look at some of your uncommented code. Here are the problems that I have found so far:
You are adapting code that was written for a different processor running at a different speed but you haven't taken those differences into account. This leads to the first two problems.
The ATmega32 has four 8-bit I/O ports so any of them can be used for the data lines when you are using the 8-bit LCD interface. The ATmega328 as implemented on the Arduino has only one 8-bit I/O port (Port D) but in more than one case you are trying to use another port for your data.
You are specifying an 8 MHz clock frequency but your Arduino is running at 16 MHz. This means that all of your delays are only half as long as you think they are. It's always OK (as far as the LCD module is concerned) to use a longer than necessary delay, but a too short delay can cause problems.
Also:
The 8-bit initialization routines are based on examples shown in the LCD controller datasheets but they do not implement the 'Initialization by Instruction' sequence that is recommended in the datasheet. These steps work most of the time for LCDs and your VFD controller may not be as intolerant as the LCD controller. On the other hand your datasheet mentions the possible need for 'Initializing by Commands', but doesn't give the technique. It's in the middle of page 11 in really fractured English.
Remarks
There is a possibility that reset doesn’t work by slow start power supply.
Therefore the initializing by commands needs.
The 4-bit initializations are just plain wrong. They are attempting a trick maneuver to implement the 'Initialization by Instruction' sequence but I doubt if the timing requirements are being met.
The 8-bit routines to send data and commands do not properly implement the timing diagram in section 10.3 of the datasheet. I did not look at the 4-bit routines.
That should keep you out of trouble for a while.
Don