New GUI for the Atari 8-bit

[potatohead]

Well, I'm the one that started the thread, and I stand by my assessment that it's brilliant work!

 

Cheers, and I'm following the project with great interest.

 

Over at Format War, we tend to talk about stuff on various levels, with no real bitings yet. Could be way worse.

Seems fairly innocuous to me. I think Jon was more amused by the fact that the adjective "simple" was used to describe something that has the potential to give him daily migraines.

 

I chuckled at it too honestly. Then again, "simple" is one of those things that can vary considerably, depending on what our skills are.

[popmilo]

...

Seems fairly innocuous to me. I think Jon was more amused by the fact that the adjective "simple" was used to describe something that has the potential to give him daily migraines.

 

I chuckled at it too honestly. Then again, "simple" is one of those things that can vary considerably, depending on what our skills are.

That is just about right description

 

It's all about context...

When I said "simple", I was in middle of trying to get my head around double-buffered-multi-charset-per-screen-dli-heavy-"+10 software sprites"-pm-underlay-kind-of-engine.

 

And it was giving me hourly migraines

 

Compared with "1-soft sprite-with-some-text" seemed simple

 

All I can say now: :thumbsup:

[flashjazzcat]

Heh... no offense was taken. I understand the stage that the project was at when those comments were made. Everything's relative - this is quite true. Once I had exceptionally efficient box/line draw routines, raster block copies, quick region inversion, mouse rendering, and the font renderer coded up - that was the graphics routines just about done and dusted. No competent and experienced machine code programmer would find that part an insurmountable challenge (although the pre-rendered software sprite mouse which can - if need be - be drawn "around" - is rather neatly implemented, and the reward for that is VERY fast operation and exceptionally smooth mouse movement: if I'm proud of anything, I'm proud of that). There are much more complex things being done graphically out there. When I said the GUI used "demo" effects, I was talking about unrolled loops and lookup tables. And the use of those techniques has yielded an extremely fast font renderer.

 

By "demo" techniques, I did not mean to imply that the GUI would include rotating 3D cubes/balls, spinning chequerboards, multiplexed software sprites, or other effects. I apologize if that's the impression I gave.

 

The HEADACHES come from implementing data structures, event handlers, and recursive, hierarchical methods normally almost exclusively coded in C or another high-level language, but here writing them in assembly language. MADS source code can look very elegant, but this stuff is MUCH easier to understand in C. Someone early on described my approach as taking the early Mac OS, GEM, and GEOS API documentation, and reverse engineering a blend of these interfaces in an assembly language implementation on the Atari. That just about sums it up. The GUI is all about data structures; that's why we spent many, many pages discussing them here.

 

The graphics are the bits you can see. The "simple" bits, if you like. But there are a number of very good reasons why - to the best of my knowledge - a full OOP GUI implementation has not been seen on the A8. Do the existing ones use object trees, message listening, hierarchical redraws, object inheritance, relative/virtual coordinates, etc, etc? I think Diamond GOS was a decent stab at it, but there were some very serious limitations apparent from the API documentation, and the somewhat sluggish performance. Alan Reeve offered to dig out the source code for Diamond GOS 3 a year or two back in the hopes I would develop it further, but having waited patiently and recived nothing, I no longer have any need for that source code. I think, on reflection, it was better to start from scratch.

 

So, in the interests of producing something people can download and actually play with, I'm gonna waste as little time as possible discussing the relative merits or otherwise of my programming ability or my approach to this project. I'm just gonna spend the next couple of weeks recapturing the spirit of rapid, confident, and competent progress which prevailed a month or so back. The vast majority of people want, I think, to see this project completed; either so they can use it, or describe what's wrong with it and why their GUI would have been better.

Edited April 18, 2011 by flashjazzcat

[sack-c0s]

Interesting what Google throws up:

 

Format War

 

Apparently this is simple stuff!

If you look at the date of the posts, you'll see they were from Feb. 12 - 15. At that point we we had the menus/subs/checkmarks. That was quite a while back. It's possible their opinions may have changed somewhat since then.

 

There are also several people who are disagreeing with the "simple" assessment.

 

(Edit: Except for the most recent post, which clocks in at under 15 minutes ago )

 

I know the comment you're referring to - but demo coders are always like that. Don't get me wrong - I love a good demo but all a demo proves is that the code as produced by that person is capable of throwing out those frames in that specific order under those conditions. It is a somewhat unrealistic scenario which allows for a lot of smoke-and-mirrors a game or OS developer isn't going to get away with so when they manage it then it's far more impressive.

 

The only difference this time is it's an OS and not a game they're describing - and just like with games I'm sure the demo coders pouring scorn would have a go, come out with a single super-optimised case and have it grind to a halt, fall over or just generally not be that good when someone else tries something.

 

 

 

so yeah - sorry if someone wanted a dissenting opinion from a C64 fanboy but I'm afraid I reckon he's doing a good job and I do driver code by day so know the sting of fanboys chanting 'that's only a little bit of code - it's p*ss easy! anyone could do that!' all to well so I'm showing a little solidarity

[popmilo]

...

So, in the interests of producing something people can download and actually play with, I'm gonna waste as little time as possible discussing the relative merits or otherwise of my programming ability or my approach to this project. I'm just gonna spend the next couple of weeks recapturing the spirit of rapid, confident, and competent progress which prevailed a month or so back. The vast majority of people want, I think, to see this project completed; either so they can use it, or describe what's wrong with it and why their GUI would have been better.

That is an excellent way to think about it!

 

And until I'll have my own oo-asm-coded-mouse-driven-gui-on-a8, I'll be sitting in a corner silently waiting for test download to appear

[flashjazzcat]

...so yeah - sorry if someone wanted a dissenting opinion from a C64 fanboy but I'm afraid I reckon he's doing a good job and I do driver code by day so know the sting of fanboys chanting 'that's only a little bit of code - it's p*ss easy! anyone could do that!' all to well so I'm showing a little solidarity

 

Thanks man!

 

...

So, in the interests of producing something people can download and actually play with, I'm gonna waste as little time as possible discussing the relative merits or otherwise of my programming ability or my approach to this project. I'm just gonna spend the next couple of weeks recapturing the spirit of rapid, confident, and competent progress which prevailed a month or so back. The vast majority of people want, I think, to see this project completed; either so they can use it, or describe what's wrong with it and why their GUI would have been better.

That is an excellent way to think about it!

 

And until I'll have my own oo-asm-coded-mouse-driven-gui-on-a8, I'll be sitting in a corner silently waiting for test download to appear

LOL - and thank you!

 

I had a change of heart and decided to indulge andym00 because - as I said over at the FW forum today - with something as fundamental as the mouse rendering (which is more or less "drop in" code and isn't going to upset anything if it's changed), I'd rather do it the best way even if the best way isn't my original way. We've been discussing here on this forum recently the relative merits of opinion-driven projects and doing things your own way regardless. The fact is, what Andy proposes (namely, raster interrupt driven pointer rendering which appears to the system as a hardware sprite) fascinates me greatly. I have my own idea of how to code up something like that, but I'd like to see what his suggestions are. And if and when I come to test out his idea, I'm gonna cycle benchmark both rendering methods and see which one's the least expensive. The current mouse rendering method is very similar to GEM's on the ST, and it looks more or less identical in operation.

Edited April 18, 2011 by flashjazzcat

[flashjazzcat]

Nothing comes without a price: In the abscence of any code at Format War, I tested out an admittedly rather half-assed attempt at Andy's raster-mouse-rendering method last night and it didn't work so well. But two things occur to me:

 

1) The fixed cycle overhead for drawing the mouse in a DLI (and then erasing it again, before unblocking) is gonna impact on everything, since the mouse redraws and erases on every frame, regardless of whether it's moved. At least if the mouse is turned off at the top of a tree redraw, those cycles are released. Similarly, if the pointer is stationary, it's not being rendered.

 

2) What happens during disk I/O, particularly high speed SIO transfers? SDX turns DLIs off altogether at high baud rates, so the DLI mouse will become a "flicker-fest". The current method enables the mouse to not only remain visible, but change shape (to an hourglass, for example) and keep sampling (during those frames that DLIs are active) during disk I/O.

 

As my mother says: "Everything I do, I do for a reason."

 

Anyway, the idea still interests me, so I wait to see if all the requirements can be fulfilled: Uses as few or fewer cycles than the current method, and stays visible during disk I/O.

 

Heh... this strikes me as a bit like looking at MyIDE and saying it should run at 70KB/s and have a GUI partition manager... Oh, wait....

Edited April 20, 2011 by flashjazzcat

[flashjazzcat]

Didn't get anywhere with the experimental mouse renderer, so I designed this great suggestion box widget instead:

 

 

[snicklin]

Didn't get anywhere with the experimental mouse renderer, so I designed this great suggestion box widget instead:

 

Very witty, I enjoyed that!

[kenfused]

Nothing comes without a price: In the abscence of any code at Format War, I tested out an admittedly rather half-assed attempt at Andy's raster-mouse-rendering method last night and it didn't work so well. But two things occur to me:

 

1) The fixed cycle overhead for drawing the mouse in a DLI (and then erasing it again, before unblocking) is gonna impact on everything, since the mouse redraws and erases on every frame, regardless of whether it's moved. At least if the mouse is turned off at the top of a tree redraw, those cycles are released. Similarly, if the pointer is stationary, it's not being rendered.

 

2) What happens during disk I/O, particularly high speed SIO transfers? SDX turns DLIs off altogether at high baud rates, so the DLI mouse will become a "flicker-fest". The current method enables the mouse to not only remain visible, but change shape (to an hourglass, for example) and keep sampling (during those frames that DLIs are active) during disk I/O.

 

As my mother says: "Everything I do, I do for a reason."

 

Anyway, the idea still interests me, so I wait to see if all the requirements can be fulfilled: Uses as few or fewer cycles than the current method, and stays visible during disk I/O.

 

Heh... this strikes me as a bit like looking at MyIDE and saying it should run at 70KB/s and have a GUI partition manager... Oh, wait....

 

Well you could have both methods of drawing the mouse pointer. The DLI one most of the time when interacting with the interface, and switch to the other one when doing something processor intensive or disk IO I think the current way where it might flicker here and there is plenty good enough though. I found the DLI method mentioned interesting though and something I would never have though of doing.

[flashjazzcat]

I think the current way where it might flicker here and there is plenty good enough though. I found the DLI method mentioned interesting though and something I would never have though of doing.

I'd never thought of it either, and it's a pretty neat idea in theory. If I could have coded it up without clattering the whole system, I might have explored it futher. I didn't expect to be writing it myself.

[Faicuai]

I think the current way where it might flicker here and there is plenty good enough though. I found the DLI method mentioned interesting though and something I would never have though of doing.

I'd never thought of it either, and it's a pretty neat idea in theory. If I could have coded it up without clattering the whole system, I might have explored it futher. I didn't expect to be writing it myself.

 

...This whole GUI-enchilada sounds absolutely F-amazing, from a pure 8bit point-of-view.. The mere idea of trying to do it is, on its own, a feat already.

 

Beyond the technical implications comes, in my opinion, probably the most important reason for doing it: inheritance. If I pass on my beloved 8bit goodies to my kids (who are growing in my mouse-and-click-filled wonderland :-)), they may get a bit perplexed or neutralized with the "Ready" prompt, if I am not around... :-)

 

...BUT, with the advent of FujiX, problem solved: they will be able to discover it or explore it all, in a more friendly and contemporary manner... and should they feel brave enough to open the hood... well, it would be a mouse-click from FujiX, itself. :-)

 

Therefore, count on my PAYMENT, if this project gets somewhere. More than deserved.

 

F.

Edited April 20, 2011 by Faicuai

[+MrFish]

Didn't get anywhere with the experimental mouse renderer, so I designed this great suggestion box widget instead:

 

 

Hey, you can't take credit just because you rescaled it Photoshop.

[potatohead]

I don't see the occasional mouse display artifact as being a significant value loss. Frankly, keeping the GUI lean overall is worth way more than avoiding the occasional occlusion is.

[fibrewire]

... know the sting of fanboys chanting 'that's only a little bit of code - it's p*ss easy! anyone could do that!' ...

Those that can... DO! Everyone else is a critic - including us

 

Paragraph 3 - http://www.ylmf.org/...lease_note.html

[bpj1138]

Who the hell needs a desktop just so they can click on a program they wanna load? Most 8 bit programs overwrite DOS and won't even let you exit out of it. (come to think of it, most ST software does the same thing, you're lucky if you can get back to the desktop and then the colors are usually f'ed up).

 

I'd go for something a little more crazy, like a multitasking OS where programs would ask for an off screen rectangle, use the graphics lib to draw to it, then finally mark damaged areas, and the OS would blit these areas to the screen.

 

As crazy as that sounds, I think writing a soft sprite for a mouse is more crazy. I'd use a normal sprite, and move the mouse with joystick or keyboard. (I'm aware the 8 bit has no cursor keys)..

 

--Bart

[Fox-1 / mnx]

Most 8 bit programs overwrite DOS and won't even let you exit out of it.

There ain't a single tool on my 16MB DOS partition that overwrites DOS, nor won't exit to DOS.

 

I'd go for something a little more crazy, like a multitasking OS where programs would ask for an off screen rectangle, use the graphics lib to draw to it, then finally mark damaged areas, and the OS would blit these areas to the screen.

What are you waiting for?

 

I'd use a normal sprite, and move the mouse with joystick or keyboard. (I'm aware the 8 bit has no cursor keys)..

So, you would use a joystick to move the mouse? I think it's much easier when using the mouse or joystick to move the pointer.

 

Also, tell me the difference between using a keyboard and using cursor keys (which the Atari has b.t.w.)

 

(Was this actually a serious reply or should we laugh about it? I'm not sure.)

[spookt]

My 800XL has cursor keys. I use them for editing all the time.

[bpj1138]

I was being sarcastic. I know there are "cursor keys" on the 8 bit. I've already written a lot of graphics code, there is line drawing, polygon fill, rectangle fill. An image blit would just be taking the rectangle fill and extending it. See, the problem is more about the emotions rather than assembly language. Flashjazzcat seems to be spearheading this, but has he asked anybody for help? Sure, one person could do all this by himself (or herself, if there are any girls coding on the 6502... LOL), but what fun would that be, and who's gonna use it when he's done? Nobody, cuz you're back to the emotional problems. Look, you wanna be pragmatic about this, let's get people to post code, let's see who's got the fastest code, let's talk code. Doing everything by yourself is not the way to go..

[potatohead]

re: Sprite for mouse.

 

The mouse and GUI would not align on individual pixel boundaries. When working in color, Atari's are 160 pixel machines. When doing monochrome, they are 320 pixel machines, and the Sprites are color, as is the hardware scrolling capability.

 

Soft sprite makes that happen pixel perfect. Given the original design goals, a coarse mouse really doesn't make a lot of sense.

Edited April 24, 2011 by potatohead

[spookt]

I was being sarcastic. I know there are "cursor keys" on the 8 bit. I've already written a lot of graphics code, there is line drawing, polygon fill, rectangle fill. An image blit would just be taking the rectangle fill and extending it. See, the problem is more about the emotions rather than assembly language. Flashjazzcat seems to be spearheading this, but has he asked anybody for help? Sure, one person could do all this by himself (or herself, if there are any girls coding on the 6502... LOL), but what fun would that be, and who's gonna use it when he's done? Nobody, cuz you're back to the emotional problems. Look, you wanna be pragmatic about this, let's get people to post code, let's see who's got the fastest code, let's talk code. Doing everything by yourself is not the way to go..

 

There are others involved in the project either directly contributing or indirectly through code discussions in this very thread. If you read back you'll see that the GUI will have an API to allow new GUI programs to be written and a number of people are already keen to do just that.

 

For one I can't wait to try it out.

[flashjazzcat]

I've already written a lot of graphics code, there is line drawing, polygon fill, rectangle fill. An image blit would just be taking the rectangle fill and extending it.

That's wonderful. I can pick up line drawing and polygon fill routines right off this forum when the time comes, and they're probably much better than the ones I wrote myself fifteen years ago. The fact is, the graphics routines comprise like ten percent of the code at the moment and they don't cause me a whole lot of stress. The last person who offered me completely realized assembly code (in the form of a proportional font renderer) wanted money for it, so once I'd stopped laughing, I wrote my own and asked MrFish to design all the fonts. We brainstormed the LUTs for the bit shifting right here in this thread, and - by pooling knowledge - we ended up with something extremely efficient.

 

See, the problem is more about the emotions rather than assembly language.

No - it's written in assembly language, I can assure you.

 

Flashjazzcat seems to be spearheading this, but has he asked anybody for help?

MrFish is my equal partner in the project; he does all the graphic design and will be writing the resource editor and various other applications when the time comes. Without his skill and hard work, the project wouldn't be proceeding, since the design element forms about fifty percent of the hard work in producing a GUI.

 

MrFish and I have several private threads which have been running for months and which cover many pages. He advises me on many aspects of design (not just graphics), and this is one of the reasons we've made such massive progress in less than four months.

 

Other than that, have I asked for help? Yes - many times in this thread I've posed questions about GUI structures, algorithmic approaches and code design and I'm usually not left wanting for expert help and opinion. The fact that the code hasn't changed much in light of these suggestions doesn't mean I don't listen. It probably just reflects the fact it's well designed in the first place.

 

Sure, one person could do all this by himself (or herself, if there are any girls coding on the 6502... LOL), but what fun would that be, and who's gonna use it when he's done?

Do we look like we're having problems? Please enlighten us.

 

And show me the team of people who got together and wrote a full OOP GUI for the A8 any time during the past 25 years (and I include Diamond GOS in that). Show me the people who got behind Alan Reeve and wrote apps for Diamond. Show me the people who sat down and wrote a GUI word processor or DTP package for the otherwise commendable TRS Desktop or Boss-X.

 

I'll tell you something. Last week, someone at Forum War deciced he could do a better job of rendering the mouse pointer. He went into great detail about why his approach might be superior and said he'd spent a couple of afternoons working on the idea, and when I made a hash of implementing something similar to see if it would work, I asked him to post his code and told him that if I used it, he'd be credited with writing the mouse renderer. I was also obliged to post a couple of caveats since his rendering method hadn't really been thought through properly in the context of a program which peforms any kind of serial I/O. Did he post his code? No - he turned around and said he didn't have time to mess around with outdated tech and was gonna sell all his 8-bit gear. I've no doubt, however, that said code will turn up at some opportune stage...

 

That's another of my experiences of asking for code. I have asked for plenty of advice, and I got plenty. Read the thread. Pseudo code, references, C code, you name it. What's the problem with me disseminating these ideas, this expertise, and turning it all into assembly language?

 

In what way is this project not yielding positive results? Is there something about my track record with previous projects which suggests this project is unlikely to bear fruit?

 

Nobody, cuz you're back to the emotional problems. Look, you wanna be pragmatic about this, let's get people to post code, let's see who's got the fastest code, let's talk code. Doing everything by yourself is not the way to go...

Heh... emotional problems? Well, I must be doing something right, if so many people suddently want to prove they can write faster code. I'm used to it, being a guitarist... that the detractors can't detect their own emotional motivation is often amusing.

 

I honestly don't see what the problem is. Like I say, nobody wanted to touch this for twenty five years. In a year or so, there'll be an API coders without chips on their shoulders can use to write GUI applications for the Atari 8-bit. It'll be fairly reminiscent of GEM and the old MacOS to code for, but simplified where it needs to be. If nobody wants to write applications for it, fair enough. I don't doubt there are a few hot coders out there who wouldn't want the indignity of writing apps for an API they didn't design themselves. Up till now, coders on the A8 haven't really had to follow any kind of prescribed structure: they have more or less total control of the machine, and they design their own UI.

 

In summation, it comes as absolutely no surprise whatsoever that the faster the GUI works and the better it looks, the more seems to be wrong with it. If you take the trouble to properly study this thread, you'll realize that the challenges I face right now have nothing whatsoever to do with drawing lines or filling polygons. They centre around memory management, buffer allocation, and running banked code in a cartridge. I've taken a lot of advice on it, though, and it's gonna be in hand. If I get stuck, you'll hear about it here first when I ask for help. Hopefully someone will come forward and take 8,000 lines of source code and organize all the inter-bank subroutine calls, object trees in banked memory, inderect memory access, etc, etc, etc. Of course, you don't get so much immediate reward for that as you do for drawing lines on the screen quickly, because you can't actually see anything happening.

 

It has to be said, it's bold to tell me what my best working practises are. I realize three months is a long time to go from a mouse driver to bare-bones multi-window interface, but these are the penalties one pays for living in an ivory tower. Unfortunately, I have to suggest that those who are fundamentally unhappy with the way the project is going or is being handled go write their own GUI. I say this because I feel a change in approach now will totally f**k up the project, frankly. Anyway, I've no doubt the GUI someone else has been working on for twenty-five years is gonna be totally awesome.

 

Just in case any of the above is taken the wrong way:

 

1) I do not claim and never have claimed to be the world's greatest 6502 coder

2) There are things I still need help with, both in this and in other projects

3) MrFish and I listen to objective advice, we respond, and we react

4) Without the expertise and encouragement of the knowledgeable folks on this forum, I'd have probably given up on this project a long time ago

 

If I do get hit by a bus tomorrow (doubtless a positive development in some quarters), I really do hope someone will pick up the existing code, and either finish it or look at it in horror (or point and laugh) and completely rewrite it so that we still get to have a full OOP GUI on the Atari 8-bit by the end of the year. I have absolutely no doubt that there are literally dozens of people with the right balance of skill, experience, and time on their hands (just like me) who would be falling over themselves to do this.

 

Too many cooks...

Edited April 24, 2011 by flashjazzcat

[potatohead]

LOLS

[popmilo]

Well said.

[hitchcock4]

Just for the record, flashjazzcat and MrFish, keep up the good work. I think you are right to let the negative comments slide off of your back.