Re: [cc65] cc65 + tcp/ip howto and/or example

Hi Oliver,

On Mon, Jan 03, 2011 at 02:51:45PM +0100, Oliver Schmidt wrote:
> Hi Gábor,
> 
> > It would be so nice if cc65 has some kind of library for some TCP/IP so many
> > new projects can be born using tcp/ip then. Sure, I can use Contiki, but now
> > I'm thinkin in "simple individual" (not within contiki) programs utilizing
> > TFE and/or RR-Net for example.
> 
> I'm not sure what you are refering to with "within Contiki":
> 
> If you mean the Contiki O/S with its own desktop than you should know
> that this was Contiki 1.x. In Contiki 2.x you write "individual"
> programs loaded from your DOS running in full screen mode (or doing
> their own user interface).

Ok, it's my fault, I don't know too much about Contiki, I've heard about it,
I've tried it once in vice, but it was "a long time ago".

> 
> If you mean that Contiki isn't just a library you call into when you
> like but rather a framework you embedd your code into than this is
> because it is the *only* way to do TCP in a way efficient enough for
> cc65 targets. Just a few of the several reasons:
> 
> - An event/callback architecture implicitly serializes access to
> resources. Otherwise explict locking and/or multiplication of
> resources would be necessary.
> 
> - Have you ever written a GUI application? The GUI core calls you when
> your screen area needs to be (re-)drawn. This makes perfect sense as
> in most cases the code to do so is the same for drawing your screen in
> the first place. So there's no overhead on the application side but
> the GUI core can avoid to buffer your screen content offscreen. In
> many cases the GUI applications just send themselves a redraw event
> when they want to update the screen. uIP is using the very same
> paradigm for networking: If a packet needs to be resent it just calls
> the application to recreate it! In most cases this is no problem at
> all for the application but allows uIP to go without any
> buffering/copying. An exception is the web server on the C64 serving
> disk files as they allow only sequential access. Here the application
> buffers the last frame - still not worse than uIP doing it.

Yes, I know about the event-driven programming model, and I've coded for GTK
on Linux both in C and Python. But now I am really unsure why you mention
this, it sounds like you think I have some negative feeling against this.

> Exactly. Those APIs only work in a reasonable way in environments
> where "everything is a file" so you can put its handle into select().
> Because otherwise you can't multiplex I/O on several network streams,
> the user interface, ... That is one reason why you don't get far with
> those APIs i.e. on Windows...
> 
> But even on UNIX-like OSes: Applications tend to be either
> thread-or-fork based or select() based. The thread-or-fork approach is
> supposed to perform better - but would you really want to program cc65
> targets that way? And when you look at a select() based application
> than you're basically back at event driven programming with select()
> being your event source you act upon - don't you?

Surely, forking a process would be a bit hard on C64 because of lack of MMU
and other problems as well, it's simply not so suited a target like C64 is.
Maybe the same for threads too, there is not so much difference between
fork'ed processes and threads (at least on Linux for example) just some
different parameters for the clone() syscall, like shared memory, or some
Copy-On-Write mechanism to have separated data area, but with initial same
memory content. It's simply not suitable for a target without advanced MMU,
like C64 is. You may misunderstood me, I don't expect to have POSIX like API
on the C64, I've just mentioned because I have experience with that, it was
the only reason I've mentioned it, that's all. So I don't want to code
using cc65 targeting a C64 with an API like that because it's nearly
impossible, indeed.

After reading your mail, I have the thought that you really misunderstood
something, or I can't express myself clearly, which can be the case since my
English is far from being perfect, I think. So: I don't want a POSIX like
API: not because it sucks, but because it's not suitable for C64 or anything
like that. Also, I'm not against the event driven programming model. Also, I
have no problem with uIP, the only reason I mentioned IP65, since it seems
to be easiler for me to understand, that's all. So we can say it's my
limitation, not so much technical reason to say that :) Still, I am trying
to work with uIP, but simply IP65 seems to result shorter (in size) code,
and I have only some minimal goals now, not an advanced TCP/IP solution
(well, "advanced" compared to a C64, I mean). Also, it's just a hobby for
me, and I simply enjoying to try to make everything by myself as much as
possible, but still because of lacking enough free time, IP65 is perfect to
learn about how to program a TFE on I/O level and things like that which is
more a quick way for me learn.

--
- Gábor
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.