flashjazzcat Posted November 7, 2013 Author Share Posted November 7, 2013 optmization cool I like that seems it can be even faster What about a 65816 version in the future ? Yeah - it's always the way with new code: most important thing is to get it working and bug-free... then comes the optimisation. I thought of lots of obvious things since I uploaded the vid, including inlining clipping stuff. Plenty of slack there, and there's already a scheduler interrupt firing 50 times a second in that video, together with the mouse sampler IRQ at 1,000 Hz. It's taking so long just to develop the 6502 version that I can't say a 65816 build is something I'd undertake till... well... somewhat later in life, if at all. The main objective is to see what can be done with a stock CPU and a minimum of 64KB or 128KB. There's application development after that, which should occupy a lot of my hobby time for some years. That said, I have taken care to ensure that the GUI will run on a 65816 accelerator, although even that seems to me to defeat the object somehow. 1 Quote Link to comment Share on other sites More sharing options...
JamesD Posted November 7, 2013 Share Posted November 7, 2013 One of the best things about the 65816 is 6502 code pretty much runs as is unless you use illegal instructions.You could probably optimize some stack operations and use 16 (24) bit index registers so you don't have to use page zero addressing. And you could switch some other stuff to use the 16 bit accumulator or B accumulator.That wouldn't be that difficult.Memory management would be what is significantly different.If you program for the 65802 though, you wouldn't have to worry about that and apps could manage more memory on their own. Quote Link to comment Share on other sites More sharing options...
fibrewire Posted November 7, 2013 Share Posted November 7, 2013 (edited) Are there minimum cycle counts to maintain interface responsiveness, and does perception of responsiveness relate to the refresh rate of the screen? For example, what is the performance impact of the scheduler running at 10Hz vs 100Hz? Also what's the benefit of the mouse pointer at 1000Hz vs double the refresh @ 100Hz? I want to better understand different polling routines and their relationship to the GUI and what does each cost in CPU cycles. Edited November 7, 2013 by fibrewire Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 7, 2013 Author Share Posted November 7, 2013 (edited) Are there minimum cycle counts to maintain interface responsiveness, and does perception of responsiveness relate to the refresh rate of the screen? For example, what is the performance impact of the scheduler running at 10Hz vs 100Hz? Also what's the benefit of the mouse pointer at 1000Hz vs double the refresh @ 100Hz? I want to better understand the relationship of simple and complex polling routines and what they cost in CPU cycles. It's less a mathematical thing than a "feel" thing. Responsiveness to me is how long it takes before the is GUI ready to respond to user actions. If the windows take too long to redraw, the user is already trying to click on something else, and so perceives lag. Redraws can't be instantaneous, so the objective is to make them fast enough and unobtrusive enough that the user appreciates that the system is busy without becoming frustrated by lag. The performance impact of running the scheduler at 10Hz would be that the renders would get a little more CPU time (though not an appreciably greater amount, since the scheduler IRQ is brief if there's no context switch). 10Hz is impracticably slow for a scheduler, though: it would negatively impact the system in other ways (tasks would be slow to respond since the context switches weren't happening fast enough). Regarding refresh: there's no "frame rate" as such. It's not an immediate-mode GUI. Stuff takes as long to draw as it takes to draw... you see the updates real-time. Mouse sampling is 1KHz or thereabouts because that's the lowest frequency (coupled with acceleration) which works reliably and accurately. If the mouse isn't moving, the IRQ is cheap (especially with the custom IRQ handler): .local mouse ; pokey timer interrupt-driven mouse sampler lda $d300 cmp old_mouse bne Moved pla rti Moved ... Edited November 7, 2013 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
JamesD Posted November 7, 2013 Share Posted November 7, 2013 I believe 1KHz is a bit arbitrary and could be played with but a GUI doesn't necessarily have to sync to the refresh rate of the screen. It's not like a game where you worry about the screen memory being completely updated before the hardware refreshes the screen. The desktop/window redraws can take place at any time. The mouse pointer redraw would not have to be more than once every frame though. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 7, 2013 Author Share Posted November 7, 2013 I believe 1KHz is a bit arbitrary and could be played with but a GUI doesn't necessarily have to sync to the refresh rate of the screen. It's not like a game where you worry about the screen memory being completely updated before the hardware refreshes the screen. The desktop/window redraws can take place at any time. The mouse pointer redraw would not have to be more than once every frame though. 1KHz is not arbitrary. It took months of experimentation to arrive at that sample rate. Much slower, and you get roll-back when moving the mouse at speed. The mouse pointer is drawn once per frame. Quote Link to comment Share on other sites More sharing options...
Joey Z Posted November 8, 2013 Share Posted November 8, 2013 1KHz is not arbitrary. It took months of experimentation to arrive at that sample rate. Much slower, and you get roll-back when moving the mouse at speed. The mouse pointer is drawn once per frame. I think the 1 KHz rate is being misunderstood here as redraw for the pointer, but 1KHz is not the rate of redraws, it is how many times we look at the quadrature encoder of the mouse to sample the current state and detect if it moved. IIRC, the mouse pointer is drawn in a DLI (or otherwise related to a DLI) and that happens once every frame (correct me if i am wrong FJC). 1 Quote Link to comment Share on other sites More sharing options...
+wood_jl Posted November 8, 2013 Share Posted November 8, 2013 Wow, I missed some of the thread. You're an A8 wizard; talk about professionalism!. Looking forward to this in the future. 2 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 8, 2013 Author Share Posted November 8, 2013 (correct me if i am wrong FJC). Correct in every detail. Quote Link to comment Share on other sites More sharing options...
fibrewire Posted November 8, 2013 Share Posted November 8, 2013 (edited) 1KHz is not arbitrary. It took months of experimentation to arrive at that sample rate. Much slower, and you get roll-back when moving the mouse at speed. The mouse pointer is drawn once per frame. Forgot about that annoying rollback issue. If 1kHz is what the mouse uses in the GUI now, then it's perfect. It's taken patience, persistence, and many man hours to get this GUI to the excellent benchmark it is currently at. I hope not only for good health and happiness for FJC, but also that we get to use this system in the near future. Thanks Jon! Edited November 8, 2013 by fibrewire Quote Link to comment Share on other sites More sharing options...
JamesD Posted November 8, 2013 Share Posted November 8, 2013 1KHz is not arbitrary. It took months of experimentation to arrive at that sample rate. Much slower, and you get roll-back when moving the mouse at speed. The mouse pointer is drawn once per frame. Months? Try googling "mouse polling rate". Standard rates are 125Hz, 250Hz, 500Hz and 1000Hz. And it sounds like it may depend on the mouse which to use but I only spent about 5 minutes looking it up. Quote Link to comment Share on other sites More sharing options...
TheNameOfTheGame Posted November 8, 2013 Share Posted November 8, 2013 Months? Try googling "mouse polling rate". Standard rates are 125Hz, 250Hz, 500Hz and 1000Hz. And it sounds like it may depend on the mouse which to use but I only spent about 5 minutes looking it up. Dude what are you trying to prove? You spent 5 minutes looking this up but 1 minute sounding like a dick. FJC is doing amazing things here. Not sure what you are trying to accomplish with this post. Quote Link to comment Share on other sites More sharing options...
JamesD Posted November 8, 2013 Share Posted November 8, 2013 Dude what are you trying to prove? You spent 5 minutes looking this up but 1 minute sounding like a dick. FJC is doing amazing things here. Not sure what you are trying to accomplish with this post. My apologies, The mouse he's using is probably a 1000Hz mouse and why he gets rollback if he doesn't poll it at that speed. I don't know if a 500Hz mouse would change anything because I only spent a few minutes researching it and that may depend on how individual mice deal with fast movements anyway. But, the page I looked at still referred to 500Hz as a gaming mouse speed though so it *shouldn't* be too sluggish if you could hook one up. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 8, 2013 Author Share Posted November 8, 2013 (edited) Months? Try googling "mouse polling rate". Standard rates are 125Hz, 250Hz, 500Hz and 1000Hz. And it sounds like it may depend on the mouse which to use but I only spent about 5 minutes looking it up. Heh - Google is admittedly much faster than MADS and Eclipse. Right here on this thread we rehashed the driver code until a decent sampling rate was possible without consuming too much CPU time. 1KHz is no good if it's tying up all the processing time, "standard" speed or not. On the other hand, if 1000Hz is a standard polling rate (as you've written), how can it also be "arbitrary"? Here's a forum discussion which advocates a 1KHz sampling rate for an Amiga mouse, and here is CPC wiki entry which suggests polling an ST mouse at at least 500Hz. My experiments demonstrated that on real hardware, with a standard ST or Amiga mouse, somewhere towards the 1KHz end provides the best compromise. But I was still getting reports of roll-back (when the mouse direction becomes ambiguous because readings have been missed) until I added in ballistics, and now it's really smooth (because the acceleration tends to prevent the user moving the mouse too fast). I haven't done a precise count of how many cycles the mouse IRQ consumes when the mouse is idle, but if we blew say 40,000 cycles per second polling the mouse, I think that's reasonable in order to ensure smooth movement. A lot of A8 mouse drivers (such as Multi-Mouse) poll the mouse in a closed loop, so the machine can't do anything else except service interrupts until some kind of exit condition is met. I wonder what the sample rate is in a closed loop? 20KHz? 30KHz? No good for our purposes, though. The mouse he's using is probably a 1000Hz mouse and why he gets rollback if he doesn't poll it at that speed. I don't know if a 500Hz mouse would change anything because I only spent a few minutes researching it and that may depend on how individual mice deal with fast movements anyway. But, the page I looked at still referred to 500Hz as a gaming mouse speed though so it *shouldn't* be too sluggish if you could hook one up. Standard ST and Amiga mice. No idea what the Hz rating is but as I say, the optimal sample rate was arrived at through experimentation on the target hardware. Not that I want to constantly revisit this subject (since there are many more pressing matters which need addressing in order to advance the project), but the only additional optimisation I can think of is to drop the sample rate after a period of mouse inactivity - say 20 IRQ ticks. Then, while sampling at a low frequency, boost the sample rate back up again as soon as a change is detected. Regardless: this won't account for massive increases in rendering speed, and it would only be of any benefit if you didn't move the mouse while the screen was being redrawn. I'm really more concerned with stuff like which relocatable binary format to use, since that will become an issue before too long. I PM'd tebe about a couple of issues with the capabilities of MADS' own proprietary format six weeks ago, but haven't received a reply. While we banter about other stuff, and this kind of thing goes unaddressed, potential obstacles are stored up for a later day... Edited November 8, 2013 by flashjazzcat 1 Quote Link to comment Share on other sites More sharing options...
danwinslow Posted November 8, 2013 Share Posted November 8, 2013 Jon - You might consider an early 'developer' release of some sort with a provisional API layer in place...that way we could start on some app development and hopefully then you could release the finished v1.0 with some user-written apps and sample code available. 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 8, 2013 Author Share Posted November 8, 2013 Jon - You might consider an early 'developer' release of some sort with a provisional API layer in place... Sounds sensible, although we're months away even from that stage yet. Quote Link to comment Share on other sites More sharing options...
JamesD Posted November 8, 2013 Share Posted November 8, 2013 Heh - Google is admittedly much faster than MADS and Eclipse. Right here on this thread we rehashed the driver code until a decent sampling rate was possible without consuming too much CPU time. 1KHz is no good if it's tying up all the processing time, "standard" speed or not. On the other hand, if 1000Hz is a standard polling rate (as you've written), how can it also be "arbitrary"? .... Standard ST and Amiga mice. No idea what the Hz rating is but as I say, the optimal sample rate was arrived at through experimentation on the target hardware. Not that I want to constantly revisit this subject (since there are many more pressing matters which need addressing in order to advance the project), but the only additional optimisation I can think of is to drop the sample rate after a period of mouse inactivity - say 20 IRQ ticks. Then, while sampling at a low frequency, boost the sample rate back up again as soon as a change is detected. Regardless: this won't account for massive increases in rendering speed, and it would only be of any benefit if you didn't move the mouse while the screen was being redrawn. I'm really more concerned with stuff like which relocatable binary format to use, since that will become an issue before too long. I PM'd tebe about a couple of issues with the capabilities of MADS' own proprietary format six weeks ago, but haven't received a reply. While we banter about other stuff, and this kind of thing goes unaddressed, potential obstacles are stored up for a later day... ST and Amiga mice may be different than PC mice but I have to think it would be cheaper to use the same parts used on PC mice. Once you get something out there maybe others can play with different mice. Maybe just offer a configuration for this somewhere since there are only 4 settings. FWIW, I wouldn't even know where to look to find a mouse designed to work at a different speed. I agree that your time is best spent somewhere else at the moment. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 8, 2013 Author Share Posted November 8, 2013 ST and Amiga mice may be different than PC mice but I have to think it would be cheaper to use the same parts used on PC mice. Once you get something out there maybe others can play with different mice. Maybe just offer a configuration for this somewhere since there are only 4 settings. FWIW, I wouldn't even know where to look to find a mouse designed to work at a different speed. I agree that your time is best spent somewhere else at the moment. Drivers are the answer. Just get rid of the default mouse driver and replace it with one which supports the fancy hardware. Quote Link to comment Share on other sites More sharing options...
fibrewire Posted November 9, 2013 Share Posted November 9, 2013 Drivers are the answer. Just get rid of the default mouse driver and replace it with one which supports the fancy hardware. Have you given any thought on how your driver model will look? Do you think it would hurt to practice with the Apple /// SOS driver manuals? Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted November 9, 2013 Share Posted November 9, 2013 I'm really more concerned with stuff like which relocatable binary format to use, since that will become an issue before too long. You may already know this format too (?): http://www.6502.org/users/andre/o65/fileformat.html Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 9, 2013 Author Share Posted November 9, 2013 (edited) You may already know this format too (?): http://www.6502.org/users/andre/o65/fileformat.html Yes indeed, but I really prefer to use MADS for development, and it'll be easier if I don't have to start using a different (and possibly deprecated) assembler. Edited November 9, 2013 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 9, 2013 Author Share Posted November 9, 2013 Have you given any thought on how your driver model will look? Do you think it would hurt to practice with the Apple /// SOS driver manuals? Probably just hooks or tables: the pointer driver, for example, just needs to define the polling routine (which should also update the relative X,Y coordinates, which are added to the absolute coordinates by the stage 2 VBL), the frequency of the polling, and some trigger code. Symbols are nice too (as found in SDX): we can have a global symbol "poll" which just points to an RTS until a driver updates the poll vector. Dunno about "practicing" (practising?): I've had a look at the docs and I'll "adapt" any relevant ideas. Quote Link to comment Share on other sites More sharing options...
Matej Posted November 9, 2013 Share Posted November 9, 2013 (edited) Will be possible to have there monochrome/charset games too? Something like this but more simple? Will be there enough RAM? Games can be just something like minigames {4kb, 8kb}... Edited November 9, 2013 by Matej Quote Link to comment Share on other sites More sharing options...
kskunk Posted November 10, 2013 Share Posted November 10, 2013 (edited) ST and Amiga mice may be different than PC mice but I have to think it would be cheaper to use the same parts used on PC mice. Once you get something out there maybe others can play with different mice. Maybe just offer a configuration for this somewhere since there are only 4 settings PC mice have a dedicated CPU inside. For (old) PC ball mice, the mouse's internal CPU accumulates motion at rates above 10KHz, but then sends the summarized data to the PC at a much lower rate. ST and Amiga mice do not have an internal CPU, so the Atari must monitor and accumulate the data itself. That's why a PC polling rate of 62.5Hz (processed updates) is not the same as an ST polling rate of 1KHz (raw updates). There is no simple way to adapt a modern PC USB mouse to work on an A8. However, old PS/2 mice can be adapted. Some time ago in this thread, I described a PS/2 mouse driver for FJC's system. I would enjoy working on that. A PS/2 mouse could be adapted to the Atari by simply rewiring the plug, and with the right driver, a lower (<=60Hz) polling interval is possible, along with less CPU utilization (not 16x less, maybe half). - KS Edited November 10, 2013 by kskunk 2 Quote Link to comment Share on other sites More sharing options...
NRV Posted November 10, 2013 Share Posted November 10, 2013 PC mice have a dedicated CPU inside. For (old) PC ball mice, the mouse's internal CPU accumulates motion at rates above 10KHz, but then sends the summarized data to the PC at a much lower rate. ST and Amiga mice do not have an internal CPU, so the Atari must monitor and accumulate the data itself. That's why a PC polling rate of 62.5Hz (processed updates) is not the same as an ST polling rate of 1KHz (raw updates). There is no simple way to adapt a modern PC USB mouse to work on an A8. However, old PS/2 mice can be adapted. Some time ago in this thread, I described a PS/2 mouse driver for FJC's system. I would enjoy working on that. A PS/2 mouse could be adapted to the Atari by simply rewiring the plug, and with the right driver, a lower (<=60Hz) polling interval is possible, along with less CPU utilization (not 16x less, maybe half). - KS Yep, the only thing that I had read about that would be this: http://atariage.com/forums/topic/134949-advance-orders-for-cmi08-ps2-mouse-interface/?do=findComment&comment=1919221 Wasn't a cartridge with a usb port also? 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.