Jump to content
IGNORED

Altirra 2.30 released


phaeron

Recommended Posts

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!

Link to comment
Share on other sites

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 ;)

Link to comment
Share on other sites

  • 3 weeks later...

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.

Link to comment
Share on other sites

  • 2 weeks later...

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).

  • Like 3
Link to comment
Share on other sites

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 ;)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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,0
20 FOR I=0 TO 1000:NEXT I
30 ? PEEK(20)

 

Results:

Shadow ROMs: Disabled | Shadow Cartridges: Disabled | Loop Time = 91 Jiffies
Shadow ROMs: Enabled | Shadow Cartridges: Disabled | Loop Time = 67 Jiffies
Shadow ROMs: Disabled | Shadow Cartridges: Enabled | Loop Time = 32 Jiffies
Shadow ROMs: Enabled | Shadow Cartridges: Enabled | Loop Time = 10 Jiffies

Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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

Link to comment
Share on other sites

 

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. icon_smile.gif

 

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.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...