Once you start getting into the world of embedded systems and industrial
controls and real-time communications protocols, your view of what computers
are supposed to be and do changes significantly. DOS can be a very robust
solution in those types of applications. Simply throwing money (such a
"640K of memory should be enough for anybody."
lol :)
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐ Original Message ‐‐‐
On Wednesday, January 13, 2021 4:47 PM, Andreas Berger
andr...@thebergerclan.org wrote:
> On 13/01/2021 18:18, Eric Auer wrote:
>
>> Hi!
>>
>>> I
Hi!
> However, the reason I answered in the first place was to show Tom that
> DOS programs exist that use more then 100MB. I don't think I will ever
> need more then 4GB - or even that much, but it is good to know that it
> is possible. On the other hand, I never imagined I would end up using
>
On 13/01/2021 18:18, Eric Auer wrote:
Hi!
I don't receive gigabytes at once. I have multiple serial lines using a
RS485 similar communications method (Master - Slave). The peers can be
up to 1KM away. Each line can have up to 50 peers. Each peer is
interrupted when it's 9-bit address is called
Hi!
> I don't receive gigabytes at once. I have multiple serial lines using a
> RS485 similar communications method (Master - Slave). The peers can be
> up to 1KM away. Each line can have up to 50 peers. Each peer is
> interrupted when it's 9-bit address is called and it starts
> communicating.
Hi Eric,
I don't receive gigabytes at once. I have multiple serial lines using a
RS485 similar communications method (Master - Slave). The peers can be
up to 1KM away. Each line can have up to 50 peers. Each peer is
interrupted when it's 9-bit address is called and it starts
communicating. Al
Hi Andreas,
how do you manage to receive gigabytes of data from a
few dozen peers with mere megahertz of CPU clock rate?
What are the chances to reduce server RAM footprint?
Regards, Eric
> I still use DOS to this day in an industrial setting...
> hundreds of remote machines with tens of embed
On 10/01/2021 17:50, tom ehlert wrote:
there is simply no DOS application needing even 100 MB.
making more than 4 GB available won't change this.
applications needing more then 4GB would probably benefit more from
multiple cores.
You may not know it, but I still use DOS to this day in an indu
hi tom,
> there is simply no DOS application needing even 100 MB.
> making more than 4 GB available won't change this.
i beg to differ: jack's cache can be configured to cache
huge fractions of your partition (which may or may not be
good for performance) and that ramdisk modification by
japheth
Hallo Herr Mercury Thirteen via Freedos-devel,
am Sonntag, 10. Januar 2021 um 18:59 schrieben Sie:
> On Sunday, January 10, 2021 10:48 AM, Eric Auer e.auer@jpberlin.dewrote:
> Hi Mercury & everybody,
> I noticed a while back that Japheth updated his HiMemX driver, and
> I've finally gotten arou
On Sunday, January 10, 2021 10:48 AM, Eric Auer e.a...@jpberlin.de wrote:
> Hi Mercury & everybody,
>
>> I noticed a while back that Japheth updated his HiMemX driver, and I've
>> finally gotten around to packaging it up for use in FreeDOS. Also, he's made
>> a new driver which can do what that
Hi Mercury & everybody,
> I noticed a while back that Japheth updated his HiMemX driver, and
> I've finally gotten around to packaging it up for use in FreeDOS.
>
> Also, he's made a new driver which can do what that HiMemX does, and
> more... way more. HiMemSX can access memory above the 4 GiB
I noticed a while back that Japheth updated his HiMemX driver, and I've finally
gotten around to packaging it up for use in FreeDOS.
Also, he's made a new driver which can do what that HiMemX does, and more...
way more. HiMemSX can access memory above the 4 GiB mark! I've packaged it up
also, i
13 matches
Mail list logo