I'm also pretty new regarding LinuxCNC, and in the process of orienting for the direction to control my machine.
A quick search:
duckduckgo.com/?t=h_&q=Unimat+SL100+&iax=images&ia=images
SL1000 (with three zero's) is a hobby level lathe.
Do you already have a PC for controlling your machine?
LinuxCNC needs a specially crafted OS with a real time kernel and quick I/O capabilities, because it does all calcualtions on the PC side. If you want to use USB, something like GRBL may be more appropriate. With GRBL, you send the G-code to a microcontroller, and the microcontroller does all the real time stuff. This makes the communication between the PC and the controller very tolerant of timing issues, the PC also does not need to meet real time performance, and any PC can be used. Have a look at the GrblHAL project, where you can choose from quite a lot of different microcontroller families.
For LinuxCNC
Parallel ports are mostly obsolete as PC hardware, but there are still motherboards where an LPT port is available on an internal header, but does not have a connector on the outside of the PC.
The lowest cost option (except the 2nd hand PC from the attic) for LinuxCNC is probably one of those SBC's I once had a working machine with machinekit on a Beaglebone Black, but it was headless and X-forwarding over SSH was atrociously slow (about a 2Hz display update rate. In the meantime Machinekit has mostly died too, but a Raspi 5 combined with Remora is an option. This uses an SPI bus to communicate with a microcontroller that does the step generation, but it still needs a low latency communication channel to exchange data with a servo thread. Apparently it's untested or not supported to attempt to use an SPI bus from another SBC then the Raspi 5.
SPI is supposed to be unavailable on regular PC's, but as far as I know it's often available on the TPM module, together with the LPC bus. But I have not seen any hint of LinuxCNC being able to work with those communication channels.