At least on the alternative hardware, this "blindly sending" a reset command causes the shell to be terminated right away:
The driver acknowldges the reset command with a zero byte - and that byte ends up being read by DumpOutput causing it to branch to endOutput.
Maybe that sending a reset command is beneficial on the original hardware. Then another .if is required. Or DumpOutput shouldn't quit on reading a zero byte - the shell handler doesn't seem to send it on purpose(?)
Neither the original hardware type nor the alternative hardware type have any read and write i/o port share addresses. Therefore phantom reads aren't an issue with those hardware types.
This reverts commit ae5cb754fb.
The new hardware type has simple UART-type interface. Beside the two data registers, there are only the two bits to indicate readability and writability of the data registers.
Depending on the 6502, LDA addr,X and/or STA addr,X produce additional phantom reads. In order to avoid those phantom reads to do i/o access, I used the "classic" approach of moving those reads from page $C0 to page $BF.