New GUI for the Atari 8-bit

[flashjazzcat]

To the detriment of other overdue projects, I'm experimenting with the basics of a new GUI system for the 8-bit. The mouse handler is just about finished (the reason this is taking so long is because the mouse is drawn in bitmapped graphics rather than using a PMG, and this necessitates extra work to ensure it always remains visible even when the underlying app is drawing to the screen), and everything else should keep me busy for the next six months or so.

 

There are two reasons this project interests me:

 

1) I find GUIs intrinsically fascinating, and I always wanted to write one.

2) At the risk of courting huge criticism from those who've already written good GUIs for the 8-bit, I think the world could stand another crack at it, since mostly they've either ended up as unsupported novelties, or elaborate ways of launching text-mode applications.

 

Diamond still seems the most ambitious attempt, and I'm inclined to make the new system partly or wholly compatible with the API described in the Diamond Developers' Kit. This doesn't mean, however, that the new system will look or work the same as Diamond. I think it's a mistake to try an implement a full-blown Windows type environment that the 8-bit can't really handle. GEOS on the Commodore 64, for example, didn't have moveable or sizeable windows, and if it had been running on a 1.7MHz 6502, it would have been quite useable. So we won't necessarily see overlapping windows, scroll bars, and the like with my system. It will be a framework for writing consistent applications which utilize a uniform mouse/menu/dialogue interface.

 

The system will also use proportional fonts, which is a good compromise between readability and maximising screen real-estate. Whether it will end up on a cartridge or not, I don't know. There's a huge amount of work to do and when I get a blank desktop with a working menu bar across the top of it, I'll know I'm getting somewhere.

 

The intention is to release it with a GUI version of The Last Word, plus a simple notepad type program, a handful of accessories, and a decent file manager. Being realistic at this stage in the game, life's too short to write a bunch of big applications on my own, so one of my most difficult tasks is going to be making this system attractive and accessible to the handful of programmers who might be inclined to write their own apps.

 

We can look at what happened to Diamond, which to my knowledge never had a single third-party application written for it. Perhaps my own effort will go the same way. I'd like from the offset, though, to get opinions from interested parties. What kind of GUI would you have liked to have seen twenty years ago on the Atari? What would you like such a system to do now? Do you think it's a waste of time?

 

I'd love to hear your views.

 

 

 

[analmux]

...and this necessitates extra work to ensure it always remains visible even when the underlying app is drawing to the screen...

 

Well, a first thought could be executing the mouse-drawing routines at the end of a VBI, and make sure all other drawing commands are finished before that.

 

Another solution could be to monitor the y-position of the mouse-softwaresprite and do a timed interrupt right before the corresponding rasterline. The interrupt itself will draw the mousepointer. Then do some other stuff (like computing something) when the video chip is displaying the pointer. After the last line of the pointer another GFX task could be started, but it would never affect the already displayed pointer.

Edited December 6, 2009 by analmux

[+Stephen]

Looking forward to whatever you come up with. Although, no matter how cool this ends up being, my main appeal of the 8-bit is lack of a GUI. But, I like seeing the machines pushed past what they were designed for.

 

Stephen Anderson

[+Philsan]

You already know I am a big fan of this project.

One question, just for curiosity.

Why don't you use PMG for pointer? Perhaps because you want an high resolution pointer?

[walter_J64bit]

Are you saying that the your apps for you new OS are going to be compatible with Diamond? If So I like to see this. :thumbsup:

[flashjazzcat]

Well, a first thought could be executing the mouse-drawing routines at the end of a VBI, and make sure all other drawing commands are finished before that.

 

Another solution could be to monitor the y-position of the mouse-softwaresprite and do a timed interrupt right before the corresponding rasterline. The interrupt itself will draw the mousepointer. Then do some other stuff (like computing something) when the video chip is displaying the pointer. After the last line of the pointer another GFX task could be started, but it would never affect the already displayed pointer.

I've solved this problem by channeling the application's output to a small back-buffer if it hits the mouse. On the visible screen, the mouse pixels are drawn over the new screen data on the fly, and when it moves, the necessary data to restore the background is already in the buffer. The mouse is drawn during the VBI.

 

You already know I am a big fan of this project.

One question, just for curiosity.

Why don't you use PMG for pointer? Perhaps because you want an high resolution pointer?

Pretty much as you say: I want half-colour clock x resolution, and for the mouse pointer designs to be two-colour (black and white) and quite detailed.

 

Are you saying that the your apps for you new OS are going to be compatible with Diamond? If So I like to see this.

It might end up going that way: it depends if the feature set ends up allowing everything Diamond did (i.e. scroll bars, overlapping windows). A compatible API with a better looking interface is certainly an appealing option.

[flashjazzcat]

Crap... having problems already. By the time I got the bitmasking working for the pointer (in the VBI), that plus the DLIs to sample the mouse have thoroughly overloaded the system. I can see why a PMG is the preferred mouse pointer, owing to the minimal processing. I'd forgotten just how few cycles can be crammed into the DLI.

 

 

 

[phaeron]

Crap... having problems already. By the time I got the bitmasking working for the pointer (in the VBI), that plus the DLIs to sample the mouse have thoroughly overloaded the system. I can see why a PMG is the preferred mouse pointer, owing to the minimal processing. I'd forgotten just how few cycles can be crammed into the DLI.

 

What about only activating the mouse sampling DLIs if the VBI routine notices a change in the joystick port? Won't solve the whole problem, but it'd help when the user is typing.

[Rybags]

That's an interesting concept that might work well. Default sampling at 50 Hz, then ramp up to 100, 150, 200 or whatever's needed.

 

I'm sure someone (might have been Heaven) posted some time ago a quick mouse movement algorithm that could quickly be adapted between Amiga/ST mouse types.

[andym00]

That's an interesting concept that might work well. Default sampling at 50 Hz, then ramp up to 100, 150, 200 or whatever's needed.

 

I'm sure someone (might have been Heaven) posted some time ago a quick mouse movement algorithm that could quickly be adapted between Amiga/ST mouse types.

 

How about the fast pot scan mode, where the caps charge over only 2 scanlines ? Then you'd have a known worst case cost to expend on the AD conversion.. Don't know how the fast mode is reflected in terms of accuracy though..

[Rybags]

Amiga/ST mice use the joystick directional lines... it's the Commodore mouse for the 128 that uses Pots.

 

In some ways, that would be better. Only need to read once per frame, supposedly it gives a delta X/Y value that you only have to scale then adjust your pointer with.

[Heaven/TQA]

yeah. it was me posting the mouse code... It was on my old website... maybe I have a look on google and see...

[Heaven/TQA]

http://atariwiki.strotmann.de/xwiki/bin/view/Code/STMouseDriverforBasic

[Velcro_SP]

I would like a GUI desktop where I can launch a binary (like Atari Tennis or BobTerm for example) via icon double-click. I would like then to be able to terminate it, perhaps by escape key or key-combination, and end up back on the desktop without reboot. The icons would be assigned automatically for all files, with simple images perhaps even 8x8 or 16x16 to start appearing automatically, and different based on file-type. One would be able to rename, move, and delete the files via the icons.

 

I guess a drawer paradigm is most practical. The user creates drawers on the desktop and can move files in and out of the drawers by moving the icons. Android OS makes use of a labeling paradigm, however. There might be some advantages to going with that, but I don't know if it applies and I don't quite understand it yet.

 

I encourage you to go as simple as possible each step of the way, and get the memory and other requirements down-down-down, so that the new GUI may even run on a 48k 800 or 400. Good luck!

[andym00]

Amiga/ST mice use the joystick directional lines... it's the Commodore mouse for the 128 that uses Pots.

 

In some ways, that would be better. Only need to read once per frame, supposedly it gives a delta X/Y value that you only have to scale then adjust your pointer with.

 

 

Ah, didn't realise that it was about using an Amiga/ST mouse! Oops.. I'll shut up now

 

 

[Rybags]

I haven't mentioned it yet... go interlaced.

 

Then there's plenty of room for the cute but still readable smallish fonts.

 

One barrier to overcome though is keeping it active when SIO is going... but I might have an idea or two there.

[flashjazzcat]

What about only activating the mouse sampling DLIs if the VBI routine notices a change in the joystick port? Won't solve the whole problem, but it'd help when the user is typing.

I'll look into that if I don't have any luck with what I'm working on (see below).

 

http://atariwiki.str...eDriverforBasic

Thanks!

 

I would like a GUI desktop where I can launch a binary (like Atari Tennis or BobTerm for example) via icon double-click. I would like then to be able to terminate it, perhaps by escape key or key-combination, and end up back on the desktop without reboot. The icons would be assigned automatically for all files, with simple images perhaps even 8x8 or 16x16 to start appearing automatically, and different based on file-type. One would be able to rename, move, and delete the files via the icons.

 

I guess a drawer paradigm is most practical. The user creates drawers on the desktop and can move files in and out of the drawers by moving the icons. Android OS makes use of a labeling paradigm, however. There might be some advantages to going with that, but I don't know if it applies and I don't quite understand it yet.

 

I encourage you to go as simple as possible each step of the way, and get the memory and other requirements down-down-down, so that the new GUI may even run on a 48k 800 or 400. Good luck!

That's an interesting interface metaphor. I absolutely agree with the last point: The system is growing from the mouse pointer upwards: everything's going to be as tight as Hell. I am giving some thought, however, to utilising extra memory on expanded machines. Diamond used a virtual memory driver which yielded (for example) 64K of text space in Diamond Write. Great!... But it was deadly slow. I'll probably put all the resident code in a 16K extended bank until we get into cartridges, etc (I have no experience of cart programming, BTW). The resident library will ideally contain not only the user interface routines and API entry points, but also a general graphics library with line draw, circle, fill, etc. So applications shouldn't need to be weighed down with proprietary code to do common tasks. The windowing system will also use a 16K bank for heap space (saving the screen RAM behind windows), so clearly an expanded machine will be a must. That said, I can see the appeal of something which would run on the older machines: however, I think that will be a cartridge-based code scenario. I'm already roughing out ideas for the event handler, how to set up dialogues, etc. Optimisations will include a dialogue/window's workspace always being on byte boundaries to speed things up, etc. The text entry control will be fairly sophisticated and may include mouse selection and cut/copy/paste. A clipboard would be nice. Although simplicity is the watchword, a suitably complex text box control could make the creation of a simple text editor as easy as sticking a multi-line control in a window (in much the same way as it's possible in Windows).

 

Speaking of exiting apps back to the desktop, how does something like Diamond accomplish this when an application jumps through DOSVEC?

 

I haven't mentioned it yet... go interlaced.

 

Then there's plenty of room for the cute but still readable smallish fonts.

 

One barrier to overcome though is keeping it active when SIO is going... but I might have an idea or two there.

A possibility, although I'd prefer to do this in VBXE's 640x200 mode in order to maintain the pixel aspect ratio. Just imagine that screen real estate.

 

Speaking of VBXE, it goes without saying that eventually a display driver will allow this system to take advantage of the VBXE graphics modes and blitter, etc. But that's a long way off yet.

 

Back to the mouse and pointer: I'm going to have one more crack at it using the DLI/VBI/blitted pointer system I've been working on. It occured to me that pre-rendering the mouse pointer in all 8 positions across two horizontal bytes will save a ton of cycles. This pre-rendering will be done whenever the routine is called which loads up a new mouse shape/mask. This only costs a page of RAM. I coded it up on paper today and it looks like the VBI will consume at most 1,200 machine cycles if it erases and redraws the mouse pointer in a new position. Surely that will work???

[+Philsan]

Another Atari ST mouse routine.

The 8bit Mouse.zip

[flashjazzcat]

Phew... finally got the mouse pointer working. I had to trim the DLIs down to 500 samples per second to offset the larger VBI routine. Unsure how much these interrupts will affect main program speed at the moment, so I may have to rework the interrupt sampling.

 

Not much to see: just a hi-res pointer you can move, and it's all interrupt driven with pre-rendered mouse images and masks. The main code just goes into an empty loop after doing the setup. Some bounds checking doesn't work yet, x won't go past 255, and so on. Move pointer over the inverse text to see the pointer outline.

 

Mouse.zip

 

It would be nice to do a 16x16 mouse pointer: then we could do an exact copy of the ST's bumble-bee, for example. That may just be too much for the VBI, however (16 loops instead of 8 for draw and erase, plus 3 bytes of shifted data per line instead of 2). The pointer won't look as tiny in 8x8 when the fonts are proportional, though.

 

Next update will be the text changing and being printed "under" the pointer when you click on it. The only precaution I'll need to take is to set a flag to prevent the VBI drawing the mouse in a different position for the dozen or so cycles when the main program is writing to a byte under the pointer (and also to the pointer back-buffer).

 

Only another 1,000 hours work and we'll have a brand new WIMP system for the 8-bit.

Edited December 8, 2009 by flashjazzcat

[Curt Vendel]

If you're really going to look to get people to use your GUI - you need to consider coding a good wordprocessor and terminal program to give your environment something useful to run under it.

 

 

 

Curt

 

 

Phew... finally got the mouse pointer working. I had to trim the DLIs down to 500 samples per second to offset the larger VBI routine. Unsure how much these interrupts will affect main program speed at the moment, so I may have to rework the interrupt sampling.

 

Not much to see: just a hi-res pointer you can move, and it's all interrupt driven with pre-rendered mouse images and masks. The main code just goes into an empty loop after doing the setup. Some bounds checking doesn't work yet, x won't go past 255, and so on. Move pointer over the inverse text to see the pointer outline.

 

Mouse.zip

 

It would be nice to do a 16x16 mouse pointer: then we could do an exact copy of the ST's bumble-bee, for example. That may just be too much for the VBI, however (16 loops instead of 8 for draw and erase, plus 3 bytes of shifted data per line instead of 2). The pointer won't look as tiny in 8x8 when the fonts are proportional, though.

 

Next update will be the text changing and being printed "under" the pointer when you click on it. The only precaution I'll need to take is to set a flag to prevent the VBI drawing the mouse in a different position for the dozen or so cycles when the main program is writing to a byte under the pointer (and also to the pointer back-buffer).

 

Only another 1,000 hours work and we'll have a brand new WIMP system for the 8-bit.

[flashjazzcat]

If you're really going to look to get people to use your GUI - you need to consider coding a good wordprocessor and terminal program to give your environment something useful to run under it.

Well, hadn't thought about the terminal (good idea, though), but further up this topic I mentioned that I intend to release the GUI with:

 

A GUI version of The Last Word

A handful of small apps (control panel, notepad, such like)

A good file manager

 

The file manager may, however, simply be intrinsic to the desktop (like the ST). I don't know yet. The Last Word will be the "killer" app, though. I envisage it working with small and large fonts, akin to "Newsroom", although I doubt it will be absolutely WYSIWYG. There's a lot to be said for the separation of text composition and typesetting.

Edited December 8, 2009 by flashjazzcat

[walter_J64bit]

I like to add one thing, it was over looked when Diamond was made, you can't run any programs that needs "Translator" this is one App. that should had been looked into when Diamond was made.

Edited December 9, 2009 by walter_J64bit

[Rybags]

I don't see Translator as any sort of issue - any game or application worth having should have been XL fixed by now.

[Urchlay]

I would like a GUI desktop where I can launch a binary (like Atari Tennis or BobTerm for example) via icon double-click. I would like then to be able to terminate it, perhaps by escape key or key-combination, and end up back on the desktop without reboot.

 

That would be a neat trick, on an Atari. Most games assume they own all the RAM in the machine, especially ones that were converted from cartridge like Tennis. There's a good chance that any random game will overwrite your GUI system (either the GUI code itself, or the memory it's using for whatever data structures it needs while running). Without hardware support for protected memory pages, there's not much the GUI code could do about it...

 

However, a thought... If the entire GUI (code and data both) could be made to fit in XE extended RAM banks, plus a modified OS ROM that handles switching the extended banks on and off, then you could run any software that doesn't use XE extended banks (or anyway doesn't use the same ones the GUI is using). The boot process would sort-of resemble the original Atari ST (before TOS was in ROM, the built-in ROM would load TOS from floppy and store it in "write-once RAM" or somesuch).

 

The actual program-loader code would have to be in the OS ROM, and it would switch the GUI's RAM banks out (and main system RAM in), then load the program from disk the way Atari DOS does, and execute it.. Once the app is running, the GUI code would NOT be running at all, so the app could do whatever it wants to any part of RAM (so long as it doesn't switch in the banks the GUI's code and data live in), and the GUI would be able to pick back up where it left off when the app exits...

 

Your "terminate app" key would have to be the Reset button, but it wouldn't have to cause a full reboot. Maybe the ROM code could checksum the extended banks to make sure they haven't been diddled with by application software, and force a hard reboot if they have (so you could still load/run programs that use the XE banks, it would just take a long time and maybe a floppy swap to "exit" from them).

 

I think SpartaDOS X already does some or all of what I'm thinking about here (it doesn't use a modified OS ROM, but it's a cartridge, so it doesn't need to), but I don't know much about SDX. Probably nothing I'm rambling about here counts as a new idea (for one thing, it's a bit like MTOS)..

[Cebus Capucinis]

Looking very forward to seeing how this turns out! A GUI would push the limits of the system to the very max and would make lots of leaps & bounds improvements that would be astonishing to see. Modifying existing code for a loader for binary files would be the easiest part of the plan, I would think. It would be really cool to just click on those ROMs and have some gaming goodness!