Re: [MiNT] CDROM drivers, desktops

[Jim DeClercq <jimd@panix.com>]

On Tue, 25 Nov 2003, Lonny Pursell wrote:

> on 11/25/03 7:52 PM, Jim DeClercq at jimd@panix.com wrote:
>
> > I am probably missing something simple. The latest version of
> > Extendos arrived today, and it does what it is supposed to do,
> > which is run, sort of, with MiNT. If I disable MINT.CFN, I get
> > the single TOS desktop with MiNT running, and a working CD
> > driver.
>
> If you can make it run from the auto folder, with the latest kernel
> and init.prg, please let me know how.  It all goes fine until init.prg
> starts and then the system dies.  Remove extendos, all is well again.
>
This is a really useful group. One on list reply, and one off
list reply, and I have extendos working two ways, although with
1.15.12 and whatever init.prg works with that.

I was reminded of the fact that extendos and MiNT are two
different things, so extendos can and must run after MiNT runs,
in order to find the file system. So it does work from the auto
folder, using the next-to-last kernel.

And, Thing can set memory to Super. So, probably, could flags, if
I knew the flag order. Once in the dimness of history, I found
the flag order, to set the fastload bit on a program that the CPX
did not handle, using the binary mode of Edith. I could not find
it again, and went through a bunch of .h files looking for it. In
some old version of gcc, there was an atari.h file with flag
order in it. But, this got done, and it does run from the
desktop.

Now, without changing the subject line, I followed the directions
in a paper by Guido Flohr, headed "Please read the following
important information!".  gcc -H -c hello.c produces no errors,
and a working a.out file. But my mshort directory is empty. gcc
finds all the files it needs, so far, so it is not a problem, but
why an mshort directory that is empty? This is the standard
EasyMiNT distribution.

Is this anything to worry about?

Jim