New GUI for the Atari 8-bit

[+David_P]

I, for one, am looking forward to the VNC implementation so I can remotely manipulate an 800xl...

[flashjazzcat]

About how large do you estimate the final product to be?

 

Currently the XEX is 29KB. This includes the demo application, three system fonts (roughly 1KB each), and a number of icons. So the system code itself is maybe 20KB in size, and JUST fits into conventional memory. I can see the kernel and core library consuming 32KB (4 x 8KB banks) pretty soon after the move to cartridge, and the finished product being quite a bit bigger than that. As much functionality as possible needs to go into the cart ROM, since the cart area is one of the few with unbuffered access to the extended memory banks.

 

Any 64KB flash ROM cartridge will be more than adequate.

 

I'd hoped Candle would give me 64KB of the Ultimate 1MB's ROM space, but I get the feeling he's found another use for it since we discussed it, so I may have to share with SDX in that situation. A "GUI" option on the Ultimate's BIOS menu would have been nice...

 

Can one "lasso" or otherwise graphically select groups of files for copying, etc?

 

Not yet, but you will be able to eventually. Lassoing will also automatically scroll windows in the appropriate direction.

 

It is HARD to believe that a 1.7+Mhz 40-pin CPU sitting in a 25+ years machine, with an amount of ram that does not even match the buffer of network-card or my hard-drive, is actually capable of rendering this...

 

The machine never ceases to amaze me. Coding is one thing, but if the Atari wasn't such a wonderful computer, this would run like a dog. I myself am surprised at the speed of text rendering (of proportional fonts), and I wrote the renderer!

 

It's going to use any ST compatible mouse, correct?

 

In that case, shouldn't a PeST work with the 8bit and this GUI,

since the ports are so close? Just curious...because if it does

work, it would allow a little more latitude over mouse choices.

 

I've (deliberately) picked up a lot of really nice 9 pin serial mice for the ST/Amiga, all of which are VASTLY superior to the original ST/Amiga mice and similar in use to older PS/2 ball mice. Logic3, TecnoPlus, Quik... they're on eBay all the time.

 

The GUI will support both ST and Amiga mouse bit mappings.

Edited May 31, 2012 by flashjazzcat

[doomguy]

Of course I can't speak on Candle's behalf, but.... I think Candle might have actually given you much more than you expected -- in the c816 thread when asked what the huge amount of internal rom was for, his response was simply "think gui".

 

On the topic of ST mice... There are several nice devices for sharing the joystick port with a mouse with either a manual switch to go between the two or automatically by pressing the fire button or mouse button. I wonder if these would work. I hate swapping devices.

 

Best Electronics should give you a commission on ST mice -- I'm sure they'll have a large influx of orders when your GUI nears completion.

 

Keep up the great work flash -- truly remarkable what you have done.

[flashjazzcat]

Of course I can't speak on Candle's behalf, but.... I think Candle might have actually given you much more than you expected -- in the c816 thread when asked what the huge amount of internal rom was for, his response was simply "think gui".

 

I don't want to speak on his behalf either (although he never speaks here) but I know he's kind of interested to see how fast the GUI will run on the c816 and I remember some mention of some ROM space on the board. Obviously the performance will be extremely impressive at 7MHz (even the slowest GUI written in Basic should become usable), and I must admit it'll be something to see. However, my priority is in making a system which performs well on stock hardware. Hopefully Candle won't mind me saying that his interest in the GUI on a 6502 is virtually nil, and never the twain shall meet on that topic, I think. However, I'll be using the GUI on an Ultimate 1MB equipped 1200XL, and that's where my immediate interest lies. I believe many onlookers and potential users are similarly primarily concerned with running the system on a 1.7xMHz machine.

 

On the topic of ST mice... There are several nice devices for sharing the joystick port with a mouse with either a manual switch to go between the two or automatically by pressing the fire button or mouse button. I wonder if these would work. I hate swapping devices.

 

I'm using port 2 for this very reason. Diamond did the same, IIRC.

 

Best Electronics should give you a commission on ST mice -- I'm sure they'll have a large influx of orders when your GUI nears completion.

 

Generating revenue for others by writing software is what I do.

 

Keep up the great work flash -- truly remarkable what you have done.

 

Many thanks!

Edited May 31, 2012 by flashjazzcat

[+DarkLord]

 

Best Electronics should give you a commission on ST mice -- I'm sure they'll have a large influx of orders when your GUI nears completion.

 

 

If you're gonna get an ST compatible mouse from Best Electronics, get this one:

 

http://www.best-electronics-ca.com/accesori.htm

 

Its far superior to the original ST mouse. I've got several of them, and while

a bit expensive, they are great.

[flashjazzcat]

Nice. I've got an ST trackball as well, which works great.

[doomguy]

If you're gonna get an ST compatible mouse from Best Electronics, get this one:

 

http://www.best-elec...om/accesori.htm

 

Its far superior to the original ST mouse. I've got several of them, and while

a bit expensive, they are great.

 

I already have two broken ST mice that I'm going to try to canabalize into one working one, or otherwise use Best's repair kit. I like keeping to the Atari brand as much as possible. Especially now with VBXE I can finally have a monitor that matches my XE setup.

 

And yeah, using the second joystick is nice, but even still if an old Mouse Master or similar device works, I'd be happy to be able to leave both in.

[Stormbringer]

Maybe you could sell a mouse with software/license combo when you are finished, I would expect something around $50 should be easily attainable?

[flashjazzcat]

I already have two broken ST mice that I'm going to try to canabalize into one working one, or otherwise use Best's repair kit. I like keeping to the Atari brand as much as possible. Especially now with VBXE I can finally have a monitor that matches my XE setup.

 

I hadn't considered the "original hardware" angle, and I agree an ST mouse looks nice with the XE. The XL is a different matter: all the beige mice I have look nice alongside it.

 

Perhaps replacing the tactile switches on an ST mouse will give it a better feel? I have a few lying around which I might dig out. I fixed a couple already by replacing the switches, but couldn't live with the bulky shape.

 

Re: VBXE. Definitely nice to have an SC1435 plugged into the XE!

 

Maybe you could sell a mouse with software/license combo when you are finished, I would expect something around $50 should be easily attainable?

 

Yeah, why not. Collector's pack is the ultimate goal: boxed custom cartridge with software disk and printed manual. Could throw a mouse in there as well!

[Jacques]

Currently the XEX is 29KB. This includes the demo application, three system fonts (roughly 1KB each), and a number of icons. So the system code itself is maybe 20KB in size, and JUST fits into conventional memory. I can see the kernel and core library consuming 32KB (4 x 8KB banks) pretty soon after the move to cartridge, and the finished product being quite a bit bigger than that. As much functionality as possible needs to go into the cart ROM, since the cart area is one of the few with unbuffered access to the extended memory banks.

 

Any 64KB flash ROM cartridge will be more than adequate.

 

Hmmm... I have 1088KB RAM and SIDE. You mentioned cartridge... How will I be able to use GUI with SIDE, then?

Or will there be a pure "software" version of GUI available for extended RAM machines?

Edited May 31, 2012 by Jacques

[Jacques]

<deleted double-post, sorry>.

Edited May 31, 2012 by Jacques

[flashjazzcat]

Hmmm... I have 1088KB RAM and SIDE. You mentioned cartridge... How will I be able to use GUI with SIDE, then?

Or will there be a pure "software" version of GUI available for extended RAM machines?

 

Easy: with rare foresight, I asked Candle to make SIDE emulate an external cartridge during the design stage for expressly this purpose. This is what the cartridge-based XEX loader uses, but it can also be used for any other cartridge ROM with suitable banking.

[Jacques]

That's great, thank you for clarification

[flashjazzcat]

Enough with the videos... but I thought I'd share this busy clip of four open windows in icon view:

 

 

Let's say I'm pleased with the speed. Nothing else now until there's an XEX...

[simonl]

Enough with the videos... but I thought I'd share this busy clip of four open windows in icon view:

 

Let's say I'm pleased with the speed. Nothing else now until there's an XEX...

 

Looking great, definitely in the same ballpark as an original Mac, so should be good in use

 

Cheers,

 

Simon

[Stormbringer]

Can you add in that windows7 feature that when you drag a window to the side it re-sizes it half screen?

[flashjazzcat]

Can you add in that windows7 feature that when you drag a window to the side it re-sizes it half screen?

 

Yeah, can do. And we could even do it properly, so that if you drag the window to a corner of the screen, it scales to 1/4 the size of the desktop.

[doomguy]

THAT would be awesome. I've really become used to that feature of Windows 7 -- to the point where I am frequently trying to do it in XP.

[kogden]

Looking like a lot of progress made lately lately, looking impressive as a usual!

[flashjazzcat]

Problem here is that there are so many half-finished bits of functionality in the demo, it's taking time to get everything working, and a lot of new code is being introduced. The disk-based demo isn't really geared up to being this large, but hopefully I'll be able to squeeze everything in.

 

In order to get the sample application to support different file views in different windows, for example (rather than the uniform view that applies in TOS), I've added an extra field to the window struct which the application can use as a pointer to a custom structure allocated from the heap. The sample application uses this structure to hold details about the folder view, such as the first displayed entry, the view type (list or icon), etc, etc. This seemed better than having a static table or linked list in which the saved window handle would have to be looked up.

 

Once this was implemented, a knock-on effect is that the client application now has to manage the "View" menu's check marks every time a window is topped, so that the menu reflects the status of the focused window's current view.

 

Still to do is scroll thumb "snapping" (so that the thumb positions neatly correspond to the exact column / row offset calculated by the application after dragging), although any minor cosmetic bugs resulting from view changes and window resizing may have to be left alone for the moment. A greater priority is to get leave the disk-based version behind altogether: it's a dead-end.

 

Consideration of tasking has been at the forefront of my thoughts lately, and I've been doing a lot of reading up on multi-processing methods. Contiki's protothreading is an attractive proposition (since it only requires one stack), although the applications look rather unusual since you can't have blocking dialogue managers, etc. Perhaps for coders more familiar with threading concepts it's a little easier to digest. A simple cooperative multi-tasking model at least seems useful, since most background tasks are waiting for events anyway. It would be sufficient for the application's calls to GetEvent to allow the GUI a chance to hand out events to other waiting processes. Most of the time there would be none (the most common one would simply be a "get focus" event handed to some dormant application's window), although it would be a useful way to handle timer events without complex work (for example, the clock on the menu bar could quite happily tick over while a scroll bar was being dragged without any need to interrupt any drawing operations).

 

Anyway, I consider this to be (roughly) the half-way stage in the project.

[twh/f2]

I wonder how fast the screen output performance would be for a Console/Terminal-type application. Of course it is very comfortable to drag'n'drop files with the file manager application but more complex file masking and copy'n'move operations probably would be more effective with spartados' mv and cp CLI commands.

 

I hope that the "console" is in your scope? Otherwise a "fullscreen option" like the "ALT+ENTER" keystroke in MS Windows should be available to switch on/off the normal command line.

 

Actually, it would be really cool to have a E: handler for FJC windows In that scenario clean coded text-based-programms could be available in the UI

 

*just dreaming

Edited June 5, 2012 by twh/f2

[flashjazzcat]

I wonder how fast the screen output performance would be for a Console/Terminal-type application. Of course it is very comfortable to drag'n'drop files with the file manager application but more complex file masking and copy'n'move operations probably would be more effective with spartados' mv and cp CLI commands.

 

It should be quick, especially if we use a mono-spaced "Courier" font. We then address the window via character cells (say, 6x8 pixels).

 

I hope that the "console" is in your scope? Otherwise a "fullscreen option" like the "ALT+ENTER" keystroke in MS Windows should be available to switch on/off the normal command line.

 

Certainly there'll be a CLI, and this can be as complex as necessary (scripting, etc).

 

Actually, it would be really cool to have a E: handler for FJC windows In that scenario clean coded text-based-programms could be available in the UI

 

Taking this idea a stage further, what would have been really nice is to be able to shell out to the SDX prompt (assuming we were running under SDX). SDX has everything we need to redirect the CON output to our own bespoke handler. We would then be able to run any SDX text-based application which didn't perform any direct writes to the screen RAM or hardware registers inside a window, using a small fixed-pitch font. Unfortunately (and partly because the GUI would effectively be a "child" process of SDX anyway), such a scheme throws up all kinds of nightmarish memory management problems.

 

So - I tend to think a good custom CLI which can handle subdirectories is the way to go. For stuff like drive mapping (for APT devices) and partitioning, we'll have GUI apps, but there'd be nothing to prevent folks from writing CLI utilities to do the same job.

 

Anyway: the different folder views are working:

 

Edited June 5, 2012 by flashjazzcat

[tschak909]

it's too bad that we can't...hmm..actually, what if we could intercept writes to screen memory, and then redirect them to a window? kidding.. I know that there are far too many screwy things to make that really workable... I just mentioned it to make your head explode.

 

-Thom

[flashjazzcat]

it's too bad that we can't...hmm..actually, what if we could intercept writes to screen memory, and then redirect them to a window?

 

Heh - like I say, that's no so much an issue with SDX. The problem with running the command processor as a shell is that it'll wipe out everything in conventional memory, so it's (apparently) impossible to run it alongside the GUI, which is already sitting above DOS and using every inch of RAM.

[flashjazzcat]

Good things come to those who wait... More work's been done on the Window Manager and redraws are a lot more "intelligent" now:

 

 

Redraw events shouldn't be issued when windows shrink in both directions, etc, but these are fairly routine things on the to-do list. Main thing is the Window Manager is working very consistently with a large number of windows.