EmbeddedRelated.com
Forums

(MS-)DOS PC on a microcontroller??

Started by Paul Rosen October 23, 2007
larwe wrote:
> Vladimir Vassilevsky <antispam_bo...@hotmail.com> wrote: > >> For example: in the MS DOS, it is perfectly valid to allocate a >> memory block of zero bytes. In PTS-DOS and some others it results >> in an error. It appears that surprisingly many programs are >> actually making the requests of zero bytes, so here is a >> compatibility problem. > > Let me guess... the 0 byte malloc code is in the runtime libraries > for Microsoft C, so that no kosher program will run properly on > non-kosher DOS clones.
See the following from the C standard. Note the provision for a size request of zero. This is easily missed, because it applies to all of malloc, realloc, and calloc and thus is isolated in the standard. 7.20.3 Memory management functions [#1] The order and contiguity of storage allocated by successive calls to the calloc, malloc, and realloc functions is unspecified. The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object or an array of such objects in the space allocated (until the space is explicitly freed or reallocated). Each such allocation shall yield a pointer to an object disjoint from any other object. The pointer returned points to the start (lowest byte address) of the allocated space. If the space cannot be allocated, a null pointer is returned. If the size of the space requested is | zero, the behavior is implementation-defined: either a null | pointer is returned, or the behavior is as if the size were | some nonzero value, except that the returned pointer shall | not be used to access an object. The value of a pointer | that refers to freed space is indeterminate. | | This is the critical provision ----------------------' -- Chuck F (cbfalconer at maineline dot net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> -- Posted via a free Usenet account from http://www.teranews.com
Paul Rosen wrote:

> On Tue, 23 Oct 2007 10:21:24 -0700, karthikbalaguru > <karthikbalaguru79@gmail.com> wrote: > > Thanks for your suggestions. > > >>FreeDOS is a complete, free, 100% MS-DOS compatible >>operating system. Works ... in embedded systems. > > > This is the the operative point. One needs a microcontoller at least > connected to a floppy, a CD-ROM or a USB-stick to install Freedos and > to copy the old MS-DOS programs into the microcontoller. Further one > needs a monitor connected to the microcontroller. Where can I find a > wiring diagram for this.
We give out paper schematics with our dev kits. A few customers have developed their own products from our schematic and I don't have a problem with that as long as they don't pirate our bios.
On Tue, 23 Oct 2007 17:30:28 -0400, CBFalconer <cbfalconer@yahoo.com>
wrote in comp.arch.embedded:

> larwe wrote: > > Vladimir Vassilevsky <antispam_bo...@hotmail.com> wrote: > > > >> For example: in the MS DOS, it is perfectly valid to allocate a > >> memory block of zero bytes. In PTS-DOS and some others it results > >> in an error. It appears that surprisingly many programs are > >> actually making the requests of zero bytes, so here is a > >> compatibility problem. > > > > Let me guess... the 0 byte malloc code is in the runtime libraries > > for Microsoft C, so that no kosher program will run properly on > > non-kosher DOS clones. > > See the following from the C standard. Note the provision for a > size request of zero. This is easily missed, because it applies to > all of malloc, realloc, and calloc and thus is isolated in the > standard. > > 7.20.3 Memory management functions > > [#1] The order and contiguity of storage allocated by > successive calls to the calloc, malloc, and realloc > functions is unspecified. The pointer returned if the > allocation succeeds is suitably aligned so that it may be > assigned to a pointer to any type of object and then used to > access such an object or an array of such objects in the > space allocated (until the space is explicitly freed or > reallocated). Each such allocation shall yield a pointer to > an object disjoint from any other object. The pointer > returned points to the start (lowest byte address) of the > allocated space. If the space cannot be allocated, a null > pointer is returned. If the size of the space requested is | > zero, the behavior is implementation-defined: either a null | > pointer is returned, or the behavior is as if the size were | > some nonzero value, except that the returned pointer shall | > not be used to access an object. The value of a pointer | > that refers to freed space is indeterminate. | > | > This is the critical provision ----------------------'
Chuck, I think you're missing the point here. There is not necessarily a relationship between the C library being required to support malloc/calloc requests for 0 bytes and whether or not the operating system chokes on zero bytes. Given any real world implementation of malloc etc., a C library will do one of the following: -- return a NULL pointer without even calling the OS allocation routine. -- call the OS allocation routine for a block of (requested size + internal header size) bytes. On real mode MS-DOS and clones running in 16-bit real mode on x86, the internal header is almost certainly 16 bytes (one "paragraph"). Even if the requested value is left at 0 and not rounded up to one "paragraph" of 16 bytes, if the library calls the OS at all, it will almost certainly be for 16 bytes. The differences in the responses of different DOS clones to a call to allocate 0 paragraphs would never be seen by any DOS C library I have ever used. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://c-faq.com/ comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Jack Klein wrote:
> CBFalconer <cbfalconer@yahoo.com> wrote: >> larwe wrote: >>> Vladimir Vassilevsky <antispam_bo...@hotmail.com> wrote: >>> >>>> For example: in the MS DOS, it is perfectly valid to allocate a >>>> memory block of zero bytes. In PTS-DOS and some others it results >>>> in an error. It appears that surprisingly many programs are >>>> actually making the requests of zero bytes, so here is a >>>> compatibility problem. >>> >>> Let me guess... the 0 byte malloc code is in the runtime libraries >>> for Microsoft C, so that no kosher program will run properly on >>> non-kosher DOS clones. >> >> See the following from the C standard. Note the provision for a >> size request of zero. This is easily missed, because it applies to >> all of malloc, realloc, and calloc and thus is isolated in the >> standard. >> >> 7.20.3 Memory management functions >> >> [#1] The order and contiguity of storage allocated by >> successive calls to the calloc, malloc, and realloc >> functions is unspecified. The pointer returned if the >> allocation succeeds is suitably aligned so that it may be >> assigned to a pointer to any type of object and then used to >> access such an object or an array of such objects in the >> space allocated (until the space is explicitly freed or >> reallocated). Each such allocation shall yield a pointer to >> an object disjoint from any other object. The pointer >> returned points to the start (lowest byte address) of the >> allocated space. If the space cannot be allocated, a null >> pointer is returned. If the size of the space requested is | >> zero, the behavior is implementation-defined: either a null | >> pointer is returned, or the behavior is as if the size were | >> some nonzero value, except that the returned pointer shall | >> not be used to access an object. The value of a pointer | >> that refers to freed space is indeterminate. | >> | >> This is the critical provision ----------------------' > > Chuck, I think you're missing the point here. There is not > necessarily a relationship between the C library being required to > support malloc/calloc requests for 0 bytes and whether or not the > operating system chokes on zero bytes. > > Given any real world implementation of malloc etc., a C library will > do one of the following: > > -- return a NULL pointer without even calling the OS allocation > routine.
But that return normally is treated as an error signal. Using such a library is valid, but the caller has to detect the zero size and ignore that false error signal. I don't think the world realizes that. -- Chuck F (cbfalconer at maineline dot net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> -- Posted via a free Usenet account from http://www.teranews.com
"Paul Rosen" <proxx@lycos.de> wrote in message 
news:dv9sh3tsvgjqpqpfj3j684d517c1kccfg1@4ax.com...
> Hallo. > > I am wondering, whether anyone made the possibly useless attempt, to > create a (MS-)DOS (and its old programs) compatible PC on a > Microcontroller by using its flash as harddisk?
The controller inside a Canon EOS 300D camera runs DOS. This was discovered by someone reflashing the firmware (provided by Canon). For the whole story, Google "Canon Russian firmware hack." There is of course Caldera DOS (freeware), compatible with MS-DOS.
On Tue, 23 Oct 2007 13:15:30 -0700, Jim Stewart <jstewart@jkmicro.com>
wrote:

>larwe wrote: >> On Oct 23, 1:08 pm, Paul Rosen <pr...@lycos.de> wrote: >> >>> I am wondering, whether anyone made the possibly useless attempt, to >>> create a (MS-)DOS (and its old programs) compatible PC on a >>> Microcontroller by using its flash as harddisk? >> >> Sure. <http://www.jkmicro.com/products/products.html> (inter alia) > >Thanks Larwe. > >We've been making them since 1994. Our products >have flown on the Shuttle, the ISS, and several >low-earth sats. They've also tracked whales in >the Gulf of Mexico and measured shroud tension >on manned parachutes. Hardly useless. > >I'm quite sure that we were the first to do a >PC-compatible flash drive on an embedded controller. >The motivation was the frustration my wife and I >suffered working with the Ampro PC/104 MS/DOS >controllers of the time. >
Jim, Sounds like one hell of a good story there about how your idea turned into a solution, then how your solution turned into a product. And finally, how your product wound up in the space program. If you ever have time to put it down on paper, I'm sure I'm not the only one who'd be fascinated by it. Thanks! Tom
larwe wrote:
> On Oct 23, 1:08 pm, Paul Rosen <pr...@lycos.de> wrote: > >> I am wondering, whether anyone made the possibly useless attempt, to >> create a (MS-)DOS (and its old programs) compatible PC on a >> Microcontroller by using its flash as harddisk? > > Sure. <http://www.jkmicro.com/products/products.html> (inter alia) >
I agree! I have a couple of 80386 boards from JK Micro and found them to be of outstanding quality. They are good people to deal with. Jerry -- If replying, preform appendectomy on email address. --
"Jim Stewart" <jstewart@jkmicro.com> wrote in message 
news:mNGdnSSXn9j_y4PanZ2dnUVZ_uCinZ2d@omsoft.com...
> larwe wrote: >> On Oct 23, 1:08 pm, Paul Rosen <pr...@lycos.de> wrote: >> >>> I am wondering, whether anyone made the possibly useless attempt, to >>> create a (MS-)DOS (and its old programs) compatible PC on a >>> Microcontroller by using its flash as harddisk? >> >> Sure. <http://www.jkmicro.com/products/products.html> (inter alia) > > Thanks Larwe. > > We've been making them since 1994. Our products > have flown on the Shuttle, the ISS, and several > low-earth sats. They've also tracked whales in > the Gulf of Mexico and measured shroud tension > on manned parachutes. Hardly useless. > > I'm quite sure that we were the first to do a > PC-compatible flash drive on an embedded controller. > The motivation was the frustration my wife and I > suffered working with the Ampro PC/104 MS/DOS > controllers of the time. >
I was going to mention jkmicro.com in response to the original email - but thought it was not quite what the OP was meaning. The JK Micro boards I have use a DiskOnChip, rather than implementing a PC compatible system purely using the microcontrollers flash. AFAIK the DiskOnChip has a driver that makes it look like a driver, rather than what it actually is (flash). Is this the case? I too would recommend the JK Micro products. Having DOS on your embedded platform is more than convenient. -- Regards, Richard. + http://www.FreeRTOS.org 13 official architecture ports, 1000 downloads per week. + http://www.SafeRTOS.com Certified by T&#4294967295;V as meeting the requirements for safety related systems.
On Tue, 23 Oct 2007 13:15:30 -0700, Jim Stewart <jstewart@jkmicro.com>
wrote:

>>> I am wondering, whether anyone made the possibly useless attempt, to >>> create a (MS-)DOS (and its old programs) compatible PC on a >>> Microcontroller by using its flash as harddisk? >> >> Sure. <http://www.jkmicro.com/products/products.html> (inter alia) > >I'm quite sure that we were the first to do a >PC-compatible flash drive on an embedded controller.
Hello Jim, I do not really understand where this boards are good for. What can be done with them, that cannot be done with a single chip microcontroller? The intention of my original-posting question was to know, whether nowadays singlechip microcontrollers are able, to be a complete PC, at least the way as we had them in the beginning of the PCs and to run the old software on it. That means only ONE! microcontroller-chip with only some drivers or transistors to make the signals of the microcontroller strong enough to drive a floppy, a keyboard and a Hercules monitor. Your product needs additional chips beside the processor. Thus it cannot answer the question, whether a microontroller can be a complete PC. Because your product is the only one, which was mentioned here: Is it correct, that a PC on nowadays microcontrollers is not possible?
> The intention of my original-posting question was to know, whether > nowadays singlechip microcontrollers are able, to be a complete PC, at > least the way as we had them in the beginning of the PCs and to run > the old software on it. That means only ONE! microcontroller-chip with > only some drivers or transistors to make the signals of the > microcontroller strong enough to drive a floppy, a keyboard and a > Hercules monitor. > > Your product needs additional chips beside the processor. Thus it > cannot answer the question, whether a microontroller can be a complete > PC. Because your product is the only one, which was mentioned here: Is > it correct, that a PC on nowadays microcontrollers is not possible?
A PC is a *collection* of hardware with defined interfaces. There are some IO chips that place all these interfaces on one piece of silicon, but there still has to be compliance with instruction set, processor architecture, vector numbers, IO locations, IRQ, BIOS interface, etc. Otherwise it is not PC compatible. I think what I am saying is - I don't understand your question. -- Regards, Richard. + http://www.FreeRTOS.org 13 official architecture ports, 1000 downloads per week. + http://www.SafeRTOS.com Certified by T&#4294967295;V as meeting the requirements for safety related systems.