From: muta...@gmail.com   
      
   On Wednesday, August 10, 2022 at 1:32:26 AM UTC+8, s_dubrovich@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.   
   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?   
      
   > > > 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?   
      
   > > > 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.   
   > Are you talking about IO.SYS or RomBios?   
   > I'd say the IO.SYS is the walkway into the RomBios, perhaps the minimum io   
   functions handler.   
      
   Either will do the job from the point of view   
   of the os. Which leads to another question. Someone said   
   that what I am calling an ideal bios or pseudo-bios   
   is actually a hardware abstraction layer.   
   Does that sound right?   
      
   > > Specifically I am after fopen of 0x80   
   > At first glance I saw fopen port 80, the http port, but you have written 80h.   
      
   The first hard disk. Being opened as a stream.   
   That's what I want the bios to provide.   
      
   The bios is just software, easily changed   
   to prove a concept. Especially with Bochs.   
      
   >   
   > Steve   
   > > > > The hardware could also have been designed with   
   > > > > another wire if you think the existing wires cannot be   
   > > > > repurposed.   
   > > > Sure, why not. But all serial port pins are already used. The DCD and RI   
   > > > pins are the only possible ones which can be repurposed for what you're   
   > > > trying to achieve.   
   > > Well maybe that's exactly what should be specified.   
   > > > > It's a good point that with a serial cable you could   
   > > > > have data corruption so ideally you want a crc and error   
   > > > > correction. When that is added do you end up   
   > > > > with SLIP/PPP?   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)