Re: deciding to code for OS/9
Quote: whereas on OS9, you write it separately, or you don't write one and expect the OS (or the user) to
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.
Coco mailing list
Coco <at> maltedmedia.com