New GUI for the Atari 8-bit

[flashjazzcat]

One tiny request - can you please make this at least joystick compatible? That way I can use my CMI08 adapter, and the code won't have the overhead of directly handling the mouse.

Hmmm... tricky without implementing some kind of mouse pointer. Imagine this system as a greatly simplified version of the Windows UI's keyboard interface: Tab for next field, Shift+Tab for previous field, etc. I suppose it might be possible to use the up/down cursor keys to move between fields, with some careful redesign. The fire button could then be mapped onto Return...

 

If you wait six months to a year, of course, the whole thing will hopefully run in bit-map mode with proportional fonts, mouse pointer, click-regions, etc (plus the keyboard shortcuts).

[+bob1200xl]

That is very nice...

 

What kind of code is that? Where is the rest of it? (is it available?)

 

Bob

 

 

 

 

One tiny request - can you please make this at least joystick compatible? That way I can use my CMI08 adapter, and the code won't have the overhead of directly handling the mouse.

Hmmm... tricky without implementing some kind of mouse pointer. Imagine this system as a greatly simplified version of the Windows UI's keyboard interface: Tab for next field, Shift+Tab for previous field, etc. I suppose it might be possible to use the up/down cursor keys to move between fields, with some careful redesign. The fire button could then be mapped onto Return...

 

If you wait six months to a year, of course, the whole thing will hopefully run in bit-map mode with proportional fonts, mouse pointer, click-regions, etc (plus the keyboard shortcuts).

[Mclaneinc]

Is it finished yet??

 

 

[flashjazzcat]

That is very nice...

 

What kind of code is that? Where is the rest of it? (is it available?)

Thanks.

 

That's MADS Assembler. FDISK is 100% relocatable SpartaDOS X binary.

 

The other 3,000 lines are on my PC. When the library is finished, I'll make it available as an SDX DLL, and probably as an open-source INCLUDE library for other systems.

 

Is it finished yet??

 

 

Nearly. I'm considering re-coding the file selector to use the dialogue controls (at the moment, the selector is all hard-coded with custom routines). Plus there are numerous other keyboard shortcuts to implement.

[puppetmark]

Very very Cool!

 

Nice work

[+Stephen]

One tiny request - can you please make this at least joystick compatible? That way I can use my CMI08 adapter, and the code won't have the overhead of directly handling the mouse.

Hmmm... tricky without implementing some kind of mouse pointer. Imagine this system as a greatly simplified version of the Windows UI's keyboard interface: Tab for next field, Shift+Tab for previous field, etc. I suppose it might be possible to use the up/down cursor keys to move between fields, with some careful redesign. The fire button could then be mapped onto Return...

 

If you wait six months to a year, of course, the whole thing will hopefully run in bit-map mode with proportional fonts, mouse pointer, click-regions, etc (plus the keyboard shortcuts).

Ah - if the original design is to be keyboard only, I am fine with that. I still prefer keyboard shortcuts to mouse on my PC.

[flashjazzcat]

With any kind of dialogue interface like this, it's always tempting to reach for the mouse. But we're not there yet, and I don't want to get mixed up about what I'm trying to achieve (namely a ready-made interface for text mode applications). Mouse interaction will require scroll bars for drop-down lists, command buttons, etc, and it all gets much more complicated. These things will come later.

 

With the text mode UI library, one should be able to code up the framework of a menu-based app with dialogues and file selectors pretty quickly. It's designed for keyboard operation, and the absence of a pointing device will be compensated for to some extent by sensible shortcuts: for example, letter keys will take you to the first menu option starting with that character, and in dialogues, <CTRL+KEY> will action the control whose label begins with that character. In order to keep the interface clean, the shortcuts won't be highlighted; one may simply assume that this is how it works. There are no command buttons, either. At the top level, <Return> is equivalent to "OK", while <Esc> equates to "Cancel". The only exception is if you're in a drop-down list, in which case <Return> selects the current entry and closes the list.

 

It's possible to get away with a very small number of controls on a machine this size. Text input (with a number-only option), check boxes, and static and drop-down lists cover most bases. Mutually exclusive options (handled by grouped "radio buttons" in Windows) are best covered by a drop-list.

 

The next program to get the UI treatment will be a text editor, and the fancy interface should not impede its usability. To find a string using the menu, the sequence will be: <Esc> (activate menu bar), <E> (Edit), <F> (Find), <enter string>, <Return>. Add <Tab>, <Space> to that in order to toggle the "reverse search" checkbox. Of course, you'll also be able to get the find dialogue direct from the editor with <CTRL+F>.

 

Naturally this library works with Drac030's S_VBXE and GR8 drivers, and repositions the dialogues in 80 column mode:

 

Edited December 31, 2010 by flashjazzcat

[Mathy]

Hello Jon

 

Why not contact Mirko Sobe, he did something similar in TurboBASIC. See this video. Mirko's site can be found here: http://www.atarixle.de which seems to be available only in German, but I know Mirko speaks English too. Mirko is still improving his BOSS-X GUI.

 

sincerely

 

Mathy

 

PS Tom Hunt also wrote a GUI, it's called ATOS. But I'm not sure if Tom is still active in the Atari 8 bit scene.

Edited December 31, 2010 by Mathy

[flashjazzcat]

Hi Mathy

 

I'm aware of (and impressed by) Boss-X, although I really want to write something from the bottom up in machine code. Perhaps Mirko could offer some help and/or suggestions, though. Any forms of inspiration are useful.

 

By the way: the video is great. I love the use of PMG overlays in Boss-X.

 

I recall ATOS as well. I've downloaded and tested just about every GUI ever written for the Atari, but the closest to what I want to achieve is Diamond. I had some very promising discussions with Alan Reeve a while ago, but sadly they came to nought (he was supposedly going to send me the source code for Daimond 3 on the understanding I would update it, along similar lines to what Drac030 and Trub have done with SDX). It certainly would have accelerated the deveopment cycle.

Edited December 31, 2010 by flashjazzcat

[flashjazzcat]

This took quite an alarmingly long time to code up, mostly due to silly bugs:

 

 

guitest1.xex

 

Click in the text area to invert it.

 

It should work OK on NTSC as well as PAL (the sampling rate is varied according to the VBLANK interval), and the mouse movement is, I think, very smooth considering the pointer is a software sprite. However, this is down to a high sampling rate, and I begin to wonder how this is going to impact on the performance of the rest of the system.

 

The pointer is rendered during the stage 2 VBL (NTSC didn't seem to like using stage 1), and the mouse sampled via a DLI as before. Much of tonight's work has been done getting Mr Fish's proportional font onto the screen. But the really tricky bit is the put/get byte to screen routine, which masks data which falls under the mouse pointer. It's quite an expensive routine (as demonstrated by the speed of the box XOR routine), but I just wanted to see if it could be done. Whether it will be practical to use this approach when drawing the drop-down menus (next on the to do list), it remains to be seen. I may have to go the ST route and turn off the pointer when drawing the menus.

 

There's a bug in the syncronisation of the screen writes and mouse interrupt: sometimes, if the mouse "creeps" when you have the button held down, there'll be screen corruption. I attempted to get round this by settting a movement inhibit flag and storing a value in WSYNC at the same time, but it still doesn't work 100% of the time.

[Mathy]

Hello Jon

 

Check out the mouse files on my special stuff page.

 

sincerely

 

Mathy

[atarixle]

I am impressed by the Graphics 0 GUI you're making, especially the combo-boxes ... I never really implemented useful combo-boxes, even if they are available in the BOSSXGND.BOS framework program.

 

Unfortunately, I can't offer much help, as I don't have much experience with the Assembler language. Only thing I can offer is all the Artwork I made for BOSS-X (like fonts, icons, may be file-formats for INI-files, wallpapers). You can use it, it's free.

[flashjazzcat]

Check out the mouse files on my special stuff page.

This is the mouse driver I'm using in the demo.

 

I am impressed by the Graphics 0 GUI you're making, especially the combo-boxes ... I never really implemented useful combo-boxes, even if they are available in the BOSSXGND.BOS framework program.

 

Unfortunately, I can't offer much help, as I don't have much experience with the Assembler language. Only thing I can offer is all the Artwork I made for BOSS-X (like fonts, icons, may be file-formats for INI-files, wallpapers). You can use it, it's free.

Many thanks! The artwork would probably be useful in the bitmapped GUI: I envisage having to design a lot of fonts, icons, etc. Hopefully I can rely on the help of Mr Fish too...

 

Be aware that there are two distinct development strains going on here: the text mode UI (more or less finished), and a full GUI (as demonstrated by the demo above). The full-blown GUI is something of a proof-of-concept, since I doubt it will be all that useful in the real-world until a lot of software has been written for it, and that will either take years or not happen at all. I can probably do the shell, file manager, control panel, and text editor. That would basically make it a very pretty shell for launching programs and managing files. Part of its purpose is also to realize something that looks at least as good as GEOS on the C64, but runs faster and works a bit more like Windows.

 

I'm investing a lot of thought into how to make the bitmapped GUI run quickly enough to be useful. There's already a table of screen RAM line addresses, keeping all the multiplication to a minimum. The mouse pointer is pre-rendered, also, as are the masks, so every time you change the mouse shape, all the bit-shifted images will be pre-drawn before the image changes on the screen. I'm considering keeping the windows and menus byte-aligned, to greatly simplify Z-processing and optimize any clipping I decide to implement.

 

One area of uncertainty with the bitmap GUI is still the fonts. Currently I have two bitmapped proportional fonts to play with. I also have code for rendering Borland CHR vector fonts, but I can't imagine vector fonts being practical for this application. Certainly the "system" font needs to be bitmapped. Other than that, a means needs to be found to quickly convert ready-made bitmapped fonts (GDOS, for example) into a format suitable for the 8-bit. For the moment, however, there are plenty of other things to do.

 

Coming back to the text-mode UI: I don't yet have what I'd call a combo-box (which I understand to be a text-entry box with a drop-down list), but I intend to implement one. This would be great for something like a history list for search and replace.

[flashjazzcat]

I've updated the little demo so that the panel now cycles through three different states when you click on it:

 

mouse3.xex

 

(Note the mouse needs to be in port 2).

 

The improvement here is that you can now hold the button down while moving the mouse around. The pointer floats undisturbed over the screen writes going on behind it. It jumps a little because although the mouse sampling is undisturbed, mouse drawing is necessarily suspended when a byte is being written to or read from the screen (this is to avoid the case of an interrupt occuring and changing the back-buffer while the write/read routine is busy referencing it).

 

I promise the next demo will be a bit more exciting: namely a menu bar using proportional fonts and text effects. I'm still working out how to implement the event handler for dialogue box controls.

 

I notice (from a quick look at Steem) that TOS on the ST masks the mouse pointer in this way when drawing the drop-down menus, but completely turns of the mouse when updating other elements of the screen (for example, when clicking on a drive icon). Presumably the slower method is used for menus for the sake of aesthetics. I'm happy to follow suit...

Edited January 3, 2011 by flashjazzcat

[Shawn Jefferson]

I've updated the little demo so that the panel now cycles through three different states when you click on it:

 

Looking good.

 

I promise the next demo will be a bit more exciting: namely a menu bar using proportional fonts and text effects. I'm still working out how to implement the event handler for dialogue box controls.

 

Any good gui is going to need to be event driven, for sure. You could look at Contiki for one method of doing an event-driven GUI on an 8-bit platform. Also, Allegro (the programing library) also has a neat event-driven method for it's built-in GUI, as well as an "object-oriented" paradigm, making it easy to customize the different GUI pieces in your own programs. Adapting that idea to the 8-bit may be a bit of challenge though.

[atarixle]

I'm using a fast-text-routine written by Peter Dell now, it's much faster than the meanwhile 11 years old (and also damn fast) routine by Ron Hamilton ... so or so, these routines are much faster than the one from your demo, so may be you want to use the one I use in BOSS-X, but I only got the machine code (don't have the sources here). I think, Peter is active in this forum too ... username JAC in ABBUC-Forum (and I think here too) ... PM him for the sources.

 

Generally, I think GUIs that support current technologies are always useful. Like BOSS-X supports MyDOS' sub-directories, it's useful to find files and folders on 16 MB disks and images. The links you can make on the desktop help you to arrange frequently used programs, which can be a lot and hidden between useless files on a 16 MB disk.

 

You can say what you want, GUIs have to look nice, and they help you to manage large storages, so even if you just create a graphical file-manager for SpartaDOS, this will be a huge helpful application for users who work with this DOS.

Edited January 4, 2011 by atarixle

[+MrFish]

Unfortunately, I can't offer much help, as I don't have much experience with the Assembler language. Only thing I can offer is all the Artwork I made for BOSS-X (like fonts, icons, may be file-formats for INI-files, wallpapers). You can use it, it's free.

Many thanks! The artwork would probably be useful in the bitmapped GUI: I envisage having to design a lot of fonts, icons, etc. Hopefully I can rely on the help of Mr Fish too...

I'm still onboard. Doing the fonts, icons, and gui elements should be a blast.

 

I would still like to get the original proportional font design in there, which has full ascenders, rather than the chopped down version that we stuffed into the Atari font format.

 

 

I'm still up for either building a unique font editor or creating a utility that will convert bitmapped drawings into a font file, unless you're planning on utilizing some other preexisting format.

[Syfo-Dyas]

I'm thinking a VBXE compatible GUI would do the trick! Either way, I'm always eager to see new GUI's for the Atari. Too bad our CPU is too slow for the task. :/

[Mathy]

Hello Mirko, guys

 

I think, Peter is active in this forum too ... username JAC in ABBUC-Forum (and I think here too) ...

 

Peter (Dell) is active as peter.dell here on AtariAge.

 

sincerely

 

Mathy

[flashjazzcat]

Looking good.

 

...Any good gui is going to need to be event driven, for sure. You could look at Contiki for one method of doing an event-driven GUI on an 8-bit platform. Also, Allegro (the programing library) also has a neat event-driven method for it's built-in GUI, as well as an "object-oriented" paradigm, making it easy to customize the different GUI pieces in your own programs. Adapting that idea to the 8-bit may be a bit of challenge though.

Handy links: thanks. I know what needs to be done, but the methods tend to present themselves during the design stage. For example, the control methods for the text-mode dialogue boxes became quite elegant as I coded them up: on the first refresh pass, all the controls are drawn, but on subsequent tab-key entry into a control, it enters its edit state. This is easily controlled with a single flag, which all control routines observe, and either draw the control in a static state, or enter the edit stage. The main loop takes care of wrapping things up when you tab to the next field. This becomes a little more complicated with a mouse pointer system (although the keyboard control will be preserved), mainly because the access to controls is non-linear. The only real question is whether a control in the edit state should incorporate its own loop, polling the event handler, or whether the main dialogue loop should poll the event handler and feed keystrokes/mouse clicks to the active control. It's a subtle point, but I'm sure the most efficient method will soon become apparent.

 

I'm using a fast-text-routine written by Peter Dell now, it's much faster than the meanwhile 11 years old (and also damn fast) routine by Ron Hamilton ... so or so, these routines are much faster than the one from your demo, so may be you want to use the one I use in BOSS-X, but I only got the machine code (don't have the sources here). I think, Peter is active in this forum too ... username JAC in ABBUC-Forum (and I think here too) ... PM him for the sources.

 

Generally, I think GUIs that support current technologies are always useful. Like BOSS-X supports MyDOS' sub-directories, it's useful to find files and folders on 16 MB disks and images. The links you can make on the desktop help you to arrange frequently used programs, which can be a lot and hidden between useless files on a 16 MB disk.

 

You can say what you want, GUIs have to look nice, and they help you to manage large storages, so even if you just create a graphical file-manager for SpartaDOS, this will be a huge helpful application for users who work with this DOS.

I'll certainly PM Peter. Bear in mind that although the rendering routine I've written is pretty efficient, it is slowed in the demo both by the interrupt driven mouse, and the masking routine (which makes the text appear "under" the pointer). The masking routine replaces simple STA (SCR),Y and LDA (SCR),Y with two expensive subroutine calls, both of which establish whether the target location is behind the mouse pointer, and perform all the writing to/reading from the back buffer if that is the case. Even when the target byte isn't behind the pointer, the X,Y coordinates still have to be checked, and this takes a little time. That's why I'll only use the masked routine when drawing the drop down menus, but I'll turn off the mouse in all other situations (if the mouse pointer is removed from the screen, the rendering routines automatically use the "fast" option). I think the text rendering will be dramatically faster with the mouse switched off.

 

I'm still onboard. Doing the fonts, icons, and gui elements should be a blast.

 

I would still like to get the original proportional font design in there, which has full ascenders, rather than the chopped down version that we stuffed into the Atari font format.

 

 

I'm still up for either building a unique font editor or creating a utility that will convert bitmapped drawings into a font file, unless you're planning on utilizing some other preexisting format.

That's good to hear! We can quickly knock-up a font format with a header describing the baseline, cell width, height, etc. That way, we can have a font which has 8-bit wide chars which occupy, say, 12 lines. The routine to calculate the character width table from your original "PROPSANS" font is quite interesting in itself. The only problem I had was with the lower case "I", until I realize you'd left 1 bit of padding on the left of the character. I removed it, and all was well.

 

If we could get some kind of conversion chain going where we could quickly produce proportional bitmapped fonts in various sizes (maybe up to 32 x 32 pixels maximum) with built-in character width data, that would be a weight off my mind. Borland CHR stroke fonts would be nice, but I see no practical way to use them throughout the system. GEOS was absolutely agonizing to watch as it rendered those fonts. Much easier to blit characters to the screen straight from the font buffer. Of course, italicisation, emboldening, etc, can all be accomplished reasonably well on the fly using bitmapped fonts.

 

Icons will probably come in 8x8 and 16x16 flavours - possibly larger ones, too, for icon view file windows. I fancy having little visual cue icons next to some menu entries.

 

I'm thinking a VBXE compatible GUI would do the trick! Either way, I'm always eager to see new GUI's for the Atari. Too bad our CPU is too slow for the task. :/

It would be nice to make the system device-independent as far as the screen display is concerned, but we really need to use game/demo tech to get this system to run anywhere near fast enough. Once the version for stock machines is working, maybe it wouldn't be too hard to create a VBXE version.

 

As for the CPU: it's going to be a struggle, especially since I've taken the decision to use (or at least cater for) proportional fonts. But the whole objective is to see if it can be made to work, and work fast, using all the dirty tricks in the book. I believe it can. Boss-X shows what can be done in Turbo Basic.

 

Something as simple as "Notepad" running in a window and using proportional fonts is a good test of practicality. The editor window can't be fully redrawn after each keystroke, but I already have optimisations in mind to make responsive editing possible.

 

Oh - almost forgot. Are there any real advantages to using a POKEY timer instead of a DLI for sampling the mouse? It really needs to be sampled at least 500 times per second (yes, that's right), but I thought using a POKEY timer might "spread out" the sampling somewhat. With a DLI, SIO is handled OK: CRITIC will disable the stage 2 VBL (preventing the mouse from re-drawing), which sector I/O will (usually) turn off the DLI bit. But what precautions are required prior to SIO transfers when using a POKEY timer for a mouse interrupt?

Edited January 4, 2011 by flashjazzcat

[danwinslow]

Oh - almost forgot. Are there any real advantages to using a POKEY timer instead of a DLI for sampling the mouse? It really needs to be sampled at least 500 times per second (yes, that's right), but I thought using a POKEY timer might "spread out" the sampling somewhat. With a DLI, SIO is handled OK: CRITIC will disable the stage 2 VBL (preventing the mouse from re-drawing), which sector I/O will (usually) turn off the DLI bit. But what precautions are required prior to SIO transfers when using a POKEY timer for a mouse interrupt?

 

I don't know specifically, but I wound up using a pokey timer. I thought that in order to get a fast enough sampling rate I'd need to have multiple DLI's and I was concerned that I would block myself from complete freedom of screen design. Plus, as you mentioned, the POKEY timer seemed to be more deterministic. I didn't do anything special about SIO and it seems to work ok.

Edited January 4, 2011 by danwinslow

[flashjazzcat]

I don't know specifically, but I wound up using a pokey timer. I thought that in order to get a fast enough sampling rate I'd need to have multiple DLI's and I was concerned that I would block myself from complete freedom of screen design. Plus, as you mentioned, the POKEY timer seemed to be more deterministic. I didn't do anything special about SIO and it seems to work ok.

OK: I'll give it a go. I've never used the timers before, but I guess it can't be that difficult. The idea is to spread the sampling out; at the moment, the mouse is read around a dozen times per frame, but I guess that means the sampling is all bunched up before the VBL.

 

The Allegro source code is very interesting. Looks like I was thinking along the right lines with regard to feeding dialogue controls "messages" from the event handler. Naturally the methods used in Allegro will have to be drastically shrunk and simplified for the 8-bit.

 

I've been pondering most of the day about how a text editor using proportional fonts might handle horizontal windowing, which is bound to crop up if a word processor ever gets written (the horizontal resolution of the Atari being far too low to accomodate a full document). One decision I've already made is to keep viewports on byte boundaries. It may also be wise for the text editor to make use of a routine which renders entire lines, and only hooks up to the screen when the first visible column is reached. This way, you could display an x-offset into the page. We can also keep a list of pointers to the beginnings of lines of text in RAM, and checking for changes to avoid unnecessary screen writes (LW already does this). Then there's the other trick, which never got implemented in The Last Word: the idle time screen refresh, which just abandons the screen redraw after printing the current line if the user has pressed another key.

[atarixle]

I'll certainly PM Peter. Bear in mind that although the rendering routine I've written is pretty efficient, it is slowed in the demo both by the interrupt driven mouse, and the masking routine (which makes the text appear "under" the pointer).

 

Ok, I disregard that the mouse-driver is running all the time. In fact, BOSS-X stops the mouse-driver completely, if it's not waiting for a users interaction. Additionally, BOSS-X used PM-graphics for drawing the mouse-cursor, so it's much easier for the Atari to handle this.

 

Attaching some screenshots of my fonts, you're free to use.

[flashjazzcat]

Thanks for those: they're really nice fonts. If we can blow a few of those up to 16x16 and then smooth out the blocky upscaling, it would offer a good starting point for handling the larger point sizes.

 

Does Boss-X calculate the character widths on the fly? That's what my demo's doing at the moment.

 

Single-pixel mouse resolution and a hi-res bitmapped pointer are kind of a must for this challenge, as is free mouse movement when the system is busy. I understand I'm making life difficult for myself. The menu/dialogue system and event handler is all mapped out in my head now: just a question of coding it all up. The big question mark hangs over text editor screen redraw, though. I'm going to have to take a completely fresh approach to redrawing a screen full of proportionally spaced text (possibly with assorted point sizes). I wish I could find the sources for GEOWrite, just to see how they approached the problem.

[twh/f2]

It seems that the 8bit atari is hardware-wise not very well prepared for the amiga/st mouse concept. it's a pity to see, that we waste rare cpu time for old fashioned equipment. of course, the advantage is that technically a Amiga/ST mouse can be connected easily. The other approach would be to use the microUSB expansion ( http://microusb.org/ ) .. I onced tried the Generic USB mouse-driver. It is simply fantastic and very fast, because you get from the USB device simply x-/y-deltas. Furthermore I could use any modern laser mouse and it had a very simple programing model. see here:

 

http://wiki.strotmann.de/wiki/Wiki.jsp?page=ProjUSBCartAtariMouse

 

What I'm saying is that there should be the possibility to deactivate the legacy-Amiga/ST mouse support and so that a USB user could have performance benefits.

 

grtx,

\twh!