Jump to content

Photo

Altirra 2.30 released


232 replies to this topic

#201 danielcg OFFLINE  

danielcg

    Space Invader

  • 41 posts

Posted Fri Sep 6, 2013 12:55 AM

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!



#202 Mclaneinc OFFLINE  

Mclaneinc

    River Patroller

  • 4,968 posts
  • Location:Northolt, UK

Posted Sat Sep 7, 2013 7:11 AM

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



#203 MaPa ONLINE  

MaPa

    Dragonstomper

  • 915 posts
  • Location:Czech Republic

Posted Wed Sep 25, 2013 11:20 AM

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.

#204 phaeron OFFLINE  

phaeron

    River Patroller

  • Topic Starter
  • 2,251 posts
  • Location:USA

Posted Sun Oct 6, 2013 1:56 AM

Alright, release candidate:

http://www.virtualdu...2.40-test19.zip

http://www.virtualdu...-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).



#205 Mclaneinc OFFLINE  

Mclaneinc

    River Patroller

  • 4,968 posts
  • Location:Northolt, UK

Posted Mon Oct 7, 2013 2:28 AM

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



#206 serj OFFLINE  

serj

    Chopper Commander

  • 206 posts
  • Location:Russia, Omsk city.

Posted Mon Oct 7, 2013 3:54 AM

http://www.virtualdu...2.40-test20.zip

http://www.virtualdu...-test20-src.zip

 

Avery, whats new ?



#207 laoo OFFLINE  

laoo

    Space Invader

  • 37 posts
  • Location:Wrocław, Poland

Posted Mon Oct 7, 2013 9:20 AM

It's a fix for an obscure 65c816 bug that I've reported 18 hours ago :-o

I'm really impressed!



#208 phaeron OFFLINE  

phaeron

    River Patroller

  • Topic Starter
  • 2,251 posts
  • Location:USA

Posted Mon Oct 7, 2013 10:10 PM

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.



#209 Mclaneinc OFFLINE  

Mclaneinc

    River Patroller

  • 4,968 posts
  • Location:Northolt, UK

Posted Tue Oct 8, 2013 12:00 AM

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



#210 serj OFFLINE  

serj

    Chopper Commander

  • 206 posts
  • Location:Russia, Omsk city.

Posted Tue Oct 8, 2013 4:26 AM

Avery, you can upgrade in the emulator, VBXE core to version 1.26?



#211 avanze OFFLINE  

avanze

    Space Invader

  • 48 posts
  • Atari User
  • Location:State College, PA

Posted Tue Oct 8, 2013 1:31 PM

It's always nice to see an update. Thanks, phaeron.



#212 Xuel OFFLINE  

Xuel

    Dragonstomper

  • 605 posts
  • Location:US

Posted Sun Oct 13, 2013 1:43 PM

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?



#213 flashjazzcat ONLINE  

flashjazzcat

    Quadrunner

  • 12,634 posts
  • Location:United Kingdom

Posted Sun Oct 13, 2013 2:27 PM

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.



#214 atx4us OFFLINE  

atx4us

    Moonsweeper

  • 433 posts
  • Location:Michigan, USA

Posted Tue Oct 15, 2013 8:42 PM

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



#215 phaeron OFFLINE  

phaeron

    River Patroller

  • Topic Starter
  • 2,251 posts
  • Location:USA

Posted Wed Oct 16, 2013 12:05 AM

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.



#216 Xuel OFFLINE  

Xuel

    Dragonstomper

  • 605 posts
  • Location:US

Posted Wed Oct 16, 2013 1:54 AM

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



#217 atx4us OFFLINE  

atx4us

    Moonsweeper

  • 433 posts
  • Location:Michigan, USA

Posted Wed Oct 16, 2013 5:23 AM

 

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.



#218 Mclaneinc OFFLINE  

Mclaneinc

    River Patroller

  • 4,968 posts
  • Location:Northolt, UK

Posted Wed Oct 16, 2013 6:21 AM

Atx4us, this is the Excessive unneeded quote Police, come out with your hands up...

 

Book him Dano, Murder 1...



#219 atx4us OFFLINE  

atx4us

    Moonsweeper

  • 433 posts
  • Location:Michigan, USA

Posted Wed Oct 16, 2013 3:31 PM

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



#220 Mclaneinc OFFLINE  

Mclaneinc

    River Patroller

  • 4,968 posts
  • Location:Northolt, UK

Posted Thu Oct 17, 2013 2:11 AM

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



#221 serj OFFLINE  

serj

    Chopper Commander

  • 206 posts
  • Location:Russia, Omsk city.

Posted Fri Oct 18, 2013 9:35 AM

new test release.

 

http://www.virtualdu...2.40-test21.zip

http://www.virtualdu...-test21-src.zip



#222 phaeron OFFLINE  

phaeron

    River Patroller

  • Topic Starter
  • 2,251 posts
  • Location:USA

Posted Sun Oct 20, 2013 10:36 PM

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.virtualdu...2.40-test22.zip

http://www.virtualdu...-test22-src.zip



#223 flashjazzcat ONLINE  

flashjazzcat

    Quadrunner

  • 12,634 posts
  • Location:United Kingdom

Posted Mon Oct 21, 2013 9:30 AM

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! :)



#224 H.E.R.O. OFFLINE  

H.E.R.O.

    Chopper Commander

  • 215 posts
  • New leader of the Bungeling Empire
  • Location:Underground

Posted Mon Oct 21, 2013 11:24 AM

Well, I should extend my gratitude, A fine working emulator indeed. Atari 5200/400/800 is no longer a chore to get working.



#225 David Baldwin OFFLINE  

David Baldwin

    Chopper Commander

  • 210 posts
  • Location:Patea, New Zealalnd

Posted Tue Oct 22, 2013 11:11 PM

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.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users