New GUI for the Atari 8-bit

[fibrewire]

My favorite of the GUI tool kits was the IRIX Interactive Desktop. SGI built a great GUI kit. Wheels, spinners, jumpers (short cut launchers to the web and other places), etc...

 

Thanks for that link. I hadn't seen IRIX in a long time. You know an interface is intuitive when you mouse over a screenshot expecting to click on something

 

That or I've been up for 30+ hours working on an edge router... Just a measily old Cisco 1811. 30 hours. Without sleep. OSPF...

[potatohead]

Yeah, that's funny.

 

The IRIX team spent a lot of time on the last coupla revisions working on GUI elements. Their core ideology was to look at the N64, which used a stripped down MIPS and Reality engine for graphics.

 

Latency, discover-ability, interactivity feedback, etc... all were well balanced to both the hardware and X window display system. At the time IRIX was developed, a higher end X server wasn't common. Most UNIX machines had a solid X window system, but it was SGI that went through and did the 3D extensions, and the work needed to manage the display. IRIX desktop was actually a low color affair, usually 8 bit color, with application windows able to request full color depth and geometry accelerated windows.

 

The mouse was hardware sprite overlay, and refreshed at the screen blanking period, where many other machines updated on the kernel heartbeat, typically 15 or maybe 30 FPS. 15 was ugly. 30 is OK, and faster than that appears just solid!

 

All the GUI elements were built to operate on the lower color depth, and with one another, with various themes. The IRIX desktop actually would bog down running full color bitmaps on the background, root window, unless the machine had some serious power. Great example of blending the hardware and the GUI for a optimal experience. Basically, the GUI would run on 8 bit hardware, 1024x768 and 1280x1024, both of which were more or less "standard" resolutions for the machines at the time. All the rest were options, 3D geometry, lights, color buffers, Z, etc...

 

What I liked most about that OS, and the GUI, was the kernel scheduling was keyed toward interactive, "solid" UI experiences. You might bury the machine with some compute heavy task, I/O, whatever, but the GUI always worked, period. The core interaction did not change much, even across vastly different machines. A user could walk up to one of those machines and get a TON of things done without having to actually type anything.

 

Best damn computing experience I ever had. The systems engineering was as good as the Interaction Engineering was. Holistic. Apple is close today. Mac OS has many of the same attributes, and more or less delivers what SGI was back then.

 

(I'll shut up now, LOL!!!)

[fibrewire]

I'm already looking for a ST mouse to use with the 130XE

 

 

[flashjazzcat]

I've bought three bargain ST/Amiga mice in the last month. The place is overrun with the little beggars.

[spookt]

I've bought three bargain ST/Amiga mice in the last month. The place is overrun with the little beggars.

 

Haven't your cats caught 'em?

[flashjazzcat]

I've bought three bargain ST/Amiga mice in the last month. The place is overrun with the little beggars.

 

Haven't your cats caught 'em?

Surprisingly not, although the wife's getting a bit pi**ed off with seeing them all over the place. I'm expecting one to run in through the letterbox tomorrow before she leaves for work...

Edited May 6, 2011 by flashjazzcat

[fibrewire]

Finally made it back to page 32 of this thread... What a long and winding road this project has been. A good hour's worth of reading, if one takes their time to soak in everything that has been done so far. There are so many points that I would like to reiterate on, but I'll just shut up and let others read the thread in it's entirety.

 

FJC: Thanks for showing us what the Atari 8-bit is capable of.

 

Not that it's official, but I would like to point out that "Fuji X Operating System" shortens up as an acronym nicely!

 

Also, are you looking for some source code? I know it's 68K code, but its free

[flashjazzcat]

It's hard to keep track of all the water that's flowed under this bridge. With the other pressing endeavour out of the way, I aim to tighten up the this project in many ways. It's impossible to keep track of everything without copious notes and a proper version management system (which I already have plenty of links for).

 

I'd seen the Mac Paint sources before, but thanks for reposting. I was actually enjoying the article on GEM the other day which appeared in about issue 29 of the Page 6 back-issues, but sadly it petered out before it got really interesting. Mr Fish is tinkering around with some very nice 3D button designs at the moment, while for me, reorganization is the name of the game.

 

FX/OS or some such does sound pretty nice. Let's just hope it doesn't turn out to be murder by design.

[UNIXcoffee928]

...

Not that it's official, but I would like to point out that "Fuji X Operating System" shortens up as an acronym nicely!

...

 

Yes! FuX/OS... That will need to be listed on the resume right next to extensive experience with several versions of

... haha

[+CharlieChaplin]

Well,

 

some big "A" company uses iOS, so the other once big "A" company could use aOS (or AOS)...

 

-Andreas Koch.

[atarixle]

well, is it an OS or is it a GUI?

 

I would name it something that it can be both

[flashjazzcat]

Well, the boundaries are traditionally blurred. Diamond GOS, AFAIK, stands for Diamond Graphical Operating System. However, Diamond is an on-top-of-DOS GUI.

 

In any case, Fuji X is suitably ambiguous.

[Fujix]

Well, the boundaries are traditionally blurred. Diamond GOS, AFAIK, stands for Diamond Graphical Operating System. However, Diamond is an on-top-of-DOS GUI.

 

In any case, Fuji X is suitably ambiguous.

 

 

'Fujix' is something I was working on a few years ago -- an Atari port of Lunix from the C64. It's also my username since I joined AA in 2005. I'm fond of it but would be happy to see it associated with the GUI (and I'll probably never finish Lunix).

[Faicuai]

Well, the boundaries are traditionally blurred. Diamond GOS, AFAIK, stands for Diamond Graphical Operating System. However, Diamond is an on-top-of-DOS GUI.

 

In any case, Fuji X is suitably ambiguous.

 

 

...Not only that, but think about the "recall" potential (speaking in pure marketing terms):

 

Phonetically, it can be pronounced in one single, fluid stroke, something like "phooghix", and could be shown in many fancy, cool-looking ways, such as "FujiX" or "Fuji-X", to show just humble examples.

 

On top of that, most folks in real knowledge of Atari's origins also know that the word "Atari" itself originates from a Japanese word, and, for this reason, it is also natural (or not bizarre) to associate Atari's logo/shape (and anything alike) to Japan's Fuji mountain.

 

 

Sounds, to me, as cool and as contemporary as the Atari line-up truly deserves.

 

 

F.

Edited May 10, 2011 by Faicuai

[fibrewire]

I just like the idea of FXTerm, FXDraw, FXChat, and FXEdit

 

Of course, FX-API isn't bad either

 

FXGame - a game launcher...

FXDisk - a floppy and hard disk utility...

FXNote - a POKEY music player...

FXMail - an email client

[flashjazzcat]

Epson FX-80...

[fibrewire]

Epson FX-80...

 

Printer of choice for the discerning FJC GUI user!

[flashjazzcat]

The Only Way is FX!

[fibrewire]

FJC: Sorry I ran with that blasted name. I'm feeble minded when it comes to buzz words. It's your GUI and you can do what you want! I really feel bad, hopefully you can find it in your 6502 kernel to fogive meh!

***ALERT*** FJC GUI it is until further notice!

[flashjazzcat]

Been thinking over a couple of things, now that it's time to get back into this project (and I fear the weeks away from it are gonna be tough to recover from, now the "rhythm" has been interrupted).

 

If the event handler effectively "blocks", what about scenario whereby there's a progress dialogue on the screen with a cancel button, the purpose of which is to chart the progress of a multi-file copy operation. Obviously we can't be in the event loop, but we want to register a click of the cancel button. In this simplified model, I suppose the only way is to monitor the mouse button inside the file copy loop, and if a mouse down occurs, immediately jump into the event loop and find out what happened (everything except a click on "cancel" being ignored). This would require exact timing, since we don't want to the mouse button to be released by the time the event handler gets the chance to register a click. I'm starting to think it might be a good idea to buffer the mouse clicks and use a pipe after all.

[fibrewire]

I don't really know what I'm talking about, but what about ignoring the mouse completely? If an operation is in progress, does using the keyboard 'ESC' and 'BREAK' keys make more sense? You could show a radio button with 'ESC' - The escape key would pause the process so that a 'Cancel? Yes/No' dialog would pop up also allowing mouse control, and a CTRL-BREAK operation would destructively terminate the operation.

 

Black Magic Composer locked the mouse pointer. Tandy 1000 Deskmate OS would display a big hour glass in the center of the screen, and the pointer would disappear completely.

 

[danwinslow]

Been thinking over a couple of things, now that it's time to get back into this project (and I fear the weeks away from it are gonna be tough to recover from, now the "rhythm" has been interrupted).

 

If the event handler effectively "blocks", what about scenario whereby there's a progress dialogue on the screen with a cancel button, the purpose of which is to chart the progress of a multi-file copy operation. Obviously we can't be in the event loop, but we want to register a click of the cancel button. In this simplified model, I suppose the only way is to monitor the mouse button inside the file copy loop, and if a mouse down occurs, immediately jump into the event loop and find out what happened (everything except a click on "cancel" being ignored). This would require exact timing, since we don't want to the mouse button to be released by the time the event handler gets the chance to register a click. I'm starting to think it might be a good idea to buffer the mouse clicks and use a pipe after all.

 

( Jon, I may be missing some context here and would like to apologize beforehand if I'm off base )

 

I'm wondering why you would want the event handler to block at all. Mouse clicks should be delivered to the appropriate message queue by the mouse handler. After that its up to the app. Since the mouse handler is interrupt driven, it should be able to drop off events even when the app is otherwise occupied. Being tempted to do things like monitoring the mouse events directly from inside a loop other than the main event loop is pretty much always an indication that something is wrong in the design.

 

In the case of the app being very busy in some long running operation, like a file copy, you must insert queue checks at periodic intervals during the operation. Basically you never want to let an app lock itself up in a long running loop to do anything without checking the event queue, or you'll freeze the system. The mouse will work, but no app will respond until after the operation is complete. So the loop would copy a sector (say) and then exit back out to the main app event loop, process any pending events as per usual, and then go back into copying the next sector. If no events were pending, the execution speed of the copy would not be impacted that much. In your example, you would need to periodically interrupt the copy operation anyways to draw the progress bar. Note that a critical feature of the app event loop will be to EXIT back to the 'main dispatcher' of the GUI OS itself. If it doesn't do that, then you can only run one app at a time.

 

So how would we run more than one app if they all have their own event loops? Well, when an app registers itself with the GUI, the address of it's main event loop is placed in a jump table that you maintain inside the GUI. The GUI simply loops through the table, calling each app's event loop in turn. A critical feature is that the app event loop is not really an endless loop, its just single pass call that returns to the GUI after processing (X) number of events, (X) being a variable number that could be used to implement 'priority' levels ( ie., high priority tasks get more trips through their app loop before they return to the GUI ).

 

So, this is really a kind of multitasking without actually having separate tasks. The thread running is always belonging to the GUI. Really, the GUI is the only thing running at all, its just that apps can hook into a table and have their main event 'loop' code called at periodic intervals by the GUI. You get the benefits of multithreading mostly, without the pain of actually doing task swaps and locking and so forth. So the GUI loop would be something like

 

loop

foreach entry a in app_table loop

if it's 'time' to call a

call a

update a's entry to reflect next time to be called

end if

end foreach

check 'global' events queue ( ie., for 'shutdown' and so forth )

do internal housekeeping

end loop

 

and an app 'loop' would be

 

for (x) number of times

get next event for me

dispatch event

if I've got something to do ( like copy the next sector, for instance )

call my code

end if

end loop

return to GUI

 

 

The hardware event drivers ( mouse, etc. ) are all on interrupts and could care less what the apps are doing, they just need to know the address of the queue to stick an event in. You could decide to have a global event queue and then have your GUI main loop distribute them to the app queues in a housekeeping function, or you could arrange some way for the drivers to (quickly!) look up a particular apps' event queue.

 

Of course, an app could still lock the whole system by not cooperating ( not returning from its app call periodically enough ). There's not a whole lot to be done about that without restricting the ways in which an app writer can express his code, and so I would just leave it as a warning to app writers not to do that kind of thing if they want people to use their apps.

Edited May 18, 2011 by danwinslow

[flashjazzcat]

( Jon, I may be missing some context here and would like to apologize beforehand if I'm off base )

 

I'm wondering why you would want the event handler to block at all. Mouse clicks should be delivered to the appropriate message queue by the mouse handler. After that its up to the app. Since the mouse handler is interrupt driven, it should be able to drop off events even when the app is otherwise occupied. Being tempted to do things like monitoring the mouse events directly from inside a loop other than the main event loop is pretty much always an indication that something is wrong in the design.

 

In the case of the app being very busy in some long running operation, like a file copy, you must insert queue checks at periodic intervals during the operation. Basically you never want to let an app lock itself up in a long running loop to do anything without checking the event queue, or you'll freeze the system. The mouse will work, but no app will respond until after the operation is complete. So the loop would copy a sector (say) and then exit back out to the main app event loop, process any pending events as per usual, and then go back into copying the next sector. If no events were pending, the execution speed of the copy would not be impacted that much. In your example, you would need to periodically interrupt the copy operation anyways to draw the progress bar. Note that a critical feature of the app event loop will be to EXIT back to the 'main dispatcher' of the GUI OS itself. If it doesn't do that, then you can only run one app at a time.

 

So how would we run more than one app if they all have their own event loops? Well, when an app registers itself with the GUI, the address of it's main event loop is placed in a jump table that you maintain inside the GUI. The GUI simply loops through the table, calling each app's event loop in turn. A critical feature is that the app event loop is not really an endless loop, its just single pass call that returns to the GUI after processing (X) number of events, (X) being a variable number that could be used to implement 'priority' levels ( ie., high priority tasks get more trips through their app loop before they return to the GUI ).

 

So, this is really a kind of multitasking without actually having separate tasks. The thread running is always belonging to the GUI. Really, the GUI is the only thing running at all, its just that apps can hook into a table and have their main event 'loop' code called at periodic intervals by the GUI. You get the benefits of multithreading mostly, without the pain of actually doing task swaps and locking and so forth. So the GUI loop would be something like

 

loop

foreach entry a in app_table loop

if it's 'time' to call a

call a

update a's entry to reflect next time to be called

end if

end foreach

check 'global' events queue ( ie., for 'shutdown' and so forth )

do internal housekeeping

end loop

 

and an app 'loop' would be

 

for (x) number of times

get next event for me

dispatch event

if I've got something to do ( like copy the next sector, for instance )

call my code

end if

end loop

return to GUI

 

 

The hardware event drivers ( mouse, etc. ) are all on interrupts and could care less what the apps are doing, they just need to know the address of the queue to stick an event in. You could decide to have a global event queue and then have your GUI main loop distribute them to the app queues in a housekeeping function, or you could arrange some way for the drivers to (quickly!) look up a particular apps' event queue.

 

Of course, an app could still lock the whole system by not cooperating ( not returning from its app call periodically enough ). There's not a whole lot to be done about that without restricting the ways in which an app writer can express his code, and so I would just leave it as a warning to app writers not to do that kind of thing if they want people to use their apps.

No apology needed: you understood the query perfectly. The mouse button event handling was completely blocking, until I realized this was the wrong way to go about things. You've provided me with plenty to think about, and this is a great opportunity to express some of these ideas in code, now that I'm coming back to this project with a fresh set of eyes.

 

Thanks, as always, for your invaluable guidance!

Edited May 18, 2011 by flashjazzcat

[flashjazzcat]

This is kind of interesting:

 

 

ACE 128 Home Page

 

Monospaced 80 column, but using a lot of colour. Not a direct, like-for-like "competitor", of course...

Edited May 20, 2011 by flashjazzcat

[fibrewire]

Monospaced 80 column, but using a lot of colour. Not a direct, like-for-like "competitor", of course...

The machine - eBay Auction -- Item Number: 110684870771

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

Would you make a monthly compiled .atr demo of your GUI?