Hi,

1. The RetroReplay clockport activation IS part of the Contiki driver for the RR-Net. However the MMC64-specific stuff IS NOT.

2. Contiki 2.x for 6502 machines uses a binary configuration file called contiki.cfg. I've created an online generator for this file: http://www.a2retrosystems.com/contiki.htm.

3. The general desktop stuff in the Contiki 2.x codebase was broken because the Contiki project in general moves on to different areas. I repaired it to make sure that Contiki 2.x desktop stays a valid option. The test and demo environment is the Win32 console environment. The same is true for the dynamic loader using *.PRG and *.DSC files: Broken -> Repaired -> Win32 console as test environment.

So why isn't there a Contiki 2.x C64 desktop? Simply because I don't see a point in doing so. The Contiki desktop apps didn't receive any improvement since 1.x so it would be a significant amout of work yielding something already available.

In fact it would be hard to even archive the Contiki 1.x state as there are quite some C64 specific hacks written in assembler in the 1.x codebase: Graphics mode desktop, file and directory I/O, mouse support, screen savers, ... All this stuff isn't present in the 2.x codebase anymore and would need to be ported - just to get to the same result as with 1.x

However I thought that there could be something in between the 1.x desktop and the current "non-UI" server-type 2.x apps: Standalone UI client-type apps !

Why that? The C64 doesn't have enough memory to load more than one significant UI app from the desktop. So it might after all make more sense to have standalone UI apps loaded directly from the BASIC prompt. That allows to omit all the dynamic loading code, the window management code and the menu handling code. So I created a Contiki 2.x build option to have a single UI app running in "fullscreen mode". This is a single statically linked binary containing both the "lightweight fullscreen desktop" and the application itself. Again I tested this initially in the Win32 console environment.

Then I ported this approach to the C64 (and Apple2). In contrast to 1.x this time without special assembler hacks but rather making consequent use of cc65 assets: The UI runs in text mode completely relying on the cc65 conio library.

Obviously the by far most interesting UI app is the web browser. As a standalone text mode fullscreen app it uses much less memory than inside the 1.x desktop so I was able to activate the mouse support existing both in the 1.x and 2.x codebase. And here again no assembler hacks but usage of the stock cc65 loadable mouse drivers!

Sounds great so far - doesn't it? The Contiki web browser as a simple app with mouse support running both on the C64 and the Apple2 with only a handful of machine specific code

The issue is that there's a nasty bug that I'm just not able to find:
- Contiki 1.x C64 web browser: fine
- Contiki 2.x C64 web server: fine
- Contiki 2.x Win32 web browser: fine
- Contiki 2.x C64 web browser: lots of lost ethernat packets

If someone is willing to tackle with that it would be just great. I'd certainly be able to assist in using the Contiki 2.x build system to generate the standalone web browser app.

Best, Oliver

Thank you, Oliver, for your information on Contiki 2.x.



This could explain my problems, as I use both, RetroReplay and MMC64 on my c64 (c64 --> MMC64 --> RetroReplay).



Yay! That's just what I needed, thank you!



Makes sense, I mean despite GEOS, most apps I used on the c64 were standalone applications anyway. You had a sprite editor, a text editor, some small address database ... they were all standalone. So this shouldn't be too much of an "acceptance problem" to most long-time c64 users.

_________________
LOAD ":*",8,1
READY.
RUN

I am creating a contiki friendly website on c64web.com its also runs from a
commodore 64 so it will be interesting "a c64 serving a c64"

Be ready in a few days as i have finally got time to take a breath
from work etc.

Have Fun Shane

_________________
Commodore 8bit Web Services http://cbm8bit.com
Try our new browser driven disk image editor.

You're welcome

Best, Oliver

Just to proof that the Contiki 2.x standalone fullscreen webbrowser with mouse support isn't vaporware (and potentially for motivation purposes) please find attached a screenshot. Please note the status line showing the URL the mouse pointer is over.

Best, Oliver

Nice job Oliver!
Well guys, there's something to work on!

Hmm ... I just tried to compile Contiki-2.1 (latest release) and I get this when compiling the webserver example using make TARGET=c64:

cpu/6502/./mtarch.c -o obj_c64/mtarch.s
../../cpu/6502/./mtarch.c(68): Error: Incompatible pointer types
../../cpu/6502/./mtarch.c(113): Warning: Parameter `thread' is never used
make: *** [obj_c64/mtarch.o] Error 1

Is it me, the Contiki-2.1 sourcecode or my cc65 version (2.12.9_apr08 snapshot) ? Do I need to patch something here? Any help is appreciated!

Oh, BTW: the cc65 2.11.9 release causes the same problem. It also happens when I try to compile the hello-world example.

EDIT: Oliver helped me out here, now everything works - thanks again!

_________________
LOAD ":*",8,1
READY.
RUN

I recognize this problem but I don't remember the cause. What was it?

I used the Contiki 2.1 "download" release insted of the CVS release. There must be something broken int the download version, that is now fixed in CVS but not yet released officially. I am already playing around with some of the telnet-server / shell code. Contiki really has a lot to offer. I wonder, if it's possible to do disk i/o? Or is that not implemented yet for the c64 taget?

_________________
LOAD ":*",8,1
READY.
RUN

Disk I/O is both used by Contiki internally (i.e. for reading the 'contiki.cfg' and loading the *.eth drivers) and by Contiki apps (i.e. the file-based web server and the file-related commands of the telnet-shell).

Best, Oliver

Well, the cfs_read command works, but it seems like you can't write data to a file (on the c64 platform, native and with VICE) using cfs_write. I've attached my example code, feel free to try it. It just won't work.

_________________
LOAD ":*",8,1
READY.
RUN

This may not be the right place for it, but I've got a question about Contiki/VICE. I downloaded the 'Instant Contiki Development Environment 1.0a' ubuntu dev environment in hopes of messing around with Contiki and C64 emulation via VICE.

Now the VICE included with the IDE doesn't have networking enabled. So I (eventually ) got the right libraries required for VICE compilation with network support, and compiled a version that had networking enabled.

I used Oliver's 2.1 image posted here and tried Contiki networking with VICE set to TFE, RR-net etc with no luck. RR-net seemed to work on the C64 side, but no network data was being passed. So is VICE networking the culprit? I know that it's broken a bit, but not to what extent.

To have ethernet enabled for VICE on Linux, you must have libpcap and libnet installed and VICE must be run as "root" user (e.g. via sudo). See this document for more information on this topic.

However, I've also built my VICE (on Ubuntu 8.04) from source, with the ethernet build option enabled. I've also installed libpcap and libnet and ran VICE as root user. Still, there's no ethernet available in the Linux build (but it works with WinVICE). So even if you follow the instructions given above, ethernet functionality may still be absent in the Linux version of VICE. And I wouldn't wonder if it was disabled for security reasons, as running such an app as root user *is* a security risk.

Small hint: try to use the latest cc65 (e.g. 2.12.0) release along with the CVS version of Contiki 2.1. It may be a bit more complex to create a proper build environment that way, but compiling cc65 and checking out Contiki 2.x really is no big deal. And that way you always have the latest sourcecode of Contiki 2.x available through CVS.

_________________
LOAD ":*",8,1
READY.
RUN

Yeah, it's quite tricky (and frustrating) to get the ethernet emulation running on Vice/Linux. Be very meticulous about build warnings. The make script generally ignores them and builds without failure (and without ethernet) !

You have to make sure that (on Ubuntu Linux 8.04) you use libnet0 and libnet0-dev, not libnet1/libnet1-dev. If so, get libnet0/libnet0-dev and recompile. That's how I got it compiled in (the option is now available). Still it's not working ... hmm ... what memory address and which IP address (is it the same as the host system e.g. the linux box?) do I have to set? On my C64 it's $DE08 but I don't know what to do within VICE ...

_________________
LOAD ":*",8,1
READY.
RUN