New GUI for the Atari 8-bit

[flashjazzcat]

Happy to report progress on fonts:

 

 

 

 

 

 

This is just a simple Turbo Basic program which displays the whole character set (although the renderer is in machine code). I just need to incorporate the same code into the GUI proper. Meanwhile, we're finalising the font file design... then it's just a matter of churning them out to order.

[+MrFish]

Some more font eye-candy:

 

 

[fibrewire]

Sacrilege Jon! little Apple logos but no Fuji?

 

Imagine my irreparable psychological damage upon pressing the Fuji logo and getting a little Apple!

[+MrFish]

Apple logos but no Fuji?

 

How about a Fuji-Apple?

 

[flashjazzcat]

Sacrilege Jon! little Apple logos but no Fuji?

 

Imagine my irreparable psychological damage upon pressing the Fuji logo and getting a little Apple!

 

Steady - we don't want to get the lawyers involved.

 

How about a Fuji-Apple?

 

 

Two law-suits in one!

[venom4728a]

Some more font eye-candy:

 

 

 

That is Awesome!

[atarixle]

Not bad indeed ... I'd like to see that in BOSS-X aswell

 

Can I have the sources of the Turbo-BASIC Demo?

[flashjazzcat]

Can I have the sources of the Turbo-BASIC Demo?

 

Sure - I'll discuss with MrFish, since fonts are his province and the program is of little use without fonts in the correct format. Assembler routine which renders fonts in TB demo is very simplistic compared to actual GUI renderer (it doesn't use a background mask, for a start, since it can rely on background being clear, and has no fast lookup table for the screen RAM). However, here is the MADS listing:

 

; character renderer for Basic
; call with x = usr (1536, x, y, width, height, data)
cx  equ $cb
cy equ $cd
width equ $ce
height equ $cf
data  equ $d0
scr  equ $d2
temp  equ $d4
screen equ $58

org $600
;
render
pla ; get # arguments
pla ; get x
sta cx+1
pla
sta cx
pla
pla
sta cy
pla
pla
sta width
pla
pla
sta height
pla
sta data+1
pla
sta data
lda width ; get byte width
and #7
sta temp
lda width
lsr
lsr
lsr
sta bytewidth
lda temp ; if spare pixels, bump byte count
beq nopix
inc bytewidth
nopix
jsr getscr ; work out screen pointer and pixel offset
ldx height
render1
ldy bytewidth
lda #0
sta charbuffer,y ; ensure rightmost byte is zeroed
dey
render2
lda (data),y ; copy font bitmap into line buffer
sta charbuffer,y
dey
bpl render2
gotbits
ldy pixoff
beq nopixoff
shiftbits ; shift bitmap if it's not on a byte boundary
lsr charbuffer
ror charbuffer+1
ror charbuffer+2
ror charbuffer+3
dey
bne shiftbits
nopixoff
ldy bytewidth
render3
lda (scr),y ; OR bits into frame buffer
ora charbuffer,y
sta (scr),y
dey
bpl render3
lda scr ; bump screen to next scanline
clc
adc #40
sta scr
bcc *+4
inc scr+1
lda data ; and bump data pointer
clc
adc bytewidth
sta data
bcc *+4
inc data+1
dex
bne render1
rts
;




getscr
lda cx
and #7
sta pixoff
lda cx+1
sta scr+1 ; work out cx / 8
lda cx
lsr scr+1
ror
lsr scr+1
ror
lsr scr+1
ror
sta scr
ldy cy
beq noyadd
scrlp1
lda scr
clc
adc #40
sta scr
bcc *+4
inc scr+1
dey
bne scrlp1
noyadd
lda scr
clc
adc screen
sta scr
lda scr+1
adc screen+1
sta scr+1
rts
;

pixoff ; x pixel offset
.byte 0
bytewidth
.byte 0
charbuffer
.ds 5
end

 

This is just a glorified blitter. You may wish to design your own font format: the basics of the renderer shouldn't change much.

 

The multiply by 40 for the Y coordinate should at the very least be replaced by * 8 + * 32 using left shifts, but a look up table is best. Like I say - this is lazy code and speed is unimportant.

Edited February 12, 2012 by flashjazzcat

[Defender II]

Very nice work.

[+MrFish]

Chinese anyone?

 

[Tin_Lunchbox]

Those modified fonts are amazing, never seen anything like that. I guess these characters are actually 3 x 3 arrangements of GR. 0 characters, so 24 x 24 pixels? Incredible work.

[+MrFish]

Those modified fonts are amazing, never seen anything like that. I guess these characters are actually 3 x 3 arrangements of GR. 0 characters, so 24 x 24 pixels? Incredible work.

 

Thanks. They're all in bitmap mode since most sets require variable character spacing. At the moment we can use any point size, but FJC may put a restriction on that at some point. Many of the more usable fonts will be at smaller point sizes, but it's cool to play around with some of these other point sizes.

[fibrewire]

A little off-topic, but can several pages of fonts be displayed with a 'smooth scroll' function?

[flashjazzcat]

I'll code up a font viewer in the GUI proper just as soon as I can get through the forest of obstacles. You'll be able to scroll through them with the vertical scroll bar.

[1NG]

Very cool work!

I like the GUI very much and I think I understand why you are doing that fascinating stuff :-)

I did something like that but with easier conditions: I've done a XWindows-like Gui in graphics mode under DOS in c++.

And I did a multitasking system on a 6809 in Assembler in 1989. The 6809 has a register to set the zero page to a 256 byte aligned address. So every task had it´s own zero page. After doing the kernel I did the priority of the tasks like this:

In an (timer-)interrupt every task can be switched

a) if its time was up during normal looping

b) if it has consumed a lot of time without looping

c) it signaled that it does not need further time

 

a) is for programs, that are doing things like looking for user events periodically in a loop while doing something

b) is for copying data, drawing rectangles etc. this is not done in an event loop and needs to be done as quickly as possible

c) is for a program that has nothing to do yet.

 

a) a "Main Program" with interactions

b) drawing windows

c) Background Task. E.g. printer task, but nothing to print

 

the differnce is only the time a process/task has at one time slice

a) about 20ms before the next task is running

b) about 100ms before the next task is running

c) 0ms before the next task is running, change immediately

 

technically it is done by looking in the main-loop if a program has run 20ms or does not run anymore. Then the actual task is hold and the next task is started.

If a program has to do a lot of work (without event polling) (or hangs) it will be hold after 100ms.

 

switching was done by manipulating the stack. The saved stack was restored and the program jumped back to it´s last execution line.

This was done for a maintenance system which acted as a master and asked a lot of sensors via a telephone-chip and ordinary telephone cable. It had 4 fixed tasks running at the same time and programming them was not very special. They shared the hole ROM-memory for the programs and had it´s own stack and zero page. Main memory was always shared by all tasks. The User could navigate in the LCD-Display while sensors where polled and lists where printed at the same time! The 4th task checked some system states an produced messages if something was going on.

It was fun for me in the past doing that kind of programming!

 

This is not a complicated approach. Programs can be debugged quiet well (which is very important).

 

But I think a good API is the key to acceptance. As far as I understand there is no program running under the GUI that is not designed for it. Maybe a full screen mode is possible while running tasks in the Background.

While I am typing this I think that a good name for the GUI would be quiet useful. -> Quius :-) If not, maybe the text-editor for the OS can get that name :-) Or Quit Useful Operating System Quos. If it has a name (or a project name) then it is concrete instead of the more common "the GUI" which stands for other GUIs as well. Is there a name for it (What is the name of/in the source file?)

 

As I read a few posts I understood the API is similar to existing ones, so some programs will work without changes and others with a few. That is interesting! I would like to know more about the API.

[1NG]

A little off-topic, but can several pages of fonts be displayed with a 'smooth scroll' function?

I think smooth means here: With a lot of frames per second and constant speed.

All frames (50/60) per second is the best of course, but what about the speed: 1 line per frame or 2 or 4?

everything uneven like 3.3 will look unsmooth without further processing - which is not possible on A8 like in modern TVs.

So pressing the mousebutton on the arrow-up or -down maybe can scoll smooth, but in a window it has no hardware assistance like scrollregisters. Without that registers everything is done by the 6502 alone.

That is usually done by moving a part from the screen and painting the new visible part. Speed then is gained from copying and drawing speed.

I think copying speed is fast on byte aligned windows (as mentioned in the discussion). Drawing the new part depends on the graphics that is shown. Showing text with the great fonts shown earlier can only be fast up/down if it is scolled a complete textlineheight at a time. Therefore the windows height also have to be a multiple of a texts height.

This is part of the application design I think.

 

Or did you mean with "offtopic" scolling the text fullscreen without the topic of the GUI multiwindow system? That is easiliy possible via hardwarescrolling for a few pages if the text is rendered in memory first (at any fontsize).

Edited February 12, 2012 by 1NG

[+MrFish]

Many of the more usable fonts will be at smaller point sizes...

 

Here are a couple font examples showing some of the more common point sizes and styles that will be seen in the GUI:

 

 

 

[flashjazzcat]

... I think I understand why you are doing that fascinating stuff :-)

 

I'm glad you do. One or two people don't understand the point of writing this for stock hardware.

 

I did something like that but with easier conditions: I've done a XWindows-like Gui in graphics mode under DOS in c++.

And I did a multitasking system on a 6809 in Assembler in 1989. The 6809 has a register to set the zero page to a 256 byte aligned address. So every task had it´s own zero page. After doing the kernel I did the priority of the tasks like this:

In an (timer-)interrupt every task can be switched...

 

...

 

This is not a complicated approach. Programs can be debugged quiet well (which is very important).

 

Excellent information. If I could have spent more time talking to people who had coded similar small-memory systems, it would probably have saved me a lot of time. Unfortunately I struggle to find any prior project of this particular scope implemented on the 6502 (GEOS of course had its own integral FS and was a masterpiece of brevity, but our window manager has, I think, already surpassed even the modded versions of that system). That's not a boast - just a fact. We can learn a lot from 6809 systems, but the 6502 puts many obstacles in our way, especially with regard to multi-tasking (which isn't a massive concern right at the moment, I must say - although it's something which needs exploring in detail). Your suggestions have already provided great food for thought.

 

But I think a good API is the key to acceptance. As far as I understand there is no program running under the GUI that is not designed for it. Maybe a full screen mode is possible while running tasks in the Background.

While I am typing this I think that a good name for the GUI would be quiet useful. -> Quius :-) If not, maybe the text-editor for the OS can get that name :-) Or Quit Useful Operating System Quos. If it has a name (or a project name) then it is concrete instead of the more common "the GUI" which stands for other GUIs as well. Is there a name for it (What is the name of/in the source file?)

 

The API is of absolute paramount importance and always has been. I have looked at other attempts at A8 GUIs, as well as SymbOS on the Z80 machines, Mac OS, GEM, GEOS, Amiga OS, etc, etc. Many 8-bit systems fall down by being little more than a simulation of the "desktop" experience, or by having a fairly limited API and not fully implementing abstraction between the application and the hardware. Or even something as simple as blocking events: in a Diamond GOS dialogue box, you cannot exit a text entry field by clicking elsewhere with the mouse. You must also set up manual "touch" areas... I wanted to avoid all this. Controls are naturally exposed to events when they are rendered.

 

Of equal importance to MrFish and I is the interface. We're enforcing very high standards on this project. After all - the "look and feel" is the first thing the user experiences.

 

As I read a few posts I understood the API is similar to existing ones, so some programs will work without changes and others with a few. That is interesting! I would like to know more about the API.

 

Yes - it's intentionally similar, although calls aren't yet sufficiently diverse or well documented to make much sense, I'm afraid (yes - there is still a long way to go!). It looks like it's going to be kind of a mix-up of GEM AES and Classic Mac OS calls. Many decisions yet to be made will decide on the balance. The "inner workings" of the object hierarchy, etc, have already borrowed ideas from the "big boys". For example, we use a threaded binary tree for objects, just like GEM.

 

A little off-topic, but can several pages of fonts be displayed with a 'smooth scroll' function?

I think smooth means here: With a lot of frames per second and constant speed.

All frames (50/60) per second is the best of course, but what about the speed: 1 line per frame or 2 or 4?

everything uneven like 3.3 will look unsmooth without further processing - which is not possible on A8 like in modern TVs.

So pressing the mousebutton on the arrow-up or -down maybe can scoll smooth, but in a window it has no hardware assistance like scrollregisters. Without that registers everything is done by the 6502 alone.

That is usually done by moving a part from the screen and painting the new visible part. Speed then is gained from copying and drawing speed.

I think copying speed is fast on byte aligned windows (as mentioned in the discussion). Drawing the new part depends on the graphics that is shown. Showing text with the great fonts shown earlier can only be fast up/down if it is scolled a complete textlineheight at a time. Therefore the windows height also have to be a multiple of a texts height.

This is part of the application design I think.

 

Or did you mean with "offtopic" scolling the text fullscreen without the topic of the GUI multiwindow system? That is easiliy possible via hardwarescrolling for a few pages if the text is rendered in memory first (at any fontsize).

 

I doubt you'll get one line per frame. Download The Last Word and have a look at the scrolling on that (although it could be much faster if it were rewritten from scratch: best to use "View file" from the disk menu and watch the scrolling there). It uses DL manipulation. The GUI will use screen blitting and clipped redraws to scroll content.

 

However, I have already said to MrFish that I can see the usefulness, perhaps, of having an interim font viewer outside of the GUI, such is the volume of fonts being produced.

 

Regarding window dimensions and text line height: window client areas are always on byte boundaries, but don't forget that all rendering operations can be "double" clipped - i.e. on byte boundaries or via masks. So, even if half a line's height is visible at the foot of a window, only the visible scanlines of the text will be rendered. Same goes for any horizontal scrolling that will be necessary: characters are clipped on all axes.

[flashjazzcat]

Totally rewritten clipping routines:

 

 

Should have some of those lovely fonts gracing those window client areas in a couple of days...

[Shawn Jefferson]

Very, very nice!

[kogden]

That looks pretty darn zippy! Will window resizing be much slower when there's widgets and content in there?

[atarixle]

I was using a dirty "trick" when I was working on the BOSS-XE V9.0 (never released) Desktop: when it (completely) "redraws" the multiple windows, it just didn't restore the contents of the non-active windows. This speeded up the whole redrawing a lot, but it was less useful of course ... but as long as BOSS-X doesn't offer drag-n-drop (or any other activities between multiple windows) anyway, this didn't take away any functionality. Complete Redraws were initialized after resizing, moving, or closing menus or other windows. When bringing all windows to front step-by-step, the windows shown on the screen all had their full contents, because then only the foremost window was restored.

 

You can imagine, how slow this was in non-optimized Turbo-BASIC ... Version 9.0 never was more than a demo for me, myself and I.

Edited February 20, 2012 by atarixle

[flashjazzcat]

Will window resizing be much slower when there's widgets and content in there?

 

Naturally there'll be an impact, although this will be confined to the top window if the target system has sufficient memory to cache the contents of the back windows. We'll use blitting and clipping to minimize unnecessary redraws.

 

I was using a dirty "trick" when I was working on the BOSS-XE V9.0 (never released) Desktop: when it (completely) "redraws" the multiple windows, it just didn't restore the contents of the non-active windows. This speeded up the whole redrawing a lot, but it was less useful of course ... but as long as BOSS-X doesn't offer drag-n-drop (or any other activities between multiple windows) anyway, this didn't take away any functionality. Complete Redraws were initialized after resizing, moving, or closing menus or other windows. When bringing all windows to front step-by-step, the windows shown on the screen all had their full contents, because then only the foremost window was restored.

 

You can imagine, how slow this was in non-optimized Turbo-BASIC ... Version 9.0 never was more than a demo for me, myself and I.

 

Sounds interesting. I wasn't aware you'd explored multiple overlapping windows (although, as you say, it was a personal demo). Are you saying you were caching the contents of the back windows? Although in the new system we have the opportunity to draw to partially obscured back windows if we want, it makes good sense to cache their contents until they change. This will happen automatically when there's sufficient RAM. The font window will be blitted when it's moved. When it's resized or closed, only the "uncovered" regions are redrawn. I'm using a cache to restore the screen under menus, since redrawing stuff they obscure would be far too slow. The background is saved and restored as the menus drop down and roll up again. The GEM, GEOS, Diamond and other systems use a similar technique.

[w1k]

pleeeease, pleeese, post here a little XEX demo, i LOVE trying this things on real atari

 

ps. i dont upload that file to any torrent, i promise

[atarixle]

Are you saying you were caching the contents of the back windows?

 

Nope. I was restoring and caching the content of the foremost window only. The back-windows where just empty, and the desktop-wallpaper was shining through.

 

I'm sure, if I had spend more time with BOSS-XE V9.0, I had better ideas to restore the screen, but I'm sure, I'd left the background-windows just empty when restoring.