"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
[email protected] wrote:
> 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 and it starts
>>> communicating. All peers are remote from each other but are one system
>>> that must work synchronized. The large RAM usage is because the DOS
>>> program (the big boss) must make fast decisions depending on things that
>>> can have happened some time ago. Also, many peers have so little memory
>>> that most of their status is stored by the DOS program and must be
>>> available at any time. A disk is too slow.
>>> Still... What needs more than 2 GB of data in that scenario?
>>
>> You can now have M2 SSD with between half a million and 1 million
>> I/O per second, both for reading and writing. Even if you consider
>> that single-threaded DOS I/O will perform significantly worse,
>> you still get plenty of time for a bit of I/O unless you require
>> nanosecond reaction times on a RS485 line where it takes at a few
>> microseconds to transmit a single bit given your cable lengths.
>> You could also use a multi level system with ramdisk, disk cache,
>> fast SSD as disk, compressed swap memory etc. but of course I do
>> not know which types of data access you need :-)
>> I remember that when working with data acquisition in DOS, even
>> the BIOS USB support for mice or keyboards had significant lag
>> and jitter in the order of milliseconds, so there certainly is
>> a point in using RAM for the fastest bits of your task - I just
>> see an interesting challenge here to reduce footprint below the
>> 32 bit pointer limit of a few gigabytes. Because beyond that,
>> you will either make your whole app 64 bit or have to work by
>> copying memory areas in and out your accessible few GB space,
>> which is what HIMEMX with ultra extended XMS 3.5 would offer
>> unless you also have a matching ultra extended long mode DOS
>> extender to run the whole app in 64 bit address space.
>> Another idea could be "ultra EMS" which just maps memory into
>> accessible address space with a not-too-bad delay, giving you
>> more freedom to decide later which exact address to access,
>> without having to copy whole blocks.
>> Regards, Eric
>
> All you say is very correct, and if I were to start today I would write
> the program differently for sure. But for a program that started in the
> late 90s and grew to add more and more features it is doing quit well.
> At that time our systems where MUCH smaller.
> 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
> more then 100 to 200MB in this program.
> Freedos-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
