New GUI for the Atari 8-bit

[atari8warez]

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,

 

Speed was only one of the concerns, although is a major one it is not the only one, you have many other obstacles to conquer, that is if you can. The whole point is the adventure is not worthwhile, believe me it would have been done already in the past 35+ years had it been possible on a Atari 8 bit, writing a multitasking OS with a GUI isn't the same as writing a WP and I sincerely hope (despite all of the nasty name calling you've been doing so far) that you prove me wrong. And as far as me not being a 6502 coder all i can say is you seem to love to speculate a lot even when you don't have a clue about me or about my technical skills. And if you think programming a 6502 is a challenge you have to see what kind of challenges modern architecture offer to the programmers, just trying to debug a multi-threaded, object oriented, event driven application is enough to keep one scratching his head on hours end, don't kid yourself!...

 

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.

 

You really have a way of turning subjects around, don't you?. What I meant was how are you going to handle DLI and VBI interrupts in a multi-tasking environment that so many Atari applications depend on. Where did I say the individual application will directly interact with hardware? The question is how are you going to provide a similar functionality to those apps in the GUI environment... Instead of answering the question you choose to try to ridicule the question. That's what some people do when they don't have an answer... On the subject of bank switching, yes it may take a split second to do it on a single threaded, single application system when the CPU has nothing else to do but serve only one program at a time, but it is a whole different can of worms when you task the poor 6502 to handle all the overhead that comes naturally with a multitasking OS with a GUI. I guess one needs to be a real "dreamer" not to see the reality...and of course calling me a Buzz Killington is always easier then answering though questions...

Edited December 5, 2012 by atari8warez

[atari8warez]

and some people just live to be negative.

 

In our neck of the woods we call that being realistic

[atari8warez]

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

 

Good question!!, in a multitasking OS with GUI on a 6502 system, it may take a while for the CPU to even get ready to do it

[atari8warez]

 

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.

 

Zero page is a very popular area for at least two reasons that I am aware of, first some indirect addressing modes are only possible with zero page locations and second some ops require less cycles with zero page locations, so apps, if they could, would use all of the available zp locations to their advantage. However the major user of zero page addresses is the system OS / DOS on the Atari, so very few if any is left for apps and usually its advised to stay away from zero page locations. This is however not such a big concern when an application takes over the whole machine (like many of them do).

 

As for the registers, there are only 3 of them. A (accumulator), X and Y. They are 8 bit and can not be paired or split.

 

 

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

 

That's true, when apps do nothing the system will look like multitasking (or like task switching), the problem begins when they start doing things in tandem. There is a reason why first commercially viable/successful multi-tasking system was the Amiga (and not an 8 bit system) with it's many co-processors, better suited architecture and 32 bit 68000.

[Prodatron]

the adventure is not worthwhile, believe me it would have been done already in the past 35+ years had it been possible on a Atari 8 bit

Sorry, but this is not a proof at all. People are still breaking through higher and higher limits on the 8bit machines. That's how it is on the A8 as well as on the Amstrad CPC. There are so many things released during the last few years, where people couldn't imagine that this would be possible on the same system 30 years ago. What FJC already achieved with the current status of the GUI is more than we have ever seen before on a 6502-system. So would be the next step - multitasking - really a problem compared to this?

 

However the major user of zero page addresses is the system OS / DOS on the Atari, so very few if any is left for apps and usually its advised to stay away from zero page locations.

Thanx for the information about the ZP. Wow, the latter is even one more reason, that it can be possible!

 

There is a reason why first commercially viable/successful multi-tasking system was the Amiga (and not an 8 bit system) with it's many co-processors, better suited architecture and 32 bit 68000.

The funny thing is, that the Workbench on my Amiga 1000 runs slower than SymbOS on my Amstrad CPC I know, that it was an older version, the VRAM is 32K instead of 16K, and the code was very unoptimized. But anyway, I don't see an argument here as well...

[flashjazzcat]

Thanx for the information about the ZP. Wow, the latter is even one more reason, that it can be possible!

 

The assertion regarding page zero is inaccurate (indeed it's fantasy), and I'd discourage you from relying on this particular source of information. The entire upper half of page zero (i.e. 128 bytes) is free for application use if BASIC and the FP package aren't used (and obviously neither is used by the GUI).

 

Regarding the rest... I'll deal with it later, since I'm busy with my website right now.

Edited December 5, 2012 by flashjazzcat

[atari8warez]

The assertion regarding page zero is inaccurate (indeed it's fantasy), and I'd discourage you from relying on this particular source of information. The entire upper half of page zero (i.e. 128 bytes) is free for application use if BASIC and the FP package aren't used (and obviously neither is used by the GUI).

 

Regarding the rest... I'll deal with it later, since I'm busy with my website right now.

 

The devil is in the details as it seems.... Even if the upper memory locations are made available - at the expense of disabling BASIC and FP - the advantages of using zero page locations by the apps quickly become moot in a multi-tasking environment at least from the point of view of additional speed as the speed gains would be more than offset by the OS overhead of moving those zero-page locations in and out in the quest of switching apps, that is simply just more overhead for the CPU to deal with.

Besides why would I have to give-up BASIC and FP for the sake of running an inefficient GUI on a already overworked 6502.

[atari8warez]

Sorry, but this is not a proof at all. People are still breaking through higher and higher limits on the 8bit machines. That's how it is on the A8 as well as on the Amstrad CPC. There are so many things released during the last few years, where people couldn't imagine that this would be possible on the same system 30 years ago. What FJC already achieved with the current status of the GUI is more than we have ever seen before on a 6502-system. So would be the next step - multitasking - really a problem compared to this?

 

What he currently achieved so far (and actually lot more) was already done with Diamond GOS in the past as it can be seen on the following video:

http://www.youtube.com/watch?v=40CPFljl3fk

 

I'll leave it up to you to determine the reasons why that particular GUI never caught on. For me a GUI based OS is just a novelty on a Atari 8 bit, good for a demo to show that it can be done, useability on the other hand is a whole different story. There is a reason why the video doesn't show what happens to the GUI after Zaxxon is launched and used. A GUI based app launcher... YES... a real multitasking GUI/OS... NO...

 

 

Thanx for the information about the ZP. Wow, the latter is even one more reason, that it can be possible!

 

You're welcome...and yes it is possible but not usable in the sense of a real multitasking OS.

And I agree many upgrades to the Atari 8 bit have been done over the years that might have been seen as impossible years ago, but most of those upgrades (and almost all of them hardware related) use additional more advanced processors, chips, and memory. In some cases the Atari is not an Atari anymore but becomes a hybrid based on 6502 with a little (a lot!) of help from ATMegas, CPLDs, flash memory chips etc....

 

One such example is the Ultimate 1MB upgrade, which gives the Atari 8 bit a lot of memory, multiple OS selection, real time clock, built-in DOS, switchable ROM based games, support for Parallel Bus etc... Is this really breaking limits on the Atari as you put it, well I respectfully disagree... to me it's really enhancing Atari's usability and extending its useful life through the use of newer technology, and some of those ugrades like U1MB are truly brilliant in achieving this particular objective.

Edited December 5, 2012 by atari8warez

[+Stephen]

I think you're missing the point. If you want to speak "practicality", or "usefullness", none of us would be using the 8-bit computers for anything more than a door stop. Some people like doing things not for money or fame, but purely for the challenge of doing it.

 

DiamondGOS was also nothing like the current GUI. It was not event based, did not use a message queue, etc.

[atari8warez]

I think you're missing the point. If you want to speak "practicality", or "usefullness", none of us would be using the 8-bit computers for anything more than a door stop. Some people like doing things not for money or fame, but purely for the challenge of doing it.

 

DiamondGOS was also nothing like the current GUI. It was not event based, did not use a message queue, etc.

 

I don't know other people but I certainly don't use mine as a door stop , I think Ataris have their place in the useful domain (even if for nothing but retro gaming or pure demos). On the other hand I would have been really excited had I been able to use such an OS on my 8 bit, but I know that won't happen.

 

As to why people are doing it, sure its not for the money I agree 100% on that, the fame...., hmmm I am not as sure about that as you are, challenge... sure... and I am not saying that FJC shouldn't do it. He's apparently done other projects that are successful and usable. And I would have to wonder whether he's putting his efforts in the right place with this GUI adventure, which may and in all likelihood will have a similar legacy as the Diamond GOS (notwithstanding the fact his GUI is event based unlike GOS)

 

1 + 1 is always equal to 2 not 3, 4 or 5, well at least in the realm of current science.

Edited December 5, 2012 by atari8warez

[Prodatron]

I already saw these Diamond GOS videos.

FJCs A8GUI is already...

- much faster

- looks much nicer

- uses proportional fonts, which means (amongst other things), you get much more information on the screen

- the refresh method of the GUI elements is clearly ahead

- the flexibility of the GUI elements is clearly ahead

- etc. etc.

I was really impressed by Diamond GOS, too! But at least regarding the GUI it has been already beaten by the new A8GUI.

So it's not the reference anymore, or - let's say - it DOES NOT illustrate the limits of the A8!

[atari8warez]

I already saw these Diamond GOS videos.

FJCs A8GUI is already...

- much faster

- looks much nicer

- uses proportional fonts, which means (amongst other things), you get much more information on the screen

- the refresh method of the GUI elements is clearly ahead

- the flexibility of the GUI elements is clearly ahead

- etc. etc.

I was really impressed by Diamond GOS, too! But at least regarding the GUI it has been already beaten by the new A8GUI.

So it's not the reference anymore, or - let's say - it DOES NOT illustrate the limits of the A8!

 

Ok, I agree with most of your observations above (except the speed which i found not much faster than GOS, especially window redraws), and if beating an existing GUI in terms of looks is the objective he certainly achieved that. He actually designs very nice looking front ends (knowing some of his other projects). But my opinion on a multitasking GUI on an Atari 8 bit still stands. I guess further discussions on this matter is pointless and I will believe that a usable multitasking GUI based OS can be done on a 8 bit Atari when I see one in action... until then I would have to stick with good ol' single threaded, non-GUI OSes.

[+Gemintronic]

Has anyone tried the Atari version of Contiki? How does Contiki compare with this project?

http://hitmen.c02.at/html/tools_contiki.html

[atari8warez]

Has anyone tried the Atari version of Contiki? How does Contiki compare with this project?

http://hitmen.c02.at...ls_contiki.html

 

Contiki is just a web browser for 8 bit computers, not much in common with this project.

[Joey Z]

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).

 

not to shoot down multitasking on the A8, but I am not sure exactly where you heard this. the Z80 is definitely a more complex MPU than the 6502 is (just look at the transistor count as an example - 3510 (6502) vs. 8500 (Z80) (assuming wikipedia is correct)). also, the Z80 has features that are very useful, like being able to do block memory moves a lot faster than the 6502 due to dedicated block memory move instructions, whereas you have to use a loop to do the same on the 6502. The Z-80 has over 600 instructions (this is from a book this time, instead of wikipedia) and the 6502 has <256. on top of all that, the A8 isn't really 1.79Mhz since the ANTIC steals cycles for DMA. not sure what it effectively drops to, but I know that makes a pretty significant difference.

[Prodatron]

Contiki is just a web browser for 8 bit computers, not much in common with this project.

Not at all. Contiki is (or WAS?) a C-based easy to port mini-OS for 8bit ("memory constrained") systems with a textmode-GUI. It also includes a TCP/IP stack (called "uIP"/"micro IP" - Adam is great in creating new marketing names for his implementations). The browser is just one of the apps, which is available for Contiki.

Since Contiki 2.x is a commercial version for embedded systems, Adam removed the old 8bit-Contiki (1.x) website completely (unfortunately).

[Joey Z]

I guess one needs to be a real "dreamer" not to see the reality...and of course calling me a Buzz Killington is always easier then answering though questions...

 

Then so what? let him dream then. How are we to get anywhere in this world if we keep thinking we can't do something? now I understand maybe an A8 GUI won't get us much further in the world, but what do you have against a man trying to obtain a dream? countless wonderful inventions were once thought impossible until one or a group of 'dreamers' were able to figure it out.

[atari8warez]

A8 isn't really 1.79Mhz since the ANTIC steals cycles for DMA. not sure what it effectively drops to, but I know that makes a pretty significant difference.

 

Only about 30% Joey , that's why some processing intensive apps/utilities prefer to turn DMA off. SDX with hi-speed I/O is one of those apps that comes to mind....

[Prodatron]

not to shoot down multitasking on the A8, but I am not sure exactly where you heard this.

This is, what the C64 guys are telling me all the time!

 

like being able to do block memory moves a lot faster than the 6502 due to dedicated block memory move instructions, whereas you have to use a loop to do the same on the 6502.

Let's compare it:

- On an Amstrad CPC it takes exactly 6 microseconds to move 1 byte via these block copy instrutions (the opcode is "LDIR"). So moving 1000 bytes costs you 6 milliseconds. By using multiple "LDI"-commands (they don't have the repeat-feature) you can optimize it to 5 microseconds for 1 byte

- how long would this take on the A8?

 

on top of all that, the A8 isn't really 1.79Mhz since the ANTIC steals cycles for DMA. not sure what it effectively drops to, but I know that makes a pretty significant difference.

Seems to be the same on every of these (early) 8bit machines machines. The Z80 in the Amstrad CPC effectively has a clock rate of about 3,2MHz (because of the video hardware).

Edited December 5, 2012 by Prodatron

[atari8warez]

Not at all. Contiki is (or WAS?) a C-based easy to port mini-OS for 8bit ("memory constrained") systems with a textmode-GUI. It also includes a TCP/IP stack (called "uIP"/"micro IP" - Adam is great in creating new marketing names for his implementations). The browser is just one of the apps, which is available for Contiki.

Since Contiki 2.x is a commercial version for embedded systems, Adam removed the old 8bit-Contiki (1.x) website completely (unfortunately).

 

I've just downloaded and tried the atari 8 bit port and can't even successfully run it on my 130XE or Altirra for that matter (it loads but no response from the UI). It looks nothing like a GUI or OS from what I've seen from the start-up screen. (EDIT: Apparently the GUI is an optional part of the system which may have or may not have been ported to Atari) I may have a better idea if I can get it to work later. But here's a screen shot from the Atari port.

Edited December 6, 2012 by atari8warez

[Joey Z]

This is, what the C64 guys are telling me all the time!

 

 

Let's compare it:

- On an Amstrad CPC it takes exactly 6 microseconds to move 1 byte via these block copy instrutions (the opcode is "LDIR"). So moving 1000 bytes costs you 6 milliseconds. By using multiple "LDI"-commands (they don't have the repeat-feature) you can optimize it to 5 microseconds for 1 byte

- how long would this take on the A8?

 

 

Seems to be the same on every of these (early) 8bit machines machines. The Z80 in the Amstrad CPC effectively has a clock rate of about 3,2MHz (because of the video hardware).

 

let's see...

/me dredges up some 'block move code' he has...

LDX #$00 ;load X with the number of bytes to move. in this case, 256, we count down from 0 (0,255,254, etc.)

LOOP LDA $A800,X ;load the accumulator with the byte pointed at by A800+X

STA $2400,X ;store the accumulator in the byte pointed at by $2400+X

DEX ;decrement X, the byte counter

BNE LOOP ;branch as long as X isn't 0

 

OK, the first LDX is a one time thing, similar to setting the BC pair before a block move on the Z80 (IIRC) so we won't count that

the LDA $A800,X takes 4 T cycles, 5 if it is across a page boundary (and it usually is, so we will assume 5)

the STA $2400,X takes 5 T cycles as well

DEX takes 2 T cycles

lastly, the BNE takes 2 T cycles, plus one if the branch occurs, and plus one more if it is across a page boundary. we will assume it is NOT and say 3 T cycles.

now unless I am wrong (and correct me please if I am) a T cycle is just a clock cycle, right?

so then:

(5+5+2+3)/1790000=8.4uS/byte

if I have done my math right, the 6502 is slower. also, this is assuming you know exactly what two groups of memory locations you want to move between when you write the code, although I suppose (provided this routine is in RAM) that one could implement self modifying code to change the source and destination addresses. for the record, this code works on a real machine sloopy can attest to that.

EDIT: the other thing I forgot about is the DRAM refresh feature in the Z80 which adds a T cycle onto every M1 or something, doesn't it?

RE-EDIT: looked it up myself and found the M1 chart in: "Microcomputers and Microprocessors: The 8080, 8085, and Z-80 Programming, Interfacing, and Troubleshooting" by John Uffenbeck. it adds TWO T-cycles to every M1... and you can probably assume it does something special during block memory move instructions because moving some significant amount of memory takes a while, and it can't go on that long without doing a refresh.

Edited December 6, 2012 by Joey Z

[Prodatron]

Ok, there seem to be a difference. But it also shows, that there are no RELEVANT differences (like >= 2x faster/slower or even more).

Don't forget, that the VRam of the Amstrad CPC has the double size compared to the VRam of the A8 (16KB instead of 8KB). So on the performance side the A8 wins again!

 

Now see this (4MHz Z80 Amstrad CPC, 16K vram - original CPU speed!):

 

http://www.youtube.com/watch?v=Ish4ReOjdIw

 

Somehow using multitasking in this video has been carried to the excess, but usually you don't do it like this - only for demonstration.

So even if (worst case!) the A8GUI would be only half as fast, it would be still great I think!

And now can someone explain me, why multitasking shouldn't be possible on the A8, which is the same computer generation like the CPC?

[Prodatron]

I've just downloaded and tried the atari 8 bit port and can't even successfully run it on my 130XE or Altirra for that matter (it loads but no response from the UI). It looks nothing like a GUI or OS from what I've seen from the start-up screen. (EDIT: Apparently the GUI is an optional part of the system which may have or may not have been ported to Atari) I may have a better idea if I can get it to work later. But here's a screen shot from the Atari port.

 

Contiki is really something you could call a "nice demo": To demonstrate, that you can port small C projects to a bunch of 8bit platforms. It's funny to watch it with its primitive text-GUI on a Commodore PET ore something like this. But already on the more advanced 8bit systems it's too primitive.

Edited December 6, 2012 by Prodatron

[Joey Z]

Ok, there seem to be a difference. But it also shows, that there are no RELEVANT differences (like >= 2x faster/slower or even more).

Don't forget, that the VRam of the Amstrad CPC has the double size compared to the VRam of the A8 (16KB instead of 8KB). So on the performance side the A8 wins again!

 

Now see this (4MHz Z80 Amstrad CPC, 16K vram - original CPU speed!):

 

http://www.youtube.com/watch?v=Ish4ReOjdIw

 

Somehow using multitasking in this video has been carried to the excess, but usually you don't do it like this - only for demonstration.

So even if (worst case!) the A8GUI would be only half as fast, it would be still great I think!

And now can someone explain me, why multitasking shouldn't be possible on the A8, which is the same computer generation like the CPC?

only a8w is saying it isn't possible. anyway, my point was that a 1mhz 6502 does NOT compare well to a 4mhz Z-80 . don't believe them commies!

 

BTW, does SymbOS run on anything other than an Amstrad?

Edited December 6, 2012 by Joey Z

[atari8warez]

only a8w is saying it isn't possible. anyway, my point was that a 1mhz 6502 does NOT compare well to a 4mhz Z-80 . don't believe them commies!

 

BTW, does SymbOS run on anything other than an Amstrad?

 

Hah ha, Joey not you tooo!.... You guys really need to re-read some of the stuff I have written. Maybe BOLD CASE WILL STICK OUT BETTER. I NEVER SAID IT'S NOT POSSIBLE, I SAID IT'S NOT WORTHWHILE THE EFFORT AND I REPEAT IT AGAIN DESPITE THE AMSTRAD DEMO with nice looking girls shaking their butts against a backdrop of Pacman chasing ghosts. If you don't believe me, just wait, and our lifespans permitting, we will see the results...

Edited December 6, 2012 by atari8warez