New GUI for the Atari 8-bit

[UNIXcoffee928]

Today's news: Nokia will adopt Windows Phone as its principal smartphone strategy.

Coders of the big Nokia are unable to compete with Android and Apple in developing a good OS?

BTW, EPOC (Symbian predecessor) was very advanced at the time.

...

That is utter nonsense. I have a Nokia N800 and it is killer, running Linux (Maemo). Nokia makes great stuff, but is developing a very consistent habit of leaving it's users out in the cold, OS-wise, with incompatible OSs for each new release (from N770 to N800 to N900 to Nokia WindozeFone). Nokia=Good Products, but Bad Business. It is very frustrating to buy a product, then not be able to upgrade. The N800 could have been a great computing platform, but instead they made it just another disposable consumer electronics item, doomed to obsolescence, for no good reason. Sucks.

I agree with you (apart the "that is utter nonsense" part, if it is related to my words and not to Nokia).

I used this news not to open a discussion regarding OSes values, marketing strategies... but only to to introduce my hilarious last sentence:

Luckily A8 is in a better situation thanks to Jon!

No, nothing to do with you, whatsoever! It was just the news that Nokia is so daft. & Hell Yeah, we could not ask for a better Atari 8-Bit GUI, nor could we ask for a better Helmsman!

[flashjazzcat]

...nor could we ask for a better Helmsman!

LOL... as he steers into the murky, uncharted waters of multi-line, scrollable text boxes.

[flashjazzcat]

Did some interesting reading today about the Andrew User Interface System (AUIS), which has all sources available in C. Most interesting of all was this article on the data structures used in the text editor, which - although not designed for 8-bit machines - does at least attempt some optimisation of the screen redraw. The text editor discussed uses a split buffer (like The Last Word), and what it calls "markers" to keep track of which lines on the screen have changed owing to edits and thus need redrawing (again, more or less the same system The Last Word uses).

 

That such optimisations are used in a GUI is encouraging to see. Coupled with what was described as "intermittent" or "periodic" redrawing/reformatting in another (lost and very obscure) text on UI design, I think the text box I'm working on might just be fast enough to keep up with the keyed input. This is basically a prototype control which will form the basis of the text editor/word processor app.

 

The text control keeps the text as a contiguous data block (it will eventually be a split buffer), and introduces a list of line lengths (in characters). The line length table removes the requirement for constant reformatting while moving around the document, and also means that not all of the intermediate text must be inspected when moving from point A to point B. The split buffer will be able to avail itself of a high-speed memory block move routine rather than relying on repeated calls to cursor left/right in order to travel up and down the text.

 

When editing text, the reformat command (which need not complete if a key is in the message queue; it may be prematurely abandoned, providing the line the cursor is on is in a displayable state) proceeds to the end of the current paragraph, fixing up all the word wrap and flagging up any lines which need redrawing. When the system is idle for long enough, the screen redraw (now with no repsposibility for the word wrapping), simply renders those areas of the screen which aren't up to date (after first ensuring that the current line is ALWAYS redrawn, at least from the insertion point to the line end).

 

The intermittent refresh - though tested - was never implemented in a final release of LW (the extra speed boost was hardly required), but in the case of a GUI, it's more or less essential. Even a five line, twenty column text box can't be completely re-rendered 3-4 times a second when drawing proportional fonts, much less a word-processor's document window. When the user is typing fast, the absolute minimum set of events between keystrokes will be:

 

• Character from message queue received by text control
• Character inserted into buffer at insertion point
• Current line reformatted (or current and previous line if the cursor has moved from one line to another), before formatter interrupted by presence of another character in the input queue
• Renderer erases current line from cursor position to right edge (or whole line and previous line if cursor moved), and then renders new content
• Renderer is then aborted owing to presence of character in input buffer
• Vertical/horizontal scroll bars updated and redrawn

 

It's obvious that it's quite a fight to get everything done in time (even with a simple text box with no mixed font styles/sizes), but I think it'll work quite well. Even the most convoluted content will gracefully rearrange itself and fill the entire window as soon as the user eases up on the typing (naturally all the keystrokes are buffered).

Edited February 13, 2011 by flashjazzcat

[UNIXcoffee928]

I was going through some old Amiga disks, and ran across Fred Fish #96, from 1987, which had a program called, "Hackbench", that was a user's attempt to write a functional clone of Workbench 1.2 in C, for experimental/educational purposes. It looks as if it was pretty bare bones, but there may be a good idea or two hiding in the code. Here's the link. It's an lha file, so you'll need 7-Zip or a similar archiver.

[flashjazzcat]

I was going through some old Amiga disks, and ran across Fred Fish #96, from 1987, which had a program called, "Hackbench", that was a user's attempt to write a functional clone of Workbench 1.2 in C, for experimental/educational purposes. It looks as if it was pretty bare bones, but there may be a good idea or two hiding in the code. Here's the link. It's an lha file, so you'll need 7-Zip or a similar archiver.

Thanks! It's certainly incomplete as a GUI, but what's implemented seems quite comprehensive. Some good examples of virtual coordinate processing, etc. Very useful indeed!

[flashjazzcat]

I ended up going through the entire Fred Fish Archive last night, and while there were a few other things mildly pertinent to this project, Hackbench was certainly the best. The sheer conciseness of its menu handler encouraged me to optimize that part of the GUI and I managed to chop out about fifty lines of code (and about a hundred bytes). The in-place checking of menu items has been ditched: usually the menus close down anyway when you check an item, so the menu disappears before the callback is invoked. This reduces the code size yet further.

 

Mr Fish is making great progress with the icons (in various resolutions up to 16x16), and I'm keeping busy with the text box control in the meantime. As Dan says, the text box control is almost a mini application in itself, and is easily the most difficult programming hurdle to overcome before this project really starts to shape up.

 

Here's some 12x12 icons in a list view window (no particular correspondence between icon and filename):

 

 

Love that hard disk icon on the desktop!

 

Note the scrollbars in the finished system are likely to be proportional to the area of the workspace being viewed in the window.

Edited February 16, 2011 by flashjazzcat

[UNIXcoffee928]

Glad that that helped you out!

 

Yeah, it was totally random... I got that A4000T for Christmas, and I'm finally starting to get it decked-out. I was going through 100s of floppies that have been sitting in a dresser drawer for 15-20 years, and happened upon it. Really random... must have been meant to be... funny how that happened, in relation to how important it is, in this context, since you are essentially creating a big piece of Atari history. It's sort of like you got a message in a bottle from 1987, ha.

 

After looking it up, I was very sad to see that Mr. Fish had passed away in 2007. sux. Great guy, did a lot of important stuff while he was alive, that's for sure!

 

After checking the latest gui screenshot, can you make it so that the date column lines up precisely, it will list nicer, when in motion. Otherwise, it looks fookin-fab!

 

Are you setting the icon files up *.info style, like the Amiga did? If you standardize on an icon format, it will add to the versatility of the icons (with say a text description field, and perhaps a Tool-Type).

 

There are thousands of icons out there that can be converted to the new format. It might be nice if you made them so that they could be edited directly in the Amiga icon editor (say in the upper left quadrant of the editing screen)... this way, they would actually be small Amiga-compatible icons, following the established format, and could be produced quickly & easily.

 

You are doing a great job!

[UNIXcoffee928]

PS, here's the link to the icon & icon tools section on Aminet.

[JamesD]

I'd guess there are huge collections of Mac icons and tools. You might check for those if you haven't already.

[flashjazzcat]

Glad that that helped you out!

 

Yeah, it was totally random... I got that A4000T for Christmas, and I'm finally starting to get it decked-out. I was going through 100s of floppies that have been sitting in a dresser drawer for 15-20 years, and happened upon it. Really random... must have been meant to be... funny how that happened, in relation to how important it is, in this context, since you are essentially creating a big piece of Atari history. It's sort of like you got a message in a bottle from 1987, ha.

Well, as I said, it was really the brevity of the Hackbench code which simply brought forward my code optimisation session (currently 400 bytes have been shaved off the library). So far I have just done a fairly cursory scan of Fred's code; I haven't actually taken any coding ideas from it. The best thing it did was reaffirm that what is being written is roughly correct in structure and approach. No Eureka moments yet. But code like Hackbench is such a rare find; if I was writing an Amiga Workbench clone, it would surely be the place to start.

 

Speaking of code revision, since I last conversed with Dan, I've completely reorganized the source code. It was a real mess (having just grown off the back of the old mouse driver demo). It's now neatly split into include files by subject (text rendering, graphics primitives, mouse driver, etc) and is a lot easier to manage. There was also a huge sequence of menu creation code which was repeated twice virtually verbatim because I couldn't quite get the recursion to work from the previous "level": that's removed now. Just about every time I systematically sweep through the library code, more patterns begin to emerge, which are then duly delegated to a common subroutine.

 

After looking it up, I was very sad to see that Mr. Fish had passed away in 2007. sux. Great guy, did a lot of important stuff while he was alive, that's for sure!

It's a great shame. He was prolific in his output, that's for sure.

 

After checking the latest gui screenshot, can you make it so that the date column lines up precisely, it will list nicer, when in motion. Otherwise, it looks fookin-fab!

Screenshot: mockup. Mr Fish is entirely responsible for all that eye-candy. I should have made it clear this wasn't an emulator shot, although the window drawing code is nearly done so we should be able to replicate that scene very shortly. The reason the numbers don't align properly in the mock-up is that Mr Fish is presumably still using numerals which don't have uniform spacing. We fixed that issue with the "real" fonts, so dates and times, etc, will always line up.

 

Are you setting the icon files up *.info style, like the Amiga did? If you standardize on an icon format, it will add to the versatility of the icons (with say a text description field, and perhaps a Tool-Type).

Not sure yet. I guess we could store each folder's icon data in an INF file. This would map out the icon associations with applications and files. It would have to be closely tied into the file manager so that renamed files, etc, cause it to be updated. The icon data format is already standardized. We're looking at up to three sizes, to cope with the Atari's limited resolution. The maximum size is 16x16. The huge Diamond-style generic icons aren't needed here, since the longest possible icon label is 68 pixels wide. It's all tested and it looks good.

 

There are thousands of icons out there that can be converted to the new format. It might be nice if you made them so that they could be edited directly in the Amiga icon editor (say in the upper left quadrant of the editing screen)... this way, they would actually be small Amiga-compatible icons, following the established format, and could be produced quickly & easily.

I'm leaving the icon conversion/creation work to Mr Fish. As for the icon editor: a basic resource editor (icons and fonts to start with) will be the first application which gets written for this system.

 

You are doing a great job!

Thanks!

 

PS, here's the link to the icon & icon tools section on Aminet.

Thanks. I know Mr Fish is largely using Mac material for inspiration, but that might be of interest to him too.

 

I'd guess there are huge collections of Mac icons and tools. You might check for those if you haven't already.

You'd think so. I wasn't able to locate a damned thing after a couple of hours' searching the other week. Fortunately Mr Fish has it all in hand, via whatever magical methods he employs!

[JamesD]

I'd guess there are huge collections of Mac icons and tools. You might check for those if you haven't already.

You'd think so. I wasn't able to locate a damned thing after a couple of hours' searching the other week. Fortunately Mr Fish has it all in hand, via whatever magical methods he employs!

The MacOS didn't support custom icons until System 7, and that's when color was also introduced.

I did some searching and found some B&W ones but most were color.

[Rybags]

Just about sure they had colour icons before 7... they just didn't have proper multitasking yet.

[JamesD]

Just about sure they had colour icons before 7... they just didn't have proper multitasking yet.

I got the info from wiki, blame whoever wrote it.

[R6502A]

I ended up going through the entire Fred Fish Archive last night, and while there were a few other things mildly pertinent to this project, Hackbench was certainly the best. The sheer conciseness of its menu handler encouraged me to optimize that part of the GUI and I managed to chop out about fifty lines of code (and about a hundred bytes). The in-place checking of menu items has been ditched: usually the menus close down anyway when you check an item, so the menu disappears before the callback is invoked. This reduces the code size yet further.

 

Mr Fish is making great progress with the icons (in various resolutions up to 16x16), and I'm keeping busy with the text box control in the meantime. As Dan says, the text box control is almost a mini application in itself, and is easily the most difficult programming hurdle to overcome before this project really starts to shape up.

 

Here's some 12x12 icons in a list view window (no particular correspondence between icon and filename):

 

 

Love that hard disk icon on the desktop!

 

Note the scrollbars in the finished system are likely to be proportional to the area of the workspace being viewed in the window.

 

It would be nice to have region specific config e.g. date formats.

[flashjazzcat]

It would be nice to have region specific config e.g. date formats.

Agreed. Where applicable, the date format will also echo the current DOS setting (for SDX users). Better yet, since the data and code are completely separated, users with fairly basic knowledge can edit the resource files and make international language versions of the GUI and its apps. We're using 256 character fonts with full international characters, so anyone can make versions in many different languages with no programming changes and a few hours' translating the resources.

Edited February 17, 2011 by flashjazzcat

[flashjazzcat]

Hehe... just rewrote the mouse handler interrupt to use the bit shifting tables, optimized it cycle by cycle, and properly calibrated the sampling rate to 600Hz in both PAL and NTSC modes. Menus render even faster now, and pointer movement is exceptionally smooth on an NTSC machine.

[ToddUGA]

Hehe... just rewrote the mouse handler interrupt to use the bit shifting tables, optimized it cycle by cycle, and properly calibrated the sampling rate to 600Hz in both PAL and NTSC modes. Menus render even faster now, and pointer movement is exceptionally smooth on an NTSC machine.

 

Crap. You're gonna make me end up buying an 800XL aren't you?

[flashjazzcat]

You're gonna make me end up buying an 800XL aren't you?

Hehe. Has to be seen on a real machine. We've got those boxes now which appear to grow/shrink from/to and icon when a window opens/closes. Looks cool!

 

Demo coming this weekend - it's been a while.

Edited February 18, 2011 by flashjazzcat

[UNIXcoffee928]

You're gonna make me end up buying an 800XL aren't you?

Hehe. Has to be seen on a real machine. We've got those boxes now which appear to grow/shrink from/to and icon when a window opens/closes. Looks cool!

 

Demo coming this weekend - it's been a while.

 

YAY!

[flashjazzcat]

We have a window... I now have to code up the messaging system and the render code for all the window elements. Static buttons are dead easy, but scroll bars are a little more tricky. I'm keeping an eye on code size here, since we have passed the half-way point of the nominal 14KB library size limit. Should be doable, though.

 

To do:

 

• Render code for buttons, scroll bars and title bar
• Messaging system which calls render methods for various classes (ensuring a "redraw" message issued to an object also causes all the children to be iteratively redrawn)
• Off-screen virtual coordinate handler which will capture events on objects in the scrollable client area of a window

Once that lot's written, we'll have movable, scalable, sizeable, scrollable windows. After they're done:

 

• Code up the common dialogue controls
• Finish "nemesis" (the multi-line text box control)
• Write the dialogue event handler

If I can do all the above in under 7KB, we're laughing.

 

I'll get some basic window functionality complete by the end of the weekend and put out an executable so folks can have a play.

Edited February 18, 2011 by flashjazzcat

[svenski]

Looks amazing so far, can't wait to see the finished product

[+MrFish]

You're gonna make me end up buying an 800XL aren't you?

Hehe. Has to be seen on a real machine. We've got those boxes now which appear to grow/shrink from/to and icon when a window opens/closes. Looks cool!

 

Demo coming this weekend - it's been a while.

They used to call them "Zoom Rects", back in the day...

[Fox-1 / mnx]

They used to call them "Zoom Rects", back in the day...

 

That's at least a lot easier when creating labels and such :-)

[flashjazzcat]

They used to call them "Zoom Rects", back in the day...

 

That's at least a lot easier when creating labels and such :-)

Heh... I'll keep that in mind. I had no idea what to call them.

 

I actually had to slow them down a bit: the rubber-band box drawing for windows happens on byte boundaries and is therefore extremely quick.

 

I fell asleep last night thinking about the code to calculate the size of the size of a scroll bar slider. I don't really want to resort to FP calls, so I came up with the notion of doing away with fractional calculations by first multiplying the window size/height by an arbirary value. For example:

 

window width = 20 bytes

virtual work area width = 30 bytes

 

20/30 = 0.66 recurring. Multiplied by the window width, this would have rounded off to about 14 bytes for the width of the slider.

 

However:

 

20 bytes * 32 = 640

640 div 30 = 21

 

21 * 20 = 420

420 div 32 = 13

 

So we end up with a 13 byte wide slider. I'll still require efficient 16 bit mult/div routines. 32 is just a handy multiplier; anything will do, and the higher the multiplier, the more accurate the calculation. The only requirement is that the resulting value is greater than the workspace size in bytes (which could be enormous, in theory).

Edited February 19, 2011 by flashjazzcat

[UNIXcoffee928]

They used to call them "Zoom Rects", back in the day...

 

That's at least a lot easier when creating labels and such :-)

Heh... I'll keep that in mind. I had no idea what to call them.

 

I actually had to slow them down a bit: the rubber-band box drawing for windows happens on byte boundaries and is therefore extremely quick.

 

I fell asleep last night thinking about the code to calculate the size of the size of a scroll bar slider. I don't really want to resort to FP calls, so I came up with the notion of doing away with fractional calculations by first multiplying the window size/height by an arbirary value. For example:

 

window width = 20 bytes

virtual work area width = 30 bytes

 

20/30 = 0.66 recurring. Multiplied by the window width, this would have rounded off to about 14 bytes for the width of the slider.

 

However:

 

20 bytes * 32 = 640

640 div 30 = 21

 

21 * 20 = 420

420 div 32 = 13

 

So we end up with a 13 byte wide slider. I'll still require efficient 16 bit mult/div routines. 32 is just a handy multiplier; anything will do, and the higher the multiplier, the more accurate the calculation. The only requirement is that the resulting value is greater than the workspace size in bytes (which could be enormous, in theory).

 

I'm not sure that I totally understand what you're getting at... Since we are working with extreme resource limitations, wouldn't it be the least resource intensive to make the scrollbar's slider a fixed size? Sure, proportional slider gadgets look cool, but, really, a cursor with a dot in the middle would serve the purpose of a handle, and do it without taxing the system. Up to you, but if you are running low on resources, if you have a fixed scrollbar width, a fixed slider width, fixed up/down arrow size... then the only thing that varies is the vertical height of the scrollbar. ...but, hey, if you can pull it off, go with the proportional sliders!

 

 

I do like the NeXTStep slider "dimple" a lot. Another feature of NeXTSteps GUI, that was innovative, was having the Up/Down arrows right next to each other... this was done specifically for ergonomics, to reduce the amount of mouse movement that the user has to do, to achieve a task (much less movement).

 

Here's the

, I wish that there was a higher quality version to show you, but there isn't. One day, I really need to get a Tricked Out NeXT... it really was the pinnacle of interface design. So many great ideas in not only the GUI, but the simplicity of the actual interfacing of applications. Nothing has come close, since. Watch that demo, to see what I mean.

 

Also, if you can scrape up like $60-100.00 USD, get an Apple Messagepad 2100 on ebay, and study it's interface. This was the last Newton, and the closest to perfection that they came. It's the only Apple product that I own, ha. It has a fabulously integrated environment that was designed by guys that were responsible for the LISPmachines, of yesteryear. Extremely intelligent interface design, in that one. Highly recommended. It can do things that no other system does. & it is really more of a "Computing Platform", rather than just some shoddy "handheld device". You won't be disappointed with the Messagepad 2100. You can use this search string:

 

(newton,messagepad) 2100

 

and set it up to email you, if you want to try to get a good deal on one.

 

As I had mentioned, when we were first getting started on this GUI, the Newton is fully documented, and all of the tech/api/programming books are available online. It's a really nice system, and well worth it.