A new OS for our Atari ?

[TXG/MNX]

Hi,

 

People overhere are talking alot about porting games and tools from the c64.

 

We had Diamond GOS but GEOS on c64 was better. Diamond GOS is dead

 

We had a lunix port for the atari, but this port seems to crash and no support

 

I would love to see an OS like JOS or WINGS ported to the Atari 8-bit. or something like that.

 

We have all the hardware like the c64 and harddisks are pretty common right now, also memory upgrades.

 

For both projects the source is free. So I would like to see an open-source project like it for the 8-bit. It doesn't need to be a port just something like it would be nice.

 

Some ideas:

Unix/QNX like architecture

Microkernal

Message Passing

Multitasking

mountable devices

drivers for rs232, xep80 and such

....

 

TXG/MNX

 

JOS link http://www.sweetcherrie.com/jos/

Wings link http://www.king.igs.net/~billnacu/wings/

[patarik]

It is bad luck,

 

but JOS and WINGS require 65816 processor.

I havn't seen any valuable implementation of 65816 in atari XL/XE.

If you know somebody with 65816 in atari XL/XE and it works without problem, let me know.

 

Things like multitasking is nearly impossible to make on 6502.

 

Comunity can try to continue with contiki port, but contiki uses character graphics mode to make GUI (atari has much fewer colors in this modes).

Other problem is that we must programme driver for expanded memory

for cc65 to make some valuable port of contiki.

[Cybernoid]

Actually, Contiki has a colorful GUI for the C64. Something similar can be done for the Atari. The Driver has to be written for Contiki however.

 

Plans for the future...

 

~C

[patarik]

We also need working ethernet card for usable contiki OS.

When it will be done?

[TXG/MNX]

Contiki seems to be nice, only using the port will be much slower then a real atari 8-bit specific program.

I would love to see something like this started as an open-source project, so that all 8-bit coders can contribute there knowledge...

 

I am sure the 8-bit can handle just a small OS like this, look at LUNIX it did run on a 1Mhz C64... and even this version could handle tcp/ip and ftp... and more...

[patarik]

Hm.

LUnix was updated in september 2004.

I am going to see his sources.

[TXG/MNX]

I know it was updated, but the atari port is not working the last version i saw did crash directly after boot...

[Dr. Van Thorp]

Is there some massive resource page someplace for new operating systems that run on non-X86 machines?

[Fröhn]

Actually, Contiki has a colorful GUI for the C64.  Something similar can be done for the Atari.  The Driver has to be written for Contiki however.

the c64 can easily use all of it's 16 colors. this is different on atari: hires modes only allow two colors.

 

but anyway, as far as i can see on the contiki homepage, there IS already an atari 8-bit port:

 

http://www.sics.se/~adam/contiki/

[mos6507]

I don't think multitasking is that useful on really slow processors with limited memory. Task switching, maybe.

 

The only aspect of multitasking that matters is I/O, and that is mostly important with networking, which is already handled via ConTiki.

 

I think what can be done with the Atari 8 WITHOUT a 65816 is to better utilize banked RAM.

 

There are only two non-game programs that I'm aware of that use banked RAM transparently, PaperclipXE and BasicXE.

 

But in the case of BasicXE it's still not smart enough to detect more than 128K.

 

It's a shame that the majority of what people used extra RAM for in their 8-bits was RAMdisks.

 

I think a 65816 would really make things easier but there has never been a successful product to market such an upgrade. And without being able to offer higher speed (unlike the C=64) it's generally not seen as a good investment.

 

Upgrading RAM, however, is relatively straightforward.

 

The problem there, to me, is that doing it via PortB is a mistake because once you start reassigning bits you start losing XE compatibility at some level.

 

I personally think that a be-all-end-all RAM expansion should either be via stacking another PIA chip onboard, or even better, just put RAM in a cartridge and bank the cart as if it were ROM. The PIA approach has the added benefit of enabling ANTIC banking. The cart approach is solderless and opens up a secondary bank window. The combination of the two would be pretty powerful because you could partition off the banked RAM into two categories, like graphics vs. program data, or OS extensions vs. programs. It would make sense to have the internal RAM be for graphics and data because of the ANTIC banking, and the cart for program code.

 

The largest single application for the Atari8 I know of is BBS Express and that was written with a kind of dumbed down virtual memory model in which "modules" would swap in and out of a memory window. By using a RAMdisk, this process was pretty fast, but even then, you are still asking the CPU to move data in and out of that window. Even moving data from one area of RAM to another on the A8 is slow. Banking, however, is instantaneous, almost equivalent to having one big continuous program. Without the latencies involved in swapping modules you could, for instance, have a more extensive TCP/IP stack that consumes 128K or more of RAM in total but only occupies a small stub of main RAM at a time. I believe this is how Spartados-X and other OSS supercarts work a lot of their magic, but with just banked ROM. With RAM you can manage larger buffers and datasets.

 

You do have to think, however, what kind of programs you'd want to have running on your machine to use this space. Most people just use their old machines for games. So writing new OSs and stuff like this just becomes an exercise where you reach the prototype stage and then nothing happens afterwards because nobody actually uses the new environment for anything. So it doesn't really make sense to spend the effort on this if you don't also intend on writing a killer app to utilize it.

 

In my case, I'd be interested in setting up my A8 again as a telnettable BBS or webserver down the road. I don't think I'd use it for anything else besides games although it would be cool to see it do advanced things.

[cas]

I don't think multitasking is that useful on really slow processors with limited memory.  Task switching, maybe.

 

Well, I see no preemtive multitasking (like Linux, Windows XP, OS/2 etc) for the 8-bit, but cooperative Multitasking (like MacOS Classic, Windows 3.1x, Oberon, Mobilephones) is possible. Cooperative Multitasking is essentially Task-Switching.

 

The only aspect of multitasking that matters is I/O, and that is mostly important with networking, which is already handled via ConTiki.

 

I think what can be done with the Atari 8 WITHOUT a 65816 is to better utilize banked RAM.

 

I agree 100%. There should be support for this on an OS level, and this support should be hardware independent (PORTB Ram Extension, Cartride RAM, XL OS RAM, even virtual pages ram on Harddisk or Ramdisk) cc65 has already support for this on the programming language level. But having support on an OS level (can be a DOS OS) would be really nice.

 

There are only two non-game programs that I'm aware of that use banked RAM transparently, PaperclipXE and BasicXE.

 

But in the case of BasicXE it's still not smart enough to detect more than 128K.

 

It's a shame that the majority of what people used extra RAM for in their 8-bits was RAMdisks.

 

I think a 65816 would really make things easier but there has never been a successful product to market such an upgrade.  And without being able to offer higher speed (unlike the C=64) it's generally not seen as a good investment.

 

Upgrading RAM, however, is relatively straightforward.

 

The problem there, to me, is that doing it via PortB is a mistake because once you start reassigning bits you start losing XE compatibility at some level.

 

For me, usch solutons should be Hardware independent, that is there should be a OS Interface that hides all Hardware dependencies from the programmer. The Programmer just ask for an amound on memory and gets an address. Essential a virtual memory manager.

 

I personally think that a be-all-end-all RAM expansion should either be via stacking another PIA chip onboard, or even better, just put RAM in a cartridge and bank the cart as if it were ROM.  The PIA approach has the added benefit of enabling ANTIC banking.  The cart approach is solderless and opens up a secondary bank window.  The combination of the two would be pretty powerful because you could partition off the banked RAM into two categories, like graphics vs. program data, or OS extensions vs. programs.  It would make sense to have the internal RAM be for graphics and data because of the ANTIC banking, and the cart for program code.

 

Hardware dependencies shouldn't matter if the OS Interface can hadle all of them (be loadable driver). Like SIO. As a programmer you don't care if you're talking to a 1050, XF551 or APE. Should be the same with Memory.

 

The largest single application for the Atari8 I know of is BBS Express and that was written with a kind of dumbed down virtual memory model in which "modules" would swap in and out of a memory window.  By using a RAMdisk, this process was pretty fast, but even then, you are still asking the CPU to move data in and out of that window.  Even moving data from one area of RAM to another on the A8 is slow.  Banking, however, is instantaneous, almost equivalent to having one big continuous program.  Without the latencies involved in swapping modules you could, for instance, have a more extensive TCP/IP stack that consumes 128K or more of RAM in total but only occupies a small stub of main RAM at a time.  I believe this is how Spartados-X and other OSS supercarts work a lot of their magic, but with just banked ROM.  With RAM you can manage larger buffers and datasets.

 

You do have to think, however, what kind of programs you'd want to have running on your machine to use this space.  Most people just use their old machines for games.  So writing new OSs and stuff like this just becomes an exercise where you reach the prototype stage and then nothing happens afterwards because nobody actually uses the new environment for anything.  So it doesn't really make sense to spend the effort on this if you don't also intend on writing a killer app to utilize it.

 

In my case, I'd be interested in setting up my A8 again as a telnettable BBS or webserver down the road.  I don't think I'd use it for anything else besides games although it would be cool to see it do advanced things.

 

I can think of many applications, like a good spreatsheet or nice development IDE.

 

Along with an virtual memory manager we need a standard for relocateable loading. Today all Atari Programs are loading at fixed adresses. So it is sheer luck if you can load two programms into memory and they don't destroy each other (DOS and Application, Driver an Application, etc). If an virtual memory manager manages all memory, then programs can be loaded into free memory blocks, no matter where they reside (RAM, Ext Ram, even pages to harddisk).

 

I would really like to see a team of skilled programmers to start an ATARI Standarization entity (like IETF or W3C, virtually connected by the web) to define such new OS Interfaces and let individual programmers come up with reference implementations.

 

This would help that not every programmer has to re-invent the wheel over and over again.

 

How about the ATARI Engineering Task Force, AETF?

 

Or am I tooo ambitious?

 

Carsten

[patarik]

OK

let summarize

 

The new OS could have

1. task switching

2. memory manager for managing memory allocation and releasing

(memory = standard raw 64KB plus all kind of expanded memory)

3. TCP/IP stack ?

4. later some GUI ?

 

But the most important are applications. Could The new OS hosts applications

which we dont have now? Will be the new applications for the new OS enough interesting to move people to using the new OS?

[patarik]

for more information about atari 8-bit and 65816

goto

http://atariarea.histeria.pl/forum/viewtop...opic.php?t=2368

[Heaven/TQA]

could not be implemented a 65816 core into atari800win??? just for testing? would be nice to see what is possible with atari & 16bit cpu even just running in 1,79mhz mode...

[dely]

It's running without any problems. Since 2003 in my Atari.

[TXG/MNX]

I would like to join, and just help as much as I can.

 

TXG/MNX

[Tickled_Pink]

*Sigh* This discussion brings back memories. I had a similar discussion 10 years ago (when I first discovered the net through college) with Bill Kendrick and Dave Paterson. Think we were going to call the project ADOS ... if I recall, BK seemed to think that multitasking was possible on the 6502 but I felt the lack of direct access to the program counter made it difficult.

 

Of course, it never got off the ground - or we'd never have need for another discussion on the topic :wink:

[Wrathchild]

Was the 6809's OS9 portable to the 6502?