New GUI for the Atari 8-bit

[danwinslow]

I think I can probably safely speak as the "MIO Crown" since Ive laid hands on more of them in the past 3 years than anyone else will in a lifetime..

 

Heres what I say..

 

With a GOOD ethernet device, why would you want/need an MIO or blackbox? Everything could be hosted remotely on a LAN, or even over the intenret.. Even a 10Mbit ethernet connection vastly outruns the atari's ability to accept data. Someone could start server (and website front-end for administration/registration) that a)contains a copy of every publicly avaialable .ATR disk image that is available for the ATARI, and B)allows users to create an account that gives them a certain amount of storage space to create their own writeable disk images..

 

Of course this also depends on the way the ethernet adaptor is done.. If you use an embedded controller to run the TCP/IP stack and other low level protocols, it would be very feasible to include an handler in SDX that mounts remote storage devices in this way.. On the other hand, if your ethernet device relies on the 6502 to handle networking protocols, you are GREATLY reducing/limiting the practical/useful applications of the device, itself, and probably preempting any possibility of a universal remote storage solution.

 

Now.. Secondly, I'll say this.. The ATARI needs a better "PBI Standard".. The PHI2 timing issue is a bitch.. The 1090XL was designed to fully buffer all the needed bus signals, so that up to 8 devices could "live" together without severe bus timing skew in relation to various signals.. This is not the case with any scheme that involves plugging "PBI devices" directly into the ATARI.

 

Niether the Black Box or MIO is an "ATARI LEGAL" PBI device.. They are more like a "PBI bus hog".. They were designed with the idea that they would be the only device plugged into the atari, and that the atari would not have a massive amount of internal expansions also "hanging off the bus" so to speak. As Candle, Hias, and others have poitned out in the past, theres no reason that correctly designed PBI devices can not coexist on the same system. But I say from experience, that the more stuff you connect to the data bus, whether it be an internal expansion, cartridge, or PBI device, the more critical and hard to "tune" the PHI2 timing becomes. What we need is a universal adaptore board that employs the same principles that the 1090XL was deigned with. To have the greatest functionality/flexibility, this would probably need a "ribbon cable" going to various points inside the machine for various signals, in addition to what is available at the standard PBI/ECI connectors. If you want a path for the ATARI to have serious "plug in" expansion possibilities in the future (in the same sense that the Apple II and PC did) then I think a universally accepted upgrade to the PBI standard is in order..

 

The Ethernet device being produced is a standard cartridge. It's got a cs8900 Ethernet module on it.

http://www.atari8ethernet.com/

 

I am doing the stack on the 6502 side. Obviously its limiting compared to a seperate processor board, but I haven't found it to be unworkable. As you say, you cant write data any faster than the disks anyways. What we are developing shoudl be very useful. I already have a UDP based file copy program that works well, and the Contiki ethernet apps work as well.

Edited January 28, 2011 by danwinslow

[erazmus]

If you want a path for the ATARI to have serious "plug in" expansion possibilities in the future (in the same sense that the Apple II and PC did) then I think a universally accepted upgrade to the PBI standard is in order..

Has the schematics for the 1090XL ever surfaced, or has anyone reverse engineered it? I think it would be kind of neat to make replica 1090XL expansions, and build new peripherals that meet that 'standard'.

[Defender II]

If you want a path for the ATARI to have serious "plug in" expansion possibilities in the future (in the same sense that the Apple II and PC did) then I think a universally accepted upgrade to the PBI standard is in order..

Has the schematics for the 1090XL ever surfaced, or has anyone reverse engineered it? I think it would be kind of neat to make replica 1090XL expansions, and build new peripherals that meet that 'standard'.

 

Yes, Curt has them click this link to the old thread I don't know if he finished.

[flashjazzcat]

Wow... I didn't even know such a thing as a 1090XL ever existed. Just been checking it out at the Atari museum. It's a real shame the project was abandoned.

 

Meanwhile, I've begun the serious work of rewriting the existing menu system using the object heirarchy code I wrote the other week. It's the first time any of this code has been tested, and I'm at the stage of rendering a menu bar using its redraw method. It doesn't look like much yet and does nothing, but the menu bar is built from real menu bar title objects contained in their parent container. The object creation and memory allocation routines appear to be working OK, with all the parent/child pointers and linked lists tying up correctly. It'll probably take a week or so to get the new event handler written and a cascading menu demo working, but from that point on, things will get dramatically easier, and I can start coding up new object types and interacting with them. Hopefully in a month or so we'll have a fairly complete control set with which to code up a working window and dialogue box.

[MEtalGuy66]

The Ethernet device being produced is a standard cartridge. It's got a cs8900 Ethernet module on it.

http://www.atari8ethernet.com/

 

I am doing the stack on the 6502 side. Obviously its limiting compared to a seperate processor board, but I haven't found it to be unworkable. As you say, you cant write data any faster than the disks anyways. What we are developing shoudl be very useful. I already have a UDP based file copy program that works well, and the Contiki ethernet apps work as well.

 

No, what I said is that the ATARI cannot move data as fast as 10mbit ethernet's max throughput.. period.. The disks we are talking about replacing where the MIO/BLACKBOX/IDEa are concerned are modern hardisks and flash devices which also function much faster than the atari can move data.

 

I did not say you couldnt make a functional TCP/IP stack on the 6502. WHat I said was that you are gonna severely limit its applications/usefulness. And by that I mean that theres no way in hell you are gonna get anywhere near the throughput (which would be possible with an embedded processor handling all the networking protocols that you are going to have to run on the 6502) neccesary in order to do remote emulation of ALL storage devices, and therefore completely negate the need for other PBI devices.

Edited January 28, 2011 by MEtalGuy66

[flashjazzcat]

Can the TCP/IP stack be stored in extended RAM? I must confess I'm not sure of the order of magnitude of memory these things consume.

[danwinslow]

Yes, I think so, and I am planning on doing so. The data size isn't too extreme, given the limitations. There's a lot of code though. Right now the stack is about 10k-ish in size, without a TCP layer. I can squeeze that down a bit, and hopefully after adding TCP I can still fit it into one 16k bank. My ultimate goal is to get into a single separately loadable and resident bank, and drive it with a VBI.

[flashjazzcat]

I don't pretend to understand TCP/IP stacks (despite some cursory reading), but it does look code-intensive. Even some microcontroller implementations quote quite large amounts of RAM for code.

 

Trying to shoe-horn modern software technology onto the A8 unsurprisingly eats RAM. As soon as I realized how many problems having a complete bit-mask of all the overlapping windows sould solve, I decided to devote 8K to it. Similarly, we can do easy clipping (and even modeless dialogue boxes) using large bitmasks. I'm just being careful not to make the minimum spec exceed four extended banks (obviously the solution is to make the memory set-up flexible, with more memory permitting more resident fonts and more windows). I'm just glad I started writing the GUI in assembler, mind-bendlingly strenuous though it is at times (the recursive object tree walker was a real pain).

 

The Atari's banking system isn't too limiting for stuff like this, though. The average GUI object size being around 20 bytes, we can fit a hell of a lot of them into 16KB. I'll probably end up adding a "bank number" property to each object when more than one bank is used. It might also be nice to buffer access to the objects via the API, so, for example, you can load a whole object into a string in Basic, make changes to it, then send it back.

Edited January 31, 2011 by flashjazzcat

[flashjazzcat]

Not that I'm one for unrealistic project timescales (er, ahem), but I'm about half way through the coding for the GUI library. That's a month of coding and 3,600 lines of code. I figure the first beta of the library/GUI will be double that size, and that's not including the desktop manager. In the meantime, I hope to have a "playable" demo in the next couple of weeks.

Edited January 31, 2011 by flashjazzcat

[+wood_jl]

I'm hardly qualified to make suggestions, but I'd drop all that TCP/IP stuff from the GUI - I'm assuming (from above discussion) it's a consideration at all. If it's going to eat up RAM - who has any serious intention of getting online with the 8-bit, anyway. Just having a GUI is enough!

[flashjazzcat]

I'm hardly qualified to make suggestions, but I'd drop all that TCP/IP stuff from the GUI - I'm assuming (from above discussion) it's a consideration at all. If it's going to eat up RAM - who has any serious intention of getting online with the 8-bit, anyway. Just having a GUI is enough!

It's entirely down to application developers. If someone wants to integrate TCP/IP functionality into the GUI, I'd be happy for them to do so. It's not something I'm going to worry about at the moment.

 

I'll put the call out right now to application developers: I should be able to provide a draft API spec in a couple of months, and we need applications (a spreadsheet, for example), otherwise the whole thing will die on its ass. I've already got the task of writing not only the desktop file manager but a rather ambitious word processor. Mr Fish is interested in writing some apps, too, as well as doing the graphic design work.

 

Any developers requiring inspiration should look here:

 

New Atari 8-bit GUI

[danwinslow]

who has any serious intention of getting online with the 8-bit, anyway. Just having a GUI is enough!

 

Me.

 

But, I agree with you, there's no need to add a network stack into an already compilcated framework. But, I plan to try and do some as applications that run under the framework that flashjazzcat provides. It might not be possible, but I'll certainly give it a look.

[+wood_jl]

 

Any developers requiring inspiration should look here:

 

New Atari 8-bit GUI

 

I'm no developer. However, I offer the following cliche: You're the man!

[AtariNerd]

Any developers requiring inspiration should look here:

 

New Atari 8-bit GUI

 

I'm no developer. However, I offer the following cliche: You're the man!

 

^2

[ToddUGA]

Wow. Just...wow.

 

When this thing is finished I'm taking a copy back in time with the time machine in my basement and giving it to late 70's Atari. We shall rule the computing world.

[flashjazzcat]

Thanks. I still get mesmerized by the drop-down menus running so fast on a real machine. I can't wait to start dragging icons around.

[atarixle]

Your Preview looks really good, and I'm looking forward to a first release.

 

As the memory of the small 8-Bit is limited, I'm thinking of dropping any Menus on my BOSS-X GUI. I'm not running behind Microsoft Windows, which runs behind Mac OS, which drops/never had menus in it's windows. But now, when you see the Icon-Bar on the top of the screen, there is no need for the memory-intensive, redraw-needing menu-implementation. I think I will go this way.

[flashjazzcat]

Icon bars certainly save memory, although you then have the overhead of the bitmap data for the icons. A reasonable resolution (which I think we're going to use) is 16x16, which takes up 32 bytes (plus another 32 for the icon's mask). The nice thing about a menu system on a limited-resolution screen is that you can map out around 60-70 selections in the top level menus. If you want to do this with an icon bar, you'll need a tabbed interface (similar to Microsoft's "ribbon"). I intend to implement icon toolbars as a control, but only for a limited sub-set of commonly-used selections (or let the user drag which icons they want onto the toolbar).

 

These menus don't require any redrawing as such. They employ a back-buffer on a stack. An average menu probably pushes about 2-3KB of background data onto the stack, and any subordinate cascading menus a lot less (since they're usually smaller). On top of this, the whole menu structure exists as a static object heirarchy (in a tree structure), with each node occupying about 20 bytes. All items are objects, as are the containers (the menu panes). So a menu structure with six top-level menus each with ten items in them will consume 1.5KB of object tree space, plus the text strings and flags for each menu item (which exist in the resource, either in the application code or in a resource buffer). On top of that you have the background buffer.

 

The solution is to keep the back buffer in one bank, the object tree in another, and fonts and bitmaps in another. This leaves all the conventional memory free for code space (in your chosen language). I'd never done any object-oriented programming before I started this project, but once the mechanisms are in place, the whole heirarchy just takes care of itself. You want a window? Just add it as a child object of the desktop. The event handler then automatically "sees" the window and all its child objects (the workspace, window controls), and takes care of all the callbacks when a user clicks on something. The user resized the window? The event handler issues a redraw message to the window, which closes itself down and redraws itself with the new proportions. The application doesn't necessarily need to intervene at all.

 

Great fun, I have to say.

Edited February 2, 2011 by flashjazzcat

[+Allan]

This is looking fantastic. I can't wait to see more.

 

Could existing popular programs be modified so that they behave when launched from your GUI and then return to it?

 

Allan

[flashjazzcat]

This is looking fantastic. I can't wait to see more.

 

Could existing popular programs be modified so that they behave when launched from your GUI and then return to it?

The aim is that ALL existing software will be lauchable from the GUI, and will go straight back to the desktop when it quits. Since the desktop itself will be an application, this will need to be re-loaded from disk anyway (a bit like DUP.SYS, or COMMAND.COM in SDX). Of course, we'll also have to do an integrity check to ensure the GUI library itself (wherever it lives) hasn't been overwritten. If it has, we need to re-install that too.

[+Allan]

This is looking fantastic. I can't wait to see more.

 

Could existing popular programs be modified so that they behave when launched from your GUI and then return to it?

The aim is that ALL existing software will be lauchable from the GUI, and will go straight back to the desktop when it quits. Since the desktop itself will be an application, this will need to be re-loaded from disk anyway (a bit like DUP.SYS, or COMMAND.COM in SDX). Of course, we'll also have to do an integrity check to ensure the GUI library itself (wherever it lives) hasn't been overwritten. If it has, we need to re-install that too.

Cool. It would be great to see even some games written with the GUI.

 

Of course you have to have the traditional calculator.

 

Allan

[atarixle]

You benefit a lot from the language of your choice, assembler. As long as I still write in Turbo-BASIC, I have to use the commands included in TB. So it's a little hard to use a back-buffer for menus (and for the menus only .... having a back-buffer for the whole screen is no problem - I'm thinking about using the RAM-Disk as back-buffer to improve speed). So I prefer to do a complete screen-refresh. You can make your own particular-back-buffer-routines, and you have a lot more memory left because you don't need to pre-load TB. You also can benefit from directly accessing the RAM-Disk/additional memory.

 

The Icon-bar doesn't need much memory - it's stored in the RAM-Disk (only the PM-Layer has to be in the main-memory). It's tricky, 16x16 icons were too small to show what function is hidden behind them. On the other hand, 16x16 icons need less than half the memory for the PM-Layer (8x16 instead of 16x24 - where only 12x24 are used on 24x24-icons).

 

To store like 70 functions behind the menus could be a little much, I'd re-load functions from the RAM-Disk in that case (which I already do in the BOSS-X 10.3 Desktop). But on usual programs I can't offer so much functionality (this will change in 10.4 when programs load some resources into the RAM-Disk).

 

All-in-all your GUI will be so much better than mine, I'd be proud if you use some Art-Work from my system ... so I can say "see, there are parts of my work in it"

[flashjazzcat]

Naturally coding in TB is limiting, but the development cycle is quicker, providing you have realistic goals. Keeping stuff on the RAM-disk is a good solution, and in several respects somewhat "safer" than using direct memory addressing. I was considering implementing some kind of swap file, but it wouldn't be much use unless the user has a hard disk (in which case it will be very effective indeed), and there may well be no RAMdisk, since I've already used the 130XE's memory.

 

The resolution of icons was something I meant to mention last time around as well. Unless you have pop-up "tool-tips", it's very important that the icon image clearly describes its function. There's no room on the Atari's screen for the icons in a toolbar to have even small descriptive labels. Your decision to use colour (which is very well implemented) creates further complications, as you say.

 

As far as the complexity of menus is concerned, this highlights the fact that Boss-X and the "unnamed project" are different beasts. The new GUI is sopposed to be a complete platform for WIMP application development. Pin over at AtariArea has drawn attention to the also excellent TRS Desktop, which employs a totally different interface again (highly icon-oriented). I don't know much about the inner workings of either Boss-X or TRS (also written in TBXL, I understand), and I'm not sure if TRS has an API which one can use to write applications which use the TRS "look and feel", and access a complete control set.

 

The new project, on the other hand, is all about the API, and this also applies if a sub-set of the code is released for stand-alone apps which wish to incorporate a GUI interface. One should be able to sit down and write an application which entirely and solely communicates with the user via calls to the GUI library. This means a unified "look and feel", reduced application code size, and a rich control set. Once you have written one application, the skeletal structure will be the same for any other application you write.

 

One of the drawbacks I found with Diamond GOS was that, for example, when designing a dialogue box, one first placed the controls in the box, then set up touch areas for mouse interaction. The controls themselves were static entities with no inherent methods or behaviour. The text input routine was completely "blocking" until you pressed return.

 

The aim here - which I shall shortly demonstrate by example (he said with confidence!) - is to make objects and controls which are inherently active. As soon as a button is placed on the screen with some code attached to it, it is clickable, it accepts and yields the focus, and it executes your code when you click on it (or returns a exit condition to the dialogue handler).

 

The other major aspect of the new GUI is of course the aesthetic. Fonts are proportional, aren't confined to 8 bytes per character, and can have a number of style attributes. We're going for a "small classic Mac", no bones about it!

 

I'm no expert in OOP programming, but I've researched the subject well and I don't know if what's being implemented (i.e. totally data driven GUI applications) has been done on the A8 before, although Contiki appears to implement a full object heirarchy (albeit without the GUI in the case of the Atari port).

 

Yes: the choice of assembly language means you can do just about anything under the sun. But the development cycle is much slower, the coding more difficult, and the debugging more fraught. Two hours single-stepping trees and linked lists in machine code? Who really wants that?

 

The point is that it's not a competition! "Better" is subjective (and my, haven't we seen that demonstrated on these forums lately). There have been half a dozen GUIs for the Atari 8-bit, and I'm glad to see at least a couple of them still in active development. TRS and Boss-X are both technical feats, and there are many different ways to solve the same problem. That's why there's always room for one more on board. But as an application developer, the kind of API I'd like to see in a GUI on the A8 hasn't presented itself to me yet.

 

BTW: as far as incorporating artwork, you'll have to speak to my artistic director, Mr Fish.

Edited February 2, 2011 by flashjazzcat

[atarixle]

The new project, on the other hand, is all about the API, and this also applies if a sub-set of the code is released for stand-alone apps which wish to incorporate a GUI interface. One should be able to sit down and write an application which entirely and solely communicates with the user via calls to the GUI library. This means a unified "look and feel", reduced application code size, and a rich control set. Once you have written one application, the skeletal structure will be the same for any other application you write.

 

On BOSS-X, not an usual API, but something you would call a "framework" is provided to write own BOSS-X programs (BOSSXGND.BOS Disk 2/Side a, bossx3c.atr). May be someone wants to take a look?

[danwinslow]

Jon, to register a callback on a control, you pass in ... what? A bare address to jump to? You'll need to specify some kind of parameter passing mechanism so that the callback code can get context data. Also, from your description you'll potentially be jumping from banked code to non-banked and back, and you might be jumping to a memory location that is switched out at the time of the call ( because the GUI code is running ), so you'll need some kind of wrapper mechanism to make sure that the callback proceeds from somewhere that is guaranteed to not be switched out. That wrapper would gather the parameters, swap the user bank in, and jump to the user code. Then the RTS from the user code would go back to the wrapper, which would then swap the GUI bank back in and RTS back to it. In C I've used a wrapper located in high memory for this kind of thing.