New GUI for the Atari 8-bit

[+mytek]

I think 16 bit machines wouldn't have had as much of an impact if GUIs had been common on 8 bits but Atari was in cost cutting mode at the time so I don't see it happening.

 

 

Yeah so many things are all about making just the right decision at the right time, and of course having the right idea plus putting it into action. Let me see... where did I park that Delorean???

 

-Michael

[flashjazzcat]

You'd need some kind of time travel machine, since we also needed twenty-five plus years of hindsight to implement a rectangle-based window manager in assembly language on a 1.7MHz computer. Such window managers were fairly taxing for 8MHz Motorola machines at the time, so there was more than marketing preventing such things from happening (although Apple appeared capable of writing a decent working 8-bit window manager in the 80s). And to do the same thing on top of a pre-emptively multi-tasking kernel at the time without the Delorean? Unlikely. We need something to prove to get these things done

Edited August 17, 2015 by flashjazzcat

[+mytek]

We need something to prove to get these things done

 

Funny how that works. And that is what drives me as well.

 

-Michael

[Bryan]

I think 16 bit machines wouldn't have had as much of an impact if GUIs had been common on 8 bits but Atari was in cost cutting mode at the time so I don't see it happening.

The biggest problem that 16-bit computers solved is the additional memory space needed for graphical apps.

[JamesD]

The biggest problem that 16-bit computers solved is the additional memory space needed for graphical apps.

I kinda agree but there were upgrades for the Apple II with 512K or more of RAM and the CoCo 3 offered expansion to 512K of RAM (larger homebrews were possible) back in the day.

I don't think it's just more RAM but the flat memory model and better compiler support of the CPU kinda round out the deal.

Paging RAM for an 8 bit is certainly doable but it's a bit awkward and requires more work on behalf of the developer.

Apple did sort of get around it with UCSD Pascal but running a stack based virtual machine on a 1 MHz cpu with no stack relative addressing is a bit slow.

 

It would be interesting to see UCSD Pascal or something similar integrated with a GUI like this though.

 

 

[gozar]

I love the look and progress of the GUI, but was wondering. What about moving away from the window model and toward a full screen multitasking model like what is used on mobile devices?

 

Each full screen app could have multiple windows (like the desktop app with a menu bar) but each app would always have the entire screen to themselves. Apps in the background would never have to worry about drawing anything. Would it be possible then for apps to use different graphics modes?

 

Just thinking out loud. :-)

 

 

Sent from my iPhone using Tapatalk

[Kyle22]

Are you one of those "Metro" types? I am certainly not.

[FifthPlayer]

Each full screen app could have multiple windows (like the desktop app with a menu bar) but each app would always have the entire screen to themselves. Apps in the background would never have to worry about drawing anything. Would it be possible then for apps to use different graphics modes?

 

Even further, you'd be able to emulate something like the Amiga Workbench, which multitasked full-screen apps with mixed resolutions, and allowed you to "windowshade-pull" down a screen to expose an app running underneath, using a different display mode. The A8 hardware is totally capable of doing this.

[Joey Z]

I love the look and progress of the GUI, but was wondering. What about moving away from the window model and toward a full screen multitasking model like what is used on mobile devices?

 

Each full screen app could have multiple windows (like the desktop app with a menu bar) but each app would always have the entire screen to themselves. Apps in the background would never have to worry about drawing anything. Would it be possible then for apps to use different graphics modes?

 

Just thinking out loud. :-)

 

 

Sent from my iPhone using Tapatalk

 

 

 

Even further, you'd be able to emulate something like the Amiga Workbench, which multitasked full-screen apps with mixed resolutions, and allowed you to "windowshade-pull" down a screen to expose an app running underneath, using a different display mode. The A8 hardware is totally capable of doing this.

 

 

So let me get this straight, you guys want him to start over? That's what it sounds like to me...

[+JAC!]

Same old, same old visuals here but it definitely feels snappier:

 

I like the speed and way of the redraw when changing the Z order.

[flashjazzcat]

Z-order changes can be faster when already visible areas of the window brought to the front are properly clipped.

 

Regarding full-screen stuff, I had been thinking virtual desktops would be useful on a machine on which most apps will likely be run full-screen anyway. Quite easy to do, and would cater for things which need to run in a different gfx mode. Not going to worry too much about it for the moment, though.

[danwinslow]

No Metro/Iphone style interface for me, thanks.

 

But I think you are really talking about virtual desktops, as FJC mentioned. The idea of allowing an app to go full screen and have complete control over the desktop while it is running would enable app programmers (i.e., us) to do anything they like. This is a capability the GUI needs anyway, to support games and so forth, and I was assuming that was part of the plan.

[flashjazzcat]

Full screen mode is one thing, but should still be accessed through the API. Once you start accessing hardware directly, it's no longer a GUI app: you're effectively in "legacy" mode. Only way back from that is a reboot, since we couldn't rely on the integrity of extended RAM, etc, once software has bypassed the API.

[danwinslow]

Yes, by 'games' I meant new ones, written as an app. Games using the standard GUI resolution of course, but to me it also seems possible for an app to have its own screen graphics mode, as long as there are API calls to support it and they don't get too fancy with interrupts and so forth.

 

Perhaps there could even be a way for the GUI to dump it's entire current state onto disk in a 'restore' file for transitioning into and out of legacy games or really involved app-style games. The GUI would dump itself, the game would initialize and take over everything, and upon termination the system would be reloaded back to the state it was in before the game was run. Just a thought.

Edited August 19, 2015 by danwinslow

[gozar]

I didn't want to get started into a Metro/full screen apps discussion! I brought it up because on such a resolution strained device almost every app will be running full screen anyway, so I assumed it would free up cycles.

[flashjazzcat]

Yes - it would probably be sensible to cater for different graphic modes in a formal manner. SymbOS platforms tend not to suffer from the A8's severe colour constraints, and you'll now find a healthy collection of games which run in windows. That's not to say that mono games can't work, however (there were plenty written for the Apple Macintosh, for example).

 

Regarding interrupts: you'll get timer interrupts, etc, set up using the API. Direct communication with the hardware is strictly forbidden (even "SEI/CLI"). No "GOS Approved" certificate for those apps. The current task manager's graph display runs off a countdown timer, of which there may be an unlimited number.

 

The "dump" idea is a reasonable approach to legacy applications. To be honest, I stopped worrying about supporting legacy apps a long time ago since it seemed more important to me to get a multitasking OS working which isn't bogged down with legacy support (think Windows). Aside from the matter of such applications being free to completely wipe every trace of the GOS upon execution (solved by caching everything beforehand), an emulation layer is also required for such things as disk IO. If you look at SpartaDOS X, native applications do not use the CIO at all, but instead use a completely different kernel based file handle mechanism for IO. In order to provide support for "non-native" applications (i.e. everything else), an intermediate CIO handler maps standard IO requests onto the SDX kernel calls. So, since the GOS clearly does not use the CIO to perform IO (it employs IPC between the application and the IO process), an emulation layer would be required to allow legacy applications to use the resident file system. If anything, such a mechanism will be somewhat more complex than that used by SDX, since the low-level file system library will need to be accessible via the CIO and via messages from parallel processes. Either that, or map in a copy of DOS 2.x when the GOS is cached out, just before running the legacy application. And with that, we're a short distance away from a complete system restart prior to running the legacy application.

 

Honestly: what's appealing to me (and I hope to others) is developing new applications which are message and event driven. I've written one reasonably complex relocatable application so far (the task manager, which isn't even finished yet), and it was a lot of fun - completely unlike any development I've undertaken for the A8 platform in the past. Very formalised, and very appealing to those who enjoy good structure and organisation. Meanwhile, having written a lot of DOS-based applications which have to work with display drivers in the past (FDISK, etc), I recently had lots of fun going to town with direct hardware access in BIOS menus, etc. But having full access to the display hardware is not something I miss about GOS application development, since the two endeavours are rewarding in entirely different ways. And we used direct hardware access to design bespoke UIs for every application on an ad-hoc basis for the past thirty-odd years anyway. GUI apps make a nice change.

Edited August 19, 2015 by flashjazzcat

[Kyle22]

How about saving all the GUI's data in a swapfile on the hard drive? Sort of like the snapshot program saved to extended RAM for context switching. When the legacy application or game is finished, everything is swapped back.

 

Is this possible?

[flashjazzcat]

Assuming a hard drive is present (one is not mandatory), then I see no reason why not.

[+Ripdubski]

I stopped worrying about supporting legacy apps a long time ago since it seemed more important to me to get a multitasking OS working which isn't bogged down with legacy support (think Windows).

 

^^^ This! No need to ensure old stuff runs under it, everyone knows how to boot just about every piece of software created to date. Supporting old software will f' it up in my opinion.

[+MrFish]

^^^ This! No need to ensure old stuff runs under it, everyone knows how to boot just about every piece of software created to date. Supporting old software will f' it up in my opinion.

 

I'm generally with FJC, that new games/applications running under the GUI itself are going to be the most interesting. Just having the use of menus and a tasteful array of proportionally spaced fonts alone is going to add a lot of depth to games and allow Atari development to go places that it's rarely been before. Board, card, simulation, and RPG games can benefit greatly from the use of menus.

 

Lack of legacy support is by no means a deal breaker for using a GUI that can prove useful in it's own right. But there is a coolness factor, and some satisfaction and convenience to be had by clicking on an icon to pull up a legacy app/game from your "environment".

Edited August 19, 2015 by MrFish

[+mytek]

How about saving all the GUI's data in a swapfile on the hard drive? Sort of like the snapshot program saved to extended RAM for context switching. When the legacy application or game is finished, everything is swapped back.

 

Is this possible?

 

This does sound like perhaps the least painful solution, but of course I have no idea what it would take to integrate this into what you got already.

 

Assuming a hard drive is present (one is not mandatory), then I see no reason why not.

 

You seem ok with it, but maybe that's just because you appear to be a very calm and patient person. Hopefully this observation doesn't make you laugh your socks off

 

 

^^^ This! No need to ensure old stuff runs under it, everyone knows how to boot just about every piece of software created to date. Supporting old software will f' it up in my opinion.

 

I would say if it could be easily done, then why not. Otherwise I am in agreement as to not F_ing it up just to support this. And I'm certainly not getting any younger (turning 60 next year), so it would be fantastic to see this GUI fully launched before I And it just looked so friggin cool in that last video, really makes me want to play with it when I get my hardware project done. Once again, great job flashjazzcat

 

 

I'm generally with FJC, that new games/applications running under the GUI itself are going to be the most interesting. Just having the use of menus and a tasteful array of proportionally spaced fonts alone is going to add a lot of depth to games and allow Atari development to go places that it's rarely been before. Board, card, simulation, and RPG games can benefit greatly from the use of menus.

 

Lack of legacy support is by no means a deal breaker for using a GUI that can prove useful in it's own right. But there is a coolness factor, and some satisfaction and convenience to be had by clicking on an icon to pull up a legacy app/game from your "environment".

 

Yes indeed no doubt about it, it would be very COOL

 

-Michael

[danwinslow]

Well, I continue to call dibs on Minesweeper. Maybe Othello too.

[AtariNerd]

Seems possible, that if an old proggy/game is especially liked, one could build a "wrapper" for it, a little seperate front-end program that could load into the GUI, maybe have its own icon, that when clicked sets up special constraints, opens it full screen and allows it to crash out back to the GUI, if necessary.

[flashjazzcat]

This does sound like perhaps the least painful solution, but of course I have no idea what it would take to integrate this into what you got already.

Dumping RAM isn't the tricky part (and might not really be necessary anyway, given that legacy applications tend not to completely trash SDX, which also often keeps parts of itself in extended RAM) - creating a CIO emulation layer is. Rupdubski "gets it", since I guess he realizes that making the host file system work with legacy applications will have an impact on its overall design. For example, the primary file system drivers would not want to be ROM based, since the legacy app will likely turn the cart off (as with the "X" command in SDX), so the drivers would have to live in RAM for the most part. Then there's the emulation layer, most of which would probably have to live in conventional RAM. So, ignoring these considerations now will make legacy support more difficult later on, but focusing on these concerns now will simply complicate matters and delay the point at which we have a system which can do useful things using native GUI applications. As you observe: it would be nice to have a productive system inside of a decade.

 

You seem ok with it, but maybe that's just because you appear to be a very calm and patient person.

Heh... looks can be deceiving. The words I'd use are "polite and restrained".

[FifthPlayer]

For a suggestion that may actually make sense to implement in the GOS - it seems possible to provide a sprite API to provide access to PMGs inside a GOS application.

 

Though it would work best with applications that live on virtual desktops (or virtual "screens" as the Amiga called them), they could be useful to an app that lives on the desktop along with others, they way the GUI works now. The API could restrict the sprite canvas to the windows owned by the application, or it could give the application free reign to place sprites anywhere on the screen. Since the PMGs are a finite hardware resource, only the currently active application (with input focus) would own the sprites at any given time.

 

There's lots of possible uses ways an app could use the sprites, including underlays to add colors to the application.

Edited August 22, 2015 by FifthPlayer