New GUI for the Atari 8-bit

[flashjazzcat]

The object messaging system is great: I've been writing render code for various window controls tonight, and I don't have to care about explicitly calling it: it's the draw method of the class, and it just goes ahead and draws the control whenever its parents get drawn. It's really unusual programming this way when you're used to procedural stuff, but I like it.

 

Of course, I'm having my share of glitches:

 

 

The sizer control (now disabled) and a chunk of the horizontal scroll bar are mysteriously drawing themselves in odd places in the window - sometimes multiple times. I figure this is something to do with the recursive messaging routine, but at least we have a window on the screen. I'm pleasantly surprised by its instantaneous rendering, too.

Edited February 23, 2011 by flashjazzcat

[mellis]

 

I don't think a single garbage collection run through the list will take long at all (as opposed to the accrued overhead incurred by doing it hundreds of times), but the problem with the "every x calls" approach (which is a good idea, and one I considered) is that you might run into a situation whereby the application's request for 3KB fails, but would have been fulfilled after the next one or two calls to free (when the counter singals that it's time to clean up the heap). For that reason, I like the idea of leaving the cleanup call in the hands of the programmer. Only the application's logic can know when it's a good time to run cleanup (say, after releasing a couple of hundred blocks). It's just a question of coding it up (should be fun, but hopefully not too much work).

 

This is a good idea. You should allow the application to request a heap cleanup, as you propose. However, I would like to suggest that, in the event that a memory block request cannot be fulfilled, your memory manager should automatically run a garbage collection cycle in a last-ditch effort to satisfy the request before returning from "malloc". That way, you get the best of both worlds, and apps that don't properly request a GC cycle will function nevertheless.

[flashjazzcat]

This is a good idea. You should allow the application to request a heap cleanup, as you propose. However, I would like to suggest that, in the event that a memory block request cannot be fulfilled, your memory manager should automatically run a garbage collection cycle in a last-ditch effort to satisfy the request before returning from "malloc". That way, you get the best of both worlds, and apps that don't properly request a GC cycle will function nevertheless.

An excellent proposal. That would work well with the "every x call approach" too, although it makes sense to encourage coders to periodically call cleanup themselves. I haven't looked again at the memory manager code yet (not for some weeks, in fact); I hope I can still get my head around what I wrote sufficiently that I can amend it.

[flashjazzcat]

Window rendering is now working perfectly:

 

 

The rendering is very fast indeed (instantaneous), largely because most of the controls are drawn on byte boundaries. Because we can only clip by bytes horizontally (clipping with pixel granularity on the horizontal plane on an 8-bit is entirely impractical), all clipping windows are aligned on byte boundaries. As a consequence, when specifying the position of a window, x refers to the top corner byte of the window's non-client area immediately inside the border. This means the client area always lines up on byte boundaries (on both sides, since the width of the window is also expressed in bytes and the right hand scroll bar - excluding the right hand border - is exactly eight pixels wide).

 

All clipping controls (text boxes being another example) need their clipping region to line up on byte boundaries. A text input box will have a 1 pixel wide box border 1 pixel outside of the text entry area, so when specifying the position of such a control, you'll have to leave a 2 pixel space around its perimeter for the border. The GUI has a complex mixture of byte and pixel based horizontal coordinates, necessary because we need fine granularity with many controls and visual elements (for example, the menu panels' sizes and positions are precisely aligned to the proportional entries on the menu bar). Since we're working at the machine level, this isn't really a problem as regards performance, but it does tend to expand the code.

 

On the subject of clipping, I became somewhat sidetracked last night with the notion of a proper clipping system which filters down the tree during drawing operations and querying the mouse position. It's quite complex, but it's possible for the dispatcher to progressively pass byte-oriented clipping regions to child objects (I haven't even attempted to amend the event handler yet). The result of the experiment was that a window positioned partly off-screen rendered correctly. In theory, this would facilitate the nesting of controls and objects to an arbitary depth: one could, for example, place a clipping text box in a window's virtual client area and the text box would clip itself if it wasn't fully visible. This is the desired scenario, but implementing "true" clipping rectangles in this way comes at the cost of code complexity and a slight performance hit.

 

Now, on the subject of performance, if we regard a byte store operation as the lowest-level screen-write (which it essentially is here), it's completely impractical for all the GUI's drawing routines (lines, box fills, drop shadow boxes, invert region, etc) to call a subroutine which sorts out all the clipping every time they want to write a byte to the screen. Do this, and just watch the performance drop away... however, it's possible - if the drawing routine is passed XMIN, XMAX, YMIN and YMAX, to implement quite efficient in-line clipping with just a handful of extra instructions around STA (SCR),Y. Rendering routines tend to have an inner and outer loop: the outer loop works on lines, and the inner loop on columns. The routine first calls SET_UP_X, which calculates the starting and ending line positions of the drawing operation and calculates the horizontal left and right byte extents. The outer loop then calls GET_SCR, which creates a pointer to a given screen line; at this stage, we can perform vertical clipping on the line. The inner (horizontal) loop uses the Y register as an offset into the horizontal region; again - using a couple of comparisons - we can effectively clip both sides of the object.

 

This is what the experimental window draw routine does. Even the "standard" window routine clips the drop shadow border if any edge of the window is touching the sides of the screen.

 

It's certainly possible to implement a GUI without "full" clipping of this kind, but controls which need to be clipped inside of windows would then no longer be "self clipping". The application would need to manually set XMIN and XMAX according to the window size and the client area's origin. In addition, it would be impractical to drop list boxes and such like into the client area and expect all their components to be clipped properly.

 

So: that's one decision to be made. If I implement full parent clipping, I'll also need a flag to disable it, since the menu components (naturally) do not clip to their parents, and in any case, their pixel-resolution can't be clipped on bytes.

 

And all this - even before we get around to a virtual coordinate system for the windows.

 

In any case, it's all still surprisingly fast in operation. The only issue is code size. The "game technique" approach of lots of inlined code and lookup tables instead of bit-shifts does not lend itself to creating the super-compact 14KB GUI library I would have liked. If it gets too big, the only option is to put it on a banked cartridge, which I have no technical objection to. However, using cart-based code has a few important consequences:

 

1. The Shadow RAM is suddenly freed up (SpartaDOS 3.x compatibility!), but the application code space drops by 8KB. Space would then be so tight that the 8KB display RAM would need to go at $8000, and the display list below $4000...

2. Compatibility issues with SpartaDOS X with regard to legacy applications may arise. If the GUI is in the Shadow RAM, it will be run with SDX's "X" command, disabling the DOS cart library. The GUI is then free to use its own proprietary code to load application code under the cartridge space. However, if the GUI is on a cartridge, disabling the GUI cart (via code in low RAM) may or may not leave the SDX library ROM at $A000. If this is the case, the GUI would need to launch legacy apps which don't require the cart by getting DOS to perform the binary load via the X command. Complex: I need to speak to Drac030 and Trub about this ASAP.

3. Users require a flash cart to run the GUI on real hardware.

4. Users without internal SDX cannot easily run the GUI with SpartaDOS X.

5. MyIDE users without an internal HDD interface cannot run the GUI with SDX (using the new SDX MyIDE driver).

 

Of course, the upside of using a 128KB banked cartridge is that there's no real limit on code size, the GUI code will never be overwritten by a legacy app, and we can code up every last piece of functionality conceivably required so that all an application has to do is invoke a system library call. Multi-line text edit windows with different font sizes, etc - it can all be coded onto the cartridge, greatly simplifying application authoring.

 

At the moment, the demo code is compiling to 10KB. 2KB of that is lookup tables, and another 1KB or so various tables and arrays. 1KB is the demo "app", so that leaves 6KB of library code.

 

Some decisions need to be made...

[danwinslow]

Hmm. A lot of this seems to revolve around issues with an underlying DOS. Take SDX, for example. I'm unsure what I would get from the GUI if I'm running in SDX that I wouldn't have anyway. I'm sure that part of what you want to do is to be able to provide a CLI that allows the use of the native DOS in a window, but setting that aside for the moment, why would I really care what DOS I'm running the GUI on? As an app writer, I just need to use the standard device handlers...I mean you're in the same position here as any other app or game provider. When you go to fill up your window with the contents of the C drive, what are you going to do? Why, you'll start making a bunch of CIO and XIO calls, of course, which will work over most any dos. Other app writers will be in that exact position. ( by the way, I think the windowed disk browser functionality should be deferred to an app and not be part of the core GUI functionality. Provide the framework, not the apps. )

 

I expect you'll have incompatibilities with certain DOSs anyways, no matter how hard you try. It's also kind of odd to imagine a CLI with the bog standard Atari dos. Of course, it would be handy to have access to a CLI without having to reboot or terminate the GUI, but people could write their own CLI shells to accomplish a similar result. That puts the main onus on them to provide access to or replacements for the underlying DOS commands.

 

The options that come to mind are :

 

1. Specify a required dos to be bundled with the GUI and develop towards that. One benefit here is that it could potentially be a very small DOS.

2. Write your own minimal DOS functionality.

 

I would consider it a requirement that the dos chosen, if you go that way, provides basic HD support. By the way, you might want to look at RealDOS's memory footprint and functionality if you haven't already.

 

Of your options,

 

1. The Shadow RAM is suddenly freed up (SpartaDOS 3.x compatibility!), but the application code space drops by 8KB. Space would then be so tight that the 8KB display RAM would need to go at $8000, and the display list below $4000...

 

For me, this is a non-starter. The traditional killer for GUI's is the lack of applications, as we discussed early on. I think priority should be given to allowing room for functional applications to run, even over development fancier GUI features.

 

2. Compatibility issues with SpartaDOS X with regard to legacy applications may arise. If the GUI is in the Shadow RAM, it will be run with SDX's "X" command, disabling the DOS cart library. The GUI is then free to use its own proprietary code to load application code under the cartridge space. However, if the GUI is on a cartridge, disabling the GUI cart (via code in low RAM) may or may not leave the SDX library ROM at $A000. If this is the case, the GUI would need to launch legacy apps which don't require the cart by getting DOS to perform the binary load via the X command. Complex: I need to speak to Drac030 and Trub about this ASAP.

 

I don't completely understand the issues here, but as I said you'll likely be incompatible with a few dos's no matter what you do.

 

3. Users require a flash cart to run the GUI on real hardware.

 

Well...I dunno. At first I thought it would limit the GUI from wide use, but...there are a lot of advantages. I assume you could run over any disk-based DOS ( and I think some of the Sparta's and maybe even SDX can run from flash too, could you host *both* the GUI and SDX on a cart? )I mean, we buy things on carts anyways. You have a right to make some money after all this work, I don't expect people would begrudge you the cost of a flash cart plus a tad more. You could have 2 versions maybe - a free, bare bones no cart version and the fully featured cart version.

 

4. Users without internal SDX cannot easily run the GUI with SpartaDOS X.

 

Again, I don't know all the implications here, but if you mean 'users are required to have internal SDX to run the GUI' then I think its a non-starter. Could they still run without Sparta at all? Maybe you should pitch the requirement ( if it is one ) that you MUST be compatible with Sparta in all cases. ( Sacrilege! )

 

5. MyIDE users without an internal HDD interface cannot run the GUI with SDX (using the new SDX MyIDE driver).

 

Um...ok. Is that a large part of the userbase?

 

As you know, you are going to have to choose a set of limitations one way or the other. I kind of like the flash cart option, as it seems like it would be the most flexible and allow for more features, but of course it makes the GUI cost something to use. Again, my overriding recommendation would be for a workable GUI with features that allow the easy development of functional apps and the space in which to run them. I would prioritize that even over fancier features of the GUI itself, and certainly over compatibility with a particular DOS. People will amaze you if you give them room to work.

Edited February 25, 2011 by danwinslow

[Stormbringer]

Ditch dos... old and busted vs new hotness!!!

[+Philsan]

I think using a cartridge is the best solution.

It would be like having a computer with built-in OS and GUI.

Instant loading!

[flashjazzcat]

Hmm. A lot of this seems to revolve around issues with an underlying DOS. Take SDX, for example. I'm unsure what I would get from the GUI if I'm running in SDX that I wouldn't have anyway. I'm sure that part of what you want to do is to be able to provide a CLI that allows the use of the native DOS in a window, but setting that aside for the moment, why would I really care what DOS I'm running the GUI on? As an app writer, I just need to use the standard device handlers...I mean you're in the same position here as any other app or game provider. When you go to fill up your window with the contents of the C drive, what are you going to do? Why, you'll start making a bunch of CIO and XIO calls, of course, which will work over most any dos. Other app writers will be in that exact position. ( by the way, I think the windowed disk browser functionality should be deferred to an app and not be part of the core GUI functionality. Provide the framework, not the apps. )

A CLI isn't something I'm worrying about at the moment, but if I do implement it, it would make a lot of sense to interface it directly onto SDX's CP, which provides all the tools we need to execute DOS commands and redirect their output to the console. That's just one of the advantages of using SpartaDOS X. Many features of SpartaDOS will be plainly apparent to the GUI user - such as time/date stamped files, built-in real-time clock drivers, proper file attributes, volume stamps, hierarchical filing structure, etc. Sure, we get some or all of this stuff in Sparta 3.x/RealDOS, but they both occupy $C000-$FFF9, so they may be left out in the cold. Diamond's current issues with SDX are one of the reasons I stopped playing with it after half an hour: the GUI's not much fun with a flat filing system, and DOS 2.5's awful, painfully slow diasychain file links.

 

Sure: file copying, setting attributes, etc, just works through the CIO via the usual commands. But - like The Last Word - the system should be "aware" of more sophisticated filing systems, and configure itself accordingly when they are detected. Writing a system intended for use with various disk operating systems is a very different ball game to writing a game or an app like a sector copier. Many, many hours were spent ensuring LW worked properly with MyDOS, SpartaDOS X, BeweDOS, DOS 2.5... and older versions with Sparta 3.x and DOS-XE.

 

As regards the file brower being a separate entity: absolutely agree. It was always the plan to make the whole desktop manager an application like any other. I intend to write it, however.

 

It's also kind of odd to imagine a CLI with the bog standard Atari dos. Of course, it would be handy to have access to a CLI without having to reboot or terminate the GUI, but people could write their own CLI shells to accomplish a similar result. That puts the main onus on them to provide access to or replacements for the underlying DOS commands.

Re: my earlier comments about SDX, this seems a sensible way to proceed. We could have different CLI code for each DOS; in fact, it seems crazy to do it any other way. SDX's CLI would be minimal, because that DOS is so well designed, it's not difficult to completely redirect the input and output of the command processor. The CP is also relocatable. Sure, I'll have problems with every DOS, but not to play nicely with SDX seems to me a point-blank shot in my own foot.

 

The options that come to mind are :

 

1. Specify a required dos to be bundled with the GUI and develop towards that. One benefit here is that it could potentially be a very small DOS.

2. Write your own minimal DOS functionality.

 

I would consider it a requirement that the dos chosen, if you go that way, provides basic HD support. By the way, you might want to look at RealDOS's memory footprint and functionality if you haven't already.

1. If I were doing that, it would be SDX. So we'd better not go down that route.

 

2. Something I want to avoid... this thing's complicated enough.

 

 

Of your options,

 

1. The Shadow RAM is suddenly freed up (SpartaDOS 3.x compatibility!), but the application code space drops by 8KB. Space would then be so tight that the 8KB display RAM would need to go at $8000, and the display list below $4000...

 

For me, this is a non-starter. The traditional killer for GUI's is the lack of applications, as we discussed early on. I think priority should be given to allowing room for functional applications to run, even over development fancier GUI features.

 

Well, this rules out RealDOS as well as SpartaDOS 3.x (and DOS XE). I can live with that, but it's important to understand the ramifications of keeping $A000-$BFFF free for the screen display.

 

2. Compatibility issues with SpartaDOS X with regard to legacy applications may arise. If the GUI is in the Shadow RAM, it will be run with SDX's "X" command, disabling the DOS cart library. The GUI is then free to use its own proprietary code to load application code under the cartridge space. However, if the GUI is on a cartridge, disabling the GUI cart (via code in low RAM) may or may not leave the SDX library ROM at $A000. If this is the case, the GUI would need to launch legacy apps which don't require the cart by getting DOS to perform the binary load via the X command. Complex: I need to speak to Drac030 and Trub about this ASAP.

 

I don't completely understand the issues here, but as I said you'll likely be incompatible with a few dos's no matter what you do.

SDX runs off a cartridge, but provides a handler which allows the FS to function with the cartridge "switched off". This is how disk based applications which require the cart space work with SDX: you use the "X" command when running them. Now, there's also the "CAR" command, which is how you invoke your application cartridge (GUI, in this case). The uncertaintly revolves around the situation of wishing to run a legacy app which requires $A000-$BFFF from within the GUI on the cartridge, since we've already used a cart to run another cart... we're too levels deep in cartridge code, and we need that RAM back.

 

3. Users require a flash cart to run the GUI on real hardware.

 

Well...I dunno. At first I thought it would limit the GUI from wide use, but...there are a lot of advantages. I assume you could run over any disk-based DOS ( and I think some of the Sparta's and maybe even SDX can run from flash too, could you host *both* the GUI and SDX on a cart? )I mean, we buy things on carts anyways. You have a right to make some money after all this work, I don't expect people would begrudge you the cost of a flash cart plus a tad more. You could have 2 versions maybe - a free, bare bones no cart version and the fully featured cart version.

The cartridge solution is attractive to me, too, but for the thorny problem of it robbing us of 8KB of RAM we can ill afford (of course, we can make the Shadow RAM accessible to application code...).

 

4. Users without internal SDX cannot easily run the GUI with SpartaDOS X.

 

Again, I don't know all the implications here, but if you mean 'users are required to have internal SDX to run the GUI' then I think its a non-starter. Could they still run without Sparta at all? Maybe you should pitch the requirement ( if it is one ) that you MUST be compatible with Sparta in all cases. ( Sacrilege! )

At no point had I intended SDX to be a requirement (although I think not bending over backwards to support that DOS when it happens to be the DOS of choice would be utter lunacy). The scenario just refers to a user who wishes to use the GUI under SDX and can't because both products happen to be cartridge based. No problem if he has an original SDX cart with pass-thru, of course...

 

5. MyIDE users without an internal HDD interface cannot run the GUI with SDX (using the new SDX MyIDE driver).

 

Um...ok. Is that a large part of the userbase?

No, but it's part of the userbase of which I was the first member.

 

As you know, you are going to have to choose a set of limitations one way or the other. I kind of like the flash cart option, as it seems like it would be the most flexible and allow for more features, but of course it makes the GUI cost something to use. Again, my overriding recommendation would be for a workable GUI with features that allow the easy development of functional apps and the space in which to run them. I would prioritize that even over fancier features of the GUI itself, and certainly over compatibility with a particular DOS. People will amaze you if you give them room to work.

The cart option is attractive, and maybe we can offset the loss of RAM somehow by utilising the Shadow RAM for applications. After all, that would take us from 24KB of application space to 38KB, with the advantage of unlimited library code space on the cartridge.

 

The whole project - now that it has progressed well beyong a proof-of-concept into something that will hopefully provide application writers with a rich, versatile API with which they can create exciting, engaging GUI applications - will absolutely succeed or fail upon support or lack thereof from developers. The GUI - although it will ship with a file manager - won't stop you from writing one of your own to replace it. As a developer, I know (and am constantly attempting to visualize and predict) the kind of corners programmers can get backed into when RAM runs out or some built-in function is too inflexible or plain limiting. This is almost like designing a programming language, but with the additional and huge overhead of the machanics of the GUI added into the mix.

 

DOS compatibility is surely a troublesome consideration, but perhaps Drac030 will enlighten me to some gloriously simple solution with regard to SDX. Like I say - I've got the DOS compatibility T-shirt (and the "App using extended banks which doesn't corrupt MyDOS and DOS 2.5 RAMdisks" T-shirt, too). But if this thing didn't work with SDX for any reason, I'd really feel like we'd missed a trick.

 

I have no doubt that some astounding software will be forthcoming over the next few years if I can provide the VERY talented programmers we have here in our midst with adequate tools. I mentioned to Mr Fish the other day that I predict it will be a LOT of fun writing apps for the GUI. The fact so many coders are ostensibly keen to develop for the new system is very exciting, and a driving force in the continuation of the project.

Edited February 25, 2011 by flashjazzcat

[Mclaneinc]

The more I read about this the more stunning it gets..Brill work Flash old man...

[UNIXcoffee928]

Did anyone ever make a battery-backed, banked RAM module for the Atari? (RAM, not a flash-cart). That might do the trick, especially if it was at an address range that was totally safe. That way, you just load the GUI in once, and it stays there, ready to be accessed, for whenever you want to use it. It could also be like a resident RAM-disk... but, I don't know if anyone ever made something like that for the Atari.

[UNIXcoffee928]

Did anyone ever make a battery-backed, banked RAM module for the Atari? (RAM, not a flash-cart). That might do the trick, especially if it was at an address range that was totally safe. That way, you just load the GUI in once, and it stays there, ready to be accessed, for whenever you want to use it. It could also be like a resident RAM-disk... but, I don't know if anyone ever made something like that for the Atari.

I posted such a query in the RAM 320XL Thread, and it turns out that this is completely do-able, and that it is a much cheaper alternative than a flash cart.

 

The post is here.

 

Hope that helps!

[flashjazzcat]

Interesting notion. Drac030 replied to my email with a few helpful suggestions on running the GUI from both RAM and from a cartridge with SpartaDOS X. Basically, some lateral thinking is required in both scenarios.

 

As for the GUI itself, I'm coding up the drag events for the scroll bar handles and running into problems with the event handler always returning the desktop as the "hot" object. Doubtless that will take hours to rectify, if past experience is any guide... Methods for objects are stored as vector tables and looked up, since it's totally impractical (space-wise) to make individual objects store instances of the addresses of their draw, drag, click, double-click, get focus routines. If this approach persists in the finished system, it means custom controls will have to be "registered", and their methods set up as entries in the method table. It seems to make sense to do things this way, since the vast majority of the time, objects have generic event handlers (for example, dragging any icon usually involves the same code: drag a ghost of the image around until the mouse button is released, then return a drag event, a pointer to the ID of the object dragged, and the ID/address/coordinates of the object the icon was dropped on top of). However, if one wishes to create custom events for a built-in control (for example, a custom drag routine for a dialogue control), a means will need to be put in place to facilitate that. The event handler would use the custom event code if it exists, and if not it would fall back to the generic event code. Perhaps objects could have a pointer to a custom event table. If the pointer is null, no custom events are defined. Otherwise, the table pointed to would be an array of vectors to custom event routines.

Edited February 27, 2011 by flashjazzcat

[flashjazzcat]

Heh... it's always something simple. Messenger was propagating events to a control and all its children, so a drag over the desktop was executing the scroll handle's drag event code. I forgot to set the "depth" control. Easy when you know how.

[flashjazzcat]

We have proportional scrollbars:

 

 

I actually had to place a call to wait_jiffy inside the drag loop to make sure the mouse pointer has long enough to become visible after the scroll handle is redrawn. You'll eventually drag ghosted outlines of the handles and the handles proper will snap into place when the mouse button is released; it was just easier to drag the actual handle objects for the purposes of this demo.

 

The horizontal scroll bar is a bit buggy (notice how the handle widens when at the right hand end of the scroll bar), but the basic functionality is there.

 

My aims for the next downloadable demo remain the same: fully resizable and movable window (possibly two overlapping). This will allow folks to get a feel for the interface. There's lots of room for tweaking: the drag delay being a case in point (the mouse can travel a little too far before the drag event is registered). The actual overhead for drawing the scrollbars is tiny, and if the contents of the windows can be drawn quickly as well, things will be looking good. In operation, this feels rather like TOS on the ST.

Edited February 27, 2011 by flashjazzcat

[Kylev]

flashjazzcat,

 

I normally browse this forum from work where I do not have access to the demo videos. Watching the most recent one here from home, I must say you are a genius. Please keep at this until you have a finished product. I am very impressed with what I can see so far.

 

Russ

[JamesD]

Looks fast but the real test will be the refresh of what is in the window. But then you really don't control that.

[flashjazzcat]

I normally browse this forum from work where I do not have access to the demo videos. Watching the most recent one here from home, I must say you are a genius. Please keep at this until you have a finished product. I am very impressed with what I can see so far.

Thanks! You're very kind. It may take a very long time to finish this project, but rest assured I'm determined to see it through till the end.

 

Looks fast but the real test will be the refresh of what is in the window. But then you really don't control that.

It's hardly surprising that drawing the scroll bars is so fast, since the code which renders them is very slight. As for window contents, that's the true test as you rightly point out. As regards the level of control, there's really nothing to stop the event handler from redrawing the window contents in the case of the file browser (since the objects will receive MESSAGE.DRAW in just the same way that the window controls do), but in the case of a text editor or another application in which the window client redrawing is better handled by the application, of course it's largely down to the application writer as you suggest. It's important for that reason that the text rendering, clipping, blitting, and scrolling routines provided by the toolset are absolutely the most efficient possible. The best test of the interface will be the multi-line text box which - if it is sufficiently fast - will bode well for the viability of the system as a platform for useful applications.

Edited February 28, 2011 by flashjazzcat

[flashjazzcat]

The shape of things to come...

 

 

I just did an s-video mod on the 800XL and I couldn't resist. The scrollbars and menus seem even faster on a real machine for some reason... I believe it's largely to do with using a real mouse. I just can't wait to use this now, but there's a long way to go yet.

Edited March 3, 2011 by flashjazzcat

[spookt]

Stop taunting us damnit!

Edited March 3, 2011 by spookt

[+wood_jl]

The shape of things to come...

 

 

 

Wow! Please don't forget to make it work with Yankee Ataris!!!

[w1k]

excellent

[analmux]

...

...

One little question:

 

Look at f.e. function "Find Next" in the pulldown menu. There's no immediate fast-key for this. But, on PC we could do it by typing ALT "E N". Where's Atari's Alt-key in this case? Or should we change to SHIFT-CTRL instead?

[Rybags]

Shift-Ctrl only works with a subset of all possible keys.

 

Maybe something like Option-<key> would work.

[flashjazzcat]

Wow! Please don't forget to make it work with Yankee Ataris!!!

If anything, the GUI runs even more smoothly on NTSC machines (because of the more frequent VBLANK interval). Mouse sampling is fixed at 600Hz on both PAL and NTSC, however.

 

One little question:

 

Look at f.e. function "Find Next" in the pulldown menu. There's no immediate fast-key for this. But, on PC we could do it by typing ALT "E N". Where's Atari's Alt-key in this case? Or should we change to SHIFT-CTRL instead?

The shortcuts are just for decoration at the moment...

 

Shift-Ctrl only works with a subset of all possible keys.

 

Maybe something like Option-<key> would work.

...yes, a console key will probably activate the menu bar.

[+Stephen]

Looks amazing, as usual! In case you don't have enough to read through, I just ran across an article which contains the source code for MacPaint and QuickDraw.