New GUI for the Atari 8-bit

[apt]

Does this only run from a cart then?

[flashjazzcat]

5 minutes ago, apt said:

Does this only run from a cart then?

Currently yes; there's an awful lot of bank-switching involved and using a banked cartridge for code allows unimpeded access to all the RAM. You can run the AtariMax demo from a SIDE3, AVG, etc.

 

[flashjazzcat]

20 minutes ago, ivop said:

I'd love to see this semi-finished (it's never really finished ), even though I think windowing on a 320x200 (and even 640x400 on the ST) display is clumsy, but a single app full-screen with all sorts of widgets (buttons, list boxes, tree view?) would be very cool!!

The coordinate system is signed 16-bit, so one could conceivably write a VBXE display driver for it. While I know what you mean about the cramped screen, a rectangle-based windowing system was just too cool not to implement, even if everything ends up being run full-screen 99 per cent of the time.

24 minutes ago, ivop said:

I'd really love if you at some point release your textual UI library, the one you use for UFlash.

Someone asked me about this years ago and I feel pretty bad about not getting around to it yet. It does need some cleaning up and it's complex enough to require decent documentation. So many projects, as you say. I must get around to it, though, since having the UI of one's application basically pre-written saves an enormous amount of time when starting a new project.

[+MrFish]

46 minutes ago, flashjazzcat said:

I started to understand a long time ago that this project is so huge that providing any kind of estimated completion date was an exercise in futility. Then in 2015 or so, I realised the spare 'GUI' slot on the U1MB needed to be made bootable, so I wrote new firmware for the Ultimate, Incognito, SIDE, etc. And thus my time was accounted for for the next five years.

 

In any case: I've started to become interested in this project again, primarily because I have just overcome one of the biggest obstacles (the file system drivers) by means of the FAT drivers I have just written for the SIDE3 loader. If I can manage a coding stint like the one I am just about to finish but apply it to the GOS at some point, real progress can be made. As usual, though, it's a matter of balancing this kind of effort with work and other commitments.

For me, the time spent on preparation steps -- even though many parts may not have been directly related -- means a quality foundation.

 

33 minutes ago, ivop said:

I'd love to see this semi-finished (it's never really finished ), even though I think windowing on a 320x200 (and even 640x400 on the ST) display is clumsy, but a single app full-screen with all sorts of widgets (buttons, list boxes, tree view?) would be very cool!!

 

7 minutes ago, flashjazzcat said:

The coordinate system is signed 16-bit, so one could conceivably write a VBXE display driver for it. While I know what you mean about the cramped screen, a rectangle-based windowing system was just too cool not to implement, even if everything ends up being run full-screen 99 per cent of the time.

 

Resolution available has always been a big focus where the design is concerned. When comparing this to the ST GUI, for instance, much more breathing room is instantly available here by the use of proportional fonts -- compared with the ST's poor economy of using mono-spaced fonts. For instance, the regular weight, system font we're using -- which isn't the smallest one we have on tap -- is capable of approximately 72 characters per line. Similarly the size of icons has also been carefully selected to ensure that everything is scaled well for the space available, as well as the GUI controls themselves.

 

Windowing, yeah... it's not gonna feel like two 1080p or 4K screens hooked up to a modern PC, but you're also not going to attempt using it like one. The ST really feels clumsy because of the mono-spaced fonts; they eat up screen space all over the place; and really hamper the overall feel. Compare that with even something like a Macintosh Classic II, which is very usable, even with a smaller resolution screen than the ST's.

 

[ivop]

1 hour ago, flashjazzcat said:

The coordinate system is signed 16-bit, so one could conceivably write a VBXE display driver for it. While I know what you mean about the cramped screen, a rectangle-based windowing system was just too cool not to implement, even if everything ends up being run full-screen 99 per cent of the time.

Emphasize mine. I suppose that's the point of the most of the things we do around here. If it's cool, and you can spare the time, go for it!

 

1 hour ago, flashjazzcat said:

Someone asked me about this years ago and I feel pretty bad about not getting around to it yet. It does need some cleaning up and it's complex enough to require decent documentation. So many projects, as you say. I must get around to it, though, since having the UI of one's application basically pre-written saves an enormous amount of time when starting a new project.

Absolutely. A MIDI player with a proper file selector is so much better than what we have now. But time is scarce.

 

A SpartaDOS command line MIDI player could be useful, too. You could even batch play a whole directory without much difficulties. We'll see.

[flashjazzcat]

15 minutes ago, ivop said:

A SpartaDOS command line MIDI player could be useful, too. You could even batch play a whole directory without much difficulties.

I would really love to see some media players (in standard binary XEX format) which use normal CIO calls and the SDX subdirectory commands, since the DOS in the new SIDE3 loader allows read/write access to FAT volumes several GB in size. The UFLASH file selector works just fine with this; the application is fooled into thinking it was launched from some nebulous version of DOS 2.x with SpartaDOS subdirectory support (i.e using the exact same CIO API). If I can find the time to get that text mode UI released, I would love to see what people do with it, anyway.

Edited September 19, 2021 by flashjazzcat

[danwinslow]

I think one of the crucial steps would be an exposed API and an SDK with examples, so people can write apps and drivers. That way, you don't have to write it all. Put up the OS itself on github with an API (or at least the OS binaries and an API), and then sit back and be Lord Of The Pull Requests :). Y'know, like Linus.

[JamesD]

On 3/1/2021 at 4:14 PM, ClausB said:

Was that for the 6800 family? Can't do that in 6502 nor Z80.

Just an FYI, the 6803 & 6809 have A & B registers (accumulators) as well as an exclusive or, but sadly EOR doesn't work between A & B registers like the code shown.
You have to LDA val_A, EORA val_B, STA val_B, etc...
 

[bradc]

Just checking in and seeing how it's going?  Need any help?  

[mikro]

Hi,

 

I'm a passive observer of this project but every time U1MB gets updated, I check also GOS to see its current shape.

 

Out of curiosity, I have a question or two:

 

- is it true that the OS aims for real multi-tasking? (i.e. with all its applications actively running in background)

- wouldn't be easier (and maybe even not so harmful to the original idea) to have just one foreground app running and all the others "frozen" (similar as what iOS or Android do) ?

- or maybe make a compromise, from my brief reading through this thread it seems that four is the ideal amount of apps to handle so why not handle the four most recent apps as real-time and the others put "on hold" ?

 

Cheers and good luck with the project!

[+mytek]

5 years ago I introduced PS/2 mouse ports as standard on the 1088XEL and followed this up with the same on the 1088XLD, all with the hope that if more people had mice on their A8's that this project would have new life breathed into it.

 

Edit: and then Candle released the Side3

Edited July 31, 2022 by mytek

[TheNameOfTheGame]

Not to be a downer because I would love it to be released, but it's been 13 years...most likely not gonna happen :).

[Prodatron]

42 minutes ago, mikro said:

- is it true that the OS aims for real multi-tasking? (i.e. with all its applications actively running in background)

When you have a look at videos like this...

...it is quite obvious, that it is real (pre-emptive) multitasking.

 

42 minutes ago, mikro said:

- wouldn't be easier (and maybe even not so harmful to the original idea) to have just one foreground app running and all the others "frozen" (similar as what iOS or Android do) ?

I think that FJC already proved, that it is possible "even" on the 6502 without big issues, slowdowns and CPU-eating overheads. So it seems that there is no reason to do without real multitasking.

 

42 minutes ago, mikro said:

- or maybe make a compromise, from my brief reading through this thread it seems that four is the ideal amount of apps to handle so why not handle the four most recent apps as real-time and the others put "on hold" ?

A process can put itself into sleep mode (see the list in the profiler app in the video above). Such processes are already "on hold" and won't use any CPU time anyway. In practice most processes can go into sleep mode while waiting for a user event, so it is an exception, that multiple tasks are really working at the same time.

Maybe because of the zero page and/or the stack there is a limit for the maximum amount of running tasks on the 6502 (I don't remember anymore exactly how FJC solved this), but when you see the videos, it doesn't seem to be limited too much.

[ivop]

FJC's GUI looks incredibly cool, but I doubt its usage because of the low resolution. Even in 640x480 on the ST in monochrome you have so little screen real estate that you run every application full screen. No need for elaborate windowing mechanisms. Just a full screen widget set, like Android/iOS apps, would suffice, IMHO. Lists, buttons, ...

 

I'd rather see FJC spend time on releasing his TUI library

 

 

Edit: 3000th post

Edited July 31, 2022 by ivop

[+MrFish]

1 hour ago, TheNameOfTheGame said:

Not to be a downer because I would love it to be released, but it's been 13 years...most likely not gonna happen :).

Is 13 years some kind of magical cut-off point for finishing projects?

 

[+MrFish]

10 hours ago, ivop said:

FJC's GUI looks incredibly cool, but I doubt its usage because of the low resolution. Even in 640x480 on the ST in monochrome you have so little screen real estate that you run every application full screen.

The early Macs had 512 x 342. I used a Classic II (same resolution) for years, loved it, and completed all of my college work on it.

 

As I've said already, the big difference is proportional fonts. The ST didn't use them; it used mono-spaced fonts (for menus and icon/filenames), which kill screen real estate. It also used larger-sized icons than it should have. The Macs had proportional fonts everywhere, and used sizes that were proportional to the screen dimensions. Judge by the outcome, STs died, Macs still live today. Smart engineering is part of the difference -- and interface scaling figures into the equation.

 

Our proportional fonts and icons are scaled down from the original Macs. The Macs used 32 x 32 icons, and we're using 16 x 16. Half the size but less than half the screen size; so, do the Math. Font scaling is similar (I forget exactly at this point) but not quite as scaled down as the icon sizes. The result is something that should be at least as usable as the early Macs, which in my opinion were more than adequate for a great many applications, games, and accomplishing file management tasks. Will it be used in fullscreen a lot of the time? Sure, but this won't invalidate the windowing interface's usefulness.

 

[TheNameOfTheGame]

24 minutes ago, MrFish said:

Is 13 years some kind of magical cut-off point for finishing projects?

 

Like I said, I'll be very glad to see it happen.  It's been pretty much crickets for the last few years, but you never know! Hope springs eternal :).

[+MrFish]

17 minutes ago, TheNameOfTheGame said:

It's been pretty much crickets for the last few years, but you never know! Hope springs eternal :).

Not really. I think people fail to realize (in spite of various comments already posted by FJC) that FJC is working on this project via other projects which are seemingly unrelated. Long ago, FAT was chosen as the preferred file system; his current work with that file system (and firmware for the Ultimate 1MB as target hardware) is related to this project (foundational work). So, lack of specific updates to the system software (and related comments in this thread) might appear to indicate no progress; but this isn't the case.

 

[mikro]

43 minutes ago, ivop said:

FJC's GUI looks incredibly cool, but I doubt its usage because of the low resolution. Even in 640x480 on the ST in monochrome you have so little screen real estate that you run every application full screen. No need for elaborate windowing mechanisms. Just a full screen widget set, like Android/iOS apps, would suffice, IMHO. Lists, buttons, ...

As a person who spent the early 2000s coding on Falcon day and night in its 640x200x16c RGB resolution in MagiC (a multitasking OS running nicely even on ST) I can tell you this is not true. My usual setup was a text editor (yes, fullscreen), mp3 player, web browser/text viewer (with documentation) and the desktop where I would click on the compiler's executable. Usually I would switch between the docs and my code but for instance the mp3 player ran below the text window so I could see what's playing, switching to the next music, pause it when needed etc. Also, it was very handy to be able to click on the desktop, verify that my code still compiles and continue typing.

 

I'm not saying this use case couldn't be fixed with widgets and small icons somewhere, just wanted to point out that it wasn't that bad as you described.

[TheNameOfTheGame]

29 minutes ago, MrFish said:

Not really. I think people fail to realize (in spite of various comments already posted by FJC) that FJC is working on this project via other projects which are seemingly unrelated. Long ago, FAT was chosen as the preferred file system; his current work with that file system (and firmware for the Ultimate 1MB as target hardware) is related to this project (foundational work). So, lack of specific updates to the system software (and related comments in this thread) might appear to indicate no progress; but this isn't the case.

 

Understood.  I've read some of Jon's posts for his other work regarding how it could relate to this project.  That being said, that other work (which is quite valuable and useful to the community!) appears to be an on-going venture at this point.  Not surprising seeing as what he is attempting to accomplish (and has done) as a one-man band so to speak.

 

So, we'll see.  I am subscribed to this thread so that is a little indication of my interest in it :).

[Prodatron]

5 hours ago, ivop said:

FJC's GUI looks incredibly cool, but I doubt its usage because of the low resolution.

 

Mr.Fish already explained it very well, I think 320x200 is still great for a desktop computer GUI. We still have a monitor in front of us, not a mobile phone which has the size of a hand, so the size of the monitor is more important than the resolution.

 

The proportional font is one of the reasons why it will work great with lower resolutions.

The funny thing is that my MSX partner EdoZ prefers a resolution of 256x212, which is even lower than Atari8/Amstrad CPC:

 

...starting from 6:10.

And SymbOS icons are even 24x24 instead of the very nice 16x16 ones by Mr.Fish in A8GOS, so you will get a lot of stuff on your screen

Edited July 31, 2022 by Prodatron

[+MrFish]

1 hour ago, Prodatron said:

Mr.Fish already explained it very well, I think 320x200 is still great for a desktop computer GUI. We still have a monitor in front of us, not a mobile phone which has the size of a hand, so the size of the monitor is more important than the resolution.

 

The proportional font is one of the reasons why it will work great with lower resolutions.

The funny thing is that my MSX partner EdoZ prefers a resolution of 256x212, which is even lower than Atari8/Amstrad CPC:

 

...starting from 6:10.

And SymbOS icons are even 24x24 instead of the very nice 16x16 ones by Mr.Fish in A8GOS, so you will get a lot of stuff on your screen

Nice demo.

 

Looks like the SymbOS application pool continues to grow. I see there was an Email application added at the end of last year too. That would be very cool to use on older systems -- standard email messaging.

 

[flashjazzcat]

16 hours ago, TheNameOfTheGame said:

That being said, that other work (which is quite valuable and useful to the community!) appears to be an on-going venture at this point.  Not surprising seeing as what he is attempting to accomplish (and has done) as a one-man band so to speak.

The thing to remember about the 'other work' is that a) it generates part of my (albeit wildly variable) monthly income in the form of firmware licenses which will dry up if I don't maintain interest in the hardware by continually developing the firmware, and b) I'm heavily invested in producing firmware for Candle O'Sin's new products going forward, and would not necessarily want to dig my way out of that commitment even if I felt able to.

 

Someone overseas once floated the idea of paying me a wage to work full-time on the GOS project, but I didn't really take that proposition seriously. That said, it was in the days before crowdfunding existed.

 

It's already been mentioned, but spending much of the past year developing and testing FAT drivers (not to mention a complete CLI-based DOS) for the Atari means that I already have the file system driver for the GOS (although it will need to be made relocatable and turned into a 'file system manager' service).

Edited August 1, 2022 by flashjazzcat

[TheNameOfTheGame]

4 hours ago, flashjazzcat said:

The thing to remember about the 'other work' is that a) it generates part of my (albeit wildly variable) monthly income in the form of firmware licenses which will dry up if I don't maintain interest in the hardware by continually developing the firmware, and b) I'm heavily invested in producing firmware for Candle O'Sin's new products going forward, and would not necessarily want to dig my way out of that commitment even if I felt able to.

Yes, kinda what I was hinting at by my use of the term "on-going venture". ?

 

Not that anyone could fault you for prioritizing your income and general welfare by any means.

 

Quote

Someone overseas once floated the idea of paying me a wage to work full-time on the GOS project, but I didn't really take that proposition seriously. That said, it was in the days before crowdfunding existed.

 

It's already been mentioned, but spending much of the past year developing and testing FAT drivers (not to mention a complete CLI-based DOS) for the Atari means that I already have the file system driver for the GOS (although it will need to be made relocatable and turned into a 'file system manager' service).

That's why I said "we'll see" above.  Wasn't trying to be negative, but if GOS was ever going to get near the usability of something like SymbOS (maybe an unfair comparison, but you get my meaning) then it would take some singular and intense focus on the development process, which the "on-going venture" just doesn't seem to allow without the GOS side generating some income stream to replace or supplement the firmware dev.

 

So,  we'll see.  I do hope it happens mind you. ?

 

Take care, have a great day!  Thanks for all your work for the community btw.

Edited August 1, 2022 by TheNameOfTheGame

[flashjazzcat]

I don't mind this being compared to SymbOS, since SymbOS is the benchmark. It wasn't long after Prodatron took an interest in this project that the GOS became multi-tasking and the desktop manager was completely redesigned.

 

Read Prodatron's account of how SymbOS came about on his website if you haven't already done so. These things tend to be done in fits and starts over a long period of years, but I definitely envy the position he's in now (where it's bascially finished and subject to continued improvements).

 

Thanks for the kind comments!