The original Atari XEP80 driver supports both S: and E:. However, S: is mostly for bitmap mode, which is not very useful because of how slow and crippled it is, and the weird squarish aspect ratio. The SpartaDOS X driver only hooks E:.
If you're going to emulate the XEP80, be aware that it uses a 9 data bit protocol, not 8. The XEP80 handles this with a standard UART by monitoring the parity error status on each byte during receive and changing parity mode on each byte during transmit. That may be tricky to do with a standard serial interface. That having been said, I wouldn't recommend emulating the XEP80 at all, for the following reasons.
Let's start with the hardware protocol. The joystick based protocol is a big pain in the butt on the Atari side because it eats tons of CPU time in order to bang out one bit per scanline. In the transmit direction, this burns 10 scanlines per byte. In the receive direction, this practically requires display DMA to be turned off to lock onto the bit timing. The joystick port also seems not to be very good for higher speed operation. I've been able to run the XEP80 driver at 31.5Kbaud transmit speed for about a 20% increase in throughput, but could not get 63Kbaud operation stable. That's significantly below speeds that are normally attained on the SIO bus, which also is much easier to drive with standard interrupt-driven operation. Ditch the weird 9-bit protocol for a standard 8 data bit protocol and use a standard SIO2PC connection, and it's easier on both ends.
Even if the hardware protocol weren't an issue, let's go to the software protocol. First issue, the XEP80 deviates a lot from standard E: behavior. The biggest issue is that instead of using a logical line bitmap like the Display Handler does, it stores EOLs in the framebuffer to mark lines. This leads to lots of bugs like "move right" actually changing the contents of the screen and returning spaces at the end of a line. This is frustrating in BASIC because your source lines tend to accumulate lots of spaces at the end that you can't see and have to remove later on. Then we get to the more advanced features like bitmap graphics and hardware scrolling. These are a pain to use for one silly reason, which is that you can't get any control values into the XEP80 without actually printing them on screen. For instance, in order to move the cursor in graphics mode you need to write two address bytes before issuing the set cursor position command, but those two bytes will actually get written into the framebuffer. The workaround involves abusing the text mode positioning commands to temporarily move the cursor off screen before printing the control bytes. It's hard to do anything fast when it takes six bytes to plot a pixel.