If it's a DOS function, there is no multitasking, so there is nothing that would happen instead, so yes.Originally Posted by Bladactania
--
Mats
If it's a DOS function, there is no multitasking, so there is nothing that would happen instead, so yes.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
That is unfortunate. But I guess there's no way around it.
Thanks.
Well, I guess you could rewrite the code to be Windows-compatible instead of using very ancient DOS...
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
I'm limited by the computer the code will be running on. I'm writing code to run on a Single Board Computer running a 133Mhz Processor with about 32MB of memory...
Right. So if you are going to use more than about 2% of the 32MB, you will need a different OS than DOS.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Wait... What?
DOS is limited to 640KB (well, ok the first 1MB, but the last 384KB of "DOS" memory is occupied by the BIOS, Video Memory and such things, so the application has a bit less than 640 KB to play with, since the first little bit of memory is occupied by vector table and the actual DOS kernel).
There are ways around it, but it gets messy very quickly.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Obviously that can't be true considering my first computer ran DOS with 4MB of RAMDOS is limited to 640KB (well, ok the first 1MB, but the last 384KB of "DOS" memory is occupied by the BIOS, Video Memory and such things, so the application has a bit less than 640 KB to play with, since the first little bit of memory is occupied by vector table and the actual DOS kernel).
Read more about this here. There are several ways to overcome the 640K barrier (back in the day, I used XMS). Chances are that whatever DOS version you are using supports a DOS extender of some kind. If you are using a version of DOS prior to 3.0, then things might get kind of tricky though.
DOS memory extenders require cooperation from the application. You don't just plug it in and magically get access to more memory.Obviously that can't be true considering my first computer ran DOS with 4MB of RAM
Read more about this here. There are several ways to overcome the 640K barrier (back in the day, I used XMS). Chances are that whatever DOS version you are using supports a DOS extender of some kind. If you are using a version of DOS prior to 3.0, then things might get kind of tricky though.
If DOS is a requirement, I'd calibrate a busy-loop to do subsecond waiting.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Nowhere did I imply there was magic involved, I just stated that is was possible (and relatively common to do).DOS memory extenders require cooperation from the application. You don't just plug it in and magically get access to more memory.
How is that an improvement over calling the delay() function?If DOS is a requirement, I'd calibrate a busy-loop to do subsecond waiting.
How do you know you will have this function? The OP indicated targetting some custom environment.
Where would you even acquire a DOS memory extender? None of those companies are still in business.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Kids these days! Back in my day we had himem.sys and emm386.sys ... both of which came with DOS.
Quzah.
Hope is the first step on the road to disappointment.
Yes, but beyond that, you need the compiler to produce code that uses the extended memory. Most DOS applications didn't actually USE memory above 1MB, it was mainly used as disk-cache.
Note that to use memory above 1MB, the application code needs to run in protected mode, and to get above 16MB, it is necessary to have 32-bit protected mode. Neither of the protected modes are compatible with real-mode that DOS runs in, so basically, any interrupts have to be turned off whilst in protected mode. This also means no calls to BIOS, no reading/writing from/to hard-disk, etc, etc. It is non-trivial to run in protected mode and DOS at the same time.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
I'm pretty sure DOOM used more than 1 MB of memory, and that it read from files, and could read key interrupts. Pardon me while I disagree with you.
Speak of the devil, here it is now: DOS extender - Wikipedia, the free encyclopedia
Perhaps I'm misunderstanding your statement, but again, I'm pretty sure DOOM handled keyboard interrupts just fine, and that it read from disk...
Quzah.
Hope is the first step on the road to disappointment.
DOOM was loading it own memory manager if I remember correctly. I do not know was it was doing, but it was one of the first programs doing it...
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
