Jump to content

Photo

New GUI for the Atari 8-bit


2643 replies to this topic

#1 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 8,178 posts
  • Location:United Kingdom

Posted Sun Dec 6, 2009 2:56 PM

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. :)




#2 analmux OFFLINE  

analmux

    Stargunner

  • 2,091 posts

Posted Sun Dec 6, 2009 3:10 PM

...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 by analmux, Sun Dec 6, 2009 3:11 PM.


#3 Stephen OFFLINE  

Stephen

    River Patroller

  • 4,591 posts
  • A8 Gear Head
  • Location:Akron, Ohio

Posted Sun Dec 6, 2009 4:14 PM

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

#4 Philsan OFFLINE  

Philsan

    River Patroller

  • 2,738 posts
  • New Orleans Saints Super Bowl XLIV Champions
  • Location:Switzerland

Posted Sun Dec 6, 2009 4:18 PM

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?

#5 walter_J64bit OFFLINE  

walter_J64bit

    River Patroller

  • 4,045 posts
  • Location:Goldsboro NC

Posted Sun Dec 6, 2009 5:28 PM

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: :thumbsup:

#6 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • Topic Starter
  • 8,178 posts
  • Location:United Kingdom

Posted Mon Dec 7, 2009 2:57 AM

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. Posted Image Posted Image

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. :)

#7 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • Topic Starter
  • 8,178 posts
  • Location:United Kingdom

Posted Mon Dec 7, 2009 10:37 AM

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.




#8 phaeron OFFLINE  

phaeron

    Stargunner

  • 1,146 posts
  • Location:USA

Posted Mon Dec 7, 2009 10:00 PM

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.

#9 Rybags OFFLINE  

Rybags

    Quadrunner

  • 12,581 posts
  • Location:Australia

Posted Mon Dec 7, 2009 10:11 PM

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.

#10 andym00 OFFLINE  

andym00

    Stargunner

  • 1,036 posts
  • Location:A geordie cowfield...

Posted Tue Dec 8, 2009 4:30 AM

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..

#11 Rybags OFFLINE  

Rybags

    Quadrunner

  • 12,581 posts
  • Location:Australia

Posted Tue Dec 8, 2009 5:15 AM

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.

#12 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 8,837 posts
  • Location:Baden-Württemberg, Germany

Posted Tue Dec 8, 2009 5:17 AM

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

#13 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 8,837 posts
  • Location:Baden-Württemberg, Germany

Posted Tue Dec 8, 2009 5:23 AM

http://atariwiki.str...eDriverforBasic

#14 Velcro_SP OFFLINE  

Velcro_SP

    Chopper Commander

  • 132 posts
  • Location:Universe

Posted Tue Dec 8, 2009 5:52 AM

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!

#15 andym00 OFFLINE  

andym00

    Stargunner

  • 1,036 posts
  • Location:A geordie cowfield...

Posted Tue Dec 8, 2009 5:56 AM

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 :)



#16 Rybags OFFLINE  

Rybags

    Quadrunner

  • 12,581 posts
  • Location:Australia

Posted Tue Dec 8, 2009 6:31 AM

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.

#17 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • Topic Starter
  • 8,178 posts
  • Location:United Kingdom

Posted Tue Dec 8, 2009 12:46 PM

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???

#18 Philsan OFFLINE  

Philsan

    River Patroller

  • 2,738 posts
  • New Orleans Saints Super Bowl XLIV Champions
  • Location:Switzerland

Posted Tue Dec 8, 2009 1:02 PM

Another Atari ST mouse routine.

Attached Files



#19 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • Topic Starter
  • 8,178 posts
  • Location:United Kingdom

Posted Tue Dec 8, 2009 2:08 PM

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.

Attached File  Mouse.zip   859bytes   330 downloads

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. Posted Image

Edited by flashjazzcat, Tue Dec 8, 2009 2:10 PM.


#20 Curt Vendel OFFLINE  

Curt Vendel

    River Patroller

  • 4,441 posts
  • Location:Carmel, New York

Posted Tue Dec 8, 2009 2:32 PM

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.

Attached File  Mouse.zip   859bytes   330 downloads

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. Posted Image



#21 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • Topic Starter
  • 8,178 posts
  • Location:United Kingdom

Posted Tue Dec 8, 2009 2:38 PM

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 by flashjazzcat, Tue Dec 8, 2009 2:39 PM.


#22 walter_J64bit OFFLINE  

walter_J64bit

    River Patroller

  • 4,045 posts
  • Location:Goldsboro NC

Posted Tue Dec 8, 2009 8:06 PM

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 by walter_J64bit, Tue Dec 8, 2009 8:11 PM.


#23 Rybags OFFLINE  

Rybags

    Quadrunner

  • 12,581 posts
  • Location:Australia

Posted Tue Dec 8, 2009 8:08 PM

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

#24 Urchlay OFFLINE  

Urchlay

    Stargunner

  • 1,131 posts

Posted Tue Dec 8, 2009 9:51 PM

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)..

#25 Cebus Capucinis OFFLINE  

Cebus Capucinis

    Not-so-secretly Trolling

  • 8,013 posts
  • Wiseass Extraordinaire
  • Location:Ellensburg, WA

Posted Tue Dec 8, 2009 9:58 PM

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!




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users