[Coco] deciding to code for OS/9

[Dave Philipsen]

A number of years ago I worked with a company and we created a control 
system that ran under OS9000 on a PC platform.  We had an 8-bit ISA bus 
card that was used to transmit hi speed data.  Instead of writing a 
driver for it we opted to access the device directly from the programs 
we had written.  OS9000 was handy for that because the system was 
modular.  We wrote several different programs and were able to 
communicate between them.  The system ended up in an entertainment venue 
in Las Vegas.  After OS9000 sort of died it was ported to Linux but by 
that time I had broken off my relationship with the company.

Dave


On 5/20/2016 2:00 PM, Barry Nelson wrote:
> Quote: whereas on OS9, you write it separately, or you don't write one and expect the OS (or the  user) to supply one.
>
> That is not completely true. It is possible for a user space program to access the hardware directly, it is just not the preferred method. For example, most programs that play audio under OS-9 through the CoCo's 6 bit D/A converter do so by outputting the data directly to that I/O port. Another example is my sdc program, it communicates directly with the CoCo SDC hardware, since the driver for the CoCo SDC only works when media is already mounted, and the sdc command needs to mount and unmount media. This is not the "correct" way to do things, but it can be done and does work.
>
>> Mathieu Bouchard matju at artengine.ca
>> Fri May 20 14:16:47 EDT 2016
>>
>> Running OS9 code isn't any slower than non-OS9 code, but you do lose
>> certain forms of flexibility. Whereas a plain CoCo app has to be
>> autonomous on many things and could expect to have total control of the
>> computer, an OS9 app needs to collaborate with a set of other programmes,
>> such as the kernel, the drivers, and the other apps. If you write a driver
>> for plain CoCo, you typically put it directly in your app, whereas on OS9,
>> you write it separately, or you don't write one and expect the OS (or the
>> user) to supply one.
>>
>> So, yeah, sort of DOS vs Windows, or DOS vs Linux, or DOS vs pretty much
>> anything else for that matter.
>