New GUI for the Atari 8-bit

[Ransom]

And frankly, I find the prospect of doing things this way rather exciting.

 

That's wonderful! It's great that you can still have that feeling for the project after putting in so many hours on it.

[+DarkLord]

And frankly, I find the prospect of doing things this way rather exciting.

 

Heck, the prospect of you getting excited gets us all excited!

[popmilo]

And frankly, I find the prospect of doing things this way rather exciting.

You are getting us excited

Sounds like it will be great new year

[flashjazzcat]

Thanks guys - it's good to know people are still worked up about this, despite nothing but a drip-feed of vaguely related developments. But you know the score: after this length of time, the project could easily just turn into a massive chore, especially when there are unresolved problems in the way. Prodatron's email out of the blue was really inspirational, and was exactly the ingredient required to keep this project fresh.

[Prodatron]

Dialogue manager in the text mode GUI is just about done:

Wow, that's cool! Are these windows and widgets organized in the same way like in the graphic-mode GUI? So do you have the same data structures here?

 

I'm also now seriously considering having a crack at pre-emptive multitasking.

I would be really excited about seeing pre-emptive multitasking on the 6502! Has this every been realized in a practical/useable way before?

 

CU,

Prodatron

[Prodatron]

Prodatron's email out of the blue was really inspirational, and was exactly the ingredient required to keep this project fresh.

Thanx, glad to hear this! We inspired us both in a mutual way

[flashjazzcat]

Wow, that's cool! Are these windows and widgets organized in the same way like in the graphic-mode GUI? So do you have the same data structures here?

 

The dialogues and menus in the TUI use similar data structures to those I'm going to use in the GUI - i.e. when I revise them. Having most of the UI structures pre-coded in the application's data area is the way to proceed, as far as I can see.

 

I would be really excited about seeing pre-emptive multitasking on the 6502! Has this every been realized in a practical/useable way before?

 

Tebe showed a small example here, which uses a segmented stack. OS/A65 also uses a segmented stack when not running with a custom MMU. I think one could use an optimised mixture of segmentation and full caching.

 

What about Contiki? Does that use cooperative multitasking?

 

...here's another interesting Article relating to the Atari.

Edited December 4, 2012 by flashjazzcat

[Prodatron]

Thanx for the links, especially the two last ones are very interesting...

Yes, Contiki uses cooperative multitasking. Adam calls his tasks "protothreads", they all use the same stack, so maybe it's like the subroutine-methode we spoke about (each task is nothing else like a subroutine).

Edited December 4, 2012 by Prodatron

[flashjazzcat]

Adam calls his tasks "protothreads", they all use the same stack, so maybe it's like the subroutine-methode we spoke about (each task is nothing else like a subroutine).

 

Ah yes - protothreads. I'd forgotten this, although I read up on Contiki some months ago. The code reminded me of lots of little state machines, although I'm not sure that's a sensible assessment.

 

On the Atari, I think one task could be solely devoted to handling I/O calls, since on the A8, these must never be interrupted. It would be like a layer on top of the SIO, to which applications would pass messages.

 

Regarding multitasking, the only thing I haven't really thought through yet is how to ensure that tasks which are simply waiting for messages aren't allocated big chunks of CPU time. The scheduler needs to get out of those tasks quickly, perhaps if it sees an application polling its empty message queue.

[Prodatron]

On the Atari, I think one task could be solely devoted to handling I/O calls, since on the A8, these must never be interrupted. It would be like a layer on top of the SIO, to which applications would pass messages.

It's the same on the Amstrad CPC. All device I/O accesses are handled by only one task (the principle is the same like for the desktop manager task - only this task can draw gui-elements, windows etc.). For special I/O tasks the interrupts have to be disabled.

 

that tasks which are simply waiting for messages aren't allocated big chunks of CPU time. The scheduler needs to get out of those tasks quickly, perhaps if it sees an application polling its empty message queue.

That's not an issue. You can implement "idle" and "sleep" calls, which can be used by the tasks.

- "idle" means, that the task hands back the CPU time already before the scheduler-IRQ is fired. That may happen, if a task is looking for a new message, but recognized, that there isn't any at the moment. In this case the task consumes nearly no CPU time but is still active.

- "sleep" means, that the task is temporary removed completely from the task chain. It won't be called as long as there isn't any new message for it available. Only when a new message is available, it will be put back to the task chain. In this case the task (during "sleep") doesn't consume any CPU time at all, but it's also not active until it receives a new message, so it also can't react on anything else.

[flashjazzcat]

That's not an issue. You can implement "idle" and "sleep" calls, which can be used by the tasks.

 

Excellent - thanks for the explanation! See how much time we're saving here.

[atari8warez]

I would be really excited about seeing pre-emptive multitasking on the 6502! Has this every been realized in a practical/useable way before?

 

CU,

Prodatron

 

The short answer is no, one can always implement the code to show it can be done on a 8 bit Atari, but useability is a whole different ballgame on a 1.79Mhz machine... I know this is going be taken as a negative approach to the whole subject, but it is the truth nevertheless :-), to me multitasking on a 8 bit Atari is largely an academic discussion.

Edited December 4, 2012 by atari8warez

[Jacques]

Yes indeed, fingers crossed for good balance between GUI usability, author's ambition/satisfaction and... Sooner rather than later giving it to the users and programmers of future applications

[w1k]

hm, whats new with project? what is a priority, next level?

[Prodatron]

 

 

The short answer is no, one can always implement the code to show it can be done on a 8 bit Atari, but useability is a whole different ballgame on a 1.79Mhz machine... I know this is going be taken as a negative approach to the whole subject, but it is the truth nevertheless :-), to me multitasking on a 8 bit Atari is largely an academic discussion.

 

I dont know. I heard that a 1mhz 6502 is as fast as a 4mhz Z80. SymbOS runs great with pre- emptive multitasking on the 4mhz z80 based Amstrad CPC, so why shouldnt work preemptive multitasking on a faster 1,79mhz A8? The only reason would be, that the problem with the stack would slow it down a lot (this problem doesnt exist on the z80).

Edited December 4, 2012 by Prodatron

[flashjazzcat]

Firstly, let me react to Buzz Killington:

 

http://youtu.be/XFcqGGMPc3k

 

I dont know. I heard that a 1mhz 6502 is as fast as a 4mhz Z80. SymbOS runs great with pre- emptive multitasking on the 4mhz z80 based Amstrad CPC, so why shouldnt work preemptive multitasking on a faster 1,79mhz A8? The only reason would be, that the problem with the stack would slow it down a lot (this problem doesnt exist on the z80).

 

Another thing worth pointing out is the length of time GUI applications (indeed, many non-game or multimedia applications) spend waiting on events. By far the most labour intensive operatioins in the A8 GUI as it currently stands are the window redraws.

 

Intuitively, I doubt we'll be able to match SymbOS's simultaneous music / video playback / game demo mode, but that's not the objective here. Having recognized a clear need for background tasks which don't necessarily fall into the category of interrupt service routines (and this even on a system with only one foreground application), I already considered cooperative multitasking quite carefully, and that method has its own set of problems (not least the capacity for system-wide lock-ups and nightmarish application debugging). Imagine a clock, calculator, notepad and file browser open simultaneously. The clock is periodically updating its display; the notepad is flashing its cursor; and the other two applications are sitting idle. You start a search and replace in the notepad: it can go about its business without having to self-consciously call "yield" all the time, and if the application becomes unresponsive (i.e. its event queue starts overflowing with mouse clicks), you just shut it down. I don't see any of this as inherently impractical or unusable on this machine.

 

hm, whats new with project? what is a priority, next level?

 

Tasks:

 

1. Reimplement UI structures (smaller data, smaller code, easier memory management)

2. Code and test experimental multitasking kernel

3. Move to cartridge

Edited December 4, 2012 by flashjazzcat

[atari8warez]

I dont know. I heard that a 1mhz 6502 is as fast as a 4mhz Z80. SymbOS runs great with pre- emptive multitasking on the 4mhz z80 based Amstrad CPC, so why shouldnt work preemptive multitasking on a faster 1,79mhz A8? The only reason would be, that the problem with the stack would slow it down a lot (this problem doesnt exist on the z80).

 

Honestly, I don't know anything about Z80, so I can't comment on that comparison, however processor speed is only one of the variables in the scheme of things, there are many other issues to be resolved before a successful pre-emptive multitasking GUI is implemented on the Atari 8 bit. For example even though XE line having a EMMU unit is an advantage for memory management, having only about 40K main memory available for a single task makes this advantage look moot. Moving bytes in and out of main memory (for data and task switching, as well as swapping GUI code itself) would be a slow proposition when 6502 has lots to do in such an environment. Interrupt processing would have to be redesigned within the limitations of the hardware etc etc... I am not saying it couldn't be done if someone really puts his mind and effort into it, whether it will have any practical useability however is another question.

 

So for me the real question is whether showing that it's doable is enough satisfaction for the developer, or does the real satisfaction comes from seeing that it's actually used for a real purpose. The latter is true for me and it's only my opinion...

Edited December 4, 2012 by atari8warez

[flashjazzcat]

Honestly, I don't know anything about Z80, so I can't comment on that comparison, however processor speed is only one of the variables in the scheme of things, there are many other issues to be resolved before a successful pre-emptive multitasking GUI is implemented on the Atari 8 bit. For example even though XE line having a EMMU unit is an advantage for memory management, having only about 40K main memory available for a single task makes this advantage look moot. Moving bytes in and out of main memory (for data and task switching, as well as swapping GUI code itself) would be a slow proposition when 6502 has lots to do in such an environment. Interrupt processing would have to be redesigned within the limitations of the hardware etc etc... I am not saying it couldn't be done if someone really puts his mind and effort into it, whether it will have any practical useability however is another question.

 

Why would one want to copy bytes in and out of the banking window? Why not just run applications directly out of the banking space, and allow the code / data to span as many banks as they need to? And can you explain how the interrupt processing would have to be redesigned on the 6502 "within the limitations of the hardware"?

 

And who's this "someone" who's gonna put his mind and effort into it? The cat's mother? In any case, at least we now understand why there isn't a competing Atari8Warez GUI taking shape.

 

So for me the real question is whether showing that it's doable is enough satisfaction for the developer, or the real satisfaction comes from seeing that it's actually used for a real purpose.

 

We come back to this question repeatedly. How can it be answered? If the developer (whoever he is) is gonna get zero satisfaction unless the system is actually used, then he's setting himself up for a fall, because there ain't no-one can guarantee people are gonna use the A8 GUI, let alone develop applications for it. I have no crystal ball, no mind-control abilities. All the developer can do is create the most exciting, imaginitive, innovative system he can, and then let people use it.

 

My question is: where are you actually going with this line of questioning, and what do you hope to achieve by it?

Edited December 4, 2012 by flashjazzcat

[atari8warez]

Why would one want to copy bytes in and out of the banking window? Why not just run applications directly out of the banking space, and allow the code / data to span as many banks as they need to?

 

I don't think I said COPYing, moving in and out of memory in this context means bank switching and even though it's much faster than swapping to disk it still occupies CPU with it's associated overhead.

 

And can you explain how the interrupt processing would have to be redesigned on the 6502 "within the limitations of the hardware"?

 

I'll answer that with a question, how would you handle the use of DLI and VBI by more than one app in a multitasking environment?.

 

And who's this "someone" who's gonna put his mind and effort into it? The cat's mother?

 

In this instance that would be you FJC.

 

In any case, at least we now understand why there isn't a competing Atari8Warez GUI taking shape.

 

I am not sure what you understood, but if you ask me there is no competition in this case for me as I don't see a carrot dangling at the end of the stick

 

We come back to this question repeatedly. How can it be answered?

 

Probably by a through understanding of the requirements of a real preemptive multi-tasking GUI and the capabilities of the system at hand.

And where I am going by this... nowhere really, I was just replying to Prodatron but with your reply to Buzz Killington, you really encouraged me to the following:

Edited December 4, 2012 by atari8warez

[atari8warez]

Firstly, let me react to Buzz Killington:

 

http://youtu.be/XFcqGGMPc3k

 

 

 

Would this be an appropriate video response

 

http://www.youtube.com/watch?v=kw32fiasUSs&list=PLC4AFC65BBCE88534&index=4&feature=plpp_video

 

Sorry can't really help....

[LoTonah]

Ugh... what the hell...

 

Flashjazzcat, please pay no attention to this. You're doing awesome, groundbreaking work and some people just live to be negative.

 

Frankly I don't care if it is truly preemptive or not. The original Mac definitely wasn't! The closest it came was being able to run accessories like stickies and calculator at the same time as MacPaint (sort of like TSR programs in MS-DOS). Even if you made it cooperatively multitasking, you'd still have the Mac beat (at least until MultiFinder/Switcher came out).

[sack-c0s]

How is multitasking going to work out with the 6502 do you reckon?

 

I can see this being less of an issue with the Z80, as you can just repoint the stack freely, and it doesn't have the concept of zeropage but the only way I can see of context switching with a 6502 is to physically back up from $01ff down to the stack pointer, and the designated area of the zeropage, which is a bit of a ballsache if I'm honest.

 

I'm not ruling out the possibility that someone has thought up some nice clever trick to ease the problem though - and if they have I'd be interested to know

[flashjazzcat]

Ugh... what the hell...

 

Flashjazzcat, please pay no attention to this. You're doing awesome, groundbreaking work and some people just live to be negative.

 

Well, don't worry - insightful notes of caution are taken seriously and soberly (see below), but a running commentary from someone who isn't a 6502 coder, has previously called the project "crap", evidently thinks it's a waste of time, and yet still spends time posting is a mere inconvenience. I can only assume Prodatron's interest in and praise for this project was so frustrating to Buzz that he felt duty-bound to try and engage the esteemed visitor in a pseudo-technical discussion over my head in order to show the GUI project as the sham it really is. Once detailed CPU speed concerns ("1.79Mhz") were addressed, Buzz turned his attention to memory management and interrupt handling, showing tremendous insight by asserting that GUI applications will - instead of being entirely hardware abstracted - interact directly with the hardware by setting up their own DLIs and VBIs in contention with one another.

 

Frankly I don't care if it is truly preemptive or not. The original Mac definitely wasn't! The closest it came was being able to run accessories like stickies and calculator at the same time as MacPaint (sort of like TSR programs in MS-DOS). Even if you made it cooperatively multitasking, you'd still have the Mac beat (at least until MultiFinder/Switcher came out).

 

I remember saying - after some insirational exchanges with Prodatron - I'd "have a crack at pre-emptive multi-tasking". I think a single-tasking system would be very limiting, but the fact is that both cooperative and pre-emptive context switches have tricky overheads. At the end of the day, the most practical solution will be the one I use. But since I haven't actually implemented either approach yet, there's no way of knowing until I try.

 

How is multitasking going to work out with the 6502 do you reckon?

 

I can see this being less of an issue with the Z80, as you can just repoint the stack freely, and it doesn't have the concept of zeropage but the only way I can see of context switching with a 6502 is to physically back up from $01ff down to the stack pointer, and the designated area of the zeropage, which is a bit of a ballsache if I'm honest.

 

I'd say it's going to be tricky. Prodatron cites raw CPU grunt as a good "for" argument, but he's used to dealing with the Z80's movable stack and plentiful register set. As for the stack (and these ideas were also thrown around regarding cooperative tasking), you can segment it, or cache it. Caching will obviously take time. However, there's no need to cache the entire stack - merely the entries between the application's stack base and it's stack pointer. Most of the time, this won't be a lot of bytes - especially if communication between tasks is exclusively message-based (as it is with SymbOS). Also, in the I/O task, when it yields to the OS (with the potential for a deeper call stack), there'll be no context switches anyway, since I/O is a critical job.

 

If the stack's segmented, you face a hard limit of - say - four concurrent tasks. But you could work caching into the mix, too, so that you had 2 or 3 segmented stacks. Then you'd end up with a slow context switch every fourth task... really, some experiments are needed.

 

Regarding page zero, that's another pain. The window / desktop manager currently uses a lot of page zero, although I'm being careful to leave a reasonable number of locations free for applications. A fair number of the PZ locations are global pointers, which are vital for fast running of the font renderer. If we implement the window / desktop manager as a task, suddenly it's sharing the same PZ space with running applications, and I don't think there'll be a LOT of stuff to cache... we're certainly not talking about the entire upper half of page zero. Probably more like 40-50 bytes.

 

I'm not ruling out the possibility that someone has thought up some nice clever trick to ease the problem though - and if they have I'd be interested to know

 

Wouldn't we all.

 

Out of interest, how many cycles does it take to switch in a 16KB bank using a PORTB write?

Edited December 5, 2012 by flashjazzcat

[Prodatron]

Regarding the stack:

The task-scheduler should exactly know, how many bytes of the stack have been used by the task, as it knows the stack position before calling the task and when returning from the task. So only this amount of bytes need to be copied (saved) before switching to the next task.

- if you stay with cooperative multitasking, each task should try to return to the task-scheduler at a point, where (nearly) nothing of the stack is currently used (that would be probably in the "main loop"). This would make task switching damn fast, if the applications are optimized in this way.

- if you use pre-emptive multitasking, you don't know when the task is interrupted. So it will be slower, if it happens inside a sub-routine with heavy stack usage. But usually this is only, when a task is currently "working". Most tasks are usually "waiting", in this case it will happen again in the main loop, and the switch can be performed in a fast way, too.

Now the question is, if in pre-emptive mode you have to handle too often too large stacks...

 

Regarding the zero page:

Unfortunately I never coded on the 6502, so I really have no experience how much of the zero page you usually want to/have to use in your code. If I understood it correctly, the zero page is somehow a replacement for the many registers other CPUs (like the Z80) provide. On the Z80 we have 7x8bit (6 of them can be paired to 3x16bit) and 2x16bit registers (which can also be split into 4x8bit), with which you can work. So at all these are 11 bytes (I don't count the 2nd register set of the Z80, as in most OS it's occupied by the interrupt handler). So I wonder if 16 or at least 32bytes inside the zero page would be enough for most kind of code? In this case it wouldn't take too much time to save these bytes during task switching as well.

In cooperative mode, the task could even tell the scheduler, how many bytes are currently used in the zero page. And in pre-emptive mode you could store in the first byte of the zero-page area, how many bytes are currently used here.

 

Anyway as I said before, usually most tasks do nothing. So I am quite sure, that multitasking (which at least feels like multitasking) will work on the A8 in a useable way.

 

CU,

Prodatron

[potatohead]

Of course the real question is how many cycles does it take to get ready to perform that PORTB write?