EtherNat & USB drives
J.-Luc
As suggested in the subject : is there any way to have an usb
flashdisk working on the EtherNat ?
Regards,
J.-Luc
--
"From" is invalid. In order to answer directly, replace :
Myname= Jean-Luc ; Mysurname= Ceccoli ; myisp= wanadoo.fr
Atari...@gmail.com
Sorry J.-Luc, I can't help you out...but I do agree that we atarians
are in dire need of usb drivers, else what's the point of the usb
ports on the ethernat? If someone could come up the drivers for usb
mice, flash drives, printers, cameras, etc, it would make the ethernat
that much more desireable. Too bad the usb drivers from Linux can't
be used afaik.
Götz Hoffart
> but I do agree that we atarians are in dire need of usb drivers, else
> what's the point of the usb ports on the ethernat?
First one has to be a lucky boy to own an Ethernat. I do not,
unfortunately.
I hope that the USB driver situation will be a bit more planned and
organised compared to the TCP/IP-stack-world ... worlds.
Regards
Götz
Dave Wade
""Götz Hoffart"" <use...@hoffart.de> wrote in message
news:1ih3387.160b1hgwgqwsdN%use...@hoffart.de...
I think its already too late... One per OS perhaps...
> Regards
> Götz
J.-Luc
We bought a device that reveals totally unuseable for non-MiNT users
and partly useable only for MiNT ones... :-(
I think I'll never trust anymore anyone else than Rodolphe for any-
thing to be added to the Falcon. At least, he ensured his products
would work fine on every common OS people run.
PHANTOMM_2
"J.-Luc" <Myname.Mysurname@myisp> wrote in message
news:482ecd31$0$928$ba4a...@news.orange.fr...
will not advance the Atari platform. This only makes the number of users
of advance hardware smaller.
I think anyone who wants to develop hardware and or software, should develop
for the whole or most of the platform. So that new users can pick it up
easy.
Most people simply don't have or don't want to take the time to install
another
OS so that they can run a piece of hardware.
We needed USB support for along time now as well as other things to keep
the platform going.
If possible, stick with developing items that will work with TOS and the
whole
platform will benefit.
.
MiKRO / Mystic Bytes
> another
> OS so that they can run a piece of hardware.
is really time expensive operation...
I understand your concern, it would be definitely better to have
drivers for both sting and mintnet but remember, there are only
limited resources (in manner of atari programmers). It's not HW
developers' fault MagiCNet is dead and author disappeared. So if you
want to use your Ethernat, I recommend you either do that "time
expensive" copy operation or code driver by yourself.
USB stack is another story but honestly -- in case they decide to
develop something as huge as this, would you be willing to accept the
waiting for the Ethernat another 3-4 years? Me definitely not.
J.-Luc
>
>> Most people simply don't have or don't want to take the time to install
>> another
>> OS so that they can run a piece of hardware.
> Yeah, that copying mint.prg into auto folder and mint directory to c:
> is really time expensive operation...
>
drivers ?
I wonder why such an important news hasn't been unveiled so far...
MiKRO / Mystic Bytes
> drivers ?
and one directory is enough for installing whole FreeMiNT (if you
aren't interested in unix stuff) and Ethernat drivers.
> I wonder why such an important news hasn't been unveiled so far...
>
What about reading README in FreeMiNT release? There's such clear (and
exhaustive for each situation) explanation I can't imagine what else
you could be looking for.
http://sparemint.org/sparemint/mint/kernel/1.16.1/readme.txt
PHANTOMM_2
"MiKRO / Mystic Bytes" <miro.k...@gmail.com> wrote in message
news:a569b494-8e47-47e0...@a1g2000hsb.googlegroups.com...
I've had Mint installed before, Installing the basic is simple enough.
You can do that with Geneva.
However, I don't like having to run a certain OS to get Ethernat.
It sounds rather PC ish.
I'm not knocking Mint, but why must it be used for this hardware
to work properly?
Finding people to code anything on an Atari now days is rare indeed.
J.-Luc
In fact, the real problem is that some developpers earned money
selling (at the time) powerful software that people bought trusting
it would last a little longer than pc stuff, then those developpers
retired without releasing their sources and because, in most cases,
the software has still commercial status, nobody can make further
development on its basis.
I mean about MagiC!, CAB, NVDI, and some others that we bought and
are still sold rather expensively though quite outdated.
For instance, I own legal copies of all three, and none of them has
evolved for 5 years at least.
That make me fell somehow a little disappointed...
And we must rely on free stuff made by people that don't earn
anything to have our machines run...
>
> Finding people to code anything on an Atari now days is rare indeed.
>
Unfortunately.
PeP
> In my opinion, any device that relies on using another OS such as Mint,
> will not advance the Atari platform. This only makes the number of users
> of advance hardware smaller.
Problem is it doesn't work like that. The FreeMiNT kernel has proper
support for device drivers, whereas TOS and MagiC has not. This, and
the fact that it's a good idea to keep APIs etc. similar to that of
the unix-world in general, means the preferred way of writing device
drivers for FreeMiNT differs significantly from that of the other two.
This doesn't mean there can't be compatibility. A good example is the
STiK API vs. MiNTNet, where compatibility has been solved by means of
a wrapper daemon.
> I think anyone who wants to develop hardware and or software, should develop
> for the whole or most of the platform. So that new users can pick it up
> easy.
> Most people simply don't have or don't want to take the time to install
> another OS so that they can run a piece of hardware.
An aspect that people seem to forget is that while all these OS:s
sport the same user application compatibility, they don't share the
same functionality or features internally. The FreeMiNT kernel and
recent AES:s has functionality not found in legacy systems like TOS/
MagiC, and it is sometimes difficult to write stuff without using this
functionality. What complicates things even more is that MagiC costs
cash (still), which means you can't even test your stuff without
having to pay for something which is A: essentially dead and B: you
don't want to use anyway. As a user however, you have the option to
support the ongoing development by using stuff that is being actively
developed, including the OS.
Jo Even Skarstein
> Problem is it doesn't work like that. The FreeMiNT kernel has proper
> support for device drivers, whereas TOS and MagiC has not. This, and
MagiC has proper support for device drivers, although it looks to me that
it offloads a lot more work to the driver (and the developer!) than the
API used in MiNT. It also has support for loadable filesystems similar to
MiNT's, but I don't know the details. They're not binary compatible
though, that's for sure.
MiNT-Net and MagiXnet-drivers used to be binary compatible though. I'm not
sure why they're not compatible now, as the XIF-interface doesn't appear
to have changed in MiNT-net. There might be some other reason why this
particular driver doesn't work with MagiC.
> same functionality or features internally. The FreeMiNT kernel and
> recent AES:s has functionality not found in legacy systems like TOS/
> MagiC, and it is sometimes difficult to write stuff without using this
> functionality. What complicates things even more is that MagiC costs
Indeed! Using new features AND be compatible with MagiC means adding lots
of code to emulate the new features under MagiC. This means wasted time
and efforts, which we really can't afford with the small number of
developers left.
> cash (still), which means you can't even test your stuff without
> having to pay for something which is A: essentially dead and B: you
I'd like to test my stuff under MagiC, but will wait until some sends me a
free copy of MagiC-Milan ;-) I already have a legal copy of MagiC 6.1, but
that one doesn't work on the Milan.
--
/*
** Jo Even Skarstein http://joska.nvg.org/
*/
Carey Christenson
> in article awYYj.371$772...@bignews2.bellsouth.net, PHANTOMM_2 wrote on
> 5/21/08 12:59 PM:
>
>> I've had Mint installed before, Installing the basic is simple enough.
>> You can do that with Geneva.
>> However, I don't like having to run a certain OS to get Ethernat.
>> It sounds rather PC ish.
>> I'm not knocking Mint, but why must it be used for this hardware
>> to work properly?
>
> 2 paths, there are missing system calls/features in magic. Or worse yet the
> same calls exist but they don't work the same because someone decided they
> didn't need to follow the path laid down before them.
Hello lp,
Long time NO talk! Well the old Magic and MINT battle. I am sure
this is all true since you are a coder and all and well aware of what
the ins and outs are of both OS's. But lets be reasonable here. If I
had the 1/2 the knowledge that anyone else that claims they could have
written a work around for this MagicNET on EtherNAT thing it would have
been done by now and no one would be writing on this newsgroup about not
have a driver for this card.
>
> Then a coder comes along who happens to use MiNT, and for whatever reason
> codes a driver for it. He maybe don't care about magic, magic came later,
> it's missing stuff, and it's extra work to duplicate the effort and code a
> work around etc. Sure some will argue it's not so hard, then that person
> can write the magic driver. But do they? ;-))
Sure this is true but really what is programming. Me being a programmer
on the 8-bit line of Atari computers I know that programming is nothing
more than hacking a computer to do what you want. Where there is a will
there is a way.
>
> To further complicate matters, installing MiNT is not as hard as some make
> it out to be. It can also be installed in a few varying levels of
> difficulty depending on just what the end users wants to do with it.
> The unix parts can be optional depending on your needs.
>
> One can install multi-tos (the original version from atari)
> Don't like the AES swap it out, it's a component.
> Don't like the kernel, swap it out for FreeMiNT, again a component.
> Want all the unix extras, either hand install them or use EasyMiNT.
> And sure there are configs a long the way to adjust, and various docs.
>
> I installed the original KGMD distribution well before EasyMiNT came out and
> I done it twice. Hand installed a Desktop as KGMD leaves on a blank screen
> with nothing but a prompt. At the time I was clueless about unix anything.
> So I don't understand all the hoopla over installing MiNT. Later on I
> installed the RPM manager and brought it up to SpareMiNT level, again by
> hand. Anyone that thinks EasyMiNT is hard should take a serious look at
> the old KGMD package.
>
No none of it is hard when using the EasyMINT installation. But here
lies the problem. MINT does not allow the usage of some programs that
were MAGIC only like Emailer, Fiffi some other ASH products. Those are
great programs and I still use them to this day. So anyone wanting to
use MINT has to do what? There are some cool things in Magic that I
have not been able to find for MINT and vice versa. But I am not
willing to dump Magic for MINT entirely, because of the lack of some of
these applications. That is why I currently have the availibility to
run three OS's TOS, Magic and MINT on my CT60'ed Falcon. I would like
to get 2 systems running, one with MINT and one with MAGIC so that I can
use both over my network.
The hand install of MINT is crazy since EasyMINT is available. I
certainly would not recommend that for any beginner. Start out with
EasyMINT and if you have a working setup and do not want to get rid of
your existing setup you can install MINT on your current HD and
partition before beginning the installation. This will all be covered
in my MINT Tutorial coming soon.
Carey Christenson
PeP wrote:
> On 18 Maj, 22:01, "PHANTOMM_2" <phant...@bellsouth.net> wrote:
>> In my opinion, any device that relies on using another OS such as Mint,
>> will not advance the Atari platform. This only makes the number of users
>> of advance hardware smaller.
>
> Problem is it doesn't work like that. The FreeMiNT kernel has proper
> support for device drivers, whereas TOS and MagiC has not. This, and
> the fact that it's a good idea to keep APIs etc. similar to that of
> the unix-world in general, means the preferred way of writing device
> drivers for FreeMiNT differs significantly from that of the other two.
>
> This doesn't mean there can't be compatibility. A good example is the
> STiK API vs. MiNTNet, where compatibility has been solved by means of
> a wrapper daemon.
Why cant this be done with this driver for MINT to work on MagicNET??
There has to be someway of getting MagicNET to work with this driver in
some fashion.
>
>> I think anyone who wants to develop hardware and or software, should develop
>> for the whole or most of the platform. So that new users can pick it up
>> easy.
>> Most people simply don't have or don't want to take the time to install
>> another OS so that they can run a piece of hardware.
>
> An aspect that people seem to forget is that while all these OS:s
> sport the same user application compatibility, they don't share the
> same functionality or features internally. The FreeMiNT kernel and
> recent AES:s has functionality not found in legacy systems like TOS/
> MagiC, and it is sometimes difficult to write stuff without using this
> functionality. What complicates things even more is that MagiC costs
> cash (still), which means you can't even test your stuff without
> having to pay for something which is A: essentially dead and B: you
> don't want to use anyway. As a user however, you have the option to
> support the ongoing development by using stuff that is being actively
> developed, including the OS.
I am more than willing to help in anyway I can. I have Magic with
Jinnee setup and ready to test any programs that anyone is willing to
throw at me. Call me a beta tester to the programmers. For a living I
write procedures for my work place in a very structural manner so
desciptions of problems that are happening will be very detailed in
deed. Anyone willing to work on this I have some money on the line for
the project and I am sure there is several others that would join me in
paying a few bucks for the effort so that it does not go unrecognized.
Anyone else with me??
Carey Christenson
> PeP <pep.fi...@gmail.com> wrote:
>
>> Problem is it doesn't work like that. The FreeMiNT kernel has proper
>> support for device drivers, whereas TOS and MagiC has not. This, and
>
> MagiC has proper support for device drivers, although it looks to me that
> it offloads a lot more work to the driver (and the developer!) than the
> API used in MiNT. It also has support for loadable filesystems similar to
> MiNT's, but I don't know the details. They're not binary compatible
> though, that's for sure.
Hello Jo Evan,
That is interesting to know.
>
> MiNT-Net and MagiXnet-drivers used to be binary compatible though. I'm not
> sure why they're not compatible now, as the XIF-interface doesn't appear
> to have changed in MiNT-net. There might be some other reason why this
> particular driver doesn't work with MagiC.
That is VERY interesting to know. What was coded differently in the
versions of MINT or MINTNET that would have caused a problem with the
API as has been stated is the problem??? Was something added to this
particular driver for MINT that makes it not work the same for MagicNET??
>
>> same functionality or features internally. The FreeMiNT kernel and
>> recent AES:s has functionality not found in legacy systems like TOS/
>> MagiC, and it is sometimes difficult to write stuff without using this
>> functionality. What complicates things even more is that MagiC costs
>
> Indeed! Using new features AND be compatible with MagiC means adding lots
> of code to emulate the new features under MagiC. This means wasted time
> and efforts, which we really can't afford with the small number of
> developers left.
As I stated basically the same thing that you have to create a work
around to get your idea to work. There may not be a direct feature so
to speak that can be accessed but there is always a way to get anything
to work on any device if you think about it long enough.
>
>> cash (still), which means you can't even test your stuff without
>> having to pay for something which is A: essentially dead and B: you
>
> I'd like to test my stuff under MagiC, but will wait until some sends me a
> free copy of MagiC-Milan ;-) I already have a legal copy of MagiC 6.1, but
> that one doesn't work on the Milan.
>
Jo Evan I can certainly help you out testing your stuff so that it works
under Magic. Would you like me to beta test your stuff and get back to
you on it?? Anything in particular you wish me to start with?? I
wished I had the Milan version as I only have the regular Atari version.
Jo Even Skarstein
> That is VERY interesting to know. What was coded differently in the
> versions of MINT or MINTNET that would have caused a problem with the
At some point the sockets functionality was moved from a device into the
kernel itself. Then the relevant GEMDOS-functions has been added. However,
I don't think the XIF-interface (the interface between the network device
driver and inet4.xdd) has been changed, as I've used the same driver
before and after this change without any problems. Also, this particular
driver (DE620-driver by Elmar Hilgart) worked on both MiNTnet and MagiXnet
simply by changing the filename suffix from xif to mif.
> API as has been stated is the problem??? Was something added to this
> particular driver for MINT that makes it not work the same for MagicNET??
I have no idea. Is the source code available? If so, it should be possible
to fix it unless it depends heavily on some MiNT-only feature(s).
> As I stated basically the same thing that you have to create a work
> around to get your idea to work. There may not be a direct feature so
> to speak that can be accessed but there is always a way to get anything
> to work on any device if you think about it long enough.
Thinking is the easy part. The actual development might not be so easy ;-)
Believe me, it's quite frustrating to draw the benefits of new features in
XaAES and then have to implement the same feature from scratch to be able
to run the application under N.AES or MagiC. It would be so much easier if
everybody just switched to XaAES (or MyAES, which is very up-to-date as
well).
> Jo Evan I can certainly help you out testing your stuff so that it works
> under Magic. Would you like me to beta test your stuff and get back to
I have beta-testers, but the problem now is that I have a particular
program that won't even start under MagiC. So I need to debug it under
MagiC. I have MagiC on my Falcon/AB, but no space to set up this Falcon so
I can't use it...
Gerhard Stoll
> code to emulate the new features under MagiC.
What new AES features do you use?
Gerhard
Jo Even Skarstein
Floating windows. Extensions to appl_control (which again doesn't exist at
all under MagiC). Menu-widget in windows. Automatic handling of keyboard
shortcuts in forms when using form_keybd.
PeP
> Why cant this be done with this driver for MINT to work on MagicNET??
> There has to be someway of getting MagicNET to work with this driver in
> some fashion.
Well, I don't know if you're refering to network interface drivers or
to the USB stuff. The latter has nothing to do with MagiCNet, while
the former suffers from compatibility issues which are difficult to
solve since MagiCNet is nolonger developed, and the source code seems
to be closed (which is odd, because afaik it's based on MiNTNet which
is GPL).
> I am more than willing to help in anyway I can. I have Magic with
> Jinnee setup and ready to test any programs that anyone is willing to
> throw at me.
Good thinking. Kudos for that! :)
J.-Luc
>
> On 23 Maj, 00:14, Carey Christenson <falcon...@roadrunner.com> wrote:
>
>> Why cant this be done with this driver for MINT to work on MagicNET??
Hello,
Maybe because MagiC-Net is a very outdated hack of MiNT-Net, which
used to be compatible enough until MiNT-Net developpers added new
important features (not to blame the MiNT-Net developpers, is it?)
that allowed the stack to keep accurate.
>> There has to be someway of getting MagicNET to work with this driver in
>> some fashion.
>
> Well, I don't know if you're refering to network interface drivers or
> to the USB stuff. The latter has nothing to do with MagiCNet, while
> the former suffers from compatibility issues which are difficult to
> solve since MagiCNet is nolonger developed, and the source code seems
> to be closed (which is odd, because afaik it's based on MiNTNet which
> is GPL).
And, worse, the author seems to have vanished - unless he only refuses
to answer hte mails ? -. :-(
Regards,
PeP
> MagiC has proper support for device drivers, although it looks to me that
> it offloads a lot more work to the driver (and the developer!) than the
> API used in MiNT. It also has support for loadable filesystems similar to
> MiNT's, but I don't know the details. They're not binary compatible
> though, that's for sure.
Well, since it's not binary compatible then we're kind of screwed
anyway. But I wouldn't mind getting my hands on the specifications for
that stuff so I could port my joystick drivers for it (well, provided
I get access to MagiC as well).
> Indeed! Using new features AND be compatible with MagiC means adding lots
> of code to emulate the new features under MagiC. This means wasted time
> and efforts, which we really can't afford with the small number of
> developers left.
And - (no offence non-coders) - non-coders tend to claim it's just a
matter of "try a little harder". This is usually not the case, because
it means you can't rely on a particular design but need to do a "one
size fits all"-solution (which is often no way near as good as the
original design).
> I'd like to test my stuff under MagiC, but will wait until some sends me a
> free copy of MagiC-Milan ;-) I already have a legal copy of MagiC 6.1, but
> that one doesn't work on the Milan.
Me too! In such case I would consider supporting it. As things look
now I won't.
PeP
> > Me being a programmer
> > on the 8-bit line of Atari computers I know that programming is nothing
> > more than hacking a computer to do what you want. Where there is a will
> > there is a way.
Well, and there we have it. My impression is that most of the active
coders (far from all though) are using FreeMiNT. Asking them to fix it
for MagiCNet won't get you far. There should be a few MagiC hackers
around, and perhaps they could fix it? The driver sources are - thank
god - GPL.
And btw - "programming is nothing more than hacking a computer" - I'm
not sure I agree with that. In the end ofcourse it's down to 1:s and
0:s, but frankly, it's more than that.
Fidel-Sebastian Hunrichse-Lara
> There should be a few MagiC hackers around, and perhaps they could fix
> it?
Why should they? Most MagiC-User don't use MagiCNet...
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#
Gerhard Stoll
Mmh, what is that?
> Extensions to appl_control (which again doesn't exist at all under
> MagiC).
It's no problem to wrote a TSR which add some function, but I think it is
impossible to add all.
I don't know if that helps you and other programmer.
Gerhard
Jo Even Skarstein
> > Floating windows.
> Mmh, what is that?
Windows that are always on top, or always on top when an associated window
is on top.
PeP
Sebastian Hunrichse-Lara) wrote:
> Why should they? Most MagiC-User don't use MagiCNet...
Well, the discussion was about the EtherNat & USB, and the current
Ethernet drivers for this card are written for MiNTNet, hence it would
be natural to get these drivers working in MagiCNet.
J.-Luc
Unfortunately, Vassilis P., MagiC-Net maintainer, seems to have
vanished. :-(
Fidel-Sebastian Hunrichse-Lara
> > Why should they? Most MagiC-User don't use MagiCNet...
>
> Well, the discussion was about the EtherNat & USB, and the current
> Ethernet drivers for this card are written for MiNTNet, hence it would
> be natural to get these drivers working in MagiCNet.
Well, as a matter of course there're ethernet drivers written for
MiNTNet, STinG, MM (MacSTip) and M_PC (In2Cat.dll) but implies this
anything to USB drivers? Or should MiNTNet IYO be responsible for USB?
PeP
Sebastian Hunrichse-Lara) wrote:
> Well, as a matter of course there're ethernet drivers written for
> MiNTNet, STinG, MM (MacSTip) and M_PC (In2Cat.dll) but implies this
> anything to USB drivers? Or should MiNTNet IYO be responsible for USB?
No offence, but I believe you just missed the point of the whole
discussion.
Fidel-Sebastian Hunrichse-Lara
> > Well, as a matter of course there're ethernet drivers written for
> > MiNTNet, STinG, MM (MacSTip) and M_PC (In2Cat.dll) but implies this
> > anything to USB drivers? Or should MiNTNet IYO be responsible for
> > USB?
>
> No offence, but I believe you just missed the point of the whole
> discussion.
O'Really? Well, MiNTNet has in actual fact IMHO to do as much with USB
drivers as STinG, MacSTip or In2Cat.dll...
PeP
Sebastian Hunrichse-Lara) wrote:
> O'Really? Well, MiNTNet has in actual fact IMHO to do as much with USB
> drivers as STinG, MacSTip or In2Cat.dll...
Well none of that has anything to do with USB drivers. The original
discussions were about USB, viable driver solutions, and the famous
MagiCNet vs. EtherNat incompatibility. You contributed by stating that
noone use MagiCNet.
Fidel-Sebastian Hunrichse-Lara
> > O'Really? Well, MiNTNet has in actual fact IMHO to do as much with
> > USB drivers as STinG, MacSTip or In2Cat.dll...
>
> Well none of that has anything to do with USB drivers.
ACK
> The original discussions were about USB, viable driver solutions, and
> the famous MagiCNet vs. EtherNat incompatibility.
Nope! That's not the issue...
--------------------- <nibble here off> ---------------------
> > I know that programming is nothing more than hacking a computer to
> > do what you want. Where there is a will there is a way.
Well, and there we have it. My impression is that most of the active
coders (far from all though) are using FreeMiNT. Asking them to fix it
for MagiCNet won't get you far.
--------------------- </nibble here off> --------------------
© <8ae7bffc-4343-4747...@2g2000hsn.googlegroups.com>
The main problem is that none of the the few active FreeMiNT coders is
willing to look over the rim of his tea cup!
> You contributed by stating that noone use MagiCNet.
And that's the absolute truth - most MagiC hackers use MM or M_PC...
PeP
Sebastian Hunrichse-Lara) wrote:
> <pep.fishmo...@gmail.com> wrote:
> > The original discussions were about USB, viable driver solutions, and
> > the famous MagiCNet vs. EtherNat incompatibility.
> Nope! That's not the issue...
Well, after all, it was the topic for this thread - "EtherNat & USB
drives"...
> The main problem is that none of the the few active FreeMiNT coders is
> willing to look over the rim of his tea cup!
Well, we've been over this before. If the overwelming majority of all
coders on the planet use some form of MagiC, how come we haven't seen
any EtherNat drivers for MagiC yet? How can that be, Fidel-Sebastian
Hunrichse-Lara? Is this the fault of the "few" narrow-minded FreeMiNT
coders who are not willing to look over the rim of their tea cup?
> > You contributed by stating that noone use MagiCNet.
> And that's the absolute truth - most MagiC hackers use MM or M_PC...
And how does that help people get USB & network drivers for their
EtherNats and NetUSBees?
GokMasE
http://images.istheshit.net/mxguzrwa.gif
Regards,
/Joakim
Fidel-Sebastian Hunrichse-Lara
> how come we haven't seen any EtherNat drivers for MagiC yet?
Because till now no MagiC coder has an EtherNat?
> Is this the fault of the "few" narrow-minded FreeMiNT coders who are
> not willing to look over the rim of their tea cup?
Well, finally it's of course the fault of the EtherNat developers...
> > > You contributed by stating that noone use MagiCNet.
> > And that's the absolute truth - most MagiC hackers use MM or
> > M_PC...
>
> And how does that help people get USB & network drivers for their
> EtherNats and NetUSBees?
We go entirely round in a circle and thus it's an absolute no-no!
Fidel-Sebastian Hunrichse-Lara
> I think this picture sums up the situation pretty good:
>
> http://images.istheshit.net/mxguzrwa.gif
That's the pot calling the kettle black...
PeP
Sebastian Hunrichse-Lara) wrote:
> That's the pot calling the kettle black...
Speaking about pot...