flashjazzcat Posted May 23, 2019 Share Posted May 23, 2019 Yes: I think that's known as beta testing, but ideally it should be carried out - by whatever means - before the finished product is released or sold. I'm implicitly speaking of software which aims for a reasonably high threshold of quality and reliability, but it's self-evident that people are free to fulfil themselves by using the available tools in any way they wish. 3 Quote Link to comment Share on other sites More sharing options...
JohnPolka Posted May 23, 2019 Share Posted May 23, 2019 (edited) To be sure, every knows my thoughts when it comes to real hardware. I do however believe that if we didn't have devs using Altirra much of what we have wouldn't exist. Some our best talented people don't have the Atari stuff set up anymore (wife life space kids)... They do the best they can using the tools that let them continue with their passion. It's up to people who have the time and space with real machines/devices to help them out and get the issues tackled. This could be dev partners or the general public. Honestly it's not far from bitd when code was written on an S-100 or other machine (yes big time shared machine too), compiled and checked out sometimes by others. It's a partnership that is gratifying and amazing if you think about it. People in different physical locations all around the world making games/applications/ and even devices with and without the real physical machines. Amazing stuff. I agree. I currently don't have the space to keep my Atari hardware out in the open all the time. As you point out, space and kids, are the reason for it. Space is a premium at our house. And when I do find a space, I have curious little kids that might wreak havoc on the old hardware. Fortunately, I have organized my closet enough where I can set up a system within a couple of minutes when I need to (or want to) work on native hardware. One of these days, the kids will get older and less curious and/or we will move into a larger house where I can safely keep the hardware out in a dedicated space. -JP Edited May 23, 2019 by JohnPolka 1 Quote Link to comment Share on other sites More sharing options...
phaeron Posted May 24, 2019 Author Share Posted May 24, 2019 The timeout value is as per the screenshot of the command frame ($06), but when I looked at CDTMV1 again, aside from being cleared on a cold power-up, it isn't set at all in this scenario before we enter the endless polling loop. Of course the VBI will only jump through the vector if the timer transitions from non-zero to zero. So presumably something about this particular command frame is causing the OS not to bother initialising the timer? Anyway: I manually set the LSB of CDTMV1 to some non-zero value and set a breakpoint on my VBI, which did duly jump through CDTMA1. However, the code at $EC21 just writes 0 to TIMFLG ($0317) and returns, which doesn't break the deadlock. Eh, wait a minute. That's not the receive loop, that's the transmit loop. It doesn't check for the timeout because there isn't supposed to be a timeout, the timing is controlled by the computer sending bytes. If it's looping there it means that either (VSEROR) or (VSEROC) didn't get called. That moves the area of focus from VBI to IRQ. Would it be possible to obtain your test case so I can debug it locally (here or PM)? I've tried to repro using the SIDE/SIDE2 version of the loader, but it doesn't seem to have the same behavior (and doesn't service serial IRQs at all in its immediate IRQ handler). 3 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted May 24, 2019 Share Posted May 24, 2019 (edited) Eh, wait a minute. That's not the receive loop, that's the transmit loop. It doesn't check for the timeout because there isn't supposed to be a timeout, the timing is controlled by the computer sending bytes. If it's looping there it means that either (VSEROR) or (VSEROC) didn't get called. That moves the area of focus from VBI to IRQ. Would it be possible to obtain your test case so I can debug it locally (here or PM)? I've tried to repro using the SIDE/SIDE2 version of the loader, but it doesn't seem to have the same behavior (and doesn't service serial IRQs at all in its immediate IRQ handler). I've PM'd you the ROM (not that I'm secretive, but it's a bastardised version of the pre-release Incognito loader), but you've alighted on the reason for the observed issue anyway. The loader steals VIMIRQ and doesn't service serial interrupts since no serial interrupts will occur unless there's a bug in the loader which calls the SIO when there's no PBI device handler. Serial IO is off-limits anyway since there's a) no need for it, and b) it probably wouldn't work reliably (or it would wreck the display) since the screen is heavy with NMIs. So: in this scenario, SIO is called with an IRQ dispatcher which ignores serial IRQs. I suppose the only remaining mystery is why OS-A/B manages to come out of this smiling. Edited May 24, 2019 by flashjazzcat 2 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted May 24, 2019 Share Posted May 24, 2019 I name this The Theresa May bug, as in its been announced its almost fixed but just not yet! /me ends JOKE political reference.. 2 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted May 25, 2019 Share Posted May 25, 2019 (edited) Avery finally solved the mystery. An... ahem... quirk in the loader's IRQ handler resulted in the serial IRQ being misinterpreted as a BREAK key IRQ (the loader dispatches only keyboard IRQs and BREAK IRQs). Setting the OS BREAK key flag causes the transmit loop to exit in OS-A/B, but in Avery's kernel, the BREAK key is currently ignored by transmit loop, which is why the hang happens. The effect of fixing the loader's IRQ handler (so that a serial IRQ isn't misinterpreted as a BREAK key IRQ) will in fact be that the errant behaviour is duplicated in OS-A/B (or would be, were the primary bug in the Incognito loader not now fixed). But since the IRQ handler should never have to deal with a serial IRQ in the first place (a bug being the reason it handled one at all; also, if the underlying kernel fails to dispatch SIO commands to the PBI device ROM when the loader finds one to be present, it's a fatal error which will prevent the loader from working properly at all), that's intended behaviour. Thanks also to Avery for recommending an (now rather obvious) optimisation to the same IRQ handling code which usefully saved six bytes. Edited May 25, 2019 by flashjazzcat 7 Quote Link to comment Share on other sites More sharing options...
Faicuai Posted May 25, 2019 Share Posted May 25, 2019 Avery finally solved the mystery. An... ahem... quirk in the loader's IRQ handler resulted in the serial IRQ being misinterpreted as a BREAK key IRQ (the loader dispatches only keyboard IRQs and BREAK IRQs). Setting the OS BREAK key flag causes the transmit loop to exit in OS-A/B, but in Avery's kernel, the BREAK key is currently ignored by transmit loop, which is why the hang happens. The effect of fixing the loader's IRQ handler (so that a serial IRQ isn't misinterpreted as a BREAK key IRQ) will in fact be that the errant behaviour is duplicated in OS-A/B (or would be, were the primary bug in the Incognito loader not now fixed). But since the IRQ handler should never have to deal with a serial IRQ in the first place (a bug being the reason it handled one at all; also, if the underlying kernel fails to dispatch SIO commands to the PBI device ROM when the loader finds one to be present, it's a fatal error which will prevent the loader from working properly at all), that's intended behaviour. Thanks also to Avery for recommending an (now rather obvious) optimisation to the same IRQ handling code which usefully saved six bytes. OMG! If I understood correctly, then all of the above means that pressing "L" while on BIOS main screen (in Colleen mode) worked all these years by pure luck (!?) Or, in other words, it worked because OS/B just happened to have a handler for a (phantom) "BRK-key" interrupt on specifically its serial Tx-loop code (which Avery's could not have because its truly his own work...) In any case, this one was a TOUGH cookie... Almost the whole week working on it, and yet a reminder of the deep (and embedded) complexities and intricacies that surface when exercising our Atari's "micro-controller" role (besides the multitude of all the hats it already handles...) Absolutely GREAT work to both you guys... THANKS (!!!) Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 25, 2019 Share Posted May 25, 2019 I name this The Theresa May bug, as in its been announced its almost fixed but just not yet! /me ends JOKE political reference.. Lovely.... we will see tomorrow. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted May 25, 2019 Share Posted May 25, 2019 If I understood correctly, then all of the above means that pressing "L" while on BIOS main screen (in Colleen mode) worked all these years by pure luck (!?) Or, in other words, it worked because OS/B just happened to have a handler for a (phantom) "BRK-key" interrupt on specifically its serial Tx-loop code (which Avery's could not have because its truly his own work...) The PBI BIOS check was added fairly recently (probably not sooner than version 2.0) in order to avoid a lengthy timeout if the loader issued the mount command when there was no PBI BIOS. In older versions, this command timing out signified the absence of the PBI driver. Recent versions test for the PBI BIOS by setting every device selection bit in turn and checking the ROM signature. This avoids the initial SIO timeout and guarantees that the special mounting commands are handled only by the appropriate driver (just in case IDE Plus, for instance, happened to implement the same mounting API in the future and was hooked up to the machine on a PBI ID with a higher priority). Unfortunately a bypass of the PBI check was implemented at the same time in the Incognito build of the loader, for reasons which escape me at the moment. Checking the BREAK key during the transmit loop wouldn't make the 800 kernel especially derivative or unoriginal. But I have the absence of the check to thank for getting a couple of obscure corner-case loader bugs rectified. 1 Quote Link to comment Share on other sites More sharing options...
phaeron Posted May 27, 2019 Author Share Posted May 27, 2019 http://www.virtualdub.org/beta/Altirra-3.20-test26.zip http://www.virtualdub.org/beta/Altirra-3.20-test26-src.zip ARM64 build fix. Fixed a crash that sometimes occurred when single stepping after a cold reset when the computer is still off due to power-up delay. Fixed MegaMax 2M cartridge type (CAR 61) to also switch banks on reads. 9 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted May 29, 2019 Share Posted May 29, 2019 (edited) Hi Phaeron, Has it always been the case that if you are running a fully emulated Disk drive that the D&D bas files stop working, well only work by the conventional way of loading? (I'd go back versions but I keep forgetting to back up my settings (will do it now)... Also saw that the SPeedy 1050 which used to use the speedy 1.33n rom no longer recognises that one, just an update to use other / correct rom? (found one that works in the set, speedy-140724) Edited May 29, 2019 by Mclaneinc Quote Link to comment Share on other sites More sharing options...
pmgraphics Posted May 29, 2019 Share Posted May 29, 2019 I'm using Altirra 3.10 to do video capture of game play. I have the same configurations on two different PC's, capture settings Zipped Motion Block Video and Frame rate 59.923 (accurate). One PC captures video at 672x448 while the other computer captures at 752x480. How do get the same capture dimensions on both systems? Quote Link to comment Share on other sites More sharing options...
phaeron Posted May 30, 2019 Author Share Posted May 30, 2019 I'm using Altirra 3.10 to do video capture of game play. I have the same configurations on two different PC's, capture settings Zipped Motion Block Video and Frame rate 59.923 (accurate). One PC captures video at 672x448 while the other computer captures at 752x480. How do get the same capture dimensions on both systems? This is determined by the Overscan settings in the View menu. 672x is 168 color clocks across (Normal) while 752x is 188 color clocks (Extended). 2 Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted June 7, 2019 Share Posted June 7, 2019 Hi, I enabled SIO2SD emulation, but the sio2sd.xex configurator shows no files. Is there any way to configure SIO2SD emulated device (to tell which directory should be read in) or is it hardcoded ? Regards Marcin Quote Link to comment Share on other sites More sharing options...
phaeron Posted June 8, 2019 Author Share Posted June 8, 2019 Hi, I enabled SIO2SD emulation, but the sio2sd.xex configurator shows no files. Is there any way to configure SIO2SD emulated device (to tell which directory should be read in) or is it hardcoded ? Regards Marcin No, SIO2SD emulation is currently only partial for the raw sector access. The higher-level calls for file access and mounting are not emulated. Quote Link to comment Share on other sites More sharing options...
Faicuai Posted June 8, 2019 Share Posted June 8, 2019 (edited) Avery finally solved the mystery. An... ahem... quirk in the loader's IRQ handler resulted in the serial IRQ being misinterpreted as a BREAK key IRQ (the loader dispatches only keyboard IRQs and BREAK IRQs). Setting the OS BREAK key flag causes the transmit loop to exit in OS-A/B, but in Avery's kernel, the BREAK key is currently ignored by transmit loop, which is why the hang happens. The effect of fixing the loader's IRQ handler (so that a serial IRQ isn't misinterpreted as a BREAK key IRQ) will in fact be that the errant behaviour is duplicated in OS-A/B (or would be, were the primary bug in the Incognito loader not now fixed). But since the IRQ handler should never have to deal with a serial IRQ in the first place (a bug being the reason it handled one at all; also, if the underlying kernel fails to dispatch SIO commands to the PBI device ROM when the loader finds one to be present, it's a fatal error which will prevent the loader from working properly at all), that's intended behaviour. Thanks also to Avery for recommending an (now rather obvious) optimisation to the same IRQ handling code which usefully saved six bytes. Always wondered whether this issue could also be observed on XL/XE-compatible OS'es. Here are the findings, at-a-glance, after spending some time on this: With Incognito in XL-mode, and turning ON PBI support in bios, pressing "L" works WELL with Avery's XL-OS. With Incognito in XL-mode, and turning OFF PBI support in bios, pressing "L" hangs with Avery's XL-OS. With Incognito in XL-mode, and turning ON PBI support in bios, pressing "L" works WELL with Atari XL/XE, Q-MEG, OMNIVIEW 80, OMNIVIEW XE (1985). With Incognito in XL-mode, and turning OFF PBI support in bios, pressing "L" works WELL with Atari XL/XE, Q-MEG, OMNIVIEW 80, OMNIVIEW XE (1985). I thought it would be interesting reporting the effect of turning ON or OFF PBI-support on BIOS, and the consequent effect on starting SIDE Loader... Findings on #1 and #4 are kind of surprising, to me. Edited June 8, 2019 by Faicuai Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 8, 2019 Share Posted June 8, 2019 It's fixed. Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted June 9, 2019 Share Posted June 9, 2019 I have an odd issue tonight - I reset my Altirra settings to the defaults, reconfigured my preferred emulation settings but now I'm booting into the Ultimate 1MB configuration screen and my arrow keys are not working in the U1MB menus. Heck, for that matter, the emulated U1MB BIOS is completely unresponsive to any keypresses. I've tried several different save U1MB firmware versions I've used going back about a year and they all do the same. I boot right into the U1MB setup screen and then the emulated machine doesn't recognize keyboard input. With the U1MB disabled in the Altirra memory settings, everything else is fine. Anyone have any idea what I may have reset inadvertently preventing me from using an emulated U1MB? Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted June 9, 2019 Share Posted June 9, 2019 Well, I'm stumped here - I've tried every setting I can think of in Altrra that affects acceleration or keyboard controls to see if that might be causing any problems, I've run CCleaner to see if I have any fubar registry settings, finally deleted and all the Altirra registry entries entirely and set the program to run in portable mode, but the problem persists. At the U1MB BIOS screen - and ONLY at the U1MB BIOS screen - all keyboard entries seem to be ignored. I still trigger a soft or hard reset with F5 and Shift+F5 so Altirra itself seems to be running just fine, but the emulated Atari is *not* happy with a U1MB firmware selected. But this is *very* interesting - if I have ANY of Jon's test firmware builds later than September 2018, my PC keyboard does not work in the U1MB BIOS screens. However, if I go back to a test build from September 2018 or earlier, my keyboard is recognized as per normal. This is very weird ... Quote Link to comment Share on other sites More sharing options...
phaeron Posted June 10, 2019 Author Share Posted June 10, 2019 I presume that all of the affected builds would be pre-release builds? The latest publicly downloadable BIOS build is July 2018, as far as I can tell. You don't need to delete registry entries to switch to portable mode, btw. The presence of Altirra.ini is what enables portable mode and it has priority. Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted June 10, 2019 Share Posted June 10, 2019 I presume that all of the affected builds would be pre-release builds? The latest publicly downloadable BIOS build is July 2018, as far as I can tell. You don't need to delete registry entries to switch to portable mode, btw. The presence of Altirra.ini is what enables portable mode and it has priority. Yeah, these are XEL and XLD-specific builds. The key point is, I was having some weird stuff going on with the my emulated setup (*), so I reset Altirra to the defaults and started over. After I added back in my XEL-CF 3 and HD image, then enabling the U1MB and pointing Altirra at the same firmware I'd been using for a couple months, it suddenly stopped recognizing my keyboard in the BIOS screen. Very, very weird. (*) The problem I was having was this: the new U1MB beta builds allow disabling the cartridge ROM specifically, so you can keep a cart inserted and enable it or disable it as needed without needing to physically remove the cart. This is useful especially for the 1088XLD, where the cart connector is generally vestigial - inside the case, it's impractical to use at all unless you can disable it. Altirra suddenly stopped recognizing the setting I had enabled in the U1MB BIOS, despite it having worked before. I presumed I had some corrupted setting, so I just reset everything and went to set it all up again. That's when the U1MB BIOS stopped working for me. Quote Link to comment Share on other sites More sharing options...
phaeron Posted June 10, 2019 Author Share Posted June 10, 2019 Yeah, these are XEL and XLD-specific builds. The key point is, I was having some weird stuff going on with the my emulated setup (*), so I reset Altirra to the defaults and started over. After I added back in my XEL-CF 3 and HD image, then enabling the U1MB and pointing Altirra at the same firmware I'd been using for a couple months, it suddenly stopped recognizing my keyboard in the BIOS screen. Very, very weird. Don't you have to enable stereo in the emulator for 1088XLD-specific builds to work, since they rely on the dual POKEYs guaranteed by that hardware? 2 Quote Link to comment Share on other sites More sharing options...
+DrVenkman Posted June 10, 2019 Share Posted June 10, 2019 Don't you have to enable stereo in the emulator for 1088XLD-specific builds to work, since they rely on the dual POKEYs guaranteed by that hardware? Ah, I bet that’s it! I’ve closed my laptop and about to head to bed - I worked 64+ billable hours these last 7 days straight, and expect another 10+ hours tomorrow to meet a hard deadline. I’ll confirm whenever I finally get home tomorrow night. Thanks for pointing me at the obvious thing to check right under my nose that I’ve missed completely. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 10, 2019 Share Posted June 10, 2019 Sorry: I would have jumped in yesterday had I known you were emulating an XEL. Avery is absolutely correct and the lack of stereo is guaranteed to be the issue here. 2 Quote Link to comment Share on other sites More sharing options...
NuY Posted June 10, 2019 Share Posted June 10, 2019 Random feature request: is it possible to add 1020 plotter emulation as well as the P: device? Yes, I know I'm obsessed with 1020s I'm a big fan of the 1020 emulation in APE so would be very cool to see something similar in Altirra! 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.