Amiga.org
The "Not Quite Amiga but still computer related category" => Alternative Operating Systems => Topic started by: Generale on April 07, 2005, 04:06:35 PM
-
Hey all.
Something popped into my head late last night. Thought I'd share it with you.
As you may or may not be aware, there is a little almost-OS called contiki.
It has been ported to heaps of platforms because it is written in C.
Now, even if it were to run as an app, I think it'd be great fo amiga.
Imagine a TCP/IP stack, a (simple) web browser, http, and ftp server, irc client, and a few other things living in probably less than 100kb. I would love that for my 1mb a500.
Main thing that troubles me is contiki's multitasking vs the amigas multitasking. Probably not that hard to get around. preemptive multitasking is so simple.
Anyway, what are everyones thoughts?
-
This is certainly a curiosity.
If it was simply to utilise the TCP/IP features then it would be of use. Quite frankly, can't think why anyone would want to use it but your idea of running it as an app sounds promising.
It goes to prove that it is possible if (as their web site states) it runs on the C64?
-
it does indeed run on a c64. I put it on disk about a year ago and chucked it in. Worked great. It's advanced since then though.
Been wanting to try it on my apple//e too.
someone even ported it to an atmel micro!
-
If nothing else, Contiki proves that "it can be done." A related project, lwIP, sounds like a good candidate for a small, open, and free IP stack packaged as a bsdsocket.library replacement. (Queue the naysayers.) Actually, the Amiga stands to benefit from all of Adam Dunkels' projects, assuming there are one or two dedicated programmers willing to put in a few hours of their spare time.
Trev
-
Ah..here it is. I guess this thread does kind of fit into alternative OSes a bit better.
I do find Adam Dunkels' projects interesting too. I'm always impressed by small, functional programs created in a 3GL language.
Like I said, my a500 only has 1mb of ram, so anything that works in less space is interesting to me.
Unfortunately I have no knowledge of the Amiga APIs, or any of the development tools/docs, so I definitely wouldn't be one to port any of it.
Could also make an interesting replacement for launcher on palm. but not really worth the effort.
-
Porting lightweight IP is one of the cool project I'm going to do in the future (unless someone beats me to it) A colleque of mine has already done it commercially. But I'm allowed to use his code as a guideline. But first I want to program a gamestarter.
I still haven't got the time really. I'm still in progress redecorating/restoring my apartment (almost a year busy now).
So I hope I get around to it. BTW the contiki stack is not a candidate. Contiki is a coorperative operating system. That will not do on AmigaOs. You'll need some changed done to get it to amiga multitasking.
-
The protothreads library comes from that project, perhaps the rest can become more standalone(I wonder how small a C64 emulator for the 500 can be...)
-
Hm. I thought that contiki was meant to be preemptive. I admit I thought it a little odd though. But if a CPU has interrupts, it can usually have a preemptive multitasking kernel made for it.
The multitasking would need to be changed for different platforms anyway. But it wouldn't need too much alteration if it runs as an app and the programs as loadable modules. That way Amigas OS can do the multitasking.
does anyone remember writing apps for win3.1? It needed bits put into the apps for the kernel to break in and multitask. This was great for jamming up a PC.
Back to the point. The method of cooperative multitasking became moot with the preemptive core. the core just broke in whenever it felt like it. Timed interrupts are a wonderful thing.
edit: Why would you want a c64 emulator on the amiga exactly? Not for the threading I hope? It's all portable you know :-)
-
I just tried the latest release of contiki. It has really changed! Most notably a different menu system and ctk 80 column mode (c64 version).
If it can be ported to native X, I see no reason why it can't work on an amiga!
-
As far as I know contiki is a coorperative multitasking environment. Keep in mind that contiki is designed to run on 8bits 64k (or less) devices. A preemitive task scedular would take too much ram (and time) due to it's complexity.
someone might have come up with something in the meantime that allows use of such scedular with contiki I don't know. My information might be old since I have not looked at contiki for some time.
Sure it can be ported to Amiga but why should you. The Amiga has a supperior OS sitting in it's ROM.
I'm more interested in lightweight-IP and that sort of thing. Does anyone know if someone attempted to port that to Amiga. I'd very much like to do it myself the next winter (these projects should not be attempted during the summer).
-
It's true, AmigaOS is good. I think contiki is stiff competition against OS 1.x though...
I had a better read about contikis multiprocessing abilities. I see what you mean. Except it uses preemptive multithreading as a loadable library of ~4k when it just can't be done without. Still pretty small, but on a 64k system, pretty big.
what about uIP? for those of you saying "eh?" Look here (http://www.sics.se/~adam/uip/).
It's tiny!!!!
I'd love to see a port of a small IP stack to amiga. Just make sure it works on 1.3 :-D
-
Thats is what I was talking about. there is micro-Ip (uIP) which is for microcontrollers. I've been told that this stack would not be really usefull for Amiga. It is ment to be in embedded controllers. The application is known and therefor the stack is very much tailored for the application at hand.
To be able to provide something like bsdsocket it will be easier to use lightweight-IP. A collegue of mine has sourcecode for that. I intend to use that as bases. When I have more time I'll look up some links for you.
Gotta go now. Lunch time!
-
Ohhh... I see. Any idea why the stack's no good?
It's just it's been used for a few ports of contiki, so I thought it would have been more veratile. Ah well. It's not my forte anyway.
Another year older. Happy birthday tooo meeeee.....
It should be interesting to see what you will create!
-
Well Im kind of eager to start on it. But I have one programming project preceeding it. That will be my game database/starter. But since I have zero Amiga programming experience it will take some time getting worked in (I'm more into win32 and embedded systems). Adding to that the fact I will not do much programming in the upcoming summer it may take awhile for my project to see the light of day. So please be patient (or beat me to it ;-)). Anyways happy birthday.
-
You don't have any amiga programming experience either?
About the same as me. Except I'm guessing you're still an active programmer. I'm horribly rusty. Trying to relearn it all again. All I can still really understand is ANSI C and a few assemblers including PIC, and basic, but that doesn't count. I'd rather be tortured than use pascal again.
I think I'm moving again sometime too. I don't know.
I'm going to hassle one of the developers at infogrames for a job tomorrow. It can't hurt :-D It'll give me more cash for living.
-
Yes, my main occupation is software designing. During my coffee breaks I check amiga.org. (must cut down on my coffee breaks) Anyway I don't think it will be all that difficult learning the Amiga. The main problem I see is lack of proper documentation availanble. The amiga system is pretty old and uncommen. Its not I walk into a store and get myself a book or something.
-
I agree about difficulty with documentation. There are usually books on ebay, but they cost money. Sometimes serious money.
Most of the info I find is sketchy at best.
There's probably a lot in the headers of various compiler packages. But there are some things that can't tell you.
I'm not even sure if the so called amiga developer CD would be much use.
Best of luck though.
There are probably people out there that would donate information to a worthy cause like a nice small IP Stack. Can't hurt asking.
-
Some of my colleques have done amiga programming in their carreer. I got 2 books for free from them. One is an Os1.3 reference the orher an OCS hardware reference. The latter is in german :-(.
I also have the developer cd 2.1. So i think it will be enough to get me started.
As for the stack. I know you have an A500 so there might not be anything in it for you.
The A500 has no easy obtainable network interface. I would puy my stack on top of cnet.device. That means an A600 or 1200 would be required (guess what's in my fleet).
Maybe I can make it OS1.3 compatible. Then it would require changing it to a hardware interface available on the A500 to make it work for you. Perhaps we could work something out there. But I have no means of doing any A500 related testing.
As for donations and such. I dont want to make any obligations. If people donate I'm obliged to deliver. To me it is just a hobby. I don't want to have a 'time to market'. Not that this means anything in amiga context. Even amiga itself does not seem to be aware of the concept 'time to market'
:lol:
But I'm sure I will look into this matter as soon as my game database/starter is finished (which I haven't even started aswell.....so many ideas...so little time).
-
Does Contiki support preemptive multi-threading?
Yes. While the Contiki kernel is based on event driven cooperative multitasking, an additional library provides preemptive multi-threading. The reason for not basing the kernel on a preemptive multi-threading model is that it would increase the complexity not only of the operating system, but also of the applications that would run under it. By providing preemptive multi-threading as a library, only programs that explicitly require such functionality will need to pay the extra price.
-
Great! I didn't know that. I'm still not going to port it :-)
-
I didn't even think of the obligation. Dont I feel silly. In my defense, I just had a very big meal of filipino takeaway and was feeling kind of sleepy....
I didn't realise 1.3 was that bad! Although I did kind of expect it. When I finish the kickflasher it'll be upgraded anyway. Probably to 3. Then I'll get even more upset with the lack of RAM and upgrade to 9mb total.
Don't blame you for saying no to porting contiki. It'd be interesting but not really worth the hassle unless someone really wanted it. Did I mention it can have a VNC interface?
-
A preemitive task scedular would take too much ram (and time) due to it's complexity.
Nonsense!
A pre-emptitive task scheduler can be done in well under 100 bytes of code and a table, size of which depends on max number of tasks (Or maybe you just consider that too big / complex :-) )
And how do I know?
Becouse I've done it!
Of course it was very simple (didn't have priorities, events or anything else, but it kinda proved, that it is possible)
Maybe I'll finish it some day :-)
And I don't quite agree with pre-emptitive multitasking making things more complex than co-operative... With pre-emptitive you don't have to even think about giving time for other tasks, as the OS will switch to the next task after pre-set time.
-
Don't worry it was just an idea of yourse. Maybe I did fancy the obligation.
why do you think 1.3 is that bad.
The NIC I was talking about has nothing to do with the OS.
Nic is just the network interface. None of the amiga OSses have something like that build in. That does not mean you cant implement a network interface. This just takes some effort in hardware and in software.
As for hardware; with big box amiga's this is no problem. Just insert a network card.
As for wedgies the A600 and 1200 can use the PCMCIA interface to use a network card. The A500 has no such interface. (I'm speaking of interfacing directly to a network not via dialup).
There is a processor bus on the left if I recall correctly. And if that is unusable just pop the cpu and piggyback the expantions between the cpu and it's socket :-)
What you would need is a piece of hardware that allows your amiga to interface to the network. And a piece of software like cnet.device. I beleive the latter is called a SANA-II driver or something. You could slam the to be created TCP/IP stack on top of that and you'd end up with a networking enabled OS1.3.
Upgrading to a newer OS would not be needed if all the software is 1.3 compatible.
-
Tomas wrote:
Does Contiki support preemptive multi-threading?
Yes. While the Contiki kernel is based on event driven cooperative multitasking, an additional library provides preemptive multi-threading. The reason for not basing the kernel on a preemptive multi-threading model is that it would increase the complexity not only of the operating system, but also of the applications that would run under it. By providing preemptive multi-threading as a library, only programs that explicitly require such functionality will need to pay the extra price.
I think you can do away safely with this library, to me it seems like it was added as a mere curiosity. The kernel does not support pre-emptive scheduling: well, then no application library will give you the Real Thing. I am not saying nót having pre-emptive scheduling is bad---there are applications where you don't need it---just that you should not rely on that library too much (read: at all).
-
It's true. Pre-emptive multitasking is simple.
IIRC it involves the following steps (varies a little from platform to platform). This is a very basic example.
* Induce an NMI. Whether it be from a clock or whatever.
* Jump to handler.
* Save registers, PC, and stack somewhere.
* Grab next process from the list
* load its stack, registers and PC.
* End interrupt
I have nasty memories of doing this in MIPS RISC assembler.
Its what I don't get about contiki. I can only guess why cooperative multitasking was used. Maybe for portability?
It can also help if you don't want to reimplement low level functions. more than one preemptive multitasking OS can't happily coexist on one machine (VMs excluded).
Ohhh. I thought that AmigaOS 2+ made it a bit easier for networking.
That's just a completely uninformed guess.
And 1.3 seems to be fighting me all the way. Everything I find needs wb/ks 2 or later. I'd like FFS for floppies, and the ability to unmount too.
I'm going to have one helluva card under my 68k. I shot myself in the foot with the hard drive controller. If I could un-superglue the connector from my interface card I could add the extra connections I need for the RAM expansion. But I can't.
-
Generale wrote:
It's true. Pre-emptive multitasking is simple.
IIRC it involves the following steps (varies a little from platform to platform) [...] Its what I don't get about contiki. I can only guess why cooperative multitasking was used. Maybe for portability?
If you do not implement pre-emptive sheduling, easy as it is to implement, then you do not have to worry about race conditions and deadlocks. The kernel itself cannot be interrupted at crucial moments. Everything is single-threaded: a resource is either occupied or free, and there is almost no contention to it. These design considerations make cooperative scheduling far cleaner and easier to implement, but it comes at a price: your computer no longer has control over what the programs do.
And 1.3 seems to be fighting me all the way. Everything I find needs wb/ks 2 or later. I'd like FFS for floppies, and the ability to unmount too.
Forget about 1.3. It's dead, gone, and should be forgotten. Its BCPL legacy makes any decent DOS programming a nightmare. Stick to OS2.x or higher. So much easier and cleaner it hurts.
-
Heh. I forgot about race and deadlock. You can still get it though with preemptive multiprocessing.
Usually where shared resources, I/O and job control are concerned. There are algorithms to get around all that, but it makes the OS grow.
Even if it is something as simple as a semaphore or a mutex.
I keep getting urges to read through my concurrent systems stuff, but then I realise that my textbook can be fairly impenetrable without the right mindset.
WB1.3 does have some horrible hangovers I agree. It....angers....me. Can't wait to upgrade.
-
Fine. So I will not have to bother making the tcp stack 1.3 compatible. There will probably be too few programs making use of the stack. What are the requirements for amiga explorer anyway?
-
I wouldn't want you going out of your way to do it. Especially if software support is scant. Now that I think of it, the logical progression of thoughts says that if there isn't a TCP/IP stack available that works properly with wb1.3 then there probably won't be any software that uses said stack.
I just feel that 1.3 is incomplete somehow. It does some things, and only half-does others. Sort of like GTA3. There are so many half finished things in that game. If they'd finished off a lot of the things they were putting in, it would have been something extra special.
-
I can only guess why cooperative multitasking was used. Maybe for portability?
That might be one of the reasons. Think of C64 for example. Just save the registers somewhere, that simple. But have you ever thought of how to write that on C? I'd guess it would be quite impossible.
There are just so many things you can't write in C. Accessing certain registers, zero page etc... Don't know if it would be possible to even change the stack pointer (if you wanted to share the stack between many tasks)
But in any case, Contiki is a proof of what can be done on an unexpanded C64 with C.
-
Not possible with vanilla C. It has to be done with assembler. C, especially of the ANSI variety knows jack about hardware, because that violates the 'platform independence' of ansi C.
I hate to think of what C would do if used for state saving and restoration. hehe. strange concept really.
Gotta say it. ANSI C is platform independent, fast and good at what it does. Java is none of those. Sorry, I just _really_ hate java. It was a good idea (I guess) that went badly astray.
I find contiki inspiring. To my eyes anyway, it is more capable byte for byte than GEOS, which was painfully optimised assembler. Mind you, geowrite still impresses me.
More OSes should be like it.
I get upset that any OS needs more than 1mb RAM. It shouldn't!...unless it does a lot of things like unix/linux which does pretty well at keeping its RAM footprint down.
And windows shouldn't need more than 640k RAM, because nothing should ever need more than that, eh, Mr. Gates?
-
@Doppie1200
Amiga Explorer needs bsdsocket.library emulation for IP. I'm really liking the idea of a real bsdsocket.library wrapper for lwIP that handles access to the network dynamically (i.e. the network is available as long the library is loaded by at least one task). I really hate that most Amiga stacks run like an application and not a service.
Trev
-
Quite frankly, can't think why anyone would want to use it
That's what I said about MUI. :lol:
-
I can't use MUI. Either that or I'm doing something wrong.
-
@Generale:
MUI requires WB2.0.
/Patrik
-
Trev wrote:
@Doppie1200
Amiga Explorer needs bsdsocket.library emulation for IP. I'm really liking the idea of a real bsdsocket.library wrapper for lwIP that handles access to the network dynamically (i.e. the network is available as long the library is loaded by at least one task). I really hate that most Amiga stacks run like an application and not a service.
Trev
Maybe they had good reason to implement the stacks that way I don't know. I'll keap your idea in mind when I'm going to take this beyond ythe vapour stages.
-
Oh. it needs wb2 or later. That explains it.
Anyway I have a question about having a dynamically loaded stack.
Would it at least have a small resident portion to load the stack when there is incoming data?
I mean it's perfectly fine to have something that is loaded when needed, without doubt. But how easy is it to initialise whenever the stack is required by an incoming packet, for uses such as file sharing when there may be no need for the IP stack most of the time.
I hope you can understand what I mean. I can't figure out how to explain it properly. Sorry.
-
Just realising most of this thread is offtopic but here goes another post.
Generale wrote:
Anyway I have a question about having a dynamically loaded stack.
Would it at least have a small resident portion to load the stack when there is incoming data?
how easy is it to initialise whenever the stack is required by an incoming packet, for uses such as file sharing
My interpretation was that the stack was loaded on demand. An incoming packet would never load a TCP/IP stack. When something like filesharing is active the stack would be loaded. The filsharing software will listen for incoming data (connectionless or not). Filesharing means there is a demand for the stack to be present.
But when filesharing is off and no other programs are active that requires a stack the stack should unload.
I like this idea and will surely look into it. But for staters I guess its best to get it going the traditional way and have the user load/unload the stack.