Contiki 2.1 released
Oliver Schmidt
Just in time for the Contiki 2.1 release I finished my port of the
Contiki 2.x codebase to cc65 targets :-)
http://www.sics.se/contiki/current-events/contiki-2.1-released.html
This port consist primarily of two parts:
1. Complete and clean integration of the cc65 toolchain into the
Contiki 2.x build system. This allows Contiki 2.x applications to be
built for about every cc65 target. Predefined are the C64 and the
enhanced Apple //e.
2. Generic Ethernet packet driver with dynamically loading,
self-modifying Ethernet card device drivers for the CS8900A and the
LAN91C96. These two drivers are used both for the C64 and the enhanced
Apple //e.
My Contiki 2.x port is _NO_ successor of my Contiki 1.x port !
While Contiki was originally a disk based OS with a GUI and with
TCP/IP the goals have totally changed in the meanwhile. Now it's a ROM
based OS for embedded systems without UI and with TCP/IP or low power
radio MAC protocols.
As a consequence there's no development at all done on the original
GUI applications. Therefore it didn't make sense to invest a lot of
effort into just recreating the Contiki 1.x experience with the
Contiki 2.x codebase.
On the other hand there are several people interested in creating
TCP/IP enabled 8-bit applications on the Apple2. But they don't want /
need the Contiki GUI either because they want to create their own GUI
or don't need a GUI at all. Surely it was possible to strip the GUI
from Contiki 1.x but the whole thing is so highly optimized from
source to build that this seems a quite difficult task to begin with.
Therefore those people tend to go for uIP instead. uIP is a quite
popular TCP/IP library being the core of the TCP/IP stack in Contiki.
I think this is a pity as you most of the time end up recreating a lot
of what the Contiki core offers on top of uIP - and still miss the
rest. In a nutshell my Contiki 2.x port claims to be "the better uIP"
for cc65 targets.
Some features:
- Windows/Cygwin or Un*x as test platform work out of the box
- cc65 targets as target platform work out of the box
- Several examples (including a web server) work out of the box
- Both Uther and LANceGS work out of the box
- The Protothreads paradigm for intuitively interleaving /
coordinating several streams of activity in extremely lightweight
processes
Some processes come with Contiki and can used as needed:
- TCP/IP stack
- Ethernet card driver
- DNS client
- DHCP client
The application is defined as a custom process. A potential web
browser could consist of the Protothreads:
- Keyboard/mouse handler
- HTML parser
- Page renderer
So I think by now nobody wonders anymore why I posted this message to
comp.sys.apple2.programmer ;-)
Have fun, Oliver
Toinet
Oliver,
Congratulations for your huge work. It is really impressive!
Antoine
schmidtd
> Some processes come with Contiki and can used as needed:
> - TCP/IP stack
> - Ethernet card driver
> - DNS client
> - DHCP client
>
> The application is defined as a custom process.
Can you give an estimate of how much memory is left (in a 128k
enhanced IIe) for the application given the configuration above? Is
there any hope if I want to target a II+?
Oliver Schmidt
>Congratulations for your huge work. It is really impressive!
Thanks! Do you have any plans to build something with it?
Best, Oliver
Oliver Schmidt
>On Dec 4, 6:19 pm, ol...@web.de (Oliver Schmidt) wrote:
>> Some processes come with Contiki and can used as needed:
>> - TCP/IP stack
>> - Ethernet card driver
>> - DNS client
>> - DHCP client
>>
>> The application is defined as a custom process.
>Very cool. Thanks for your work.
Thanks for the positve feedback :-)
>Can you give an estimate of how much memory is left (in a 128k
>enhanced IIe) for the application given the configuration above? Is
>there any hope if I want to target a II+?
Neither the Contiki framework nor the underlying cc65 C-Library make
themselves actively use of the second 64k in any way. So a 64k machine
is in fact the expected target.
Nevertheless cc65 defines a machine-neutral "extended memory
interface" allowing you to map/copy memory pages into a memory window.
There's an implementation for this interface based on the second 64k
of a 128k //e.
Hope that helps, Oliver
schmidtd
> Hi,
>
> >On Dec 4, 6:19 pm, ol...@web.de (Oliver Schmidt) wrote:
> >> Some processes come with Contiki and can used as needed:
> >> - TCP/IP stack
> >> - Ethernet card driver
> >> - DNS client
> >> - DHCP client
>
> >> The application is defined as a custom process.
> >Very cool. Thanks for your work.
>
> Thanks for the positve feedback :-)
>
> >Can you give an estimate of how much memory is left (in a 128k
> >enhanced IIe) for the application given the configuration above? Is
> >there any hope if I want to target a II+?
>
> Neither the Contiki framework nor the underlying cc65 C-Library make
> themselves actively use of the second 64k in any way. So a 64k machine
> is in fact the expected target.
left after TCP/IP, Ethernet, DNS and DHCP are loaded?
aiia...@gmail.com
> Ah, perfect. Now, back to the question... ;-) How much memory is
> left after TCP/IP, Ethernet, DNS and DHCP are loaded?
DHCP??? Probably don't want this in RAM...
ethernet driver
tcp/ip
dns
should take a bunch of RAM....
I just looked at my CC65 built web client... (actually, 99.999%
written by Glenn Jones)
32031 bytes.
this was built 1 year ago, with previous versions of CC65, etc..
this includes: ethernet driver, tcp/ip, DNS
NO DHCP... Glenn was having trouble getting it to compile about a
year ago.
I have the web browser working
http://rich12345.tripod.com/htmlview/index.html
with about 64k available for the parser, GUI, etc, running in
AUX RAM while tcp/ip, ethernet, DNS are all in main RAM.
I have had 10+ web pages open at a time, each in a different
AUX RAM bank... I'm working on cleaning up the GUI (HGR)
for release..
Rich
aiia...@gmail.com
> I finished my port of the
> Contiki 2.x codebase to cc65 targets :-)
neat!
>
> http://www.sics.se/contiki/current-events/contiki-2.1-released.html
OK, there is the announcement... where is the source?
> This port consist primarily of two parts:
> 1. Complete and clean integration of the cc65 toolchain into the
> Contiki 2.x build system.
> 2. Generic Ethernet packet driver with dynamically loading,
> self-modifying Ethernet card device drivers
What exactly did you change?
> On the other hand there are several people interested in creating
> TCP/IP enabled 8-bit applications on the Apple2. But they don't want /
> need the Contiki GUI either because they want to create their own GUI
> or don't need a GUI at all.
I want a GUI in AUX RAM that works with HGR, and can hopefully be used
by Contiki OS or standalone apps... With little toll on MAIN RAM.
>Surely it was possible to strip the GUI
> from Contiki 1.x but the whole thing is so highly optimized from
> source to build that this seems a quite difficult task to begin with.
and the GUI used the text screen. Works great for sure...
> Therefore those people tend to go for uIP instead. uIP is a quite
> popular TCP/IP library being the core of the TCP/IP stack in Contiki.
Glenn Jones (a2retrosystems.com) compiled uIP with CC65 and that's
what I'm using on my web browser.
> I think this is a pity as you most of the time end up recreating a lot
> of what the Contiki core offers on top of uIP - and still miss the
> rest. In a nutshell my Contiki 2.x port claims to be "the better uIP"
> for cc65 targets.
Contiki is C...
I'm going for GUI in 6502, so far it's working nice and fast. and
it's in
AUX.
> Some features:
> - Windows/Cygwin or Un*x as test platform work out of the box
> - cc65 targets as target platform work out of the box
> - Several examples (including a web server) work out of the box
> - Both Uther and LANceGS work out of the box
was this not true previous to your announcement?
> - The Protothreads paradigm for intuitively interleaving /
> coordinating several streams of activity in extremely lightweight
> processes
?? greek ??
:-)
> Some processes come with Contiki and can used as needed:
> - TCP/IP stack
> - Ethernet card driver
> - DNS client
> - DHCP client
how is this different from previous releases?
> The application is defined as a custom process. A potential web
> browser could consist of the Protothreads:
> - Keyboard/mouse handler
> - HTML parser
> - Page renderer
I've got those working in 6502... I'm sure it's sloppy and
unoptimized,
but it is fast, and resides in AUX.
Rich
sfahey
Re: Re: Contiki 2.1 released
By: aiiadict to comp.sys.apple2.programmer on Wed Dec 05 2007 01:54 pm
> I have had 10+ web pages open at a time, each in a different
> AUX RAM bank... I'm working on cleaning up the GUI (HGR)
> for release..
That is Wozsome.
Wozsome <adj> something "awesome" in the Wozniak tradition.
--- Synchronet 3.14a-Win32 NewsLink 1.85
A2Central.com - Your total source for Apple II computing.
a2retro
aiiadict wrote:
> On Dec 5, 12:38 pm, schmidtd <schmi...@my-deja.com> wrote:
>> Ah, perfect. Now, back to the question... ;-) How much memory is
>> left after TCP/IP, Ethernet, DNS and DHCP are loaded?
>
> DHCP??? Probably don't want this in RAM...
>
> ethernet driver
> tcp/ip
> dns
>
> should take a bunch of RAM....
>
> I just looked at my CC65 built web client... (actually, 99.999%
> written by Glenn Jones)
That was based on uIP 1.0 which was 99% written by Adam Dunkels and 1%
glue (by me) to make it interface to your code ... :)
>
> 32031 bytes.
the ip stack was around 24 thousand bytes .. the binary was 32K partly
because to the filler in the middle due the HGR screen
>
> this was built 1 year ago, with previous versions of CC65, etc..
>
> this includes: ethernet driver, tcp/ip, DNS
>
> NO DHCP... Glenn was having trouble getting it to compile about a
> year ago.
Never did figure that out ...
>
> I have the web browser working
>
> http://rich12345.tripod.com/htmlview/index.html
>
> with about 64k available for the parser, GUI, etc, running in
> AUX RAM while tcp/ip, ethernet, DNS are all in main RAM.
>
> I have had 10+ web pages open at a time, each in a different
> AUX RAM bank... I'm working on cleaning up the GUI (HGR)
> for release..
:o) Glenn
>
>
>
> Rich
a2retro
Hi Oliver,
I built the CFS enabled HTTPD server and it worked like a charm. A nice
addition would be to build a directory page if no file was specified.
Binary generated was 32,602 bytes plus 663 bytes for the Ethernet driver.
> - Both Uther and LANceGS work out of the box
> - The Protothreads paradigm for intuitively interleaving /
> coordinating several streams of activity in extremely lightweight
> processes
>
> Some processes come with Contiki and can used as needed:
> - TCP/IP stack
> - Ethernet card driver
> - DNS client
> - DHCP client
>
> The application is defined as a custom process. A potential web
> browser could consist of the Protothreads:
> - Keyboard/mouse handler
> - HTML parser
> - Page renderer
Rich, I would start to look at moving your Web browser platform over to
Contiki 2.1
>
> So I think by now nobody wonders anymore why I posted this message to
> comp.sys.apple2.programmer ;-)
>
> Have fun, Oliver
Oliver, Thanks for all your hard work on Contiki 2.1
Glenn
Oliver Schmidt
<schm...@my-deja.com> wrote:
>Ah, perfect. Now, back to the question... ;-) How much memory is
>left after TCP/IP, Ethernet, DNS and DHCP are loaded?
The reason why I didn't answer in the first place has two reasons:
- I didn't look at it.
- It depends.
But as you seem to insist in some number - here we go:
- I'm presuming a 64k machine and BASIC.SYSTEM thrown out - which is
the typical setup for cc65 binaries loaded with my "ProDOS loader".
- Contiki 2.1 is configured in a very "luxury" way: 1500 bytes of
network buffer. 10 simultanious connections. ...
- All major (aka large) parts of the cc65 C-library already included:
Heap management. ProDOS low level disk I/O. Stdio high level I/O
(especially the large printf() and friends). Errno, strerror()
(pulling in large error text tables). Dynamic module
loading/relocation. ...
In such a setup something like 15k are available. This may sound small
but keep in mind that about all you'll ever need from the cc65
C-Library is already there!
One the other hand it is of course possible to:
- Configue Contiki in a less "luxury" way.
- Reduce the amount of stuff pulled in from the C-Library by removing
printf, errno, strerror, ... from the Contiki codebase - quite easy to
do.
- Incorporate other more or less creative ways of reducing the memory
usage (like in example restrict the number of simultaniously open
ProDOS files to one and share the then single 1k ProDOS buffer with
the network buffer).
As pointed out before, Contiki 2.1 comes plain and straight in order
to be understood easily. But that doesn't keep you from incorporating
some of the tricks used in Contiki 1.3 as needed in case you run out
of memory. The Contiki 1.3 codebase is still there to have a look at
the tricks ;-)
Hope that helps, Oliver
Oliver Schmidt
>DHCP??? Probably don't want this in RAM...
I'm having trouble over here running code from disk ;-)
>I just looked at my CC65 built web client... (actually, 99.999%
>written by Glenn Jones)
>
>32031 bytes.
That is uIP, this thread is about Contiki.
Best, Oliver
Oliver Schmidt
>I built the CFS enabled HTTPD server and it worked like a charm. A nice
>addition would be to build a directory page if no file was specified.
Thanks for the testing. The webserver is just an example...
>Binary generated was 32,602 bytes plus 663 bytes for the Ethernet driver.
Thanks for the numbers. But that's without the memory used dynamically
and without DHCP.
>Rich, I would start to look at moving your Web browser platform over to
>Contiki 2.1
Thanks for your appraisal - that I share ! But judging from his
postsin this thread Rich might not share it ;-)
>Oliver, Thanks for all your hard work on Contiki 2.1
I appreciate your feedback :-)
Best, Oliver
Oliver Schmidt
>> http://www.sics.se/contiki/current-events/contiki-2.1-released.html
>
>OK, there is the announcement... where is the source?
Hm, the page says "Download the source code from the Download page".
For me it helps to read that string and select then the hyperlink on
the last two words. That directs my web browser to the download page.
Is there some aspect in the workflow above that causes trouble to you
?
>> This port consist primarily of two parts:
>> 1. Complete and clean integration of the cc65 toolchain into the
>> Contiki 2.x build system.
>> 2. Generic Ethernet packet driver with dynamically loading,
>> self-modifying Ethernet card device drivers
>
>What exactly did you change?
1. Integrated the cc65 toolchain into the Contiki build system.
2. Implemented a generic driver framework and dynamically loadable
drivers.
>> Therefore those people tend to go for uIP instead. uIP is a quite
>> popular TCP/IP library being the core of the TCP/IP stack in Contiki.
>
>Glenn Jones (a2retrosystems.com) compiled uIP with CC65 and that's
>what I'm using on my web browser.
Both Glenn and me are both happy that it is not necessary to do that
anymore :-)
>> I think this is a pity as you most of the time end up recreating a lot
>> of what the Contiki core offers on top of uIP - and still miss the
>> rest. In a nutshell my Contiki 2.x port claims to be "the better uIP"
>> for cc65 targets.
>
>Contiki is C...
Could you please elaborate ?
>I'm going for GUI in 6502, so far it's working nice and fast. and
>it's in
>AUX.
How does that relate to this thread ?
>> Some features:
>> - Windows/Cygwin or Un*x as test platform work out of the box
>> - cc65 targets as target platform work out of the box
>> - Several examples (including a web server) work out of the box
>> - Both Uther and LANceGS work out of the box
>
>was this not true previous to your announcement?
The statements above are meant as advantages compared to uIP - and the
latest uIP release has none of the things above.
>> - The Protothreads paradigm for intuitively interleaving /
>> coordinating several streams of activity in extremely lightweight
>> processes
>
>?? greek ??
Could you please elaborate ?
>> Some processes come with Contiki and can used as needed:
>> - TCP/IP stack
>> - Ethernet card driver
>> - DNS client
>> - DHCP client
>
>how is this different from previous releases?
The statements above are meant as advantages compared to uIP - and uIP
has no processes at all.
>I've got those working in 6502... I'm sure it's sloppy and
>unoptimized,
>but it is fast, and resides in AUX.
You wrote that already further above. How does that relate to this
thread ?
Best, Oliver
Michael J. Mahon
> On Wed, 5 Dec 2007 13:54:25 -0800 (PST), aiia...@gmail.com wrote:
>
>
>>DHCP??? Probably don't want this in RAM...
>
>
> I'm having trouble over here running code from disk ;-)
Given the memory constraints, have you considered an overlay
area for "transient" code? Considering the prevalence of hard
disks (or RAM disks), adding a disk access to a response time
seems tolerable.
-michael
NadaPong: Network game demo for Apple II computers!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
Oliver Schmidt
>>>DHCP??? Probably don't want this in RAM...
>Given the memory constraints, have you considered an overlay
>area for "transient" code? Considering the prevalence of hard
>disks (or RAM disks), adding a disk access to a response time
>seems tolerable.
The cc65 toolchain used for building Contiki doesn't have something
like an overlay linker. So any overlay approach would need to be
implemented manually - which was done in Contiki 1.x and made the
architecture quite complex - at least distracting enough that nobody
apart for the Contiki core team never implemented a single Contiki
application.
Contiki 2.x ist intentionally less cool and "sexy" but simpler. But I
believe that this is in many cases a benefit after all...
Maybe the DHCP is good example: Contiki 2.x reads by default a binary
config file on startup containing the IP (and other) settings.
Currently this file needs to be edited manually with a hex editor.
Obviously it would be nice to have an editor for that config file -
and that editor might have the option to "auto fill" the values by
DHCP. Surely this wouldn't be really "dynamic" but most likely just
good enough and still quite simple.
Best, Oliver
aiia...@gmail.com
> of what the Contiki core offers on top of uIP - and still miss the
> rest. In a nutshell my Contiki 2.x port claims to be "the better uIP"
> for cc65 targets.
Using Contiki 2.1, is it possible to have webclient.c download
multiple files
simultaneously, from different servers?
Can you tell me how to do it, or where to find docs?
Rich
Oliver Schmidt
>Using Contiki 2.1, is it possible to have webclient.c download
>multiple files
>simultaneously, from different servers?
Not out of the box...
>Can you tell me how to do it, or where to find docs?
...however:
The file in question declares the 'struct webclient_state' which is
exactly what you want. But then it defines one static variable 's'
which isn't what you want.
Options for changing that:
- an array instead of a single instance
- malloc() instances dynamically (the heap code is linked in anyway)
- use memory blocks (see core/lib/memb.c)
Then you'd adjust all occurances of 's.' with the appropriate
construct. Choosing the "right" connection could be done via a
parameter to the functions in question or "the Contiki way" by having
a single 'struct webclient_state' pointer which is set to the
"current" connection before calling one of the functions. In that case
you'd just have to replace 's.' with 's->'.
The reason why it is so simple is because the Contiki network core
handles multiple connections for sure! It's just the file in question
which doesn't as it was designed to be used with a single window text
browser or a 'wget' like file downloader.
BTW: The association of any type of application state with the Contiki
network core is done with tcp_markconn(uip_conn, <state pointer>).
You'll find it in the file in question...
Hope that helps, Oliver
aiia...@gmail.com
>
> Just in time for the Contiki 2.1 release I finished my port of the
> Contiki 2.x codebase to cc65 targets :-)
>
>
> - Windows/Cygwin or Un*x as test platform work out of the box
> - cc65 targets as target platform work out of the box
> - Several examples (including a web server) work out of the box
> - Both Uther and LANceGS work out of the box
With the help of Glenn Jones I was able to get the web server
to build. (more than help... He pretty much held my hand through
the whole process)
I had to use the snapshot version of CC65, the build that I had
from a year ago would not work. I followed the instructions
provided by Glenn at :
http://www.a2retrosystems.com/blog/?page_id=17
and built CC65.. It is easy to do, but takes a bunch of
steps and time (mostly waiting for it to build)
then I downloaded contiki source...
to build the webserver, I went to the
/contiki2.x/examples/webserver directory
I typed the command:
make TARGET=apple2enh
CC65 built the web server.
then I got the binary into a DSK image, and
it works as advertised...
the webserver can serve files from the prodos
file system!
Rich
Oliver Schmidt
>With the help of Glenn Jones I was able to get the web server
>to build. (more than help... He pretty much held my hand through
>the whole process)
Nice to read that you're actually checking out Contiki 2.1 :-)
>I had to use the snapshot version of CC65, the build that I had
>from a year ago would not work. I followed the instructions
>provided by Glenn at :
>
>http://www.a2retrosystems.com/blog/?page_id=17
>
>and built CC65.. It is easy to do, but takes a bunch of
>steps and time (mostly waiting for it to build)
Interesting. What OS are you using? cc65 comes as ready-built binaries
for several popular host platforms.
This is as well true for the snapshots! Everytime the cc65 source is
modified a build of the binaries is automatically triggered. So if
nothing goes wrong there are always binaries of the very latest
sources. At least I had never a reason to build cc65 on my own ...
>then I downloaded contiki source...
>
>to build the webserver, I went to the
>/contiki2.x/examples/webserver directory
>
>I typed the command:
>
>make TARGET=apple2enh
>
>CC65 built the web server.
>
>then I got the binary into a DSK image, and
>it works as advertised...
Thanks for the positive feedback :-)
>the webserver can serve files from the prodos
>file system!
The command you mentioned above won't actually build a webserver using
the ProDOS filesystem. For doing so the command is:
make TARGET=apple2enh HTTPD-CFS=1
Best, Oliver
a2retro
Hi Oliver,
>
> Interesting. What OS are you using? cc65 comes as ready-built binaries
> for several popular host platforms.
>
> This is as well true for the snapshots! Everytime the cc65 source is
> modified a build of the binaries is automatically triggered. So if
> nothing goes wrong there are always binaries of the very latest
> sources. At least I had never a reason to build cc65 on my own ...
>
This is probably just due to a lack of understanding on my part ....
Looking at the pre-built binaries for Windows, I noticed the paths
embedded in the zip file are not setup the way the install script would
normally install them under cygwin .. which is what the document is
describing.
I noticed there is vbs script to install the prebuilt binaries but I
just found it easier to download and build from source. It works for me
.. YMMV
Oliver Schmidt
>Looking at the pre-built binaries for Windows, I noticed the paths
>embedded in the zip file are not setup the way the install script would
>normally install them under cygwin .. which is what the document is
>describing.
I never used any install script so I can't comment on that.
>I noticed there is vbs script to install the prebuilt binaries but I
>just found it easier to download and build from source. It works for me
>.. YMMV
I always made sure to stay clear from that vbs script ;-) I just unzip
the binaries and that's all. I can't see any issue in that approach
nor can I imagine anything as simple.
Best, Oliver
aiia...@gmail.com
> Interesting. What OS are you using? cc65 comes as ready-built binaries
> for several popular host platforms.
windows XP, CYGWIN
>
>At least I had never a reason to build cc65 on my own ...
>
My copy from a year ago would not build the webserver,
it could not find string.h... downloading a prebuilt CC65
did not help (the latest version), so I built it myself with
Glenn's help.
Rich
aiia...@gmail.com
http://www.cs.york.ac.uk/rtslab/demos/readme/docs/pdf/contiki_refman.pdf
Is there a copy of the manual for Contiki 2.1 ?
I would like to hook into these routines, or have them call my
assembly
language program to draw on the HGR screen:
5.5 The CTK graphical user interface.
5.5.1 Detailed Description
The Contiki Toolkit (CTK) provides the graphical user interface for
the Contiki system.
Files
* file ctk.h
CTK header file.
* file ctk.c
The Contiki Toolkit CTK, the Contiki GUI.
* file ctk-draw.h
CTK screen drawing module interface, ctk-draw.
Modules
* groupCTK application functions
* groupCTK device driver functions
Functions
* void ctk_init (void)
Initializes the Contiki Toolkit.
* void ctk_mode_set (unsigned char mode)
Sets the current CTK mode.
* unsigned char ctk_mode_get (void)
Retrieves the current CTK mode.
* void ctk_window_new (struct ctk_window window, unsigned char w,
unsigned char h, char title)
Create a new window.
* void ctk_window_clear (struct ctk_window w)
Remove all widgets from a window.
* void ctk_window_close (struct ctk_window w)
Close a window if it is open.
* void ctk_window_redraw (struct ctk_window w)
Redraw a window.
* void ctk_dialog_open (struct ctk_window d)
Open a dialog box.
Generated on Thu Mar 25 10:50:06 2004 for Contiki 1.2 by Doxygen
Oliver Schmidt
>On Dec 15, 1:09=A0am, ol...@web.de (Oliver Schmidt) wrote:
>> Interesting. What OS are you using? cc65 comes as ready-built binaries
>> for several popular host platforms.
>
>windows XP, CYGWIN
That's exactly what I use myself...
>My copy from a year ago would not build the webserver,
>it could not find string.h... downloading a prebuilt CC65
>did not help (the latest version), so I built it myself with
>Glenn's help.
I presume that you have generally set the three environment variables
CC65_INC, LD65_LIB and LD65_OBJ.
But in the environment we both use the interesting question is their
actual content:
If you use an absolute Windows path like C:/... then gnumake will fail
in rebuilds to process the dependencies generated by cc65 as the ':'
is supposed to separate the target from the prerequisites.
If you use an absolute Cygwin path like /cygdrive/c/... then cc65 will
fail right away as it (at least as prebuilt binary) doesn't use the
Cygwin runtime library and theirfore doesn't know about Cygwin paths
at all.
The only thing that works for me (although not very elegant) are
relative paths starting with '../../../...'. However if you don't use
cc65 for lots of different projects than this isn't an issue.
Best, Oliver
Oliver Schmidt
>http://www.cs.york.ac.uk/rtslab/demos/readme/docs/pdf/contiki_refman.pdf
>
>Is there a copy of the manual for Contiki 2.1 ?
Nope :-( I'd propose to check out the source first and only then look
into the PDF after understand it's relevance.
>I would like to hook into these routines, or have them call my
>assembly
>language program to draw on the HGR screen:
I already thought about that...
BTW: Adam Dunkels wrote a ctk implementation using gtk (www.gtk.org)
to draw on an X Server surface.
ctk consists of two layers:
>* file ctk.h
>* groupCTK application functions
This is the upper layer. It defines the ctk functions to be used by
applications. They are very well suited for a web browser as they
allow to dynamically create widgets and place them on the screen,
which is exactly what a web browser needs when it comes to draw a
form. This layer defines the behaviour of widgets like the editing
facilities of the textentry widget.
>* file ctk-draw.h
>* groupCTK device driver functions
This is the lower layer. It is never called directly but only from the
upper layer. It defines functions for drawing the widgets on the
screen. These functions are not like draw_line() or draw_rect() but
rather like draw_button() or draw_textentry() so they can freely
define the look.
You may wonder why I'm only talking about widgets and not about
windows. In general ctk contains windows management facilities like
z-order handling etc. But recently (after the Contiki 2.1 snapshot) I
added the option to use ctk in a "fullscreen" mode with just one
(invisible) window. This significantly reduces the memory footprint -
and the reduces greatly the stuff to be actually implemented in the
lower layer, as there's no need to draw window borders, window titles
and alike.
The Contki web browser already runs in that fullscreen mode, so you
could use this combination as a starting point for a graphical browser
by first replacing the ctk drawing layer 1:1 and then extend the HTML
parser to fit your needs.
Nevertheless there's one downside with using ctk for a graphical
environment. All coordinates are character based, not pixel based.
Surely it's no rocket sience to change that as ctk more or less only
passes coordinates given by the application to the drawing layer.
Anyway you wouldn't be able to use the stuff as-is.
I personally think nevertheless that using Contiki not only for
network i/o but also for implementing the web browser core is a very
promising approach. In fact your project was one of the key drivers
for me to implement the fullscreen mode.
Best, Oliver
aiia...@gmail.com
> On Mon, 24 Dec 2007 10:36:44 -0800 (PST), aiiad...@gmail.com wrote:
>
> >Is there a copy of the manual for Contiki 2.1 ?
>
> Nope :-( I'd propose to check out the source first and only then look
> into the PDF after understand it's relevance.
Ok.. Did it change drastically from 1.2 to 2.1? I'll find out after
looking
at source..
> >I would like to hook into these routines, or have them call my
> >assembly
> >language program to draw on the HGR screen:
>
> I already thought about that...
What did you think?
> BTW: Adam Dunkels wrote a ctk implementation using gtk (www.gtk.org)
> to draw on an X Server surface.
Interesting... I am over my head playing with contiki, so I'll stick
to
it for now. One source code that isn't mine is too much for my small
mind to understand :-P (I can't even understand my own code
sometimes :-))
> ctk consists of two layers:
>
> >* file ctk.h
> >* groupCTK application functions
>
> This is the upper layer. It defines the ctk functions to be used by
>applications <snip>
ok, thanks for explanation.. So ctk.h, the upper layer, will probably
be
left as-is for the most part.
>
> >* file ctk-draw.h
> >* groupCTK device driver functions
>
> This is the lower layer. It is never called directly but only from the
> upper layer. It defines functions for drawing the widgets on the
> screen.
Ok, so this is what I'd have to modify...
> You may wonder why I'm only talking about widgets and not about
> windows. In general ctk contains windows management facilities like
> z-order handling etc.
Ok, Z order like window depth...
>But recently (after the Contiki 2.1 snapshot) I
> added the option to use ctk in a "fullscreen" mode with just one
> (invisible) window. This significantly reduces the memory footprint -
> and the reduces greatly the stuff to be actually implemented in the
> lower layer, as there's no need to draw window borders, window titles
> and alike.
Ok... You added "fullscreen" mode... What is build command to
force fullscreen or windowed mode?
> The Contki web browser already runs in that fullscreen mode, so you
> could use this combination as a starting point for a graphical browser
> by first replacing the ctk drawing layer 1:1 and then extend the HTML
> parser to fit your needs.
Ok...
> Nevertheless there's one downside with using ctk for a graphical
> environment. All coordinates are character based, not pixel based.
> Surely it's no rocket sience to change that as ctk more or less only
> passes coordinates given by the application to the drawing layer.
> Anyway you wouldn't be able to use the stuff as-is.
I'll be looking at the source later today. I was thinking about this
as I typed my original question. I could either force 80/40 columns
to the HGR screen using fixed width fonts and 1 character scrolling,
or modify ctk-draw.h to forget about 40/80 columns...
> I personally think nevertheless that using Contiki not only for
> network i/o but also for implementing the web browser core is a very
> promising approach. In fact your project was one of the key drivers
> for me to implement the fullscreen mode.
Ok, you have my interest. Your implementation is a key driver for me
to get graphical web browser to work with contiki 2.1 using the CTK
Rich
Oliver Schmidt
>Ok... You added "fullscreen" mode... What is build command to
>force fullscreen or windowed mode?
Fullscreen: Define CTK_CONF_WINDOWS to be 0.
Windowd: Define CTK_CONF_WINDOWS to be 1 or just don't define it at
all.
You'll need to get the recent source via anonymous CVS access in order
to do that.
>Ok, you have my interest. Your implementation is a key driver for me
>to get graphical web browser to work with contiki 2.1 using the CTK
Great :-)
Best, Oliver