New GUI for the Atari 8-bit

[potatohead]

Everything (with the exception of the screen buffering, for which I have a few competing ideas) is absolutely clear in my mind now and it's just a case of laboriously coding things up according to the grand plan.

 

So, how do you manage that? For me, I find I don't have this skill down very well, which limits me on larger projects. I know most of it has to do with inexperience, as I've just done programming for a hobby most of the time, and where I didn't, the tasks were discrete, well defined, and not too complex in scope. A driver, filter, renderer (those can get messy, but I can build them incrementally), etc...

 

Is it really all in your head? If so, aren't you concerned that you might lose it, or it gets bent this way and that, based on things you may see, hear, do? Very curious to hear what you have to say.

 

If not, how do you represent things? Curious either way, and I apologize for the digression.

 

Looking great as always, BTW!

[popmilo]

... it's the best one for demonstrating the 1px 3D button shift. I've no idea if I'll keep this feature in, but it looks cool and has good novelty value. The more balanced button design has even borders and the text doesn't shift 1px down and to the right....

Yeah, that 1px shift looks strange...

Its ok if you have higher resolution, but in 320x200 it looks like too much...

Simple change of button borders shades should be enough.

 

I think you will find the best solution!

 

Btw. nice progress on inner structure in the last few weeks ...

[flashjazzcat]

Everything (with the exception of the screen buffering, for which I have a few competing ideas) is absolutely clear in my mind now and it's just a case of laboriously coding things up according to the grand plan.

 

So, how do you manage that? For me, I find I don't have this skill down very well, which limits me on larger projects. I know most of it has to do with inexperience, as I've just done programming for a hobby most of the time, and where I didn't, the tasks were discrete, well defined, and not too complex in scope. A driver, filter, renderer (those can get messy, but I can build them incrementally), etc...

 

Is it really all in your head? If so, aren't you concerned that you might lose it, or it gets bent this way and that, based on things you may see, hear, do? Very curious to hear what you have to say.

 

If not, how do you represent things? Curious either way, and I apologize for the digression.

 

Looking great as always, BTW!

Good questions. I make lots and lots of notes, but I find I never look at them. What I do keep looking at - and what I keep permanently open when coding - is the GUIDEF file, which lits all the structures, constants, data types and variables for the GUI. This is the most modular piece of software I've ever written, and once the basic data types are done (hence the frantic rewrite the other week), the rest is really like joining the dots. I have dozens of stub markers for controls I haven't implemented yet: all I do - when I get around to it - is code up their render and click methods under the stub labels. That's fairly procedural stuff. The slightly more elusive stuff (memory management, the application loader, screen buffering) is what's floating around in my head, backed up by a few scribbled notes. So really, my head's not too over-cluttered, since I don't have to fret over when I'm actually implementing right now; I'm fretting about stuff that's yet to come.

 

I don't worry, either, about being swayed by outside factors. This has happened a lot already, and it's usually been beneficial. The best example is the mouse pointer renderer, which I think is incredibly cool and wouldn't have happened without the ideas, suggestions and code samples from Popmilo and others. I must admit I like being in complete control of this project at the end of the day, but primarily because this means I can work as fast or as slow as I like, and I have no-one breathing down my neck telling me to do things this way or that way.

 

I don't know if that answers your questions. The fact of the matter is, I have told my self off already for not keeping a technical journal of some sort, so that if I did get hit by a falling piano, it would be at least possible to intuit the gist of where I'm going with certain things that aren't complete or haven't been started.

 

No need to apologize for digressing. This is such a huge undertaking, it often helps to talk about how it's being done, and - indeed - why it's being done. I sometimes need reminding of the answer to the second question!

 

... it's the best one for demonstrating the 1px 3D button shift. I've no idea if I'll keep this feature in, but it looks cool and has good novelty value. The more balanced button design has even borders and the text doesn't shift 1px down and to the right....

Yeah, that 1px shift looks strange...

Its ok if you have higher resolution, but in 320x200 it looks like too much...

Simple change of button borders shades should be enough.

 

I think you will find the best solution!

 

Btw. nice progress on inner structure in the last few weeks ...

You concur with MrFish: he doesn't like the 1px shift either. Shame - I simply add the value of CMD_BUTTON.STATE (UP = 0 , DOWN = 1) to the X and Y offset of the text label when rendering the button. I guess I just wanted to see what it would look like, though. The buttons with even borders look better.

 

The fact is, you can have pretty much any effect you like: just provide bitmaps for idle and pressed buttons and you can have lozenge-shaped buttons, buttons which invert - anything you like.

 

Yes - I'm reaping the rewards of all the re-coding over the past couple of weeks. The only things I'd like to change in the code example are ensuring that CX and CY aren't corrupted by the control rendering routine. This would remove the need to call GET_OBJECT_POSITION all the time. I could simply cache X and Y, of course.

[flashjazzcat]

Buttons look better now:

 

http://www.youtube.com/watch?v=iUDXbF6Diy0

 

I also drag the window around a little to demonstrate the client area rendering.

 

There's now plenty of space for underlined shortcut keys and a "selected" box around the label while still keeping everything nice and balanced.

[UNIXcoffee928]

Buttons look better now:

 

http://www.youtube.com/watch?v=iUDXbF6Diy0

 

I also drag the window around a little to demonstrate the client area rendering.

 

There's now plenty of space for underlined shortcut keys and a "selected" box around the label while still keeping everything nice and balanced.

 

Looks like everything is moving along splendidly!

 

I've watched this new video about 20 times, and here are my recommendations:

 

1. The bitmap complexity of the desktop needs to be reduced, to facilitate faster window movement. Here is my suggestion: Use NeXT tiles running down the right side of the screen, rather than the icons on the left side of the screen. If you make them so they display no text, until you mouse-over them, then you have reduced the amount of rendered text, freeing some cycles to give more processing time for window movement.

 

The main menu-bar/titlebar bar does not need to be displayed all of the time, either. You will gain screen real-estate, and have a tidy desktop if the menu-bar at the top only appears during mouse-over, or from click invocation from a "control" tile on the NeXT-like tile-bar (topmost one). This will free cycles for window movement, and, in general give the interface a more hi-tech look... (considering that the NeXT interface is still more hi-tech looking then any of the Xerox/Macintosh derivative GUIs...).

 

2. The new buttons work great, but are 2x larger than necessary, and require excess bits to move, due to their design. If you try an Amiga Workbench 1.3 button, instead, you will have a lot less to move around, and window movement will be faster. Your smaller soft-font would help here too.

 

3. There must be a way to parallelize operations. Perhaps through creative interleaving, to take better advantage of the Atari's co-processor architecture, and the memory banking scheme that you are using. You've got to brainstorm on it.

 

4. I think that the window and all of it's decorations look fabulous! However, you may need to reduce the complexity of the bitmap to get the window to move perfectly fluidly... If this isn't done, the user-experience will suffer, because it will feel slow, and unresponsive. Are you double-buffering the display? You may need to save your current window code, to refer back to, and start with moving a plain rectangular box around, again. It would be most useful to show a text-based directory listing in this plain rectangular box, rather than icons. You need to get to a point where you can move the window, fluidly, showing the contents of the window, whilst dragging. Once this is achieved, then look back at the old code, and selectively re-implement portions of it, until you notice a visible performance lag.

5. You should take a look at your memory banking scheme, with regard to performance. Set up timers, and determine where your faster memory accesses occur (Internal vs. External), and also check if interleaving data in different banks can be used to speed things up. There are also extra operations that need to be performed, to use external banking, so, it is wise to bear in mind that the stuff that needs to look stationary (the desktop itself) should be accessed in the fastest way possible. Then the performance of the window should be tweaked in relation to the desktop's display performance, so that you never see the desktop flicker.

 

It is a good time to review the possibilities of interleaving concepts, so that it is fresh in your head... then start thinking how data can be in multiple places, by separating it and putting it in different places, to facilitate faster queuing of data that needs to be displayed.

 

An interesting method, to achieve fluidity, which I just conceived of, would be a quad, or preferably, 8-way bit-complimented hash table pointer, or just a computable bit-shift that is always loop updated, and residing in memory (North, South,East, West or mimic the 8 way of the Atari-joystick logic method. Since you will have some memory to burn, via ultimate 1mb, use 8+ banks. This is a rather novel approach to massive "double buffering", but it could be very simple (bit shift of current dot, apply-able to all points, or more complex (a full table of pre-bit manipulated bitmaps, for each direction, residing in it's own memory segment.).

 

These are all just observations, take what you want from them. You are doing an amazing job, thanks for all of your hard work!

[UNIXcoffee928]

Additionally, check out the Zebra Striped Network File System. If you use these concepts, for your memory banking & management, you'll know what I'm describing, with regard to separating data, per bank. Just substitute "Bank" & "Memory segment" for the concepts that Zebra Striping uses, with regard to Networks and Hosts.

[potatohead]

Would it be too big of a distraction for you to share / scan a note or two, that file, with some meta-commentary on how, why, etc...? Just a snippet I can see and mull over, not anything that would be real labor. PM it, if you are inclined to. If it is too big of a distraction, that's ok too. No worries. One doesn't get, unless they ask, so I'm asking!

Edited September 4, 2011 by potatohead

[flashjazzcat]

Looks like everything is moving along splendidly!

Slowly but surely.

 

1. The bitmap complexity of the desktop needs to be reduced, to facilitate faster window movement. Here is my suggestion: Use NeXT tiles running down the right side of the screen, rather than the icons on the left side of the screen. If you make them so they display no text, until you mouse-over them, then you have reduced the amount of rendered text, freeing some cycles to give more processing time for window movement.

I quite like the "tooltip" text idea, and this is indeed something which MrFish and I have in mind - to one extent or another - for the finished article. Our main concern was to maximize screen real estate, although cycle saving through printing less text is surely a beneficial side-effect. I can't honestly say I feel as if I'm struggling for responsiveness at the moment, but I take your comments on board, and the more screen elements we have, the more compound savings we will make through saved cycles in frequently executed routines.

 

The main menu-bar/titlebar bar does not need to be displayed all of the time, either. You will gain screen real-estate, and have a tidy desktop if the menu-bar at the top only appears during mouse-over, or from click invocation from a "control" tile on the NeXT-like tile-bar (topmost one). This will free cycles for window movement, and, in general give the interface a more hi-tech look... (considering that the NeXT interface is still more hi-tech looking then any of the Xerox/Macintosh derivative GUIs...).

I've looked at NeXT before, but I'll gladly look again with special attention to the tiles. I want the interface to be "familiar", but also contemporary. Even Windows Mobile / Windows 8 has given me pause for thought, although the tiles are often simply doorways to applications with a more traditional desktop interface.

 

2. The new buttons work great, but are 2x larger than necessary, and require excess bits to move, due to their design. If you try an Amiga Workbench 1.3 button, instead, you will have a lot less to move around, and window movement will be faster. Your smaller soft-font would help here too.

Coincidentally I was thinking the same thing about the size of the buttons, but I don't want to use a 6 or 7 point font for the buttons and the "thick" system font for the menus and other window components, since I feel this will be unbalanced. No doubt MrFish will be digesting all this, and perhaps he'll have another point of view.

 

3. There must be a way to parallelize operations. Perhaps through creative interleaving, to take better advantage of the Atari's co-processor architecture, and the memory banking scheme that you are using. You've got to brainstorm on it.

There are a lot of very fundamental barriers to where things can go when it comes to banked memory. I don't want to have bitmasks in one bank, and bitmaps in another, for example, for obvious reasons (lots of buffering or byte-by-byte bank switching). I take the point about parallelization, though: the mouse pointer renderer is a decent example, since it caches the background and draws the pointer in the same loop. With a stacking windowing system, however, some things just have to happen before others. I have a close eye on keeping the redraws fast (yes - they will be buffered), but on the other hand I don't wish to expend huge amounts of code on overlapping windows when they'll likely be seen in few places other than the built-in file browser (and even then, I was considering a tabbed interface). The pointer renderer - to my surprise it must be said - certainly showed that we can take advantage of many hardware tricks in this project.

 

4. I think that the window and all of it's decorations look fabulous! However, you may need to reduce the complexity of the bitmap to get the window to move perfectly fluidly... If this isn't done, the user-experience will suffer, because it will feel slow, and unresponsive. Are you double-buffering the display? You may need to save your current window code, to refer back to, and start with moving a plain rectangular box around, again. It would be most useful to show a text-based directory listing in this plain rectangular box, rather than icons. You need to get to a point where you can move the window, fluidly, showing the contents of the window, whilst dragging. Once this is achieved, then look back at the old code, and selectively re-implement portions of it, until you notice a visible performance lag.

Full window drag? It ought to be possible depending on the buffering / blitting scheme, but I wasn't that keen on going for it, although I'm sure it would look great. If you're going to drag a blitted bitmap around the screen, though, what it contains doesn't really matter much: the blitted image can contain as many or as few elements as you like.

 

5. You should take a look at your memory banking scheme, with regard to performance. Set up timers, and determine where your faster memory accesses occur (Internal vs. External), and also check if interleaving data in different banks can be used to speed things up.

I was considering interleaving banks for a word processor, funnily enough. However, we must remember that this needs to run on a 130XE.

 

There are also extra operations that need to be performed, to use external banking, so, it is wise to bear in mind that the stuff that needs to look stationary (the desktop itself) should be accessed in the fastest way possible. Then the performance of the window should be tweaked in relation to the desktop's display performance, so that you never see the desktop flicker.

I'm considering running the window manager with the object bank permanently switched in, so that tree traversal is as fast as it can be. Unfortunately there's always some abstracted, object-specific information residing in the OB_SPEC bank. Creative collation and caching of this information might save a lot of time.

 

It is a good time to review the possibilities of interleaving concepts, so that it is fresh in your head... then start thinking how data can be in multiple places, by separating it and putting it in different places, to facilitate faster queuing of data that needs to be displayed.

A perfect time, yes - since I just rewrote the whole object database. Paying special attention to this OB_SPEC data now makes good sense.

 

An interesting method, to achieve fluidity, which I just conceived of, would be a quad, or preferably, 8-way bit-complimented hash table pointer, or just a computable bit-shift that is always loop updated, and residing in memory (North, South,East, West or mimic the 8 way of the Atari-joystick logic method. Since you will have some memory to burn, via ultimate 1mb, use 8+ banks. This is a rather novel approach to massive "double buffering", but it could be very simple (bit shift of current dot, apply-able to all points, or more complex (a full table of pre-bit manipulated bitmaps, for each direction, residing in it's own memory segment.).

I'll come right out with it and admit that I hardly understood a word of that.

 

These are all just observations, take what you want from them. You are doing an amazing job, thanks for all of your hard work!

I appreciate that, and you've raised some excellent points. Food for thought.

 

Would it be too big of a distraction for you to share / scan a note or two, that file, with some meta-commentary on how, why, etc...? Just a snippet I can see and mull over, not anything that would be real labor. PM it, if you are inclined to. If it is too big of a distraction, that's ok too. No worries. One doesn't get, unless they ask, so I'm asking!

Not at all. The hand-written notes are illegible, since I wrote them, but I'll gladly upload the GUIDEF file here once I've removed any embarrassing commented out junk!

Edited September 4, 2011 by flashjazzcat

[+MrFish]

1. The bitmap complexity of the desktop needs to be reduced, to facilitate faster window movement. Here is my suggestion: Use NeXT tiles running down the right side of the screen, rather than the icons on the left side of the screen. If you make them so they display no text, until you mouse-over them, then you have reduced the amount of rendered text, freeing some cycles to give more processing time for window movement.

I quite like the "tooltip" text idea, and this is indeed something which MrFish and I have in mind - to one extent or another - for the finished article. Our main concern was to maximize screen real estate, although cycle saving through printing less text is surely a beneficial side-effect. I can't honestly say I feel as if I'm struggling for responsiveness at the moment, but I take your comments on board, and the more screen elements we have, the more compound savings we will make through saved cycles in frequently executed routines.

We have actually discussed using NeXT tiles before, and it could have several possible applications for use on the desktop. We're definitely not leaving out anything as a possibility for giving the richest and most useful environment, while providing the maximum amount of space and performance, combined with good esthetics and clearly distinguishable elements. We also want to design in as much flexibility as possible for the configuration, as everybody's idea of what makes up "the best" balance of all of the different elements is never singular.

 

The main menu-bar/titlebar bar does not need to be displayed all of the time, either. You will gain screen real-estate, and have a tidy desktop if the menu-bar at the top only appears during mouse-over, or from click invocation from a "control" tile on the NeXT-like tile-bar (topmost one). This will free cycles for window movement, and, in general give the interface a more hi-tech look... (considering that the NeXT interface is still more hi-tech looking then any of the Xerox/Macintosh derivative GUIs...).

I've looked at NeXT before, but I'll gladly look again with special attention to the tiles. I want the interface to be "familiar", but also contemporary. Even Windows Mobile / Windows 8 has given me pause for thought, although the tiles are often simply doorways to applications with a more traditional desktop interface.

I think we also discussed menu-bar hiding as an "option" as well. I personally find it annoying when mousing around to have the bloody menu popping up constantly when it isn't wanted. I'm pretty happy to give up that space in order to have a stable menu-bar. As an option for people who want it seems fine.

 

2. The new buttons work great, but are 2x larger than necessary, and require excess bits to move, due to their design. If you try an Amiga Workbench 1.3 button, instead, you will have a lot less to move around, and window movement will be faster. Your smaller soft-font would help here too.

Coincidentally I was thinking the same thing about the size of the buttons, but I don't want to use a 6 or 7 point font for the buttons and the "thick" system font for the menus and other window components, since I feel this will be unbalanced. No doubt MrFish will be digesting all this, and perhaps he'll have another point of view.

As far as I know these buttons are just something we're playing around with, eh Jon?. A little bulky, maybe... I've only done one mockup with them as of yet. We'll have to see how bad the crowding gets with a fully loaded file-selection dialogue. We haven't dumped using the standard Macintosh 1-pixel buttons, and other similarly minimalist button designs, to my knowledge.

 

I agree with Jon, that whatever menu font is used, it should also be used on the buttons as well. Since this is intended, currently, to be optional, then smaller text on buttons is possible in that respect.

Edited September 5, 2011 by MrFish

[flashjazzcat]

We have actually discussed using NeXT tiles before, and it could have several possible applications for use on the desktop. We're definitely not leaving out anything as a possibility for giving the richest and most useful environment, while providing the maximum amount of space and performance, combined with good esthetics and clearly distinguishable elements. We also want to design in as much flexibility as possible for the configuration, as everybody's idea of what makes up "the best" balance of all of the different elements is never singular.

Yep - everyone's ideas are different. I was reading a review of NeXT last night, and the reviewier complained that the tiles got in the way at 640x480. Horses for courses...

 

I think we also discussed menu-bar hiding as an "option" as well. I personally find it annoying when mousing around to have the bloody menu popping up constantly when it isn't wanted. I'm pretty happy to give up that space in order to have a stable menu-bar. As an option for people who want it seems fine.

Auto-hide menus bug me too, but it is indeed no problem to have them as an option.

 

As far as I know these buttons are just something we're playing around with, eh Jon?.

Yes - it's clearly stated on the videos that these are first attempts.

 

A little bulky, maybe... I've only done one mockup with them as of yet. We'll have to see how bad the crowding gets with a fully loaded file-selection dialogue. We haven't dumped using the standard Macintosh 1-pixel buttons, and other similarly minimalist button designs, to my knowledge.

The only limitation is that the minimum button width = 1 byte of left image + 1 byte of centre image + 1 byte of right image. When I changed the design, I simply swapped in new bitmaps and got rid of the 1px shift. Minimalist designs might look really nice.

 

I agree with Jon, that whatever menu font is used, it should also be used on the buttons as well. Since this is intended, currently, to be optional, then smaller text on buttons is possible in that respect.

The only thing we'll have to watch is that changing the font size is likely to skew existing resource designs all over the place. It might be wise to provide relative positioning meta instructions for dialogues, etc. I've seen this with a couple of open-source GUIs. This would allow dialogue elements to "reflow" when the font size was changed, rather than remain in fixed positions and at fixed sizes, ending up with text strings running over them, etc.

 

I was mulling over a couple of screen-buffering ideas last night, and I can see a lot of mileage in keeping separate cached bitmap copies of all "layers" of the desktop, i.e. the desktop itself and each window image. This would make redraws extremely fast but would be rather costly in terms of memory, and as I've said before, I'm against throwing lots of resources at making stacked windows look slick when they'll only show up in the desktop manager. The special "RAM cart" Steve Tucker designed for me would have been ideal for this, since we have plenty of 8KB RAM banks to waste. Unfortunately, I don't think folks want to be tied to using one particular flash cart for this thing. That's a shame, since if I could overcome the headache of where to put things when $4000-$7FFF is the RAMdisk banking window and $8000-$BFFF is taken up by 8KB of banked cart RAM and 8KB of banked cart ROM, then we could have gone really wild and designed something which ran out of the box on a stock 800XL.

Edited September 5, 2011 by flashjazzcat

[danwinslow]

If I read that mouse event snip correctly, you are having the button wait for it's own button up event using a loop? Assuming that's not just quick demo code, I think you'd probably want to stay away from having objects hard loop waiting on events, it shuts everything else out. Any loops in event processing code is usually bad juju.

 

Usually what you want here is a kind of little finite state machine, where the top of each trip through the code is an event pull. If you're waiting on a mouse up, you'd have to track that in some kind of local state variable that you refer to.

 

You also might want to consider having the mouse driver generate the 'you got clicked' event all by itself. If you abstract the mechanics of what generates a mouse down/mouse up combo away from what it means, it'll make it easier to implement other pointing devices later.

Edited September 5, 2011 by danwinslow

[flashjazzcat]

If I read that mouse event snip correctly, you are going into a hard loop waiting for the button release? Does this mean that nothing in the entire system can process any events while the user is holding the button down?

Yeah - you read that correctly. I'll need to change that to allow for timer events, etc.

[HiassofT]

Hi Jon!

 

The special "RAM cart" Steve Tucker designed for me would have been ideal for this, since we have plenty of 8KB RAM banks to waste. Unfortunately, I don't think folks want to be tied to using one particular flash cart for this thing. That's a shame, since if I could overcome the headache of where to put things when $4000-$7FFF is the RAMdisk banking window and $8000-$BFFF is taken up by 8KB of banked cart RAM and 8KB of banked cart ROM, then we could have gone really wild and designed something which ran out of the box on a stock 800XL.

The development of the new Turbo Freezer is now (almost) finished, and might serve as another platform for your GUI.

 

I added a special 8k+RAM mode to the cartridge emulation that allows you to bank in up to 384k of RAM at $8000. We have a total of 960k free flash, plus full SDX support, including emulation of "stacked" carts. So you can have SDX, your GUI code plus 384k of RAM all in the Turbo Freezer. Hope this is enough memory for your GUI

 

Banking is quite simple: there's a R/W bank register at $D590 for the main 8k $A000 area (banks 0-127), writing this register automatically enables the $A000 bank. There's a separate enable/disable register at $D591 (also R/W). Just write 0 to disable the cart and 1 to (re-)enable it.

 

RAM-banking is exactly the same, with registers at $D592/93 and banks 0-47. If you press the RESET button on the Atari, the RAM bank is automatically disabled to prevent accidental data corruption (OS putting the screen there etc).

 

In addition to this the new Turbo Freezer also comes with a 512k RamDisk (standard PORTB switching using PB 2,3,5,6,7 for banks), and all of the RAM is battery-backuped

 

The prototypes are already running fine and we hope it'll be available by the end of this year.

 

so long,

 

Hias

[flashjazzcat]

Sounds great Matthias (and good to hear from you, BTW - it's been a while!).

 

Hopefully there'll be emulator support for this soon? Lack of emulation support for fancy carts is one of the things which discourages me from using them (after all, that even makes my development work ten times harder).

Edited September 5, 2011 by flashjazzcat

[flashjazzcat]

Why is it every time I take the 1200XL out of the cupboard, I start making videos...

 

http://www.youtube.com/watch?v=5p8bFNy8TaU

 

I have a cream coloured mouse to go with it.

[danwinslow]

because 1200xl's are cool!

[w1k]

this stuff must be hard work men..

[Gunstar]

Well, I haven't been paying much attention to the 8-bit scene for a couple of years now, so I'm getting in on this conversation probably way to late to contribute with ideas, but here it goes anyway.

 

The things I want out of a GUI are the ability to be resolution-independant (able to run in ANY 8-bit resolution). Ability for desktop wallpaper, the ability to load and display any graphic resolution pictures, Atari mode or jpeg and gif stuff to(even the newer software graphic modes with 64/128/256/4096 color interlaced and non-interlaced like APAC for one example) regardless of the desktop resolution (obviously desktop pics would have to be in the desktop res). Of course all the usual stuff like being able to boot up any program, or disk image and then recover to the desktop afterwards. Can work on 64k or 128k machines, but takes full advantage of more memory. Multitasking with programs developed for the GUI.

Edited September 8, 2011 by Gunstar

[UNIXcoffee928]

Well, I haven't been paying much attention to the 8-bit scene for a couple of years now, so I'm getting in on this conversation probably way to late to contribute with ideas, but here it goes anyway.

 

The things I want out of a GUI are the ability to be resolution-independant (able to run in ANY 8-bit resolution). Ability for desktop wallpaper, the ability to load and display any graphic resolution pictures, Atari mode or jpeg and gif stuff to(even the newer software graphic modes with 64/128/256/4096 color interlaced and non-interlaced like APAC for one example) regardless of the desktop resolution (obviously desktop pics would have to be in the desktop res). Of course all the usual stuff like being able to boot up any program, or disk image and then recover to the desktop afterwards. Can work on 64k or 128k machines, but takes full advantage of more memory. Multitasking with programs developed for the GUI.

 

Why stop there? What about a harem of female laboratory assistants, (blond, brunette, AND redhead) wearing labcoats, bikinis, and silver combat boots, with makeup like the Scorpion's "Rock You Like a Hurricane" video, a large, tropical private island, in the middle of nowhere, WITH a racetrack going around it, a candy-apple red squadron of SR-71 Blackbirds, a German automobile mechanic, on staff 24/7, a full size remote-control helicopter (one of those big dual prop Soviet ones, thanks), a huge stone castle, with a razor-wire perimeter, a pack of laughing hyenas for pets to keep in the front yard (please dye the fur pink, with a black Mohegan stripe, thanks), an unlimited ebay budget, a 100 foot schooner from the 1890s, a pet dolphin, and a fishbowl like the Brooklyn Aquarium, 600 Menacing-Looking Evil Robots, 20 gynoid fembots programmed like LEXX, 40 fembots programmed to do laundry with the same type of determination, a CDC 6600 and a SAGE workstation (be sure to include the built-in ashtray, thanks), Energy, food, tobacco, coffee, & support systems to make the whole island self-sustainable, a Saturn 5 launchpad, the contents of the NY Public Library, and the Museum of Natural History, some other trifles, and a really wiz-bang Internet connection? Thanks, Jon!

 

 

 

[Gunstar]

Well, I haven't been paying much attention to the 8-bit scene for a couple of years now, so I'm getting in on this conversation probably way to late to contribute with ideas, but here it goes anyway.

 

The things I want out of a GUI are the ability to be resolution-independant (able to run in ANY 8-bit resolution). Ability for desktop wallpaper, the ability to load and display any graphic resolution pictures, Atari mode or jpeg and gif stuff to(even the newer software graphic modes with 64/128/256/4096 color interlaced and non-interlaced like APAC for one example) regardless of the desktop resolution (obviously desktop pics would have to be in the desktop res). Of course all the usual stuff like being able to boot up any program, or disk image and then recover to the desktop afterwards. Can work on 64k or 128k machines, but takes full advantage of more memory. Multitasking with programs developed for the GUI.

 

Why stop there? What about a harem of female laboratory assistants, (blond, brunette, AND redhead) wearing labcoats, bikinis, and silver combat boots, with makeup like the Scorpion's "Rock You Like a Hurricane" video, a large, tropical private island, in the middle of nowhere, WITH a racetrack going around it, a candy-apple red squadron of SR-71 Blackbirds, a German automobile mechanic, on staff 24/7, a full size remote-control helicopter (one of those big dual prop Soviet ones, thanks), a huge stone castle, with a razor-wire perimeter, a pack of laughing hyenas for pets to keep in the front yard (please dye the fur pink, with a black Mohegan stripe, thanks), an unlimited ebay budget, a 100 foot schooner from the 1890s, a pet dolphin, and a fishbowl like the Brooklyn Aquarium, 600 Menacing-Looking Evil Robots, 20 gynoid fembots programmed like LEXX, 40 fembots programmed to do laundry with the same type of determination, a CDC 6600 and a SAGE workstation (be sure to include the built-in ashtray, thanks), Energy, food, tobacco, coffee, & support systems to make the whole island self-sustainable, a Saturn 5 launchpad, the contents of the NY Public Library, and the Museum of Natural History, some other trifles, and a really wiz-bang Internet connection? Thanks, Jon!

 

It could actually be done, that's why stop there. If you want to be sarcastic, you should at least keep it computer oriented, going off in an "anything in the world" tangent is too lame to be sarcastic.

[simonl]

Well, I haven't been paying much attention to the 8-bit scene for a couple of years now, so I'm getting in on this conversation probably way to late to contribute with ideas, but here it goes anyway.

 

The things I want out of a GUI are the ability to be resolution-independant (able to run in ANY 8-bit resolution). Ability for desktop wallpaper, the ability to load and display any graphic resolution pictures, Atari mode or jpeg and gif stuff to(even the newer software graphic modes with 64/128/256/4096 color interlaced and non-interlaced like APAC for one example) regardless of the desktop resolution (obviously desktop pics would have to be in the desktop res). Of course all the usual stuff like being able to boot up any program, or disk image and then recover to the desktop afterwards. Can work on 64k or 128k machines, but takes full advantage of more memory. Multitasking with programs developed for the GUI.

 

You should have a read of this thread (if you've got a week or so spare ), I think essentially what the first version of this desktop manager will offer is cooperative multitasking between the desktop and its accessories and one "user mode" application. I could be wrong though, hard to keep track of a thread this length. As far as wanting full multitasking goes I think the programs would have to be very limited, as the 6502 is not really suited for this in the same way that 65816 or 6809 are with their relocatable pages etc. so you'd be on a hiding to nowhere trying to implement this. Having the desktop manager send a message to the current program to prompt you if you want to quit, review unsaved documents etc. when you go to start a new one would be a reasonable way round this.

 

Personally, I would love to see a version down the line with support for VBXE (the 640x200x16 mode seems made for this, and the blitter capabilities would allow the drawing code to be greatly accelerated - you might even be able to have desktop wallpaper without any slowdown!), but what's here already looks excellent. Reminds me of my days programming classic Mac OS

 

If once the desktop manager is completed it had a text editor on a par with the existing Last Word and a SpartaDos X command window, and someone could port an assembler and/or C compiler so they run without needing to quit the desktop environment then together with an SIDE or similar it would be like my ideal 8-bit baby workstation

 

Cheers,

 

Simon

[flashjazzcat]

You should have a read of this thread (if you've got a week or so spare ), I think essentially what the first version of this desktop manager will offer is cooperative multitasking between the desktop and its accessories and one "user mode" application. I could be wrong though, hard to keep track of a thread this length. As far as wanting full multitasking goes I think the programs would have to be very limited, as the 6502 is not really suited for this in the same way that 65816 or 6809 are with their relocatable pages etc. so you'd be on a hiding to nowhere trying to implement this. Having the desktop manager send a message to the current program to prompt you if you want to quit, review unsaved documents etc. when you go to start a new one would be a reasonable way round this.

You're on the right lines with that. We're talking about background tasks (timer events, such as a system clock on the menu bar), task-switching between main app and accessories, and that's about it to be getting on with. The fact applications will load at $4000 and can occupy more than one extended bank deliberately opens the door to switching between multiple active applications in RAM, but only the "front" application would be active at a given time. I see no mileage whatsoever in trying to implement time-slicing or multi-threading.

 

Personally, I would love to see a version down the line with support for VBXE (the 640x200x16 mode seems made for this, and the blitter capabilities would allow the drawing code to be greatly accelerated - you might even be able to have desktop wallpaper without any slowdown!), but what's here already looks excellent. Reminds me of my days programming classic Mac OS

If you're a Classic Mac coder, I hope to give you an API you can be creative with. I'm holding you to developing some apps, though! Regarding VBXE, Candle is also keen to see this happen, but it's a case of one step at a time. Once the API is documented, I might get him to code up a VBXE graphics library himself. There are certain things which will need to be done differently with VBXE, however, such as the "invisible" mouse pointer (rendered and erased in a blocking raster interrupt). I see no obvious way of accomplishing the exact same thing using the VBXE FX core.

 

If once the desktop manager is completed it had a text editor on a par with the existing Last Word and a SpartaDos X command window, and someone could port an assembler and/or C compiler so they run without needing to quit the desktop environment then together with an SIDE or similar it would be like my ideal 8-bit baby workstation

As long as it's all running on a 1200XL! Actually an SDX command window is something I have been thinking about, but I need to discuss the practicalities in detail with KMK. I'll bet it's going to be complex, although SDX has all we need to redirect screen input and output to a window.

 

Well, I haven't been paying much attention to the 8-bit scene for a couple of years now, so I'm getting in on this conversation probably way to late to contribute with ideas, but here it goes anyway.

Never too late...

 

The things I want out of a GUI are the ability to be resolution-independant (able to run in ANY 8-bit resolution).

OK, well that isn't going to be this one. The graphics routines aren't resolution independant, and that's deliberate because I feel that would make it WAY too slow. 320x200 is the bare minimum resolution for a useful screen display, IMO.

 

Ability for desktop wallpaper...

Check.

 

...the ability to load and display any graphic resolution pictures, Atari mode or jpeg and gif stuff to(even the newer software graphic modes with 64/128/256/4096 color interlaced and non-interlaced like APAC for one example) regardless of the desktop resolution (obviously desktop pics would have to be in the desktop res).

If people want to write picture viewers which go full screen and display APAC pictures, etc, they'll have my blessing.

 

Of course all the usual stuff like being able to boot up any program, or disk image and then recover to the desktop afterwards.

A vital capability, so check.

 

Can work on 64k or 128k machines...

This won't work on a 64K machine without a special RAM cartridge - no way, no how.

 

...but takes full advantage of more memory.

No problem. You have RAM? I'll use it.

 

Multitasking with programs developed for the GUI.

Task-switching further down the line at least.

[Gunstar]

You should have a read of this thread (if you've got a week or so spare ), I think essentially what the first version of this desktop manager will offer is cooperative multitasking between the desktop and its accessories and one "user mode" application. I could be wrong though, hard to keep track of a thread this length. As far as wanting full multitasking goes I think the programs would have to be very limited, as the 6502 is not really suited for this in the same way that 65816 or 6809 are with their relocatable pages etc. so you'd be on a hiding to nowhere trying to implement this. Having the desktop manager send a message to the current program to prompt you if you want to quit, review unsaved documents etc. when you go to start a new one would be a reasonable way round this.

You're on the right lines with that. We're talking about background tasks (timer events, such as a system clock on the menu bar), task-switching between main app and accessories, and that's about it to be getting on with. The fact applications will load at $4000 and can occupy more than one extended bank deliberately opens the door to switching between multiple active applications in RAM, but only the "front" application would be active at a given time. I see no mileage whatsoever in trying to implement time-slicing or multi-threading.

 

Personally, I would love to see a version down the line with support for VBXE (the 640x200x16 mode seems made for this, and the blitter capabilities would allow the drawing code to be greatly accelerated - you might even be able to have desktop wallpaper without any slowdown!), but what's here already looks excellent. Reminds me of my days programming classic Mac OS

If you're a Classic Mac coder, I hope to give you an API you can be creative with. I'm holding you to developing some apps, though! Regarding VBXE, Candle is also keen to see this happen, but it's a case of one step at a time. Once the API is documented, I might get him to code up a VBXE graphics library himself. There are certain things which will need to be done differently with VBXE, however, such as the "invisible" mouse pointer (rendered and erased in a blocking raster interrupt). I see no obvious way of accomplishing the exact same thing using the VBXE FX core.

 

If once the desktop manager is completed it had a text editor on a par with the existing Last Word and a SpartaDos X command window, and someone could port an assembler and/or C compiler so they run without needing to quit the desktop environment then together with an SIDE or similar it would be like my ideal 8-bit baby workstation

As long as it's all running on a 1200XL! Actually an SDX command window is something I have been thinking about, but I need to discuss the practicalities in detail with KMK. I'll bet it's going to be complex, although SDX has all we need to redirect screen input and output to a window.

 

Well, I haven't been paying much attention to the 8-bit scene for a couple of years now, so I'm getting in on this conversation probably way to late to contribute with ideas, but here it goes anyway.

Never too late...

 

The things I want out of a GUI are the ability to be resolution-independant (able to run in ANY 8-bit resolution).

OK, well that isn't going to be this one. The graphics routines aren't resolution independant, and that's deliberate because I feel that would make it WAY too slow. 320x200 is the bare minimum resolution for a useful screen display, IMO.

 

Ability for desktop wallpaper...

Check.

 

...the ability to load and display any graphic resolution pictures, Atari mode or jpeg and gif stuff to(even the newer software graphic modes with 64/128/256/4096 color interlaced and non-interlaced like APAC for one example) regardless of the desktop resolution (obviously desktop pics would have to be in the desktop res).

If people want to write picture viewers which go full screen and display APAC pictures, etc, they'll have my blessing.

 

Of course all the usual stuff like being able to boot up any program, or disk image and then recover to the desktop afterwards.

A vital capability, so check.

 

Can work on 64k or 128k machines...

This won't work on a 64K machine without a special RAM cartridge - no way, no how.

 

...but takes full advantage of more memory.

No problem. You have RAM? I'll use it.

 

Multitasking with programs developed for the GUI.

Task-switching further down the line at least.

 

Sounds pretty good, task=switching would be fine.

With regards to resolution independence, I agree that the lower resolutions are..harder to display and control a desktop with, but screen scrolling and scalable fonts could take care of it. My main reason for wanting all resolutions support is I'm a graphic artist and want more than monochrome or 4-color desktops and GUI oriented art programs. I want to be able to use APAC and GR. 9, etc. modes to have cool wallpaper.

Your saying that gr. 8 mode is faster for graphic routines than say Antic E or Gr. 9 would be?!? Isn't it generally the lower the res, the faster it can display?

Edited September 8, 2011 by Gunstar

[simonl]

If you're a Classic Mac coder, I hope to give you an API you can be creative with. I'm holding you to developing some apps, though!

 

Go on then, you talked me into it. I feel a version of Minesweeper or something coming on for a kick off. Have you decided how you're handling bitmap resources for apps, or will they get a canvas and wrangle that directly themselves? If you have resource formats and APIs for bitmaps and bitmap drawing, best to make them capable of holding or referencing device parameters such as bit depths, aspect ratios and palettes for future proofing (otherwise you'll end up in the same mess as Apple when Macs went colour ) Bayer and Floyd Steinberg dither are pretty easy to implement for crunching colour/greyscale ones down to monochrome.

 

Regarding VBXE, Candle is also keen to see this happen, but it's a case of one step at a time. Once the API is documented, I might get him to code up a VBXE graphics library himself. There are certain things which will need to be done differently with VBXE, however, such as the "invisible" mouse pointer (rendered and erased in a blocking raster interrupt). I see no obvious way of accomplishing the exact same thing using the VBXE FX core.

 

Cool!

 

As long as it's all running on a 1200XL! Actually an SDX command window is something I have been thinking about, but I need to discuss the practicalities in detail with KMK. I'll bet it's going to be complex, although SDX has all we need to redirect screen input and output to a window.

 

Well, not strictly necessary for a first release if the desktop has basic Mac Finder style functionality, but a "nice to have" for the future. Is anyone looking into making a CC65 lib for it? That would probably make app development a lot easier for non time critical stuff.

 

Cheers,

 

Simon

 

(Edit: Me fail English? That's unpossible!)

Edited September 8, 2011 by simonl

[danwinslow]

I'm planning on doing CC65 support for the API.

 

If you're a Classic Mac coder, I hope to give you an API you can be creative with. I'm holding you to developing some apps, though!

 

Go on then, you talked me into it. I feel a version of Minesweeper or something coming on for a kick off. Have you decided how you're handling bitmap resources for apps, or will they get a canvas and wrangle that directly themselves? If you have resource formats and APIs for bitmaps and bitmap drawing, best to make them capable of holding or referencing device parameters such as bit depths, aspect ratios and palettes for future proofing (otherwise you'll end up in the same mess as Apple when Macs went colour ) Bayer and Floyd Steinberg dither are pretty easy to implement for crunching colour/greyscale ones down to monochrome.

 

Regarding VBXE, Candle is also keen to see this happen, but it's a case of one step at a time. Once the API is documented, I might get him to code up a VBXE graphics library himself. There are certain things which will need to be done differently with VBXE, however, such as the "invisible" mouse pointer (rendered and erased in a blocking raster interrupt). I see no obvious way of accomplishing the exact same thing using the VBXE FX core.

 

Cool!

 

As long as it's all running on a 1200XL! Actually an SDX command window is something I have been thinking about, but I need to discuss the practicalities in detail with KMK. I'll bet it's going to be complex, although SDX has all we need to redirect screen input and output to a window.

 

Well, not strictly necessary for a first release if the desktop has basic Mac Finder style functionality, but a "nice to have" for the future. Is anyone looking into making a CC65 lib for it? That would probably make app development a lot easier for non time critical stuff.

 

Cheers,

 

Simon

 

(Edit: Me fail English? That's unpossible!)