Forums before death by AOL, social media and spammers... "We can't have nice things"
|    alt.os.development    |    Operating system development chatter    |    4,255 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 3,216 of 4,255    |
|    mutazilah@gmail.com to All    |
|    Re: com port    |
|    04 Aug 22 19:36:38    |
      From: muta...@gmail.com              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?              If someone types:              rm -fr /scratch              And line noise of "enter" happens after       the "/", who failed to think things through?              > 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.              > Cause I could think that it's for a special use case only.              I'm more interested in the philosophy of       external communication.              > > 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.              Specifically I am after fopen of 0x80              > > 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?       > It would be similar to it, at least for the error detection/correction part.       > > Maybe this crude method, relying on error-free       > > communication, could be used while waiting for       > > SLIP/PPP to be implemented?       > >       > > Paul.       > I think it's fine if it's just for a temporary solution. Otherwise it would       > be naive to think that, users would use it in an ideal environment. Who       > knows, one may use it in a factory/lab where it's plenty of electromagnetic       > wave.              Perhaps with error-correcting modems too.              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca