New GUI for the Atari 8-bit

[+MrFish]

thats faster then win xp, 300mhz, 128mb ram.. seriously, try that configuration

 

Admittedly Windows XP is doing much more than just moving around a few windows. Windows XP needs a much bigger memory footprint than that, no matter what the minimum requirements state. I give it a reasonable minimum of 1 gb, although as always, the more RAM the better.

[w1k]

yes, i know i but i remember lot of times about zzzz zzzz zzz when i dragging opened windows

[+MrFish]

yes, i know i but i remember lot of times about zzzz zzzz zzz when i dragging opened windows

 

I've never used a 300mhz machine with XP either, so I couldn't comment on that. I would say a 300mhz machine is better suited to Windows 2000, or even Windows 98. I stuck with 2000 on my old 550mhz P III years ago, even though I had copies of XP. Probably a good minimum speed for XP is more like 1 ghz. These days, if you want to run XP, there should be no good reason to even use a machine that's as slow as 1 ghz. There are plenty of used Pentium 4 and higher machines/parts out there. There should be no problem running XP at a good speed and reasonably cheap these days.

[flashjazzcat]

The whole matter of "bloat" in the larger operating systems is interesting. If it was practical (from a time and motion point of view) to code a modern operating system in pure assembler, everything would run at startling speed and it then becomes questionable whether we'd need as many GHz as the typical PC now boasts. From the ST / Amiga onwards, the bulk of the operating system was written in a high-level compiled language such as C. While highly efficient, this is never going to be as fast as pure assembler, and indeed many low-level, critical code sections were written in 68000 assembler. The same is true of Mac OS, which was written in Pascal, while the QuickDraw component of the GUI was coded in 68000 assembly language.

 

It's natural to consider writing a GUI in C because of the complex data structures involved (binary trees, structures, queues, recursion, stacks, parameter blocks). By the time GEM and Amiga OS were written, the machines were clearly powerful enough to absorb a certain amount of overhead in non-critical areas. Nevertheless, the STE's hardware biltter and the higher MHz of later models addressed - at least to some extent - the requirement to run the same OS faster. With the extra processing slack thus introduced, one naturally adds complexity to the compiled, high-level OS code and so the hardware / software cycle continues.

 

The interesting thing about writing a GUI for a thirty year old machine is that - ostensibly at least - the hardware development cycle is long finished and we can't expect to take up the slack with a faster processor further down the line. It was therefore immediately apparent that a high-level solution was not going to work in this instance. By coding the entire system in assembly lanaguage and by using a lot of cycle-saving techniques such as LUTs (and inventing some unique approaches), I believe we can go some way to closing the perceivable hardware gap between the 8-bit and 16-bit machines. This is not to prove a point, but is simply necessary to make the system responsive.

 

Of course applications may be written in C, since they are largely at the behest of the GUI itself.

 

Regarding Windows XP: the lowest hardware spec I found to be more or less usable with SP1 was a 450MHz AMD setup with 256MB of RAM. However recollections are clouded by ensuing hardware upgrades, so by the time I had a 1GB machine the lower spec probably wouldn't have seemed so agreeable. But yes - XP should run pretty good on almost anything that's not comparitively prehistoric.

Edited April 1, 2012 by flashjazzcat

[+MrFish]

yes, i know i but i remember lot of times about zzzz zzzz zzz when i dragging opened windows

 

Actually, I did used to run XP on a 200 mhz machine, back in the day. But, it was a Dual Pentium Pro, and those processors kicked back in their time. Even then, you have to configure XP for the machine you're running it on. You were using "Show Window Contents While Dragging"? Probably a good idea to turn some of the interface graphics options off if you're going to run it using an underpowered piece of hardware.

[potatohead]

Adding to that mess is 4th gen languages and scripting. My newer Lenovo laptop came with this goofy power manager application. It runs Win 7. My last one from 5 years ago, running XP, also came with that same app. The difference is stunning! On XP, it was written with an early .net something or other, and it would launch, twiddle the power bits desired and close rapidly. Non issue. The current one, takes several seconds to launch, will bury a CPU core while a user is interacting with it, and takes a while to close. All for twiddling a few power bits!

 

I replaced it with Throttlestop, written in a much leaner basic MFC mode, and it's very lean.

 

Also seeing this in higher end applications. A powerful, high end CAD application I work with professionally has a massive XML structure describing it's GUI. This is parsed each time, many bits of the GUI built at run-time, with a typical program start taking 30 seconds or so on an average modern machine. Once it has launched, it can launch again with about the expected load time.

 

Interacting with the program will spike a CPU core regularly, more or less demanding a 2.5Ghz CPU and very solid front side bus throughput to avoid unusual delays. Funny thing, rotating a graphics model consumes less overall resources, unless the model is very large. Clearly, the graphics path is optimized as it should be, leaving an ugly framework not-optimized at all...

 

Re: XP on older machines.

 

If those machines featured a nice front side bus, XP ran well with lower clocks. (300Mhz or so) Often, bus speeds on those were like 60Mhz, which is terrible for graphical tasks. Right near the end of that time, front side bus clocks would match or be very close to the CPU clock, changing everything --or changing it as much as larger CPU cache did. A reasonable modern machine will feature at least 10x those early bus speeds (600Mhz), if not a lot more. Mine runs somewhere north of 1ghz today.

Edited April 1, 2012 by potatohead

[flashjazzcat]

Heh... my friends and I were always chasing higher FSBs in the early 2000s. I remember putting bits of wire between a socket-A Duron's pins to overclock it via the FSB. 140-150 Mhz bus speeds with PC133 memory... heady days indeed! As soon as PC's were decently fast without all that palaver, I stopped tinkering altogether...

[Mark Wolfe]

I have always wanted to run Mac OS7x on the last PPC machine, the G5 un-emulated, just to see how fast it would be, that last version of OS7 was pretty amazing for the time. things changed very rapidly for mac users once OS8 came along, there were so many different macs and the architecture kept changing every few months, it was nuts. it is still kind of like that now, they make a new mac every year and update the OS along with it. I can't keep up. I am stuck for now with a 2GB ram ceiling in my mac laptop... it is painful for me, that damn spinning rainbow wheel of death is an hourly occurrence for me. I probably should step the OS back from 10.5x to 10.4x but then half my apps would not work

Edited April 1, 2012 by Mark Wolfe

[kogden]

I have always wanted to run Mac OS7x on the last PPC machine, the G5 un-emulated, just to see how fast it would be, that last version of OS7 was pretty amazing for the time. things changed very rapidly for mac users once OS8 came along, there were so many different macs and the architecture kept changing every few months, it was nuts. it is still kind of like that now, they make a new mac every year and update the OS along with it. I can't keep up. I am stuck for now with a 2GB ram ceiling in my mac laptop... it is painful for me, that damn spinning rainbow wheel of death is an hourly occurrence for me. I probably should step the OS back from 10.5x to 10.4x but then half my apps would not work

 

MacOS 7 won't run on a G5. I don't think the G5 will even run MacOS 9 natively but they supported "Classic Mode" in 10.4. With 2GB of RAM you'll see some gains w/ 10.5 if you turn off Dashboard, Spotlight and the 3D dock. They suck quite a bit of RAM. Not so bad on my Macbook as it has 4GB RAM. There's lots of ways to make Leopard suck less.

 

I was pissed they didn't port 10.6 to PPC. Hell, I'm pissed 10.7 axed the CoreDuo machines. A lot of serious optimization was done under the hood that would have really benefited PPC machines in 10.6. 10.6 is also MUCH smoother than 10.5. I gave up and gave the PPC desktop to my son and built a Core2Duo hackintosh. Not even Firefox supports 10.5 on PPC anymore.

 

It's to the point now where PPC macs are more useful as Linux machines than Macs. Only real way to run recent software.

[Mark Wolfe]

I def know you can't run older OSs on the G5, but I didn't know you could turn things on and off in OSXx... how do I turn off Dashboard, Spotlight & 3D Dock... or anything else I don't use , I sure as hell don't use those. I miss the days of the extension manager app... ugh. anyway, I would appreciate a tutorial, I assume it is all done via the terminal? btw, my core duo is the one with the 2GB ram limit... sucks ass

Edited April 1, 2012 by Mark Wolfe

[thorfdbg]

The whole matter of "bloat" in the larger operating systems is interesting. If it was practical (from a time and motion point of view) to code a modern operating system in pure assembler, everything would run at startling speed and it then becomes questionable whether we'd need as many GHz as the typical PC now boasts.

 

You guess wrong. Even if everything would be written in assembly, the Os would need the Ghz as of today. Re-implementing the same algorithms from C or C++ in assembly will, at the very best, improve the speed by at most a factor of two, unless heavy signal process is involved and you can make use of some of the advanced processor features.Nothing of that is the case in operating systems. The trouble is - if you call it trouble - the hardware abstraction the Os provides. Note that any serious operating system like Linux (or Windows, if that is serious enough for you) runs on various hardware types, so you have drivers in between the program and the Os. You have memory management that shields the programs between each other. In Win7 and above, you have entire virtual machines between some programs, you have a whole bunch of services and architectures, legacy interfaces and wrappers between these interfaces crammed together. It is not the programming language that makes the modern systems so demanding. This is really the least problem. The hardware and interface legacy is.

[flashjazzcat]

I don't think ST users would have said no to a two-fold performance increase. I certainly wasn't inferring that things would run ten times faster even today. Anyway - what you say makes total sense. Of course the GUI itself is a hardware abstraction layer as far as applications are concerned, right here on the A8.

[Faicuai]

 

(...)

 

You guess wrong. Even if everything would be written in assembly, the Os would need the Ghz as of today. Re-implementing the same algorithms from C or C++ in assembly will, at the very best, improve the speed by at most a factor of two,

 

(...)

 

 

I suppose you have already tested this (to some extent), correct?

 

I would really like to see this, with my own eyes, with a relatively simple task / mini-demo (or mini-benchmark), one written in C/C++ and the other in pure, "heart-pumping" Assembly, a-la pure/"old-skool" fashion...

[+DarkLord]

I don't think ST users would have said no to a two-fold performance increase. .

 

Nope, we sure wouldn't have.

[atarixle]

I got something for you:

 

Now I'm light years ahead of you

 

Seriously, take a look at the new feature I plan to add to my GUI.

[Mark Wolfe]

@atarixle: does your GUI have windows like flashjazzcat's ? also, is there an english version of your webpage and the project you're referring to?

 

also, I fail to see how it is light years ahead...

Edited April 1, 2012 by Mark Wolfe

[+MrFish]

If those machines featured a nice front side bus, XP ran well with lower clocks. (300Mhz or so)

 

It all depends on what your idea of reasonable performance is. Personally, I wouldn't care to slog it out on XP with anything less than a Pentium III, 1 ghz, or higher (preferably Tualatin). I basically go with the theory that you use an operating system that's matched to your hardware. You may have to give up some features to stick with an older system, but I'll take the trade-off in order to have a system that can keep up with me. Anything at 300 mhz is going to be much better suited to using Windows 2000 for performance, irregardless of the front side bus.

[+MrFish]

also, I fail to see how it is light years ahead...

 

He was being facetious. Although in terms of practical use he's not too far off. Our GUI presently will help you...?

[Mark Wolfe]

I'm not savvy enough to understand what he is doing with his GUI in that video, maybe if it was in english I could understand it better. For my use, I'd want a gui that behaved like any OS, you have a desktop, you can double click on items in the desktop and launch apps or files or mounted disk images. I don't need a search feature, I already know what I have, I need to be able to see my games listed in a directory like any modern OS does. I don't really need any bells or whistles.

[atarixle]

The video is in english ... at least I tried to speak english (for which I need more practise). And idk why the link has been converted to an embedded video now :/ ... the youtube page holds more information in the description.

Oh, and yes, it has windows. Pretty fast drawn, even it's in Turbo-BASIC (with some help on machine language code).

 

Anyway, I implemented an indexed search into my GUI. The video shows a sneak peak of what will come in the (near?) future. That's a feature, all GUIs/OS' GUIs on the PC have (whether Windows NT 6.x, Mac OS X >10.4.x, or Ubuntu >11.04, GNOME3). Now the Atari 8 Bit has it too.

The search-feature is very important to me, no matter if I work on my Atari or on my PC (mostly PC, shame on me). My permanently installed 2x16MB MyDOS-drives are full of files (1317 files+67 folder on my boot-drive, 1426 files+105 folders on my data drive).

 

The idea to an indexed search I had, when I was playing around with the ls command in Linux:

 

ls -ABR | grep what_Im_looking_for

lets me search for files without a GUI, and

ls -ABR > index

let's me build an index, while

cat index | grep what_Im_looking_for

lets me find files even faster.

 

Now I implemented a similar behave in the small A8.

 

Oh btw, I know, the GUI in my video is not really lightyears ahead, but I still got a lead of about 19 years (that's when I wrote my first line of code for BOSS).

Edited April 1, 2012 by atarixle

[kenjennings]

The whole matter of "bloat" in the larger operating systems is interesting. If it was practical (from a time and motion point of view) to code a modern operating system in pure assembler, everything would run at startling speed and it then becomes questionable whether we'd need as many GHz as the typical PC now boasts.

You guess wrong. ... etc... etc... In Win7 and above, you have entire virtual machines between some programs, you have a whole bunch of services and architectures, legacy interfaces and wrappers between these interfaces crammed together. It is not the programming language that makes the modern systems so demanding. This is really the least problem. The hardware and interface legacy is.

 

Really, it is just simply due to grossly inefficient design. At microsoft the left hand doesn't know what the right hand is doing. The different divisions at microsoft do not work together. Each group has to reinvent the same wheel for themselves. Huge chunks of code are redundantly implemented and unecessarily called in layer after layer. Ever notice how many different file and print dialogs appear in Windows? It really is shocking how many Gigs of disk space Windows 7 consumes with zero applications installed. Other than some added glitz it doesn't do much more than XP.

[flashjazzcat]

Oh btw, I know, the GUI in my video is not really lightyears ahead, but I still got a lead of about 19 years (that's when I wrote my first line of code for BOSS).

 

Boss-XE is a working system, and any system which works has a lead over us. The new GUI is an entirely different beast: almost a reimplementation of the early Mac OS or GEM on the A8. Applications interact with the system solely and entirely in response to events generated by the OS. Boss-X implements a very nice desktop metaphor.

 

There are as number of excellent solutions out there: Diamond, Boss-X, TRS Desktop, SAM-Desktop... they all take entirely different approaches. Anyone who needs a working GUI today had better choose one of them. If you want to write or use Mac-like applications on the A8, however, it's gonna take a while. I'm not consciously competing with any existing system, since I don't believe there is any precedent for precisely what we're attempting to do here.

 

I do look forward to the stage at which we're writing file search utilities and other such tweaks. Unfortunately, six months' work on a good solid window manager comes first (several places higher up the list, in fact).

Edited April 2, 2012 by flashjazzcat

[Mark Wolfe]

re: Diamond, Boss-X, TRS Desktop, SAM-Desktop.... are any of them in english?

[flashjazzcat]

re: Diamond, Boss-X, TRS Desktop, SAM-Desktop.... are any of them in english?

 

Diamond is entirely in English, and also the closest of the lot IMO to what we're attempting here (cartridge based, event handler, etc). Diamond has also just been fixed up to work with SpartaDOS X, and the patched version is available on the SDX website.

[atarixle]

re: Diamond, Boss-X, TRS Desktop, SAM-Desktop.... are any of them in english?

 

Yes, yes, yes, I don't know

 

Diamond is english by default, BOSS-X has an english brother which I'm maintaining parallel to the german version, TRS is english by default, and SAM used to be a german product but idk of they published it in german or english.

 

Boss-X implements a very nice desktop metaphor.

 

(I hope I translated the word "metaphor" correctly, to get correctly what you really meant by that)

Oh, I don't see it as a metaphor, it is in fact a desktop, which is great for everyday use - if you have a MyDOS-Setup. The implementation of the so called "API" is a metaphor, because it technically totally different from how APIs are implemented/shipped on other OS' or GUIs.

Technically, my API (let's better call itskeletalstructure) is closer to what we call "frameworks" on other platforms.

Edited April 2, 2012 by atarixle