You're taking risks that aren't warranted.

The "popular" rate for crystals attached to the 805x 12-clockers of that era is 11.0592 Mhz. That allows you to program the first timer with a single-byte reload value and use that as the baud rate generator for 9600 Baud. Another SFR bit doubles that rate, so you then run at 19.2 kbaud.

Do you have an 80C51-BH1? If not, as I said, you're investing in something that's likely to be doomed. If they produced parts capable of 10.432 MHz, which was, in the '70's, a very popular and ubiquitous crystal, don't you think they'd have said so? If they cut off the allowable frequency for that 80C51-BH1 at 16 MHz, don't you think they knew that 18.432MHz would have been advantageous to advertise?

I'm not concerned with issues associated with getting your MCU to run, though you probably should be. If you don't concern yourself with adhering to specified operating conditions, e.g. voltage, clock frequency, circuit configuration, etc, you're running the risk of ending up with a circuit that won't work because it's designed incorrectly.

What you've proposed to do is NOT an easy thing, i.e. synchronizing two asynchronous events in such a way as to produce a glitch-free output suitable for use as the MCU oscillator input. You CANNOT use a crystal attached to the MCU to do what you propose. The crystal oscillator starts and stops at a widely variable rate, not readily predictable, and very dependent on the power supply behavior. I think you need to spend some time "skulling out" the details of producing a glitch-free switch between an oscillator and the SPP that you plan to use.

How, exactly, do you propose to do that?

Could you be more specific (post a schematic) about how you intend to interface your SPP to the 80C51, running in 80C31 mode, in such a way that it allows you to jam code into the MCU during its nPSEN cycle. This was common practice in the early days of microcomputers, but those had a "wait" line which made it easy. For an 805x-type, I'd presume you have to register the code byte, set a flipflop that says there's a code byte available, thereby allowing the at that point frozen oscillator to progress and use nPSEN to enable the registered data byte onto the 80C51 data bus.

All in all, that's not a terrible problem, BUT, I'm curious why you'd choose to do things in this way. Why do you need to do thta? What system requirement imposes such restrictions on you? Why do you want to use the parallel port (not that there is any reason why you shouldn't)? Is there some goal/purpose that you've not yet mentioned?

This sort of information might help us, or at least me, to help you make this work.

RE