New GUI for the Atari 8-bit

[flashjazzcat]

Hah yknow I was thinking of a female name as well, also started with hearkening back to Lisa. If 'Deborah' is who I think her to be then for the sake of your future availability I suggest we so honor her.

Heh... I try not to harken back to Lisa if I can avoid it.

 

But I think Deborah would be truly delighted by such an honour. The guidance, encouragement and inspiration... well, even without providing any of that, she does still feed me in between programming stints.

[Mclaneinc]

I though AGOS was ok...wasn't that what you started with?

A:GOS originally stood simply for "Atari GOS", then later morphed into meaning "Agis", which is the name of a series of Spartan kings, providing a nice link to the SpartaDOS tradition. It's also a phonetic pun on "A:GOS". The Greek connection also allows us to use the Alpha character on the system menu.

 

I'll speak to Mr Fish about it. It's probably one of the last details we'll decide on.

 

Of course, I could also call it "Deborah OS"... the rightful and vastly superior successor to "Lisa".

 

I suppose that's better than my choice of 'Jimmy Krankie OS'

 

Mind you I've never been great at naming things, my daughter, Gutbucket Gammylegs always moans

 

(her name is Serena and she's an angel of loveliness.....)

[UNIXcoffee928]

I wouldn't be too down on yourself for choosing an English Major. That was a lot of hard work, and gave you the excellent skills that you have shown with your exceptional documentation of The Last Word.

 

In fact, you would probably be better off writing a collection of short stories, perhaps in the Cyberpunk genre, (William Gibson's, Neuromancer, is a good start, if you're not familiar with the genre) where there will be a ready-made audience for your work, rather than bother with starting from scratch, all over again, in the professional computer biz... which is basically a dead end, anyway.

 

Face it, right at this very moment:

 

- The whole African Continent is heading toward revolution, country by country.

 

- Here, we have what amounts to "Great Depression, Part II, the Sequel" right at our doorsteps.

 

- There are vast degrees of unemployment & underemployment in the US & Europe.

 

- We have a complete & utter ecological nightmare to look forward to, in our old age, from years of greed.

 

- The old people can no longer retire, the young people have no jobs to secure their future (& I don't mean fast-food careers)...

 

- Who the hell would have imagined that we would have Pirates to contend with, in Modern Times?

 

Need I go on? (I could, really, for several hundred pages, lol... or perhaps, you should, ha). Personally, as a fan of History, it's pretty obvious to me that the only people that were living satisfactorily, during the First Great Depression, were the Entertainers, the Old Wealth, and the Corporate Moguls.

 

So, writing is probably a more valuable asset than computer work, say, if you like things like: eating, having a roof over your head, & a real flushing toilet. ha.

 

My suggestion is to: sit cross-legged in front of a mirror, alone, with a notebook & your favorite pen, stare into the mirror for a few minutes, then just start writing what comes into your head. Always works.

 

Despite your great skill with computers, my crystal ball says that you will make a better living writing, since you already have the skill & qualifications. Then, just use the proceeds to buy more gear (lol!), & just do your own thing with computers. You will probably be happier, in the long run. Really.

[UNIXcoffee928]

Here's a perfect recipe for your first Cyberpunk Novella... First read Neuromancer, then read the lyrics to Sabbath's "Into the Void", play & read Portal, tie it in with today's news headlines. Done.

 

If you drink enough coffee, you can get that done in three days. Then put out a Kindle ebook. Instant career.

[flashjazzcat]

LOL... I hear ya! Writing is another one of those pursuits I haven't followed in years. To be honest, since I got married, I haven't even read a novel: it's all computer press and other "coffee table" reading.

 

Ebooks and the online publishing revolution are something which happened in the hiatus since I last typed a word of fiction. Maybe when the GUI's done I could dig out some old copy (last short story was written in about 2006), or preferably write something new. The changes which happened in my life over the past three or four years should be sufficient inspiration in themselves. My favourite author was always Martin Amis (his books are my most prized, along with Nabokov's), and he got a lot of mileage out of reactions to capitalism and commentary on the money culture. Not even Martin seems to have written a novel for a few years, though!

 

If I do write more stories, I should really put my money where my mouth is and use The Last Word. I truly and genuinely believe the purchase of a Windows PC and Microsoft Word is what put the final nail in the coffin of my writerly aspirations.

 

By the way: I'm now doing the third re-write of the resource file format. When that's done, anyone who can work with a plain ATASCII text file will be able to code up and translate resources for the GUI.

[pixelmischief]

"I truly and genuinely believe the purchase of a Windows PC and Microsoft Word is what put the final nail in the coffin of my writerly aspirations."

 

I had the exact same experience! I had a novel fully developed. It was laid out on cards, I had the first chapter written, as well as a bunch of development material that would make into the book at other points. Every time I sat down to write, I just couldn't. It was impossible.

 

A buddy of mine who does web dev told me it was the platform. He owed me some money and convinced me to let him buy me a MacBook to do my writing. To tell the truth, I loved the Mac. It wasn't the solution to my writing problem, but it did show me just how much difference the right environment can make.

 

So I bought a TT, tricked it out, and it was my writing machine. I used a text editor instead of a word processor. No urge to format, no nag about misspelled words, and most of all, no games or Internet to distract me. For 2 hours a day, I focused on one thing: writing. The novel was done 3 months later, I an 1/2 way through my second now.

 

Do it. Dedicate a machine to writing; a platform you love - one that feels like home. Then, set aside some time every day and write. It will change your life. It changed mine.

[+wood_jl]

I wouldn't be too down on yourself for choosing an English Major. That was a lot of hard work, and gave you the excellent skills that you have shown with your exceptional documentation of The Last Word.

 

Hell, I'm even more impressed with his work - both software and hardware wise - after seeing English major. Talk about a gifted English major!

[potatohead]

This is a great story!

 

Thanks for sharing it.

[flashjazzcat]

"I truly and genuinely believe the purchase of a Windows PC and Microsoft Word is what put the final nail in the coffin of my writerly aspirations."

 

I had the exact same experience! I had a novel fully developed. It was laid out on cards, I had the first chapter written, as well as a bunch of development material that would make into the book at other points. Every time I sat down to write, I just couldn't. It was impossible.

 

A buddy of mine who does web dev told me it was the platform. He owed me some money and convinced me to let him buy me a MacBook to do my writing. To tell the truth, I loved the Mac. It wasn't the solution to my writing problem, but it did show me just how much difference the right environment can make.

 

So I bought a TT, tricked it out, and it was my writing machine. I used a text editor instead of a word processor. No urge to format, no nag about misspelled words, and most of all, no games or Internet to distract me. For 2 hours a day, I focused on one thing: writing. The novel was done 3 months later, I an 1/2 way through my second now.

 

Do it. Dedicate a machine to writing; a platform you love - one that feels like home. Then, set aside some time every day and write. It will change your life. It changed mine.

Fantastic! I wrote a whole novel back in the mid-nineties using TextPro. I used the same program to write my dissertation and all my assignments, and I printed them out using Daisy Dot II. Like you say: no worries about formatting, no distracting screen clutter. I always wondered why I liked ProText on the ST so much. But The Last Word was designed to be exactly that distraction-free word processor. Maybe it's time I started using it!

 

OK: before I get back to the last hour's coding for the evening, here's a sample menu resource (TEST.RSC):

 

menu 1
[
&File
 [
 &New
 -
 &Open...
 Save &As...
 &Save
 &Close
 -
 E&xit
 ]
&Edit
 [
 &Undo/^Z
 -
 Cu&t/^X
 &Copy/^C
 &Paste/^V
 De&lete/Del
 -
 &Find.../^F
 Find &Next
 &Replace...
 &Goto...
 -
 Select &All/^A
 ]
&Format
 [
 Character
 Paragraph
 Font
   [
   8 Point
   10 Point
   12 Point
   ]
 ]
&Tools
 [
 &Options
 ]
&Help
 [
 View &Help
 &About
 ]
]

I coded this up using The Last Word, and it's about 1/3 of the size of the original menu structure definition in the example app's source code. The next demo is delayed yet again as I code up the parser for the resources. You can either "INS" the raw resource text into an app's executable, or (eventually) use a system call to load the resources from a file. Since the sequential order of the menus is perfectly obvious from this tree definition, the application can use a (menu,item) notation to set the checked/greyed-out flags for individual items. Of course, we'll need a resource editor, or at the very least a text editor which handles the GUI's 256 character fonts in order to make multi-lingual translations of the resource files. But no programming knowledge will be required.

 

 

Edited February 21, 2011 by flashjazzcat

[danwinslow]

"I truly and genuinely believe the purchase of a Windows PC and Microsoft Word is what put the final nail in the coffin of my writerly aspirations."

 

I had the exact same experience! I had a novel fully developed. It was laid out on cards, I had the first chapter written, as well as a bunch of development material that would make into the book at other points. Every time I sat down to write, I just couldn't. It was impossible.

 

A buddy of mine who does web dev told me it was the platform. He owed me some money and convinced me to let him buy me a MacBook to do my writing. To tell the truth, I loved the Mac. It wasn't the solution to my writing problem, but it did show me just how much difference the right environment can make.

 

So I bought a TT, tricked it out, and it was my writing machine. I used a text editor instead of a word processor. No urge to format, no nag about misspelled words, and most of all, no games or Internet to distract me. For 2 hours a day, I focused on one thing: writing. The novel was done 3 months later, I an 1/2 way through my second now.

 

Do it. Dedicate a machine to writing; a platform you love - one that feels like home. Then, set aside some time every day and write. It will change your life. It changed mine.

Fantastic! I wrote a whole novel back in the mid-nineties using TextPro. I used the same program to write my dissertation and all my assignments, and I printed them out using Daisy Dot II. Like you say: no worries about formatting, no distracting screen clutter. I always wondered why I liked ProText on the ST so much. But The Last Word was designed to be exactly that distraction-free word processor. Maybe it's time I started using it!

 

OK: before I get back to the last hour's coding for the evening, here's a sample menu resource (TEST.RSC):

 

menu 1
[
&File
 [
 &New
 -
 &Open...
 Save &As...
 &Save
 &Close
 -
 E&xit
 ]
&Edit
 [
 &Undo/^Z
 -
 Cu&t/^X
 &Copy/^C
 &Paste/^V
 De&lete/Del
 -
 &Find.../^F
 Find &Next
 &Replace...
 &Goto...
 -
 Select &All/^A
 ]
&Format
 [
 Character
 Paragraph
 Font
   [
   8 Point
   10 Point
   12 Point
   ]
 ]
&Tools
 [
 &Options
 ]
&Help
 [
 View &Help
 &About
 ]
]

I coded this up using The Last Word, and it's about 1/3 of the size of the original menu structure definition in the example app's source code. The next demo is delayed yet again as I code up the parser for the resources. You can either "INS" the raw resource text into an app's executable, or (eventually) use a system call to load the resources from a file. Since the sequential order of the menus is perfectly obvious from this tree definition, the application can use a (menu,item) notation to set the checked/greyed-out flags for individual items. Of course, we'll need a resource editor, or at the very least a text editor which handles the GUI's 256 character fonts in order to make multi-lingual translations of the resource files. But no programming knowledge will be required.

 

Hopefully whitespace is insignificant?

This seems like a straightforward way to build menus, but I wonder how these items will be 'wired' onto their callbacks. This looks like mostly just a text layout with some embedded hints as to indicators (&) and ctrl-keys (^). The [] are object nesting. I wonder about the use of the dash as a spacer indication...its unprotected and might give you trouble parsing later if you decide to re-use it or encounter it embedded in names, etc. You might want to consider escaping strings that are lexical data with quotes...I know its kind of a pain but it might save you some trouble later.

 

I guess for the callbacks you would be sending a 'menu_activation' event to the app...with some kind of id that is associated with a particular menu item. I suppose at runtime you could go ahead and just send the menu item object address in the event. Then the app would have to query that object to find out which menu item it was, and potentially climb up to the parent and back down in the case of an identically named item in 2 different submenu's...unlikely I know, but you never know when people start writing apps. It'd be nice if you could assign an 'id' yourself, some kind of number or something that could be passed in the event that the app writer could use to uniquely identify a menu item without having to do text compares or climb around the object tree too much.

Edited February 21, 2011 by danwinslow

[UNIXcoffee928]

Maybe somewhat late but why not add this GUI to LUNIX.

 

LUNIX is already a UNIX clone like program for the 6502 and there was an Atari version compiled but that only did work fine on a emulator.

 

http://lng.sourceforge.net/

 

Would be nice to see it modified to use banked memory :-)

 

The 0.21 (latest) source has all of the Atari specific files, and instructions on how to compile for Atari! This looks very interesting, indeed!

 

 

[LoTonah]

I know I can't really contribute much to the development of this project, but if you ever need to see a particular tool or feature of NextStep, I'm running it on VMWare and I can make videos for you. Just let me know.

 

Yes, that would be great, especially with a good hi-res recording, like you could get, in that scenario. I would say that directory listboxes, and anything with a scrollbar would be a good start. Thanks!

 

 

Hi, sorry about the delay. My six-week old baby girl wasn't feeling good last night so I didn't get far with this.

 

But today, I did. Unfortunately, I don't own a good screen capture utility... it did a great job, but it has a huge watermark on it. Hopefully you can look past that and glean what you need out of it.

 

I tried to show scrollbars, and the control panel. Let me know if there is anything else you need!

 

-Don

 

Youtube Video:

[flashjazzcat]

Hopefully whitespace is insignificant?

This seems like a straightforward way to build menus, but I wonder how these items will be 'wired' onto their callbacks. This looks like mostly just a text layout with some embedded hints as to indicators (&) and ctrl-keys (^). The [] are object nesting. I wonder about the use of the dash as a spacer indication...its unprotected and might give you trouble parsing later if you decide to re-use it or encounter it embedded in names, etc. You might want to consider escaping strings that are lexical data with quotes...I know its kind of a pain but it might save you some trouble later.

 

I guess for the callbacks you would be sending a 'menu_activation' event to the app...with some kind of id that is associated with a particular menu item. I suppose at runtime you could go ahead and just send the menu item object address in the event. Then the app would have to query that object to find out which menu item it was, and potentially climb up to the parent and back down in the case of an identically named item in 2 different submenu's...unlikely I know, but you never know when people start writing apps. It'd be nice if you could assign an 'id' yourself, some kind of number or something that could be passed in the event that the app writer could use to uniquely identify a menu item without having to do text compares or climb around the object tree too much.

Yep: whitespace is complete arbitary. You can style it up just the way you want, but ultimately this will be the output from the resource editor. It's not finalized at all: it's just something I wrote to see what it would look like. The forward slash (signifying right justification) will change, and the dash probably will too. The Macintosh System used "(-" for separator lines. I may use "%" or some such for escape sequences, since it's very C-like (already the "&" and "/" characters can be included literally by doubling them up). I'll also require some way of embedding ASCII codes to denote non-printable or accented characters in a form readable in other text editors.

 

The callbacks are of course a real pain. Previously, I had the luxury of including assembler labels in the data fields, and the callbacks were automatically set up by the menu builder (which just makes appropriate calls to "create_menu" and "create_menu_item"). The app doesn't have to intervene at all in menu selection, which I like, and I think I want to preserve that behaviour. The event handler takes care of menu display, selection, closing the menus, and executing the callback code, all without exiting the event loop (as far as the app's mainloop is concerned). I reckon that - after running the menu builder on the menu resource - the app will then target menu items via the matrix (menu_num, item; no worries about name clashes) and place the callback addresses into the objects. Something like:

 

lda #3
sta menu_num
lda #4
sta menu_item
lda #< callback
ldx #> callback
jsr set_click_event

 

The app can use a vector table and a loop to do that. I can see that - although the menus have an inherent numerical sequence - it's implied, and it would probably make more sense to explicitly specify an ID number at the top of each menu def.

 

The other approach is for the event handler to return a menu index pair to the application when something is chosen, and for the application to then use a switch statement to run the relevant code. This behaviour can be obtained (if it is desired) by simply not setting up callbacks. The event handler will see it has nothing to do, and will just return a menu click event to the application. This way, you get the maximum flexibility (and this approach will work with BASIC).

 

On the subject of object IDs, I was thinking how easy it will be to implement some cool callbacks in the dialogue handler. If we give controls "on_click" and "on_double_click" event code, we can grey out list boxes when checkboxes are cleared, etc. I recall having a great time designing dynamic dialogue boxes using these techniques when I wrote that MS Access app.

Edited February 22, 2011 by flashjazzcat

[flashjazzcat]

Youtube Video:

Great, but I don't think I'll implement the large, green text floating over the desktop. It's a wonder the designers didn't drop that feature before the release.

Edited February 22, 2011 by flashjazzcat

[UNIXcoffee928]

...

 

Unfortunately, I don't own a good screen capture utility... it did a great job, but it has a huge watermark on it. Hopefully you can look past that and glean what you need out of it.

 

 

 

I tried to show scrollbars, and the control panel. Let me know if there is anything else you need!

 

-Don

 

 

I use an older version of "BSR Screen Recorder", and it's very good for this kind of stuff.

[UNIXcoffee928]

Oh, never mind, you're doing it on a Mac... IDK. That watermark is horrible, though... maybe someone else can recommend a good screen capture program, for Macs.

[Eyvind Bernhardsen]

Oh, never mind, you're doing it on a Mac... IDK. That watermark is horrible, though... maybe someone else can recommend a good screen capture program, for Macs.

 

Snow Leopard's QuickTime Player has screencasting built in: http://www.maciverse.com/how-to-create-a-screencast.html

[UNIXcoffee928]

I'm doing feasibility study on lunix. I'm going through the source, and applying a common format to it, to make it easier to read, and fixing comments that were in broken English. I'm going to try to understand it's construction, and do a working build for the Atari.

 

It has been worked on by different people, in different time-periods, so it's more than a little squirrely. ...but, I think that after I get it looking more uniform, I should be able to temporarily strip out all non-Atari code, to understand it better, then build it. As long as it works, I'll change the Makefile, and restructure the directory setup, to reflect the Atari-Oriented release, putting all of the C64, C128, & Apple code into an archive directory, for future reference on how to port those tools. What we'll be left with is the Atari-oriented build environment, the Atari executables, the generic lunix tools, and the Other Ports archive directory.

 

Since no one has done anything with it since 2004, I'm changing it's name from LUnix to lunix, for my revision of LUnix v. 0.21 to lunix v. 0.21a mostly because LUnix looks really ugly, and there are comments from the Original Author referring to it as, "lunix", anyway. Since this is mostly just a clean it up, focus on Atari, and cross my fingers release lol it gets the "a" revision.

 

Other than that, I'm making No Promises Whatsoever that it will work or be useful in any way. I will post the revised stuff when I'm done, though. It seems like it's worth fooling with, specifically because it does actually all work off of init.

 

Bear in mind that lunix is very full-featured on the C64, but is just a minimal kernel build for the Atari, as it is, in it's present state. ...but, that is all of the hard work, anyway... as long as the kernel works correctly, the rest of the stuff is easy, in comparison. It is compatible with both Atari DOS 2.5 & mydos, to quell any fears of an incompatible DOS.

 

This is all experimental. I don't want to be "Responsible" for it. It may turn out to be cool, though... OR it may turn out to be a useless & explosive Red Herring of a UNIX implementation... I have no idea at this point. Seems like it's worth a try, though... so, don't bother messing with the downloadable sources above... I'll eventually post something more Atari-Oriented, and more clear, that you can hack on, if anyone wants to give it a go.

[LoTonah]

Oh, never mind, you're doing it on a Mac... IDK. That watermark is horrible, though... maybe someone else can recommend a good screen capture program, for Macs.

 

Snow Leopard's QuickTime Player has screencasting built in: http://www.maciverse.com/how-to-create-a-screencast.html

 

 

I had no idea! If I do any more (or redo this one), I'll definitely give this a try. Thanks for the tip.

[+David_P]

May I contribute to feature creep?

 

One thing I liked about Diamond was the ability to have small memory resident apps. Of course, since Diamond was built to run on a 48K 800, there was precious little memory available.

 

But with expanded memory being the norm, would it be possible to commit one bank (16K) to memory resident apps (user controllable)? Being able to call up, say, a calculator while in the middle of writing a novel in the GUI version of the Last Word, would be very useful. It's not multi-tasking, just shifting attention to another object. And integrating that functionality from day 1 (the ability to have memory-resident apps) with a well-defined interface would permit future expansion.

[+MrFish]

But with expanded memory being the norm, would it be possible to commit one bank (16K) to memory resident apps (user controllable)?

I'll let fJC answer the specifics, but in general I do know there will be memory set aside for desk accessories, etc.

Edited February 23, 2011 by MrFish

[flashjazzcat]

But with expanded memory being the norm, would it be possible to commit one bank (16K) to memory resident apps (user controllable)?

I'll let fJC answer the specifics, but in general I do know there will be memory set aside for desk accessories, etc.

Yeah: we'll have desk accessories resident. I actually think I overestimated the amount of RAM the basic GUI will consume, so there'll be plenty of space for apps of 1-2KB on a 128K machine. What would have been really nice would be to run all apps out of extended RAM, and then we have the potential for - at the very least - simple task switching. But the complexity arises when you factor in the necessity for most useful apps to store their data in extended RAM, too. This means all memory access has to be indirect and (possibly) buffered. I think the question of where to put everything (especially in relation to running lagacy apps) is the one big question mark which hangs over this project. There are so many different approaches to take, each with their drawbacks and advantages.

 

But task-switching really is feature-creep right now.

 

No-one came up with any 16-bit super-fast integer division/multiplication routines in 6502 assembler; no problem there, since there are many to choose from. But another request: any opinions on self-cleaning malloc/free routines? I already wrote one and it's quite nice: it keeps the free memory in a linked list, and is self-cleaning. The only drawback is that every time you free a block, it has to walk the whole (doubly linked) list until it establishes that there are no other free blocks adjacent to the target block being freed (if there are, it consolidates the freed RAM into a single, larger block). That's no problem if we free up a couple of dozen blocks, but I can envisage a long blocking loop if we - for example - free up 256 file icon objects when closing a directory window. That's potentially 256 complete walks of the linked list, and the linked list could contain twice that number of memory blocks (since the heap is used for menus, desktop icon bitmaps, etc).

 

Of course I've not yet had an opportunity to gauge the real-life impact of this list walking. It may not be too bad when an average-sized list of dynamic resources get destroyed, but we might end up with a nasty one second pause after closing a window. There are a couple of ways to improve malloc and free. Approaches include keeping the allocated as well as the free blocks in a linked list (my routine just keeps the free memory in a linked list, but maintains a header at the top of each allocated block so that the free routine doesn't need to be passed the size of the memory to be freed - just the pointer to its location), and double-indirection of the block pointers; the latter allows the free routine to physically move allocated blocks when chunks are freed up, ensuring there are no gaps in the allocated RAM. In doing this, it must also update the pointers to the allocated blocks; hence the application must access the memory using a pointer to a pointer:

 

ldy #0
lda (block),y
sta pointer
iny
lda (block),y
sta pointer+1
dey
lda (block),y ; finally we access the block
...

This is hardly relevant to the problem at hand, however, since in a GUI, allocated blocks are typically small and of predictable sizes (objects and control structures, short text strings, small bitmaps, etc) and fit nicely into previously freed up blocks. Consolidation is less of an issue, but we must still ensure that contiguous free space is not unnecessarily fragmented.

 

An approach which occured to me was to call a cleanup routine immediately following a bunch of free calls. In this case, free will just mark blocks as empty without walking the tree at all. We'll potentially end up with hundreds of free memory blocks, many adjacent to one another but still regarded as separate free chunks, and thus unable to be allocated as a consolidated block. Cleanup would do the tree walking - just once - and consolidate all the fragmented blocks. However, this places the onus on the application writer to make calls to cleanup at appropriate places in his code. The ideal time is following a bunch of free calls, or immediately prior to a malloc.

Edited February 23, 2011 by flashjazzcat

[danwinslow]

You could instrument the malloc/free code to force a garbage collection every x calls. The problem is that you would get (apparently) unpredictable pauses. If the pause is significant, I feel it's better to leave the decision to call cleanup in the hands of the app writer. After all, this is a small system and the app writers will have to know what they are doing in any case. If you could provide an easy way for the app writer to inquire as to the state of the heap and the degree of fragmentation, that would give them the info they need to make their own design choices.

 

One other approach you could take to cut down on holes between blocks would be to pre-allocate specifically for your most commonly sized objects.

 

In that vein, you could also have a separate 'heap' for your 'object' storage ( assuming these are of static size ). That way you could have an optimized, much faster way of handling specific malloc/free's without having to worry about odd sizes, holes, and merging. The drawback, of course, is that now you have to partition your heap into 2 sections, a 'system' heap and a general purpose heap, and have different code paths for each.

[walter_J64bit]

The OS won't be compatible with Diamond at all. There are hardly any quality apps written for Diamond, so I wouldn't really be availing myself of a ready-made software library. Also, Diamond's API, object tree, resource structure, etc, are highly simplified and quite under-powered for writing apps flexibly

 

That's too bad, I was hoping for more APP's for Diamond. I'll just keep trucking on with Diamond, until the new GUI comes to out.

[flashjazzcat]

You could instrument the malloc/free code to force a garbage collection every x calls. The problem is that you would get (apparently) unpredictable pauses. If the pause is significant, I feel it's better to leave the decision to call cleanup in the hands of the app writer. After all, this is a small system and the app writers will have to know what they are doing in any case. If you could provide an easy way for the app writer to inquire as to the state of the heap and the degree of fragmentation, that would give them the info they need to make their own design choices.

 

One other approach you could take to cut down on holes between blocks would be to pre-allocate specifically for your most commonly sized objects.

 

In that vein, you could also have a separate 'heap' for your 'object' storage ( assuming these are of static size ). That way you could have an optimized, much faster way of handling specific malloc/free's without having to worry about odd sizes, holes, and merging. The drawback, of course, is that now you have to partition your heap into 2 sections, a 'system' heap and a general purpose heap, and have different code paths for each.

I don't think a single garbage collection run through the list will take long at all (as opposed to the accrued overhead incurred by doing it hundreds of times), but the problem with the "every x calls" approach (which is a good idea, and one I considered) is that you might run into a situation whereby the application's request for 3KB fails, but would have been fulfilled after the next one or two calls to free (when the counter singals that it's time to clean up the heap). For that reason, I like the idea of leaving the cleanup call in the hands of the programmer. Only the application's logic can know when it's a good time to run cleanup (say, after releasing a couple of hundred blocks). It's just a question of coding it up (should be fun, but hopefully not too much work).

 

As for dual heap sections: that's already part of the plan. One 16KB bank forms the object heap, and another holds all the dependant data (i.e. text strings for menu items, bitmaps for icons, etc). Not only does this make (de)allocation more efficient, it also segregates "clickable" objects from their data. Rationalising the whole thing, I figure the data bank will fill up fast, while the object bank should be comparatively lean. Unfortunately, while the core object structure is about twenty bytes (I've just added a lastchild pointer for fast Z-positioning), the controls which are based on the object structure tend to vary in size.

 

In any case: periodic calls to cleanup look like the way to go. It's not as if it needs to be coded up this very minute (I have a window taking shape at the moment, which is a milestone development).

 

Fonts notwithstanding (we'll need some kind way of grabbing them from disk as and when, and storing only the most "current" set in RAM), the top half of the object bank can probably be devoted to the background buffer for menus and dialogues (never more than 8KB required by those, and they're mutually exclusive). When no menus or dialogues are open, this space can be used as a large mask so that desktop icons partially obscured by windows can be moved and re-rendered without having to draw the entire desktop from the bottom up. It's as versatile as the little menu buffer which TOS uses.

 

The OS won't be compatible with Diamond at all.

 

That's too bad, I was hoping for more APP's for Diamond. I'll just keep trucking on with Diamond, until the new GUI comes to out.

Hopefully anyone who harboured the desire to write apps for Diamond will write them for this GUI instead. I know it would have been super-handy to make the API compatible, but the two systems take a completely chalk-and-cheese approach.

Edited February 23, 2011 by flashjazzcat