New GUI for the Atari 8-bit

[Defender II]

I am so impressed by your dedication, openness to helpful suggestions, and flexibility to recognize and switch to a better approach to each problem you face in this GUI project!

If any software written for a modern system removed a comparable number of lines of coding and memory usage to your ~3,000 lines of code by implementing a more efficient structure and slashing more than 2KB to 700 bytes of contiguous space it would blow away all the bloated monstrosities that currently clog the software market.

With the advances in the cartridges we have seen, I can't wait to purchase this GUI paired with them for the Atari 8-bit. Keep up the great work!

Edited December 27, 2012 by Defender II

[+JAC!]

Yeah, real coders don't code - the REMOVE code to make it work!

[flashjazzcat]

I'm gonna have a party when the code gets stripped out... hopefully I'll time it right for New Year's Eve.

 

Sorry, Jon, for not writing, I was completely occupied during december, but will answer soon!

 

No problem - I figured you were very busy! Most things in my last email have become clear now, I think, given how much reading and coding I've done since I sent it. However, I have a few more things I'd like to put to you in light of all the changes I've made, since I've roughly modelled the new record structures on those in SymbOS (shame we can't hope for source level app compatibility... maybe in C with a few libraries and macros! ).

 

BTW: I was reading the Monitor issues recently uploaded to AtariMania today, and for those interested there's an excellent description of GEM's object trees in the ST Programming column in issue 19, complete with diagrams. This is the exact system I implemented in the A8 GUI... and am now removing. It worked well, but it was more than we need, and the advantages of using simpler data structures are already very apparent.

[+CyranoJ]

Yeah, real coders don't code - the REMOVE code to make it work!

 

Sometimes you have to remove yourself from any emotional attachment to hours of work and rip out the old to make way for the new. It's not easy to bring yourself to do that. I guess that's why there's a lot of stuff out there that looks 'forced' and 'doesn't quite work' - Luckily (??) I have a good team who'll tell me when when something is 'complete arse' so I know it's time to hit the delete key.

 

Well done, FJC.

Edited December 27, 2012 by CyranoJ

[flashjazzcat]

Changes are going well, although in between finishing off three long-overdue hardware jobs, time has been limited. Aside from the massive rewrites I've undertaken, Prodatron's multi-line text control inspired me to optimise the hell out of the text rendering routines. If anything's gonna slow the visuals down, it's text rendering, so it seems sensible to spend time making this critical code as fast as possible.

 

BTW: SymbOS's multi-line text control looks great, and I've been testing the CPC version in WinAPE:

 

 

I've also been learning alot from Andy regarding ready states and other IPC stuff, and this will ensure that the scheduler doesn't waste time context switching into processes which are inactive while waiting for events. Process priorities are potentially complex (at least if they're dynamically manipulated to boost efficiency), but all is gradually becoming clear.

[flashjazzcat]

Finally: the Samsung Galaxy Ace 2 gets the long-awaited upgrade from Gingerbread:

 

[JohnBuell]

Are you saying you've mapped the pointer so that it works with a touchscreen under Android?

[flashjazzcat]

Are you saying you've mapped the pointer so that it works with a touchscreen under Android?

 

Well, I wish I could - but there's (understandably) no mouse support in Colleen, so I might have to use a joystick driver. This is a developmental build, BTW - hence the garbage in the scroll bar.

[Stormbringer]

Haha!!!! thats awesome!

[Prodatron]

The coolest smartphone GUI I ever saw!

[flashjazzcat]

http://youtu.be/rPuSJeitYgM

 

Managed to get this working with a joystick driver, but it's rather difficult to control (as evidenced by the video). The 800Mhz processor in the phone is running things at full speed, though. One problem is that I can't get Colleen to register trigger clicks unless the joystick is simultaneously moving, for some unknown reason.

 

Here's the joystick driver I threw together, for interest:

 

.proc mouse
lda $d300
and #$0f
eor #$0f
bne Moved
pla
rti
Moved
stx mtmp1
tax
lda x_change
clc
adc joytabx-1,x
sta x_change
lda y_change
clc
adc joytaby-1,x
sta y_change
ldx mtmp1
pla
rti
.endp

joytabx .byte 0,0,0,255,255,255,0,1,1,1,0,0,0,0,0
joytaby .byte 255,1,0,0,255,1,0,0,255,1,0,0,0,0,0

 

The aggregated changes to X and Y are applied to the coordinates when the VBL comes around, and I had to slow the timer 1 interrupt down somewhat to manage the pointer speed.

 

Enough playing with this for now, I think - got more productive things to do.

 

EDIT: I've noted that rendering in the joystick version is appreciably faster than the mouse version, since timer 1 is only firing about 100 times a second instead of 1,000. Damn shame mouse movement can't itself generate an interrupt, then we could do away with the high-frequency polling.

Edited January 11, 2013 by flashjazzcat

[flashjazzcat]

And the answer, of course, is mouse acceleration, although this doesn't allow us to drop the sampling rate by much (maybe by 10-20 per cent), because we can still get false axis changes if the sampling isn't regular enough, and these are simply amplified by acceleration.

 

 

In the video, the border flashes when the acceleration threshold is reached. I also experimented with redrawing the background desktop-first, as someone suggested a while back. Looks a little weird, but only half a dozen lines of code need changing to reverse the redraw order.

 

The acceleration threshold will be configurable, of course, as will the sampling rate, and you'll be able to turn off the acceleration altogether. I definitely find it helps in avoiding mouse "overrun", though.

[+JAC!]

>Damn shame mouse movement can't itself generate an interrupt, then we could do away with the high-frequency polling.

Hmm, we could use a joystick adapter which plugs both into port 1 & SIO. There we have the unused PIA IRQ :-)

[popmilo]

>Damn shame mouse movement can't itself generate an interrupt, then we could do away with the high-frequency polling.

Hmm, we could use a joystick adapter which plugs both into port 1 & SIO. There we have the unused PIA IRQ :-)

"Smarter" mouse could buffer all movements and deliver them to atari only when polled. 50/60 times a second would be enough for fluent mouse movements...

You could do it 'when there is time', so wouldn't interfere with disk i/o, dli's and similar stuff at all...

 

Any kind of modern micro controller can do it and it would be quite cheap ...

 

Of course , anyone wanting to use Gui fluently would have to buy (or make) their own mouse adapter

[Irgendwer]

"Smarter" mouse could buffer all movements and deliver them to atari only when polled. 50/60 times a second would be enough for fluent mouse movements...

You could do it 'when there is time', so wouldn't interfere with disk i/o, dli's and similar stuff at all...

 

Any kind of modern micro controller can do it and it would be quite cheap ...

 

Of course , anyone wanting to use Gui fluently would have to buy (or make) their own mouse adapter

 

You are describing the CMI08...

The thread now enters an infinte loop:

http://www.atariage.com/forums/topic/154520-new-gui-for-the-atari-8-bit/page__st__1025#entry2342564

[flashjazzcat]

Hmm, we could use a joystick adapter which plugs both into port 1 & SIO. There we have the unused PIA IRQ :-)

 

Yep - funnily enough someone suggested that to me a while back. It's rather a shame the IRQ line wasn't brought out on the joystick port.

 

"Smarter" mouse could buffer all movements and deliver them to atari only when polled. 50/60 times a second would be enough for fluent mouse movements...

You could do it 'when there is time', so wouldn't interfere with disk i/o, dli's and similar stuff at all...

 

Any kind of modern micro controller can do it and it would be quite cheap ...

 

Of course , anyone wanting to use Gui fluently would have to buy (or make) their own mouse adapter

 

Well, the aim is to keep it fluent without such hardware, and while useful savings can be made from reduced mouse polling frequency, polling certainly isn't bogging the system down unduly. Using an acceleration threshold makes 750Hz sampling very usable, and this is down from 1MHz. The Pokey IRQ bails out if the joystick bits haven't changed, and this takes around nineteen cycles. So, at 750Hz, we burn up to 15,000 machine cycles per second (not including interrupt mechanism's initial stack pushes) when the mouse is stationary. This is appreciably better than 20,000 cycles with 1MHz polling.

 

This sure puts however many hundred cycles per frame for the context switches into perspective.

 

But yeah: some custom hardware would sure enhance things, so if someone wanted to make / design something like this, I'll add driver support.

 

You are describing the CMI08...

The thread now enters an infinte loop:

 

Well, the pre-emptive task switching will take care of the infinite loop - but yeah, thanks for pointing that out!

 

If someone wants to send me a CM108 so I can write a driver for it, feel free... then we can reach an exit condition.

Edited January 12, 2013 by flashjazzcat

[popmilo]

You are describing the CMI08...

The thread now enters an infinte loop:

http://www.atariage....25#entry2342564

The moment I wrote that and went outside for a walk, I remembered we were discussing it before

 

CMI08 is a great device btw!

 

Hmmm... Maybe I'm 'cheap' but isn't it possible to build something cheaper in '2013 (and easily built with less parts) with modern microcontrollers ?

Something that connects usb mouse with joystick port ... (I wouldn't touch SIO port, having irq is not worth all the hassle as we'll probably have something occupying SIO port anyway)

 

I have couple arduinos on my table already... Might as well connect them to atari

[Irgendwer]

Hmmm... Maybe I'm 'cheap' but isn't it possible to build something cheaper in '2013 (and easily built with less parts) with modern microcontrollers ?

Something that connects usb mouse with joystick port ...

 

I'm already working on it... (so many projects so little time...)

[Jason1024]

What an awesome project. I'm trying to imagine what this would have meant if Atari had shipped something like this in e.g. 1982. And more importantly, looking forward to seeing how far FJC can take this. Please keep up the great work!

[flashjazzcat]

Heh... If I'd started this in 1982 I'd have been lucky to have it ready the XE launch.

 

Andy and I have been thrashing out ideas to circumvent the BRK bug, since I'd like to use BRK as a rather neat way of making kernel calls and passing messages (Andy's idea). As I understand it, we could end up in the NMI handler with the B flag set, but providing we react to this, worst we end up with is the odd skipped DLI or VBI. The effect of IRQs on BRK is slightly more concerning: naturally missed IPC is fatal.

 

On a related topic, are we likely to upset the SIO by abandoning the OS NMI routines entirely, providing the system timers are still maintained? It strikes me that a complete replacement ISR would be better than a wrapper around the OS routine. Naturally the default vectors will be restored before non-GUI applications are launched.

 

I've managed to save 15,000 cycles per second on the NMI mouse pointer, and 2,000 on mouse polling, so there's now a nice cushon to absorb the NMI scheduler.

[GroovyBee]

As I understand it, we could end up in the NMI handler with the B flag set,

 

You end up in the IRQ hander with the B flag set.

[flashjazzcat]

When an NMI happens in the middle of a BRK?

[GroovyBee]

Sorry I misread it. If NMI happens whilst in the IRQ handler (entered from a BRK instruction) you are correct.

[+Stephen]

I've managed to save 15,000 cycles per second on the NMI mouse pointer, and 2,000 on mouse polling, so there's now a nice cushon to absorb the NMI scheduler.

That is why proper hand coded assembly will never be beaten by an optimizing compiler!

[flashjazzcat]

Sorry I misread it. If NMI happens whilst in the IRQ handler (entered from a BRK instruction) you are correct.

 

It's bloody confusing at first, frankly, but at the same time I think it's easy to over-complicate the problem unnecessarily. We're kind of going into uncharted territory using BRK like this... but that's what's fun about it.

 

That is why proper hand coded assembly will never be beaten by an optimizing compiler!

 

I basically discovered that the pointer was only 12 scanlines high, but the renderer was going through 16 lines of data (i.e. the pointer shape / mask plus four blank lines). So just reducing the iterations shaved off a whole bunch of cycles. This could be made flexible for taller pointers, but I can't see that we'd need more than 12 lines that often. Next, I looked at two STA WSYNC instructions, and I'm close to eliminating these... or at least one of them. The delay is necessary so that the bottom of the mouse pointer isn't erased before the raster beam has had a chance to display it. I set about dealing with this by looking at the display list offset table which is used to translate the Y coordinate of the mouse into an offset into the DL, so we can dynamically insert an NMI trigger on the appropriate line. By placing the DLI as close as possible to the physical starting line of the mouse pointer, we start drawing it slightly later and can therefore spend less time idling before erasing it. If you start drawing the pointer too late, however, you'll lose the top of it... or sometimes the whole thing disappears. I was able to move the DLI down by about 5 lines, anyway. I still have some jitter at the bottom, and I need to mod one of my PAL 800XLs up to NTSC so I can test behaviour on real NTSC hardware (1200XL being PAL now). Altirra is very faithful to the real hardware, even at this level, however...

 

Regarding SIO - I suppose if we're gonna redirect the machine vectors, we need a RAM OS anyway, and we could just re-instate the ROM when calling the SIO. Most of the custom interrupts will be shut down then anyway.

Edited January 15, 2013 by flashjazzcat