As someone else said he is likely moving at around 80 pixels per second, so it basically means he is in fact moving faster than a typical 60 fps screen is refreshed (1.33 pixels per frame). While its rather simple to represent pacmans x and y position as fractions and just add the speed (adjusted for screen refresh), it means you have to be careful with your logic for deciding when pacman can turn. Many turns will not be aligned with integer values which is what you operate on the screens pixels. So if your code works with an offset value for pacman (as a max +/- 8 pixel offset from a character position) that offset might jump from e.g. -0.1 to 1.1 meaning that any check for offset 0 as a valid turning point would be missed.
One solution to this could be to work with the fractions by themselves and whenever they pass a full pixel value you then move pacman one pixel and perform the logic for tests/turns. If the fraction add resulted in two pixels move you can do the logic twice too. For example when the fraction x offset of pacman is 0.9, adding the speed of 1.33 means he is at offset 2.23 and in fact has to move two pixels and you should execute the logic tests for each pixel added to his offset, in case he could turn after the first pixel.
One trick often used is to divide the speed by 2 to lower the actual speed below 1 pixel movement per frame and then execute movement logic twice for each screen refresh. This assumes that the frame rate is fixed and known and that the divided speed would become lower than 1.
In reality the movement of pacman is quite a bit more complex as you would have to support "cornering" too, so you have to check if he can turn quite a bit before the actual intersection as well. All this is described in the Pacman Dossier with some detail.