Homing process

Hello community! I need some expert help to restore the automatic homing sequence on my 2014 PROBOTIX Meteor.
Current Status:
• I am running LinuxCNC / AXIS version 2.5.0 on an older PC.
• The machine is perfectly calibrated by software. Motors are running fine at 240 in/min, acceleration is dialed in, and the SCALE is correct (-1685 for X and Y).
• Since automatic homing wasn't working, I successfully set up a "Virtual/Manual Home Routine" by setting HOME_SEARCH_VEL = 0.000000, HOME_LATCH_VEL = 0.000000, and HOME_SEQUENCE = 0, 1, 2 inside the .ini file. The software references perfectly in the air and my soft limits (MAX_LIMIT) protect the entire table (25x50").
The Problem:
I want to recover the physical automatic homing sequence, but LinuxCNC seems completely blind to the physical switches.
When looking at the HAL Configuration screen (Pins ➔ parport ➔ 0), the pins parport.0.pin-11-in (Z), parport.0.pin-12-in (Y), and parport.0.pin-13-in (X) are constantly stuck on FALSE, even if I physically click the microswitches on the machine with my finger. The inverted signal (-not) stays on TRUE all the time.
My Question:
Has anyone with a 2014 Unity Box experienced this? Is this a known hardware issue like a loose common ground wire inside the breakout board, a faulty ribbon cable, or do I need to look for a specific pinout override in my .hal file?
I am attaching my current .ini and .hal files. Any guidance on where to look inside the breakout board or the wiring would be highly appreciated. Thanks in advance!

Note on Hardware Alteration: Please note that the original motherboard supplied by PROBOTIX was replaced with a different motherboard. I am still using the original 2014 Unity Box and breakout board, but the parallel communication is now handled by this new motherboard setup. Could this motherboard swap change the base address or cause a voltage mismatch on the input pins (parport.0.pin-IN), even though the motors (parport.0.pin-OUT) are outputting movement perfectly?"

A port address change would prevent the step/dir outputs from working,
so it's probably not that.

You might check that you get a valid voltage change at the limit switch pins,
in case there is a wiring problem.

Another possibility is that the new motherboards parallel port lacks pullup
resistors on the input pins, and the breakout board expects these pullups.
( This problem has happened before with parallel port systems and would
have similar symptoms, that is, input pins always read low )