potatohead Posted August 3, 2013 Share Posted August 3, 2013 Yeah, just change the pointer. I totally agree with that. IMHO, the biggest value add there is consistency. Of course, the next question is where to draw the line? Is it a big deal on a few files? Probably. One file? Maybe. Disk access while something is running? Likely. Just musing here late on a Friday... Perhaps there will need to be options. For something that needs the I/O to work in a sane, timely way, indicate that's happening and shut the mouse down. For other things where the mouse might make sense, limit the I/O, and keep the mouse operable. Maybe a final one would be sort of a batch, "get it done as it can get done" option where the mouse gets priority. If the user is moving it around, stall the I/O, slipping it in whenever there is time, leaving it for the user to manage. Keep the drive spun up until it's all done. Users would quickly modify their mouse behavior in a fairly transparent way, but it would exercise the drive more. Maybe that's not a big deal, given flash / SD card type storage options. Could be useful for some application that can tolerate I/O delays. (don't ask me what that is, maybe somebody will write for it, if the option is there, that's all) Perhaps a puzzle game fetching assets might look like this as would a text editor that is operating on a very big file. Dang, I should boot some stuff on the Apple and examine how it's done there. Seems to me, single applications just block the mouse out during I/O. For the desktop stuff, there was text mode and graphics mode. I never did run any graphical desktop on an Apple, but I did the text mode stuff. Correction, I did use the one below. Did not remember until I saw the video. Most use was the text mode desktop, which was fast and used with Appleworks. What I can't recall is the mouse priority on something more complex than a quick blast to disk. Maybe it's always locked out and the users deal with it, or use keyboard more of the time. When I was using real Atari disks, I recall them being about 1/3 to maybe 1/2 the speeds I experienced on the Apple and CoCo computers. Both of those could go quite fast, depending. CoCo had the disk controller, and the Apple just had the CPU. Most of the time, those machines just got the I/O done quick and the user was back to doing whatever. In emulation, I've seen the Atari disks go a lot faster. How fast are they on real devices these days? I don't have an SIO device for the Atari, but I do have a SD cartridge for the CoCo 3, and it's much quicker than a real drive ever was, though I don't know about hard disks. Never ran one back in the day. The same is true for the Apple using that CFFA device. Maybe this isn't so big of a problem when not using real disk drives? Then again, depending on what people do, data might be a lot bigger, but it could be in chunks too... Quote Link to comment Share on other sites More sharing options...
fibrewire Posted August 3, 2013 Share Posted August 3, 2013 Well, here's how it looked on a 65C02 CPU Apple II with 128K banked ram http://www.youtube.com/watch?v=weFF8P6gyCE 2 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted August 3, 2013 Author Share Posted August 3, 2013 Yeah, just change the pointer. I totally agree with that. IMHO, the biggest value add there is consistency. Absolutely - and it's simpler. I don't much like the idea of different mouse behaviour depending on whether IO is parallel or serial, to be honest. Of course, the next question is where to draw the line? Is it a big deal on a few files? Probably. One file? Maybe. Disk access while something is running? Likely. Just musing here late on a Friday... Perhaps there will need to be options. For something that needs the I/O to work in a sane, timely way, indicate that's happening and shut the mouse down. For other things where the mouse might make sense, limit the I/O, and keep the mouse operable. Maybe a final one would be sort of a batch, "get it done as it can get done" option where the mouse gets priority. If the user is moving it around, stall the I/O, slipping it in whenever there is time, leaving it for the user to manage. Keep the drive spun up until it's all done. Users would quickly modify their mouse behavior in a fairly transparent way, but it would exercise the drive more. Maybe that's not a big deal, given flash / SD card type storage options. Could be useful for some application that can tolerate I/O delays. (don't ask me what that is, maybe somebody will write for it, if the option is there, that's all) Perhaps a puzzle game fetching assets might look like this as would a text editor that is operating on a very big file. Fact of the matter is, the mouse will disappear and motion sensitivity will be limited unless the SIO is carefully tailored, simple as that. It'll tend to happen during sector I/O, so a buffer read during a copy operation (if the SIO handler happens to shut off DLIs) will result in a lot of pointer flicker, and the Pokey timer which manages the mouse sampling will likely stop working until we come back out of the CIO call entirely. Whether this is aesthetically or practically unacceptable is another matter. If we just left it to chance, you'd see none of these negative things during parallel IO. However, if we go for the "consistent" approach of shutting down the mouse during IO, at least everything will look neat. My feeling now is to forget about it and see what's best once we actually have disk IO going on. Well, here's how it looked on a 65C02 CPU Apple II with 128K banked ram Well, I watched that and it's hard to differentiate between mouse flickering caused by I/O and flickering caused by the need to turn off the pointer every time something's rendered on the desktop. Our GUI used to work that way until the DLI-based renderer was worked out, and this completely banished mouse flickering outside the realms of serial IO. It may be that the Apple doesn't have a problem running the mouse during IO, but it certainly turns off the pointer during every screen redraw, and we see a lot of that here. Quote Link to comment Share on other sites More sharing options...
atarixle Posted August 3, 2013 Share Posted August 3, 2013 WOW I never knew that Apple made an 8 Bit Desktop for a 6502 Computer! Is this more than just a nice File Manager? Or is there a whole Desktop just like -let's say- GEM (imagined that was 8 bit, which it was not of course)? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted August 3, 2013 Author Share Posted August 3, 2013 Yes they did it, but sadly no source code available. Quote Link to comment Share on other sites More sharing options...
potatohead Posted August 4, 2013 Share Posted August 4, 2013 Nice video. Are you running that on a CFFA? And is that Apple stock, or sped up? Came back here to report I don't have a disk setup like that anymore. Never had one that good actually. Would love to get a disk image to show off to a few people.... hint, hint. Yes, it looks to me like a fairly lean draw system. Get it done quick and only draw what is needed. The addressing on the high resolution or double high resolution screens didn't exactly make for high throughput. The signal is there to sync the mouse up, but no standard interrupts, meaning one needs a card, a hack, or poll for it, so they don't. Lots of stuff on the Apple is that way due to the simple computer design in that respect. Your GUI project is excellent. Mouse Desk was one I actually used for a time back in the day. Fetching apps was a bit slower than that video, and I can't really remember the draw speeds. So far, the Atari is posting up nicely. Generally agreed. After looking at the "draw it when possible" method, I think it's cleaner as you envision it. Quote Link to comment Share on other sites More sharing options...
AtariGeezer Posted August 4, 2013 Share Posted August 4, 2013 Would love to get a disk image to show off to a few people.... hint, hint. Found some data here: http://www.chebucto.ns.ca/Services/PDA/AppleIIMiscellaneous.shtml Now to figure out how to get it to the //c or //e Quote Link to comment Share on other sites More sharing options...
potatohead Posted August 4, 2013 Share Posted August 4, 2013 There it is. Just a little work from there setting up other apps. Thanks for finding that. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted August 4, 2013 Author Share Posted August 4, 2013 I'd like to see a bit more of "Beagle Write" in action, since we just got a glimpse of the (quite ponderous) screen update there. Getting a lot of text on the screen is generally the bottleneck with a GUI running on a slow system, and that's why we spent a few months on optimising that stuff. I believe one of the Apple programmers came up with a fast way of rendering text on the screen using look up tables (for bit-shifts), which is exactly the technique we use. So - if the Apple is polling the mouse and the pointer rendering isn't interrupt driven, what's the consensus on mouse activity during IO on that system? As I said: it's definitely using the ST-like method of turning the pointer off every time something's drawn on the screen. Quote Link to comment Share on other sites More sharing options...
potatohead Posted August 4, 2013 Share Posted August 4, 2013 Somebody else will have to comment on the mouse for sure. Apple generally did not employ interrupts, so my guess is polling. I think it is skipping draws on most activity. Modal. If there is a screen draw that overlaps the mouse, it just gets drawn over, then replaced last. That means typing with a significant font would blow it away too. Of course, the user is modal too. One is either using the mouse to pick or do, or one is typing, or one is waiting. Seems to me the mouse is just last draw on the draw stack, and there is no drawing during I/O. The Apple has its low level RWTS read write track sector in RAM, and it is nearly all CPU, but for a bit of clever discrete logic on the disk controller. This brought the Apple a very fast disk for it's time, as well as higher capacities and various formats, but it came at the cost of doing essentially nothing during I/O. About the best possible would be to cram something in between sectors slowing things down considerably. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted August 4, 2013 Author Share Posted August 4, 2013 Mousedesk is physically removing the pointer from the screen before any redraw, regardless of whether the drawn object intersects with the mouse or not. Have a look at the pointer when the user is typing into a text box on a far removed region of the screen. This is exactly the way I was doing things originally, because otherwise (if you just let intersecting stuff draw over the mouse), you'll tend to get problems when the mouse handler restores what it believes to be the underlying image (which may have changed in the intervening time). What I also did, though, was have a slow masked drawing routine which would actually draw around the pointer (which still had to be frozen for the duration of the drawing). I used this for stuff like highlighting menu items, and this really cut down on the amount of flicker. At the end of the day, though, the simulated hardware mouse pointer did away with all this nonsense, at the price of a few thousand machine cycles per second. Quote Link to comment Share on other sites More sharing options...
potatohead Posted August 4, 2013 Share Posted August 4, 2013 You are right about that.. Funny, I would glance at various parts of the screen and would miss it. Another look shows that when I just focus on the screen rather than details. Guess that comes with your critical eye on this project. In any case, no draw on I/O that I could see. Mostly, no draw for any reason on the Apple, LOL Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted August 4, 2013 Author Share Posted August 4, 2013 Heh - I wouldn't have had a clue what I was looking at three years ago... it's only through having implemented some of this stuff myself that I can feign special insight now. Anyway: we should be grateful that we have a sufficiently elaborate NMI / IRQ architecture on the A8 to allow cool stuff like the simulated hardware mouse pointer and interrupt-driven sampling. OK - onwards and upwards... to the keyboard I go. Quote Link to comment Share on other sites More sharing options...
potatohead Posted August 4, 2013 Share Posted August 4, 2013 Totally. It is worth the lark to see what was done. Yeah, having the interrupt there makes a world of difference. A quick CPU doesn't hurt either. What strikes me is the good graphic design. That odd pixel ratio on the Apple is ugly, but it didn't have to be that ugly. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted August 4, 2013 Author Share Posted August 4, 2013 Re: graphic design - I was looking through the early pages of this topic yesterday, from the days before MrFish came on board. The GUI got pretty after he arrived. Quote Link to comment Share on other sites More sharing options...
potatohead Posted August 4, 2013 Share Posted August 4, 2013 Yes. Very nicely done. One of my favorite parts of the development to watch. Quote Link to comment Share on other sites More sharing options...
+MrFish Posted August 4, 2013 Share Posted August 4, 2013 I don't really want to show too many graphics outside of them appearing in actual executable or video demonstrations. But I'll let everyone have a taste of what I did, mostly, about a year and a half ago or so. There are somewhere over 1,000 icons in the current collection, which includes a copy for each icon design at 16 x 16 and 12 x 12 pixels, so somewhere over 500 unique file icon pairs. Each icon is displayed as such here too. The programming source file icons have several different styles that will be selectable, and there are of course more languages covered in the full collection. This is not to say that there is such a heavy focus on programming source file icons, as there will be variations for as many different types of icons as I have time or interest to create, or Jon or anyone else reasonably requests. There are a lot of variations already created, which are not shown here obviously. The collection continues to grow as I have time. 4 Quote Link to comment Share on other sites More sharing options...
TheNameOfTheGame Posted August 5, 2013 Share Posted August 5, 2013 Nice! You did great job with those. It will be fun to see these show up in the program. Quote Link to comment Share on other sites More sharing options...
+MrFish Posted August 5, 2013 Share Posted August 5, 2013 Nice! You did great job with those. It will be fun to see these show up in the program. Thanks. I'm looking forward to it too. Jon has quite a quite of few of these at his disposal right now, but I think he's been holding back a little. Once we get to the stage of having a working file-manager, the fun with icons should begin though. Quote Link to comment Share on other sites More sharing options...
Subby Posted August 5, 2013 Share Posted August 5, 2013 I wish I were an artiste. I'd love to have this as a Windows 7 theme. It'd drive my boss nuts too. Quote Link to comment Share on other sites More sharing options...
fibrewire Posted August 5, 2013 Share Posted August 5, 2013 There is a download for the BeagleWrite editor at that link AtariGeezer posted http://www.chebucto.ns.ca/Services/PDA/AppleIIEditors.shtml Someone familiar with Apple II could load it in an emulator and post a video... Quote Link to comment Share on other sites More sharing options...
+MrFish Posted August 5, 2013 Share Posted August 5, 2013 (edited) I wish I were an artiste. I'd love to have this as a Windows 7 theme. It'd drive my boss nuts too. Haha... well, you'd definitely have more real-estate to create an icon with in Windows. On the older Mac OS, even when they had millions of colors available, you could still run the system in 1-Bit mode. I used to use it and grayscale mode sometimes, when I was spending a lot of consecutive hours on the machine, because it was easier on the eyes than the high-color modes. Edited August 5, 2013 by MrFish Quote Link to comment Share on other sites More sharing options...
potatohead Posted August 5, 2013 Share Posted August 5, 2013 If the image works, I'll do it later this evening. I'm home now where the Apple is. No big deal to put it on a USB and run through it. Quote Link to comment Share on other sites More sharing options...
potatohead Posted August 5, 2013 Share Posted August 5, 2013 Scratch that. Seems my Apple is pissy. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted August 5, 2013 Author Share Posted August 5, 2013 Once we get to the stage of having a working file-manager, the fun with icons should begin though. Absolutely. Imagine the scrolling list of all these icons when defining a new shortcut... worth the wait, I should think. Thanks for posting these! 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.