Have a look over at the Atari Age forum to see how the project is progressing. I considered it more important to make significant progress on the core code than release frequent demos. I am currently working on a resource manager (having done a complete re-write of the menu manager) and when this is closer to completion I will release another demo for people to play with. It will demonstrate a movable/sizeable window with a complete set of controls, as well as the menu system and some static icons on the desktop.

What - rewriting the whole GUI from scratch? I have around 2,500 lines of code, and only 500 lines of code (those in the GFX.S module) are concerned with drawing to the screen. And of those 500 lines of code, there are about 20-30 direct writes to the screen RAM. Moreover, GFX.S hasn't grown in size for weeks (while GUILIB.S grows exponentially). There is much more to a GUI than drawing lines and blitting. The bulk of the system is all about object manipulation.

Exactly so. Most of the GUI operations are reducible to:

- Clear an area of the screen
- Move an area of the screen to a back-buffer
- Move buffered background data back to the screen
- XOR an area of the screen
- Draw a horizontal/vertical line
- Blit a bitmap to the screen (an icon or alpha character)

This is all pretty straightforward and re-usable code (e.g. the code to draw boxes and drop-shadow boxes simply calls the draw horizontal/vertical line routine a few times). To implement VBXE support, one would change the clipping limits, re-write PARTS of GFX.S, replace certain code with blitter operations, etc. Not a trivial task, but probably only a month's work.

As for drivers, why on earth would I concern myself with a device independent screen driver when I'm writing a GUI for an Atari 8-bit? 99.9% of these machines have a fixed 1bpp 320x192 display. Why overload screen draw operations with multiple levels of indirection, varying screen dimensions, etc, just to have a system which runs sluggishly but which is easier to convert for VBXE use?

The fact is, it would be better to regard GFX.S as the "driver", and to think in terms of "draw line", "render bitmap", and "clear screen area" as the lowest-level operations. There are half a dozen such operations at the moment, and this code is all we need to re-write to implement support for VBXE modes.

Well said. Of course the "proper" way would be to render everything at the pixel level and simply implement a driver which provides the low-level interaction with the screen. But this is an Atari 8-bit with a 6502 processor. I said at the start that the GUI would have to employ "techniques normally seen in games and demos". How many demos draw to the screen using the CIO? :D

VBXE modes would obviously solve a lot of problems (such as representing a 72dpi document on the screen), but the objective is to get something working on standard hardware first. Of course it's fairly easy to add VBXE support later: amend masking and screen RAM write routines, and adjust the size of the root (SCREEN) object in memory. But naturally when you introduce device independence, you introduce an overhead. "JSR write_byte" is many cycles slower than "STA (SCR),Y". Let's get the basics out of the way first. In any case, with VBXE's blitter, it would be difficult NOT to write a fast and responsive GUI. Or one could just use an ST. :)

Pin's meaning is especially hard to translate, ;) but SDX plus GUI is a match made in heaven. The system will use the full features of the Sparta FS, and will have a clock-widget in the top-right corner of the screen. You'll double-click on it to set the system time. Drag and drop files(s) from one folder to another. The usual basic GUI stuff.

Cartridge or files? Who knows. I'll make the best practical decision after taking everything into account. All my software has always been free. If it's on a cart, you'll have to buy yourself a flashable cart and flash the GUI onto it. It's it's on disk, there is zero financial outlay. :)

Cascading menus are now finished, and I've started the window/dialogue render routines, and the rest of the event handler. It will take several weeks to code up all the controls (scroll bars, text boxes, list boxes, buttons, etc, etc).

The new GUI will be able to launch "legacy" applications and return to the desktop. It's a pretty essential feature. I should have listed that in the specifications. :)

Thanks for the encouragement. There should be a demo with a dialogue box and some draggable icons in the next few weeks.

http://www.atari8.co.uk/downloads/HDSC_32MB.jpg

MyIDE with SDX driver and KMK/IDEa (they fight for superiority).

XM301/SIO2SD conversion with built-in SIO2PC for moving data to and from PC and making HDD backups.

My KMK works now, so I needed a reason to use the MyIDE driver:

DOS writing: 59411.3628 B/sek
DOS reading: 71035.3252 B/sek
DOS average: 65223.344 B/sek

(Eight unrolled reads in the MyIDE driver's read loop, and four unrolled writes). :)

JEALOUSY.VX at 10 fps:

http://www.youtube.com/watch?v=R36TS0uZuEU

Indeed so! :)

It's something I would consider but it's pointeless duplicating the functionality of Sparta Commander for SDX. Perhaps a version which works with any DOS would be useful.

Hardly a bug. You're loading any old file into the font buffer. :)

<SHIFT+CTRL+H> is the only command which lets you set the filemask for the disk menu and then press return. To get a file selector after you pressed <SHIFT+CTRL+N>, press <Tab>. Sadly whatever you already typed is ignored in that case.

In the next version I will do away with typing filenames altogether: file selector by default. It will be more consistent.