New GUI for the Atari 8-bit

[Stefan Both]

Pheew!

 

I did it somehow...

Maybe I risked a damage, but

hotplugging the Miide2 while trying

to load the Workbook.atr did the job

(hopefully it's still flashing.

 

So it should be a good idea, to fix a

cord on the key, before throwing it away.

(To be able to get it back, if you recognise

the door is closed - and it was THE key.)

 

Stefan

Edited February 28, 2015 by Stefan Both

[flashjazzcat]

Agreed.

[jk40001]

Running now the GOS on real hardware from my SIDE2 and it is just amazing..thanks Jon!

My only problem was I did not have ST mouse. If you guys also have only Amiga mouse like me, then you can turn it to st mouse simply by swaping yellow and brown wires. I just did it and it works fine:-)

 

[flashjazzcat]

Great. For those who prefer not to mod the mouse, I'll upload Amiga-mouse friendly versions tomorrow.

 

Will also add cart boot bypass so DOS can be booted instead, for the purpose of re-flashing.

Edited February 28, 2015 by flashjazzcat

[w1k]

i cant wait for amiga mouse version

[w1k]

hmmm?

[flashjazzcat]

"Hmmm" what? I'm not on the w1k developer payroll.

[w1k]

you wrote tommorow - today

[Joey Z]

Possible, by splitting the frame buffer so that some of it is below the banking window and some is above it (already, the display list and screen RAM have 16KB separating them), but we have 200 lines already and I'm mindful of not ruining the NTSC display.

maybe you could allow a slightly longer display for those with monitors (instead of TV's) that show all (or most) of the overscan to turn on optionally in the final version? unless that'd be too complex to handle multiple vertical resolutions.

[flashjazzcat]

It's not so much the issue of handling vertical resolutions as accommodating the frame buffer. If there's sufficient memory left below the banking window, it's no problem.

[Muzz73]

I got an adapter via ebay that switches the brown and yellow wires within. Universal switcheroo from ST to Amiga or vice-versa without having to open up the mouse.

 

I think it came from somewhere in Europe and only cost about $8 USD.

[flashjazzcat]

Here's an archive containing builds for both ST and Amiga mice:

 

GOS ROMs.zip

 

You can use the version of UFlash posted earlier in the thread to flash SIDE, SIDE2 and the 512KB Sic! cart.

 

This version of the ROM permits a disk boot and drops straight back out of the cart if you boot with Option pressed, although I haven't tested this in all possible scenarios. It's a temporary fix for not being able to boot another flasher subsequently to reprogram the cart.

Edited March 3, 2015 by flashjazzcat

[fibrewire]

Nice work FJC! Someday soon i hope to be back in the mix - don't you guys go getting all old on me Seriously, congradulations!

[Frankie]

I flashed my SIDE2 and everything worked.. except my mouse.

I have an Amiga mouse and it seems the only direction that works is down.

I don't know if it's the mouse or something else.I made sure I flashed the correct version.

 

Is there any other software I can use to see if my mouse is working normally?

 

Frank

 

UPDATE -

 

Turns out my Amiga mouse is actually an ST mouse. I guess when I bought it I didn't notice it was one that had been modified to work on an ST.

Edited March 24, 2015 by Frankie

[+Philsan]

New GUI desktop!

 

DESKTOP.XEX

 

From Glucholazy Party 2015, G2F by Rocky/MadTeam.

[flashjazzcat]

Looks pretty nice. Now where have I seen three colour hi-res before recently?

[+MrFish]

Yeah, I saw that too. Very nice, but not practical to implement. Here are the underlying P/M's. Yikes!

 

[+Philsan]

Yeah, I saw that too. Very nice, but not practical to implement. Here are the underlying P/M's. Yikes!

 

New GUI Desktop.png

Maybe Atari Logo only?

Edited July 29, 2015 by Philsan

[flashjazzcat]

The big PITA with PMG underlays (which I've used to similar effect recently with the new Ultimate BIOS) in the context of the GUI is the fact everything needs to be bound to character cells in order to get sufficient screen coverage, and I don't think even that would be sufficient for anything but a static image as we see in this demo. Having said that, I've liked the three luma effect since I accidentally stumbled into it while designing the icons for the BIOS.

 

Funny this topic should be bumped, since I'm working on a rewrite (for the third time) of the GFX routines for the GUI. I figure this stuff has to be absolutely as fast as humanly possible before we start work on file systems and the like.

[analmux]

And another 128 colour GUI desktop. More than 10 yrs ago.

 

"N" |-> "POS" => "liNux" |-> "liPOSux"

Edited July 29, 2015 by analmux

[flashjazzcat]

I think I prefer the grey one.

[popmilo]

Funny this topic should be bumped, since I'm working on a rewrite (for the third time) of the GFX routines for the GUI. I figure this stuff has to be absolutely as fast as humanly possible before we start work on file systems and the like.

I thought they were already as fast as humanly possible ?

[flashjazzcat]

I thought they were already as fast as humanly possible ?

 

It seemed so at the time, but some poor design decisions taken at the start of the project (i.e. using the "compressed window mask" clipping mechanism) resulted in code surviving which would have been better rewritten from scratch, so that's what's being done now.

 

Even after the rectangle-based window manager was implemented, I stuck with the use of the look-up table to clip bitmaps. The LUT is a 256 byte array with binary 1s denoting visible pixels and binary 0s denoting off-screen/clipped pixels. All but the first 40 bytes of the array are permanently zeroed. Since objects can be drawn partly off-screen, a negative X offset will map to the permanently masked areas of the array. However, this design meant that the on-screen part of the LUT had to be computed prior to every render, since every object was drawn through the resulting mask. This wasn't an enormous overhead, but I could see (after stepping away from things for a while) that much of the time ANDing with the mask was a waste of cycles - as was populating it in the first place.

 

Another problem is that using the LUT meant that the screen offsets were fixed to the start of the line (so that each column corresponded to a position in the mask array). This meant using counters or comparisons to test for the right-hand edge of a render, since we couldn't count up to zero, for example. In addition, the Y index register typically found three different uses inside a render: the screen line offset, the source bitmap offset, and the bit-shifting look-up table index.

 

The theory is that this can be improved a lot. The clipping LUT has been done away with, and the first column, middle span, and last column of a bitmap are now handled by separate sections of code. This allows the centre (full bytes) span of a bitmap to be rendered in a very tight loop with no masking, comparisons, or counters. The source bitmap and screen pointers are dropped by the requisite amount to ensure that Y is always equal to 128 at the last column rendered (enabling quick detection of the final column by branching on the N flag). Y also serves as an index into the source bitmap and screen buffer using the same value. The low-level code has also been moved into RAM so that self-modifying instructions can be used to access the bit-shifting LUT using the X register. Finally, the bit-shifting LUT has been split into two tables: one containing only the bits rolled over to the right, and the other containing only the low bits rolled into the next byte. This removes two masking operations inside the loop.

 

Bitmap clipping should also be significantly faster, since rather than iterating through off-screen data and bouncing it off the masking table, such off-screen data is now completely jumped over by adjusting the pointers, on both the horizontal and vertical planes. So, drawing a small centre section of a 320x200 pixel wallpaper bitmap should be magnitudes quicker than it used to be.

 

Some of the most critical sections of code should run a fair bit faster, although much depends on getting the set-up code as optimal as possible. Here's a comparison of the old and new code which renders a character glyph of 8 pixels wide or less and which does not shift into an adjacent screen byte:

;	old glyph render loop

CharLineLoop1
	lda linetable,x		; point SCR at beginning of line
	sta scr
	lda linetable+200,x
	sta scr+1
	
	ldy tmp4		; get data index
	lda (ptr1),y
	tay
	lda (shiftptr),y	; shift bits
	and lmask		; mask out high bits
	ldy xbyte		; get screen index
	and ForeGroundMask,y	; apply clipping mask
	ora (scr),y
	sta (scr),y
	inx
	inc tmp4		; bump data
	dec tmp5		; any more lines?
	bne CharLineLoop1
	beq Done1

	

;	new glyph render loop

	ldy BitmapYStart
	clc			; pre-clear carry
LineLoop
	lda (ptr1),y		; get byte
	tax
	lda ShiftTableLo,x	; shift bits (rolled over bits already stripped)
ShiftLoAddr	equ *-1
	and FGMask		; apply clipping mask
	ora (scr),y
	sta (scr),y
	iny			; bump data
	dec LinesLeft		; any more lines?
	beq Done
	lda scr			; since index is bumped, add one less to screen pointer
	adc #39			; carry already clear
	sta scr
	bcc LineLoop
	inc scr+1
	clc
	bcc LineLoop
Done
	rts

The output of the bit-shift LUT no longer needs masking, and Y is not corrupted inside the loop (the latter is true of all the new render loops, even those spanning multiple bytes). A trick from the mouse pointer renderer has also been borrowed in this particular instance: bumping Y to iterate through the source bitmap, and bumping the screen pointer by one less to compensate.

 

It's fairly heavy going changing everything, but it should all be easier to maintain and I'm expecting good performance.

Edited August 1, 2015 by flashjazzcat

[popmilo]

Looks pretty good to me!

 

I've always disliked horizontal byte order... So wrong for software sprites... Both Spectrum and Amstrad have modes like that and work with it very well using those 16bit register pairs... 6502 machines don't have that luxury.

 

Only thing that I experimented with in that mode (more or less successful) is large block of unrolled code for each line on screen + small routine to init entry and exit point, jsr routine and then restore unrolled code operands on place of exit.

 

Maybe something like this for Yreg = Xscreen (in bytes):

lax (ptr1),y ; get byte
lda ShiftTableLo,x ; shift bits (rolled over bits already stripped)
and FGMask ; apply clipping mask
ora scr0+0*40-0,y
sta scr0+0*40-0,y
iny

lax (ptr1),y
lda ShiftTableLo,x ; shift bits (rolled over bits already stripped)
and FGMask ; apply clipping mask
ora scr0+1*40-1,y
sta scr0+1*40-1,y
iny

lax (ptr1),y
lda ShiftTableLo,x ; shift bits (rolled over bits already stripped)
and FGMask ; apply clipping mask
ora scr0+2*40-2,y
sta scr0+2*40-2,y
iny
..
.

Setup FGMask and 'ptr1' to your shape top line, put rts instead of one of those 'iny' and then 'jsr' to beginning of one of these segments based on Y coord of top byte you want to draw.

Each segments screen address is reduced by one to compensate Yreg increasing value.

14 bytes x 200 lines = 2800 bytes of unrolled code.

You did say you wanted it to be as fast as possible

 

ps. You can use LAX in your current code also instead of: lda (ptr1),y and tax.

[Kyle22]

if you use the illegal opcode then it won't run on my 816