Jump to content
IGNORED

Atari 8-bit Ethernet and Contiki - Want your help!


Cybernoid

Recommended Posts

I actually have an Altair 8800. It can be seen in my AtariAge gallery: http://www.atariage....9-img-0635sjpg/

 

I am working on getting it online with the mess of cables there...

 

Actually, it is not too far fetched to get the altair with monitor and serial port additions online. ;)

 

gallery_4398_30_142004.jpg

 

Edited by Cybernoid
  • Like 1
Link to comment
Share on other sites

I actually have an Altair 8800. It can be seen in my AtariAge gallery: http://www.atariage.com/forums/gallery/image/369-img-0635sjpg/

 

I am working on getting it online with the mess of cables there...

 

Actually, it is not too far fetched to get the altair with monitor and serial port additions online. ;)

 

Alright, that's your project number two now. Altairnet!

Link to comment
Share on other sites

I actually have an Altair 8800. It can be seen in my AtariAge gallery: http://www.atariage....9-img-0635sjpg/

 

I am working on getting it online with the mess of cables there...

 

Actually, it is not too far fetched to get the altair with monitor and serial port additions online. ;)

 

gallery_4398_30_142004.jpg

 

That thing is shocking! It looks like a bunch of circuit boards got very sick and started vomiting up cables. :D

 

Now that's what I call retro computing. :)

Link to comment
Share on other sites

I've been unable to get any of the ported Contiki apps in the "Disk" folders in the examples in the Atari port to run successfully. I got a glimpse of a text based "Desktop" but then it crapped out. No matter which way I set things up it either can't find the config files or it runs out of memory. A cohesive demonstration (perhaps an easy-to-run ATR) of the Contiki Desktop would be useful, as I try to place myself into this project and figure out exactly what I'm supposed to be coding and in which language.

 

My GUI is intended as a single-tasking shell which will sit over DOS. Quite how I can interface it with Contiki I confess I have no idea as of yet. It would be a shame if I start coding a GUI only to realize later on that I've gone off on a complete tangent, re-invented the wheel, etc.

 

On the subject of Web Browsers, I'm aware of one which was in development last year. I won't say whose it was until I've spoken with them first. I just wondered if any progress had been reported on the German or Polish forums.

Link to comment
Share on other sites

Great to see that page. Rooting for all you brilliant coders to come up with something that makes it easy to put my 800 on the Internet!

 

Coders, please co-ordinate what you are working on. SVN works up to a point, but its still very easy to step on functionality and duplicate work. If you are going to start on something, please PM me here and I will keep a list. If you do not know how to use SVN to create branches and merge, please take a moment to google on the subject. We will need to keep a trunk source tree where we can do integration builds on a regular basis. We must have central management of the source base or we will lose work and gain frustration. This is part of what I do for a living; so at least at first I will perform that function.

 

I think sourceforge uses TRAC to manage ticketing issues; I will see what needs to be done such that coders/testers can submit bugs and use tickets to track their work.

 

Soon, we will need a supply of testing boards, or at least clear instructions on how to build them. Some of us are quite hardware-challenged...I fit into that category.

Link to comment
Share on other sites

I've been unable to get any of the ported Contiki apps in the "Disk" folders in the examples in the Atari port to run successfully. I got a glimpse of a text based "Desktop" but then it crapped out. No matter which way I set things up it either can't find the config files or it runs out of memory. A cohesive demonstration (perhaps an easy-to-run ATR) of the Contiki Desktop would be useful, as I try to place myself into this project and figure out exactly what I'm supposed to be coding and in which language.

 

My GUI is intended as a single-tasking shell which will sit over DOS. Quite how I can interface it with Contiki I confess I have no idea as of yet. It would be a shame if I start coding a GUI only to realize later on that I've gone off on a complete tangent, re-invented the wheel, etc.

 

On the subject of Web Browsers, I'm aware of one which was in development last year. I won't say whose it was until I've spoken with them first. I just wondered if any progress had been reported on the German or Polish forums.

 

The GUI will have to be completely encapsulated in contiki, I would think. There's already a bunch of macros and so forth for making widgets, but I'm not sure they work on the atari port. I have a similar project as yours, a text based gui intended to run over top of a dos ( but mine is cooperatively multitasked...sorta ) but I expect that putting it into contiki would be a total rewrite.

Link to comment
Share on other sites

Also, I think there's only 2 critical things that must be solved before we can effectively go anywhere else with Atari Contiki on the Internets :

 

1. Availabillity of basic ethernet connectivity via a direct memory interface ( cart or PBI )

2. Banked memory usage to free up space

 

 

Without those 2 items I don't think there's much use in going forward. I am going to look at getting things into extended banks; maybe FJC can look at under the OS.

Link to comment
Share on other sites

Hmm, sorry for my continued fit of posting frenzy, but :

 

I also think that Contiki, while very cool, is not the only road to the internetz. The ethernet board is the key. Once that is done and a driver written, integration over existing DOS's ( like RealDos :) ) would be viable. Contiki has a lot of extra tasking and memory overhead and so forth which technically aren't really needed. An atari with vbxe and a regular dos could put up a pretty good browser I would think.

Link to comment
Share on other sites

flashjazzcat,

 

There are two different ways you can use Contiki.

 

1. Use the Contiki CTK and desktop

2. Build stand-alone applications

 

I was taking route #2. Basically the telnet application does not use the desktop. It only uses the Contiki core which uses UIP. There is no reason to integrate the GUI into the applications. I wanted them to be stand-alone so you can run them from any DOS.

 

Right now the code uses pretty low mem (from 0x2000 to 0xbf00 or something similar). The only DOS that work well and had a low enough lomem was SpartaDos 2.3. You will need to run with this for now.

 

I agree with danwinslow. Once the ethernet board is made there is no reason someone cannot just use UIP or LwIP or some other IP stack and build applications without contiki. Contiki just has done some of this for you AND you do not have to use all of Contiki. I think a good path to take would be to produce some more applications: telnet, irc, telnetd, ftp, webbrowser, email, etc... that can run from most any DOS and hence from most any GUI. The example telnet app I had is a modified version that has all the CTK GUI stuff stripped out.

 

This way the applications are not Contiki OS centric per se, but rather more Atari centric and do not require the Contiki desktop to run. What I wanted to do was work out a good scheme to run from extended banks in order to produce the other applications without the Contiki Desktop. Running from under the OS was starting to work, but I think the code was trying to call code in the OS while it was switched off and could not quite figure it out. Basically I think the core of Contiki will fit in low mem and under the OS ROM.

Link to comment
Share on other sites

flashjazzcat,

 

There are two different ways you can use Contiki.

 

1. Use the Contiki CTK and desktop

2. Build stand-alone applications

 

I was taking route #2. Basically the telnet application does not use the desktop. It only uses the Contiki core which uses UIP. There is no reason to integrate the GUI into the applications. I wanted them to be stand-alone so you can run them from any DOS.

 

Right now the code uses pretty low mem (from 0x2000 to 0xbf00 or something similar). The only DOS that work well and had a low enough lomem was SpartaDos 2.3. You will need to run with this for now.

 

I agree with danwinslow. Once the ethernet board is made there is no reason someone cannot just use UIP or LwIP or some other IP stack and build applications without contiki. Contiki just has done some of this for you AND you do not have to use all of Contiki. I think a good path to take would be to produce some more applications: telnet, irc, telnetd, ftp, webbrowser, email, etc... that can run from most any DOS and hence from most any GUI. The example telnet app I had is a modified version that has all the CTK GUI stuff stripped out.

 

This way the applications are not Contiki OS centric per se, but rather more Atari centric and do not require the Contiki desktop to run. What I wanted to do was work out a good scheme to run from extended banks in order to produce the other applications without the Contiki Desktop. Running from under the OS was starting to work, but I think the code was trying to call code in the OS while it was switched off and could not quite figure it out. Basically I think the core of Contiki will fit in low mem and under the OS ROM.

 

A uIP stack based driver in banked mem would be a real big step forward I think in general.

Link to comment
Share on other sites

Soon, we will need a supply of testing boards, or at least clear instructions on how to build them. Some of us are quite hardware-challenged...I fit into that category.

 

I just setup gEDA and PCB designer on my machine and I started working on a schematic we could use to design a single board cart. I was hoping to have it done today but it looks a little more challenging than I thought as I have not used gEDA before but it looks like it I can use it's utilities to capture the schematic and that should make designing the board much easier. If there is anyone who is more experienced at board design and would be willing to help, that would be awesome! The board needs a card edge, has 1 100 pin TQFP chip, a 74LS138, a sixteen pin 10BaseT transformer, 10 caps, 7 resistors, 2 LEDs and 1 crystal.

 

Also, I did some checking and the Olimex board uses the CS8900A-CQ3 which is a 3.3volt part, so a voltage regulator will be needed to step down the voltage from the 5 volts on the Atari cartridge port if anyone is planning on getting this board for testing. BTW, The CS8900A-CQ is the 5V part and shoud work fine off the 5V from the Cartridge port.

Link to comment
Share on other sites

 

I just setup gEDA and PCB designer on my machine and I started working on a schematic we could use to design a single board cart. I was hoping to have it done today but it looks a little more challenging than I thought as I have not used gEDA before but it looks like it I can use it's utilities to capture the schematic and that should make designing the board much easier. If there is anyone who is more experienced at board design and would be willing to help, that would be awesome! The board needs a card edge, has 1 100 pin TQFP chip, a 74LS138, a sixteen pin 10BaseT transformer, 10 caps, 7 resistors, 2 LEDs and 1 crystal.

 

 

Would it not be easier just to have a socket for the Olimex board? Makes the cart interface much easier, vice trying to rebuild a CS8900 complete on a cart.

Link to comment
Share on other sites

Emulation would be very nice to have. I do not believe that the current hardware would need to change much as far as emulation is concerned (maybe some hardware stuff needs changes or the address need changing, but not much else since it is working).

 

I believe someone has built an ethernetcart-ready C64 emulator for the CS8900a. Maybe we can reuse some of their sources. Basically the cart needs 16 address from $D500 - $D50f. Just need to map those registers to the cs8900a code. Should not be too bad.

 

 

--C

 

 

 

Link to comment
Share on other sites

Would it not be easier just to have a socket for the Olimex board? Makes the cart interface much easier, vice trying to rebuild a CS8900 complete on a cart.

I agree it would, but I guess I don't really like the idea that if the Olimex board becoms unavailable, we would have to redesign the board anyway. However, maybe we should make a cart for the Olimex board because it will be a faster way to get the interface to the software guys so they can dig into the development. If you guys think that's the better way to go for now , just say the word, I will shift gears and make a pattern for the Olimex board.

Edited by puppetmark
Link to comment
Share on other sites

There are two different ways you can use Contiki.

 

1. Use the Contiki CTK and desktop

2. Build stand-alone applications

 

I think both would be useful/neat.

 

#1: I was imagining a cartridge based design (like the Atarimax MyIDE cart), that includes the Ethernet cart and flash memory for storage of the Contiki app. Put uIP, CTK, and the other core stuff in low memory ($400 to $BC1F or so, depending on display). Run the apps/processes themselves out of the cartridge banked memory at $A000. That would give us 8k per app/process using the Atarimax flashcart system, or we could use all of the cartridge space with a different cartridge design. I think this would be doable by extending the process structure to include the bank that the app runs out of. You'd have to provide a custom "load" function to start the app/process, and probably a custom close function.

 

I've wanted to run a full Contiki GUI system since I saw it running on the C64! You might be able to allow the cartridge to load a DOS too, for file support. The downside to this is that you would need custom hardware.

 

#2: You need more RAM... RAM under the OS is the best to use for compatibility reasons, and then the extended banks, IMO. Putting some piece of the system under the OS ROM might work, given the proper wrappers...

 

So, what are we striving for with this project?

Link to comment
Share on other sites

There are two different ways you can use Contiki.

 

1. Use the Contiki CTK and desktop

2. Build stand-alone applications

 

I think both would be useful/neat.

 

#1: I was imagining a cartridge based design (like the Atarimax MyIDE cart), that includes the Ethernet cart and flash memory for storage of the Contiki app. Put uIP, CTK, and the other core stuff in low memory ($400 to $BC1F or so, depending on display). Run the apps/processes themselves out of the cartridge banked memory at $A000. That would give us 8k per app/process using the Atarimax flashcart system, or we could use all of the cartridge space with a different cartridge design. I think this would be doable by extending the process structure to include the bank that the app runs out of. You'd have to provide a custom "load" function to start the app/process, and probably a custom close function.

 

I've wanted to run a full Contiki GUI system since I saw it running on the C64! You might be able to allow the cartridge to load a DOS too, for file support. The downside to this is that you would need custom hardware.

 

#2: You need more RAM... RAM under the OS is the best to use for compatibility reasons, and then the extended banks, IMO. Putting some piece of the system under the OS ROM might work, given the proper wrappers...

 

So, what are we striving for with this project?

 

Right now, in my opinion we are striving for a usable board and a driver to use it with. After that, we'll see what people want to do. I would like us to remain narrowly focused on the board itself and basic driver software...often projects get 'suggestion poisoning' and lose focus and then interest wanes. If someone wants to work on Contiki in general, thats great. My focus is going to be on the board and following that some kind of bare bones tcp stack with maybe a conventional CIO driver wrapper on top of it. I think Cyber's focus on general use tcp programs, telnet, ftp, and the like is the right one, under contiki or not.

 

I think on the topic of Contiki, Shawn has a good set of ideas. But its not going to be my focus. The sourceforge project doesn't have to be about just the board though, if someone wants to drive Contiki development I think that would be a great thing. The board folks and the guys working on Contiki at some point would come together and produce something pretty damn cool.

Edited by danwinslow
Link to comment
Share on other sites

Agreed. We should focus on the board, first and it seems Mark and Candle may have that under control. We already have a working telnet app that others can use to test with it.

 

Some of us could work on the bare bones tcp stack... I really think it would be good to also branch away from Contiki for those who want something light weight. It seems Dan has that under control.

 

And, some of us work on getting the code to run from extended memory and under the OS to extend Contiki. I would like to see the other apps working, then I want to see the contiki GUI in action, and eventually *maybe* see the GUI extended for the VBXE (long-term).

 

If we think that is too much, let me know.

 

Do you want to take some of this discussion over to the developer's board on sourceforge?

Link to comment
Share on other sites

I'm glad to hear than any extant GUI projects can in theory be "married up" to TCP stack mechanism later on during the development phase. I'd feel more comfortable taking care of the basic mechanics of my GUI first, without having to worry about a new API or whatever. I'm very, very interested in helping with extended and virtual memory pool management, since I have always regarded that as the biggest obstacle to running any large apps with large amounts of data on a 6502 system. My favoured approach so far has been to keep code in main RAM and data in extended RAM (using virtual memory mapping), mainly because in a single-tasking environment, data size tends to outweigh code size. If we take the view early on that all data access is performed indirectly, then all apps will have full access to the memory pool from the get go. We can also do this when running code out of extended banks, although it becomes significantly more complex when given code is more than a bank's length.

 

It seems to me appealing and quite feasible to put the GUI core code under the OS, and stick drivers into an extended bank. This loosely follows the SDX model (or we could go the whole hog and put the GUI on a cart), which works and seems to me the most fully realised memory manager for the Atari. As far as conflicts with DOSes which reside under the OS: DOS had better not reside there. When we can all get SpartaDOS X free of charge, I don't to see why this would be an issue.

Link to comment
Share on other sites

  • 5 weeks later...

here is CS8900A-H for czech/slovak users :)

http://www.pvelectro...%5D?ItemIdx=447

 

We need to be carefull about the Olimex boards. They are using the 3.3V version of the CS8900A. That means it is not using 5V logic which is what we need to interface to the Atari. HOWEVER, the ABSOLUTE Voltage rating of the CS8900A-CQ3 is 6.0V and the threshold of the IO lines are tied to the supply lines. So we can try running the Olimex board at 5V. However, being It's pretty close to the threshold, the chip will run hot and it could shorten the life of the chip. I have a few Olimex boards and as soon as I can, I am going to test one and see what happens.

Link to comment
Share on other sites

I definitely have to thank everyone for this!!!

 

In less than 2 days, we already have a webpage (thanks to beta-tester, hardware guy and now webmaster, puppetmark), sourceforge thanks to danwinslow, and many people interested in helping with the source code and with building boards. If that is not community support, I do not know what is. Way to go y'all!

 

Check out the new webpage:

 

http://www.atari8ethernet.com

 

More to show up on that site, I am sure, so keep an eye out...

 

Thanks again!

Chris

 

Hey I recognize that BBS in the video :cool:

Link to comment
Share on other sites

I just updated the website with some new info and pictures. We are making progress. I just finished making a few "header boards that will be used to make some prototype cartridges. BTW: I think my cartridge prototyping board may be useful for others that do cartridge prototyping / experimenting. Also, and most importantly, we found a great supplier of CS8900A boards! The board is called the IP Dragon and I have one in my possession now for experimenting and hopefully a working Cartridge utilizing the IP Dragon II is not far behind.

 

 

http://www.atari8ethernet.com

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...