New GUI for the Atari 8-bit

[flashjazzcat]

Thanks! I'm kind of devoted to those window mask lists now. They took some designing and have really evolved, and they're one of the more unique aspects of the project I'd be reluctant to change.

 

Good suggestions too. Regarding window copying (blitting) when scrolling, that's certainly planned: indeed the blitter is already written and is used to move the top window when it doesn't disappear off the desktop. Using it for scrolling, etc, is simply on the to-do list (I had some good chats with prodatron a while ago about blitting scrolling window content). I quite agree that such things can really be left until the project is somewhat more advanced. They're ready to implement, but we have more important things to do.

 

And agreed: it would make sense both to heavily optimise small font character drawing, and to dispense with window masking in the foremost window.

[flashjazzcat]

Fiddled on with the string print routine a bit; optimised just about everything possible for the moment. The "text editor" window content perhaps gives a better idea of raw text output speed:

 

 

Ignore nonsensical scroll bars for the moment.

 

Doesn't compare too badly to prodatron's (excellent) SymbOS multi-line text control. His demo text has quite a few short / blank lines at the top of the file; you get a better comparison if you watch him scroll down through the text.

 

 

On the other hand, the font in SymbOS is smaller: faster render per character, but more characters.

 

OK... onto something else now.

Edited October 10, 2013 by flashjazzcat

[JamesD]

Keep in mind that SymbOS is also running in a 4 color mode so it has to write twice as many bytes for the same size font.

[flashjazzcat]

Keep in mind that SymbOS is also running in a 4 color mode so it has to write twice as many bytes for the same size font.

 

That should also cut down on masking and bit-shifting a bit... anyway, I'm just making a general comparison - not daring to compete with the Z80 - heaven forbid.

[Kyle22]

I have done a little Z80 programming. It is Awesome!, but I find that it is difficult to get back in '02 mindset after doing lots with Z80.

 

ld c,9

ld de, msg

jp bdos

 

msg: db 'It is easy to display a string in CP/M (or MS-DOS), for the same reason.$'

 

 

 

Bill Gates can NOT answer the question about the Dollar Sign, because he has NO idea... Only Gary Killdall knew that answer. May you Rest in Peace Gary!

Edited October 11, 2013 by Kyle22

[The Usotsuki]

I see you appropriated the "Geneva 7" font

[flashjazzcat]

I see you appropriated the "Geneva 7" font

Ahem... I doubt MrFish would describe it so. It's hand-designed, although using the Mac system font as s reference.

[andym00]

That is a seriously cool looking font actually, and eminently readable at only 320 pixel resolution.. Good choice

[atarixle]

you better don't smooth-move the scrollbar when clicking onto the Arrow-Buttons, this lets the user wait for too long for browsing thru the whole view IMO ... instead the scrollbar (and the view port) should jump to the next valid viewport position. Holding the Arrow-Button should start an auto-repeat.

 

H/e, the smooth-sliding scrollbars look great when moving them with the mouse-pointer ...

Edited October 11, 2013 by atarixle

[flashjazzcat]

you better don't smooth-move the scrollbar when clicking onto the Arrow-Buttons, this lets the user wait for too long for browsing thru the whole view IMO ... instead the scrollbar (and the view port) should jump to the next valid viewport position. Holding the Arrow-Button should start an auto-repeat.

 

H/e, the smooth-sliding scrollbars look great when moving them with the mouse-pointer ...

 

Correct: as I said earlier, the scrollbars should "snap to" the valid offsets (in this case, columns in the file list view), but I haven't implemented it yet,

 

The arrows do auto-repeat, though.

 

Still in two minds about whether to "ghost" the scroll thumbs when not in "live scrolling" view... (see ST GEM behaviour).

[atarixle]

... the scrollbars look too good to make it ghosts ... lol

[fibrewire]

Jon, have you experimented with ideas for managing ram? I would love to be able to run this on a stock Atari 800 with an Axlon ramdisk and Corvus disk system. A virtual memory manager seems like a good idea, as seen on a thread from long ago...

 

http://atariage.com/forums/topic/60343-a-new-os-for-our-atari/

[flashjazzcat]

Jon, have you experimented with ideas for managing ram? I would love to be able to run this on a stock Atari 800 with an Axlon ramdisk and Corvus disk system. A virtual memory manager seems like a good idea, as seen on a thread from long ago...

 

http://atariage.com/forums/topic/60343-a-new-os-for-our-atari/

 

Interesting thread. There'll be two types of RAM: call them "fast" and "slow". Fast RAM's the memory an application can address directly in its own bank(s). The stipulation there is that the memory will have to be in the same extended bank as the code, so this will be most useful for small, statically allocated buffers. "Slow" RAM is allocated by page (using a bitmap allocation table, much like a DOS VTOC) from extended banks, and can't be accessed directly by applications. Instead, it has to be buffered into "fast" RAM space in low memory. Obviously anything which isn't directly accessed by applications is a candidate for paging out to disk, assuming there's insufficient space to house it in extended RAM. In a task-switching system, one could even page out applications themselves (i.e. banks containing code and fast RAM), although any kind of multi-tasking would likely be clobbered by this approach.

 

As I say, though, there are some interesting things in that thread. What jumped out to me is the request for a generic binary relocation format. MADS supports two formats (its own, and that of SpartaDOS X), although neither are 100 per cent ideal for use by the GUI. However - we'll have to work with what we've got.

[JamesD]

That should also cut down on masking and bit-shifting a bit... anyway, I'm just making a general comparison - not daring to compete with the Z80 - heaven forbid.

Shouldn't it require more masking because you have to write more bytes to the screen?

[flashjazzcat]

Shouldn't it require more masking because you have to write more bytes to the screen?

 

More bytes written, less masking per byte. Tomato, tomato... and SymbOS only has to move font data to one of four possible bit-shifted positions per render, instead of eight. That means smaller tables and more opportunity for pre-shifting and caching.

[popmilo]

 

... more opportunity for pre-shifting and caching.

Wouldn't it be possible to cache (or make LUTs) most used font characters ?

There are maybe 40 most used characters (letters + numbers), 7 lines each, two bytes wide shifted shape, 8 positions = 4.5 K...

Worth thinking about in cartridge version imho...

[flashjazzcat]

Wouldn't it be possible to cache (or make LUTs) most used font characters ?

There are maybe 40 most used characters (letters + numbers), 7 lines each, two bytes wide shifted shape, 8 positions = 4.5 K...

Worth thinking about in cartridge version imho...

 

Absolutely agree - in fact I was talking to MrFish about exactly this yesterday. I had a really good discussion with Prodatron a while back about the details of SymbOS font rendering, and the various optimisations involved, but I can't seem to find the emails now... maybe it was via PM and got deleted. I have vague recollections of some quite aggressive caching and pre-shifting, although my recollections may be inaccurate.

[flashjazzcat]

Made a few changes:

 

* Custom SetupX routine targeting text rendering used: just sets up xbyte, handles clipping, and doesn't bother with right-hand line extents (since they're not needed for text).

* Test for change to clipping area or window masking removed from top of SetupX. Pointless to test for changes there - much more efficient to get the application or window manager to explicitly call clipping and masking routines when it needs to (instead of setting flags).

 

Few optimisations to render loop:

	lda (WindowMask),y
	cmp CurrMask ; don't bother updating window mask if it hasn't changed on this line
	beq @+
	sta CurrMask
	tay
	lda mask_slot_table,y
	sta maskptr
	lda mask_slot_table_hi,y
	sta maskptr+1

@

;------------------------------------------



	ldy DataOffset ; index into char data
	lda (ptr1),y
	tay
	lda (shiftptr),y
	and lmask
	ldy xbyte
	and (maskptr),y
	and ClipMask,y
	and greymask
	ora (scr),y
	sta (scr),y
SkipByte3
	inc DataOffset ; bump index
	jmp nextline

1) Since the window mask doesn't tend to change much, and since the mask list is (luckily) just a series of byte codes, we can test for the code changing instead of repeatedly loading the pointer.

2) Instead of bumping ptr1 the whole time, now just keeping a page zero offset loaded into Y.

 

 

It's faster for sure. Should look better when the text is scrollable and we're blitting parts of the window. I'm fairly satisfied that this speed of rendering is sufficiently fast for a reasonably responsive text editor, hopefully even when the overheads of maintaining scroll-bar movement and reformatting are taken into account.

 

Note also line spacing has been tightened up by 1px and the first window lacks an info bar so as to get more text on the screen.

Edited October 15, 2013 by flashjazzcat

[popmilo]

And again - great work!

 

Now that drawing text is faster, restoring background behind a window (when you move it) starts looking slow.....

 

What's the method you are using when restoring parts of screen ?

Any chance for improvement ?

 

ps. It is great as it is, can't wait to get API so we can start testing our crazy ideas

[flashjazzcat]

And again - great work!

 

Now that drawing text is faster, restoring background behind a window (when you move it) starts looking slow.....

 

What's the method you are using when restoring parts of screen ?

Any chance for improvement ?

 

ps. It is great as it is, can't wait to get API so we can start testing our crazy ideas

 

Ta! Well, outline text is next up for optimisation (this will improve speed at which desktop icon labels are drawn), along with bitmap rendering in general (so icons will be looked at). Background redraws naturally depend on the window masking mechanism I described earlier, and all rendering which goes through these masks will benefit from that CurrMask optimisation described above: that can really be applied across the board, along with other stuff.

 

So yeah - certainly a chance for improvement, since we've been solely focused on text rendering lately (as well as rewriting scrollbars, etc: functionality-wise, we're about where we were with the old demo, but largely rewritten, smaller, and faster!).

 

And yeah - I'd prefer moving ahead with API instead of making speed-test videos. Gonna press on with cartridge conversion, then as MrFish said - it'll be business as usual (i.e. adding dialog boxes and all kinds of cool controls).

 

Oh - forgot to mention background window clipping which is in a really raw state at the moment: should see a dramatic reduction in the number of things which even hit those window masks once that's done.

Edited October 15, 2013 by flashjazzcat

[AtariNerd]

It's becoming difficult for me to fathom this being a stock 1.79 Mhz 6502. I eat my err tip my hat to you.

[fibrewire]

JON! The text render speed is FAST - it's so cool that your code is constantly shrinking, and getting ever faster. It's impressive to see the difference when watching videos before & after the code rewrite.

 

Could GUI modules benefit from being stored in LZ4 on a cart and unrolled into ram when accessed?

[flashjazzcat]

Could GUI modules benefit from being stored in LZ4 on a cart and unrolled into ram when accessed?

I quite like the look of LZ4 and am sure to find a use for it somewhere in this project, given GUIs tend to be quite data-heavy.

[Joey Z]

From the first post:

To the detriment of other overdue projects, I'm experimenting with the basics of a new GUI system for the 8-bit.

Funny how things change. I consider anything NOT the GUI as a detriment to this project personally, I don't know about you FJC

[flashjazzcat]

From the first post:

Funny how things change. I consider anything NOT the GUI as a detriment to this project personally, I don't know about you FJC

Yeah - I completely agree Joey.