Jump to content

ol.sc's Photo

ol.sc

Member Since 6 Nov 2010
OFFLINE Last Active Nov 9 2017 11:05 AM

#3886844 Telnet65 for DragonCart

Posted by ol.sc on Thu Nov 9, 2017 11:03 AM

I'm for sure no Atari guy so maybe I'm wrong - but I think our 6502 machines tend to be powered on and off rather quickly / often. But any Linux SoC thingy takes ~30 secs to come up and usually wants to be shut down cleanly. So I'm with you that I prefer clean integrated solutions I have by now come to the point to see the Linux SoC as an optional add-on.




#3871496 Telnet65 for DragonCart

Posted by ol.sc on Thu Oct 19, 2017 9:43 AM

Hi,

 

I tried the wget and the browser [...]

 

Are you refering to the Contiki web browser and the Contiki wget?

 

The menu item "save URL as" [...]

 

Neither the Contiki web browser nor the Contiki wget have any menu.

 

The web browser shows the text "Would you like to download instead?" - see

https://github.com/c...wser/www.c#L715

 

The wget shows a prompt asking "Save as:" - see

https://github.com/c...get/wget.c#L183

 

But maybe you are rather refering to some web browser / wget running on some box you are connected to via Telnet. Then it's obvious that you can only download files to the file system on the box you are connected to via Telnet. 

 

Even if you run the Contiki wget on your Atari you will only be able to download to a file in your Atari file system, but not to "raw blocks" on your disk. Maybe I'll provide a new wget that will be able to do the latter.

 

Regards,

Oliver




#3675227 Contiki - August 2015

Posted by ol.sc on Thu Jan 19, 2017 5:46 AM

Hi,

 

For everybody finding this thread maybe without having the complete context...

 

By now I've set up my own Contiki download page. Please find my latest Contiki builds at https://github.com/o...ontiki/releases

 

Regards,

Oliver




#3664182 Contiki - August 2015

Posted by ol.sc on Wed Jan 4, 2017 7:13 AM

Hi Andreas,

 

Thanks for pointing out the ABBUC thread to me :-)

 

Just two remarks:

 

1. Returning to DOS

- IPCONFIG returns to DOS on using the UI buttons.

- WEBBROWS and IRC return to DOS on Ctrl-C.

- WGET returns to DOS when done.

- TELNETD and WEBSERV don't return to DOS.

When I tested the programs returning to DOS worked. The only idea I have is that your issue is related to the mouse driver used. In case you find something out I'd be interested to learn via email to ol.sc@web.de

 

2. Adding http://

As you'd expect the web browser checks if http:// is already entered - see https://github.com/c...wser/www.c#L333

I have no idea why this didn't / doesn't work for you.

 

Regarding websites "usable" with the web browser you may want to check out https://groups.googl...le2/JiWYnLf22YA

 

Regards,

Oliver




#3383588 Contiki - August 2015

Posted by ol.sc on Thu Dec 3, 2015 12:43 PM

Hi,

 

Sorry - yesterday's .zip file didn't actually fully fix the issue - this one does (hopefully)  ;-)

 

Regards,

Oliver

Attached Files




#3372908 Contiki - August 2015

Posted by ol.sc on Fri Nov 20, 2015 4:46 AM

In my opinion a Telnet Client and an IRC Client would be the most usefull applications for CONTIKI.

 

Just to be sure there's no misunderstanding: The .ZIP files I'm attaching in this thread actually contain an IRC client - although likely not as feature-rich and/or bug-free as desirable. Regarding the Telnet client I'm absouletly with you!

 

Are there any activities on the Apple II / C64 side to implement such machine abstracted CONTIKI apps?

 

Not that I'm aware of - so I'd say it's an educated guess to say 'no' :-(

 

I'm pretty sure that the cc65 CONIO layer is both fast and feature-rich enough to be used as abstracted screen output layer. And if somethings would be missing I'd be willing to cooperate on extensions. I.e. I very recently merged a soft80-based CONIO variant for C64 to the cc65 GitHub upstream. So the C64 now has a 80 column web browser (and IRC client). With about no changes to the Contiki code base. If there were a cc65 CONIO based Telnet client (either using Contiki or not) then that would have got C64 80 column support "for free" too.

 

What I want to say it that good coders aren't excatly standing in line nowadays to work on retro Internetworking projects. Therefore I personally would like to see the scarce resource spent well. With cc65 you get highly optimized libraries for the individual target machines written by people at home on those machines. Remember that I ported Contiki successfully to the Atari without having ever written any Atari software before. And you certianly don't have to write everything in "slow and large" C code if you don't like to. cc65 comes with a macro assembler that is at least good enough to be popular for projects not making use of anything else cc65 offers.

 

So for a Telnet client one might decide to implement the actual Telnet data stream parsing in 6502 code and implement the configuration menu in C. And it would still benefit from the machine abstractions. I.e. Contiki is in general of course written completely in C (as it runs on a multitude of CPUs). But for the TCP checksum calculation there's a 6502 code alternative. And the CS8900A driver is written in 6502 code. But all this 6502 still runs the same on the Atari, C64 and Apple II.

 

The point I'm trying to make is: From my perspective there are valid design point between the extremes of "fully machine agnostic POSIX C" and "register level hardware hacking in 6502 asm". From my perspective it's about making smart choices what tool to use for what purpose.

 

Just my two cents,

Oliver




#3368519 Contiki - August 2015

Posted by ol.sc on Sun Nov 15, 2015 10:08 AM

Hi,

 

I fixed several issues and created new Contiki disk images.

 

I'm not in control over Contiki versioning - and even if I were I'd likely not bump the version for every code drop. So in order to allow you to understand what Contiki code base was used to create the disk images the ZIP files from now on contain a ZIP comment. It's a link to the Contiki GitHub page showing the last commits (incl. their date) that are part of the code base. For the ZIP file attached that link is https://github.com/c...commits/a161dc2

 

Regards,

Oliver

Attached Files




#3324006 Contiki - August 2015

Posted by ol.sc on Fri Sep 18, 2015 1:55 AM

Hi,

 

First of all thanks for checking out the IRC client.

 

I am pretty sure you've already started working more deeply in the client ...

 

Actually the very opposite is true. I've basically never looked at the IRC client code.

 

I've personally never used IRC neither in the past nor now. I must admit that I'm personally not interested IRC. Maybe I just don't know what I'm missing but I'm not into any type of text chat / messaging.

 

Given the above I'd appreciate if you - or someone reading (and in contrast to me understanding) your post - would look at the souce and modify it to your needs. I'd commit to make sure that I'll have it merged into the Contiki upstream repo and create new disk images. See:

https://github.com/c.../apps/irc/irc.c

https://github.com/c...apps/irc/ircc.c

 

If that's impossible you'd need to provide me a step-by-step guide on how to reproduce the issue you describe, what part of the screen output differs from your expectation and how that part should rather look like.

 

Regards,

Oliver


  • w1k likes this


#3311109 Stock IP65 for the ATARI

Posted by ol.sc on Sun Aug 30, 2015 5:11 PM

Hi,

 

The IP65 project page now reflects the addition of the ATARI: http://oliverschmidt.github.io/ip65/

 

Regards,

Oliver




#3309477 Stock IP65 for the ATARI

Posted by ol.sc on Fri Aug 28, 2015 8:15 AM

Hi,

 

Since end of 2013 I'm the maintainer of the IP65 6502 TCP/IP - located at http://oliverschmidt.github.io/ip65/

 

So far the machines officially supported were the C64 and the Apple II (and to some extend the 32kB VIC20). Today I added the ATARI: https://github.com/o...mit/6987df44ed2

 

I'm sure you may wonder how my work relates to Dan's work on IP65. Although I presume he can (and hopefully will) provide better background info here are some hints from my perspective:

 

1. Although IP65 was in general devided into machine-neutral code (in the ip65 directory) and machine-specific code (in the drivers directory) quite some C64 specific code slipped into the ip65 directory over time. I removed all that code and presume Dan did more or less the same. One of the benefits of doing so is that adding a new machine like I did now isn't much effort - at least for someone with system programming experience on that machine. In contrast I was totally clueless so I checked out what Dan did 2 years ago in http://atariage.com/...ware/?p=2734494

 

2. Both Dan and I would like to make creating Ethernet applications simpler in order to tempt more people to do so. However afaik our ways to archive that goal are very different.

 

2.1 Dan brings IP65 much "closer" to the ATARI and converts it into a "driver" (by i.e. moving its background processing into interrupt handlers) allowing ATARI programmers to access it in ways they expect.

 

2.2 I want to make IP65 accessible for cc65 C programmers. I already "normalized" its cc65 segment usage and zeropage usage. The primary work left is to make the actual IP65 API callable from C programs. And then there are some rather minor topics left like "normalizing" timer usage.

 

As you may know Contiki for the ATARI is built completely on the cc65 abstraction layers. So one can see that pretty powerful applications can be written in pure C. Given that the cc65 C libraries are written nearly completely in 6502 code the IP65 library fits in nicely - and it fits nicely into the cc65 idea of allowing for easy cross-machine programming.

 

At this point some may wonder how I position an IP65 callable from cc65 C programs in relation to Contiki:

 

- Contiki is about apps which "wrap themselves around" the Contiki TCP/IP stack. It takes quite some effort to understand the Contiki programming model. The result are fully event driven apps reacting on multiple network connections, keyboard events, mouse events, timer events...

 

- "C callable IP65" is about apps doing primarily other things but needing additionally some network connectivity.

 

- Contiki has a LOT functionality and is written completely in C thus taking up pretty much RAM but allowing to be compiled on other machines. I.e. my recent work on the Contiki web browser was completely done on Windows using Visual Studio. Without its excellent debugger I simply would have never reached the state it is in now.

 

- "C callable IP65" has more limited functionality (i.e. only one TCP connection) and is written in 6502 code. Thus it is much smaller but requires 6502 skills for debugging.

 

Anyway I'm talking here about vaporware as it is pretty unclear when I'll actually work on that C callable IP65...

 

Back to facts: Please find attached a disk image with the "usual" IP65 test programs. However those test programs are mostly either rather useless or broken. PARSER.COM, DNS.COM and GETURL.COM are supposed to do "something". The only sort of interesting program is HTTPD.COM which is a web server displaying a simple form and dumping the entered data to the ATARI screen after submission by a web browser.

 

Right now I have no access to an ATARI (and Altirra still has afaik some issues with Dragon Cart emulation) so I'd really appreciate if I would receive feedback from Dragon Cart owners here - especially on the web server.

 

Regards,

Oliver

Attached Files

  • Attached File  ip65.atr   130.02KB   117 downloads



#3303108 Contiki - August 2015

Posted by ol.sc on Tue Aug 18, 2015 4:08 PM

Hi,

 

Thank you for the kind words Oliver.  I am very proud of the work we have done.

 

:-)

 

For me that was/is like standing on the shoulder of giants: On the one hand the Dragon Cart behaving totally identical to the CS8900A-based devices on the C64 and Apple II - and on the other hand the work Chris and others have put into the cc65 C library for the Atari (XL).

 

[...] but it only had a small part in my decision to put the next hardware production oh hold.

 

Good to know !

 

Regards,

Oliver




#3302763 Contiki - August 2015

Posted by ol.sc on Tue Aug 18, 2015 6:32 AM

Hi,

 

I just wanted everyone to know I have updated the Atari Ethernet website with the latest Contiki, some website fixes and the current status of the hardware.  I have been enjoying and  monitoring this thread as well as the one on the WIZNET W5100.

 

As starter of this thread I feel entitled to add some words from my perspective...

 

First of all: Without you donating a Dragon Cart both to Chris and me the current Contiki wouldn't exist - thanks :-)

 

Regarding the (CS8900A-based) Dragon Cart vs. a potential W5100-based cart:

 

- The Dragon Cart has been - at least to my knowledge - the first Ethernet solution for the 8-bit Atari. Whatever should follow, that's still a fact !

 

- Even if there should be no more Dragon Carts built it's already virtually immortal through Altirra's Dragon Cart emulation:-)

 

- Even if there should be at some point a W5100-based cart that doesn't mean for me to drop Dragon Cart support. Remember that on the C64 there is no momentum for a (directly 65xx-accessible) W5100-based solution because of all the existing CS8900A-based software. That means to me that for all cross-machine projects (like Contiki) a 6502 TCP/IP stack with two Ethernet drivers (for the CS8900A and the W5100-Raw-Mode) will stay state-of-the-art. Not even talking about not just leaving the numerous customers of CS8900A-based solutions on the C64 and Apple II behind.

 

And finally: I would be very unhappy if my babbling about a W5100-based cart would be the reason for you to not realize your idea of a module-less CS8900A-based "Dragon Cart II" - without any alternative actually existing for Atari users interested in Ethernet connectivity !

 

Just my two cents,

Oliver




#3297484 TCP/IP Offloading With The WIZnet W5100

Posted by ol.sc on Tue Aug 11, 2015 7:17 AM

Hi,

 

In http://atariage.com/...ki-august-2015/I mentioned the WIZnet W5100 Ethernet controller because Contiki (and IP65) have a driver for it.

 

However the W5100 might be of some interest unrelated to Contiki so I opted for a new topic...

 

- The current W5100 datasheet can be found at http://www.wiznet.co...uct-item/w5100/

 

- WIZnet also provides a module containing the W5100, see http://www.wiznet.co...-item/wiz811mj/

 

- I implemented several W5100 drivers (see links below) and recently wrote some notes on the W5100 I'm presenting here:

 

1. Operation Modes
 
1.1 MAC-Raw
In MAC-Raw mode the W5100 behaves pretty much like a CS8900A or a LAN91C96. The W5100 is usually only configured with a MAC address which is used by the W5100 to limit incoming frames to those sent to its MAC address (or broadcasts).
 
1.2 IP-Raw
IP-Raw mode is usable to implement non-UDP/non-TCP IP protocols like ICMP. The W5100 is usually configured with a full IP profile (IP addr, netmask, gateway). It transparently takes care of incoming/outgoing ARP and optionally of incoming ICMP Echo (aka Ping).
 
1.3 UDP
UDP mode is pretty simlar to IP-Raw mode but additionally takes care of header checksum calculation.
 
1.4 TCP
TCP mode is rather different from the other modes. Incoming/outgoing data isn't delimited by headers like in all other modes. Rather the W5100 behaves like a BSD socket delivering/taking a data stream - in chunks not necessarily related to data packets received/sent. The W5100 transparently takes care of TCP flow control by sending ACK packets. It advertises a receive window identical to the free space in the its receive memory buffer.
 
The W5100 offers up to 4 'sockets' allowing to specify the operation mode for each socket individually. However MAC-Raw mode is only available for the first socket. It is possible to combine MAC-Raw mode with other modes for the other sockets - which is called 'hybrid TCP/IP stack'. I have no personal experience with this hybrid TCP/IP stack and see open questions:
- Are packets delivered to other sockets filtered from the first socket?
- Who takes care of incoming ARP and incoming ICMP Echo?
 
The W5100 divides its 16kB memory buffer statically into 8kB for receive and 8kB for send (in contrast to the CS8900A and the LAN91C96 which both do dynamic receive/send buffer division). When using several sockets it is additionally necessary to statically assign the two 8kB memory buffers to the sockets.
 
2. Memory Buffer Access
In 6502 machines the W5100 is accessed using its indirect bus interface. This interface optionally allows for pointer auto-increment (like the CS8900A and the LAN91C96). However in contrast to those two Ethernet controllers the W5100 does NOT virtualize access to its memory buffer! So when reading/writing data from/to the W5100 and reaching the end of the memory buffer assigned to the socket it's the responsibility of the 6502 program to continue reading/writing at the begin of the memory buffer. Please note that the pointer auto-increment does NOT take care of that wraparound operation! I have implemented several ways to handle this difficulty.
 
2.1 Copy Split
If it is necessary or desired to have the interface to the upper layers being based on a receive/send buffer and one can afford the memory for a little more code than it is appropriate to check in advance if receive/send will require a wraparound and in that case split the copy from/to the buffer into two copy operations. That approach is used in all WIZnet code and I implemented it in pretty optimized 6502 code for the Contiki/IP65 MAC-Raw mode driver located in drivers/w5100.s - however the copy split technique is in general applicable to all W5100 operation modes.
 
2.2 Shadow Register
When it comes to using as little memory as possible I consider it in general questionable if a buffer is the right interface paradigm. In many scenarios it makes more sense to read/write bytes individually. This allows i.e. to directly write bytes from individual already existing data structures to the W5100 or analyze bytes directly on reading from the W5100 to decide on processing of subsequent bytes - and maybe ignore them altogether. This approach splits a receive/send operation into three phases: The initialization, the individual byte read/write and the finalization. The initialization sets up a 16-bit shadow register to be as far away from overflow as the auto-increment pointer is away from the necessary wraparound. The individual byte read/write then increments the shadow register and on its overflow resets the auto-increment pointer to the begin of the memory buffer. I implemented this approach in two drivers using heavily size-optimized 6502 code for the W5100 UDP mode and TCP mode showing that the shadow register technique yields the smallest code. They are located in supplement/w5100_udp.s and supplement/w5100_tcp.s with C test programs located in test/w5100_udp_main.c and test/w5100_tcp_main.c. There's a Win32 communication peer for the test programs located in test/w5100_peer.c.
 
2.3 TCP Stream Split
A correct BSD TCP socket program never presumes to be able to read/write any amount of data. Rather it is always prepared to call recv()/send() as often as necessary receive/send the expected amount data in whatever chunks - and the very same holds true for any program using the W5100 TCP mode! But this already necessary complexity in the upper layers allows to handle W5100 memory buffer wraparounds transparently by artificially limiting the size of a read/write operation to the end of the memory buffer if necessary. The next read/write operation then works with the begin of the memory buffer. This approach shares the benefits of the shadow register technique while avoiding its performance penalties coming from maintaining the shadow register. Additionally it allows the upper layers to directly access the auto-increment W5100 data register for individual byte read/write because it is known to stay within the memory buffer limits. Therefore the TCP stream split technique avoids both the overhead of a buffer as well as the overhead of function calls for individual bytes. It sort of combines the best of both sides but it means larger code than the shadow register technique and is only applicable to the W5100 TCP mode. I implemented the TCP stream split technique in a C-only driver located in supplement/w5100.c with a test program representing the upper layers located in test/w5100_main.c being compatible with test/w5100_peer.c.
 
Regards,
Oliver

 




#3295587 Contiki - August 2015

Posted by ol.sc on Sat Aug 8, 2015 10:57 AM

Hi,

 

I've create a new build of Contiki for the Atari 8-Bit Computers (with a Dragon Cart). Let me summarize the changes:

 
1. The Twitter client had to go :-( Twitter just doesn't want any 3rd party clients anymore and successfully drives them away.
 
2. The email client didn't make any sense anymore (it never did make much anyway). Nowadays everybody uses strong encryption.
 
3. The FTP was a similiar case. Without PASV support not interoperable with anything out there. Without support for sending files it was never really useful anyway.
 
4. The Telnet server is now part of the package. It was "always" there but had a bug keeping it from working with cc65. I found and fixed it because it is used as base for https://github.com/l...c64/Contiki-BBS. The demo Telnet server I'm providing comes with the shell command 'wget' allowing you to download a i.e. the Google homepage with 'wget www.google.com | write google.htm'.
 
5. I'm sure about everybody sees the web browser as most interesting Contiki app. So I went ahead and invested many hours in improvement:
 
- Originally there were several fixed sized arrays to hold the data of links and forms. While that had the benefit of simple (aka fast and small) 6502 code to access the data it turned out to be simply to inflexible to accommodate somewhat more complex pages. Quite some time ago I changed that https://github.com/c...7e2bbb121556f5e to use a single buffer containing linked lists of items allocated according to their actual size. As part of that change I moved away from storing input field data in the actual page allowing to support scrolling input fields and hidden input fields.
 
- In the meantime I fixed quite some issues. Among them there were several fixes improving the "skipping" of unhandled stuff:
a) HTTP header field parsing uses a fixed 1024 byte buffer. If a header field was longer the whole page parsing failed. Nowadays many pages set cookies - which are easily larger than 1024 bytes. Now the header field parsing successfully skips too-long header fields.
b) Nowadays about every pages comes with huge amounts of JavaScript. That was generally already skipped. But there were two special cases not handled:
- an HTML tag inside a JavaScript string.
- a JavaScript comparison using the less-than operator.
Now both cases are handled correctly.
 
- Regarding the actual page display nowadays people use loads of <div> to structure their content. Inserting a newline for every </div> sometimes meant literally empty pages ;-) Instead of blowing up the parser code I opted for a post-processing: There are simply never more than two consecutive newlines rendered.
 
- I was surprised to find that "THE" web page (www.google.com) is generally still operational without TLS and JavaScript. So I set out to bring it (back) to the Contiki web browser. The only thing I more or less explictly added for that purpose was https://github.com/c...7ec56d45445e83e
 
6. I moved away from those Contiki online configurator thingy. Contiki now comes as straight .atr downloads. Either as three 130k DOS 2.5 images or as one 800k MyDOS image.
 
7. Before the Atari version of Contiki had way less features than the Apple II / C64 version - because cc65 programs for the Atari had less memory to use than cc65 programs for the Apple II / C64. In the meantime Christian Grössler has put quite some effort into the Atari support of cc65 (Thanks !) allowing cc65 programs for the Atari to optionally make use of the RAM behind the ROM. Contiki now does so - and thus has as much memory available as the version of Contiki for the Apple II / C64 and therefore offers all features.
 
8. The Contiki GUI programs for the Atari now come with mouse support. This is possible because of the increased memory available to cc65 programs for the Atari - and because of the mouse support added to cc65 for the Atari (again Thanks to Christian Grössler !). If you have a non-ST mouse you may rename the mouse drivers on the disk(s) to get your mouse working.
 
I produced a video of configuring Contiki, bringing up the web browser, searching on Google for 'atari' and finally surfing to the Dragon Cart website, see https://vid.me/tEIm
 
and now for some more general info:
 
Contiki source code: https://github.com/contiki-os/contiki (all my Atari changes are there upstream - there's no need for another source)
 
Contiki home page: http://www.contiki-os.org/
 
On the Apple II we decided after literally years of consideration to move away from the CS8900A for the new Apple II Erthernet card. Rather it uses the WIZnet W5100, see http://www.a2retrosy...om/blog/?cat=26
 
The W5100 has basically two modes: In Raw MAC mode it behaves pretty much like a CS8900A. All porting efforts "simply" use the W5100 in that mode. In IP mode it includes a complete TCP/IP stack allowing for UDP and TCP (with up to four simultanious connections).
 
Using the W5100 in IP mode allows for totally different use cases than what we saw so far. Imagine super small drivers for virtual fast network floppy drives or alike. I've done a size-optimized send/receive of UDP frames for the W5100 in ~260 bytes.
 
The W5100 surely isn't the latest and greatest but it is very well understood - i.e. the Arduino Ethernet Shield contains it, meaning _LOT'S_ of people use it in the open source "makers" domain.
 
Just in case someone is consideriing to build a W5100 based cart for the Atari:
 
- Contiki works both with CS8900A and W5100 in just the same way. It would cost me 1/2 to build an Contiki-for-Atari actually doing so.
 
- Dan's code is based on IP65. I guess you know that I'm the IP65 maintainer now. I modified IP65 to share the low level driver code with Contiki. So IP65 already has full W5100 support.
 
So the existing Atari Ethernet software can work with the W5100 instead of the CS8900A without problems. On the other hand I know that there are quite some guys thinking that TCP/IP on the 6502 isn't the right way. They could enter the game with a W5100. So the W5100 basically offers the best of two worlds :-)
 
Regards,
Oliver

Attached Files