On Tuesday, August 9, 2022 at 2:52:09 PM UTC-5, muta...@gmail.com wrote:   
   > On Wednesday, August 10, 2022 at 1:32:26 AM UTC+8, s_dub...@yahoo.com wrote:    
   > > On Thursday, August 4, 2022 at 9:36:39 PM UTC-5, muta...@gmail.com wrote:    
   > > > On Thursday, August 4, 2022 at 10:04:54 PM UTC+8, JJ wrote:    
   > > > > On Wed, 3 Aug 2022 15:36:27 -0700 (PDT), muta...@gmail.com wrote:    
   > > > > >    
   > > > > > Hi JJ. Thanks for your thoughtful response.    
   > > > > >    
   > > > > > Do you think, with the benefit of hindsight, there should have been   
   a    
   > > > > > mechanism for what we now know as host file access?    
   > > >    
   > > > > It would be nice, but don't you think it's too late for that?    
   > > > No. I am trying to extract philosophy.    
   > > >    
   > > > If you think this would be nice, then what    
   > > > would you propose exactly?    
   > > >    
   > > > And could this have been figured out decades ago?    
   > > >    
   > > > Or was something missing?    
   > > >    
   > > > At the same time you can solve the problem of    
   > > > people in real life, for years, taking their chances    
   > > > with line noise. Before error-correcting modems.    
   > > > Does error-correction belong in modems or applications,    
   > > > as happened in real life?    
   > > >    
   > > > Or does it belong in the os?    
   > > Here is where a driver for the device is useful. The OS should only get   
   notification of device error.    
   > > The driver for the device would be the place to attempt error correction,   
   at the least, return a fail status to the OS.   
   > Ok, good point. I don't really understand drivers.    
      
   Think 'Device Control'.  A device driver is the controlling code for the   
   device, that is, the device specific code.   
      
   > So far in pdos I have not attempted or needed such a concept.   
   > > >    
   > > > If someone types:    
   > > >    
   > > > rm -fr /scratch    
   > > >    
   > > > And line noise of "enter" happens after    
   > > > the "/", who failed to think things through?    
   > > The shell. It's design fails to catch that and issue a warning and a   
   confirm request, istm.    
   > > Your example uses the keyboard to communicate to the console through the   
   'shell'.    
   > > Very early on, before the ibm pc this was handled through the i8255, with   
   the pc this changed.    
   > > reference note of modes of operation..    
   > > https://en.wikipedia.org/wiki/Intel_8255    
   > >    
   > > The OS kernel should not have to deal with these low level details, a   
   specific driver should handle it.    
   > > Same with error detection and attempted correction. It should be handled   
   by the specific driver.   
   > So for example, if an app does an fseek of a com    
   > Port to an earlier position, what I want is for the com port    
   > to be reset, which Bochs detects and does a rewind    
   > of the host file, then reads done from the com port to    
   > get to the right position. That is something that would go    
   > into a driver?   
      
   Yes.  Bochs has provided a driver for you.   
   From your description, Bochs is treating the COM: as a rewindable Mag Tape   
   device, by chance.   
   Generally though, COM: has a device attached that is not rewindable.   
   A Modem, paper tape reader RDR:, paper tape punch PUN:, a console, provide a   
   data stream that is not rewindable.  (A limited cheat would be to write the   
   input stream to a temporary file, and perform the seek on the temporary file.    
   The temp file would    
   need to be in fast memory, a huge ring buffer basically).   
      
   Each of these devices require code specific to the device, a device driver.   
      
   > > > > Serial port is    
   > > > > now considered as a legacy (but not dead yet) communication port. It's   
   no    
   > > > > longer in development and it's no longer widely used except in   
   industrial    
   > > > > and business fields. What's your intended use case scenario for it,   
   anyway?    
   > >    
   > > > Host file access is what I am after right now.    
   > > What is this 'Host'? Bochs? -- or are you calling your OS the host? -or- ?   
   > I am running pdos under Bochs on an Android phone.    
   >    
   > Pdos is the guest os and the android is the host.    
   >    
   > I thought this was standard terminology?   
      
   It is, but I didn't see mention of Android.   
   I didn't know you could do what you're doing on the Android phone.  Kudos to   
   you!   
      
   > > > > Cause I could think that it's for a special use case only.    
   > > > I'm more interested in the philosophy of    
   > > > external communication.    
   > > You develop in C I think, so dig into the topic of streams.    
   > > -- It's likely you have, forgive me for being a dunce.    
   > > In addition to stdin, stdout, stderr, you could add stdtmp where stdtmp is   
   a file already in an opened state, like the others, to catch COM1: input   
   stream through the stdtmp driver.   
   > I don't have a problem at this level.    
   > For the purposes of this conversation I am happy    
   > to do an fopen of com1 r+b   
   > > The hard part is determining End Of Transmission.   
   > For normal com port usage I would rely on the    
   > Bios timeout. When I am accessing a host file,    
   > I expect Bochs to give a timeout at EOF.   
   > > Perhaps the stdtmp driver has a time-out function to catch EOT.    
   > > When the simplest protocol is the case, where COM1: just takes byte data,   
   no control bytes are allowed to be embedded. The risk of errors is low if   
   stored in memory, or a thumb-drive.    
   > > The risk is high if the device is slower than COM1: such as a floppy   
   drive.    
   > > Early on, all devices were slow, so some form of transmission protocols   
   were developed.    
   > > So think in terms a byte being converted into two bytes, each an ASCII   
   nibble.    
   > > Prepend some ascii info and trailing check sum and you have a Intel .HEX   
   record.    
   > > https://en.wikipedia.org/wiki/Intel_HEX    
   > >    
   > > Since ASCII HEX restricts bytes into the printable range, bytes outside   
   this range can be used for control.    
   > > For example, 07h aka byte value 7, where value 7 is not printable if   
   handled by the console.    
   > > But causes the console to 'beep'.    
   > > The ASCII form of 07h is 30,37.    
   > > > > > The method above, abusing the hardware, is not the only    
   > > > > > method I have used. My pdos-generic code is already capable of    
   > > > > > this, but relies on a cooperative bios.    
   > > > > That's expected, since it's not part of the standard specification.   
   Though,    
   > > > > BIOS modification is not actually required, since what's needed can be    
   > > > > implemented as a TSR/driver which hooks BIOS functions; unless you   
   want it    
   > > > > to work even without an OS.    
   > > > I'm interested in changing the bios specification.    
   > > >    
   > > > Within the limits of the old computers.    
   > > > Or close.    
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)