retrohackers.org
http://retrohackers.org/

Contiki 2.1 released
http://retrohackers.org/viewtopic.php?f=5&t=311		 Page 1 of 6
Author:  Oliver [ Wed Dec 05, 2007 1:31 am ]
Post subject:  Contiki 2.1 released
Hi,

My name is Oliver Schmidt and I'm the author of the Contiki 1.x port to the Apple2. Judging from the content in this forum I presume that you might be interested in the following:

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-even ... eased.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 the Contiki 1.x ports to 6502 targets !

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 applications on the C64. 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 some people tend to go for uIP (or other alternatives) 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
- RR-Net, TFE and ETH64 are supposed to 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

Have fun, Oliver
Author:  MagerValp [ Wed Dec 05, 2007 1:06 pm ]
Post subject: 
Wow, very very nice. Developing TCP/IP applications just got a lot easier!
Author:  RaveGuru [ Wed Dec 05, 2007 2:08 pm ]
Post subject: 
Wonderful news!

@Oliver: Are there any major changes to the uIP code base from Contiki 1.2 to 2.1?
Author:  hollowman [ Thu Dec 06, 2007 10:47 am ]
Post subject: 
Nice! I built the webserver on a windows machine using gnumake and it worked fine, however I still have problems with getting it to work with rr-net.
retro replay+rr-net didnt work
mmc64 + rr-net didnt work
mmc64 + retro replay + rr-net worked

How's it working for other people? Also I couldnt get it to run from mmc64 using the kernal mode in the dreamload plugin. I havent looked at the code, but I guess the webserver only uses the cc65 library for file access, or?
Author:  Oliver [ Thu Dec 06, 2007 11:32 am ]
Post subject: 
Hi,

First of all I'd like to point out that I just uploaded an image containing the Contiki 2.1 example webserver in order to allow for easy testing - and that I explicitly ask for feedback !

@MagerValp, RaveGuru:

Thanks for the positive feedback :-)

@RaveGuru:

There were no changes justifying an update of an existing application. However for new application development I'd certainly go for the new codebase because of the very useful protothreads/protosockets abstraction layer.

@hollowman:

Thanks for actually checking out Contiki 2.1 - and the positive feedback on the build process :-)

Regarding the network I/O: I didn't write the CS8900A driver according to the specs but by modifying existing - supposed to be working - code. Maybe someone can look at the code and point out a flaw:

http://contiki.cvs.sourceforge.net/*che ... vision=1.3 (or look into the released zip file)

Regarding the file I/O: Yes, in contrast to Contiki 1.2 there are no special hacks, just the plain cc65 C-Library calls open/read/close. To be honest I was thinking that this would be the most compatible solution possible ?!?

Unfortunately I have about no C64 knowledge but looking at the cc65 C-Library source code it seems to use "disk command channels" to implement open/read/close - for what every that means / helps...

Best, Oliver
Author:  Devia [ Thu Dec 06, 2007 1:42 pm ]
Post subject: 
Oliver wrote:
Maybe someone can look at the code and point out a flaw:


Well, you need to either detect or hardcode a config for which Clock-Port the RR-Net is located at and then take the proper steps to enable that particular Clock-Port.
Now, I only looked briefly at the code, but it seems that the config is read from some file, right? To avoid a HW detection algo, you could put some config bytes in that file saying something about which Clock-Port address on which expansion card the RR-Net is located.
Author:  hollowman [ Thu Dec 06, 2007 2:09 pm ]
Post subject: 
Devia wrote:
Now, I only looked briefly at the code, but it seems that the config is read from some file, right? To avoid a HW detection algo, you could put some config bytes in that file saying something about which Clock-Port address on which expansion card the RR-Net is located.

The config file contains the adress of the rr-net. But my previous experience was that setting the clockport adress didnt help with the hardware setups that didnt work.
Author:  hollowman [ Thu Dec 06, 2007 2:30 pm ]
Post subject: 
Oliver wrote:
Regarding the file I/O: Yes, in contrast to Contiki 1.2 there are no special hacks, just the plain cc65 C-Library calls open/read/close. To be honest I was thinking that this would be the most compatible solution possible ?!?

Unfortunately I have about no C64 knowledge but looking at the cc65 C-Library source code it seems to use "disk command channels" to implement open/read/close - for what every that means / helps...

Yeah, it should be the most compatible solution, and I got contiki 1.2 to load from mmc64 by just using the kernal mode in the dreamload plugin, so I was surprised that it didnt work in 2.1
Author:  Oliver [ Thu Dec 06, 2007 9:48 pm ]
Post subject: 
hollowman wrote:
Oliver wrote:
Unfortunately I have about no C64 knowledge but looking at the cc65 C-Library source code it seems to use "disk command channels" to implement open/read/close - for what every that means / helps...

Yeah, it should be the most compatible solution, and I got contiki 1.2 to load from mmc64 by just using the kernal mode in the dreamload plugin, so I was surprised that it didnt work in 2.1

Sorry but I don't even know what "kernal mode" and "dreamload plugin" means and how/if it relates to my previous statement about "disk command channels" :-(

Best, Oliver
Author:  Oliver [ Thu Dec 06, 2007 10:11 pm ]
Post subject: 
hollowman wrote:
Devia wrote:
Now, I only looked briefly at the code, but it seems that the config is read from some file, right? To avoid a HW detection algo, you could put some config bytes in that file saying something about which Clock-Port address on which expansion card the RR-Net is located.

The config file contains the adress of the rr-net. But my previous experience was that setting the clockport adress didnt help with the hardware setups that didnt work.

Sorry but I have no idea what you are talking about when it comes to "clock-port address" and "expansion card location" :-(

Up to now I was under the - obviously quite naive - impression that TFE and RR-Net only differ in the locations of the mapping of the CS8900A chip I/O ports:

TFE
rxtxreg = $de00
txcmd = $de04
txlen = $de06
packetpp = $de0a
ppdata = $de0c

RR-Net
rxtxreg = $de08
txcmd = $de0c
txlen = $de0e
packetpp = $de02
ppdata = $de04

The address my config file contains allows to switch between those two mappings: $de00 for TFE, $de08 for RR-Net which means that you basically specify the address of the rxtxreg.

So if there is anything beyond that which is specific to RR-Net I'd appreciate any help on understanding like i.e. pointers to driver code doing "it" right.

Best, Oliver
Author:  zap [ Fri Dec 07, 2007 9:52 am ]
Post subject:  rrnet
hollowman wrote:
Nice! I built the webserver on a windows machine using gnumake and it worked fine, however I still have problems with getting it to work with rr-net.
retro replay+rr-net didnt work
mmc64 + rr-net didnt work
mmc64 + retro replay + rr-net worked

How's it working for other people? Also I couldnt get it to run from mmc64 using the kernal mode in the dreamload plugin. I havent looked at the code, but I guess the webserver only uses the cc65 library for file access, or?


You got it to work by plugging the rrnet into the retoreplay then the retoreplay into the mmc card ??

This will not work for me.


I have tried contiki 2.1 on 3 c64s with The RRNet plugged into the RetroReplay as well as the RRNet Plugged into the MMC64.

I so far have not been able to make it work i feel the problem is in the clock bus whats your idea.

I would love to see this work for someone so i can emulate it.

:) this port is very good news

:) Oliver thanks.
Author:  zap [ Fri Dec 07, 2007 10:10 am ]
Post subject:  TFE
Oliver wrote:
Up to now I was under the - obviously quite naive - impression that TFE and RR-Net only differ in the locations of the mapping of the CS8900A chip I/O ports:

Best, Oliver


You think Contiki 2.1 would work on a TFE card ?
Author:  Oliver [ Fri Dec 07, 2007 10:21 am ]
Post subject:  Re: TFE
zap wrote:
You think Contiki 2.1 would work on a TFE card ?

First all I need to point out that it's in fact about thinking, not knowing!

With my - as I'm learing the hard way - very limitted CBM Ethernet knowhow, I'd guess that it works with a TFE card for two reasons:

1. The driver I modified was originally written for the TFE - as least as far as I understand.

2. The TFE seems to be built around some embedded CS8900A solution by just adding some glue logic. The Apple2 Uther card is built just the same way - and the driver _DOES_ work with the Uther card on the Apple2.

Best, Oliver
Author:  MagerValp [ Fri Dec 07, 2007 11:11 am ]
Post subject: 
Oliver wrote:
Sorry but I have no idea what you are talking about when it comes to "clock-port address" and "expansion card location" :-(

Up to now I was under the - obviously quite naive - impression that TFE and RR-Net only differ in the locations of the mapping of the CS8900A chip I/O ports:

TFE
rxtxreg = $de00
txcmd = $de04
txlen = $de06
packetpp = $de0a
ppdata = $de0c

RR-Net
rxtxreg = $de08
txcmd = $de0c
txlen = $de0e
packetpp = $de02
ppdata = $de04


The RR-Net registers are only visible after you write $01 to $de01, when connected to a Retro Replay. It's something else if you have an RR-Net connected to an MMC64, but I'm not sure what it is.
Author:  Devia [ Fri Dec 07, 2007 1:11 pm ]
Post subject: 
It's the same with MMC64, you have to "Enable" the clock port by setting bit 0 of $de01 or $df21 depending on where you have mapped the clock-port to.

Here is an example of how you "could" detect and enable RR-Net if it is mounted on either RR or MMC64 or on RR mounted on MMC64... very confusing... If RR-Net is mounted on BOTH, it will enable the one on the MMC64.. I have no idea how this would behave if you mix in a Port Expander, tho..

Code:
.proc RRNetDetect
   lda   #%00000100
   ora   $00
   sta   $00
   lda   #%00000100
   ora   $01
   sta   $01         ;Make sure I/O is mapped in at D000-DFFF
   
CheckForRRNetOnMMC64
   lda   #$0a      ;Re-Enable MMC64 if it was disabled
   sta   $df13      ;-
   lda   #$1c      ;-
   sta   $df13      ;-
   lda   #%00001011   ;External ROM + CARDSEL + Map I/O to $df20
   sta   $df11      ;Set on MMC64
   lda   #$01         ;Enable Clock Port on MMC64
   sta   $df21         ;-
   lda   #%00000011      ;External ROM + CARDSEL + Map I/O to $de00
   sta   $df11      ;Set on MMC64

   RRNetReadReg   PP_ProductIDCode ;Try to read the ProductIDCode from RR-Net
   
   cpx   #<$0e63 ; EISAID
   bne   noRRNetOnMMC64
   cpy   #>$0e63
   beq   RRNetFound
noRRNetOnMMC64
   lda   #%00001011   ;External ROM + CARDSEL + Map I/O to $df20
   sta   $df11      ;Set on MMC64
   lda   #$00         ;Disable Clock Port on MMC64
   sta   $df21
   
CheckForRRNetOnRR
   lda   $de00
   and   #%11111010
   ora   #%00000001
   sta   $de01         ;Enable Clock Port on RR
   and   #%10011000
   sta   $de00

   RRNetReadReg   PP_ProductIDCode ;Try to read ProductIDCode from RR-Net
   
   cpx   #<$0e63      ;Check if first 2 bytes of ProductIDCode
   bne   noRRNetOnRR      ;matches EISA ID for Crystal Semiconductor
   cpy   #>$0e63
   beq   RRNetFound
noRRNetOnRR
   lda   #0
   clv
   bvc   Return
   
RRNetFound
   RRNetReadReg   PP_ProductIDCode+2   ;Read Product ID and Revision
   txa

Return
   rts
.endproc


Short functional description for the non-code junkies:
1: Make sure MMC64 is enabled
2: map MMC64 clockport to $df20 and enable it. This is to make SURE that it is the MMC64 clock-port we are enabling and not the one on RR
3: Map clock port on MMC64 back to $de00 - my RRNet read/write functions only support $de00
4: Try to read from the RR-Net
5: If unsuccessful there is no RR-Net on the MMC64 or no MMC64 at all.
6: Map the MMC64 clockport back to $df20 and disable it. In case there IS an MMC64 but no RR-Net on it.
7: Enable clockport on Retro Replay
8: Try to read from the RR-Net
9: If unsuccessful there is no RR-Net on the Retro Replay either...

The function returns the CS8900A Revision in A if it finds a RR-Net or returns 0 in A if no RR-Net was detected.

..maybe this routine should start by disabling the Retro Replay clock-port... I dunno... Depends on it's initial state, which I don't know about in the case of Contiki. In fact, I don't know anything about any other bits that might need clearing/setting on RR or MMC64 in the Contiki case.. It all depends on how contiki is started and how it may or may not initialize the HW I guess.

oh.. almost forgot, my RRReadReg Macro looks like this, in case you were wondering:

Code:
.macro RRNetReadReg addr,dest
   lda   #<(addr)
   sta   $de02
   lda   #>(addr)
   sta   $de03
   ldy   $de08
   ldx   $de09
.ifnblank dest
   sty   dest
   stx   dest+1
.endif
.endmacro


This detection/enabling routine doesn't seem to work on IDE64 systems according to Schema.. I fail to see why :(

..btw.. tabs2spaces conversion in the code field kinda sux :(
Page 1 of 6 All times are UTC [ DST ]
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/