I'll put together updated customised ROMs with FDISK over the weekend and these will be hosted at atari8.co.uk as per usual. I've no objections to the tools being included on the official ROMs or toolkit disks, but was simply never asked the question yet. In any case, FDISK 4.5 just takes up room on the CAR: device so in some ways it just makes sense to use the tools from the APT Toolkit ATR.

The general system architecture is modelled on SymbOS:

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. :)

It's an operating, not an application, so it boots direct from the cartridge and takes complete control of the machine. No need for Sparta or any other DOS. :)

Thanks! The passages of interest will hopefully be understandable to me soon! :)

Looks great. Interested. :)

I can make little sense of this in translation, but FDISK2 by Drac030 and FDISK 4 by FJC don't belong in the same sentence. FDISK2 partitions the disk according to the old partitioning scheme used by the KMK/JZ and IDEa interfaces. The IDE Plus 2.0 BIOS is backwards compatible with the old partitioning scheme used by FDISK2, but it's preferable to use the APT partitioning scheme (for reasons of compatibility with SIDE, SIDE2, Incognito, etc). FDISK2 cannot understand APT, but FDISK (FJC) uses it exclusively, and is the only APT editor available. It might make sense to bundle it with the IDE Plus 2.0 toolkit disk, in order to avoid confusion. :)

Critical soft-driver update: http://atari8.co.uk/news/

http://atari8.co.uk/apt/idea/

http://atariage.com/forums/topic/220750 … try2912054

With manual hardware selection.

OK - thanks Sebastian. We'd better discuss both detection methods on IRC to save me messing around. ;)

Turn the SIDE 1 SDX off to avoid conflict. RTCs shouldn't be a problem. Just install the Ultimate RTC driver.