I have an idea.

When we only have 64KB of base memory, and everything else is addressed through a little banking window

I guess it should be possible to reprogram Ultimate 1M and its integrated MMU to switch whole 64 kB or at least bigger memory window, and/or page 1 (stack).

Would it help?

That would have helped enormously. Even something as simple as a second banking window (say, $8000-$BFFF) would make life a lot easier. The Amstrad CPC has a fairly flexible banking scheme (described in the SymbOS docs), but unfortunately on the A8 we must work with what we're given. The best way to use more than a single bank on the A8 is to compile an application in multiple segments which run at absolute address $4000 and use inter-bank jumps so that the code which needs to access data in bank n is also in bank n. That's one way to accomplish large applications. The other way to access allocated RAM is of course indirectly, which will be slow. Fortunately I intend the control toolkit to be rich enough that the UI does most of the hard work (for example, if you want a text editor with a 16KB buffer, put a multi-line text control in your window, allocate 16KB of RAM, and pass that to the text control). The great thing about having the window server running on a cartridge is that it can access all banked RAM without limitation. Same with the kernel and most of the other services. Drivers in RAM become a bit tricky, especially since MADS only allows a single segment per relocatable binary, but overcoming these things is part of the drama. :)

I guess it should be possible to reprogram Ultimate 1M and its integrated MMU to switch whole 64 kB or at least bigger memory window, and/or page 1 (stack).

Would it help?

http://www.symbos.de/

I've been lucky enough to have Prodatron's ear for a couple of years, and this helped the A8 project progress from a GUI front-end to a pre-emptively multitasking graphical OS.

One may also look at the rather long AA thread:

http://atariage.com/forums/topic/154520 … ari-8-bit/

And my website:

http://atari8.co.uk/gui/index.html

The project began as a front-end for stand-alone applications, and later was going to be some kind of updated Diamond GOS (i.e. a shell on top of DOS). But then the issue of multi-tasking (or at least task-switching, at first) was discussed, and then I started speaking to the author of SymbOS (who was also able to look at the "long term" picture). The problems inherent in running a graphical shell on top of an existing DOS should be obvious. No-one seems able to agree on a "standard" DOS (SDX is justifiably popular, but believe it or not there are many people who don't want to use it, despite the fact it appears on almost every piece of hardware we can buy today), so one cannot even depend on a sophisticated file system unless use of SDX is mandatory, which requires two software layers designed by different people sharing the same cartridge ROM space and the same extended memory. A recipe for disaster, or at least very painful headaches. Consider (or research) what actually comprises a multi-tasking micro-kernel operating system and you'll understand why writing a new OS from scratch seemed the lesser of two evils. ;)

This is hardly a unique situation: consider GEOS and the aforementioned SymbOS. GEOS (though rather limited, single-tasking, and slow) had a lot of good applications, and meanwhile third-party development for SymbOS is now gathering pace, since development tools are getting better.

Meanwhile, GUIs on top of DOS haven't really caught on. I see few (well, no) third-party Diamond GOS applications, despite the fact it now works with the latest SDX, and we have a handful of other GUI DOS shells (some mentioned in this thread), and I see little progress being made. The scope for application development is certainly almost nil if the shell is written in BASIC.

So what's being written is a fast, pre-emptively multitasking graphical OS using a micro kernel architecture, fully machine code, which runs in a bank-switched cartridge and is able to utilise up to 1MB of RAM. There are rich window controls, rectangle-based window manager, 16 tasks, inter-process messaging, timer processes, 12x12 and 16x16 icons, 256 character proportional fonts up to 32pt, Adobe BDF font conversion tool chain, and the whole thing (since it was rewritten to use the kernel, scheduler, and cartridge) was up and running in 18 months, and is probably another 18 months from completion.

Development is currently undertaken using the MADS assembler, and the MADS relocatable binary format is used for applications (which are loaded using a relocating loader). MADS' relocatable format is not ideal (support for .DS would be useful, for instance), but it works surprisingly well and perhaps there'll be more interest in developing the binary format in the future.

In any case, it's very liberating to take complete control of the hardware when the machine boots. When we only have 64KB of base memory, and everything else is addressed through a little banking window, it's useful to be able to jettison useless stuff like the resident screen handler and floating point. The OS interrupt handlers are also high-latency (when it comes to Pokey timers), so the whole thing has been rewritten to suit a multi-tasking OS. Getting rid of the OS and DOS allows us to use all of page zero, and not worry about the segmented stack (it is split into four chunks and paged in and out) being corrupted by DOS or the SDX formatter. Anything "legacy" which deals directly with the hardware (or screen memory, extended RAM, interrupts) will completely wreck a multitasking OS. The two just do not sit well together. So I decided to do the job properly. Certainly it takes twice as long, but it's rather enjoyable to write. :)

Wiec nie wiem czy sie przyda.

EDIT:

Czyli nie masz U1MB, side, ide+, ani carta. Da się załatwić.

EDIT:

Najlepszym tego przykładem jest chyba Draco - wszystkie programy przezeń pisane są pisane na Atari. Wcale męczyć się nie trzeba:

http://drac030.krap.pl/

(to żart, żeby nie było) :D

Demo should be ready in a few days. Here's a taster:

http://youtu.be/Xugc1tqYf0c

Impressive! It looks great. Can you describe a little bit how os is built inside?