danielcg Posted September 6, 2013 Share Posted September 6, 2013 I am very happy that shadowing options had been added. Star Raiders was able to be accelerated when shadowing a cartridge was turned on. By default, shadowing ROM is turned on but shadowing a cartridge is turned off. I had to turn on shadowing a cartridge manually. I think shadowed ROM into fast RAM are also write-protected. DOS and BASIC software are also works in accelerated mode. DOS menu is displayed much faster in accelerated mode and I can access disk drives without any problems. Drawing demo in BASIC is far faster in accelerated mode! I love it! Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted September 7, 2013 Share Posted September 7, 2013 Just found the new OSK from the 360 pad, very nice indeed...But Found a bug...If you use the reset the window layout with the GUI layout on screen you then can't get rid of it and if its not on screen then you can't enable it either. Seems to take a restart to fix it. Or have I missed something devious Quote Link to comment Share on other sites More sharing options...
MaPa Posted September 25, 2013 Share Posted September 25, 2013 Is there a way to have all command parameters in hex format? Even if i set .base hex when trying to search or .writemem and maybe others, the starting address a can type 4000 which it takes as $4000 but the second parameter when typed 1000 it means 1000 bytes and not $1000. Quote Link to comment Share on other sites More sharing options...
phaeron Posted October 6, 2013 Author Share Posted October 6, 2013 Alright, release candidate: http://www.virtualdub.org/beta/Altirra-2.40-test19.zip http://www.virtualdub.org/beta/Altirra-2.40-test19-src.zip This version fixes Action! when using the LLE kernel and MAC/65 when using LLE/HLE kernels or floating-point acceleration. There are also a bunch of other fixes to the math pack support when not using the vanilla OS-B or XL/XE math pack. I also fixed a couple of bugs in emulated P: and R: that were reported to me (single byte writes to P: being broken and R: not responding to keyboard break). 3 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted October 7, 2013 Share Posted October 7, 2013 Bump as bug still in Altirra. Just found the new OSK from the 360 pad, very nice indeed...But Found a bug...If you use the reset the window layout with the GUI layout on screen you then can't get rid of it and if its not on screen then you can't enable it either. Seems to take a restart to fix it. Or have I missed something devious Quote Link to comment Share on other sites More sharing options...
serj Posted October 7, 2013 Share Posted October 7, 2013 http://www.virtualdub.org/beta/Altirra-2.40-test20.zip http://www.virtualdub.org/beta/Altirra-2.40-test20-src.zip Avery, whats new ? Quote Link to comment Share on other sites More sharing options...
laoo Posted October 7, 2013 Share Posted October 7, 2013 It's a fix for an obscure 65c816 bug that I've reported 18 hours ago I'm really impressed! Quote Link to comment Share on other sites More sharing options...
phaeron Posted October 8, 2013 Author Share Posted October 8, 2013 Sorry, folks... I don't always work on stuff in order. The OSK lockup is kind of nasty to deal with, so I'm postponing it to next version. The 65C816 issue was actually easy to fix because I had both a test suite and a test case. I wouldn't call (dp),Y and [dp],Y being broken with dp>0 an obscure bug, though -- it would break any code that used DP as a frame pointer, which is a common trick. Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted October 8, 2013 Share Posted October 8, 2013 Wasn't meant to seem like a bullish reminder, just bumped it as you said it was a release candidate, me, I'm just happy you update it Quote Link to comment Share on other sites More sharing options...
serj Posted October 8, 2013 Share Posted October 8, 2013 Avery, you can upgrade in the emulator, VBXE core to version 1.26? Quote Link to comment Share on other sites More sharing options...
avanze Posted October 8, 2013 Share Posted October 8, 2013 It's always nice to see an update. Thanks, phaeron. Quote Link to comment Share on other sites More sharing options...
Xuel Posted October 13, 2013 Share Posted October 13, 2013 For me, Altirra's audio gets out of sync by maybe 500ms after I press F1. I can re-sync by pausing with F9 or just hitting Alt twice. Anyone else have that experience? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 13, 2013 Share Posted October 13, 2013 Haven't noticed that, but I have noticed the OS pointer (under Win 7 at least) doesn't always disappear when I press F12 to capture the mouse. Occasionally (usually the first time after loading an XEX with Alt-O or rebooting the emulated machine) the OS pointer just sits there jittering on the spot. Had to use a camera to capture it: NOT a major problem and only happens once in a while but I just assumed no-one else had stumbled on it and Avery might be interested. Quote Link to comment Share on other sites More sharing options...
atx4us Posted October 16, 2013 Share Posted October 16, 2013 I performed a simple test to experiment with the ROMs shadowing feature in Altirra. The results are impressive! CPU: 65C816 (14.28 MHz), System = 800XL, NTSC, [8x], 64K RAM Atari BASIC cartridge Program: 10 POKE 20,020 FOR I=0 TO 1000:NEXT I30 ? PEEK(20) Results: Shadow ROMs: Disabled | Shadow Cartridges: Disabled | Loop Time = 91 JiffiesShadow ROMs: Enabled | Shadow Cartridges: Disabled | Loop Time = 67 JiffiesShadow ROMs: Disabled | Shadow Cartridges: Enabled | Loop Time = 32 JiffiesShadow ROMs: Enabled | Shadow Cartridges: Enabled | Loop Time = 10 Jiffies Quote Link to comment Share on other sites More sharing options...
phaeron Posted October 16, 2013 Author Share Posted October 16, 2013 For me, Altirra's audio gets out of sync by maybe 500ms after I press F1. I can re-sync by pausing with F9 or just hitting Alt twice. Anyone else have that experience? That's odd... unless you've changed the audio buffering settings, the maximum buffer by default is 100ms. Turbo mode tends to cause the buffers to fill up, but then Altirra starts dropping audio frames to bring the latency down. If you've got the max buffer cranked up then this will take longer. Otherwise, what do the buffering stats look like when debug info is enabled in audio options? Haven't noticed that, but I have noticed the OS pointer (under Win 7 at least) doesn't always disappear when I press F12 to capture the mouse. Occasionally (usually the first time after loading an XEX with Alt-O or rebooting the emulated machine) the OS pointer just sits there jittering on the spot. Had to use a camera to capture it: NOT a major problem and only happens once in a while but I just assumed no-one else had stumbled on it and Avery might be interested. Got it, happens when capture is triggered when the mouse isn't within the display bounds. I'll defer the fix to the next version, but it should be a quick one. I performed a simple test to experiment with the ROMs shadowing feature in Altirra. The results are impressive! Well, as impressive as stats are for a configuration that AFAIK doesn't truly exist exactly. 65C816 accelerated mode is more to be able to experiment with an accelerator rather than any specific hardware. From what I'm told, the actual memory configurations vary a lot on the accelerators that are out in the wild and that makes a big difference in how fast code actually runs, with some of the accelerators having serious bottlenecks. Altirra's accelerator memory model works as follows: The 65C816 is on a fast RAM bus, running at a multiple of system speed (1.79MHz * N). ANTIC is on the chip RAM bus at 1.79MHz. ANTIC DMA takes only a single cycle on the fast bus. This is modeled after the MEMAC window on the VBXE. Accesses from the fast bus to the chip bus by the 65C816 first require synchronization to the start of the next chip bus cycle and then a full chip bus cycle to complete. The shadow options control whether the ROMs and the cartridge are on the chip bus or the fast bus. Obviously, it isn't practical to run real cartridges at 14MHz, so this would require the accelerator to shadow them. Real accelerators deviate from this quite a bit. One setup has all 64K of base RAM still on the chip bus instead of replacing it with fast RAM. I imagine this is the simplest interfacing solution, but it pretty much negates the accelerator in bank 0 and requires code running in native mode for any speedup. Because the 65C816 has the annoying limitation that both direct page and stack must be in bank 0, this also hobbles native mode code running in upper bank, so overall it's a poorly performing setup. An improvement is to use the accelerator's memory for the base RAM, but synchronize the buses together on an access from either direction. This is what the earlier test builds did, and the accelerator does give a speed up for 6502 code, but ANTIC DMA still slows things down quite a bit. What this means is that a Gr.0 display still takes ~30% of total CPU even at faster speeds. Running from the real ROMs is also slow as then all instruction fetches slow the CPU down to 1.79MHz, meaning not much speedup happens on ROM routines except for word accesses to RAM like (zp),Y or JSR/RTS. Using write protected RAM to shadow the ROMs and the cartridges and optimizing the bridge between the buses removes the majority of the bottlenecks and allows the 65C816 to run at nearly full speed, which is what the current test builds do. What I've seen in a couple of accelerator specs is in between: they use fast RAM to shadow chip RAM with write-through. This means that reads go full speed, writes can be slowed down depending on timing and design of the write-through logic, and ANTIC DMA may or may not slow down the CPU. The reason I didn't implement this is that it's a lot more complex to emulate and I don't want to do anything that significantly impacts the main 6502 mode. Fortunately, there's already so much variation in '816 accelerators that you'd have to be insane to write code for one that's highly timing sensitive. Ultimately, what's needed to make this really compelling is a native 65C816 OS, in order to make the "Atari IIGS." That's a really big undertaking, though, and there's a serious chicken-and-egg problem between the lack of an OS and lack of accelerators. The 65816's native mode programming model is also such a mess that it makes 8086 real mode look clean in some ways. It is still a nice break from plain 6502, though. 2 Quote Link to comment Share on other sites More sharing options...
Xuel Posted October 16, 2013 Share Posted October 16, 2013 That's odd... unless you've changed the audio buffering settings, the maximum buffer by default is 100ms. Turbo mode tends to cause the buffers to fill up, but then Altirra starts dropping audio frames to bring the latency down. If you've got the max buffer cranked up then this will take longer. Otherwise, what do the buffering stats look like when debug info is enabled in audio options? That was it, thanks! I had extra buffer set to 500ms. When I set it to 20ms instead, F1 doesn't desync the audio. I'm using Altirra 2.40-test18. I have latency set to 80ms. Other than "Incoming Data Rate", the "Measure Range" stat is the one that varies the most when pressing F1. It looks like this: 500ms normal: ~18-25k 500ms after F1: ~100K then drops to 18-25k after some time and audio slowly syncs back up 20ms normal: ~18-25k 20ms after F1: ~30k then quickly drops back to 18-25k Quote Link to comment Share on other sites More sharing options...
atx4us Posted October 16, 2013 Share Posted October 16, 2013 That's odd... unless you've changed the audio buffering settings, the maximum buffer by default is 100ms. Turbo mode tends to cause the buffers to fill up, but then Altirra starts dropping audio frames to bring the latency down. If you've got the max buffer cranked up then this will take longer. Otherwise, what do the buffering stats look like when debug info is enabled in audio options? Got it, happens when capture is triggered when the mouse isn't within the display bounds. I'll defer the fix to the next version, but it should be a quick one. Well, as impressive as stats are for a configuration that AFAIK doesn't truly exist exactly. 65C816 accelerated mode is more to be able to experiment with an accelerator rather than any specific hardware. From what I'm told, the actual memory configurations vary a lot on the accelerators that are out in the wild and that makes a big difference in how fast code actually runs, with some of the accelerators having serious bottlenecks. Altirra's accelerator memory model works as follows: The 65C816 is on a fast RAM bus, running at a multiple of system speed (1.79MHz * N). ANTIC is on the chip RAM bus at 1.79MHz. ANTIC DMA takes only a single cycle on the fast bus. This is modeled after the MEMAC window on the VBXE. Accesses from the fast bus to the chip bus by the 65C816 first require synchronization to the start of the next chip bus cycle and then a full chip bus cycle to complete. The shadow options control whether the ROMs and the cartridge are on the chip bus or the fast bus. Obviously, it isn't practical to run real cartridges at 14MHz, so this would require the accelerator to shadow them. Real accelerators deviate from this quite a bit. One setup has all 64K of base RAM still on the chip bus instead of replacing it with fast RAM. I imagine this is the simplest interfacing solution, but it pretty much negates the accelerator in bank 0 and requires code running in native mode for any speedup. Because the 65C816 has the annoying limitation that both direct page and stack must be in bank 0, this also hobbles native mode code running in upper bank, so overall it's a poorly performing setup. An improvement is to use the accelerator's memory for the base RAM, but synchronize the buses together on an access from either direction. This is what the earlier test builds did, and the accelerator does give a speed up for 6502 code, but ANTIC DMA still slows things down quite a bit. What this means is that a Gr.0 display still takes ~30% of total CPU even at faster speeds. Running from the real ROMs is also slow as then all instruction fetches slow the CPU down to 1.79MHz, meaning not much speedup happens on ROM routines except for word accesses to RAM like (zp),Y or JSR/RTS. Using write protected RAM to shadow the ROMs and the cartridges and optimizing the bridge between the buses removes the majority of the bottlenecks and allows the 65C816 to run at nearly full speed, which is what the current test builds do. What I've seen in a couple of accelerator specs is in between: they use fast RAM to shadow chip RAM with write-through. This means that reads go full speed, writes can be slowed down depending on timing and design of the write-through logic, and ANTIC DMA may or may not slow down the CPU. The reason I didn't implement this is that it's a lot more complex to emulate and I don't want to do anything that significantly impacts the main 6502 mode. Fortunately, there's already so much variation in '816 accelerators that you'd have to be insane to write code for one that's highly timing sensitive. Ultimately, what's needed to make this really compelling is a native 65C816 OS, in order to make the "Atari IIGS." That's a really big undertaking, though, and there's a serious chicken-and-egg problem between the lack of an OS and lack of accelerators. The 65816's native mode programming model is also such a mess that it makes 8086 real mode look clean in some ways. It is still a nice break from plain 6502, though. Thank you for the detailed explanation - all very useful information. Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted October 16, 2013 Share Posted October 16, 2013 Atx4us, this is the Excessive unneeded quote Police, come out with your hands up... Book him Dano, Murder 1... 1 Quote Link to comment Share on other sites More sharing options...
atx4us Posted October 16, 2013 Share Posted October 16, 2013 Atx4us, this is the Excessive unneeded quote Police, come out with your hands up... Book him Dano, Murder 1... I guess I'll have to learn what the "MultiQuote" button does since the "Quote" button makes it all too easy to get arrested Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted October 17, 2013 Share Posted October 17, 2013 I guess I'll have to learn what the "MultiQuote" button does since the "Quote" button makes it all too easy to get arrested Sorry Sir, just doing my job... Quote Link to comment Share on other sites More sharing options...
serj Posted October 18, 2013 Share Posted October 18, 2013 new test release. http://www.virtualdub.org/beta/Altirra-2.40-test21.zip http://www.virtualdub.org/beta/Altirra-2.40-test21-src.zip Quote Link to comment Share on other sites More sharing options...
phaeron Posted October 21, 2013 Author Share Posted October 21, 2013 Had to take a fix for a hires playfield collision issue that broke Chicken. The fix in test-21 was for 64K 5200 cartridges. http://www.virtualdub.org/beta/Altirra-2.40-test22.zip http://www.virtualdub.org/beta/Altirra-2.40-test22-src.zip 3 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 21, 2013 Share Posted October 21, 2013 The different 65816 emulation speeds are great. This has enabled me to get rid of the cycle counting in my mouse renderer and make something which works at any CPU speed. Thanks! Quote Link to comment Share on other sites More sharing options...
H.E.R.O. Posted October 21, 2013 Share Posted October 21, 2013 Well, I should extend my gratitude, A fine working emulator indeed. Atari 5200/400/800 is no longer a chore to get working. Quote Link to comment Share on other sites More sharing options...
David Baldwin Posted October 23, 2013 Share Posted October 23, 2013 Just testing out the new Altirra 2.40 testing with ICET 280 i am having no trubble at all telnet around with it thumbs up. Quote Link to comment Share on other sites More sharing options...
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.