Gunstar Posted September 27, 2018 Share Posted September 27, 2018 (edited) I better start making a basics list for starting up my system under different circumstances for when I forget it all...hold OPTION for disks...hold START&OPTION for tapes, Hold SELECT to change OS, Hold SELECT&OPTION for APE remote control...etc., etc...I'll make a copy for myself when I send one along to my old friend Danny "Bugman" P. with his upgraded 800XL and SDrive MAX for Christmas...alone in the Atari world but for me as his conduit...he just doesn't get into forums for some reason, or general on-line socialization...6' 5" 60 year old black man...nicest guy ever always with a huge smile...been an Atari fan since the beginning...best guy in the world since he gave me his Falcon... Edited September 27, 2018 by Gunstar 5 Quote Link to comment Share on other sites More sharing options...
+mytek Posted September 27, 2018 Share Posted September 27, 2018 Jon you definitely have no reason to be apologetic. It would be different if you took someone's money and they were expecting you to be on a schedule to completion. But that's certainly not the case here. The GOS project is more like a guy that tinkers in his garage on an old classic car, slowly but surely making it a little better and nicer over a period of years. And on occasion we come over to take it for a test drive, marveling over some recent improvement. The fact is that even in it's present state of incompleteness, it serves to remind us of what the A8 can and would have been able to do with a proper GUI. And just seeing and playing around with the demo, reveals that awesome potential lurking beneath the hood. 6 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 27, 2018 Author Share Posted September 27, 2018 I remember when my PC died in 2012 or so, there was a tremendous rallying round of donations on this forum for the specific purpose of getting me back up and running again. This enabled me to replace the motherboard, CPU and RAM, with money to spare. I'll never forget that (although that PC's now long gone), and it's just one of many reasons why I'm so ardently loyal to AtariAge and the community. Subsequent to this, the aforementioned feature-creep saw the introduction of preemptive multitasking and other unexpected developments, so it's hoped that no-one who donated to the motherboard fund is now seething with regret and bitterness. In my experience, it's the most generous and supportive people who spend the least time complaining about projects, interestingly enough. In any case, I can think of far worse complaints than 'Why is it not done yet?'. 8 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted September 27, 2018 Share Posted September 27, 2018 I'm getting curious as to the average age here on AA 8-bit forum, what the percentage is above and below the 50 mark, etc. I just turned 50 myself last month...man time flies...17 when I got my first Atari 8-bit, 27 when I got my Jaguar...37 when I got my first Falcon and Amiga 2000... Just turned 43, got my 400 in 82, Jaguar in 94, and believe it or not, just purchased my 1st Amiga (a 2000) but it has not yet arrived 2 Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted September 27, 2018 Share Posted September 27, 2018 I'm getting curious as to the average age here on AA 8-bit forum, what the percentage is above and below the 50 mark, etc. I just turned 50 myself last month...man time flies...17 when I got my first Atari 8-bit, 27 when I got my Jaguar...37 when I got my first Falcon and Amiga 2000... I turned 50 in July. Got my first Atari computer (the 400) in the fall of 1982 when I was 14, upgraded to the 800 late the next summer ('83) when I was 15. My brain still feels pretty darn sharp (thank $DEITY!) but that can't be said about the damned knees. And sometimes, my back. Ugh. 2 Quote Link to comment Share on other sites More sharing options...
Gunstar Posted September 28, 2018 Share Posted September 28, 2018 (edited) I turned 50 in July. Got my first Atari computer (the 400) in the fall of 1982 when I was 14, upgraded to the 800 late the next summer ('83) when I was 15. My brain still feels pretty darn sharp (thank $DEITY!) but that can't be said about the damned knees. And sometimes, my back. Ugh. I got my first computer at 14 in '82, but it was a Timex/Sinclair 1000 with the 16K expansion. I upgraded at 17 in '85 to a 130XE. Of course I had the 2600 and Pong before all that. Used Apples at school and was saving for an Apple IIc when I found the 128K 130XE for a quarter the price, half after the disk drive. But if I'd known about memory upgrades for XL's back then, I'd have gone with an 800XL that was on sale for $99 that the salesman was pushing on me (he mentioned a better keyboard, but 128K blinded me to all else at the time) but I insisted on a 128K computer. For like $189 or $199...something like that. Got it at Service Merchandise. then I went over to Toys R Us,and got an after-market tape deck for $25 and a few games. The 1050 drive I got about 6 months later. Edited September 28, 2018 by Gunstar Quote Link to comment Share on other sites More sharing options...
Kernal Posted September 30, 2018 Share Posted September 30, 2018 (edited) Ive had an 800xl since early 85 passed down to me by my uncle john and his brother in law mark, this original 800xl was gifted to kurt cobains daughterr frances bean cobain in 2011, and is currently in the possesion of eric erlandson I have 2 1050 drives, a 850, and the cassette drive and ape sio2pc i have 1 800xl with vbxe and stereo pokey and u1mb and a stock 130xe with svideo upgrade (i want to add a rapidus and u1mb to this.) Edited September 30, 2018 by Kernal 5 Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted October 1, 2018 Share Posted October 1, 2018 I turned 50 in March, got my first computer in 83 (an 800XL) switched to an ST, then 3 various Amigas before Moving to Windows 95 on a 486sx25. Since then I've moved to linux and now macOS. I've been working in IT since 88, first in operations on a PDP11 then developing on various VAX minis and Wintel machines before switching to operations on vm and san. Came back to the Atari 8Bits last year when I got another 800xl, since then I've made a 1088XEL and use that as my 'main' Atari (I made a XEL-CF3 today!). My mind is still sharp but getting pretty cynical, my body is getting pretty squidgy and achy, my back is wrecked from decades hunched over keyboards, I've had carpel tunnel surgery in both hands, my eyes are failing. 3 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 28, 2018 Author Share Posted December 28, 2018 (edited) Thanks to Hias' comments in this thread, I was inspired to revisit the GOS mouse driver last night and make some experimental changes which should allow for reasonably consistent pointer operation during IO. There were a few big obstacles in the way keeping the mouse running in the middle of IO: SIO transfers - especially at low divisors - don't leave much CPU time for interrupt-based processes. Hias' own high-speed SIO driver disables IRQs entirely (it polls the IRQ status register) and the U1MB implementation of his code runs a minimal VBI at divisors 6 and below. NMIs are not explicitly disabled, however; while it's possible to run DLIs, they need to be short. The GOS - while it will provide its own SIO driver (probably Hias' code) for stand-alone environments - has no way of knowing whether PBI HDD drivers have intervened in an SIO call, or whether a given volume resides on a serial device or a fast hard disk partition where timing is not critical. So while we could happily run a full complement of interrupts were we certain we were dealing with IDE storage the entire time, those same heavy interrupts would cause big problems with reasonably fast serial IO. The mouse driver was running on a 1KHz POKEY timer IRQ, and since Hias' driver disables IRQs, mouse sampling would naturally stop dead for the entire duration of an SIO transfer when using his driver. Moreover, it might be better to keep any process designed to run during serial IO out of the way of POKEY timers altogether. I'd already noticed some years ago that Diamond GOS sampled the mouse by running a series of DLIs at regular intervals down the height of the screen. My GOS in fact used the same method initially, but I moved things over to a POKEY timer interrupt after implementing the hi-res 'soft sprite' mouse pointer, which relies on a precisely positioned NMI dynamically travelling up and down the display list. In any case: the GOS's POKEY timer-based driver hands the VBI coordinate changes collected over the course of each frame, while Diamond's DLI implementation buffers raw port readings which are processed by the VBI once per frame. There didn't seem to be much in it between the two methods until the matter of SIO came up. Hias suggested the exact same method used by Diamond (use DLIs to build a ring buffer of raw mouse port readings), but this was clearly going to be fiddly owing to the aforementioned roaming DLI which renders the mouse pointer. Nevertheless I cooked something up using look-up tables, and it works. There's a DLI on every tenth line of the screen, and the VBI dynamically clears a few of them at the position surrounding the 'soft-sprite' pointer so the longer, blocking interrupt doesn't cause problems. When the mouse moves, the port-reading DLIs are reinstated and and render DLI is positioned some place else. A counter is used so that the DLI knows when to jump into the mouse rendering section. The rest of the time, it just reads PORTA and stores the value in the buffer. At the end of each frame, the VBI runs through seventeen or so PORTA readings in the buffer, updates the mouse pointer coordinates, and does all the display list adjustments. The plan regarding IO is to draw a static mouse pointer on the screen and disable all but the short, port-reading DLI during critical sections. When the critical section is complete, the VBI will re-enable dynamic, DLI-based pointer rendering and update the pointer coordinates using all the buffered port readings. This will probably be staggered a little (i.e. a limit will be placed on how many readings from the queue are processed per frame), but eventually (i.e. in half a dozen frames) the pointer will catch up with the user's mouse input. A potential problem is an extended critical period caused by a very slow serial transfer or a sustained number of sector transfers which results in the VBI not getting a chance to run before the mouse buffer (which is only 256 bytes long) fills up. The latter problem is easily solved, at least, since this is a multi-tasking system. The IO process simply needs to yield the CPU after every sector transfer, which will give the system a chance to process the mouse buffer and catch up. A very lengthy sector seek, meanwhile, will probably result in buffer wrap-around, but this is all assuming that the user is frantically moving the mouse during sector IO. One optimisation which saves buffer space is that mouse readings are only added to the buffer when the mouse has actually moved since the last PORTA poll. That's the theory, anyway. I won't know how well this works until I test some burst IO with various serial devices and at various speeds. I expect this will act somewhat like a type-ahead keyboard buffer. The mouse pointer - though still visible - will move less smoothly since it will be rooted to the spot during critical sections, but the pointer will quickly seem to 'catch up' with movement of the mouse. It may prove unusable, on the other hand, and the better solution may be to replace the pointer with a static egg-timer during all critical sections. But it would be nice to be able to run background processes which interact with disk drives without said processes causing too much disruption to the UI. In any case: I suspect the overhead of polling the mouse using DLIs is lower than that of an IRQ (although the GOS's IRQ handler is already optimised for timer 1 dispatch). It's an interesting subject and intriguing enough that it's got me knee-deep in GOS source code again. Edited December 28, 2018 by flashjazzcat 9 Quote Link to comment Share on other sites More sharing options...
TheNameOfTheGame Posted December 28, 2018 Share Posted December 28, 2018 Nice to see you dig back into the GOS source again! Been hoping you'd get the itch to get a it again. 3 Quote Link to comment Share on other sites More sharing options...
+JAC! Posted December 29, 2018 Share Posted December 29, 2018 Hi Jon, sounds great. I checked the code in the demo download: It will mean to have more DLIs, speed-up processing of the sampling DLI can be important to not interfere with the IRQ., You could adapt the NMI routine to only do the minimum for DLIs. Currently, it saves all registers, does CLD and a JMP for DLI instead of doing the JMP for the VBI. E0E0: 48 LE0E0 PHA E0E1: 8A TXA E0E2: 48 PHA E0E3: 98 TYA E0E4: 48 PHA E0E5: D8 CLD E0E6: 2C 0F D4 BIT NMIST E0E9: 10 03 BPL $E0EE E0EB: 4C 5D F7 JMP $F75D Most of this will not be important for the sampling DLIs. GO_VBIJMP VBI PHA BIT NMIST BPL VBI ... PLARTI Fasted implementation for a ring buffer would be having the NMI in RAM so you can do LDA port STA buffer INC *-2 without the need for further registers. And you'll probably have to CLI in the NMI which draws the pointer, as there will be IRQs during these 16 scanlines 3 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 29, 2018 Author Share Posted December 29, 2018 Thanks Peter: good ideas. I already optimised NMI dispatch a little since this seemed a prime candidate for savings, but avoiding the index register is much better. This way, I need only save X and Y when the counter = 0 (this tells the DLI it's time to render the pointer). 2 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 29, 2018 Author Share Posted December 29, 2018 And you'll probably have to CLI in the NMI which draws the pointer, as there will be IRQs during these 16 scanlines The idea is to suppress mouse rendering during critical sections and just keep buffering mouse input, so the long NMI will be skipped entirely (and the mouse pointer can't be rendered anyway without fairly considerable setup in the prior VBI, which will also be skipped during critical sections). Most of the high-speed SIO implementations poll IRQST anyway and in some cases disable IRQs during serial transfers (Hias' driver, for example). The idea is that when the full VBI and mouse rendering NMI are re-enabled when we come out of the critical IO section, the UI is able to catch up by processing the mouse input readings collected in the ring buffer. 1 Quote Link to comment Share on other sites More sharing options...
BlueMoon_001 Posted December 31, 2018 Share Posted December 31, 2018 What applications are complete to use this GUI? Word Processor, Spreadsheet, Text/Program Editors, Graphics? Is the GUI running from RAM, or do you have any plans to use a flash cartridge? Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted December 31, 2018 Share Posted December 31, 2018 The idea is that when the full VBI and mouse rendering NMI are re-enabled when we come out of the critical IO section, the UI is able to catch up by processing the mouse input readings collected in the ring buffer. You'll also probably want to disable clicks and just track deltas, otherwise you might click on something that hasn't been drawn and possibly do something you don't want to. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 31, 2018 Author Share Posted December 31, 2018 What applications are complete to use this GUI? Word Processor, Spreadsheet, Text/Program Editors, Graphics? Complete? No complete apps yet: just the skeletal stuff in the demo thus far. The 'Profiler' app is by far the most complete of all, being fifty per cent functional. Since the system requires bespoke applications and drivers for pretty much everything, it's naturally an enormous undertaking. Is the GUI running from RAM, or do you have any plans to use a flash cartridge? The GOS runs from a flash cart or banked ROM of at least 128KB capacity (16 x 8KB banks). A lot of code runs in RAM but is launched from a ROM-disk built into the cartridge. The chief advantage of using a cartridge is that there's a large amount of code which has uninhibited access to every other area of memory on the system. You'll also probably want to disable clicks and just track deltas, otherwise you might click on something that hasn't been drawn and possibly do something you don't want to. Mouse down/up is already buffered by the interrupt-driven handler and has the nice effect of allowing clicks to register on close buttons, etc, even if the click happened while the window content was still redrawing. It 'feels' like the Windows UI in this respect and helps avoid lag. This feature will also be essential part of keeping the UI responsive during long periods of disk activity. Anyway: I've implemented some of Hias' and Peter Dell's excellent suggestions and we now have a mouse driver which is lighter, faster, doesn't rely on IRQs at all, is functionally identical to the IRQ-based implementation, and should function reasonably well during serial IO. I've put the software acceleration back which was missing for a few days while I rewrote the driver. After eight sustained frames of mouse movement, the deltas are doubled until we get another frame with no movement. This is accomplished by simply shifting left the value in the direction look up table (which is 1 or -1) before it's added to X or Y. Really pleased with how this has turned out and am looking forward to pushing the project forward. 14 Quote Link to comment Share on other sites More sharing options...
TheNameOfTheGame Posted January 1, 2019 Share Posted January 1, 2019 Really pleased with how this has turned out and am looking forward to pushing the project forward. Oh what am I reading? Please do. Happy New Year! 2 Quote Link to comment Share on other sites More sharing options...
Ocelo Posted March 22, 2019 Share Posted March 22, 2019 This project is amazing. My Father and I are very interested to see the functioning GUI when it is complete.My 130 XE awaits the software eagerly. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 22, 2019 Author Share Posted March 22, 2019 This project is amazing. My Father and I are very interested to see the functioning GUI when it is complete. My 130 XE awaits the software eagerly. Thank you! I intend to return to the GOS later this year. 14 Quote Link to comment Share on other sites More sharing options...
Bobbs Posted June 7, 2019 Share Posted June 7, 2019 A fancy GUI needs a nice mouse... https://www.instructables.com/id/Atari-8-Bit-Optical-Mouse/ Quote Link to comment Share on other sites More sharing options...
+mytek Posted June 8, 2019 Share Posted June 8, 2019 A fancy GUI needs a nice mouse... https://www.instructables.com/id/Atari-8-Bit-Optical-Mouse/ - OR - https://ataribits.weebly.com/mousetari.html Just needs a pcb with a DB9 and a PS/2 connector to allow plugging the chip into the joystick port, and a PS/2 mouse. 2 Quote Link to comment Share on other sites More sharing options...
Lastic Posted June 8, 2019 Share Posted June 8, 2019 OR http://lavago.de/retro-computer.html 7 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 8, 2019 Author Share Posted June 8, 2019 OR http://lavago.de/retro-computer.html Oh now that's going on the wish list. 2 Quote Link to comment Share on other sites More sharing options...
Gunstar Posted June 8, 2019 Share Posted June 8, 2019 Oh now that's going on the wish list. Most definitely! Quote Link to comment Share on other sites More sharing options...
bradc Posted January 1, 2020 Share Posted January 1, 2020 Is it possible to try this out in an emulator? Which is preferred? I'm currently using atari800 on Linux. Awesome work, BTW! 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.