New GUI for the Atari 8-bit

[potatohead]

Totally.

 

Right there is the reason I follow projects on old machines, and enjoy the embedded space. There are sharp limits that scale the art down to something a single person can explore and others can appreciate. IMHO, it's easier to see the beauty in computing when the scale is small or very large. The stuff in the middle is harder, because it's ordinary.

 

Did big for a while, multi-CPU unixey things. Now I'm enjoying small, where the pixels and the bits are something one can see, understand and manipulate in was that are beautiful, intriguing, fun, and interestingly, often useful and productive.

 

FWIW, I was also entirely serious about embedded. You have a calling.

[wesmond]

I'd quite enjoy trying to write some fun black and white games for the GUI - yes, probably the reversi/battleships/solitaire (with the marbles)/chess type of games... Just because to me, it feels like little games like that should exist in a GUI/OS! I'm not sure how well I'd get on, but it sounds like a lot of fun! A bit like Amazon's kindle - you wouldn't buy it to play minesweeper/go, but it's quite cool that they're there. (Shift+Ctrl+G on the old keyboard one)

 

My commute at present is largely spent on my first full A8 assembler game, getting DLI timings right, spending a few hours juggling the VBI to make it work with NTSC... and then when I get to work, I then work in Visual Studio C++ on simulation code that runs on 3 24-core machines, and between them uses over 700Gb of RAM... the difference is refreshing (by which I mean, when I leave my 700Gb at work and return to a few k, it feels good!)

 

And honestly, working within the timing limits with 6502 instructions for a season is something I think would help a lot of C++ programmers to optimise their main loops more...! Meanwhile, my two little boys (4 and 2), keep asking me to play pacman with them (specifically Tepp's new version!)... Perhaps they'll learn "The Last Word" before they have the horrors of MS Word shoved onto them...?!

 

Anyway.. plenty of reasons why my 30-year old Atari is still one of the most fun things to work on, and why I like to keep an eye on Jon's projects, and others here.

Edited July 23, 2012 by wesmond

[flashjazzcat]

...I was also entirely serious about embedded. You have a calling.

 

Ta! I finally prepared a "targetted" CV the other day and sent it out into the field. Talk about embellishing the facts... Thanks to Kevin Ogden for his kind and thoughtful advice in this matter.

 

And honestly, working within the timing limits with 6502 instructions for a season is something I think would help a lot of C++ programmers to optimise their main loops more...!

 

Well, a while ago we touched upon how beneficial (or otherwise) it would be to code a modern OS at the machine level. While that's certainly impractical, I think an insight into the actual architecture of the OS you're coding for is a good thing to have. Off an on, I've been researching GUI architectures for the past eighteen months, and what I can deduce is that - for the most part - we're increasingly in the dark about how operating systems actually work. Contrast this with GEM: I have the TOS 4.04 sources right here on my hard drive, and I've referred to them often while writing this GUI (hence we're using a hierarchical object tree). Tim Oren's "Professional GEM" articles are an absolute goldmine for anyone who wants to understand how a GUI is constructed (or at least one possible way of constructing a GUI). API documentation abounds for other platforms, but not much is given away about their internal data structures (I refer to anything which isn't open-source, of course - and for the most part the closed source ones were the ones I was most interested in studying).

 

Meanwhile, my two little boys (4 and 2), keep asking me to play pacman with them (specifically Tepp's new version!)... Perhaps they'll learn "The Last Word" before they have the horrors of MS Word shoved onto them...?!

 

If they end up writing stuff in 6502 when they're older, there's still hope for the world!

 

Anyway: it lives:

 

 

Doesn't look like much, but it feels like an achievement: closing a window requires the recursive destruction of an object tree, and the removal of allocated blocks from the heap. All this appears to be working well, using the newly-introduced memory manager. All I seem to have done is read lately, so it's nice to make some small but tangible bit of progress.

Edited July 26, 2012 by flashjazzcat

[Defender II]

...I was also entirely serious about embedded. You have a calling.

 

Ta! I finally prepared a "targetted" CV the other day and sent it out into the field. Talk about embellishing the facts... Thanks to Kevin Ogden for his kind and thoughtful advice in this matter.

 

And honestly, working within the timing limits with 6502 instructions for a season is something I think would help a lot of C++ programmers to optimise their main loops more...!

 

Well, a while ago we touched upon how beneficial (or otherwise) it would be to code a modern OS at the machine level. While that's certainly impractical, I think an insight into the actual architecture of the OS you're coding for is a good thing to have. Off an on, I've been researching GUI architectures for the past eighteen months, and what I can deduce is that - for the most part - we're increasingly in the dark about how operating systems actually work. Contrast this with GEM: I have the TOS 4.04 sources right here on my hard drive, and I've referred to them often while writing this GUI (hence we're using a hierarchical object tree). Tim Oren's "Professional GEM" articles are an absolute goldmine for anyone who wants to understand how a GUI is constructed (or at least one possible way of constructing a GUI). API documentation abounds for other platforms, but not much is given away about their internal data structures (I refer to anything which isn't open-source, of course - and for the most part the closed source ones were the ones I was most interested in studying).

 

Meanwhile, my two little boys (4 and 2), keep asking me to play pacman with them (specifically Tepp's new version!)... Perhaps they'll learn "The Last Word" before they have the horrors of MS Word shoved onto them...?!

 

If they end up writing stuff in 6502 when they're older, there's still hope for the world!

 

Anyway: it lives:

 

[media]http://youtu.be/dPajSgiour0[/media]

 

Doesn't look like much, but it feels like an achievement: closing a window requires the recursive destruction of an object tree, and the removal of allocated blocks from the heap. All this appears to be working well, using the newly-introduced memory manager. All I seem to have done is read lately, so it's nice to make some small but tangible bit of progress.

 

It lives!!!!!!

[+wood_jl]

Anyway: it lives:

[media]http://youtu.be/dPajSgiour0[/media]

 

I haven't been keeping up with this thread. So I haven't seen the videos in a long time, until this one.

 

Wow! That's fantastic! Hat off to you, Jon. It looks commercial-quality.

[potatohead]

Sure does.

[flashjazzcat]

Doesn't look so good when a memory leak causes a crash, hehe. Busy step-tracing memory deallocations caused by tree deletions using breakpoints in Altirra... such fun.

[flashjazzcat]

Memory manager appears fixed. Two hours of single-stepping through break points revealed that if a re-allocation grabbed the first block in the free list, the head pointer wasn't updated properly. I then spent time with a memory window open on the heap to check that repeated window closing / reopening (without actually increasing the maximum number of windows open at any given time) didn't actually cause the top of the heap to go up (i.e. all deallocated blocks lower down are correctly re-occupied by new window structures using first-fit allocation). MrFish highlighted a crashing issue after closing / reopening several windows, but this appears to be down to the object array crashing into the display list - i.e. pure shortage of RAM. This will all be fixed when we break out into extended memory.

 

We've also been working on buffered mouse actions (it was quite a saga of build / bug report / build / bug report) and I've finally come up with something which works. When the system is busy redrawing windows, you can still click and drag, but the visual feedback of control "tracking" naturally only happens when the system catches up. We were getting "phantom" drags which have been eradicated now, while preserving the buffering of mouse actions.

 

We also have nice little animations when closers / fullers are clicked, and I spent a bit of time this week experimenting with larger mouse cursors. Unfortunately the interrupt timings are so tight I decided it's best to stick with the 8-bit wide designs for the moment.

 

This grotty video shows the GUI running on a 1200XL - the first time it's been run on real hardware for a while. As well as a few more bug fixes, I have a bit of work to do to ensure the system works properly when loading at a reasonable address. This one's loading at $1800 and I still need more room for the heap. The windows are full of some random text grabbed from my website. The intention was to simulate how a simple text editor with multiple windows might behave.

 

 

As I say, all these kludges to get the demo to work in 64KB are just temporary measures until the banking window is opened up.

Edited August 10, 2012 by flashjazzcat

[LoTonah]

Bump!! 2 weeks and no news? This saddens me.

[flashjazzcat]

Bump!! 2 weeks and no news? This saddens me.

 

Yep - saddens me too. However, there have been about fifteen code commits to the SVN since the last update. I'd been delaying some re-writes to event handler stuff, and after failing to get a demo ready for Fujiama (too late by one day), I decided to make the changes before releasing anything. This week my wife's been on holiday (for our forth wedding anniversary... yes, we still commemorate this!), and what coding time I've had has been devoted to Ultimate 1MB PBI / Incognito PBI / APT partition editor / ATR browser. Once these projects are complete (soon, I hope), then nothing will stand in the way of GUI progress, other than married life, three cats, and the pressing need to earn money.

Edited August 25, 2012 by flashjazzcat

[flashjazzcat]

Demo nearly ready - just want to make double-clicked desktop icons open new windows. Icons can at least be selected now:

 

 

Somehow the highlighting looks more balanced with the label reversed out too. Note the masking is starting to pay off now: you can draw anything you like behind anything else on the screen.

[+Allan]

Looks fantastic. Can't wait for the demo.

 

Allan

[fibrewire]

All this speed without using PMG???

 

- and -

 

ideas for apps http://video.google....006623234946073

Edited August 28, 2012 by fibrewire

[danwinslow]

Jon, thats simply amazing.

[flashjazzcat]

Trash can finally made its way onto the desktop, along with debut of 12x12 icons:

 

 

Note the (placeholder) abbreviation below the Recycle Bin stands for "Atari 8-bit Wastebasket", just in case anyone's wondering.

[Fres]

Very impressive, FJC.

[+MrFish]

Trash can finally made its way onto the desktop, along with debut of 12x12 icons:

 

 

Note the (placeholder) abbreviation below the Recycle Bin stands for "Atari 8-bit Wastebasket", just in case anyone's wondering.

 

Wow, lucky guy. I don't have my name on any icons yet...

[atari8warez]

:rolling: ... you are an extremely funny guy FJC.... and looks like Stephen would like to marry you , heck if somebody liked me that much I would certainly think about it (you're wife will understand).....

 

And this brings the topic view numbers to 93773, just a bit more on the desktop and you will be hitting 100,000 soon, and if we had to give an high achievement award solely based on view numbers, you would be the Academy Award Winner (although I am not sure that would be because of the GUI or you being a joker).

Edited September 1, 2012 by atari8warez

[flashjazzcat]

It's unimportant. Topic views don't really count for much in terms of practical achievement, do they? (fortunately for some). They're a good general measure of interest, though. The counter itself is beyond my control.

 

Regarding the amount of time spent on the project: can I just calmly say - please don't assume post 1 marked the beginning of the undertaking. I'd say this one marks the beginning proper. I've already explained the various subsequent hiatuses and divisions of time elsewhere, so please, when I tell you the estimate is 14 months, accept the fact and don't presume to tell me or others on this forum how I've been spending my time.

 

I won't be disingenuous enough to ask you what you're doing here... glad you got the joke.

Edited September 1, 2012 by flashjazzcat

[Stormbringer]

I'd say something technical and witty to get conversation flowing again - but alas, I have none....

 

I can offer this. FJC, your project is awesome!!!!!

[flashjazzcat]

I'd say something technical and witty to get conversation flowing again - but alas, I have none....

 

I can offer this. FJC, your project is awesome!!!!!

 

Heh: a valued contribution gratefully accepted.

 

In return, I can only offer window grow-boxes:

 

 

Time's been unexpectedly short over the last week and other projects experienced unforeseen complications, but an XEX will be appearing here in the next couple of days. I've simply gone as far as I can within the current memory constraints, and once the "demo" is out, I'm ready to disappear again to move ahead with the actual product proper.

[Stormbringer]

my gosh that looks amazing! *golf clap*

[flashjazzcat]

Since I think it's more important to deliver something than to ensure all the bugs are fixed, here's the (probably last) disk-based demo:

 

Atari_8_bit_GUI_Demo_300912.zip

 

I was working on a graphic describing the UI elements, but everyone on this forum knows how to use a computer and should therefore know or be able to intuit what the controls do.

 

Note: this XEX loads at $1200, so you'll either have to boot it, or use an extremely minimal SDX set-up to run it from DOS. Any emulator should boot it for you (load XEX...), and it also works with Candle's (excellent) SIDE Loader.

 

Known issues:

• Client content of front window will occasionally spill out to the bottom of the screen, and the window will end up with both vertical and horizontal scroll bars. The bug is so elusive I haven't traced it yet, though
  
• Scroll bar handles do not "snap" to position as they should (with columnar output such as this). I simply don't have the RAM to do the math in the application at the moment.
  
• Problems with scroll handle offsets in very small windows. This will be down to rounding / precision errors (lots of 16 bit signed arithmetic going on, with "up-sampled" integer math replacing FP calls), and will be taken care of later.
  
• Scroll bar handles may assume unpredictable positions if not zeroed before a window resize
  
• You can't double-click icons on the desktop yet (although you can single-click them)
  
• Closing the File->Exit dialogue (one of the few working menu items) always refocuses the top window, even if the window had previously lost the focus to a clicked desktop icon (also, the desktop icon isn't de-selected). Can't be bothered to fix this, since those parts are being rewritten anyway and were kludged up for this demo.
  
• Some other graphical glitch or problem will almost certainly come up after prolonged use...
  

It should be apparent that proportional scroll bars are quite tricky, and this hitherto hasn't been an unusual situation in GUI programming (as a read through some window manager articles on the MacTech website will verify). The application simply needs to perform adequate checking and frequent updates of the scroll bar positions and sizes. Once again, I ran out of code space in the demo application to make the scroll bars really robust. It's surprising the amount of 16-bit calculations involved in simply setting up the virtual coordinate system. The good thing is that this is all re-usable code, which I'll eventually put together in the form of skeleton applications.

 

Note this one is for ST mice. I'll put one up for Amiga mice tomorrow if anyone wants one. For those underwhelmed by the functionality: consider that in the early months of the year great efforts were put into the font renderer, and the fruits of these labours remain largely unseen in this demo... or should I say "demo".

 

It's really a game of diminishing returns trying to add more functionality to this disk version, so I just wanted to get this out of the way so I can convert the whole thing to cartridge format ASAP.

Edited September 30, 2012 by flashjazzcat

[Jacques]

It "feels" great!

[Fox-1 / mnx]

What can I say.

 

Impressive, without a doubt. Much faster then I ever expected.