New GUI for the Atari 8-bit

[LoTonah]

As a new ST user, I think this GUI looks better than GEM (no proportional fonts - seriously?!?) and it seems almost as fast.

 

I was watching the videos for the Coldfire project and I immediately thought that this was faster at resizing/redrawing of windows. So, even at 266MHz, GEM is slower in some aspects? Yeah, I realize that there is a lot more going on in FreeMINT, but not *that* much. So, this is now the benchmark in my mind for how things should be done LOL

[flashjazzcat]

What can I say? Thanks for your confidence in the project and my ability to complete it (with MrFish's help, of course - believe me he's a powerhouse of font creation, having already created a massive icon collection I haven't even shown off yet).

 

But to those of you who offer unbiased praise and encouragement - it's appreciated. Not for the purposes of ego development, but to remind me that I'm doing something right and worthwhile.

 

I'm just sorry I didn't get this demo (that word again) finished for you guys before I have to go out (which is about now):

 

 

It'll have to wait till tomorrow now, since the buttons don't highlight yet.

 

And can I just repeat myself for the umpteenth time about how nice code looks in MADS:

 

mva #window_title_flag object_flags ; no window furniture
mwa #88 cx
mwa #70 cy
mwa #144 width
mwa #60 height

jsr create_window
mwa client_handle parent

mwa #16 cx
mwa #20 cy
mwa #48 width
lda #< button1_text
ldx #> button1_text
jsr create_button

 

Much clearer than that, and it might as well be C, or something even higher level.

[+DarkLord]

As a new ST user, I think this GUI looks better than GEM (no proportional fonts - seriously?!?) and it seems almost as fast.

 

Yeah, that was a bit of oversight upon release, and Atari, in their infinite hurry to fix things, took awhile. GDOS, SPeedoGDOS,

and later NVDI took care of that though.

[+DarkLord]

Gonna stike out here a bit against the grain..don't really mean to make waves, and it's

just "IMHO", but...

 

The ST, including its OS was out the door from ground zero in -6- months...They were

desperately trying to beat the Amiga's release, so a lot of things that should have been

done, weren't or weren't done well...

 

Now with that being said, I'm in total awe of anyone who can code like flashjazzcat.

 

This project is awesomeness incorporated, and long overdue for the 8bit, IMHO and

I'm firmly in the home team's corner, rooting like mad.

 

So here is the unfair/kicker question... Flashjazzcat, if you were working for company

X, and you had to have this OS out in 6 months, would it be any different? Step back

and look at the 6 month mark of this OS's development state. A really, totally unfair

hypothetical situation, I know... but I think its only fair to compare it to GEM/TOS if they

both had the same amount of time put in upon release...

 

And yes...I wish flashjazzcat was doing OS improvements on GEM/TOS *now* as well!

[+MrFish]

So here is the unfair/kicker question... Flashjazzcat, if you were working for company

X, and you had to have this OS out in 6 months, would it be any different? Step back

and look at the 6 month mark of this OS's development state. A really, totally unfair

hypothetical situation, I know... but I think its only fair to compare it to GEM/TOS if they

both had the same amount of time put in upon release...

 

And yes...I wish flashjazzcat was doing OS improvements on GEM/TOS *now* as well!

 

In all fairness to FJC and myself, we also don't have funds, coders and resources backing us up, as the ST had. It's just Jon, myself and whoever has given help or advice on the forums here. We also are not doing this for a living and working on it full time. So, although you're right from a certain perspective, it's also unfair to give us the same constraints without also adding the money, hours per day and manpower that Atari had.

 

We all know why Atari didn't live up to it's potential in the mid to late eighties, and working on a project like this is one way to help bring the 8-bits up to their potential.

[Mark Wolfe]

I think there are too many variables to answer the question with any sort of accuracy. we can only speculate about where the software would be within a given set of parameters, time & money being only two of those parameters. the fact that any of it is being worked on today is just amazing and speaks volumes about the longevity and usefulness of the hardware.

[potatohead]

I think this thing is just brilliant. I also think it will actually be useful when complete. If so, damn cool. Personally, I think it would be a total blast to do some long form writing on the old Atari, similar to what I do from time to time on the Apple. Apples are still productive actually. Yeah, it's mouse text, and it's got various clunky things, but one can do real stuff. One day, an Atari will join that club. Again, damn cool.

 

There is something just golden about doing that. Heck, maybe write up a few game reviews on the thing. (We need an ASCII output option in LW, if it's not there already.)

[oky2000]

As a new ST user, I think this GUI looks better than GEM (no proportional fonts - seriously?!?) and it seems almost as fast.

 

I was watching the videos for the Coldfire project and I immediately thought that this was faster at resizing/redrawing of windows. So, even at 266MHz, GEM is slower in some aspects? Yeah, I realize that there is a lot more going on in FreeMINT, but not *that* much. So, this is now the benchmark in my mind for how things should be done LOL

 

Even scrolling First Word Plus screens are fast and smooth with a software blitter let alone the desktop GUI. It's just the lower level line A routines that are botched called by the GUI

[flashjazzcat]

Personally, I think it would be a total blast to do some long form writing on the old Atari, similar to what I do from time to time on the Apple. Apples are still productive actually. Yeah, it's mouse text, and it's got various clunky things, but one can do real stuff. One day, an Atari will join that club. Again, damn cool.

 

There is something just golden about doing that. Heck, maybe write up a few game reviews on the thing. (We need an ASCII output option in LW, if it's not there already.)

 

A word processor will probably be the biggest hurdle of all, but fortunately most of the groundwork's already been done in LW and I have a few optimisations up my sleeve which I was considering using there but didn't, so I think we have enough slack to make a responsive editor. For example, I confirmed via an experimental version of LW that the only thing which needs to refresh after each keystroke is the current line - all the rest of the text below can shuffle into place when the user stops typing for a moment. This is going to be key to our success, because there's no way we can redraw fifteen or so lines of text in a paragraph (assuming they all realigned at once) every time the user types a character. So once the important stuff is redrawn (the current line), the next keystroke in the buffer will cause the redraw to abort. This is surprisingly acceptable in practice, although - as I say - LW doesn't do it. Word processors / text editors are my favourite applications bar none, so I'll be spending extra time getting those right. The ASCII output option is a great idea, by the way: something I was planning on putting in the GUI wp, but I can also build it into the non-GUI version of LW. In the GUI, we have 256 character fonts and code pages, and thus Unicode support (or a flavour thereof), so getting text between the PC and the Atari should be straightforward. In point of fact there's no particular reason to use $9B as the EOL character in the GUI anyway, so we could use either ASCII or ATASCII internally (dynamically converting text files to suit either way).

 

Regarding the ST: yes it was developed quickly, and GDOS, etc, put some things right later on, but I'm just puzzled why modern OSes for the ST / TT / Falcon still persist with the fixed-pitch system font. As for the meticulous work going into this project and why TOS perhaps wasn't as efficient comparatively speaking: I've already said that I have no choice at all but to code this GUI in assembler, to take my time about it, and to painstakingly develop new ways of doing things. I wouldn't expect developers for 16-bit machines, in a commercial scenario, to spend two years hand-coding everything in assembler. That said, though, MrFish raises a good point: we have one person writing the code, and one person doing all the resources. Surely software houses have big, full-time, payrolled teams?

 

Seriously, though: we're talking with the benefit of hindsight here, and we've gotten used to nice proportional fonts, etc, over the past twenty years. TOS did its job just fine when it came out. If the A8 GUI compares favourably in performance or aesthetics to the ST / Amiga / Mac, then that's a plus for us as opposed to a minus for those other machines. It was a different world back then.

Edited May 10, 2012 by flashjazzcat

[+DarkLord]

I was watching the videos for the Coldfire project and I immediately thought that this was faster at resizing/redrawing of windows. So, even at 266MHz, GEM is slower in some aspects? Yeah, I realize that there is a lot more going on in FreeMINT, but not *that* much. So, this is now the benchmark in my mind for how things should be done LOL

 

I'm not sure what all is going on with that...

 

I don't have a FireBee (I wish!), but I do have a 40mhz Atari STacy. While I don't have the demo, I did watch the youtube videos and I can definitely say that its not faster than my STacy. The STacy is using TOS 3.06, a 32 bit OS. It is wicked sick fast at 40mhz.

 

Which by no means is saying that the 8bit GUI is slow - its not! I really don't think its fair or even reasonable to compare them.

 

How about comparing it to a GUI on say....a Commodore 64?

[JamesD]

Just remember that GEM originated with Digital Research.

Atari didn't write it from scratch, they ported it... which pretty much means just the hardware specific APIs.

[potatohead]

I've worked with software that updates the current line, and it's no big deal. Updating every other character can work too, in a crunch. What I did note was the screen update does need to stop quickly, should the user type stuff in again, buffering a few keys as needed; otherwise, the latency starts to get in the way. Reads like you've had similar experiences.

 

Proportional fonts are good, but not always good. Some tasks still work best with character aligned fonts, just saying... The beauty in this project is the much improved utility of the high-res graphics screen. Every pixel matters

[Stormbringer]

So the next step is to port this over to the ST's and make a unified line of atari's?

[+MrFish]

Proportional fonts are good, but not always good. Some tasks still work best with character aligned fonts, just saying... The beauty in this project is the much improved utility of the high-res graphics screen. Every pixel matters

 

We'll have plenty of mono-spaced fonts on tap... no worries there.

[flashjazzcat]

Just remember that GEM originated with Digital Research.

Atari didn't write it from scratch, they ported it... which pretty much means just the hardware specific APIs.

 

Excellent point. Looking at the TOS 404 sources, you can see how Atari embellished to system to suit in later years.

 

I've worked with software that updates the current line, and it's no big deal. Updating every other character can work too, in a crunch. What I did note was the screen update does need to stop quickly, should the user type stuff in again, buffering a few keys as needed; otherwise, the latency starts to get in the way. Reads like you've had similar experiences.

 

Yep. The experimental refresh I tested checked CH regularly and dropped out as soon as the type-ahead buffer spat out a key. Writing the same thing again from the ground up, I think we can be a lot smarter, though. LW's refresh had a lot of optimisations bolted onto it (the 80 column display being something of an afterthought, after all), and I know I can do a better job this time. We can apply similar "intermittent" approaches to other areas, too, such as list boxes if I decide to have a crack at "live" scrolling versions.

[Fox-1 / mnx]

Which by no means is saying that the 8bit GUI is slow - its not! I really don't think its fair or even reasonable to compare them.

 

How about comparing it to a GUI on say....a Commodore 64?

 

How about comparing with other GUI's on the same system? Let's see. We have BOSS-XE... and, uh.. did I forgot one? :-)

[LoTonah]

I was watching the videos for the Coldfire project and I immediately thought that this was faster at resizing/redrawing of windows. So, even at 266MHz, GEM is slower in some aspects? Yeah, I realize that there is a lot more going on in FreeMINT, but not *that* much. So, this is now the benchmark in my mind for how things should be done LOL

 

I'm not sure what all is going on with that...

 

I don't have a FireBee (I wish!), but I do have a 40mhz Atari STacy. While I don't have the demo, I did watch the youtube videos and I can definitely say that its not faster than my STacy. The STacy is using TOS 3.06, a 32 bit OS. It is wicked sick fast at 40mhz.

 

Which by no means is saying that the 8bit GUI is slow - its not! I really don't think its fair or even reasonable to compare them.

 

How about comparing it to a GUI on say....a Commodore 64?

 

First of all, I wish this project had a real name! It would make conversations about it easier.

 

Well, GEOS definitely has the advantage of being something we can actually use, with applications and a development environment. Hopefully we'll get some of that someday.

 

As far as looks, elegance, and aesthetics go, this has GEOS beat. Easily.

 

I've never used Wheels before, so I can't comment on that.

 

I'd say the closest thing to "our" (haha) GUI on an 8-bit is GS/OS 6, if you want to call the Apple //GS 8bit.

[potatohead]

Just remember that GEM originated with Digital Research.

Atari didn't write it from scratch, they ported it... which pretty much means just the hardware specific APIs.

 

Excellent point. Looking at the TOS 404 sources, you can see how Atari embellished to system to suit in later years.

 

I've worked with software that updates the current line, and it's no big deal. Updating every other character can work too, in a crunch. What I did note was the screen update does need to stop quickly, should the user type stuff in again, buffering a few keys as needed; otherwise, the latency starts to get in the way. Reads like you've had similar experiences.

 

Yep. The experimental refresh I tested checked CH regularly and dropped out as soon as the type-ahead buffer spat out a key. Writing the same thing again from the ground up, I think we can be a lot smarter, though. LW's refresh had a lot of optimisations bolted onto it (the 80 column display being something of an afterthought, after all), and I know I can do a better job this time. We can apply similar "intermittent" approaches to other areas, too, such as list boxes if I decide to have a crack at "live" scrolling versions.

 

You know this stuff is really becoming a lost art. Human attention is a fickle thing. Easy case is infinite compute power, just updating things to communicate state and data. Most cases though have dependencies, which introduce time, modes, etc...

 

Watching you guys think through this stuff is interesting and entertaining on that level. IMHO, some great lessons for embedded systems too.

[+DarkLord]

So the next step is to port this over to the ST's and make a unified line of atari's?

 

If we're voting, I'm giving this idea 2 thumps up!

[+DarkLord]

Just remember that GEM originated with Digital Research.

Atari didn't write it from scratch, they ported it... which pretty much means just the hardware specific APIs.

 

A valid point. I'm still amazed at what they did in 6 months though, taking in both hardware and software...

 

Thanks.

[spookt]

 

I'm just sorry I didn't get this demo (that word again) finished for you guys before I have to go out (which is about now):

 

 

It'll have to wait till tomorrow now, since the buttons don't highlight yet.

 

 

Is it tomorrow yet?

 

[flashjazzcat]

Is it tomorrow yet?

 

Not quite, hehe. It's like a domino effect: simple extra functionality like closing a window requires all kinds of other stuff (such as code which walks a tree and deletes objects from the bottom back up to the root-node). Nearly done, though.

[atarixle]

Which by no means is saying that the 8bit GUI is slow - its not! I really don't think its fair or even reasonable to compare them.

 

How about comparing it to a GUI on say....a Commodore 64?

 

How about comparing with other GUI's on the same system? Let's see. We have BOSS-XE... and, uh.. did I forgot one? :-)

 

Yes, you forgot BOSS-X (without the E )

 

GEOS screamed at its time and I really wondered, why no comparable GUI has been released on the small A8.

 

In the 80s and the early 90s (and may be still today), GEOS has been the semi-standard OS on the C64, it was very popular as I can say in germany.

There was a large number of professional programs available for GEOS only, so the GUI has been pushed by many companies as they pushed Windows in the 90s.

 

I never used it myself, althru I have a C64 somewhere and I have several emulators able to run GEOS. But it had/has its very large and loyal user-base.

 

Back to the FJC GUI ... well I never been good in conceiving names, I mean, c'mon, what is "BOSS" for a ridiculous name for a GUI. But I think "The Last GUI" (as mentioned in earlier posts) was a really good idea as a name for it, so it could be part of a small but professional product-line of apps by FJC.

 

Ok, that's my two cents for the moment ...

[JamesD]

Just remember that GEM originated with Digital Research.

Atari didn't write it from scratch, they ported it... which pretty much means just the hardware specific APIs.

 

A valid point. I'm still amazed at what they did in 6 months though, taking in both hardware and software...

 

Thanks.

Based on personal experience with embedded systems, I'll bet they had most of the firmware running in around 3 months.

The floppy drivers were probably the most troublesome for them.

[1NG]

And can I just repeat myself for the umpteenth time about how nice code looks in MADS:

 

mva #window_title_flag object_flags ; no window furniture
mwa #88 cx
mwa #70 cy
mwa #144 width
mwa #60 height

jsr create_window
mwa client_handle parent

mwa #16 cx
mwa #20 cy
mwa #48 width
lda #< button1_text
ldx #> button1_text
jsr create_button

 

Much clearer than that, and it might as well be C, or something even higher level.

 

There are also other possibilities in Mads:

 

create_window(window_title_flag, #88, #70, #144, #60)
create_button(client_handle, #16, #20, #48, button1_text)

 

Is that pretty?

 

And where your libraries are something like

create_window  .proc (.byte object_flags .byte cx .byte cy .byte width, .byte height) .var
...
  rts
  .endp

create_button .proc(.byte parent, .byte cx, .byte cy, .byte width, .word ax) .var
...
  rts
  .endp

 

The generated code is the same. No overhead.

And there is more: You can change the program directly via parameter without an extra location by defining the destination of the parameter as location in the executing code (eg.in "MYLABEL AND #00" destination is the 00 as MYLABEL+1)

 

Maybe you can use it. Anyway: Mads is very cool!

 

And good job! I like that planning of a long life product is top priority (and not only a "demo"). I like to watch the project here and I CAN WAIT for a final result, knowing it gets better because of that.