New GUI for the Atari 8-bit

[Tezz]

How nice is that!

Excellent progress Jon, fantastic work as ever. It's a truly inspirational achievement.

[UNIXcoffee928]

"I'll come right out with it and admit that I hardly understood a word of that."

 

Sorry that that was unclear. I had lost most of that paragraph in an Atariage-editor fault, and re-typed that portion quickly.

 

I was suggesting the creation of both desktop & object bitmasks as tables in extended RAM banks, to allow for an environment where bit-shifted values for directional movement of objects could be pre-computed during idle-time, within the program's main loop.

 

I later worked on establishing a proof for this, and it seemed to fail to be up to be up to snuff cycle-wise, so, I didn't bother going on about it. I could email my findings to you, if you're interested in sifting through it for other ideas that may be useful, though.

 

Overall, the initial mention was just a quick idea, and I should have thought it out a bit more before posting it. Losing the first draft of it in the editor didn't help much, either... ha, but you know how it is when you've been up for like 36 hours, lol.

 

What I meant by "joystick directions" was to use the already established joystick bit-pattern as an easy mnemonic for "handles" at the corners & mid-points of the perimeter of each GUI object. Just to establish and easy to remember convention. This way, any clicked point could be an offset from any of those points, for the given object, instead of working your way through the object hierarchy from the desktop down to the window/icon in question. These are the standard Atari joystick direction values & associated joystick functions:

 

{0100

0101

0110

0111

1000

1001

1010

1011

1100

1101

1110

1111}

 

Easy enough. Now if you make a little poster with 8 points of the compass, and assign the correct nybbles to the correct points, you can always see, at a glance, anchors, or movement directions which you could create offsets from, and then use standard trigonometry to facilitate an appearance of analog movement, from a constrained digital directional system.

 

I'm a little time-limited, lately, so, regretfully, I can't go into it too deeply at this moment.

 

Check out this video on how Constraint Systems were used in the program, "Thinglab", made at XEROX PARC, in 1978. It's a little different than what I'm going on about, but you should find it quite interesting, and pick up a thing or two, from it.

[media='']http://www.cs.washington.edu/research/constraints/videos/thinglab-1978.mov[/media]

Edited September 19, 2011 by UNIXcoffee928

[flashjazzcat]

"I'll come right out with it and admit that I hardly understood a word of that."

 

Sorry that that was unclear. I had lost most of that paragraph in an Atariage-editor fault, and re-typed that portion quickly.

No problem - we've all been there.

 

I was suggesting the creation of both desktop & object bitmasks as tables in extended RAM banks, to allow for an environment where bit-shifted values for directional movement of objects could be pre-computed during idle-time, within the program's main loop.

 

I later worked on establishing a proof for this, and it seemed to fail to be up to be up to snuff cycle-wise, so, I didn't bother going on about it. I could email my findings to you, if you're interested in sifting through it for other ideas that may be useful, though.

 

Overall, the initial mention was just a quick idea, and I should have thought it out a bit more before posting it. Losing the first draft of it in the editor didn't help much, either... ha, but you know how it is when you've been up for like 36 hours, lol.

Yeah - been there...

 

But this is an interesting notion. There will be plenty of idle time and we need to find something useful to do with it other than service interrupts and timer events. One thing I will say is that I've deliberately aligned a great many GUI components on byte boundaries, so other than the mouse pointer itself and textual elements, there's not a great deal of bit shifting to do (and any bit shifting that is done is accomplished using LUTs). Please email your findings, though, since (as you correctly imply) incomplete or seemingly unsuitable ideas have a habit of finding their way into the project in a modified form (read: raster interrupt mouse pointer).

 

A perfect application for idle time might be the creation of the Classic-Mac style bitmask for drawing icons underneath desktop windows. There's contention for the buffer space occupied by this mask, but when windows have just been rearranged, it might be an opportune moment to build a negative mask of the desktop window silhouette, just in case the next thing the user does is drag a desktop icon.

 

What I meant by "joystick directions" was to use the already established joystick bit-pattern as an easy mnemonic for "handles" at the corners & mid-points of the perimeter of each GUI object. Just to establish and easy to remember convention. This way, any clicked point could be an offset from any of those points, for the given object, instead of working your way through the object hierarchy from the desktop down to the window/icon in question. These are the standard Atari joystick direction values & associated joystick functions:

 

{0100

0101

0110

0111

1000

1001

1010

1011

1100

1101

1110

1111}

 

Easy enough. Now if you make a little poster with 8 points of the compass, and assign the correct nybbles to the correct points, you can always see, at a glance, anchors, or movement directions which you could create offsets from, and then use standard trigonometry to facilitate an appearance of analog movement, from a constrained digital directional system.

 

I'm a little time-limited, lately, so, regretfully, I can't go into it too deeply at this moment.

This is a little more difficult to grasp, but I think well worth getting to grips with. It's starting to remind me - in a way - of the region notation used by the Classic Mac OS.

 

Check out this video on how Constraint Systems were used in the program, "Thinglab", made at XEROX PARC, in 1978. It's a little different than what I'm going on about, but you should find it quite interesting, and pick up a thing or two, from it.

[media='']http://www.cs.washington.edu/research/constraints/videos/thinglab-1978.mov[/media]

Great viewing - quite fascinating. Thanks for the link.

[flashjazzcat]

Just stumbled on this:

 

 

 

http://www.stryker.pigwa.net/atari/atari_window_system.atr

 

Doesn't do a great deal, but it's fast and makes interesting use of PMGs.

[Gunstar]

We've had a couple of those virtual res type apps for the ST over the years.

Let you run a desktop larger than your actual physical monitor/res could do.

 

I have to say, while not knocking anyone's idea's, that I never did care for

them at all...

 

That's fine if you didn't like them, but I see no reason why anyone would be against the GUI having this ability besides the programmer with the extra work involved, it's bonus, if you don't like virtual desktops in high color low res, then you just ignore those modes and stick with the high-res mode! It's ALL BONUS! I for one, mostly working with either wordprocessing or graphics want it, so when I'm writing, I use high-res, but when I'm using graphics, I can use a low-res, high-color mode that scrolls, or not, at this point I want lots of colors for my art, and don't care a bit how detailed desktop icons are, or if low-res text has to be used. 256 color wallpaper on an 8-bit desktop will look awsome and would make up for poor icons (which could still be very colorful).

[flashjazzcat]

Not so much a question of the extra coding work involved (after all, what's an extra hunded hours' work on top of a thousand or so?), but as soon as different bit-depths are catered for, there's great potential for an overall performance drop. Of course there are two ways to look at this: we might consider the situation which occured when higher colour depths were bolted onto the Apple Quickdraw library, which had been designed with 1bpp in mind and (reputedly) ran slowly in 256 colours until someone came along and rewrote the graphics library. So do I go back to the drawing board now and rewrite all the render code so that it will work in HIP and TIP modes, etc? I think not, given that the overriding concern right now is to get something reasonably complete running by next summer. Fortunately the graphics library is sufficiently modular that I might revisit it for version 2, and rewrite it for higher bit depths, should the mono system prove to have sufficient processing slack. This is probably the same approach I would take with a VBXE version. Too much ambitiousness now - to wide a scope - and the project might become sufficiently intimidating that it loses momentum altogether.

[Gunstar]

Not so much a question of the extra coding work involved (after all, what's an extra hunded hours' work on top of a thousand or so?), but as soon as different bit-depths are catered for, there's great potential for an overall performance drop. Of course there are two ways to look at this: we might consider the situation which occured when higher colour depths were bolted onto the Apple Quickdraw library, which had been designed with 1bpp in mind and (reputedly) ran slowly in 256 colours until someone came along and rewrote the graphics library. So do I go back to the drawing board now and rewrite all the render code so that it will work in HIP and TIP modes, etc? I think not, given that the overriding concern right now is to get something reasonably complete running by next summer. Fortunately the graphics library is sufficiently modular that I might revisit it for version 2, and rewrite it for higher bit depths, should the mono system prove to have sufficient processing slack. This is probably the same approach I would take with a VBXE version. Too much ambitiousness now - to wide a scope - and the project might become sufficiently intimidating that it loses momentum altogether.

 

Could this be an option that is implemented through an application by programmer of said application? In other words, can someone develop a graphic arts app for your GUI that could change the desktop and windows to the graphic modes the graphic arts app supports? Or does it have to be in the base GUI code?

[flashjazzcat]

Could this be an option that is implemented through an application by programmer of said application? In other words, can someone develop a graphic arts app for your GUI that could change the desktop and windows to the graphic modes the graphic arts app supports? Or does it have to be in the base GUI code?

Well - put it this way - you can create your own custom objects, and you will be able to redefine the render methods of exisiting objects (as well as naturally create render methods for your new objects), so the possibility surely exists. I'll try to make things as flexible as I can within reason.

[flashjazzcat]

I'm gradually easing myself back into this project now, and have started by recoding the rendering routines so that they can be fully masked (in a way not dissimilar to Apple's QuickDraw library). This will ultimately mean that objects can be drawn through arbitrary shaped masks (we're in no way limited to rectangles), but for now the main purpose of the exercise is to draw the desktop windows front to back. This will allow immediate visual feedback when moving or resising the top window, followed by the background objects "filling in the gaps" (or at least appearing to). I prefer this approach to dirty rectangle lists or double-buffered screens, but time will tell how effective it is. Unfortunately the whole lot has to be coded in-line for speed. I'm greatly concerned by the impact the extra in-line instructions (we're talking about an extra AND and OR here and there for each screen write) will have on performance during time-critical operations, but on the other hand this takes care of all our masking requirements in one fell swoop.

 

In this video, not all rendering routines are compliant, but you can see that the vertical strip of set bits in the background mask prevents the background from being overwritten. This mask could be absolutely any shape at all, and doesn't have to lie on byte boundaries.

 

http://www.youtube.com/watch?v=93kTzdUvg-8

 

The key to really capitalizing on this, of course, will be dynamically creating masks at sufficient speed.

Edited October 18, 2011 by flashjazzcat

[UNIXcoffee928]

Yes, that is what I was trying to get across... however, I was also saying to use a Hybrid Approach... by employing both masks and a multi-buffering scheme, dependent upon the needs of the object that you are working with. Just add a CanBeBuffered parameter, so that the option exists to take advantage of extended memory, via multi-buffering to different RAM banks. I'm not sure if they would be mutually exclusive techniques, or if they could be combined, simultaneously... that you would need to find out via experimentation, based on your implementation.

[flashjazzcat]

Yes, that is what I was trying to get across... however, I was also saying to use a Hybrid Approach... by employing both masks and a multi-buffering scheme, dependent upon the needs of the object that you are working with. Just add a CanBeBuffered parameter, so that the option exists to take advantage of extended memory, via multi-buffering to different RAM banks. I'm not sure if they would be mutually exclusive techniques, or if they could be combined, simultaneously... that you would need to find out via experimentation, based on your implementation.

 

This makes sense, although it will be tough to manage. The aim is to code all the rendering routines so that they'll use a more efficient non-masked approach depending on the contents of the masked flag. The forground window, for example, will always be rendered without masking (clipping being managed separately). Sure, having each window buffered separately in extended RAM would be quicker, and then we could overlay them off-screen very rapidly in the correct order, then blit the whole lot to the display. I very quickly decided that without individually buffered window bitmaps, the off-screen rendering wouldn't be so good, since if one window's contents rendered very slowly, the user would be left sitting around with no visual feedback whatsoever (except perhaps an hourglass pointer). At least rendering stacked windows front to back using a mask, one gets an immediate visual impression of the redraw (as the newly exposed underlying areas redraw themselves around the front window). The buffered model (which Windows uses) would be way faster, of course, and it's correct to say that when the necessary RAM is available, this would be the preferred technique.

 

A nice advantage of masking is that we can very easily draw, highlight and erase desktop icons without having to redraw anything else. It seemed overkill to rebuild the entire display offscreen just in order to highlight a desktop icon which was situated at some awkward position, partially obscured by intersecting windows but still selectable. As long as we have the composite mask of all the open windows, we can happily draw what we like on the desktop without disturbing anything else.

Edited October 19, 2011 by flashjazzcat

[atarixle]

stupidly, a full-screen-redraw is exactly what I'm still doing in BOSS-X. While the Desktop redraws quickly, the filemanager takes a lot of time (even if I got new routines by Peter last year).

Edited October 21, 2011 by atarixle

[flashjazzcat]

stupidly, a full-screen-redraw is exactly what I'm still doing in BOSS-X. While the Desktop redraws quickly, the filemanager takes a lot of time (even if I got new routines by Peter last year).

Nothing stupid about it - these things are hard to manage. It's not such an issue if you don't have overlapping windows, though. The issue is the regeneration of obscured screen data. If you just have one "layer", you can optimize the hell out of the refresh routine, only redrawing those parts which have changed. When scrolling, for example, it would be much quicker to "blit" regions of the screen rather than re-render the text from scratch.

 

At least - using the masking technique - it's only necessary to redraw those objects whose location falls inside the exposed region vacated by a moved or resized window. Since the exposed region isn't likely to be a single rectangle, however, we might as well clip the refresh to the top window's previous location, and the masking will take care of the rest.

[atarixle]

ok, the term "stupidly" sounds a lil less "stupid" in german ...

 

I was thinking about handling multiple layers in the RD ...

[flashjazzcat]

I was thinking about handling multiple layers in the RD ...

 

RAMdisk? Yes - well if you can find a place to store a complete image of each window, that will work well, and might even be faster. I'm a bit constrained in that respect, since I want this to run on a 130XE, and 2-3 banks are already spoken for (all four if you're using SDX, which will need one for itself). Ideally, you'd want to save an image of the desktop, and then a bitmap of each open window in its most recently updated state. It should then be a cynch to overlay them in a hurry. If you have a 64KB RAMdisk without much on it, you're laughing.

 

I'm really keen on the masking, though, since it allows simple jobs like selecting and moving desktop icons or changing the wallpaper to be performed without redrawing or blitting any of the open windows. As UnixCoffee says, we can reward Ultimate 1MB owners and the like by using the faster layered buffers. Nevertheless, drawing a partially obscured desktop icon and its label through a bitmask is going to be quicker than drawing the icon to a back buffer, blitting all the window bitmaps over the top of it, then blitting the composite image to the main display buffer. I haven't forgotten the overhead of building the composite mask in the first place, of course, but that just needs to be done once every time a window changes position.

Edited October 21, 2011 by flashjazzcat

[UNIXcoffee928]

Now, here's today's tip, to keep you from thinking about actually seeing any sunlight again, soon, ha... (mu-ha-ha)...

 

Bitmaps & Bitmasks are very ideal candidates for compression.

 

If you apply a fast & simple compression scheme to your collections of 1s & 0s, and set this compression algorithm up to execute on a custom chip (not the 6502) you will achieve parallelism and dramatically decrease the RAM necessary to do all of this bit-twiddling. You may need to think creatively on how to use a custom chip to do this, but it has to be possible. There should be no performance hit on the GUI, in fact, it may turn out that it reacts substantially faster.

 

This little scheme will likely let you accomplish what was previously thought to be impossible.

[flashjazzcat]

Yep - check out the MacTech articles on region compression. I studied them in great depth when I was designing the masking scheme. QuickDraw used ingenious right / down shifted XOR images to make efficiently compressed masks (actually pen up/down switches) describing complex shapes. Since most of the masks have lots of repetition, it's relatively easy to collapse them line by line. The 6502 might even manage a kind of RLE mask encoding, by simply collapsing repeated lines of identical data. These could also be fairly efficiently used by the drawing routines. However, compressing it is one thing, but drawing the mask pre-compressed is another thing entirely, since we build the mask by very rapidly overlaying silhouttes of the open windows in their current locations (although the masking has many, many other diverse and potentially wonderful applications). I have a buffer set aside, and I only need the one at the moment, so storage isn't currently critical.

 

VBXE's FPGA is perhaps capable of compression (perhaps not?), but if we have a VBXE, we have (effectively) unlimited buffer space anyway.

 

Hopefully when I get a demo of this stuff put together, the impossible will already have been achieved (without a custom chip).

Edited October 21, 2011 by flashjazzcat

[Gunstar]

Below is text I copied and pasted from another thread becuase I wanted to continue the discussion, but flashjazzcat was right in that it should be continued in the correct thread. Old text it below the dashed line.

 

Anyway, flashjazzcat, you point out that most GUI's or "desktops" lack killer apps that make them a tru GUI system. You mentioned Diamond GOS as the first real GUI, but had lots of bugs. I know, I owned the Diamond cartridge, IIRC it was version 2.x and I later got the upgrade chip from Alan Reeve for 3.x and all the upgraded software. I wanted to love Diamond, and stuck with it through two upgrades, but in the end the apps were all too buggy and slow and I only ever used it as a desktop anyway.

 

I would love to have your full-featured GUI, with Last Word in GUI form, and a good database and spreadsheet programs like the Syn series, and a multi-resolution graphic art program that utilizes all the Atari's graphic modes, DLI's, and even APAC and possibly other software driven modes. I'd like to see a GUI version of Atari Contiki so I can surf the web.

 

But even if all of this happens, the vast majority of Atari software is "legacy" software designed to be self-booting or run with DOS. So no matter what, the GUI needs to be transparent with basically everything legacy.

 

It needs to be fast, slow GUI's are a pain when the whole point is supposed to be ease of use and a pleasurable, user friendly graphic environment. It needs desktop wallpaper and any program can be excuted from the desktop icon, window icon and disk directories. The ability to display all types of Atari graphic pictures. Use of looping graphic demos for screen-savers.

 

ATOS can do much of this stuff, through either it's windows (with installed programs) or disk directory. ATOS sort of reminds me of Amiga's Workbench in how it operates, which is different from all othe Atari 8-bit GUI's I've encounterd, and it seems to work well for the A8, like workbench does for the Amiga.

 

Heck, I going to install your Last Word 3.2 into ATOS with it's own icon and now I can load LW through my ATOS window environment! Though I'll have to see and test extensively, to see if there are any memory conflicts at all. I haven't tried using programs that use more than 64K of memory with ATOS yet, except demos as screen-savers, like Atari shiny bubbles (128k).

 

 

 

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

It is true, as usual, that it does suffer from lack of GUI apps. It has a lot of it's own support programs, but they are mainly for customizing the desktop/windows system. But as you pointed out, they pretty much all suffer from this, so I figure, why not go with the best, most comprehensive GUI that works well with virtually anything. IIRC, it also has a psuedo-multitasking abilities too, though it's been a while since I've really used it.

 

Of course I merely ask the question because I have a vested interest in what people want out of a GUI on the 8-bit Atari. One of the most popular features is probably the ability to launch all exisiting software via mouse clicks. For this reason, I tend to categorize most existing GUIs on the Atari as "Desktops", since they are (for the most part) not GUI infrastructures (as in "frameworks" for applications), but program launchers with extra features. Diamond GOS is one notable exception... but - once again - it lacks apps.

 

 

Quote

 

I don't recall TRS, I'll look into it, I tried a version of BOSS once, but never looked into it much at the time. ATOS is much more intuitive and user friendly "right out of the box" with loads of features. But, as I said, you have to have superior memory and speed to use it, the faster the better. It even has a voice synthesis text reader! 100's of wallpapers, loads of demos for screen savers, it goes on and on with what is included (hence the 16MB ATR).

 

No doubt about it - it's fast, and the bundled wallpapers and extra functionality are cool. However, the windows and their contents are static and the bits you'd expect to work fast (like the config program drawing its text screen) are slow. But it's all good, since we can learn from it.

 

 

Quote

 

I'm looking forward to trying out your GUI, flashjazzcat, and hope it has the support apps. But really, how many people even use 8-bits as their "App" machines anymore? I'm not knocking it, I AM one who still uses 8-bit wordprocessors and graphic arts and spreadsheets, but I assume I'm one of maybe half a dozen people who DON'T turn to their PC for all but fun and games with the 8-bits.

 

The "killer app" is the essential ingredient that they all lack, IMO. Our GUI will get a word processor soon after its release, and the desktop ile manager will be "the business", but you make a very valid point about how many people actually use the Atari as a productivity tool. I think the number is greater than half a dozen (otherwise SDX, LW, etc would be dead in the water), but it's interesting to consider. The GUI topic has a huge number of views, but are these views all from potential users, or from the same small core group of followers, or just casual spectators? Time will tell.

 

 

Quote

 

ATOS web site has been down for quite a while now (Closer to Home), but the image can be found at other sites. I'm not sure if documentation is still available for it or not, online; I have a booklet I printed out ages ago. So it's another orphaned GUI.

 

That's probably the greatest problem - the fact it's not being supported any more. Nevertheless - it's a really interesting product.

 

OK - any more comments on ATOS, etc, I'll confine to one of the ATOS threads, or the GUI topic itself.

Edited October 27, 2011 by Gunstar

[flashjazzcat]

Below is text I copied and pasted from another thread becuase I wanted to continue the discussion, but flashjazzcat was right in that it should be continued in the correct thread.

 

Thanks. This is a long thread, so perhaps by dealing with some of the points I can clarify where we're heading with this, and why I think there's a point to it all.

 

Anyway, flashjazzcat, you point out that most GUI's or "desktops" lack killer apps that make them a tru GUI system. You mentioned Diamond GOS as the first real GUI, but had lots of bugs. I know, I owned the Diamond cartridge, IIRC it was version 2.x and I later got the upgrade chip from Alan Reeve for 3.x and all the upgraded software. I wanted to love Diamond, and stuck with it through two upgrades, but in the end the apps were all too buggy and slow and I only ever used it as a desktop anyway.

 

I would love to have your full-featured GUI, with Last Word in GUI form, and a good database and spreadsheet programs like the Syn series, and a multi-resolution graphic art program that utilizes all the Atari's graphic modes, DLI's, and even APAC and possibly other software driven modes. I'd like to see a GUI version of Atari Contiki so I can surf the web.

 

I'll deal with what seems to me to be the difference between desktops and GUIs first. To me, a GUI should provide a resident interface infrastructure and library in much the same way as DOS provides a resident FMS infrastructure. With DOS, to perform filing operations, one delegates a great deal of functionality from one's application by simply setting up a control block and calling a library routine (in the case of BASIC, via an "open" or "XIO" command). DOS itself can be as complex as it needs to be - indeed a simple XIO call can cause swathes of banked code to be brought into play, depending upon the complexity of the task at hand. In all cases, however, the operation is performed within the strictures of the FMS design, and the application programmer has a very clear idea of what error codes might be returned, etc. The reason we have DOS is so that we don't have to include FMS routines in every program we write.

 

Now, the way I see it, only Diamond GOS attempted to do the same thing with the GUI on the A8. Ostensibly, all interface operations were performed via system calls. An application provided the dialogue handler with an object tree/list, the dialogue handler got the user's input, and returned the information to the application. If a user resized a window, the application got a window resize event. Now, the implementation was by no means complete (the text entry routine, for example, completely blocked everything until Return was pressed), nor did it even attempt a slavish but scaled down version of, say, GEM's API. But it was a valiant stab, nevertheless, and if you look at Diamond application source code... well, it's at least well on the way to looking like it was built from a proper GUI skeleton template.

 

Tempting though it was to code up Diamond apps, the API was limiting and the implementation was pretty slow. So - the number one objective of the new GUI is to have the most complete possible API. Radio buttons, check boxes, input boxes, drop lists, etc, and the dialogue handler should allow the user to click the "cancel" button while the I beam is flashing in a text box, swipe the mouse across text to copy it to the clipboard, etc, etc. This should all be part of the dialogue handler. It should be very complete, and it should be as efficient as possible.

 

So - if it's efficient and offers a rich set of controls, the idea is that programmers aren't hampered by its limitations and are thereby encouraged to see the system as a usable platform with which they can create rich interfaces. The reason I never had a go at writing a Diamond program is that I was convinced that no matter how hard I tried, the GUI itself would ensure the application ran as slow as hell.

 

The alternative, of course, to a resident GUI library is a stand-alone application which creates a "desktop" interface on the machine. I see many examples of this, or variations on the theme. They do the valuable job of allowing files to be lanched or managed using an attractive desktop interface, and perhaps they run legacy applications pretty transparently. However, without a resident GUI library, or some kind of overlays or DLLs which applications can load at run time, every attendant application needs to effectively reimplement the desktop manager's interface itself. More often than not, clicking on "control panel" or "file copier" runs some text mode program perhaps written years before the desktop system was developed. There's therefore no uniformity in the interface, even across applications intended to be integrated parts of the desktop manager. To a varying extent, such systems are file launchers which work using a "desktop" metaphor, and the API rarely supports overlapping windows, scrollbars, or other rich controls which can be accessed by simple system calls.

 

So, although the line is often blurred in practice, I'm highlighting a difference here between "desktops" and GUIs. Diamond GOS is a GUI for the Atari 8-bit. ATOS - as far as I can tell - is a desktop.

 

To use a convenient example, the Atari ST has two main libraries: VDI and AES. VDI is concerned with drawing operations (lines, text, etc), while the AES manages windows and dialogues and responds to system events. GEM apps generally include a combination of calls to AES and VDI. What we are trying to do here - building on what was achieved with Diamond GOS - is create AES for the A8 (although the GUI will have its own "VDI" library of sorts as well). The rest is down to what talented programmers make of it.

 

But even if all of this happens, the vast majority of Atari software is "legacy" software designed to be self-booting or run with DOS. So no matter what, the GUI needs to be transparent with basically everything legacy.

 

Absolutely - and this is what ATOS appears to do extremely well. This is an advantage of the stand-alone desktop. As long as it ties into the DOS entry point somehow and keeps itself out of the way at other times, most legacy programs should work with it. Because of the lack of uniformity with regard to extended memory management, etc, on the A8, it's quite a big job to ensure clashes don't occur. ATOS appears tightly tied-in with one particular DOS, which will help greatly.

 

It needs to be fast, slow GUI's are a pain when the whole point is supposed to be ease of use and a pleasurable...

 

It needs to be fast, of course. But at the same time we can't expect miraculous performance on a 1.7MHz machine. The reason many "desktops" are efficient is because they frankly aren't doing that much graphically. Drawing a white box on a desktop background and filling it with fixed-pitch text can be done very quickly without too much trouble. On the other hand, an overlapping window manager with clipped, scrolling content is something else entirely. There's basically a performance "cliff" (I believe) over which we must not fall. If anyone rearranges four windows in the GUI running on a 128KB machine and complains that there's a short pause while things redraw themselves (either using a composite window manager or back-buffered model), they ought to stick with desktops, application launchers, or other stuff which runs quick on a small processor.

 

...user friendly graphic environment.

This is what all your applications should have when running on top of a rich GUI.

 

It needs desktop wallpaper and any program can be excuted from the desktop icon, window icon and disk directories.

 

It doesn't need desktop wallpaper, although people might perhaps think it's a cool feature. It's totally unnecessary. Nevertheless, the new GUI will allow it if you have the RAM.

 

As for the rest - absolute essentials.

 

The ability to display all types of Atari graphic pictures.

 

Well - hopefully someone will write an amazing viewer if I don't get around to it. A lot depends on how programmers in the community take to it.

 

Use of looping graphic demos for screen-savers.

Again - although cleverly implemented by ATOS, this is hardly an essential requirement of a GUI. It's something ATOS does, and - along with the enormous mass of wallpapers supplied - it takes attention away from the fairly limited scope of the desktop manager, to be frank.

 

ATOS can do much of this stuff, through either it's windows (with installed programs) or disk directory. ATOS sort of reminds me of Amiga's Workbench in how it operates, which is different from all othe Atari 8-bit GUI's I've encounterd, and it seems to work well for the A8, like workbench does for the Amiga.

 

I don't want to take anything away from ATOS because it's pretty fast, does what it set out to do, and - above all - it's finished. However, its "windows" are immovable static panes with fixed content (hence the "empty" folder entries), and the disk directories span in columns across the entire screen. Yes - it's totally different from anything else on the A8. It's not a window manager and has no dialogue manager, but it does what it does pretty well - which is to present applications and disk structures using the desktop metaphor.

 

Heck, I going to install your Last Word 3.2 into ATOS with it's own icon and now I can load LW through my ATOS window environment! Though I'll have to see and test extensively, to see if there are any memory conflicts at all. I haven't tried using programs that use more than 64K of memory with ATOS yet, except demos as screen-savers, like Atari shiny bubbles (128k).

This would be interesting, although LW will not work with disk-based SpartaDOS owing to its use of the Shadow RAM. Can ATOS be used with SpartaDOS X? Perhaps that would work. I'd be impressed if ATOS managed to keep out of the way of LW's banked text buffers!

Edited October 27, 2011 by flashjazzcat

[+orpheuswaking]

GOOEY!!!

[Gunstar]

Below is text I copied and pasted from another thread becuase I wanted to continue the discussion, but flashjazzcat was right in that it should be continued in the correct thread.

 

Thanks. This is a long thread, so perhaps by dealing with some of the points I can clarify where we're heading with this, and why I think there's a point to it all.

 

Anyway, flashjazzcat, you point out that most GUI's or "desktops" lack killer apps that make them a tru GUI system. You mentioned Diamond GOS as the first real GUI, but had lots of bugs. I know, I owned the Diamond cartridge, IIRC it was version 2.x and I later got the upgrade chip from Alan Reeve for 3.x and all the upgraded software. I wanted to love Diamond, and stuck with it through two upgrades, but in the end the apps were all too buggy and slow and I only ever used it as a desktop anyway.

 

I would love to have your full-featured GUI, with Last Word in GUI form, and a good database and spreadsheet programs like the Syn series, and a multi-resolution graphic art program that utilizes all the Atari's graphic modes, DLI's, and even APAC and possibly other software driven modes. I'd like to see a GUI version of Atari Contiki so I can surf the web.

 

I'll deal with what seems to me to be the difference between desktops and GUIs first. To me, a GUI should provide a resident interface infrastructure and library in much the same way as DOS provides a resident FMS infrastructure. With DOS, to perform filing operations, one delegates a great deal of functionality from one's application by simply setting up a control block and calling a library routine (in the case of BASIC, via an "open" or "XIO" command). DOS itself can be as complex as it needs to be - indeed a simple XIO call can cause swathes of banked code to be brought into play, depending upon the complexity of the task at hand. In all cases, however, the operation is performed within the strictures of the FMS design, and the application programmer has a very clear idea of what error codes might be returned, etc. The reason we have DOS is so that we don't have to include FMS routines in every program we write.

 

Now, the way I see it, only Diamond GOS attempted to do the same thing with the GUI on the A8. Ostensibly, all interface operations were performed via system calls. An application provided the dialogue handler with an object tree/list, the dialogue handler got the user's input, and returned the information to the application. If a user resized a window, the application got a window resize event. Now, the implementation was by no means complete (the text entry routine, for example, completely blocked everything until Return was pressed), nor did it even attempt a slavish but scaled down version of, say, GEM's API. But it was a valiant stab, nevertheless, and if you look at Diamond application source code... well, it's at least well on the way to looking like it was built from a proper GUI skeleton template.

 

Tempting though it was to code up Diamond apps, the API was limiting and the implementation was pretty slow. So - the number one objective of the new GUI is to have the most complete possible API. Radio buttons, check boxes, input boxes, drop lists, etc, and the dialogue handler should allow the user to click the "cancel" button while the I beam is flashing in a text box, swipe the mouse across text to copy it to the clipboard, etc, etc. This should all be part of the dialogue handler. It should be very complete, and it should be as efficient as possible.

 

So - if it's efficient and offers a rich set of controls, the idea is that programmers aren't hampered by its limitations and are thereby encouraged to see the system as a usable platform with which they can create rich interfaces. The reason I never had a go at writing a Diamond program is that I was convinced that no matter how hard I tried, the GUI itself would ensure the application ran as slow as hell.

 

The alternative, of course, to a resident GUI library is a stand-alone application which creates a "desktop" interface on the machine. I see many examples of this, or variations on the theme. They do the valuable job of allowing files to be lanched or managed using an attractive desktop interface, and perhaps they run legacy applications pretty transparently. However, without a resident GUI library, or some kind of overlays or DLLs which applications can load at run time, every attendant application needs to effectively reimplement the desktop manager's interface itself. More often than not, clicking on "control panel" or "file copier" runs some text mode program perhaps written years before the desktop system was developed. There's therefore no uniformity in the interface, even across applications intended to be integrated parts of the desktop manager. To a varying extent, such systems are file launchers which work using a "desktop" metaphor, and the API rarely supports overlapping windows, scrollbars, or other rich controls which can be accessed by simple system calls.

 

So, although the line is often blurred in practice, I'm highlighting a difference here between "desktops" and GUIs. Diamond GOS is a GUI for the Atari 8-bit. ATOS - as far as I can tell - is a desktop.

 

To use a convenient example, the Atari ST has two main libraries: VDI and AES. VDI is concerned with drawing operations (lines, text, etc), while the AES manages windows and dialogues and responds to system events. GEM apps generally include a combination of calls to AES and VDI. What we are trying to do here - building on what was achieved with Diamond GOS - is create AES for the A8 (although the GUI will have its own "VDI" library of sorts as well). The rest is down to what talented programmers make of it.

 

But even if all of this happens, the vast majority of Atari software is "legacy" software designed to be self-booting or run with DOS. So no matter what, the GUI needs to be transparent with basically everything legacy.

 

Absolutely - and this is what ATOS appears to do extremely well. This is an advantage of the stand-alone desktop. As long as it ties into the DOS entry point somehow and keeps itself out of the way at other times, most legacy programs should work with it. Because of the lack of uniformity with regard to extended memory management, etc, on the A8, it's quite a big job to ensure clashes don't occur. ATOS appears tightly tied-in with one particular DOS, which will help greatly.

 

It needs to be fast, slow GUI's are a pain when the whole point is supposed to be ease of use and a pleasurable...

 

It needs to be fast, of course. But at the same time we can't expect miraculous performance on a 1.7MHz machine. The reason many "desktops" are efficient is because they frankly aren't doing that much graphically. Drawing a white box on a desktop background and filling it with fixed-pitch text can be done very quickly without too much trouble. On the other hand, an overlapping window manager with clipped, scrolling content is something else entirely. There's basically a performance "cliff" (I believe) over which we must not fall. If anyone rearranges four windows in the GUI running on a 128KB machine and complains that there's a short pause while things redraw themselves (either using a composite window manager or back-buffered model), they ought to stick with desktops, application launchers, or other stuff which runs quick on a small processor.

 

...user friendly graphic environment.

This is what all your applications should have when running on top of a rich GUI.

 

It needs desktop wallpaper and any program can be excuted from the desktop icon, window icon and disk directories.

 

It doesn't need desktop wallpaper, although people might perhaps think it's a cool feature. It's totally unnecessary. Nevertheless, the new GUI will allow it if you have the RAM.

 

As for the rest - absolute essentials.

 

The ability to display all types of Atari graphic pictures.

 

Well - hopefully someone will write an amazing viewer if I don't get around to it. A lot depends on how programmers in the community take to it.

 

Use of looping graphic demos for screen-savers.

Again - although cleverly implemented by ATOS, this is hardly an essential requirement of a GUI. It's something ATOS does, and - along with the enormous mass of wallpapers supplied - it takes attention away from the fairly limited scope of the desktop manager, to be frank.

 

ATOS can do much of this stuff, through either it's windows (with installed programs) or disk directory. ATOS sort of reminds me of Amiga's Workbench in how it operates, which is different from all othe Atari 8-bit GUI's I've encounterd, and it seems to work well for the A8, like workbench does for the Amiga.

 

I don't want to take anything away from ATOS because it's pretty fast, does what it set out to do, and - above all - it's finished. However, its "windows" are immovable static panes with fixed content (hence the "empty" folder entries), and the disk directories span in columns across the entire screen. Yes - it's totally different from anything else on the A8. It's not a window manager and has no dialogue manager, but it does what it does pretty well - which is to present applications and disk structures using the desktop metaphor.

 

Heck, I going to install your Last Word 3.2 into ATOS with it's own icon and now I can load LW through my ATOS window environment! Though I'll have to see and test extensively, to see if there are any memory conflicts at all. I haven't tried using programs that use more than 64K of memory with ATOS yet, except demos as screen-savers, like Atari shiny bubbles (128k).

This would be interesting, although LW will not work with disk-based SpartaDOS owing to its use of the Shadow RAM. Can ATOS be used with SpartaDOS X? Perhaps that would work. I'd be impressed if ATOS managed to keep out of the way of LW's banked text buffers!

 

I understand all what you have said, and I like ATOS, now, for what it is, I really hope to love your GUI much more. But to me, you seemed to skirt my main concern with a GUI vs. Desktop on the A8, and that is, in this day and age, no matter how great your GUI is, I believe the apps eventually created for it will be rare, and even if dozens are made, 99+% of A8 programs are legacy and if the GUI is to be successful in my opinion, it must be able to run both legacy and new GUI apps as transparently as possible.

 

Becuase to me, a GUI should be structured around the entire OS/DOS system (so that any program can be run and return to the desktop, and GUI apps run with the desktop. You can't just completely replace the current OS/DOS system unless it's completely compatible.

 

With Macs, PC's, ST's etc., they wee introduced with the GUI so the vast majority of programs were naturally made with it, but even then the ST still has TOS for non GEM apps.

But older systems that weren't "born" with a GUI must be compatible with legacy programs or else it isn't and never will be the main operating environment; you will have to ignore the fact that you have a GUI most of the time and use the traditional OS/DOS, except when you want to use the few apps there are for it.

 

If you were doing all this in the Atari's heyday, you could possibly have many development companies to make apps for it, but today...just some hobbyists, and anyway, how many apps did the C64's GEOS ever have devloped for it? A dozen maybe? How transparent is GEOS with C64 legacy programs? Do C64 users always lauch from GEOS and the desktop, or is it just limited to running it's own few apps and ignored when running anything else?

 

As you've clearly stated over and over, it's about support apps...I agree...but from experience I MUST look at it from the half-empty point of view while you look at it as half-full. I see any GUI's coming out eventually having only half a dozen to a dozen apps for it and not be a major influence in how we use the A8. Of course you do have the advantage of VBXE compatibility, and that exciting new hardware may instill ambition in the community to create lots of new games and apps...maybe, depends on how many people will actually ever upgrade to VBXE and how many apps for the GUI will have Standard A8 versions for the rest of us.

Edited October 27, 2011 by Gunstar

[UNIXcoffee928]

http://www.youtube.com/watch?v=IJ_R-G_i4Xk

[potatohead]

Well, the only A8 apps I would even consider using, that are relevant to a GUI, would be last word and perhaps a simple graphics program, calc, text pad, etc... Anything beyond that really can just be ran as it is.

 

I've been doing some stuff with my Apple, and there are GUI type programs on it. The most cohesive is Apple Works, with some nice other apps that require a boot to use. It's a stretch to use the machine anyway. What I did get done was actually quite productive. Where the GUI was integrated with the application, it all made good sense. Where it wasn't, it's just some layer one works through to get to what does. Not a lot of value there for me anyway.

 

Out of all that, I got some graphics I wanted to author, and some text, which was just fun. Both moved over to the PC, and life was good. If all that were possible is graphics and authoring a document here, it would be pretty damn great, IMHO. Beyond that depends on what people would want to author. Honestly, that's a challenge anyway. What actually makes any sense? IMHO, adventure game, clock, graphics painter type program... I suppose somebody could go balls out and actually make some IDE. Wouldn't that be a hoot?

 

Oh, and I won't do a VBXE. It's cool and all, don't get me wrong. It's just not really Atari 8 bit anymore.

Edited October 28, 2011 by potatohead

[Gunstar]

http://www.youtube.com/watch?v=IJ_R-G_i4Xk

 

Please don't get me wrong, I really want this new GUI and want it to succeed, but from experiencing several GUI's or desktops on the Atari, it has made no difference if it's a proper GUI or just a "desktop" becuase of lack of support with good GUI apps, so even GUI's just get used as "desktops." So from the perspective of "it will only ever get used AS a desktop" I figure it should at least operate with legacy apps and games transparently, and have lots of desktop bells and whistles, like screen savers and wallpapers, etc.

[flashjazzcat]

...you seemed to skirt my main concern with a GUI vs. Desktop on the A8, and that is, in this day and age, no matter how great your GUI is, I believe the apps eventually created for it will be rare, and even if dozens are made, 99+% of A8 programs are legacy and if the GUI is to be successful in my opinion, it must be able to run both legacy and new GUI apps as transparently as possible.

Sorry - I didn't mean to sidestep the main concern - I simply had some stuff to get off my chest. There's certainly little point in creating something which doesn't run legacy apps well (it's an "essential" in this project), and it's perhaps prudent to look at Windows 3.1 when it first came out: it sat on top of DOS (like our GUI does), and had excellent integration with both the underlying OS and older DOS apps - the reason being that there were few native Windows applications at the time. Of course, the UI was rich and pretty enough to encourage developers to start writing software for it. Contrast this with something like the Mac, which - when it was first released - had a bare handful of applications written for it and absolutely no legacy software whatsoever. The new A8 GUI is clearly in the Windows mould (circumstantially if nothing else), and the plan is to make it useful as a file manager, front end, and application environment. It will not replace the OS, be tied to a specific DOS, or require special hardware other than 128KB of RAM and a flash cart. You're correct to identify both the limited user base and the dearth of GUI applications: the best we can hope to do is make the system as useful as possible across the board, and a truly viable platform for developers. Admittedly, though, a certain part of this is just to see if it can be done.

 

Becuase to me, a GUI should be structured around the entire OS/DOS system (so that any program can be run and return to the desktop, and GUI apps run with the desktop. You can't just completely replace the current OS/DOS system unless it's completely compatible.

Quite so. The GUI would be much better if it replaced DOS completely and had its own FMS, but it then becomes cast in the Classic Mac OS mould and is thus useless without plenty of specially written applications.

 

With Macs, PC's, ST's etc., they wee introduced with the GUI so the vast majority of programs were naturally made with it, but even then the ST still has TOS for non GEM apps.

As I mentioned before, though, the PC had a very large back-catalogue of DOS software, and one of Windows' killer features was that it would run DOS software well.

 

But older systems that weren't "born" with a GUI must be compatible with legacy programs or else it isn't and never will be the main operating environment; you will have to ignore the fact that you have a GUI most of the time and use the traditional OS/DOS, except when you want to use the few apps there are for it.

It should now be clear that I understand the importance of the legacy software issue.

 

If you were doing all this in the Atari's heyday, you could possibly have many development companies to make apps for it, but today...just some hobbyists, and anyway, how many apps did the C64's GEOS ever have devloped for it? A dozen maybe? How transparent is GEOS with C64 legacy programs? Do C64 users always lauch from GEOS and the desktop, or is it just limited to running it's own few apps and ignored when running anything else?

I think GEOS runs GEOS apps and nothing else, but then there are tons of GEOS apps. I don't think Berkley Softworks wrote all of the applications; GEOS was attractive and viable enough at the time to encourage third-party developers and hobbyist authors alike to write software for it. For all its limitations, GEOS is quality through and through and a great piece of programming. I'm under no illusions that we could enjoy the same level of developer support for an 8-bit GUI written today, however.

 

As you've clearly stated over and over, it's about support apps...I agree...but from experience I MUST look at it from the half-empty point of view while you look at it as half-full. I see any GUI's coming out eventually having only half a dozen to a dozen apps for it and not be a major influence in how we use the A8.

Indeed. I hardly think we'll be binning all of our legacy apps any time soon. I enjoy running text based programs on the A8, each with their own proprietary interface. How many native GUI programs we end up with depends on many things, among them my productivity, and the quality of the API and how inspiring it is to developers. The API has been the most important thing to me right from the start. If it's fun to write programs for, and said programs are useful, then why not? In any case - there'll be plenty of applications for it in the long term, since I'll be coding for it for the next 20 or 30 years, God willing.

 

Of course you do have the advantage of VBXE compatibility, and that exciting new hardware may instill ambition in the community to create lots of new games and apps...maybe, depends on how many people will actually ever upgrade to VBXE and how many apps for the GUI will have Standard A8 versions for the rest of us.

The GUI is compatible with VBXE at the moment only in the sense that it works with it just the same as it works on a stock machine. We're a long way from having specific support for the VBXE FX core. I can see the numerous advantages of using VBXE, but 640px horizontal resolution, blitting capability, and almost unlimited buffer space relieve me of most of the challanges that make the project so compelling in the first place (specifically: how to make it run fast enough; how to represent sufficient information on a 320x200 screen, and how to fit it into 128KB of RAM).

 

Well, the only A8 apps I would even consider using, that are relevant to a GUI, would be last word and perhaps a simple graphics program, calc, text pad, etc... Anything beyond that really can just be ran as it is.

 

I've been doing some stuff with my Apple, and there are GUI type programs on it. The most cohesive is Apple Works, with some nice other apps that require a boot to use. It's a stretch to use the machine anyway. What I did get done was actually quite productive. Where the GUI was integrated with the application, it all made good sense. Where it wasn't, it's just some layer one works through to get to what does. Not a lot of value there for me anyway.

 

Out of all that, I got some graphics I wanted to author, and some text, which was just fun. Both moved over to the PC, and life was good. If all that were possible is graphics and authoring a document here, it would be pretty damn great, IMHO. Beyond that depends on what people would want to author. Honestly, that's a challenge anyway. What actually makes any sense? IMHO, adventure game, clock, graphics painter type program... I suppose somebody could go balls out and actually make some IDE. Wouldn't that be a hoot?

Funny you should mention an IDE, since I was just musing over how nice it would be to have a version of BASIC specially designed for the GUI, with special keywords, callbacks, etc.

 

With regard to "what will it be used for", word processing, text editing, and drawing are obvious applications. In addition, I think (with ironic reference to my earlier comments on "desktops") that a really good desktop file manager might be the most frequently used component of all. It needs to be attractive, integrated, and capable. There aren't many exisiting "desktops" on the A8 that I'd like to look at every time I switch on the machine, but that's just my personal aesthetic. I can see myself looking at nicely proportioned drop-shadow windows, smart drop-down menus, and MrFish's lovely icons and proportional fonts every day, however.

 

One of the first applications I want to code up is an APT partition editor for SIDE. This will be a great demonstration of the API, using scrolling windows, tabular information, dialogues, menus and the file selector.

 

Oh, and I won't do a VBXE. It's cool and all, don't get me wrong. It's just not really Atari 8 bit anymore.

Note my comments above.

 

Please don't get me wrong, I really want this new GUI and want it to succeed, but from experiencing several GUI's or desktops on the Atari, it has made no difference if it's a proper GUI or just a "desktop" becuase of lack of support with good GUI apps, so even GUI's just get used as "desktops." So from the perspective of "it will only ever get used AS a desktop" I figure it should at least operate with legacy apps and games transparently, and have lots of desktop bells and whistles, like screen savers and wallpapers, etc.

I just don't think there are several GUIs of this scope on the Atari - only Diamond set out to do something similar (and perhaps SAM Desktop to a lesser extent, although that had better apps), and it's too slow and doesn't even get used as a desktop by many people (I would venture). That's why I'm having another crack at it. The "desktops", meanwhile, are either highly idiosyncratic or tied to a specific DOS - or both. It really depends what you're after. They're like marmite.

 

As for the bells and whistles - all nice and fun to use, as I've said, but they shouldn't (and won't) come before the core functionality of the API. I see no point in having a flashy screensaver if you have to go into a graphics mode 0 program to set it up.

Edited October 28, 2011 by flashjazzcat