New GUI for the Atari 8-bit

[Curt Vendel]

Its on my radar, once the XM is done and out of the way and at the end of spring once all of the major foot work is done on the Atari History book Marty and I are working on is out of the way, I want to look at bringing the 1090XL out and also get back to doing the 1200XL pizza box top with PS/2 to 8bit keyboard interface I built a while ago.

 

Just too much on my plate and I need to finish and deliver other long promised stuff first.

 

 

Curt

 

If you want a path for the ATARI to have serious "plug in" expansion possibilities in the future (in the same sense that the Apple II and PC did) then I think a universally accepted upgrade to the PBI standard is in order..

Has the schematics for the 1090XL ever surfaced, or has anyone reverse engineered it? I think it would be kind of neat to make replica 1090XL expansions, and build new peripherals that meet that 'standard'.

Yes, Curt has them click this link to the old thread I don't know if he finished.

[w1k]

when we can try it?

[flashjazzcat]

when we can try it?

 

When I've finished the current chunk of coding. I've spent the morning looking for a job so far, unfortunately. The bank is sending us more hate-mail...

[flashjazzcat]

Some major progress over the weekend. Anyone familar with the "Classic" Macintosh OS will know about "regions". This is a patented technology which employed absolutely ingenious compression techniques to store and manipulate what are effectively large bitmasks, although it's actually a little more complex than that. There's an interesting description here.

 

Now, our little 8-bit CPU isn't fast enough to handle a slavish implementation of Mac Regions (not that I'd want to, since a) it's patented, and b) I'd rather invent some new way of handling masking). However, those MacTech articles (and I'd recommend them to anyone interested in GUI development) set me thinking about how we could implement full-screen masking without the big speed and storage penalties this might involve.

 

What I've come up with is a hybrid approach which simply uses RLE encoding of window silhouettes (or any other fairly repetitive rectangular objects). Using a 200-entry array of pointers (one entry for each raster line on the screen), we can quickly create, combine and manipulate 40-byte masks running the entire height of the desktop. When building, say, the silhouette of a window (which has three distinct masks, because of the drop-shadow), we just just create new mask entries and set the pointers to refer to them repetitively. Overlaying masks is easy and quick, since once we've started a new mask pattern, we just have to test the pointers to see the underlying RLE pattern has changed, and when it does, we make a new intersected mask, and do the same thing all over again.

 

This is a very rare instance when using compression is faster than not doing so. Creating and manipulating an uncompressed 8KB bitmask requires much, much processing than the compressed version, which is - even when there are many overlapping window silhouettes in the mask - in the order of ten per cent the size of the equivalent uncompressed mask. In addition, masks can be created to order very rapidly indeed - quickly enough, in fact, that we can dynamically generate complex full-screen bitmasks while rendering GUI elements.

 

In the future, the potential exists to use full-screen masking in lots of interesting ways. For now, however, I finally got the basics working:

 

 

This is a bitmask for three overlapping windows, generated in very short order and consuming only 440 bytes (eleven different masks, each of 40 bytes; entirely opaque or transparent masks are stored elsewhere and not dynamically generated).

 

We can draw anything we like through these masks, since all the object rendering operations are filtered through them.

Edited January 23, 2012 by flashjazzcat

[UNIXcoffee928]

Ah, OK, now we're at the point that the stuff that we were discussing on page 46 of this thread is more relevant.

 

You are doing an excellent job, thanks for all of your hard work!

[flashjazzcat]

Here's a short demo of the new window manager which I JUST got working a moment ago. It's very buggy but it shows the repainting of "regions", which is something I've been waiting to see for several months since I dreamed up the algorithms:

 

 

I need to optimise and debug this, then stick some static content in those windows and let folks have a play with it.

[Gunstar]

Looking fantastic!

[popmilo]

Here's a short demo of the new window manager which I JUST got working a moment ago. It's very buggy but it shows the repainting of "regions", which is something I've been waiting to see for several months since I dreamed up the algorithms:

Looking good!

 

So, you are using compressed mask data to draw only parts of screen that change ?

What is the order of draw operations that you have there ?

Is it something like:

1. draw moved window on new position.

2. Make mask transparent on part of screen that is the difference of old window position and new position.

3. Draw all screen stuff using mask data.

 

Not sure if what I wrote makes any sense

[flashjazzcat]

Looking good!

 

So, you are using compressed mask data to draw only parts of screen that change ?

What is the order of draw operations that you have there ?

Is it something like:

1. draw moved window on new position.

2. Make mask transparent on part of screen that is the difference of old window position and new position.

3. Draw all screen stuff using mask data.

 

Not sure if what I wrote makes any sense

 

Perfect sense - and basically it's just as you say. The mask is added to as each back window is drawn, and then the desktop is drawn through the mask last. There's a lot of area clipping stuff I will add to ensure that only objects which reside in the vacated space are drawn, and this will save pointlessly throwing pixels at opaque masks. I'll also blit the top window to the new position instead of redrawing it, eventually; the blit code is written, but untested.

 

I need to do a lot of planning with regard to resources once the window manager is finished, then I think things will start to progress quite rapidly. I'm looking forward to writing the dialogue manager. Larger (up to 24pt) fonts are also in the pipeline.

[flashjazzcat]

Here's another version of the video with Altirra's frame blending disabled. Thanks to MrFish for pointing out that it was causing the "ghosting" effect.

 

http://youtu.be/nKenrtfU-lM

 

As I say, the clipping optimisations I have in mind should minimise the pain of drawing content into the back windows, and on big-memory systems we can cache images of the windows anyway.

 

I've just read an interesting article by Yeb Havinga on multi-tasking with the A8, and I'll definitely be designing the system to incorporate multi-tasking further down the line. I see no real reason not to have a crack at it. With a multi-tasking system, each window would have its own mask buffer, and the window manager would hand the window an updated mask every time something got moved, topped or closed. This would allow a partially obscured window belonging to a process which doesn't have the focus to merrily redraw its content in the background.

Edited January 27, 2012 by flashjazzcat

[Marius]

@flashjazzcat

 

I did not read the whole thread. Only shorter pieces, but I must say: WOW!

 

You are definitely a coding-wizard.

 

Don't shoot if I ask something that is described already (several times), but will this run on Atari 8bit hardware, or is VBXE needed? It looks almost too good to be true

[flashjazzcat]

Yeah - the thread's becoming pretty indigestible now. The private discussions are getting pretty hard to map, too.

 

VBXE is definitely NOT required to run the GUI. It'll run on a stock 130XE. If you have more than 128KB of RAM - all the better, but it's not essential. The only extra hardware you'll need - eventually - is a 128KB flash cart.

 

Thanks for the comments. The project's hard going at times, and encouragement definitely helps to keep us motivated.

[+Allan]

This really is amazing. I can't wait to see more. Keep up the fantastic work. It will be so cool to see applications and even games running in the gui.

 

Allan

[JamesD]

@flashjazzcat

You are really pushing the hardware to the limit now.

Did you realize how big this job was going to be when you started?

[spookt]

Amazing work as always Jon! Simply amazing.

[flashjazzcat]

Thanks for the thumbs-up folks! I'm really glad that commentators are able to appreciate just what's going on "under the hood".

 

You are really pushing the hardware to the limit now.

Did you realize how big this job was going to be when you started?

 

Heh - I suspected it would be quite a thrill to see this kind of redraw running on the A8, and I was right. Regarding the size of the job: absolutely not! This grew out of a tiny mouse demo I picked up off the net, and as the bigger project began to suggest itself, I had to take a crash course in GUI theory as I went. By the time I fully appreciated what kind of mountain I was climbing, it was already too late!

 

The A8 (like other 8-bit machines) presents us with so many challenges and limitations, but the Atari somehow always seems up to the job if you coax it right.

[sven86]

Here's another version of the video with Altirra's frame blending disabled. Thanks to MrFish for pointing out that it was causing the "ghosting" effect.

 

http://youtu.be/nKenrtfU-lM

 

As I say, the clipping optimisations I have in mind should minimise the pain of drawing content into the back windows, and on big-memory systems we can cache images of the windows anyway.

 

I've just read an interesting article by Yeb Havinga on multi-tasking with the A8, and I'll definitely be designing the system to incorporate multi-tasking further down the line. I see no real reason not to have a crack at it. With a multi-tasking system, each window would have its own mask buffer, and the window manager would hand the window an updated mask every time something got moved, topped or closed. This would allow a partially obscured window belonging to a process which doesn't have the focus to merrily redraw its content in the background.

 

That sounds interesting. What about RAM when it comes to multitasking?

[flashjazzcat]

That sounds interesting. What about RAM when it comes to multitasking?

 

All applications live in $4000-$7FFF, and may span more than one bank. So switching between tasks is as simple as writing to $D301. Of course, there's also the stack and page zero to worry about, as well as any shared memory regions outside of the banked area. These may have to be cached on-the-fly.

[R6502A]

^{Sorry if you've already gone over this.}

 

^{So, to multitask would it be a matter of switching between these banks in some sort of main window loop?}

^{Is window focus as opposed to multitasking managed through some sort of list? i.e. the one at the head of the list has the focus?}

 

^{I have three main lists in my head: event, task and windows hierarchy.}

Edited February 3, 2012 by R6502A

[flashjazzcat]

^{Sorry if you've already gone over this.}

 

^{So, to multitask would it be a matter of switching between these banks in some sort of main window loop?}

^{Is window focus as opposed to multitasking managed through some sort of list? i.e. the one at the head of the list has the focus?}

 

^{I have three main lists in my head: event, task and windows hierarchy.}

 

Don't apologize: We may have touched on this earlier in the thread, but it's pretty hard to find stuff and multi-tasking wasn't previously a priority (and still isn't, but I'm starting to give it serious thought).

 

Managing window focus and application focus are things I was briefly considering the other day. The single menu model we're using means the menu bar needs to regenerated every time a different application gets the focus. Even if the actual task switching mechanism is simple, managing all the resources soon becomes pretty involved, and the object array and resource tree storage requirements rocket accordingly.

 

Although I'm preoccupied with font rendering on the coding front at the moment, your thoughts on multi-tasking are most welcome.

[atarixle]

That sounds interesting. What about RAM when it comes to multitasking?

 

All applications live in $4000-$7FFF, and may span more than one bank. So switching between tasks is as simple as writing to $D301. Of course, there's also the stack and page zero to worry about, as well as any shared memory regions outside of the banked area. These may have to be cached on-the-fly.

 

Do you really plan to give this GUI a kind of multitasking? Or is it more a "multi-presens", holding multiple programs in RAM but they cannot really run at the same time?

 

In BOSS-X I was trying this by loading several programs into the RAM-Disk (D8:) and fake-switch between them via Fake-Task-Manager. Summary, it's a different looking way to load and start programs from the Disk (RAM-Disk in that case).

[flashjazzcat]

To begin with, there were no plans to task-switch or multi-task at all. I still don't think it's essential that such functionality is part of the first release. However, the arrangement of code and data in RAM is well-suited to holding multiple applications in memory at the same time. It's a fairly short step to task-switching, and then to multi-tasking. The door to multi-tasking was really opened by the work I've done on the window manager, though: it's now pretty easy to have partially obscured windows redrawing themselves in the background, which is vital for mutli-tasking, although not essential for task-switching.

[31336haxx0r]

This is absolutely awesome! Great work!

[sven86]

To begin with, there were no plans to task-switch or multi-task at all. I still don't think it's essential that such functionality is part of the first release. However, the arrangement of code and data in RAM is well-suited to holding multiple applications in memory at the same time. It's a fairly short step to task-switching, and then to multi-tasking. The door to multi-tasking was really opened by the work I've done on the window manager, though: it's now pretty easy to have partially obscured windows redrawing themselves in the background, which is vital for mutli-tasking, although not essential for task-switching.

 

So you're saying that RAM space and management shouldn't be much of an issue?

Edited February 5, 2012 by sven86

[flashjazzcat]

So you're saying that RAM space and management shouldn't be much of an issue?

 

Far from it - even on a single-tasking system. When I finish changes to the font renderer which I'm currently undertaking, then begins the operation of getting all resources to live in extended banks (in the demos, everything fits into 40KB of linear memory). The planning for this is clear, but it's far from easy - especially without impacting on general performance. I'm making provision in advance for task ownership of resources, etc, so the jump to multi-tasking shouldn't be excessively painful further down the road.