a8isa1 Posted September 30, 2012 Share Posted September 30, 2012 (edited) It's very responsive and I like the icon typeface. It loaded OK using both picoboot and mypicodos loaders (ver. 4.05) and with QMEG+ OS 4.04. -SteveS Edited September 30, 2012 by a8isa1 Quote Link to comment Share on other sites More sharing options...
jacobus Posted September 30, 2012 Share Posted September 30, 2012 Incredible! Thank you Jon! Works perfectly on my 800XL, 1200 XL and 65 XE ... CTIA 800 crashed and burned (no surprise) Quote Link to comment Share on other sites More sharing options...
atari8warez Posted October 1, 2012 Share Posted October 1, 2012 (edited) Nice and certainly fast for a GUI on an 8 bit computer. I didn't try to duplicate the few problems you mentioned above, however I came across something that is rather serious. If you move a window to the top of the screen and the top of the window overlaps the menu bar, the screen becomes completely garbled and the only way to recover is to reboot. Hope that is something you can easily fix. I attached a video for you so you can see the problem. I tried the demo with Altirra. I also have a question. Is the number of New Windows one can open limited to 4, or is this limit for the demo only? gui.zip Edited October 1, 2012 by atari8warez Quote Link to comment Share on other sites More sharing options...
Jacques Posted October 1, 2012 Share Posted October 1, 2012 Other thing: it doesn't load from SIDE's SDX - memory conflict even on SIDE's built-in config.sys. Quote Link to comment Share on other sites More sharing options...
w1k Posted October 1, 2012 Share Posted October 1, 2012 i have problems with shaking mouse (amiga) on joy port 2 Quote Link to comment Share on other sites More sharing options...
Jacques Posted October 1, 2012 Share Posted October 1, 2012 Haven't you read post #1823? Quote Link to comment Share on other sites More sharing options...
w1k Posted October 1, 2012 Share Posted October 1, 2012 thanks Quote Link to comment Share on other sites More sharing options...
atari8warez Posted October 1, 2012 Share Posted October 1, 2012 (edited) Other thing: it doesn't load from SIDE's SDX - memory conflict even on SIDE's built-in config.sys. Did you try loading it with the X command? Like this: X GUI.EXE Edited October 1, 2012 by atari8warez 1 Quote Link to comment Share on other sites More sharing options...
Jacques Posted October 1, 2012 Share Posted October 1, 2012 Sure I did. Also with /C parameter, but it didn't help. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 1, 2012 Author Share Posted October 1, 2012 (edited) Other thing: it doesn't load from SIDE's SDX - memory conflict even on SIDE's built-in config.sys. I pointed this out in the original post. The XEX loads at $1200... I'm sorry about that, but it's the reason I'm not spending any more time on this disk version. The SIDE driver is probably a non-starter. You'll need to run SDX with USE BANKED and no extraneous drivers. I'll upload the Amiga mouse build shortly. Note the mouse goes in port 2. Nice to see the system running on some hardware other than my own (or MrFish's), Jacobus: thanks for those screenshots. Nice and certainly fast for a GUI on an 8 bit computer. I didn't try to duplicate the few problems you mentioned above, however I came across something that is rather serious. If you move a window to the top of the screen and the top of the window overlaps the menu bar, the screen becomes completely garbled and the only way to recover is to reboot. Hope that is something you can easily fix. I attached a video for you so you can see the problem. I tried the demo with Altirra. Thanks Ray: I don't believe we'd spotted that one before. The windows simply shouldn't overlap the menu bar at all. Probably some new bug I introduced when rewriting the drag code. I also have a question. Is the number of New Windows one can open limited to 4, or is this limit for the demo only? Yes - the four window limit is for the demo only. There's no practical reason to limit the number of open windows, aside from storage and performance considerations, and it's the former which was the brick wall in this instance. The Exit dialogue is in fact a fifth window, though, and shares the exact same data structures as the others. I'd say background applications will have to start caching their window contents on larger memory systems to keep the redraws nice and fast if we end up doing cooperative multitasking. What seems to work well is the self-cleaning heap manager and the various clipping and masking algorithms. I'm glad, since they took a long time to develop. Edited October 1, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 1, 2012 Author Share Posted October 1, 2012 (edited) Here are two bug-fixed builds, one for an ST mouse and one for an Amiga mouse: guiST_011012.zip guiAmi_011012.zip The window-over-menu-bar bug is fixed, and it's no longer possible to select desktop icons while the modal dialogue is on the screen. Revised project page: http://www.atari8.co.uk/gui/ Edited October 1, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
+bob1200xl Posted October 1, 2012 Share Posted October 1, 2012 GUI works fine on a 1.79mhz, 64K 65816, but the cursor is not rendered on a 7.16, 512K 65816. You can see a single pixel where the cursor should be drawn, so you do have some control. Regardless, it is very cool. Bob GUIon1200XL7.WMV Quote Link to comment Share on other sites More sharing options...
w1k Posted October 1, 2012 Share Posted October 1, 2012 this is a bug? move windows totally left .. in try move right https://www.youtube.com/watch?v=Z5QmFhmeCSg Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 1, 2012 Author Share Posted October 1, 2012 (edited) GUI works fine on a 1.79mhz, 64K 65816, but the cursor is not rendered on a 7.16, 512K 65816. You can see a single pixel where the cursor should be drawn, so you do have some control. Thanks Bob. I knew this would happen since the pointer renderer relies on cycle counting. I'll have to revise it to use WSYNC waits (or VCOUNT?) before it'll work at 7Mhz. Candle warned me... Shame there are no 7Mhz emulation options. I'll prepare a fix soon, if you want to test it Bob? this is a bug? move windows totally left .. in try move right https://www.youtube....h?v=Z5QmFhmeCSg Well spotted. It's a bug. Edited October 1, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
+bob1200xl Posted October 1, 2012 Share Posted October 1, 2012 Sure, I'll test it. (cycle counting? egad...) Is there an outline of what does work in the demo? No point in reporting 'bugs' that are just not implemented. Bob Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 1, 2012 Author Share Posted October 1, 2012 (edited) Sure, I'll test it. (cycle counting? egad...) Great. The renderer simply has to do three things: Cache the frame buffer contents where the pointer is to be rendered Draw the pointer Erase it again after the raster beam has had time to display it Steps 1 and 2 are done together in the same loop, to get the pointer on the screen ASAP. The whole DLI routine has to be as brief as possible so as not to tie up too much CPU time. It just so happens that - on a 6502 - once the pointer has been drawn, the raster beam is just on the point of catching up, so it's already time to erase the pointer. On a 7Mhz system, naturally step 3 is happening far too early. So, we might for example sample VCOUNT when the interrupt fires, and then ensure a certain number of scanlines have been drawn before allowing the erase routine to execute. Is there an outline of what does work in the demo? No point in reporting 'bugs' that are just not implemented. The following works: Window open, close, full, restore, resize, move, top Scroll bar drag, arrows, and "jump" Menus Menu options: File->Exit and View->Text / Icons Desktop icons: click to select BTW - which mouse are you using, Bob? Edited October 1, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
atari8warez Posted October 1, 2012 Share Posted October 1, 2012 Here are two bug-fixed builds, one for an ST mouse and one for an Amiga mouse: guiST_011012.zip guiAmi_011012.zip The window-over-menu-bar bug is fixed, and it's no longer possible to select desktop icons while the modal dialogue is on the screen. Revised project page: http://www.atari8.co.uk/gui/ Hi Jon, the window-over-menu bar problem is certainly fixed (that was quick by the way), but I have found some new windowing problems. In summary, when one drags a child-window all the way to the bottom-left corner of the Main Window, the child window disappears from the view and is no longer accessible. This does not happen with the bottom-right corner as the child window always remains partly visible there. Also after the above scenario, moving around a second window corrupts the display. Attached is a video of the problem. Ray guiST.zip Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 1, 2012 Author Share Posted October 1, 2012 (edited) Thanks Ray. That royally f**ks things up, no doubt about it. I didn't envisage windows being dragged entirely off the screen (of course this is all part of field testing!), so it's unsurprising that such circumstances create problems. This is similar to the bug w1k reported, so I'll look into it. There's a lot of clipping going on, and it's easy to end up with impossible conditions (this one probably being one clipping region being entirely outside of another, and the condition not being picked up). Bob: do you want to give this one a spin (ST mouse) and tell me if the mouse pointer is properly rendered yet at 7Mhz? gui65816.xex Once it works, a video will be required for proof. Edited October 1, 2012 by flashjazzcat 1 Quote Link to comment Share on other sites More sharing options...
Jacques Posted October 1, 2012 Share Posted October 1, 2012 The menu bar requires a left button click on it to stretch the pull-down menu. A different behaviour than on ST if I remember correctly. A feature, or sth that will change? It doesn't matter at this stage of development, just my curiosity... Quote Link to comment Share on other sites More sharing options...
popmilo Posted October 1, 2012 Share Posted October 1, 2012 Fantastic work Jon! This is a good day for Atari! Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 1, 2012 Author Share Posted October 1, 2012 The menu bar requires a left button click on it to stretch the pull-down menu. A different behaviour than on ST if I remember correctly. A feature, or sth that will change? It doesn't matter at this stage of development, just my curiosity... It will be made customisable to the user's preference. Fantastic work Jon! This is a good day for Atari! Those 16 colour PAL blended pics of yours have made my day. 1 Quote Link to comment Share on other sites More sharing options...
popmilo Posted October 1, 2012 Share Posted October 1, 2012 Those 16 colour PAL blended pics of yours have made my day. Thanks! Finally testing your gui (even if it is only on emulator) made my day These little Ataris are such a nice little machines to code for in 2012 ... 1 Quote Link to comment Share on other sites More sharing options...
+bob1200xl Posted October 1, 2012 Share Posted October 1, 2012 Cursor works, now. This will really be cool on a 14mhz machine. (are we going to get 640x400?) Short Video: GUItest2.WMV Bob 3 Quote Link to comment Share on other sites More sharing options...
+JAC! Posted October 1, 2012 Share Posted October 1, 2012 The redraw speed and logic (only certain parts redrawn) is a really amazing. Keep it going (and keep releasing stuff in way people can play with it, it's the only way to really test it :-) Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 1, 2012 Author Share Posted October 1, 2012 Thanks! Finally testing your gui (even if it is only on emulator) made my day These little Ataris are such a nice little machines to code for in 2012 ... Aren't they just. Drac030 said something the other day at AtariArea about the only problem being the lack of time to write all the software for the little Atari that one can dream up. I think that's true. Cursor works, now. This will really be cool on a 14mhz machine. (are we going to get 640x400?) Thanks Bob - that looks jaw-droppingly quick. Some more adjustment is required on the pointer renderer, however, since at times the tail of the arrow is chopped off. As for increased resolution: that would be VBXE territory, and I should be nearing state pension age by the time I've written that version. It's hardly surprising, though, that a very usable system could be created on accelerated / graphically enhanced machines. The redraw speed and logic (only certain parts redrawn) is a really amazing. Keep it going (and keep releasing stuff in way people can play with it, it's the only way to really test it :-) Thanks Jac! That's what's taken most of the time - creating a "smart" window manager. There's still plenty of scope for more redraw optimisation, too, and hopefully this will offset any unforeseen memory banking overheads, etc. As for releases - they'll be thin on the ground while I'm converting to ROM. Many important parts of the system architecture need to be implemented at this stage (RAM banking and windowing, resource management, etc), but hopefully it'll all be worth it. 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.