New GUI for the Atari 8-bit

[atarixle]

LOL!

 

I love this tiny Mac!

 

That's totally cute and cool!

[flashjazzcat]

Yet another video showing the same old window-drag:

 

 

However, this is a completely re-written window manager, hence the revisited territory. I'm about 2/3 of the way to getting the GUI as functional as the previous demos, but using the completely new underlying structures. This was a much bigger job than I'd anticipated, and the amount of surplus code which is being ripped out means this is an ideal time to inventory all the subroutines and convert the thing to ROM. Hopefully that'll be done by Christmas and then we can press on with added functionality such as a dialogue manager, wallpaper, etc.

 

I'm not at all sure the speed increase brought about by rewriting the interrupt handlers is discernible in any way. Anyway - we have 150,000-200,000 extra machine cycles per second to play with.

[flashjazzcat]

Managed to get wallpaper working:

 

 

 

BTW: Thanks to MrFish for these wonderful designs!

Edited October 3, 2013 by flashjazzcat

[Magic Knight]

Managed to get wallpaper working:

 

 

 

BTW: Thanks to MrFish for these wonderful designs!

Awesome!

[JamesD]

That looks pretty impressive!

[TheNameOfTheGame]

Yet another video showing the same old window-drag:

 

 

However, this is a completely re-written window manager, hence the revisited territory. I'm about 2/3 of the way to getting the GUI as functional as the previous demos, but using the completely new underlying structures. This was a much bigger job than I'd anticipated, and the amount of surplus code which is being ripped out means this is an ideal time to inventory all the subroutines and convert the thing to ROM. Hopefully that'll be done by Christmas and then we can press on with added functionality such as a dialogue manager, wallpaper, etc.

 

I'm not at all sure the speed increase brought about by rewriting the interrupt handlers is discernible in any way. Anyway - we have 150,000-200,000 extra machine cycles per second to play with.

 

ooooh, nice!

[+Stephen]

Wow - that is killer!

[Kylev]

flashjazzcat,

 

If the explanation isn't overly complicated, what is the new data structure that is producing this amazing amount of extra cycle time?

[+MrFish]

If the explanation isn't overly complicated, what is the new data structure that is producing this amazing amount of extra cycle time?

 

It's the rewritten interrupt handler that he's talking about Kylev. He starts talking about it in post #2152.

[fibrewire]

Totally amazing! The speed is so unbelievable! Congratulations on blowing my mind with the fantastic wallpapers!!!

 

Do you think it's possible to make this run in altirra in a 48K Atari 800 with a 128K Axlon RamDisk without doing to much work?

 

On a side note, your donation button on the new atari8.co.uk site isn't working

[The Usotsuki]

That's a 1.79 MHz 6502?

 

I haven't seen that kind of speed on a 2.8 MHz 65816... o.o;

[flashjazzcat]

Totally amazing! The speed is so unbelievable! Congratulations on blowing my mind with the fantastic wallpapers!!!

 

Do you think it's possible to make this run in altirra in a 48K Atari 800 with a 128K Axlon RamDisk without doing to much work?

Hmmm... well, the window masks (and probably the 2KB bit-shifting look-up-table) will have to reside outside of the banking window ($4000-$7FFF), so it very much depends whether I need to use the Shadow RAM for this. The only other place is $2000-$3FFF, and I'll probably need that for storage space. In the demo, I've squeezed the wallpaper into $D800-$F7FF, with the menu background buffer at $F800 and the mask buffers at $C000-$CFFF.

 

On a side note, your donation button on the new atari8.co.uk site isn't working

Yikes... thanks for that. Fixed now.

 

That's a 1.79 MHz 6502?

 

I haven't seen that kind of speed on a 2.8 MHz 65816... o.o;

Yes it is. Maybe it is appreciably faster than it was before.

 

Anyway: I was a bit daunted by this half-finished, part-rewritten project for a while, but a after a few sessions of heavy coding, things are starting to look manageable.

[The Usotsuki]

My point of reference is Apple II Desktop, written for a 1 MHz 65C02 and running on a 2.8 MHz 65C816.

[flashjazzcat]

My point of reference is Apple II Desktop, written for a 1 MHz 65C02 and running on a 2.8 MHz 65C816.

 

It's as good a reference-point as any, I guess. Speaking of Apple II (and what a great source of inspiration that system is): I found the 65816 source code to the Apple IIGS System the other day:

 

http://macgui.com/downloads/?cat_id=197

 

Maybe someone will port that for an A8 accelerator board one day: it won't be me doing it, though.

 

Only thing i could derive from quickly leafing through the vast source listing was that regions are used for window updates, which is kind of nice since the A8 GUI does something similar.

 

Regarding the underlying changes which are consuming so much time: I'd encourage any interested parties to head over to the SymbOS website and check out the developer docs for that system, because the revised A8 GUI uses very similar window and control structures. The advantage of this is that all the menus, window, and dialogue records are embedded right in the source code, and don't require dynamically allocated RAM to set up. Also, no complex b-trees (that's what the first version of the GUI used) or massive node arrays. The system would now be slightly faster even without the benefit of the redesigned interrupt handler.

 

Some kind of API will gradually become apparent, then, over the coming months, and it's just about time to start documenting it. Obviously it won't be identical to the SymbOS API, although there are key similarities. SymbOS lets the window (rather "Desktop") manager handle all the client area redraws (window content is stored as a control group), which makes sense but for the moment I'm using a callback routine attached to the window record. This lets the application handle the client redraw (ultimately, when these things matter) without actually having to be in its own context (in addition, the client redraw routine can also directly call system library rendering code without context problems). This works well for the moment, and saves a lot of complexity when the system needs to redraw a lot of background windows.

 

The dialogue manager should be an absolute cinch, since I've already finished same for the text mode UI. Just need to change the rendering code and superimpose mouse functionality. Well, not quite as simple as that but at least we have a starting point.

Edited October 4, 2013 by flashjazzcat

[fibrewire]

We're running the whole thing in Antic mode 15 (graphics 8 ), so drawing icons - indeed, drawing anything - is a case of setting the relevant bits in the display RAM. Naturally the OS drawing routines are far too slow, so we have a bunch of custom routines to get lines and stuff on the screen. An icon is arranged in two parts: first, a list of bytes (2 x 16) representing the icon bitmap, and secondly, another 32 bytes representing the icon mask, which basically describes the "silhouette" of the icon against the background. To render the icon, we take a byte of the screen RAM, AND it with the complement of the corresponding byte of the icon mask, then OR that byte with the corresponding byte of the icon bitmap, before writing the byte back to the screen RAM. If the icon position isn't on byte boundaries, there's some bit shifting (rather: table lookups) involved, but that's the general idea. PMGs or other hardware features are not employed at the moment.

Did you ever get around to experimenting with PMGs? The GUI is already very fast, but there's got to be something ANTIC could do to hide window redraw without sucking up too many cycles. If not, maybe on a window resize or new window the GUI will already start precomputing how the updated desktop will be presented with some of those extra machine cycles, and whenever the button is let go on a window drag the GUI will only have to make up the difference. This make up the difference time could be concealed by the screen item doing something like flashing a menu item or a window rectangle animation. I don't really know how these things work, so maybe I'll finally get some Atari Roots reading under my belt.

 

+1 for the zoom window rectangle feature whenever an icon is launched, and also the flash menu item selected feature of System 6 on the Macintosh, as seen here.

 

 

EDIT: Just watched the GUI with wallpaper demo - just scratch that first paragraph I wrote. Jon's GUI is totally as fast as the video I posted. Please still add the window rectangle animation and flash menu item when selected features, and please please PLEASE crank out an XEX soon

Edited October 5, 2013 by fibrewire

[flashjazzcat]

I did experiment with zoom rects a while ago and they worked out quite nicely, and they're easy to implement. The menu flash is kind of implementation dependent, perhaps: we don't "drag" on the menus in the current version (in as much as they work like Windows menus), but we can make that configurable as well. Unless something's completely at odds with the basic design ethic of the system and providing it makes sense to add it (and the code overheads are low), I'm all for making stuff like this configurable in system preferences.

 

I might put out one more XEX just before we make the switch to ROM, despite the fact that on the surface it won't seem much different to the old one.

 

Regarding window redraw speed: I'm putting all my eggs in the masked window basket, since I still believe this innovative approach is the right way to go (the alternative being rectangle lists). I could never quite get away with the fact that you have to call the refresh routine multiple times with rectangle lists, with the display port clipped to each rectangle in the list. Might be faster in some instances, but it would also be slower in others.

Edited October 5, 2013 by flashjazzcat

[+bob1200xl]

Will the next .XEX work on a 65816 with an ST mouse?

[flashjazzcat]

Will the next .XEX work on a 65816 with an ST mouse?

 

Should do. The only thing I want to tweak is the DLI which draws the mouse pointer. The last 65816 demo had some tearing on the pointer, which was caused by the erase routine coming in too early. I'll have to wait on VCOUNT so that CPU speed won't be an issue.

[ClausB]

Nice work!

 

I can't tell from the video - does it force horizontal window extents to multiples of 8 pixels so as to avoid bit masking?

[+MrFish]

Nice work!

 

Thanks!

 

 

I can't tell from the video - does it force horizontal window extents to multiples of 8 pixels so as to avoid bit masking?

 

Yes.

[flashjazzcat]

I can't tell from the video - does it force horizontal window extents to multiples of 8 pixels so as to avoid bit masking?

 

Yes but this restriction might be lifted since because of the cheap bit-shifting and masking there's little reason to keep things on byte boundaries.

[flashjazzcat]

Reimplemented scroll bars, finally working:

 

 

Code's half the size and half as complex as it used to be.

Edited October 6, 2013 by flashjazzcat

[fibrewire]

Holy crap man, it looks so polished. I can't wait to see dialog boxes and moveable icons, GUI settings, etc - it's just too cool!

[danwinslow]

Brilliant work, Jon.

[popmilo]

...Code's half the size and half as complex as it used to be.

Tends to happen after a successful rewrite

 

Possible improvement: could you redraw only edges of slider when moving for a step (by clicking on arrows)?

(Now it looks like you are erasing slider and than drawing it in new place).