Matej Posted December 15, 2016 Share Posted December 15, 2016 Can we call it ACHROMATIC OS? New GUI OS sounds strange. Achromatic = https://en.wikipedia.org/wiki/Achromatic Achromatic means literally “without color”. It can also refer to: Achromatic colors, “greys” or “neutral colors”, also black Achromatic lens, a lens designed to minimize chromatic aberration Achromatic vision: Monochromacy (total color blindness) Achromatopsia Monochrome So meaning is perfect. Also A can be for Atari. So can be Atari Chromatic shortage. Also any plans for VBXE version??? As I will have VBXE. And I want see color icons! Blitter support! When will be cartridge available? Quote Link to comment Share on other sites More sharing options...
w1k Posted December 15, 2016 Share Posted December 15, 2016 lol Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted December 15, 2016 Share Posted December 15, 2016 (edited) Not to get too far ahead here.... but this GOS is moving at fast enough speeds that some color imho might eventually be possible... I prefer performance over aesthetics but I am sure it could be demand driven. color might naturally drop out under demand, display list cut down when speed is needed etc... we have sort of seen that done for bbs output speeds and for compression decompressing programs and the like.... it may be possible in the future or not at all but there could be a way in which things get done in due time. As I looked at what has been accomplished so far.... the OS already sort of does handle things or appears to prioritize things to give it the nice feel it's already got going on. Edited December 15, 2016 by _The Doctor__ 1 Quote Link to comment Share on other sites More sharing options...
Prodatron Posted December 15, 2016 Share Posted December 15, 2016 FJCs GUI based multitasking operating system really should have a real brand name soon. Though A8GUI and A8GOS already created a brand here (and at youtube etc...) But I know, it's really hard to find the perfect name, logo etc. for such a project, especially when it's already existing for so many years. 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 15, 2016 Author Share Posted December 15, 2016 All it needs to work in colour is a VBXE driver and colour resources. So it might be unwise to give it a name referencing a lack of colour. A VBXE driver would be faster than the ANTIC driver, since the hardware blitter could be used for most rendering operations (and would replace the software blitter). There are many unaddressed unknowns regarding mouse pointer rendering in an interrupt and font bitmap upscaling, but the possibility is there. 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted December 15, 2016 Share Posted December 15, 2016 (edited) I vote for Flash Jazz GOS, or name it after the CAT! I am not buying a VBXE, and during our discussion I thought it was primarily going to be standard Antic machines and that a VBXE driver would be provided for extra goodies overlaying the base displays but if that has changed can we at least fork it or make it part of an auto-config where the software blitter ANTIC driver stays unless the VBXE is detected and then the software blitter gets yanked and the vbxe hardware drivers load? Edited December 15, 2016 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 15, 2016 Author Share Posted December 15, 2016 (edited) What have I written which suggests the GOS is no longer primarily aimed at stock video hardware? The whole idea of having display drivers is that the GUI itself is completely hardware abstracted. If in the future we can be bothered to write a VBXE driver and craft 16 or 256 colour icons and handle resampling them down to various bit depths on the fly, then the facility exists to do so. The coordinate system is signed 16-bit and the GUI control records allow for 8-bits of colour. No forks are required: just a driver. Seriously, I have enough to worry about writing filesystem drivers and all the unwritten GUI components without reaching for a colour display at the moment. Edited December 15, 2016 by flashjazzcat 4 Quote Link to comment Share on other sites More sharing options...
+mytek Posted December 15, 2016 Share Posted December 15, 2016 What have I written which suggests the GOS is no longer primarily aimed at stock video hardware? The whole idea of having display drivers is that the GUI itself is completely hardware abstracted. If in the future we can be bothered to write a VBXE driver and craft 16 or 256 colour icons and handle resampling them down to various bit depths on the fly, then the facility exists to do so. The coordinate system is signed 16-bit and the GUI control records allow for 8-bits of colour. No forks are required: just a driver. Seriously, I have enough to worry about writing filesystem drivers and all the unwritten GUI components without reaching for a colour display at the moment. I love the monochrome look I remember way back when I had an ST, the color desktop always looked so cheesy, whereas the hi-rez mono one looked very pro. IMHO color GUIs only look good if you've got the resolution to back it up. Not sure how much the VBXE is reasonably able to pull off when it comes to this, but for me mono just has that serious Desktop Publishing/CAD feel to it that I love. - Michael Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 16, 2016 Author Share Posted December 16, 2016 With VBXE, 640x480x16 should be doable using Rybags' interlace. And of course 320x240x256. The biggest job would be equipping all applications with resources of sufficient colour depth and then figuring out how to store and display them in a stock system. 1 Quote Link to comment Share on other sites More sharing options...
TheNameOfTheGame Posted March 10, 2017 Share Posted March 10, 2017 That would be a great use of the vbxe. Maybe just plugging in a driver for it depending on how the driver subsystem is built. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 10, 2017 Author Share Posted March 10, 2017 That would be a great use of the vbxe. Maybe just plugging in a driver for it depending on how the driver subsystem is built. That's exactly how it will work. The entire display subsystem is being painstakingly redesigned so that all the hardware-specific parts are part of a module which can be swapped out. 3 Quote Link to comment Share on other sites More sharing options...
TheNameOfTheGame Posted March 11, 2017 Share Posted March 11, 2017 That's exactly how it will work. The entire display subsystem is being painstakingly redesigned so that all the hardware-specific parts are part of a module which can be swapped out. Sounds like a pretty big nut to crack, but if anyone can do it it is yourself. Thanks for the update! 1 Quote Link to comment Share on other sites More sharing options...
areeve Posted March 11, 2017 Share Posted March 11, 2017 To the detriment of other overdue projects, I'm experimenting with the basics of a new GUI system for the 8-bit. The mouse handler is just about finished (the reason this is taking so long is because the mouse is drawn in bitmapped graphics rather than using a PMG, and this necessitates extra work to ensure it always remains visible even when the underlying app is drawing to the screen), and everything else should keep me busy for the next six months or so. There are two reasons this project interests me: 1) I find GUIs intrinsically fascinating, and I always wanted to write one. 2) At the risk of courting huge criticism from those who've already written good GUIs for the 8-bit, I think the world could stand another crack at it, since mostly they've either ended up as unsupported novelties, or elaborate ways of launching text-mode applications. Diamond still seems the most ambitious attempt, and I'm inclined to make the new system partly or wholly compatible with the API described in the Diamond Developers' Kit. This doesn't mean, however, that the new system will look or work the same as Diamond. I think it's a mistake to try an implement a full-blown Windows type environment that the 8-bit can't really handle. GEOS on the Commodore 64, for example, didn't have moveable or sizeable windows, and if it had been running on a 1.7MHz 6502, it would have been quite useable. So we won't necessarily see overlapping windows, scroll bars, and the like with my system. It will be a framework for writing consistent applications which utilize a uniform mouse/menu/dialogue interface. The system will also use proportional fonts, which is a good compromise between readability and maximising screen real-estate. Whether it will end up on a cartridge or not, I don't know. There's a huge amount of work to do and when I get a blank desktop with a working menu bar across the top of it, I'll know I'm getting somewhere. The intention is to release it with a GUI version of The Last Word, plus a simple notepad type program, a handful of accessories, and a decent file manager. Being realistic at this stage in the game, life's too short to write a bunch of big applications on my own, so one of my most difficult tasks is going to be making this system attractive and accessible to the handful of programmers who might be inclined to write their own apps. We can look at what happened to Diamond, which to my knowledge never had a single third-party application written for it. Perhaps my own effort will go the same way. I'd like from the offset, though, to get opinions from interested parties. What kind of GUI would you have liked to have seen twenty years ago on the Atari? What would you like such a system to do now? Do you think it's a waste of time? I'd love to hear your views. Thanks for the kind words about Diamond GOS... my view on it is... a) I sure didn't have the money to support the project to the point that would have gotten 3rd party apps developed for it. I kept having whispers in my ear about Atari being interested, but they clearly weren't (as they were focused on the Atari ST). I never had any direct contact with Atari and don't know how much of what I heard was actually true vs hearsay, but in thinking about it now it seems a bit ridiculous to think Atari would have packaged an 8-bit computer with a GOS which would have somewhat competed with its Atari ST line of computers. b) The install base wasn't there and when ICD pulled the plug on it (e.g. I got a phone call telling me I could order one last batch of cartridges and that was it and certainly didn't have the resources to make a huge order... a great lesson in binding your product to one supplier) I don't recall exactly how many had been sold, but I'd guess around 4 to 5 hundred at most... ultimately this is what killed it. c) I didn't have the Comp Sci knowledge to do some of the stuff I would have done with it had I known what I know now. Better memory management is what comes to mind first. - Alan 12 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted March 12, 2017 Share Posted March 12, 2017 (edited) @Alan- Don't be hard on yourself... we had a lot of that back in the day. You were and still are an inspiration. Friends and common interests persist through years. I.C.D. became a mixed bag for a multitude of reasons, delivery of product became a problem as someone wanted a lifestyle and made a mess of a number of things.. Supra and Electrosmith, and a couple others produced most of their stuff anyway.... and there was really no way for you to know it.... Edited March 12, 2017 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
toddtmw Posted March 12, 2017 Share Posted March 12, 2017 Wasn't there a graphical interface for the 8-bit Ataris back in the 80's? Quote Link to comment Share on other sites More sharing options...
+MrFish Posted March 12, 2017 Share Posted March 12, 2017 Wasn't there a graphical interface for the 8-bit Ataris back in the 80's? Yes, Diamond GOS; and Alan Reeve -- speaking above -- is the one who created it. 3 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted March 12, 2017 Share Posted March 12, 2017 Wasn't there a graphical interface for the 8-bit Ataris back in the 80's? Yeah, a very few posts ago, if you can't find it, it's here: http://atariage.com/forums/topic/154520-new-gui-for-the-atari-8-bit/page-149?do=findComment&comment=3716043 It's nice to see such an astute contributor to the GUI thread. 1 Quote Link to comment Share on other sites More sharing options...
toddtmw Posted March 12, 2017 Share Posted March 12, 2017 Sorry, I saw the thread and read a little bit of it and jumped to the end to ask my question. These threads get so long, it's hard to get caught up when you come into them late. 2 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 14, 2017 Author Share Posted March 14, 2017 Memory management is challenging on the A8, not least because the RAM banking is a little inflexible. Since 2014 or so, the A8 GOS's general structure is broadly modelled after SymbOS (on the CPC, Amstrad and MSX) and if you look at the SymbOS documentation you'll see that the banking schemes on those Z80 machines lend themselves a little better to a multitasking OS. For example, one bank is the "transfer" area which is basically directly addressable by code in any other bank. Contrast this with the A8, where everything in an extended bank is forced to share the same address space. This presents some mighty challenges, especially when applications want to dynamically allocate memory or drivers need to transfer data to and from buffers belonging to a different process. Difficulties are compounded by the relocatable binary format I decided to adopt (that of the MADS assembler), which - unlike the SDX relocatable file format, which has its own limitations - only allows a single binary segment. The upshot of that is that you can't build a driver with a segment which installs in conventional memory, another which installs in extended memory, and code which gets fixed up in both regions and is able to directly call the other. In reality this may not be such a big deal since the kernel provides calls outside of the banked area whose job it is to copy data between banks, read n bytes from a hardware register into a specified address, etc. But it's still a tremendous PITA, and far more cumbersome than working around a fixed stack location, sharing ZP between processes, and other stuff which has already been solved. For information, the memory manager in the GOS uses a bitmap as an index to 256-byte pages of extended RAM, and there's another version of it which handles conventional memory in small sixteen byte chunks. Both are closely modelled on the allocator in the LNG (Lunix) OS, whose author I emailed some time ago with this exciting news but I didn't hear anything back. It does rather nice best-fit allocation so things don't become too fragmented. It's interesting to see how little of the original blurb quoted above (written a year before the project was undertaken in earnest) still applies now. The thing was originally going to be a graphical UI for DOS applications, then it was a single-tasking desktop metaphor, then it was a multi-tasking shell, and then it became a full multi-tasking graphical OS... with corresponding re-writes along the way. Having a clear plan from the get go would probably have helped, as would not being involved in other stuff (APT, UFLASH, U1MB Alt BIOS, The Last Word), but you live and learn. It's a gargantuan investment of time and effort and the most short-sighted thing I ever did was try to put dates on the road-map. 14 Quote Link to comment Share on other sites More sharing options...
ivop Posted March 14, 2017 Share Posted March 14, 2017 Perhaps you could optionally support the 128kB S/XEGS RAMCart . That way you can switch $4000-$7FFF and $8000-$BFFF, effectively bank switching 32kB. Or maybe we need a new RAM upgrade that can switch a full 48kB, including stack and page zero through an Axlon style bank switching location 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 14, 2017 Author Share Posted March 14, 2017 Well, the banking limitations are the prime reason the system must be ROM/cart based, since we need large amounts of code which can get direct access to all the banked RAM. The microkernel sits in the Shadow RAM and the GUI is in banked ROM. This gets around some of the problems and at least means the OS can work without hardware mods. Quote Link to comment Share on other sites More sharing options...
+JAC! Posted March 16, 2017 Share Posted March 16, 2017 the most short-sighted thing I ever did was try to put dates on the road-map One more quote from the thread printed and now hanging on the wall :-) 3 Quote Link to comment Share on other sites More sharing options...
DracIsBack Posted May 21, 2017 Share Posted May 21, 2017 Thanks for the kind words about Diamond GOS... my view on it is... a) I sure didn't have the money to support the project to the point that would have gotten 3rd party apps developed for it. I kept having whispers in my ear about Atari being interested, but they clearly weren't (as they were focused on the Atari ST). I never had any direct contact with Atari and don't know how much of what I heard was actually true vs hearsay, but in thinking about it now it seems a bit ridiculous to think Atari would have packaged an 8-bit computer with a GOS which would have somewhat competed with its Atari ST line of computers. b) The install base wasn't there and when ICD pulled the plug on it (e.g. I got a phone call telling me I could order one last batch of cartridges and that was it and certainly didn't have the resources to make a huge order... a great lesson in binding your product to one supplier) I don't recall exactly how many had been sold, but I'd guess around 4 to 5 hundred at most... ultimately this is what killed it. c) I didn't have the Comp Sci knowledge to do some of the stuff I would have done with it had I known what I know now. Better memory management is what comes to mind first. - Alan Wow Alan ... great to hear your experience with that GOS. Honestly as a kid, I was completely obsessed with Diamond GOS. But alas, with a 15 year old's budget, I never could do anything more than rent it from a local user's group. i thought it was a work of art at the time 1 Quote Link to comment Share on other sites More sharing options...
Daschewie Posted June 28, 2017 Share Posted June 28, 2017 Is there any developer documentation available for GOS? I would like to create a subset of ResEdit as an Eclipse extension.(see https://developer.apple.com/legacy/library/documentation/mac/pdf/ResEditReference.pdf) I need to know if GOS has a resource system with identifiers, and data structures/binary format for include files. 1 Quote Link to comment Share on other sites More sharing options...
Matej Posted June 28, 2017 Share Posted June 28, 2017 Any plans for NewGUI-VBXE??? With colors and hires? Quote Link to comment Share on other sites More sharing options...
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.