[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Just my 2 penny worth..
NOTE: I'm not gonna reply to everyone else's replies; too many of 'em,
but I will address it all here.
>Wow! The MiNT mailing list hasn't been this active ever, from what I can
>remember, and that after about 3 years of hardly anything on it at all.
Nice to see you getting involved again.
I seem to remember your SCC is the only broken part in your TT?
Check out a shop specialized in surface-mount repairs and get it
sucked out and replaced by an AMD am85c30 or Zilog z85230.
You won't regret it! ;-)
>It's time for MiNT to become a fully fledged TOS compatible OS.
Perhaps now is a good time, indeed.
>This would only work, of course, on a 68020 + PMMU and above.
I don't mind. I think a CPU with PMMU should now be a minimum.
>Replacing the AHDI's of this world with internal hard disk drivers would
>allow MiNT to get over the bottleneck and restrictions of these external and
>variable quality drivers. Let's face it.. how many times has ICD changed
>their hard disk utilities and broken minixfs.xfs?
Here, I must point out that CBHD (freeware) and HD-Driver (commercial)
have completely eradicated AHDI and ICD. Both feature XHDI hard-disk
protocol, while the newest HD-Driver even has a built-in generic SCSI
driver that can be used to program drivers for SCSI-Ethernet and some
other more contemporary nicies.
I heartily recommend you purchase HD-Driver 7.53 and see for yourself.
Forget about AHDI and ICD. They're both long gone! ;-)
>"And what about the AES and GEM etc.?" I hear you ask.. well, that IS a
>problem. You could map the screen memory etc. into the processes memory
>map and allow them to control the hardware directly.
I really like this idea of virtual GEM screens you outline.
It would allow older apps that prefer the SingleTOS domain
to function on their own little console. I love it! ;-)
>(1) Forget about the old DOS drive labelling as the primary way of
> accessing disks. Instead allocate sub-trees of a UNIX-like mountable
> filesystem as virtual drive letters.
Hmm.... isn't that what we already do?
When I'm using GEM, I resort to DOS C:\path\to\app.prg, but most
of the time (espcially on vcons), I use Unix /dir/path/to/app
type of adressing. Unless I totally misunderstood?
> What's the advantage?
> Well, firstly you're not stuck with the size of a "drive" being the
> size of a physical disk or partition. Secondly, if you want to swap
> data from one physical drive to another you don't have to change all
> your paths, merely mount the new drive in the old one's place.
Ahhh! Well, yes, it's highly desirable.
>(2) A new exec format and exec scheme.
Hmm... how would older GEM apps still work?
> virtual memory system. And if you're going this far, why not make
> the system call interface fully POSIX compliant as well?
That would definitely be welcome.
> In fact, why not give the system a complete UNIX-a-Like programming
> interface with libraries to interface to all the TOS/GEM facilities
> you love and hate so that you can compile and run all your old
> source?
Agreed.
> And if you're going that far, you may as well do a Linux/68k system
> call emulation so that you can merely copy the binary from a Linux
> system onto MiNT and run it?
MiNT already IS designed for m68k hardware, so what's the point
of emulating anything? Wouldn't making MiNT fully POSIX allow
us to freely port Linux 68k stuff already?
>before you start shouting "But I don't want a Linux system on my Atari!"
hmmm.... opening a BIG can of worms here:
Over the last few months I've been subscribing to this list, I notice
two crowds:
1) "Whatever you do, KISS and able to run on my ST as an overlay (TSR)"
2) "Allright folks, let's give ourselves a fully POSIX thing that
can pass for a Linux 68k substitute with GEM on top"
Personally, if someone ever figures out an X clone that understands
GEM calls and runs on top on Linux 68k, so much for the better, as
my current platform is a well-equipped TT (I only consider my Stacy
as an "ST on the go" not a Unix workstation).
However, I think in the long term, unless we figure out a way to
make certain features as compiler-options (eg: if CPU >= 020 then
enable VM at compiling, etc.) then we might wanna keep MiNT as
a simple TSR, while focussing on a GEM/X clone that runs on both
MiNT and Linux 68k.
People who want the full monthy will naturally gravitate towards
Linux 68k anyways, but obviously, with all the STs out there, It's
becoming very clear that MiNT is the only Unix they can have, so
I suggest we keep it that way.
>I'd like to point out that I'm not proposing that.. what I am
>proposing is a new-age TOS system which is binary compatible with Linux.
>Its primary job will be to run TOS/GEM programs, even misbehaving ones,
>in a stable and protected way, but giving all the extra advantages that
>source and binary compatibility with the rest of the Open Source world
>gives you.
If someone succeeds, I'm in exctassy! ;-)
>Now, there will be another group of you moaning that this is all very well,
>but it won't work on a lowly 520ST.. and you'd be right.. a lot of this
>won't. However, a cut-down version of at least some of this would.
Read my comment above, about compiling options, versus PMMU.
>Integrating the disk hardware device drivers into the kernel would help
>the 68000 people as much as it would the rest of the community.
I have read all further replies to this thread, but cannot understand
that particular part. Please examplify?
***
NOTE: The TT allows direct access to TT-Ram using DMA, so Steve's
idea that HD-drivers should be able to perform faster on
the TT is correct (this only works on the SCSI bus, however;
ACSI is still blocking non-DMA, AFAIK).
The Falcon is far more limited over this aspect, as it's 100%
ST-ram based. ask Sven or Uwe Seimet, there's been plenty of
details about this, over this mailing list and on newsgroups.
>Your job, if you wish to take it, is to implement the new MiNT. This message
>will self destruct in 5 seconds. Good Luck Jim^H^H^HMiNT-list
^^^
Good luck Steve! ;-)
----------------------------------------------------------------
Martin-Eric Racine The Atari TT030 Homepage with FAQ
FUNKYWARE CREATIONS inc. http://members.tripod.com/~TT030/
----------------------------------------------------------------