New GUI for the Atari 8-bit

[walter_J64bit]

Sorry about the lack of progress with this, but I've used all my spare time over the weekend finishing my SIO2SD case. Once that's done (which should be tonight), that's it for the hardware mods for the time being.

 

I found out today that my full-time job is not being extended beyond Christmas, so I'll have some time on my hands in a couple of weeks to get stuck into the GUI (and other stuff I've promised people I'd get around to).

Awesome! :thumbsup:

[flashjazzcat]

Sorry about the lack of progress with this, but I've used all my spare time over the weekend finishing my SIO2SD case. Once that's done (which should be tonight), that's it for the hardware mods for the time being.

 

I found out today that my full-time job is not being extended beyond Christmas, so I'll have some time on my hands in a couple of weeks to get stuck into the GUI (and other stuff I've promised people I'd get around to).

Awesome!

Yep - great for my programming, not so great for the bank balance!

 

My wife's already finding things for me to do after Christmas: paint the staircase and the bathroom, assemble new furniture, do the cleaning while she's at work. In between this, hopefully I'll be putting in six hours a day on the Atari, so we should see the kind of progress I can only dimly recall this time last year when I first started revising The Last Word. Then in March I started a full time job, which pushed a June release date back by nearly six months. Believe me, I'm going to make hay while the sun shines until I find gainful employment!

[flashjazzcat]

It took me some staring at the screen to understand the code I'd written only a month ago, but having looked at Arc OS the other day, I decided to redesign the mouse pointer and cater for double-byte x-coordinates. The mouse shape/mask can now be up to 16 lines high, but I've shaved a pixel width off the Arc OS mouse shape to keep the mouse renderer from having to do too much work (otherwise the pre-rendered bit-shifted masks would have been three bytes wide instead of two). I may experiment with three byte wide pre-rendered shapes (this would allow for 16x16 pixel mouse pointer resolution), but that's a lot of fiddly work and it can wait till later. It must be remembered that all the mouse drawing/background restoration is done during an interrupt, so economy is critical.

 

The only fundamental improvement to the mouse renderer yet to be implemented is shaving off the MSB/extra lines when the mouse hits the right hand edge or bottom of the screen. MOUSE.XEX works especially well in Altirra (which wisely shuts off the system pointer when capturing the mouse):

 

Mouse.xex

 

Amazing how foreign stuff I wrote only a month ago looks now; however, the proportional font renderer (utilizing Mr Fish's specially created fonts) shouldn't take too long to code up, so hopefully I'll be in direct competition with Jose for screen mockup output in the coming months.

 

Y co-ord checking needs tidying up too...

Edited January 24, 2010 by flashjazzcat

[phaeron]

The only fundamental improvement to the mouse renderer yet to be implemented is shaving off the MSB/extra lines when the mouse hits the right hand edge or bottom of the screen. MOUSE.XEX works especially well in Altirra (which wisely shuts off the system pointer when capturing the mouse):

 

Mouse.xex

 

 

Neat. Seems to be some periodic VBI overrun problem on NTSC; doesn't happen on PAL. Profiler says you've got about 75% of the CPU remaining after display and mouse interrupts, based on time spent in the idle loop:

[flashjazzcat]

Balls... This seems to be happening with the older, slimmer version on page 1 of this topic as well. Well done for being the first to spot the NTSC problem. I figure the best way around it is to reduce the number of DLIs under NTSC so the total number of reads per jiffy * VBLANKs is equal on both TV standards. That will keep the mouse response consistent and hopefully smooth things out. The mouse sample rate is about 600 times a second at the moment.

 

Where's this profiler to be found? Looks indispensable.

Edited January 24, 2010 by flashjazzcat

[phaeron]

Where's this profiler to be found? Looks indispensable.

 

Work in progress.

[flashjazzcat]

Where's this profiler to be found? Looks indispensable.

Work in progress.

Tantalising...

 

This one has about ten samples per jiffy, so still around 600 per second under NTSC, and appears to cure the VBI overrun:

 

MausNTSC.xex

 

However, screen jumps occasionally in Altirra. No way of testing using real hardware, so this would be appreciated. If jittery screen persists, only option is to savagely optimise interrupt routines themselves (which I'd probably do anyway). Everything's pointing to the VBI routine being too long now, rather than the DLI. If you can unleash the profiler...

 

For info, the rendering loop does 16 lines for calculation convenience rather than the 12 necessary to draw the mouse. If necessary, I'll just knock it back down to 12 and that will shave a couple of thousand cycles off.

Edited January 24, 2010 by flashjazzcat

[flashjazzcat]

Reducing the iterations to 12 works in Altirra:

 

USMOUSE.xex

 

...Dying to pull down a menu with this mouse pointer.

 

Edited January 24, 2010 by flashjazzcat

[Rybags]

If your Immediate VBlank runs too long, the Stage 2 VBlank (esp on NTSC) might be delayed to the point where the Display List pointer is being copied from the shadow register too late.

 

That can cause screen jumping since the display has already started, then you suddenly get the case of part of it being repeated.

[flashjazzcat]

If your Immediate VBlank runs too long, the Stage 2 VBlank (esp on NTSC) might be delayed to the point where the Display List pointer is being copied from the shadow register too late.

 

That can cause screen jumping since the display has already started, then you suddenly get the case of part of it being repeated.

That's evidently what was happening. The new version works well and there should still be enough cycles left for a keyboard buffer.

 

Although a VBXE version of this system will make many optimisations obsolete, for the "standard" version I was considering the idea of pre-rendering the proportional font in its eight bit-shifted positions, in the same way I've done with the mouse pointer. For a 1K proportional font, this would neatly translate into a 16K extended bank's worth of data. With a couple of extra tables, it should then be possible to get a character on the screen with negligible effort.

 

The GUI will need to detect whether it's running on PAL or NTSC hardware: I'll reach for Mapping later, but I do recall there's a register which holds this info???

Edited January 25, 2010 by flashjazzcat

[Rybags]

PAL register in GTIA.

 

Other alternatives - run your stuff in Deferred VBlank.

 

Or just dispense with the OS VBlank altogether... it's surprising how slim you can make it if you dispense with stuff you don't need.

[atarixle]

some ideas from my old unfinished project, graphics primitives, line (dot line), box, fillbox (fill with shape 8x8 pixels), pmgbox (underlay pmg), circle etc.

How do I take a look onto this .obx file?

Edited January 25, 2010 by atarixle

[flashjazzcat]

PAL register in GTIA.

 

Other alternatives - run your stuff in Deferred VBlank.

 

Or just dispense with the OS VBlank altogether... it's surprising how slim you can make it if you dispense with stuff you don't need.

Considered deferred vblank but it would be nice to have the mouse pointer movable while disk activity is taking place (esp with "hourglass" pointer). Having said that, will be interesting to see if DLIs still work during SIO. In any case, the interrupt seems to work as is so time to move on to the next step.

[Rybags]

Keep the DLIs trim and they should be OK.

 

But when you ramp up SIO speed the whole game changes. I'd suspect even a worst-case DMA situation might upset SIO once the speed gets really high.

[flashjazzcat]

Keep the DLIs trim and they should be OK.

 

But when you ramp up SIO speed the whole game changes. I'd suspect even a worst-case DMA situation might upset SIO once the speed gets really high.

Yep - that's exactly what happens with the DLI in LW 3.1 if you ramp the SIO rate right up. SDX, for example, clears the DLI enable bit when the baud rate is beyond a certain value. Forcing the bit "ON" during the VBLANK would likely cause data corruption. So I think we'll just have to play it by ear: if I need a more long-winded interrupt I'll just migrate to the deferred VBLANK and the mouse pointer will harmlessly stop moving during disk I/O.

Edited January 25, 2010 by flashjazzcat

[flashjazzcat]

I've been thinking about this GUI project again recently. What really inspired me today was testing out the PenPal word processor on the Amiga 500 Plus. I recognized lots of redering optimisations already present in The Last Word, including stuff like dispensing full screen redraws when the typing rate is high. Overall, however, the thing ran slowly: reminiscent of Diamond Write on the Atari. I honestly believe something faster can be done on the A8.

 

Apart from lack of time, one thing holding me back from getting on with the GUI project is the lack of a good, large font collection. We really need a ready made library of proportional fonts in various sizes which I can just plug into the software. It would be great if someone else could take care of that. I already have Mr Fish's excellent system font, but since I want to build larger fonts into the system from the get go, I could use some help. It doesn't have to be right now, or this week, or month even...

 

Another goal is to keep the interactions with the screen device independent without being slow. This would allow a device driver to use - for example - 640x400 VBXE mode. VBXE has a lot of underused resources and if a GUI could be made to pick up on the blitter, extra colour depth, where available, the system would really fly on upgraded machines.

 

I suppose it all rests on how much interest there is in a project like this. It's certainly a large undertaking and I wouldn't have any drive to work on it if it was just going to be a case of a couple of people contributing and testing and half a dozen people downloading the finished product.

 

Some people have pointed out that since the Atari is inherently not GUI based, there's hardly much point in making it so. However, I enjoy a challenge...

 

Oh... and Rybags: can you recall your ideas regarding interlace mode and SIO?

Edited July 12, 2010 by flashjazzcat

[Rybags]

Interlace should be able to be coaxed to work with a user-written SIO at least in 1x speed, higher speeds could be a problem.

 

Best approach might be to have a Timer IRQ triggered inside the VBlank, since the normal method I use of just waiting on VCOUNT won't work with SIO going on.

 

The code that runs in the 3.5 scanlines around VSync time is pretty critical and can't be interrupted... 1x SIO = a byte received roughly every 8 scanlines so it should be OK. 2x SIO might very well be pushing things too far.

 

Alternatively, Interlace can be just turned off for a while, if you leave the character set or bitmap toggling going on, you still get a perception of enhanced resolution.

 

I think the later version I did of MemoPad 480i allowed turning various stuff off with the console keys, so you could try that to see how it'd look.

 

 

Another idea might be to do all the SIO using Polling Mode (no IRQs). An alternate Interlace routine could then be written, it just becomes a case of careful cycle-counting so that SERIN and no SERIN conditions equate to equal time. Really you probably only need to check if data is waiting once per scanline, so it'd probably work fine then even with 3x SIO speeds.

Edited July 12, 2010 by Rybags

[flashjazzcat]

Even more to consider than I'd expected, then. If I were writing an OS from the ground-up, a custom SIO routine would be doable, but really I just want the system to sit on top of DOS a la Windows 3.1. Still, if a workaround could be effected it would look pretty cool. I can't wait to see what VBXE 640x400 looks like with a proportional character set. I was surprised by some of the high RGB resolutions the Amiga can pump out through a SCART cable; one of which is a 500 line interlace, of course.

 

I just wish I had time to have a good run at a basic pull down menu and windowing system.

[Rybags]

There's the big problem. Keeping such things standard insofar as letting DOS do things it's way.

 

About the only workaround I can see is to have part of the OS at least copied to RAM so that SIO calls could be intercepted and replaced with your own, but that's only good for DOSes that use standard SIO calls @ 19.2k/sec.

And since there's all those variants out there, you may as well have to copy the entire OS just for the sake of changing half a dozen bytes for the purpose.

 

Taking over the Immediate IRQ vector might work in some cases. It could possibly work as some kludge to do standard SIO calls in a polled fashion, but I've got real doubts about it working with DOSes that do their own SIO - plus you also need to cater for various sector sizes... there's the sector size variable in OS RAM but I doubt many DOSes would bother to set/use it.

Edited July 12, 2010 by Rybags

[flashjazzcat]

There's the big problem. Keeping such things standard insofar as letting DOS do things it's way.

 

About the only workaround I can see is to have part of the OS at least copied to RAM so that SIO calls could be intercepted and replaced with your own, but that's only good for DOSes that use standard SIO calls @ 19.2k/sec.

And since there's all those variants out there, you may as well have to copy the entire OS just for the sake of changing half a dozen bytes for the purpose.

 

Taking over the Immediate IRQ vector might work in some cases. It could possibly work as some kludge to do standard SIO calls in a polled fashion, but I've got real doubts about it working with DOSes that do their own SIO - plus you also need to cater for various sector sizes... there's the sector size variable in OS RAM but I doubt many DOSes would bother to set/use it.

We could liaise with all the DOS writers and release custom SIO drivers for every operating system...

 

I imagine SDX will be used a lot, and that has its own SIO routine. Worrying too much about this could become a distraction from the real job of getting the interface written. The timing issues during SIO operations are a real pain: that's why I had to do a major rewrite when I started using high baud rates with the word processor. Although in that case, I could have gotten around the problem if I'd had room to use PMGs for colour changes.

 

On top of all this, we have a DLI/VBI driven mouse eating up cycles. I can't see interlace happening somehow.

[UNIXcoffee928]

...

I've been thinking today about data structures and the general architecture of the window manager. It's very hard to find good texts on the theory of this stuff so I would appreciate any pointers (no pun intended). I assume I'm leaning in the right direction by implementing a stack of clickable regions: basically, these regions will be scanned, from foreground window to back (thus dealing with overlapping windows) on a mouse click, yielding an ID of the region clicked. The event handler will then match the ID against any controls it needs to deal with itself (scroll bar dragging, window swaps, focusing on dialogue controls, etc), and if not, it will finally return the X,Y and region ID (along with click type) to the application if it's within the workspace area.

 

It seems a good idea to keep the click regions and controls/window data structures separate (relating them together with ID numbers), but complications arise with the stacks when it comes to windows changing their stacking order, etc.

 

As I say, I could do with some good reading on the basic data structure theory of a window/GUI manager.

 

This book is a MUST read for interface design:

 

- The Art of Human-Computer Interface Design, by Brenda Laurel

 

 

These books will show how it's been done on other small systems, presenting the different types of screen elements & their functions, in an encyclopedic way:

 

- The Amiga User Interface Style Guide

 

- Apple IIGS Toolbox Reference

 

- Newton OS 2.0 Interface Guidelines (pdf) This was an excellent, small gui, which was very well integrated into the system. Highly recommended reading. Ran VERY well on a Newton Messagepad 2100.

 

The Amiga ROM Kernel Reference Manuals, Exec, & Intuition manuals (pdf) (ebooks section) contain all of the code (in c) for the various functions of the system, and you should be able to get some excellent ideas for preparing your data structures from the examples provided. There are many other links to excellent manuals there, as well.

 

The Motif programming manuals (pdf), may also give you some ideas.

 

Other than that, "Computer Graphics: Principles and Practice" is the bible of graphics algorithms endorsed by siggraph. The first edition was in ALGOL-derived pseudocode, the second was in c. This book is indispensable if you are looking for the most efficient algorithms to create on-screen GUI elements from scratch.

 

The works of J. C. R. Licklider & Douglas Engelbart are highly recommended. "The Mother of All Demos" 1968 video by Englebart should be watched, and appreciated for its incredibly innovative ideas, and to give Mr. Englebart all of the credit that he deserves (If you haven't seen this yet, prepare to be blown away). The last, but not least link is the

, despite being too advanced for an 8-bit, you will find neat features that you have never seen elsewhere.

 

 

...but wait, there's more... One last thing... Avoid this:

lol.

 

 

Hope that helps!

 

PS, maybe the new "Project Veronica" will be the answer that you are looking for, with regard to fast display management.

[flashjazzcat]

Thanks a million!

 

Great references there: I did attempt cohesive research on GUI design some months ago, but there are many titles I wasn't aware of in your recommendations and a unified "reading list" is most useful. I will enjoy tucking into those titles.

[flashjazzcat]

This project is still staggering along. I'm currently finishing a text-mode, keyboard-only UI library intended for knocking out menu/dialogue based apps (along the lines of the FDISK program for the SDX MyIDE driver). That'll eventually form the bare-bones code for the GUI. Progress will be slow, but hopefully there'll be something interesting by the end of 2011!

[flashjazzcat]

Not the GUI as such, but the finishing touches to the UI library I started writing for the SDX FDISK app for MyIDE:

 

 

The code which sets up the dialogue box is shown below:

 

show_help ; dialogue box test
 jsr open_dialogue
 .byte 30,10
 .byte 'Dialogue Box',0
 .byte 3 ; 3 controls
 .word check_box1
 .word text_box1
 .word list_box1
 rts

;
check_box1 ; definition for check box 1
 .byte DLG_CHECK_BOX ; control type
 .byte 12,1  ; control coordinates  
 .byte 1,1  ; label coordinates
 .word cb1_label
 .word option_1
cb1_label
 .byte 'Check Box:',0
option_1
 .byte 128

text_box1 ; definition for text box 1
 .byte DLG_TEXT_BOX
 .byte 12,3
 .byte 2,3
 .word tb1_label
 .word text_1
 .byte 16,1 ; width and height
 .byte 64 ; max input length
 .byte 0 ; numeric mask fla
tb1_label
 .byte 'Text Box:',0
text_1
 .byte 'Example string',0
 .byte 0,0,0,0,0,0,0,0,0,0
 .byte 0,0,0,0,0,0,0,0,0,0
 .byte 0,0,0,0,0,0,0,0,0,0
 .byte 0,0,0,0,0,0,0,0,0,0
 .byte 0,0,0,0,0,0,0,0,0,0
;
list_box1 ; definition for list box 1
 .byte DLG_DROP_LIST
 .byte 12,5
 .byte 2,5
 .word dl1_label
 .word list_1
 .byte 6,3 ; width and height
 .byte 5  ; # items
 .byte 0   ; selected item
 .word list_1 ; pointer to selected item
 .byte 0  ; first displayed item
 .word list_1 ; pointer to first displayed item
dl1_label
 .byte 'List Box:',0
list_1
 .byte 'Item 1'
 .byte 'Item 2'
 .byte 'Item 3'
 .byte 'Item 4'
 .byte 'Item 5'
;

 

 

 

 

Edited December 30, 2010 by flashjazzcat

[+Stephen]

This project is still staggering along. I'm currently finishing a text-mode, keyboard-only UI library intended for knocking out menu/dialogue based apps (along the lines of the FDISK program for the SDX MyIDE driver). That'll eventually form the bare-bones code for the GUI. Progress will be slow, but hopefully there'll be something interesting by the end of 2011!

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.