New GUI for the Atari 8-bit

[spookt]

Wanna see my W.I.P.? http://andymanone.dyndns.org/atarixle/download/bossx/BeWeBOSS16.zip

 

should work in any emulator with RAM-Disk and joystick in port 1. This is a very special milestone as it can change the GUI language on-the-fly even without re-starting the program or anything else...

 

Nice work. I do like the way the icons get highlighted with colour when you mouse over them. I actually spent a moment wondering why I couldn't move the mouse pointer out of the emulator window with the cursor keys to come back to Safari!

[potatohead]

Very nicely done! Watching this with interest.

[flashjazzcat]

By better management on the mouse pointer enable/disable routine (which waits a jiffy to sync with the interrupt), I've doubled the speed of the menu renderer:

 

 

I don't think pre-rendered bitmap menu panels would be much faster than that.

That looks incredibly responsive! Really looking forward to this.

Thanks. Responsiveness is the key. It's absolutely vital to a GUI. The sluggishness of GEOWrite on the C64 even put me off, I'm afraid. Any theoretical text on GUIs will stipulate that the use must feel in control. Obviously there's only so much we can do on an 8-bit system, but if it takes ten seconds to refresh a window full of icons, it would be quicker to go back to the command line.

[+Philsan]

By better management on the mouse pointer enable/disable routine (which waits a jiffy to sync with the interrupt), I've doubled the speed of the menu renderer:

 

 

I don't think pre-rendered bitmap menu panels would be much faster than that.

Fake...

That's what everyone not knowing your terrific skills should write after having seen this awesome video.

[flashjazzcat]

We have italics!

 

 

The renderer will handle up to 24 x 24 pixel characters; anything more than this seems impractical, since the font files would consume more than 16KB.

[Rybags]

Looks pretty cool... so they're just derived from your default chset by bitshifts?

 

I did that in Quadrillion, just single-shifted the bottom half of the Atari character set for a "free" light italic effect.

 

I have a bit of an idea for doing derived outline characters, but it'd likely need tables to work. But significant saving could be had at the cost of speed by just doing it by nybble.

Edited January 25, 2011 by Rybags

[flashjazzcat]

Yeah - just bitshits. The old Apple Macs used a similar algorithm (which tends to form breaks in narrow characters with slanted verticals).

 

Funny you should mention outline characters, since I talked about outlining to Paul earlier today. My idea was to shift and OR by one pixel on all 4 axes, and then XOR the original bitmap into the middle. Not sure how that would be economically incorporated into the rendering routine. The left/right shift and ORing is easy to do on a per-line basis. It's the vertical shift/OR which would be trickier.

Edited January 25, 2011 by flashjazzcat

[Fletch]

Very impressive! I'm amazed at the quality of new stuff being made for 30 year old hardware. Kudos!

[potatohead]

Yeah, isn't it great! I'm thinking at some point, it's gonna be fun to do some basic writing on the old Atari.

[danwinslow]

Yeah - just bitshits.

 

O my! Isn't that an illegal instruction

[flashjazzcat]

Yeah - just bitshits.

 

O my! Isn't that an illegal instruction

Indeed so! That's the new term for "bitshifts", now they've been replaced with lookup tables.

Edited January 25, 2011 by flashjazzcat

[+wood_jl]

We have italics!

 

 

The renderer will handle up to 24 x 24 pixel characters; anything more than this seems impractical, since the font files would consume more than 16KB.

 

If you're not taking the Atari hardware "where no man has gone before" (I suspect that you are) then you're awfully close. This is incredibly awsome!!!

[atarixle]

Looks pretty great. When do you think a first fully working demo app will be available?

Edited January 26, 2011 by atarixle

[frogstar_robot]

Looks pretty great. When do you think a first fully working demo app will be available?

 

Expect it to be awhile. Looks like he's got his drawing primitives about 80% of the way there. That done, it will be a similar amount of work to come up with a minimal but usable API. Much of that is tolerably difficult work like text entry widgets and filebrowsers (depending of course how much he wants to flesh it out) and work on the application programmer interface will of course reveal limitations and suggest improvements to the underlying drawing code.

 

It is at that point a demo app can be developed and everybody else turned loose in the playground. Though what he's doing now really is the hardest part and looks awesome.

[JamesD]

Looks good!

 

A program similar to this Atari project was used on several CoCo applications including CoCo Max which is basically a Mac Write clone. It worked really well.

 

Someone also made what is basically a port of the MacOS to the Adam many years ago. If I remember right, the whole thing was a bit of a fiasco with people donating money up front and it didn't get released. After legal action it was released in some form (a demo?) and it actually worked but took so much memory you couldn't do anything with it.

I think if you want to go very far with this it would be a good idea to create a version for 128K machines where the APIs are in the paged RAM where possible.

[flashjazzcat]

Looks pretty great. When do you think a first fully working demo app will be available?

 

Expect it to be awhile. Looks like he's got his drawing primitives about 80% of the way there. That done, it will be a similar amount of work to come up with a minimal but usable API. Much of that is tolerably difficult work like text entry widgets and filebrowsers (depending of course how much he wants to flesh it out) and work on the application programmer interface will of course reveal limitations and suggest improvements to the underlying drawing code.

 

It is at that point a demo app can be developed and everybody else turned loose in the playground. Though what he's doing now really is the hardest part and looks awesome.

Yes: quite a while. The font renderer was indeed pretty tricky, and that's just about finished (apart from some basic clipping routines). Even the widgets don't pose too much of a challenge, since once everything's considered in terms of the object heirarchy, it becomes a case of simply churning out the code and testing it. Even scroll bars aren't too difficult once every component of the control is an object. Much of the object tree/linked list code is already written, but untested. I think the biggest challenge will be writing object clipping routines which allow icons and other objects to partly disappear off the edges of windows, yet still be selectable. Some kind of off-screen coordinate system will have to be implemented, and clicks and screen draws will have to be clipped (on byte boundaries) to the parent container.

 

The most sensible "demo app" (apart from a text editor and a version of the MyIDE FDISK program) will be a resource editor. This is really top of my list, so that Mr Fish has a proper editor for icons and fonts. His input into the design aspect of this project is imperative, and having the font/icon design work taken off my hands frees me up to concentrate on the programming.

 

Looks good!

 

A program similar to this Atari project was used on several CoCo applications including CoCo Max which is basically a Mac Write clone. It worked really well.

 

Someone also made what is basically a port of the MacOS to the Adam many years ago. If I remember right, the whole thing was a bit of a fiasco with people donating money up front and it didn't get released. After legal action it was released in some form (a demo?) and it actually worked but took so much memory you couldn't do anything with it.

I think if you want to go very far with this it would be a good idea to create a version for 128K machines where the APIs are in the paged RAM where possible.

These old ports are all interesting to me. The opportunity to study the source code (ideally 6502 assembler) of any small GUI implementation is usually informative. I've been browsing through the TOS 4 source code (in C, of course), although that's a little dense for our purposes here (the menu code alone is hundreds of lines long). I'll be chasing up the CoCo / Adam projects. If anyone has any links, they'd be appreciated. Sometimes even using a small GUI, or reading the API docs is a big source of inspiration.

 

What I'd really love to have a look at is the source code for MouseDesk on the Apple II. It's probably closest to what we'll be able to achieve here.

 

Good point re: 128K, BTW. Things are shaping up so that fonts will occupy one bank, background screen buffers another (basically for saving info under menus, etc), and the heap/stack will sit in a third bank (for storing all the objects). If all the objects are addressed indirectly (as they should be, strictly speaking), the language interfacing with the API will never have to explicitly bank switch the memory. This should mean that apps can happily be written in BASIC, without having to do complex buffer allocation in main memory.

 

A long way to go, though, and I'm sure there'll be stumbling blocks and what seem like compelling reasons to abandon the project before it gets finished.

[JamesD]

Looks good!

 

A program similar to this Atari project was used on several CoCo applications including CoCo Max which is basically a Mac Write clone. It worked really well.

 

Someone also made what is basically a port of the MacOS to the Adam many years ago. If I remember right, the whole thing was a bit of a fiasco with people donating money up front and it didn't get released. After legal action it was released in some form (a demo?) and it actually worked but took so much memory you couldn't do anything with it.

I think if you want to go very far with this it would be a good idea to create a version for 128K machines where the APIs are in the paged RAM where possible.

These old ports are all interesting to me. The opportunity to study the source code (ideally 6502 assembler) of any small GUI implementation is usually informative. I've been browsing through the TOS 4 source code (in C, of course), although that's a little dense for our purposes here (the menu code alone is hundreds of lines long). I'll be chasing up the CoCo / Adam projects. If anyone has any links, they'd be appreciated. Sometimes even using a small GUI, or reading the API docs is a big source of inspiration.

The CoCo stuff was commercial and source code has never been released. I believe the GUI stuff was sold as a stand alone product you could build apps around but I've never seen that myself so I can't be sure.

 

I don't think the Adam source was released either but I've only read about it in some old Adam newsletters so I can't be sure.

The author basically took a reference book of the Mac APIs and wrote Z80 equivalents. At least that's my understanding.

 

 

What I'd really love to have a look at is the source code for MouseDesk on the Apple II. It's probably closest to what we'll be able to achieve here.

I've never seen MouseDesk.

 

Good point re: 128K, BTW. Things are shaping up so that fonts will occupy one bank, background screen buffers another (basically for saving info under menus, etc), and the heap/stack will sit in a third bank (for storing all the objects). If all the objects are addressed indirectly (as they should be, strictly speaking), the language interfacing with the API will never have to explicitly bank switch the memory. This should mean that apps can happily be written in BASIC, without having to do complex buffer allocation in main memory.

Nice!

 

A long way to go, though, and I'm sure there'll be stumbling blocks and what seem like compelling reasons to abandon the project before it gets finished.

Keep up the good work!

[flashjazzcat]

I don't think the Adam source was released either but I've only read about it in some old Adam newsletters so I can't be sure.

The author basically took a reference book of the Mac APIs and wrote Z80 equivalents.

That's basically what I'm doing now (using the Apple IIGS Programmer's Reference). I don't think there's much original Apple source code floating around. I think they've kept everything close to their chest, although I did read a story about some people at MIT working on something to do with the MouseDesk source code (MouseDesk was a front-end for the original Apple II, and wasn't a full GUI operating system).

 

Anyway, the nice thing is the API shouldn't be too far removed from that described in the Apple IIGS docs.

 

This thing's going to use memory like it was going out of fashion. One approach (doubtless unpopular with SpartaDOS 3.x fans) is to put the GUI library in the Shadow RAM, use three 130XE banks for stack/objects/fonts, leaving 30K of main RAM for GUI applications, which will also be able to keep data/additional code in any additional extended banks. Static resource data (menu text strings, bitmaps, dialogues) could be held in main memory or in an extended bank. This will method will of course also rule out the use of Turbo Basic XL, but the only other option (realistically) is to put the GUI on a cartridge, and that slashes the application code space by 8K.

 

I already decided this morning that we'll need one huge bitmask representing the shape of all intersecting windows on the desktop in order to render the desktop icons in just the way I want them (i.e. selectable and re-drawable while partly obscured by intersecting windows). Diamond solved this problem by making partly obscured desktop icons completely vanish from view, but we're going for the full beans here.

[danwinslow]

I don't think the Adam source was released either but I've only read about it in some old Adam newsletters so I can't be sure.

The author basically took a reference book of the Mac APIs and wrote Z80 equivalents.

That's basically what I'm doing now (using the Apple IIGS Programmer's Reference). I don't think there's much original Apple source code floating around. I think they've kept everything close to their chest, although I did read a story about some people at MIT working on something to do with the MouseDesk source code (MouseDesk was a front-end for the original Apple II, and wasn't a full GUI operating system).

 

Anyway, the nice thing is the API shouldn't be too far removed from that described in the Apple IIGS docs.

 

This thing's going to use memory like it was going out of fashion. One approach (doubtless unpopular with SpartaDOS 3.x fans) is to put the GUI library in the Shadow RAM, use three 130XE banks for stack/objects/fonts, leaving 30K of main RAM for GUI applications, which will also be able to keep data/additional code in any additional extended banks. Static resource data (menu text strings, bitmaps, dialogues) could be held in main memory or in an extended bank. This will method will of course also rule out the use of Turbo Basic XL, but the only other option (realistically) is to put the GUI on a cartridge, and that slashes the application code space by 8K.

 

I already decided this morning that we'll need one huge bitmask representing the shape of all intersecting windows on the desktop in order to render the desktop icons in just the way I want them (i.e. selectable and re-drawable while partly obscured by intersecting windows). Diamond solved this problem by making partly obscured desktop icons completely vanish from view, but we're going for the full beans here.

 

About all the banking, I was thinking that it would be good to have some external control over what the banking scheme is and maybe what banks can be used for what. Some kind of config file that would hold info about how to bank and which banks are free for use and which are reserved. This could possibly let an ordinary ramdisk still work while GUI apps bank 'around' it.

 

For my part, I am now starting on moving the Ethernet stuff into banked code. I think as more and more banked apps appear it would be very handy to have an agreed-upon standard banking config file.

[flashjazzcat]

About all the banking, I was thinking that it would be good to have some external control over what the banking scheme is and maybe what banks can be used for what. Some kind of config file that would hold info about how to bank and which banks are free for use and which are reserved. This could possibly let an ordinary ramdisk still work while GUI apps bank 'around' it.

 

For my part, I am now starting on moving the Ethernet stuff into banked code. I think as more and more banked apps appear it would be very handy to have an agreed-upon standard banking config file.

I'm one hundred percent in agreement with everything you say there. I tried to make the word processor as configurable as I could with regard to banking, but even finer control would be better for some people, and I think that should be built into this project.

 

I have even emailed Drac030 on the subject of SDX banking. I'm interested in his ideas, since SDX has an excellent and accessible banking list. However, there's still no obvious way for - say - the GUI to dictate to a non-GUI-aware legacy application (such as The Last Word) - that it must avoid certain extended banks.

 

I think we discussed the idea of a standard elsewhere some time ago, and I'd like to get that moving again. A DOS memory driver is one possibility: something which expands upon the methods used in SDX. DOS should be able to reserve memory (for a RAMdisk, etc), and other apps should be able to interrogate the list and allocate memory for their own use.

 

As things stand at the moment, to have any hope of being useful, the GUI can make no real assumption that anything stored in extended/shadow RAM will still be there when a legacy application has finished executing. The only way will be to perform an integrity check on re-entry to the desktop and reload everything if necessary.

[danwinslow]

About all the banking, I was thinking that it would be good to have some external control over what the banking scheme is and maybe what banks can be used for what. Some kind of config file that would hold info about how to bank and which banks are free for use and which are reserved. This could possibly let an ordinary ramdisk still work while GUI apps bank 'around' it.

 

For my part, I am now starting on moving the Ethernet stuff into banked code. I think as more and more banked apps appear it would be very handy to have an agreed-upon standard banking config file.

I'm one hundred percent in agreement with everything you say there. I tried to make the word processor as configurable as I could with regard to banking, but even finer control would be better for some people, and I think that should be built into this project.

 

I have even emailed Drac030 on the subject of SDX banking. I'm interested in his ideas, since SDX has an excellent and accessible banking list. However, there's still no obvious way for - say - the GUI to dictate to a non-GUI-aware legacy application (such as The Last Word) - that it must avoid certain extended banks.

 

I think we discussed the idea of a standard elsewhere some time ago, and I'd like to get that moving again. A DOS memory driver is one possibility: something which expands upon the methods used in SDX. DOS should be able to reserve memory (for a RAMdisk, etc), and other apps should be able to interrogate the list and allocate memory for their own use.

 

As things stand at the moment, to have any hope of being useful, the GUI can make no real assumption that anything stored in extended/shadow RAM will still be there when a legacy application has finished executing. The only way will be to perform an integrity check on re-entry to the desktop and reload everything if necessary.

 

I think a dos 'extended-memory' driver is an ultimate goal...as long as it doesn't try to do too much. 'virtualizing' the memory access completely is probably not feasible, or desireable. I think a good place to start would be a simple config file that has information about how to bank select, and allows for reserving banks for named applications. Of course, you'd have to pay attention to it, and unaware apps would continue to do whatever they wanted, but at least you could use it to inform aware applications what their banking space looked like.

[flashjazzcat]

I think a dos 'extended-memory' driver is an ultimate goal...as long as it doesn't try to do too much. 'virtualizing' the memory access completely is probably not feasible, or desireable. I think a good place to start would be a simple config file that has information about how to bank select, and allows for reserving banks for named applications. Of course, you'd have to pay attention to it, and unaware apps would continue to do whatever they wanted, but at least you could use it to inform aware applications what their banking space looked like.

Quite so. I don't know off-hand how many applications use extended RAM beyond the usual 4 banks in an unrestrained manner, but people aren't going to stop using those programs (I hope not, since one of them is mine). Of course, any layer which exists between DOS and legacy apps is always going to be on shaky ground when it comes to memory use. But at least we can make the information there for apps which want to take advantage of it.

 

Total virtualizing: not feasible or desirable, mainly because it's too damned slow. I think we can do little more than say to an application: "here's the PORTB mask for a free bank if you want to use it".

[danwinslow]

I think a dos 'extended-memory' driver is an ultimate goal...as long as it doesn't try to do too much. 'virtualizing' the memory access completely is probably not feasible, or desireable. I think a good place to start would be a simple config file that has information about how to bank select, and allows for reserving banks for named applications. Of course, you'd have to pay attention to it, and unaware apps would continue to do whatever they wanted, but at least you could use it to inform aware applications what their banking space looked like.

Quite so. I don't know off-hand how many applications use extended RAM beyond the usual 4 banks in an unrestrained manner, but people aren't going to stop using those programs (I hope not, since one of them is mine). Of course, any layer which exists between DOS and legacy apps is always going to be on shaky ground when it comes to memory use. But at least we can make the information there for apps which want to take advantage of it.

 

Total virtualizing: not feasible or desirable, mainly because it's too damned slow. I think we can do little more than say to an application: "here's the PORTB mask for a free bank if you want to use it".

 

Yes, I think we are on the same page...or should I say bank . I will take a stab at starting it as part of my Ethernet work, and then I'll post an alpha of it in teh programming forum and request comments. I'm sure I'll get a few.

[+David_P]

I'd like to see the Ethernet cart as a PBI device - that way it would have the 4K available by disabling the math pack; split it into a 2K fixed / 2K banked and you could use a 32K EEPROM and need to latch only 4 lines - and no interferenfe with any extended RAM. Under the OS, on the other hand, might present some problems, and the MIO.IDEa/BlackBox crown would get grumpy.

[MEtalGuy66]

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..

Edited January 28, 2011 by MEtalGuy66