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,211 of 4,255    |
|    JJ to muta...@gmail.com    |
|    Re: com port    |
|    04 Aug 22 21:04:52    |
      From: jj4public@outlook.com              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? 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?       Cause I could think that it's for a special use case only.              > 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.              > 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.              > 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.              --- 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