New GUI for the Atari 8-bit

[Gunstar]

Well, your GUI sounds to be the best yet, and you have certainly eased my worries about Legacy software, but I still say the bells and whistles are important on the desktop, since it will be used most of the time as just a desktop file server by most. Normally, no, they are less important than getting the API functionality, of course, but I like ATOS specifically for it's bells and whistles (in the light of few actual GUI apps). That's just the way it is for me, and if your GUI doesn't have the bells and whistles I like, if it looks too plain-jane and I use it for little but a file server, I'll probably run back to ATOS for it's screen-savers, wallpapers and graphic art display abilities.

 

But by all means, keep up the good work, I am looking forward to trying out your GUI...any name for it yet? Gem...Diamond...how about Saphire?

[potatohead]

Funny you should mention an IDE, since I was just musing over how nice it would be to have a version of BASIC specially designed for the GUI, with special keywords, callbacks, etc.

 

Batari type basic, with a few pre-wired display kernels, keywords and such. Would be absolutely golden.

[flashjazzcat]

Well, your GUI sounds to be the best yet, and you have certainly eased my worries about Legacy software, but I still say the bells and whistles are important on the desktop, since it will be used most of the time as just a desktop file server by most. Normally, no, they are less important than getting the API functionality, of course, but I like ATOS specifically for it's bells and whistles (in the light of few actual GUI apps). That's just the way it is for me, and if your GUI doesn't have the bells and whistles I like, if it looks too plain-jane and I use it for little but a file server, I'll probably run back to ATOS for it's screen-savers, wallpapers and graphic art display abilities.

Well, the GUI is anything but "plain-jane", as demonstrated by MrFish's absolutely wonderful design touches, his proportional fonts, his 100+ 16x16 icons (and the windows and menus are faithful replicas of his original design mock-ups). Or how about little gadgets on the right hand end of the menu bar, like a clock you can double-click in order to set the time via a nice little dialogue box? I do think wallpaper's highly desirable, too, although it consumes 8KB of resources.

 

 

But the proof is in the pudding at the end of the day. I'm confident that even the file manager will surpass expectations, but it will take time. As I said before - ATOS and any other A8 desktop manager has the advantage of being finished and working. It's hardly fair to start picking fault with them until ours works too.

 

But by all means, keep up the good work, I am looking forward to trying out your GUI...any name for it yet? Gem...Diamond...how about Saphire?

 

We're quite close to choosing a name for it. We have a list of dozens which we're whittling down.

 

Batari type basic, with a few pre-wired display kernels, keywords and such. Would be absolutely golden.

 

Wouldn't it just. The great thing about it is that since all graphic and event handling grunt-work is delegated to the super-fast routines in the library, an application written using an interpreted language should run almost as fast as machine code in some respects. It would also be a fast-track way of getting some software written for the thing. I reckon we could easily devote a couple of 8KB banks to an interpreter. How about a compiler, too?

 

Anyway - progress update: cartridge build is coming together pretty nicely. I just have to painstakingly replace all the inter-bank JSRs and JMPs with calls to the "long" mechanism. Making sure everything's in the correct bank takes time. Once that's done, however, I can make a proof-of-concept of the window masking, then start work on the dialogue handler.

Edited October 29, 2011 by flashjazzcat

[Gunstar]

Well, your GUI sounds to be the best yet, and you have certainly eased my worries about Legacy software, but I still say the bells and whistles are important on the desktop, since it will be used most of the time as just a desktop file server by most. Normally, no, they are less important than getting the API functionality, of course, but I like ATOS specifically for it's bells and whistles (in the light of few actual GUI apps). That's just the way it is for me, and if your GUI doesn't have the bells and whistles I like, if it looks too plain-jane and I use it for little but a file server, I'll probably run back to ATOS for it's screen-savers, wallpapers and graphic art display abilities.

Well, the GUI is anything but "plain-jane", as demonstrated by MrFish's absolutely wonderful design touches, his proportional fonts, his 100+ 16x16 icons (and the windows and menus are faithful replicas of his original design mock-ups). Or how about little gadgets on the right hand end of the menu bar, like a clock you can double-click in order to set the time via a nice little dialogue box? I do think wallpaper's highly desirable, too, although it consumes 8KB of resources.

 

 

But the proof is in the pudding at the end of the day. I'm confident that even the file manager will surpass expectations, but it will take time. As I said before - ATOS and any other A8 desktop manager has the advantage of being finished and working. It's hardly fair to start picking fault with them until ours works too.

 

 

I have NEVER ONCE "picked fault" with your unfinished GUI, I've only seen a couple of the short movies you've shown clicking on the desktop. All I've EVER said anything about here is what I want in a GUI and what I like about the ATOS GUI/Desktop manager. So relax and show me what you got!

 

 

By the way, and I'm sorry if it's been reported before in this huge thread, how far along is this project? Is this an imminent release, even as an alpha or beta, or are your sleeves stilled rolled up, deep in critical coding with a long way to go?

Edited October 29, 2011 by Gunstar

[flashjazzcat]

I have NEVER ONCE "picked fault" with your unfinished GUI, I've only seen a couple of the short movies you've shown clicking on the desktop. All I've EVER said anything about here is what I want in a GUI and what I like about the ATOS GUI/Desktop manager. So relax and show me what you got!

 

Read the following again:

 

As I said before - ATOS and any other A8 desktop manager has the advantage of being finished and working. It's hardly fair to start picking fault with them until ours works too.

 

In other words, what I'm saying is that it's hardly fair of me to pick too many faults with ATOS when ATOS is finished and working, while my GUI remains a WIP.

 

By the way, and I'm sorry if it's been reported before in this huge thread, how far along is this project? Is this an imminent release, even as an alpha or beta, or are your sleeves stilled rolled up, deep in critical coding with a long way to go?

 

My sleeves fell off at the shoulders some time ago. I'm deep in coding, but not always as deep as I'd like to be owing to pesky old real life. I'm hoping that there'll be a fairly complete cart-based GUI and desktop manager in six months. Fingers crossed...

Edited October 29, 2011 by flashjazzcat

[Gunstar]

I have NEVER ONCE "picked fault" with your unfinished GUI, I've only seen a couple of the short movies you've shown clicking on the desktop. All I've EVER said anything about here is what I want in a GUI and what I like about the ATOS GUI/Desktop manager. So relax and show me what you got!

 

Read the following again:

 

As I said before - ATOS and any other A8 desktop manager has the advantage of being finished and working. It's hardly fair to start picking fault with them until ours works too.

 

In other words, what I'm saying is that it's hardly fair of me to pick too many faults with ATOS when ATOS is finished and working, while my GUI remains a WIP.

 

By the way, and I'm sorry if it's been reported before in this huge thread, how far along is this project? Is this an imminent release, even as an alpha or beta, or are your sleeves stilled rolled up, deep in critical coding with a long way to go?

 

My sleeves fell off at the shoulders some time ago. I'm deep in coding, but not always as deep as I'd like to be owing to pesky old real life. I'm hoping that there'll be a fairly complete cart-based GUI and desktop manager in six months. Fingers crossed...

 

Sorry, definately my fault for not carefully reading the post. I missed the "with them" part. I really am sorry as one of my own pet peeves is people who don't read carefully or just have no sense of reading comprehension. Of course I understand missing stuff if one is trying to skim a huge thread, but it shouldn't happen with an on-going conversation.

Edited October 29, 2011 by Gunstar

[Shawn Jefferson]

^{ATOS is supposed to have an API to write programs to, and the "drawing library" was written in C with cc65 (the Atari version I guess). I tried a couple of times to contact the author to see if he would release the source, since recompiling with the superior cc65.org version would be great, and also further development could be done... no response ever, so I forgot about it.}

[flashjazzcat]

Having a timely look at memory management at the moment, and coding up a testbed DOS application which tests the heap routines. With reference to discussions a few months back regarding garbage collection, I've arrived at a few conclusions:

1. If the list of free blocks is not in linear order, even a "cleanup" routine which is only run when an allocation request fails becomes quite time consuming, since for every node visited, the list has to be walked in its entirety to discover any contiguous free blocks to coalesce with the current node (reason being that a neigbouring freed block might be way down the list in either direction). It becomes quite useful, then, to keep the list in linear order.
   
2. To keep the list in order, there's a slight overhead required: when freeing a block of memory, rather than just pointing the list head at the freed block and the freed block's "next" pointer to the previous "head", we need to walk the free list from the head until we either reach an entry beyond to target block or the end of the list. We then insert or append the freed block to the list at this point, keeping everything in address order.
   
3. The "cleanup" routine then not only becomes simpler, but it becomes redundant too, since checking that neighbouring nodes in the free list point to contiguous free blocks of memory is a trivial process. We might as well, then, perform this simple check (for a free block ahead of and / or behind the block being freed) when performing the "free" operation.
   

The deallocation routine thus becomes "self cleaning", although at the cost of having to walk the free list for every deallocation. The point is that a single walk of an in-order list is far less costly than a complete traversal of an unordered list for every node in the "cleanup" routine. Perhaps I'm not being clever enough to see how a cleanup of an unordered free list can be done without quite lengthy processing.

 

So we have (for example) in the free list (sizes in brackets):

 

Root -> 16386 (2048) -> 24568 (2048) -> 28668 (4096) -> NULL

 

If we want to free memory immediately in front of 28668, say, we walk the list, realize that 24568 is the previous entry, amend its pointers, and point the newly freed block to 28668. If the block at 24568 and / or the one at 28668 is an immediate neighbour, we can check for that too and coalesce the blocks. In any case, we'll go ahead and save pointers to the list elements at 24568 and the block we just freed, since if the next block we free falls between them, we can skip walking the list. I imagine this would be a common scenario when freeing RAM which was allocated in chunks. If we also use sub-allocation within larger allocated blocks, we avoid a whole lot of work.

 

Now, we can of course go a step further and maintain an array of indirection pointers so that we can call a cleanup routine which actually moves allocated blocks to ensure free memory is contiguous. We could keep this array at the front of the banked region ($4000), and let it grow upwards so that we don't have to waste a fixed block of RAM on it (after all, why have 512 array elements if we want to allocate two 7KB blocks of RAM). Memory allocation, meanwhile, can extend down from the top of the 16KB block. If the array crashes into the lowest allocated block, or an alloc fails because of a lack of free blocks, we call cleanup.

 

I wonder if we really need to have indirection like this, however. It's hard to predict just when memory will become too fragmented to be of use on a system of this size. Making all handles point to pointers is an extra complication.

 

One final point which I'll throw out there for now: since we're accessing the extended RAM indirectly (this is always the case, since application code lives in the same space), we have an opportunity to present the application with up to 64KB of memory by doing all the bankswitching transparently during memory requests (which, by the way, will simply copy up to a couple of KB to and from an intermediary buffer in unbanked memory). The drawback with this is that moving data around in the cleanup routine (assuming we use indirect handles) becomes a processing nightmare (as I think inter-bank moves and copies tend to be). Of course, we might eschew the cleanup routine altogether, or oblige the application to manage its data in 16KB chunks.

Edited November 15, 2011 by flashjazzcat

[Master Phruby]

I just finished reading this thread. What an amazing journey you have gone through. I'm really impressed with what you have accomplished here. I remember Diamond from my 8bit days and thought that was amazing at the time. You blew that away many years ago. Thank you for designing this.

[flashjazzcat]

I just finished reading this thread. What an amazing journey you have gone through. I'm really impressed with what you have accomplished here. I remember Diamond from my 8bit days and thought that was amazing at the time. You blew that away many years ago. Thank you for designing this.

Many thanks for your comments, but I couldn't do it without MrFish's efforts and the support, expertise and encouragement I receive from the community (yourself included). Hence my "thinking aloud" posts such as the above! As for Diamond: I guess we have a long way to go before the new system has half Diamond's practical functionality, but we are surely aiming very high in the long-term.

[almightytodd]

I really enjoy following this thread. Keep up the good work and thanks for bringing us all along for the ride...

[flashjazzcat]

Thanks! Since there have been no voices of dissent so far, I'm pressing on with this heap management stuff and I'll post some code or an algorithmic description soon. I'm considering making malloc smart enough to look for the smallest free block which will satisfy the memory request, rather than the first block which is large enough. I figure this way we don't needlessly compromise large, contiguous free blocks for the sake of small requests (the larger blocks might be useful when a larger request is received). Oh - and I remembered that the garbage collection method I was talking about is called "moving" or "compacting" garbage collection. Even without this extra level of garbage collection, the system should be pretty efficient, but I need to carefully organize allocations so that corresponding deallocation makes best use of the cached pointers. I also believe that pointer caching can be used during the allocation phase, potentially avoiding a list walk in order to find a suitable block.

[Gunstar]

ATOS is supposed to have an API to write programs to, and the "drawing library" was written in C with cc65 (the Atari version I guess). I tried a couple of times to contact the author to see if he would release the source, since recompiling with the superior cc65.org version would be great, and also further development could be done... no response ever, so I forgot about it.

 

I found all my ATOS documentation if you are still interested. It's all hardcopy so I'd have to scan it and send you scans. I can't help with the source code, but the documentation I have includes all the details for users and programmers to use and program for it in it's current form. For example I have the 'Programming ATOS-The Core Routines' docs and also 'Programming ATOS-The CC65 Library.'

Also the manual (quite extensive), faq&details (which include the developers philosophy on why he did things the way he did), etc.

 

I have everything BUT the source code (that I know of, I'll look into it). I try to download and back-up all kinds of stuff like this, and print hardcopies for just this reason; developer no longer supports product and has fallen off the face of the earth. When dealing with ancient computers and software one has to expect this and take action. No matter what anyone says about archives, paper is still the best way to ensure long-term survival. All electronic media is far more likely to get lost due to degradation or power loss. Paper can last for hundreds of years if properly stored and conditioned-just avoid fire and water. In just ten years this ATOS documentation and source situation has proven my point.

Edited November 17, 2011 by Gunstar

[flashjazzcat]

API docs sound interesting as a possible source of inspiration. The manual, FAQ and the story behind the project should naturally make fascinating reading.

 

Regarding source code: unless there's a ready written self-cleaning heap manager which runs in extended RAM or code which renders 24x24 proportional fonts at break-neck speed, I guess we can survive without it.

[Gunstar]

API docs sound interesting as a possible source of inspiration. The manual, FAQ and the story behind the project should naturally make fascinating reading.

 

Regarding source code: unless there's a ready written self-cleaning heap manager which runs in extended RAM or code which renders 24x24 proportional fonts at break-neck speed, I guess we can survive without it.

 

Although I was merely skimming through the docs again, it's funny that you should mention a self-cleaning heap manager as I think I saw that mentioned...I'll have to verify.

I'll be happy to get all the docs up here then, but it's about 30-40 pages of docs, so I may not do it all at once. I'll start a seperate topic for this though, I don't want to hi-jack this thread; keep on keep'n on with your new GUI, and maybe this stuff will help in some way.

Edited November 17, 2011 by Gunstar

[UNIXcoffee928]

Thanks! Since there have been no voices of dissent so far, I'm pressing on with this heap management stuff and I'll post some code or an algorithmic description soon. I'm considering making malloc smart enough to look for the smallest free block which will satisfy the memory request, rather than the first block which is large enough. I figure this way we don't needlessly compromise large, contiguous free blocks for the sake of small requests (the larger blocks might be useful when a larger request is received). Oh - and I remembered that the garbage collection method I was talking about is called "moving" or "compacting" garbage collection. Even without this extra level of garbage collection, the system should be pretty efficient, but I need to carefully organize allocations so that corresponding deallocation makes best use of the cached pointers. I also believe that pointer caching can be used during the allocation phase, potentially avoiding a list walk in order to find a suitable block.

 

Good, this scheme should keep memory fragmentation to a minimum. It would be worth the extra effort to make this section of the program generic enough that it could also be re-used in the Last Word, & future apps.

 

I recommend that you look into Garbage Collection techniques that were used on the "LISP Machines", and in the Apple Newton's OS (which was created by LISP Machine guys). Garbage Collection had always been a very big issue with LISP, and extreme efforts were invested in the LISP Machines & the Newton to do it as efficiently as was possible, so you should get some additional good ideas from their labors, if you search around for info.

 

Glad everything is coming along, looking forward to the code samples!

[tinctu]

I want to have RMT, SAP music player like "WinAMP" on AchroDesk- AchroPlayer .

Edited November 20, 2011 by tinctu

[flashjazzcat]

Good, this scheme should keep memory fragmentation to a minimum. It would be worth the extra effort to make this section of the program generic enough that it could also be re-used in the Last Word, & future apps.

It's generic alright - the development version of the heap manager is a relocatable SDX binary which operates from the command line with test data. I was in two minds about making the garbage collection compacting - so you think it's worth the extra level of indirection and the slight complication in pointer management (from the application point of view)?

 

I recommend that you look into Garbage Collection techniques that were used on the "LISP Machines", and in the Apple Newton's OS (which was created by LISP Machine guys). Garbage Collection had always been a very big issue with LISP, and extreme efforts were invested in the LISP Machines & the Newton to do it as efficiently as was possible, so you should get some additional good ideas from their labors, if you search around for info.

Will do - thanks!

 

Glad everything is coming along, looking forward to the code samples!

Before all this is finalized, I'm just deciding on how the heap manager should span banks, if at all. I figure we have a global heap (for stuff like fonts, drivers, accessories, etc), and application heaps (for a program's menus, dialogues, and "privately" reserved memory). Both heaps exist in 16KB chunks, but you can have many such chunks. The free linked lists can either thread through all the banks, or requests can successively call MALLOC on one bank after another until the request is satisfied. I rather think chaining the list through the banks would be faster.

[UNIXcoffee928]

There is an unusually in-depth Wikipedia page on the many ways that Garbage Collection may be performed, and the benefits and disadvantages of each method. There are also very good external links at the bottom of the page.

 

The trick is to find the method that works best with the resources available on our Atari hardware. I would suggest focusing on techniques that work well in Real Time Systems, since timing constraints apply to the GUI on the Atari, and Real Time programming techniques translate very well to what we are working with. With that said, after looking into the real-time methods, look into the standard methods, and hybridize the concepts, to make the most of our unique hardware.

 

Without getting too in-depth right at this moment, what I think should be done is to offload as much work as is possible from the CPU, and take great care in devising the Banking scheme. POKEY Timers, DLIs, and the 130XE's ability to let ANTIC bank separately from the CPU.

 

This will involve a little abstract thinking... how to make POKEY, ANTIC, & GTIA do our bidding, in ways that they are not commonly used. All of the support chips have functions which can be tapped, as well as the system's IRQs.

 

A very good idea, also, is to find events that have cycles to burn, performance-wise... like your pull-down menus... they are superfast, which is awesome. This implies that there is some free processing time there... so it might be an ideal candidate to look into, meaning, if a menu operation is taking place, alternate the code so that memory management occurs during menu operations. This is just an example, but, overall, look for spots in the app that have low CPU overhead, and try to figure in memory management in those spots.

 

I think that hybrid methods, and separate, discrete methods are the way to go; meaning try to use 2 or more memory management methods, not just settling on one, as everyone else does.

 

As I said, it's not the time for me to get in-depth, yet... but I will, soon.

 

Other than that, get some graph paper, and start visualizing. We tend to think of a flat address space as one long avenue of memory locations. If we look at the problem differently, and apply some of what we learned in Statistics, we can get very different visualizations of the same set of addresses, which can include 4 quadrant graphs from geometry, and circular and elliptical graphs, even topological graphs (star, etc., as seen in network design).

 

It may very well be that you will find simple algorithms, by using mathematical functions. The trick to this is start visualizing address space on graph paper. Aside from Statistics, Game Theory will also give you an advantage.

 

I would like to have this aspect of the program be a shining example of the most effective use of XE RAM Banking. Let me know what constraints we are working under, with regard to the demands & requirements of the other aspects of the application, this way we can determine what resources are free to be utilized.

 

This should be fun!

Edited November 21, 2011 by UNIXcoffee928

[flashjazzcat]

There is an unusually in-depth Wikipedia page on the many ways that Garbage Collection may be performed, and the benefits and disadvantages of each method. There are also very good external links at the bottom of the page.

Yes - Wikipedia started showing up in my Google search results some years ago, and I've done a fair bit of reading on this subject already.

 

The trick is to find the method that works best with the resources available on our Atari hardware. I would suggest focusing on techniques that work well in Real Time Systems, since timing constraints apply to the GUI on the Atari, and Real Time programming techniques translate very well to what we are working with. With that said, after looking into the real-time methods, look into the standard methods, and hybridize the concepts, to make the most of our unique hardware.

That all seems very sensible. I'm trying to come up with a method which works best with our hardware and resources, rather than something which works best with some other hardware and resources. What I'm building is tailored to be as efficient as possible when allocating and freeing blocks, not wasteful of RAM (hence the indirection pointers growing up towards the bottom block), and completely unfragmented (moving garbage collection).

 

Without getting too in-depth right at this moment, what I think should be done is to offload as much work as is possible from the CPU, and take great care in devising the Banking scheme. POKEY Timers, DLIs, and the 130XE's ability to let ANTIC bank separately from the CPU.

Forget ANTIC banking mode - not gonna happen. Too many DOSes and memory upgrades interfere with or completely do away with that banking mode. That's why the frame buffer is in main memory. Pokey timers are already used for the mouse sampling, and they'll probably be used for other stuff too. The DLIs are tied up with the rather wonderful mouse pointer renderer. As for the banking scheme - I'm taking pains over it, since if it's not right, the system will be slow and inflexible.

 

This will involve a little abstract thinking... how to make POKEY, ANTIC, & GTIA do our bidding, in ways that they are not commonly used. All of the support chips have functions which can be tapped, as well as the system's IRQs.

We have to take some care, since the GUI sits on top of DOSes which already have interrupts and hardware tied up with their own services. If DOS was built into the GUI, we could potentially do away with the entire operating system. However, I want to get this finished inside of a decade.

 

A very good idea, also, is to find events that have cycles to burn, performance-wise... like your pull-down menus... they are superfast, which is awesome. This implies that there is some free processing time there... so it might be an ideal candidate to look into, meaning, if a menu operation is taking place, alternate the code so that memory management occurs during menu operations. This is just an example, but, overall, look for spots in the app that have low CPU overhead, and try to figure in memory management in those spots.

Yes - that makes sense, although the menus rendering might not be the best time to perform background processing. I don't think the fact they render pretty quickly necessarily implies there are free cyles left over: naturally, when the menus are drawing, the CPU (which works flat out 100 per cent of the time on the Atari) is fully occupied with writing to the screen, sampling the mouse, and servicing other interrupts. Any interruption to this will pretty quickly make the menus draw slowly, which impacts on the immediacy of our GUI. I'd be more inclined to run a background task when nothing is rendering, and that will probably be more than fifty percent of the time. There's a compromise between real-time processing and idle-time processing. If a memory allocation fails, it's time for a garbage run. I don't much mind the system slowing down for a second or two when that happens, since hopefully memory allocations won't fail too often, since the free blocks are always coalesced in the first place.

 

I think that hybrid methods, and separate, discrete methods are the way to go; meaning try to use 2 or more memory management methods, not just settling on one, as everyone else does.

This makes sense. I'm considering a similar kind of duality in other areas of the system.

 

As I said, it's not the time for me to get in-depth, yet... but I will, soon.

The only note of caution I will voice is that I'm spending more time researching this than actually coding it at the moment. The original code I'm coming up with doesn't (thankfully) have to reference existing approaches in ways it doesn't want or need to (for example, I have read about some heap management structures which are just way over the top for what we need here), and we're lucky enough to be writing non-portable code here which can very tightly suit the 6502's capabilities. I love simplicity, and not only because it's simple: it's compact and fast too. I want to get the heap manager out of the way this week and be well on the way to completing the resource storage formats too.

 

Other than that, get some graph paper, and start visualizing. We tend to think of a flat address space as one long avenue of memory locations. If we look at the problem differently, and apply some of what we learned in Statistics, we can get very different visualizations of the same set of addresses, which can include 4 quadrant graphs from geometry, and circular and elliptical graphs, even topological graphs (star, etc., as seen in network design).

Yep - this is gonna be a week or two of paper based notes and diagrams (yet more of them). While profiling will be important to the memory manager (I can use the testbed to obtain a ratio for list traversals and garbage collects per allocation), I'm gonna leave the 4 quadrant graphs till later on.

 

It may very well be that you will find simple algorithms, by using mathematical functions. The trick to this is start visualizing address space on graph paper. Aside from Statistics, Game Theory will also give you an advantage.

Yes - simple algorithms. You're talking my language. Fewest number of list traversals (cached pointers), coalesce on the fly, etc, etc.

 

I would like to have this aspect of the program be a shining example of the most effective use of XE RAM Banking.

Me too!

 

Let me know what constraints we are working under, with regard to the demands & requirements of the other aspects of the application, this way we can determine what resources are free to be utilized.

Not much RAM and the fact it's split into 16KB banks are the two most constraining factors. As soon as I have objects and resources living in extended banks, we can start to see the wood for the trees. As it is said, so shall it be...

 

This should be fun!

It is - let's hope it stays that way!

Edited November 21, 2011 by flashjazzcat

[flashjazzcat]

OK - thinking aloud here because I've been reading about small memory management systems... so much source material out there.

 

A compacting memory manager works very nicely in a single 16KB bank of extended RAM because we can do a single sweep through the bank and move all the indirectly referenced allocated blocks up to the top of the bank, updating their handles as we go. It's especially simple since I'm forcing all the free block pointers to be in linear order (this makes dynamic coalescing of neighbouring free blocks much easier too). Now, since we have to access memory indirectly anyway (since the heap and the application code share the same physical address space), it's a small step to decode full 16 bit addresses to bank and offset in real time, opening up the possibility not only of 64KB block allocation, but of a virtual memory driver. Sure we have Ultimate 1MB, etc, but we also have lots of hard disks floating around, and this approach is nicely scalable. About the only drawback to mapping memory accesses across four banks is that compacting becomes difficult (the dreaded inter-bank block copy). So I'm wondering whether to do away with the compacting garbage collection, or keep the heap in individual 16KB blocks (possibly interlinked via the list, but the point being that 16KB would be the largest single allocation possible).

[UNIXcoffee928]

I know that the majority of the RAM upgrades out there do not follow the 130XE standard, as defined by Atari as the "correct/legal" way to bank. The default architecture of the 130XE has the specific advantage of either the CPU or the ANTIC accessing extended RAM, and I'm sure that you could really do some fancy stuff with it... perhaps it's hasty to rule it out completely?

 

Personally, I don't think that it's unrealistic to state that the System Requirements call for a 130XE... for an app this good people will surely add a 130XE to their collection, if they don't already have one.

 

Without digging into the documentation, and I'm sure that MetalGuy & Claus could answer this in their sleep, I'll wonder, out loud, if the old 800 Axalon method could be tacked onto the 130XE... The Axalon upgrade could potentially add 16MB of banking in addition to the standard 130XE banking. That would be pretty ideal! I've never heard of it done before, so there is probably a reason why it couldn't be done... but, then again, maybe no one has tried.

 

As far as virtual memory goes... if you keep everything VM to the standard Atari convention of 256 byte pages, then buffer it for a block transfer to an SD card, based on the requirements of the card's allocation unit size, it should work out well for a virtual memory subsystem... particularly, if you go out of your way to make sure that there is not a lot of other extra data-fitting/manipulation going on. You'll eventually have to specify a specific SD card setup for the system requirements, or provide config options to use different types of interfaces.

 

I'm guessing that SpartaDOS is going to be the underlying DOS. Maybe some work has already been done in the area of virtual memory?

[flashjazzcat]

I think some of this has been touched upon already, but since I've forgotten half of what's in this thread myself...

 

I know that the majority of the RAM upgrades out there do not follow the 130XE standard, as defined by Atari as the "correct/legal" way to bank. The default architecture of the 130XE has the specific advantage of either the CPU or the ANTIC accessing extended RAM, and I'm sure that you could really do some fancy stuff with it... perhaps it's hasty to rule it out completely?

The primary advantage of Antic extended mode (the way I see it) - if we were able to rely on its presence - which we cannot - was that the frame buffer could be kept in extended memory. However, I won't use it since a) only a stock 130XE and certain third-party upgrades support it, and b) most DOSes which use RAMdisks or any kind of bank switching will totally f**k up the screen display when they perform bank switching (since they'll probably ignore the bits which differentiate between Antic and CPU access to extended banks). Having solved the issue of where to put the frame buffer (and it's actually preferable to keep it in conventional memory), I'm happy to leave Antic mode alone.

 

Personally, I don't think that it's unrealistic to state that the System Requirements call for a 130XE... for an app this good people will surely add a 130XE to their collection, if they don't already have one.

Yep - I made it known that a 130XE was the minimum requirement quite early on. Looking at another way, I also feel that the GUI must be reasonably usable on a 128KB machine.

 

Without digging into the documentation, and I'm sure that MetalGuy & Claus could answer this in their sleep, I'll wonder, out loud, if the old 800 Axalon method could be tacked onto the 130XE... The Axalon upgrade could potentially add 16MB of banking in addition to the standard 130XE banking. That would be pretty ideal! I've never heard of it done before, so there is probably a reason why it couldn't be done... but, then again, maybe no one has tried.

It's certainly doable, and I asked Candle if he'd add a secondary banking register to the Ultimate 1MB for precisely the purpose of preventing DOS and legacy apps from interfering with the GUI's extended RAM. Unfortunately I asked late in the project and Sebastian wasn't keen on the idea anyway - so we're stuck with sharing PORTB with DOS. In any case, we can't rely on the presence of Ultimate 1MB. I have a RAM cart too, but the cart banking scheme (all in the $8000-$BFFF area) isn't ideal (that's not a criticism of Steve's cart - it's just a limitation of carts in general).

 

As far as virtual memory goes... if you keep everything VM to the standard Atari convention of 256 byte pages, then buffer it for a block transfer to an SD card, based on the requirements of the card's allocation unit size, it should work out well for a virtual memory subsystem... particularly, if you go out of your way to make sure that there is not a lot of other extra data-fitting/manipulation going on. You'll eventually have to specify a specific SD card setup for the system requirements, or provide config options to use different types of interfaces.

I'm not doing any direct interfacing with SD cards or hard disks of any kind. Everything's being done through the CIO, because I want this to work with any hard disk or other storage mechanism and as many DOS packages as we can reasonably cater for. If we have a paging file, it'll be maintained via whichever FMS is in use. SDX will do this very, very efficiently - DOS 2.5 far less so. It'll be up to the user to splash out on the best hardware / software configuration for their needs.

 

I'm guessing that SpartaDOS is going to be the underlying DOS. Maybe some work has already been done in the area of virtual memory?

For much of the sane world, SDX will be the DOS of choice - or perhaps earlier versions of SpartaDOS (assuming I keep the Shadow RAM vacant). However, neither are obligatory, although a hierarchical filing system is HIGHLY recommended (think: recycle bin for a start). As far as SDX is concerned, KMK has already written a DLL which permits the use of virtual memory via the hard disk, but the implementation is specific to SDX. If we use a generic approach, we end up with improving efficiency depending on the efficiency of the filing system and mass-storage interface in use.

 

And still I'm no further forward with my original quandry!

[flashjazzcat]

Hmmm... to heck with it, I'll do it my way then. Actually getting some code written tonight, and the self-cleaning heap is working pretty good (one bug to iron out). I'm considering following the Classic Mac OS example and allowing for relocatable blocks and static blocks... then the programmer can decide whether they want to complexity of indirect handles via the master heap table, or straightforward pointers. Without the relocating garbage collection which comes with the relocatable blocks, there's absolutely no additional garbage collection required if fixed-address blocks are used - all the free space is silently coalesced during release operations, and with minimal overhead.

[fibrewire]

I wrote 3 lengthy messages to you regarding your endeavors with the GUI, and deleted them all. I didn't want to add to the clutter of this thread - and you STILL managed to hear my brain grinding away from across the pond!

 

I can't ever ask for a source code listing, but a flow chart of the logic behind the GUI would be awesome to see

 

EDIT: Source to flowchart - http://www.assemblyflowchart.com/