potatohead Posted May 20, 2011 Share Posted May 20, 2011 (edited) Well, that machine can do color at a greater pixel resolution than Ataris can. That said, I don't see the level of interaction you are aiming for. Frankly, it reminds me of a simple DOS tool kit more than a real GUI environment. The most interesting part of this project to me is the "behind the scenes" work being done to actually facilitate GUI applications that can work together, instead of just presenting a structured input layer, as seen in that project. They really should have attached a mouse for the demo too. Color would be nice, but is totally not necessary to get the benefit of a GUI. Another data point here: There is a project to bring a GUI to the Propeller. It's a 32K device, unless somebody adds external memory. Turns out, that is required for a lot of reasons. One of those is the expectation of color, and the sheer size of the video buffer, which takes a big chunk of the 32K, meaning the app has to sit in the external RAM. I'm very intrigued by this project because it's efficient, and the results so far, on a 320 pixel screen exceeded my initial expectations. Well done so far! I am eager to show this off to a few people, just to reset some expectations on what GUI possibilities are in limited environments. You've really done a nice job so far balancing things. Lots of perspective here. It seems to me, after following this for a while, the hard work is in the planning and back end structure. All to easy to go right for the graphics and the expectations that come with that. Realistically, that should be a secondary consideration, after what I've seen. Edited May 20, 2011 by potatohead Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted May 20, 2011 Author Share Posted May 20, 2011 (edited) The machine - eBay Auction -- Item Number: 110684870771 Thanks... doesn't seem like a necessary purchase yet, though. Would you make a monthly compiled .atr demo of your GUI? Let me explain the situation, since a few people are probably wondering what happened to the demo, mooted just before I spent a month finishing the MyIDE suite. Coming back to the project after a month off has its advantages and disadvantages. The disadvantages: The "rhythm" of the project has been interrupted I was living and breathing the code before, and now I'm having to refamiliarize myself with the thousands of lines of code I churned out over a couple of months The demo has been delayed, and the code somehow doesn't seem quite ready for demo release Adavantages: I can now look at things with fresh eyes, and many aspects seem ripe for redesign now, before they cause problems later on I've had time to think and do more research, rather than just blustering into the next phase The demo has been delayed, and the code somehow doesn't seem quite ready for demo release We've already seen how high expectations are, and how scrupulously the demo will be appraised. I want it to be as good as possible. At the very least, there are a couple of bugs to iron out, and it should be possible to bring windows to the front in the demo. At least we're not far from that point. The most interesting part of this project to me is the "behind the scenes" work being done to actually facilitate GUI applications that can work together... Absolutely. Hopefully this is what will distinguish this project from those that have gone before. They really should have attached a mouse for the demo too. Certainly: it's the second thing that struck me after the mono-spaced text. Color would be nice, but is totally not necessary to get the benefit of a GUI. I completely agree, although if it was available at 320px, I would have used it. It's not, but I see that as no great obstacle. I'm very intrigued by this project because it's efficient, and the results so far, on a 320 pixel screen exceeded my initial expectations. Well done so far! I am eager to show this off to a few people, just to reset some expectations on what GUI possibilities are in limited environments. You've really done a nice job so far balancing things. Thanks. It seems to me, after following this for a while, the hard work is in the planning and back end structure. All to easy to go right for the graphics and the expectations that come with that. Realistically, that should be a secondary consideration, after what I've seen. This is absolutely correct, and a point which many commentators have missed. Roughly speaking, about ten percent of the existing code deals with drawing things to the screen (partly, of course, because of the fact that objects use redraw "methods", which in turn use common code). I myself was surprised - a few weeks into the project - just how detached one becomes from graphical operations when immersed in large amounts of code whose only interaction with the screen is to send a redraw message to a sub-tree. Edited May 20, 2011 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted May 20, 2011 Author Share Posted May 20, 2011 (edited) A bit of fun before the hard work starts again (I just fixed up those couple of bugs I mentioned, although discerning viewers will note I'm actually still dragging the window behind the front one. This is just an incomplete implementation of focus-shifting). http://www.youtube.com/watch?v=8nA4WaJTc7Y It was MrFish who pointed out that you can actually open more windows with File->New. It's an unintentional side-effect of the way the sample app is coded up (it calls File->New twice to open the windows; naturally logic dictates that if the menus work, File->New will then open up windows, but I had not tried it). There are actually four windows in the video, but one completely and exactly obscures another. MrFish claimed it was difficult to discern the window border components drawing with the emulator slowed down. That's what we like to hear. Of course, this brute-force update isn't the way the end-product will work, but it's nice to see how the system chews up those empty windows. It's really nice coming back to this after a month. I'd forgotten how fast the pointer and menus are. But enough fun... back to the hard work. Edited May 20, 2011 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
fibrewire Posted May 20, 2011 Share Posted May 20, 2011 eBay Auction -- Item Number: 390080732953 Is this a waste of money, or would this speed up the GUI significantly? A review can be seen here Quote Link to comment Share on other sites More sharing options...
potatohead Posted May 21, 2011 Share Posted May 21, 2011 The floating point math routines shipped in the stock Atari are slow. That chip provides faster ones. Unless there is something I missed on the progress of this, floating point math is not used for the GUI project. Quote Link to comment Share on other sites More sharing options...
+David_P Posted May 21, 2011 Share Posted May 21, 2011 One of the archives has the source code and binaries for enhanced speed floating point; I seem to recall years ago "rolling my own" 800xl OS into an EPROM, adding the updated floating point, the Hyper E: screen handler, and removing the international character set (since I'm a North American philistine) to add a hot-key screen dump utility for graphics zero. Quote Link to comment Share on other sites More sharing options...
fibrewire Posted May 21, 2011 Share Posted May 21, 2011 One of the archives has the source code and binaries for enhanced speed floating point Finding that archive would prove useful for a few other projects (like emulators), as would finding roms for other devices like bit 3. Wasn't there a rom dump project that made all the 3rd party hardware device roms available? Quote Link to comment Share on other sites More sharing options...
+Stephen Posted May 21, 2011 Share Posted May 21, 2011 One of the archives has the source code and binaries for enhanced speed floating point Finding that archive would prove useful for a few other projects (like emulators), as would finding roms for other devices like bit 3. Wasn't there a rom dump project that made all the 3rd party hardware device roms available? Here's a fastmath ROM Fastmath.zip Quote Link to comment Share on other sites More sharing options...
fibrewire Posted May 21, 2011 Share Posted May 21, 2011 Stephen: Thank you for the ROM! ------------------ FJC: looks awesome! Maybe I can convince you to release a monthly video? I just want to be a part of the QA team Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted May 21, 2011 Author Share Posted May 21, 2011 (edited) The GUI doesn't use the FP ROM routines at all. I perform all calculations using signed 16 bit integers, obtaining and then dispensing with fractional precision using shifting techniques described further back in the thread. It's about as fast as it's gonna get. More than monthly videos (which we've had already), I aim to produce monthly demos. Edited May 21, 2011 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
Chilly Willy Posted May 21, 2011 Share Posted May 21, 2011 More than monthly videos (which we've had already), I aim to produce monthly demos. Great! I'm looking forward to it... I really like the B&W Mac look the GUI has. It would be nice to see this GUI with things like editors (word and program). Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted May 24, 2011 Author Share Posted May 24, 2011 (edited) I spent some time in the small hours last night downloading a copy of SymbOS and actually installing it on a CPC emulator. I have to say I was pretty knocked out by it. It makes pretty much everything else look primitive, although it suffers from a terrible lack of applications. Anyway, I wanted to get a feel for it, and it's really nice. I used the WinAPE emulator. Perhaps the thing that struck me most about SymbOS (quite apart from the brilliant pre-emptive multi-tasking) is the beautifully implemented stacking window manager. It evidently maintains a dirty rectangle list, and does a very nice job of updating newly revealed areas of underlying windows and desktop regions when the top window is moved or resized. Relying on redraws, the system requires no background buffer, thus saving a ton of RAM. Now, with regard to the A8 GUI, all the clipping gets done on byte boundaries, which is a bugger when it comes to defining clip regions outside of the borders. The border/drop-shadow is 1px on the top/left side and 2px on the bottom/right edge. A slightly ugly side-effect of adopting a dirty rectangle system here is that the borders of windows would be momentarily overwritten by the underlying graphics until the windows in the foreground redrew themselves (or at least their border). One way around this is to use a huge bitmask, then we can mask out anything we like with absolute pixel precision. If the top window is moved, we can easily and quickly produce a mask revealing just the area of the screen which has been revealed, then draw everything else through it. Of course, no optimisation is possible unless we tell the other windows the approximate dimensions of the hole in the bitmask. But it would do away with the need for rectangle lists altogether. Anyway: I pondered for a while over bi-directional list walking, and came to the conclusion that the best way to ensure the mouse is detected over the last drawn object is to just keep walking the list until the last element. That way, we don't have to have a "last child" pointer and don't have to walk right through the list then start walking back again in the opposite direction. In this GUI, objects in the foreground are near the end of the list (this is rarely of relevance outside the realm of overlapping windows and desktop icons). Anyway - not to sound depressing, but SymbOS took ten years... Edited May 24, 2011 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
popmilo Posted May 24, 2011 Share Posted May 24, 2011 Have you seen it running on MSX ??? Its even better They even wrote separate graphics driver for gfx9000 MSX addon (http://www.faq.msxnet.org/gfx9000.html). Its even playing videos and music and some... Multi tasking like that is really impressive for an 8-bit cpu... But don't worry yourself about 10 year period. You can do it much faster! Just focus on getting one thing working at a time. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted May 25, 2011 Author Share Posted May 25, 2011 Yes, multi-tasking is so tempting, and I'm trying to design the system so that it will at least be possible to have a crack at this later in the development cycle without doing a complete re-write. Anyway, I've been doing my homework again, and am busy implementing a proper interrupt-driven message pipe, as always with frequent reference to both the GEM AES documentation, and Inside Macintosh. It's really coming together nicely now. Quote Link to comment Share on other sites More sharing options...
bpj1138 Posted May 25, 2011 Share Posted May 25, 2011 First off, I didn't see FJC's demo, so I didn't know he was that far along with this. It looks great, btw, very clean design. I hope I'm not stepping on any toes here, for whatever reason. I thought I'd mention FLTK, since it's a good design. FL stands for Fast, Light, if that sways anybody. It is in C++, but we all know that's just C structures with function pointers. I bet FJC could even implement that with MADS or by hand if he had to. C++ was after all designed to tackle this exact problem. It's important for example, to be able to call superclass methods once you've done your own event handling or drawing. This actually makes things *smaller*. An a bare FLTK app compiles to maybe 20K on windows. The other litmus test for a GUI system is how it handles resizing behavior. I rememer trying to do this in Motif at one point, and it turned out to be quite confusing. I think you had to link widgets to other widgets that were adjacent, and do all sorts of magic to do that. Motif suffered from the same problems as X11, it was designed by committee of people trying to impress their bosses with a whole lot of grunt work. This is why so many people were tempted to code their own system. There had to be a better simpler way... FLTK handles resizing pretty implicitly. You only have to specify the resizable area of a window. The widgets in that area will be resized proportionally to the initial dimensions of each widget compared to the window size.. (what was that about FP routines?) The widgets outside the resizable area are moved. So for example, you don't want the scrollbars to resize, just leave 'em outside the resizable area. WHOOP.. Other than that, if you go by name recognition, the guy that designed it was behind NeXT.. Wasn't that the only 68040 box ever created? Oh well, who cares I guess, and I'm sure it wasn't. If you're still not convinced, take a look at some sample code from a few toolkits out there. FLTK code is by far the smallest, and cleanest. I looked at wxWidgets, Qt, and GTK. No contest. Oh, one more thing. With all the bloatware out there and all the BS in CS, it's no wonder people go back to an 8 bit machine from the 80's. Quote Link to comment Share on other sites More sharing options...
fibrewire Posted May 25, 2011 Share Posted May 25, 2011 Pardon me if I am missing the point - FLTK is a great tool in "the real world" but perhaps you aren't familiar with how much ram the Atari 800 has? I tell ya what, FLTK would be solid gold for a new Atari ST GUI. Quote Link to comment Share on other sites More sharing options...
sloopy Posted May 25, 2011 Share Posted May 25, 2011 Monospaced 80 column, but using a lot of colour. Not a direct, like-for-like "competitor", of course... The machine - eBay Auction -- Item Number: 110684870771 --------------------------------------------------------------- Would you make a monthly compiled .atr demo of your GUI? /me beats head against wall... that is a B128, NOT a C128... http://ace128.mirkosoft.sk/requirements.html sloopy. Quote Link to comment Share on other sites More sharing options...
fibrewire Posted May 25, 2011 Share Posted May 25, 2011 I had no idea the C128 was an 80-column machine. What was the purpose of the B128 besides that sweet 'π' key? I like the B128 because it reminds me of a fond childhood memory Quote Link to comment Share on other sites More sharing options...
sloopy Posted May 26, 2011 Share Posted May 26, 2011 its one of their 'business' computers 'Commodore Business Machines', see it has 00 key for currency entry? and the 'π' key is for when your hungry... it produces a pastry food with commonly a fruit filling... also it is equal to 3 (for large values of 3)... sloopy. Quote Link to comment Share on other sites More sharing options...
fibrewire Posted May 26, 2011 Share Posted May 26, 2011 ಠ ♥ π FJC: Do you have a font set so I can create mockups of your GUI? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted May 27, 2011 Author Share Posted May 27, 2011 ಠ ♥ π FJC: Do you have a font set so I can create mockups of your GUI? In what format precisely would you require such a thing? A tabular bitmap? What features do you wish to visualize? Quote Link to comment Share on other sites More sharing options...
fibrewire Posted May 27, 2011 Share Posted May 27, 2011 Yes a bitmap of the font set would be great. I want to visualize APPS! I like making mockups, and I've wanted to participate in making an 8-bit GUI since 1997. If that's okay with you. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted May 27, 2011 Author Share Posted May 27, 2011 The only one I can find a "sampler" of at the moment is the system bold font, which is used in the menus and window titles: If you want others, I'll have to ask MrFish nicely if he can knock some together. Quote Link to comment Share on other sites More sharing options...
UNIXcoffee928 Posted May 27, 2011 Share Posted May 27, 2011 (edited) its one of their 'business' computers 'Commodore Business Machines', see it has 00 key for currency entry? and the 'π' key is for when your hungry... it produces a pastry food with commonly a fruit filling... also it is equal to 3 (for large values of 3)... sloopy. "Which is precisely the sort of thing we need to know...( for instance), do people want fire that can be fitted nasally?", Douglas Adams Yes, it appears that Commodore was on the fast track to the hearts & minds of Business Folk , back in those days. lol. Good one about the cheap pastries, they live on those... big gloppy platters of them /shivers/ uggg, gross. Edited May 27, 2011 by UNIXcoffee928 Quote Link to comment Share on other sites More sharing options...
fibrewire Posted May 27, 2011 Share Posted May 27, 2011 With FJC GUI, the Atari 800 will live on... Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.