Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store
IGNORED

New GUI for the Atari 8-bit

flashjazzcat

By flashjazzcat
in Atari 8-Bit Computers

 Share

Recommended Posts

flashjazzcat Quadrunner

flashjazzcat

Posted
  • Author
Posted

Yeah - it's stored offsite and MrFish gets (fairly) regular copies of the source code. Pity anyone who takes over following my untimely demise, however. :)

 

At least by doing this twenty-five years late we avoid the risk of being targetted by industrial assasins hired by the ST development team. :D

  • Like 1
Link to comment
Share on other sites
kogden Dragonstomper

kogden

Posted
Posted

Here's a quick look at the window manager with some dummy content (lists of tiny filenames, which is the slowest-to-render folder view the file manager will produce) and using raster copies to move the front window:

 

Wow, things seem to be progressing quick! Am I wrong in assuming that it'll be even faster when drawing large icons instead of text in the file manager?

 

What sorts of GUI widgets will be available in the initial release for programmers to take advantage of? Are you leaving it up to application developers to implement complex widgets like tables, etc? Any particular requirements for an assembler development environment?

 

I'd like to take a stab at a simple VisiCalc clone.

 

A simple presentation package that supported full-screen color slides in playback mode with the editor running in the GUI might be an interesting project one day too.

 

--Kevin

Link to comment
Share on other sites
Gunstar Quadrunner

Gunstar

Posted
Posted

If my memory serves me correctly, I don't recall the Diamond GOS 2.0&3.0, ATOS or any other GUI/desktop out there for the A8 running windows as quickly. I'm satisfied with that speed of redraw, if it gets better, great.

Link to comment
Share on other sites
flashjazzcat Quadrunner

flashjazzcat

Posted
  • Author
Posted (edited)

you also could use Ubuntu One ... on Ubuntu Laptops or so

 

Didn't know about that: thanks. :)

 

anyway, did you complete some programs yet? e.g. filemanager?

 

I'm months away from writing the file manager. The demo is just a 30KB executable which loads entirely into conventional RAM, and has a small sample application assembled right into it. Once the system is transferred to cartridge, the resources running out of extended RAM, and the API closer to completion, then work will begin on the file manager proper. The fact the demo appears to be tantalisingly close to the file manager's functionality is a mere side effect of it testing out the window manager.

 

when will be finished, what will be this gui contains? browsing files, copying, viewwing txt files, or? some features?

 

All of the above. I'll do the file manager, text editor, word processor (at length) and an APT partition editor. All that will take a long time, so I'm reliant on other developers (including MrFish) to start churning out programs once the API is reasonably complete. The word processor will hopefully be the "killer app", but the file manager on its own should prove useful on a day-to-day basis.

 

Wow, things seem to be progressing quick! Am I wrong in assuming that it'll be even faster when drawing large icons instead of text in the file manager?

 

You're correct to assume that. List view is the slowest to render, although even that will be much quicker when I finish the rest of the code which skips unnecessary rendering. Icon view should be extremely fast.

 

What sorts of GUI widgets will be available in the initial release for programmers to take advantage of? Are you leaving it up to application developers to implement complex widgets like tables, etc?

 

A LOT of widgets. I figure since this thing is gonna run on a banked cartridge, the code base isn't much of an issue. So - for example - a text editor should be able to place a text edit control in a window and that will be most of the functionality taken care of. The GUI library itself enjoys unbuffered access to all the banked RAM, so the more tasks are directly handled by the cartridge code, the better. This will also keep application size to a minimum. Table objects, collapsing trees (especially looking forward to that one), etc, etc, will all be there... eventually. That's not to say you can't create your own widgets: everything's table-based so you just register your custom control and its methods, and it becomes part of the system.

 

Any particular requirements for an assembler development environment?

 

That's a tricky question. Ideally we'd all be writing apps using MADS's relocatable format, so that nothing would be tied to a specific address and we could dynamically link symbolic references to library calls, etc. I was drawing up plans for such a loader a while back. However, I don't want to leave C coders out in the cold, and there's no special need for applications to be relocatable (although desk accessories are another matter), so to be honest that's a bit up in the air at the moment.

 

I'd like to take a stab at a simple VisiCalc clone.

 

OK - that's the spreadsheet taken care of. Great! :)

 

A simple presentation package that supported full-screen color slides in playback mode with the editor running in the GUI might be an interesting project one day too.

 

What I'd like to do is provide the tools for people to have a crack at stuff like this. If people end up developing for the GUI, we'll have done something right here.

 

I have a question: would it be possible to implement some sort of virtual memory/ram for those with IDE/SD/CF storage expansion? or is the only option to upgrade physical ram to run the GUI?

 

Good question. The memory pool isn't intrinsically virtual, but resources will tend to "fall out" of RAM when available memory fills up, and will be pulled back in from disk when needed (thereby pushing out some other less-recently accessed resource). Since memory pool access is indirect anyway, though, we can extend the system to use a "swap file" if it's prudent to do so further down the line. There's really so much still to do on the resources front, though; we've been concentrating on getting the font renderer and window manager to work, and both have just about been nailed during the past two months or so.

 

If my memory serves me correctly, I don't recall the Diamond GOS 2.0&3.0, ATOS or any other GUI/desktop out there for the A8 running windows as quickly. I'm satisfied with that speed of redraw, if it gets better, great.

 

Other systems may in fact render stuff (especially the non-client area of windows) faster (although Diamond renders window content more slowly), but we have to offset this against the fact that the new GUI clips and masks everything (to allow absolutely the most flexible presentation), allows windows to move off the screen, and has windows which are made up of actual widgets which all have their own callbacks, etc. In addition, the redraw here works very much like TOS / Mac OS, in as much as it's not a "flat" redraw of the desktop from the bottom up everytime something moves. It's still easy for the application, though, and we have no dirty rectangle lists, etc. The application just draws the whole client area when asked, and the GUI takes care of all the masking and clipping for every object drawn. For a full list view window, only a few dozen of several hundred calls to the character renderer may actually result in anything being drawn to the screen. And it will get faster when I add the rest of the clipping code. :) At the end of the day, the cumulative effect is a much more responsive system.

 

I wish I could provide more detailed replies (especially regarding the API), but many aspects of this project are moving forward in parallel, and we're only just over a year into it. I'm extremely pleased with the momentum we've enjoyed so far this year (note that MrFish - having already designed hundreds of icons - has also been working double-hard at the conversion utilities to bring us all those wonderful fonts). Now that the window manager is taken care of (the workings of which were by far the most complex aspect of the whole project, and several rather innovative solutions have been used), everything else should be a fairly procedural process of designing and coding.

 

Nice as it would be to be six months or so further into this, the pleasure has to be in the doing (that's why I enjoy coding), so I just have to regard each new working component as a reward in itself. One thing is now certain: the Atari's 6502 IS fast enough to run a fully masked and clipped GUI with overlapping windows and proportional fonts in different sizes, and this realization provides us with the determination to finish what we started.

Edited by flashjazzcat
  • Like 3
Link to comment
Share on other sites
twh/f2 Dragonstomper

twh/f2

Posted
Posted (edited)

Given the size and complexity of this project, I'm delighted to announce a new addition to the GUI development team:

 

post-21964-0-21602300-1333106971_thumb.jpg

 

:)

 

At last an Atari picture which me AND my girl friend really like :) And she is not much into the Atari scene believe me :)

Edited by twh/f2
  • Like 1
Link to comment
Share on other sites
MrFish Quadrunner

+MrFish

Posted
Posted

Given the size and complexity of this project, I'm delighted to announce a new addition to the GUI development team:

 

post-21964-0-21602300-1333106971_thumb.jpg

 

I think he's just after the mouse...

 

I heard he prefers Fish. ;)

 

I'm a 5' 11", 230 pound fish -- he'll have a better chance with minnows. ;)

Link to comment
Share on other sites
flashjazzcat Quadrunner

flashjazzcat

Posted
  • Author
Posted (edited)

Glad to see the new addition is popular! :)

 

Finally at the stage where windows have content, are blitted where possible, and can be freely dragged on and off the desktop:

 

http://youtu.be/k-DQlbenn9c

 

I regard this as something of a milestone, at least as far as development of the window manager is concerned. It's bloody complicated getting all the blits clipped but it's getting there, although I still have the extra clipping and intersection checking to do, which will save many cycles so I don't even think this is a true picture of performance as it will be. For example: eventually if a window is partly off-screen, what's visible will blit, then that area will be masked out and not redrawn. Similaly, when a window is topped, only the parts which are newly exposed will be drawn. All that's coming: just taking time to code up.

Edited by flashjazzcat
  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...