New GUI for the Atari 8-bit

[+JAC!]

Relocating the ZP location will probably now work, but having fixed positions for them and letting the task specify how many of them it actually needs (and have to be copied) can of course speed up the copy process.

[Prodatron]

Relocating the ZP location will probably now work, but having fixed positions for them and letting the task specify how many of them it actually needs (and have to be copied) can of course speed up the copy process.

Now or Not?

[flashjazzcat]

Relocating the ZP location will probably now work, but having fixed positions for them and letting the task specify how many of them it actually needs (and have to be copied) can of course speed up the copy process.

That's a nice compromise which can be used during testing, at least until the relocating loader is written.

[+JAC!]

>Now or Not?

Here: "not" - my default spelling mistake when writing quickly. Unfortunately there's no default for what I actually meant in a given context

[flashjazzcat]

Yes, you are right! I already guessed that the A8GUI desktop process would be something like this. In SymbOS it doesn't have any file browser features itself, it just reacts on clicked icons, startmenu and taskbar entries and does some more things like managing the taskbar display etc., everything else is pure UI stuff. SymbOS 3.0 will get an optional module ("active desktop") with some more advanced desktop functionalities (like widgets, enhanced start menu etc.). This will be an own process as well

Anything which minimizes the number of required processes on the 6502 will be a good thing, but I did think about the "stripped down" nature of the SymbOS desktop when you wrote that it runs in the same process as the UI. SymCommander (an application), of course, does the heavy lifting when it comes to file management. But the "active desktop" sounds really exciting, and something I've really wanted to see in SymbOS for a while.

 

The SymbOS file manager consists of three layers:

- low level mass storage access: this is for initializing a device and reading/writing sectors

- mid level file system access: this is for handling a special file system (currently FAT12+16+32 and CP/M+Amsdos)

- high level: provides all features for the applications

 

So you are speaking about what I call in SymbOS the mid level.

Here we have the following functionalities:

- allocate and deallocate clusters (always as a chain)

- get part of the cluster number chain starting from a special cluster number

- search for a file inside a directory and load infos

- create new file (or directory) inside a directory

- modify file (or directory) properties

- remove file (or directory) from a directory (after its cluster have already been deallocated)

- initialize new created directory

- get free number of clusters of the device/partition

So this is mostly abstracting the cluster and directory handling and works for FAT as well as for Amsdos and CP/M, which have completely different directory structures and methodes of cluster allocation. The high level routines use the mid level routines for this file system specific stuff. Both the high and the mid level routines use the low level ones for loading/writing sector data.

The file system layer in SymbOS is designed like an internal driver structure, where each driver could be replaced by another one for another file system. Unfortunately there is currently no possibility for additional/alternative drivers because of memory and banking limitations.

Thank you for yet more excellent insights!

[+MrFish]

Yes, you are right! I already guessed that the A8GUI desktop process would be something like this. In SymbOS it doesn't have any file browser features itself, it just reacts on clicked icons, startmenu and taskbar entries and does some more things like managing the taskbar display etc., everything else is pure UI stuff. SymbOS 3.0 will get an optional module ("active desktop") with some more advanced desktop functionalities (like widgets, enhanced start menu etc.). This will be an own process as well

 

The SymbOS file manager consists of three layers:

- low level mass storage access: this is for initializing a device and reading/writing sectors

- mid level file system access: this is for handling a special file system (currently FAT12+16+32 and CP/M+Amsdos)

- high level: provides all features for the applications

 

So you are speaking about what I call in SymbOS the mid level.

Here we have the following functionalities:

- allocate and deallocate clusters (always as a chain)

- get part of the cluster number chain starting from a special cluster number

- search for a file inside a directory and load infos

- create new file (or directory) inside a directory

- modify file (or directory) properties

- remove file (or directory) from a directory (after its cluster have already been deallocated)

- initialize new created directory

- get free number of clusters of the device/partition

So this is mostly abstracting the cluster and directory handling and works for FAT as well as for Amsdos and CP/M, which have completely different directory structures and methodes of cluster allocation. The high level routines use the mid level routines for this file system specific stuff. Both the high and the mid level routines use the low level ones for loading/writing sector data.

The file system layer in SymbOS is designed like an internal driver structure, where each driver could be replaced by another one for another file system. Unfortunately there is currently no possibility for additional/alternative drivers because of memory and banking limitations.

 

I wonder how this should work: On startup of a process all its zeropage references have to be relocated, if you provide such a dynamic usage of it. If the process is swapped out and in again, you have to relocate these references again, as now it could be another part of the zeropage. Does that make sense?

 

CU,

Prodatron

 

Anything which minimizes the number of required processes on the 6502 will be a good thing, but I did think about the "stripped down" nature of the SymbOS desktop when you wrote that it runs in the same process as the UI. SymCommander (an application), of course, does the heavy lifting when it comes to file management. But the "active desktop" sounds really exciting, and something I've really wanted to see in SymbOS for a while.

 

 

Thank you for yet more excellent insights!

 

Yes, thank you again for you're insights. I know allowing Jon to pear into the inner workings of SymbOS is making his journey a lot less bumpy, opening up more options at important development junctures.

 

I'd like to return the favor, if you're interested. Jon recently pointed out that you're working on beefing up the available fonts for SymbOS. I'd be willing to lend some of my knowledge and storehouse of bitmapped fonts. PM me if you'd like to discuss.

[576XE]

What's about...

 

What do you thing about LCARS interface for ATARI.

 

Atari has some kind of touch tablet interface, great movie capabilities.

LCARS needs not mouse, icons etc.

 

[Prodatron]

 

I'd like to return the favor, if you're interested. Jon recently pointed out that you're working on beefing up the available fonts for SymbOS. I'd be willing to lend some of my knowledge and storehouse of bitmapped fonts. PM me if you'd like to discuss.

Wow, thanks for this great offer! I will contact you soon!

[flashjazzcat]

Prodatron: do you implement any kind of spinlock or similar when an application is modifying menu resources or window contents in the Transfer Area? I was just thinking that since there are no kernel calls which specifically deal with adding or amending menu items, for example, you could end up in a situation where the menu was opened while its structure was invalid (while an application is changing one of the items, assuming it was pre-empted by the IRQ).

 

Anyway I'm mid-way through rewriting the desktop application and the UI manager to work with the kernel; unfortunately both tasks must be completed before the kernel can even be tested.

[Prodatron]

Prodatron: do you implement any kind of spinlock or similar when an application is modifying menu resources or window contents in the Transfer Area? I was just thinking that since there are no kernel calls which specifically deal with adding or amending menu items, for example, you could end up in a situation where the menu was opened while its structure was invalid (while an application is changing one of the items, assuming it was pre-empted by the IRQ).

No, there isn't any locking mechanism yet for these situations.

Usually a window is not updated while an application does changes inside the data, as only the application itself tells the Desktop Manager when to update it.

It may happen, that the user acts on the desktop and causes a redraw as well. But TBH I never had exactly this situation yet, that some corrupt data have been displayed because of such a reason.

Maybe it's necessary to have a look at this in the future, when there are applications with more complex and frequent rearrangement of the window content. As it's currently not a problem at all, I guess it's the application which then should take care about that. E.g. it should first set the number of controls to 1 or so, rearrange the window content and then set the number of controls back to its real value. So if there is a screen update inbetween, you will just see a blank form.

Edited July 12, 2014 by Prodatron

[flashjazzcat]

Yeah - clearly there'll be little scope for problems if applications don't do complex re-arrangement of window content. Manipulating the item count in the control record would probably work well for dialog boxes and such. It was mainly the menus which concerned me, although again in SymbOS once the menus are defined, they probably don't change much in current applications. With the A8 GUI, we have the additional matter of one application's menu bar being replaced by another when it is brought to the front. The application will be unaware of this (except to know that it lost or gained the focus), and rather than caching bitmaps I think it should be fast enough simply to re-render the menu bar each time. When a menu is first defined, certain tabulation offsets need to be calculated. I was considering doing away with the "definition" stage and simply calculating these formatting values the first time a given menu is opened, and then setting a flag to say the calculations are done. Any process which wanted to re-define the menu structure could perhaps set the flag on the menu bar to yet a third state (invalid), ensuring nonsense wouldn't be displayed if the user tried to open the menu while extensive changes were being made. This would also invalidate all the tabulation offsets. But as you say: in real-life, I imagine problems would be few and far between.

[danwinslow]

I think for sanity's sake you should implement some kind of coarse-grained spinlock system. As an alternative, implement some way to temporarily turn off the pre-emption, like a non-interruptable code segment, for instance while system is updating screen structures, etc. I've done a lot of work with pre-emptive multitasking, and my attempts to say "ah, it probably won't happen much" have all been miserable failures, usually way down the road when people have actually started using my code. It might not apply to your effort here, but I suspect it would.

[flashjazzcat]

Well, I'll certainly implement something before applications start making contextual changes to the menus. You're right in saying every base needs to be covered, especially when (as here) so much code has to be written before the thing can even be tested. SEI/CLI around a short section of critical application code would work just fine, although I'm uncomfortable about endorsing direct manipulation of the I flag at app level. Even the kernel doesn't manipulate the interrupt disable flag much, since the supervisor calls are software interrupts anyway, so everything's automatically atomic. But there's a flag which disables pre-emption (which - again - applications don't touch), and either this or a spinlock will be used by stuff like the memory allocator, so that interrupt latency can be minimised (by clearing the I flag) while more time-consuming kernel operations are performed. So yeah - it definitely applies to what we're doing here.

 

Since the UI process is the only process (other than the application itself) which requires access to a process's menu tree, the simple tri-state variable should work. If the user tries to pull down a menu while the application was mid-way through changing it (and was pre-empted, having first invalidated the menu), the UI can just yield and try again during its next quantum.

 

At least, using the chosen architecture, I'm not having to worry about re-entrancy and other nasties.

[danwinslow]

SEI/CLI around a short section of critical application code would work just fine, although I'm uncomfortable about endorsing direct manipulation of the I flag at app level.

 

At least, using the chosen architecture, I'm not having to worry about re-entrancy and other nasties.

Well, I'd probably provide an API call that wraps whatever mechanism is used so the apps don't really need to know. An app that starts messing around with interrupts is going to be problematic for a number of reasons, so the bets are off at that point.

 

Not totally sure what it is about the architecture that would prevent re-entrancy issues, but I'm sure you have that handled. If you are actually using preemptive task switching seems like some kind of re-entrancy might arise but maybe not.

[flashjazzcat]

Well, I'd probably provide an API call that wraps whatever mechanism is used so the apps don't really need to know.

Makes sense. Either way, if an application can open and end its own critical section, the onus is on that app to close it in a timely manner. I quite like the idea of simply putting a spinlock on the invalid data.

 

Not totally sure what it is about the architecture that would prevent re-entrancy issues, but I'm sure you have that handled. If you are actually using preemptive task switching seems like some kind of re-entrancy might arise but maybe not.

Because everything is IPC based, and supervisor calls (since they're interrupts) can't be pre-empted. So only one process can be in the kernel context at any one time, and everything else is just message passing. SymbOS's kernel calling mechanism is a bit different, but Prodatron said that the need for re-entrant code was rare. I've identified a couple of frequently used routines (such as inter-bank jumps) which could be made re-entrant, but for now they're non-pre-emptable and that will work.

Edited July 13, 2014 by flashjazzcat

[pixelmischief]

I am sure that I must be thinking about the problem at far too high a level or with far too little understanding of how constrained processor and memory resources are in the execution context, but...

 

Isn't the UI responsible for managing menu contents, state, and display? If so, wouldn't the UI realize that the menu was being displayed at the time a request for its alteration was received? Could it then add the menu change request to a queue, executing menu state change operations in order?

[flashjazzcat]

Following SymbOS's example (which I am), the UI manager does not have any calls pertaining to the addition, removal, and changing of menu contents. The menu records are stored in the application's data area, so if an application wants to change the menus, it may either point the UI to a new menu structure, or amend what's already there. Way back when (before Prodatron mercifully started offering advice), I had the entire UI stored as a right-threaded binary tree, and menus were built iteratively and their structure and data stored in the heap. Therefore we (would have) had calls to add, remove and change items. Storing things as flat records in the application has many advantages, though: it's simpler, saves memory (since the menu is defined "in situ"), and means heap allocation is required less often.

 

The first thing I noticed a couple of years back when I started rewriting things in alignment with SymbOS's API was how the memory requirements were immediately slashed. A small application, its menus, windows, and dialogs can easily be stored in a 16KB bank, with no additional memory allocation overhead.

 

Doubtless things would have worked quite well using the slightly more high-level approach (which was very GEM-like), but they would have been slower and more RAM-hungry. All changes so far made which were inspired by SymbOS have dramatically improved performance. Once again, I'd refer any interested readers to the SymbOS developer docs.

[pixelmischief]

So, maybe Mac style then? The displayed menu is a combination of system level menus and application level menus, each controlled completely by the owner? This would mean that the system would have to have some kind of plugin architecture for compositing system menus with application menus and every application would be required to have conformant menu management facilities. But it sounds like, given the three competing interests, this results in the best user experience for an acceptable burden in the other factors.

[flashjazzcat]

Well, we're using the Mac style, or an approximation thereof. Having the leftmost menu as the "system" menu and then just replacing the rest depending on which application has the focus ought to work OK. But it'll require some thought, no doubt, since it's one area in which this system differs completely from SymbOS (which uses a Windows-like menu structure).

[AtariNerd]

You may have covered this, but if so, I've long-forgotten, but what is the target hard-ware for this, if any? Or is it a custom RAM/ROM-cart config?

[flashjazzcat]

No wonder people forget: long thread, and I need to update the website. Looking at 130XE minimum configuration (it might end up running on an 800XL, but you'll have no multi-tasking, no space for large applications, and all kinds of other limitations) and a bank-switched 128KB ROM cartridge (or Ultimate 1MB, which has 64KB of GUI ROM space reserved). I have a ROM/RAM cart here but the banking scheme is naturally completely incompatible with the normal extended memory model, so using that is a distant prospect.

Edited July 13, 2014 by flashjazzcat

[flashjazzcat]

Right: individual menus now get formatted the first time they open or after any changes are made, so that's done away with the "walker" which previously iterated through the entire menu tree adjusting the sizes and offsets before first use. There's also a flag on each menu that the application can set to temporarily invalidate the data, and the menu can't be opened until the bit is cleared. Now: back to what I was doing before.

[flashjazzcat]

Thought it wise to test this first using the old GUI build:

 

 

The border changes colour when the menu formatter is running (for the purpose of illustration). The formatter calculates the size of the menu container based on the longest item, tabulates the shortcuts, etc. Funnily enough the menus are barely any slower to open first time, when the formatter is invoked, but there it is: it simplifies things yet further and got rid of a bit of code.

 

Regarding the "System" menu and applications owning their own menu structures: the solution is fairly simple. The menu bar will be divided into three sections; indeed, there will effectively be three menu bars, laid end-to-end. The desktop manager will own the "System" menu (the "Fuji symbol" menu) and the "tray" menu on the right (containing the clock, task swapper, etc). Applications (including the file explorer) own the app menu which is situated between these two, and this is what gets swapped in and out when different applications get the focus.

Edited July 14, 2014 by flashjazzcat

[+MrFish]

Thought it wise to test this first using the old GUI build:

 

 

Did you by any chance have "Frame-Blending" on when you recorded the video? Frame-Blending always gives some odd side-effects when it's not needed, especially when recording to a video.

[flashjazzcat]

 

Did you by any chance have "Frame-Blending" on when you recorded the video? Frame-Blending always gives some odd side-effects when it's not needed, especially when recording to a video.

 

Yeah I did. Just turned it off now.