New GUI for the Atari 8-bit

[flashjazzcat]

The unrolled code is a nice, aggressive approach. A pleasant side-effect of the current redesign work is that large swathes of unrolled code can be dispensed with, since the loop overheads are so slight. It will be surprisingly easy to blow 128KB of ROM in the long-run. LAX would have been a really nice optimisation, but I'm not keen on spoiling 65c816 compatibility either. Maybe we can have subtly different code paths for different CPUs.

Edited August 1, 2015 by flashjazzcat

[popmilo]

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

Fortunately, using lax is not obligatory

 

There can always be two versions of gui - one just for nerds and second for Uber nerds

[Joey Z]

The unrolled code is a nice, aggressive approach. A pleasant side-effect of the current redesign work is that large swathes of unrolled code can be dispensed with, since the loop overheads are so slight. It will be surprisingly easy to blow 128KB of ROM in the long-run. LAX would have been a really nice optimisation, but I'm not keen on spoiling 65c816 compatibility either. Maybe we can have subtly different code paths for different CPUs.

macros. can you conditionally define a macro? compile for 816/C02, macro is defined as one way, compile for '02, macro is just LAX. That would let you use a LAX macro anywhere it would help, but it will compile as a combination of equivalent instructions on 816/C02. Anyway, maybe that won't work because there's no way to do LAX in 'legal' opcodes without destroying registers you need or something...

 

I don't even know what LAX does, I only deal in legal opcodes when I write code.

 

EDIT: ah, LAX is just load A and X at the same time... multiple addressing modes may make it difficult to implement a macro for that, but normal conditional assembly would not be difficult for that.

 

I say go for it, especially if you're rewriting a ton of stuff. In this case, the saved cycles matter. It's easy enough to have conditional assembly, and then provide NMOS 6502 and everything else versions. Also this opens up the possibility for using instructions which only exist on the CMOS version. I think there are some that were added in 65C02, weren't there?

Edited August 1, 2015 by Joey Z

[Joey Z]

again, just looking here, http://6502.org/tutorials/65c02opcodes.html#3

 

There appear to be a great deal of useful new instructions you can make use of if you have separate CMOS and NMOS versions. Things like 'STZ,' X and Y stack instructions, new addressing modes for other instructions appear like very obvious improvements can be made in many areas. Clearing a memory location took what before? load a register with 0 then store it? maybe you can get by with storing a register without loading it, by assuming a value based on previous things done.

 

I assume the '816 stuff is fully backwards compatible with the 65C02?

[flashjazzcat]

Conventional assembly and macros are used rather extensively already (to compile the same ROM for any of half a dozen different hardware targets), but this would also certainly be the most painless way of producing binaries tailored to different CPUs. I had been thinking of a version which would dynamically adapt to the target processor (since the low-level render code is now in RAM anyway, we can modify it), but any solution which doesn't result in maintaining two completely separate builds is agreeable. Even if I do end up playing with illegal opcodes, I promise not to break 65C816 compatibility whatever happens.

 

As for STZ: useful, but more often than not it tends to happen just as you describe it: i.e. there's already a 0 to hand in some register (or it's easy to make it so). Same thing goes with the carry flag, etc: if you need it clear, it's usually possible to arrange the code so it's conveniently clear when it needs to be. I think such practices just become natural after working with the 6502 for a long time, and it's really one of the pleasures of coding for this CPU. X and Y push/pull instructions appear the best time-savers to me, although their use would be largely confined to the kernel, which admittedly does a lot of stack manipulation, especially in the ISRs.

[fujidude]

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

 

Please, do not be tempted to use illegal opcodes. it is really poor programming practice. It's right up their with directly using system routines at certain addresses instead of using published methods and vectors. It's lazy and short sighted. Well, maybe that's too harsh. But it's not a best practice.

Edited August 1, 2015 by fujidude

[flashjazzcat]

Please, do not be tempted to use illegal opcodes. it is really poor programming practice. It's right up their with directly using system routines at certain addresses instead of using published methods and vectors. It's lazy and short sighted. Well, maybe that's too harsh. But it's not a best practice.

I've avoided illegal opcodes like the plague, but as already written above: if I use them on the stock CPU, I won't use them on an incompatible CPU. The primary argument against illegal opcodes (which I would second) is that they break software on a 65C816. But if that doesn't happen, I see no problem at all. I'm sure owners of stock CPUs would like to get every last cycle out of it if doing so is consequence-free.

Edited August 1, 2015 by flashjazzcat

[Joey Z]

 

Please, do not be tempted to use illegal opcodes. it is really poor programming practice. It's right up their with directly using system routines at certain addresses instead of using published methods and vectors. It's lazy and short sighted. Well, maybe that's too harsh. But it's not a best practice.

IMO, I think it's not an issue, as long as you provide a version (perhaps at a performance loss, like this case) that does not use the illegal opcodes.

[fujidude]

Yes yes. If there is a version which doesn't use them then it's all covered. But... if you have a version that works without them, why make another one that does use them? I think what's being put forward is two versions: one for 6502 that uses "illegal" op codes, and another that does not but does use 65C816 only features to accomplish the same goals? If so, that makes sense.

[Joey Z]

Yes yes. If there is a version which doesn't use them then it's all covered. But... if you have a version that works without them, why make another one that does use them? I think what's being put forward is two versions: one for 6502 that uses "illegal" op codes, and another that does not but does use 65C816 only features to accomplish the same goals? If so, that makes sense.

well, I was suggesting an NMOS 6502 version, and a CMOS version for 65C02, which would also work on 65C816. I think full 65C816 support is a long ways off

[flashjazzcat]

All 65C816 support requires is no illegal Sally opcodes. I was never intending to write a version which runs in Native mode. As for illegal opcodes on the stock CPU: they'll only be used if they add up to a noticeable performance increase, and I'm not even sure that will be the case yet. The 65C02 is the one with the more useful enhanced instruction set.

[fujidude]

The concern was illegal opcodes making the software incompatible with some hardware setups. I can see that's not a worry here. I should have known better than to worry about such when it comes to FJC. Your work is always top notch.

[flashjazzcat]

Managed to get the rewrite done: now comes the debugging, since the GUI gets as far as rendering the desktop pattern and then things go awry. But even without resorting to illegal opcodes, the speed at which the screen is filled looks very encouraging indeed.

[flashjazzcat]

Well it worked: desktop fill is about three times faster, line drawing and rectangle fill about doubled in speed, and text rendering improved a bit after I optimised the setup code. Still some broken stuff to fix but the work was definitely worth doing.

 

I tried LAX in the glyph renderer but since the cyle saving was so tiny it was hard to notice any real improvement. Larger fonts might show obvious benefits but smaller glyphs are now more reliant on fast clipping and setup routines.

[TheNameOfTheGame]

Congratulations! That is a big increase and I thought it was super fast already

[KLund1]

Hi,

just getting back into A8's after a while. I would like to try this GUI. Went to the download page, and found the file. But there was no docs on how to run it. This thread would take several days to read thru. I know it is still being worked on, but some docs on how to run this would be helpful. I think it needs some version of flash cart (which I have). Any instruction/docs out there?
Thanks !!

[fujidude]

Good work FJC! Once you get this thing up and slugging the way you want it I know I will want to check it out. When I first got into the A8 scene again and I saw this project, I wasn't that excited about it really. I was mostly just looking for ways to relive the programs and stuff that I used to use or that I could have used to use if I had bought it all. Now, I've even been doing a bit of coding for the A8, and am more into it than I thought I would be. I am also more interested in this A8 GUI project too.

[flashjazzcat]

I know it is still being worked on, but some docs on how to run this would be helpful. I think it needs some version of flash cart (which I have). Any instruction/docs out there?

Fair point: some kind of familiarity with what's been going on was assumed, but the ROMs in the archive have phonetic names which are supposed to pertain to a particular flash cart. "SC512" is for a 512KB Sic! cart, there's a build for SIDE (replaces the XEX loader), and the rest are all for AtariMax flash carts (MaxFlash 1Mb, MaxFlash 8Mb, MyIDE/Flash and MyIDE II), and you can use the MaxFlash studio to flash them. It's then a case of simply booting the cartridge, although I recently received a PM from one user who was puzzled by the fact clicking the icons doesn't launch the applications (you have to use the Atari Logo menu). Again, this is a perfectly reasonable criticism, and will be put right in the next demo, which will at least have a README attached.

 

That is a big increase and I thought it was super fast already

It was pretty fast, but it can always be faster. The re-write wasn't entirely driven by performance goals anyway, however. I wanted to remove the last vestiges of bad planning from the project. If the GUI had been designed around a rectangle-based window manager from the get go, two complete re-designs of the UI would not have been necessary. Unfortunately I didn't have Prodatron (SymbOS author) on hand at the beginning, and it was he who convinced me to drop the peculiar mask-based window manager I had designed. But the conversion job was so massive that bits of the masking code were left behind in the rendering routines simply because I didn't have the time or energy to completely re-write everything at the time. Now, at least, it's as it should have been from the start.

 

Aside from speed improvements, getting rid of mask arrays and huge swathes of special-case code (for instance: three different code paths to draw horizontal lines of varying lengths) means ROM and RAM space have been recouped as well. It's nice when code becomes smaller and faster. Even doubling the size of the bit-shifting look-up-table (from 2K to 4K) hasn't hurt that much, since hi/lo divide by eight arrays are now implicit in the bit-shifting LUT, so 512 bytes were immediately shaved off, and the menu cache (the buffer which stores the background under the menus) is now allocated with MALLOC, freeing up 3KB of RAM under the OS. I was going to put the 4KB LUT in ROM, but this involved some time-consuming ROM bank manipulation, and having the LUT in RAM also ensures that - coupled with the low-level rendering code in RAM - accelerator boards will run most of the cycle-heavy graphical stuff on the accelerated clock.

Edited August 12, 2015 by flashjazzcat

[flashjazzcat]

Same old, same old visuals here but it definitely feels snappier:

Bodged the blitter last night to use the new shift tables but a complete rewrite will make that faster too and won't take long. Idle CPU usage when showing one CPU graph dropped from 10 per cent to 9 per cent so I guess that means it got better somehow. Now I can see the wood from the trees, more sophisticated clipping when bringing windows to the front (only drawing what's revealed, etc) will be fairly easy, and I'll add clickable icons and possibly a skeletal console app for the next download. Am mentally focused on file systems at the moment, and if I can abstract the file system on the ROM (which is kind of a modified version of FAT) so that it's accessed using a proper driver API, we'll be getting somewhere (you'll be able to list the ROM disk directory in the console, for example).

Low-level GFX routines shouldn't have taken this long to get right, but you live and learn I suppose.

 

Note: button bug (white text) now noticed and fixed.

Edited August 15, 2015 by flashjazzcat

[+MrFish]

It looks pretty snappy to me...

 

Once you've got things squared away, a good test might be to reinstate live dragging of windows.

[+mytek]

WOW, DOUBLE WOW!!!!!!!!!!!

 

That is absolutely amazing. I can't help but wonder if you had done this before the Mac, if Atari would now be the ones making phones, tablets, and stock prices in the triple digits.

 

I watched the video several times, because I just couldn't get over the fact that an 8-bit Atari was doing that. Sure beats the hell out of some of the earlier GUI attempts made by others. Be cool to have that be ROM based when all the bugs are worked out (default OS?).

 

-Michael

[flashjazzcat]

Glad you like it, and I hope it will one day become the second-best 8-bit multitasking graphical OS after SymbOS (and I was pleased to learn that our A8 GUI inspired Prodatron to resume work on his astounding SymbOS project a couple of years ago).

 

Unfortunately the task was so gargantuan and my initial planning so misguided I'd have had to commence the project in the mid-Seventies to have any hope of beating the Macintosh to market. If only my stock prices were in triple digits, though (or even single digits).

 

It's ROM-based already, BTW, and can be flashed to the Ultimate 1MB using the new BIOS so that the machine boots directly into the GOS. Unfortunately it's still some way from being especially useful thereafter.

[danwinslow]

Amazing.

[+MrFish]

Unfortunately the task was so gargantuan and my initial planning so misguided I'd have had to commence the project in the mid-Seventies to have any hope of beating the Macintosh to market.

 

You'd also have needed close ties with Xerox.

Edited August 16, 2015 by MrFish

[JamesD]

WOW, DOUBLE WOW!!!!!!!!!!!

 

That is absolutely amazing. I can't help but wonder if you had done this before the Mac, if Atari would now be the ones making phones, tablets, and stock prices in the triple digits.

 

I watched the video several times, because I just couldn't get over the fact that an 8-bit Atari was doing that. Sure beats the hell out of some of the earlier GUI attempts made by others. Be cool to have that be ROM based when all the bugs are worked out (default OS?).

 

-Michael

I think 16 bit machines wouldn't have had as much of an impact if GUIs had been common on 8 bits but Atari was in cost cutting mode at the time so I don't see it happening.