New GUI for the Atari 8-bit

[fibrewire]

Got the stripped-down character renderer working as fast as I can manage today, and here it is filling a window with simulated "real world" content:

 

http://youtu.be/n8BnTrssMFI

 

So what do you call it? The Fuji Joystick Cursor environment?

 

The GUI looks great!

[flashjazzcat]

Looks very good. It takes what? A second or less to draw all the text on that window?

 

I've been watching some videos about the original Macs and they are definitely faster, but without having the two side by side doing the same thing it's difficult to say how much faster the Mac is.

 

Yeah - I run Vmac all the time to get ideas and check performance. The thing that struck me after I spent most of the day tuning the renderer so the 18 point font filled up the window like lightning was that switching to a smaller font slowed things down a lot. I guess that should be expected, since we're suddently rendering about 400 characters as opposed to fifty or so and therefore we're doing a lot more subroutine calls and the speed of the individual character blits has less of an overall impact. However, the effect is the sum of its parts and if overheads hadn't been ironed out everywhere it would take twice as long to fill a window.

 

I'm constantly surprised by how fast this thing is running, but realistically we can't hope to match a machine with an 8Mhz 16-bit CPU. Nevertheless, we're doing masked and clipped rendering operations using proportional fonts with Pokey interrupts and a DLI running at the same time, so we're not doing too badly. One comforting realization is that the font window will be blitted when it's moved, so even without caching only the back windows will have to redraw their content. Top window blitting would not have been possible with the bottom-to-top desktop render as used by Diamond, GEOS 2.5 and the early versions of our GUI demo. We can also make liberal use of blitting when scrolling content.

[Bryan]

It'll be interesting to develop an app for such an environment. So, what kind of basic stuff would we need? Calculator? Reversi? NotePad? SimCity?

[flashjazzcat]

It'll be interesting to develop an app for such an environment. So, what kind of basic stuff would we need? Calculator? Reversi? NotePad? SimCity?

 

That'll be when the fun really starts. I'm under instruction to write a text editor as soon as the file browser is up and running.

[flashjazzcat]

Interesting to compare the latest video with TOS in hi-res:

 

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

 

Like our system will, TOS makes heavy use of the blitter when doing partial scrolling of window content. Of course, TOS is using a monospaced font on an 80 column grid.

Edited March 5, 2012 by flashjazzcat

[AtariNerd]

I guess I kind of assumed (very dangerous that) , that you'd somehow encorporate a special version of TLW or at least create a version that would take its functionalty, but create a new interface/skin that would work within the GUI's browser. It seems kind of a natural. Perhaps, though, something a bit more stripped down, like you suggest, would better serve. I know it's about us finding function, as well, but TLW, to put any false modesty aside, is such a "killer ap".

[+DarkLord]

Hmm, it looks like TOS 1.62 or less there, as far as the icons go, just making

sure you weren't actually running NeoDesk/Geneva were you?

[flashjazzcat]

I guess I kind of assumed (very dangerous that) , that you'd somehow encorporate a special version of TLW or at least create a version that would take its functionalty, but create a new interface/skin that would work within the GUI's browser. It seems kind of a natural. Perhaps, though, something a bit more stripped down, like you suggest, would better serve. I know it's about us finding function, as well, but TLW, to put any false modesty aside, is such a "killer ap".

 

Kind of you to say so. But yeah - I fully intend to write LW version 4 (?) for the GUI. The text editor (stripped down, as you say, and ideal for coding or any jobs using a uniform text size) is just a warm-up for what will be a much more ambitious project. TLW for the GUI will present the most intimidating challenge of all: a word processor using some degree of WYSIWYG editing with multiple fonts and text styles in the editing window. I've been mulling over approaches to various aspects of that program for several months now. It will be the GUI's "killer app". However, this will likely consume all of my spare time, so aside from the text editor and perhaps a SIDE partition editor, I'll be reliant on other coders (such as the capable MrFish!) to take on the job of writing accessories and applications.

 

Looking at The Last Word as it stands, the very full-featured disk menu / file selector and the code necessary to drive the interface take up a good chunk of the program. Replace that with the GUI file selector and API calls for menus, fonts and all the screen furniture, and the core codebase should shrink dramatically. Here the benefits of a unified interface become apparent from a developer's point of view.

 

In any case, the more ambitious the goals, the better. The whole point of the project is to make the machine do things it hasn't done before.

 

Hmm, it looks like TOS 1.62 or less there, as far as the icons go, just making

sure you weren't actually running NeoDesk/Geneva were you?

 

It's TOS 2.06 running on Steem (4MB, 8Mhz). NeoDesk is nice, though: live scrolling list boxes, etc... perhaps doable.

Edited March 5, 2012 by flashjazzcat

[kogden]

Wow that last GUI text rendering demo was quick! I can see rewrites of old mac games in the future....Daleks.....Banzai....muahahahaha

Edited March 6, 2012 by kogden

[flashjazzcat]

I think MrFish is keen to write some games for it. But the full arsenal of speed-up tricks will be required to keep things running fast. For instance, a real file browser will be generating file sizes and time/date stamps from raw directory data in memory (unless we choose to read from disk and hold fully formatted directories in the buffer, which would not be space efficient and would make switching "views" from icon / detail / list, etc, cumbersome). This will mean additional work to produce formatted decimal numbers. The PRINTF routine (as seen in The Last Word, and similar to that used by SpartaDOS X and most C libraries) will have to be the most efficient possible (faster than LW's). Given we'll be on a cartridge, throwing LUTs at everything should work out well.

[fibrewire]

Can you make an .xex of your latest demo for Altirra?

[Bryan]

Any chance it could support wide playfield for expanding beyond 320?

[flashjazzcat]

Can you make an .xex of your latest demo for Altirra?

 

Soon enough. I don't like releasing buggy stuff.

 

Any chance it could support wide playfield for expanding beyond 320?

 

Doubtful, since the display RAM is at a premium. In any case, were a large scrolling desktop to be implemented (doubtful), it would likely be accomplished by other means.

[flashjazzcat]

Any chance it could support wide playfield for expanding beyond 320?

 

Doubtful, since the display RAM is at a premium. In any case, were a large scrolling desktop to be implemented (doubtful), it would likely be accomplished by other means.

 

It seems I completely misunderstood this question (thanks to MrFish for pointing that out). A wide playfield could be used - in theory - to give a horizontal resolution of 384 pixels, although the practical limit would be significantly lower. Still, on a CRT we might get an extra 8-16 pixels in either direction with a bit of tube adjustment. A couple of things put me off the idea, though. Firstly, we're talking about an extra 200 x 8 (1,600) bytes of frame buffer, unless we have an LMS on every scanline and overlap the lines so that maybe 44 instead of 48 bytes per line are used. Secondly, TFT monitors are generally far less flexible when it comes to making the overscan region visible. Thirdly, I'm wondering what the effect of the extra DMA would be on the blocking DLI mouse pointer renderer...

 

We might get a "safe" eight pixels or so either way, but I wonder if it's worth it.

[Bryan]

It would be a neat feature to add 8 or 16 (plus controls for top and bottom) in a Control Panel type setting, but don't make it a priority. Sometimes you need all the desktop you can get, though.

[flashjazzcat]

Well, although variable length screen lines would mean a lot of constants (and thus immediate mode instructions) in the source code going up in smoke, I'll bear this request in mind.

[Rybags]

Probably not worth it insofar as DMA/memory penalty. Although you can squeeze out some of the DMA by using high HScrol values.

 

Modern LCDs should actually cope better with the overscan areas. I've only had my 1200XL on my LCD briefly so didn't get around to testing the bounds.

 

What might work better is a scrolling desktop in the vertical direction. Then the cost is only the extra memory and a bit more programming.

Although that said, it might be unappealing. I've tried the virtual scrolling desktop available with some PC graphics drivers and don't like it.

[fibrewire]

I know this has been covered before, but I am *REALLY* hoping that any caching routines involving things beyond Atari 800 48K will be made as autodetect. This includes reading directories from disk, virtual desktops, or any features that benefit from lookup tables that use extra RAM. Even if it is a half-functional version that has to run from a floppy to accomplish this. Please!!!

[+MrFish]

Sometimes you need all the desktop you can get, though.

 

Having 4 screens tied to a single PC, I totally agree with this.

[flashjazzcat]

Probably not worth it insofar as DMA/memory penalty. Although you can squeeze out some of the DMA by using high HScrol values.

 

Modern LCDs should actually cope better with the overscan areas. I've only had my 1200XL on my LCD briefly so didn't get around to testing the bounds.

 

What might work better is a scrolling desktop in the vertical direction. Then the cost is only the extra memory and a bit more programming.

Although that said, it might be unappealing. I've tried the virtual scrolling desktop available with some PC graphics drivers and don't like it.

 

Both 5:4 and 4:3 TFTs I have would manage maybe 8 extra pixels at either side before cutting off, and there's no control over that. The more modern widescreen I have of course allows setting of the aspect ratio, but even then it trims the 4:3 box pretty close.

 

What I quite fancy (and it would be the most memory efficient solution) is a number of different desktops which can be swapped in at will. You could have one rigged up for games, one for productivity, etc. This doesn't address the problem of screen resolution, though. I could easily bump up the vertical resolution beyond the current 200 lines, although I actually feel that 320x200 is the best compromise in terms of AR and the work required to redraw the screen. Even if we (at some point in the future) took advantage of VBXE 640x200 mode, a 400 line interlace would be essential since I don't regard 1:2 pixel ratios as that attractive. Nice for fitting an 8" wide page on the screen, but it would look like Panavision on a 4:3 TV set (i.e. ST medium res).

 

I know this has been covered before, but I am *REALLY* hoping that any caching routines involving things beyond Atari 800 48K will be made as autodetect. This includes reading directories from disk, virtual desktops, or any features that benefit from lookup tables that use extra RAM. Even if it is a half-functional version that has to run from a floppy to accomplish this. Please!!!

 

As I mentioned before, use of the Shadow RAM might be unavoidable and so one may have to be equipped with an Incognito board. I'll do what I can, but some kind of extended memory at the very least is a must. More flexibility would be possible if I insisted that all applications are written using MADS' relocatable format, but that blocks out C developers. So we're looking at applications compiled at $4000-$7FFF, with as many 16KB blocks of code and data as needed. This leaves the cart space, an 8KB frame buffer, and interrupt routines, LUTs, and "fast RAM" between $2000-$3FFF. We also need somewhere to put the mask buffers, which can't be in extended memory.

 

I was testing GEOS on a 64KB emulated Commodore the other day, and GeoWrite crapped out when I tried to copy more than a few lines of text, demanding I inserted a blank floppy. I was then unceremoniously dumped back onto the desktop. If coding within the bounds of 48K means emulating that experience on the Atari, it's an experience I can do without. I'd rather have something which takes advantage of 128KB and is fast and usable. I think it's understood that even GEOS is far more agreeable on an upgraded machine. We have the advantage of raw CPU grunt on the Atari, and since sprites and colour aren't a concern here, Mhz and RAM are what matter. That's not to say that a GUI running on a stock 800 wouldn't have an ephemeral "wow" factor. I just think for the thing to actually be usable (and that's surely what we want), the XE personality board will be the way to go.

[potatohead]

This makes a lot of sense. Back in the day, running on a 48K machine would matter in terms of potential users. Now? Might as well make it work well. In fact, the opposite is likely true now. Something that works well, actually drives users toward machines that can deliver the experience.

[twh/f2]

The mouse pointer movement looks very smooth while the screen is redrawn.. very impressive !! i think this gives a positive user experience.

 

It's good idea to compare the speed with TOS or other GUI's of the 80's .. I personally forgot how painfully slow TOS was at the time (so was probably win3.1 on my AT286). Your GUI is almost as fast as the TOS but does not require 1MB and M68000

 

great work btw. One of the most fascinating threads in this forum...

 

grtx,

\twh

[Chilly Willy]

I have two 65XEs, an 800XL, and a 400 with 64K... so requiring extra ram means I'd have to try to get an expansion for one of the systems. I have an 8Mb MaxFlash cart, so using cart space (for code) instead of ram space would work for me.

 

In any case, I really think you're doing an excellent job here. You're getting great performance from such an old system.

 

In case you didn't want to scan through the thread, I'm the one testing your releases with an Amiga Boing! 3-button optical mouse... original Dale Luck version, not the newer converted PC mouse version. The last version I ran on my 65XE worked so great it was amazing.

[flashjazzcat]

The mouse pointer movement looks very smooth while the screen is redrawn.. very impressive !! i think this gives a positive user experience.

 

It's good idea to compare the speed with TOS or other GUI's of the 80's .. I personally forgot how painfully slow TOS was at the time (so was probably win3.1 on my AT286). Your GUI is almost as fast as the TOS but does not require 1MB and M68000

 

great work btw. One of the most fascinating threads in this forum...

 

grtx,

\twh

 

Thanks! Having a mouse pointer which moves freely while other stuff is going on was a big priority for me, and I had the best help here figuring out a unique solution. It surprises me that the system remains as nippy as it does with all those interrupts firing.

 

I've paid close attention to my Amiga 500+, ST and the "classic" mac (the latter in emulation) in order to gauge performance. Obviously the operating systems of those machines suffer a little from the overheads of being developed in C / Pascal (with critical parts written in assembler), although Mac OS was admirably compact. I guess we can come close to the performance of those systems in some areas via very tight code optimisation in pure machine code. Development of commercial 16-bit systems in pure machine code was prohibitive and probably unnecessary. It's essential for a 6502 implementation, though.

 

I have two 65XEs, an 800XL, and a 400 with 64K... so requiring extra ram means I'd have to try to get an expansion for one of the systems. I have an 8Mb MaxFlash cart, so using cart space (for code) instead of ram space would work for me.

 

Using a cart for the code works for me too, but GUIs are pretty data-heavy things. This is a true object-oriented system which uses a right-threaded binary tree as a "database" of all the menus, windows, icons and controls. 16KB of RAM houses a database of 1,000 objects (which won't be overkill for complex applications). Then we need at least two system fonts for the UI (1-2KB each), somewhere to put the icon bitmaps and masks, system buffers, etc. And we need 16KB (at least) for the desktop manager application, and space to store all the drop-down menu items, disk directory buffers, dialogue resources, etc, etc. It all seems a little unlikely to happen in 64KB at the moment.

 

In any case, I really think you're doing an excellent job here. You're getting great performance from such an old system.

 

Thank you!

 

In case you didn't want to scan through the thread, I'm the one testing your releases with an Amiga Boing! 3-button optical mouse... original Dale Luck version, not the newer converted PC mouse version. The last version I ran on my 65XE worked so great it was amazing.

 

Brilliant!

Edited March 8, 2012 by flashjazzcat

[Gunstar]

Sometimes you need all the desktop you can get, though.

 

Having 4 screens tied to a single PC, I totally agree with this.

 

I wonder if it might be possible to have this GUI running on two screens in the case of an Atari with VBXE installed? I'm not up to snuff on what exactly the VBXE does, but if it's possible to have RGB and composite/s-video outputs to two monitors at the same time and have desktop cross-over that would rock!