From: muta...@gmail.com   
      
   On Wednesday, August 3, 2022 at 4:26:48 AM UTC+8, Scott Lurndal wrote:   
   > "muta...@gmail.com"  writes:   
   > >On Tuesday, August 2, 2022 at 9:40:46 PM UTC+8, JJ wrote:   
   > >> On Mon, 1 Aug 2022 15:15:27 -0700 (PDT), muta...@gmail.com wrote:   
   > >> > This could be a double post.   
   > >> >   
   > >> > Bochs could be designed to point a com port   
   > >> > To a host file.   
   > >> >   
   > >> > The pdos application could do fopen of com1 r+b   
   > >> >   
   > >> > Pdos will dutifully translate that into reads and writes of the com   
   port.   
   > >> >   
   > >> > If the app does an fseek to an earlier position   
   > >> > an initialization of the com port could be   
   > >> > done which Bochs interprets as a rewind.   
   > >> >   
   > >> > Pdos would then do reads to get to the right position.   
   > >> >   
   > >> > Tape drives may behave similarly.   
   > >> >   
   > >> > Is there some principle here?   
   > >> >   
   > >> > It won't work if the com port is connected to another computer though.   
   > >> >   
   > >> > Although maybe if dtr/dcd were manipulated it could.   
   > >> According to Bochs documentation (bochsrc.html), when a serial port is   
   > >> configured as file mode, the specified file can only work as an output. It   
   > >> can not work as an input (i.e. as a data source).   
   > >>   
   > >> For both output and input, only raw, socket, and pipe modes should be   
   used.   
   > >>   
   > >> Also, serial port is not a seekable device. It's just a generic   
   > >> communication device with no data-size related protocol. Thus, there is   
   > >> concept of data position. There's no way to seek to specific data   
   position,   
   > >> or do a rewind. Such functionality/feature is for application level   
   > >> implementation instead of hardware level implementation.   
   > >   
   > >You just described what currently happens.   
   > >   
   > >I just described what could happen, including the ability to seek.   
   > >   
   > >Is there a reason why my proposal wouldn't work?   
   > How, exactly, do you propose to handle seek on an   
   > inherently ephemeral bitstream such as that produced   
   > by serial receiver logic, whether it is a RS232C   
   > UART or a 100Gb/s LAN?   
      
   Are you talking about Bochs or a real serial port attached to perhaps a null   
   modem cable to another computer?   
      
   The former I explained above already.   
      
   The latter I touched on above but I'm not certain about.   
      
   The latter would involve dropping dtr or dcd to rewind, but I'm not sure that   
   is possible.   
      
   In both cases, rewinding a file is similar to a tape drive so there may be   
   prior art.   
      
   Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)