ol.sc

> that takes the dragon out of the loop On https://github.com/a2retrosystems/uthernet2/wiki/Uthernet-II-and-Raspberry-Pi I describe the benefits of using Ethernet to connect a Linux SoC (here a Raspberry Pi) to a 6502 machine. On a Raspberry Pi you can for example run a SIO emulator and and a SSH client at the same time. But maybe you don't have much fun connecting both at the same time to the Atari. But with the Atari having an Ethernet interface with (in contrast to the Dragon Cart) it's own TCP/IP using the W5100 one can at the same time run SIO over some simple proprietary UDP protocol and run Telnet over a TCP connection. And with Telnet one logs on to the Raspberry Pi and SSHs from there to anywhere. This setup surely blocks the single Ethernet port on the Raspberry Pi. But with Ethernet you can just connect both (the Atari and the Pi) to your LAN and have the Pi located anywhere. Or you're into WiFi, connect the Atari via a short Ethernet cable directly to the Pi and use the Pi's WiFi to connect to the net. You can even have the Pi act as WiFi bridge allowing Atari Ethernet software like the Contiki web browser to directly connect other machines on the net.

SSL/TLS is something you can get today in things like an ESP8266 / ESP32. But I'm not aware of a (free) SSH client implementation for any micro-controller platform. So from my perspective you end up with some Linux-capable SoC running OpenWRT or Raspbian.

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/contiki-os/contiki/blob/master/apps/webbrowser/www.c#L715 The wget shows a prompt asking "Save as:" - see https://github.com/contiki-os/contiki/blob/master/examples/wget/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

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/oliverschmidt/contiki/releases Regards, Oliver

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/contiki-os/contiki/blob/master/apps/webbrowser/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.google.com/forum/#!topic/comp.sys.apple2/JiWYnLf22YA Regards, Oliver

Hi, TelnetD is known to generally work. The directory listing is done with 'ls .' and the latest build can been found at https://github.com/oliverschmidt/contiki/releases Regards, Oliver

Hi, I just wanted to state that with 2.70 Contiki is now supported by Altirra's DragonCart emulation. Altirra's DHCP server provides an IP address to Contiki (192.168.0.101 by default) and the client type programs (web browser, wget, IRC) work just fine :-) However I didn't manage to get the server type programs (web server, TelnetD) working. I added in the 'Dragon Cart Settings' - 'Forwarding address' the value 192.168.0.101 and the 'Port' 80 for the web server but couldn't receive web pages successfully. Regards, Oliver

Hi, Sorry - yesterday's .zip file didn't actually fully fix the issue - this one does (hopefully) Regards, Oliver contiki-atari.zip

Hi, Someone else introduced a bug into Contiki without me noticing it. Today I was made aware of it - and fixed it: https://github.com/contiki-os/contiki/commit/48d1d74f1c4fbba8baa43573a65718cfb12068c2 Attached is a .zip file with disk images containing the fix. Regards, Oliver contiki-atari.zip

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! 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

I don't understand what "for the CONTIKI" means. Contiki is a framework one can use to build event driven programs. It has libraries for quite some Internet protocols and and a widget library. From that perspective it would be a viable option to build a Telnet client "with Contiki". I personally think that a Telnet client built using the cross target capabilities of cc65 to address the Atari, the C64 and the Apple II is for sure the thing that is missing most in the "6502 retro Internet arena". That could be built using Contiki or some other Internet protocol library (like IP65) - as long as it uses the cc65 machine abstraction layer allowing it to run on the three machines mentioned. I'd consider such a Telnet client a medium sized effort - in whatever metric However I'm not capable of spending the time necessary.

TELNETD.COM isn't a Telnet client, it's a Telnet server (aka Telnet Daemon). Use it like the web server: Start it and connect to it with a suitable client from another computer.

SSH isn't Telnet Use a Telnet client (on default Telnet port 23). I.e. PuTTY allows to switch to Telnet.

Primarily https://github.com/contiki-os/contiki/commit/1066bb1a0b7aa4ceab004592610d813252f6538f

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/contiki-os/contiki/commits/a161dc2 Regards, Oliver contiki-atari.zip

Hi Dan, Sorry if that is a "stupid" question but have you ever considered to use Ice-T (or another advanced Atari VT100 program) as starting point for your Telnet client instead of porting that CaTer code from the C64? Regards, Oliver

Hi, First of all thanks for checking out the IRC 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/contiki-os/contiki/blob/master/apps/irc/irc.c https://github.com/contiki-os/contiki/blob/master/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

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

Hi, Re-reading my last message it now seems (too) easy to misunderstand :-( What I wrote wasn't meant as criticism of you. I regularly read threads in some forum about people discussing their issues with cc65. Those issues occur mostly from abusing the tools because of missing understanding. The result are pretty ugly workarounds. But they some to not even consider to join the cc65 mailing list and ask there for hints... Anyway I'm happy that you doesn't seem to have interpreted my message in the wrong way :-) :-) I see. I'd be happy if I could add a little to the success of your GOS project - I read (most of) the corresponding thread here - pretty impressive ! Regards, Oliver

Hi, - The ca65 assembler comes with pretty extensive macro support. Maybe it's reasonable to have a single IP65 source usable for both ca65 and MADS... - The ld65 linker already supports the .o65 relocatable format. It is designed to support multiple output file formats: http://cc65.github.io/doc/ld65.html#ss5.7Maybe it would make sense to add support for the relocatable format in question to ld65. That would btw. open the option to use the cc65 C compiler to produce files in that format too... In general I'm wondering why there is so little communication about potential synergy effects. From my perspective open source isn't about grabbing source and doing with it what is necessary but about collaboration. I'm always against fragmentation - but seem to be rather alone with that idea... Just because I'm no regular reader of the AtariAge forum and for sure no Atari guru that doesn't mean that I'm not approachable. I see my role as maintainer of cc65 and IP65 not as primary implementer but as manager of an upstream repo to avoid fragmentation. If you check out the cc65 git log you'll see that I'm actually not contributing a lot... Regards, Oliver

Hi, :-) Does 'C' refer to cc65 here? Anyway I'd appreciate if you write me a short email with a hint when it becomes available. Thanks - but I have both a Dragon Cart (donnated by Mark) and a 130 XE (donnated by the ABBUC). I'm just currently > 1500 km away from both. I presume that Avery would like to know if HTTPD.COM works on real hardware. Therefore I'm asking here for feedback asap. Regards, Oliver

Hi, Wow, that's pretty cool :-) In fortunately not :-( After all I didn't write the core Contiki code... However I felt that it might be helpful for you to have alternative ATARI network software listening on incoming TCP connections. Therefore I went ahead and "quickly" ported the stock IP65 library to the ATARI - see http://atariage.com/forums/topic/242150-stock-ip65-for-the-atari/ The HTTPD.COM in the disk image attached to that message works pretty nicely on the C64 and the Apple II. In fact it was used for endurance testing the Contiki/IP65 W5100 driver (using Siege)... Regards, Oliver

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/oliverschmidt/ip65/commit/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/forums/topic/211161-dragoncart-software/?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 ip65.atr

Hi, Thanks for testing and providing feedback :-) Thanks for the explanation. As you can imagine I was wondering how you managed to find an issue in Contiki's DHCPREQUEST message when I didn't manage to get to the point of having Contiki send a DHCPREQUEST message Does your latest 2.70 pre-release already contain your DHCPD fixes - apart from the xid thingy? If not it would be nice if you would post a short message in this thread when an Altirra is available that's compatible with the IPCONFIG.COM I posted yesterday. BTW: It would of course be great if the Altirra NAT would allow for incoming connections. From the tech demo perspective the Contiki Telnet server is the most interesting program as it can use two TCP connections simultanously: One incoming from the Telnet client and one outgoing for the wget shell command. Regards, Oliver

Hi, Thanks :-) Yes, Contiki is about running everything on the Atari. No host / server / proxy whatsoever. Just a straight Ethernet connection. As already mentioned I don't see Contiki with any type of "serial line emulated by TCP connection" device. SLIP is of course different as the TCP/IP stack stays on the Atari... SLIP would be conceptually for sure be possible. It would even be sort of nice as cc65 comes with an abstraction layer for serial ports which could be used here in the same way the Contiki mouse support uses the mouse abstraction layer of cc65. For the Atari there's an implementation of that abstraction layer for the R: device - see http://cc65.github.io/doc/atari.html#ss6.5 However I personally am not interested in SLIP as it isn't a standard network interface nowadays. You'd have to set up a SLIP server for that very purpose. And at that point you can as well start to move functionality to that SLIP server - up to the point of offering a shell login with Lynx etc. and running Dan's Telnet client... Regards, Oliver