It is currently Mon Oct 14, 2019 9:48 am

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 13 posts ] 
Author Message
PostPosted: Fri May 10, 2019 6:40 pm 
Offline

Joined: Wed Dec 05, 2007 2:15 am
Posts: 90
Hi,

So far both Contiki and IP65 used a single driver for a single type of Ethernet chip, no matter in which device the chip was installed. So e.g. the CBM RR-Net, the Apple II Uthernet and the ATARI Dragon Cart all used the same CS8900A driver. This was sort of cool, but the user didn't have any benefit from it. On the other hand it prevented me from supporting features specific to a specific device.

Therefore I recently changed all this for both Contiki and IP65. Now there are individual drivers built for the individual devices. This allowed me to add specific support for the RR-Net MK3 to the CBM CS8900A driver. But what does "specific support" mean here?

No matter if the RR-Net MK3 is connected it to the clockport of a carrier-card or if it is plugged directly to the expansion port, its unique MAC address is used by all Contiki and IP65 programs instead of the default MAC address built into the programs.

Some additional notes:

The unique MK3 MAC address has the format 28:CD:4C:FF:??:??. If you do not use an RR-Net MK3 but want Contiki and IP65 programs to use a unique MAC address then make sure that the CS8900A chip already contains a MAC address in the format 28:CD:4C:FF:??:?? by the time the Contiki or IP65 programs start.

So far the default MAC address built into the Contiki and IP65 programs was 00:0E:3A:11:11:11. Now it is 00:0E:3A:64:64:64 (and 00:0E:3A:28:28:28 for the Contiki C128 programs).

Other programs using IP65 just need to link the new IP65 libraries to get the RR-Net MK3 support. Because of optimizations made possible by building individual Ethernet drivers the IP65 libraries now require less memory despite the new feature.

Contiki:
https://github.com/oliverschmidt/contik ... 2019-05-08

IP65:
https://github.com/cc65/ip65/releases/tag/2019-05-10

Have fun,
Oliver


Top
 Profile  
Reply with quote  
PostPosted: Mon Jul 01, 2019 5:50 pm 
Offline

Joined: Thu May 17, 2007 3:00 pm
Posts: 105
Location: Duesseldorf, Germany
Hi Oliver,
how does this change affect my build which relies on upstream Contiki? Or to put it another way: can I make use of these drivers when compiling my code against vanilla Contiki OS?

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


Top
 Profile  
Reply with quote  
PostPosted: Tue Jul 02, 2019 7:00 pm 
Offline

Joined: Wed Dec 05, 2007 2:15 am
Posts: 90
Hi,

My expectation is that every program built upon/against the most recent Contiki will behave as described above. And as mentioned above the new drivers are smaller so there should be no issues from that perspective. The only thing to take into account as CBM coder is, that there's no support for the TFE anymore. Ah... the contiki.cfg file format has changed but as far as I understand this doesn't hurt on the CBM as the new CBM drivers ignore the part that has changed.

Regards,
Oliver


Top
 Profile  
Reply with quote  
PostPosted: Tue Jul 02, 2019 9:04 pm 
Offline

Joined: Thu May 17, 2007 3:00 pm
Posts: 105
Location: Duesseldorf, Germany
Okay, so these changes are already included in the vanilla (github) Contiki OS sources? I used your source tarball and my stuff compiled just fine and there still is a cs8900a.eth, lan91c96.eth and w5100.eth driver after building everything. So these are now "platform specific" ?

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


Top
 Profile  
Reply with quote  
PostPosted: Wed Jul 03, 2019 12:27 am 
Offline

Joined: Wed Dec 05, 2007 2:15 am
Posts: 90
> Okay, so these changes are already included in the vanilla (github) Contiki OS sources?

The changes are in https://github.com/oliverschmidt/contiki, but _not_ in https://github.com/contiki-os/contiki. The latter is dead, I don't see a point anymore in pushing my changes there.

> there still is a cs8900a.eth, lan91c96.eth and w5100.eth driver after building everything.

That's a bad sign! There shouldn't be a w5100.eth anymore for the CBM.

> So these are now "platform specific" ?

Yes, I saw reasons to rename them but I saw more reasons to keep the names. Check out e.g. https://github.com/oliverschmidt/contik ... #L367-L368 to see that the build generates separate files for each platform which are only renamed during the final step of putting the files into disk images.

BTW: The easiest way to check that you have the new drivers is the changed default MAC address (see my original post).


Top
 Profile  
Reply with quote  
PostPosted: Wed Jul 03, 2019 10:24 am 
Offline

Joined: Thu May 17, 2007 3:00 pm
Posts: 105
Location: Duesseldorf, Germany
Oliver wrote:
> Okay, so these changes are already included in the vanilla (github) Contiki OS sources?

The changes are in https://github.com/oliverschmidt/contiki, but _not_ in https://github.com/contiki-os/contiki. The latter is dead, I don't see a point anymore in pushing my changes there.

[...]

BTW: The easiest way to check that you have the new drivers is the changed default MAC address (see my original post).


Just switched to your Contiki OS repo and re-compiled, then checkd MAC address - now I'm up to date! Thanks for the info!!

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


Top
 Profile  
Reply with quote  
PostPosted: Wed Jul 03, 2019 1:26 pm 
Offline

Joined: Wed Dec 05, 2007 2:15 am
Posts: 90
You're welcome - and thanks for the feedback :-)


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 14, 2019 10:51 am 
Offline

Joined: Thu May 17, 2007 3:00 pm
Posts: 105
Location: Duesseldorf, Germany
Hi Oliver,
I wanted to play around with ip65 and got the sources from github. The libs compile fine, but the apps compile fails with date65 throwing an error:

make[2]: Verzeichnis „/home/nhaede/Downloads/ip65-2019-05-10/drivers“ wird verlassen
cl65 -o date65.prg -Or -t c64 -m date65.c64.map -vm date65.c ../ip65/ip65.lib ../drivers/ip65_c64.lib
date65.c(55): Error: Variable `time' has unknown size
date65.c(102): Error: Struct/union has no field named `tv_sec'
date65.c(102): Error: Invalid lvalue in assignment
date65.c(103): Error: Struct/union has no field named `tv_sec'
date65.c(110): Error: Struct/union has no field named `tv_sec'
date65.c(110): Error: Invalid lvalue in assignment
date65.c(110): Warning: Statement has no effect
date65.c(110): Error: `;' expected
date65.c(110): Error: Expression expected
date65.c(110): Warning: Statement has no effect
date65.c(110): Error: `;' expected
date65.c(110): Warning: Statement has no effect
date65.c(112): Error: Struct/union has no field named `tv_sec'
date65.c(112): Error: Illegal address
date65.c(112): Fatal: Too many errors
make[1]: *** [Makefile:103: date65.prg] Fehler 1
make[1]: Verzeichnis „/home/nhaede/Downloads/ip65-2019-05-10/apps“ wird verlassen
make: *** [Makefile:44: ip65.d64] Fehler 2

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Jul 14, 2019 10:08 pm 
Offline

Joined: Wed Dec 05, 2007 2:15 am
Posts: 90
I'm pretty sure that this is because your cc65 isn't recent "enough". As a general guideline it's always best to start any work with Contiki and/or IP65 with updating cc65.


Top
 Profile  
Reply with quote  
PostPosted: Mon Jul 15, 2019 10:32 am 
Offline

Joined: Thu May 17, 2007 3:00 pm
Posts: 105
Location: Duesseldorf, Germany
You were right, I updated to cc65 2.18 and now the code from your git repo compiles. However, while the libs build without a problem, there are some issues packaging the stuff:

C1541 variable is missing from the Makefile in apps/ directory - causing the error below. The call below should be "c1541 format ip65,00 d64 ip65.d64".

I fixed this by adding C1541 = <path to tool> to the apps/Makefile:

make[2]: Verzeichnis „/home/nhaede/src/contrib/ip65/drivers“ wird verlassen
cl65 -o date65.prg -Or -t c64 -m date65.c64.map -vm date65.c ../ip65/ip65.lib ../drivers/ip65_c64.lib
cl65 -o hfs65.prg -Or -t c64 -m hfs65.c64.map -vm hfs65.c ../ip65/ip65_tcp.lib ../drivers/ip65_c64.lib
ca65 -o telnet65.s.o telnet65.s
ld65 -o telnet65.prg -C c64.cfg -m telnet65.c64.map -vm telnet65.s.o ../ip65/ip65_tcp.lib ../drivers/c64combo.lib c64.lib
cl65 -o tweet65.prg -Or -t c64 -m tweet65.c64.map -vm tweet65.c ifttt.c ../ip65/ip65_tcp.lib ../drivers/ip65_c64.lib
format ip65,00 d64 ip65.d64
make[1]: format: Command not found
Makefile:112: recipe for target 'ip65.d64' failed
make[1]: [ip65.d64] Error 127 (ignoriert)
attach ip65.d64 -write date65.prg date65,p
make[1]: attach: Command not found
Makefile:112: recipe for target 'ip65.d64' failed
make[1]: [ip65.d64] Error 127 (ignoriert)
attach ip65.d64 -write hfs65.prg hfs65,p
make[1]: attach: Command not found
Makefile:112: recipe for target 'ip65.d64' failed
make[1]: [ip65.d64] Error 127 (ignoriert)
attach ip65.d64 -write telnet65.prg telnet65,p
make[1]: attach: Command not found
Makefile:112: recipe for target 'ip65.d64' failed
make[1]: [ip65.d64] Error 127 (ignoriert)
attach ip65.d64 -write tweet65.prg tweet65,p
make[1]: attach: Command not found
Makefile:112: recipe for target 'ip65.d64' failed
make[1]: [ip65.d64] Error 127 (ignoriert)
rm telnet65.s.o
make[1]: Verzeichnis „/home/nhaede/src/contrib/ip65/apps“ wird verlassen
cp apps/ip65.d64 ip65.d64
cp: Aufruf von stat für 'apps/ip65.d64' nicht möglich: Datei oder Verzeichnis nicht gefunden
Makefile:46: recipe for target 'ip65.d64' failed
make: *** [ip65.d64] Error 1


Also, packing up Apple II disk images sems to fail:

make[2]: Verzeichnis „/home/nhaede/src/contrib/ip65/drivers“ wird verlassen
cl65 -o wget65.bin -Or -t apple2enh -m wget65.a2.map -vm wget65.c w5100.c linenoise.c ../ip65/ip65.lib ../drivers/ip65_apple2_uther2.lib
cl65 -o date65.bin -Or -t apple2enh --start-addr 0x0C00 apple2enh-iobuf-0800.o -m date65.a2.map -vm date65.c ../ip65/ip65.lib ../drivers/ip65_apple2.lib
cl65 -o hfs65.bin -Or -t apple2enh --start-addr 0x0C00 apple2enh-iobuf-0800.o -m hfs65.a2.map -vm hfs65.c ../ip65/ip65_tcp.lib ../drivers/ip65_apple2.lib
ca65 -o telnet65.s.o telnet65.s
ld65 -o telnet65.bin -C apple2.cfg -m telnet65.a2.map -vm telnet65.s.o ../ip65/ip65_tcp.lib ../drivers/a2combo.lib apple2.lib
cl65 -o tweet65.bin -Or -t apple2enh --start-addr 0x0C00 apple2enh-iobuf-0800.o -m tweet65.a2.map -vm tweet65.c ifttt.c ../ip65/ip65_tcp.lib ../drivers/ip65_apple2.lib
cp ../build/prodos.dsk ip65.dsk
java -jar -as ip65.dsk date65 < date65.bin
Error: Invalid or corrupt jarfile ip65.dsk
Makefile:121: recipe for target 'ip65.dsk' failed
make[1]: *** [ip65.dsk] Error 1

My cc65 version is: cc65 V2.18 - Git 28584b31
OpenJDK is Version 8

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Jul 15, 2019 12:38 pm 
Offline

Joined: Wed Dec 05, 2007 2:15 am
Posts: 90
> I updated to cc65 2.18 and now the code from your git repo compiles.

:-)

> I fixed this by adding C1541 = <path to tool> to the apps/Makefile.

My idea was that this is rather done via an environment variable or on the make command line.

Anyhow, this issue and your issue with the Apple II disk image shows me that it doesn't seem obvious to "everybody" that the Maikefile "of course" needs to be told where the disk image tool appropriate for the target machine is installed. Therefore I added defaults for the variables for all necessary disk image tools just containing the pure names. This should have two benefits:

1. The user gets a much clearer error message showing that a file wasn't found - and what the name of that file is.
2. Users may choose to put the disk image tool in the path or the current directory thus getting away with any variable (modification) at all.

See https://github.com/cc65/ip65/commit/110 ... b6c84f7d57


Top
 Profile  
Reply with quote  
PostPosted: Mon Jul 15, 2019 2:07 pm 
Offline

Joined: Thu May 17, 2007 3:00 pm
Posts: 105
Location: Duesseldorf, Germany
Oliver wrote:
> I updated to cc65 2.18 and now the code from your git repo compiles.

:-)

> I fixed this by adding C1541 = <path to tool> to the apps/Makefile.

My idea was that this is rather done via an environment variable or on the make command line.


Anyhow, this issue and your issue with the Apple II disk image shows me that it doesn't seem obvious to "everybody" that the Maikefile "of course" needs to be told where the disk image tool appropriate for the target machine is installed. Therefore I added defaults for the variables for all necessary disk image tools just containing the pure names. This should have two benefits:

1. The user gets a much clearer error message showing that a file wasn't found - and what the name of that file is.
2. Users may choose to put the disk image tool in the path or the current directory thus getting away with any variable (modification) at all.

See https://github.com/cc65/ip65/commit/110 ... b6c84f7d57


Okay, got your point. In fact, I couldn't imagine you wouldn't notice such an obviuous "bug" ... hehe
My ambitious plan - maybe I should open a new thread for this - is to try (really, no promises made!) to port the Contiki OS telnetd.c to IP65. I did not yet start any work, but the idea is alluring . If I have further, more technical questions regarding IP64, may I contact you via mail?

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Jul 15, 2019 2:51 pm 
Offline

Joined: Wed Dec 05, 2007 2:15 am
Posts: 90
> If I have further, more technical questions regarding IP64, may I contact you via mail?

For sure!


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group