flashjazzcat Posted September 4, 2014 Author Share Posted September 4, 2014 The "Desktop" menu (top) would allow the creation/deletion/selection of named desktops. No scrolling necessary, "just" draw a new screen. The buttons at bottom left/right would allow quick navigation. I mentioned multiple desktops the other day when responding to a question about whether the desktop could be larger and scrollable. So I like the way you're thinking. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 4, 2014 Share Posted September 4, 2014 Barnsey: A Father Ted fan....nice.... _DRINK!!!_ Quote Link to comment Share on other sites More sharing options...
barnsey123 Posted September 4, 2014 Share Posted September 4, 2014 @tschak. Father Jack was once too close to reality...I'm sure they were great days if only I could remember them! @FJC. If mult-desktops are possible then I wonder if we could also set preferences on them (different graphic modes). A well written app might then be able to set up its own desktop to run in...if different from the standard inviolable "master" desktop the app could kick off a new desktop with more colors. If somehow the user manages to alter their prefs to make the desktop unusable a pre-defined key sequence would take them back to the master. From there the faulty desktop can be restored, redefined or nuked by going to the desktop drop-down menu. Those buttons on previous screenshot should probably go on the top menu bar...keyboard shortcut ctrl+< or > Anyway, that's the hard bit done, you just have to code it now... Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 4, 2014 Author Share Posted September 4, 2014 (edited) @FJC. If mult-desktops are possible then I wonder if we could also set preferences on them (different graphic modes). A well written app might then be able to set up its own desktop to run in...if different from the standard inviolable "master" desktop the app could kick off a new desktop with more colors. Maybe higher bit-depths will be supported (much) later on, but for now I'm adamant that anything less than 320x200 looks like crap. VBXE will be the best option for more colour/higher resolution, but that's also low on the list of priorities (indeed, it is akin to the idle process: something I'll think about when there's nothing else to do). Edited September 4, 2014 by flashjazzcat 1 Quote Link to comment Share on other sites More sharing options...
kogden Posted September 4, 2014 Share Posted September 4, 2014 I'm totally with you there, GUI's are pretty useless at less than 320x200. 160x160 on traditional PalmOS was terrible and that didn't even support multiple windows. It could be done but usefulness would be pretty limited I would think. Now a GUI powerpoint-like app that can kick things full screen and in color for the slideshow and then use the GUI for editing would be pretty slick. For giggles I would even drag my Atari in and plug it into the projector at work and use it for meeting slides occasionally. VBXE support would be killer down the road though. I might actually bite the bullet and buy a VBXE at that point. 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 4, 2014 Author Share Posted September 4, 2014 (edited) Full-screen will be the way forward for anything involving colour. I was musing on IRC the other night about how cool it would be to make a 50FPS video player once someone comes up with a DMA hard disk host adapter. It would then be possible to read the videos from a filesystem (FAT) and we could have a player in the GUI which goes full-screen, and something to fill the 4GB partitions with. VBXE will be a big undertaking. It would have been much easier if the graphics library was device independent, but unfortunately there are a lot of direct screen writes and everything's mapped bit-to-pixel. If redraws had been done at the pixel level, it would have been much easier to simply replace the device dependent parts. Having said that, it's more or less inevitable we'll have to do something for VBXE at some point in the future - even for curiosity's sake. There's space for colour information in UI controls, and the coordinate system is signed 16-bit on both axes. Having all kinds of troubles with non-working YouTube embed links at the moment, but I've done a small site update: http://www.atari8.co.uk/news/ http://www.atari8.co.uk/gui/ Edited September 4, 2014 by flashjazzcat 1 Quote Link to comment Share on other sites More sharing options...
Chilly Willy Posted September 4, 2014 Share Posted September 4, 2014 @FJC. If mult-desktops are possible then I wonder if we could also set preferences on them (different graphic modes). A well written app might then be able to set up its own desktop to run in...if different from the standard inviolable "master" desktop the app could kick off a new desktop with more colors. If somehow the user manages to alter their prefs to make the desktop unusable a pre-defined key sequence would take them back to the master. From there the faulty desktop can be restored, redefined or nuked by going to the desktop drop-down menu. Ah yes, the Amiga method of handling desktops (which they called screens). The Amiga started with a "workbench" screen that anybody could open windows on. Apps could have a private screen by opening it directly. Then in 2.0 KS, Amiga added the ability to allow apps to open public screens that apps could use in place of workbench. The Amiga used a couple widgets in the top left of the menu bar to allow flipping screens, and you could also drag down screens to see the ones behind it (I don't expect THAT on the Atari ). You could also press a couple keyboard combos to flip screens or bring the workbench to the front. 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 4, 2014 Author Share Posted September 4, 2014 (edited) ...you could also drag down screens to see the ones behind it (I don't expect THAT on the Atari I remember that on the Amiga, and oddly enough it's one thing to which the Atari display list is perfectly suited. Edited September 4, 2014 by flashjazzcat 2 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 4, 2014 Share Posted September 4, 2014 the copper, and its list, on the Amiga (which allows such behavior to happen), was a direct outgrowth of the antic and its display list. -Thom 2 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted September 4, 2014 Share Posted September 4, 2014 Rip jay miner Quote Link to comment Share on other sites More sharing options...
pixelmischief Posted September 4, 2014 Share Posted September 4, 2014 Maybe higher bit-depths will be supported...VBXE will be the best option for more colour/higher resolution. A 256 color desktop at 640x480 running "The Last Word" in a window would be freaking AMAZING!!! Is it possible, and if so planned, to provide a virtual machine for text mode apps to run in? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 4, 2014 Author Share Posted September 4, 2014 Is it possible, and if so planned, to provide a virtual machine for text mode apps to run in? I'd like it to be possible to launch non-GUI apps eventually, but this will require the Atari OS, DOS, etc, so I'd like to leave such complex matters for the future. I'm quite looking forward to getting a command console running in a window, though. I was playing with SymbOS's CP the other day and it's really cool. 1 Quote Link to comment Share on other sites More sharing options...
+Ripdubski Posted September 4, 2014 Share Posted September 4, 2014 So when this is done, I'm loading this, my 800XL, and a plugin RAM expansion into the Delorean and taking this bitch back to October 26, 1985 thus creating an alternate timeline where Atari will rule the world. 6 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 4, 2014 Author Share Posted September 4, 2014 So when this is done, I'm loading this, my 800XL, and a plugin RAM expansion into the Delorean and taking this bitch back to October 26, 1985 thus creating an alternate timeline where Atari will rule the world. Make sure you take the de-rezonizer to protect against the coloured spheres! 2 Quote Link to comment Share on other sites More sharing options...
pixelmischief Posted September 4, 2014 Share Posted September 4, 2014 I'm quite looking forward to getting a command console running in a window, though. SpartaDOS as a console app would be sick. 1 Quote Link to comment Share on other sites More sharing options...
Chilly Willy Posted September 5, 2014 Share Posted September 5, 2014 I remember that on the Amiga, and oddly enough it's one thing to which the Atari display list is perfectly suited. I was thinking about that... use the reload display address function to start with a new screen when multiple screens are visible. I just said I didn't expect it, not that it wasn't possible. But if you add it in, I won't complain any! 2 Quote Link to comment Share on other sites More sharing options...
kenjennings Posted September 6, 2014 Share Posted September 6, 2014 I remember that on the Amiga, and oddly enough it's one thing to which the Atari display list is perfectly suited. Somewhere on a disk around here I have a demo that does this. It used two graphics 7 screens, one using the GEM default colors, the other using the Workbench default colors. A DLI changed colors between the "top" and "bottom" screens when both were visible. a VBI moved the top screen up and down based on joystick movements by altering the display list (which amounted to shifting about four bytes around.) The rest of it was in basic. It drew different things/printed text messages on the screens when the joystick button was pressed. The display glitz was really very trivial, because of the way the display list works. If only I knew which disk it was on... Did you know that post-it note glue doesn't last as long as the floppy disks they're stuck on? Quote Link to comment Share on other sites More sharing options...
phoenixdownita Posted September 6, 2014 Share Posted September 6, 2014 (edited) Make sure you take the de-rezonizer to protect against the coloured spheres! ..... so true ..... it's been 3 days that we have 1 day ..... before that it was 2 days that we had 2 days ..... complex math makes my head spin ..... I thought it was 3, 2, 1, "ignition" but it appears more like ...3, 2, 2, 1, 1, 1, some more 1, "ignominy" .... wait this will derail the thread. On a more pertinent note hell of a job going on here, speechless. Ever thought of flipping the problem on his head ... I mean the basic fjc-OS dealing with scheduling, resource allocation and gfx driver, while the fjc-UI-svr is a "privileged" service process that deals with the rendering and the widgets, at that point a console can exist outside the fjc-UI-svr or hosted in the fjc-UI-svr ... and GUI apps simply interact with the fjc-UI-svr process (aka window manager + desktop compositor). It will slow down vanilla operations but it would allow alternative renderers as well as separate drivers for VBXE. Just a thought, my specialty is not on OS internals or gfx architecture anyway. Edited September 6, 2014 by phoenixdownita Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 6, 2014 Author Share Posted September 6, 2014 (edited) Ever thought of flipping the problem on his head ... I mean the basic fjc-OS dealing with scheduling, resource allocation and gfx driver, while the fjc-UI-svr is a "privileged" service process that deals with the rendering and the widgets, at that point a console can exist outside the fjc-UI-svr or hosted in the fjc-UI-svr ... and GUI apps simply interact with the fjc-UI-svr process (aka window manager + desktop compositor). It will slow down vanilla operations but it would allow alternative renderers as well as separate drivers for VBXE. That's exactly how it works. Well - more or less: the graphics driver being (necessarily) built into the "UI server". But if you replace bits of the "UI server", you could make it run in VBXE modes without changing anything else. Edited September 6, 2014 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
UNIXcoffee928 Posted September 6, 2014 Share Posted September 6, 2014 Did you know that post-it note glue doesn't last as long as the floppy disks they're stuck on? Romy White and Michele Weinberger are clearly to blame for this issue. 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 6, 2014 Share Posted September 6, 2014 Just wanted to say what an amazingly impressive piece of work this is, flashjazzcat. Really inspiring stuff, and this thread has been fascinating to follow. Apologies if the name matter has already been settled and I missed it, but how about naming (or code naming) it after that supportive wife of yours? It could be a tongue-in-cheek play on the old Atari code-naming tradition. Anyway, just a silly idea I had. Keep up the good work! 3 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 6, 2014 Author Share Posted September 6, 2014 DebiOS? 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 6, 2014 Author Share Posted September 6, 2014 Found something odd this evening: leaving the mouse pointer stationary over on the right hand side of the screen resulted in idle CPU usage of 31-32 per cent. Moving the mouse pointer over to the left hand side of the screen and leaving it stationary saw idle usage drop to 27 per cent. There was no obvious explanation for this, but a clue lay in the fact that the 31-32 per cent was constantly fluctuating, while the 27 per cent load was steady. Because of carry-over arithmetic, the duration of the NMI when the mouse was over to the right was about 100 cycles more than when it was at the left. All I can assume is that this results missed scheduler IRQs, when the NMI finishes and the next IRQ which hits is for the mouse port. There may also be the odd missed scheduler IRQ when the pointer is over to the left. Obviously a missed scheduler IRQ means that the VCOUNT sampling is thrown off (since it's assumed than no more than one frame has elapsed during samples). There might be some mileage in simply moving the scheduler to the VBlank NMI: this will avoid skipped interrupts and also drop the scheduler down to 50/60Hz (down from 64). Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 7, 2014 Share Posted September 7, 2014 Now that you mention that, that makes perfect sense, but sheezus, these are the kids of weird things that you only run into after you've implemented interrupt sensitive code. -Thom Quote Link to comment Share on other sites More sharing options...
Stefan Both Posted September 7, 2014 Share Posted September 7, 2014 DebiOs IS INDEED a good idea. I vote it, if you do a survey... Stefan 2 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.