New GUI for the Atari 8-bit

[AtariGeezer]

I missed the good news Jon, congratulations on the new job. Great news

 

Same here, it's about frick'n time (jk)

Well they say that "good things come for those who wait" and I think you've waited long enough

 

Congrats to you and your wife on the new journey :thumbsup:

[fibrewire]

Pretty awesome Jon! Also does your NDA allow you to nod once for using Asterisk as the core of your company or nod twice if its something else?

[flashjazzcat]

*

[fibrewire]

Jon, any chance you could post an xex of the mouse acceleration demo?

[flashjazzcat]

Jon, any chance you could post an xex of the mouse acceleration demo?

 

gui.xex

 

This one should run under DOS (loads at $2000), but be aware it's a developmental version and the windows aren't re-implemented yet (File->New Window will cause a crash). The new (faster) menus work, though, and you'll see the mouse acceleration in action. This build is about half-way through re-implementing all the data structures in a manner similar to SymbOS, although zero progress has been made in that direction in the past six months or so... little hope of that changing in the immediate future.

[fibrewire]

This is amazing! Not only does it seem as fast as the Bob1200XL video, but it works under Altirra as 800XL 64K mode...

 

It also *nearly* works under Altirra as an Atari 800 52K mode!!!

 

Simply AMAZING!

 

I wonder if this gui could detect and run on an unmodified 48K 800 with the Axlon 128K card with your recent changes?

Edited July 27, 2013 by fibrewire

[a8isa1]

gui.xex

 

This one should run under DOS (loads at $2000), but be aware it's a developmental version and the windows aren't re-implemented yet (File->New Window will cause a crash). The new (faster) menus work, though, and you'll see the mouse acceleration in action. This build is about half-way through re-implementing all the data structures in a manner similar to SymbOS, although zero progress has been made in that direction in the past six months or so... little hope of that changing in the immediate future.

works quite well from Atari800 emulator (2.1.0). usage: atari800 -mouse st -mouseport 2 -mousespeed 9 gui.xex

 

I could try a real A8 but my SVIDEO cable needs repair (again).

 

Flashjazzcat, how does your GUI look with NTSC artifacting?

 

[EDIT]

It doesn't like my converted mouse, a Logitech Bus mouse. I can't remember if it's like an Atari trak-ball or an ST mouse.

 

-SteveS

Edited July 28, 2013 by a8isa1

[TheNameOfTheGame]

I wanted to try the gui demo, but then I realized I had no idea what mouse would work .

 

Are you guys using an Atari ST mouse?

[fibrewire]

On a real Atari, an ST mouse in joystick port 2

 

In Altirra, click on Input > Port 2 > Mouse > ST Mouse

[Faicuai]

WOW!

 

Just rushed to test this, like a little kid at the opening-doors of a toy-store... 8-)

 

I almost fell from my chair with the responsiveness and overall redraw-speed of the drop-down menus... I could barely believe what I was seeing, because it almost mirrored my initial impression with Atari ST GEM and Apple's Finder / OS, back in 1984-86 time-frame... but with 1979-1980 hardware (!)

 

If this performance can be maintained along the development (or re-development) cycle, then... I am already SALIVATING... 8-)

 

Tried it also on Incognito-800 and the whole package looks just as sleek as it does with my 800XLs... Boy, can't wait for this to get done (although it may not be anytime soon, obviously)...

 

THANKS!

[TheNameOfTheGame]

On a real Atari, an ST mouse in joystick port 2

 

In Altirra, click on Input > Port 2 > Mouse > ST Mouse

 

Thanks, I am using actual hardware. I must say that is one impressive demo!! Good work flashjazzcat!!

[flashjazzcat]

This is amazing! Not only does it seem as fast as the Bob1200XL video, but it works under Altirra as 800XL 64K mode...

 

It also *nearly* works under Altirra as an Atari 800 52K mode!!!

 

Simply AMAZING!

 

I wonder if this gui could detect and run on an unmodified 48K 800 with the Axlon 128K card with your recent changes?

 

Thanks. The memory requirement of this build is significantly less than some of the others, but it still requires the RAM under the OS, since it isn't using the banking window yet.

 

Flashjazzcat, how does your GUI look with NTSC artifacting?

 

Not sure about that: not a fan of artifacting myself, but I should imagine it'll be colourful.

 

WOW!

 

Just rushed to test this, like a little kid at the opening-doors of a toy-store... 8-)

 

I almost fell from my chair with the responsiveness and overall redraw-speed of the drop-down menus... I could barely believe what I was seeing, because it almost mirrored my initial impression with Atari ST GEM and Apple's Finder / OS, back in 1984-86 time-frame... but with 1979-1980 hardware (!)

 

If this performance can be maintained along the development (or re-development) cycle, then... I am already SALIVATING... 8-)

 

Tried it also on Incognito-800 and the whole package looks just as sleek as it does with my 800XLs... Boy, can't wait for this to get done (although it may not be anytime soon, obviously)...

 

THANKS!

 

Thank you! You know, I'm constantly surprised by the appreciativeness shown to what are such tiny incremental developments, but make no mistake: it's encouraging too. I was pleasantly surprised as well by how much faster the menus rendered following the major re-write (inspired by studying SymbOS and talking to its author Prodatron). Basically, the right-threaded-binary-tree model (borrowed from GEM) was completely abandoned in favour of simpler, linear table structures. I figured if it's good enough for SymbOS (as well as the old Mac System software), it's good enough for a 6502 machine. The savings on stack management and recursion were considerable. Windows will be getting the same treatment (that's about 50 per cent done).

 

Thanks, I am using actual hardware. I must say that is one impressive demo!! Good work flashjazzcat!!

 

Many thanks.

 

I've been very much NOT "in the groove" lately for a variety of reasons, but just as everything finds a way of righting itself, I'm sure development will pick up on this project again soon. The whole scope of the thing is very much up in the air, though, as I consider the pros and cons of things like integral file system managers and SIO handlers. Not that I wish to leave DOS out in the cold, but there are tremendous advantages to actually writing a complete OS. Basically the GUI (or GOS) would boot from the cartridge and take over the whole machine. Using that approach, I'd probably need help with things like file system drivers for SDFS, etc. Of course it would be easier to run the thing on top of DOS (and SpartaDOS X is especially well-prepared in this respect), but once the system hands over control to a third-party SIO driver, the mouse will necessarily lock-up and the whole thing will become unresponsive during file operations. Contrast this with taking a hit on serial IO speed and having the mouse and background processes still running the whole time. Using modern PBI devices, you'd still get full-speed IO. Of course, one argument against this approach (and indeed the whole notion of a pre-emptively multi-tasking kernel) is the need to run legacy applications easily - and these cannot be multi-tasked, and would need to have a "familiar" FMS "environment". That said, Candle's CIO-based FAT loader showed what can be done to fool applications into loading from unfamiliar file systems, providing the CIO entry points are preserved.

 

Anyway: thanks everyone for your continued interest in this slow-moving but exciting project.

 

EDIT: Just noticed there's a bug if you click on the desktop (outside of an open menu). Need to remind myself how all this s**t works...

Edited July 28, 2013 by flashjazzcat

[Chilly Willy]

On a real Atari, an ST mouse in joystick port 2

 

In Altirra, click on Input > Port 2 > Mouse > ST Mouse

 

I use an Amiga Boing! mouse on my Atari. I've asked for an Amiga build a few times, and it's always worked like a charm. At some point the GUI is supposed to move to 128K machines. I just have my old A400 and a couple 65XEs, so I'll have to do something about that eventually.

[flashjazzcat]

At some point the GUI is supposed to move to 128K machines. I just have my old A400 and a couple 65XEs, so I'll have to do something about that eventually.

 

Yes - we'll move to using the extra RAM eventually, but owing to the GUI's revised internal architecture, it should be possible to at least run just the shell and maybe a couple of small (single-tasked) apps on a 64KB machine. I think this would be pretty good, since you could use the desktop as a launcher on a machine with no extra memory.

[flashjazzcat]

Just managed to get a new flat-record window to render on the screen, albeit with bits missing:

 

 

Non-client area seems to render really fast, but there's a bit of work to do to get these windows to react to the mouse. Some progress, at least...

[fibrewire]

Jon, it looks great! Keep up the great progress (when work and wife allows )

 

Of course it would be easier to run the thing on top of DOS (and SpartaDOS X is especially well-prepared in this respect), but once the system hands over control to a third-party SIO driver, the mouse will necessarily lock-up and the whole thing will become unresponsive during file operations.

 

I only know a little about Linux kernels, but couldn't someone with SpartaDOS knowledge modify the SIO driver with a hook for the GUI? Like if the SIO driver polls a flag and when set SIO hands over exclusive control to the GUI or something along those lines. I know a new OS would be optimal, but maybe some clever sockets or however one does it in assembly could be implemented that would allow a new OS to be swapped if/when the time comes.

Edited July 29, 2013 by fibrewire

[TheNameOfTheGame]

Just managed to get a new flat-record window to render on the screen, albeit with bits missing:

 

 

Non-client area seems to render really fast, but there's a bit of work to do to get these windows to react to the mouse. Some progress, at least...

 

Going good! Looks better than GEOS from that other 8-bit

[flashjazzcat]

I only know a little about Linux kernels, but couldn't someone with SpartaDOS knowledge modify the SIO driver with a hook for the GUI? Like if the SIO driver polls a flag and when set SIO hands over exclusive control to the GUI or something along those lines. I know a new OS would be optimal, but maybe some clever sockets or however one does it in assembly could be implemented that would allow a new OS to be swapped if/when the time comes.

 

That's a good idea, and something I should speak to Drac030 about. Basically it's SIO troubles which are the primary motivation behind considering a complete stand-alone OS, but if they can be resolved, the work could be cut in half. Obviously the GUI isn't tied to SDX, but I'd have no qualms about restricting multi-tasking functionality to a DOS with a soft-SIO driver. The file system process would work even if "blocking" (I/O requests simply getting exclusive use of the CPU and turning most of the interrupts off, before returning a "done" message to the caller), but the rub is that the mouse has to turn into a static icon during that time (since the polling of the mouse and rendering of the pointer are both fairly processor-heavy, using a VBI, long DLI, and short Pokey timer interrupt). Mouse responsiveness could surely be preserved if we could be sure that a) the baud rate was limited, b) I/O wasn't timing-critical to the point at which a sudden NMI trigger would knock things all to Hell, and c) the Pokey timer didn't get messed up. SDX's soft-SIO driver actually deactivates DLIs above a certain bitrate, so we'd need a GUI-friendly SIO routine with that DOS. Another precedent is that I experienced problems using a long VBI at higher SIO baud rates with The Last Word.

 

On the other hand, depending on your point of view, it wouldn't be a huge issue. However, one scenario I keep considering is having a file copy dialogue going (copying multiple files), and having the mouse responding jerkily and very briefly only during those short stages when we're not in the context of an SIO call. Imagine trying to hit that "Cancel" button during a multi-file delete under similar circumstances.

 

Going good! Looks better than GEOS from that other 8-bit

 

At least GEOS also has proportional fonts... unlike some Atari Corp. GUIs.

Edited July 29, 2013 by flashjazzcat

[fibrewire]

On the other hand, depending on your point of view, it wouldn't be a huge issue. However, one scenario I keep considering is having a file copy dialogue going (copying multiple files), and having the mouse responding jerkily and very briefly only during those short stages when we're not in the context of an SIO call. Imagine trying to hit that "Cancel" button during a multi-file delete under similar circumstances.

 

If it's any consolation, System 6 on a Mac Plus works fine accessing HDD over SCSI and acts slightly frustrating as described above when accessing floppies. If its not too difficult, I really like the idea of a GUI-friendly SIO routine

Edited July 29, 2013 by fibrewire

[TheNameOfTheGame]

gui.xex

 

This one should run under DOS (loads at $2000), but be aware it's a developmental version and the windows aren't re-implemented yet (File->New Window will cause a crash). The new (faster) menus work, though, and you'll see the mouse acceleration in action. This build is about half-way through re-implementing all the data structures in a manner similar to SymbOS, although zero progress has been made in that direction in the past six months or so... little hope of that changing in the immediate future.

 

Well with your new job (congratulations btw) have you thought about bringing in a programmer or 2 to help move this along? Maybe opensource or something along those lines.

 

Obviously you would direct the development to your vision, but maybe others could lend a helping hand.

[Chilly Willy]

Yes - we'll move to using the extra RAM eventually, but owing to the GUI's revised internal architecture, it should be possible to at least run just the shell and maybe a couple of small (single-tasked) apps on a 64KB machine. I think this would be pretty good, since you could use the desktop as a launcher on a machine with no extra memory.

 

That would be great! Use the desktop on 64K machines like a simple file manager.

[flashjazzcat]

...have you thought about bringing in a programmer or 2 to help move this along? Maybe opensource or something along those lines.

 

Obviously you would direct the development to your vision, but maybe others could lend a helping hand.

 

Largely depends on the scale of the operation. I've already had help from Popmilo, Andym00 and others with regard to the mouse driver, multi-tasking, etc, and if we did end up going for the full OS approach (if the custom SIO driver idea falls through), I'd probably have to farm out stuff like the file management system, serial driver, etc. Obviously I've already long-since been relieved of any graphic design labours, thanks to MrFish, and that in itself was a major help - not least because a lofty aesthetic is thereby assured. Once the core code is mapped out on a cartridge, maybe folks might be interested in writing custom UI controls, etc. Really, getting third-party help would be partly dependent on detailed API documentation, which we don't have yet.

[popmilo]

...Once the core code is mapped out on a cartridge, maybe folks might be interested in writing custom UI controls, etc. Really, getting third-party help would be partly dependent on detailed API documentation, which we don't have yet.

I have a game idea sitting in my notebook, simple enough for hires graphics, and cool enough to really want to see it in a draggable window

 

Build that API, they will come

[potatohead]

On the other hand, depending on your point of view, it wouldn't be a huge issue. However, one scenario I keep considering is having a file copy dialogue going (copying multiple files), and having the mouse responding jerkily and very briefly only during those short stages when we're not in the context of an SIO call. Imagine trying to hit that "Cancel" button during a multi-file delete under similar circumstances.

 

 

 

At least GEOS also has proportional fonts... unlike some Atari Corp. GUIs.

 

That is what the ESC key is for. Seriously. I suppose the optimal workflow would be to prompt the user on the copy or move operation with a dialog that says, "press ESC to abort the operation" and the little OK and cancel buttons there for them to decide on doing it or not. Once started, cancel goes away, nobody cares about the mouse much and the user has a nice out if they need it.

 

On ESC, complete the file operation, or roll it back, whichever is closest, throw up another dialog that reports what did happen, and give them an "OK" to dispense with it after having seen what they need to.

[flashjazzcat]

That is what the ESC key is for. Seriously. I suppose the optimal workflow would be to prompt the user on the copy or move operation with a dialog that says, "press ESC to abort the operation" and the little OK and cancel buttons there for them to decide on doing it or not. Once started, cancel goes away, nobody cares about the mouse much and the user has a nice out if they need it.

 

On ESC, complete the file operation, or roll it back, whichever is closest, throw up another dialog that reports what did happen, and give them an "OK" to dispense with it after having seen what they need to.

 

Makes good sense. I discussed these issues with Candle last night and I think I might be making too much of them. Don't forget the dialogues are by their very nature operable with the keyboard (or they will be, at least), so pressing Esc to action the Cancel button is perfectly intuitive. What I want to avoid is the situation of the mouse driver hedging its bets on IO being parallel and leaving the pointer on the screen, only for the IO to be serial, resulting in the mouse flickering all over the place. Hard-limiting SIO to a standard baud-rate might work (and this is possible in SDX, for example), but it's a somewhat imprecise approach. So maybe the original approach of iconifying the mouse pointer in a fixed position on the screen for the duration of a CIO call might be the best way to proceed after all.