New GUI for the Atari 8-bit

[fibrewire]

At this point is there anything specifically tying this to the Atari? Hypothetically speaking, if one were to use this as a frontend to Contiki, is having the 6502 really the only requirement?

[Defender II]

It took me some staring at the screen to understand the code I'd written only a month ago, but having looked at Arc OS the other day, I decided to redesign the mouse pointer and cater for double-byte x-coordinates. The mouse shape/mask can now be up to 16 lines high, but I've shaved a pixel width off the Arc OS mouse shape to keep the mouse renderer from having to do too much work (otherwise the pre-rendered bit-shifted masks would have been three bytes wide instead of two). I may experiment with three byte wide pre-rendered shapes (this would allow for 16x16 pixel mouse pointer resolution), but that's a lot of fiddly work and it can wait till later. It must be remembered that all the mouse drawing/background restoration is done during an interrupt, so economy is critical.

 

The only fundamental improvement to the mouse renderer yet to be implemented is shaving off the MSB/extra lines when the mouse hits the right hand edge or bottom of the screen. MOUSE.XEX works especially well in Altirra (which wisely shuts off the system pointer when capturing the mouse):

 

Mouse.xex

 

Amazing how foreign stuff I wrote only a month ago looks now; however, the proportional font renderer (utilizing Mr Fish's specially created fonts) shouldn't take too long to code up, so hopefully I'll be in direct competition with Jose for screen mockup output in the coming months.

 

Y co-ord checking needs tidying up too...

 

I think this is a great project and am looking forward to the finished product. I had the same problems looking back at old code so I started making detailed notes so I could interpret what I was doing when I went back later, sometimes much later.

[flashjazzcat]

If the scale on the bars gets too expensive, you could always have the bars remain a fixed size and just vary the "steps" between the extremes.

The scaling is only done following a resize or prior to an initial render, and I save the scaling factor in the scroll bar structure. This means that when moving the scrollbars, the math is pretty light. They do require some tweaking to ensure that the max range values always land the thumb in the extreme right/bottom position, though.

 

At this point is there anything specifically tying this to the Atari? Hypothetically speaking, if one were to use this as a frontend to Contiki, is having the 6502 really the only requirement?

Right now, there's very little tying this to the Atari. All that's required is a 6502, an interrupt handler, and a 1bpp bitmapped display. However, that'll soon change of course with the creation of the file selector and as the GUI starts to load in fonts and resources from disk. To be sure, though, a fully realized GUI on top of Contiki would be a fairly powerful combo. It would entirely depend how "expensive" Contiki's back-end processing is.

 

I think this is a great project and am looking forward to the finished product. I had the same problems looking back at old code so I started making detailed notes so I could interpret what I was doing when I went back later, sometimes much later.

I mentioned to Mr Fish last night that it's time to start writing up some serious documentation. If I take an extended break from this thing - for more than a few weeks - a lot of what's in my mind is likely to leak out.

Edited March 19, 2011 by flashjazzcat

[danwinslow]

I think it unlikely that this and Contiki would be easy to integrate.

[fibrewire]

flashjazzcat is right, it would be a powerful combo. Especially if his Atari GUI gets adopted to manage contiki devices everywhere, the possibilities of tiny embedded devices with a gui configuration would be endless.

[w1k]

mouse.xex doesnt work in my real atari.. with basic or withous basic.. with q-meg or without qmeg. in emulator works fine

[flashjazzcat]

mouse.xex doesnt work in my real atari.. with basic or withous basic.. with q-meg or without qmeg. in emulator works fine

I don't even think I've kept the source code for the early mouse demos. Forget about mouse.xex: you'll have something better to try out soon.

[flashjazzcat]

Pretty weird effect in this photo: the desktop almost looks blue:

 

 

Must be the moire effect playing tricks on the phone camera.

[+Philsan]

Today I've received Best Electronic's new Atari/Amiga trackball (together with Atari Logo manuals):

I will test it with Jon's upcoming demo.

For the moment I can say that with this trackball I don't need too much space near my XL.

Unfortunately trackball's color is white and not beige (I am a fashion victim!).

[flashjazzcat]

At least you know it's the Best Trackball!

[flashjazzcat]

Busy coding up the messaging system, and I think I'll follow Diamond's lead here and set things up so that all the non-client area stuff is handled by the library before an application even gets an event message. This is to say that rather than an app having to rescale the scroll bars and reposition the handles after a scroll or window resize event, the window stucture will hold sufficient information so that this can all be done by the OS prior to the application being asked to redraw the client area. I'm starting to document things as I go now, because I have a large number of enumerated codes for events, object editing flags, etc. MADS enumerated constants and structs are really fantastically useful here. For example:

 

	.enum wm_arrow ; arrow scroll types (returned in EVENTRECORD.message)
COL_UP
COL_DOWN
COL_LEFT
COL_RIGHT
PAGE_UP
PAGE_DOWN
PAGE_LEFT
PAGE_RIGHT
.ende

 

We reference these codes with:

 

lda myevent[0].what
cmp #event.WM_ARROW
beq arrow_event

...

arrow_event
lda myevent[0].message
cmp #wm_arrow.COL_UP
beq column_up
...

 

This alone makes the code far more readable than it would otherwise be. Coupled with some judiciously chosen macros, it should be pretty easy to follow.

Edited March 25, 2011 by flashjazzcat

[ilmenit]

Talking about programs for your GUI... I just finished quite strong Reversi program which could use your GUI as an interface

The game is written in way that the AI may calculate during the player turn, which could lead to faster response time or much stronger AI.

However we need a second thread (or interrupt action) for this

 

In the current demo there is only AI vs AI game - no human control yet.

reversi-demo.zip

[danwinslow]

I doubt there will be interrupts or threading as such, but there may be software 'interrupts' accomplished by timer controls. An application could use them to generate timer events to itself on a (semi) regular basis, which could be used to do periodic processing during otherwise idle times. I'm not sure, Jon would have to say for sure, but I know its been discussed.

 

Writing an app will be very different from the normal control flow. Apps won't have an actual 'game loop' of their own; they will basically just respond to events and then return control to the GUI. It's a different way of thinking...it makes some things harder but it offers a lot too. An App that keeps control and does not yield back to the GUI in a timely fashion will be problematic. That kind of thing is what used to cause the GUI-hog lockup problems in early versions of windows if anyone remembers those days.

Edited March 25, 2011 by danwinslow

[flashjazzcat]

Talking about programs for your GUI... I just finished quite strong Reversi program which could use your GUI as an interface

The game is written in way that the AI may calculate during the player turn, which could lead to faster response time or much stronger AI.

However we need a second thread (or interrupt action) for this

 

In the current demo there is only AI vs AI game - no human control yet.

Very interesting indeed. I think Mr Fish wants to write a couple of games for the GUI too. The sooner I get the API documented, the better. It'll be really exciting when other authors start coding for it (although I'm sure that stage in the development will herald a lot of frantic bug fixing and a lot of question fielding).

 

I doubt there will be interrupts or threading as such, but there may be software 'interrupts' accomplished by timer controls. An application could use them to generate timer events to itself on a (semi) regular basis, which could be used to do periodic processing during otherwise idle times. I'm not sure, Jon would have to say for sure, but I know its been discussed.

 

Writing an app will be very different from the normal control flow. Apps won't have an actual 'game loop' of their own; they will basically just respond to events and then return control to the GUI. It's a different way of thinking...it makes some things harder but it offers a lot too. An App that keeps control and does not yield back to the GUI in a timely fashion will be problematic. That kind of thing is what used to cause the GUI-hog lockup problems in early versions of windows if anyone remembers those days.

Yeah: timer interrupts will be catered for. There are a number of components which will require interrupt servicing, not least the clock widget on the menu bar. Every time the minute ticks over, the clock will have to re-render itself, so it'll have to be linked into the system in such a way as the main process can be suspended and control temporarily passed over to the clock redraw.

 

Writing GUI apps is indeed startlingly different from coding a procedural program. At this early stage, it's a real voyage of discovery as it slowly becomes clear how something like the file manager will be structured. I can indeed remember early errant windows apps which caused interminable egg-timer hang-ups. The app should spend the lion's share of its time calling the event handler and reacting as efficiently as possible to the messages it returns. Any processing which takes more than a second or two outside of the event loop should invoke the "busy" mouse pointer, which - since the mouse runs in an interrupt - will usually at least remain mobile.

 

I'm still working hard on the window manager, and I'll have some sample event loop code to post shortly. I'm also constantly distracted by the support macros I keep adding. The following routine stores x, y, width and height in an object structure:

 

store_object_xy
putobw widget.x,cx
putobb widget.y,cy
putobw widget.width,width
putobb widget.height,height
rts

 

With a keen eye on code size, this expands to:

 

store_object_xy
ldy #WIDGET.X
lda CX
ldx CX+1
jsr o_putw
ldy #WIDGET.Y
lda CY
sta (object),y
ldy #WIDGET.WIDTH
lda WIDTH
ldx WIDTH+1
jsr o_putw
ldy #WIDGET.HEIGHT
lda HEIGHT
sta (object),y
rts

 

Again, this kind of thing was inspired by Alan Reeve's excellently readable MAC/65 source code.

Edited March 25, 2011 by flashjazzcat

[+Stephen]

MADS enumerated constants and structs are really fantastically useful here. For example:

 

	.enum wm_arrow ; arrow scroll types (returned in EVENTRECORD.message)
COL_UP
COL_DOWN
COL_LEFT
COL_RIGHT
PAGE_UP
PAGE_DOWN
PAGE_LEFT
PAGE_RIGHT
.ende

 

We reference these codes with:

 

lda myevent[0].what
cmp #event.WM_ARROW
beq arrow_event

...

arrow_event
lda myevent[0].message
cmp #wm_arrow.COL_UP
beq column_up
...

 

This alone makes the code far more readable than it would otherwise be. Coupled with some judiciously chosen macros, it should be pretty easy to follow.

That is absolutely beautiful! Is it possible to have Intelli-sense like autocomplete via WUDSN+Eclipse?

[flashjazzcat]

That is absolutely beautiful! Is it possible to have Intelli-sense like autocomplete via WUDSN+Eclipse?

I'm still getting to grips with autocomplete in WUDSN, and I still haven't added the PROC wrappers, the window manager alone being 1,600 lines long. Unforunately, when I type "CMP #", WUDSN pops up with a lot of compiler preprocessing directives, rather than a choice of enumerated constants.

[flashjazzcat]

We have icons!

 

 

And not before time, either. I've had an icon resource file containing over 100 icons designed by Mr Fish sitting on the drive, unrendered, for over a month.

[+Stephen]

We have icons!

 

 

And not before time, either. I've had an icon resource file containing over 100 icons designed by Mr Fish sitting on the drive, unrendered, for over a month.

Looks fantastic! 100 icons - sounds pretty comprehensive! The scale is perfect for that size screen.

[w1k]

wow, fantastic and cute

[atarixle]

3,5" Disk Icons? ... o.O

[danwinslow]

That looks great! Yeah, they may be 3.5" icons but what the heck.

 

A couple things I wanted to mention :

 

There is not much real estate on the screen. I mean, it's 320x200. With that in mind, I think that it would be nice to maybe shrink up some of the size of the screen elements? Especially the font...its a nice font, but I personally would opt for a 6x6 font or something, in order to fit more on the screen. The borders (and most other elements) are probably 8 pixels wide...so taken together (as in a few windows being open) it could really limit the visibility of things. I am speaking from a practical aspect rather than aesthetic.

For instance drag and drop operations get kind of clumsy if you have to use overlapping windows. Imagine 2 file manager windows open...you'd want to line them up next to each other horizontally to move things back and forth. That would be 4 borders for 32 pixels...then say 20 chars for filename and 20 more for other data like size and date, plus spaces, times two....it would be impractical. I know there would be a scroll bar at the bottom of each window but it would be difficult to see everything you need probably. You'd be better off stacking them vertically, but then there's even less room in that direction. I know I used to hate that situation on the ST comps.

 

Whether you want to shrink things down or provide an alternate font or not, some things I think might be helpful:

 

1. Provide a 'task bar' at the bottom ( or wherever ) where you can minimize windows to and pop them back up from. I don't see a minimize button on the window you have, or at least I don't recognize it.

 

2. Provide more than one screen. So you would have maybe 1 2 3 4 as press-able icons in the task bar, that would flip to an alternate screen where other windows could be stored. Some of the linux desktops do this. Of course, the window would probably have to be completely re-rendered on the way up, as you can't afford ( I think ) to have 4 actual screens all living at the same time in memory. A non active screen would be truly non-active...no events etc., just frozen until woken back up.

 

3. Provide a system clipboard. That's invaluable for situations where you need to swap stuff between windows. I suppose you could tell us to write that as an app, but if you did it as part of the system core then we wouldn't have to get tangled up with different versions and standards and ideas of how to use it.

[AtariNerd]

Whenever flashjazzcat posts a work-in-progress screen-shot, I'm tempted to click on the menus and explore. I guess that's a testimony to how intuitive and comfortable it looks/feels, already. Something we've experienced in like kind from other platforms, given a new, yet familiar old face..

[+MrFish]

@ 3.5 icons: They're just an option for those using 3.5 drives.

 

@ Dan: All the things you speak of have been high considerations since the beginning. Stay tuned...

 

[UNIXcoffee928]

There is an Amiga program named "Diskman" that you need to check out on an Amiga or in an Amiga emulator. Despite it's age, it is the best file management program metaphor that I have ever used, and it would be an ideal screen metaphor to use with your GUI.

 

I've never seen a clone of it on any other platform, but it really made excellent use of screen real-estate, and it was just so intuitive & ergonomic to use... really was great!

 

"Directory Opus" AKA "dopus" took some hints from it (in that that it was dual-paned & configurable), but dopus was BIG & not as streamlined as Diskman... Diskman was small, & was designed with speed, convenience, & reconfigurability in mind, and really, I don't know of any modern program that lets you manipulate files as quickly & easily.

 

If you are wondering how to do some type of efficient file-explorer, Diskman may be just what you are looking for.

[flashjazzcat]

Thanks. As soon as I can get bloody WinUAE to work, I'll check it out. Actually, DiskMan rings a bell - I may have used it during my brief stint as an Amiga 600 owner back in the mid-nineties.

 

I have a few ideas in mind to make the file manager easier to use. TOS in low-res on the ST is not fun. The clipboard is a given: even in hi-res on the ST, I find it a pain being obliged to position windows just so prior to a drag-and-drop when I want to copy a number of files. We should be able to select what we want, copy it, close the source window, then paste it somewhere else. This being a single-tasking system, we need to remember that the file manager is just an MDI application, using the same windowing system as a text editor which allows the opening of multiple files.

 

Actually, I seriously wonder if a tabbed browser interface would be useful on a constrained screen like this...

 

In the meantime, if you have any Amiga emulator recommendations, I'm all ears. Ideally, I don't want to spend time looking for ROMs and Workbench disks... I just want something I can test apps on within five minutes.