Current status of MagiC

12 views
Skip to first unread message

Jo Even Skarstein

unread,
Oct 15, 2007, 6:39:49 AM10/15/07
to
It looks like the latest version of MagiC is 6.20, which is six years old
by now. Does anybody have any news, heard any rumours or something? Is
MagiC abandoned?

--

/*
** Jo Even Skarstein http://joska.nvg.org/
*/

Guillaume Tello

unread,
Oct 15, 2007, 7:21:20 AM10/15/07
to

"Jo Even Skarstein" <jo...@nvg.ntnu.no> a écrit dans le message de news:
fevg1l$ve8$1...@orkan.itea.ntnu.no...

> It looks like the latest version of MagiC is 6.20, which is six years old
> by now. Does anybody have any news, heard any rumours or something? Is
> MagiC abandoned?

And if so... Are the sources available somewhere?

Guillaume.


Message has been deleted

Jo Even Skarstein

unread,
Oct 15, 2007, 3:38:50 PM10/15/07
to
lp <gfa-...@mint.net> wrote:

> See entry #6 regarding sources, posted by Andreas Kromke

Not very encouraging. So MagiC really is dead then. A pity - no more OS
flamewars on csas ;-)

Fidel-Sebastian Hunrichse-Lara

unread,
Oct 16, 2007, 12:09:00 AM10/16/07
to
Salve commonly, Jo Even Skarstein <jo...@nvg.ntnu.no> wrote:

> So MagiC really is dead then.

Don't tell it to my MagiC v6.20 R3... ;->

Saluti-gerulus

--
*"If this were a dictatorship, it'd be a heck of a lot easier, just so*
*long as I'm the dictator."* G.W. Bush <http://www.brunnenvergifter.de>
#Investigations between ratio and paranoia#

Message has been deleted

Jo Even Skarstein

unread,
Oct 16, 2007, 6:36:20 AM10/16/07
to
Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian...@b.maus.de> wrote:

> > So MagiC really is dead then.

> Don't tell it to my MagiC v6.20 R3... ;->

What's R3? An update to 6.20? I'm interested in aquiring MagiC for my
Milan, but I'm *not* interested in paying ASH 100 euros for a product that
has no support and has not been updated since 2001...

Jo Even Skarstein

unread,
Oct 16, 2007, 6:39:42 AM10/16/07
to
lp <gfa-...@mint.net> wrote:

> > Not very encouraging. So MagiC really is dead then. A pity - no more OS
> > flamewars on csas ;-)

> I was told the same thing about gfa-basic when I inquired with the company,
> they also said "the source code is 100% assembler and not commented". If
> that is true of magic, simply run it through TTDigger like I did, and you
> got the sources. Then start fixing things. ;-)

That is certainly an option - if you're a mad genious or have a crack
addiction ;-) I did some fixes to ST-Guide this way, I have absolutely no
intentions of doing this to a binary 10 times bigger.

Gerhard Stoll

unread,
Oct 16, 2007, 12:35:00 AM10/16/07
to
> MagiC is 6.20

This is the latest version. I read in april 2007 that Andreas Kromke work on a
MagiCMac X 2.

MagiC is *not free* and sourcecode is not available. Yon can always buy it by
ASH.

Gerhard

Uwe Seimet

unread,
Oct 16, 2007, 2:04:18 PM10/16/07
to
Jo Even Skarstein wrote:

> What's R3? An update to 6.20? I'm interested in aquiring MagiC for my
> Milan, but I'm *not* interested in paying ASH 100 euros for a product that
> has no support and has not been updated since 2001...

Looks like MiNT is what you should use in this case. In this case you
even have the advantage of the sources being available.

--
-----------------------------------------------------------------------
Dr. Uwe Seimet http://www.linkbylink.net/

Fidel-Sebastian Hunrichse-Lara

unread,
Oct 16, 2007, 2:10:00 PM10/16/07
to
Salve commonly, Jo Even Skarstein <jo...@nvg.ntnu.no> wrote:

> What's R3?

Revision 3...

> An update to 6.20?

Not really! It's simply MM v6.1.5 with MagiC v6.20 from 2.10.2000...

> I'm interested in aquiring MagiC for my Milan, but I'm *not* interested
> in paying ASH 100 euros for a product that has no support and has not
> been updated since 2001...

For what do you need support? MagiC usually works, as it should...

GokMasE

unread,
Oct 16, 2007, 5:05:57 PM10/16/07
to
On Oct 16, 8:04 pm, Uwe Seimet <Uwe.Sei...@seimet.de> wrote:
> Looks like MiNT is what you should use in this case. In this case you
> even have the advantage of the sources being available.

Yep, I agree. For those who got something faster than an 8mhz Atari
with >4mb of RAM, FreeMiNT is probably the best bet.

If nothing else, do consider encouraging Ozk, Frank and the other
FreeMiNT developers by *using* the stuff they put down efforts into
supplying to the community! The remainings of the platform will only
last for as long as ppl still find it rewarding enough to keep on
writing software, making demos, chip music - well, doing whatever! -
with their Ataris :)

Regards,

/Joakim

Jo Even Skarstein

unread,
Oct 16, 2007, 5:25:00 PM10/16/07
to
Uwe Seimet <Uwe.S...@seimet.de> wrote:

> Looks like MiNT is what you should use in this case. In this case you
> even have the advantage of the sources being available.

I have been a MiNT-user since 1996. I want to test my own software under
MagiC though, and while I do have MagiC 6.0x on my TT I can't use it as I
don't have any space for other computers than my Milan.

Jo Even Skarstein

unread,
Oct 16, 2007, 5:27:57 PM10/16/07
to
Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian...@b.maus.de> wrote:

> > in paying ASH 100 euros for a product that has no support and has not
> > been updated since 2001...

> For what do you need support? MagiC usually works, as it should...

There is no such thing as a bug free piece of software, and for 100 euros
I expect at least some bugfixes. Also, there's a lot of new stuff being
added to XaAES and MyAES now, if these are not added to MagiC in the
future there is no point in developing software for it.

calimero

unread,
Oct 17, 2007, 4:31:52 AM10/17/07
to

Fidel-Sebastian Hunrichse-Lara

unread,
Oct 17, 2007, 12:36:00 AM10/17/07
to
Salve commonly, Jo Even Skarstein <jo...@nvg.ntnu.no> wrote:

> Also, there's a lot of new stuff being added to XaAES and MyAES now, if
> these are not added to MagiC in the future there is no point in
> developing software for it.

For a normal MagiC-user it's not interesting if a lot of new stuff is
being added to XaAES or MyAES but rather if it runs under MagiC!
Whatever happens with XaAES or MyAES doesn't concern me...

Fidel-Sebastian Hunrichse-Lara

unread,
Oct 17, 2007, 12:41:00 AM10/17/07
to
Salve commonly, Jo Even Skarstein <jo...@nvg.ntnu.no> wrote:

> I want to test my own software under MagiC though, and while I do have
> MagiC 6.0x on my TT I can't use it as I don't have any space for other
> computers than my Milan.

You know that MagiC often behaves differently as on original hardware?

Jo Even Skarstein

unread,
Oct 17, 2007, 6:45:17 AM10/17/07
to
Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian...@b.maus.de> wrote:

> > I want to test my own software under MagiC though, and while I do have
> > MagiC 6.0x on my TT I can't use it as I don't have any space for other
> > computers than my Milan.

> You know that MagiC often behaves differently as on original hardware?

I know that MagiCMilan differs from MagiC on original hardware, but I
thought that was only at the hardware-level? From the application's point
of view these systems should be identical, right?

Jo Even Skarstein

unread,
Oct 17, 2007, 6:49:29 AM10/17/07
to
Fidel-Sebastian Hunrichse-Lara <Fidel-Sebastian...@b.maus.de> wrote:

> > Also, there's a lot of new stuff being added to XaAES and MyAES now, if
> > these are not added to MagiC in the future there is no point in
> > developing software for it.

> For a normal MagiC-user it's not interesting if a lot of new stuff is
> being added to XaAES or MyAES but rather if it runs under MagiC!
> Whatever happens with XaAES or MyAES doesn't concern me...

The point is that stuff written to take advantage of the new features in
XaAES/MyAES won't work on MagiC. In that sense developments in XaAES and
MyAES will affect MagiC-users in the future. Currently there's only minor
things that differs MagiC and XaAES (XaAES supports nearly everything in
MagiC now, and adds some new features as well), but that will add up in
the future.

Fidel-Sebastian Hunrichse-Lara

unread,
Oct 17, 2007, 11:09:00 AM10/17/07
to
Salve commonly, Jo Even Skarstein <jo...@nvg.ntnu.no> wrote:

> The point is that stuff written to take advantage of the new features
> in XaAES/MyAES won't work on MagiC.

That's really nothing new...

> In that sense developments in XaAES and MyAES will affect MagiC-users
> in the future.

That's IMHO since MINT previosly reported...

> Currently there's only minor things that differs MagiC and XaAES (XaAES
> supports nearly everything in MagiC now, and adds some new features as
> well), but that will add up in the future.

The Great Shism between MagiC and MINT is long ago a matter of fact...

Fidel-Sebastian Hunrichse-Lara

unread,
Oct 17, 2007, 10:55:00 AM10/17/07
to
Salve commonly, Jo Even Skarstein <jo...@nvg.ntnu.no> wrote:

> From the application's point of view these systems should be identical,
> right?

Nope! MagiC is on non-original hardware significantly more tolerantly
than on original hardware! Therefore MagiC is on non-original hardware
IMHO absolutly inappropriate for developers - as the only one...

Fidel-Sebastian Hunrichse-Lara

unread,
Oct 17, 2007, 10:55:00 AM10/17/07
to
Salve commonly, Jo Even Skarstein <jo...@nvg.ntnu.no> wrote:

> From the application's point of view these systems should be identical,
> right?

Nope! MagiC is on non-original hardware significantly more tolerantly

than on original hardware! Therefore MagiC is on non-original hardware

IMHO absolutely inappropriate for developers - as the only one...

Guillaume Tello

unread,
Oct 17, 2007, 12:30:20 PM10/17/07
to

"Fidel-Sebastian Hunrichse-Lara" <Fidel-Sebastian...@b.maus.de>
a écrit dans le message de news: 200710171...@b.maus.de...

> Salve commonly, Jo Even Skarstein <jo...@nvg.ntnu.no> wrote:
>
>> The point is that stuff written to take advantage of the new features
>> in XaAES/MyAES won't work on MagiC.
>
> That's really nothing new...

Sure but with the MagiC sources, some improvements made to XaAES and
MyAES could be ported to MagiC, just for compatibility.

Guillaume.


Uwe Seimet

unread,
Oct 17, 2007, 2:11:18 PM10/17/07
to
Guillaume Tello wrote:

> Sure but with the MagiC sources, some improvements made to XaAES and
> MyAES could be ported to MagiC, just for compatibility.

Considering that the MagiC sources are in assembler and the MiNT sources
are in C you would have to rewrite everything in assembler. I think that
when Andreas Kromke says that understanding MagiC's assembler code is
very difficult (or something similar) he is serious.

One should not assume that simply by releasing the sources of such a
project others will be able to maintain these sources. One must at least
have an excellent knowledge of the problem domain. In the case of MagiC
one would have to have an excellent knowledge of assembler programming,
of operating systems in general and of the details in the specifications
released for TOS, the AES, VDI etc. My guess is that most of those still
writing software for the Atari do not even have a complete set of valid
specifications.

Martin Elsässer

unread,
Oct 17, 2007, 2:32:00 AM10/17/07
to
Hallo Gerhard,

>This is the latest version. I read in april 2007 that Andreas Kromke
>work on a MagiCMac X 2.

That's true. The new MagiCMacX 2 is a new emulator, but the MagiC in this
emulator is the well known MagiC 6.2 as in MagiCMacX 1.2.

Gruß

Martin [PGP-Key available]

Jo Even Skarstein

unread,
Oct 18, 2007, 3:20:46 AM10/18/07
to
Uwe Seimet <Uwe.S...@seimet.de> wrote:

> One should not assume that simply by releasing the sources of such a
> project others will be able to maintain these sources. One must at least
> have an excellent knowledge of the problem domain. In the case of MagiC
> one would have to have an excellent knowledge of assembler programming,
> of operating systems in general and of the details in the specifications
> released for TOS, the AES, VDI etc. My guess is that most of those still
> writing software for the Atari do not even have a complete set of valid
> specifications.

Ozk would be the ideal person to do this, but he's not interested in MagiC
at all ;-)

Didier Méquignon

unread,
Oct 18, 2007, 11:42:05 AM10/18/07
to
Jo Even Skarstein <jo...@nvg.ntnu.no> wrote:

I can do this task, 68K assembler is not a problem for me.
I remember to post here an answer about a MagiC thread of Andreas (some
years old).
My last task was to rewrite the the main part of the VDI in 68K/Coldfire
assembler (who use fVDI C routine and Radeon C driver).
And I think I have also build the biggest program in assembler for
Atari...Aniplayer.

Regards,

Didier.
--
Didier MEQUIGNON Aniplayer download: http://aniplay.atari.org
CT60 package download: http://ct60conf.atari.org
CTPC I : http://ctpci.atari.org

Uwe Seimet

unread,
Oct 18, 2007, 1:44:59 PM10/18/07
to
Didier Méquignon wrote:

> My last task was to rewrite the the main part of the VDI in 68K/Coldfire
> assembler (who use fVDI C routine and Radeon C driver).
> And I think I have also build the biggest program in assembler for
> Atari...Aniplayer.

Is it bigger than the text program TempusWord, which immediately comes
to my mind when thinking about big programs written in assembler?

Do you think somebody else would be able to maintain your assembler
sources, fix bugs and add new features?
Maintaining software like MagiC may be particularly difficult. Not only
because the author says so, but also because software that works on a
very low level, in the case of MagiC the operating system itself, is
hard to debug. Additionally one must have access to all the officially
supported hardware (ST, TT, Falcon, Milan) in order to ensure that new
versions still run on all platforms. And one needs beta testers willing
to risk losing their data if. Bugs in operating systems - and hard disk
drivers ;-) - can cause serious problems.

Guillaume Tello

unread,
Oct 18, 2007, 2:09:25 PM10/18/07
to

"Uwe Seimet" <Uwe.S...@seimet.de> a écrit dans le message de news:
5npkcrF...@mid.individual.net...

> Didier Méquignon wrote:
>
>> My last task was to rewrite the the main part of the VDI in 68K/Coldfire
>> assembler (who use fVDI C routine and Radeon C driver).
>> And I think I have also build the biggest program in assembler for
>> Atari...Aniplayer.
>
> Is it bigger than the text program TempusWord, which immediately comes to
> my mind when thinking about big programs written in assembler?
>
> Do you think somebody else would be able to maintain your assembler
> sources, fix bugs and add new features?

I think that Didier can do it.
In my opinion, you don't have to understand the whole program to add
something. For example, I have disassembled the SUPERCHARGER software
(driver for the DMA hard PC emulator), and I'm really not good at DMA
transferts, etc... But I changed lots of things to adapt it to my NOVA card
and to get the Hercules resolution. I changed what I understood.

> versions still run on all platforms. And one needs beta testers willing to
> risk losing their data if. Bugs in operating systems - and hard disk
> drivers ;-) - can cause serious problems.

For this, you're totaly right, a beta OS can be dangerous! Well, this
can be done by booting from a ZIP drive, or from a floppy and "hiding" the
other partitions you want to preserve.
But MagiC looks to me as a very good program, easy to install and with
good performances, it's a pity to let it behind with no improvements.

Guillaume.


Jean-François Lemaire

unread,
Oct 18, 2007, 2:52:22 PM10/18/07
to
On Thursday 18 October 2007 20:09, Guillaume Tello wrote:

[...]

> But MagiC looks to me as a very good program, easy to install and
> with
> good performances, it's a pity to let it behind with no improvements.

Wouldn't efforts be best spent on FreeMiNT, a free and time-proven OS,
to make it faster (if possible, it's already pretty fast) and easier to
install and more compatible with MagiC so that current MagiC users will
be motivated to switch to FreeMiNT knowing that their programs will run
in the same manner as under MagiC? As someone already said in this
thread, XaAES is already very close, AES-wise, to MagiC).

Well, just my 2 cents, as the expression goes.

JFL
--
Jean-François Lemaire

Uwe Seimet

unread,
Oct 19, 2007, 2:12:49 AM10/19/07
to
Jean-François Lemaire wrote:

> Wouldn't efforts be best spent on FreeMiNT, a free and time-proven OS,

I also think so, even though I have preferred MagiC. But as far as
maintenance is concerned one needs much less time to improve software
with its sources available (most of it in C I think, not in assembler)
than it takes to work on undocumented assembler code.

OL

unread,
Oct 19, 2007, 3:19:30 AM10/19/07
to
On 18 oct, 17:42, NOSP...@wanadoo.fr (Didier Méquignon) wrote:
> Jo Even Skarstein <jo...@nvg.ntnu.no> wrote:
>

Hello Didier

I think better should be to have source code of NVDI rather than Magic
because if fVDI is enough good, this software does not support
printing support at all and we have no substitue of speedogdos
unfortunatly.

Olivier

Jo Even Skarstein

unread,
Oct 19, 2007, 6:46:38 AM10/19/07
to
Jean-François Lemaire <jfle...@skynet.be> wrote:

> Wouldn't efforts be best spent on FreeMiNT, a free and time-proven OS,
> to make it faster (if possible, it's already pretty fast) and easier to
> install and more compatible with MagiC so that current MagiC users will
> be motivated to switch to FreeMiNT knowing that their programs will run
> in the same manner as under MagiC? As someone already said in this
> thread, XaAES is already very close, AES-wise, to MagiC).

I'm using FreeMiNT with XaAES now, and speedwise it's already very good.
Compatibility to MagiC is also good (wdialog implemented, pdlg
implemented, all RSC objects from MagiC is supported). Stability is very
good. So on these points I don't see any benefit in using MagiC, unless
you want to use software that absolutely requires MagiC. There are some
things in MagiC that I don't see coming in MiNT/XaAES, like AES threads.

Also, some things are just different between MagiC and MiNT/XaAES, and
changing this in XaAES would break existing apps one way or the other.

- Should there be a limit on the number of windows in XaAES (there is in
MagiC).
- Should MiNT be changed to allocate pid's the same way MagiC does? MagiC
re-use slots in the pid-list, MiNT doesn't. This means that under MagiC,
when you exit application one and then start application two, application
two will have the same pid as application one has. I had to change a lot
of internal structures in Taskbar when I adapted it to MagiC a few years
ago because of this.
- Should we limit the number of running accessories under XaAES?
- Should there be a MaGX-cookie installed when running MiNT/XaAES.
- Should the special SM_M_SPECIAL messages be supported, including
emulating the bugs which you need to work around when using these?

Any application that makes any assumptions about such conditions will
break under XaAES, to get these to work you'll basically have to make
XaAES a clone of MagiC, including all of it's limitations. This is why
it's very difficult to be able to run all applications properly under
XaAES. Most will work, as they look for the features they use and not
their prefered OS.

I do see the point in having a simple installer that focus purely on the
GEM/desktop side of MiNT/XaAES though. EasyMiNT is a very good
distribution with a very smooth and nice installer, but it's probably to
unix-biased for most MagiC users.

OL

unread,
Oct 19, 2007, 8:40:35 AM10/19/07
to
Hello Jo

Just for be a defender of Magic I just want to said you speak as an
developer under Mint like me, but as any developers we write in
function of our system configuration, we not remember problems we have
find during our work, but we are very disappointed if we need do some
changed on an other system due to a limitation, this is human but
generally not very objective.
I have start write some software on an old STf, I stop for a time and
after some years I bought MagicMac, really all my work was near need
to rewrite! After a time all work correctly, and I have pass a lot of
time to fix last bugs when I try to run my software on real hardware!
One day I start writing MyAES (how crazy I was!), I do the kernel, I
plane only it work on multitask system and I have imagine a very
beautiful scheme for stop and start process, with very low time
consumption, using Signal of Mint, it work marvelous on Magic at the
first time, I was very happy! On day (this was not public), I have
start to work on Mint, I can't imagine that my use of signals can't
work on Mint :-( simply because under signal I can't use during signal
interupt any gemdos function (here Pkill()), I have need to rewrite.
No system is perfect!


Olivier

Jo Even Skarstein

unread,
Oct 19, 2007, 9:13:48 AM10/19/07
to
OL <o...@lutece.net> wrote:

> beautiful scheme for stop and start process, with very low time
> consumption, using Signal of Mint, it work marvelous on Magic at the
> first time, I was very happy! On day (this was not public), I have
> start to work on Mint, I can't imagine that my use of signals can't
> work on Mint :-( simply because under signal I can't use during signal
> interupt any gemdos function (here Pkill()), I have need to rewrite.
> No system is perfect!

This is exactly my point :-) Like I said, I had to rewrite some key parts
of Taskbar when I ported it to MagiC as MagiC allocated pids differently
than MiNT. However, neither MagiC nor MiNT is "wrong" - both methods are
correct implementations of the specifications. There is no rule that says
that you can't re-use available pids until they roll over from 999 to 0 -
I made an assumption when I originally designed this code and had to pay
for that later.

Unfortunately there are lots of such differences between MagiC and
MiNT/XaAES, and if an application makes any assumptions about
non-documented behaviour it's difficult to support such applications under
any other OS than the one it was originally developed for.

OL

unread,
Oct 19, 2007, 9:51:11 AM10/19/07
to

Oh yes, but most of time there is bugs in software, for example in
past version of Kronos I have a trouble in a new xaaes version, xaaes
killed it when I start opengl tests, as I remember it was link to an
action I done on a windows that not exist! In all AES, when you try to
do this the function return 0 that's all, in xaaes they prefer kill
application! This was a bug of Kronos, now it's fixed!.

Olivier

Jean-François Lemaire

unread,
Oct 19, 2007, 11:16:16 AM10/19/07
to
On Friday 19 October 2007 15:13, Jo Even Skarstein wrote:

[...]

> Unfortunately there are lots of such differences between MagiC and
> MiNT/XaAES, and if an application makes any assumptions about
> non-documented behaviour it's difficult to support such applications
> under any other OS than the one it was originally developed for.

So the moral of the story is: "programmers should never make any
assumptions about non-documented behaviours" :-)

JFL
--
Jean-François Lemaire

Didier Méquignon

unread,
Oct 19, 2007, 12:00:48 PM10/19/07
to
Uwe Seimet <Uwe.S...@seimet.de> wrote:

> Didier Méquignon wrote:
>
> > My last task was to rewrite the the main part of the VDI in 68K/Coldfire
> > assembler (who use fVDI C routine and Radeon C driver).
> > And I think I have also build the biggest program in assembler for
> > Atari...Aniplayer.
>
> Is it bigger than the text program TempusWord, which immediately comes
> to my mind when thinking about big programs written in assembler?

There are 2,6 MB of sources with an average of just 3 spaces / line.



> Do you think somebody else would be able to maintain your assembler
> sources, fix bugs and add new features?
> Maintaining software like MagiC may be particularly difficult. Not only
> because the author says so, but also because software that works on a
> very low level, in the case of MagiC the operating system itself, is

Since one year I have also a TOS404 with lot of low level part rewrited
for the Coldfire (it's a Falcon clone with a Radeon but there always
some problems with thr CF68KLIB). Before I have already patched the TOS
and MagiC who runs on the CT60. The Coldfire TOS boot also on a Compact
Flash without driver ;-), the Radeon boot screen is selected by a
Setscreen, there are a list up new modes selectable by a CPX (actually
1280 x 1024 x 16M), like the VDI. The XBIOS, BIOS, and VDI are rewrited
in assembler (and C for the VDI with fVDI sources), the GEMDOS is
replaced by BDOS where I have add SLB functions. There are also FreeRTOS
(an embbeded OS) with a TCIP stack lwIP with a Telnet, TFTP, HTTP
servers, (the TOS is just a TASK) and since his week I use also a
Gluestik part (always in Flash !) tested with AFTP.
The story is here: http://ctpci.atari.org but i'ts not updated since
some months :-(
If I had the sources of MagiC, you can imagine a new TOS machine with
MagiC in Flash. Actually there a just one TSR program actually
disabled... MiNT!
Since more than 20 years I know, and I write in assembler, 6502, 6809,
68000, 68030, 68060, Coldfire and a little bit PPC at factory. I use
only C langage since 15 years, and also since 6 years at factory where I
write drivers and systems parts for VME boards (68K and PPC) on
multitasking embbeded OS pSOS. My last project is on a Phytec board with
a Coldfire ;-) like at home excepted than is a M6484LITE from Freescale.

So I said... I can do this job. Maybe it's that last chance for MagiC.

> hard to debug. Additionally one must have access to all the officially
> supported hardware (ST, TT, Falcon, Milan) in order to ensure that new
> versions still run on all platforms. And one needs beta testers willing
> to risk losing their data if. Bugs in operating systems - and hard disk
> drivers ;-) - can cause serious problems.

Regards,

Message has been deleted

Jo Even Skarstein

unread,
Oct 19, 2007, 3:18:36 PM10/19/07
to
OL <o...@lutece.net> wrote:

> Oh yes, but most of time there is bugs in software, for example in
> past version of Kronos I have a trouble in a new xaaes version, xaaes
> killed it when I start opengl tests, as I remember it was link to an
> action I done on a windows that not exist! In all AES, when you try to
> do this the function return 0 that's all, in xaaes they prefer kill
> application! This was a bug of Kronos, now it's fixed!.

Yes, but that's not so easy to do with applications you don't have the
sources for ;-)

Henk Robbers

unread,
Oct 19, 2007, 7:25:33 PM10/19/07
to

I can imagine that :-) I wouldnt be either.
His work has made MagiC de facto obsolete.
Mint/XaAES is the future of Atari GEM.

Besides that, the original TOS x.06 remains to be simple
and usable if you only need 1 program at a time.

I personally only consider single TOS and XaAES as target OS's
for my programs.

--
Groeten; Regards.
Henk Robbers. http://members.chello.nl/h.robbers
Interactive disassembler: TT-Digger; http://digger.atari.org
A Home Cooked teXt editor: AHCX

Henk Robbers

unread,
Oct 19, 2007, 7:36:14 PM10/19/07
to

Yeah, yeah. And in pre MiNT and pre MagiC times this was
half of all the fun on Ataris. :-)

Jo Even Skarstein

unread,
Oct 20, 2007, 6:02:01 AM10/20/07
to
Henk Robbers <h.ro...@chello.nl> wrote:

> > So the moral of the story is: "programmers should never make any
> > assumptions about non-documented behaviours" :-)

> Yeah, yeah. And in pre MiNT and pre MagiC times this was


> half of all the fun on Ataris. :-)

Indeed. My favourite was to use self-modifying code to speed up my
graphics routines - I got into serious trouble when I got my first 030 ;-)

samf

unread,
Oct 20, 2007, 12:32:35 PM10/20/07
to
Jo Even Skarstein wrote:
> Henk Robbers <h.ro...@chello.nl> wrote:
>
>>> So the moral of the story is: "programmers should never make any
>>> assumptions about non-documented behaviours" :-)
>
>> Yeah, yeah. And in pre MiNT and pre MagiC times this was
>> half of all the fun on Ataris. :-)
>
> Indeed. My favourite was to use self-modifying code to speed up my
> graphics routines - I got into serious trouble when I got my first 030 ;-)
>
I for one would love to see continued developement of Magic! It is
always nice to have more than one choice of os's, or to be able to run
both, setting up the falcon to be dual boot! :)

PeP

unread,
Oct 21, 2007, 5:50:46 AM10/21/07
to
> For a normal MagiC-user it's not interesting if a lot of new stuff is
> being added to XaAES or MyAES but rather if it runs under MagiC!
> Whatever happens with XaAES or MyAES doesn't concern me...

Personally, I've dropped support for MagiC in my stuff, since
supporting MagiC often means *not* being able to use features present
in modern AESs, thus not encouraging further development. It's also
very difficult to support MagiC since it's not designed the way Atari
originally intended.

Think if it this way. You most likely want new software for your
machine.
If you don't support the active developers, why should they support
you?


-- Peter

Fidel-Sebastian Hunrichse-Lara

unread,
Oct 22, 2007, 6:25:00 AM10/22/07
to
Salve commonly, PeP <pep.fi...@gmail.com> wrote:

> It's also very difficult to support MagiC

Maybe for MINT-user/supporter but not for MagiC-user/supporter...

> it's not designed the way Atari originally intended.

Atari intend something? Really? How long since?

> If you don't support the active developers, why should they support you?

I support active developers and all of them develop under MagiC...

PeP

unread,
Oct 22, 2007, 3:21:15 PM10/22/07
to
> > It's also very difficult to support MagiC
> Maybe for MINT-user/supporter but not for MagiC-user/supporter...

I think you misinterpreted my post. My point was, that if you are a
programmer (like me) and would like to actively support recent
development in the AES, it gets more difficult to support obsolete
systems such as MagiC and Geneva, since they are nolonger being
updated.

> > it's not designed the way Atari originally intended.
> Atari intend something? Really? How long since?

Yes. And they've documented it thoroughly in their developer
documentation. The physical manifestation of it all is called "TOS",
"MultiTOS" and "AES". Programmers have picked up the very same code
that Atari used for this stuff and developed it further, the result is
called FreeMiNT. The last version of the FreeMiNT kernel and it's
standard AES (called XaAES) was relased 2006-09-27, and a new version
is coming soon. When was the last update of MagiC?

> > If you don't support the active developers, why should they support you?
> I support active developers and all of them develop under MagiC...

No, that's not the case. Many of them don't, since MagiC has become
outdated. Most of them *try* to stay compatible with MagiC, however.
That's a completely different thing.

-- Peter

GokMasE

unread,
Oct 22, 2007, 3:36:21 PM10/22/07
to
On Oct 22, 9:21 pm, PeP <pep.fishmo...@gmail.com> wrote:

> No, that's not the case. Many of them don't, since MagiC has become
> outdated. Most of them *try* to stay compatible with MagiC, however.
> That's a completely different thing.

Indeed, that is a very important difference. That is certainly true in
the case of AtarICQ, at least until now.

Btw, some FreeMiNT developers are pretty active too (compared to
average Atari coding activity), and I bet my ass they don't develop
under MagiC...


Regards,

/Joakim

Matthias Arndt

unread,
Oct 23, 2007, 6:05:01 AM10/23/07
to
PeP schrieb:

>>> it's not designed the way Atari originally intended.
>> Atari intend something? Really? How long since?
>
> Yes. And they've documented it thoroughly in their developer
> documentation. The physical manifestation of it all is called "TOS",
> "MultiTOS" and "AES". Programmers have picked up the very same code
> that Atari used for this stuff and developed it further, the result is
> called FreeMiNT. The last version of the FreeMiNT kernel and it's
> standard AES (called XaAES) was relased 2006-09-27, and a new version
> is coming soon. When was the last update of MagiC?

Exactly the point on this discussion. If you stick to what TOS and MinT
do define, you clearly follow what Atari intended back then. Maybe their
MultiTOS wasn't the most perfect way to implement this API but it did work.

A vote for Single TOS compatibility at this point! :D

cheers,
Matthias
--
Matthias Arndt <mar...@asmsoftware.de> <matthia...@tu-clausthal.de>
PGP-Key: http://www.asmsoftware.de/marndt.pgp ICQ: 40358321
>>> Jabber: simons...@jabber.ccc.de <<<

Gerhard Stoll

unread,
Oct 23, 2007, 12:32:00 PM10/23/07
to
GokMasE <gok...@gmail.com> worte:

> some FreeMiNT developers are pretty active too (compared to average
> Atari coding activity), and I bet my ass they don't develop under
> MagiC...

I work only with MagiC [1] or do you mean that they work on FreeMiNT? OK, my
last entrie to FreeMiNT (COPS) is from the 2006-03-12, cflib is form the
2007-05-19.

But from Smurf is 2007-10-14. ;-)

I develop programs for Ataris and I try to fix problems with MagiC,FreeMiNT or
TOS. Why should I exclude someone, there are so few users.

Gerhard, and now I go on to work on two programs which need MagiC. :-)

[1] FreeMiNT is only good for CVS, but some tell me that this works also with
MagiCNet.

PeP

unread,
Oct 23, 2007, 4:31:00 PM10/23/07
to
> I develop programs for Ataris and I try to fix problems with MagiC,FreeMiNT or
> TOS. Why should I exclude someone, there are so few users.

A good point.

> Gerhard, and now I go on to work on two programs which need MagiC. :-)

Which sort of contradicts that first point!

> [1] FreeMiNT is only good for CVS, but some tell me that this works also with
> MagiCNet.

Now that's silly but you get away with it. This time. :-)

Gerhard Stoll

unread,
Oct 24, 2007, 9:24:00 AM10/24/07
to
> Which sort of contradicts that first point!

I get some sourcecode from a programmer, who make this between 1998 and 2000.
So he use the thread and the editable object from MagiC.

I think it is better to release this source, instead of delete them.

> Now that's silly but you get away with it.

Why is that silly? The problem is that I can use only FreeMiNT 1.15.12. With
newer version are problems with VFAT32 and CVS. I won't wast my time in testing
all applictions I have if they run with FreeMiNT 1.16.x or not.

Gerhard

PeP

unread,
Oct 24, 2007, 12:04:19 PM10/24/07
to
> I get some sourcecode from a programmer, who make this between 1998 and 2000.
> So he use the thread and the editable object from MagiC.

> I think it is better to release this source, instead of delete them.

Fair enough.

> > Now that's silly but you get away with it.

> Why is that silly?

You said that FreeMiNT is only good for CVS. I took that as a joke,
since I've been using it for everything the last 2 years.

> The problem is that I can use only FreeMiNT 1.15.12. With
> newer version are problems with VFAT32 and CVS. I won't wast my time in testing
> all applictions I have if they run with FreeMiNT 1.16.x or not.

I'm using CVS and VFAT32 without problems, but it's possible that
there are some trouble with it, perhaps in combination with MagiCs
implementation of it. Can't someone test your stuff with the new
kernel version? After all, it is the only Atari OS that is still being
actively maintained...

-- Peter

Uwe Seimet

unread,
Oct 25, 2007, 2:01:59 PM10/25/07
to
Matthias Arndt wrote:

> Exactly the point on this discussion. If you stick to what TOS and MinT
> do define, you clearly follow what Atari intended back then. Maybe their
> MultiTOS wasn't the most perfect way to implement this API but it did work.

I think that what Atari intended is irrelevant. Relevant is everything
the users want.

Uwe Seimet

unread,
Oct 25, 2007, 2:03:30 PM10/25/07
to
Gerhard Stoll wrote:

> [1] FreeMiNT is only good for CVS, but some tell me that this works also with
> MagiCNet.

As long as the CVS repository is on the same machine as the checked out
files CVS also works with MagiC and FAT32 partitions. This is what I use
for maintaining my sources.

Edward S. Baiz Jr.

unread,
Nov 4, 2007, 4:24:12 AM11/4/07
to

Yeah, I agree. There are many more nice programs for Mint, then for Magic.
Right now I use mainly Magic on my Falcon, but I will change to Mint as soon
as I get my CT63 upgrade. Too bad about Magic though. It is a great OS and
just needs a BIG upgrade that, for now, will never come.

--
Edward S. Baiz Jr.
(Gamer)

Falcon 030 16meg of Ram

Reply all
Reply to author
Forward
0 new messages