New GUI for the Atari 8-bit

[UNIXcoffee928]

Tested four open windows just for kicks after debugging the window manager:

 

http://youtu.be/EwLXQzkmGi8

 

Will be a tad faster when the front window is being blitted. Should have icons in all windows and said windows extending off desktop in a few days.

 

Worth a try: If you draw the white background only for the foremost, selected window, it should make the redraw of all of the displayed objects much less noticeable.

 

Presumably, if a deselected (background window) window's whole border, and the window's contents are "ghosted", the bitmap for the window border will likely consume 50% less data, and you should see a speed boost (since you are only drawing every other pixel, then shifting over by one for the next line, in a checkerboard-like fashion).

 

Historically, redraw-performance was probably the inspiration for inventing ghosting, in the first place, on the earliest GUIs.

 

Have you experimented with translucent window backgrounds? (ones that take on the desktop's background).

 

Also, your text (under the icons on the left) will look a bit more natural if you use white for the text foreground, and a gray that matches the desktop's background, for the text's background.

 

To really speed things up & keep everything tidy, icons with no text would be ideal. Just set them up so that when you mouse over the icon it displays a "Tool-Tip" exactly the way you are currently displaying your text, with the white background. You will have much less to have to keep redrawing, every time something covers something else.

 

All together, you should see a big speed up, all around, and much less noticeable screen redraw.

 

As I said, worth a try, even if it's just for experimentation.

 

Looking forward to seeing a Right Click Pop-Up Menu that has the blinding speed of the top main menu text!

 

It's really coming along great! Thanks for all of your hard work!

[flashjazzcat]

Thanks for the suggestions! Of course I was deliberately attempting to strain the system by having four windows open. Regarding back window ghosting, etc - the reason I don't remove the stripes on the window title bars of deselected windows (as does the Mac) is that I don't really want to touch them at all. When a window comes to the front, it's just drawn over the top of everything - nothing at the back is redrawn at all. Of course, when the front window moves, then we get into the situation of redrawing the exposed areas, and then your efficiency suggestions come into their own. Diamond leaves back windows empty (although it also draws the entire desktop and all the windows from the back forward, totally differently to what's happening here). I certainly don't want to make the back windows empty: the reasoning for this will become clear when one wants to drag a selection from the front window onto a target folder in a back window, perhaps.

 

As for ghosting: that's usually achieved (here at least) by ANDing bitmap data through a chequerboard bitmask. It takes a few cycles more to do this than to actually draw the objects in full. Perhaps in higher bit-depth systems where entire bytes of bitmap data can be skipped over, savings could be made. It's worth remembering that the GUI object redraws don't call pixel rendering routines: the render code hits the screen with bytes. It's the only way to make it fast enough, but it also means we're not screen mode independent.

 

I have not experimented with transluscent window backgrounds yet, I must say.

 

Text under icons could actually be outlined / shadowed straight onto the desktop background if I can get that working quick enough. As for white on black: horses for courses, I suppose. A selected icon's label will be XORed with $FF anyway, so it depends on which is the default state and which the selected state.

 

We already hit upon some fairly obvious savings by not drawing text background pixels in areas where the background is already rendered. That happens almost all the time, in fact, so text is now ORed to the display and there's rarely any need for background masks. The "tool-tip" option makes great sense, and is something that's been on the drawing board for a while. The no-label view would be really quick to render. Of course there'll be lots of views (icon, list, detail, name only, etc), so folks will be able to tune things how they want.

 

Bear in mind there's nothing in those overlapping windows yet, though, so we're gonna see a speed reduction first. This is why I'm constantly coming up with new ideas and optimisations for getting lots of clipped material onto the screen as quickly as possible. There's obviously a limit as to what this machine can achieve, but although some compromises have to be made, part of the challenge is in making something which is usable but which hasn't made obvious concessions to the limited capabilities of the hardware (such as empty back windows, etc). Of course, anything which saves cycles is good - it's all a trade-off. Given what's going on behind the scenes to get this kind of redraw happening, if it was much faster, I'd be starting to become superstitious.

 

Anyway - thanks everyone for the comments. Helps to keep the energy levels going.

Edited March 19, 2012 by flashjazzcat

[Heaven/TQA]

this videos look awesome. and I can only imagine how much work goes into a windowed GUI. Any additional comments compared to GEOS on c64?

[flashjazzcat]

I'd recommend comparison with GEOS 2.5 which uses TopDesk 1.2 to allow multiple, movable windows. I have evaluated it in emulation. It uses a simple bottom-up desktop redraw, similar to Diamond. Performance wise, it should be noted that (AFAIK) it runs in 64KB, so the disk directories in the paged windows have to be read from disk during scrolling, which perhaps isn't unreasonable on such a tight setup.

[31336haxx0r]

Well, the disk could be a RAM disk, couldn't it? Hopefully I'm not sparking off a new (continued) debate about RAM usage here.

[flashjazzcat]

Well, the disk could be a RAM disk, couldn't it? Hopefully I'm not sparking off a new (continued) debate about RAM usage here.

 

No problem: I meant not unreasonable for GEOS running inside of 64KB. I'm keeping the directories in RAM - no ifs or buts about it.

[flashjazzcat]

Partially off-screen windows now working. At this rate of progress, once the blitter code is working and various clipping and virtual coordinate considerations are taken care of, the window manager per-se should be completely finished in a week or two.

Edited March 21, 2012 by flashjazzcat

[flashjazzcat]

Still buggy, but here it is:

 

 

Bugs are confined to masking but once they're fixed, windows will be draggable off the left edge of the desktop too, which even TOS 2.06 can't manage.

 

This is all accomplished via what is effectively a massive LUT covering a 2048 x 255 pixel area with coordinates running -1024 to 1023 in the horizontal and -54 to 201 in the vertical. However, the LUT consumes only 512 bytes. This is primarily to clip objects at the left / top - the upper range beyond 319,199 effectively being "stop" bits which cause rendering to abort at the right / bottom of the clip region.

[Ransom]

Nice!

[+Allan]

Amazing. I can't wait.

 

Allan

[Mark Wolfe]

I'm really late coming in to this, forgive me for not reading all 50+ pages... will this GUI work on my 800XL without any modifications or additions? It really looks nice and reminds me of my Mac Plus. I guess the next step is to have this running on an added hard disk or sd of some kind like AtariMax's MyIDE... is that the goal? will the gui allow you to mount floppy disc images, say if you had the gui running from MyIDE which had bunch of floppy images in the root directory... ? that would be atari 8bit heaven imho

[flashjazzcat]

I'm really late coming in to this, forgive me for not reading all 50+ pages...

 

I was leafing through the topic earlier and believe me there's a lot of valuable information in earlier posts which I've forgotten / overlooked - so it's quite understandable.

 

Will this GUI work on my 800XL without any modifications or additions? It really looks nice and reminds me of my Mac Plus. I guess the next step is to have this running on an added hard disk or sd of some kind like AtariMax's MyIDE... is that the goal? will the gui allow you to mount floppy disc images, say if you had the gui running from MyIDE which had bunch of floppy images in the root directory... ? that would be atari 8bit heaven imho

 

I'm 99 per cent certain this won't fit into 64KB, so 128KB is the probable minimum requirement. However, I have a specially designed RAM cart (the testing results for which Steve Tucker is probably growing old waiting for) which - given some inventive reworking of the memory map - may be capable of running the system on an unexpanded machine (this was the whole point of the special hardware, after all). I'd recommend an Ultimate 1MB or Mega-HZ 512MB upgrade in the short term, though. Either way, you'll need a 128KB flash cart as well (unless the GUI can be flashed to Ultimate's own banks, which doesn't look too likely from Candle's reaction to the suggestion).

 

The GUI will work entirely using standard CIO calls, so it'll handle any mass storage transparently. This includes IDE Plus, MyIDE, SIDE, etc, etc. As for image mounting: if the underlying hard disk driver provides SIO calls for volume mounting, it's doable (for instance, support for SIDE dynamic mounting or for any other system which follows the APT partitioning system is easy to implement), but other HDD systems may handle mounting solely via hotkeys or some kind of BIOS menu. I certainly intend to write a GUI version of the SIDE / APT partition editor so support for dynamic volume mounting is a logical extra step. We could have rather a nice disk map with a visual representation of all the named partitions on the HDD, and just assign drive letters to them as and when.

Edited March 23, 2012 by flashjazzcat

[Mark Wolfe]

thanks for the reply, a lot of that is over my head. I'd buy whatever upgrade was needed if I could get my Atari 800XL to behave like my Mac Plus. To be able to turn it on, have a system OS or GUI come on that shows the directory contents of whatever I have attached and then to be able to "double-click" or give some other command once the disc image in the directory list is highlighted that would then open and mount that disc image... THAT would be very cool indeed and quite an accomplishment.

 

I am not familiar with SIDE or IDE Plus, I have MyIDE but I have abandoned that in lieu of floppy emulator w/ SD slot and LCD. it lists all disc images on the SD card which can be selected and mounted. the only thing better would be something with a GUI that did the same thing

[flashjazzcat]

Well, as I say I'll support APT mounting or any other device which provides a sensible interface through the SIO. Your floppy emulator may support such commands. When the time comes, if people want to remind me on (and preferably send me documentation), I'll do my best to support the hardware in question.

 

You basically sum up one of the main goals of this project: to provide a standard graphical interface that people want to be confronted with every time they turn on the computer. There are plenty of offerings out there which implement some kind of desktop metaphor on the A8, but nothing yet which I personally want to run every time I boot up (mainly because the file managers aren't viable replacements for the DOS menu / command prompt - at least not from the point of view of productivity or performance).

Edited March 23, 2012 by flashjazzcat

[Mark Wolfe]

that is really good to hear. I have no way to supply any documentation on the sio floppy emulator. I do know the device is readily available and for a while there was being sold on ebay. I don't recall who made the one I have. I'd be happy to test from the perspective of a novice user and also support with my wallet when I can.

[Mark Wolfe]

ahh, this is the one I have: http://afs.atari.org/sio2sd.htm I bet they would share whatever documentation they have with you. although I think a completely new product may need to be produced by someone. something that would give the user the appropriate memory upgrade along with a built-in micro-sd storage solution. something discreet that does not interfere with the sio port or the cartridge port... man that would be sweet

[flashjazzcat]

Heh... how about an Atari 800 with an Incognito board? Seriously - there are a lot of great upgrades around at the moment.

 

I'm sure someone posted a full list of the SIO2SD's extended SIO command set a while back. I'm some way off needing them yet, but what you want to do is perfectly achievable from within a suitable GUI application.

[Mark Wolfe]

would you be willing to summarize what exactly an "Incognito board" is and what it does? that thread is some 20 pages long

[flashjazzcat]

Basically a personality board for the 800 which provides 1MB RAM, Internal SpartaDOS X, PBI (APT compatible) hard disk interface (with integral Compact Flash card adapter), Real-Time Clock, etc, etc. All this stuff can be turned on and off via a built-in menu. Rather a nice piece of kit.

[Mark Wolfe]

oooh nice, But I have an 800XL and am looking to get a 1200XL as my final go-to machine, does that mater?

 

has it been built yet for production? are they taking orders? how much?

[flashjazzcat]

Well, it won't fit a 1200XL. Candle stopped updates on the Incognito thread a while ago because of tomfoolery. Keep an eye on the foum, though, for further updates. Only the last few pages of the Incognito thread I showed you are "recent", so it doesn't take too long to digest it (it follows on from another project which was on hold for a long time).

[flashjazzcat]

Must start using macros more in this project:

 

add16 .macro   ; 16 bit addition
lda :1
clc
adc :2
sta :3
lda :1+1
adc :2+1
sta :3+1
.endm
;
cmps16 .macro ; signed 16-bit compare
lda :1
cmp :2
lda :1+1
sbc :2+1
bvc *+4
eor #$80 ; bmi if :1 < :2, bpl if :1 >= :2
.endm
;
...

.proc clip ; clip cx, cy to XMin, YMin, XMax-1, YMax-1
cmps16 cy,YMax ; is y >= YMax
bpl NoDraw ; object outside clipping area - return carry set
lda cy ; if not, see if any of object is inside clip region
clc
adc Height
sta ptr3
lda cy+1
adc #0
sta ptr3+1

cmps16 ptr3,YMin ; is y + height < YMin
bmi NoDraw
cmps16 cx,XMax ; is x outside right hand clipping bounds?
bpl NoDraw
add16 cx,Width,ptr3 ; is any part of object is inside clip region
cmps16 ptr3,XMin
bmi NoDraw
jmp SetUpX.Start ; we know object is partly or fully inside the clip region
NoDraw
sec ; carry set means don't render object
rts
.endp
;

 

(by the way - any idea how to prevent intenting being totally messed up when posting code here?)

 

Macro expansion aside, the clipping code above has shrunk by a factor of three since I researched a slightly more succinct signed 16-bit signed comparison than the one I was previously using. I think more liberal use of macros improves readability and lessens the scope for typos and other logic errors when the sheer volume of coding is as massive as it is here.

 

Regarding overlapping windows, we can save a lot of work by performing additional clipping based on the area vacated by a moved window and the position of any other windows in front of the window being drawn. If we clip to the vacated area, then check that objects are not entirely obscured by any windows in front (including the ultimate position of the one that moved), the amount of rendering undertaken (regardless of whether it's masked out) will be slashed. This extra clipping is all extremely cheap and is automatically avoided by objects drawn in the foremost window.

Edited March 24, 2012 by flashjazzcat

[+David_P]

So are you going to hardwire a "max windows" value, or permit users to set memory preferences? WIth each window requiring up to 8k (fullscreen), four windows could need up to 32K. On a 130xe where SDX is using a bank as well, that's only 16K expanded memory remaining.

[flashjazzcat]

Each window only requires the memory taken to hold the objects which make up its structure (up to about a dozen objects, each consuming 16 bytes, a few of which are linked to resources such as the title bar string, extra scroll bar data, etc), and whatever memory is allocated by the application to hold the content (this may be a buffer allocated from the pool to hold a disk directory, for instance, or a sub-tree of icons). This is the beauty of a smart redraw which doesn't require the windows to be cached or back-buffered. The application draws window content directly to the screen, but the GUI itself transparently takes care of clipping and masking so that foreground windows aren't overwritten.

 

So in theory, there's no particular limit on the amount of open windows, although I doubt there'll be any practical need to have more than 3-4 open at a time. The opportunity also exists to have modeless dialogue boxes floating around in front of the focused window (since we can - with very slight overhead - draw behind said dialogues).

 

I'll soon be clarifying the arrangement of extended memory with regard to resources, etc, but as a rough outline we need 1 x 16KB extended bank for the object tree array (1024 x 16 bytes), and any number of extended banks for the memory pool, from which resource memory will be allocated, housing fonts, bitmaps, icons, menu strings, etc, etc.

 

So, on a stock 130XE running SDX in the top bank, the three remaining banks are quite adequate to run the file manager (assuming it's around 16KB in size, occupying $4000-$7FFF in main RAM) with a 16KB directory / file copy buffer.

Edited March 24, 2012 by flashjazzcat

[flashjazzcat]

Here's a quick look at the window manager with some dummy content (lists of tiny filenames, which is the slowest-to-render folder view the file manager will produce) and using raster copies to move the front window:

 

http://youtu.be/HLbnhBagd9k

 

There are screen glitches caused by the opportunistic extra clipping I just added, and further clipping still to implement, which will speed up redraws even more. It will take days to implement code to handle all possible movement and resizing situations, such as windows partly off the screen scooting back onto the desktop (requiring a blit plus a partial redraw), windows focused but not covered by other windows, windows entirely obscured by others (to which no redraw event will be returned), resized windows becoming smaller on both axes (no redraw event, again)... really a lot of code to write, but it took two days' work to get the window manager to return events to the sample application properly so I may ease off on the coding for a day or two. The good news is the only thing limiting progress is the speed I can type assembly code.

 

Note interrupt-driven pipe, so your mouse actions register even when the system's busy.

Edited March 27, 2012 by flashjazzcat