jvas Posted April 12, 2012 Share Posted April 12, 2012 The ST has the very same resolution. Though in 16 colors. The colours certainly help, but there's still a massively claustrophobic feeling with GEM at that resolution.. I admit that, but it is not that bad, if you choose smaller fonts, than the default one. Quote Link to comment Share on other sites More sharing options...
+DarkLord Posted April 12, 2012 Share Posted April 12, 2012 The ST has the very same resolution. Though in 16 colors. The colours certainly help, but there's still a massively claustrophobic feeling with GEM at that resolution.. I admit that, but it is not that bad, if you choose smaller fonts, than the default one. RIght, traditionally ST owners avoided it, only using it for games or the rare piece of software that absolutely required it, otherwise switching to and using Medium res... As you said though, you can change the font, and check out this thread for what's been happening to low res. I think it's quite pretty. http://www.atariage....-color-desktop/ Oh btw, it says "STe", but it will actually work with any ST... Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 12, 2012 Author Share Posted April 12, 2012 (edited) If this GUI gets any faster, I'll start to wonder why a project like this wasn't picked up towards the end of the 130XE line - could've breathed new life into a dying computer brand. $100 Mac! Would a $100 Mac lookalike be a better description? given the Mac had a 32 bit CISC microprocessor. What's the point being made here? We're getting (unexpectedly) good performance out of the 6502. The GUI isn't intended just to look pretty - it's supposed to be usable as well. I don't think the assumption was that the 6502 was not powerful enough was the problem, but I think from a comfort point of view 320x200 screen just didn't offer enough screen real-estate, not once the medium and high resolution displays arrived. And to a lesser degree the small storage options available to the 8bits at the times, and the fact they traditionally had bugger all memory, and that display devices usually connected to these were awful things. I was just going by a few remarks right at the beginning of this thread, and in other places on this forum and elsewhere on the Net. I don't believe the screen size is such a big issue, especially when using small proportional fonts. I agree with the latter points: I think it was a combination of storage and RAM shortage, plus the feeling that lots of MHz were required to push the data around. Yes, there was GEOS, but the graphics were pretty static in the early versions, windows didn't scroll, move, etc. Later versions partly addressed this, but in a limited way. Of course there was GEOS in 1986, which I think is about as successful, commercially, as any 8Bit GUI could have been at the time and I think did an amazing job given the constraints.. Perhaps if the Apple2 version of GEOS with its higher resolution had arrived in 1986 instead of 1988 things might taken a different turn. GEOS was a pretty sober approach to an 8-bit GUI, since it didn't attempt to implement some of the tricker aspects, such as overlapping, movable windows, etc (although later versions did, albeit using a full desktop redraw which was rather slow). The GUI - it transpires - relies on very heavy CPU work, and I think that's where the Atari has a slight advantage. ...but there's still a massively claustrophobic feeling with GEM at that resolution. Proportional fonts would have made all the difference. That's where Mac OS 1 wipes the floor up with GEM, IMO. Edited April 12, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
IndusGT Posted April 12, 2012 Share Posted April 12, 2012 The GUI's going to be cartridge based. Are we talking about an Atarimax type of cartridge(flashcart) or something that would be sold through example Video 61? Will you be using Antic banking Mode, since Diamond used it and it was undesirable if not impossible to run in an XL system. Thank you for all your efforts Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 12, 2012 Author Share Posted April 12, 2012 Are we talking about an Atarimax type of cartridge(flashcart) or something that would be sold through example Video 61? SIDE, SIC!, AtariMax... anything which has enough space. You'll download ATR, flash cart, and begin... However, I want to make a commercial version with custom cart case, printed manual, etc. The custom cartridge will at the very least have a pass-thru on the back. Will you be using Antic banking Mode, since Diamond used it and it was undesirable if not impossible to run in an XL system. I did NOT know that Diamond used Antic banking mode. You learn something every day. The new GUI does NOT use Antic banking mode, since it's simply impossible to rely on its presence. You do need at least 128KB, however. Quote Link to comment Share on other sites More sharing options...
IndusGT Posted April 12, 2012 Share Posted April 12, 2012 Are we talking about an Atarimax type of cartridge(flashcart) or something that would be sold through example Video 61? SIDE, SIC!, AtariMax... anything which has enough space. You'll download ATR, flash cart, and begin... However, I want to make a commercial version with custom cart case, printed manual, etc. The custom cartridge will at the very least have a pass-thru on the back. Will you be using Antic banking Mode, since Diamond used it and it was undesirable if not impossible to run in an XL system. I did NOT know that Diamond used Antic banking mode. You learn something every day. The new GUI does NOT use Antic banking mode, since it's simply impossible to rely on its presence. You do need at least 128KB, however. Great news, I am down for at least TWO of the commercial versions... Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 15, 2012 Author Share Posted April 15, 2012 (edited) Fixed several bugs this weekend (still a few left), and managed to implement some of the extra clipping and masking optimisations missing from the previous demos. Still more to add (such as not redrawing client area if a window becomes smaller on both axes, etc), but these refinements are numerous and will take rather a long time to realize. The most obvious stuff is working now: http://youtu.be/mGowo9a7Bm8 This feels a lot more responsive in operation, since rendering of objects entirely hidden by foreground items is now completely skipped. That window shoots off the desktop, by the way, because of an inadvertent mouse movement: you don't have to explicitly "top" windows before grabbing drag bars, etc, in the this system, and the slight delay as a window comes to the front while you're dragging can be slightly disconcerting. Even in this demo, topped windows are unnecessarily rendering stuff through opaque masks, so it'll be even faster with the rest of the intersection code is added. Edited April 15, 2012 by flashjazzcat 2 Quote Link to comment Share on other sites More sharing options...
w1k Posted April 15, 2012 Share Posted April 15, 2012 (edited) what do you mean, you try remove that slow window movement/redraw ? Edited April 15, 2012 by w1k Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 15, 2012 Author Share Posted April 15, 2012 (edited) what do you mean, you try remove that slow window movement/redraw ? What I mean is bringing a window to the front will become slightly quicker when the rest of the clipping for that operation is implemented. Now, go ahead and show me the slow bit. Edited April 15, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
Faicuai Posted April 15, 2012 Share Posted April 15, 2012 Fixed several bugs this weekend (still a few left), and managed to implement some of the extra clipping and masking optimisations missing from the previous demos. Still more to add (such as not redrawing client area if a window becomes smaller on both axes, etc), but these refinements are numerous and will take rather a long time to realize. The most obvious stuff is working now: http://youtu.be/mGowo9a7Bm8 This feels a lot more responsive in operation, since rendering of objects entirely hidden by foreground items is now completely skipped. That window shoots off the desktop, by the way, because of an inadvertent mouse movement: you don't have to explicitly "top" windows before grabbing drag bars, etc, in the this system, and the slight delay as a window comes to the front while you're dragging can be slightly disconcerting. Even in this demo, topped windows are unnecessarily rendering stuff through opaque masks, so it'll be even faster with the rest of the intersection code is added. ...Just a BIG thanks for the continued effort and focus. The on-screen dynamics already remind me of what I used to see in first-gen Macs: screen-redraw speed, masking "intelligence", overall aesthetics and quality seem already in place. It will very likely need s-video to realize its full potential (running this on composite would be a disservice to both our Ataris as well as this product). The reason I mention this is because a week-ago I also bought an DVDO iScan V2-Pro, Si502-powered de-interlacer (not to be confused with my coming VP-50) in order to complete my 800XL desktop-LCD setup (with Viewsonic VP-191B LCD monitor). Long story short, the iScan V2 has a small switch on the front to immediately move from active s-video input to stand-by Composite input (e.g. SW that relies on color-artifacting, etc.) and I can clearly see that ALL the Gr.8-B&W material significantly suffers from Composite-video rendering (e.g. pixel-fine patters become garbled/false-colored, 80-cols. fonts become color-aliased, etc.). In fact, even my own-generated Gr.8 patterns to adjust LCD-monitor+iScan rendering seem like day-and-night when flipping the video-input switch on the iScan... Nevertheless, your work has all the basic ingredients for becoming a masterpiece. Bring it on! Quote Link to comment Share on other sites More sharing options...
w1k Posted April 15, 2012 Share Posted April 15, 2012 i mean nothing wrong to you i want ask if you want fastest final version, or waht, if you understand Quote Link to comment Share on other sites More sharing options...
1NG Posted April 15, 2012 Share Posted April 15, 2012 Great work! I was thinking about the drawing order: On the one hand it is good to see the moved window drawn first before the "old" one disapears on the last position because the directory is shown early and can be read while the rest of the drawing is rendered. On the other hand it looks unnaturally because something has to disapear before it apears again to look natural. Beeing there twice and erasing the false twin has something unnatural. If it is possible to change the order easily I would like to see a prototype with changed drawing order just to feel out the difference. But don´t waste to much time on it if it is not easy to do. It is good like it is. Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted April 15, 2012 Share Posted April 15, 2012 Damn, that's looking really good Wish we could play with it now Jay Quote Link to comment Share on other sites More sharing options...
+Stephen Posted April 16, 2012 Share Posted April 16, 2012 Looks awesome as usual! Just curious - do you have the scrollbars "wired" yet? Quote Link to comment Share on other sites More sharing options...
+MrFish Posted April 16, 2012 Share Posted April 16, 2012 Looks awesome as usual! Just curious - do you have the scrollbars "wired" yet? Last I checked they weren't. I doubt he's had time to add that, since he's been focused on the redraws, coding up the BIOS for Incognito and working with FAT32. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 16, 2012 Author Share Posted April 16, 2012 ...Just a BIG thanks for the continued effort and focus. The on-screen dynamics already remind me of what I used to see in first-gen Macs: screen-redraw speed, masking "intelligence", overall aesthetics and quality seem already in place. Many thanks. It will very likely need s-video to realize its full potential... No question about it. You don't want artifacting on a system like this. i mean nothing wrong to you i want ask if you want fastest final version, or waht, if you understand No - of course I want the slowest final version. Making it as fast as possible is a great idea though! I was thinking about the drawing order: On the one hand it is good to see the moved window drawn first before the "old" one disapears on the last position because the directory is shown early and can be read while the rest of the drawing is rendered. On the other hand it looks unnaturally because something has to disapear before it apears again to look natural. Beeing there twice and erasing the false twin has something unnatural. If it is possible to change the order easily I would like to see a prototype with changed drawing order just to feel out the difference. But don´t waste to much time on it if it is not easy to do. It is good like it is. I appreciate the comments, but it's staying the way it is. Look at early Mac OS, GEM, and SymbOS. They all work this way for good technical reasons. The entire window manager would have to be rewritten in order for old stuff to be erased first (and it would then be impossible to blit a window from one place to another). Hope that's OK. Looks awesome as usual! Just curious - do you have the scrollbars "wired" yet? Last I checked they weren't. I doubt he's had time to add that, since he's been focused on the redraws, coding up the BIOS for Incognito and working with FAT32. That's right. The scroll bars scale and move, but dragging them doesn't affect the content yet. The sample application isn't taking any notice of the scrollbar offsets just yet. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 17, 2012 Author Share Posted April 17, 2012 Window manager is just about debugged now. Here I am flinging three windows around (it was never tested with more than two following re-writes prior to this capture being made). This marks the end of a critical stage (notwithstanding further optimisations to the window manager, which I see as non-urgent in light of other pressing tasks). With a solid window manager in place, we can now relocate to cartridge, farm resources out to extended RAM, write a dialogue manager and start to draw up the API calls. Desktop icon selection and window scrolling are a short step away, but I'd like to tackle other, long-overdue jobs first. 3 Quote Link to comment Share on other sites More sharing options...
Ransom Posted April 17, 2012 Share Posted April 17, 2012 That looks very, very nice. Amazing, really. Quote Link to comment Share on other sites More sharing options...
Mark Wolfe Posted April 17, 2012 Share Posted April 17, 2012 smooooooth! definitely time to move on to other issues, you nailed this part of it. Quote Link to comment Share on other sites More sharing options...
mangamuscle Posted April 19, 2012 Share Posted April 19, 2012 Window manager is just about debugged now. Here I am flinging three windows around (it was never tested with more than two following re-writes prior to this capture being made). I would like to ask, in the (near?) future, if the atari ethernet cartdrige is ever completed is there a chance that this GUI gets/imports/recompiles Contiki's IP stack and utilities? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 19, 2012 Author Share Posted April 19, 2012 I would like to ask, in the (near?) future, if the atari ethernet cartdrige is ever completed is there a chance that this GUI gets/imports/recompiles Contiki's IP stack and utilities? I couldn't honestly say. I was led to believe the stack was RAM-hungry, but I must say my understanding of Contiki is limited. My preference would have been for something which delegated the IP stack implementation entirely to the hardware, so that a simple software interface could have been employed for interaction with the Internet. I would imagine - since this GUI bears no relation whatsoever to Contiki - that the IP stack would have to be entirely reimplemented in assembly language. Technical minds will have to explain... Whatever happens, it won't be in the near future: I have hands full for the next year or so getting basic functionality written. Quote Link to comment Share on other sites More sharing options...
mangamuscle Posted April 19, 2012 Share Posted April 19, 2012 I would like to ask, in the (near?) future, if the atari ethernet cartdrige is ever completed is there a chance that this GUI gets/imports/recompiles Contiki's IP stack and utilities? I was led to believe the stack was RAM-hungry I am no expert, but Contiki "advertises" itselft as requiring only 40k ROM + 2k RAM. That is the reason the IP stack could be used in other low RAM configurations. Thanks for replying Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted April 20, 2012 Author Share Posted April 20, 2012 I am no expert, but Contiki "advertises" itselft as requiring only 40k ROM + 2k RAM. That is the reason the IP stack could be used in other low RAM configurations. Well - maybe it will be possible. I hope so. However, one practical point: if the ethernet cart is plugged in, where does the GUI cart go? 1 Quote Link to comment Share on other sites More sharing options...
31336haxx0r Posted April 20, 2012 Share Posted April 20, 2012 Well - maybe it will be possible. I hope so. However, one practical point: if the ethernet cart is plugged in, where does the GUI cart go? Well... However, I want to make a commercial version with custom cart case, printed manual, etc. The custom cartridge will at the very least have a pass-thru on the back. You just gave the answer to yourself. Quote Link to comment Share on other sites More sharing options...
andym00 Posted April 20, 2012 Share Posted April 20, 2012 Well - maybe it will be possible. I hope so. However, one practical point: if the ethernet cart is plugged in, where does the GUI cart go? Contiki is a bit more than 'just' a TCP/IP stack, hence it's full name Contiki-OS.. Projects like uIP(micro IP) work in 4-5K of code space with RAM use measured in the hundreds of bytes.. And is also part of Contiki.. By the same guy, but whether or not it was the starting point of Contiki I don't know.. It used to be a seperate project, but now seems to link directly to Contiki, hence why I've linked to the old uIP Also projects like ip65 etc.. There's stacks of them out there, and there's no reason for them to be show-stopping in size, unless you want to write the worlds first 6502 Torrent client supporting 1000's of simultaneous connections 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.