phaeron Posted June 13, 2016 Author Share Posted June 13, 2016 Hi guys! I've been messing around a little bit more with the VCOUNT register and I found an efficient way to get the maximum VCOUNT value. I was expecting a value of 130 for NTSC and 155 for PAL video systems. However, if I keep rerunning the program, I sometimes get 131 for NTSC and 156 for PAL video systems on the Altirra Emulator. How can this be? Can the number of video lines vary this way? (and even on a real computer?) This happens on the real hardware. There's exactly one cycle in the frame where VCOUNT rolls over to 131 or 156 before it gets reset back to 0. 1 Quote Link to comment Share on other sites More sharing options...
Xuel Posted June 13, 2016 Share Posted June 13, 2016 I was expecting a value of 130 for NTSC and 155 for PAL video systems. However, if I keep rerunning the program, I sometimes get 131 for NTSC and 156 for PAL video systems on the Altirra Emulator. How can this be? Can the number of video lines vary this way? (and even on a real computer?) Yes, you are correct. phaeron explains it as follows in the Altirra Hardware Reference Manual: End-of-frame anomaly ANTIC requires one additional cycle to detect that the vertical counter has hit the end of frame value and to reset it to $00. This means that reading VCOUNT on exactly cycle 110 of the very last scan line will give $83 (NTSC) or $9C (PAL), which correspond to scan lines 262 and 312, respectively; starting with cycle 111, it reads $00. This is the only cycle in the frame where this highest value can be seen and is thus extremely rare, but it could be a surprise to a DLI handler using VCOUNT to index tables. 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 13, 2016 Share Posted June 13, 2016 Fixes a bug that fjc reported with SIDE2 drive removal reporting (incorrect state on device init). Many thanks - works great. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 13, 2016 Share Posted June 13, 2016 May have spoken too soon there. Although $D5F9 (the SIDE2 CF card removal flag) now properly reads $01 on cold power-up when the cart is booted with no card present, it also appears to read $01 on cold power-up when there IS a card present. This causes the SDX SIDE soft driver to issue a bogus "Card not present" error in test42 (didn't happen in test41). Many thanks to Anna for pointing this out. Quote Link to comment Share on other sites More sharing options...
AnnaWu Posted June 13, 2016 Share Posted June 13, 2016 May have spoken too soon there. Although $D5F9 (the SIDE2 CF card removal flag) now properly reads $01 on cold power-up when the cart is booted with no card present, it also appears to read $01 on cold power-up when there IS a card present. This causes the SDX SIDE soft driver to issue a bogus "Card not present" error in test42 (didn't happen in test41). Many thanks to Anna for pointing this out. Thank you of taking care of it. Quote Link to comment Share on other sites More sharing options...
atx4us Posted June 13, 2016 Share Posted June 13, 2016 This happens on the real hardware. There's exactly one cycle in the frame where VCOUNT rolls over to 131 or 156 before it gets reset back to 0. Yes, you are correct. phaeron explains it as follows in the Altirra Hardware Reference Manual: End-of-frame anomaly ANTIC requires one additional cycle to detect that the vertical counter has hit the end of frame value and to reset it to $00. This means that reading VCOUNT on exactly cycle 110 of the very last scan line will give $83 (NTSC) or $9C (PAL), which correspond to scan lines 262 and 312, respectively; starting with cycle 111, it reads $00. This is the only cycle in the frame where this highest value can be seen and is thus extremely rare, but it could be a surprise to a DLI handler using VCOUNT to index tables. Thanks guys for your help and for the excellent explanations. Quote Link to comment Share on other sites More sharing options...
phaeron Posted June 14, 2016 Author Share Posted June 14, 2016 May have spoken too soon there. Although $D5F9 (the SIDE2 CF card removal flag) now properly reads $01 on cold power-up when the cart is booted with no card present, it also appears to read $01 on cold power-up when there IS a card present. This causes the SDX SIDE soft driver to issue a bogus "Card not present" error in test42 (didn't happen in test41). Many thanks to Anna for pointing this out. Try now: http://www.virtualdub.org/beta/Altirra-2.80-test43.zip http://www.virtualdub.org/beta/Altirra-2.80-test43-src.zip Turns out the IDE removed flag wasn't ever forced on a cold reset, so I added that. Not 100% sure about powerup state on actual hardware since it's tough for me to test, but you can probably verify that quickly. Interestingly, I do see the LED on the SIDE 2 cartridge blinking on and off for about a split second, so it's possible this is ensured by the hardware. Also, I threw in the saving of the file viewer state. 4 Quote Link to comment Share on other sites More sharing options...
AnnaWu Posted June 14, 2016 Share Posted June 14, 2016 Thanks for the fix, phaeron. The card is now present. 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 14, 2016 Share Posted June 14, 2016 Try now: http://www.virtualdub.org/beta/Altirra-2.80-test43.zip http://www.virtualdub.org/beta/Altirra-2.80-test43-src.zip Turns out the IDE removed flag wasn't ever forced on a cold reset, so I added that. Not 100% sure about powerup state on actual hardware since it's tough for me to test, but you can probably verify that quickly. Interestingly, I do see the LED on the SIDE 2 cartridge blinking on and off for about a split second, so it's possible this is ensured by the hardware. Also, I threw in the saving of the file viewer state. Thanks - it appears to work now. Hardware powerup state must reflect card presence right off the bat, since the SDX driver just reads the removal flag before doing anything else and complains there's no card if it's non-zero without making any attempt to reset the latched bit. The PBI BIOS obscured the bug introduced by the first fix, however, since it didn't bother testing the removal flag at all on cold powerup (it just timed out trying to read the card). I fixed that behaviour in the PBI BIOS now, but in a way which still would have obscured the bug since an attempt is made to reset $D5F9 as soon as the BIOS notices that bit 0 is set. Tested with the XEX loader as well and behaviour appears correct when starting without a card, then inserting one, or starting with a card then removing it, etc. Re: file viewer state - thanks! Quote Link to comment Share on other sites More sharing options...
phaeron Posted June 19, 2016 Author Share Posted June 19, 2016 http://www.virtualdub.org/beta/Altirra-2.80-test44.zip http://www.virtualdub.org/beta/Altirra-2.80-test44-src.zip Fix for FDC status bits with returning deleted sector status in 810 emulation mode. Adds emulation of serial bus noise effects (toggle in System > Audio > Serial Noise). 1 Quote Link to comment Share on other sites More sharing options...
morelenmir Posted June 19, 2016 Share Posted June 19, 2016 http://www.virtualdub.org/beta/Altirra-2.80-test44.zip http://www.virtualdub.org/beta/Altirra-2.80-test44-src.zip Fix for FDC status bits with returning deleted sector status in 810 emulation mode. Adds emulation of serial bus noise effects (toggle in System > Audio > Serial Noise). Many thanks Phaeron! I'll give it a whirl shortly. Quote Link to comment Share on other sites More sharing options...
morelenmir Posted June 19, 2016 Share Posted June 19, 2016 (edited) Works as well as ever and the serial noise is amusing too! But... but... I have not been active with either real hardware nor Altirra for the past couple of months, but... I could have sworn I had found a full cassette emulator as part of Altirra. No. Surely not. Phaeron hates tapes and will never ever emulate them. Its probably just because I am up late and getting tired. Yep. That's must be it. There'll never be emulation of cassette handling in Altirra....!!!???!?!?!? Edited June 19, 2016 by morelenmir 2 Quote Link to comment Share on other sites More sharing options...
serj Posted June 19, 2016 Share Posted June 19, 2016 and I still have a hope to see one day in the emulator emulation "Turbo 2000". 2 Quote Link to comment Share on other sites More sharing options...
RetroDan Posted June 19, 2016 Share Posted June 19, 2016 Looks like a winner. But I need help. How do i add the Atari ROMS. How does one actually load/run programs. i've tried a fewe things but they did not work. Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted June 19, 2016 Share Posted June 19, 2016 (edited) Hi Dan Roms can be found here http://atari.vjetnam.cz/index.php?frame=roms For legal reasons there's only one very old emulator out there that has permission to supply them as part of the emulator. Unpack them and then go to system firmware and firmware images, use the scan options to scan the directory the roms are in and it will auto recognise the known good crc versions. Then after that use the System menu to either adjust one of the profiles to use what you want or set the hardware wanted via Hardware and then firmware to pick what OS you want it to use, obviously mixing different hardware with older firmware can and most likely will run in to problems. From there on get whatever format of game / util you want and either boot it from the File menu or drag and drop it on to the emulator, drag and drop does not work for BAS files, those must be booted and it will auto load BASIC for you, if you don't have an Atari rom for the BASIC it will use the internal Altirra BASIC which is optimised and very fast but there are commands like CONT it does not use so the original system roms can be used for when you run into a problem. You will also find BAS2BOOT atrs will not run under Altirra basic but that's because of a naughty use of hardware calls by the author to BAS2BOOT. For ATR's that need BASIC you will either need to enable it via Firmware if its an XL - XE model or if its 400 or 800 hardware you want to use then you have to attach it from the File / attach special cartridge menu as on those machines BASIC was a stand alone cart and not built in. Don't enable basic if its not needed for lots of reasons.. There's also LOTS of games on that page with the roms.. Lastly, if you want a set of all the OS / Hardware roms Altirra can use then check this link provided very kindly by Serj.. http://atariage.com/forums/topic/246939-altirra-270-released/page-9?do=findComment&comment=3445433 Hope it helps Paul.. Edited June 19, 2016 by Mclaneinc 1 Quote Link to comment Share on other sites More sharing options...
Madi Posted June 19, 2016 Share Posted June 19, 2016 Excellent way to simplify starting Altirra for new commers.. Really nice Hi Dan Roms can be found here http://atari.vjetnam.cz/index.php?frame=roms .... .... "drag and drop does not work for BAS files" Paul.. Drag and drop works for basic files. Also, Altirra will recognize .BAS files and will turn on BASIC if it is not already on. madi Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted June 19, 2016 Share Posted June 19, 2016 (edited) Excellent way to simplify starting Altirra for new commers.. Really nice Drag and drop works for basic files. Also, Altirra will recognize .BAS files and will turn on BASIC if it is not already on. madi Thank you, the usability is one thing I know Avery is working on himself but its also one of the MANY things he's working on.. Doh, yep drag and drop does indeed work, I meant double clicking on a bas file that does not / is not meant to work, the right words were in my head while my hands typed complete rubbish in post 615 above... Thank you for highlighting it as its too late to edit it And yes, the autoloading of BASIC is a lovely little touch by Avery, thankfully I got that right in my post Edited June 19, 2016 by Mclaneinc Quote Link to comment Share on other sites More sharing options...
fujidude Posted June 19, 2016 Share Posted June 19, 2016 When the hell does a copyright expire? My gosh, it's been 1979-1983 that these ROMs were released? Criminie. 2 Quote Link to comment Share on other sites More sharing options...
morelenmir Posted June 19, 2016 Share Posted June 19, 2016 (edited) When the hell does a copyright expire? My gosh, it's been 1979-1983 that these ROMs were released? Criminie. I know... Its crazy isn't it!!! Especially when you consider all the source code is readily available and in such an excellent condition that, under Linux and CA65 you can build totally fresh and complete *.ROM files from those downloads. Edited June 19, 2016 by morelenmir Quote Link to comment Share on other sites More sharing options...
JoSch Posted June 19, 2016 Share Posted June 19, 2016 Thanks to Mickey Mouse, US copyright seems to virtually be forever. 3 Quote Link to comment Share on other sites More sharing options...
morelenmir Posted June 19, 2016 Share Posted June 19, 2016 Thanks to Mickey Mouse, US copyright seems to virtually be forever. Mickey mouse and Pooh-bear! Not to mention Cliff Richard... Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted June 20, 2016 Share Posted June 20, 2016 Doh....You mentioned him... He's still annoyed they confiscated his collection of school boy satchels! 1 Quote Link to comment Share on other sites More sharing options...
atx4us Posted June 21, 2016 Share Posted June 21, 2016 (edited) I know... Its crazy isn't it!!! Especially when you consider all the source code is readily available and in such an excellent condition that, under Linux and CA65 you can build totally fresh and complete *.ROM files from those downloads. I'm glad someone said this! If I understand correctly, Atari gave the OS ROMs distribution rights to the Xformer 2000 emulator. Why not to the other emulators as well? Because the other emulators authors just simply didn't bother to ask Atari? And so, Avery wrote his own Altirra OS to workaround the distribution issues. From my lack of complete OS familiarity, what doesn't the Altirra OS do that we still need the original Atari ROMs anyway? Edited June 21, 2016 by atx4us Quote Link to comment Share on other sites More sharing options...
phaeron Posted June 21, 2016 Author Share Posted June 21, 2016 If I understand correctly, Atari gave the OS ROMs distribution rights to the Xformer 2000 emulator. Why not to the other emulators as well? Because the other emulators authors just simply didn't bother to ask Atari? Agreements like that typically require various groups within the company to vet the agreement to be in line with the business goals of the company and to avoid legal issues, such as conflicts with other third party agreements made by the company. Typically these agreements are drawn narrowly to mitigate issues if something was missed or there are unintended consequences. IOW, the agreement only covers what is needed and no more. Keep in mind also how old the Xformer emulator is, and how few viable and open source emulators existed at the time that the arrangement would have been created. Additionally, we don't actually know the nature of the agreement between the Xformer author and Atari, so we don't know what usage is or isn't covered, or even if there was a written document confirming the arrangement. And so, Avery wrote his own Altirra OS to workaround the distribution issues. From my lack of complete OS familiarity, what doesn't the Altirra OS do that we still need the original Atari ROMs anyway? There are certain coding practices that are nearly impossible to support in a ROM OS without being too legally close to the original Atari OSes. In particular, relying on undocumented addresses or behaviors within the OS is difficult to support. Often this happened unintentionally, and it was a hassle even to Atari itself when trying to revise the OS for the 1200XL and later the 800XL+ lines. What's less excusable is when people deliberately do this in new software in 2016 and write programs that only work on the XL/XE OS ver 2-4 just to save a few bytes. Quote Link to comment Share on other sites More sharing options...
atx4us Posted June 21, 2016 Share Posted June 21, 2016 (edited) There are certain coding practices that are nearly impossible to support in a ROM OS without being too legally close to the original Atari OSes. In particular, relying on undocumented addresses or behaviors within the OS is difficult to support. Often this happened unintentionally, and it was a hassle even to Atari itself when trying to revise the OS for the 1200XL and later the 800XL+ lines. What's less excusable is when people deliberately do this in new software in 2016 and write programs that only work on the XL/XE OS ver 2-4 just to save a few bytes. I thought I was going to be on Avery's good programmer list by not using any of those old practices (that I'm aware of) that will make my program incompatible with Altirra OS. Initially, ACTris! 1.2 seems to run just fine with Altirra OS (B & XL versions). However, after a few object drops and then the VBI "Popcorn" music routine becomes all garbled. Avery, can you please take a look? Thanks. Edited June 21, 2016 by atx4us 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.